能从代码库查到的不许问用户
更新于 2026-09-22
**需求澄清(brainstorm)阶段的证据规则:能从代码库查到的答案不许问用户,只问仓库回答不了的问题 —— 产品意图、范围、验收标准。** 把可自查的事实问题丢给用户,等于把 agent 的检索成本转嫁给唯一的时间瓶颈。为什么这条要写成硬契约
- 用户对代码库细节的回答往往不精确,还会引入新的错误前提;仓库是这些问题唯一的真值源。
- 问「这个函数在哪调用的」和问「你希望失败时是静默还是报错」是两类问题:前者是事实检索,后者是意图决策。 混在一起问,用户会开始替你读代码。
- 配套的一条同样重要:用户说「做吧」不等于批准实现。 非平凡任务至少要有一轮「最终计划摘要」的确认才能动代码 —— 批准方向 ≠ 批准方案。
可迁移的判断
- 提问前先自问:「这个答案在不在这台机器上?」在 → 自己查,别问。
- 只在两个维度上向用户提问:意图(想要什么、为什么)与边界(范围、验收、优先级)。
- 把「确认计划摘要」当成一个独立的闸门,而不是把「用户点头了」当成开工信号。
相关
- 阻塞式工具与提案确认 —— 确认闸门属于宿主,不属于模型
- skill约束要区分补短板与替模型判断 —— 该写进契约的是判断规则,不是替模型想
- Issue完成由用户验收后再关闭 —— 同一取向:用户的确认是状态机里的一环
- 作者是AI时协议要唯一规范答案
- 委派颗粒度要匹配信息缺口