raidenfc 软著资料生成 Skill
概述
此 Skill 用于自动分析项目代码和文档，生成计算机软件著作权申请所需的资料。
工作模式：采用渐进式生成，分为两大阶段：
- 规划阶段：分析项目并生成《软著规划书》，用户确认后进入执行阶段
- 执行阶段：基于规划书逐步生成三类资料文档
最终产物：
- 软著主文档
- 代码文档（60 页）
- 使用说明书
使用方式
当用户提到需要生成软件著作权申请材料、申请资料或类似请求时，调用此 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 优先读取以下文档
contexts/context.md- 项目核心上下文README.md- 项目概述.doc/repowiki/系统概述.md- 系统概述.doc/repowiki/功能模块详解/- 功能模块文档docs/目录下的其他文档
3.2 提取关键信息
- 项目背景和开发目的
- 主要功能模块列表
- 技术特点和创新点
- 系统架构说明
3.3 深度功能挖掘（重点执行）
普通文档分析容易遗漏后台和辅助功能。必须执行以下深度扫描，找出“不容易发现的功能”：
管理端/后台隐形功能：
- 扫描关键词：
admin,manage,system,config,auth,role,log. - 查找目标：
- 权限体系：角色管理、用户授权、菜单配置、部门管理。
- 系统运维：操作日志、登录日志、异常监控、系统参数设置。
- 基础配置：数据字典、公告发布、版本管理、广告位管理。
- 扫描关键词：
从依赖库推断技术功能：
- 检查
package.json/pom.xml/go.mod等依赖文件。 redis-> 缓存加速 / 高并发处理jwt/security-> 多重身份认证 / 接口安全防护oss/cos-> 海量文件云存储schedule/cron-> 自动化定时任务websocket/socket-> 实时消息推送excel/csv-> 数据批量导入导出
- 检查
用户端辅助功能：
- 个人中心：修改密码、绑定手机、实名认证、地址管理。
- 互动功能：收藏/关注、评论/点赞、分享转发、积分足迹。
- 服务支持：在线客服、帮助中心、意见反馈、关于我们。
第四步：生成软著规划书（关键中间产物）
基于前三步收集的信息，生成《软著规划书.md》并保存到输出目录。
4.1 读取规划书模板
读取模板文件：
{SKILL_DIR}/templates/planning_doc_template.md
4.2 生成代码文件索引（核心逻辑）
扫描与清洗统计
- 遍历源码文件，对每个文件执行
grep -v "^\s*$"统计有效行数。 - 注意：必须使用清洗后的行数，否则生成的文档行数将不足。
- 遍历源码文件，对每个文件执行
文件排序与筛选
- 按照 高权重 → 普通权重 → 低权重 的顺序排列文件。权重定义如下：
权重 文件类型 说明 高优 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）。
数据准备
- 准备 file_list 数据，包含：文件路径、单文件行数、当前累计行数。
4.3 生成功能模块清单（核心关键）
分析代码提取功能模块。必须严格区分“用户端”与“管理端”的代码来源，严禁混用。
步骤 0：前端路由分析与去重（必须执行）
在提取功能之前，必须先分析前端路由文件，以"页面"为维度进行归纳，避免遗漏或机械式重复。
- 定位路由文件：
- 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
- Django:
- Vue/React Web: 查找
[!NOTE] 纯后端项目特殊处理：若项目完全没有前端（无
.vue,.jsx,.wxml,.html等 UI 文件），使用说明书应改为"接口使用说明"模式，按 API Endpoint 分组组织功能描述，每个 Endpoint 描述其请求方式、参数、响应及使用场景。
智能筛选与去重：
- 读取组件内容：进入路由对应的组件文件（如
.vue,.jsx），分析其 UI 和业务逻辑。 - 去重逻辑：
- 合并同类项：如果发现多个路由指向相似的页面（如
detail/:id），只归纳为一个"XX详情页"。 - 排除无效页面：忽略纯静态的协议页、过渡页或无实质功能的空白页。
- 内容审查：只有包含用户交互（表单、按钮）或动态数据展示的页面才生成模块。
- 合并同类项：如果发现多个路由指向相似的页面（如
- 读取组件内容：进入路由对应的组件文件（如
用户端（User Side）：
- 核心原则：必须优先读取前端/客户端的 UI 代码。只有在完全没有前端代码时（如纯后端渲染），才允许读取后端 Controller。
- 扫描优先级（按顺序查找）：
- 小程序/App:
.wxml,.axml,.vue(UniApp),.dart(Flutter),.swift,.kt - Web 前端:
.vue,.jsx,.tsx,.html - 模板引擎:
.blade.php,.jsp,.ejs(仅在无独立前端时使用)
- 小程序/App:
- 禁止行为：禁止使用 pure Backend Logic（如
UserLogic.php,OrderService.java）作为用户端功能的“对应代码路径”，除非该文件包含了 HTML 输出。
管理端（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 文件。
- 路由/菜单分析（前端优先）：
提取要求（严格执行）：
对于每个识别出的页面/模块，必须提取以下 5 个字段：
- 页面名称：从路由 path 或 title 提取（如
首页）。 - 功能点：页面内的主要功能列表（如
轮播图展示,推荐列表）。 - 复杂度：简单/中等/复杂。
- 代码路径：对应的组件文件路径。
- 主要操作点：基于 UI 元素的交互描述（必须包含动词）。例如：“点击‘立即购买’ -> 弹出规格选择 -> 确认支付”。
- 页面名称：从路由 path 或 title 提取（如
数量要求（尽可能全面）：
- 不要只提取最少的几个，而是尽可能覆盖路由文件中定义的业务页面。
- 用户端：建议提取 10~20 个 模块（覆盖首页、分类、购物车、个人中心、订单、设置等）。
- 管理端：建议提取 5~10 个 模块（覆盖控制台、商品、订单、用户、营销、财务、设置等）。
4.4 写入规划书
将收集的数据填充到模板中，写入 {输出目录}/软著规划书.md。
关键规则：
- 严禁修改表格表头：必须保留模板中的 6 列结构（页面名称 | 功能点 | 复杂度 | 代码路径 | 主要操作点）。
- 请勿重写表格：请直接替换模板中的
{Page_Name1}等占位符，或在占位符位置循环插入新行。 - 未识别到的字段：如果某个字段为空，请填写 "无" 或 "N/A"，不要删除列。
4.5 请求用户确认
重要：生成规划书后，必须通知用户审阅并请求确认。
通知内容应包含：
- 规划书已生成及其路径。
- 核心数据摘要：
- 预计总页数：{Total_Pages}
- 用户端模块数：{User_Modules}
- 管理端模块数：{Admin_Modules}
- 询问用户是否同意按此规划生成最终文档。
只有用户确认后，才能进入后续的"执行阶段"（第五步）。
第五步：生成软著主文档（基于规划书）
数据来源：直接读取《软著规划书.md》中的信息，不再重新分析。
- 读取数据：从规划书中提取基本信息、硬件环境、软件环境、源程序量（总行数）、主要功能列表、技术特点。
- 读取模板：
templates/main_doc.md - 填充生成：将提取的数据填充到模板中。
- 保存文件：文件名
{软件名称}_{开发完成日期}.md。
参考标准的软著文档结构：
- 开发的硬件环境
- 运行的硬件环境
- 开发该软件的操作系统
- 软件开发环境 / 开发工具
- 该软件的运行平台 / 操作系统
- 软件运行支撑环境 / 支持软件
- 源程序量
- 开发目的
- 面向领域 / 行业
- 软件的主要功能
- 软件的技术特点
- 代码文档（占位）
- 文档鉴别材料（占位）
硬件环境推断规则
如果项目文档中未明确说明，可使用以下默认值：
开发环境（个人电脑）
- 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 读取规划书与准备
- 读取
软著规划书.md，提取4.1 前 30 页文件列表和4.2 后 30 页文件列表。 - 确认生成模式：
- 若
Effective_Line_Count >= 3000→ 分页模式（前 30 页 + 后 30 页） - 若
Effective_Line_Count < 3000→ 全量模式（输出所有代码）
- 若
[!NOTE] 页数计算说明：规划阶段按每页 53 行预估分页（含安全余量），实际在 Word 中排版后每页应 ≥ 50 行。
6.2 代码清洗规则（严格执行）
在读取每个源代码文件内容后，由 AI 在内存中执行以下清洗，然后再写入文档：
敏感信息过滤（正则删除整行）：
Copyright,(c),©@author,Created byAddress:,Email:,Phone:- 具体的日期时间
TODO,FIXME,HACK,XXX等开发备注console.log,console.warn,console.error,print(),var_dump等调试语句- 硬编码的密钥、Token（包含
ApiKey,Secret,Password,Token等关键词的赋值行）
空行处理：
- 删除所有纯空行 (
^\s*$)。 - 仅保留代码和功能性注释（如类说明、方法说明）。
- 删除所有纯空行 (
6.3 执行生成（分页模式）—— 强制达标机制
[!CAUTION] 红线规则：前部和后部代码行数必须各自达到 1590 行才能停止生成。 若行数不足，禁止写入"中间省略"，必须继续添加文件直到达标。
- 写入顶部格式提示（必须执行）
- 读取并写入
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 自动补充机制（文件不足时触发）
当规划书的文件列表用尽但行数仍不足时，自动执行以下补充策略：
扫描未列入的源代码文件：
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/*"按优先级排序补充：
- 高优先级：页面组件（
pages/）、视图文件（views/） - 中优先级：通用组件（
components/）、工具函数（utils/） - 低优先级：配置文件、类型定义
- 高优先级：页面组件（
动态添加到文件列表，继续循环生成直到达标。
更新规划书：将补充的文件追加到规划书的文件列表中。
6.4 执行生成（全量模式）
如果规划书指定为全量模式：
- 写入顶部格式提示：同样先写入
templates/code_material.md中的格式设置提示。 - 写入标题
# 全部代码。 - 遍历列表中的所有文件，逐个清洗写入，不做截断。
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 读取规划书与准备
- 读取
软著规划书.md，提取5.1 用户端功能和5.2 管理端功能清单。 - 识别每个模块的复杂度（简单/中等/复杂）和对应代码路径。
- 读取模板：
templates/user_manual.md。
7.2 逐模块生成流程
核心原则：像素级 UI 还原 + 业务逻辑串联。不能只写“功能介绍”，必须写“使用流程”。
准备工作：
准备两个内容块变量：User_Content_Block 和 Admin_Content_Block。
对清单中的每个模块，执行以下深度扫描与生成步骤：
读取源码（强制 UI 优先）：
- 读取该模块对应的 UI 界面代码（.vue, .wxml, .jsx 等）。
- 如果源码引用了子组件，必须推断子组件的含义，或者有条件时进一步查看子组件。
深度解析 UI（像素级扫描）： 你必须要在脑海中构建出页面画面，提取所有可见元素：
- 交互控件：提取所有 Button（文案是什么？）、Input（Placeholder是什么？）、Select（选项有哪些？）、Checkbox/Switch。
- 展示信息：提取页面展示的关键字段（如：订单号、金额、红色高亮的状态文字）。
- 反馈机制：提取 Toast 提示、Modal 弹窗、Validator 错误红字。
关联业务逻辑：
- 如果代码中调用了 API（如
api.submitOrder()），根据 API 命名推断后台发生了什么（如：扣减库存、创建记录）。
- 如果代码中调用了 API（如
生成详细内容： 基于上述提取的信息，编写详细的操作步骤。绝不允许一笔带过（例如：“用户填写信息后提交”是不合格的）。
合格示例：
“用户在界面顶部点击‘筛选’按钮，在弹出的下拉菜单中选择‘已发货’状态。列表自动刷新后，用户找到目标订单，点击右侧红色的‘确认收货’按钮。系统弹出二次确认弹窗‘是否确认收到商品？’，用户点击‘确定’后，系统提示‘操作成功’并自动跳转至评价页面。”
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 关键写作要求（红线规则）
拒绝冷冰冰：
- ❌ "点击提交按钮。"
- ✅ "用户确认信息无误后，点击'提交'按钮，系统将自动验证数据并保存。"
强化逻辑闭环：
- 必须遵循
前置条件 -> 用户动作 -> 系统响应 -> 后续状态的链条。 - 使用 "首先"、"接着"、"随后"、"完成后" 等连接词。
- 必须遵循
拒绝简略描述（详细化要求）：
- ❌ 错误示范：“进入页面，填写信息，点击保存。”（太简略，不知道填了什么，点了哪个按钮）
- ✅ 正确示范（需包含 UI 细节）： “用户进入个人中心，点击头像下方的‘编辑资料’图标。在编辑页面中，用户可以点击头像区域触发‘更换头像’弹窗，选择本地图片上传；随后在‘昵称’输入框中修改名称（支持 emoji）。修改完成后，点击底部深蓝色的‘保存修改’长按钮，若格式正确，顶部弹出‘保存成功’绿色提示条。”
能够反映业务深度：
- 结合代码逻辑，描述数据流转。例如不只是“点击支付”，而是“点击支付唤起微信收银台，支付成功后系统自动扣除优惠券并生成核销码”。
7.5 生成后验证与处理
生成使用说明书后，必须执行以下检查：
验证清单：
- 用户端是否包含 ≥ 5 个模块？
- 管理端是否包含 ≥ 3 个模块？
- 复杂模块是否有"使用场景"？
- 简单模块描述是否清晰完整？
- 是否消除了所有
{占位符}？ - 描述是否包含"系统响应"？
验证不通过处理：
- 如果字数不足或描述过于简单，必须重新生成该模块。
- 如果缺少模块，从规划书中补充更多模块。
7.6 最终检查清单
- 确认文档结构完整
- 确认所有占位符已替换
- 确认截图位置已标记
文件名
{软件名称}_使用说明书.md
7.7 组装与最终生成（关键）
读取模板：读取
templates/user_manual.md的完整原始内容。清洗示例内容（核心步骤）：
- 清除用户端示例：保留
### 1.1 用户端功能标题，但删除该标题之后、### 1.2 管理端功能标题之前的所有内容（包括模板中的 "1.1.1 注册登录"、"1.1.2 商品浏览" 等所有示例章节）。 - 清除管理端示例：保留
### 1.2 管理端功能标题，但删除该标题之后、## 附录标题之前的所有内容（包括模板中的 "1.2.1 管理员登录"、"1.2.2 商品管理" 等所有示例章节）。
- 清除用户端示例：保留
执行组装：
- 在
### 1.1 用户端功能标题下方，插入生成的User_Content_Block。 - 在
### 1.2 管理端功能标题下方，插入生成的Admin_Content_Block。 - 替换全文中的
{软件名称},{版本号},{编制日期}等基本信息占位符。 - 保留：文档头部信息、版权声明（如有）、以及 此处未被删除的附录部分。
- 在
保存文件：
- 将组装好并替换完成的完整内容保存为
{软件名称}_使用说明书.md。
- 将组装好并替换完成的完整内容保存为
7.8 生成提示
✓ 使用说明书已基于模板组装完成
ℹ 已分析项目代码，提取了 {X} 个用户端功能模块和 {Y} 个管理端功能模块
! 请注意：您需要手动补充功能截图，标记为【需补充截图】的位置
第八步：输出与转换
8.1 创建输出目录
默认路径：{项目根目录}/软著资料/
8.2 保存 Markdown 文件
保存以下文件。务必删除模板顶部的 <!-- ... --> 警告块。
{软件名称}_{日期}.md- 软著主文档{软件名称}_代码文档.md- 代码鉴别材料{软件名称}_使用说明书.md- 使用说明书框架
8.3 转换为 Word (Pandoc)
检测 Pandoc： 运行
pandoc --version检查是否安装。执行转换： 如果检测到 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 的核心流程：
- 信息收集：询问用户软件名称、单位等基本信息
- 规划先行：分析项目结构，生成《软著规划书》并计算代码页数
- 用户确认：展示规划书，确认功能模块和文件清单无误
- 执行生成：基于规划书的数据，精确生成三份核心材料
- 质量验证：生成的每份文档都经过清洗规则和质量标准的自动验证
- 后续指导：提示用户补充截图
核心思想：通过"规划书"将复杂的生成任务解耦，确保源代码行数达标、功能描述详实。
确保每个步骤都清晰告知用户进度，遇到不确定的信息主动询问。