加了“去 AI 味”Skill，水稿还是水：AI 写作流程缺的不是润色

它会检查“此外”“至关重要”这类高频词，提醒我删掉整齐得过分的三段式、连续破折号和突然升华的结尾。检查跑完，文字确实顺眼了一些。

但文章还是水。

标题没有非点不可的理由，正文说不清读者能带走什么，证据也只是几条新闻链接。继续调文风，等于拿 lint 工具修产品需求。

这篇文章复盘一次真实的流程改造：我把 AI 写作拆成需求发现、证据与读者合同、结构生成、文风与发布审计四个阶段。每个阶段都有独立产物，前一层没通过，后一层不启动。

这次问题为什么值得单独拆

2026 年 9 月 17 日，Thomas 和 Erin Ptacek 发了一篇 How to Write with an LLM。核心建议很克制：先由作者写，再把模型当 copyeditor，而不是 ghostwriter。

文章进入 Hacker News 后，短时间内积累了几十条评论。讨论没有形成统一结论，但暴露了几个真实分歧：

• 有人认可模型查赘词、事实错误和论证漏洞；
• 有人认为模型无法站到预期读者的位置上；
• 还有人担心，大量低成本生成内容正在消耗阅读信任。

这些评论不能代表所有读者，却解释了一个常见现象：文章的“AI 味”并不只来自词汇。更深的问题是，作者把需求、判断和措辞一起交给了模型。

如果输入只有一句：

帮我写一篇专业、有深度、能引发共鸣的文章。

模型需要同时猜四件事：谁会读、他为什么在意、哪些材料可信、什么结构能兑现承诺。结果通常很完整，也很平均。

问题不在模型不会写，而在流水线只有一个 generate()。

把写作从一个 Prompt 拆成四个阶段

下面是这套流程的概念伪代码。它用于说明阶段边界，不是可直接运行的 SDK：

<span># conceptual_pseudocode</span>
brief = discover_demand(fact_signals, heat_signals, reader_signals)
contract = define_reader_contract(brief)

<span>if</span> brief.score >= <span>70</span> <span>and</span> contract.is_specific:
    draft = generate_with_structure(contract)
    report = audit(draft, evidence=brief.sources)

    <span>if</span> report.blockers == []:
        final = humanize(draft)

顺序很重要。humanize() 在最后，因为它只能处理表达，无法替前面三层补证据。

阶段一：需求发现，不从主题名开始

“AI 写作”是主题，不是需求。

需求应该描述一个正在发生的时刻：开发者已经用 LLM 写完技术博客，换了模型、删了套话，成稿仍像一份没有决策价值的说明书。

我把选题证据分成三类：

一条产品公告可以证明“新”，不能单独证明“读者需要”。一个高赞帖子可以证明“有人看”，也不能证明它适合自己的账号。

因此增长简报里必须单列：

<span># conceptual_configuration</span>
<span>reader_now:</span> <span>正在反复调</span> <span>Prompt</span> <span>修一篇水稿</span>
<span>belief_before:</span> <span>去掉</span> <span>AI</span> <span>高频词就会像真人写作</span>
<span>change_after:</span> <span>先验证需求和证据，再处理文风</span>
<span>promise:</span> <span>给出可审计的四阶段写作流水线</span>
<span>stakes:</span> <span>时间、读者信任、错误判断</span>
<span>non_goals:</span>
  <span>-</span> <span>不承诺流量</span>
  <span>-</span> <span>不把单个平台评论当行业共识</span>

这些字段不是为了让 JSON 看起来专业。缺少其中任何一个，正文都很容易退回新闻摘要。

阶段二：先签读者合同，再让模型起草

“程序员”“职场人”“AI 用户”都不是合格的读者定义。

一个可执行的读者合同至少要回答：

reader_now     他此刻在做什么、卡在哪里
belief_before  他现在相信什么
stakes         不处理会损失什么
desired_after  看完能改变哪个判断或动作
promise        文章明确交付什么
proof          靠哪些证据兑现

这一步和产品需求很像。模型可以帮忙找模糊字段、模拟反对意见，却不能证明某种痛点真的存在。

例如，“读者会担心失业”只是猜测。评论区反复有人讨论“我无法判断这是不是 AI 输出”“事实核查有用但文风建议不可信”，才是可记录的读者信号。

两者的权限不同：

• 模型生成的反对意见属于假设；
• 真实评论、搜索问题和工单才属于需求证据。

如果把模拟读者当成真实读者，后面的分数再漂亮也没有意义。

阶段三：正文之前，先审标题和留存图

以前我的顺序是先写正文，再从摘要里挑一句当标题。这样得到的标题通常准确，也通常没有点击理由。

现在标题单独过一道门禁：

• 至少生成 16 个候选；
• 覆盖异常证据、失败根因、工程决策和边界纠偏四类；
• 分别检查真实性、注意力、读者关联、收益和可说出口；
• 主标题至少 21/25，真实性和读者关联均不低于 4/5。

本篇实际生成了 20 个标题。最终选择的是：

加了“去 AI 味”Skill，水稿还是水：AI 写作流程缺的不是润色

它先暴露可观察异常，再承诺解释缺失的流程。备选标题“去 AI 味只是 lint”更像方法总结，因此没有放在第一位。

标题通过后，再画留存图。每一节必须新增一种价值：现场、机制、证据、反对意见、方法或决策。连续两节只换说法，就合并或删除。

本篇的留存节点是：

异常现场
  → 单 Prompt 的失败机制
  → 四阶段架构
  → 最小字段
  → 真实审计输出
  → 反对意见
  → 可复用检查表

这比“背景—现状—问题—展望”更麻烦，但也更容易发现哪一段只是在凑字数。

阶段四：最后才做 humanize 和确定性审计

到这一步，humanizer-zh 才派得上用场。

我不再让模型执行“帮我写得更好”，而是限制它的权限：

不要重写正文，也不要提供可直接替换的句子。

只标记：
1. 哪句话缺少来源；
2. 哪两段表达同一个意思；
3. 哪个结论比证据更确定；
4. 哪个小节没有给目标读者新增价值；
5. 哪些措辞带有模板化 AI 痕迹。

模型擅长做这种不知疲倦的机械检查。具体改成什么，仍由作者决定。

语言审查和发布审查也要分开。语言自然不代表证据完整，正文完整不代表可以进平台编辑器。

我给最终包增加了两个确定性脚本门禁。下面是本次真实执行结果，目录已缩写：

$ python3 score_candidates.py 今日热点选题-增长简报.json
llm-writing-second-eyes  90/100  selected

<span>{</span>
  <span>"status"</span><span>:</span> <span>"ready"</span><span>,</span>
  <span>"errors"</span><span>:</span> <span>[</span><span>]</span><span>,</span>
  <span>"reviews"</span><span>:</span> <span>[</span><span>]</span><span>,</span>
  <span>"summary"</span><span>:</span> <span>{</span>
    <span>"title_candidates"</span><span>:</span> <span>20</span><span>,</span>
    <span>"title_angles"</span><span>:</span> <span>4</span><span>,</span>
    <span>"retention_beats"</span><span>:</span> <span>7</span>
  <span>}</span>
<span>}</span>

第一个分数是项目内部的选题门禁。第二个结果只说明必填字段、标题数量和留存节点满足当前合同。

它们都不预测阅读量，也不能证明读者假设正确。脚本负责拦住明显缺项，作者仍要为证据与判断负责。

AI 当然可以写第一稿，但生成和验收要隔离

这套流程不要求每个字都手写。

格式固定的周报、已有材料的整理、接口说明初稿，让模型生成很合理。要避免的是：同一个上下文既负责生成，又负责给自己打分，最后再宣布“文章已经很完整”。

更稳妥的做法是分离角色：

1. 生成阶段只读取已经通过的读者合同和证据清单；
2. 审查阶段重新读取正文与证据，不继承生成过程中的自我解释；
3. 确定性脚本检查字段、数量、路径和状态；
4. 人工终审标题承诺、证据强度和平台实际预览。

这和代码审查类似。能编译不等于需求正确，单元测试通过不等于线上验收，文风自然也不等于文章值得发布。

可以直接复用的最小检查表

下一次准备继续调 Prompt 前，先判断失败发生在哪一层：

• 我能说清目标读者此刻正在做什么吗？
• 至少有事实、热度、读者三类证据吗？
• 文章承诺的是判断或动作，而不是“带你了解”吗？
• 标题里的异常和收益在首屏兑现了吗？
• 每一节都增加了新证据、机制、反对意见或方法吗？
• 模型生成的读者反应是否被误当成真实需求？
• 语言审查是否发生在需求和证据通过之后？
• 内部评分是否被误写成流量、质量或平台推荐保证？

只有最后两项有问题时，继续优化 humanizer 才可能有用。

如果前面几项是空的，水稿不是被 AI 写坏的。它在生成之前，就没有完成立项。