豆包代码评审意见具体化提示词可复用写法

俗话说得好，让AI干活不难，让它干得出彩才是真本事。要是用豆包做代码评审，总收到“逻辑不够清晰”“命名可以优化”这类模糊笼统的反馈，那项目进度就会寸步难行。要想让豆包输出真正能用、能直接落地的修改建议，你的“指挥策略”必须升级——得采用一套结构化提示词，把它的输出颗粒度和专业锚点彻底锁死。

具体怎么操作？以下几招，都是从实战经验中提炼出来的。

先明确角色和任务边界

第一句话就要把豆包的身份固定下来：它必须是“刚接手一个 Python + FastAPI 项目的资深后端工程师，正在进行 Code Review”。这比写“请认真评审代码”有效得多。你给出的“角色”越具体，它的回答就越不容易走样。

紧接着，一句话把任务范围框定：“针对下方提交的代码片段，逐行指出问题类型、出现位置、违反的规范依据、修复后的代码示例，以及不修复会带来的后果。”

这一步如果不说死，豆包往往图省事，省略“依据”和“后果”两项，最终给你的依然是令人头疼的模糊建议。从项目实战来看，防止偷懒的最佳方法，就是一开始就把所有要求都摆在明面上。

强制输出可复用的“代码块模板”

这里有个小技巧：用 JSON-like 的框架去约束格式，但别用真正的 JSON，以免豆包卡在语法上。参考下面的模板，干净又利落：

【问题编号】：从 1 开始连续编号
【位置】：精确到文件名+函数名+行号（如 main.py → create_user → 第42行）
【类型】：从「安全漏洞」「性能缺陷」「可读性差」「测试缺失」「风格违规」中选择
【依据】：必须引用 PEP 8 / OWASP Top 10 / 本项目 README 中第3.2节等真实出处
【修复示例】：给出可直接复制粘贴的代码块，并附带注释说明改动点
【后果】：写清楚不改会引发什么问题——例如“该硬编码密钥将导致 CI 流水线在 prod 环境失败”

这才是关键所在。它跟以前带实习生的经验类似：你不能光告诉他“这不对”，还得指着教科书（PEP 8、OWASP等）告诉他“为什么不对”，再手把手演示“怎么改对”，最后还要提醒一句“不改会出大事”。有了这个结构，AI的输出就有了灵魂。

堵住它所有偷懒的“捷径”

AI 再聪明，也是个喜欢“走捷径”的家伙。要对付它，下面几招杀手锏很管用。

第一招：禁用“模糊形容词”
在提示词末尾，严肃地加上一句：“禁止出现‘某些情况’‘部分逻辑’‘建议考虑’等模糊表述；所有‘建议’必须转为‘应改为’或‘必须替换为’。”这就像给豆包的“废话开关”上了把锁。

第二招：迫使它“自我复核”
要求豆包在每条意见后，追加一句自检：“本条是否满足：①有行号 ②有依据来源 ③有可执行代码 ④有明确后果——如任一缺失，请重写。” 这招最高明，让豆包自己当自己的“质检员”。这就像上学时做题目，答完要自己检查一遍，防止粗心大意。

第三招：设定“最低字数红线”
“每条意见正文不得少于35字，少于则自动补全；若原文无行号，则主动标注‘需补充行号’并暂停输出后续意见。” 这招能有效防止豆包敷衍了事，也倒逼它去深度思考问题。信息密度不够，说出来也是白说。

从行业共识来看，这三招组合拳打出去，基本能把豆包从“AI助手”调教成一个对你俯首帖耳的“专业代码评审员”。最终你会发现，与其抱怨AI不给力，不如反思自己这把“发令枪”打得是否足够专业。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：豆包代码评审意见具体化提示词可复用写法要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题