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

name, version, description, allowed-tools, compatibility

name	version	description	allowed-tools	compatibility
deai-writing	1.1.0	中文正式文档「去 AI 味」审校。用于任何需要产出不露 AI 痕迹的正式中文文本： 投标方案、技术方案、公司官网文案、研究文章、汇报材料、说明文档、商务邮件。 在生成或润色中文正式文档之后调用，也可在评审阶段单独调用做质量门禁。 提供可执行的病症词典扫描脚本，把「凭感觉找 AI 味」变成「按清单定位并改写」。 触发词：去 AI 味、AI 腔、AI 味、文案审校、润色中文文档、官网文案评审。	Read Grep Glob Execute	Python 3.9+，不依赖第三方 Python 包

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

AI 味不是玄学，而是一批可枚举、可正则命中、可批量修改的固定套路。所以这件事 能做成脚本 + 清单反复调用，不用每次靠人肉感觉。

什么时候用

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

怎么用

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

<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. 通读全文，检查关键词扫描无法发现的前后矛盾和主体错位。

扫描器只负责定位，不提供自动替换。语义改写必须由 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。 英文的 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 点积」，不要套成「这不是完整检索，而只是……」。

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

改写纪律

去 AI 味不是把文本改得干瘪，而是去套路、留信息。四条底线：

1. 只删套路，不删事实。 形容词换成数字/动作是「换」不是「删信息」； 连接词、铺垫、升华才是直接删。
2. 保留专业术语与必要限定。 技术文档里的约束/前提/风险不是对冲水词， 该留；要删的是无意义的「可能、或许」堆叠。
3. 不删除事实边界。 保留研究指标的测试条件与统计口径、第三方来源和归属、 人工复核要求、数据与接口条件及部署范围。去 AI 味不能改变成熟度，也不能把 规划能力写成已经实现。
4. 改完复读一遍出声。 AI 味的本质是结构过于工整、信息密度偏低，出声读 最容易发现。

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

• 开头有没有「随着/在……的今天」？删。
• 有没有「不仅……而且/综上所述/值得注意的是」？删。
• 有没有「不是 A，而是 B」或「回答三个问题」式标题？直接写 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 字面量赋值，扫描器不会执行其中的函数调用或 导入语句。

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

验证技能

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

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

已知边界

• 结构性问题（排比、三段式、每段凑三点）正则只能给候选，最终要人读。
• 「不仅……而且」等词单独出现误报率高，词典里已收敛成句式匹配；仍会有误报， 阻断项要逐条看过再改，不能盲目全局替换。
• 扫描器不判断事实正确性。改写时新引入的数字必须有证据支撑。