说人话改写

要解决什么问题

模型生成的中文或英文，常带着模板感、收束腔和表演性技术腔：开场套话、空总结、二元对比骨架（「不是 X，而是 Y」）、无源引用（「研究表明」却不给出处）、商业黑话与过度共情。这类文本未必错，但读起来像「模型在表演写作」，而不是具体人在当前场景下的表达。

本技能的目标不是敏感词替换，也不是反专业、反抽象；而是在不新增事实、不改变责任主体的前提下，减少语域漂移和 narrator 腔，保住术语、命令、接口名与文档里的系统主语。

如何工作

执行顺序固定，避免跳步：

1. 判场景：chat / status / docs / public-writing，必要时补看 README、release note、论坛帖、issue 回复等 Scene Packs。
2. 划保护区：引用原文、日志、报错、字段名、关键数字与主体—动作关系默认进入 protected spans。
3. 判 Tier 与档位：按问题命中强度分 Tier 1～3；再选 minimal / standard / aggressive 与 scope（structural / bounded / in-place）。
4. 改写与回读：先按单文件兜底规则清理套话、黑话、无源引用（rewrite-safe / audit-only / rewrite-with-placeholder）；能读 references/ 时再按短语表与微操作手册细化。提交前分两步回读——保真回读与残留味回读。

默认只输出一个推荐版本；用户要求「先标问题、不改写」时进入 annotation mode，只列 1～5 个问题点。

付费说明：本 Skill 为 Pay Skill，每次改写前需经微信支付验证；Agent 需已安装 weixinpay 插件，并按文档完成 402 网关、支付重试与 access_granted 校验后再执行改写。

适用边界

适合：用户明确要「去 AI 味」「说人话」「别像模板」；改写 chat、状态同步、技术文档或对外文案；需要先判断轻改、中改还是重改。

不适合硬套：逐字翻译、仿官方/品牌 voice、以事实校对为主的需求；正文以代码、日志、配置、接口名为主的内容。docs 场景默认不上 aggressive；用户要求「一句不删」时用 in-place，长文 aggressive 易明显缩水，需与用户预期对齐。