说人话
把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。
这份 skill 不是敏感词替换器，也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移，同时保住事实、术语和责任主体。
When to use
在下面这些需求里使用：
- 用户明确说”去 AI 味””说人话””自然一点””别像模板””别太像 ChatGPT”
- 需要改写中文或英文
chat、status、docs、public-writing - 需要先判断文本该轻改、中改还是重改
在下面这些需求里不要硬套：
- 用户要逐字翻译、保留原文风格、仿官方模板或仿特定品牌 voice
- 文本主要是代码、日志、命令、配置、接口名、报错
- 用户要的是事实校对，不是风格改写
Core stance
- 去 AI 味，主要处理的是模板感、收束腔、虚假主语、语域混搭和表演性技术腔。
- 保留技术性。专业词、系统主语、事故复盘用语、PRD/发布说明中的术语默认可保留。
- 优先保信息，再谈风格。任何改写都不能新增事实、删核心事实或改变责任主体。
- 不用机械同义词替换表。默认可以删句、并句、降调、换主语、去总结式收尾；如果进入
in-placescope，就只做句内改写。 - 短语表默认只列代表项，不追求穷举所有变体。遇到新口癖，先按现有模式归类，再决定要不要补词。
Execution order
按固定顺序做，不要跳步：
- 判场景：
chat / status / docs / public-writing - 查禁改项：先划
protected spans，看有没有必须保留的术语、系统主语、引用原文、命令或正式语体 - 判 Tier：
Tier 1 / Tier 2 / Tier 3，按问题命中强度判断，不要把 Tier 当作改写力度 - 再判档位：
minimal / standard / aggressive - 判 scope：
structural / in-place，判断这次能不能动句子和段落结构 - 先执行本文件里的最小规则；只要环境里能读
references/，默认继续按问题类型补看 Protected Spans、Positive Style Contract、微操作手册、结构反模式 和相关短语表；如果目标是“改完能直接发”，或文本明显属于 README、release note、论坛帖、issue 回复，再补看 Scene Packs、真实样本评测 和 改写示例 - 回读拆成两步：先做保真回读，再按需做残留味回读
- 输出：默认只给单一推荐版本；用户明确要求“先标问题，不改写”时切到
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 是两条轴。
structural
默认 scope。适用于短文本、明确要求重写的文本、AI 味密度很高且不需要保留原节奏的文本。
允许动作：
- 删整句空总结
- 合并相邻事实句
- 轻量调整句序或段落落点
- 按场景重写局部结构
in-place
适用于长 public-writing、观点文、复盘文、评论文，以及用户明确说“保长度 / 别缩水 / 字数 / 节奏 / 别删 / 尽量原样”的情况。
默认触发条件：
- 主场景是
public-writing，且中文原文约 1000 字以上 - 用户 prompt 明确要求保留长度、句数、段落节奏或原文结构
禁止动作：
- 不删整句
- 不合并相邻句
- 不重排段落
- 不把多段压成一段
允许动作：
- 句内替换词或短语
- 删除句内提示层、空泛修饰和语气垫片
- 把句内拔高语气降回普通判断
- 在单句内部拆短过满结构，但不改变段落顺序
删短语前先做语义独立性检查：删掉短语后，剩余部分必须仍是完整、可读、没有悬空指代的陈述句。否则改用句内替换，不要硬删。
aggressive + in-place 可以存在，但默认先提醒用户：长文 aggressive 很容易明显缩水；如果用户真正要保长度，优先改成 standard + in-place。用户明确坚持时，再执行 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 项：
- protected spans 是否漂了
- 信息是否丢失
- 语域是否统一
- 术语是否失真
- 删改后是否出现生硬断裂
如果删掉一句后段落突然没了落点，就补一条事实句，不要补口号句。
in-place scope 下额外检查：
- 输出字数低于原文字数 85% 时，回退检查是否误删整句、并句或压段落
- 句数变化超过约 10% 时，回退检查是否偷偷做了 structural 改写
- 关键事实句、转场句和承担节奏的重复句，不能因为“看起来像模板”就默认删除
Pass 2 | Residual Audit
只有在第一遍已经保住事实、但读起来还有轻微 AI 味时，才做第二遍。第二遍固定只查这 5 件事：
- 开场残留：还在用
结论先说 / 直接说结论 / 值得注意的是这类提示层 - 总结残留：还在用
总的来说 / 归根结底 / 最终来看这类空收尾 - narrator 残留：还在解释“这说明了什么”，而不是直接说事实或判断
- 空泛判断残留：还在写
方向是对的 / 意义重大 / 真正理解了用户 - 句长过匀：每句都差不多长、差不多整齐，像被统一抛光过
第二遍只允许做轻量修正：
- 删一个残留开场或收尾
- 合并两句过匀的事实句，或拆一处过满的句子
- 把一句 narrator / 空泛判断压回直接表达
第二遍不要做的事：
- 不重写全文
- 不补原文没有的事实
- 不为了“更像人”改掉术语、参数、命令、报错或责任归属
场景保守策略：
public-writing和 AI 味偏重的chat，第二遍更常需要docs / status / code-context默认更保守；如果第二遍会让语气变口语、变广告、或影响保真，就停在第一遍
Reference navigation
- 本文件可以单独兜底；完整模式默认是
SKILL.md+references/一起工作 - 想先看“改成什么样才算更像人”：看 Positive Style Contract
- 想先看哪