feat: improve skill import and runtime delivery
This commit is contained in:
lofyer
@@ -0,0 +1,272 @@
|
||||
---
|
||||
name: deai-writing
|
||||
version: 1.1.0
|
||||
description: |
|
||||
中文正式文档「去 AI 味」审校。用于任何需要产出不露 AI 痕迹的正式中文文本：
|
||||
投标方案、技术方案、公司官网文案、研究文章、汇报材料、说明文档、商务邮件。
|
||||
在生成或润色中文正式文档之后调用，也可在评审阶段单独调用做质量门禁。
|
||||
提供可执行的病症词典扫描脚本，把「凭感觉找 AI 味」变成「按清单定位并改写」。
|
||||
触发词：去 AI 味、AI 腔、AI 味、文案审校、润色中文文档、官网文案评审。
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Grep
|
||||
- Glob
|
||||
- Execute
|
||||
compatibility: Python 3.9+，不依赖第三方 Python 包
|
||||
---
|
||||
|
||||
# 中文正式文档「去 AI 味」审校
|
||||
|
||||
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. 通读全文，检查关键词扫描无法发现的前后矛盾和主体错位。
|
||||
|
||||
扫描器只负责定位，不提供自动替换。语义改写必须由 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 字面量赋值，扫描器不会执行其中的函数调用或
|
||||
导入语句。
|
||||
|
||||
共享或导出技能时，只带通用词典和匿名模板。项目专属规则可能包含客户名称、
|
||||
内部措辞和评审记录，不应进入分发包。
|
||||
|
||||
## 验证技能
|
||||
|
||||
```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 代码区屏蔽、目录扫描和自定义词典。
|
||||
增加或调整规则后先补回归样例，再发布新版本。
|
||||
|
||||
## 已知边界
|
||||
|
||||
- 结构性问题（排比、三段式、每段凑三点）正则只能给候选，最终要人读。
|
||||
- 「不仅……而且」等词单独出现误报率高，词典里已收敛成句式匹配；仍会有误报，
|
||||
阻断项要逐条看过再改，不能盲目全局替换。
|
||||
- 扫描器不判断事实正确性。改写时新引入的数字必须有证据支撑。
|
||||
Reference in New Issue
Block a user