需求里写着快速和方便，Agent 怎样生成可评审的验收示例

需求写了“快速”“方便”，Agent不应直接补一个秒数让它看起来可测。更有用的做法是定位哪个词无法判定，说明缺的是观察起止、比较对象还是用户体验标准，然后产出候选行为场景。这样产品负责人可以批准具体口径，测试团队也能知道以后观察什么。

已有需求模板之后，还要审一句话的含义

通用需求文档已经会写角色、输入、期望行为和反例。本题继续往下处理这些文字本身：同一句“及时释放名额”，可以被开发理解为提示出现，被业务理解为另一个人能够重新预约。二者都像成功，观察点却不同。因此附件以原句为单位，不再复制角色、输入、动作等整套需求书。

拟定的审阅行保留原句、条款位置、不可判定原因、候选观察、未定参数和决定人。原句不能被改写稿覆盖，否则后续无法解释为何新增了一个第二用户场景。若需求已经足够明确，记录采用的条件即可，不为展示智能而继续制造问题。

官方机制说明1：Rule、Given/When/Then、Scenario Outline与Examples可以表达规则和具体示例，不自动证明业务规则正确。

Gherkin在这里是共同阅读的行为表达。文字写成Given和Then，并不意味着业务口径已获批准；带未决参数的草案也不能直接算可执行测试。正式执行步骤和覆盖设计应留给规则确认后的测试环节。

按不可判定的原因分别改写

合成输入1。 条款R01写取消后及时释放名额，未说明从点击取消还是管理员批准起计，也未说以提示出现还是另一个用户能再次预约为终点。

预期处置：列两个起点/终点歧义；生成带事件顺序和第二用户观察的候选场景，时限与最终采用的观察点待产品确认，不只填一句及时完成。

合成输入2。 条款R02已确认精确场地编号A01应优先；合成结果有A01、A010及名称含A01的其他场地，但规格仅写搜索体验更好。

预期处置：将相对词改成A01排在其他候选前的可观察排序场景，保留三个候选和判定对象；不把文字更自然当排序符合。

合成输入3。 条款R03写大批量导出更方便，既有小批量同步下载和大批量异步任务两条产品路径，未定义用户要完成的操作及便利评判方法。

预期处置：分别列两条可观察用户任务和缺失成功条件；把方便保留为需用户研究的体验项，不随意发明最多几步或几秒即方便的阈值，也不以接口返回成功替代文件可取得。

时间类要问从什么事件开始，到什么观察结束，再讨论允许等待多久。排序类需要一个能区分不同实现的候选集合，而不只输入一个唯一结果。体验类则先分成功任务与使用感受；文件能够取得是功能事实，操作是否方便还需要适当用户研究，不能由模型给出一个通用步数标准。

让附件真正包含行为文本

下载表中的proposed_scenario_text保存完整Background、Scenario或Scenario Outline与Examples。取消案例包含甲占用唯一名额、乙有预约资格的背景，并将释放时限明确写为待确认。精确编号案例同时放入A01、A010和名称含A01的B02，预期A01在前；这样没有精确优先的实现才会暴露差异。

导出案例分别列同步取得文件与异步回查结果的候选路径，并在注释注明内容格式和恢复规则尚未确认。它没有把“接口成功”偷换为“用户已拿到文件”。审批前这些文本是讨论材料，不是已生效产品承诺。

评审看能否产生相反结论

产品和测试可以各自拿一段假想观察来填写满足、不满足或无法判断。如果一个人只看提示，另一个人还要尝试再次预约，说明观察定义仍未对齐。对已经确认的排序例，故意让A010排第一，应能明确指出不符合哪条口径。

交付时保留未决问题的具体影响：缺时限会阻止性能判定，缺观察终点会阻止功能判定，主观便利未定义则不影响已经确认的文件范围检查。这样开发方可以继续明确的部分，产品负责人也能集中处理真正需要决定的事项，而不是面对一份笼统的“需求不清”。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。

通用相近旧文解决整份输入，本题解决句子能否判定。候选行为可回到产品经理的长需求交给 Agent，怎样拆成可独立讨论的用户故事的故事边界，再送往PRD 的多条业务规则交给 Agent，怎样找出重叠和无人覆盖的条件检查规则空间。文档与数据处理专题还有资料准备任务；可向定制咨询提交原句与一条争议观察。