豆包需以资深后端工程师身份，对Python+FastAPI代码做CR，逐行输出含编号、位置、类型、依据、修复示例及后果的结构化意见，禁用模糊表述，每条不少于35字并强制自检四项要素。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想让豆包在代码评审时给出具体、可落地的修改建议，而不是泛泛而谈“逻辑不够清晰”“命名可以优化”，就得用结构化提示词锁定它的输出颗粒度和专业锚点。
明确角色与任务边界
第一句就定义豆包是资深后端工程师，刚接手一个 Python + FastAPI 项目，正在做 CR（Code Review）——这比写“请认真评审”有效得多，角色越实，输出越聚焦。
紧接着用一句话框定任务：“针对提交的代码片段，逐行指出问题类型、触发位置、违反的规范依据、修复后的代码示例，以及不修复可能引发的后果。”
这一步必须写死，否则豆包默认会省略依据和后果，只给模糊建议。
立即进入“豆包AI人工智官网入口”；
立即学习“豆包AI人工智能在线问答入口”；
强制输出结构模板
用 JSON-like 框架约束格式，但不用真 JSON，避免豆包卡在语法上：
【问题编号】：从 1 开始连续编号
【位置】：精确到文件名+函数名+行号（如 main.py → create_user → 第42行）
【类型】：选填「安全漏洞」「性能缺陷」「可读性差」「测试缺失」「风格违规」
【依据】：必须引用 PEP 8 / OWASP Top 10 / 本项目 README 中第3.2节等真实出处
【修复示例】：给出可直接复制粘贴的代码块，含注释说明改动点
【后果】：写清不改会导致什么——比如“该硬编码密钥将导致 CI 流水线在 prod 环境失败”
堵住常见偷懒路径
方法一：禁用模糊形容词
在提示词末尾加一句：“禁止出现‘某些情况’‘部分逻辑’‘建议考虑’等模糊表述；所有‘建议’必须转为‘应改为’或‘必须替换为’。”
方法二：反向校验机制
要求豆包在每条意见后追加一句自检：“本条是否满足：①有行号 ②有依据来源 ③有可执行代码 ④有明确后果——如任一缺失，请重写。”
方法三：设定最小信息密度
“每条意见正文不得少于35字，少于则自动补全；若原文无行号，则主动标注‘需补充行号’并暂停输出后续意见。”
