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

name, version, description, allowed-tools, compatibility

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

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

所谓 AI 味，通常是模板化连接词、空心形容词、强迫式排比、元话语和低信息密度 等可观察特征。扫描器负责找候选，Agent 结合语境改写，人工负责事实与语气验收。 检测结果不是作者身份鉴定，也不能证明一段文字由 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. 做一次结构复核：检查段落是否等长、标题是否同构、列表是否总凑三点、句子 是否反复使用同一种节奏。
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 字面量赋值，扫描器不会执行其中的函数调用或 导入语句。

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

验证技能

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

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

已知边界

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