最新豆包代码评审意见具体化实战技巧：提示词减少来回改稿

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

因此，要实现“评审意见一次过”，必须在提示词层面主动锁定三条规则。下面详细展开。

明确指定评审关注的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 导致后续计算异常”。

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