# 我拆解了SoftwareCopyright-Skill 这个软著申请的开源项目，告诉你它到底值不值

> 龙虾AGI通用实验室 · 2026-07-15

最近在 GitHub 上刷到一个项目：**SoftwareCopyright-Skill**。

![](images/7906ab/img_001.png)

它的定位很直接——用 AI 帮你自动生成软件著作权申请的全套材料，不用花钱找代理，不用把代码交给第三方。

软著申请这件事，做过的人知道有多烦，没做过的人以为就是"填个表交个代码"。我自己也没深入研究过代理公司和软著申请的门道，所以看到这个项目第一反应是好奇：**这事儿真的能自动化吗？它到底是认真做了，还是套个模板糊弄人？**

带着这个问题，我花了一下午把这个项目从头到尾拆了一遍——SKILL.md 工作流、5 份业务规则文档、9 个 Python 脚本、内置的 Word 生成工具链、还有一套完整的 demo 输出。下面是我的发现。

· · ·

## 它是什么

一句话：一个 Codex Skill（本质是提示词 + Python 脚本 + 参考文档），安装到 AI 编程工具后，能分析你的项目代码，自动生成软著申请需要的三样材料——**申请表、源代码材料、操作手册**，最终输出 Word 和 TXT 文件。

整个过程在本地完成，代码不外传。

· · ·

## 深度拆解：它做对了什么

## 1. 把"你不知道自己不知道"的东西编码成了规则

这是我觉得这个项目最有价值的地方。

软著申请表面上就三样材料，但里面藏着一堆隐性规则。这些规则不难，但你不查资料或者没被退回过，就是不知道。项目把这些规则写进了 5 份参考文档和脚本逻辑里，我挑几个最有代表性的：

**"开发工具"不能填 React。** 申请表有个字段叫"软件开发环境/开发工具"，很多开发者会填 React、Vue、TypeScript——这是填错了。这个字段要求填的是 IDE 名称：Visual Studio Code、WebStorm、Cursor。框架属于"技术特点"字段。项目的参考文档里明确写了这条规则，脚本也会自动检测 .vscode/ 或 .idea/ 目录来推荐正确的 IDE 名称。

**版本号首次提交写 V1.0。** 很多项目的 package.json 里版本号是 0.1.0 或 0.9.0，但软著首次提交通常建议写 V1.0。这是行业惯例，不是法规要求。项目会检测你的项目版本号，如果小于 1.0，会主动提醒你确认。

**操作手册是写给审查员看的，不是写给用户看的。** 这一条最反直觉。大多数人第一反应是写一份用户手册，但软著手册的读者是版权局的审查员——他们不会真的操作你的软件，只需要看懂"这个软件有什么功能、怎么用"。项目的手册写作规则明确要求：避免技术术语、不写代码示例、用通俗语言描述"做什么→怎么操作→看到什么结果"。

**代码材料的 30/30 页规则。** 根据《计算机软件著作权登记办法》，代码超过 60 页只提交前 30 页和后 30 页，不足 60 页提交全部，每页不少于 50 行。项目把这套规则完整实现在了代码提取脚本里，自动计算分页、自动判断是否需要分割。

**Word 文档必须纯黑色。** 所有文字必须是黑色（RGB 000000），不能有蓝色超链接、不能有彩色标题。项目的 Word 生成脚本里有一个 force_black_xml 函数，会后处理整个文档的 XML，强制剥离所有颜色和超链接。

这些规则单独拿出来都不复杂，但放在一起就构成了一套完整的合规知识体系。代理公司收费的核心价值，相当一部分就是确保这些细节不出错。

## 2. 让 AI 做判断，但不让 AI 编造

项目的架构设计有一个清晰的原则：**AI 负责理解和分析，脚本负责执行，人负责确认。**

具体体现在三个方面：

**代码只从真实文件提取。** 代码材料脚本逐行读取项目源文件，绝不让 AI 生成一行代码。每个提取的片段都记录了来源文件路径和行号范围，可以追溯到原始位置。

**业务理解由 AI 独立判断。** 脚本先收集项目证据（README、路由名、页面名、API 端点），然后交给 AI 模型分析行业定位、目标用户、核心功能。参考文档里明确禁止"用关键字表决定行业和功能"——必须让 AI 真正读懂项目再下判断。

**每个关键决策都有理由。** AI 选择代码文件时必须填写 model_reason（选择理由），不能无理由选择。最终用户可以审阅每个选择的理由，决定是否调整。

## 3. 6 道强制关卡防止跑偏

项目设计了 6 个不可跳过的用户确认关卡：

关卡	确认什么

环境确认	Word 生成环境的选择

业务理解	AI 分析的行业/功能/用户是否准确

代码选择	选的代码文件是否恰当

申请表字段	版权人、日期等只有人知道的信息

截图方式	怎么获取软件截图

最终确认	所有 Markdown 草稿的整体审阅

每个关卡都有对应的 JSON 记录，带时间戳，形成审计链。关键是——**下游脚本会检查上游关卡是否通过**。比如代码提取脚本会检查"代码选择"关卡是否已确认，没确认就拒绝执行。这不是摆设，是硬约束。

## 4. Markdown 先行，Word 收尾

所有材料先生成 Markdown 草稿，用户审阅确认后再转 Word。

这个设计看起来简单，但很聪明：Markdown 是人类直接可读可改的格式，用户不需要打开 Word 就能审阅全部内容。把"内容正确性"和"格式排版"解耦——先确保内容对，再处理格式。

## 5. 操作手册的"去 AI 味"机制

项目内置了一套检测和消除 AI 痕迹的系统：

一份包含 15 个 AI 高频词的黑名单："旨在""赋能""一站式""智能化""高效便捷""显著提升"……

一份技术术语替换表：把"后端"替换为"系统服务"、"接口"替换为"数据通道"、"React/Vue"替换为"相关软件能力"

手册生成后自动进行 3-6 轮自检，检测模板化表达、重复句式、章节厚度不均等问题

每轮自检结果记录在 操作手册自检记录.json 中，可追溯

· · ·

## 诚实评估：局限在哪

## 前端 Web 项目的体验远好于其他项目

项目分析层只统计前端文件（.vue, .ts, .tsx, .js），框架检测只覆盖 React、Vue、Next.js 等 Web 框架，文件分类逻辑基于 /pages/、/components/、/api/ 等 Web 目录结构。

纯后端（Go、Java、Python）项目不是不能用——代码提取支持 .py, .java, .go 等后端语言——但自动分析会很薄，需要用户在确认关卡处做更多手工补充。

## 操作手册是"智能模板"，不是"自由撰写"

手册生成基于 9 套预设的功能类别蓝图（认证、查询、表单、工作流等），通过关键词把功能匹配到对应类别，填入预写好的操作步骤。

不过这对软著申请场景来说**反而是合理的**——软著手册本身就是高度格式化的合规文档，审查员要看的是结构完整、内容准确，不是文采飞扬。模板确保结构不出错，业务理解步骤确保内容跟项目相关。

## 只覆盖材料准备，不覆盖提交流程

项目帮你生成好全部文件，但"去哪个网站提交""怎么注册账号""被退回怎么改"这些不在范围内。它是一个材料准备工具，不是软著申请的全流程方案。

## 需要 AI 编程工具环境

它是一个 Skill（提示词 + 脚本），需要安装到 Codex、Claude Code 等 AI 编程工具中运行。不是那种 pip install 一键搞定的命令行工具。

· · ·

## 结论

**这个项目的核心价值，不在于它做了多难的事情，而在于它帮你避开了你不知道自己会踩的坑。**

"开发工具不能填 React""版本号写 V1.0""手册是写给审查员的""Word 文档必须纯黑色"——每一条都不复杂，但你不用这个工具，可能要被退回一次才能学会。

它最适合的场景是：**你有一个 Web 项目，想自己申请软著，不想把代码交给代理，也不想花大半天跟排版格式较劲。** 装好工具，跟着 6 个确认关卡走一遍，大概 1-2 小时就能拿到全套材料。

它不适合的场景：纯后端项目（帮助有限）、完全不懂技术的人（还是需要能看懂草稿）、只申请一次且不在乎钱的（直接找代理更省心）。

总的来说，在 AI 工具满天飞的时代，大部分项目是在用 AI 做"看起来能做但其实不靠谱"的事情。这个项目让我觉得不一样的地方是——它对"AI 会犯什么错"有清醒的认知，并且用强制关卡、真实代码提取、去 AI 味机制等设计把这些错误挡在了输出之前。

**这种"让 AI 做擅长的事，用工程手段防止 AI 做不擅长的事"的思路，可能比项目本身更值得关注。**

· · ·

项目地址：https://github.com/Fokkyp/SoftwareCopyright-Skill

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。如果你也在自己跑模型、写代码、做项目，欢迎点赞关注转发一键三连，然后加我微信，备注写清"你在做的AI方向"，聊得来的话我拉你进群。纯围观的和小白就不加了，有一定门槛。当然你也可以简单粗暴的甩给我999元，我拉你进群，这个没门槛。

![](images/7906ab/img_002.jpg)