shumengya
50edff80f5
包含 extensions、skills、prompts、settings、auth、models、mcp 等配置。 排除 node_modules、npm 缓存、sessions 等运行时数据。
2.6 KiB
2.6 KiB
业务理解规则
申请表信息和操作手册不能只根据代码结构泛泛生成，必须先理解软件业务。
证据收集
先用脚本收集证据，输出 草稿/业务理解证据.md/json 和 草稿/业务理解模型稿模板.json。证据通常包括：
README.mddocs/*PRD*.mddocs/*BRD*.mddocs/*ARCHITECTURE*.md- 产品说明、需求文档、设计文档
- 前端页面标题、按钮文案、路由、核心组件名
- 后端 API 路由和模型名称
这些只是候选证据，不代表最终行业、功能和手册结构。
输出业务理解草稿
模型必须阅读证据和必要源码，自行判断应该抽取哪些业务信息，再生成业务理解模型稿 JSON。不得用关键字表或固定模板决定行业、功能和结构。
模型稿经脚本校验后生成 草稿/业务理解.md 和 草稿/业务理解.json，至少包含：
- 产品定位
- 面向领域 / 行业
- 目标用户
- 用户痛点和核心价值
- 主要业务功能
- 典型操作流程
- 操作手册结构建议
- 操作手册页面/流程模块，必须说明每个真实页面或核心流程的使用场景、进入位置、用户可见元素、用户动作、输入/状态规则、结果反馈和截图预留
- 申请表建议口径
- 证据来源
- 待用户确认项
外部调研
如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料。
外部调研只用于帮助理解行业表达，不能编造项目不存在的功能。需要把调研结论写入业务理解草稿，并区分“项目证据”和“行业参考”。
生成材料约束
申请表信息.md/txt的开发目的、行业、主要功能、技术特点必须优先来自业务理解。操作手册.md/docx的说明、功能特点、系统要求、核心页面/流程、常见问题、术语表和章节结构必须优先来自模型确认后的业务理解。- 操作手册不应只生成抽象“功能列表”。模型应把路由、页面、按钮、输入框、列表、弹窗、状态提示、额度或权限规则等用户可见证据整理到
manual_modules，供脚本按通用操作手册骨架排版。最终成稿应是段落化用户手册，不是“进入方式/页面内容/操作步骤/结果反馈”的字段列表。 - 如果缺少
manual_modules、system_requirements、faq或glossary，应回到业务理解阶段补充真实内容；脚本不得用分类模板兜底生成。 - 如果业务理解仍不充分，先提示用户补充产品说明，而不是直接生成泛泛描述。