申请软件著作权，真正让开发者头疼的，往往不是写代码，而是整理材料。
软件叫什么名字？有哪些核心功能？说明书应该怎么写？哪些代码适合作为源程序材料？文档中描述的功能，能不能在项目里找到对应实现？
如果完全依靠人工处理，不仅耗时，而且很容易出现一个问题：说明书、源代码和申请信息互相对不上。
最近我开源了一个专门解决这个问题的 Agent Skill：
Copyright Forge Skill
项目地址：
https://github.com/Rodert/copyright-forge-skill
它可以配合 Codex、Claude Code、OpenCode 等编程 Agent 使用。你只需要在真实项目中说一句：
帮我给当前项目做一套软著材料。
Agent 就会自动分析项目结构、技术栈、页面、接口和核心代码，在真实代码证据的基础上整理软件著作权材料。
它不是一个简单的“软著模板生成器”，而是一套尽可能避免 AI 胡编的材料生成流程。
一、传统 AI 生成软著材料有什么问题？
很多人会直接把项目名称发给 AI：
帮我给“智能客户管理系统”写一份软件著作权说明书。
AI 很快就能生成十几项功能：
- 客户管理
- 合同管理
- 财务管理
- 数据大屏
- 权限管理
- 消息通知
- 智能分析
- 自动生成报表
看起来很完整，但项目里可能根本没有这些功能。
这会造成三个问题。
1. 功能描述和真实代码对不上
说明书写了“智能数据分析”，代码里却找不到对应接口、页面或算法。
2. 不同材料中的信息不一致
申请信息里写的是“客户关系管理系统 V1.0”，说明书里可能变成“智能客户管理平台”，源程序页眉中又使用了另一个名称。
3. AI 容易替用户猜测事实
比如：
- 著作权人是谁
- 软件完成日期是什么时候
- 是否已经公开发表
- 是独立开发还是合作开发
这些信息无法单纯从代码中判断，AI 不应该自行编造。
Copyright Forge 的设计目标，就是解决这些问题。
二、Copyright Forge 是怎么工作的？
这个项目的核心思路可以概括为一条流水线：
真实项目
↓
扫描项目结构
↓
建立功能证据
↓
生成功能关系
↓
确认无法判断的事实
↓
锁定统一事实源
↓
生成软著材料
↓
独立质量检查
它会优先分析：
- README 和项目文档
- 依赖配置
- 后端路由
- Controller、Service、Repository
- 前端页面和菜单
- 数据模型
- 项目配置
- 第一方核心源代码
然后把识别到的功能和代码位置建立对应关系。
例如，假设项目中存在下面的 Go 接口：
package handler
import (
"net/http"
"github.com/gin-gonic/gin"
"gorm.io/gorm"
)
type User struct {
ID uint `json:"id"`
Username string `json:"username"`
Status int `json:"status"`
}
type UserHandler struct {
DB *gorm.DB
}
func (h *UserHandler) ListUsers(c *gin.Context) {
var users []User
if err := h.DB.
Where("status = ?", 1).
Order("id DESC").
Find(&users).Error; err != nil {
c.JSON(http.StatusInternalServerError, gin.H{
"message": "查询用户失败",
})
return
}
c.JSON(http.StatusOK, gin.H{
"data": users,
})
}
同时，路由中注册了用户查询接口：
func RegisterUserRoutes(router *gin.RouterGroup, handler *UserHandler) {
userGroup := router.Group("/users")
{
userGroup.GET("", handler.ListUsers)
}
}
前端还存在用户管理页面：
<script setup lang="ts">
import { onMounted, ref } from 'vue'
import { getUserList } from '@/api/user'
interface User {
id: number
username: string
status: number
}
const users = ref<User[]>([])
async function loadUsers() {
const response = await getUserList()
users.value = response.data
}
onMounted(loadUsers)
</script>
<template>
<div class="user-page">
<h2>用户管理</h2>
<table>
<thead>
<tr>
<th>用户编号</th>
<th>用户名</th>
<th>状态</th>
</tr>
</thead>
<tbody>
<tr v-for="user in users" :key="user.id">
<td>{
{ user.id }}</td>
<td>{
{ user.username }}</td>
<td>{
{ user.status === 1 ? '正常' : '停用' }}</td>
</tr>
</tbody>
</table>
</div>
</template>
Copyright Forge 可以据此建立类似下面的功能证据：
{
"feature_id": "USER_MANAGEMENT",
"feature_name": "用户管理",
"description": "系统支持查询并展示正常状态的用户信息。",
"evidence": [
{
"type": "backend_handler",
"path": "internal/handler/user.go",
"symbol": "ListUsers"
},
{
"type": "backend_route",
"path": "internal/router/user.go",
"route": "GET /users"
},
{
"type": "frontend_page",
"path": "src/views/user/index.vue"
}
]
}
这意味着“用户管理”并不是根据项目名称猜出来的，而是可以回到真实项目中验证。
三、先扫描代码，再向用户提问
Copyright Forge 有一个很重要的设计原则：
不要一上来就让用户填写一大堆申请字段。
它会先分析项目，把能够从代码中确定的信息尽量找出来，例如：
- 使用了什么编程语言
- 前端和后端采用什么框架
- 软件采用什么架构
- 有哪些页面
- 有哪些接口
- 包含哪些核心模块
- 哪些代码属于第一方代码
- 哪些目录是依赖、构建产物或压缩文件
只有下面这些无法从代码中可靠判断的信息，才会集中向用户确认：
1. 软件最终登记名称是什么？
2. 当前版本号是什么？
3. 著作权人是个人还是企业？
4. 软件属于独立开发、合作开发还是委托开发？
5. 软件的真实开发完成日期是什么？
6. 软件是否已经公开发表？
7. 如果已经发表，首次发表日期是什么？
比如可以这样回答：
软件名称：轻量级任务协作管理系统
软件简称：FlowTask
版本号：V1.0
著作权人：某某科技有限公司
开发方式：独立开发
开发完成日期：2026 年 8 月 10 日
是否发表：未发表
这些事实确认后，会被写入统一的软件档案。
四、用统一事实源解决材料不一致
Copyright Forge 使用 software-profile.yaml 保存已经确定的软件事实。
示例：
software:
full_name: 轻量级任务协作管理系统
short_name: FlowTask
version: V1.0
category: Web 应用软件
ownership:
owner_type: company
owner_name: 某某科技有限公司
development_mode: independent
dates:
completion_date: "2026-08-10"
published: false
publication_date: null
technology:
frontend:
- Vue 3
- TypeScript
- Vite
backend:
- Python
- FastAPI
database:
- SQLite
approved_features:
- TASK_MANAGEMENT
- PROJECT_MANAGEMENT
- STATUS_TRACKING
- DATA_STATISTICS
后续的说明书、源程序材料和申请信息指引，都从这份统一档案读取信息。
这样可以避免：
申请信息：FlowTask 任务管理系统 V1.0
说明书：智能项目协作平台 V1.0
源程序：企业任务系统 V2.0
统一事实源的意义不是让文档更漂亮，而是让所有材料在软件名称、版本、功能和技术描述上保持一致。
五、它能生成哪些材料？
完成项目分析和事实确认后，Skill 可以继续整理：
- 软件说明书
- 源程序鉴别材料
- 软件申请信息填写指引
- 功能证据清单
- 软件事实档案
- 用户确认记录
- 工作流状态
- 独立质量审核报告
- HTML、DOCX 或 PDF 等可交付文件
其中源程序材料会优先选择第一方核心代码，并排除常见的无效内容，例如：
node_modules/
vendor/
dist/
build/
target/
*.min.js
package-lock.json
pnpm-lock.yaml
二进制文件
自动生成文件
第三方依赖代码
它还会对材料进行分页和敏感信息检查，尽量避免把下面这些内容直接带入输出：
DB_PASSWORD=123456
JWT_SECRET=my-secret
OPENAI_API_KEY=sk-xxxx
REDIS_PASSWORD=xxxx
当然，自动脱敏不能代替人工检查。正式提交前，仍然应该再核对一次密码、Token、内部地址、个人信息和商业机密。
六、在 Codex 中安装
Copyright Forge 的辅助脚本要求 Python 3.10 及以上版本；如果需要进行 PDF 渲染，运行环境还需要提供 reportlab。
在终端中执行：
CF_SKILL_HOME="${CODEX_HOME:-$HOME/.codex}"
mkdir -p "$CF_SKILL_HOME"
git clone --depth 1 \
https://github.com/Rodert/copyright-forge-skill.git \
"$CF_SKILL_HOME/copyright-forge-repo"
mkdir -p "$CF_SKILL_HOME/skills"
ln -s \
../copyright-forge-repo/skills/copyright-forge \
"$CF_SKILL_HOME/skills/copyright-forge"
安装完成后，重新启动 Codex 会话。
进入需要申请软著的项目目录：
cd ~/projects/flowtask
codex
然后直接输入：
帮我给当前项目做一套软著材料。
也可以显式调用 Skill：
$copyright-forge
请分析当前项目，并生成一套软件著作权材料。
先扫描代码并建立功能证据，不要根据项目名称编造功能。
所有无法从代码中判断的权属、日期和发表信息，请集中向我确认。
七、一个更完整的使用示例
假设我们有一个前后端分离的任务管理项目：
flowtask/
├── backend/
│ ├── app/
│ │ ├── api/
│ │ ├── models/
│ │ ├── schemas/
│ │ └── services/
│ ├── requirements.txt
│ └── main.py
├── frontend/
│ ├── src/
│ │ ├── api/
│ │ ├── views/
│ │ ├── stores/
│ │ └── router/
│ └── package.json
└── README.md
进入项目目录以后提出需求：
帮我给这个项目做软著。
要求：
1. 只根据当前项目里的真实代码整理功能；
2. 不要修改原项目；
3. 所有材料输出到项目目录之外；
4. 无法判断的信息统一问我；
5. 生成完成后检查软件名称、版本和功能是否一致；
6. 检查源程序中是否存在密码、Token 和个人隐私。
Agent 扫描后，可能给出类似结果：
已经完成项目初步分析。
识别到的项目类型：
- 前后端分离 Web 应用
主要技术：
- 前端：Vue 3、TypeScript、Vite、Pinia
- 后端：FastAPI、SQLAlchemy
- 数据库：SQLite
识别到的主要功能：
- 用户登录
- 项目管理
- 任务创建与编辑
- 任务状态流转
- 任务筛选
- 数据统计
以上功能均找到了对应的页面、接口、模型或业务代码证据。
目前还需要确认：
1. 软件登记名称；
2. 软件版本号；
3. 著作权人；
4. 开发方式；
5. 开发完成日期；
6. 是否已经发表。
完成确认后，它会锁定事实并继续生成材料。
如果任务中途停止，下次可以直接说：
继续完成刚才的软著材料。
项目会根据 workflow-state.json 恢复工作流，同时检查代码和已经锁定的事实是否发生变化，避免继续使用过期证据。
八、不只适用于 Java 项目
Copyright Forge 当前可以自动识别多种常见项目结构，包括：
- Go
- Java 与 Spring
- Python、Django、Flask、FastAPI
- Node.js、Express、NestJS
- Next.js、Nuxt
- Vue、React
- PHP、Laravel
- .NET
- Flutter
- 常见小程序项目
即使项目结构暂时没有被适配器识别，也可以通过手动提供项目档案和源程序清单继续分析。
例如，一个 Go 项目可能是：
server/
├── cmd/
├── internal/
│ ├── handler/
│ ├── service/
│ ├── repository/
│ └── model/
├── pkg/
├── configs/
├── go.mod
└── README.md
一个 Spring Boot 项目可能是：
src/main/java/com/example/system/
├── controller/
├── service/
├── mapper/
├── entity/
├── config/
└── Application.java
不同技术栈的扫描方式可以不同，但最后都使用统一的证据结构、事实档案和质量检查流程。
九、八道质量门，比“生成一份文档”更重要
这个项目不是生成完文件就结束。
它还会从多个维度进行独立审核，主要覆盖：
- 事实是否完整；
- 功能是否有代码证据；
- 不同材料是否一致；
- 源程序选择是否合理；
- 说明书结构是否完整；
- 是否存在隐私和敏感信息；
- 是否出现无依据的 AI 幻觉；
- 提交前是否仍有未解决问题。
工作流状态包括：
ANALYZING
WAITING_FOR_CONFIRMATION
FACTS_LOCKED
GENERATING
REVIEWING
NEEDS_FIX
READY
只有完成材料生成并通过检查后，状态才会进入：
READY
如果检查发现问题，则会进入：
NEEDS_FIX
对于能够自动修正的问题，Agent 可以先完成修正；对于权属、日期等无法自动判断的事实问题，则必须重新向用户确认。
十、这个项目最适合哪些人？
我认为它尤其适合下面几类开发者：
- 有真实软件项目，需要整理软著材料；
- 经常开发外包项目，需要重复准备材料；
- 独立开发者或小团队，希望减少文档整理时间；
- 不熟悉软著材料结构，但熟悉自己的项目；
- 想使用 Codex、Claude Code 或 OpenCode 自动处理重复工作；
- 担心 AI 编造功能，希望材料能够追溯到代码。
它最有价值的地方，不是“让 AI 帮你写一篇说明书”，而是把软著材料整理变成了一套相对严谨的工程流程：
代码证据 + 用户确认 + 统一事实 + 材料生成 + 独立复查
十一、必须注意的边界
Copyright Forge 是材料辅助工具，不是登记机构，也不能替代必要的人工审核。
使用时需要注意：
- 它不会代替你提交登记申请；
- 不会伪造官方申请表；
- 不应该编造权属关系和开发日期；
- 不保证登记一定通过；
- 合作开发、委托开发、权利受让等情况需要额外核对相关证明；
- 正式提交前应人工检查生成材料；
- 涉及最新登记要求时，应以主管机构当前公开规则为准。
尤其是企业项目，不要未经检查就把完整源码直接交给任何第三方服务。
总结
过去，我们使用 AI 生成软著材料，通常是：
输入一个项目名称
↓
AI 猜测软件功能
↓
生成一套看似完整的文档
Copyright Forge 想做的是另一种方式：
读取真实项目
↓
建立功能与代码证据
↓
确认不能从代码判断的事实
↓
锁定统一软件档案
↓
生成说明书和源程序材料
↓
完成独立质量审核
从“让 AI 帮我编一份材料”，转变为“让 Agent 基于真实项目整理材料”。
如果你正在使用 Codex、Claude Code 或 OpenCode，并且手里正好有需要申请软件著作权的项目，可以尝试一下。
项目地址：
https://github.com/Rodert/copyright-forge-skill
在线演示：
https://rodert.github.io/copyright-forge-skill/demo/flowtask/
打开项目，对 Agent 说一句：
帮我给当前项目做一套软著材料。
剩下的事情，就让它先从代码开始。
