它做的事情很直接——把软著申请的整套流程，编码成一套结构化的工作流。而且它用的是 Anthropic 定义的 SKILL.md 通用规范，所以不只是 Codex，理论上 Claude Code、Cursor Agent、Gemini CLI 这些支持 SKILL.md 的本地编程工具，都能直接加载使用，不绑定任何一家。
你不需要把代码交给任何人。AI 在你本地读你的源码、理解你的业务、生成全套材料。
660 Star，完全免费，Apache-2.0 协议。
作者在项目里写了一句话：
本项目完全免费。请不要相信任何使用本项目包装出来的付费服务。
今天我扒了它的 SKILL.md、6 个 Python 脚本、DOCX 生成管线，把这个工具的底层机制一层层拆开。
每个机制我都会告诉你：你以前遇到过什么坑 → 它怎么解决的 → 对你意味着什么。
01 它不是套模板，是先理解你的业务再写
以前用 AI 写软著材料，最大的问题是——它根本不知道你的软件是干嘛的。
你让它写操作手册，它给你出一套万能模板："第一步登录、第二步创建、第三步提交"。每个软件都一样，全是空话。
这个 Skill 的做法完全不同。它的第一步不是写文档，而是读你的项目。
工作流启动后，AI Agent 会做以下几件事：
扫描项目目录——识别框架（Next.js/Django/Spring...）、源码文件数、页面入口、路由结构生成 项目分析.json——记录每个文件的路径、类型、行数、功能候选生成 业务理解.md 和 业务理解.json——基于源码，用自然语言描述：这个软件是做什么的、面向什么行业、目标用户是谁、核心价值是什么、典型操作流程是什么
然后停下来，让你确认。
STOP_FOR_USER NEXT_ACTION: 请确认软件用途、行业、目标用户、核心功能和申请口径。确认后运行 confirm_stage.py --stage business。
如果业务理解写偏了，你可以直接改。改完确认了，AI 才进入下一步。
对你意味着什么：
操作手册不再是套模板出来的空话。它是基于你的真实源码和业务逻辑写出来的，审核员看了能明白你的软件到底是做什么的。
02 代码材料只来自你的真实源码，禁止 AI 编造
软著申请要求提交代码鉴别材料——通常是前 30 页 + 后 30 页，每页约 60 行。
很多人的痛点是：项目代码几千行，怎么挑？哪些代码最能体现软件的核心功能？
这个 Skill 的处理方式非常硬核：
第一步：AI 扫描全部源码文件，生成候选清单。
它会列出每个文件的路径、行数、类型（前端入口/页面文件/后端逻辑/补充文件），并标注优先级。
第二步：AI 自己先做一轮筛选。
它会在 草稿/代码文件选择.json 里填写：
{
"path": "backend/app/agents/graph.py",
"selected": true,
"line_count": 187,
"model_reason": "LangGraph Swarm 编排核心，体现六 Agent 创建、handoff 和图编译。"
}
注意——每个被选中的文件都必须附上选择理由，说明这段代码体现了软件的什么核心功能。
第三步：让你确认或修改。
如果你觉得它漏了某个重要文件，或者选了不相关的文件，你可以直接改 JSON。
第四步：按规则生成。
而且它有一条铁律：代码材料必须来自真实项目源码，禁止 AI 编造代码。
对你意味着什么：
你不需要自己一行一行翻代码、决定哪些该交。AI 帮你挑好、附上理由、等你确认。生成的代码材料能直接回溯到你的真实源码。
03 操作手册去 AI 味：三轮自检，套话清零
软著操作手册是写给审核员看的，不是写给程序员看的。
但 AI 写出来的东西有两个致命问题：
一是太技术化——满篇"异步队列"、"状态管理"、"接口封装"，审核员看不懂。
二是 AI 味太重——"旨在赋能用户一站式智能化高效便捷地……"这种话连你自己都读不下去。
这个 Skill 的处理方式是我见过最狠的。
它要求操作手册生成必须同步输出 操作手册自检记录.md 和 操作手册自检记录.json，记录每一轮的修改：
轮次
检查内容
第 1 轮
初稿生成，检查章节完整性、截图预留、模块内容厚度、技术化表达
第 2 轮
按项目真实运行流程扩写模块说明，补足上下游衔接关系
第 3 轮
去除制式表达和 AI 味——检查重复句式、统一套话、空泛赞美、营销口号、过度整齐的排比、没有项目细节的正确废话
后续轮次
如果仍有问题，继续补写、去重、改写，不能把未修正的问题交给用户
它还有一个技术术语替换表：
而且 SKILL.md 里明确列出了禁止使用的套话：
避免使用"旨在、赋能、一站式、智能化、高效便捷、显著提升、强大能力、丰富功能"等套话。每段都应能回答"这个项目里这个功能具体做什么、用户看见什么、操作后有什么结果"。
对你意味着什么：
你拿到的操作手册，审核员读得懂，而且不会一眼看出是 AI 写的。每一段都在说具体的事，不是正确的废话。
04 7 道强制人工门禁：AI 不会自己闷头跑完
用 AI 工具最怕什么？它闷头跑完，最后你发现全跑偏了，只能重来。
这个 Skill 的做法是：每到一个关键节点，强制停下来，等你确认。
它定义了 7 道人工门禁：
门禁
停在哪
你必须做什么
environment
环境检查后
选择"安装完整 DOCX 环境"或"用兜底方案继续"
project
发现多个项目目录时
指定哪个是你的项目
business
业务理解生成后
确认行业、目标用户、核心功能、申请口径
application-fields
申请表信息生成后
补全著作权人、日期、硬件环境等字段并确认
code-selection
代码文件选择清单生成后
确认或修改抽取文件和行段
screenshot-method
操作手册截图前
选择 Chrome MCP / Computer Use / 自己截图 / 跳过
markdown
全部草稿完成后
确认可以进入 Word/TXT 生成
每一道门禁都禁止"用户未选择则默认继续"。
确认之后，AI 才会运行对应的 confirm_stage.py 脚本，记录确认时间和内容，然后才进入下一阶段。
对你意味着什么：
你全程可控。不是把项目丢给 AI 然后祈祷它做对。每一步它都会停下来问你："这个方向对吗？"
05 DOCX 生成管线：不是简单的 Markdown 转 Word
很多人觉得"Markdown 转 Word"不就是个格式转换吗？
但软著申请对 Word 的格式有硬性要求：
这个 Skill 的 DOCX 生成管线分三层：
第一层：.NET OpenXML 引擎（推荐）
vendor/docx-toolkit 是一个完整的 .NET 项目，用 OpenXML SDK 直接操作 Word 的 XML 结构。生成出来的文档格式最规范，页眉页脚、分页、代码块格式都精确可控。
第二层：python-docx 兜底
如果没装 .NET SDK，脚本会自动降级到 python-docx。功能基本够用，但复杂格式（比如精确的代码块分页）可能不如 OpenXML 规范。
第三层：基础 OOXML 兜底
如果连 python-docx 都没有，脚本会直接构造 OOXML XML 文件。这是最底层的方式，保证至少能出文件。
而且生成前会做一致性检查：
对你意味着什么：
生成的 Word 不是"能用就行"，而是格式规范、可以直接提交到版权局的水平。而且你不用担心格式出错——生成报告会把所有不一致的地方都列出来。
06 截图方案三选一：不截图也能继续
操作手册需要截图，但不是每个人都有自动截图的条件。
这个 Skill 给了你四个选择：
Chrome DevTools MCP——如果你的 Web 项目已经在浏览器里打开了，AI 可以直接通过 MCP 协议截取页面Codex Computer Use——如果需要点击、切换页面后再截图，AI 可以模拟操作用户自行截图——你自己截好 PNG 放进 用户截图/ 目录，AI 负责整理和引用跳过截图——如果你说"现在不截图"，AI 会在操作手册里保留可见的截图预留位置：
【截图预留：请在此处插入"项目管理"页面或操作结果截图。】
注意：它不用 HTML 注释做占位——因为 HTML 注释在 Word 里看不到。它用的是审核员能看见的明文预留文字。
对你意味着什么：
截图不是硬性门槛。你可以先出文字版材料，截图以后再补。流程不会卡死。
07 完整的输出目录结构
跑完整套流程后，你的项目目录里会多出这样一个结构：
软件著作权申请资料/
├── 环境检查.md
├── analysis/
│ └── project.json ← AI 对你项目的分析结果
├── 草稿/
│ ├── 业务理解.md ← AI 理解后的业务描述
│ ├── 业务理解.json ← 结构化数据
│ ├── 申请表信息.md ← 申请表字段草稿
│ ├── 代码文件选择.json ← AI 推荐抽取的文件清单
│ ├── 操作手册.md ← 操作手册草稿
│ └── 操作手册自检记录.md ← 去 AI 味的自检过程
├── 正式资料/
│ ├── 申请表信息.txt ← 可直接复制填报
│ ├── XXX_操作手册.docx ← 正式操作手册
│ ├── XXX-代码(前30页).docx ← 代码材料前半部分
│ ├── XXX-代码(后30页).docx ← 代码材料后半部分
│ └── 生成报告.md ← 生成过程记录和一致性检查
└── 截图/
└── 截图清单.json ← 截图引用清单
所有文件都在你的本地目录里，没有上传到任何外部服务器。
怎么跑起来
# 1. 克隆仓库
git clone https://github.com/Fokkyp/SoftwareCopyright-Skill.git
cd SoftwareCopyright-Skill
# 2. 安装到 Codex
mkdir -p ~/.codex/skills
cp -R software-copyright-materials ~/.codex/skills/
# 3. 在你的项目目录打开 Codex，说：
# "帮我生成软著申请资料"
运行要求：
可选：.NET SDK（用于完整 DOCX OpenXML 生成）
写在最后
软著申请本身不神秘，真正麻烦的是整理材料。
这个 Skill 做的事情，就是把一个熟练的软著代办的工作流程，编码成 AI 可执行的规则：
先理解业务，再抽代码，再去 AI 味写手册，最后按规范出 Word。
而且每一道关卡都让你确认。
你不需要把项目代码交给外部商家。一切都在本地完成。
作者原话：本项目完全免费。请不要相信任何使用本项目包装出来的付费服务。
觉得这玩意儿能帮你省点事的，去给它点个 Star，也顺便给我点个赞。不用花一分钱，但能让下一个被软著折磨的兄弟知道，有个现成的轮子可以抄。
你申请软著是自己弄还是找代办？花了多少钱？评论区聊聊。