v5.5.0：Ask-First 需求对齐——智能体不再交付你不需要的东西¶
快速答案： 智能体能自主执行，但有时交付的跟用户真正想要的正相反。根因：需求澄清只在用户恰好说出"验收标准""需求不清"等关键词时才触发——一句"优化一下前端页面"会完全跳过澄清，直接进入规划，模型自行猜测目标。v5.5.0 从工作流层面修复：模糊变更请求现在会自动在规划前进入需求澄清；智能体遵循"查 → 推 → 猜 → 问"优先级链（提问是最后手段，不是第一反应）；每个问题都自带默认答案；澄清预算（3 轮）+ 假设兜底给对话一个硬出口，永远不可能无限问下去。
失败模式：能干的智能体，错位的交付¶
工作流能执行。测试跑了、diff 出了、评审也做了。但反复出现的现象是：回来的东西不是用户要的东西。
原因链从外面看很无辜：
- 请求到达："优化一下前端页面" / "Improve the landing page."
- requirements capability 只在消息里出现显式关键词（
acceptance criteria、需求不清、澄清需求……）时才激活。 - 没有关键词 → 没有澄清 → 模型直接进入规划，自己对目标做假设。
- 模型把它的假设执行得完美——这正是错误的东西被"可靠"地造出来的原因。
这是典型的需求验证缺失。软件工程规范说：在设计实现之前，先验证你在做对的事（Are we building the right thing?），而不只是把事做对。我们证据驱动的 capability 链保证了后者，却从没保证前者。
v5.5.0 改了什么¶
1. 结构性识别模糊请求（不再依赖关键词）¶
derive-facts 现在按结构而不是措辞判断"需求缺失"：
- 泛化优化目标（"优化"、"improve"、"优化一下前端页面"）
- 没有可观察的验收/结果描述（"要求首屏加载时间降低到 2 秒以内"）
- 且没有特指功能实体（"支付模块"、"login"、"checkout"）
→ 自动产生 acceptance-criteria-missing → 工作流在规划之前进入 rex-requirements（Grilling 模式）。
内置防误报："我们把上次讨论的优化方案提交了"（完成时态陈述）和名词短语（"optimization plan"）不触发澄清。
2. Ask-First 优先级链——先思考，后提问¶
rex-requirements 与 build agent 现在遵循严格优先级链：
- 查 —— 从环境查证（文件、代码、已有 requirements decision）
- 推 —— 从上下文推断（已有决定、仓库约束、领域惯例）
- 猜 —— 采用合理默认值并标注"这是假设"
- 问 —— 只有前三步都失败、且该问题会改变实现或验收方式时才问
每个问题必须携带假设 + 默认值："我理解你的目标是提升页面转化率，对吗？如果不是，是 A 还是 B？（若不回答，我将按 A 继续）"。用户不回答时按默认继续——永不因缺答案卡住。
3. 澄清预算——防死循环的硬保证¶
requirements 证据契约新增 anyOf 收敛组：
{
"expectedEvidence": [
{ "anyOf": ["acceptance-criteria-recorded", "assumptions-recorded"] },
{ "anyOf": ["non-goals-recorded", "assumptions-recorded"] },
"first-slice-identified",
"requirements-decision-recorded"
]
}
- 验收标准或假设记录满足该组。
- 3 轮未收敛 → 智能体停止询问，把未决项记录为假设清单（
assumptions-recorded），解锁实现。 - 假设清单随交付物一起交付，验收时用户一眼看到"我做了这些假设"。
每个需求只澄清一次，然后类型化 requirements-decision 工件记录对齐——同一需求的重复请求不再重复触发澄清。
旧流程 vs 新流程¶
之前： "优化一下前端页面" → 规划 → "重构样式 + 性能优化 + 加暗黑模式" → 交付 → "我要的是转化率，不是这个。"
现在： "优化一下前端页面" → 智能体自检：目标模糊（优化什么？给谁？怎么算成功？） → 带默认值的一次提问："我理解你的目标是提升本页转化率，对吗？如果不是，是 A 还是 B？" → 用户确认 → 记录 requirements-decision → 解锁开发 → 交付的就是用户要的。
验证¶
- rex-harness 200 项测试通过（199/200；唯一失败是 macOS
/private路径的环境基线，与本改动无关）。 - 主仓库 workflow 测试 103/103 全绿，含新增用例：中文模糊请求 → 需求澄清；英文模糊请求 → 需求澄清；带验收描述 → 不澄清；特指功能目标 → 不澄清；已澄清需求 → 不重复触发；假设收敛 → 阶段完成。
- 新增收敛契约测试：完整验收证据（兼容路径）、假设兜底（防循环出口）、缺组 blocked（契约不放松）。
rex-harness doctor报告ready。
升级说明¶
- 这是行为变更：当请求结构性模糊时，工作流会暂停并提问。这个暂停就是功能本身。
- 已有类型化 requirements decision（
requirements-decision-recorded）会被尊重，抑制重复澄清。 - UI 任务增加方向确认环节：实现前先给 1-2 个风格/布局方向让用户选择。
用一个故意模糊的请求试试——观察工作流在动手前先对齐。