软著申请小助手

面向软件著作权（软著）申请的全流程规范化助手。以下规则均经过实战验证。

〇、快速上手与使用指引（新手先看这里）

本 Skill 像跟同事说话一样自然,不需要记命令。两种用法,按需选。

怎么触发（怎么让它启动）

只要你的消息里出现「软著 / 著作权登记 / 源码 PDF / 说明书 / 申请表」等关键词,或说出第十节任一句触发词(如"帮我审查这份软著材料""软著申请表怎么填"),Skill 就会自动启动。无需特殊指令、无需切换模式。

两种模式

• 查规则(自学模式):想了解格式要求 / 字段限制时直接问,如"软著主要功能描述怎么写""源码 PDF 要多少页"。按第一~七节给你规则 + 示例。
• 贴材料审查(审查模式):材料写好了想核对是否合规,把材料贴进来即可(见下方 3 步)。这是本 Skill 的核心能力。

审查模式怎么用（3 步）

1. 准备材料:把要核对的内容贴给我,可一次贴也可分开贴——① 软件全称(如「XX 系统 V1.0」) ② 主要功能描述(一段 500–1300 字文字) ③ 源码片段(密钥先按第三节用 * 遮蔽) ④ 关键日期(开发完成日 / V1.0 日 / 首次发表日)。
2. 说一句:"帮我审查"或"看看这份材料能不能提交"。
3. 收报告:确定性引擎(scripts/review.py)扫 5 项硬规则 + 语义检查,输出带 PASS / WARN / FAIL 的分级报告,每条标出问题位置 + 修改建议。

使用示例

• 示例 1 · 查规则
• 你:软著主要功能描述有字数限制吗?
• 我:有,必须 500–1300 字符;建议结构 (1)(2)(3)(4) 四功能点 + 场景描述;低于 500 会被补正,超 1300 需压缩。
• 示例 2 · 审查模式(贴材料)
• 你:帮我审查:全称=智慧社区物业管理系统 V1.0;功能描述=……(贴一段);源码里有个 sk-abc123 没脱敏;开发完成=2025-04-10,V1.0=2025-04-15。
• 我:运行引擎 → ①名称≤50字 PASS ②功能 500–1300字 PASS ③密钥脱敏 FAIL(发现 sk-abc123 未遮蔽,请改为 sk-****...****) ④零 AI 标记 PASS ⑤日期勾稽 PASS → 结论:改完密钥脱敏即可提交。

> 本 Skill 的定位是「帮你核对材料哪里不合格」,不包办、不承诺包过(详见第九节)。它告诉你问题,修改由你完成——这也符合软著申请必须真实性的要求。

一、申请表填写规则

1.1 公共字段 ≤50 字符

以下字段必须控制在 50 字符（含标点）以内：

1.2 主要功能：500-1300 字符

必须≥500字、≤1300字。结构：(1)(2)(3)(4) 四个功能点 + 场景描述。示例结构：

(1)AI内容智能生成：支持...全链路自动化...(2)内容安全审核引擎：基于Trie树...
(3)垂直领域知识库管理：内置...条目...(4)多模态素材库管理：支持...
系统服务于...场景描述+应用效果...

1.3 技术特点：分类点选 + 文字描述 ≤100 字符

格式：分类点选。文字描述。

可选分类（可多选）：APP、游戏软件、教育软件、金融软件、医疗软件、地理信息软件、云计算软件、信息安全软件、大数据软件、人工智能软件、VR软件、5G软件、小程序、物联网软件、智慧城市软件

1.4 日期对齐规则

• 开发完成日期 必须在说明书 DOCX 修订记录中 V1.0 日期之前（约前 5-10 天）
• 首次发表日期 与 V1.0 修订日期同一天
• 如果各产品按时间顺序排，前面产品的日期必须早于后面产品
• 示例：说明书 V1.0=2025-04-15 → 开发完成=2025-04-10，首次发表=2025-04-15

1.5 质权登记

与软著登记无关。申请表上勾"否"即可。质权=把软著当抵押品贷款。

1.6 已发表 vs 未发表

勾"已发表"需要提供发表证明（发布公告截图、用户协议页面等）。若是内部系统未对外公开发布，建议清空首次发表日期，改填"未发表"，省去补材料的麻烦。

二、说明书材料标准

2.1 PDF 格式要求

• 品牌统一页眉：产品全称 + 申请人品牌 VI 色（如主色 #XXXXXX）
• 12章结构：引言 → 总体概述 → 架构设计 → 业务流程 → 功能设计 → 数据库 → 接口 → 安全 → 部署 → 操作手册 → 测试 → 未来扩展
• 至少 5 张流程图/架构图（image 方式嵌入）
• 修订记录表：V1.0/V1.1/V1.2 三个版本

2.2 修订记录与申请日期关系

以下勾稽关系必须成立：

开发完成日期 < V1.0修订日期 = 首次发表日期 < V1.1 < V1.2

三、源码材料标准

3.1 页数：前 30 页 + 后 30 页

• 核心代码放前半（src/ + 主入口），测试/配置/部署放后半
• 页眉格式：产品全称 V1.0 | 第 X 页（前/后X页）
• 页脚：{{申请人公司全称}}

3.2 代码真实性

• 零 AI 标记：不允许出现"对齐说明书""§X.X""参见说明书"等教程式标注
• 真实开发者风格：代码用 JSDoc 注释，require/module.exports，有错误处理
• 密钥脱敏：API Key/密码用 * 遮蔽，保留前后各4位可见，长度不变
• 示例：sk-gE****...****0LIz、ld67****...****b7BV
• 绝不允许 your-key、change-me 等教学式占位符
• 代码须展开：不能是压缩的一行流，要有合理的缩进、空行、JSDoc 块注释

3.3 字体处理

• PDF 代码字体必须用 CJK 字体（如微软雅黑），不能用 Courier——Courier 无法渲染中文导致黑块
• 文件头标签也用 CJK 字体

3.4 编码一致性

• 源码的技术栈（Node.js/PostgreSQL/Redis/Express等）必须与申请表一致
• 申请表源程序量应大于实际源码行数 2-5 倍（正常偏差，审查员不会逐行数）

四、产品部署演示标准

4.1 数据库降级策略

当 PostgreSQL 不可用时，使用 JSON 文件存储（零外部依赖）：

const fs = require('fs');
// 读写 database.json，兼容 pg Pool.query(text, params) API

4.2 缓存降级策略

Redis 不可用时，使用内存 Map 替代：

const cache = new Map();
// 兼容 set/get/incr/del API

4.3 AI 模型降级

DeepSeek API 不可用时，使用 mock 降级生成示例内容，不阻塞演示流程。

五、工具与环境坑点

5.1 Windows curl 中文编码（⚠ 已验证）

在 Windows Git Bash 下，curl -d '{"中文":"内容"}' 会损坏 UTF-8 中文（变为 U+FFFD 替换字符）。

正确做法：

printf '%s' '{"title":"恐龙灭绝之谜","style":"科普型","keywords":["恐龙"]}' | \
  curl -s -X POST http://localhost:3000/api/v1/content/generate \
    -H "Content-Type: application/json; charset=utf-8" \
    -H "Authorization: Bearer $TOKEN" \
    --data-binary @-

5.2 Node GYP 编译问题

better-sqlite3 需要 C++ 编译环境，沙箱内可能不可用。优先选择纯 JS 方案（sql.js 或 JSON 文件存储）。

5.3 reportlab XML 标签解析

reportlab 的 Paragraph 会把 < 当作 XML 标签，导致 <api/v1/:id> 这类路径解析失败。
修复： 渲染代码前先转义：line.replace("<", "<").replace(">", ">")

六、多产品申报的序号与日期关系（通用示例）

> 以下产品名、公司名、日期均为虚构占位示例，仅用于演示"日期必须顺序排列"的勾稽规则，与任何真实业务无关，请替换为你的真实信息。

多产品申报时，各产品时间线必须顺序排列（①<②<③），不能出现后一产品的 V1.0 日期早于前一个产品的日期。

七、检查清单

生成完材料后，逐项检查：

• [ ] 公共字段全部 ≤50 字符
• [ ] 主要功能 500-1300 字
• [ ] 技术特点：分类+描述 ≤100 字
• [ ] 开发完成 < V1.0 = 首次发表 < V1.1 < V1.2
• [ ] 源码 PDF 60 页，前30+后30
• [ ] 源码 PDF 用 CJK 字体，无 Courier 黑块
• [ ] 源码零"对齐说明书""§"标记
• [ ] 密钥用 * 遮蔽，无 "your-key" 占位符
• [ ] 源码展开为正常工程格式（非一行流）
• [ ] 申请表技术栈与实际源码一致
• [ ] 源程序量 > 实际行数
• [ ] JS 源码全部通过 node --check
• [ ] Windows curl 测试用 printf + --data-binary
• [ ] 下载版权局正式申请表后，右下角盖章清晰、不超出框线（彩打后手工盖章再扫描）

八、审查模式（v1.2 新增 · AI 辅助审查）

当用户贴入真实申报材料（而非仅询问规则）时，进入「审查模式」，对材料做主动审查并输出分级报告。

8.1 两种模式

• 自学模式（默认）：用户只问规则/格式，按第一~七节回答，不跑脚本。
• 审查模式（贴材料时触发）：对材料做确定性 + 语义双引擎审查，输出报告。

8.2 审查流程

1. 从用户材料中抽取四类字段（缺失则跳过对应检查，并在报告中标注"未提供"）：
   - full_name 软件全称
   - function_description 主要功能描述
   - source_code 源码片段
   - dates 日期字典：{dev_complete, v1_0, first_publish, v1_1, v1_2}（YYYY-MM-DD）
2. 脱敏提示：提醒用户"仅粘贴脱敏字段"，源码中的密钥须已按第三节用 * 遮蔽。
3. 将字段写入临时 materials.json，运行确定性引擎：
   bash python scripts/review.py --materials materials.json # 或：cat materials.json | python scripts/review.py
   脚本输出 JSON，含逐条 PASS / WARN / FAIL 与 detail。
4. 语义三项（由你即 LLM 完成，脚本不覆盖）：
   - 功能偏题：功能描述是否偏离"软件功能"写成营销/情怀话术
   - 章节完整：说明书 12 章是否齐全、每章是否有实质内容
   - AI 痕迹：源码/说明书是否带 AI 生成特征（模板化结构、无意义注释）
5. 合并确定性 + 语义结果，输出分级合规校验报告：每条检查的状态、定位、修改建议；可提示用户"用 scripts/build_pdf_from_disk.py 重新生成源码 PDF"。

8.3 确定性引擎覆盖的检查

九、安全与合规声明（上架前必读）

• 运行环境 / 无需密钥：本 Skill 全程本地运行，不需要任何 API Key、Token 或外部服务配置。确定性审查引擎 scripts/review.py 为纯 Python 标准库实现（零第三方依赖）；语义检查由 Agent 自身模型完成；文档与脚本中出现的 sk- / api_key / Bearer 等字样，仅用于「检测用户源码中未脱敏密钥」的规则与示例，并非本 Skill 要求你提供的凭证。scripts/build_pdf_from_disk.py 为可选脚本（需 reportlab + 本地 CJK 字体，如 Windows msyh.ttc），仅用于重生成源码 PDF，不参与核心审查。
• 合规边界：本 Skill 仅提供软著申请的规范化辅助与自检，不承诺"包过 / 代写 / 100% 下证"，最终结果以中国版权保护中心审核为准。请勿用于任何形式的虚假申报。
• 数据处理原则：处理你的材料（申请表、源代码、营业执照等）时，建议在本地环境运行，不上传至不可信第三方，不持久化存储你的原始文件；源代码中的密钥务必按第三节规则用 * 遮蔽，绝不留 your-key 等教学式占位符。
• 素材泛化：本 Skill 内的产品名、公司名、日期均为通用示例，与任何真实业务无关，请替换为你的真实信息；如引用自身历史申报记录，注意脱敏。

十、触发词清单（自然语言激活）

> 本 Skill 面向以下自然语言意图自动激活。覆盖「查规则（自学模式）」与「贴材料审查（审查模式）」两类场景，便于 Agent 在用户不同表述下都能精准唤起——这也是可发现性（基因 6）的硬指标。

A. 申请表填写与字段咨询

1. 帮我填软著申请表
2. 软著申请表硬件环境（开发/运行）怎么写，有示例吗
3. 软著开发用硬件环境、运行用硬件环境分别填什么
4. 软著主要功能描述怎么写才不超字数
5. 软著技术特点分类怎么选（APP / 人工智能软件 / 小程序…）
6. 软著的「开发目的」「面向领域/行业」写什么内容
7. 软著申请表源程序量填多少合适

B. 功能描述撰写与字数校验

8. 帮我写一段软著功能描述（500–1300 字）
9. 软著功能描述超过 1300 字了怎么压
10. 软著功能描述不到 500 字怎么扩充

C. 说明书与材料格式

11. 软著说明书要写哪 12 章
12. 软著说明书结构 / 章节顺序是什么
13. 软著已发表和未发表怎么选，要不要补发表证明
14. 软著质权登记是什么，申请表要勾吗

D. 源代码 PDF 与脱敏

15. 软著源码 PDF 怎么生成，要多少页
16. 软著源码 PDF 出现中文黑块（Courier 字体）怎么解决
17. 软著源码里的 API Key / 密码怎么脱敏处理
18. 软著源码怎么避免被判定为 AI 生成（教程式标注）

E. 主动审查（审查模式 · v1.2 双引擎）

19. 帮我审查这份软著申报材料有没有问题
20. 看看我这份软著申请表 / 功能描述能不能提交
21. 这份软著源代码会不会被判定 AI 生成，帮我扫一下
22. 帮我校验软著材料里的日期勾稽对不对

F. 流程与通用咨询

23. 软著申请整体流程是什么，个人能申请吗
24. 软著和专利有什么区别，我该申请哪个
25. 软著下证要多久，审查严不严、会不会被补正
26. 我现在想做软著代申请，先帮我把这份材料做遍自检