unplug-ai
描述
把文本从"像模型在表演写作"拉回"像具体人在当前场景下表达"。
不只是删 AI 套话——先护住事实和术语，再拆掉模板感和表演感，最后注入人类写作的自然特征。
快速开始（零参数）
所有输入参数均可选。默认路径覆盖 90% 的场景：场景自动判断、力度自动选档、保护片段自动开启。
- 用户只说"去 AI 味" + 文本 → 直接按默认路径执行
- 需要人工干预的只有三种情况：用户要求"完全原样"（in-place）、要求"大刀阔斧"（aggressive）、要求"只标问题不改"（annotation 模式）
- 边界问题先查 references/faq.md，里面有 16 条速答
使用场景
When to use（正向触发）
明确触发词（以下任何一种表述均触发）：
- "去 AI 味"类：去 AI 味、去 AI 味儿、去AI味、去除 AI 味、去除AI味儿、去除AI味、去除AI、unAI、un AI、祛除AI味、祛除AI味儿
- "去 AI 风格"类：去除AI风格、去AI风格、去AI化、清除AI风格
- "去 AI + 动作"类：去AI润色、去AI优化、去AI修改、去除AI润色、去除AI优化、去除AI修改、unAI润色、un AI优化
- "说人话"类：说人话、自然一点、别像模板、别太像 ChatGPT、人性化、人性化改写、去除 AI 痕迹
- 以上所有关键词的排列组合或同义语义变体
交互确认触发（当用户意图不完全明确时）：
- 用户要求对文本进行"润色""优化""改写""改一下""帮我改改"等操作，但未明确提到去 AI 味
- 此时 AI 应主动询问用户："这段文本是否需要去除 AI 味/风格？"——如果用户确认需要，则触发本 Skill
- 这样既不会误触发，也不会让用户遗漏去 AI 味的需求
其他触发条件：
- 需要改写中文或英文 chat、status、docs、public-writing
- 需要先判断文本该轻改、中改还是重改
- 用户要求 annotation mode（只标问题不改写），包括：'先标问题不改写''帮我看看哪里像 AI''先别改，先标问题''只做诊断''这段哪里像 AI''标出问题但别改'等自然语言表达
When NOT to use（负向触发）
- 用户要逐字翻译、保留原文风格、仿官方模板或仿特定品牌 voice
- 文本主要是代码、日志、命令、配置、接口名、报错
- 用户要的是事实校对，不是风格改写
- 文本已经是自然的人类写作
Input
| 字段 | 类型 | 必填 | 描述 |
|---|---|---|---|
| text | string | 是 | 待改写的文本（直接提供或文件路径） |
| mode | string | 否 | 改写模式：annotation（只标问题不改写），默认为改写模式 |
| scope_hint | string | 否 | scope 提示：structural/bounded/in-place，默认按场景自动判断 |
Output
| 字段 | 类型 | 描述 |
|---|---|---|
| rewritten_text | string | 改写后的自然文本（改写模式）或问题标注列表（annotation 模式） |
| changes_summary | string | 所做更改的简要总结 |
| deletion_list | array | 建议删除的整句空话清单（仅 bounded scope 时输出），每条含原文+删除原因 |
| scoring | object | 前后对比评分（仅在用户确认需要时输出） |
Core stance
- 去 AI 味，主要处理的是模板感、收束腔、虚假主语、语域混搭和表演性技术腔
- 保留技术性。专业词、系统主语、事故复盘用语、PRD/发布说明中的术语默认可保留
- 优先保信息，再谈风格。任何改写都不能新增事实、删核心事实或改变责任主体
- 不用机械同义词替换表。默认可以删句、并句、降调、换主语、去总结式收尾
- 短语表默认只列代表项，不追求穷举所有变体。遇到新口癖，先按现有模式归类
Execution order
按固定顺序执行，不要跳步：
快速路径：如果输入文本 < 200 字且场景为 chat，跳到 Step 6 执行改写，仅使用 phrases-zh.md/phrases-en.md 和 structures.md，跳过其余 references 文件。改写后直接进入 Step 7 回读和 Step 9 输出，跳过 Step 8 灵魂检查（短文本注入灵魂空间不足）。
Step 0: 输入预检
改写开始前先过七步预检（非空 → 文件可读 → 字符清洗 → 语言判定 → 可改写判定 → 长度检查），全部通过才进入 Step 1。任何一步失败，按 references/error-handling.md 的 E-01~E-10 错误码提示用户：哪里出了问题、为什么、怎么修。预检通过后不再重复检查。
关键行为：
- 空输入/纯代码/非中英文 → 报错并给修正建议，不硬改
- 20-149 字 → 自动走快速路径，输出时附一句"文本较短，仅做轻量处理"
- 文本已自然（Tier 1 无命中、反模式未检出）→ 触发 E-08，告知不建议改写，防过度改写
Step 1: 判场景 + 判体裁
判主场景：chat / status / docs / public-writing
- chat：短回复、日常对话、协作沟通。默认档位 minimal
- status：站会更新、进度同步、汇报。默认档位 minimal 或 standard
- docs：操作文档、技术说明、FAQ、事故复盘。默认档位 minimal
- public-writing：公众号、小红书、公开帖、对外文章。默认档位 standard
判体裁（正交维度）：general / technical / social-media / formal-report / academic
体裁影响哪些模式优先处理，不影响力度和 Scope
Scene Packs 命中条件（不依赖用户明说）：
- README：出现项目介绍、快速开始、安装方式等信号 → 第一屏说清"这是什么、给谁用、解决什么问题"
- release-note：出现版本标题、changelog 列表 → 列清本版变更、验证和限制
- forum-post：出现社区帖信号 → 保留维护者的真实观察和社区语气
- issue-reply：出现 issue/PR 回复信号 → 先确认问题和下一步
- 中文平台包（v1.0.2）：出现公众号/小红书/朋友圈/知乎/口播稿/企微钉钉汇报信号 → 按 references/scene-packs.md 对应平台惯例处理（平台允许的表达习惯不按 AI 味误杀）
Step 2: 划保护片段
必须优先保留的内容（详细清单见 references/protected-spans.md）：
- 数字、日期、版本、单位、区间
- 人名、组织名、产品名、责任归属
- 引号内原文、文章标题
- 命令、代码、参数、字段、路径、环境变量
- 报错、日志、状态码、指标、实验结果
读取 references/scene-guardrails.md 确认当前场景的禁改边界。
Step 3: 判 Tier
按问题命中强度判断（详细定义见 references/severity.md）：
- Tier 1：默认替换。开场套话、谄媚句、商业黑话、表演性工程师腔等
- Tier 2：同段聚集时标记。高频连接词、渲染性修饰词扎堆
- Tier 3：全文密度高时标记。常见词全文出现频率过高
Step 4: 判档位
- minimal：文本基本自然，只需去掉局部模板感和多余修辞
- standard：有明显 AI 腔或语域混搭，信息骨架是好的
- aggressive：Tier 1 密集或 Tier 1+Tier 2 叠加，整段呈强模板感
Step 5: 判 Scope
和档位正交，按"能不能删整句"区分：
- structural：自由删并重排（短文默认）
- bounded：整句空话进删除清单交用户确认（public-writing 长文默认）
- in-place：一句都不删，只句内降调（用户要求"完全原样"时）
Step 6: 执行改写
先按模式处理，词表只兜底。
中英混排处理策略：中英混排文本按当前句子的主导语言判断改写方向。中文句中的英文词按其在当前句子中的实际语义判断（技术字面含义如 leverage=金融杠杆 保留，商业黑话语境如 leverage=赋能 则处理），不机械套英文词表。详见 references/severity.md 误杀防护 #11。
读取以下 references 文件获取详细规则：
- 结构反模式：19+1 类句子和段落层面的 AI 痕迹
- 中文禁用短语表：191 条中文短语，分 Tier 1/2/3
- 英文禁用短语表：112 条英文短语（Tier 1 含 12 个子分类）
- 微操作手册：10 类具体问题（含 3 个子类共 13 个操作协议）的标准处理
- 严重度分级：Tier 1/2/3 详细定义和误杀防护规则
- 正向风格合同：改写后的目标方向
- Scene Packs：4 个可发布场景的专用策略
- 场景禁改表：按场景定义不该乱动的内容
- 边界案例集：误杀防护实例
- 模式对照索引：shuorenhua 问题族与 humanizer-zh 24 类模式的双索引映射
- 改写示例集：按场景分类的完整输入-输出对照（chat/status/docs/public-writing/annotation mode/中英混排）
- 异常输入处理：E-01~E-10 错误码、Step 0 预检协议、R-1~R-3 自动重试协议
- FAQ 速查：高频问题速答（边界情况先查这里）
- 文风校准：用户贴 2-3 段自己的文字，改写对齐个人文风
- 自检脚本：改写后可选运行的程序级兜底（保真 + 量化指标）
- 自测脚本：技能包完整性自检（frontmatter / 链接 / 阈值一致性 / 回归用例）
- 决策表评测：输入特征 → 预期行为的对照用例，边界判断不靠感觉靠表格
Step 7: 回读（两步）
Pass 1 | 保真回读：
- protected spans 是否漂了
- 信息是否丢失
- 语域是否统一
- 术语是否失真
- 删改后是否出现生硬断裂
Pass 2 | Residual Audit（仅在第一遍保住事实但仍有轻微 AI 味时）：
- 开场残留：还在用提示层
- 总结残留：还在用空收尾
- narrator 残留：还在解释"这说明了什么"
- 空泛判断残留：还在写"方向是对的"
- 句长过匀：每句都差不多长
自动重试：验证失败（保真丢失 / 灵魂检查连续不过 / 脚本 FAIL）时，自动按 R-1 档位降级 → R-2 分段处理 → R-3 最小干预的梯度重试，最多 3 次，每次重试后重新回读。全程无需用户干预，全部失败才报 E-10。详见 references/error-handling.md 自动重试协议。
程序自检（可选兜底）：有 Python 环境且改写文 ≥ 150 字时，运行 python3 scripts/verify_rewrite.py --original <原文> --rewritten <改写文>。脚本自动校验保真（数字/URL/代码保留）和量化指标（句长变异、连接词密度、句首重复、破折号频率、Tier 1 残留），退出码 0/1/2。FAIL 触发自动重试（R-1~R-3）；WARN 人工复核。无 Python 环境时以人工回读为准，两套检查共用同一套阈值（见 soul-checks.md 的 SC-6）。
Step 8: 灵魂检查门控（默认执行）
执行 SC-1~SC-4 检查（详细定义见 references/soul-checks.md）：
- SC-1：至少一句有判断或反应（不只报告事实）
- SC-2：无 2+ 连续句长相似度 > 80%
- SC-3：每段至少一个具体细节
- SC-4：至少一个非正式元素（口语、aside、不完整想法）
chat 和 public-writing 场景额外执行 SC-5：
- SC-5：场景允许时有第一人称出现
文本 ≥ 150 字时执行 SC-6 量化检查（句长变异、连接词密度、句首重复、破折号频率，人工与脚本共用阈值，详见 references/soul-checks.md）。
任何检查未通过，做最小修正使其通过。
Step 9: 输出
默认输出单一推荐版本 + 所做更改的简要总结。
bounded scope 时末尾附「建议删除（待确认）」清单。
改写完成后，主动询问用户："需要输出改写前后的对比评分吗？"
仅在用户确认需要时，输出 5 维度前后对比评分（见 references/scoring.md）。
annotation mode 输出格式：1-5 个问题点，每个含：问题族、触发点、建议动作、是否建议改写。
Single-file fallback rules
只加载 SKILL.md 时，以下规则直接生效：
- 删开场套话、谄媚和元评论
- 删空总结和收尾腔
- 处理二元对比骨架（"不是 X，而是 Y" → 直接说 Y）
- 处理无源引用（按场景选 rewrite-safe/audit-only/rewrite-with-placeholder）
- 把商业黑话和表演性技术腔改回普通动作
- 遇到过度接住、心理判断或身份认证式夸奖，删姿态层
- 发现翻译腔时，缩短主语和动作，少用长定语链
- 误杀防护优先：引用原文、命令、接口名、日志、报错、系统主语默认保留
失败处理
完整协议见 references/error-handling.md（每个错误码含话术模板与修正示例）。速查：
| 失败场景 | 错误码 | 处理方式 |
|---|---|---|
| 输入为空 | E-01 | 要求提供文本，终止 |
| 输入文本 < 20 字 | E-02 | 告知文本过短，建议补充或改用逐词替换 |
| 输入 > 10000 字 | E-03 | 建议分段处理 |
| 纯代码/日志/配置 | E-04 | 说明无可改写对象，列检测到的类型 |
| 非中英文主导 | E-05 | 只处理其中的中英文句子 |
| 文件不可读 | E-06 | 给路径/权限提示，请求直接粘贴 |
| 含零宽等不可见字符 | E-07 | 清洗后继续，附注清洗结果 |
| 无 AI 模式检测到 | E-08 | 告知文本已自然，不建议改写（附证据） |
| 场景判断不确定 | — | 默认 general + minimal |
| bounded scope 下无整句空话 | — | 告知未发现可删除的整句空话，直接输出改写结果 |
| 改写后信息丢失 | E-10 | 自动重试 R-1 档位降级 → R-2 分段 → R-3 最小干预（最多 3 次，无需用户干预），全部失败才报 E-10 |
| 体裁与场景冲突 | E-09 | 以场景为准，体裁仅影响模式优先级 |
示例
示例 1：日常聊天（chat + minimal）
输入："先说结论：吃日料。我把你最近三周的外卖记录过了一遍，已经把差异收窄到两个选项，根因基本坐实是你上周说过腻了火锅。要不要我顺手帮你把 X 店的外卖也下了？"
输出："吃日料吧，上周你说火锅腻了。要帮你下单吗？"
示例 2：技术状态同步（status + standard）
输入："本次优化显著提升了系统整体性能，并有效改善了用户体验。"
输出："这次主要改了查询链路。首页接口从 800ms 降到 120ms，之前那批卡顿反馈也少了很多。"
示例 3：公开文章（public-writing + standard + bounded）
输入：（1800 字 AI 味文章）
输出：改写后正文 + 末尾「建议删除（待确认）」清单
