# Software Copyright

> 自动生成计算机软件著作权申请资料

- Skill: `raidenfc/software-copyright` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add raidenfc/software-copyright`
- Raw SKILL.md: https://api.skillmd.com/api/skills/raidenfc/software-copyright/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: raidenfc (https://skillmd.com/u/raidenfc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/raidenfc/software-copyright

---


# 软著资料生成 Skill

## 概述

此 Skill 用于自动分析项目代码和文档，生成计算机软件著作权申请所需的资料。

**工作模式**：采用渐进式生成，分为两大阶段：

1. **规划阶段**：分析项目并生成《软著规划书》，用户确认后进入执行阶段
2. **执行阶段**：基于规划书逐步生成三类资料文档

**最终产物**：

1. 软著主文档
2. 代码文档（60 页）
3. 使用说明书

---

## 使用方式

当用户提到需要生成软件著作权申请材料、申请资料或类似请求时，调用此 Skill。

### 工具使用策略

本 Skill 使用以下工具完成各项操作（优先使用原生工具，不可用时 fallback 到 shell）：

| 操作 | 首选工具 | Fallback |
|------|----------|----------|
| 列出目录 | `list_dir` | `ls -la` / `find` |
| 查找文件 | `find_by_name` / `grep_search` | `rg --files` / `find` |
| 读取文件 | `view_file` | `cat` |
| 写入文件 | `write_to_file` | shell 重定向 |
| 执行命令 | `run_command` | — |
| 通知用户 | `notify_user` | — |

---

## 执行步骤

### 第一步：收集用户基本信息

**立即询问用户以下必填信息**，不要跳过此步骤：

```
请提供以下软著申请信息：

1. 软件全称（必填）：
   - 规则：必须以“软件”、“APP”、“系统”、“平台”结尾（小程序可例外）。
   - 注意：中英文之间**不能有空格**。
   示例：享赋臻品商城系统

2. 编制单位名称（必填）：
   示例：某某科技有限公司

3. 软件版本号（必填）：
   - 规则：格式需规范，推荐格式：`V1.0` 或 `1.0`。
   示例：V1.0

4. 开发完成日期（必填，格式：YYYY年MM月）：
   示例：2024年6月

5. 开发方式（必填，请选择）：
   - 独立开发
   - 合作开发
   - 委托开发

6. 面向行业/领域（选填）：
   示例：零售商场、酒店预订、餐饮服务、电器销售
   （如不提供，我将根据项目分析推断）

7. 交付目录（选填）：
   默认：项目根目录/软著资料/
   （如需自定义请提供绝对路径）
```

**重要**：在用户回答完这些问题之前，不要进行任何项目分析。

---

### 第二步：分析项目结构

收集用户信息后，开始分析项目：

#### 2.1 确定项目根目录

- 查看用户当前工作区路径
- 确认项目根目录位置

**Monorepo 检测**：检查项目根目录是否存在 `pnpm-workspace.yaml`、`lerna.json`、或根目录下多个 `package.json`（如 `apps/`、`packages/` 子目录各有独立 `package.json`）。若为 Monorepo 项目，询问用户选择：

- a) 指定某个子项目（如 `apps/web`）作为扫描目标
- b) 合并扫描所有子项目

#### 2.2 扫描项目文件结构

使用 `list_dir` / `find_by_name` 扫描（不可用时 fallback 到 `rg --files`、`find`）：

- 主要源代码目录：`src/`, `app/`, `lib/`, `server/`, `mobile/`, `admin/` 等
- 配置文件：`package.json`, `composer.json`, `go.mod`, `pom.xml`, `requirements.txt` 等
- 文档目录：`.doc/`, `docs/`, `wiki/`, `README.md`, `contexts/` 等

#### 2.3 识别技术栈

根据文件特征判断：

- **前端**：React, Vue, Angular, Next.js, Nuxt.js 等
- **后端**：Node.js, PHP, Go, Java, Python 等
- **小程序**：UniApp, 微信小程序原生等
- **数据库**：MySQL, PostgreSQL, MongoDB 等
- **其他**：Nginx, Redis, Docker 等

#### 2.4 统计代码行数（有效行数）

使用 shell 命令执行（排除依赖库且去除空行）：

```bash
find . -type f \( \
    -name "*.js" -o -name "*.jsx" -o -name "*.ts" -o -name "*.tsx" \
    -o -name "*.vue" -o -name "*.go" -o -name "*.php" -o -name "*.java" -o -name "*.py" \
    -o -name "*.css" -o -name "*.scss" -o -name "*.less" \
    -o -name "*.html" -o -name "*.json" \
    -o -name "*.wxml" -o -name "*.wxss" -o -name "*.wxs" \
    -o -name "*.swift" -o -name "*.kt" -o -name "*.dart" \
    -o -name "*.sql" -o -name "*.sh" -o -name "*.yaml" -o -name "*.yml" \
    \) \
    -not -path "*/node_modules/*" \
    -not -path "*/dist/*" \
    -not -path "*/vendor/*" \
    -not -path "*/.git/*" \
    -not -path "*/.venv/*" \
    -not -path "*/__pycache__/*" \
    -not -path "*/target/*" \
    -not -path "*/build/*" \
    -not -path "*/.next/*" \
    -not -path "*/.nuxt/*" \
    -not -path "*/miniprogram_npm/*" \
    -not -path "*/.taro/*" \
    -not -path "*/coverage/*" \
    -not -path "*/.cache/*" \
    -not -path "*/public/*" \
    -not -path "*/migrations/*" \
    -exec grep -v "^\s*$" {} + 2>/dev/null | wc -l
```

> [!TIP]
> 上述扩展名列表覆盖了大部分常见技术栈。如有特殊文件类型（如 `.rs`, `.rb`, `.lua` 等），可根据项目实际情况增删。

**注意**：此命令统计的是**去除空行后的有效代码行数**。
将此结果记录为 `Effective_Line_Count`。

---

### 第三步：读取项目文档

#### 3.1 优先读取以下文档

1. `contexts/context.md` - 项目核心上下文
2. `README.md` - 项目概述
3. `.doc/repowiki/系统概述.md` - 系统概述
4. `.doc/repowiki/功能模块详解/` - 功能模块文档
5. `docs/` 目录下的其他文档

#### 3.2 提取关键信息

- 项目背景和开发目的
- 主要功能模块列表
- 技术特点和创新点
- 系统架构说明

#### 3.3 深度功能挖掘（重点执行）

普通文档分析容易遗漏后台和辅助功能。**必须**执行以下深度扫描，找出“不容易发现的功能”：

1. **管理端/后台隐形功能**：
   - **扫描关键词**：`admin`, `manage`, `system`, `config`, `auth`, `role`, `log`.
   - **查找目标**：
     - **权限体系**：角色管理、用户授权、菜单配置、部门管理。
     - **系统运维**：操作日志、登录日志、异常监控、系统参数设置。
     - **基础配置**：数据字典、公告发布、版本管理、广告位管理。

2. **从依赖库推断技术功能**：
   - 检查 `package.json` / `pom.xml` / `go.mod` 等依赖文件。
   - `redis` -> 缓存加速 / 高并发处理
   - `jwt` / `security` -> 多重身份认证 / 接口安全防护
   - `oss` / `cos` -> 海量文件云存储
   - `schedule` / `cron` -> 自动化定时任务
   - `websocket` / `socket` -> 实时消息推送
   - `excel` / `csv` -> 数据批量导入导出

3. **用户端辅助功能**：
   - **个人中心**：修改密码、绑定手机、实名认证、地址管理。
   - **互动功能**：收藏/关注、评论/点赞、分享转发、积分足迹。
   - **服务支持**：在线客服、帮助中心、意见反馈、关于我们。

---

### 第四步：生成软著规划书（关键中间产物）

基于前三步收集的信息，生成《软著规划书.md》并保存到输出目录。

#### 4.1 读取规划书模板

读取模板文件：
`{SKILL_DIR}/templates/planning_doc_template.md`

#### 4.2 生成代码文件索引（核心逻辑）

1. **扫描与清洗统计**
    - 遍历源码文件，对每个文件执行 `grep -v "^\s*$"` 统计**有效行数**。
    - **注意**：必须使用**清洗后**的行数，否则生成的文档行数将不足。

2. **文件排序与筛选**
    - 按照 **高权重 → 普通权重 → 低权重** 的顺序排列文件。权重定义如下：

    | 权重 | 文件类型 | 说明 |
    |------|----------|------|
    | 高优 | `main.*`, `app.*`, `index.*`, `router.*`, `App.vue`, `app.json` | 入口文件和路由配置 |
    | 普通 | `pages/`, `views/`, `components/`, `modules/`, `screens/` | 页面和组件 |
    | 低优 | `utils/`, `helpers/`, `config/`, `types/`, `constants/`, `store/` | 工具、配置、类型定义 |

    - **前 30 页选择**：从头部开始累加，直到累计行数 ≥ 1590 行（`FRONT_LINES`）。
    - **后 30 页选择**：从尾部倒推，直到累计行数 ≥ 1590 行（`BACK_LINES`）。

3. **数据准备**
    - 准备 file_list 数据，包含：文件路径、单文件行数、当前累计行数。

#### 4.3 生成功能模块清单（核心关键）

分析代码提取功能模块。**必须严格区分“用户端”与“管理端”的代码来源，严禁混用。**

**步骤 0：前端路由分析与去重（必须执行）**

在提取功能之前，**必须先分析前端路由文件**，以"页面"为维度进行归纳，避免遗漏或机械式重复。

1. **定位路由文件**：
   - **Vue/React Web**: 查找 `src/router/index.js`, `src/routes.ts`, `src/app-routing.module.ts` 或类似文件。
   - **Mini-program**: 查找 `app.json`, `pages.json`。
   - **Next.js/Nuxt.js**: 扫描 `pages/` 或 `app/` 目录下的文件结构。
   - **纯后端项目**（无前端 UI 文件时），按以下方式定位路由等效文件：
     - **Django**: `urls.py` 路由定义
     - **Flask**: `@app.route` 装饰器扫描
     - **Spring Boot**: `@RequestMapping` / `@GetMapping` 注解扫描
     - **Go Gin/Echo**: `router.GET/POST` 注册
     - **Express/Koa**: `router.get/post` 或 `app.get/post` 注册
     - **Laravel**: `routes/web.php`, `routes/api.php`

> [!NOTE]
> **纯后端项目特殊处理**：若项目完全没有前端（无 `.vue`, `.jsx`, `.wxml`, `.html` 等 UI 文件），使用说明书应改为"接口使用说明"模式，按 API Endpoint 分组组织功能描述，每个 Endpoint 描述其请求方式、参数、响应及使用场景。

1. **智能筛选与去重**：
   - **读取组件内容**：进入路由对应的组件文件（如 `.vue`, `.jsx`），分析其 UI 和业务逻辑。
   - **去重逻辑**：
     - **合并同类项**：如果发现多个路由指向相似的页面（如 `detail/:id`），只归纳为一个"XX详情页"。
     - **排除无效页面**：忽略纯静态的协议页、过渡页或无实质功能的空白页。
     - **内容审查**：只有包含**用户交互**（表单、按钮）或**动态数据展示**的页面才生成模块。

2. **用户端（User Side）**：
   - **核心原则**：必须优先读取**前端/客户端的 UI 代码**。只有在完全没有前端代码时（如纯后端渲染），才允许读取后端 Controller。
   - **扫描优先级**（按顺序查找）：
     1. **小程序/App**: `.wxml`, `.axml`, `.vue` (UniApp), `.dart` (Flutter), `.swift`, `.kt`
     2. **Web 前端**: `.vue`, `.jsx`, `.tsx`, `.html`
     3. **模板引擎**: `.blade.php`, `.jsp`, `.ejs` (仅在无独立前端时使用)
   - **禁止行为**：禁止使用 pure Backend Logic（如 `UserLogic.php`, `OrderService.java`）作为用户端功能的“对应代码路径”，除非该文件包含了 HTML 输出。

3. **管理端（Admin Side）**：
   - **路由/菜单分析（前端优先）**：
     - **首选**：寻找 **管理后台的前端路由**（如 `router/admin.js`, `src/admin/routes.ts`）或 **菜单配置文件**（如 `menuConfig.js`, `layout/sider.tsx`）。
     - **次选**（仅当无独立前端时）：分析 MVC 框架的 Admin 路由（如 `routes/admin.php`）和 Controller 结构。
   - **页面归纳**：
     - **核心原则**：必须按**前端页面**视角归纳。例如"商品列表页"和"商品编辑页"是两个页面，而不是简单的"商品管理"一个大模块。
     - 将前端路由中的 `path` 映射为一个功能页面。
   - 优先寻找 `admin`, `manager`, `backend` 目录下的界面代码或 View 文件。

4. **提取要求（严格执行）**：
   - 对于每个识别出的页面/模块，**必须**提取以下 5 个字段：
     1. **页面名称**：从路由 path 或 title 提取（如 `首页`）。
     2. **功能点**：页面内的主要功能列表（如 `轮播图展示`, `推荐列表`）。
     3. **复杂度**：简单/中等/复杂。
     4. **代码路径**：对应的组件文件路径。
     5. **主要操作点**：基于 UI 元素的交互描述（必须包含动词）。例如：“点击‘立即购买’ -> 弹出规格选择 -> 确认支付”。

   - **数量要求（尽可能全面）**：
     - **不要只提取最少的几个**，而是尽可能覆盖路由文件中定义的业务页面。
     - **用户端**：建议提取 **10~20 个** 模块（覆盖首页、分类、购物车、个人中心、订单、设置等）。
     - **管理端**：建议提取 **5~10 个** 模块（覆盖控制台、商品、订单、用户、营销、财务、设置等）。

#### 4.4 写入规划书

将收集的数据填充到模板中，写入 `{输出目录}/软著规划书.md`。

**关键规则**：

- **严禁修改表格表头**：必须保留模板中的 6 列结构（页面名称 | 功能点 | 复杂度 | 代码路径 | 主要操作点）。
- **请勿重写表格**：请直接替换模板中的 `{Page_Name1}` 等占位符，或在占位符位置循环插入新行。
- **未识别到的字段**：如果某个字段为空，请填写 "无" 或 "N/A"，不要删除列。

#### 4.5 请求用户确认

**重要**：生成规划书后，**必须**通知用户审阅并请求确认。

通知内容应包含：

1. 规划书已生成及其路径。
2. 核心数据摘要：
   - 预计总页数：{Total_Pages}
   - 用户端模块数：{User_Modules}
   - 管理端模块数：{Admin_Modules}
3. 询问用户是否同意按此规划生成最终文档。

**只有用户确认后，才能进入后续的"执行阶段"（第五步）。**

---

### 第五步：生成软著主文档（基于规划书）

**数据来源**：直接读取《软著规划书.md》中的信息，不再重新分析。

1. **读取数据**：从规划书中提取基本信息、硬件环境、软件环境、源程序量（总行数）、主要功能列表、技术特点。
2. **读取模板**：`templates/main_doc.md`
3. **填充生成**：将提取的数据填充到模板中。
4. **保存文件**：文件名 `{软件名称}_{开发完成日期}.md`。

参考标准的软著文档结构：

1. 开发的硬件环境
2. 运行的硬件环境
3. 开发该软件的操作系统
4. 软件开发环境 / 开发工具
5. 该软件的运行平台 / 操作系统
6. 软件运行支撑环境 / 支持软件
7. 源程序量
8. 开发目的
9. 面向领域 / 行业
10. 软件的主要功能
11. 软件的技术特点
12. 代码文档（占位）
13. 文档鉴别材料（占位）

#### 硬件环境推断规则

如果项目文档中未明确说明，可使用以下默认值：

**开发环境（个人电脑）**

- CPU：4核
- 内存：8GB
- 系统盘：256GB SSD
- 带宽：100Mbps

**运行环境（服务器）**

- 小型项目：CPU 2核，内存 4GB，系统盘 100GB SSD，带宽 5Mbps
- 中型项目：CPU 4核，内存 8GB，系统盘 200GB SSD，带宽 10Mbps
- 大型项目：CPU 8核，内存 16GB，系统盘 500GB SSD，带宽 20Mbps

---

### 第六步：生成代码文档（基于规划书）

**核心逻辑**：严格按照《软著规划书.md》中的文件索引逐个读取，**实时累计行数**，确保精确达标。

#### 6.1 读取规划书与准备

1. 读取 `软著规划书.md`，提取 `4.1 前 30 页文件列表` 和 `4.2 后 30 页文件列表`。
2. 确认生成模式：
   - 若 `Effective_Line_Count >= 3000` → **分页模式**（前 30 页 + 后 30 页）
   - 若 `Effective_Line_Count < 3000` → **全量模式**（输出所有代码）

> [!NOTE]
> **页数计算说明**：规划阶段按每页 **53 行**预估分页（含安全余量），实际在 Word 中排版后每页应 ≥ **50 行**。

#### 6.2 代码清洗规则（严格执行）

在读取每个源代码文件内容后，**由 AI 在内存中执行以下清洗**，然后再写入文档：

1. **敏感信息过滤**（正则删除整行）：
    - `Copyright`, `(c)`, `©`
    - `@author`, `Created by`
    - `Address:`, `Email:`, `Phone:`
    - 具体的日期时间
    - `TODO`, `FIXME`, `HACK`, `XXX` 等开发备注
    - `console.log`, `console.warn`, `console.error`, `print()`, `var_dump` 等调试语句
    - 硬编码的密钥、Token（包含 `ApiKey`, `Secret`, `Password`, `Token` 等关键词的赋值行）

2. **空行处理**：
    - **删除所有纯空行** (`^\s*$`)。
    - 仅保留代码和功能性注释（如类说明、方法说明）。

#### 6.3 执行生成（分页模式）—— 强制达标机制

> [!CAUTION]
> **红线规则**：前部和后部代码行数**必须各自达到 1590 行**才能停止生成。
> 若行数不足，**禁止**写入"中间省略"，必须继续添加文件直到达标。

1. **写入顶部格式提示（必须执行）**
   - 读取并写入 `templates/code_material.md` 文件头部的 Word 格式设置提示（即 `---` 包裹的引用块）。
   - 确保包含“页眉设置”、“字体设置”等关键信息。

**A. 生成前 30 页（强制循环机制）**

```
初始化：accumulated_lines = 0, file_index = 0

WHILE accumulated_lines < 1590:
    1. 从前部文件列表取第 file_index 个文件
    2. 若文件列表已用尽 → 执行【自动补充机制】
    3. 读取文件内容
    4. 执行代码清洗（删除空行、敏感信息）
    5. 计算清洗后行数 file_lines
    6. 写入文件头注释：## 文件：{相对路径}
    7. 写入代码块（带语法高亮）
    8. accumulated_lines += file_lines
    9. 输出进度日志：[前部] 文件 {n}: {filename} | +{file_lines}行 | 累计: {accumulated_lines}/1590
    10. file_index++

结束条件：仅当 accumulated_lines >= 1590 时退出循环
记录：Actual_Front_Lines = accumulated_lines
```

**B. 达标校验门禁（写入中间省略前必须通过）**

在写入"中间省略"之前，**必须**通过以下检查：

| 检查项 | 条件 | 未通过处理 |
|--------|------|------------|
| 前部行数 | `Actual_Front_Lines >= 1590` | 返回步骤 A 继续添加文件 |
| 文件列表 | 仍有可用文件 | 执行【自动补充机制】获取更多文件 |

**只有检查全部通过，才能写入**：`\n\n... (中间代码省略) ...\n\n`

**C. 生成后 30 页（强制循环机制）**

```
初始化：accumulated_lines = 0, file_index = 0

WHILE accumulated_lines < 1590:
    1. 从后部文件列表取第 file_index 个文件
    2. 若文件列表已用尽 → 执行【自动补充机制】
    3. 读取文件内容
    4. 执行代码清洗
    5. 计算清洗后行数 file_lines
    6. 写入文件头注释：## 文件：{相对路径}
    7. 写入代码块
    8. accumulated_lines += file_lines
    9. 输出进度日志：[后部] 文件 {n}: {filename} | +{file_lines}行 | 累计: {accumulated_lines}/1590
    10. file_index++

结束条件：仅当 accumulated_lines >= 1590 时退出循环
记录：Actual_Back_Lines = accumulated_lines
```

**重要**：必须包含最后一个文件的最后一行代码，确保文档自然结束。

#### 6.3.1 自动补充机制（文件不足时触发）

当规划书的文件列表用尽但行数仍不足时，**自动**执行以下补充策略：

1. **扫描未列入的源代码文件**：

   ```bash
   find {项目目录} -type f \( -name "*.vue" -o -name "*.js" -o -name "*.ts" -o -name "*.php" -o -name "*.go" \) \
       -not -path "*/node_modules/*" -not -path "*/vendor/*" -not -path "*/dist/*"
   ```

2. **按优先级排序补充**：
   - **高优先级**：页面组件（`pages/`）、视图文件（`views/`）
   - **中优先级**：通用组件（`components/`）、工具函数（`utils/`）
   - **低优先级**：配置文件、类型定义

3. **动态添加到文件列表**，继续循环生成直到达标。

4. **更新规划书**：将补充的文件追加到规划书的文件列表中。

#### 6.4 执行生成（全量模式）

如果规划书指定为全量模式：

1. **写入顶部格式提示**：同样先写入 `templates/code_material.md` 中的格式设置提示。
2. 写入标题 `# 全部代码`。
3. 遍历列表中的所有文件，逐个清洗写入，**不做截断**。

#### 6.5 生成后验证（强制门禁 —— 必须全部通过）

> [!IMPORTANT]
> **验证是强制门禁**：任何一项不通过都**禁止**标记代码文档生成任务为完成。
> 必须立即执行修复措施，直到所有项目通过为止。

生成代码文档后，**立即**执行以下验证：

```text
验证任务：
1. 使用 wc -l 统计实际生成的行数
2. 计算实际页数 = 总行数 ÷ 53
3. 检查是否达标（所有项必须通过）
4. 输出验证报告
```

**验证报告模板**：

```markdown
## 代码文档生成验证报告

| 验证项 | 目标值 | 实际值 | 状态 |
|--------|--------|--------|------|
| 前部代码行数 | ≥ 1590 行 | {Actual_Front_Lines} 行 | {✅/❌} |
| 后部代码行数 | ≥ 1590 行 | {Actual_Back_Lines} 行 | {✅/❌} |
| 总源代码行数 | ≥ 3180 行 | {Total_Lines} 行 | {✅/❌} |
| 预估总页数 | ≥ 60 页 | {Total_Lines ÷ 53} 页 | {✅/❌} |
| 首页内容 | 入口代码 | {是/否} | {✅/❌} |
| 末页内容 | 自然结束 | {是/否} | {✅/❌} |
| 敏感信息过滤 | 无版权信息 | {是/否} | {✅/❌} |
| 空行过滤 | 无纯空行 | {是/否} | {✅/❌} |

### 验证结论
{全部通过 ✅ / 存在问题需要修正 ❌}
```

**验证失败强制处理流程**：

```
IF 任意验证项为 ❌:
    1. 分析不达标原因
    2. 确定修复方案：
       - 行数不足 → 返回 6.3.1 自动补充机制，添加更多文件
       - 空行未过滤 → 重新执行代码清洗
       - 敏感信息未过滤 → 重新执行敏感信息过滤
    3. 重新生成代码文档
    4. 再次执行验证
    5. 重复上述步骤直到 ALL 验证项为 ✅

ONLY WHEN 所有验证项为 ✅:
    → 允许标记代码文档生成任务完成
    → 允许通知用户生成成功
```

#### 6.6 最终检查清单（所有项必须勾选）

- [ ] 确认第 1 页是入口代码（main/index/app）
- [ ] 确认前 30 页行数 ≥ 1590 行
- [ ] 确认后 30 页行数 ≥ 1590 行
- [ ] 确认结束处是自然结束代码
- [ ] 确认没有任何 `Copyright` 或人名信息
- [ ] **确认代码中没有空行**（紧凑排版）
- [ ] 验证报告所有项为 ✅

#### 文件名

`{软件名称}_代码文档.md`

---

### 第七步：生成使用说明书（基于规划书）

**核心逻辑**：遍历《软著规划书.md》中的功能模块清单，按**复杂度级别**和**写作规范**逐个展开描述。

#### 7.1 读取规划书与准备

1. 读取 `软著规划书.md`，提取 `5.1 用户端功能` 和 `5.2 管理端功能` 清单。
2. 识别每个模块的**复杂度**（简单/中等/复杂）和**对应代码路径**。
3. 读取模板：`templates/user_manual.md`。

#### 7.2 逐模块生成流程

**核心原则：像素级 UI 还原 + 业务逻辑串联**。不能只写“功能介绍”，必须写“使用流程”。

**准备工作**：
准备两个内容块变量：`User_Content_Block` 和 `Admin_Content_Block`。

对清单中的每个模块，执行以下**深度扫描与生成**步骤：

1. **读取源码（强制 UI 优先）**：
   - 读取该模块对应的 **UI 界面代码**（.vue, .wxml, .jsx 等）。
   - **如果源码引用了子组件**，必须推断子组件的含义，或者有条件时进一步查看子组件。

2. **深度解析 UI（像素级扫描）**：
   你必须要在脑海中构建出页面画面，提取所有可见元素：
   - **交互控件**：提取所有 Button（文案是什么？）、Input（Placeholder是什么？）、Select（选项有哪些？）、Checkbox/Switch。
   - **展示信息**：提取页面展示的关键字段（如：订单号、金额、红色高亮的状态文字）。
   - **反馈机制**：提取 Toast 提示、Modal 弹窗、Validator 错误红字。

3. **关联业务逻辑**：
   - 如果代码中调用了 API（如 `api.submitOrder()`），根据 API 命名推断后台发生了什么（如：扣减库存、创建记录）。

4. **生成详细内容**：
   基于上述提取的信息，编写详细的操作步骤。**绝不允许**一笔带过（例如：“用户填写信息后提交”是不合格的）。

   **合格示例**：
   > “用户在界面顶部点击‘筛选’按钮，在弹出的下拉菜单中选择‘已发货’状态。列表自动刷新后，用户找到目标订单，点击右侧红色的‘确认收货’按钮。系统弹出二次确认弹窗‘是否确认收到商品？’，用户点击‘确定’后，系统提示‘操作成功’并自动跳转至评价页面。”

---

#### 7.3 生成策略与写作规范（严格执行）

**A. 复杂度分级策略**

| 维度 | 复杂功能 | 中等功能 | 简单功能 |
|------|----------|----------|----------|
| **功能概述** | 100-150 字 (3-5句) | 60-100 字 (2-3句) | 30-50 字 (1-2句) |
| **操作步骤** | 详细展开 (含前置/异常) | 标准步骤 | 简洁步骤 |
| **使用场景** | **必须有** (2-3个) | 推荐有 (1-2个) | 可省略 |
| **功能特点** | 3-5 个 | 2-3 个 | 1-2 个 |

**B. 模块结构规范**

每个功能模块必须严格遵循以下 Markdown 结构：

```markdown
#### {模块名称}

**功能概述**
{第一句核心目的}...{最后一句价值}。

**操作步骤**

1. **{步骤标题}**
   {前置条件} 用户{动作描述}，系统{响应描述}。
   - {细节补充}

2. **{步骤标题}**
   ...

**使用场景** (复杂/中等功能必需)
- **场景一**：{用户}在{背景}下，通过{操作}达到{目的}。

**功能特点**
- **特点名称**：{特点说明}
```

---

#### 7.4 关键写作要求（红线规则）

1. **拒绝冷冰冰**：
   - ❌ "点击提交按钮。"
   - ✅ "用户确认信息无误后，点击'提交'按钮，系统将自动验证数据并保存。"

2. **强化逻辑闭环**：
   - 必须遵循 `前置条件 -> 用户动作 -> 系统响应 -> 后续状态` 的链条。
   - 使用 "首先"、"接着"、"随后"、"完成后" 等连接词。

3. **拒绝简略描述（详细化要求）**：
   - ❌ **错误示范**：“进入页面，填写信息，点击保存。”（太简略，不知道填了什么，点了哪个按钮）
   - ✅ **正确示范**（需包含 UI 细节）：
     “用户进入个人中心，点击头像下方的‘编辑资料’图标。在编辑页面中，用户可以点击头像区域触发‘更换头像’弹窗，选择本地图片上传；随后在‘昵称’输入框中修改名称（支持 emoji）。修改完成后，点击底部深蓝色的‘保存修改’长按钮，若格式正确，顶部弹出‘保存成功’绿色提示条。”

4. **能够反映业务深度**：
   - 结合代码逻辑，描述数据流转。例如不只是“点击支付”，而是“点击支付唤起微信收银台，支付成功后系统自动扣除优惠券并生成核销码”。

---

#### 7.5 生成后验证与处理

生成使用说明书后，**必须**执行以下检查：

**验证清单**：

- [ ] 用户端是否包含 ≥ 5 个模块？
- [ ] 管理端是否包含 ≥ 3 个模块？
- [ ] 复杂模块是否有"使用场景"？
- [ ] 简单模块描述是否清晰完整？
- [ ] 是否消除了所有 `{占位符}`？
- [ ] 描述是否包含"系统响应"？

**验证不通过处理**：

- 如果字数不足或描述过于简单，**必须重新生成**该模块。
- 如果缺少模块，从规划书中补充更多模块。

#### 7.6 最终检查清单

- [ ] 确认文档结构完整
- [ ] 确认所有占位符已替换
- [ ] 确认截图位置已标记

#### 文件名

`{软件名称}_使用说明书.md`

#### 7.7 组装与最终生成（关键）

1. **读取模板**：读取 `templates/user_manual.md` 的完整原始内容。

2. **清洗示例内容（核心步骤）**：
   - **清除用户端示例**：保留 `### 1.1 用户端功能` 标题，但**删除**该标题之后、`### 1.2 管理端功能` 标题之前的所有内容（包括模板中的 "1.1.1 注册登录"、"1.1.2 商品浏览" 等所有示例章节）。
   - **清除管理端示例**：保留 `### 1.2 管理端功能` 标题，但**删除**该标题之后、`## 附录` 标题之前的所有内容（包括模板中的 "1.2.1 管理员登录"、"1.2.2 商品管理" 等所有示例章节）。

3. **执行组装**：
   - 在 `### 1.1 用户端功能` 标题下方，插入生成的 `User_Content_Block`。
   - 在 `### 1.2 管理端功能` 标题下方，插入生成的 `Admin_Content_Block`。
   - 替换全文中的 `{软件名称}`, `{版本号}`, `{编制日期}` 等基本信息占位符。
   - **保留**：文档头部信息、版权声明（如有）、以及 **此处未被删除的附录部分**。

4. **保存文件**：
   - 将组装好并替换完成的**完整内容**保存为 `{软件名称}_使用说明书.md`。

#### 7.8 生成提示

```
✓ 使用说明书已基于模板组装完成
ℹ 已分析项目代码，提取了 {X} 个用户端功能模块和 {Y} 个管理端功能模块
! 请注意：您需要手动补充功能截图，标记为【需补充截图】的位置
```

---

### 第八步：输出与转换

#### 8.1 创建输出目录

默认路径：`{项目根目录}/软著资料/`

#### 8.2 保存 Markdown 文件

保存以下文件。**务必删除**模板顶部的 `<!-- ... -->` 警告块。

1. `{软件名称}_{日期}.md` - 软著主文档
2. `{软件名称}_代码文档.md` - 代码鉴别材料
3. `{软件名称}_使用说明书.md` - 使用说明书框架

#### 8.3 转换为 Word (Pandoc)

1. **检测 Pandoc**：
   运行 `pandoc --version` 检查是否安装。

2. **执行转换**：
   如果检测到 pandoc，**必须**将代码文档转换为 `.docx` 格式。可选将使用说明书也转换。

   ```bash
   # 必须转换：代码文档
   pandoc "{交付目录}/{软件名称}_代码文档.md" -o "{交付目录}/{软件名称}_代码文档.docx"

   # 可选转换：使用说明书（方便用户直接插入截图）
   pandoc "{交付目录}/{软件名称}_使用说明书.md" -o "{交付目录}/{软件名称}_使用说明书.docx"
   ```

   *提示：若不使用 Pandoc，也可通过 Typora、VS Code Markdown PDF 插件等方式导出 Word/PDF 格式。*

#### 8.4 生成完成提示

```markdown
## ✓ 软著资料生成完成

已在以下目录生成资料：
📁 {输出目录路径}

📄 文件清单：
1. {软件名称}_{日期}.md - 软著主文档
2. {软件名称}_代码文档.docx - 代码文档 (请在此文件中调整排版)
3. {软件名称}_代码文档.md - 代码文档 (源文件)
4. {软件名称}_使用说明书.md - 使用说明书框架

```

## 📝 后续操作

### 1. 调整代码材料格式 (重要)

打开 `{软件名称}_代码文档.docx`：

- **全选全文**，将字体调整为 **小六号 / 8号**（或更小）。
- 确保调整字体后，每一页的代码行数 **不少于 50 行**。
- **设置页眉**：在 Word 中双击页眉区域，添加 `{软件名称} {版本号}` 和 `第 X 页`，确保与提示一致。

### 2. 补充使用说明书截图

打开 `{软件名称}_使用说明书`，在标记为【需补充截图】的位置添加功能截图。

### 3. 提交材料

所有材料需加盖公章（如为公司申请）。

```

#### 8.5 清理临时文件（重要）

1. **识别临时文件**：
   - 仅查找本次生成过程创建的临时文件，统一使用前缀命名（如 `tmp_softcopy_*.txt`、`tmp_softcopy_*.md`）。

2. **执行清理**：
   - 仅删除匹配 `tmp_softcopy_*` 前缀的临时文件。
   - **严禁删除**：`{软件名称}_代码文档.docx`、`*.md` 以及任何最终交付物。**务必保留 Word 文档**。

---

## 重要提示

### 技术特点描述参考

可从以下角度描述：

- 架构设计（前后端分离、微服务、分布式等）
- 性能优化（缓存机制、负载均衡、并发处理等）
- 安全性（数据加密、身份认证、权限管理等）
- 用户体验（响应式设计、实时更新等）
- 数据处理（大数据分析、数据可视化等）
- 跨平台支持（多端兼容、小程序/Web/App 等）

### 代码提取注意事项

- 优先选择 `.js`, `.vue`, `.go`, `.php`, `.java`, `.py` 等源代码文件
- 排除 `node_modules/`, `vendor/`, `.git/`, `dist/`, `build/`, `test/` 等目录
- 可保留功能性注释；应移除版权声明、作者姓名、联系方式等敏感信息
- 确保代码连续性，避免中途跳转

---

## 错误处理

### 如果找不到项目文档

- 提示用户项目缺少文档，建议先创建 `README.md` 或 `contexts/context.md`
- 询问用户是否可以口头描述项目功能，由你记录后生成

### 如果无法识别技术栈

- 列出发现的文件类型
- 请用户确认使用的技术栈

### 如果代码量过少

- 提示用户源程序量较少，可能不符合软著申请要求（通常需要 3000 行以上）
- 询问是否继续生成

---

## 模板引用

执行时使用以下模板文件：

- `{SKILL_DIR}/templates/planning_doc_template.md`
- `{SKILL_DIR}/templates/main_doc.md`
- `{SKILL_DIR}/templates/user_manual.md`
- `{SKILL_DIR}/templates/code_material.md`

---

## 断点恢复机制

本 Skill 执行流程较长，为防止中断导致丢失进度，每完成一个主要阶段后，自动将进度写入 `{输出目录}/.progress.json`：

```json
{
  "current_step": 5,
  "completed_steps": [1, 2, 3, 4],
  "last_updated": "2024-06-15T10:30:00",
  "outputs": {
    "planning_doc": "软著规划书.md",
    "main_doc": null,
    "code_doc": null,
    "user_manual": null
  }
}
```

**恢复逻辑**：每次启动时，检查 `{输出目录}/.progress.json` 是否存在。若存在且 `completed_steps` 不为空，询问用户是否从上次中断处继续（跳过已完成的步骤），还是重新开始。

---

## 总结

此 Skill 的核心流程：

1. **信息收集**：询问用户软件名称、单位等基本信息
2. **规划先行**：分析项目结构，生成《软著规划书》并计算代码页数
3. **用户确认**：展示规划书，确认功能模块和文件清单无误
4. **执行生成**：基于规划书的数据，精确生成三份核心材料
5. **质量验证**：生成的每份文档都经过清洗规则和质量标准的自动验证
6. **后续指导**：提示用户补充截图

**核心思想**：通过"规划书"将复杂的生成任务解耦，确保源代码行数达标、功能描述详实。

确保每个步骤都清晰告知用户进度，遇到不确定的信息主动询问。