| name | software-copyright-zh |
| description | 用于"软著项目开发、说明书生成、代码材料整理、截图演示"全流程。Use when: 软著申请、软件著作权、生成说明书、软著工作流、代码行数控制、截图演示、项目定题定边界。不适用于与软著无关的普通项目开发。 |
软著项目全流程技能
Project structure gate / 文件树结构门禁
只要本工作流将初始化或重组项目，或新建、移动应用、服务、包、模块、页面、API、研究步骤、实验、流水线、测试、文档或多文件产物树，必须先使用 project-structure-architect。
- 开始前：读取适用的
AGENTS.md、PROJECT_STRUCTURE.md、.project-structure.yaml 和现有文件树，锁定项目类型、蓝图及唯一合理路径。
- 运行中：每次新增或移动文件前先判断职责、所有者、复用范围和对应测试；禁止同义目录、根目录堆放、跨层混放及无关重组。
- 阶段收口：纵向切片或阶段完成后检查结构漂移；新项目或重大重组更新结构文档，最终运行结构审计。出现
BLOCK 时停止结构性写入并先修正或询问用户。
纯内容编辑且目标路径已由用户或现有规范唯一确定时，可不重复调用。
技能目标
将"软著项目从选题到材料提交"的完整链路固定下来，覆盖：定题定边界 → 生成可跑项目 → 控制代码体量 → 补截图与演示数据 → 生成说明书与代码材料 → 统一命名排版自检。
Markdown 交付要求
- 使用本技能完成正式输出时，除聊天中的简要说明外，必须在当前工作区新建一个 Markdown 文档保存完整结果。
- 默认保存位置为当前工作区
skill-outputs/software-copyright-zh/（与 artifact-curator-zh 按技能分子目录一致；根目录为 legacy-flat 兼容）。若该子目录不存在须先创建。
- 默认文件名格式为
中文主题_YYYYMMDD_HHMMSS.md（置于上述目录下；文件名不再重复 skill 名）；若主题不明确，使用 结果_YYYYMMDD_HHMMSS.md。
- Markdown 文档必须包含完整工作流、模块边界、说明书素材、代码材料整理建议与提交检查项。
- 若用户明确指定保存路径或文件名，以用户要求为准；若用户明确要求只在对话中回答，可跳过创建文件。
- 最终回复中要说明新建的 Markdown 文件路径（须含
skill-outputs/software-copyright-zh/ 前缀），以及文件里包含的主要内容。
任务模式判定
| 模式 | 判定条件 | 核心目标 |
|---|
| A. 定题与工作流规划 | "帮我选软著题目""走完工作流" | 选题 + 边界压缩 + 6阶段工作流 |
| B. 项目开发约束 | "生成项目代码""写后端""做前端" | 先跑通再美化，先闭环再扩展 |
| C. 说明书生成 | "生成说明书""写说明书正文" | 严格按模板结构生成正式文档 |
| D. 代码材料整理 | "整理代码材料""代码行数控制" | 核心代码 <3000行，连续编号 |
6阶段工作流（模式A核心）
第一阶段：定题与定边界
必须拍板的内容：
- 软件正式名称（格式：XXX系统 V1.0）
- 一句话定位
- 核心模块（4-8个）
- 核心数据实体（5-10张表）
- MVP主流程（1条最核心闭环）
- 明确"不做"清单
边界原则：
- 业务闭环压缩到1条主流程
- 不接真实模型/OCR/鉴权（除非项目本身就是这个）
- 不做复杂 RBAC / 微服务 / 消息队列
第二阶段：生成可跑项目
- 先跑通，再美化
- 先闭环，再扩展
- 假数据优先可演示
- 分批开发：骨架 → 核心业务 → 闭环补齐
第三阶段：控制代码体量
- 从一开始就把主代码集中
- 核心代码 <3000行
- 序号连续 1-3000，不断开
第四阶段：补截图与演示数据
- 初始化演示数据脚本
- 截图规划表（截什么/在哪截/证明什么）
第五阶段：生成说明书与代码材料
第六阶段：统一命名排版自检
- 名称统一（软件名、模块名、页面名前后一致）
- 禁止暴露"软著""申报""演示专用"等字样
项目开发通用约束（模式B）
功能约束
- 项目可以简单，但必须完整——保留的功能必须真实可用
- 所有按钮必须绑定实际逻辑，所有表单必须可提交
- 前端数据优先来自真实接口，后端优先来自真实数据库
- 不允许大量写死假数据冒充业务功能
- 页面名称、菜单名称、提示语要像正常业务系统
工程约束
- 不要过度分层，不要为显得专业而堆空目录
- 禁止微服务、复杂权限、复杂消息队列、复杂缓存
- 每完成一批代码说明当前打通了什么链路
- 任何时候项目都处于"能跑"的状态
增量修改约束
- 先读现有结构，再改代码
- 禁止推倒重来（除非明确要求）
- 保留兼容旧字段，增加增强层新字段
默认验收标准
能启动 / 能登录 / 能新增 / 能编辑 / 能看到列表变化 / 能完成至少一条核心业务流程
说明书生成约束（模式C）
结构约束
- 严格按用户提供的 Markdown 结构生成正文
- 不得增删章节、不得改标题名、不得改层级
- H1严格对应一级标题，H2对应二级标题
- 标题编号原样保持，不得改写编号风格
- 不得擅自增加三级及以下标题（除非结构中已有）
语言硬性要求
- 全文正式、确定、客观的说明书语言
- 禁止 不确定词：一般、通常、建议、可以、能够、视情况、根据需要、尽量、大致、基本
- 禁止 聊天过渡语、AI身份说明、写作提示
- 禁止 策划书/方案书/宣传文案/论文/教程口吻
- 不得出现占位符（待补充/此处略）
- 截图提示格式统一：【截图提示：此处插入XXX截图】
- 说明书骨架和表达风格要贴合项目类型，避免多个软著材料高度雷同
- 代码段优先选核心业务代码，不用通用骨架代码凑数
执行规则
- 收到结构后直接生成正文，不重复结构，不解释理解
- 输出 30-60 页完整正式正文
- 不含封面、不含目录
- 输出 Word 文档
内部自检
- 是否遗漏标题 / 改变顺序 / 混乱编号
- 是否出现空章节 / 模板说明语 / 不确定词
- 是否从第一章完整写到最后一章
代码材料整理约束（模式D）
- 核心代码行数 <3000
- 序号从 1 连续编到末尾，不断开
- 优先放入：路由、Service、核心业务逻辑、数据模型
- 排除：依赖配置、测试代码、构建脚本、静态资源
- 模仿模板样式输出 Word 文档
核心代码筛选补充
- 优先选能体现软件功能闭环的代码。
- 优先选核心业务、数据处理、接口编排、算法逻辑。
- 避免大量复制框架生成代码、空壳 Controller、配置文件。
- 每段代码材料应能对应说明书里的具体功能。
差异化参考
- 软著材料差异化规则：
references/differentiation-rules.md
可选项目类型参考
| 类型 | 典型项目 | 稳定度 |
|---|
| 管理系统 | 设备管理、招聘管理、教务管理、借还管理 | 最稳 |
| 数据分析 | 可视化平台、统计分析系统 | 中等 |
| 文档处理 | 智能文档处理、表单识别系统 | 中等 |
失败保护
- 若信息不足，先列出缺什么，再基于最常见方案给暂定版
- 不编造未实现的功能或未验证的结果
- 不确定内容标注"待根据实际情况补充"
自我迭代模式
触发条件
当用户在使用本技能后给出反馈（如"这部分不好用""输出格式需要改""多了/少了XX"），或主动说"优化这个skill"时，进入自我迭代模式。
迭代工作流
- 收集反馈：明确用户不满意的具体环节（哪个模式 / 哪个步骤 / 什么问题）
- 诊断根因：是规则缺失、规则冲突、粒度不够、还是场景未覆盖？
- 提出修改方案：列出拟修改的条目（原文 → 修改后），说明修改理由
- 用户确认：修改方案经用户确认后才执行
- 写入 SKILL.md：将修改直接应用到本技能文件
- 记录迭代日志：在
references/iteration-log.md 追加本次迭代记录
迭代日志格式
## [日期] 迭代 #N
- **触发反馈**：...
- **根因**：...
- **修改内容**：...
- **影响范围**：模式X / 步骤Y
迭代约束
- 不破坏现有模式结构——增量修改，不推倒重写
- 每次迭代只改一个关注点——不趁机大改
- 修改后 SKILL.md 总行数仍 < 500
- 重大结构变更（如新增/删除模式）必须用户明确同意
