Software Copyright Materials

display_name: 软著申请资料生成
short_description: 从真实项目生成软著申请 Word 和 TXT 材料
default_prompt: 读取当前目录中的项目，生成软件著作权申请资料草稿，确认后输出 Word 和 TXT。


# 申请表信息字段

按官网实际表单顺序和字段名：

1. 软件全称
2. 软件简称（可选）
3. 版本号
4. 软件分类（应用软件/嵌入式软件/中间件/系统软件/其他）
5. 开发完成日期（YYYY-MM-DD）
6. 开发方式（单独开发/合作开发/委托开发/下达任务开发）
7. 软件说明（原创 / 修改（含翻译软件、合成软件））
8. 发表状态（已发表/未发表）
9. 首次发表日期（已发表时填写，YYYY-MM-DD）
10. 著作权人（复合字段：国家/省市/类型[自然人/法人]/姓名/证件类型/证件号）
11. 权利范围（全部权利/部分权利）
12. 权利取得方式（原始取得/继受取得）
13. 开发的硬件环境（≤50字符）
14. 运行的硬件环境（≤50字符）
15. 开发该软件的操作系统（≤50字符）
16. 软件开发环境 / 开发工具（≤50字符，格式：开发环境: xxx/开发工具: xxx）
17. 该软件的运行平台 / 操作系统（≤50字符）
18. 软件运行支撑环境 / 支持软件（≤50字符）
19. 编程语言（预设按钮选择 + 自定义输入≤120字符）
20. 源程序量（纯数字，单位行，指全部源程序总行数）
21. 开发目的（≤50字符，不能只写软件名称）
22. 面向领域 / 行业（≤50字符）
23. 软件的主要功能（500~1300字符）
24. 软件的技术特点（多选标签 + 文本描述≤100字符；标签：APP/游戏软件/教育软件/金融软件/医疗软件/地理信息软件/云计算软件/信息安全软件/大数据软件/人工智能软件/VR软件/5G软件/小程序/物联网软件/智慧城市软件，都不符合时可不选）
25. 页数（代码鉴别材料实际页数）

## 字段来源与填写口径

- 软件全称、版本号、著作权人、日期：由用户确认。
- 软件全称必须显式确认；正式资料文件名、代码 Word 页眉、操作手册标题和正文中的软件名称均以申请表信息中的"软件全称"为准。
- 软件简称：可选；如有常用简称则填写。
- 版本号必须显式确认；如果项目配置中的版本号小于 V1.0，需提醒用户软著首次提交通常写 V1.0，并让用户确认填写 V1.0 还是项目当前版本号。
- 软件分类：默认选"应用软件"。
- 开发完成日期和首次发表日期：必须使用 YYYY-MM-DD 格式。
- 开发方式：默认"单独开发"，多人合作项目选"合作开发"。
- 软件说明：默认"原创"。
- 发表状态：用户确认已发表或未发表；已发表需附首次发表日期。
- 编程语言、源程序量、功能模块、技术特点：根据项目分析生成。编程语言官网为预设按钮选择 + 自定义输入（≤120字符），预设选项包括 Assembly language、C、C#、C++、Delphi/Object Pascal、Go、HTML、Java、JavaScript、MATLAB、Objective-C、PHP、PL/SQL、Perl、Python、R、Ruby、SQL、Swift、Visual Basic、Visual Basic .Net。
- 源程序量：只填纯数字（不含"行"字），指登记软件全部源程序的总行数（非仅代码材料抽取行数）。
- 软件开发环境 / 开发工具：≤50字符，格式 `开发环境: <OS>/开发工具: <IDE>`，例如 `开发环境: Windows 11/开发工具: Visual Studio Code`；不要填写 React、Next.js、Vite、TypeScript 等技术栈。
- 开发该软件的操作系统：≤50字符，填写实际开发电脑的操作系统版本。
- 该软件的运行平台 / 操作系统：≤50字符，填写软件运行所在的操作系统或浏览器环境。
- 软件运行支撑环境 / 支持软件：≤50字符，直接列出运行依赖（如 Node.js、npm、浏览器），不加格式前缀。
- 开发的硬件环境：≤50字符，优先读取当前电脑 CPU、内存、硬盘配置作为建议值。
- 运行的硬件环境：≤50字符，默认可沿用开发硬件建议值，也可按实际运行设备填写。
- 开发目的：≤50字符，用一句话说明软件开发目的，不能只写软件名称。
- 面向领域 / 行业：≤50字符。
- 软件的主要功能：500~1300字符，详细描述软件核心功能。
- 软件的技术特点：多选标签（APP/游戏软件/教育软件等）+ 文本描述≤100字符；标签都不符合时可不选。

## 一致性要求

- 软件全称和版本号必须与代码材料、操作手册一致。
- 正式代码 Word 页眉软件名称必须与申请表信息中的“软件全称”一致，生成 Word 时以申请表软件全称为准。
- 正式代码 Word 页眉版本号必须与申请表信息中的“版本号”一致，生成 Word 时以申请表版本号为准。
- 主要功能必须来自当前项目，不得沿用范本中的旧项目描述。
- `待用户确认` 字段在正式输出前应尽量替换为确认值；如仍存在，必须写入生成报告。


# 业务理解规则

申请表信息和操作手册不能只根据代码结构泛泛生成，必须先理解软件业务。

## 证据收集

先用脚本收集证据，输出 `草稿/业务理解证据.md/json` 和 `草稿/业务理解模型稿模板.json`。证据通常包括：

- `README.md`
- `docs/*PRD*.md`
- `docs/*BRD*.md`
- `docs/*ARCHITECTURE*.md`
- 产品说明、需求文档、设计文档
- 前端页面标题、按钮文案、路由、核心组件名
- 后端 API 路由和模型名称

这些只是候选证据，不代表最终行业、功能和手册结构。

## 输出业务理解草稿

模型必须阅读证据和必要源码，自行判断应该抽取哪些业务信息，再生成业务理解模型稿 JSON。不得用关键字表或固定模板决定行业、功能和结构。

模型稿经脚本校验后生成 `草稿/业务理解.md` 和 `草稿/业务理解.json`，至少包含：

- 产品定位
- 面向领域 / 行业
- 目标用户
- 用户痛点和核心价值
- 主要业务功能
- 典型操作流程
- 操作手册结构建议
- 操作手册页面/流程模块，必须说明每个真实页面或核心流程的使用场景、进入位置、用户可见元素、用户动作、输入/状态规则、结果反馈和截图预留
- 申请表建议口径
- 证据来源
- 待用户确认项

## 外部调研

如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料。

外部调研只用于帮助理解行业表达，不能编造项目不存在的功能。需要把调研结论写入业务理解草稿，并区分“项目证据”和“行业参考”。

## 生成材料约束

- `申请表信息.md/txt` 的开发目的、行业、主要功能、技术特点必须优先来自业务理解。
- `操作手册.md/docx` 的说明、功能特点、系统要求、核心页面/流程、常见问题、术语表和章节结构必须优先来自模型确认后的业务理解。
- 操作手册不应只生成抽象“功能列表”。模型应把路由、页面、按钮、输入框、列表、弹窗、状态提示、额度或权限规则等用户可见证据整理到 `manual_modules`，供脚本按通用操作手册骨架排版。最终成稿应是段落化用户手册，不是“进入方式/页面内容/操作步骤/结果反馈”的字段列表。
- 如果缺少 `manual_modules`、`system_requirements`、`faq` 或 `glossary`，应回到业务理解阶段补充真实内容；脚本不得用分类模板兜底生成。
- 如果业务理解仍不充分，先提示用户补充产品说明，而不是直接生成泛泛描述。


# 代码抽取规则

## 选择方式

脚本只生成候选源码清单，不默认决定抽取文件。模型需要先理解项目业务、页面入口和源码职责，再决定抽取哪些文件或行段，并在 `代码文件选择.json` 中填写：

- `selected`
- `start_line`
- `end_line`
- `model_reason`

选择时通常优先考虑审核员能看懂软件功能和运行逻辑的源码，例如入口、页面、业务组件、数据交互、状态处理、业务服务等。具体选择由模型根据项目实际判断，不能用固定路径规则直接拍板。

## 排除项

排除以下内容：

- `node_modules`
- `dist`、`build`、`.next`、`.nuxt`、`coverage`
- lock 文件
- 图片、字体、二进制文件
- sourcemap、minified 文件
- 自动生成文件
- 过短且无业务意义的配置文件

## 真实性要求

- 保留原始代码文本。
- 可添加文件路径标记用于追溯。
- 不改写业务逻辑。
- 不使用 AI 补齐代码。

## 用户确认要求

- 代码抽取前必须先生成 `代码文件候选清单.md` 和 `代码文件选择.json`。
- 模型必须先填写抽取选择和 `model_reason`，再让用户确认或手动调整 `selected`。
- 用户可以通过 `start_line` / `end_line` 只抽取某个文件的指定行段。
- 抽取脚本必须以 `代码文件选择.json` 为准，不能绕过确认步骤直接抽全量代码库。
- `代码提取清单.md` 必须记录