goodbuddy/resources/skills/deai-writing/SKILL.md

---
name: deai-writing
version: 1.3.0
description: |
  中文正式文档「去 AI 味」审校。用于降低模板化、空泛和过度工整的机器生成痕迹：
  投标方案、技术方案、公司官网文案、研究文章、汇报材料、说明文档、商务邮件。
  在生成或润色中文正式文档之后调用，也可在评审阶段单独调用做质量检查。
  提供可执行的病症词典扫描脚本，把「凭感觉找 AI 味」变成「按清单定位并改写」。
  触发词：去 AI 味、AI 腔、AI 味、文案审校、润色中文文档、官网文案评审。
allowed-tools:
  - Read
  - Grep
  - Glob
  - Execute
compatibility: Python 3.9+，不依赖第三方 Python 包
---

# 中文正式文档「去 AI 味」审校

所谓 AI 味，通常是模板化连接词、空心形容词、强迫式排比、元话语和低信息密度
等可观察特征。扫描器负责找候选，Agent 结合语境改写，人工负责事实与语气验收。
检测结果不是作者身份鉴定，也不能证明一段文字由 AI 生成。

## 什么时候用

- 刚用大模型生成或润色完一份中文正式文档，交付前。
- 长文方案编制流程里，接在关键词核验之后、人工通读之前，作为固定检查步骤
  （见 `longdoc-docx` 技能）。
- 官网/产品文案评审，被人挑出「像 AI 写的」但说不清哪里像。

## 怎么用

先探测可用的 Python 3 解释器：Windows 优先使用 `python`，macOS/Linux
优先使用 `python3`；不要使用未经验证的 Windows `py` 或 WindowsApps
`python3.exe`。下文 `<python>` 表示探测成功的解释器命令。

```bash
<python> "<skill-dir>/deai_scan.py" 方案.md                    # 单文件
<python> "<skill-dir>/deai_scan.py" docs/ --ext .md            # 递归目录
<python> "<skill-dir>/deai_scan.py" public/ --rules my_site    # 叠加项目词典
<python> "<skill-dir>/deai_scan.py" 方案.md --json             # 结构化输出，喂给模型改写
<python> "<skill-dir>/deai_scan.py" 方案.md --fail-on-block    # CI 门禁，阻断项非零则退出 1
```

`<skill-dir>` 指本 `SKILL.md` 所在目录。不要假定技能安装在固定路径，项目技能、
个人技能和插件技能的安装位置不同。

输出分两级：

- **阻断项**：高置信度套路表达，应逐条核对并改写，目标压到接近 0；法律原文、
  客户原话、引用内容和固定术语可以保留，但要记录理由。
- **复核项**：只是候选，结合页面类型、事实边界和专业语境逐条判断，**不追求
  机械清零**。研究文章里的「闭环」如果确有定义就该留着。

标准迭代：

1. 先确认文档类型、目标读者、称谓和不能改变的事实边界。
2. 扫描源文件，将 JSON 命中清单与原文一起交给 Agent 定向改写。
3. 逐条核对改写没有编造数字、删除限制条件或改变责任主体。
4. 复扫，直到阻断项收敛；逐条处理复核项，不机械清零。
5. 做一次结构复核：检查段落是否等长、标题是否同构、列表是否总凑三点、句子
   是否反复使用同一种节奏。
6. 通读全文，检查关键词扫描无法发现的前后矛盾、主体错位和语气漂移。

扫描器只负责定位，不提供自动替换。语义改写必须由 Agent 结合上下文完成，
避免把专业术语、法定提示和事实边界误删。

脚本默认跳过 Markdown 代码块和 HTML 的 `<script>/<style>/<pre>/<code>`，避免
把代码里的 `not ... but` 误判成对照模板。

## 病征清单

### 1. 套路化连接词与转折
`不仅……而且`、`更是`、`无疑`、`毫无疑问`、`值得注意的是`、`需要指出的是`、
`总而言之`、`综上所述`、`总的来说`、`换言之`、`一言以蔽之`、`众所周知`。

改法：直接删掉这些提示词，把后面的内容当正文说。中文母语写作很少这样起承
转合，观点直接给结论。

### 2. 空心形容词与抽象术语
`强大的`、`卓越的`、`高效的`、`全方位`、`一站式`、`赋能`、`助力`、`打造`、
`深耕`、`护航`、`保驾护航`、`量身定制`、`极致`、`无缝`。

改法：换成可验证的具体事实。「强大的性能」→「单卡 141GB 显存，可常驻 3 个
模型」；「高效赋能研发」→「代码审查从人工 30 分钟降到自动 2 分钟」。**能用
数字或具体动作说清的，绝不用形容词。**

`闭环`、`底座`、`形成衔接`、`共同约束` 这类抽象搭配要复核：原句若没说明具体
组件、关系或动作，改成 `平台`、`连接`、`共同限定`、`由……校验`；确有定义的
架构、控制理论或工程语境可以保留。

**具体数字必须来自可复查证据，不能为替换空心形容词而编造指标。**

### 3. 排比与三段式强迫症
命中信号：连续三项结构完全对称的短语；每段都凑成三点；每个要点长度刻意一致。

改法：打破对称。该两点就两点，该五点就五点；长短句混用；把排比拆成陈述句。

### 4. 开头的宏大叙事
`随着……的快速发展`、`在……的今天`、`在数字化转型的大背景下`、`当前，……`、
`近年来，……`。

改法：删掉铺垫，第一句直接进入主题。正式方案的读者不需要背景朗诵。

### 5. 结尾的空洞升华
`让我们携手……`、`共同开创……的美好未来`、`为……贡献力量`、`必将……`、
`奠定坚实基础`。

改法：正式文档结尾给可执行结论或下一步动作，不喊口号。

### 6. 过度自我指涉与礼貌层
过量的 `我们`、`我方`、`本方案`、`本系统旨在`、`致力于`；`希望能对您有所帮助`、
`如有需要，欢迎随时联系` 这类客服尾巴。

改法：正式技术文档以事实和系统为主语；删掉客服式收尾。

### 7. 机械的分点与加粗
命中信号：几乎每句话都是一个 bullet；每个 bullet 都加粗前半句做伪标题；
`首先/其次/再次/最后` 生硬编号。

改法：叙述性内容用段落写，列表只留真正并列、需要逐条对照的信息。

### 8. 中英标点与格式痕迹
滥用破折号 `——`；中文里夹英文半角逗号/括号；`：` 后强行分号排比；Emoji；
`✅❌🚀` 等符号。

改法：破折号能换成逗号、括号或分句就换掉；中文全角标点统一；不用 Emoji。

### 9. 冗余与同义反复
`进行了……的操作`、`做出了……的决定`、`起到了……的作用`、`具有……的特点`、
`实现了……的功能`。

改法：把「进行/做出/起到/具有/实现 + 名词」的绕弯结构还原成一个动词。
「进行了优化的操作」→「优化了」。

### 10. 过度对冲与免责
`可能`、`或许`、`在某种程度上`、`总体而言`、`一般来说` 的密集堆叠。

改法：有把握就直说；确需限定的地方保留一处即可。公司官网中的必要边界集中
说明一次，优先用正向范围表述，例如「支持在约定数据源与人工复核流程下运行」，
避免在标题、正文和 CTA 中反复出现 `不代表`、`不包含`、`尚未`、`不能`。

**研究方法限制、法定提示、安全边界和人工复核要求不适用上述压缩规则，必须
按事实保留。**

### 11. 对照句式、问答式标题与人为凑数
句式：`不是 A，而是 B`、`并非 A，而是 B`、`不只是 A，还要 B`、
`A，而不是 B`、`不先谈 A，先看 B`。英文的 `not A but B`、`rather than`、
`instead of` 同属一类。

标题：`结果回答了三个具体问题`、`以下四点值得关注`、`三个发现`、
`我们需要回答什么`。这类标题只描述文章结构，没有说明本节内容。

改法：删除对照框架，直接写 B；标题直接写研究对象或结果。

- 「拆分依据不是模块名称，而是控制复杂度与数据流特征」
  → 「PS/PL 分工依据控制复杂度与数据流特征」
- 「实测结果回答了三个具体问题」→「正确性、批量性能与时序结果」
- 「交付标准围绕任务结果，而不是模型清单」→「以任务结果界定交付标准」

数量只能来自内容本身。确有三组测量结果时可以列三项，但标题不必强调「有三个
问题」。

### 12. 公司官网写成实施教程
命中信号：首屏用 `先把……接入……`、`从一个场景开始`、`第一步先……` 等操作
指令；公司介绍围绕实施顺序展开，没有说明服务领域和技术能力。

改法：首页首屏先回答「公司面向哪些领域、提供什么服务」。实施步骤放到交付
方式或产品详情里，不承担公司定位。标题用公司或能力主语，例如「面向专业领域，
构建行业智能系统」。

CTA 应指向项目咨询、合作沟通或联系团队，避免 `按清单准备材料`、`从第一步
开始`、`说明当前流程` 这类需求填报或实施指导语言；清单、模板和实施指南只放在
明确标注的资料或交付页面。

首屏说明业务对象、能力范围与交付方式，不展开接口字段、配置步骤、临时文件、
异常回退、队列状态和调试过程。必要技术细节下沉到技术说明，**不因去 AI 味而
删除**。

### 13. 元话语标题
`本节回答……`、`结果说明了什么`、`需要关注的几个问题`、`我们如何理解……`。
标题在评论文章本身，没有给出信息。

改法：直接写主题、对象、指标或结论范围。研究文章优先用 `测试环境`、
`批量性能`、`时序结果`、`适用边界` 等名词性标题。

慎用以 `把`、`让`、`先`、`再` 开头的操作口令；英文标题避免 `Bring...`、
`Start...`、`Let...`、`First...` 祈使句，优先 `Project Consultation`、
`Deployment Scope`、`Human Review` 等名词性标题。

研究和技术报告可以直接陈述测量范围与方法限制，例如「当前测量仅覆盖 INT8
点积」，不要套成「这不是完整检索，而只是……」。

公司官网不公开 `当前基线`、`当前证据`、`已知缺口`、`成熟度等级`、`页面所述`
等内部审查语言，改写为客户可理解的适用范围、接入条件和分阶段交付边界；规划
能力仍须用将来时或设计阶段表述。

### 14. 万能分析框架与标签化收束
`从本质上看`、`从某种意义上说`、`从多个维度`、`核心在于`、`关键在于`、
`归根结底`、`可以看出`、`由此可见`、`具体而言`、`从……角度来看`。

这些表达不一定错误，但连续出现时常在替代真实推理。删掉框架词后检查句子：
如果仍没有对象、动作、条件或证据，就补充具体信息；如果信息已经完整，直接
陈述即可。

### 15. 假引用、假共识与来源模糊
`业内普遍认为`、`研究表明`、`数据显示`、`专家指出`、`实践证明`、
`有观点认为`，但没有来源、样本、日期或适用范围。

改法：能追溯就补来源和口径；不能追溯就改成本文可承担的判断，或删除。不要用
模糊权威给观点加重量，也不要为了显得具体而编造论文、机构、链接和数字。

### 16. 句式和段落节奏过度整齐
命中信号：连续段落以同一短语开头；每段都是「结论 + 三个分点 + 小结」；
多个标题使用同一种问句或冒号结构；句长和段长近乎一致。

改法：按信息关系组织，不按模板配平。合并重复段，拆开超载句；事实、解释、
限制和动作可以使用不同长度，不必每节都做总结。扫描器只能发现少量局部信号，
这项必须人工复核。

### 17. 角色槽位式三段法
`系统做什么、学生做什么、教师看到什么`、`用户需要什么、平台提供什么、
最终获得什么`、`输入是什么、处理什么、输出什么`。这类句子先盘点角色或槽位，
再把内容填进去，形式完整但没有描述真实流程。

角色主语本身没有问题，问题在于反复使用 `谁做什么`、`谁看到什么` 等元问题，
或把每个角色机械配成长度相近的一段。改写时按事件顺序写清触发条件、系统动作
和可见结果，不必给每个角色单独设栏。

- 「系统做什么、学生做什么、教师看到什么」
  → 「学生提交答案时，系统保存答题步骤和引用依据；教师可在评分页展开查看」
- 「教师看到的不只是最终分数」
  → 「评分页同时展示最终得分、答题步骤和引用依据」

需求矩阵、职责表和泳道图本来就按角色组织，可以保留；叙事正文和宣传标题应
优先描述具体流程或结果。

### 18. 闸门、门禁、硬约束等工程黑话
`闸门`、`门禁`、`硬约束`、`卡点`、`护栏` 在工程语境中可能是准确术语，也可能
只是给普通规则套上的比喻。单独出现只作复核，不机械删除。

检查它是否说明了四件事：对象、条件、执行动作和结果。例如：

- 「设置质量门禁」→「测试失败时禁止合并」
- 「形成发布闸门」→「延迟超过 200 ms 时停止发布」
- 「建立安全门禁」→「未通过权限校验的请求直接拒绝」
- 「施加硬约束」→「显存占用不得超过 80 GB」

`CI 门禁`、优化问题中的 `硬约束` 等团队已有明确定义的术语可以保留。若删掉
黑话后仍看不出谁在什么条件下阻止什么，就应改成可执行规则。

### 19. 拟人化数量词与连续工程隐喻
`每一次思考都有证据`、`一颗权重`、`数十亿颗权重`、`数据喂不够快`、
`存储到计算的路越来越繁忙`。拟人化或比喻偶尔能辅助解释，但多个比喻连续出现，
会让技术说明像自动生成的科普文案，并掩盖可验证的技术关系。

改写时回到实际对象、单位和瓶颈：

- 「每一次思考都有证据」→「系统保存答题步骤及其引用依据」
- 「数十亿颗权重都要被反复读取」→「每生成一个 Token，都需要访问模型各层的
  大量权重」
- 「从算得不够快变成数据喂不够快」→「Decode 阶段通常受显存带宽而非计算吞吐
  限制」
- 「这条路越繁忙」→「权重读取总量上升，显存带宽压力随之增加」

不要为了去掉比喻而引入未经测量的结论。`通常受显存带宽限制` 仍需结合模型、
批量大小、硬件和推理实现确认。

### 20. 绝对化承诺与全称判断
`每一次……都……`、`所有……均……`、`任何情况下`、`始终确保`、`完全避免`。
这类表达容易把局部能力写成无条件保证，也常与口号、拟人化表达组合出现。

先核对产品机制和证据范围。能够保证时写清条件，例如「开启过程记录后，评分页
保存每次提交的步骤与引用」；不能保证时改成实际覆盖范围。法规、数学命题和测试
验收标准中的全称表达按原意保留。

## 改写纪律

去 AI 味不是把文本改得干瘪，更不是伪装作者身份，而是去套路、留信息。六条
底线：

1. **只删套路，不删事实。** 形容词换成数字/动作是「换」不是「删信息」；
   连接词、铺垫、升华才是直接删。
2. **保留专业术语与必要限定。** 技术文档里的约束/前提/风险不是对冲水词，
   该留；要删的是无意义的「可能、或许」堆叠。
3. **不删除事实边界。** 保留研究指标的测试条件与统计口径、第三方来源和归属、
   人工复核要求、数据与接口条件及部署范围。去 AI 味不能改变成熟度，也不能把
   规划能力写成已经实现。
4. **改完复读一遍出声。** AI 味的本质是结构过于工整、信息密度偏低，出声读
   最容易发现。
5. **不编造“人味”。** 不故意加入错别字、口头禅、虚构经历、情绪或未经证实的
   个人判断。自然表达来自具体信息和真实语境，不来自人为瑕疵。
6. **尊重引用与固定文本。** 法规、合同条款、客户原话、品牌标语和准确引文不
   因命中词典而改写；必要时从扫描范围排除，或在评审记录中说明保留原因。

## 一分钟自查清单（不跑脚本时）

- 开头有没有「随着/在……的今天」？删。
- 有没有「不仅……而且/综上所述/值得注意的是」？删。
- 有没有「不是 A，而是 B」或「回答三个问题」式标题？直接写 B 或具体结果。
- 有没有「不只是 A，还要 B」？删掉对照架子，直接并列实际信息。
- 公司首页是否写成了实施步骤？改成服务领域、产品能力和公司定位。
- CTA 是否像需求填报表？改成项目咨询或合作沟通。
- 官网是否出现「当前基线」「已知缺口」等内部审校语言？改成适用范围和交付条件。
- 标题是否以 `把/让/先/再` 或 `Bring/Start/Let/First` 发出操作口令？改名词性。
- 产品首屏是否塞入接口字段、回退链、调试过程？下沉到技术说明。
- 有没有「研究表明/数据显示/业内普遍认为」却不给来源？补证据或删除归因。
- 是否反复用「从本质上看/核心在于/具体而言」代替实际分析？直接写对象和结论。
- 是否在盘点「系统/用户/教师做什么」？按真实事件顺序描述触发、动作和结果。
- `闸门/门禁/硬约束/护栏` 是否说明了执行条件和后果？否则改成具体规则。
- 是否使用「一颗权重/数据喂不够快/道路繁忙」等连续比喻？改回技术对象和指标。
- `每一次/所有/始终/完全` 是否超出了证据范围？补条件或缩小范围。
- 限制是否在同一页面重复出现？合并为一处正向范围说明，同时保留必要的研究、
  安全和人工复核边界。
- 形容词能不能换成数字或具体动作？能就换。
- 是不是每段都凑三点、每句都加粗、相邻段落等长同构？按信息关系重组。
- 有没有破折号、Emoji、客服式结尾？清掉。
- 出声读一遍：像人说话，还是像念 PPT？

## 文件构成

```
deai-writing/
  SKILL.md                        # 本文件
  deai_scan.py                    # 扫描器
  ai_smell_dict.py                # 通用词典（跨项目）
  project_rules/
    example.py                    # 可复制的匿名项目词典模板
  tests/
    test_deai_scan.py             # 扫描、屏蔽和项目词典回归测试
```

## 持续进化

每次评审被挑出的新 AI 味用词，回填进词典：

1. 记录原句、评审意见和最终改法。
2. 判断问题属于词语、句式、标题结构还是页面定位。
3. 跨项目通用的进 `ai_smell_dict.py`；只与某站点/项目相关的进
   `project_rules/<项目>.py`，并在该文件的 `REVIEW_LOG` 里追加台账。
4. 在整个项目扫描同类表达，不只修改被点名的那一句。
5. 中英文同步处理，避免中文已改而英文仍留 `not...but`、`rather than` 或
   元话语标题。

新增项目词典：在 `project_rules/` 下新建 `<名字>.py`，导出 `AI_SMELL`、
`REVIEW_ONLY`（都可选）和 `REVIEW_LOG`，用 `--rules <名字>` 加载。
项目词典只允许上述变量的 Python 字面量赋值，扫描器不会执行其中的函数调用或
导入语句。

共享或导出技能时，只带通用词典和匿名模板。项目专属规则可能包含客户名称、
内部措辞和评审记录，不应进入分发包。

## 验证技能

```bash
<python> -m unittest discover -s "<skill-dir>/tests" -p "test_*.py"
<python> "<skill-dir>/deai_scan.py" "<skill-dir>/SKILL.md" --json
```

测试必须覆盖阻断项、复核项、Markdown/HTML 代码区屏蔽、目录扫描和自定义词典。
增加或调整规则后先补回归样例，再发布新版本。

## 已知边界

- 结构性问题（排比、三段式、每段凑三点）正则只能给候选，最终要人读。
- 角色槽位、工程黑话、拟人化比喻和绝对化表达都有合理语境，只能作为复核线索。
- 「不仅……而且」等词单独出现误报率高，词典里已收敛成句式匹配；仍会有误报，
  阻断项要逐条看过再改，不能盲目全局替换。
- 扫描器不判断事实正确性。改写时新引入的数字必须有证据支撑。
- 扫描结果只描述文本特征，不判断作者身份，也不应用于学术诚信或人员考核结论。