在团队里用 Gemini 3.1 Pro 做代码生成，最大风险不是“生成不出来”，而是生成出来的代码不可靠：风格不统一、边界条件缺失、接口不匹配、测试覆盖不到位，甚至出现安全与合规问题。
因此最有效的做法，是把“生成代码”当作一个可以被工程校验的环节，建立一条标准流水线：生成 → 静态检查 → 单测 → 修复闭环。
本文提供一套可直接落地的流程、模板化提示词与输出结构，并给出校验/迭代建议，适合团队协作、可审计、可回滚。 kulaai（dl.877ai.cn）
1）总体思路：把大模型输出当作“候选补丁”，而不是最终代码
流水线的目标是让 Gemini 输出的内容始终处于“可验证状态”：
- 生成阶段只产出“候选代码与变更说明”
- 静态检查确保语法、类型、格式、潜在安全风险不过关就停止
- 单元测试用可重复的方式验证逻辑是否满足契约
- 修复闭环让模型根据失败日志进行“有目标的增量修复”
核心原则：失败就回到模型，但要提供“可操作证据”（error stack、覆盖率报告、差异 diff），而不是泛泛解释。
2）工程化流水线（可执行步骤）
Step 0：输入定义（任务契约）
在调用 Gemini 前，你需要准备“代码契约”，至少包含：
- 目标语言/框架（如 Python + FastAPI / Java + Spring）
- 接口签名或函数原型（必须固定）
- 约束（风格、复杂度上限、禁止使用的库）
- 示例与边界（含异常/空值/非法输入）
- 期望输出（返回结构/异常类型/日志要求）
建议团队把这些内容模板化为 spec.md，并在请求中原样引用。
Step 1：生成（Generate）
调用 Gemini 生成候选实现，并要求输出结构化结果，便于后续自动化处理。
模板化提示词（生成阶段，示例）
你是一名资深工程师。请根据以下规格在仓库中生成/补全代码。
禁止引入未声明依赖；禁止改变既有公共接口签名。
输出必须包含：
1）changes：文件路径→修改摘要
2）patch：可应用的 diff（或按文件逐段输出）
3）tests_added：新增/修改的测试用例列表
4）assumptions：你做的假设（若无写“无”）
规格：{{spec}}
现有代码上下文：{{repo_context}}
失败约束（如有）：{{failure_constraints}}（首次为空）
输出结构建议（JSON）
json
{ "changes": [{"path": "src/...","summary": "..." }], "patch": "diff text...", "tests_added": [{"file":"tests/...","cases":["..."]}], "assumptions": []}
生成后，自动落盘到工作区形成“候选分支”。
Step 2：静态检查（Static Check Gate）
静态检查的目的是“便宜地抓错”，让失败尽早发生，节省反复单测成本。
根据语言/仓库配置典型工具链：
- 格式：prettier / black / gofmt / ktlint
- 语法/类型：mypy / typescript compiler / javac / golangci-lint
- 规则：ESLint / Sonar / security linter
- 依赖：检查 package-lock、依赖白名单
- 变更范围：禁止越权修改（例如只允许触及指定目录）
失败策略
- 若静态检查失败：立刻进入 Step 4 修复闭环，并把完整错误日志喂回模型
- 若静态检查通过：进入 Step 3
Step 3：单元测试（Unit Tests）
运行测试并收集可用于修复的证据：
- 失败用例的 stack trace
- 期望 vs 实际的差异信息
- 覆盖率（coverage）与未覆盖分支提示
- 运行耗时（用于后续性能优化约束）
建议团队明确“通过标准”：
- 所有测试通过
- 覆盖率不低于基线（可设置最低阈值）
- 关键异常分支有测试覆盖
Step 4：修复闭环（Repair & Iterate）
当失败发生时，修复不是“重新生成一遍”，而是基于失败证据做定向修补。
模板化提示词（修复阶段，关键！）
你的任务是修复候选代码以通过测试。
只允许对涉及失败的文件做最小修改，保持公共接口不变。
请输出：
1）你理解的根因（基于日志）
2）最小 diff 修复方案
3）新增/调整的测试（如果现有测试缺失关键边界）
失败日志：{{test_failure_log}}
覆盖率变化（若有）：{{coverage_report}}
当前 diff/候选代码：{{current_patch}}
规格约束：{{spec}}
闭环次数建议
- 先设定最多 2-4 轮（防止无限迭代）
- 每轮必须带来“可度量进展”：至少一个失败用例通过或覆盖率提升或静态检查通过
3）校验与门禁：让流程“可审计、可回滚”
团队落地时建议设置“门禁”（Gates）：
- 格式门禁：不通过则不允许进入单测
- 安全门禁：禁止高危 API、禁用不受控网络请求等（依你们合规要求）
- 接口门禁：公共签名不得变更（可用 diff 检查）
- 测试门禁：不通过则回到修复阶段
- 变更范围门禁：只允许触及指定目录（例如
src/与tests/，不动config/）
另外，建议所有“模型建议的补丁”都记录：
- 模型版本、提示词版本（Prompt vX）
- 输入 spec 版本
- 静态检查结果、测试结果
- 最终合并前的人工审批状态
4）团队协作的输出结构与“最小可用上下文”
为保证协作效率，建议把上下文固定成三块并在请求中明确：
spec.md：任务契约（必带）repo_context：相关文件摘要/片段（只带必要部分，避免超长噪声）constraints：禁止项 + 接口签名 + 依赖白名单
并要求模型在修复时遵循“最小变更”原则，减少冲突。
5）常见失败类型与对应修复策略（模板化）
失败类型 A：编译/类型错误
- 证据：静态检查日志
- 修复策略：模型应引用签名/类型约束，做最小类型修正
- 禁止：通过“绕过类型检查”来通过
失败类型 B：逻辑错误导致测试失败
- 证据：单测断言差异（expected vs actual）
- 修复策略：让模型定位到具体函数路径，调整边界条件/数据处理顺序
- 建议：若多条测试失败集中在同一逻辑模块，优先修模块而非散改
失败类型 C：覆盖率低但测试通过
- 证据：coverage report
- 修复策略：补边界用例（不是改实现“靠运气通过”）
- 产出：新增测试用例 + 明确理由（failure mode）
6）A/B 与迭代建议：用数据优化“提示词与工具链”
即使你做了闭环，仍可能出现“同样问题模型总是绕不过去”。建议迭代策略：
- Prompt A/B：比较不同生成策略（例如是否强制输出 diff、是否要求先列计划再写代码）
- 工具链 A/B：比较不同静态检查组合的性价比（更快抓错还是更准抓错）
- 失败分类统计：统计失败按类别占比，把主要精力投到最高频失败的门禁规则或提示词约束上
关键不是“让模型变聪明”，而是“让系统在正确的失败证据上更快收敛”。
结论：代码生成要像 CI 一样“可验证”
把 Gemini 3.1 Pro 用在代码生成上，最佳实践不是一次性生成，而是建立工程流水线：
- 生成：结构化候选补丁 + 明确测试/变更范围
- 静态检查：廉价、快速、先拦截明显问题
- 单测：用可重复契约验证正确性
- 修复闭环：基于日志证据进行最小增量修复，限制轮次数并记录可追踪信息
