最近经常看到 Graph Engineering 这个词，很多人第一反应是：又在整新词。其实，这个东西一点不神秘，相反还有点土味，几句话就能讲清楚。
我们站在写提示词的角度，会理解得更简单，因为它的本质还是提示词工程里的一种写法：
Graph Engineering，就是把复杂任务从线性的步骤列表，改写成由任务节点和依赖关系组成的图。
从 1234 工作流开始
我们平时写任务型提示词，很容易写成这样：
1. 分析项目结构2. 检查运行日志3. 制定优化方案4. 修改代码5. 运行测试这种写法简单、清晰，也符合人类写操作手册的习惯。
但它隐含了一个假设，5个任务是线性执行的：
第 2 步必须等第 1 步完成，第 3 步必须等第 2 步完成。
现实中的复杂任务却并非如此，真正的任务关系可能更接近：
分析项目结构 ─┐ ├─ 制定优化方案 ─ 修改代码 ─┬─ 单元测试 ─┐检查运行日志 ─┘ └─ 性能测试 ─┴─ 完成分析项目结构和检查运行日志通常互不依赖，可以同时进行；只有两项分析都完成后，才能制定优化方案；修改完成后，单元测试和性能测试又可以并行执行。
顺着现实路径把任务重新梳理一下，前后依赖关系就清晰很多，这就是 Graph Engineering 的核心。
为什么线性工作流不够
线性工作流只表达了一种前后依赖关系，所有任务都被默认串行执行。
对于简单的线性工作，这种表达没有任何问题。但对于复杂任务，它会产生两个典型问题。
第一个问题，是强行串行。
分析项目结构和检查运行日志其实没有依赖关系，却被提示词排成了一条直线。
第二个问题，是隐藏依赖 。
制定优化方案依赖于前两项工作的输出，在线性流程上并没有准确地体现出来。步骤虽然写出来了，真正的任务关系却仍然藏在自然语言里。
Graph Engineering 做的，就是把这些关系显式表达出来。
怎么在提示词里写一张 Graph
写 Graph 并不需要特殊语法，也不一定真的画图。
关键是把任务拆成节点，再把节点之间的关系写清楚。
第一步，不要急着编号，而是先列出节点。
例如：
节点 A：分析代码结构节点 B：检查运行日志节点 C：制定优化方案...每个节点都应该对应一个相对独立、能够判断是否完成的任务。
第二步，再写依赖关系。
例如：
A、B 无依赖，可并行执行。 C 依赖 A 和 B。 D 依赖 C。...这样，一张任务图就自然形成了：
A ─┐ ├→ C → D B ─┘ 最后，再补充节点之间传递的信息。
例如：
节点 A 输出： - 核心模块- 调用链- 性能瓶颈
节点 C 输入： - 节点 A 的代码分析- 节点 B 的日志分析这样，每个节点不仅知道什么时候开始，还知道应该接收什么、产出什么。
小结
Graph Engineering 并不是让提示词变得更复杂，而是让任务结构表达得更准确。
当任务足够简单时，一条线就够了；当任务开始出现并行、汇合和多重依赖时，与其继续往 1234 后面加步骤，不如把提示词升级成一张任务图。