# 业务理解规则

申请表信息和操作手册不能只根据代码结构泛泛生成，必须先理解软件业务。

## 证据收集

先用脚本收集证据，输出 `草稿/业务理解证据.md/json` 和 `草稿/业务理解模型稿模板.json`。证据通常包括：

- `README.md`
- `docs/*PRD*.md`
- `docs/*BRD*.md`
- `docs/*ARCHITECTURE*.md`
- 产品说明、需求文档、设计文档
- 前端页面标题、按钮文案、路由、核心组件名
- 后端 API 路由和模型名称

这些只是候选证据，不代表最终行业、功能和手册结构。

## 输出业务理解草稿

模型必须阅读证据和必要源码，自行判断应该抽取哪些业务信息，再生成业务理解模型稿 JSON。不得用关键字表或固定模板决定行业、功能和结构。

模型稿经脚本校验后生成 `草稿/业务理解.md` 和 `草稿/业务理解.json`，至少包含：

- 产品定位
- 面向领域 / 行业
- 目标用户
- 用户痛点和核心价值
- 主要业务功能
- 典型操作流程
- 操作手册结构建议
- 操作手册页面/流程模块，必须说明每个真实页面或核心流程的使用场景、进入位置、用户可见元素、用户动作、输入/状态规则、结果反馈和截图预留
- 申请表建议口径
- 证据来源
- 待用户确认项

## 外部调研

如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料。

外部调研只用于帮助理解行业表达，不能编造项目不存在的功能。需要把调研结论写入业务理解草稿，并区分“项目证据”和“行业参考”。

## 生成材料约束

- `申请表信息.md/txt` 的开发目的、行业、主要功能、技术特点必须优先来自业务理解。
- `操作手册.md/docx` 的说明、功能特点、系统要求、核心页面/流程、常见问题、术语表和章节结构必须优先来自模型确认后的业务理解。
- 操作手册不应只生成抽象“功能列表”。模型应把路由、页面、按钮、输入框、列表、弹窗、状态提示、额度或权限规则等用户可见证据整理到 `manual_modules`，供脚本按通用操作手册骨架排版。最终成稿应是段落化用户手册，不是“进入方式/页面内容/操作步骤/结果反馈”的字段列表。
- 如果缺少 `manual_modules`、`system_requirements`、`faq` 或 `glossary`，应回到业务理解阶段补充真实内容；脚本不得用分类模板兜底生成。
- 如果业务理解仍不充分，先提示用户补充产品说明，而不是直接生成泛泛描述。