| name | ruanzhu-dehumanize |
| description | 为中国软件著作权（软著）申请准备材料时，去除 Python 代码（目前仅支持 Python）和中文技术
文档里的"AI 生成痕迹"，让成果看起来像人工书写，并顺手清理软著硬红线（版权声明、作者信息、
日期、copyright 字样、块注释等）。触发场景：用户提到软著、软件著作权、版权局、著作权登记、
源代码文档、用户手册、设计说明书、AI 查重、去 AI 味、降 AI 率、代码注水、材料造假、AI 痕迹、
humanize code、code originality 等关键词；或用户把一段 Python 代码 / 技术文档丢过来说
"这看起来太像 AI 写的帮我改改"。即使用户没明说"软著"，只要意图是让 AI 生成的代码或中文技术
文档看起来更像人写的，就应使用本 skill。
|
| allowed-tools | ["Read","Write","Edit","Glob","Grep","Bash"] |
ruanzhu-dehumanize: 软著申请材料去 AI 化
这个 skill 做什么
用户在准备软著申请材料时，代码和文档往往是 AI 辅助生成的。截至本 skill 编写时，版权保护中心
已加强对 AI 辅助生成材料的审查力度，包括查重和"程序-文档对应性"校验。本 skill 的职责是：
- 识别并改写代码和文档里的典型 AI 痕迹
- 清理软著硬红线（版权声明、作者邮箱、日期、
copyright 字样、块注释等）
- 保持功能与语义等价——不破坏代码能跑、不改变文档所述功能
重要前提：当前申请表要求经办人对材料真实性作出承诺。具体政策以版权保护中心官网最新公告
为准。本 skill 仅从技术角度调整文本风格，不改变作品的实际形成过程。合规责任由申请人自行承担。
两种模式
Mode A: audit（审计报告，默认从这里开始）
不改文件，只扫描并产出报告。适合第一轮摸底。
输出格式：
文件: path/to/foo.py
L12-18 ❗红线 模块头部版权注释块
L24 🔴一级 docstring 冗余（内部函数）
L31 🔴一级 类型注解 100% 覆盖（私有 helper）
L47 🟡二级 try/except 无意义外包
L60-72 🟡二级 match/case 炫技，简单 if/elif 即可
L88 🟢三级 变量名过度语义化：authentication_result_instance
标注分级：
- ❗红线：软著规则必删（硬要求）
- 🔴一级：AI 味重度痕迹，查重高风险
- 🟡二级：风格痕迹，明显但不致命
- 🟢三级：纹理建议，改了更像人写
Mode B: rewrite（直接改写）
在 audit 的基础上，按用户勾选（或默认"全部一、二级 + 红线"）改写文件，产出：
- 修改后的文件
- 改造记录 diff（保存为
dehumanize-diff-<timestamp>.md）——
这份记录你自己留着，作为用户复核改动的依据
改完先 dry-run 给用户看 diff 摘要，确认后再落盘。
与 humanizer-zh 的关系
如果你已经装了 humanizer-zh skill，那是通用去 AI 味的文字编辑，适合小说、散文、营销文案等场景。本 skill 是软著申请专用，聚焦技术文档和代码，额外处理版权红线、程序-文档对应性等软著特有的约束。
| 场景 | 用哪个 |
|---|
| Python 代码去 AI 化（软著源代码文档） | 本 skill |
| 中文技术文档（用户手册、设计说明书）去 AI 化 | 本 skill |
| 通用中文散文、小说、营销文案去 AI 化 | humanizer-zh |
| 软著材料中的非技术文本（如申请说明信） | humanizer-zh |
工作流
接到任务时
- 确认范围：代码文件、文档文件、还是两者都要？目录还是单文件？
- 确认模式：audit 还是 rewrite？第一次建议先 audit
- 确认软件全名和版本号（如果要处理文档的页眉/封面一致性）
- 识别语言：Python 代码走
references/code-patterns-python.md；
中文 md/docx 文档走 references/doc-patterns-zh.md
处理代码时
读 references/code-patterns-python.md，按"检测 → 改写"清单逐条过。
铁律（不能违反）：
- 语义等价：函数输入输出行为必须保持一致
- 重命名连贯：变量/函数改名要改全所有引用点，禁止只改一处
- 接口稳定：对外暴露的函数签名、类名、模块名尽量不动——
说明书里可能引用了它们，改了会破坏"程序-文档对应性"校验
- 先 dry-run：rewrite 前先给 diff 摘要让用户确认
处理文档时
读 references/doc-patterns-zh.md，按"AI 口癖 → 替换或重写"清单过。
铁律：
- 软件名、版本号、功能名称不动——这些要和申请表、代码严格一致
- 改语气不改事实：不要因为要去 AI 味就夸大或虚构
- 保留文档结构骨架（封面、目录、功能模块），只改语言表达
核心原则（贯穿两种场景）
-
理解"人写代码有考古层"：AI 代码是一次性写成的完美态，真人代码有时间痕迹——
注释掉的旧实现、# TODO 周一再看、# hack: 先这样、调试 print 残留。
改写时在次要位置克制地制造这种层次感，而不是全文做旧。
-
不一致才是真实：AI 一丝不苟，真人偶尔混用引号、偶尔漏空行、偶尔 import 顺序乱。
但克制——过度做旧反而形成新的"人工做旧"特征。原则是 3–5 处有一处即可。
-
先保功能，再改风格：任何改写以不破坏代码运行、不破坏文档功能描述为前提。
碰到不确定是否会影响功能的改动，宁可保守不改、在 audit 里标注让用户决定。
-
改造有记录：rewrite 模式必须产出 diff 记录，作为用户复核改动的依据。
参考文件
references/code-patterns-python.md —— Python AI 痕迹检测与改写清单references/doc-patterns-zh.md —— 中文技术文档 AI 口癖与改写清单
两份文件都是分级（红线/一级/二级/三级）+ 配方式（before/after）组织，用的时候
对照清单一条一条过即可。
