把通用约束抽成简报,每次给 Agent 派活只描述差异
我给自己那条内容流水线派活,最早是把所有要求一股脑写在一次任务提示里:这一篇写什么、素材从哪来、段落怎么排、哪些话不许说、写完怎么自检。一批里每一篇都发一份这样的提示,每份提示都是完整的一大块。
这是我自己在维护的那条产线上的做法,谈不上什么规范。下面写的是它长到我自己都挑不动之后,我把它拆成了什么样子,以及拆的时候用的那条判据。
现象:提示越写越长,长到我自己挑不动
规格是一点点长起来的。我的规格文档在版本历史里被反复修订过,每一次修订背后都对应一次实际的翻车:有一次补的是「结构化字段只认事实、取舍放正文」这条;有一次补的是一整节读者画像,把技术细节的权重降下来。
这个过程本身没问题,问题在于这些条目全都堆在同一块提示里。到后来,一份派活提示里真正属于「这一篇」的内容只占很小一部分——写哪个主题、绑定哪些素材、落点在哪儿;剩下的绝大部分是「每一篇都一样」的东西。
更麻烦的是它不好读了。我自己在派活前扫一遍提示,要花心思去分辨哪几句是这次特有的。我自己都得分辨,那接活的 Agent 拿到这一大块之后会怎么分配注意力,我心里是没底的——这一句是我的担心,不是我测出来的结论。
当时是怎么发现的:我没有现场记录,只能从版本历史反推
先把话说清楚:具体是哪一天、因为哪件事决定动手拆的,我没有留下记录。我手上能确认的只有版本历史里的先后顺序,下面这几句都是从那个顺序反推的,不是当时的现场描述。
顺序是这样的。先有几次针对规格本身的修订——补「结构化字段只认事实、取舍放正文」是一次,新增读者画像那一节、把技术细节降权是另一次;这些修订都发生在前面。之后才出现「抽出通用写作简报」这一次改动,而我在那次改动的说明里给自己留的理由只有一句:派活提示可以大幅精简。
从这个先后关系反推,触发点大概不是某一次新的翻车。前面几次修订都是翻车驱动的——出了问题,补一条规则进去,规格厚一层。抽简报这一次不一样,它的说明里没有对应任何新问题,写的是「精简」。也就是说,它对应的是前面那些修订累积出来的结果:条目一条条加上去之后,每份任务提示里重复的那部分自己变得扎眼了。
这个反推还有一个可以对照的后置证据,我放到后面再说:简报抽出来之后,我再补通用约束时,是直接补进简报的。
**这件事真正严重的地方,不是提示太长。**同一类要求在好几份任务提示里各存了一份,意味着一条约束没有唯一的落脚点——改一处等于漏一堆,规格已经开始有多个互相不同步的副本了。长只是症状,副本才是病。
为什么会长成这样
回头看,我把两种性质完全不同的东西写在了一起。
一种是这一批、这一类、甚至所有批次都成立的约束。比如不许写会过期的数字,比如不许在事实之外做推断,比如措辞保持中立。这些东西和「这一篇写什么」毫无关系,它们描述的是这条产线的底线。
另一种是只在这一次成立的信息。写哪个主题、素材绑定到哪几条、这一篇的落点必须落在哪个具体的东西上、跟哪几篇要避开重复。这些东西下一次全都不一样。
一开始只有几条,混着写没成本。规格随着翻车一条条变厚之后,混着写的代价就出来了:通用条款的每一次修订,都要在所有副本里同步一遍;而每一份任务提示里真正的信息量反而被稀释了。
改成了什么:分三层,单次任务书只写差异
我把原来那一大块拆成了三层,通用的部分抽成一份独立的写作简报,派活时只发差异。
第一层,全局红线。所有篇通用,写在简报的第一节:禁写会过期的数字、禁在素材之外做推断、措辞中立不做优劣裁决。这一层我不打算按批次改动,改一次就是全线改一次。
第二层,按条件拼进去的约束。它们是可复用的,但只对特定的素材源或特定的写法生效。我这边的做法是按轴动态拼接——一批内容绑的是哪个事实源,就把对应那一组红线拼进这一批的提示里,别的组不拼。这一层不属于「所有篇」,但也绝不该写进单篇任务书,因为下一批用同一个素材源时它还要原样再用一次。
第三层,词形结构。同一批里也有不同写法,我把每一种写法的段落结构写死在简报里:
- 教程类固定五段:解决什么问题 → 前置条件 → 步骤 → 边界 → 怎么验证。第二段我特意标了「这一段最容易被跳过,不许省」。
- 排查类固定五步:现象 → 怎么确认是这个问题 → 处置 → 处置后怎么验证 → 什么情况说明不是这个原因。最后一步同样标了不许省。
- 对照类:必须给出决策路径而不是罗列参数,没有依据的维度直接写「这一点我们没有依据,不比」,不排名、不裁决优劣。
那些「不许省」的标注,对应的都是实际漏过的地方。它们是通用资产,每一批都要用,所以归简报。
剩下留在单次任务书里的,就只有差异了:这一篇的标题、绑定哪几条素材、落点是什么、要避开哪一篇的话题。派活提示因此可以大幅精简。
还有一点是这条产线特有的,也是我做完分层之后才想明白的。这条线上每一篇不止一个实现者,后面还跟着一个独立的评审员,两个 Agent 互不通气——评审员看不到实现者的推理过程,只拿到落盘的文件和规格。也就是说,规格不只是用来派活的,它同时是这两个 Agent 之间唯一的对齐面。共性约束散在各份任务书里的时候,我得自己保证发给实现者的那份和发给评审员的那份说的是同一件事;沉淀到简报之后,这个对齐变成结构性的了——两边引用的是同一份东西,不再需要我去逐份对。
分层做完之后有一个附带的验证,就是前面留的那个后置证据。简报抽出来之后,我又补过一条通用约束——关于事实随时间过期该怎么处置,要求给方法规则而不是直接给结论。这一条的改动记录写得很清楚:补在简报里。补的位置是唯一的,不需要挨个去改单次任务书,这本身就是分层生效的信号。反过来说,如果某条新约束我依然不知道该往哪儿放,那说明分层没做完。
可迁移的判断:问一句「下一批还用得上吗」
分层听起来容易,难的是每条约束到底归哪层。我用的判据只有一句话:这条约束,下一批还用得上吗?
- 下一批还用得上,且对每一篇都成立 → 进简报的全局层。
- 下一批还用得上,但只在特定素材源或特定写法下成立 → 做成可拼装的部件,按条件挂进去,不进单篇任务书。
- 只对这一次成立 → 留在单次任务书里,而且这才是任务书应该占满的地方。
这条判据的好处和我给红线写的那些判据是一个路子:它不是一个标准,是一个执行时当场能自问自答的问题。「这个数字下个月可能变吗」用来判断该不该写数字,「下一批还用得上吗」用来判断一条约束该住在哪一层。判据要能当场执行,否则写进规格也没人用得起来。
还有一个更省事的信号,不用等到规格厚得读不动:两份任务书之间凡是需要整段搬运的文字,都是分层没做完的部分。 一段话要被复制到第二个地方去,就说明它还没有属于自己的位置。这个信号比「觉得提示有点长」出现得早,也比它具体——长是渐变的,没人知道多长算长;而搬运是一个动作,做没做一眼就能看见。
需要说明的是,这篇讲的是规格变大之后怎么分层,不讲「翻车之后怎么把教训回写进规格」——那是另一件事,也是我这边规格变厚的主要来源。这里只处理变厚之后的收纳问题。
这篇写的是我自己那套流程里的一次实际情况,不是通行做法。你的场景、工具和团队规模不同,结论未必适用,判断方式可能比结论更值得拿走。
延伸阅读
- 上一篇(交付与复用):没核实的要显式列出来,并禁止 Agent 推测
- 下一篇(交付与复用):Agent 产线的校验脚本:覆盖范围本身要写进清单
- 这个专题的主论点:Agent 调用没报错,不等于这件事办成了
- 专题导读与七个阶段的地图:把 Agent 当成一个要上岗的员工来带:这个专题讲什么