AI 编程代理应先测请求模糊度再写代码

我用过的每一个 AI 编程智能体，都乐于从一个一句话的需求直接开始写代码。"写一个任务管理 CLI"把数据模型、存储方式、优先级规则和 ID 方案全留给模型去猜，每个猜测都看似合理实则错误。等你审阅到第三个文件才发现问题，修复成本已经是重写而不是改一处了。

模糊度门禁（ambiguity gate）是一种截然相反的默认行为：系统先衡量你的需求还有多模糊，在模糊度降到阈值以下之前拒绝冻结需求规格。本文描述的是我们在 Ouroboros（MIT 协议、开源）中实际落地的这道门禁，包括具体的常量数值——因为我之前搜索相关实践时，搜到的全是学术论文和泛泛之谈。如果其他产品也有类似实现，我真心希望能够交流对比。

访谈循环会提出问题并对三个维度的清晰度打分，每个维度取值范围均为 [0, 1]：

• 目标清晰度，权重 0.40
• 约束清晰度，权重 0.30
• 成功标准清晰度，权重 0.30

模糊度等于 1 减去加权总和。当模糊度低于 0.2 时，需求才能过门禁。每个维度也有自己的底线（目标 0.75、约束 0.65、成功标准 0.70），所以你不能用非常清晰的约束来弥补一个模糊的目标。这些常量定义在仓库的 bigbang/ambiguity.py 中，而不是放在配置文件里——这是有意为之：门禁是一个产品声明，而产品声明应该是可 grep 搜索到的。

门禁实际拦截什么、不拦截什么

门禁是一个默认行为，不是一堵墙。UI 中提供了强制选项，可以跳过门禁直接生成需求规格。因此保证的范围比"不存在模糊的需求规格"要窄。它的含义是："没有模糊的需求规格，除非有人明确选择让它存在"。我们认为这是正确的边界：门禁的作用是把模糊从意外变成决策。

实际上改变的是迭代发生的位置。没有门禁时，迭代发生在代码写好之后：审阅代码、发现假设错误、再重新提示。有了门禁，同样的迭代发生在访谈阶段，在这个阶段一个错误的假设只消耗一个已回答的问题，而不是一个被丢弃的实现。

为什么用数字而不是主观判断

智能体总是可以说"这看起来够清晰了"。一个必须达到的阈值剥夺了这种裁量权。精确地说这个数字控制的是什么：在交互式访谈中，没有轮次限制，何时停止提问由你决定；0.2 的阈值控制的是下一步——生成需求规格。在无人值守的自动模式中，另一个就绪常量（也是 0.20，在自动驱动器中独立定义）决定访谈何时可以交接。无论哪种情况，固定的数字控制着这一步，而不是模型自己觉得"够清晰了"。

这个数字不是质量保证。一个需求可能得分 0.1 但仍然清晰地描述了一个糟糕的想法。门禁只保证一件事：你是主动决定了这个需求规格里要放什么。

curl -fsSL https://raw.githubusercontent.com/Q00/ouroboros/main/scripts/install.sh | OUROBOROS_INSTALL_REF=devto-seo1 bash

然后，在你的编程智能体内部，按顺序运行以下命令（ooo setup 只需执行一次）：

> ooo setup
> ooo interview "你原本要交给智能体的任何提示词"

用一个你原本打算交给智能体的需求试试看。回复你得到的起始分数，以及第一个暴露出你尚未决定的假设的问题。

Repo: github.com/Q00/ouroboros