豆包代码评审提示词标准化：3步打造可复用模板与要点详解

让AI执行任务简单，但让它交付可直接落地的专业成果，需要方法。如果豆包生成的代码评审意见总是停留在“逻辑待优化”、“命名需改进”这类空泛层面，项目推进效率必然受损。要获取能直接整合进代码库的具体修改方案，关键在于使用结构化提示词，精确锁定输出的专业深度与操作细节。

如何实现？以下是经过验证的实战策略。

精确界定角色与任务范围

初始指令必须明确角色：“假设你是一名资深后端工程师，刚接手一个基于 Python 与 FastAPI 的项目，正在执行代码审查。”这比泛泛的“请评审代码”更能框定AI的思考锚点。

随后，清晰定义任务格式：“针对下方提供的代码段，请逐项列出：问题类型、具体位置、违反的规范条款、修复后的代码示例，以及忽略此问题可能引发的风险。”

这一步是保障评审质量的基础。若不作强制要求，AI常会省略“规范依据”和“潜在后果”等关键信息，导致输出缺乏可操作性。项目管理经验表明，预先设定明确的交付标准是提升AI协作效率的核心。

构建可复用的结构化输出模板

技巧在于：使用类JSON结构来规范格式，但避免严格的JSON语法，以防解析错误。推荐如下清晰模板：

【问题编号】：从 1 开始连续编号
【位置】：精确至文件名、函数名及行号（例如：main.py → create_user → 第42行）
【类型】：选择「安全漏洞」「性能缺陷」「可读性问题」「测试覆盖不足」「编码风格违规」
【依据】：必须引用具体出处，如PEP 8第C415条、OWASP Top 10 2021-A7、项目README第3.2节规范
【修复示例】：提供可直接替换的代码块，并以注释说明修改点
【后果】：阐明不修复的具体影响，例如：“硬编码的API密钥将导致生产环境CI/CD流水线验证失败”

这是方法论的核心。其原理类似于指导初级开发者：不能仅指出“有问题”，必须结合编码规范（PEP 8、OWASP等）说明“为何有问题”，提供“如何修复”的实例，并明确“不修复的代价”。这个结构为AI的输出注入了专业评审所需的严谨性。

预设规则以杜绝模糊输出

AI倾向于寻求最低能耗的路径。为确保输出质量，需在提示词中嵌入以下约束：

约束一：禁止模糊表述
在提示词末尾明确要求：“禁止使用‘某些情况下’、‘部分逻辑’、‘建议考虑’等不确定性表述；所有改进建议必须使用‘应改为’或‘必须替换为’等肯定句式。”此举旨在关闭AI的模糊表达模式。

约束二：强制自我复核
要求AI在每条评审意见后添加自检说明：“本条是否满足：①有具体行号 ②有规范依据 ③提供可执行代码 ④阐明明确后果——若任一条件缺失，请重写此条意见。”这本质上是为AI内置了一个质量检查环节。

约束三：设定内容密度门槛
设定规则：“每条评审意见的正文描述不得少于35个字符，若不足则需补充分析；若原始代码未提供行号，则标注‘需补充行号信息’并暂停后续输出。”此规则能有效防止AI输出敷衍、信息量不足的结论。

行业最佳实践表明，综合运用以上策略，能将豆包从通用助手转化为高度专业的代码评审协作者。最终结论是：工具的输出质量，往往取决于使用者输入指令的精确度与专业性。