问题定义与用户场景（V10）

内容类型：Discovery 方法难度：基础适合：新项目、新主流程或需求仍然模糊的上位机任务阅读时间：约 10 分钟前置：知道大概要解决什么问题即可

“做一个上位机”不能直接变成开发任务。需要说明谁在什么场景下完成什么工作、软件和设备如何配合、异常时有什么后果，以及第一阶段怎样算完成。

但这张表不是所有任务的前置流程。如果只是改文案、修明确 Bug、执行已经确认的规则，直接走 Fast / Execution，不要重新做问题定义。

0. 什么时候用，什么时候跳过

情况	建议
新项目，只有一句想法	使用本页
新设备主流程还没定义	使用本页
用户自己也不确定应该怎样工作	使用本页 + Discovery
已有项目新增较大业务流程	只整理本次变化和新场景
用户已给详细规格	跳过，直接 Execution
UI 文案、样式、局部显示	跳过，Fast / MicroPatch
“以前正常，最近改坏”	跳过，RegressionFix

1. 先写一句问题定义

模板：

为了【目标用户】在【使用场景】中解决【当前痛点】，
我们要提供【关键能力】，
让用户能够【完成核心任务】，
并通过【成功标准】判断第一阶段是否完成。

示例：

为了实验室测试人员在电容脉冲试验中减少多设备手工操作和状态误判，
我们要提供统一的设备控制与测试流程，
让用户能够完成设备检查、参数应用、试验执行、状态观察和结果保存，
并通过连续完成规定测试流程且关键状态/记录可追溯判断第一阶段可用。

问题定义说的是“为什么做、给谁用、完成什么”，不是先决定类名、模块名和文件结构。

2. Facts 和 Decisions 分开

填写本页时，不要把所有空白都交给用户。

Facts：Agent 优先自己确认

例如：

• 当前项目是 WPF 还是 WinForms；
• 已有哪些设备模块；
• 设备协议中有哪些命令；
• 当前配置保存在哪里；
• 旧界面已经显示哪些状态；
• 现有流程有哪些步骤；
• 最近 Git 中有哪些相关实现。

这些优先从代码、截图、协议、日志、旧软件和文档确认。

Decisions：真正需要用户决定

例如：

• 设备掉线后测试是否继续；
• 自检失败后能否人工跳过；
• 某报警是否必须停机；
• 第一阶段是否需要自动报告；
• 哪些设备允许同时操作；
• 哪些危险动作需要二次确认。

只有不同答案会改变最终业务行为时，才进入 Discovery Frontier。

3. 用户和现场

优先确认这些会影响设计的事实：

问题	说明
谁使用	操作员 / 测试人员 / 调试人员 / 维护人员
主要场景	实验室 / 产线 / 客户现场 / 售后
用户关注什么	设备状态、流程、结果、报警、诊断中的哪些内容
操作频率	偶尔调试 / 每天多次 / 长时间连续运行
是否有人值守	影响自动恢复与告警方式
电脑环境	Windows、分辨率、权限、网络、DLP/E-SafeNet
验收者	操作人员 / 客户 / 质检 / 研发

如果已有现场文档或旧软件，Agent 应先自己提取这些事实，再只确认有歧义的地方。

4. 当前痛点

不要只写“需要一个软件”，要写现在为什么不方便。

痛点	当前怎么做	造成什么问题	严重程度
手工记录测试数据	人眼看设备，再填表	容易漏记、错记	高
多设备分别操作	每台设备开独立工具	容易漏步骤、状态不一致	高
通信问题只有“失败”	没有底层证据	现场难定位	中高

常见痛点：

• 手工记录慢；
• 设备状态看不清；
• 测试流程靠人记；
• 异常后不知道能不能继续；
• 数据无法追溯；
• 原始通信证据不足；
• 多台设备实例容易选错；
• 软件长期运行后资源不释放。

5. 用普通话写一次完整场景

不要先写代码结构。

步骤	谁操作	做什么	软件应该怎样反应	设备应该怎样反应
1	测试人员	选择设备	显示在线/占用状态	不产生危险动作
2	测试人员	执行自检	汇总可操作结果	允许只读状态查询
3	测试人员	应用参数	明确成功/失败	按确认规则下发
4

至少回答：

从哪里开始？
→ 用户做哪些关键动作？
→ 哪些步骤由软件自动做？
→ 哪些真实设备动作需要人工确认？
→ 正常怎样结束？
→ 异常怎样恢复/停止？

6. 异常场景要写“后果”，不只写“报警”

例如：

设备掉线

还不够。需要知道：

Trigger: 测试过程中设备连接丢失
Action: 暂停 / 继续 / 停止 / 只报警？
Recovery: 自动重连还是人工确认？
Record: 保存哪些状态和原始错误？

常见事件后果：

• InterlockFault：阻断/停止；
• AlarmOnly：报警记录但继续；
• Advisory：提示确认后继续；
• Information：仅展示。

如果这部分已经明确，后续直接进入 BehaviorPatch；不需要重新做一轮完整需求分析。

7. 成功标准

第一阶段不要写“功能全部完成”，要写可验证结果。

编号	成功标准	验证方法	通过标准
S-001	能连接指定设备实例	Fake/真机连接	状态与真实连接一致
S-002	能显示关键工程量	固定输入/Replay	数值与单位正确
S-003	能完成核心测试流程	WorkflowSmoke	主流程可到达完成态
S-004	异常后果符合规则	模拟异常	Alarm/Stop/Recovery 正确

成功标准应覆盖核心闭环，而不是为了“完整”一次加入所有报表、权限、主题和扩展功能。

8. NonGoals：明确本阶段不做什么

暂不做内容	原因	后续可能性
用户权限系统	第一阶段内部使用	可能
自动生成复杂报告	先跑通核心测试	可能
多设备并行控制	第一阶段按单实例串行	待评估

NonGoals 的价值是控制 AI 扩张范围。

但不要把项目所有历史 NonGoals 每次都塞进 Prompt，只保留当前任务相关部分。

9. 约束条件

只记录真正影响当前方案的约束：

类型	内容
技术约束	.NET / WPF / WinForms / 必须使用的库
设备约束	型号、协议、单连接、危险动作、模拟器
现场约束	无网络、权限、工控机性能、加密/DLP
数据约束	保存格式、单位、追溯、涉密
时间约束	第一版交付/联调窗口
验证约束	是否有真机、Fake、Replay、测试环境

10. 假设、未知和风险不要混成一张“待确认清单”

推荐分类：

类型	含义	谁负责下一步
ConfirmedFact	已有证据	直接使用
FactToVerify	能通过代码/文档/现场查证	Agent 优先查
OpenDecision	不同答案改变业务行为	放 Frontier，用户决定
Suggested	AI 建议	不自动纳入需求
Risk	已知风险	设计/验证时处理
Deferred	当前不阻塞	暂不追问

这样不会出现“AI 问了 20 个问题，其实 15 个可以自己查”的情况。

11. 优先级：只用于版本范围，不代替行为定义

可继续使用 Must / Should / Could / Won't 或 P0 / P1 / P2。

例如：

能力	优先级	理由
设备连接与状态	Must	核心流程入口
测试执行	Must	核心任务
原始诊断日志	Must	联调需要
历史查询	Should	第一版可简化
主题切换	Won't	与第一阶段无关

但“Must”不能代替细节，例如“必须报警”仍然需要说明是 AlarmOnly 还是 InterlockFault。

12. 当前 Frontier：只问现在必须决定的 2–5 件事

把前面内容整理后，最后输出：

Resolved:
  - 已确认的用户、场景、核心流程

Frontier:
  - 当前必须决定且会改变业务结果的问题

Blocked:
  - 依赖 Frontier 结果，暂时不问

Deferred:
  - 当前版本不阻塞

例如：

Frontier:
  - Decision: 自检发现示波器离线后是否允许进入测试准备页？
    WhyBlocking: 会改变状态机和按钮启用条件
    RecommendedDefault: 不允许开始测试，但允许进入设备维护页
    Alternatives: 完全阻断软件 / 只报警继续

用户回答后重新计算 Frontier。Blocking Frontier 清零，就停止 Discovery。

13. 可直接复制的 Prompt

$host-computer-dev
这是一个新项目/新主流程，目前业务还有关键未知，请进入 Discovery。

项目目标：
【填写】

当前场景：
【填写】

已有材料：
【需求文档 / 协议 / 旧界面 / 代码 / 日志 / 现场说明】

请先整理：
1. 一句话问题定义；
2. 目标用户和真实操作场景；
3. 核心流程与异常流程；
4. 第一阶段成功标准；
5. NonGoals；
6. 已知约束和风险。

然后把未知分成：
ConfirmedFact / FactToVerify / OpenDecision / Suggested / Deferred。

能从材料、代码、配置、Git、协议确认的 FactToVerify 请你自己查，不要反问我。
只把会改变最终业务行为的 OpenDecision 放到 Frontier。
每轮最多问 2–5 个 Frontier 问题，并给出推荐默认方案、原因和主要替代方案。
Blocking Frontier 清零后就停止，不为了“需求完整”继续追问。

下一步

继续学习

需求发现与拆解表（V10）

把已经整理出的场景、约束和 OpenDecision 继续收敛成 Requirement Delta / Decision Tree；Blocking Frontier 清零后进入 Execution 或设计。

下一步 →按问题找方案

需求发现

Decision Tree / Frontier

查看 →

对应案例

新项目案例总览

查看案例 →

完整工作流

只有新项目/大功能才需要完整阶段

查看 →