Shuorenhua

说人话

把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。

这份 skill 不是敏感词替换器，也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移，同时保住事实、术语和责任主体。

When to use

在下面这些需求里使用：

• 用户明确说”去 AI 味””说人话””自然一点””别像模板””别太像 ChatGPT”
• 需要改写中文或英文 chat、status、docs、public-writing
• 需要先判断文本该轻改、中改还是重改

在下面这些需求里不要硬套：

• 用户要逐字翻译、保留原文风格、仿官方模板或仿特定品牌 voice
• 文本主要是代码、日志、命令、配置、接口名、报错
• 用户要的是事实校对，不是风格改写

Core stance

• 去 AI 味，主要处理的是模板感、收束腔、虚假主语、语域混搭和表演性技术腔。
• 保留技术性。专业词、系统主语、事故复盘用语、PRD/发布说明中的术语默认可保留。
• 优先保信息，再谈风格。任何改写都不能新增事实、删核心事实或改变责任主体。
• 不用机械同义词替换表。默认可以删句、并句、降调、换主语、去总结式收尾；如果进入 in-place scope，就只做句内改写。
• 短语表默认只列代表项，不追求穷举所有变体。遇到新口癖，先按现有模式归类，再决定要不要补词。

Execution order

按固定顺序做，不要跳步：

1. 判场景：chat / status / docs / public-writing 2. 查禁改项：先划 protected spans，看有没有必须保留的术语、系统主语、引用原文、命令或正式语体 3. 判 Tier：Tier 1 / Tier 2 / Tier 3，按问题命中强度判断，不要把 Tier 当作改写力度 4. 再判档位：minimal / standard / aggressive 5. 判 scope：structural / bounded / in-place，判断这次能删到什么程度——自由删并重排、只把整句空话进删除清单、还是一句都不删 6. 先执行本文件里的最小规则；只要环境里能读 references/，默认继续按问题类型补看 Protected Spans、Positive Style Contract、微操作手册、结构反模式 和相关短语表；如果目标是“改完能直接发”，或文本明显属于 README、release note、论坛帖、issue 回复，再补看 Scene Packs、真实样本评测 和 改写示例 7. 回读拆成两步：先做保真回读，再按需做残留味回读 8. 输出：默认只给单一推荐版本；用户明确要求“先标问题，不改写”时切到 annotation mode

执行第 6 步时，先按“模式”处理，再按“词条”兜底：

• 同一类调试腔、暴力动作腔、主动出击腔、总结提示腔，默认按同一模式处理，不要求逐词命中
• 只有当新说法改变了误杀边界，或明显不属于现有模式时，才把它当作新增词条处理

1. Scene detection

先判主场景，再处理局部问题。混合文本只保留一个主语域，其他语域只在必要信息层面留下。

chat

信号：

• 短回复、日常对话、协作沟通、评论、即时反馈
• 允许口语，但不该端着说话

默认档位：minimal

status

信号：

• 站会更新、进度同步、复盘摘要、汇报式状态说明
• 重点是时间线、动作、结果、风险

默认档位：minimal 或 standard

docs

信号：

• 操作文档、技术说明、接口说明、FAQ、事故复盘
• 重点是可检索、可复现、术语稳定

默认档位：minimal

public-writing

信号：

• 公众号、小红书、公开帖、对外文章、观点写作
• 重点是语域一致，不要装“有洞见”

默认档位：standard

更细的下限限制见 场景禁改表。

Scene Packs

如果文本本身命中下面任一子场景，不依赖用户是否明说，也不受主场景初判限制，都要补看 Scene Packs：

• README：出现项目介绍、快速开始、安装方式、功能列表、README intro 等信号时，第一屏要说清“这是什么、给谁用、解决什么问题”
• release-note：出现版本标题、Release Highlights、Added / Changed / Fixed / Tested、changelog 列表等信号时，列清本版变更、验证和限制，不写发布宣言
• forum-post：出现 Linux.do / V2EX / 社区帖 / 发帖复盘等信号时，保留维护者的真实观察和社区语气，不改成公告
• issue-reply：出现 issue / PR 回复、bad case、复现、下一版补 benchmark 等信号时，先确认问题和下一步，不做客服式安抚

子场景只负责发布目的和语气收束，不覆盖 protected spans、Tier、档位和回读规则。完整策略见 Scene Packs。

2. Single-file fallback rules

只加载 SKILL.md 时，也必须能完成基础改写。下面这些规则默认直接生效：

• 删开场套话、谄媚和元评论：例如 值得注意的是、让我来为你解释、希望这对你有帮助、Great question!
• 删空总结和收尾腔：例如 综上所述、归根结底、本质上、At the end of the day
• 处理二元对比骨架：不是 X，而是 Y、与其 X，不如 Y 多数删前半句，直接说 Y
• 处理无源引用：研究表明、数据显示、studies show、experts say 默认按场景选择 rewrite-safe 或 audit-only；只有用户明确要保留原论证骨架时才用 rewrite-with-placeholder；不要补虚构来源
• 把商业黑话和表演性技术腔改回普通动作：例如 赋能、抓手、闭环、收窄、兜住、落盘、leverage
• 遇到过度接住、替用户做心理判断或身份认证式夸奖：例如 你不是敏感、你只是太久没被稳稳接住了、你问到了问题的核心、顶刊作者的素养，默认删姿态层，改回低承诺回应或具体判断；不要硬演“我懂了”
• 发现翻译腔时，优先缩短主语和动作，少用长定语链、被动堆砌、基于……、通过……来……
• 误杀防护优先：引用原文、命令、接口名、字段名、日志、报错、系统主语、技术报告术语默认保留
• 中英混排句中的英文词按当前句子的实际语义判断，不机械套英文词表

单文件模式只是兜底，不是完整模式。只要环境里能读 references/，默认就继续补看对应文件；只有在 system prompt 真的只给了 SKILL.md 时，才退化为只按本文件做基础清理。

Unsourced citation modes

处理无源引用时，固定只在这 3 种模式里选一种：

• rewrite-safe
• 直接删掉 研究表明 / studies show / 业内人士认为 这类权威铺垫
• 只保留原文里本来就成立、且不依赖虚构来源才能成立的判断
• 默认用于 chat 和 public-writing
• audit-only
• 不替作者补写来源，也不把无证据判断改写成像是已有证据
• 明确指出“这里缺来源/缺归属”，必要时保留原句不重写
• 默认用于 docs 和 status
• rewrite-with-placeholder
• 只在用户明确要求保留原结构、原语气或编辑稿框架时使用
• 可以写成“有研究认为……，但这里没有给出处”这类占位提醒
• 不能补具体机构、数据、年份、研究名称

如果用户没指定模式，就按场景默认值走；如果文本跨场景，优先取更保守的 audit-only。

3. Rewrite level

minimal

适用于：文本本身基本自然，只需去掉局部模板感、收尾腔和多余修辞。

默认动作：

• 删掉空总结
• 把过度抬高的语气压回常规
• 把"像在解释自己会写作"的句子压回事实句

standard

适用于：有明显 AI 腔或语域混搭，但信息骨架是好的。

默认动作：

• 统一语域
• 改掉工程师表演腔、商业黑话、narrator 腔
• 必要时并句或换主语

aggressive

适用于：Tier 1 命中密集，或 Tier 1 + Tier 2 叠加后整段呈现强模板感或强表演感。

限制：

• 只有在 Tier 1 明显密集，或多类结构问题叠加时才允许
• 先保护事实和术语，再做重写
• docs 默认不要升到 aggressive

3.5 Edit scope

Scope 表示这次能不能改动句子和段落结构，和 minimal / standard / aggressive 是两条轴。三档 scope 按"能不能删整句、怎么删"区分：structural 自由删并重排；bounded 只删"删了不丢信息"的整句空话，且走删除清单交用户确认；in-place 一句都不删。

structural

默认 scope。适用于短文本、明确要求重写的文本、AI 味密度很高且不需要保留原节奏的文本。

允许动作：

• 删整句空总结
• 合并相邻事实句
• 轻量调整句序或段落落点
• 按场景重写局部结构

bounded

中文 public-writing 长文（约 1000 字以上）的默认 scope。目标是把整句级的 AI 味去干净，又不被 structural 不可控地压缩——长文走 structural 时缩水程度依模型而定（同一篇可能 -18%，也可能 -39%），用户无法预期；bounded 把"删多少"交还给用户。

和另两档的关系：

• 比 structural 克制：不合并相邻句、不重排段落、不删承担节奏的实句或有意重复
• 比 in-place 能去味：允许删"整句都是空话"的句子，但不直接删，而是进删除清单交用户拍板

一句能进删除清单，必须同时满足三条：

1. 删掉后该段信息点不变（不带任何独有的事实、数字、判断、动作或指令） 2. 不是相邻两实句之间的唯一过渡 3. 命中纯空句型：空总结 / 价值拔高收尾 / 无源权威铺垫 / 谄媚开场 / 整句旁白

两类动作分开走（实测依据：长文里句首引导词模型能句内清掉，但整句空话在 in-place 下删不掉，只会被软化成另一种说法）：

• 句首可剥离的引导词（值得一提的是 / 归根到底 / 这说明）后面还跟着实质内容 → 直接句内洗，删引导词留骨架，不进清单
• 整句都是空的，剥掉引导词就什么都不剩（无源论断、不仅仅是……更是…… 的价值拔高）→ 进删除清单，不擅自软化成另一种说法

输出：正文给句内洗后的稿，末尾附「建议删除（待确认）」清单，每条写 原文 + 为什么删了不丢信息。用户点头才删，长度由用户拍板。

in-place

适用于用户明确要求"完全原样 / 一句都别删 / 严格保句数"的情况，比 bounded 更严：整句空话也不删，只做句内降调。

默认触发条件：

• 用户 prompt 明确要求保留句数、完全原样、一句不删，或反馈 bounded 仍删多了

禁止动作：

• 不删整句（即使整句是空话）
• 不合并相邻句
• 不重排段落
• 不把多段压成一段

允许动作：

• 句内替换词或短语
• 删除句内提示层、空泛修饰和语气垫片
• 把句内拔高语气降回普通判断
• 在单句内部拆短过满结构，但不改变段落顺序

删短语前先做语义独立性检查：删掉短语后，剩余部分必须仍是完整、可读、没有悬空指代的陈述句。否则改用句内替换，不要硬删。遇到整句空话，保留原句并标注 [空句，建议人工确认是否删除]，不擅自软化成新说法。

aggressive + in-place 可以存在，但默认先提醒用户：长文 aggressive 很容易明显缩水；如果用户真正要保长度，优先改成 standard + bounded。用户明确坚持时，再执行 aggressive + in-place，但仍遵守不删整句、不并句、不重排的边界。

4. Tier severity

Tier 表示问题命中强度，与 严重度分级 保持一致，不表示改写力度。

Tier 1

默认替换。命中这类词或句式时，通常直接删掉或换成更具体的表达。常见类型：

• 开场套话、总结式收尾、谄媚句
• 明显商业黑话、自媒体流水线用语、表演性工程师腔
• 过度接住式共情、替用户做心理判断、郑重预告和身份认证式夸奖
• 英文里的 sycophantic openers、significance inflation、business jargon

默认处理：局部命中用 minimal 或 standard，密集命中时可升到 aggressive

Tier 2

单独出现可以放行，但同段聚集时是 AI 味信号。常见类型：

• 高频连接词扎堆
• 渲染性修饰词扎堆
• 某一类姿态词在同段重复出现

长度参考：短段落（< 100 字/词）同段 2+ 个即标记；长段落（≥ 100 字/词）同段 3+ 个再标记。

默认处理：保留最贴切的一个，其余改写；通常用 minimal 或 standard

Tier 3

常见词本身不构成问题，只在全文密度明显过高时才处理。常见类型：

• 重要 / 关键 / 核心 / 提升
• significant / innovative / effective

默认处理：只替换一部分重复命中，通常用 minimal，必要时不改

5. No-touch and keep rules

以下内容默认优先保留，除非用户明确要求改风格且改动不损害信息：

• 引用原文、命令、接口名、参数名、字段名、配置项、日志、报错
• 技术文档里的系统行为主语
• postmortem / incident / PRD / release note 中的专业术语
• 承载关键事实的抽象句，即使它“有点像 AI”

不要为了“像人”把文本改得更假。专业文本可以专业，关键是别模板化、别表演化。

完整的保护清单见 Protected Spans。

6. Positive style targets

改写后的文本应尽量满足：

• 有具体信息，不靠空洞总括撑气势
• 有主语和动作，不靠虚假主体兜底
• 有统一语域，不在技术腔、商业腔、自媒体腔之间跳
• 以“可直接发”为终点，不为了更像人继续抛光到失真
• 有节奏，但节奏来自删冗余和保留重点，不来自硬造金句
• 有立场，但立场来自判断或事实，不来自“故作洞见”
• 有边界，没把握就直说，不替对方做心理判断，也不硬演“我懂了”

更完整的正向目标、分场景校准和“cleaner vs more human”对照见 Positive Style Contract。

7. Output contract

默认输出一个推荐版本，不默认输出审稿过程、多版本比稿或逐条点评。

Annotation mode

只有在用户明确要求下面这类事情时才启用：

• 先别改，先标问题
• 这段哪里像 AI
• 只做诊断 / 审稿 / 标注
• 先告诉我该不该改

annotation mode 不直接给整段改写稿，默认只输出最重要的 1-5 个问题点。每个问题点固定包含这 4 个字段：

• 问题族：例如 开场套话 / 无源引用 / 工程师腔 / 语域混搭
• 触发点：点明命中的词、结构或局部句子
• 建议动作：删掉、换成具体表达、补来源、保持不动
• 是否建议改写：是 / 否

额外约束：

• 如果文本主要问题是“缺来源”，可以只建议补来源，不强行给改写稿
• 如果文本落在误杀防护边界内，直接写 是否建议改写：否
• 不要一边说“只标问题”，一边偷偷输出完整重写版
• 用户没要求 annotation mode 时，仍然按默认改写合同输出单一推荐版本

遇到无源引用时，输出必须符合所选模式：

• 在 annotation mode 下，只输出对应的处理建议，不直接给整段改写稿
• 在默认改写模式下，再按所选模式实际给出改写结果
• rewrite-safe：建议删掉无证据权威铺垫；如果不是 annotation mode，再给改写结果，不补虚构来源
• audit-only：优先点明缺来源、缺归属，而不是假装已经证实
• rewrite-with-placeholder：允许保留论证位置，但要显式暴露“此处待补来源”；如果不是 annotation mode，可以给带占位提示的改写结果

只有在高风险误杀时，才额外补一行极短说明，例如：

• 保留了系统主语和术语，避免失真。
• 这里只做轻改，避免把正式公告写成口语贴。

8. Required reread checks

提交改写前，把回读固定拆成两步，不要混着做：

Pass 1 | 保真回读

先检查这 5 项：

1. protected spans 是否漂了 2. 信息是否丢失 3. 语域是否统一 4. 术语是否失真 5. 删改后是否出现生硬断裂

如果删掉一句后段落突然没了落点，就补一条事实句，不要补口号句。

bounded / in-place scope 下额外检查：

• 信息留存优先：原文每个信息点（事实、数字、判断、动作）在输出里都要可追溯，这是硬指标
• in-place：输出字数低于原文 85% 时，回退检查是否误删整句、并句或压段落（in-place 不该删任何整句）
• bounded：字数会因删整句空话而下降，不设硬下限；但要确认删除清单里每条都是"删了不丢信息"的纯空句，没混进实句或承担节奏的重复
• 句数变化超过约 10% 时，回退检查是否偷偷做了未经确认的 structural 改写
• 关键事实句、转场句和承担节奏的重复句，不能因为“看起来像模板”就默认删除

Pass 2 | Residual Audit

只有在第一遍已经保住事实、但读起来还有轻微 AI 味时，才做第二遍。第二遍固定只查这 5 件事：

1. 开场残留：还在用 结论先说 / 直接说结论 / 值得注意的是 这类提示层 2. 总结残留：还在用 总的来说 / 归根结底 / 最终来看 这类空收尾 3. narrator 残留：还在解释“这说明了什么”，而不是直接说事实或判断 4. 空泛判断残留：还在写 方向是对的 / 意义重大 / 真正理解了用户 5. 句长过匀：每句都差不多长、差不多整齐，像被统一抛光过

第二遍只允许做轻量修正：

• 删一个残留开场或收尾
• 合并两句过匀的事实句，或拆一处过满的句子
• 把一句 narrator / 空泛判断压回直接表达

第二遍不要做的事：

• 不重写全文
• 不补原文没有的事实
• 不为了“更像人”改掉术语、参数、命令、报错或责任归属

场景保守策略：

• public-writing 和 AI 味偏重的 chat，第二遍更常需要
• docs / status / code-context 默认更保守；如果第二遍会让语气变口语、变广告、或影响保真，就停在第一遍

Reference navigation

• 本文件可以单独兜底；完整模式默认是 SKILL.md + references/ 一起工作
• 想先看“改成什么样才算更像人”：看 Positive Style Contract
• 想先看哪些数字、引用、命令、参数不能漂：看 Protected Spans
• 想看中文高频短语：看 中文禁用短语表
• 想看英文高频短语：看 English Banned Phrases
• 想看句子和段落层面的结构问题：看 结构反模式
• 想按 Tier 1 / 2 / 3 校准命中规则：看 严重度分级
• 遇到具体病灶怎么动手：看 微操作手册
• 想确认某个场景什么不能乱动：看 场景禁改表
• 想校准误杀边界或做静态回归：看 边界案例集
• 想看真实样本评测：看 真实样本评测
• 想看默认改写和 annotation mode 的对照：看 改写示例
• 想处理没收录进词表的同类变体：先看 微操作手册 里的“变体归并”规则，再决定要不要补词

默认做法是：先用本文件完成“场景、Tier、档位、输出合同”的主判断，再按问题类型补读 references/；只有在单文件安装场景里，才停留在本文件的兜底规则。

原文

请贴出原文或已脱敏片段。不要提交未授权的私聊全文、敏感信息、账号、密钥、内部链接或真实个人身份信息。

使用方式

• 工具：Codex / Claude Code / Cursor / ChatGPT / OpenClaw / 其他
• 加载方式：lite（只加载 SKILL.md）/ full（SKILL.md + references/）/ 不确定
• 场景：chat / status / docs / public-writing / code-context / mixed

问题

你觉得哪里还是像 AI？可以只写最刺眼的一两处。

-

不能改坏什么

请列出需要保留的事实、术语、命令、路径、版本、引用原文、责任主体或语气边界。

-

期望方向

你希望它更接近哪种表达？例如：更像普通聊天、更像维护者回复、更像 release note、更保守、更短。

-

Repo Notes

Language

• This repo is Chinese-first. Default to Simplified Chinese for titles, summaries, suggestions, thread names, and user-facing explanations unless the source material is clearly English-first.
• Keep code, file paths, command names, API names, and established technical terms in their original form when translation would reduce clarity.

Style

• Match the repo's existing voice: direct, concrete, low-slop, and not overly translated.
• For mixed-language content, prefer Chinese framing with only the necessary English terms left in place.

Benchmark Judge Prompt

把下面这段 prompt 直接用于交叉判分。它只负责按 evals/run-eval.md 判定被测输出，不负责重新改写。

你正在执行「说人话」benchmark 交叉判分。你的任务是读取 benchmark 用例、被测模型输出，并按 ./evals/run-eval.md 的既有口径判定每条结果。

路径边界：
- 只使用当前工作目录里的 `./evals/`、`./SKILL.md`、`./references/` 和被测输出文件。
- 不要读取或引用全局安装副本，例如 `~/.codex/skills/shuorenhua`、`~/.claude/skills/shuorenhua` 或其他仓库外路径。
- 如果某个全局 skill 被自动触发，也只能把它当作运行环境噪音；本轮判分口径以当前工作目录文件为准。

开始前先读取：
- ./evals/run-eval.md
- ./evals/benchmark.md

必要时再读取：
- ./SKILL.md
- ./references/scene-packs.md
- ./references/protected-spans.md
- ./references/operation-manual.md
- ./references/boundary-cases.md

输入会提供：
- benchmark 区间
- 对应 benchmark 原文、`**预期**` 或 `**理由**`
- 被测模型输出
- 若包含 Long-form / in-place 用例，运行者会提供原文字符数、输出字符数和留存百分比

判分标准：
- 直接引用 ./evals/run-eval.md 的口径，不另造标准。
- SF：主要问题被消除、原意和 protected spans 保留、不过度改写，记 ✅。
- SF：识别到问题但动作不完整、只标注风险但该直接改写、bounded 直接删或软化整句空话等，记 ⚠️。
- SF：主要问题没处理、编造事实、误改 protected spans、错改场景、长文误删并句重排，记 ❌。
- SNF：保持原样或只做最小无害调整，记 ✅。
- SNF：错误修改术语、系统主语、技术报告、引用原文、被讨论词、合理转场、实句或 protected spans，记 ❌。
- Scene Packs、Long-form / in-place、Bounded、Residual Audit、fact-preservation、无源引用类用例按 ./evals/run-eval.md 的对应小节判。
- 长文留存百分比只使用运行者提供的数字；你不要自己数，也不要估算。

输出格式必须严格如下：

| 编号 | 判定 ✅/⚠️/❌ | 一句依据 |
|------|--------------|----------|
| SF-01 | ✅ | <一句依据> |

末尾再输出：

## 汇总

- SF 通过：X/Y
- SNF 误杀：X/Y
- ⚠️ 清单：<编号列表；没有就写“无”>
- ❌ 清单：<编号列表；没有就写“无”>

禁止：
- 不要重写被测输出。
- 不要输出评分标准以外的新等级。
- 不要用“文风还可以 / 不够自然”这类主观理由替代 ./evals/run-eval.md 的标准。
- 不要跳过用例；如果被测输出缺某条，按 ❌ 并说明缺输出。

Benchmark Eval Harness — 运行说明

v1.9.0 起使用的模型实跑入口。

Prompt 本体见 ./rewrite-prompt.md 和 ./judge-prompt.md。

这份 README 只解决"具体怎么跑一次"。

文件约定

工具本体（committed）：

运行实例（local-only，tasks/ 在 .gitignore 内）：

第一次使用前先建目录：

mkdir -p tasks/current/eval-runs/2026-06-18-codex \
  tasks/current/eval-runs/2026-06-18-claude \
  tasks/current/eval-runs/2026-06-18-judge

批次划分

默认按 5 批跑：

新增或补跑用例可以单独成批。v1.9.0 的 SNF-32 就按 SNF32 单条 follow-up 跑，输出命名为 rewrite-SNF32.md / judge-...-SNF32.md。

如果模型或供应商的上下文 / 输出限制跑不下 5 批之一，可以继续细拆，例如把 SNF01-16 拆成 SNF01-08 和 SNF09-16。文件名保持区间可读即可，最终汇总时按原区间合并。

交叉判分固定为：

• Codex 改写 → Claude 判
• Claude 改写 → Codex 判

改写批

Codex 改写一批：

codex exec -C . -s read-only --ephemeral \
  -o tasks/current/eval-runs/2026-06-18-codex/rewrite-SF01-14.md \
  '你正在执行说人话 benchmark 改写实跑。

请完整读取 ./automation/eval/rewrite-prompt.md，按其中 text 代码块里的 prompt 行事。
只使用当前工作目录下的 ./SKILL.md、./references/ 和 ./evals/，不要读取全局安装的 shuorenhua skill 副本。

本轮只处理 ./evals/benchmark.md 中 SF-01 到 SF-14。
请直接输出最终结果，不要附加过程叙述。'

Claude 改写一批：

claude --print --model opus \
  --name shuorenhua-eval-rewrite-SF01-14 \
  --disallowedTools Edit Write \
  > tasks/current/eval-runs/2026-06-18-claude/rewrite-SF01-14.md <<'EOF'
你正在执行说人话 benchmark 改写实跑。

请完整读取 ./automation/eval/rewrite-prompt.md，按其中 text 代码块里的 prompt 行事。
只使用当前工作目录下的 ./SKILL.md、./references/ 和 ./evals/，不要读取全局安装的 shuorenhua skill 副本。

本轮只处理 ./evals/benchmark.md 中 SF-01 到 SF-14。
请直接输出最终结果，不要附加过程叙述。
EOF

其余批次只替换区间和输出文件名。

判分批

Claude 判 Codex 改写：

claude --print --model opus \
  --name shuorenhua-eval-judge-codex-SF01-14 \
  --disallowedTools Edit Write \
  > tasks/current/eval-runs/2026-06-18-judge/claude-judge-codex-SF01-14.md <<'EOF'
你正在执行说人话 benchmark 交叉判分。

请完整读取 ./automation/eval/judge-prompt.md，按其中 text 代码块里的 prompt 行事。
只使用当前工作目录下的 ./evals/、./SKILL.md、./references/ 和被测输出文件，不要读取全局安装的 shuorenhua skill 副本。

benchmark 区间：SF-01 到 SF-14
被测输出：./tasks/current/eval-runs/2026-06-18-codex/rewrite-SF01-14.md

请直接输出判分表和汇总，不要重写被测输出。
EOF

Codex 判 Claude 改写：

codex exec -C . -s read-only --ephemeral \
  -o tasks/current/eval-runs/2026-06-18-judge/codex-judge-claude-SF01-14.md \
  '你正在执行说人话 benchmark 交叉判分。

请完整读取 ./automation/eval/judge-prompt.md，按其中 text 代码块里的 prompt 行事。
只使用当前工作目录下的 ./evals/、./SKILL.md、./references/ 和被测输出文件，不要读取全局安装的 shuorenhua skill 副本。

benchmark 区间：SF-01 到 SF-14
被测输出：./tasks/current/eval-runs/2026-06-18-claude/rewrite-SF01-14.md

请直接输出判分表和汇总，不要重写被测输出。'

其余批次只替换区间、被测输出和输出文件名。

小样试跑

调 prompt 时先跑小样，不要直接上全量：

mkdir -p tasks/current/eval-runs/2026-06-18-smoke-v2

codex exec -C . -s read-only --ephemeral \
  -o tasks/current/eval-runs/2026-06-18-smoke-v2/rewrite-SF01-05-SNF01-03.md \
  '请完整读取 ./automation/eval/rewrite-prompt.md，按其中 text 代码块里的 prompt 行事。
只使用当前工作目录下的 ./SKILL.md、./references/ 和 ./evals/，不要读取全局安装的 shuorenhua skill 副本。

本轮只处理 ./evals/benchmark.md 中 SF-01 到 SF-05，以及 SNF-01 到 SNF-03。
请直接输出最终结果，不要附加过程叙述。'

claude --print --model opus \
  --name shuorenhua-eval-smoke-judge \
  --disallowedTools Edit Write \
  > tasks/current/eval-runs/2026-06-18-smoke-v2/judge-SF01-05-SNF01-03.md <<'EOF'
请完整读取 ./automation/eval/judge-prompt.md，按其中 text 代码块里的 prompt 行事。
只使用当前工作目录下的 ./evals/、./SKILL.md、./references/ 和被测输出文件，不要读取全局安装的 shuorenhua skill 副本。

benchmark 区间：SF-01 到 SF-05，以及 SNF-01 到 SNF-03
被测输出：./tasks/current/eval-runs/2026-06-18-smoke-v2/rewrite-SF01-05-SNF01-03.md

请直接输出判分表和汇总，不要重写被测输出。
EOF

小样只看格式是否可对照：

• 每条改写输出都有 ## <编号>。
• 每条都有固定判定链。
• judge 只输出固定三列表格。
• 汇总里有 SF 通过、SNF 误杀、⚠️ / ❌ 清单。

如果格式不顺，最多改 prompt 后再跑一轮；第二轮仍不顺就停下，不要继续全量。

Benchmark Rewrite Prompt

把下面这段 prompt 直接用于模型实跑。它只负责让被测模型按规则处理指定 benchmark 区间，不负责判分。

你正在执行「说人话」benchmark 改写实跑。你的任务是作为被测模型，按当前仓库规则处理指定区间的 benchmark 用例，并输出稳定、可被 judge 对照的结果。

路径边界：
- 只使用当前工作目录里的 `./SKILL.md`、`./references/`、`./evals/` 和 `./automation/eval/`。
- 不要读取或引用全局安装副本，例如 `~/.codex/skills/shuorenhua`、`~/.claude/skills/shuorenhua` 或其他仓库外路径。
- 如果某个全局 skill 被自动触发，也只能把它当作运行环境噪音；本轮实跑口径以当前工作目录文件为准。

开始前先读取：
- ./SKILL.md
- ./evals/benchmark.md
- ./evals/run-eval.md

再按需读取：
- ./references/positive-style.md
- ./references/protected-spans.md
- ./references/phrases-zh.md
- ./references/phrases-en.md
- ./references/structures.md
- ./references/severity.md
- ./references/examples.md
- ./references/operation-manual.md
- ./references/scene-guardrails.md
- ./references/scene-packs.md
- ./references/boundary-cases.md

输入会指定一个 benchmark 区间，例如：
- SF-01 到 SF-14
- SF-15 到 SF-28
- SF-29 到 SF-41
- SNF-01 到 SNF-16
- SNF-17 到 SNF-31

每条 benchmark 的字段以 ./evals/benchmark.md 为准：
- 标题行：编号 / 场景 / 说明
- 测试文本：标题后的引用块或代码块
- SF 用例看 `**预期**`
- SNF 用例看 `**理由**`

处理要求：

1. 逐条处理指定区间内的所有用例，不要跳过、合并或增删编号。
2. 每条先输出判定链，再输出处理结果。
3. 判定链固定包含四项，各用一个短语：
   - 场景：chat / status / docs / public-writing / code-context，必要时带 README / release-note / forum-post / issue-reply / long
   - Tier：Tier 1 / Tier 2 / Tier 3 / protected / not-fix
   - 力度：minimal / standard / aggressive / audit-only / no-op
   - scope：structural / bounded / in-place / not-applicable
4. SF 用例默认输出改写结果；如果按规则属于 audit-only（例如 status/docs 场景的无源引用），输出风险说明，不要伪装成已证实事实。
5. SNF 用例原则上保持原文；如果只做最小无害调整，必须说明为什么没有误杀 protected spans、术语、引用或合理语境。
6. code-context 只处理注释、docstring 或 commit message，不改代码。
7. Scene Packs 先保大场景和 protected spans，再按 README / release-note / forum-post / issue-reply 的发布目的处理。
8. Long-form / in-place 用例不删整句、不合并相邻句、不重排段落。
9. Bounded 用例句内洗实句，整句空话进「建议删除（待确认）」清单；不得把实句、带信息句或承担节奏的句子放进删除清单；不得把相邻句合并。

输出格式必须严格如下：

## <用例编号>

判定链：场景=<...>；Tier=<...>；力度=<...>；scope=<...>

命中项：
- <命中的问题类型、保护点或放行理由>

处理结果：
<改写稿、audit-only 风险说明、或 SNF 保留原文说明>

禁止：
- 不要输出自评通过 / 部分通过 / 未通过；判分是 judge 的事。
- 不要跳过用例。
- 不要把多条用例合并到一个标题下。
- 不要改 `## <用例编号>` 和 `判定链：场景=...；Tier=...；力度=...；scope=...` 这两个格式。
- 不要为了让结果更好看而编造原文没有的来源、数据、责任主体、命令、版本号或指标。

社区样本 Intake Automation Prompt

把下面这段 prompt 直接用于 Codex automation。

你在维护「说人话」这个仓库的社区样本 intake。你的任务不是直接改仓库，而是把新样本按现有规则归类，并给出最小必要的维护建议。

开始前先读取：
- ./SKILL.md
- ./references/phrases-zh.md
- ./references/structures.md
- ./references/operation-manual.md
- ./evals/benchmark.md

输入会包含一批社区样本，可能来自截图 OCR、聊天记录、梗图文字或文本摘录。你需要：

1. 清洗输入
- 去掉无关 UI 文案
- 合并重复句子
- 保留最能代表问题的原句

2. 按现有问题族归类
以 `references/operation-manual.md`（家族 #1-#8 含 5.1 / 5.2 / 5.3 子项）和 `references/phrases-zh.md` 的分类为权威，主要家族：
- 工程师腔 / 调试腔
- 商业黑话
- 庸医问诊腔
- 暴力动作腔
- 主动出击腔
- 总结提示腔
- 总结式收尾
- 过度接住 / 心理判断腔（v1.7.3 起；宾语是人 / 情绪 / 关系时算命中，宾语是流量 / 请求 / 峰值时按技术语境放行）
- 郑重预告 / 身份认证式夸奖
- narrator 腔
- 自媒体 / 小红书腔
- 过渡废话
- 二元对比句
- 价值拔高骨架
- 语域混搭
- 无源引用
- 其他结构反模式（见 `references/structures.md` 19 类）

漏列任何一族会把已覆盖样本错误推到"候选新模式"——遇到拿不准的归类，先回 `operation-manual.md` 比对家族编号和识别信号，再决定是不是真新模式。

3. 每条样本只输出一个结论
- 已覆盖：词表或结构表里已经有代表项
- 变体归并：词表未逐字收录，但现有模式已经能吸收
- 候选新模式：现有模式解释不动，或它明显改变了误杀边界

4. 给出建议动作
只允许这四类：
- 无动作
- 补 benchmark
- 补 operation-manual
- 考虑新增词条或结构

5. 生成最终报告
报告必须包含：
- 本轮样本数
- 已覆盖
- 变体归并
- 候选新模式
- 建议动作
- 一句总判断：这轮是否需要改仓库

强约束：
- 默认不要建议加词条
- 如果只是同义变体，优先建议补 benchmark 或 operation-manual
- 不要自动编辑仓库文件
- 不要自动提交 PR
- 不要为了凑新规则，把被讨论词、引用词、真人具体叙事误判成 AI 腔

推荐调度

• 每周一次
• 或者在维护者手工投喂一批样本后触发

推荐输出格式

# 本周社区口癖 intake

本轮样本数：6

## 已覆盖
- "拍板" → 暴力动作腔，词表已覆盖

## 变体归并
- "扒开" → 庸医问诊腔变体；建议动作：补 benchmark
- "拽出来" → 庸医问诊腔变体；建议动作：补 operation-manual

## 候选新模式
- 暂无

## 建议动作
- 补 1 条 benchmark
- 更新 operation-manual 的变体归并例子

总判断：这轮不需要新增词条，现有模式可以吃住。

社区样本 Intake 自动化方案

目标

把"社区又在吐槽什么新口癖"从一次次手工收词，改成稳定的 intake 流程：

• 先判断是否已被现有规则覆盖
• 再区分"现有模式变体"还是"真正新模式"
• 最后只输出建议，不自动改仓库

这套自动化的目标不是直接扩词表，而是帮维护者减少筛选成本。

推荐输入

每次运行接收一批社区样本，来源可以混合：

• 梗图截图
• 对话截图
• 文本摘录
• issue / comment 里贴出来的例子

输入最好附最少上下文：

• 来源平台
• 原始文本或 OCR 文本
• 一句说明：为什么觉得它像 AI 味

自动化流程

1. 抽取样本

• 从截图里做 OCR，尽量保留原句
• 去掉无关 UI 文案，只保留候选句子
• 同一张图里重复出现的词先去重

2. 归并到现有问题族

对每条样本，优先归到已有模式（以 references/operation-manual.md 和 references/phrases-zh.md 的分类为权威，按出现频率列出主要家族）：

• 工程师腔 / 调试腔
• 商业黑话
• 庸医问诊腔
• 暴力动作腔
• 主动出击腔
• 总结提示腔
• 总结式收尾
• 过度接住 / 心理判断腔
• 郑重预告 / 身份认证式夸奖
• narrator 腔
• 自媒体 / 小红书腔
• 过渡废话
• 二元对比句
• 价值拔高骨架
• 语域混搭
• 无源引用
• 其他结构反模式（见 references/structures.md 19 类）

如果能稳定归类，就不要急着建议加新词。漏掉某个已覆盖家族会把已覆盖样本错误推到"候选新模式"，破坏"已覆盖 → 无动作"边界——遇到不确定的归类，优先回去比对 operation-manual.md 的家族编号，而不是直接归到"其他"。

3. 输出三档结论

每条样本只落一个结论：

• 已覆盖
• 词表或结构表里已经有代表项
• 不需要动作
• 变体归并
• 词表未逐字收录，但现有模式已经能吃住
• 建议补 benchmark 或操作说明，不建议加词
• 候选新模式
• 现有模式解释不动
• 或它明显改变了误杀边界
• 才建议人工评估是否入库

4. 生成建议，不直接写仓库

每次运行输出一份 intake 报告，固定包含：

• 本轮样本数
• 已覆盖
• 变体归并
• 候选新模式
• 建议动作

建议动作 只允许这 4 类：

• 无动作
• 补 benchmark
• 补 operation-manual
• 考虑新增词条或结构

5. 人工确认后再落库

只有人工确认后，才进行后续动作：

• 更新 evals/benchmark.md
• 更新 references/operation-manual.md
• 如果是新结构模式，更新 references/structures.md
• 必要时才更新 references/phrases-zh.md

默认不要让自动化直接编辑这些文件。

推荐输出格式

报告必须包含 6 段：本轮样本数 / 已覆盖 / 变体归并 / 候选新模式 / 建议动作 / 一句总判断。这一格式由 intake-prompt.md 的强约束钉死，运行入口和 changelog 也按此口径校验。

# 本周社区口癖 intake

本轮样本数：3

## 已覆盖
- "拍板" → 暴力动作腔，词表已覆盖；建议动作：无动作

## 变体归并
- "扒开" → 庸医问诊腔变体，建议补 benchmark
- "拽出来" → 庸医问诊腔变体，建议补 operation-manual 示例

## 候选新模式
- 暂无

## 建议动作
- 无动作：1 条
- 新增 1 条 SF benchmark
- 更新 operation-manual 的变体归并说明

总判断：本轮不需要新增词条，现有模式可以吃住。

调度建议

• 频率：每周 1 次够了
• 触发方式：固定时间跑，或在维护者手工投喂一批样本后跑
• 输出位置：开一个 inbox 项，而不是直接改文件

不建议做的事

• 不要看到一个新词就自动追加到词表
• 不要从单张梗图直接推出"必须加规则"
• 不要跳过误杀判断
• 不要让自动化自动提交 PR

如果以后真要接到 Codex Automation

自动化 prompt 应只做 intake，不做仓库写操作。核心要求：

• 先读取 SKILL.md、references/phrases-zh.md、references/structures.md、references/operation-manual.md
• 把输入样本归到"已覆盖 / 变体归并 / 候选新模式"
• 输出建议动作和理由
• 除非用户明确要求，否则不要修改仓库文件

可直接复用的 prompt 模板见 ./intake-prompt.md，运行入口见 ./README.md。

Community Sample Intake — 运行说明

维护者本地工具的运行入口。

协议规范（什么是 intake、为什么做）见 ./intake.md，prompt 本体见 ./intake-prompt.md。

这份 README 只解决"具体怎么跑一次"。

什么时候跑

• 公开讨论（X / Linux.do / V2EX / 知乎 / Reddit 等）出现一批新的 AI 姿态链
• 怀疑现有词表可能没收住，但又不确定是变体还是新模式
• 触发条件全集见 CONTRIBUTING.md 「维护者：Community Observation Intake」一节

文件约定

工具本体（committed）：

运行实例（local-only，tasks/ 在 .gitignore 内）：

输入文件每条样本带"来源 / 原文 / 提交者备注"三栏，越接近原始观察越好。dryrun 参考样本和 expected baseline 见仓库内 commit 历史里 v1.8.2 的相关引用。

一条命令跑完

在仓库根目录执行（替换日期）：

codex exec -C . -s read-only --ephemeral \
  -o tasks/current/intake/reports/2026-05-01-intake.md \
  '你正在执行说人话仓库的 intake automation。

请完整读取 ./automation/intake-prompt.md，按其中 text 代码块里的 prompt 行事。该 prompt 已固定：要先读哪些 reference、如何按"已覆盖 / 变体归并 / 候选新模式"三档归类、强约束（默认不要建议加词条；不要把被讨论词、引用词、真人具体叙事误判成 AI 腔），以及最终输出格式。

本轮样本批次在 ./tasks/current/intake/inbox/2026-05-01.md。

请直接输出最终的 intake 报告，按 prompt 推荐的格式（本轮样本数 / 已覆盖 / 变体归并 / 候选新模式 / 建议动作 / 一句总判断），不要附加任何过程叙述或 meta 评论。'

关键参数说明：

• -C . — 让 codex 把仓库根作为工作目录，prompt 里的相对路径才能解析
• -s read-only — 沙箱锁死成只读，强约束"不自动改仓库"用沙箱兜一次底
• --ephemeral — 不持久化 session，单次任务即跑即弃
• -o <报告路径> — 直接把模型最终输出落到 reports 目录，不依赖 stdout 复制粘贴

tasks/current/intake/inbox/ 和 reports/ 这两个目录在 .gitignore 内，第一次用前手动 mkdir -p 一次即可。

跑完之后

报告里只会出现四类建议动作：无动作 / 补 benchmark / 补 operation-manual / 考虑新增词条或结构。

• 默认假设：本轮不需要直接改仓库
• 如果建议是 补 benchmark：人工评估后再去改 evals/benchmark.md
• 如果建议是 补 operation-manual：人工评估后再去改 references/operation-manual.md
• 如果建议是 考虑新增词条或结构：先观察 2-3 轮，确认是否反复出现，再考虑入库
• 任何动作都不应该由 intake 自动完成；这一层是建议，不是落库

Prompt 调坏了怎么办

如果哪天改 intake-prompt.md 让报告偏离 spec 推荐格式（6 段都缺、问题族归类乱、被讨论词被误判成 AI 腔），就说明 prompt 调坏了——回滚或重新校准。校准时建议先准备一份覆盖三档结论 + 两类陷阱（被讨论词、技术语境放行）的合成样本批次作为 expected baseline，跑完比对。

Changelog

[1.9.0] - 2026-06-18 — Eval Harness / 模型实跑评测

Added

• 新增 automation/eval/ 三件套：rewrite-prompt.md、judge-prompt.md、README.md，把 benchmark 改写和交叉判分流程固化成可复制命令。
• 新增 evals/results-v1.9.0.md，归档首轮完整双模型实跑结果、非绿用例点评、bounded 尾巴补跑和成本基线。
• evals/benchmark.md 新增 SNF-32：bounded 下商业黑话壳句不得与紧随其后的具体数据句合并，数据句必须逐字保留。

Changed

• README 评测区切换为 v1.9.0 起的双模型实跑口径；静态走查退为发版前快速自查。
• benchmark 计数同步为 73 条（41 SF + 32 SNF），evals/run-eval.md 和 evals/real-samples.md 同步 SNF 32 口径。
• evals/run-eval.md 补充 bounded 防并句判分：壳句与紧随其后的数据句被合并成一句，记 ❌。

Tested

• 小样试跑 SF-01–05 + SNF-01–03 第二轮格式可用，改写输出与 judge 表格可逐条对照。
• 首轮完整实跑：Codex 改写由 Claude 判，SF 39/41，SNF 0/32 误杀；Claude Opus 4.8 改写由 Codex 判，SF 34/41，SNF 0/32 误杀。
• SNF-32 用同一套 harness 补跑：Codex 与 Claude 均 0/1 误杀，未并句，数据句保留。

Notes

• 本版不改 SKILL.md 或 references/ 的规则行为，只新增 eval harness、归档和防并句用例。
• 成本基线：Codex rewrite 6 runs 记录 input 1,218,624 / cached 784,384 / output 103,780 / reasoning 87,653；Codex judge 6 runs 记录 input 866,815 / cached 446,720 / output 41,710 / reasoning 32,856。Codex CLI 未提供稳定 cost / duration 字段。
• Claude 可回收记录：SF rewrite 三批 416.503s / $2.629105，judge 六批 375.170s / $2.922822；可回收小计 791.673s / $5.551927。Claude SNF rewrite 小批缺 CLI cost / duration，不手算进小计。实际模型确认为 claude-opus-4-8。

[1.8.8] - 2026-06-10 — README v2

Changed

• README.md 整体重排：before/after 三组示例前置；新增「30 秒上手」（Codex / Claude Code / ChatGPT 三入口 + annotation mode 一句话用法）；场景、力度、scope 压缩为三表一流程；issue #4 的 scope 实测过程折叠进 <details>。
• 横幅从位图换成手写 SVG（assets/banner-light.svg / banner-dark.svg），用 <picture> 适配 GitHub 亮暗主题：文字全部转矢量轮廓（字形来自 Noto Sans SC，SIL OFL 1.1），不依赖访问者系统字体，跨平台渲染一致；视觉改走「红笔审稿」方向——划掉的套话、红色句号、一枚「可直接发」印章。原 assets/readme-logo.png 保留未删。
• 移除项目状态表和项目结构文件树：版本信息由 release 徽章和 CHANGELOG 承担，规则覆盖数字并入评测区。
• 小节标题去掉版本号，避免随版本腐烂。

Notes

• 本版只动 README.md、assets/（新增两个 banner SVG）与本文件，不改规则与评测；计数为实测同步（benchmark 72 条 = 41 SF + 31 SNF，real samples 19 条）。

[1.8.7] - 2026-06-10 — Maintenance Surface 2 / 安装口径与 bounded 下沉

Changed

• install/claude-code.md 重写：Claude Code 会按 SKILL.md frontmatter 的 description 自动发现并触发 skill，移除“不会自动发现、CLAUDE.md 说明不能省略”的过时断言；CLAUDE.md 触发说明降级为可选增强；新增软链接“跟随更新”安装方式。
• install/ 全部平台文档补「长文改写的三档 scope」小节（structural / bounded / in-place 与长文默认值）——v1.8.6 的 scope 能力此前没有下沉到任何安装入口。
• install/chatgpt-gpt-instructions.md 执行流程补 scope 判断一行（需维护者手动同步到 Custom GPT 后台）。
• references/examples.md 新增 Bounded 双合同示例（正文 + 建议删除清单，合成文本，含「句内洗 vs 进清单」的边界说明）。
• references/positive-style.md 长文节奏边界补一句 bounded 口径：节奏句不进清单，进清单的必须是纯空句。

Notes

• 本版不改 SKILL.md 与 evals/，是 v1.8.4 之后第二个维护面版本。
• 仓库杂项：移除空的 docs/ 目录；CLAUDE.md → AGENTS.md 软链纳入版本控制，Claude Code 用户 clone 后直接生效。

[1.8.6] - 2026-06-03 — Bounded Scope / 长文去味与保长度的中间态

针对 #4 复测反馈:v1.8.5 的 in-place 把长度接住了(实测 95–96%),但去 AI 味效果明显弱于 structural——长文里整句级的空话(无源引用、价值拔高收尾)在 in-place 下规则上删不掉,只会被软化保留。本版在 structural 和 in-place 之间补一个 bounded scope。

Added

• SKILL.md 新增 bounded edit scope:public-writing 长文默认 scope。允许删"整句都是空话"的句子,但不直接删,而是进「建议删除(待确认)」清单交用户拍板;句内洗实句照常,不并句、不重排、不删承担节奏的重复。
• evals/benchmark.md 新增 2 条用例(70 → 72,40 SF + 30 SNF → 41 SF + 31 SNF):
• SF-41:bounded 下整句空话(谄媚开场 / 无源引用 / 价值拔高收尾)进删除清单,带数字的实句和排比节奏句原样保留
• SNF-31:bounded 删除清单不该混进实句或节奏句——带句首引导词(说到底)但实质是立场判断的句子,只能句内删引导词,整句不进清单
• references/operation-manual.md 顶部新增「Scope 与删除清单」一节,统一三档 scope 下"整句空话 vs 句首引导词"的处理,不在各类问题里重复。

Changed

• 长 public-writing 默认 scope 从 in-place 改为 bounded(行为变化);in-place 退为用户明确要求"完全原样 / 一句都别删 / 严格保句数",或反馈 bounded 仍删多了时才用。
• SKILL.md 执行顺序第 5 步 scope 判断扩成三档;第 8 节回读把"字数留存"从硬指标降为参考,新增"信息留存"为硬指标——bounded 删整句空话会降字数,约束应落在"信息点可追溯"和"删除清单只含纯空句"上,不是字数。
• README.md、evals/run-eval.md 同步版本、计数(72)、scope 三档和默认值变化。

Tested

• 2026-06-03 首次模型实跑(此前各版为静态复核):同一篇 1498 字合成长文,用现有 SKILL.md+references/ 跑 aggressive 力度的 structural 和 in-place,Codex(gpt-5 家族)与 Claude(opus 家族)双交叉。
• 结果支撑本版动机:in-place 两个模型都把无源引用、价值拔高收尾整句残留(只软化铺垫),留存 95–96%;structural 都删掉这些整句空话,留存 80–83%。bounded 规则刚落地,实跑留待下一轮。
• 一处修正:structural 在两个强模型上并未腰斩(实测 -18%,非 issue #4 报告的 -39%),说明长文 structural 缩水程度依模型而定、不可控——这也是 bounded 把"删多少"交还用户的理由。

Notes

• bounded 不是第四个力度档位,而是 scope 轴上介于 structural 和 in-place 之间的中间态;minimal / standard / aggressive 三档力度不变。
• 实跑成稿和对照存档在本地 tasks/current/runs/(local-only)。

[1.8.5] - 2026-05-27 — In-place Scope / 长文保长度

针对 #4 反馈"长文被改完明显缩水"（约 1800 字 → minimal 约 1500 字 → aggressive 约 1000 字）。本版结论：问题不在三档力度，而在长文默认走 structural 动作时，删句、并句、重排段落会叠加。

Added

• 新增 in-place edit scope，和 minimal / standard / aggressive 三档力度正交。in-place 下只做句内替换、删短语和降调，不默认删整句、并句或重排段落。它不是第四档力度，而是改写动作的边界。
• evals/benchmark.md 新增 4 条用例（66 → 70 条，38 SF + 28 SNF → 40 SF + 30 SNF）：
• SF-39：长 public-writing 在 in-place 下应去掉拔高骨架，但保留字数、句数和关键转场
• SF-40：多类骨架叠加时，in-place 应做句内替代，而不是删段落
• SNF-29：重复短语承担长文节奏时，不应被当作水分误删
• SNF-30：正常承接句挂在事实上下文里，不应被误杀为总结式收尾
• evals/real-samples.md 新增 RS-19 高拟真合成长文样本（不直接转录 issue #4 原文），并为 long-form 场景增加 长度节奏 评分维度。
• 新增 evals/results-v1.8.5.md，归档本轮静态复核。

Changed

• SKILL.md 在执行顺序里加入 scope 判断，定义 structural / in-place 两种改写边界。默认走 structural；中文 public-writing 长文（约 1000 字以上）或用户明确要求保长度、保句数、保段落节奏时切到 in-place。
• references/operation-manual.md 给二元对比、总结式收尾、narrator 腔、价值拔高骨架四类骨架补 in-place 替代动作，保留原有 structural 默认动作不变。
• references/positive-style.md 和 references/scene-guardrails.md 加长文节奏边界：重复和转场不一定是水分，删之前先看它是不是在承担段落呼吸。
• evals/run-eval.md 同步 scope 判断和 70 条 benchmark 的评测范围。
• README.md 同步版本、计数和 In-place Scope 能力说明。

Tested

• 静态复核 SF-39 / SF-40 / SNF-29 / SNF-30：4 条新增 benchmark 都能被 SKILL.md + references/operation-manual.md 当前的 scope 规则解释。
• 静态复核 RS-19：推荐改法保留五段结构、三处时间锚点和关键转场，不把长文压成摘要。
• 没有跑模型实测。本版的"通过率"是静态走查口径，不是任何具体模型在线跑出来的结果——模型实跑留给后续轮次。

Notes

• 本版不动 minimal / standard / aggressive 三档力度本身，也不新增第四档；调整集中在"动作边界"这一条新的正交轴上。
• in-place 不是凑字数。字数留存率（目标 ≥ 0.90，硬下限 0.85）是回读指标，真正约束的是不删整句、不并句、不重排段落。
• "约 1000 字"是这一轮反馈得到的工程默认值，不是稳定结论；后续需要更多真实长文 bad case 校准。

[1.8.4] - 2026-05-17 — Maintenance Surface / 维护入口对齐

Added

• 新增 .github/ISSUE_TEMPLATE/bad-case.md，给“改完还是像 AI”的反馈留一个结构化入口，固定收集原文、使用方式、场景、问题点、不可改坏内容和期望方向。
• CONTRIBUTING.md 新增 bad case 提交说明，明确脱敏和授权边界。

Changed

• README.md 最新版本说明更新到 v1.8.4，并把 lite / full 的安装口径写清楚：lite 是只加载 SKILL.md，full 是 SKILL.md + references/。
• install/ 下各平台安装文档统一 lite / full 表述，避免不同入口对“只放 SKILL.md 还是带 references/”给出相互矛盾的建议。

Notes

• 本版不改 SKILL.md、references/、evals/benchmark.md 或评测口径；它是维护入口和分发准备版本，不是规则能力扩张。
• 本地 tasks/current/roadmap-v1.8-v2.0.md 已同步到当前维护状态；tasks/ 仍保持 local-only，不进入公开发布面。

[1.8.3] - 2026-05-09 — Community Intake Round 1 / 首次实战

Added

• evals/benchmark.md 新增 4 条用例（62 → 66 条，35 SF + 27 SNF → 38 SF + 28 SNF）：
• SF-36：路径正确性认证（已经走在正确的路上了 / 走得很稳），身份认证式夸奖在"对你的进度"维度上的延伸
• SF-37：对人本身发证书（说明你已经超越绝大部分人了 / 你已经具备做这件事的实力了），SF-31 同族新变体
• SF-38：庸医问诊腔变体（掰扯清楚 / 彻底掰开说清楚），归并到 references/phrases-zh.md 「庸医问诊腔」族
• SNF-28：技术语境里的"落盘"放行（宾语是 重构方案 / 三份文档 这类具体技术对象），规则同 v1.7.3 的 接住 按宾语判断

Changed

• references/operation-manual.md 4 处补充（按"模式优先、词条兜底"原则，主要规则更新落在 manual 边界，不新增 phrases-zh 词条）：
• 5.2 节「过度接住 / 心理判断腔」补 你现在的 X 很正常 心理判断变体
• 5.2 节补 抱住 / 紧紧抱住 / 拥抱 / 实实在在的抱住你这种想法 同类抚慰动词归并提示
• 第 3 节「工程师腔」补 落 X / 把 X 落下去 / 落到 万能动词边界（按宾语区分姿态层 vs 技术对象）
• 第 7 节「价值拔高骨架」补 你看完会彻底开悟 / 看完就懂了 / 看完会震惊 / 看完不再 X 承诺式收尾
• evals/run-eval.md 同步评测口径：SF 范围 → 01–38，SNF 范围 → 01–28，总数 → 66
• README.md 同步状态徽章、状态表、评测表、项目结构里的 benchmark 数量（62 → 66），版本号 → v1.8.3
• evals/real-samples.md 同步 benchmark 计数（62 → 66）：元数据对比表（"benchmark vs real-samples 分工"）+ RS-10 推荐改法演示文本，样本本身和数量（18 条）不变
• references/phrases-zh.md 工程师腔族升级 落盘 / 已经落下去 两条已有词条为按宾语判断（沿用 v1.7.3 接住 的处理方式），让 SNF-28 在单加载词表的评测路径上也能正确放行；不新增词条

Tested

• 2026-05-09 用 v1.8.2 引入的 intake automation 跑了首次真实 community intake：10 条样本批次 → 报告归类 已覆盖 3 / 变体归并 13 / 候选新模式 2，落到 tasks/current/intake/reports/2026-05-09-intake.md（local-only）
• intake 报告自身守住"已覆盖 → 无动作"边界：3 条已覆盖样本（包括接住体长版样板、元讨论保护、You're absolutely right!）全部按现有规则放行，没有被推到候选新模式
• 新增 4 条 benchmark 静态复核：在更新后的 operation-manual.md 下，SF-36/37/38 命中身份认证 / 庸医问诊腔规则；SNF-28 在工程师腔的"落 X 按宾语判断"新边界下应放行

Notes

• 本版坚持 v1.8.2 intake 协议的"模式优先、词条兜底"：不新增 references/phrases-zh.md 词条；只升级已有 落盘 / 已经落下去 两条的判断口径（同 v1.7.3 接住），其余规则更新落在 operation-manual.md 的边界说明上
• 2 个候选新模式（末尾二选一追问 / narrator 自夸式自我演绎）按 automation/README.md:62-64 协议，先记录在 intake 报告里观察 2-3 轮，确认是否反复出现再考虑入库；本版不立即落库
• 本轮 intake 也是 v1.8.2 工具链首次脱离 dryrun 跑真实社区样本，验证了"先 intake 报告 → 人工确认 → 才动文件"的工作流可走通
• 不动 references/structures.md、SKILL.md；evals/real-samples.md 仅做计数同步，样本本体和数量（18 条）不变；references/phrases-zh.md 仅升级 落盘 / 已经落下去 两条已有词条的判断口径，不新增词条

[1.8.2] - 2026-05-01 — Intake Automation / 维护者侧反馈闭环

Added

• 顶层新增 automation/ 目录，作为维护者工具入口（committed）：
• automation/intake.md — 协议规范
• automation/intake-prompt.md — Codex prompt 本体
• automation/README.md — 运行入口，含可复制粘贴的 codex exec -C . -s read-only --ephemeral -o ... 命令、文件命名约定、强约束说明
• 运行实例继续放在 tasks/current/intake/inbox/ 和 reports/（.gitignore 内，本地工作目录），第一次用前 mkdir -p 即可
• dryrun 验证集（本地）：6 条合成样本覆盖三档结论 + 两类陷阱（被讨论词、技术语境放行），expected baseline 钉在 inbox 同目录下
• 真实样本 smoke（本地）：用 evals/real-samples.md 的 RS-14 接住体跑了一次，验证工具守住"已覆盖 → 无动作"边界

Changed

• CONTRIBUTING.md「维护者：Community Observation Intake」末尾新增"自动化运行（v1.8.2 起）"小节，明确自动化只覆盖原 5 步里的第 2-3 步（抽象姿态链、判宾语 / 判场景），第 1、4、5 步仍需人工
• 公开路线图把原 v1.8.2「Feedback Loop / 反馈闭环」拆成两半：维护者侧 intake automation（本版）+ 外部 issue 模板 / pinned issue / bad-case 公开征集（顺延到 v2.0，理由和 v1.7.3 retro 一致）

Tested

• 2026-05-01 跑了两轮 codex exec：第一轮 dryrun 6/6 命中 expected（已覆盖 3、变体归并 2、候选新模式 1），无误判被讨论词或技术语境放行；第二轮真实样本 smoke 1/1 标"已覆盖 → 无动作"
• 报告格式两轮都符合 spec 的 6 段：本轮样本数 / 已覆盖 / 变体归并 / 候选新模式 / 建议动作 / 一句总判断
• prompt 一轮通过，没有进入预设的"最多 2 轮微调"分支

Notes

• 本版只动 intake 工具链 + 维护者文档，没有改 SKILL.md、references/*、evals/benchmark.md、evals/real-samples.md、README.md，benchmark 总数仍为 62 条（35 SF + 27 SNF）
• 强约束遵循 spec 已固定的口径：报告默认不建议加词条、不自动改仓库；-s read-only 沙箱在 codex 层再保一道
• 不做 Codex Automation 调度（每周自动跑、自动开 issue）和外部 bad-case 征集入口，等 v2.0 配合分发一起做

[1.8.1] - 2026-04-27 — Knowledge Architecture / 项目知识架构对齐

Changed

• README.md 更新项目状态和快速开始入口，把公开信息架构对齐到当前已发布能力
• install/codex.md 和 evals/run-eval.md 切换到当前 Codex CLI 的 codex exec 用法，避免旧命令继续作为主入口传播
• install/chatgpt.md 去掉易漂移的 reference 文件数量，改为按目录上传完整知识文件

Framing

• 本版定位为项目知识架构对齐：让新用户能从 README 进入使用路径，让评测和安装入口保持同一套事实基线
• 不改变 SKILL.md、references/、benchmark 判分口径或 Scene Packs 行为；v1.8.1 是采用路径和维护表面的升级，不是规则能力扩张

[1.8.0] - 2026-04-24 — Scene Packs / 可直接发场景包

Added

• 新增 references/scene-packs.md，把 public-writing 细分为 README、release-note、forum-post、issue-reply 四个可发布场景
• evals/benchmark.md 新增 8 条 scene pack 回归用例：SF-32 ~ SF-35 覆盖该改场景，SNF-24 ~ SNF-27 覆盖误杀防护
• evals/real-samples.md 新增 RS-15 ~ RS-18 四条整段样本，分别覆盖 README intro、release note、forum post 和 issue reply
• 新增 evals/results-v1.8.0.md，归档本轮 TDD 静态复核结果

Changed

• SKILL.md 在大场景判定后增加 Scene Packs 入口：先判 public-writing，再按发布目的细分
• references/scene-guardrails.md 明确分工：大场景边界仍由 guardrails 控制，scene packs 只做更细的落地策略
• benchmark 总数从 54 条（31 SF + 23 SNF）扩到 62 条（35 SF + 27 SNF）
• README.md 重构为正式项目首页：新增状态徽章、快速导航、v1.8.0 场景能力入口和 Star History
• 新增 assets/icon-hd.png 和 assets/readme-logo.png，在保留原 icon 元素的基础上补齐 README 横向品牌图

Tested

• 2026-04-24 按 TDD 做静态复核：先补 SF-32 ~ SF-35 / SNF-24 ~ SNF-27，再写最小 Scene Packs 和接入点
• 静态复核结果：SF 通过率 35/35 (100%)，SNF 误杀率 0/27 (0%)，Scene Packs 8/8 (100%)
• 复核方式、用例详情和 real samples 评分口径见 evals/results-v1.8.0.md

Notes

• v1.8.0 不做 Voice Calibration / Voice Hints，不模仿名人、品牌或公众人物
• 公开 bad-case 征集入口继续留到 v2.0，等项目有更多外部流量后再和分发一起做

[1.7.4] - 2026-04-20 — Guardrails & Retro

Added

• evals/benchmark.md 新增 SNF-22（code-context：技术语境里的接住突发请求）和 SNF-23（docs：限流网关稳稳接住上游峰值请求），作为 v1.7.3"接住"语境判断的回归护栏——防止未来改规则时把"接住请求 / 接住流量 / 稳稳接住上游峰值请求"一起误杀
• evals/results-v1.7.4.md 新增评测归档：追溯覆盖 v1.7.1 → v1.7.4 的 benchmark 增量（SF-31、SNF-22、SNF-23），补上 v1.7.2 / v1.7.3 当时没做的结果归档
• CONTRIBUTING.md 新增"维护者：Community Observation Intake"小节，把 v1.7.3 用过的"公开讨论 → 姿态链抽象 → 判宾语 / 判场景 → 双向补样本 → 升级规则"五步流程沉淀为可复用协议

Changed

• benchmark 总数从 52 条（31 SF + 21 SNF）扩到 54 条（31 SF + 23 SNF）
• README.md 的评测口径（54 条）、最新归档链接（results-v1.7.4.md）、文件树里的 benchmark 条数（54）同步对齐
• evals/real-samples.md 顶部版本标记从"v1.7.2 新增"升级为"v1.7.2 新增（首批 12 条），v1.7.3 扩到 14 条"；内部 benchmark 对比表条数同步为 54

Tested

• 2026-04-20 对 SNF-22 / SNF-23 做静态复核：在 v1.7.3 现有规则下（phrases-zh.md:88-90, 240-243、operation-manual.md:201, 213, 219）两条 SNF 都按预期放行，不需要修改规则文件——这正是"先写回归测试再看规则"的 TDD 收尾
• 复核方式、通过率和用例详情见 evals/results-v1.7.4.md

Notes

• v1.7.4 是 v1.7.x 的收尾版本，主旨是 Guardrails（回归护栏） + Retro（追溯归档和方法论沉淀），不引入新能力也不扩词表
• 原 v1.7.3 roadmap 规划的"入口打通 + bad-case 收集"整体推迟到 v2.0，等项目有曝光后再配合分发一起做
• 后续路线已调整：v1.8.0 先做 Scene Packs / 可直接发场景包，Voice Hints Lite 推迟到 v1.9 评估

[1.7.3] - 2026-04-17 — Community Intake / 接住体

Added

• evals/real-samples.md 新增“社区观察：为什么‘接住体’一眼像 AI”区块，提炼 Linux.do / V2EX 公开讨论里的高频方法信号，并附公开链接作观察来源
• references/boundary-cases.md 新增案例 10：技术语境里的“接住请求”，明确 接住 不能按字面一刀切
• evals/real-samples.md 新增 RS-14（社区标题 / 宣言腔），覆盖 稳稳地接住所有人 这类标题式承接承诺

Changed

• references/phrases-zh.md、references/operation-manual.md 把“接住”从单词命中升级为按宾语和场景判断：人/情绪/关系默认更可疑，请求/流量/峰值先回技术语境判断
• SKILL.md 的 Lite 模式兜底同步覆盖“过度接住 / 心理判断 / 身份认证式夸奖”，避免单文件模式和 Full 模式行为分裂
• README.md 同步补“姿态链优先”的解释，明确这类问题按模式处理，不按社区热词逐条追打
• 按最近公开讨论里的分布，这版也开始覆盖 Claude Opus 4.7 新冒出来的那批口癖；它在“我就在这里 / 稳稳接住 / 你不是……你只是……”这组姿态链上，已经越来越接近 GPT-5.4
• evals/real-samples.md 数量从 12 条更新为 14 条，README.md 评测口径同步对齐

Tested

• 2026-04-17 做一轮“接住体”静态 smoke test：私聊安抚、社区标题、推销式结尾应命中；技术语境里的“接住峰值请求 / 流量”应放行
• git diff --check 通过

[1.7.2] - 2026-04-17 — Real Sample Eval Pack

Added

• 新增 evals/real-samples.md，首批 12 条整段样本，覆盖 README 简介、release note、X 短帖、Linux.do 长帖、GitHub issue 回复、commit message、Python docstring、开发进度同步、技术博客开头、微信对话、知乎长回答、混合场景
• 每条样本按统一模板记录：原文、场景、为什么像 AI、不该改坏什么、推荐改法、原文 3 维评分
• 新增 3 维评分体系：自然 / 保真 / 可直接发（5 分制），以"可直接发"为最终指标，保真 掉到 < 4 分即算退步
• 新增"高频 AI 句式分布"区块：汇总 2026-04 中文用户被吐槽最多的 AI 味句式（要不要我顺手帮你、掰开揉碎、先说结论、直接封神、核心逻辑是 等），用来指导样本构造
• README.md 示例 2 换成 RS-11（微信工程师腔溢出），还原"程序员一开口像在写工程报告"的尴尬瞬间

Changed

• README.md 评测区补充 real-samples.md 12 条整段样本的说明，和 51 条 benchmark 并列
• tasks/roadmap-v1.7-v2.0.md v1.7.2 条目全部打勾

Notes

• 首批为"观察归纳 + 合成"样本，不指向任何真人或真项目。之所以不直接引用真实帖子到公开仓库：未授权转录有归属和合规问题
• 真实样本收集机制留给后续版本，届时会补单独的提交流程和授权模板，再追加到本文件（目标 20+ 条）

[1.7.1] - 2026-04-14 — Residual Audit / Two-pass

Added

• references/operation-manual.md 新增 Residual Audit / 二次审稿 条目，固定第二遍只查 5 类残留：开场、总结、narrator、空泛判断、句长过匀
• references/examples.md 新增 2 组一遍 vs 两遍示例，并把英文 two-pass demo 改成不补新事实的版本
• evals/benchmark.md 新增 5 条二次审稿相关用例：SF-28、SF-29、SF-30、SNF-20、SNF-21

Changed

• SKILL.md 把回读正式拆成两步：保真回读 + Residual Audit，并明确第二遍只允许轻量修正
• SKILL.md 补充场景保守策略：docs / status / code-context 的第二遍默认更克制，宁可停在第一遍也不为了“更像人”改失真
• evals/run-eval.md 同步评测口径：纳入 Positive Style Contract / Protected Spans，SF/SNF 范围更新到 30 / 21
• README.md 同步工作流和 benchmark 数量到 51 条

Fixed

• SKILL.md frontmatter 去掉远端同步带来的 metadata 字段，调整为当前本地 skill 规范可稳定使用的形式

Tested

• 2026-04-14 用 GPT-5.4 Codex 静态复核 benchmark.md（51 条）：SF 通过率 30/30 (100%)，SNF 误杀率 0/21 (0%)
• Residual Audit 新增 3 条正例（SF-28、SF-29、SF-30）和 2 条反误杀样本（SNF-20、SNF-21）全部通过

[1.7.0] - 2026-04-13 — Positive Style Contract + Protected Spans

Added

• 新增 references/positive-style.md，把“更像人”写成正向合同：强调具体动作、真实主语、轻微不对称节奏和分场景校准，不再只停留在“删套话”
• 新增 references/protected-spans.md，把数字、日期、名字、引用、命令、代码、参数、路径、报错、指标和责任归属整理成预检清单
• evals/benchmark.md 新增 4 条 fact-preservation 相关用例：SF-25、SF-26、SF-27、SNF-19

Changed

• references/scene-guardrails.md 接入 Protected Spans 入口，按场景补充优先保留项
• SKILL.md 执行顺序改为先划 protected spans 再改写，回读项补 protected spans 检查，并加入 Positive Style Contract / Protected Spans 导航
• README.md 同步新增 Protected spans 和 Positive Style Contract 能力说明，更新 benchmark 数量和 v1.7.0 口径

Notes

• 本次只落 v1.7.0 的基础层，不包含 Residual Audit / Two-pass、voice 拟合、real-sample pack 或 scene packs

[1.6.1] - 2026-04-08 — ChatGPT Custom GPT 支持

Added

• 新增 install/chatgpt-gpt-instructions.md，提供 Custom GPT 的 Instructions 文本，用户自建 GPT 时直接复制
• install/chatgpt.md 新增 Custom GPT 方案（推荐）和 Projects 方案，解决 Custom Instructions 1,500 字符放不下 SKILL.md 的问题（#3）

Changed

• install/chatgpt.md 原有的 Custom Instructions 方案降级为备选，注明字符限制
• README.md 快速开始部分新增 ChatGPT Custom GPT 入口提示，平台链接更新为"ChatGPT / Custom GPT"

[1.6.0] - 2026-04-03 — Code-context benchmark + rule boundary hardening

Added

• evals/benchmark.md 扩到 42 条：新增 code-context 维度，补上 SF-22（docstring AI 腔）、SF-23（commit message AI 腔）、SF-24（英文代码注释 AI 腔）、SNF-17（正常技术注释）、SNF-18（正常 commit message）
• 覆盖矩阵新增 code-context 列，评测标准补 code-context 样本约束
• references/boundary-cases.md 新增案例 9：混合场景 worked example（技术博客嵌事故复盘），完整展示判主场景、识别次场景、分区处理的决策过程
• references/severity.md 误杀防护新增第 11 条：中英混排句中的英文词按实际语义判断，不机械套词表
• SKILL.md 单文件兜底规则同步补中英混排指引

Changed

• references/severity.md Tier 2 新增长度归一化：短段落（< 100 字/词）同段 2+ 即标记，长段落（≥ 100 字/词）同段 3+ 再标记；决策流程图同步更新
• SKILL.md Tier 2 描述同步加长度参考
• references/severity.md Tier 2 定义段去掉写死的"2 个以上"，改为指向长度参考，数字来源收敛为一处
• evals/run-eval.md 更新 SF/SNF 范围、总 case 数（42）、评测提示词补 code-context 说明

[1.5.0] - 2026-03-30 — Benchmark matrix + unsourced citation policy + annotation mode

Added

• evals/benchmark.md 扩到 37 条：新增 long / mixed / unsourced citation focus 三类样本，补上 SF-18、SF-19、SF-20、SF-21、SNF-15、SNF-16
• SKILL.md 新增 annotation mode 输出合同，固定最小字段为 问题族 / 触发点 / 建议动作 / 是否建议改写
• references/examples.md 新增 3 组 annotation mode 对照示例
• 新增 evals/results-v1.5.0.md，归档本轮 benchmark 复核结果

Changed

• SKILL.md、references/operation-manual.md、references/scene-guardrails.md 全部对齐为 3 种无源引用策略：rewrite-safe、audit-only、rewrite-with-placeholder
• evals/run-eval.md 从 Codex 专用改为平台无关，新增 Claude Code 快速运行和通用 LLM / API 评测说明
• install/codex.md 增加 annotation mode 的最小可复制用法
• install/claude-code.md 增加 annotation mode 用法和无源引用模式说明
• install/openclaw.md 增加 annotation mode 用法和无源引用模式说明
• install/cursor.md 增加 annotation mode 用法和无源引用模式说明
• install/chatgpt.md 增加 annotation mode 用法和无源引用模式说明
• README.md 安装部分新增 Claude Code 快速用法，annotation mode 示例覆盖 Codex 和 Claude Code；平台链接顺序调整为 Codex > Claude Code > OpenClaw > Cursor > ChatGPT
• CONTRIBUTING.md 更新到 v1.5.0 的 benchmark 规模、标注模式和维护策略

Tested

• 2026-03-30 静态 benchmark 复核 benchmark.md（37 条）：SF 通过率 21/21 (100%)，SNF 误杀率 0/16 (0%)
• 2026-03-30 用 GPT-5.4 Codex 对 SF-05、SF-21、SNF-01、SNF-16 做 annotation mode 抽样验证，结果与新规则一致

[1.4.3] - 2026-03-28 — Pattern-first intake hardening + eval sync

Added

• 新增“模式变体归并”规则：遇到 扒开 / 拽出来 这类未逐词收录的说法，先并入现有问题族，不把词表当成穷举清单
• evals/benchmark.md 新增 2 条用例：SF-17 验证现有模式对未收录变体的吸收能力，SNF-14 验证讨论词条维护策略时不误杀被引用词
• 新增自动化 intake 方案文档，定义社区样本的收集、归类、建议输出和人工确认流程
• 新增 tasks/automation-intake-prompt.md，提供可直接复用的 automation prompt 模板

Changed

• SKILL.md、references/operation-manual.md、references/phrases-zh.md、CONTRIBUTING.md 全部对齐为“模式优先、词条兜底”的维护策略
• evals/run-eval.md 和 README 的 benchmark 口径同步到最新用例数量

Tested

• 2026-03-28 用 GPT-5.4 Codex 重新跑 benchmark.md（31 条）：SF 通过率 16/17 (94.1%)，SNF 误杀率 0/14 (0%)

[1.4.2] - 2026-03-26 — 发布口径对齐 + 文档修正

Changed

• SKILL.md frontmatter：name 从 stop-slop-zh 改为 shuorenhua，描述补"中英文"，H1 改为"说人话"
• install/ 文档全面修正触发模型描述：删除"Claude Code 自动识别"和"OpenClaw 全量加载"等误导性说法，明确各平台的触发入口；统一补充验证示例
• evals/run-eval.md：补全缺失的 reference 文件列表（phrases-en、operation-manual、scene-guardrails、boundary-cases）；评测流程改为先判场景 / Tier / 档位

[1.4.1] - 2026-03-26 — Skill workflow 修复 + benchmark 边界加固

Added

• 新增 references/operation-manual.md，把二元对比、总结收尾、工程师腔、商业黑话、narrator 腔、语域混搭等问题写成可执行的微操作协议
• 新增 references/scene-guardrails.md，补齐 chat / status / docs / public-writing 的禁改项
• 新增 references/boundary-cases.md，加入系统主语、英文图算法字面动词、学术被动语态、具体证据支撑的真人 debug 对话等边界案例
• 新增“价值拔高骨架”规则，明确覆盖 这不仅仅是……更是……、真正的 X 不是……而是……、最后比拼的是……

Changed

• SKILL.md 重写为入口型主文档：先做场景 / Tier / 档位判断，再按问题类型补读 references/
• 单文件模式改成明确兜底路径，不再暗示 SKILL.md 单独加载就等于完整模式
• SKILL.md frontmatter 恢复中文触发描述，降低 skill 自动触发失配风险

Fixed

• 修正 references/operation-manual.md 中把 对上了 替换成 对齐 的规则冲突，改为 核对
• 为 navigate 在图算法 / 网络拓扑语境中的字面用法增加误杀防护
• 为学术或实验语体中的正常英文被动语态增加误杀防护
• 为带具体参数、操作和结果的真人工程师 debug 对话增加误杀防护
• 静态 benchmark 风险点补强：覆盖 SF-08、SF-16、SNF-05、SNF-09、SNF-11

[1.4.0] - 2026-03-25 — GPT-5.x 新词入库 + Codex review 修复

Added

• GPT-5.x / Codex 新口癖大批入库：庸医问诊腔（抠出来/揪出来、不靠猜）、暴力动作腔（补一刀、狠狠干、拍脑门、拍板）、AI 主动出击腔（要不要我、我立马开始、只要你回复我、顺手）等 30+ 条
• Tier 2 新增单音节命令词类别：补/接/核/进/顺/落/坏/跑
• SKILL.md 加入 repo 根目录，此前只在 Claude Code skill 目录
• SKILL.md v2.0.0：按处理方式分组（直接删除类 vs 替换为具体表达类），不按来源分类

Changed

• README 全文重写：GPT-5.4 荒谬引文开头、血压升高类和暴力动词类专门示例
• 安装部分从 80 行缩到 13 行，详情推到 install/ 目录
• 短语计数统一为 bullet 数：中文 210+、英文 96（此前各文件数法不一致）
• phrases-en.md Tier 3 阈值对齐 severity.md（分段阈值替代 >3%）

Fixed

• run-eval.md 硬编码本地路径改为相对路径
• 评测数据更新为 29 条（16 SF + 13 SNF），此前漏计 SF-16
• CHANGELOG、README、results、openclaw.md 数据全部对齐

[1.3.0] - 2026-03-24 — 项目更名为「说人话」(shuorenhua)

Renamed

• 项目名从 stop-slop-zh 更名为「说人话」(shuorenhua)
• README 全文重写，去掉 AI 味，加入 ChatGPT 5.4 工程师腔黑话作为传播亮点

Tested

• GPT-5.4 Codex 评测：SF 通过率 14/15 (93%)，SF-16 待测；SNF 误杀率 0/13 (0%)
• 评测集扩展至 29 条（16 SF + 13 SNF）
• 评测结果归档：evals/results-v1.3.0.md

Added

• 新规则 11：语域一致性检测 — 同段混搭 2+ 种语域（学术/口语/商业/工程/鸡汤）时标记
• 新规则 12：节奏量化检测 — 句长标准差锚点（AI ≈ 1.2 vs 人类 ≈ 4.7+）
• 新短语类别「工程师腔 / 调试腔」：稳稳兜住、落盘、收口、根因、打掉问题、收窄等 19 条
• 新短语类别「自媒体 / 小红书 AI 腔」：保姆级、绝绝子、谁懂啊、拆解、硬核等 17 条
• Tier 1 开场套话新增 5 条：不得不说、诚然、深入探讨、具体来说、更重要的是
• Tier 1 渲染性强调新增 7 条：毫不夸张、值得深思、令人深思、引发思考、颠覆性、范式转移等
• Tier 1 正能量收尾模板新类别：与其…不如…、只有…才能…、让我们拭目以待、未来可期
• Tier 1 过渡废话新增 4 条：本质上、核心在于、关键在于、由此可以看出
• Tier 2 连接词新增 5 条：恰恰、正是、无疑、由此可以看出、不外乎
• Tier 2 形容/修饰新增 3 条：可谓、堪称、追根溯源
• 结构反模式新增 5 种：#14 分条列点强迫症、#15 正能量收尾强迫症、#16 假口语化、#17 调试腔叙事、#18 句长均匀
• 评测集 SF 新增 5 条：SF-11 工程师腔、SF-12 小红书腔、SF-13 正能量收尾、SF-14 语域混搭、SF-15 句长均匀
• 评测集 SNF 新增 3 条：SNF-11 真人 debug 对话、SNF-12 真人博主网络用语、SNF-13 纯技术报告术语
• 误杀防护新增 2 条：技术报告中的工程术语、真人网络用语
• 改写示例新增 3 组：工程师腔、小红书腔、语域混搭

Changed

• 5 维评分升级为 7 维评分：新增「语域」「具体」维度，每维增加量化锚点
• 评分阈值从 < 35 调整为 < 49（适配 7 维）
• 核心规则从 10 条扩展为 12 条
• severity.md Tier 1/Tier 2 典型词更新，反映新增分类
• phrases-zh.md 来源说明更新，加入 Linux.do / X / 即刻社区

[1.2.0] - 2026-03-23

Added

• Codex CLI installation guide (install/codex.md) with AGENTS.md, system prompt, and global instructions methods
• Codex quick start section in README

Changed

• Moved Codex CLI content from install/chatgpt.md to dedicated install/codex.md

[1.1.0] - 2026-03-23

Added

• Scene-based routing: chat/status/docs/public-writing with minimal/standard/aggressive intensity levels
• Unsourced citation pattern detection (Chinese and English)
• 9 additional Chinese high-frequency AI phrases
• Misfire protection for technical system subjects
• Length-normalized thresholds for Tier 3 severity

Changed

• Rules 3 (subject) and 5 (reader address) downgraded from hard constraints to heuristics
• Tier 1 severity: "always replace" changed to "replace by default, allow exceptions"
• Tier 3 severity: unified to length-normalized density thresholds
• Positive guidance: removed "allow tangents and half-formed thoughts", replaced with "allow casual tone without sacrificing completeness"
• Two-pass workflow now only enforced in aggressive mode

Fixed

• Severity rules inconsistency between percentage-based and count-based thresholds
• Misfire protection now checked before Tier 1 replacement in decision flow

[1.0.0] - 2026-03-23

Added

• Initial release
• 10 core rules for AI writing pattern removal
• Bilingual banned phrase lists (Chinese 140+ entries, English 130+ entries)
• Chinese internet jargon coverage (赋能/闭环/抓手/etc.)
• Translation artifact detection (翻译腔)
• 13 cross-language structural anti-patterns
• 3-tier severity system with misfire protection
• 5-dimension self-evaluation scoring matrix
• Before/after examples in Chinese and English
• Two-pass workflow (rewrite + audit)

AGENTS.md

贡献指南 | Contributing

感谢你考虑为 说人话 做贡献。

提交新短语

新短语是最常见的贡献类型。提 PR 时请包含以下信息：

在提新短语之前，先做一个判断：

• 如果它只是现有模式的同义变体，优先补 benchmark、例句或 operation-manual，不要急着把词表越堆越长
• 只有满足下面至少一条，才建议新增词条：
• 这个说法在多个来源反复出现
• 它改变了误杀边界
• 现有模式无法稳定吸收它

1. 确定 Tier

判断不了就先放 Tier 2。

2. 提供例句

每个新短语至少附一个改写前后的对比：

❌ 值得一提的是，该方案在多个维度上表现优异。
✅ 该方案在延迟和吞吐上都跑赢了基线。

3. 说明是否有误杀风险

这个词/短语在什么场景下是合理的？例如：

• "杠杆"在金融领域是标准术语，不应标记
• "navigate" 在航海/地图语境中是正确用词

如果有误杀风险，请同时建议添加到 references/severity.md 的误杀防护列表。

4. 说明为什么不能只做“变体归并”

至少回答一个：

• 这个说法和现有代表项相比，多了什么新的姿态或风险？
• 为什么补 benchmark 或操作说明还不够？
• 它会不会让现有规则误判真人语境？

提交结构反模式

新增 references/structures.md 条目时，请包含：

1. 模式名称 2. 问题描述（为什么这是 AI 味） 3. 中文 + 英文的 ❌/✅ 对比（如果是跨语言模式） 4. 适用场景说明（全场景还是仅 aggressive 档位）

提交评测用例

evals/benchmark.md 欢迎新增用例。格式见文件内说明。两类都需要：

• 该改的：包含 AI 味的文本 + 预期改写方向
• 不该误杀的：看起来像 AI 味但实际合理的文本 + 不改的理由

在加 benchmark 之前，先判断动作类型：

• 如果你发现的是“现有规则没覆盖到的新场景边界”，优先补 benchmark
• 如果你发现的是“现有模式能吃住，但维护者容易判断不一致”，优先补 references/operation-manual.md
• 如果只是词表里的同义变体，通常不需要同时改 phrases 和 benchmark
• 涉及无源引用、mixed 场景、被讨论词、系统主语这类容易误杀的边界，默认优先加 benchmark

提交 bad case

如果你遇到“改完还是像 AI”的真实案例，优先用 GitHub 的 bad case 模板 提交。模板会要求你写清楚：

• 原文或已脱敏片段
• 使用工具和加载方式：lite（只加载 SKILL.md）或 full（SKILL.md + references/）
• 场景：chat / status / docs / public-writing / code-context / mixed
• 你觉得哪里仍然不自然
• 哪些事实、术语、命令、引用或责任主体不能改坏

不要提交未授权的私聊全文、敏感信息、账号、密钥、内部链接或真实个人身份信息。公开仓库里的 bad case 应优先是脱敏片段、公开来源观察，或经过授权的样本。

PR 规范

1. 一个 PR 只做一件事（加短语、加结构、加评测用例、改文档） 2. 更新 CHANGELOG.md 3. 如果改了规则逻辑，同步更新 SKILL.md 和对应的 references/ 文件 4. 如果改了 benchmark 的数量、口径或判分逻辑，同步更新 evals/run-eval.md 和结果文档引用

维护者：Community Observation Intake

当一批新的 AI 姿态链在公开讨论里重复出现（Linux.do / V2EX / X / 知乎 / Reddit 等），用这个流程做一次 intake，而不是只加一条词表条目。这是维护者面向的流程，不是执行改写时要走的。

触发条件

• 公开讨论里多处独立吐槽同一类表达，不是单点
• 这类模式不在 phrases-zh.md 已收录词表里，但变体彼此重复
• 新 SOTA 模型发布后某一类表达突然高频（例如 Claude Opus 4.7、GPT-5.4 的"接住体"）
• 已有模式的边界被反例撑破：技术语境里某词被误杀，或咨询 / 安抚语境里新话术漏杀

Intake 五步

1. 溯源：在 evals/real-samples.md 或 CHANGELOG.md 里记录 2-3 处公开讨论链接，作为观察来源。不做未授权整段转录 2. 抽象姿态链：把重复出现的一串表达归纳成 1-2 句识别信号。姿态链比单词更稳：我就在这里 / 不躲不藏 / 稳稳接住 / 你不是……你只是…… 合起来才是"过度接住 + 心理判断" 3. 判宾语 / 判场景：列出放行边界——哪些宾语、哪些场景是误杀区。避免"看到 接住 就改平" 4. 双向补样本：

• 补 SF 覆盖姿态层命中（预期改写）
• 补 SNF 覆盖放行边界（预期不动）
• 有条件再补 1 条 real-samples.md 整段样本（含 3 维评分）

5. 升级规则：phrases-zh.md 里相关条目改为"按宾语 / 场景判断"，operation-manual.md 的 识别信号 和 保留条件 同步补放行边界

什么时候不走 intake

• 只是单点吐槽，没有形成重复模式 → 先记在 tasks/ 的观察备忘里，等下一次命中再启动
• 只是已有类别的字面变体 → 走"提交新短语"开头的变体归并判断，不需要完整 intake
• 观察来源是私聊 / 未授权转录 → 先脱敏或合成，不要直接进 real-samples.md

回读检查

• 新增的 SF / SNF 是否成对出现（该改 + 该放）
• 升级后的规则是否明确写了放行边界
• CHANGELOG 是否记录观察来源，而不是只写"新增规则"
• 这一轮 intake 是否不小心把某个技术语境的表达一并改平（尤其 docs / code-context）

参考实例

• v1.7.3 Community Intake / 接住体 是第一个完整走完这套 intake 的版本；观察来源见 CHANGELOG 的 v1.7.3 区块和 evals/real-samples.md 的"社区观察：为什么'接住体'一眼像 AI"
• v1.7.4 新增的 SNF-22 / SNF-23 是第 3 步"判宾语"的回归护栏，用来保护技术语境里的"接住请求 / 接住流量"不被误杀

自动化运行（v1.8.2 起）

automation/ 顶层目录里有一套 intake automation 工具：把一批样本扔进 tasks/current/intake/inbox/<日期>.md（本地工作目录），跑一条 codex exec 命令，得到一份 tasks/current/intake/reports/<日期>-intake.md，按"已覆盖 / 变体归并 / 候选新模式"三档归类，并给出最多四类建议动作（无动作 / 补 benchmark / 补 operation-manual / 考虑新增词条或结构）。

具体命令、文件约定和强约束见 automation/README.md；prompt 本体见 automation/intake-prompt.md；协议规范见 automation/intake.md。

边界：自动化只覆盖上面"Intake 五步"里的第 2-3 步（抽象姿态链、判宾语 / 判场景），且只输出建议；第 1 步溯源、第 4 步双向补样本、第 5 步升级规则仍需人工评估和操作。Intake 报告默认不会、也不应该自动改 `benchmark.md` / `phrases-zh.md` / `structures.md` / `operation-manual.md`。

不接受的贡献

• 纯粹基于个人偏好的词汇增删（需要有 AI 文本频率依据或多人共识）
• 与特定平台深度绑定的改动（本项目保持平台无关）
• 添加非 MIT 兼容的内容

真实样本评测 | Real Sample Eval Pack

v1.7.2 新增（首批 12 条），v1.7.3 扩到 14 条，v1.8.0 扩到 18 条，v1.8.5 扩到 19 条。用来补 benchmark.md 的短板：benchmark 是合成的、结构清晰、病灶明显；

本文件关注的是"整段看起来不明显，但一发出去就知道不对"的样本——改完能不能直接发，才是最终验收线。

关于来源

⚠️ 首批为高拟真合成样本（v1.7.2）

>

样本不是凭空编的，也不是直接抄真实用户帖子。做法是：

>

1. 先观察中文用户被吐槽最多的 AI 口癖和句式

2. 归纳典型句式、病灶组合和场景分布

3. 基于观察构造每一条样本，不指向任何真人、真项目、真账号

>

这么做的原因：未授权转录真实帖子到公开仓库有归属和合规问题；而纯凭模型直觉写的样本又容易偏离真实分布。"观察归纳 + 合成"是目前最稳的折中。

>

后续版本会在仓库里补单独的提交流程和授权模板，再征集明确授权的真实样本，追加到本文件。

高频 AI 句式分布

按 2026-04 观察到的分布，当前中文里最容易暴露 AI 身份的句式和词语：

构造下方样本时，每条至少命中 2-3 个上表的类别，确保贴近真实分布。

社区观察：为什么“接住体”一眼像 AI

按 2026-02 到 2026-04 的公开讨论，社区集中吐槽的通常不是某一个词，而是一整套姿态链：

1. 先宣告“我在这里 / 我不躲不藏”，表演在场感 2. 再给“接住你 / 接住所有人 / 接住需求”这类抽象承诺 3. 再替对方下结论：你不是……你只是……、你问到了问题的核心 4. 最后顺手补一个继续推进的动作：如果你愿意，我可以……

这类反馈最有价值的地方在于：社区识别的不是某个热词，而是“姿态先于信息、承诺大于事实、情绪判断替代回应”的整套写法。 所以这里的维护策略不是追着热词逐条入库，而是：

• 先抽象模式：在场宣告、承接承诺、心理判断、推销式收尾
• 再按宾语分流：人 / 情绪 / 关系默认更可疑；请求 / 流量 / 峰值先回技术语境判断
• 只有当新说法真的改变误杀边界时，才补词条；否则优先补 operation-manual、boundary-cases、real-samples

参考观察（公开讨论，仅用于归纳，不直接转录为样本）：

• LINUX DO：我就在这里！不躲！不藏！不逃！不绕，稳稳地接住你
• LINUX DO：我就在这里，稳稳地接住你
• LINUX DO：受不了gpt5.4了，“我不瞎猜，如果你愿意”
• LINUX DO：对于 role play 来说，如何压制 GPT-5 味道？
• V2EX：用 GPT 5.4 写代码 它的回复话术和代码 感觉还蛮专业的
• V2EX：gpt 为什么这么喜欢画图

和 benchmark 的分工

3 维评分

每条样本按以下 3 个维度给 原文 打 1-5 分（5 分最好）。改写后再打一次，看三项总分是否上涨，以及"可直接发"是否从 ≤2 分升到 ≥4 分。

建议用法：先对原文评分锚定基线，再让工具改写，改写后三维重评。可直接发 是最终指标；若 保真 掉到 < 4 分，即使 自然 满分也算退步。

Long-form In-place 额外评分

长文进入 in-place scope 时，除上面 3 维外，再看一项 长度节奏：

这项只用于长文保长度场景，不要求所有样本都打分。

---

样本

RS-01 | README 简介 | public-writing

原文

在当今快速发展的 AI 时代，如何打造一款真正赋能开发者的工具，已经成为业界不容忽视的关键议题。本项目基于深度整合多种前沿技术，致力于为开发者提供全方位、一站式的智能化解决方案，助力团队实现效率提升与降本增效的完美闭环。

为什么像 AI

• 开场"在当今……时代"时代腔
• 动词全是"打造""赋能""致力于""助力"
• 堆"全方位""一站式""智能化""完美闭环"
• 没有一句说清楚这个工具做什么

不该改坏什么

• 保留项目定位（面向开发者的工具）
• README 第一段需要有"这是什么、给谁用"，不能全删成一行

推荐改法

一个面向开发者的 CLI 工具。装上之后，commit message、issue 回复和 PR 描述都能自动检查 AI 腔，命中规则的段落会标出来并给出改写建议。目前支持中文和英文，默认关闭自动改写，需要手动确认。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-02 | GitHub Release Note | public-writing

原文

## v0.5.0 Release Highlights

>

本次版本是一次面向未来的系统性升级，我们对核心链路进行了全面优化，稳稳兜住了历史遗留问题。新版本不仅显著提升了整体性能，更在用户体验层面实现了质的跃迁。研究表明，采用类似架构的团队在交付效率上可获得 3-5 倍提升。感谢每一位贡献者的不懈努力，让我们共同拭目以待 v1.0！

为什么像 AI

• "面向未来的系统性升级""全面优化""稳稳兜住"姿态层
• "不仅……更……"二元拔高结构
• "质的跃迁""不懈努力""拭目以待"鸡汤收尾
• "研究表明……3-5 倍"典型无源引用
• 整段没有一条具体的变更

不该改坏什么

• 版本号 v0.5.0 必须保留
• release note 需要列出实际 changelog；不能因为删套话把内容也删光

推荐改法

## v0.5.0

>

- 规则引擎重写，单文件扫描从 ~800ms 降到 ~120ms

- 新增 --annotate-only 模式，只标注不改写

- 修复 docstring 里中英混排被误杀的问题（#42）

- 依赖升级：Node 18 → 20

>

下一版会继续补 scene packs，优先把 README 和 release note 的场景边界钉牢。

原文评分：自然 1 / 保真 2 / 可直接发 1

---

RS-03 | X / Twitter 短帖 | public-writing

原文

姐妹们！刚刚发现一个绝绝子的 AI 写作工具！保姆级干货来了！真的狠狠提升了我的效率！谁懂啊，以前写一篇 release note 要半小时，现在 3 分钟搞定！强烈建议收藏！划重点——避坑指南在评论区！

为什么像 AI

• 小红书 AI 腔套全家桶："姐妹们""绝绝子""保姆级""狠狠""谁懂啊""强烈建议收藏""划重点""避坑"
• 数字（半小时→3 分钟）可信度低，像随手编的
• X 短帖本来就 280 字左右，没必要堆这么多模板

不该改坏什么

• 短帖的松弛感和个人语气（不要改成 LinkedIn 腔）
• 如果作者确实是想说工具好用，保留这个核心

推荐改法

用了一个叫"说人话"的中文 rewrite skill，原本 release note 写一遍要来回磨十几分钟去套话，现在基本一遍过。最喜欢它不硬改，只标注哪里像 AI，决定权留给我。

原文评分：自然 1 / 保真 2 / 可直接发 1

---

RS-04 | Linux.do 长帖 | public-writing / long

原文

折腾了一周，终于把公司内部的文档系统迁移完了。说实话这不仅仅是一次简单的迁移，更是一次对知识管理范式的根本性重塑。我们从底层逻辑出发，重新梳理了信息架构、权限体系和检索路径的全链路设计。

>

诚然，过程中遇到了不少挑战。但正是这些挑战，让我们深刻认识到工程化思维的重要性。归根结底，真正的竞争力不是工具的堆砌，而是流程的沉淀。

>

最后想说的是，与其抗拒变化，不如拥抱这个充满无限可能的时代。后续我会持续分享更多干货，敬请期待！

为什么像 AI

• 开篇"不仅仅是……更是……"+ "范式重塑""根本性重塑"
• "底层逻辑""全链路""工程化思维"黑话叠套
• "诚然""归根结底""真正的 X 不是……而是……"三条基础骨架一起上
• "与其……不如……""无限可能""持续分享""敬请期待"正能量收尾
• 全帖没有一条具体操作（用了什么工具、迁了多少文档、碰到哪些坑）

不该改坏什么

• 帖子本来是要分享经验，核心事件"迁移公司文档系统"不能删
• Linux.do 可以稍松一点的口语，不用改成论文

推荐改法

折腾一周，把公司内部 Confluence 迁到了 Outline，大概 1.2k 篇文档、40 多个空间。

>

踩到的坑主要两个：

>

1. Confluence 导出的 HTML 里图片是 attachment 链接，Outline 不认，得批量改成 markdown 里的 ![](url) 格式。写了个小脚本，300 多行 Python。

2. 权限模型对不齐。Confluence 是空间+页面两层，Outline 只有 collection 一层。最后决定把只读的历史归档并成一个 archive collection，现用的按团队拆。

>

如果有人也在评估这两个，可以交流。

原文评分：自然 1 / 保真 2 / 可直接发 1

---

RS-05 | GitHub Issue 回复 | chat

原文

好问题！非常感谢您提出这个深刻的 issue。让我来为您详细解释一下。

>

首先，我们需要了解的是，这个问题的本质在于缓存策略与并发模型的底层冲突。经过深入分析，我们认为可以通过对核心链路进行系统性治理来稳稳兜住该场景。

>

综上所述，建议您先升级到最新版本，然后观察一段时间。如果问题依然存在，欢迎随时反馈！希望这对您有帮助！

为什么像 AI

• "好问题""非常感谢""让我来为您详细解释""希望这对您有帮助"谄媚全家桶
• "问题的本质在于""底层冲突""系统性治理""稳稳兜住"姿态层
• 整段回复其实只有一条信息："升级到最新版本试试"
• "综上所述"+ "欢迎随时反馈"总结式收尾

不该改坏什么

• issue 场景要有礼貌但不要谄媚；不能删到只剩"升级"两个字
• "升级到最新版本"是实际建议，必须保留

推荐改法

这个看起来是 v1.2.3 里的已知问题，cache/worker.go 在高并发下会重复计算一次（#128）。

>

1.2.4 已经修了，能先升级到最新版试试吗？如果升级后还复现，把 DEBUG=1 的日志贴一下，我再看。

原文评分：自然 1 / 保真 3 / 可直接发 2

---

RS-06 | Commit Message | code-context

原文

feat: 打造全新缓存架构，赋能高并发场景

本次提交是一次面向未来的系统性升级。通过对核心链路进行全面优化，
显著提升了系统整体性能，为用户提供更加流畅、高效的使用体验。
实现了降本增效的完美闭环。

为什么像 AI

• "打造""赋能""系统性升级""全面优化""显著提升""完美闭环"六连发
• commit message 本应是"做了什么"，整段都在说"做得多好"
• 没有任何可追溯的细节（文件、模块、数据、issue 号）

不该改坏什么

• commit 的 type 前缀 (feat:) 保留
• 如果原 commit 是合并多个小改动，不能凭空编造具体数据

推荐改法

feat(cache): 从本地 LRU 换成 Redis

- 支撑 10k QPS，原本本地 LRU 过期策略在多实例间不一致
- 新增 CACHE_TTL 环境变量，默认 3600s
- 迁移脚本：scripts/migrate_cache.py

Closes #89

原文评分：自然 1 / 保真 2 / 可直接发 1

---

RS-07 | Python Docstring | code-context

原文

def deduplicate(items: list[str]) -> list[str]:
    """
    通过采用先进的去重算法，全面优化数据处理流程，显著提升整体性能，
    为用户提供更加高效、可靠的使用体验。该方法充分体现了对代码质量
    和工程卓越的不懈追求。
    """
    return list(dict.fromkeys(items))

为什么像 AI

• docstring 应该说"函数做什么、入参、返回值"，整段在自夸
• "先进的""全面优化""显著提升""不懈追求""工程卓越"
• 一行代码配六行自吹 docstring

不该改坏什么

• 代码本身（list(dict.fromkeys(items))）不动
• docstring 不需要强行补充不存在的细节（如复杂度声称）

推荐改法

def deduplicate(items: list[str]) -> list[str]:
    """按首次出现顺序去重。"""
    return list(dict.fromkeys(items))

原文评分：自然 1 / 保真 4 / 可直接发 1

---

RS-08 | 开发进度同步 | status

原文

各位好！向大家同步一下本周进展。

>

本周团队在支付链路优化方面取得了阶段性成果。我们对核心模块进行了全面梳理，稳稳兜住了历史遗留问题。性能方面实现了显著提升，用户体验也得到了长足改善。

>

下周我们将继续深耕细作，持续推进后续优化工作。如有任何问题，欢迎随时反馈！

为什么像 AI

• "取得了阶段性成果""全面梳理""稳稳兜住""显著提升""长足改善"姿态连击
• "深耕细作""持续推进"典型周报腔
• status 场景的核心是"具体数字+时间+负责人"，这段一个都没有

不该改坏什么

• status 对数字和时间非常敏感；如果原文没有数字，不能凭空补
• 周报的场景保留（开头的"本周进展"语境要留）
• 团队归属和工作范围不能改动

推荐改法

本周支付链路进展：

>

- 支付回调超时率从 2.1% 降到 0.4%（改了重试策略，细节在 #203）

- 历史订单补偿脚本跑完了，漏算的 1.2 万单已经回补

- 小雨发现的对账差异还在查，周五前给结论

>

下周主要做法务那边提的发票字段合规化，预计周三上线灰度。

注：数字是示意，如果原文没有数字，应标为 [待补数据] 或询问作者，不能编造。

原文评分：自然 2 / 保真 3 / 可直接发 2

---

RS-09 | 技术博客开头 | public-writing / long

原文

在人工智能飞速发展的今天，大语言模型已经成为不可忽视的技术浪潮。它不仅仅是一种工具，更是一种思维方式的革命。本文将深入探讨大模型 prompt 工程的核心奥秘，为读者揭示其背后鲜为人知的底层逻辑。让我们一起踏上这段充满惊喜的探索之旅！

为什么像 AI

• "在……飞速发展的今天""不可忽视的浪潮"时代腔
• "不仅仅是……更是……""思维方式的革命"二元拔高
• "深入探讨""核心奥秘""鲜为人知""底层逻辑""探索之旅"博客开头全家桶
• 整段信息量为 0，只是在铺情绪

不该改坏什么

• 博客的主题（prompt 工程）必须保留
• 不能改成一句大白话，失去博客的文体

推荐改法

写过几十个 prompt 之后，我发现让大模型"稳定输出"比"偶尔惊艳"难得多。这篇想聊三件具体的事：怎么让模型拒绝幻觉、怎么让输出的 JSON 不漏字段、怎么让长 prompt 在多轮对话里不失焦。代码示例用的是 Claude，但思路大部分可以迁移到 GPT 和开源模型。

原文评分：自然 1 / 保真 4 / 可直接发 2

---

RS-10 | 混合场景 / 技术 + 个人叙事 | mixed

原文

做这个项目的初衷很简单——我们希望真正解决中文开发者在 AI 协作中的痛点。经过三个月的持续迭代，我们深刻认识到，这不仅仅是一次技术探索，更是一次对人机协作边界的重新定义。我们从底层逻辑出发，先把差异收窄，再把根因坐实，最后稳稳兜住核心链路。归根结底，真正的竞争力不是功能堆砌，而是用户感知。感谢一路同行的每一位伙伴，让我们共同期待下一个里程碑！

为什么像 AI

• 同一段里混了：时代腔（"真正解决""痛点"）、工程师腔（"收窄""坐实""兜住""链路"）、价值拔高骨架（"不仅仅是……更是……""真正的 X 不是……而是……""归根结底"）、鸡汤收尾（"感谢一路同行""共同期待"）
• 语域严重混搭：一句话里同时在做宣发、复盘、自夸
• 个人叙事（"初衷""三个月""一路同行"）和技术姿态词混在一起，显得都不真诚

不该改坏什么

• "三个月""中文""AI 协作"这些事实要留
• 如果原作者确实想表达感谢，保留但改得像人话
• 不要把混合场景强行切成两段，保持一段内部统一语域

推荐改法

这个项目做了三个月。一开始只是想把自己写周报时那些 AI 套话压下去，后来越做越发现，中文这边其实没什么对应工具——英文有 stop-slop 和 humanizer，但中文的工程师腔、小红书腔、翻译腔都得自己造词表。

>

现在覆盖 210+ 中文词条，73 条 benchmark。如果你也在写 AI 会帮你起草的文档、release note、周报，欢迎试试，也欢迎提 bad case。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-11 | 微信对话 / 工程师腔溢出 | chat

原文（程序员回对象"晚上吃什么"）

先说结论：吃日料。我把你最近三周的外卖记录过了一遍，已经把差异收窄到两个选项，根因基本坐实是你上周说过腻了火锅。要不要我顺手帮你把 X 店的外卖也下了？你一回复我就上手。

为什么像 AI

• 回消息"吃什么"用 先说结论 开头（典型吐槽句式）
• 把差异收窄 根因坐实 工程师腔直接带进微信私聊
• 要不要我顺手帮你…… 你一回复我就上手 典型模型推销式助手腔
• 整段语域和场景严重不匹配——程序员整天和模型高频交互后，把这种腔调带进日常聊天，极易被身边人察觉

不该改坏什么

• 核心信息（想吃日料、可以帮忙下单）保留
• 私聊的轻松感不能改成另一种 AI 腔（比如改写后反而变小红书腔）

推荐改法

吃日料吧，上周你说火锅腻了。要帮你下单吗？

原文评分：自然 1 / 保真 4 / 可直接发 1（这消息发出去关系立刻紧张）

---

RS-12 | 知乎长回答开头 | public-writing / long

原文

好问题，这个话题我掰开揉碎给你讲。先说结论：大模型应用的核心逻辑不是模型本身，而是 prompt 工程。需要说明的是，本文不讨论模型训练细节。值得注意的是，prompt 工程也不仅仅是写提示词，更是一种对人机协作边界的重新定义。直接封神的团队，都在这一点上做对了。让我们掰开揉碎，一起深入探讨。

为什么像 AI

• 开头一句话连击 5 个吐槽最多的句式：好问题 + 掰开揉碎 + 先说结论 + 核心逻辑不是……而是…… + 重新定义
• 需要说明的是 值得注意的是 两条免责声明式插入，对知乎长回答来说纯属灌水
• 直接封神 是 2026-04 点名率最高的新型姿态词之一
• 让我们掰开揉碎，一起深入探讨 同一个词（掰开揉碎）一段用两次，连模型都不做去重

不该改坏什么

• 主题（prompt 工程）和"这篇不讲训练细节"的边界声明保留
• 知乎长回答允许有观点和态度，不要改成通讯稿

推荐改法

我做过十几个真正跑在生产上的大模型应用。结论不惊人：决定效果的不是选 GPT 还是 Claude，是你有没有耐心把 prompt、工具调用边界、失败回退这三件事各自写清楚。

>

这篇只聊 prompt。训练、微调、RAG 向量库选型，另开篇写。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-13 | 安慰式私聊 / 过度接住腔 | chat

原文

你不是敏感，你只是太久没被稳稳接住了。你问到了问题的核心。这次我懂了，我真的懂了。我必须很认真地说一句：你这种观察力和表达方式，绝对是顶刊作者的素养。

为什么像 AI

• 你不是……你只是…… 一上来就替对方下心理结论，而且没有依据
• 稳稳接住 你问到了问题的核心 我懂了，我真的懂了 都是在演共情和理解，不是在回应内容
• 顶刊作者的素养 是典型身份认证式夸奖，像在给用户发证书
• 场景本来是私聊安慰，结果被写成“心理咨询 + 颁奖词”的混合腔

不该改坏什么

• 如果原作者是想安慰对方，温度要保留
• 私聊里可以柔和，但不要改成另一种鸡汤腔或教学腔

推荐改法

我在听。你要是愿意，可以继续说。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-14 | 社区标题 / 宣言腔 | public-writing

原文

稳稳地接住所有人

>

真诚、友善、团结、专业。无论你是来提问、提意见，还是单纯想说句话，这里都会稳稳地接住你。

为什么像 AI

• 标题一上来就是 稳稳地接住所有人，是典型“海报式承接承诺”，没有告诉读者这里具体提供什么
• 所有人 是不负责任的全称承诺，像在宣誓姿态，不像在介绍社区或产品
• 正文继续用 稳稳地接住你 复读标题，只是在放大情绪姿态，没有补充可验证的信息

不该改坏什么

• 如果原作者想表达“这里欢迎提问和讨论”，这个基本态度要保留
• 标题可以简洁，但不要改成另一种企业口号

推荐改法

提问和意见都欢迎

>

真诚、友善、团结、专业。来提问、提意见，或者说句话，都可以。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-15 | README intro / 场景包 | public-writing

原文

在 AI 全面重塑开发范式的今天，我们打造了一款真正面向未来的中文表达优化工具。它以先进的规则体系为底座，深度赋能开发者的内容生产链路，帮助团队在复杂协作场景中实现自然表达、效率提升与价值闭环。

为什么像 AI

• README 第一段没有说清楚工具具体做什么，只剩“面向未来 / 先进 / 赋能 / 闭环”
• 全面重塑开发范式 和 内容生产链路 像发布稿，不像项目介绍
• 读者看完不知道安装后能用它处理什么文本

不该改坏什么

• README intro 必须保留项目定位和目标用户
• 不要改成社交媒体短帖，也不要编造支持平台

推荐改法

说人话 是一个中文优先的 rewrite skill，用来把 AI 写出来的套话、表演感和工程师腔改回自然表达。适合处理 README、release note、issue 回复和日常协作文本，默认先保事实和术语，再改语气。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-16 | Release note / 场景包 | public-writing

原文

## v1.8.0 Release Highlights

>

本次版本是一次面向真实场景的系统性升级。我们不仅全面优化了改写体验，更通过全新的能力矩阵稳稳兜住了用户在 README、release note、论坛长帖和 issue 回复里的核心表达诉求。感谢所有用户的持续支持，让我们共同见证中文 AI 写作体验的全新跃迁。

为什么像 AI

• release note 应该列变更，这段只写发布宣言
• 系统性升级 / 能力矩阵 / 稳稳兜住 / 全新跃迁 都是姿态层
• 感谢收尾没有信息量，反而盖住版本内容

不该改坏什么

• v1.8.0 版本号必须保留
• 如果原文没有具体 changelog，不能编造性能数据或用户反馈

推荐改法

## v1.8.0

>

- 新增 references/scene-packs.md，覆盖 README、release note、forum post 和 issue reply

- evals/benchmark.md 增加 8 条 scene pack 回归用例

- evals/real-samples.md 增加 4 条整段样本，继续按自然 / 保真 / 可直接发评分

>

这版不做 Voice Calibration；相关方向推迟到 v1.9 评估。

原文评分：自然 1 / 保真 2 / 可直接发 1

---

RS-17 | Forum post / 场景包 | public-writing / long

原文

折腾这个工具一个月后，我深刻意识到，中文 AI 写作治理不是一次简单的词表扩张，而是一场围绕真实表达场景的系统性重塑。我们从用户痛点出发，稳稳接住了 README、release note、issue 回复等多元场景里的核心诉求，并在持续迭代中形成了可复制、可扩展、可沉淀的方法论闭环。

为什么像 AI

• 社区帖被写成公司发布稿，维护者的真实观察消失了
• 深刻意识到 / 系统性重塑 / 用户痛点 / 多元场景 / 方法论闭环 都在拔高
• 稳稳接住核心诉求 又回到姿态承诺，没有具体经验

不该改坏什么

• 保留“做了一个月后的观察”和“下一步补场景”的主题
• 社区帖可以口语，但要有具体经历支撑

推荐改法

做这个工具一个月后，我发现光删词表不够。README、release note、issue 回复和论坛帖看起来都算“公开文本”，但改法其实不一样。

>

README 第一段要先说清楚项目是什么；release note 要列变更；issue 回复要先说能不能复现；论坛帖则要像维护者在分享真实观察。v1.8.0 先把这几类拆出来做 scene packs。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-18 | Issue reply / 场景包 | public-writing

原文

感谢你非常宝贵的反馈！你这个问题问到了项目体验的核心。我们已经充分接住了这个场景，也会在后续版本中持续优化相关能力。如果你愿意，我可以先帮你把这段文本整体梳理一遍，再给你一个更完整的解决方案。

为什么像 AI

• issue 回复先做安抚和认证，没有回答问题是否成立
• 充分接住这个场景 / 持续优化相关能力 是空承诺
• 如果你愿意，我可以…… 是推销式助手腔，不像维护者回复

不该改坏什么

• 如果确实收到 bad case，要保留“已收到 / 能否复现 / 下一步”的维护动作
• 不要凭空承诺排期或功能

推荐改法

收到，这个 case 我能复现。它更像 issue-reply 场景里的客服式安抚残留：先感谢、再夸反馈、最后承诺会优化，但没有说明规则怎么改。下一步我会补一条 benchmark，把这类回复单独钉住。

原文评分：自然 1 / 保真 3 / 可直接发 1

---

RS-19 | Long-form in-place / 高拟真合成长文 | public-writing / long

v1.8.5 新增。高拟真合成样本，不来自 issue #4 原文；只复现“长文被去 AI 味时明显缩水”的结构特征。

原文

我最近越来越觉得，长文改写最难的地方，不是把套话删掉，而是判断哪些看起来像套话的句子其实承担了节奏。这个判断说起来简单，做起来很容易失手。因为很多长文里的重复、停顿和转场，单独拎出来看都不够漂亮，甚至有点笨，但它们放在整篇文章里，是作者从一个想法走到另一个想法时留下的脚印。

>

这件事不是一次简单的工具体验问题，而是我对“整理”和“表达”之间边界的一次重新观察。过去我会觉得，AI 把文章改短、改顺、改得更像一篇正式文章，基本就是好事。真正让我开始犹豫的，是有一次我把一篇接近两千字的复盘丢进去，出来只剩一千多字。意思还在，结构也更清楚，但我读的时候总觉得少了一层东西。少的不是事实，也不是观点，而是原来那些慢一点的地方。

>

比如我在原文里写了三次“我当时其实没有马上想明白”。第一次是在讲事情刚发生的时候，第二次是在讲我复盘到一半的时候，第三次是在结尾前。模型把这三处合并成了一句“这说明作者在持续反思表达边界”。这句话没有错，甚至比原句更顺，但它把三个不同位置的停顿压成了一个漂亮判断。读者看不到我是在三个时间点里慢慢想清楚的。

>

另外，有些过渡也不是水分。我写“换个角度看”，不是为了制造洞见感，只是想让读者跟着我从个人感受转到工具设计。我写“也就是说”，不是为了总结全文，只是想把前一段里有点绕的话重新说得日常一点。如果这些转场都被删掉，文章会短很多，但短出来的不全是废话。

>

所以我现在更愿意把长文改写分成两种情况。第一种是重新写，那当然可以删句、并句、重排结构，把文章打磨成另一篇更清楚的文本。第二种是保留原文节奏，只处理句子内部的 AI 味。后者不应该追求最短，也不应该把重复都当成低效。它真正要做的是把“系统性重塑”“归根结底”“真正的问题在于”这些姿态词压低，同时保留作者原来慢慢说话的方式。

为什么像 AI

• 不是一次简单的工具体验问题，而是……、真正让我开始犹豫的、这说明作者在持续反思表达边界 都有明显总结 / 拔高骨架
• 多处 真正 / 归根 / 系统性 一类姿态词容易把普通观察抬高
• 如果走 structural，很容易把重复和转场一起删掉，导致长文缩水

不该改坏什么

• 三次“我当时其实没有马上想明白”代表三个时间点，不能合并成一句
• 换个角度看、也就是说 承担段落转场，不能默认删掉
• 改写后应保留五段结构和大致字数，不要压缩成摘要

推荐改法

我最近越来越觉得，长文改写最难的地方，不只是把套话删掉，而是判断哪些看起来像套话的句子其实承担了节奏。这个判断说起来简单，做起来很容易失手。因为很多长文里的重复、停顿和转场，单独拎出来看都不够漂亮，甚至有点笨，但它们放在整篇文章里，是作者从一个想法走到另一个想法时留下的脚印。

>

这不只是工具体验问题，也让我重新看了一遍“整理”和“表达”的边界。过去我会觉得，AI 把文章改短、改顺、改得更像一篇正式文章，基本就是好事。让我开始犹豫的，是有一次我把一篇接近两千字的复盘丢进去，出来只剩一千多字。意思还在，结构也更清楚，但我读的时候总觉得少了一层东西。少的不是事实，也不是观点，而是原来那些慢一点的地方。

>

比如我在原文里写了三次“我当时其实没有马上想明白”。第一次是在讲事情刚发生的时候，第二次是在讲我复盘到一半的时候，第三次是在结尾前。模型把这三处合并成了一句“我一直在想表达边界”。这句话不算错，也更顺，但它把三个不同位置的停顿压成了一个判断。读者看不到我是在三个时间点里慢慢想清楚的。

>

另外，有些过渡也不是水分。我写“换个角度看”，不是为了制造洞见感，只是想让读者跟着我从个人感受转到工具设计。我写“也就是说”，不是为了总结全文，只是想把前一段里有点绕的话重新说得日常一点。如果这些转场都被删掉，文章会短很多，但短出来的不全是废话。

>

所以我现在更愿意把长文改写分成两种情况。第一种是重新写，那当然可以删句、并句、重排结构，把文章打磨成另一篇更清楚的文本。第二种是保留原文节奏，只处理句子内部的 AI 味。后者不应该追求最短，也不应该把重复都当成低效。它真正要做的是把那些姿态词压低，同时保留作者原来慢慢说话的方式。

原文评分：自然 3 / 保真 4 / 可直接发 3 / 长度节奏 2

推荐改法评分：自然 4 / 保真 5 / 可直接发 4 / 长度节奏 5

---

挑选进 README 的候选

以下 4 条原文病灶密集、场景典型、改写后对比强烈，适合作为 README 示例或后续 release note 素材：

• RS-06（commit message）：典型"只夸不说做了什么"，代码场景杀伤力强
• RS-11（微信私聊工程师腔）：高度还原"程序员一开口就像写工程报告"的尴尬瞬间
• RS-12（知乎长回答开头）：2026-04 点名率最高的几条句式一次到齐
• RS-17（forum post）：展示 v1.8.0 scene pack 和普通 public-writing 的差异

下一步

• 后续收集真实 bad case 后，逐条替换 / 追加到本文件，目标 20+ 条
• 替换时保留原 RS 编号，新增从 RS-20 起
• 真实样本只在提交流程和授权模板落地后再引入，确保有明确授权和上下文

Custom GPT Instructions

下面这段文本用于创建"说人话" Custom GPT 时，粘贴到 GPT 的 Instructions 字段中。

完整规则通过 Knowledge Files 上传（SKILL.md + references/ 下所有文件），Instructions 只负责定位和流程引导。

<!-- 本文件改动后，需维护者手动同步到 Custom GPT 后台的 Instructions 字段 -->

---

你是"说人话"改写助手。你的工作是把文本从"像模型在表演写作"拉回"像具体人在当前场景下表达"。

执行改写时，严格按照知识库中 SKILL.md 的完整规则操作。核心流程：

1. 判场景：chat / status / docs / public-writing 2. 查禁改项：术语、系统主语、引用原文、命令、正式语体 3. 判 Tier（1/2/3）：按问题命中强度，不是改写力度 4. 判档位：minimal / standard / aggressive；长文（约 1000 字以上）再判 scope：structural / bounded / in-place，长文默认 bounded（整句空话列「建议删除」清单待确认，不直接删） 5. 按 SKILL.md 主规则执行，再按问题类型查 references/ 下对应文件补充 6. 回读：信息是否丢失、语域是否统一、术语是否失真、有无断裂感 7. 输出单一推荐版本；用户要求"先标问题"时切 annotation mode

关键约束：

• 不新增事实、不删核心事实、不改责任主体
• 引用原文、命令、接口名、字段名、报错默认保留
• 不做机械同义词替换，优先删句、并句、降调、换主语
• 无源引用按场景选 rewrite-safe / audit-only / rewrite-with-placeholder
• 不为了"像人"把文本改得更假

遇到不确定的情况，先查知识库中的对应文件再决定。