Appearance
上位机需求发现与拆解表（V10）
这张表不是所有任务的前置流程。V10 的第一步不是“开始需求分析”，而是先判断当前任务是否真的存在需要用户决定的业务未知。
0. 先判断：这次到底需不需要需求拆解
| 当前情况 | 推荐路径 | 是否使用本页 |
|---|---|---|
| 只想知道当前代码怎么工作 | Read-Only Trace | 否 |
| 改文字、颜色、列宽、已有样式 | Fast / MicroPatch | 否 |
| 阈值、连续次数、报警后果已经说清 | Execution / BehaviorPatch | 通常否，用 Behavior Contract 即可 |
| “以前正常，最近改坏了” | RegressionFix | 否，先看 known-good 与 Git Diff |
| 临时放开限制做边界测试 | ExperimentalChange | 否，先设计可恢复 override |
| 新项目、新设备主流程、用户也不确定应该怎样工作 | Discovery | 是 |
| 现有系统新增功能，但关键业务规则仍未决定 | Discovery | 是，只拆本次 Requirement Delta |
一个已有项目的小改，不应该因为“工程规范”又重新走一遍完整需求、总体设计、详细设计。
1. 先分清事实和决策
需求沟通效率低，很多时候不是问题太复杂，而是把“AI 能自己查的事实”也问给用户。
事实：优先由 AI 自己确认
例如：
- 当前按钮绑定哪个命令；
- 配置从哪个文件读取；
- 现有协议字段怎么解析；
- 最近哪些文件发生过修改；
- 当前报警是否会触发停机；
- 数据目前写到哪里；
- 项目有没有现成 Fake、Replay 或测试入口。
这些应优先从代码、配置、Git、日志、协议和已有文档确认。
决策：由用户决定
例如：
- 越限后应该停机还是只报警；
- 连续几次才算故障；
- 操作员能否跳过某一步；
- 本版本必须交付哪些功能；
- 设备离线后流程是否允许继续；
- 某个实验条件是临时测试还是正式规格。
判断标准很简单：不同答案会不会改变最终产品行为？ 会，就属于真正的业务决策。
2. Discovery 不按“固定五轮”走，而是维护 Decision Tree
建议使用四个区：
yaml
Resolved:
- 已经确认的业务决定
Frontier:
- 当前前置条件已经满足、现在就能决定的问题
Blocked:
- 依赖 Frontier 结果，暂时不要问
Deferred:
- 对当前实现不阻塞，可以以后再决定Frontier 是核心
每一轮只问当前 Frontier 中真正阻塞实现的问题，通常 2–5 个就够。
每个问题最好带四项：
text
问题：设备掉线后测试流程应该怎样处理？
为什么现在必须决定：它会改变状态机和恢复逻辑。
推荐默认：进入 AlarmOnly，当前步骤暂停，连接恢复后由用户确认继续。
其他选择：立即终止测试 / 自动恢复继续 / 只记录日志。用户回答后，重新计算 Frontier。阻塞当前开发的问题清零，就停止 Discovery；不要为了“需求完整”继续追问未来可能用不到的分支。
3. 最小需求输入
如果用户只有一个模糊想法，不需要先填几十个字段。第一轮只要这些：
yaml
Goal: 这次想解决什么问题
User: 谁实际使用
Scenario: 现场怎么操作
KnownConstraints: 已知硬约束
Materials: 已有代码 / 协议 / 截图 / 日志 / 文档
NonGoals: 明确不做什么
Acceptance: 用户怎样判断第一版可用
Unknowns: 目前自己也拿不准的地方示例：
yaml
Goal: 做一个实验室电源控制模块
User: 测试人员
Scenario: 选择设备 → 连接 → 设置电压 → 启动测试 → 看状态和报警
KnownConstraints:
- C# WPF
- 同一时间只允许控制一台同型号电源
- 真实高压动作必须人工确认
Materials:
- 通信协议
- 旧控制软件截图
NonGoals:
- 第一版不做历史趋势
Acceptance:
- 能稳定连接、设置、读取状态、显示故障
Unknowns:
- 掉线后的流程后果
- 自检失败后是否允许继续这已经足够让 AI 开始查事实并建立第一版 Decision Tree。
4. 已有项目优先写 Requirement Delta，而不是重做 PRD
已有系统新增或修改功能时，只记录“这次变化了什么”。
yaml
CurrentBehavior:
RequestedBehavior:
Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:
Compatibility:
OpenDecisions:
VerificationExpectation:例如：
yaml
CurrentBehavior: 单次过流即报警并终止测试
RequestedBehavior: 连续 5 次过流才报警，但测试继续
Trigger: 停机窗口残余电流监测
Condition: 连续 5 帧 >= 阈值
Action: AlarmOnly
Reset: 任意正常帧清零；下一窗口重新计数
Record: 保存连续样本和工程单位
NonGoals: 不修改高压控制和采集模式
Compatibility: 历史配置继续兼容
OpenDecisions: 无
VerificationExpectation: 连续 4 次不报警，第 5 次报警；正常帧后重新计数OpenDecisions 为空时，就应该进入 Execution，而不是继续需求访谈。
5. 新项目的最小业务骨架
只有新项目或新主流程，才建议补下面这些维度：
| 维度 | 先确认什么 |
|---|---|
| 用户 | 操作员、测试人员、调试人员、维护人员分别做什么 |
| 场景 | 一次完整操作从哪里开始、在哪里结束 |
| 设备 | 连接哪些设备，哪些只能读，哪些能写，哪些动作危险 |
| 状态 | 离线、连接中、在线、运行、报警、故障、恢复 |
| 流程 | 哪些步骤自动，哪些需要人工确认 |
| 数据 | 什么必须保存，什么只展示，单位和时间戳是什么 |
| 异常 | 超时、掉线、设备拒绝、数据非法时的后果 |
| 验收 | 第一版什么情况下可以认为“可用” |
注意：这里描述的是业务行为，不是提前决定具体类名、方法名或目录结构。
6. 需求候选状态
AI 整理需求时建议保留来源强度：
| 状态 | 含义 |
|---|---|
| SourceConfirmed | 用户原话、正式文档或现有系统直接支持 |
| Inferred | 从已知事实合理推导，需要检查 |
| Suggested | AI 建议，不应自动变成需求 |
| OpenDecision | 会改变行为，等待用户决定 |
| Deferred | 当前版本不阻塞，暂缓 |
| OutOfScope | 明确不做 |
不要因为“行业一般都这样”就把 Suggested 写成客户需求。
7. Definition of Ready：什么时候停止问问题
Discovery 的结束条件不是“所有问题都问完”，而是当前开发已经具备足够确定性。
可以开始设计或实现时，至少满足：
- 当前版本目标清楚；
- 关键业务行为没有阻塞未知；
- 危险设备动作和人工确认边界明确；
- 输入、输出、异常后果基本明确；
- NonGoals 明确；
- 验收方式可描述；
- 剩余问题都可以放进 Deferred。
如果这些都满足，就停止需求发现。
8. 重要需求再做追踪，不要求所有小改编号
正式项目、新子系统或需要验收的高风险功能，可以建立追踪关系：
text
Requirement
→ Behavior / Design
→ Implementation
→ Verification
→ Evidence示例：
| 需求 | 行为/设计 | 实现范围 | 验证 | 证据 |
|---|---|---|---|---|
| C-001 正确解析设备上报 | 帧边界 + CRC + 工程量换算 | 协议解析链 | Replay + 异常帧 | RX/PARSE 日志 |
| S-001 高压写入需人工确认 | 危险写操作前确认 | 高压写入口 | HITL | 操作记录 |
纯 UI 文案、颜色、列宽这类 MicroPatch 不需要为了追踪而新建需求编号。
9. 三个可直接复制的 Prompt
9.1 模糊新需求：进入 Discovery
text
$host-computer-dev
这是一个新的/仍然模糊的上位机需求，请进入 Discovery。
目标：
【填写】
使用场景：
【填写】
已有材料：
【代码 / 协议 / 截图 / 日志 / 文档】
已知约束：
【填写】
请先区分 Facts 和 Decisions：
- 能从材料、代码、配置、Git 查到的事实由你自己确认；
- 只把会改变最终业务行为的决策放进 Decision Tree。
每轮只问当前 Frontier 中 2–5 个阻塞问题，并给出你的推荐默认方案、原因和主要替代方案。
当前实现所需的 Blocking Frontier 清零后就停止，不要为了完整继续追问 Deferred 项。9.2 需求已经明确：不要重新访谈
text
$host-computer-dev
下面是已经确认的功能变化，请走 Execution，不要重新做需求访谈或输出长 Plan。
CurrentBehavior:
RequestedBehavior:
Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:
VerificationExpectation:
先核对必要代码事实；如果没有真正阻塞的业务决策，直接沿最小修改路径实施。9.3 已有客户文档：先做“事实抽取 + 缺口”
text
请根据我提供的需求说明书/技术协议整理可执行需求。
要求：
1. 保留原文能直接支持的要求，并标记 SourceConfirmed。
2. AI 推导内容单独标记 Inferred 或 Suggested。
3. 找出真正会阻塞开发的 OpenDecision。
4. 不要把常见行业做法自动写成客户要求。
5. 只针对当前第一阶段建立 Frontier；未来问题放 Deferred。
6. 输出第一阶段 NonGoals 和验收方式。10. 常见反模式
反模式 A：小改也重新做完整需求
“按钮文字改一下”不需要重新定义用户、场景、模块和验收体系。
反模式 B：固定问五轮、十轮
轮数不重要，阻塞决策是否清零才重要。
反模式 C：让用户回答代码事实
“这个值现在在哪个类里算？”通常应该由 Agent 查代码，而不是问用户。
反模式 D：把需求、设计、实现混在一起
业务需求先说“系统应该怎样表现”；类名、线程模型、目录结构属于设计和实现层。
反模式 E：把 AI 建议直接写成正式需求
所有 Suggested 都需要证据或用户确认后才能升级。
下一步
- 已经没有 Blocking Frontier：进入 总体/详细设计与完整工作流，或直接按任务进入 功能修改最小流程。
- 涉及串口/TCP/协议：使用 串口 TCP 通信任务模板。
- 涉及阈值、连续次数、报警后果：查看 行为与报警语义。
- 只是想知道当前代码怎么工作：不要继续填需求表，改走 AI 辅助读懂 C# 项目。