software-copyright

name	software-copyright
description	自动生成计算机软件著作权申请资料

软著资料生成 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 命令执行（排除依赖库且去除空行）：

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. 提取要求（严格执行）：

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. 扫描未列入的源代码文件：

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

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

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

验证报告模板：

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

| 验证项 | 目标值 | 实际值 | 状态 |
|--------|--------|--------|------|
| 前部代码行数 | ≥ 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 结构：

#### {模块名称}

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

**操作步骤**

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 格式。可选将使用说明书也转换。

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

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

8.4 生成完成提示

## ✓ 软著资料生成完成

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

📄 文件清单：
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. 后续指导：提示用户补充截图

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

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