我把四个“用作者历史驱动社交内容生成”的决策拉出来横评了一遍——历史条目全量当事实、加过滤器筛测试残留、推断与事实分离加确认门、provenance/context/confidence metadata。结论先甩上来：过滤器必装但不够，确认门是唯一必须上的修法，provenance 只在从零建系统时保值，存量内容追不动。反 AI 味脚本是最后一道工序，放在最前面修就是给已经跑偏的方向套滤镜。
材料交代清楚。样本来自 dev.to 上一篇 9 月 8 日的 agent skill 建设复盘，作者不是工程岗，做产品 adoption 的，用 Claude 写代码，她负责需求、测试和纠偏。样本量：一次 skill 搭建、三连失败的完整日志、两轮修复、一篇 720 字的修订稿和一篇 1198 字的脚本通过版做对照。没有版本号，这个品类两天一更，能标的只有日期。评论区的十一条评论我筛了四条有实质反驳的放进对比。这次不是跑分横评，是决策横评——判断基于过程日志，不是 benchmark 数字。条件先摆清楚：非工程背景、单人维护、不自动发布、只到草稿阶段。换一个团队结构，下面的推荐列要重排。脱离条件谈优劣是耍流氓对比，这是我说过很多次的话，这次的条件就这么窄。
先把维度表摆出来：
| 方案 | 能识别 QA/测试残留 | 能阻止推断当事实 | 存量语料可追溯 | 工程成本 | 推荐 |
|---|---|---|---|---|---|
| 历史条目全量当事实 | 否 | 否 | — | 零 | 任何时候不建议 |
| 加过滤器（短帖/重复/测试信号） | 部分 | 否 | — | 低 | 必装但不够 |
| 推断与事实分离 + 确认门 | 不直接 | 是 | 否 | 中 | 核心首选 |
| provenance/context/confidence metadata | 是 | 是 | 难 | 高 | 新系统建议，存量别追 |
三连失败的那三出，根子在一处，不是三件独立的事。skill 启动后调 list_posts 拉了最近 20 条，专门看两样东西：哪些话题已经写过、哪些线头没下文。它扫到 7 月下旬两条 LinkedIn 帖，说 Publora 要上线 Zapier，后面没更新，于是推断“作者承诺过要更新”。翻车点就在这句。那两条帖根本不是受众内容，是 Zapier review artifacts——提交 Zapier 审核要在一个 live Zap 里把每个 trigger 和 action 跑通、启用、留一条成功记录，账户里就冒出这种测试残留。agent 分不出来，因为它们和正常帖子挤在同一列表里，长得像，时间线也像。
评论里 Marco 说到了点上：证据是真的，但被赋予的意义超过了证据能撑得住的程度。Pratik 补了一句更准的，说这不是文本幻觉，是 speech act 幻觉——句子没错，是句子的语用力错了。这个区分关键。查词汇、查重复结构、查 withheld hook 都抓不到这种错，因为错不在句法层，在语用层。Agent 说“你承诺过更新”这句话，本身被“你承诺过”这个表述污染了——原帖没有任何 promise，那是审核提交后系统留下的记录，和作者本人的意图之间没有因果线。
作者第一轮修复加了三层过滤器：短帖、发布间隔几分钟内的近似重复、带测试或验证信号的内容。这层筛子能挡住大部分 QA 残留，但挡不住 agent 从剩下来的内容里继续做超限推断。所以她后加的规则更重要：agent 不准把从历史推断的任何东西当事实陈述，只能报告发现了什么，然后问作者确认。这条规则上去之后，对话在一轮内转向了。一轮，不是三轮。
这中间有一个 agent 架构上的基本区分，我想直接点出来：agent 可以是一个 consistent reader——它比作者更稳定地把一个人的公开记录读全，一条不漏地翻出“你 7 月提过 Zapier，后来怎么样了”。但它不是 author of intent，它没资格替作者决定“当时那两条帖意味着什么”。这两者的边界，就是 speech act 幻觉的根。作者的回复也圈死了这个边界：agent 可以读得比我全，但它不能替我定我发过的东西有什么意图。这句我几乎想全文引进去当确认门的设计原则。
确认门的工程形态其实很朴素。同一个“基于最近 20 条历史找话题”的任务，指令差出两个方案：
// 天真版：列表条目全当既定事实
- 拉最近 20 条 post
- 找出提及但未闭环的 thread
- 建议写点东西，开场可写“你承诺过要给 Zapier 更新”
// 确认门版：报告发现，不替意图下结论
- 拉最近 20 条 post
- 找到两条 7 月下旬帖子，提到 Publora 将上线 Zapier，后续无公开更新记录
- 报告口径：“我在你的历史里找到这个模式，你看是不是你想展开的？”
禁止句式：“你承诺过 / 你说过 / 你之前已经决定了”
这段代码能跑通，贴出来是为了说明为什么确认门比过滤器更接近根因。确认门的实质是把话语权交还给作者：从历史里读出来的是线索，从线索到意图这步，必须由作者自己走。
第二个翻车点不太显眼，但同样典型，而且更容易被漏掉。skill 后来问“Zapier 那边怎么样了”，作者说 live 了但还在 beta。这时 skill 没问一句“这个话题你今天是不是已经写过文章了”。事实是作者当天早上刚在 Dev.to 发了一篇四分钟的文章，覆盖了八轮 review、REST Hooks、和一个 label field 里的 JS workaround。Publora 的产品数据里没这条，skill 自然不知道。但问题不在“不知道”，在于 agent 请求一个缺失事实时，默认“这个话题没被写过”——这个默认本身就是一种反向超限推断。修复很轻：agent 每次向用户要一个缺失事实，同时问一句“这个话题你是否已经在文章 / changelog / release notes / 类似来源里覆盖过”。成本几乎为零，但很多 agent skill 没装。
话题生成端的架构也值得单独拉出来比。一开始的版本是给三个 topic angles 而不是 single draft，这个设计对——给用户选项比递一份“唯一正确答案”更尊重作者自己的判断。后来版本扩到 8 类 40 个角度，每个角度都要求一个来自用户的核心事实：一个 mistake、一个数字、一个工具名。这个改变比翻倍的角度数重要得多：要求核心事实，就是强迫 agent 锚定在真实发生的东西上，而不是从历史模式里合成一个“看起来像主题”的东西。Clara 在评论里说选主题是她主要的卡点，这正好印证：痛的不是没话题，是没一个她敢信任的话题。
反 AI 味这条线也很能说明问题。脚本查 machine-sounding vocabulary 和 repeated structures，draft 过了。同事还是认出了 AI slop。三个理由：draft 里三处强行文几乎复刻了当天早上旧文里的原句；结构上有 withheld hook、一个过分工整的 paradox、三连列表、加“literally”这种词。修订稿最后压到 720 字符，脚本通过那版是 1198 字符。结论：脚本查的是文本表层特征，抓不到和旧文撞句这种跨文本重复，也看不到文本之外的 recent publications、audience、cumulative pattern buildup。作者把 checker 留了下来，但移到了更靠前的位置，明说它看不到文本之外的语境。这个操作我认同——脚本前置的价值是快速挡掉表层 slop，最终闸门仍得是人眼加上下文比对，尤其要比对近期已发布内容。
三种反 slop 姿势拉出来比：
| 检测方案 | 词汇/重复结构 | 与旧文撞句 | 结构 cliché | 误报 | 推荐 |
|---|---|---|---|---|---|
| 负向提示 | 不稳定 | 抓不到 | 不稳定 | 低 | 不建议依赖 |
| 脚本前置查表层特征 | 部分抓到（漏了真 slop） | 抓不到 | 抓不到 | 低 | 前置用，别当闸门 |
| 人眼 + 上下文/已发内容比对 | 慢 | 抓到了 | 抓到了 | 看人 | 最终闸门 |
负向提示这一行单独说一下。作者试过用 negative prompting 禁结构 cliché，结论不可靠，最后把 anti-slop 检查挪到 post-draft 的单列 pass。我不意外。negative prompt 在扩散模型里还有点用，但在 LLM 生成文本上想靠“别写 withhold hook”这种句式约束住结构倾向，属于用错工具。结构 cliché 是分布性的，是训练数据里成片出现的，不是一句禁令能掰回来的。
还有一件事必须说清楚：作者把“人确认”和“发布决策”设成了两个独立的 gate。很多人搭这类 skill 会把这俩混成一个——用户点一下“可以发”就等于确认内容了。这俩不是一回事。确认门的职责是纠正 speech act 幻觉，发布决策的职责是作者最终负责。分开了，任何一个环节出错都能被单独拦下来；混在一起，一笔带过的确认就成了审计上的形式主义。
场景化建议收一下。如果你在搭 agent skill 写社交内容：确认门必装——凡是从历史推断的东西，只准报告不准陈情；历史语料先进过滤器再喂，QA 和测试残留不筛掉，后面全白干；agent 请求缺失事实时带上一句“已覆盖检查”；anti-slop 脚本前置、人眼加已发内容比对收尾；provenance/confidence metadata 如果从零建系统就上，存量内容别追了，写时没记的现在补录成本高到不划算。都不是的话，自己拿表格重排，别照搬我的推荐列。
没出现在推荐里的不代表差。provenance metadata 那套不是不好，是“写时捕捉”和“事后追溯”的成本根本不对称，存量内容追不回来，只适合新系统。负向提示在别的文本生成场景里或许还有它的位置，但在这条链路上作者试过不可靠，就别硬上。当前版本是 2026 年 9 月这个点上的结论，下个大版本如果模型本身把 speech act 判断做进上下文，确认门和 metadata 的权重会重排——这个品类我盯着呢，有新进展会重跑。