写软著 - Copyright Forge Skill 完整闭环改造方案

项目：https://github.com/Rodert/copyright-forge-skill

改造目标：从"证据驱动的软著 Agent Skill"升级为"证据驱动的软著材料交付系统"。

一、最终目标

text 复制代码

读取项目
→
分析功能
→
写一篇说明书

而应该完成：

text 复制代码

真实软件项目
↓
项目扫描
↓
项目类型识别
↓
功能发现
↓
功能证据验证
↓
申请场景判断
↓
申请人事实确认
↓
事实锁定
↓
说明书生成
↓
源程序材料生成
↓
申请信息填写指引
↓
敏感信息检查
↓
规则校验
↓
材料一致性检查
↓
独立 Reviewer
↓
最终交付包
↓
READY

用户最终的使用动作仍然应该只有一句：

text 复制代码

帮我给这个项目做一套软著材料。

然后 Agent 自己完成绝大部分工作。

二、这个项目应该保证什么

这个项目永远不要宣传或者设计成：

保证软著登记通过。

不虚构项目不存在的功能
不虚构源码
不猜测著作权归属
不猜测真实开发完成日期
不把 Git 时间当法律事实
材料中的核心信息保持一致
说明书中的主要功能都有项目证据
源码材料来自真实项目
原项目永远只读
发现敏感信息必须处理或阻止交付
关键材料缺失时不能进入 READY
复杂权属场景必须提示人工复核

这才是这个 Skill 的"专业性"。

目前仓库已经建立了 Evidence Map、software-profile.yaml、事实锁定以及 Reviewer Gate 的设计，这个方向应该保留。

三、当前版本最需要先解决的问题

1. SKILL.md 描述的流程和实际脚本没有完全对应

这是当前必须优先修复的问题。

最新 SKILL.md 已经要求调用：

text 复制代码

manage_task.py
review_materials.py

但当前 scripts/ 目录实际列出的脚本只有：

text 复制代码

build_evidence_map.py
collect_source.py
common.py
detect_secrets.py
scan_project.py
validate_consistency.py
validate_output.py
validate_profile.py

也就是说：

Skill 描述的闭环已经存在，但代码实现还没有完全跟上。

这个问题必须作为 P0 修复，否则 Agent 真正运行时会直接断链。

2. 当前源码处理只做到 Manifest，没有最终材料

当前 05-source-code-rules.md 自己明确说明：

collector 输出的是 manifest，而不是最终格式化后的源码材料。

这意味着：

text 复制代码

项目源码
↓
source-manifest.json

现在就停了。

但用户真正需要的是：

text 复制代码

项目源码
↓
源码选择
↓
排序
↓
脱敏
↓
分页
↓
页眉
↓
行数检查
↓
PDF

所以这个链路必须补齐。

3. 输出规则还是"建议"，没有形成 Delivery Contract

当前 Output Rules 使用的是：

Suggested contents

也就是"建议输出这些东西"。

这对专业工具不够。

应该改成：

READY 状态必须满足的交付合同。

缺一项就不能 READY。

四、第一优先级：重新定义最终交付物

建议统一输出：

text 复制代码

copyright-forge-output/
│
├── 01-申请信息填写指引.md
├── 02-软件说明书.pdf
├── 02-软件说明书.docx
├── 03-源程序鉴别材料.pdf
├── 04-提交前检查报告.md
├── 05-待确认事项.md
│
└── internal/
    ├── software-profile.yaml
    ├── project-analysis.json
    ├── evidence-map.json
    ├── source-manifest.json
    ├── source-selection.json
    ├── user-confirmations.json
    ├── security-report.json
    ├── consistency-report.json
    ├── rules-report.json
    ├── review-report.json
    ├── final-validation.json
    └── workflow-state.json

这里要明确分成两层。

用户层

普通用户只关心：

text 复制代码

01-申请信息填写指引
02-软件说明书
03-源程序材料
04-提交前检查报告
05-待确认事项

不要让用户研究内部 JSON。

Internal 层

这些是 Agent 和脚本用的：

text 复制代码

software-profile.yaml
evidence-map.json
workflow-state.json
rules-report.json
review-report.json
......

普通用户不需要理解。

五、重新定义 READY

目前的 READY 不能只代表：

没发现明显 blocker。

应该改成：

text 复制代码

READY =
事实全部确认
+
必要材料全部生成
+
源码材料生成完成
+
文档规则校验完成
+
一致性校验完成
+
安全检查完成
+
Reviewer Gate 通过
+
没有 Blocker

只要下面任何一项成立：

text 复制代码

缺少著作权人
缺少真实完成日期
申请场景不明确
说明书存在无证据功能
源码存在未处理 Secret
源码材料没有生成
说明书没有生成
版本号不一致
申请主体前后不一致
规则存在 Blocker

都：

text 复制代码

READY = false

六、完整状态机

现在状态设计方向是对的，但建议进一步明确状态转换。

text 复制代码

INIT
↓
ANALYZING
↓
WAITING_FOR_CONFIRMATION
↓
FACTS_LOCKED
↓
GENERATING
↓
REVIEWING
↓
READY

异常路线：

text 复制代码

ANALYZING
↓
UNSUPPORTED_SCENARIO

或者：

text 复制代码

REVIEWING
↓
NEEDS_FIX
↓
GENERATING
↓
REVIEWING

或者：

text 复制代码

WAITING_FOR_CONFIRMATION
↓
等待用户
↓
继续任务

推荐最终状态：

text 复制代码

INIT
ANALYZING
WAITING_FOR_CONFIRMATION
FACTS_LOCKED
GENERATING
REVIEWING
NEEDS_FIX
NEEDS_HUMAN_REVIEW
READY

其中：

NEEDS_HUMAN_REVIEW

专门用于：

text 复制代码

合作开发
委托开发
受让
继承
修改他人软件
复杂职务开发
例外交存
著作权归属存在冲突

不要把这种情况继续自动跑下去。

七、实现真正的 Task Manager

新增：

text 复制代码

scripts/manage_task.py

至少支持：

bash 复制代码

manage_task.py init
manage_task.py status
manage_task.py transition
manage_task.py lock
manage_task.py invalidate
manage_task.py resume

workflow-state.json 推荐：

json 复制代码

{
  "task_id": "CF-20260829-001",
  "project_path": "/xxx/project",
  "project_fingerprint": "...",
  "state": "WAITING_FOR_CONFIRMATION",
  "created_at": "...",
  "updated_at": "...",
  "locked_profile_fingerprint": null,
  "completed_steps": [
    "project_scan",
    "evidence_map"
  ],
  "pending_steps": [
    "user_confirmation",
    "materials_generation"
  ],
  "blockers": []
}

重点是：

Agent 重开以后必须真的能够继续，而不是依靠聊天上下文"记得"。

八、升级 software-profile.yaml

继续保留它作为整个系统的 Single Source of Truth。

建议变成：

yaml 复制代码

software:
  full_name:
    value: ""
    source: project
    confidence: 0.85
    confirmed: false

  short_name:
    value: ""
    source: agent_recommendation
    confidence: 0.7
    confirmed: false

  version:
    value: ""
    source: package_metadata
    confidence: 0.9
    confirmed: false

applicant:
  name:
    value: ""
    source: user
    confirmed: false

rights:
  development_type:
    value: ""
    source: user
    confirmed: false

  acquisition_type:
    value: ""
    source: user
    confirmed: false

dates:
  completion_date:
    value: ""
    source: user
    confirmed: false

publication:
  status:
    value: ""
    source: user
    confirmed: false

features:
  - id: FEATURE-001
    name: 用户登录
    evidence_ids:
      - EV-001
      - EV-002
    approved: true

每个重要事实必须带：

text 复制代码

value
source
confidence
confirmed

九、建立"事实类型"体系

把所有信息分成三类。

A. PROJECT_FACT

Agent 可以从项目确定：

text 复制代码

语言
框架
数据库
路由
API
页面
项目结构
实际存在的功能
依赖

Agent 自己处理，不要问用户。

B. RECOMMENDED_FACT

Agent 可以提出建议，但用户需要确认：

text 复制代码

软件名称
软件简称
版本号
软件用途描述

例如：

text 复制代码

我根据 README 和项目名称建议：

软件名称：XX智能管理系统
版本：V1.0

是否采用？

C. HUMAN_FACT

只能由人提供：

text 复制代码

著作权人
申请主体
独立开发 / 合作开发
委托关系
权利取得方式
真实开发完成日期
是否已经发表
首次发表日期
真实权利关系

Agent 严禁推测。

十、建立真正的规则引擎

这是项目专业化的核心。

不要只让：

text 复制代码

references/01-official-rules.md

承担规则。

建议新增：

text 复制代码

rules/
├── official/
│   ├── material.yaml
│   ├── source-code.yaml
│   ├── document.yaml
│   └── ownership.yaml
│
├── guidance/
│   ├── formatting.yaml
│   └── practical.yaml
│
└── best-practices/
    ├── consistency.yaml
    └── evidence.yaml

十一、每条规则都必须结构化

例如：

yaml 复制代码

id: CN-SCR-CODE-001

name: 普通交存源程序页数

category: source_code

authority_level: official

severity: blocker

scenario:
  - ordinary_deposit

condition:
  total_pages: ">60"

requirement:
  first_pages: 30
  last_pages: 30
  continuous: true

source:
  organization: 国家版权局
  document: 计算机软件著作权登记办法
  article: 第十条
  verified_at: 2026-08-29

这样才能让：

text 复制代码

validate_rules.py

真正执行规则。

十二、官方规则和"经验规则"必须彻底分开

这是非常重要的一点。

当前仓库的 01-official-rules.md 中已经有这种意识，但还应该强化。

规则必须明确分级：

text 复制代码

OFFICIAL
OFFICIAL_GUIDANCE
BEST_PRACTICE
PROJECT_POLICY

例如：

OFFICIAL

国家版权局《计算机软件著作权登记办法》第十条明确规定：

源程序和文档原则上取前、后各连续 30 页；不足 60 页提交全部；除特定情况外，程序每页不少于 50 行，文档每页不少于 30 行。

这可以成为硬规则。

而类似：

text 复制代码

页眉格式
字体
页边距
推荐命名习惯
排版习惯

如果不是当前官方规范明确要求，就不要写：

text 复制代码

Official / Blocker

而应该明确：

text 复制代码

GUIDANCE

或者：

text 复制代码

BEST_PRACTICE

否则项目以后很容易出现：

把行业习惯包装成法律要求。

十三、规则必须保存来源

每条正式规则必须保存：

text 复制代码

机构
文件名称
条款
URL
最后验证日期
规则版本

例如：

yaml 复制代码

source:
  organization: 国家版权局
  title: 计算机软件著作权登记办法
  article: 第十条
  url: ...
  verified_at: 2026-08-29

另外建立：

text 复制代码

rules/rules-version.json

例如：

json 复制代码

{
  "rules_version": "2026.08",
  "verified_at": "2026-08-29"
}

十四、不要每天因为 GitHub 更新失败就停止软著任务

当前 SKILL.md 有一个比较重的设计：

每天第一次执行必须检查远端 Skill 更新，如果更新检查失败，就不开始材料准备。

我建议修改。

网络失败不应该导致：

text 复制代码

整个 Skill 不可用

应该变成：

text 复制代码

本地规则版本存在
↓
正常运行

远端检查成功
↓
提示有新版本

远端检查失败
↓
WARNING
↓
继续运行本地稳定版本

只有：

text 复制代码

本地规则库缺失
本地 Skill 文件损坏
规则版本不完整

才应该停止。

否则：

GitHub 暂时访问不了，用户连软著都做不了。

体验不好。

十五、真正实现源码选择系统

现在的：

text 复制代码

collect_source.py

不要只负责"找到代码"。

建议拆成：

text 复制代码

collect_source.py
rank_source.py
select_source.py
redact_source.py
render_source.py
validate_source.py

流程：

text 复制代码

扫描所有第一方源码
↓
过滤依赖和构建产物
↓
建立源码候选池
↓
根据 Evidence Map 打分
↓
优先选择核心业务模块
↓
生成连续源码序列
↓
安全扫描
↓
必要脱敏
↓
分页
↓
生成最终 PDF
↓
验证

十六、源码不能简单"选够页数"

这是一个特别重要的设计。

假设说明书包含：

text 复制代码

用户管理
订单管理
支付管理
商品管理

源码材料最好也覆盖：

text 复制代码

auth
user
order
payment
product

所以每个源码文件都可以计算：

text 复制代码

business_score
evidence_score
core_score
risk_score

例如：

text 复制代码

OrderService.go          95
PaymentController.go     93
UserService.go           91
main.go                  70
config.go                40
utils.go                 20

优先选择：

能证明核心功能真实存在的代码。

十七、source-selection.json

新增：

json 复制代码

{
  "selected_files": [
    {
      "path": "internal/order/service.go",
      "reason": "supports FEATURE-ORDER-001",
      "evidence_ids": [
        "EV-001"
      ],
      "priority": 95
    }
  ],
  "feature_coverage": {
    "FEATURE-001": true,
    "FEATURE-002": true,
    "FEATURE-003": false
  }
}

如果核心 Feature Coverage 太低：

text 复制代码

WARNING

甚至：

text 复制代码

BLOCKER

十八、最终源码材料生成器

新增：

text 复制代码

scripts/render_source.py

输入：

text 复制代码

software-profile.yaml
source-selection.json
redacted-source/
rules/

输出：

text 复制代码

03-源程序鉴别材料.pdf

要能够控制：

text 复制代码

页数
每页代码行数
页码
软件名称
版本号
文件顺序
连续性
末页处理

具体格式必须由规则库决定，不应该把数字散落写死在 Python 代码里。

十九、说明书生成也要工程化

不要让 Agent 自由写完整说明书。

建议：

text 复制代码

document-plan.json
↓
模板
↓
Agent 写内容
↓
render_document.py
↓
PDF/DOCX

先生成：

json 复制代码

{
  "document_type": "user_manual",
  "sections": [
    "软件概述",
    "运行环境",
    "系统架构",
    "用户登录",
    "用户管理",
    "订单管理"
  ]
}

每一个功能章节必须带：

text 复制代码

feature_id
evidence_ids

这样 Reviewer 才能机械检查。

二十、根据项目类型选择说明书

当前这个方向已经存在，应该保留。

例如：

Web / App

text 复制代码

用户操作说明书

重点：

text 复制代码

界面
功能
操作流程

API / 后端服务

text 复制代码

软件功能说明书

重点：

text 复制代码

架构
接口
模块
处理流程

SDK

text 复制代码

软件设计 / 使用说明书

CLI

text 复制代码

命令行软件操作说明书

不要所有软件都强制套一个 UI 用户手册。

二十一、截图必须有证据来源

继续坚持现在的规则：

text 复制代码

用户提供
项目已有
真实运行环境截图

不得：

text 复制代码

AI 生成一个漂亮后台截图

然后假装是项目界面。

新增：

text 复制代码

screenshot-manifest.json

记录：

json 复制代码

{
  "file": "login.png",
  "source": "project_docs",
  "feature_id": "FEATURE-LOGIN",
  "verified": true
}

二十二、建立 Evidence Graph，而不只是 Evidence Map

现在 Evidence Map 是一个很好的开始。

后面可以升级为：

text 复制代码

Feature
↓
Route
↓
Controller
↓
Service
↓
Model
↓
Database
↓
UI

例如：

text 复制代码

FEATURE-ORDER-001
订单创建
│
├── UI
│   └── src/pages/order/create.vue
│
├── API
│   └── POST /api/orders
│
├── Controller
│   └── OrderController.Create
│
├── Service
│   └── OrderService.CreateOrder
│
└── Model
    └── Order

然后输出：

text 复制代码

evidence-confidence: 0.96

二十三、功能必须设置证据阈值

例如：

text 复制代码

0.90 - 1.00   CONFIRMED
0.70 - 0.89   STRONG
0.50 - 0.69   WEAK
<0.50         UNSUPPORTED

正式说明书中的核心功能最低：

text 复制代码

>= 0.70

低于阈值：

text 复制代码

不得写入正式材料

Agent 可以继续搜索证据，但不能靠语言润色把弱证据变成强证据。

二十四、建立申请场景判断器

新增：

text 复制代码

scripts/classify_scenario.py

场景：

text 复制代码

ordinary_independent
joint_development
commissioned_development
assignment
inheritance
modified_existing_software
exception_deposit
unknown

第一阶段最适合完整支持：

text 复制代码

ordinary_independent

其他场景：

text 复制代码

识别
↓
告诉用户
↓
列出需要补充的材料
↓
NEEDS_HUMAN_REVIEW

不要为了"全自动"把复杂法律问题硬做掉。

二十五、申请信息填写指引必须成为标准交付物

生成：

text 复制代码

01-申请信息填写指引.md

例如：

markdown 复制代码

# 软件基本信息

软件全称：XX智能管理系统
软件简称：XX系统
版本号：V1.0

# 开发信息

开发方式：独立开发
开发完成日期：2026-08-10

# 著作权人

王XX

# 软件功能简介

......

# 需要您在官方平台填写的信息

......

注意：

不生成、修改或者冒充官方申请表。

国家版权局《计算机软件著作权登记办法》第九条规定，登记申请需要申请表、软件鉴别材料和相关证明文件。

text 复制代码

准备填写内容

而不是：

text 复制代码

伪造官方表单

二十六、建立真正的 Consistency Engine

新增：

text 复制代码

scripts/validate_consistency.py

它不只是让 LLM 看一遍。

应该机械比较：

text 复制代码

software.full_name
software.short_name
version
applicant
completion_date
publication
feature_names

这些值在：

text 复制代码

说明书
源码页眉
填写指引
Profile
最终报告

里是否一致。

二十七、一致性检查报告

例如：

text 复制代码

软件名称          PASS
软件简称          PASS
版本号            PASS
著作权人          PASS
开发完成日期      PASS
发表状态          PASS
功能名称          PASS
源码功能覆盖      PASS
敏感信息          PASS

出现：

text 复制代码

XX管理系统 V1.0

和：

text 复制代码

XX管理平台 1.0

直接：

text 复制代码

BLOCKER

二十八、安全检查必须发生两次

建议：

第一次

源码选择完成后：

text 复制代码

detect_secrets.py

第二次

最终 PDF / 文档生成前：

text 复制代码

scan_generated_materials.py

因为有时候 Secret 不一定来自代码。

还可能来自：

text 复制代码

README
截图
配置说明
示例请求
数据库连接字符串
API 示例

二十九、敏感信息分级

例如：

text 复制代码

BLOCKER

包含：

text 复制代码

API Key
Access Token
Private Key
真实密码
数据库密码
Cookie
Secret

text 复制代码

WARNING

包含：

text 复制代码

内网 IP
真实域名
邮箱
手机号
内部服务名称

具体是否允许，需要用户确认。

三十、建立独立 Reviewer

新增实际存在的：

text 复制代码

scripts/review_materials.py

但 Reviewer 最好采用：

text 复制代码

规则检查
+
机械一致性检查
+
LLM 语义 Review

三层。

三十一、Reviewer 重点检查什么

事实

text 复制代码

名称一致吗？
版本一致吗？
日期一致吗？
申请主体一致吗？

证据

text 复制代码

每个核心功能有 evidence 吗？

源码

text 复制代码

代码真实吗？
来源真实吗？
覆盖主要功能吗？
页数规则满足吗？

文档

text 复制代码

说明书有没有写项目不存在的模块？

安全

text 复制代码

有没有 Secret？

完整度

text 复制代码

必需文件齐了吗？

三十二、Reviewer 发现问题后的处理规则

不要直接问用户。

先判断：

text 复制代码

Agent 自己能修吗？

比如：

text 复制代码

软件名称不一致

→ 自动根据 Profile 修。

text 复制代码

说明书写了一个没有证据的功能

→ 再搜索一次证据。

找不到：

text 复制代码

删除该功能

只有：

text 复制代码

真实完成日期不知道

才问用户。

原则仍然是：

能自己解决的问题，不打扰用户。

三十三、最终 Preflight Report

最终必须生成：

text 复制代码

04-提交前检查报告.md

例如：

markdown 复制代码

# Copyright Forge 提交前检查

## 当前状态

READY

## 材料

- [x] 软件说明书
- [x] 源程序材料
- [x] 申请信息填写指引

## 事实

- [x] 软件名称已确认
- [x] 版本已确认
- [x] 著作权人已确认
- [x] 开发完成日期已确认
- [x] 发表状态已确认

## 证据

主要功能：8
有充分代码证据：8
无证据功能：0

## 源码

源码安全检查：PASS
核心功能覆盖：PASS

## 一致性

材料一致性：PASS

## 注意

本工具用于准备和检查登记材料，不代表登记机构最终审查结果。

用户打开这个文件就知道：

我现在到底准备好了没有。

三十四、重新设计测试体系

现在只有：

text 复制代码

sample-go

远远不够。当前 tests 目录也主要只有 sample-go 和脚本级测试。

建议增加：

text 复制代码

tests/fixtures/
│
├── go-gin-api/
├── java-springboot/
├── python-fastapi/
├── python-django/
├── node-express/
├── vue-admin/
├── react-web/
├── nextjs-fullstack/
├── cli-tool/
├── sdk-project/
├── monorepo/
├── incomplete-project/
├── secret-project/
├── misleading-readme/
└── unsupported-project/

三十五、一定要增加"故意坑人"的测试项目

这个非常重要。

比如：

misleading-readme

README 写：

text 复制代码

支持会员系统

但代码根本没有。

测试：

text 复制代码

AI 不能把会员系统写入说明书。

secret-project

代码：

text 复制代码

OPENAI_API_KEY=sk-xxxx

测试：

text 复制代码

原项目不修改
最终交付材料不出现 Secret

fake-date-project

Git：

text 复制代码

第一次提交：2024-01-01

测试：

text 复制代码

不能自动写：
开发完成日期 = 2024-01-01

inconsistent-version

text 复制代码

package.json = 2.0.0
README = V1.0

测试：

text 复制代码

Agent 必须发现冲突并确认

三十六、建立真正的 End-to-End 测试

最终不要只测：

text 复制代码

scan_project.py 能不能跑

而应该测试：

text 复制代码

用户输入：
帮我给这个项目做软著。

整个链路最后必须得到：

text 复制代码

software-profile.yaml
evidence-map.json
说明书
源码材料
填写指引
检查报告
final-validation.json

然后断言：

text 复制代码

READY == true

三十七、必须增加 Negative Tests

专业工具最重要的其实是：

什么情况下它会拒绝 READY。

例如：

text 复制代码

缺少真实完成日期
→ NOT READY

text 复制代码

存在无证据核心功能
→ NOT READY

text 复制代码

存在 Secret
→ NOT READY

text 复制代码

源码 PDF 没生成
→ NOT READY

text 复制代码

说明书版本号和 Profile 不一致
→ NOT READY

三十八、CI 必须做完整 Smoke Test

GitHub Actions：

text 复制代码

lint
↓
unit test
↓
fixture test
↓
E2E test
↓
negative test
↓
delivery contract test

任何一个失败：

text 复制代码

禁止合并

三十九、增加 Delivery Contract Test

新增：

text 复制代码

test_delivery_contract.py

直接检查 READY 时：

text 复制代码

01-申请信息填写指引.md
02-软件说明书.pdf
03-源程序鉴别材料.pdf
04-提交前检查报告.md
internal/final-validation.json

是不是全部存在。

这条测试非常重要。

因为它防止以后再次出现：

Workflow 写着"已经完成"，实际上根本没有最终材料。

四十、建议调整仓库目录

最终建议：

text 复制代码

skills/copyright-forge/
│
├── SKILL.md
│
├── assets/
│   └── templates/
│
├── references/
│
├── rules/
│   ├── official/
│   ├── guidance/
│   └── best-practices/
│
├── scripts/
│   ├── scan_project.py
│   ├── classify_project.py
│   ├── classify_scenario.py
│   ├── build_evidence_map.py
│   ├── manage_task.py
│   │
│   ├── collect_source.py
│   ├── rank_source.py
│   ├── select_source.py
│   ├── redact_source.py
│   ├── render_source.py
│   ├── validate_source.py
│   │
│   ├── generate_document_plan.py
│   ├── render_document.py
│   │
│   ├── detect_secrets.py
│   ├── validate_profile.py
│   ├── validate_rules.py
│   ├── validate_consistency.py
│   ├── review_materials.py
│   └── validate_output.py
│
└── schemas/
    ├── software-profile.schema.json
    ├── evidence-map.schema.json
    ├── workflow-state.schema.json
    └── review-report.schema.json

四十一、给所有 JSON/YAML 加 Schema

现在这些文件不能只靠约定。

增加：

text 复制代码

JSON Schema

例如：

text 复制代码

evidence-map.schema.json

强制要求：

text 复制代码

feature_id
feature_name
evidence
confidence
status

这样 Agent 即使生成格式错误，也会被 Validator 拦截。

四十二、不要让 LLM 承担所有事情

整个系统应该遵循：

text 复制代码

LLM 擅长：
理解
分析
总结
写文档
判断语义

text 复制代码

Python 擅长：
状态管理
格式验证
一致性比较
规则执行
页数计算
代码选择
文件生成
安全扫描
Schema 校验

不要让：

text 复制代码

LLM 自己记住 30 页 + 30 页

应该：

text 复制代码

规则文件
↓
Python validator

这就是"专业 Agent Skill"和"大 Prompt"的区别。

四十三、用户体验依然保持极简

虽然内部会越来越复杂，但用户侧绝对不要越来越复杂。

用户仍然只需要：

text 复制代码

帮我给这个项目做软著。

Agent 回复应该类似：

text 复制代码

我已经分析完项目。

这是一个 Vue + Go 的后台管理系统，目前确认了 8 个主要功能。

还有 4 件只有你本人能确认的事情：

1. 这个软件最终登记在个人还是公司名下？
2. 这个项目是你独立开发的吗？
3. 实际开发完成日期是哪一天？
4. 这个软件是否已经公开提供给其他人使用？

另外，我建议软件名称为：
XX智能管理系统

版本：
V1.0

你确认后我继续生成材料。

而不是：

text 复制代码

请输入权利取得方式：
请输入开发方式：
请输入发表状态：

四十四、最终用户应该只看到三个阶段

阶段一

text 复制代码

正在分析项目

阶段二

text 复制代码

还有 4 项真实信息需要确认

阶段三

text 复制代码

材料已经准备完成

内部几十个步骤全部隐藏。

四十五、优先级规划

P0：必须马上做

1

补齐当前 SKILL.md 已引用但实际不存在的：

text 复制代码

manage_task.py
review_materials.py

2

建立 Delivery Contract。

3

实现最终源码 PDF 生成。

4

实现最终说明书 PDF / DOCX 生成。

5

重构 READY 判断。

6

增加 End-to-End 测试。

P1：专业化

7

结构化 Rule Engine。

8

Consistency Engine。

9

Scenario Classifier。

10

Source Ranking。

11

Evidence Confidence。

12

Preflight Report。

13

JSON Schema。

P2：扩大覆盖

14

Java fixture。

15

Python fixture。

16

Vue / React fixture。

17

Node fixture。

18

Monorepo。

19

CLI。

20

SDK。

P3：复杂软著场景

最后再考虑：

text 复制代码

合作开发
委托开发
受让
继承
修改软件
例外交存

不要现在一次全部做。

先把：

普通、独立开发的软件著作权登记

做到非常稳定。

四十六、官方参考依据

《计算机软件保护条例》

该条例明确：

软件包括计算机程序及有关文档；
软件著作权原则上属于软件开发者；
合作开发、委托开发等情形存在不同的权属规则；
软件著作权自软件开发完成之日起产生。

因此 Copyright Forge 不能仅根据代码仓库推测：

text 复制代码

著作权人
权利归属
开发关系
真实完成日期

《计算机软件著作权登记办法》

国家版权局明确规定申请软件著作权登记应提交：

text 复制代码

申请表
软件鉴别材料
相关证明文件

其中软件鉴别材料包括：

text 复制代码

程序
+
一种文档

普通情况下，程序和文档按照前、后各连续 30 页准备；不足 60 页时提交全部；除特定情形外，程序每页不少于 50 行，文档每页不少于 30 行。

这部分应该直接进入机器可执行的 Rule Engine，而不是只存在 Markdown 文档里。

四十七、对这个项目最核心的新定位

以前可以叫：

软件著作权材料生成 Skill

我建议内部产品定位升级成：

Evidence-backed Software Copyright Delivery Agent

中文就是：

证据驱动的软件著作权材料交付 Agent

核心不是：

text 复制代码

生成

而是：

text 复制代码

调查
→
确认
→
生成
→
验证
→
交付

四十八、最终验收标准

当整个改造完成以后，拿一个从未见过的真实项目测试。

用户只输入：

text 复制代码

帮我给这个项目做软著。

如果最终能够做到：

text 复制代码

✓ 不让用户先学习软著知识

✓ 自动识别项目

✓ 自动识别核心功能

✓ 所有正式功能都有代码证据

✓ 只询问真正需要用户确认的事实

✓ 不从 Git 推断法律事实

✓ 自动生成说明书

✓ 自动生成最终源码材料

✓ 自动生成填写指引

✓ 自动进行敏感信息检查

✓ 自动执行官方规则

✓ 自动检查材料一致性

✓ 自动 Reviewer

✓ 有问题绝不 READY

✓ 修好以后生成完整交付包

✓ 中断以后可以继续

✓ 原项目全程不被修改

那么这个 Skill 才算真正形成闭环。

最后一句

让 Agent 更会写软著。

而是：

让整个系统能够证明，它生成的每一项材料为什么可信，并且能明确告诉用户：现在到底能不能交。

内部可以复杂，可以多消耗 Token，可以多跑几轮检查。

但用户最终只应该感受到：

text 复制代码

我把项目给它。
↓
它自己研究。
↓
问我几个必须确认的问题。
↓
最后给我一套完整材料。

这才是这个项目真正应该追求的产品形态。