Gemini 3.6 Flash 这类定位为快速响应的模型，适合处理边界清晰、单次能完成的代码任务，比如解释一段逻辑、补注释、做语法转换、按报错信息修改局部代码。处理代码时真正需要注意的往往不是模型写不写得出来，而是三个容易忽略的环节：任务边界没划定、输入上下文含糊、输出没有验证就进入仓库。把这三个环节控制住，使用这类模型就接近找一个需要复查的结对程序员。

处理代码前先划定边界：单文件、局部修改、有明确输入输出时可用；跨文件重构、安全审计、性能结论需要人工兜底。输入要带语言、版本、报错信息和期望输出；输出必须经过语法检查、测试或人工比对后才能合入。真实密钥、内网地址等敏感信息不应进入对话。

先确认任务边界，不是所有代码任务都适合

Flash 类模型的特点是响应快，但上下文综合和推理深度通常弱于更大的模型。适合的任务包括：解释不熟悉的代码片段、补函数注释、在两种语言之间做语法转换、根据报错修补单个函数、生成单测骨架。不建议直接交给它的任务包括：跨多个文件的依赖重构、架构选型、给性能优化下结论、安全审查。下面的分界可以用作参考：

给模型的输入要可复现，提示词带足上下文

代码任务处理失败，第一原因往往不是模型能力，而是输入里缺关键信息。一个可复现的提示词应包含：语言和版本、文件路径、相关代码片段、完整报错、期望行为、明确约束。可以直接套用下面的骨架：

语言：Python 3.12
文件：src/parser.py
问题：运行 pytest tests/test_parser.py::test_empty_input 时
      parse('') 抛出 IndexError，期望返回空列表。
请：
1. 指出最小改动位置；
2. 给出修复后的函数代码；
3. 用一句话说明改了什么。
约束：不要改动其他函数，不要引入新依赖。

贴代码时优先贴失败函数和调用处，而不是整个文件。如果模型要求补充上下文，再逐层补相关函数，比一次性塞入大量无关代码更容易得到有效输出。对长文件，可以先让模型概括整体结构，再针对具体函数深入。

验证清单：模型输出不能直接提交

模型输出只是候选改动，进入仓库前建议至少过一遍清单：

• 语法或构建检查通过，能本地运行。
• 相关单测或回归测试跑通，并确认没有反过来改断言去迁就代码。
• 检查 diff 范围，确认没有顺手重构其他逻辑。
• 考虑边界输入：空值、超长字符串、异常编码、并发入口。
• 检索输出里是否混入真实密钥、内网地址或他人代码片段。

如果任务是解释或审查，把模型给出的结论逐条对应到源码行号；没有行号的判断只能当线索，不能当依据。

常见问题

能把整个项目代码贴进去让它做重构吗？

不建议。上下文窗口有限，内容越多越容易出现遗漏或不一致。稳妥的做法是拆成单文件、单函数的改动，每次提交前单独验证。

模型说“优化了性能”可以直接采信吗？

不能直接采信。性能结论必须由自己跑出的测量数据支撑；可以要求模型给出可复现的验证方法，而不是接收一句优化结论。