2dc44b2393
1. 新增软著登记所需的源程序生成脚本、docx生成脚本与依赖配置 2. 新增像素大勇者游戏软件V1.0设计说明书与填表指引文档 3. 更新技能配置相关的prefab与meta文件，清理冗余的up状态预制件 4. 修复部分技能buff的颜色与精灵帧引用，更新动画资源引用 5. 新增两个技能图标资源文件
340 lines
15 KiB
Markdown
340 lines
15 KiB
Markdown
---
|
||
name: "software-copyright-desk"
|
||
description: "Guides users through filling the official software copyright (计算机软件著作权) registration application. Invoke when user asks about 软著 / 软件著作权 / 软件登记 / 著作权人填报 / 源程序 / 设计说明书 / 操作手册 / 软著加急 / 软著流程."
|
||
---
|
||
|
||
# Software Copyright Desk
|
||
|
||
通过结构化提问，帮用户整理《计算机软件著作权登记申请表》所需的全部材料，并输出可直接粘贴到中国版权保护中心在线填报系统的规范化文本。
|
||
|
||
## 适用场景
|
||
|
||
- 用户首次办理软著登记，不知道该准备什么
|
||
- 用户已有初稿，需要按登记要求规范化、补齐必填项
|
||
- 用户想确认材料是否齐全、是否有常见退回风险
|
||
|
||
不适用于：
|
||
- 电子版权认证（项目已停用此线）
|
||
- 软件专利、商标、版权交易等其他知识产权事务
|
||
|
||
## 工作流程
|
||
|
||
### 第 1 步：明确用户当前进度
|
||
|
||
先问清用户处于以下哪个阶段，据此决定提问顺序：
|
||
|
||
1. **完全空白**：还没填过任何材料
|
||
2. **已有部分信息**：手头有软件名、著作权人信息、功能描述等
|
||
3. **已有初稿**：需要审校、补全、规范
|
||
|
||
### 第 2 步：按 Profile 结构收集信息
|
||
|
||
参考 `src/types/index.ts` 的字段结构，分四组提问：
|
||
|
||
**软件基本信息（SoftwareInfo）**
|
||
- 软件全称（必填，格式建议：品牌/主体名 + 功能 + 软件）
|
||
- 软件简称（可选）
|
||
- 版本号（默认 V1.0）
|
||
- 软件分类（应用软件 / 系统软件 / 支撑软件 / 嵌入式软件 / 中间件 / 游戏软件 / 其他）
|
||
- 开发完成日期（须早于或等于申请日期）
|
||
- 发表状态：未发表 / 已发表（如已发表需补充首次发表日期与地点）
|
||
- 开发方式：独立开发 / 合作开发 / 委托开发 / 下达任务开发
|
||
- 权利取得方式：原始取得 / 继受取得
|
||
- 权利范围：全部权利（默认）
|
||
|
||
**著作权人信息（OwnerInfo）**
|
||
- 主体类型：个人 / 企业 / 其他组织
|
||
- 姓名 / 单位全称（须与证件完全一致）
|
||
- 证件类型（依主体类型变化）
|
||
- 证件号码
|
||
- 国籍 / 注册地（默认中国）
|
||
- 地址（与证件地址或营业执照住所一致）
|
||
- 邮编、联系人、联系电话、电子邮箱
|
||
|
||
**软件描述（DescInfo）**
|
||
- 硬件环境（CPU、内存、硬盘、网络）
|
||
- 软件环境（操作系统 / 平台）
|
||
- 编程语言
|
||
- 源程序量（行数）
|
||
- 主要功能（申请表字段要求 500 字以上，覆盖各功能模块；设计说明书概述章节可用 200-300 字摘要版）
|
||
- 技术特点（150-250 字，可选）
|
||
|
||
**功能模块（ManualModule[]）**
|
||
- 用户补充或从"主要功能"拆解得到 6-8 个模块
|
||
- 每个模块名 + 一句话描述
|
||
|
||
### 第 3 步：生成材料
|
||
|
||
按以下顺序产出，每段都可直接复制使用：
|
||
|
||
1. **填报速查表**：调用 `buildSummary` 的输出结构（分组：软件基本信息 / 著作权人信息 / 软件描述）
|
||
2. **源程序文档**：见下方"源程序专项"章节
|
||
3. **设计说明书 / 用户操作手册**：调用 `buildManual` 的章节模板，可选其一：
|
||
- 设计说明书：引言 / 运行环境 / 功能模块设计 / 数据结构与接口设计 / 安全与异常处理 / 联系方式
|
||
- 用户操作手册：引言 / 运行环境 / 安装与启动 / 功能操作说明 / 常见问题 / 联系方式
|
||
4. **填表指引**（用户需要时）：见下方"填表指引文档"章节
|
||
|
||
### 源程序专项
|
||
|
||
源程序文档与说明书是两件不同的材料，必须**分别**准备和提交。
|
||
|
||
#### 提交要求（来自登记规范）
|
||
|
||
- 取前 30 页 + 后 30 页，不足 60 页时全部提交
|
||
- 每页不少于 50 行有效代码（默认每页 50 行；用户要求更高密度时可调，如 60 行/页，但不得低于 50）
|
||
- 页眉：左侧标注 `软件全称 版本号`，右侧标注 `第 N 页 共 M 页`
|
||
- 9.5pt 等宽字体，每行不超过 84 字符（A4 折行限制；按显示宽度计：ASCII 记 1 列，中文/全角记 2 列）
|
||
- 文件名示例：`软件全称_V1.0_源程序.pdf`；用户需要 docx/PDF 成品时按下方「docx 版本生成」章节产出
|
||
|
||
#### 三种生成方式（按用户掌握情况选用）
|
||
|
||
**方式 A：用户手头有源代码（推荐）**
|
||
|
||
让用户提供源代码文件路径或粘贴代码文本，Skill 直接执行 `paginateCode` 逻辑：
|
||
|
||
```text
|
||
1. 与用户确认源代码根目录范围（只采集约定目录，如 assets/script）
|
||
2. 排除非源码：.md/.csv 等文档、.d.ts 声明文件、着色器/材质、空文件、
|
||
构建产物、第三方框架目录（如 extensions/ 下的开源插件框架）
|
||
3. 清理文件头（前 40 行）的第三方署名与版权行：他人 ID/昵称、QQ 号、
|
||
第三方框架作者的 @Author/@LastEditors/@Date/@LastEditTime、引擎 Copyright
|
||
声明；生成后必须 grep 复验清理干净
|
||
4. 入口文件（如 Main.ts）优先排序，其余按路径字母序；文件间加注释分隔行
|
||
5. 把 \r\n 替换为 \n，\t 替换为 4 空格
|
||
6. 按每页 N 行切分（N ≥ 50，默认 50，可按用户要求调整），得到总页数
|
||
7. 若总页数 > 60：保留前 30 页 + 后 30 页，丢弃中间
|
||
8. 给每页加上统一页眉；建议沉淀为可重跑脚本（代码变更后重新生成）
|
||
```
|
||
|
||
输出格式示例：
|
||
|
||
```
|
||
============== 第 1 页 共 60 页 ==============
|
||
软件全称：星辰记账软件 V1.0
|
||
=============================================
|
||
[此处为第 1-50 行代码]
|
||
```
|
||
|
||
```
|
||
============== 第 60 页 共 60 页 ==============
|
||
软件全称：星辰记账软件 V1.0
|
||
=============================================
|
||
[此处为最后 50 行代码]
|
||
```
|
||
|
||
**方式 B：用户仅有软件雏形 / 部分代码**
|
||
|
||
引导用户补齐以下内容后再次提交：
|
||
|
||
- 主入口文件（如 `main.ts` / `MainActivity.java` / `app.py`）
|
||
- 核心业务模块（至少 6-8 个关键文件）
|
||
- 与"主要功能 / 功能模块"一一对应的实现片段
|
||
|
||
如果代码量不足 3000 行（登记常见下限），提示用户补充占位实现 / 注释 / 单元测试，使总行数达到合理区间（3000-10000 行）。
|
||
|
||
**方式 C：用户完全没有代码**
|
||
|
||
明确告知：**软著登记不接受纯文字描述代替源程序**，必须有真实可运行的代码。Skill 可以：
|
||
|
||
- 引导用户先把软件做出来（或至少做出 MVP）
|
||
- 或者按用户描述的功能，生成一份**可直接复制运行的参考骨架代码**（如 React + Vite + TS 项目骨架、Python Flask API 骨架、Android Activity 骨架），用户拿去做二次开发
|
||
|
||
骨架生成时遵循：
|
||
- 不依赖任何有版权争议的代码片段
|
||
- 包名 / 模块名用中性占位（`com.example.app`）
|
||
- 文件头不留第三方 License 声明（避免 `reviewCode` 第 4 条报错）
|
||
|
||
#### 源程序审校（调用 `reviewCode` 规则）
|
||
|
||
生成或用户提供代码后，必须执行以下检查并报告问题：
|
||
|
||
| # | 检查项 | 等级 | 处理方式 |
|
||
|---|---|---|---|
|
||
| 1 | 乱码 / 控制字符 > 0.5% | error | 提示用户上传了二进制文件，需重传 |
|
||
| 2 | 空行占比 > 30% | warn | 删除无意义空行，避免被认定"凑页数" |
|
||
| 3 | 注释行占比 > 40% | info | 建议补充有效代码 |
|
||
| 4 | 含第三方 License / Copyright 声明且与著作权人不一致 | error | 必须删除或修改 |
|
||
| 5 | 实际行数与速查表"源程序量"相差 > 10% | warn | 同步修改申请表 |
|
||
| 6 | 单行显示宽度 > 84 列（中文记 2 列） | warn | 折行换段，续行缩进 4 空格；生成 docx 时必须主动折行，勿依赖 Word 自动换行 |
|
||
| 7 | 含与著作权人无关的手机号 / 邮箱 | info | 脱敏后提交 |
|
||
| 8 | 混入 package-lock.json / node_modules / .min.js 等构建产物 | warn | 移除后再上传 |
|
||
|
||
#### 输出三档结论
|
||
|
||
- ✅ **可直接提交**：无 error，无 warn
|
||
- ⚠️ **建议修改**：无 error，有 warn，列出具体项
|
||
- ❌ **必须修改**：有 error，阻断提交
|
||
|
||
#### docx 版本生成（用户需要成品文件时）
|
||
|
||
用 Node + `docx` 库（v9）把 txt/md 排成规范 docx，关键实践：
|
||
|
||
- **页眉用 Word 域自动页码**：`PageNumber.CURRENT` / `PageNumber.TOTAL_PAGES`，
|
||
配右对齐 Tab 位；勿在正文硬编码"共 M 页"——折行增多页数时域自动跟随
|
||
- **精确分页**：每 N 行代码一页，下一页首段用 `pageBreakBefore: true`，
|
||
保证"每页行数"与规范声明一致
|
||
- **主动折行**：超 84 显示列的行在生成时折断（续行缩进 4 空格）；
|
||
依赖 Word 自动换行会导致每页物理行数失控、分页错位
|
||
- **排版**：A4；边距上下 1.27cm、左右 1.5cm；代码 9.5pt Consolas
|
||
（中文回退宋体）；行距适度压缩（如 230/240）确保每页行数放得下
|
||
- **依赖隔离**：在材料目录建独立 `package.json` 再 `npm install docx`；
|
||
中文目录名会导致 `npm init -y` 失败（Invalid name），需手写合法 name；
|
||
不隔离会污染用户项目根依赖（装错后必须还原 package.json 并删除误装的包）
|
||
- **文件占用**：写入报 `EBUSY` 说明用户正在 Word 中打开该 docx，
|
||
提示关闭后重试，勿反复盲试
|
||
|
||
## 设计说明书与用户操作手册（详细）
|
||
|
||
Skill 必须能根据"功能模块"列表生成完整的说明书文档，章节结构与项目代码 `buildManual` 一致：
|
||
|
||
### 设计说明书模板
|
||
|
||
```
|
||
# 软件全称 V1.0
|
||
# 设计说明书
|
||
著作权人 · 完成日期
|
||
|
||
## 一、引言
|
||
### 1.1 编写目的
|
||
本文档用于说明「软件全称（V1.0）」的总体设计思路、功能结构与运行环境，作为计算机软件著作权登记的鉴别材料。
|
||
### 1.2 软件概述
|
||
主要功能正文（200-300 字）
|
||
### 1.3 技术特点
|
||
技术特点正文（150-250 字）
|
||
|
||
## 二、运行环境
|
||
### 2.1 硬件环境
|
||
### 2.2 软件环境
|
||
开发语言：xxx
|
||
|
||
## 三、功能模块设计
|
||
### 3.1 模块A
|
||
模块A的处理流程、输入输出
|
||
### 3.2 模块B
|
||
...
|
||
|
||
## 四、数据结构与接口设计
|
||
（请根据实际补充：核心数据表结构、关键字段说明、模块间接口与调用关系）
|
||
|
||
## 五、安全与异常处理
|
||
（请根据实际补充：权限控制、数据校验、异常捕获与日志记录机制）
|
||
|
||
## 六、联系方式
|
||
技术支持：xxx
|
||
联系电话：xxx 电子邮箱：xxx
|
||
```
|
||
|
||
### 用户操作手册模板
|
||
|
||
```
|
||
# 软件全称 V1.0
|
||
# 用户操作手册
|
||
著作权人 · 完成日期
|
||
|
||
## 一、引言
|
||
### 1.1 编写目的
|
||
### 1.2 软件概述
|
||
|
||
## 二、运行环境
|
||
### 2.1 硬件环境
|
||
### 2.2 软件环境
|
||
开发语言：xxx
|
||
|
||
## 三、安装与启动
|
||
### 3.1 安装步骤
|
||
### 3.2 启动与登录
|
||
|
||
## 四、功能操作说明
|
||
### 4.1 模块A
|
||
入口位置、操作步骤、预期结果
|
||
### 4.2 模块B
|
||
...
|
||
|
||
## 五、常见问题
|
||
（请列举 3-5 个使用中的常见问题及解决办法）
|
||
|
||
## 六、联系方式
|
||
```
|
||
|
||
### 写作要求
|
||
|
||
- 使用书面语，句式完整
|
||
- 一律用「本软件」指代软件本身
|
||
- 不出现第三方产品名、公司名、品牌名
|
||
- 游戏软件使用玩家、关卡、战斗、背包、任务、商城等术语
|
||
- 其他软件使用用户、模块、数据、接口、权限、校验等术语
|
||
- 操作手册中"操作步骤"用 1. 2. 3. 编号
|
||
- 说明书建议配图 5-10 张（提示用户在 Word 中补）
|
||
|
||
### 第 4 步：自动审校
|
||
|
||
参考 `src/lib/core.ts` 的 `reviewCode` 思路，对用户提交的内容做轻量检查：
|
||
|
||
- 必填项是否齐全（软件全称、版本号、完成日期、著作权人姓名/证件号/地址/联系方式、运行环境、主要功能）
|
||
- 软件名称、版本号在申请表、源程序页眉、说明书封面是否完全一致
|
||
- 著作权人姓名/单位名是否与平台注册主体一致
|
||
- 主要功能、技术特点是否包含第三方品牌名、公司名
|
||
- 源程序量是否在 3000 行以上、不超过 10 万行
|
||
- 主要功能是否使用书面语、是否完整描述软件做什么、面向谁、解决什么问题
|
||
- 源程序是否通过 `reviewCode` 的 8 项检查（详见"源程序专项"章节）
|
||
- 说明书 / 操作手册的"软件全称 / 版本号 / 著作权人"与速查表是否完全一致
|
||
|
||
输出"通过 / 建议修改 / 必须修改"三档结论，列出问题清单。
|
||
|
||
## 填表指引文档
|
||
|
||
用户要求生成"填表指引/调表指引"时，按在线申请表「软件开发信息」的 12 个系统字段
|
||
逐项输出（字段名以中国版权保护中心系统实际为准），每项含
|
||
「可直接粘贴的填写内容 + 填写要点」：
|
||
|
||
1. 开发的硬件环境（开发机配置，按实际开发电脑填写）
|
||
2. 运行的硬件环境（目标设备，要求写低一些以扩大兼容范围）
|
||
3. 开发该软件的操作系统
|
||
4. 软件开发环境 / 开发工具（引擎编辑器、IDE、平台调试工具等，列主要项即可）
|
||
5. 该软件的运行平台 / 操作系统
|
||
6. 软件运行支撑环境 / 支持软件（如宿主 App、云服务）
|
||
7. 编程语言（主语言；勿把 JSON/配置格式算作语言）
|
||
8. 源程序量（与提交材料逻辑一致）
|
||
9. 开发目的（如实填写，不夸大商业目标）
|
||
10. 面向领域 / 行业（按系统下拉选项就近选择，游戏软件归文化娱乐类）
|
||
11. 软件的主要功能（500 字以上，系统要求；覆盖各功能模块，游戏术语、书面语）
|
||
12. 软件的技术特点（150-250 字）
|
||
|
||
**易错提示（必须写进指引）**：第 1/2 项（开发 vs 运行硬件）、第 3/5 项（开发 vs
|
||
运行操作系统）是两对容易填反的字段，审查员会核对逻辑一致性。
|
||
|
||
指引还应包含：办理入口与实名认证、在线填报步骤、鉴别材料上传要求与 PDF 命名规范、
|
||
提交前自检清单（checkbox）、常见退回原因与规避（已处理项标 ✅）、时间线参考、
|
||
材料重新生成命令。
|
||
|
||
## 关键规则
|
||
|
||
- 所有对外材料一律使用「本软件」指代软件本身，不出现具体产品名
|
||
- 不夸大功能，不杜撰用户量、市场数据
|
||
- 著作权人姓名 / 单位名必须与证件完全一致，提醒用户核对
|
||
- 软件分类影响描述模板：游戏软件用玩家、关卡、战斗等术语；其他软件用用户、模块、接口、权限等术语
|
||
- 写作风格：书面语、句式完整、不使用口语化表达
|
||
|
||
## 输出格式
|
||
|
||
每次回复使用以下结构：
|
||
|
||
```
|
||
📋 当前进度：<阶段>
|
||
✅ 已收集：<字段列表>
|
||
⏳ 待补充：<字段列表>
|
||
📝 下一步建议：<具体动作>
|
||
```
|
||
|
||
材料生成完毕后，附上"提交前自检清单"和"官方办理入口"提示（[中国版权保护中心](https://www.ccopyright.com.cn)）。
|
||
|
||
## 项目代码参考
|
||
|
||
实现细节可参考 `src/lib/core.ts` 中的以下函数：
|
||
- `buildSummary(p)`：生成填报速查表
|
||
- `buildManual(p, type, modules)`：生成说明书
|
||
- `reviewCode(input)`：源程序提交前检查规则
|
||
- `paginateCode(code, linesPerPage, keepHeadTail)`：源程序分页逻辑
|
||
- `FEATURE_TEMPLATES` / `TECH_TEMPLATES`：主要功能与技术特点模板
|
||
- `HARDWARE_PRESETS` / `OS_PRESETS` / `LANGUAGE_PRESETS`：硬件/软件/语言常用片段
|