# 业务理解规则

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

## 证据收集

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

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

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

## 输出业务理解草稿

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

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

- 产品定位
- 面向领域 / 行业
- 目标用户
- 用户痛点和核心价值
- 主要业务功能
- 典型操作流程
- 操作手册结构建议
- 申请表建议口径
- 证据来源
- 待用户确认项

## 外部调研

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

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

## 生成材料约束

- `申请表信息.md/txt` 的开发目的、行业、主要功能、技术特点必须优先来自业务理解。
- `操作手册.md/docx` 的说明、功能特点、核心模块、常见操作流程和章节结构必须优先来自模型确认后的业务理解。
- 如果业务理解仍不充分，先提示用户补充产品说明，而不是直接生成泛泛描述。