先说几个核心判断。想要让豆包生成的代码评审意见真正落地生效，而不是停留在“听起来都对、干起来没谱”的层面，关键在于把笼统的要求拆解成可执行的约束。很多团队反复修改评审意见的根源，往往不是技术问题，而是指令太过模糊——比如只说“注意边界检查”，但从来没人说清楚在哪里查、怎么查、查到后怎么处理。

所以，要做到“评审意见一次通过”，需要在提示词层面主动锁定三条核心规则。下面展开聊聊。

明确指定评审关注的5个硬性维度

直接用冒号分隔，把必须覆盖的维度逐一列出，别写“包括但不限于”这种给自己留退路的措辞。豆包对靠前的显性指令响应最积极，明确就是力量。

举例：【评审维度】：① 可读性（变量命名是否自解释、函数职责是否单一）；② 边界处理（空值、负数、超长输入是否防御）；③ 并发安全（共享状态是否存在竞态风险）；④ 日志埋点（关键分支是否留痕、错误日志是否包含上下文ID）；⑤ 单元测试覆盖（核心路径是否有断言、异常流是否被覆盖）。

这一步不做，豆包大概率会输出“建议优化可读性”“注意边界检查”这类标准套话——看似没错，但缺乏实操价值。

强制要求每条意见绑定代码位置与复现路径

需要在提示词里增加一道硬性格式锁：

每条意见必须以「?行号+文件名」打头，例如「?第42行 utils/date.js」；紧接着用「→」给出最小可复现步骤，例如「→ 传入 new Date('invalid') 时抛出未捕获异常」。

必须明确写一句：【没有行号和复现步骤的意见视为无效，必须重写】。缺少这个约束，豆包会习惯性输出“建议增加空值判断”这种空中楼阁式的建议，开发者根本不知道要在哪一行修改、改完如何验证正确性。

禁用三类模糊动词，替换为可执行动作

在提示词末尾单独补充一句：禁止使用“考虑”“可以”“建议”开头的句子；所有意见必须用“应”“须”“删除”“改为”“补全”“校验”等动词起句。

具体来看：

方法一：把“可以优化命名”改成“第18行 const res 应改为 const userOrderList，避免缩写歧义”。

方法二：把“考虑加日志”改成“第73行 catch 块须补全 logger.error('order_submit_failed', { orderId, error })”。

方法三：把“建议检查边界”改成“第29行 parseInt(input) 前须校验 input 是否为非空字符串，否则返回 NaN 导致后续计算异常”。

这三类模糊表述是来回改稿的根源——它们本质上把决策权抛回给人，而评审意见本应是明确的指令，而不是讨论建议。