Writing Engineering

Voice Spec：把「你的风格」编译成可复用规格

背景与原理

人们描述自己想要的风格时写「专业、简洁、有力」——这些形容词对模型几乎零信息量，因为每个人心里的「简洁」都落在模型先验的均值附近，模型只能回归到它训练出的「通用专业腔」。Day 9 讲过的 Examples > Rules 在 voice 这件事上是最极端的案例：抽象形容词永远干不过具体样本。Anthropic 的 multishot 文档建议给 3-5 个 example 来锚定输出形态；voice 同理——喂 3-5 段你自己写的代表性文字，让模型逆向提取可操作特征（句长分布、主动/被动比例、段落节奏、标点与连接词习惯、是否用列表/emoji），固化成一份 voice.md spec，之后每次写作都注入它。关键是把「风格」从模糊感觉转成可声明、可复用、可 diff 的工件。

实战示例

# 一次性运行：从样本逆向提取 voice spec（存成 voice.md 复用）
下面是我写的 5 段代表性文字（同一体裁），用 <sample> 包裹：
<sample>...粘贴你的真实段落...</sample>

请逆向分析我的写作风格，输出一份可操作的 style spec，只写
可执行的规则，不要用「专业、生动」这类形容词。覆盖：
- 句长：平均字数、长短句节奏（给数字）
- 句式：主动 vs 被动、是否用反问/破折号/分号
- 结构：段落长度、是否先结论后论证
- 用词：偏好的连接词、回避的词、专业术语密度
- 禁区：我从不用的表达（列出你观察到的）

把产出的 spec 人工校一遍（删掉模型臆测的、补上它漏掉的），存成 voice.md。这份 spec 比任何形容词都精确，而且可以版本管理——不同体裁（博客 / 周报 / 技术文档）各存一份。

Slop 反检测：识别并消除 LLM 的「味道」

背景与原理

Kobak 等人 2024 年分析了 1400 万篇 PubMed 摘要，发现 ChatGPT 出现后一批「flowery 词」频率断崖式暴涨——「delve」涨了约 28 倍，「intricate」「meticulous」同步激增。这些就是 AI 味的客观证据：它们是 RLHF 把模型推向「安全的平庸」的副产品——over-hedge（「值得注意的是」「在某种程度上」）、过度 transition、三段式排比、套话开头（「在当今快速发展的…」）和套话结尾（「总而言之…」）。Simon Willison 把这类批量低质、没人要的 AI 产出命名为 slop（2025 年成了多家词典的年度词）。要紧的是认清：这是分布层面的 bias，不是单条 prompt 能彻底清除的——你能压低频率，但根治得靠 §1 的真实样本把输出分布整体拉走。

实战示例

# 贴在写作 prompt 末尾的 slop filter
硬约束：
1. 禁用词/短语：delve, 值得注意的是, 在当今/在这个时代,
   总而言之, 不仅…而且…, 释放(潜力), 赋能, 拥抱(变化)
2. 不要 preamble（「好的，这是…」）也不要 postamble（总结性收尾）
3. 每段至少有一个具体锚点：一个数字、一个例子、或一个专有名词
4. 删掉所有不增加信息的过渡句；能用短句别用长句
5. 不要对仗排比凑气势——一个具体例子胜过三个抽象形容词

第 3 条是最有效的——强制具体性，因为 slop 的本质是空洞：模型在没有信息可填时会用华丽辞藻和排比填充。逼它放数字和例子，slop 自然没了立足之地。

分层 Prompt：章节 → 段落 → 句子的三级控制

背景与原理

一次性让模型写 3000 字，几乎必然踩三个坑：lost-in-the-middle（中段论点稀释）、结构在中途崩、术语/风格漂移。正确做法是拆成三层，每层独立 prompt、独立验证（呼应 Day 5：能用 workflow 就别用 agent，因为可控、可 debug、可 eval）。Anthropic 的 chain-prompts 文档明确推荐：复杂任务拆成串联子任务，比硬塞一个巨型 prompt 稳得多。三层各司其职：

• L1 · Outline：只产结构 + 每节一句话论点，人审——这是全流程最便宜的 verification，骨架错了后面全白做。
• L2 · 逐节扩写：每次只写一节，但 prompt 里带上全局 outline + 前一节末尾做锚点，防止各节重复或漂移。
• L3 · 句子级 style pass：套用 §1 的 voice spec + §2 的 slop filter 做最后一遍打磨。

实战示例

def write_long(topic, voice_md, banned):
    outline = llm(f"为「{topic}」写大纲：只给章节标题 + 每节一句论点，"
                  "不要正文。")
    review(outline)                       # 人审骨架——最便宜的 verification
    sections, prev = [], ""
    for sec in outline.sections:
        draft = llm(f"全局大纲：{outline}\n上一节结尾：{prev[-200:]}\n"
                    f"只写这一节：{sec}。承接上文，不重复已写内容。")
        sections.append(draft); prev = draft
    full = "\n\n".join(sections)
    return llm(f"按这份 voice spec 打磨，逐句过 slop 清单：\n"
               f"{voice_md}\n禁用：{banned}\n\n原文：{full}")

AI as Editor：把 AI 钉在 critic 而非 author 的位置

背景与原理

这是把 evaluator-optimizer 模式（Anthropic Building Effective Agents）用在写作上。关键洞察：critique 是 verification 问题，generation 是开放问题。判断「这段哪句最弱、为什么」对模型很容易且可靠；从零生成一整篇好文却容易跑飞，还附带 sycophancy——你让它评自己的初稿，它倾向说「写得不错」。所以把它当 critic（指出弱点、提改法），比当 author（直接代写）可靠得多。更关键的副作用：人写骨架天然保住 voice——voice 丢失的根因，就是让 AI 从零生成。你出思想和结构，它做放大和打磨，分工才对。

实战示例

# self-critique：让 AI 当编辑，不当枪手；只动该动的句子
你是严格的编辑，不是枪手。针对下面这段：
1. 指出最弱的 3 句，每句说明为什么弱（空洞/冗余/逻辑跳跃）
2. 给出 diff 式修改：<del>原句</del> → <ins>改句</ins>
3. 只改这 3 句，其余原文逐字保留——不要顺手重写
4. 不要夸我写得好，直接上批评

<draft>...你的段落...</draft>

第 3、4 条是命门：不限定「只改弱句」，模型会忍不住重写全部（顺带抹掉你的 voice）；不禁止夸奖，它会用 sycophancy 稀释批评。要的是 surgical edit，不是 ghostwrite。