Nemotron-Labs-Diffusion 这个名称中的 Diffusion 通常表示它属于扩散模型，而不是以代码语义理解为目标的语言模型。代码审查需要读取 diff、判断变更意图、输出结构化意见；扩散模型通常用于图像生成，输入输出格式就不匹配。建议先确认你接入的具体模型是 Nemotron 家族中的哪一类，再决定模板怎么配置。
若 Nemotron-Labs-Diffusion 是图像扩散模型，它不能可靠完成代码审查任务；若实际使用的是 Nemotron 系列语言模型，模板配置才有意义。配置前需先确认模型是否支持文本输入和代码输出，配置后用真实 diff 人工核对，不要直接用生成结果合入评审。
先确认模型能力，再写模板
配置模板之前，先查模型卡片或服务商说明，确认模型接受什么输入、返回什么输出。代码审查至少需要两类能力：一是读取代码文本，二是按照既定格式输出问题列表。如果模型只接受图像提示，或者输出是图片，那它就是图像生成模型，不适用于代码审查。如果是语言模型，可以继续按下面的骨架配置。
可复制的模板配置骨架
以下是一个通用的对话式请求骨架。实际服务接口、字段名可能不同，先与你的接入方式对齐。如果模型不提供文本对话接口，此骨架不适用。
{"model": "此处填实际模型标识","messages": [{"role": "system","content": "你是代码审查助手。只关注变更本身，输出可执行的问题清单。"},{"role": "user","content": "请审查以下 diff：
{diff_text}"}]}模板里的 system 和 user 内容都可以替换。下面三版提示词分别对应不同的审查侧重点，可以单独测试。
版本A：你是代码审查助手。只关注可利用漏洞，如注入、路径穿越、硬编码密钥。对每一条问题，给出文件位置、风险等级、触发条件和修复建议。
版本B：你是代码审查助手。重点检查命名、错误处理、重复代码、函数长度。输出按严重程度排序，并给出具体修改预览。
版本C：你是代码审查助手。结合 diff 上下文，判断变更影响范围、是否缺少测试、是否改动公共接口。无法从变更中判断时，明确说信息不足。配置后的验证清单
模板生效不等于结果可用。用一份小 diff 手动跑一遍，对照清单检查：
- 输出是否包含 diff 中不存在的文件名或函数名？若存在，说明模型在编造内容。
- 每条问题是否定位到具体行，而不是只有一句风险说明？
- 修复建议是否具体到可执行的代码改动？
- 如果模型返回的是图片或无法解析的文本，说明该模型不具备代码审查能力。
边界与回退
如果模板配置后输出仍然不靠谱，不需要反复调提示词。先回查模型类型，改用真正的代码大模型或静态分析工具。对代码审查场景，扩散模型没有优势，配置模板只能让输出格式更规整，不能弥补模型能力。安全敏感的合入流程，仍然建议人工评审把关。