把 Agent 的输出结构写死：每种词形各有固定段落

2026-08-25

一次写一篇的时候，我是在流程中间的：定方向、看提纲、终审，三道闸门都由我亲自过。那时候不存在「结构」这个问题——提纲我自己给的，哪一段该有什么，我心里有数，缺了当场就补。

改成一批一批地写之后，我就退到流程两端去了：开工前定规格和事实源，收工后验收。中间那些逐篇确认的环节，人是必然退出的，不然批量就没有意义。退出之后，最先出问题的不是文笔——实现者写出来的句子都挺通顺——而是骨架。同一批交上来的稿子，每一篇单独读都成立，放在一起就会发现它们回答的根本不是同一组问题：有的篇上来先讲原理，有的直接进操作；有的给了验证方法，有的写完步骤就结束了。

更麻烦的是，这种散架在成品侧几乎看不出来。一篇缺了关键段落的文章，和一篇不缺的文章，表现是一样的——都是「一篇读得通的文章」。我的评审员是另一个 Agent，它不知道实现者的推理过程，只拿到落盘文件和规格。如果规格里没写这一类文章该有哪几段，评审员手上就没有可对照的东西，它只能凭自己的语感判断「这篇好像少了点什么」，而语感这种东西在两个互不通气的 Agent 之间是不传递的。

判据：问一句「少写哪一段，交出来的东西照样像样」

这条我给自己的判断方法很简单，是一个当场就能做的动作，不需要等到收工验收。

拿你现有的写作任务书，逐段问：实现者少写哪一段，交出来的东西照样像样？ 只要存在这样的段落，它就一定会被跳过——不是因为实现者偷懒，是因为省掉它之后成品仍然自洽，没有任何一个环节会报错。

第二个动作是并排。把同一类的两篇成品放在一起，试着逐段对齐。能对齐，说明结构是被规格约束住的；对不齐，说明每篇都在自由发挥，这一批的骨架是随机的。

这两个动作的共同点是：判据要能当场执行，不能只给标准。 我在规格的另一处也是这么写的——讲「不许写易变数字」那条红线时，我没有列举哪些数字不许写，而是给了一句实现者可以直接问自己的话：这个数字下个月可能变吗？会变就不写。列举清单永远会漏，一句可以当场自问的话不会。结构这件事同理：与其写「文章要结构完整」，不如把段落顺序直接摆出来，让实现者对着填。

落到具体：段落顺序写进任务书，一种词形一套

我的写作任务书是分三层拼出来的：最外层是全局红线，所有篇通用，比如禁易变数字、禁推断、措辞中立；中间一层是按事实源动态拼接的专属红线，只对用了某一类素材的篇生效；最里层就是词形结构——我按文章要干的事把它们分成教程、排查、解读、对照四种，每一种的段落顺序在任务书里是写死的。

教程类和排查类的固定结构长这样：

教程类（五段，顺序不可调）
  ① 解决什么问题
  ② 前置条件        ← 这一段最容易被跳过，不许省
  ③ 步骤
  ④ 边界
  ⑤ 怎么验证

排查类（五步，顺序不可调）
  ① 现象
  ② 怎么确认是这个问题
  ③ 处置
  ④ 处置后怎么验证
  ⑤ 什么情况说明不是这个原因   ← 最后一步不许省

对照类没法用固定段落写死，我给的是三条硬约束：必须给出决策路径而不是罗列参数；没有依据的维度，原话就写「这一点我们没有依据，不比」；不排名、不裁决优劣。

注意上面那两行箭头。那不是排版装饰，是任务书里真实存在的批注文字——「这一段最容易被跳过，不许省」「最后一步不许省」，逐字写在段落后面。整份任务书里被这样单独点名的段落不多，点到的都不是随手加的。

那几处「不许省」为什么要单独点名

规格里所有标了「不许省」的地方，对应的都是实际漏过的地方。不是我坐在桌前预想出来的风险清单。（至于哪一次漏在哪一篇上，我手上没有逐条的记录，能确认的只是每一条点名都对得上一处实际发生过的疏漏。）

我的解释是这样：被点名的这几段，共同特征是省掉之后成品不会露馅。

教程篇的前置条件就是典型。写的人手里握着完整上下文，环境、依赖、权限这些东西对他来说是背景板，不构成信息；他从「第一步做什么」直接切进去，读起来是顺的，甚至更紧凑。露馅要等到读者照着做、卡在第一步、发现自己环境根本不满足的时候——那时候文章早就交付完了。

排查篇的最后一步更隐蔽。「什么情况说明不是这个原因」这一段，删掉之后文章的完成度看上去反而更高：现象、确认、处置、验证，闭环得漂漂亮亮。代价是把读者往一条单行道上引——他按流程处置完，问题还在，而文章没给他任何回头的路标。这一步的价值恰恰在于承认「你可能找错了方向」，而这正是最容易被写作时的顺畅感挤掉的东西。

这和我给评审员的一条设计是同一个道理。评审任务书里，我要求评审员先验证产物是否存在、再验证产物质量，把「有没有做」和「做得好不好」拆成两个先后的检查。原因是这两类失败的表现完全一样——都是「返回了一个看起来正常的结果」。缺段落的文章也属于这一类：它不会以错误的形式出现，只会以「正常」的形式出现。

对付这种失败，事后挑毛病是低效的，因为挑的人手上没有基准。有效的手段是把结构和禁区写进任务书，让「缺了什么」变成一个可以逐条比对的事实，而不是一个需要品味的判断。批量生产里防质量滑坡，靠的是开工前那份规格，不是收工后那双眼睛。

边界：什么时候不该把结构写死

这条不是到处都适用，我至少能说出四种情况。

一次只写一篇、而且方向、提纲、终审三道闸门都由我亲自过的时候，写死结构基本没收益，还碍事。 人在中间的时候，缺段落我当场就看见了；固定段落反而会把一篇本该自由展开的文章框住。结构写死是为了补偿「人退出中间环节」这件事，人没退出就不需要补偿。

结构写死会把结构性的错误等比例放大。 这和事实卡是一回事：卡一旦有错，错误会同时出现在用了这张卡的每一篇上，需要回头全批检查——我这条线上真发生过评审阶段反查出卡里某个数值有误、几篇同时出错、只能由我实测修正再全批过一遍的情况。段落结构也是——顺序定错了、某一段的问法设计得不好，整批文章会用同一个姿势跑偏，而且因为它们彼此一致，看起来还特别整齐。针对事实卡，我给评审员留了一条权限：它有权质疑事实卡本身，不只是核对文章符不符合卡；发现卡有问题要写进反馈，而不是自行「修正」后写进文章。段落结构的放大方式和事实卡是同一种，这条权限该不该照样覆盖到它，我倾向于该。

配额型的约束不能照搬「写死」的思路。 我吃过一次亏：给标题定长度上限时，忘了先减掉必须包含的关键词本身占的长度，剩下的空间就不够了，实现者只能砍掉关键搜索词来满足上限，返工放宽之后才修好。写死的应该是段落顺序这种「结构」，不是可发挥的空间；把空间也压没了，逼出来的是更差的取舍。给下游的配额型约束，要先减掉不可压缩的固定部分再给。

结构齐了不等于内容对。 段落是否齐全可以靠机械检查，但机械检查有它自己的陷阱：我这条流水线上出过一次首轮命中全是误报的情况——命中的是模板自带的合规声明、规范强制要求写的否定句，以及代码示例里的数字。误报率一高，执行者就会开始整体忽略这道门，那它等于不存在。而且脚本查得了字数、死链、格式、孤儿页，查不出事实错误。结构门和事实核验是两道门，不能互相顶替。

说到底，把段落写死解决的是一个很窄的问题：在人不在中间、评审员和实现者互不通气的前提下，让「这篇缺了什么」变成一个可对照的事实。它换不来好文章，只能保证一批文章不会各写各的。

这篇的判据来自我自己带 Agent 干活的实践，样本有限。它更像一份可以拿去验证的假设，而不是一份可以照抄的规范。