同一个 Agent 的三份文档，颗粒度不必对齐

2026-08-25

我给那个写公众号文章的 Agent 写了三份文档：一份岗位卡、一份工作流卡片、一份 Profile。写的时候是分几次写的，写完各自都觉得挺顺。等到要把它们摆在一起对一遍的时候，发现步骤数对不上。

这是我自己那条产线上的事，不是从哪里看来的经验。下面说的每一步都是我自己动手写、自己发现问题、自己决定怎么处理的，所以它更像一份现场记录，而不是一套方案。

一份写十三步，一份写十二步

Profile 里的工序是十三步：解析输入并建立任务上下文、确认账号阶段和内容策略、评估选题价值、生成写作方向并等待选择、生成并确认提纲、检索和核验资料、撰写正文、优化标题和搜索关键词、生成和检查封面、执行最终质量与风险检查、保存结构化成果、同步微信公众号草稿箱、等待最终确认并记录发布效果。

工作流卡片里的工作流是十二步。少的那一步不是被删了，是被合并了——「保存结构化成果」和「同步草稿箱」在工作流卡片里写成了一步。

顺带交代一个现状，免得上面那串步骤被读岔：截至我写这篇的时候，草稿箱写入这条链路还没接通。这个 Agent 的交付终点实际停在「文章和封面已生成并保存」，不是「已经进了草稿箱」。Profile 里那一步写的是目标态，不是已经跑通的状态。

我是怎么发现的：不是通读读出来的，是互相点名点出来的

这一段我觉得比上面那个现象本身有用。

我不是通读一遍就看出来的。三份文档我都通读过好几次，每一次读都觉得没问题，因为通读的时候脑子里跟着的是叙事节奏——从收到素材到交出成品，读起来是连贯的，连贯就不会觉得缺东西。

真正暴露问题的是另一种读法：我拿 Profile 的步骤挨个去点工作流卡片里的判断点，看每一步对应哪个判断，点到后面对不上号了。工作流卡片的判断点是从「输入是否足够开始」一直排到「发布效果是否成功」，我顺着往下数，数到「草稿同步与公开发布」那里，Profile 那边已经多出一格。

第一反应是我自己写漏了。我先去翻工作流卡片，想找找是不是漏写了一个判断点，找了一圈没找到该补的位置——因为「保存」这个动作在工作流卡片的语境里本来就不需要单独一个判断，它没有分叉，不存在「保存完要不要往下走」这种事。反倒是 Profile 那边必须拆开，因为 Profile 写的是执行序列，一个动作落地一次，落到本地和推到外部是两次不同的落地。

发现方式在这里比结论重要：顺着读读不出结构问题，只有横着对才能读出来。通读检验的是叙事是否流畅，交叉点名检验的才是同一件事在两份文档里是不是同一个东西。这个读法我记下来了——以后改完其中一份，就拿它去点另外两份，而不是回头重读它自己。

为什么会差这一步

想明白之后，我发现差这一步不是笔误，是这两份文档在回答不同的问题。

工作流卡片的核心结构是十二个判断点，每个判断点都写成「判断点 + 判断依据」两段。它关心的是「在这里要做一个什么决定，凭什么这么决定」。保存成果和同步草稿在这个视角下是同一个决定的两半：内容已经定稿了，接下来把它安置好。这里面没有需要人凭依据去判的东西，所以并成一格是对的。

Profile 关心的是「按什么顺序做什么动作」。在执行视角下，往本地写文件和往外部接口推送是两回事：一个是本地动作，一个要跨出去，失败形态不一样，就不该压在同一步里。

而岗位卡又是第三种。它是八段结构——岗位名称、一句话岗位定义、输入、处理动作、输出、成功标准、人工兜底、本期不做。它压根不排步骤，它划的是边界：这个岗位吃什么、吐什么、什么算做对了、什么算做错了、哪些事这一期不做。它甚至把「未经过你的确认便直接公开发布文章」写进了「做错了」那一组，跟内容质量问题并列——也就是说，流程违规本身被定义为失败。这种事在工序清单里是写不下的，它不属于任何一步。

再看这三份文档的分工就清楚了：

岗位卡讲边界——不越界的判断在这里
工作流卡片讲判断——每个岔路口凭什么选在这里
Profile 讲执行——按什么顺序动手在这里

同一个流程在三个视角下被切成不同的段数，是正常的。切法服务于用途，用途不同，颗粒度就不必相同。

我最后改的不是步骤数

我一度想把它们统一成同一个步骤数，Profile 合并成十二步，或者工作流卡片拆成十三步。两个方向我都想了一遍，都不好。

合并 Profile 会丢掉一个真实存在的分界。本地落盘和推到外部系统，出事之后要退回的地方不是同一处，按我那几条切分依据，回退目标不同就得算两步。更要紧的是，外部这一侧紧接着还有一道权限线：我这条流程里，通过终审之后同步草稿是不需要再问人的，但公开发布必须人工确认——同步和发布被我拆成了两个权限等级。执行文档如果连「同步草稿」这个动作都没有单独一格，这条权限线在执行序列上就找不到挂靠的位置，读的人容易以为终审之后剩下的是一整块，抬手就能做完。

拆开工作流卡片则是往里塞一个假判断点。「要不要保存」这件事没有依据可写，硬写出来的判断依据就是废话，而这份卡片的价值恰恰在于每条依据都是真的能用来做决定的。

所以我最后的结论是步骤一步都不动。真要补，补的也不是步骤，而是在每份文档里说清它是从哪个视角写的——谁读到步骤数对不上的时候，能直接知道这是视角差异，不用像我一样先怀疑自己写漏了。

顺便也复核了一遍工序的切分位置到底压在哪儿。我这条流程里的边界基本落在三类地方：需要人工确认的地方（方向、提纲、终审）、产出物形态发生变化的地方（素材到方向、方向到提纲、提纲到资料、资料到正文、正文到封面）、失败后回退目标不同的地方。第三类最容易被忽略：正文不达真人感要求，回退到「撰写正文」；核心依据无法核验，回退到「评估选题价值」——回退目标不同，这两步就必须是两步。用这三条一量，Profile 那边把保存和同步分开，理由正好落在第三类上。

能带走的那句话

如果只让我带走一句，是这句：判断两个步骤该不该合并，别看它们像不像，看它们失败之后要退回到哪里。

退回到同一个地方，合并没损失；退回到不同的地方，合并就会让流程在出事的时候找不到落脚点。这条判据对我的用处比「文档要保持一致」大得多，因为前者能直接指挥我改文档，后者只会让我在两份文档之间来回削。

还有半句是关于文档本身的：多份文档并存的时候，先别急着对齐，先问每一份是写给哪个用途的。不同用途的文档强行对齐，代价是其中一份被削得不好用了，而这个代价不会当场显现，要等到真的按它干活的时候才出来。

这篇写的是我自己那套流程里的一次实际情况，不是通行做法。你的场景、工具和团队规模不同，结论未必适用，判断方式可能比结论更值得拿走。