把主语去掉，Agent 写的东西还成立吗

2026-08-25

一批稿子交上来，你一篇篇看过去，挑不出错。句子通顺，结构完整，该有的段落都在。但看到后面几篇的时候会有一种说不上来的别扭：这一段挪到上一篇里去，好像也完全成立。把标题遮住，你分不出这是哪一篇。

这是我在批量内容生产里遇到的最难处理的一类问题。它不是错误，所以任何以「找错」为目的的检查都拦不住它。字数够、格式对、没有死链、没有残留的脏标签——我这条线上的客观脚本会全部放行。但这批东西没有价值，因为它没有携带任何只属于这个题目的信息。

更麻烦的是，你没法靠一句话把它修好。跟执行者说「内容要写得具体一点」，下一版会回来更长、更详细、依然可以互换的文本。「具体」是一个主观判断，你脑子里有个标准，执行者脑子里也有个标准，两个标准不一样，而且都没法拿出来对齐。

这件事在什么时候才真的成为问题

一次写一篇的时候，这个问题不存在——你自己就是那道门，读着不对就当场推翻重来。人在流程中间的每一步上，方向、提纲、终审都过一遍手，「写泛了」这种事根本活不到交付。

它是在人退到流程两端之后才浮出来的。我这套批量流水线上，人的位置从「流程中间」挪到了「开工前定规格与事实源、收工后验收」，中间那一段由每篇一个实现者加一个独立评审来跑，两个 Agent 互不通气。这个替换本身是成立的，但它有个前提：所有原本靠人在中间「读一眼就知道不对」的判断，都得提前变成写得出来的东西，塞进任务书里。

塞不进去的那部分，就是漏出来的那部分。「不许写会过期的数字」塞得进去，「不许出现本机路径」塞得进去，「写具体一点」塞不进去——因为它不是一条约束，它是一种感觉。

于是问题变成：能不能把「写泛了」这个感觉，换成一个执行者当场能自己做、做完能得到明确答案的动作。

判据：把主语删掉，看句子塌不塌

我在写作规范里给出的原句是这样一条：

把项目名从你的文章里去掉，如果它还能成立，说明写太泛了，重写。

它的形状值得注意。它没有描述「什么算具体」，它给了一个可以执行的操作和一个可以观察的结果。执行者不需要理解我心里的标准，只需要做这个动作：把文章里那个专有名词全部删掉，然后重读一遍，看句子有没有塌。

塌了，说明这篇文章的骨架长在这个对象身上——那些句子离开它就没有意义了，这正是你要的。没塌，说明你写的全是可以套在任何对象上的通用陈述，那个专有名词只是被撒在正确的废话上面的调料。

这个转换的价值不在于判据更严格，在于它把一次主观评判换成了一次动作加一次观察。主观评判没法交给别人做，因为交出去的只有词，接的人会用自己的理解填空；动作可以交出去，因为动作的执行过程和结果是同一件事，做没做、结果是什么，双方看到的一样。

我这套规格里另一条红线用的是同一种形状。「不许写易变数字」这条，我给的不是一张禁写清单，而是一句问话：这个数字下个月可能变吗？ 清单永远列不全，问话可以覆盖没想到的情况，而且执行者拿着这句话面对一个具体数字时，答案是当场就有的。

两条判据的共同点：都是把「你要达到某个标准」改写成「你去做一件事，然后看看发生了什么」。前者需要执行者拥有和我一样的品味，后者不需要。批量生产里我没法给几十个执行者装同一套品味，但我可以给他们同一个动作。

落到具体动作上：它在任务书里的位置

这条自检在我的规格里不是一段说明，是自检清单里的一项，和「用 Python 数字数」「搜一遍残留标签」并排，写成祈使句，写在执行者交付之前必须走一遍的地方。

它同时出现在两个地方，这一点是有意的。实现者的任务书里有它，评审员的任务书里也有它。评审员是另一个 Agent，不知道实现者是怎么想的，只拿到落盘的文件和同一份规格。同一条动作型判据，两个人各做一遍，结果应该一样——这是动作型判据比标准型判据多出来的一个好处：它可以被独立复核。如果我写的是「内容要具体」，评审员和实现者对同一篇文章会给出不同的判断，而且谁也说服不了谁。

推广到任何写作类岗位的时候，要替换的是「主语」那个位置上放什么。我这条里放的是项目名，因为那批文章是围绕具体项目写的。换一个场景，那个位置可能是产品名、客户名、某个具体功能的名字、某次具体事故的名字。判据的形状不变：找出这篇文章名义上在讲的那个唯一对象，把它的名字从全文抹掉，然后看剩下的文本还站不站得住。

再往前推一步，这条自检还有一个副产品：它能反过来告诉执行者该去补什么。文章抹掉主语之后没塌，说明缺的是只有这个对象才有的东西——一段具体的原文、一次具体的失败、一个具体的判断分歧。执行者知道该往哪个方向补，比知道「要更具体」有用得多。

什么情况下这条不适用

第一类是那些本来就该泛的文章。概念解释、入门总览、方法框架，它们的价值恰恰在于可迁移，抹掉主语之后当然还成立，而且必须还成立。对这类文章用这条自检，会把好文章判成坏文章。所以这条判据要绑在词形上生效，不是全批一刀切——我的规格是按词形分别写结构和自检项的，哪一类适用哪几条，在任务书里就分好了。

第二类是主语本身就是变量的文章。做横向对照的时候，文章要在两个对象之间来回走，任何一个的名字被抹掉，剩下的都是残句，这时候「塌了」不代表写得具体，只代表这篇的句子结构依赖两个主语。对照类要用的是另一套判据——有没有给出决策路径，而不是有没有绑死在某一个对象上。

第三类边界更要紧：这条自检查的是「泛」，查不出「错」。 一篇文章可以句句都紧扣某个具体对象，抹掉主语立刻散架，同时通篇写的是错的。这两类失败的检查手段完全不重合，一个靠动作型自检，一个靠回到事实来源逐条核对。我这条流水线上，客观体检脚本能查字数、能查死链、能查孤儿页，唯独查不出事实错误，这两道门谁也顶不了谁。把动作型自检当成质量的全部，会得到一批扣得很紧的错误文章。

最后一条边界关于这条判据本身：它是给一个不会自己回头怀疑的执行者用的。人写完东西会有那种别扭感，会停下来重读；一个按任务书干活的执行者不会，它交付的时候只知道任务书上的项目做完了没有。所以这条自检的全部作用，是在没有那种别扭感的地方，人工造一个当场就能得到答案的动作出来。你的执行者如果本来就会自己停下来重读，这条对它是多余的。

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