王仕宇开源了一个软件著作权材料生成 Skill：Copyright Forge
最近我做了一个比较实用的 AI Agent Skill：
Copyright Forge Skill。
它的作用很直接：
读取一个真实的软件项目，帮助开发者整理和生成软件著作权登记所需要的说明书、源程序材料、申请信息填报稿以及相关校验报告。
简单来说，以前准备软著材料，很多工作都需要自己翻项目、整理功能、筛代码、写说明书、检查软件名称和版本号是否一致。
现在我希望把这一整套流程交给 AI Agent 来完成。
项目已经开源。
为什么要做这个 Skill？
如果你自己申请过软件著作权，应该会发现一个问题：
真正麻烦的往往不是写代码，而是整理材料。
比如：
- 软件到底有哪些主要功能？
- 说明书应该怎么写？
- 哪些代码适合作为源程序鉴别材料？
- 软件名称、版本号有没有前后不一致？
- 项目里有没有数据库密码、API Key 等敏感信息？
- 说明书里写到的功能，代码里面到底有没有？
- 一个后端 API 项目，没有多少 UI 截图怎么办？
- CLI 工具和 Web 项目的说明书是不是应该用同一种模板？
如果完全让大模型自由发挥，又会遇到另一个很严重的问题：
AI 很容易“脑补”。
例如你的代码里明明没有会员系统，它可能为了让说明书看起来完整，给你写一个会员管理模块。
从文档生成角度看似乎没问题，但对于软件著作权材料来说，这反而是不应该出现的。
所以 Copyright Forge 的核心并不是：
帮你写一篇漂亮的说明书。
而是：
从真实的软件项目出发，有证据地整理软著材料。
它本质上是一个 AI Agent Skill
Copyright Forge 不是一个传统的 SaaS 网站，也不是让我再开发一套软著管理后台。
它本质上是一个：
AI Agent Skill。
也就是说，你可以把它安装到支持 Skill 工作流的 AI Coding Agent 中，让 Agent 获得一套专门处理软件著作权材料的规则、流程、模板和脚本。
Skill 的入口文件是：
skills/copyright-forge/SKILL.md
整个 Skill 不只是几段 Prompt，而是包含了一套相对完整的工作流。
项目结构类似：
copyright-forge-skill/
├── docs/
├── skills/
│ └── copyright-forge/
│ ├── SKILL.md
│ ├── scripts/
│ ├── assets/
│ └── references/
├── tests/
├── CHANGELOG.md
├── CONTRIBUTING.md
├── LICENSE
└── README.md
这也是我现在比较喜欢的一种 AI 应用方式。
不是重新开发一个 Web 页面，然后再套一个聊天框。
而是：
直接把专业知识、工作流程和工具封装成 Skill，让 AI Agent 去执行。
Copyright Forge 可以做什么？
目前第一版主要围绕普通的软件著作权登记材料准备流程设计。
1. 自动分析软件项目
首先它会扫描真实项目，识别项目结构和技术栈。
目前已经考虑：
Go
Java
Python
Node.js
Vue
React
这意味着它不是让你先手动告诉 AI：
“这是一个 Vue + Go 的管理系统。”
而是尽量先从项目本身寻找依据。
2. 从代码中提取功能证据
这是我比较看重的一个设计。
Copyright Forge 强调：
Evidence First——证据优先。
比如 AI 判断你的软件有：
用户登录
订单管理
文件上传
权限控制
数据统计
不能仅仅因为项目名称像一个后台管理系统，就自动把这些功能全部写进去。
它需要尝试建立：
功能
↓
模块
↓
文件
↓
代码证据
这样的对应关系。
然后再生成软件功能描述。
这样可以尽量避免一种很常见的问题：
说明书写得非常丰富，但是项目里面根本没有这些功能。
3. 建立统一的软件信息档案
准备软著材料时，还有一个特别容易出错的问题：
材料之间的信息不一致。
比如：
说明书：
软件名称：XX智能管理系统
版本：V1.0
源代码文档：
软件名称：XX管理平台
版本：1.0.0
申请信息里可能又出现第三种写法。
Copyright Forge 为此设计了一个统一的软件信息档案：
software-profile.yaml
类似：
software:
name: "示例智能管理系统"
short_name: "示例系统"
version: "V1.0"
applicant:
name: "待确认"
development:
method: "待确认"
completion_date: "待确认"
publication:
status: "待确认"
之后生成的材料尽量都从这个 Profile 读取信息。
也就是说：
先确定事实，再生成材料。
而不是每生成一个文件就让 AI 重新猜一次。
4. 自动整理源程序材料
申请软著时，源程序材料也是比较耗时间的一部分。
一个实际项目可能有：
3 万行代码
10 万行代码
甚至几十万行代码
你不可能把整个 Git 仓库直接提交上去。
Copyright Forge 提供了源程序选择和清单生成流程。
例如：
python3 "$SKILL/scripts/collect_source.py" \
/path/to/project \
--output "$OUT/source-manifest.json"
生成一个确定性的 Source Manifest。
也就是说，同样的项目、相同的规则，尽量得到稳定的源码选择结果，而不是让 AI 每次随机挑一批代码。
5. 检查敏感信息
这个功能其实非常重要。
真实的软件项目里面经常存在：
API Key
数据库地址
数据库密码
Token
Secret
内部服务地址
Access Key
如果直接整理代码然后提交，很可能把这些东西一起带出去。
Copyright Forge 因此提供了敏感信息检测流程。
需要特别说明的是：
它不会修改你的原始项目。
如果需要脱敏，只处理生成出来的副本，并且记录发生过哪些脱敏操作。
这一点我认为是做代码类 Agent 工具时很重要的原则：
尽量不要为了生成材料，污染用户原始代码。
6. 根据软件类型生成不同文档
不同的软件其实并不适合使用完全相同的说明书。
例如一个：
Vue + Java 管理系统
比较适合用户操作手册。
而一个：
Go API 服务
可能几乎没有用户界面。
如果强行要求几十张系统截图，反而很奇怪。
因此 Copyright Forge 会根据软件形态考虑不同的材料形式。
例如：
UI 软件
更偏向：
用户操作说明
功能页面说明
真实软件截图
API / 后端服务
更偏向：
功能说明
系统设计说明
接口能力说明
CLI 工具
则更偏向：
安装方式
命令说明
参数说明
运行示例
这比所有项目套一个 Word 模板要合理很多。
7. 最后再做一次一致性检查
材料生成完成，并不代表任务结束。
Copyright Forge 还会继续检查：
软件名称是否统一
版本号是否统一
功能是否有代码依据
Profile 是否存在未确认字段
材料是否包含潜在敏感信息
源程序清单是否正常
最终输出是否存在阻塞项
并给出类似这样的状态：
DRAFT
NEEDS_CONFIRMATION
VALIDATED
READY
尤其是开发方式、权利人、完成日期、发表状态等信息，本来就不应该让 AI 自己猜。
这些事实需要申请人确认。
一个完整流程大概是什么样？
可以把整个 Copyright Forge 理解成下面这条流水线：
真实软件项目
↓
扫描项目结构
↓
识别技术栈
↓
建立功能证据映射
↓
建立 software-profile.yaml
↓
人工确认关键事实
↓
生成软件说明材料
↓
整理源程序材料
↓
检测敏感信息
↓
生成申请信息填报参考
↓
一致性校验
↓
输出最终材料
我真正想做的，其实不是单独解决“写一篇软著说明书”这个问题。
而是尝试把：
软件项目 → 软件著作权材料
这一整个过程变成一个标准化的 Agent Workflow。
怎么使用？
项目中的辅助脚本需要：
Python 3.10+
并且只使用 Python 标准库。
可以先设置 Skill 和输出目录：
SKILL=skills/copyright-forge
OUT=/tmp/copyright-forge-output
扫描项目：
python3 "$SKILL/scripts/scan_project.py" \
/path/to/project \
--output "$OUT/project-scan.json"
建立代码证据：
python3 "$SKILL/scripts/build_evidence_map.py" \
/path/to/project \
--output "$OUT/evidence-map.json"
整理源程序清单：
python3 "$SKILL/scripts/collect_source.py" \
/path/to/project \
--output "$OUT/source-manifest.json"
然后根据模板建立：
software-profile.yaml
确认需要申请人确认的信息以后，再继续进行材料生成和校验。
有些事情，我故意没有让 AI 自动做
做这个 Skill 的时候，我给它设置了一些明确的边界。
例如：
不能虚构软件功能。
不能虚构源代码。
不能虚构软件权利归属。
不能擅自确定合作开发、委托开发等法律关系。
不能把 Git Commit 时间直接当成软件完成日期。
不能伪造软件截图。
不能修改官方申请表然后假装这是正式文件。
不能承诺“使用这个 Skill 就一定可以通过软著登记”。
这些限制看起来让 AI “没那么万能”，但我反而觉得这是专业 Agent Skill 非常重要的一部分。
一个真正能进入工作流的 Agent，不应该只是知道：
自己能做什么。
它还必须知道：
什么事情不能替用户做决定。
为什么我越来越看好 Skill？
我最近越来越明显地感觉到，AI Coding Agent 下一阶段的竞争，不一定只是：
谁的模型参数更多
谁写代码更强
谁 Benchmark 更高
还有一个非常重要的方向：
专业工作流。
过去我们使用 AI 的方式是：
人
↓
Prompt
↓
LLM
↓
答案
现在越来越像：
人
↓
Agent
↓
Skill
↓
规则 + 知识 + 脚本 + 工具
↓
真实项目
↓
结果
Copyright Forge 就是我对这个方向的一次尝试。
把过去需要人工整理的大量规则和经验，逐步沉淀成一个可以复用、迭代和开源的 Skill。
以后不只是软著。
很多相对标准化的专业工作，其实都可以这么做。
最后
Copyright Forge 目前还是一个比较早期的版本，我也会继续补充实际使用过程中遇到的问题。
如果你本身是：
独立开发者
程序员
软件公司
外包团队
AI Coding 用户
经常需要申请软件著作权的人
可以拿自己的真实项目试一下。
如果你发现某种项目结构无法识别、某类软著材料处理得不够好，或者对 Skill 的工作流有更好的想法，也欢迎提 Issue 或 PR。
我觉得 AI Agent 真正有价值的方向之一，就是把那些重复、繁琐，但是又有明确规则的专业工作逐渐自动化。
而软件著作权材料整理，恰好就是这样一个场景。
项目名称：Copyright Forge Skill
GitHub：
浙公网安备 33010602011771号