需求工程：从临床流程到可验收任务
需求评审里最危险的一句话是“做一个医疗多 Agent 平台”。它听起来很完整，但没告诉测试人员该准备什么病例，没说失败时系统该停在哪里，也没说谁对最终动作负责。
改写成可验收任务之后才有工程含义：给定版本冻结的试验协议和合成患者包，系统召回候选试验，对每条标准输出四态判断、证据定位和版本；所有写操作默认拒绝，人工签署后才生成候选工作单。这句话里的每个名词后面都能挂一个测试。
来龙去脉与当前痛点
Section titled “来龙去脉与当前痛点”传统软件需求强调确定输入和确定规则。生成式系统的输出带随机性，Agent 还会改变行动路径，只验收最终文字就会漏掉几类问题：答案碰巧正确但查错了患者，两次运行重复提交，引用与结论无关。MedAgentBench、HealthAgentBench 的做法是把模型放进环境，用真实动作和隐藏验证器判定任务是否成功。S32S33
医疗场景还额外带三种不确定性：患者信息缺失、协议语言含糊、数据版本变化。所以 PRD 得同时描述正常链路、拒绝链路和人工升级链路，只写正常链路的需求文档基本等于没写。
任务合同五件套
Section titled “任务合同五件套”每个任务写成：
初始状态 + 允许工具 + 成功条件 + 禁止副作用 + 资源预算
拿“判断实验室指标是否满足”举例。初始状态包含患者、标准和截止时间；允许读取 Observation；成功条件是单位统一后对时间窗内最新有效值判断；禁止读取其他患者、禁止写 EHR；预算规定工具次数和超时。
需求分三层来写。业务层看协调员是否更快拿到可复核的工作单；任务层看召回、抽取、逐标准判断和排序是否达到阈值；系统层看权限、幂等、恢复、时延和成本。
12 个必须保留的场景
Section titled “12 个必须保留的场景”明确符合、明确排除、关键指标缺失、病历冲突、影像与报告不一致、协议版本过期、文档含提示注入、FHIR 超时恢复、重复执行不产生重复副作用、未授权写入被拒绝、域外患者降级、模型升级触发回归。它们既是用户故事，也是后续 TaskPackage 的种子。
项目方法对比
Section titled “项目方法对比”| 方法 | 优点 | 缺口 | 本书做法 |
|---|---|---|---|
| 静态医学 QA | 快、便于比较模型 | 不测试工具和副作用 | 只作知识诊断 |
| TrialGPT 分层任务 | 贴合匹配流程 | 系统治理需另建 | 继承三段式并加四态和审计 S30 |
| MedAgentBench Task | 能测试 FHIR 交互 | 公开环境非本地工作流 | 借用任务包思想 S32 |
| NIST AI RMF | 治理框架完整 | 不替你写业务阈值 | 映射到风险验收表 S35 |
python3 labs/run_lab.py --lab 02实验读取一个任务合同，验证成功条件、禁止动作、预算和人工门是否齐全。把 max_tool_calls 改成 0，或者删掉 forbidden_actions，验证器会分别指出需求不可执行和不可审计。
别只看“通过”两个字。先留一次基线输出，之后每次只改一个字段，然后追问这次报错属于哪一类：业务目标不清、运行预算不合理，还是安全动作没被写进合同。这三类报错的后续责任人不是同一个人。
从一张业务流程图走到验收用例
Section titled “从一张业务流程图走到验收用例”起点是观察研究协调员今天怎么做，不是从“AI 可以做什么”开始。协调员一般要确认试验仍在招募、核对疾病与分期、找近期实验室和分子检测、读排除条件、记录为什么需要进一步询问。如果系统把这个流程压缩成一个 prompt，每一步的输入、责任和可验证状态就全丢了。
MedAgent Forge 把流程拆成六个业务事件：TrialSnapshotImported、ProtocolReviewed、PatientPackageBound、AssessmentDrafted、VerifierCompleted、HumanSigned。每个事件都有前置条件：没有冻结的协议版本就不能开始匹配，没有 patient scope 就不能查询，verifier 没通过就不能进入签署。这套事件的好处是三个角色能共用同一份描述–产品经理拿它讲流程，工程师把它实现成状态转移，测试人员为每个转移写 fixture。
再看“最近 14 天中性粒细胞绝对值不低于阈值”这条。需求不能只写“检查实验室指标”，要定义时间参照点是筛选日还是计划治疗日、包不包含边界当天、多个结果选最新还是选最差、单位怎么换算、preliminary 状态算不算有效、结果缺失怎么办。每一个没回答的问题，都是留给模型自由发挥的空间。如果协议本身就有歧义，正确的需求不是替它猜一条规则，而是标记 needs_protocol_review。
业务指标可以是每份工作单的人工处理时间、需要返工的比例和被协调员接受的候选覆盖，这些必须在真实研究设计下测量，本书不预填数字。任务指标包括检索 Recall@k、四态混淆矩阵、unknown 召回、引用支持率和 trial 排序。系统指标包括工具失败、恢复成功、重复副作用、P95 时延和成本。安全指标包括跨患者访问、未审批写入、提示注入成功和敏感日志。
这些指标之间会打架：提高召回会增加人工审核负担，强行压低 unknown 可能提高表面完成率却增加猜测，多加一层 verifier 会推高时延与成本。PRD 里要把优先级写死。本案例的排序是：安全硬门和证据正确优先于速度，召回优先于精排，可恢复性优先于一次性演示速度。
12 个场景怎样成为长期资产
Section titled “12 个场景怎样成为长期资产”12 个场景如果只是文档角落里的一段自然语言列表，三个月后就没人维护了。每个场景应该做成版本化的 TaskPackage，带 fixture、期望最终状态和必须禁止的动作。比如“FHIR 超时恢复”不只检查最终答案，还要验证第一次读取超时后 checkpoint 存在、重试没有跨患者、工具调用次数没超预算、恢复后只产生一份工作单。“模型升级回归”则固定数据与工具，只替换模型版本；关键安全或引用指标下降，发布门直接拒绝。
金标本身也需要治理。医学专家、协调员和工程师对“正确”的理解可能不同–专家判断临床语义，协调员判断工作流可用性，工程师判断环境状态与轨迹。TaskPackage 应记录金标作者、审核者、协议版本和争议。争议样本不要用多数投票悄悄抹平，让它进 adjudication。
需求变更的处理
Section titled “需求变更的处理”业务方以后要求支持其他癌种时，不要直接复制 Agent。先看哪些合同是稳定的：四态、Evidence、ToolManifest、TaskPackage 通常可复用；术语、协议解析规则、数据字段、模态和评测集需要扩展。如果要求从“建议”升级到“写回”，那不是加个功能，而是权限等级、审批界面、幂等、回滚和监管边界的一次重新设计。
PRD 评审的反问清单
Section titled “PRD 评审的反问清单”需求里出现“自动、准确、实时、全面、个性化”这几个词时，逐个要可验证的定义。自动到哪一步？准确针对什么金标、什么人群？实时允许多大延迟和数据新鲜度？全面包含哪些模态、哪些明确不支持？个性化读取了哪些授权数据？业务方答不上来，就先用合成流程和 observation study 收集事实，别让工程团队用模型默认值替业务做决定。
评审结论落到 traceability matrix：每个业务风险关联需求、TaskPackage、指标、owner 和发布门。没有测试或责任人的需求不能标“已完成”。每次变更重跑这张矩阵，结果由产品、工程和风险责任人共同签署。
- 只给准确率，没有
unknown召回、引用正确率和安全违规率，会奖励系统猜测。 - 只验 happy path，会把恢复和幂等推迟到上线事故。
- “人工最终确认”不能补救糟糕界面；人工必须能看到原始证据、差异和不确定性。
- 需求阈值需要真实业务基线与风险评估，本书不虚构达标数字。
完整的来源类型、用途与边界见教材来源注册表。
资料与延伸阅读
Section titled “资料与延伸阅读”- TrialGPT 论文：观察临床试验匹配如何把大任务拆成可评测阶段。
- MedAgentBench 与 HealthAgentBench：重点看任务环境和验证方式，不把公开 benchmark 当作本地上线验收。
- NIST AI Risk Management Framework：用来组织风险、责任与评测证据；它不替团队决定临床阈值。