## 任务目标
请作为企业软件产品经理，围绕真实业务整理一份可评审的需求澄清结果。用途是决定本期解决什么问题，以及如何判断问题得到解决。
交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。
## 输入信息（选填）
两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。
业务问题：
现状与需求资料：
## 信息不完整时
先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。
### 优先确认
- 逐条提取原始需求及出处，区分现象、使用者诉求、解决方案建议和未验证假设。
- 查看业务对象、责任角色、组织或租户范围，以及从触发到结果的现有办理路径。
- 查重复录入、等待、返工等问题的具体材料依据，核对已承诺范围、资源或截止时间是否真实存在。
### 可采用的默认处理
- 先还原事实与任务，再提出最小可完成目标；没有调研证据时不编造访谈、用户数量或提效比例。
- 范围优先覆盖与原始问题直接相关的内容，其他想法列为可延后或待验证，不默认扩成全系统重建。
- 没有排期和决策依据时只给有理由的优先级建议，角色与对象关系可确认多少就先整理多少。
### 必须有依据的事项
- 材料无法判断用户实际想解决的业务问题，或相互冲突的目标会导向不同范围时，需要确认这一目标；可先完成事实与现状梳理。
- 组织责任、数据归属或必须保留的业务约束不明时，不能自行决定权限和办理责任。
只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。
### 资料仍不足时的交付
- 没有工程时依据已有原始材料交付问题证据表、角色关系、当前流程及范围建议。
- 缺少调研与运行证据时交付明确标注假设的候选目标、可观察验收条件和关键验证事项，不把候选方案当作已确认需求。
## 执行要求
围绕使用者的角色、任务和现有困难分析需求，方案应减少理解和办理成本。
1. 逐条提取原始材料中的问题，记录谁在何时执行什么任务、在哪一步受阻以及现有证据位置。把明确事实、使用者诉求、方案建议和待验证假设分开，不能用自己的推测补成访谈结论。
2. 整理业务角色、业务对象、对象负责人和协作关系。存在集团、企业、部门或租户时分别定义视野；岗位名称相同不代表数据权限相同，组织边界不明的地方单独标注。
3. 用触发条件、输入、处理动作、输出和下一责任人还原当前流程，指出重复录入、等待和返工的位置。只描述材料支持的现象，不凭印象给出节省时间或提效百分比。
4. 为每个问题提出最小可完成的目标，区分用户任务和系统功能。将目标与需求一一关联，删去没有业务对象、触发条件或处理责任的宣传性功能表述。
5. 划分本期必须交付、可延后和不在范围的内容，注明优先级依据及依赖。没有实际资源、截止时间或决策授权时，给出排序建议，不虚构承诺日期。
6. 针对每项本期需求写可观察的完成条件，覆盖正常流程和至少一个失败分支。汇总会影响方案的关键未知项，列出应由哪个角色补充、需要何种材料。
## 交付与验收
输出：①简明业务目标；②问题与证据表；③角色和对象关系；④当前任务流程；⑤范围与优先级表；⑥逐项验收条件；⑦待确认事项。表格使用业务中文，保留材料引用位置。
验收：所有本期功能均能追溯到具体问题和使用角色；每项都有可验证结果；事实与假设清楚区分；不存在伪造的调研、用户数量和收益数字。
信息边界：资料不足时先完成能够确定的部分，把缺口写清楚；不要未经授权联系用户或改动线上系统。
### 本条完成检查
- 每项本期功能能追溯到具体问题、证据和使用角色，不含无业务责任的口号式功能。
- 目标、范围与优先级理由清楚，每项完成条件覆盖正常结果及适用失败分支。
- 事实、诉求、方案和假设明确区分，关键未知项说明影响和所需决定，能够确认的内容已完整交付。
按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。
## 参考资料与适用边界
参考来源（核验于 2026-09-08）：
- [Ant Design 设计价值观](https://ant.design/docs/spec/values-cn/)
