如何让 AI 生成可靠代码：先说明环境，再要求测试与边界处理

AI 可以很快写出一段看起来合理的代码，但如果不知道语言版本、运行环境、输入输出和验收条件，结果很容易停在示例层面。可靠的代码 Prompt，必须把这些上下文补齐。

代码任务和普通写作不同。文章出现一个模糊句子，可能只是表达问题；代码少一个依赖、误解一个字段、没有处理空输入，就可能直接运行失败。让 AI 编写程序时，任务目标和技术环境同样重要。

资料中关于任务拆分、上下文、结构化输出和评估的内容，可以直接迁移到编程场景：先澄清需求，再说明环境；先设计输入输出，再写最小实现；最后用测试和错误信息推动修改，而不是一开始就要求“写完整项目”。

“帮我写一个用户管理工具”不是可执行需求。需要继续说明它要解决什么问题、谁会使用、输入是什么、输出是什么、哪些行为必须支持，以及哪些行为暂时不在范围内。

可以把需求写成行为：输入一个包含用户记录的 JSON 文件，按指定字段去重，保留最新记录，输出同样结构的 JSON，并报告被合并的数量。这样的描述比“优化用户数据”更容易转换成代码和测试。

需求中还要写清成功和失败的表现。成功时返回什么，空文件怎么办，字段缺失怎么办，重复记录如何判断，非法 JSON 是报错、跳过还是停止。边界越早说明，后面的实现越少靠猜。

如果需求还不完整，让 AI 先输出问题清单，不要直接补全。可以要求它把假设与事实分开，并在关键假设会改变接口或结果时先请求确认。

同一段逻辑，在不同语言版本、框架、操作系统和依赖版本下，写法可能完全不同。Prompt 中至少要说明语言和版本、运行方式、已有依赖、禁止新增的依赖、输入输出方式以及目标平台。

如果是修改现有项目，还要提供相关文件结构、调用入口、类型定义和已有约定。不要只把错误信息贴出来就要求修复，最好同时说明错误发生前的操作、期望行为和最近改动。

依赖也要写清楚。项目不允许安装新包时，要求 AI 使用现有库；可以新增依赖时，也要说明版本和用途。让模型默认安装一个库，往往会把一个小需求变成配置和部署问题。

环境信息不完整时，要求 AI 先给出需要确认的清单，并提供不依赖额外环境的最小方案。它可以说明“在某版本下可能这样写”，但不能声称已经运行验证。

可靠代码的边界，通常从输入输出开始。输入字段、类型、是否必填、默认值和编码要明确；输出字段、顺序、错误格式和退出行为也要明确。即使只是一个小函数，也值得写一段简单接口说明。

错误处理不能只写“做好异常处理”。可以具体到：文件不存在时返回什么错误，字段类型不对时是否指出路径，网络超时时是否重试，重复请求是否幂等，空结果是空数组还是错误。不同选择会影响调用方，不能让 AI 自行决定。

如果任务包含外部输入，必须说明校验规则。长度、范围、格式、编码、空值和特殊字符都可能成为边界。校验失败后要返回可理解的错误信息，但不要在错误信息中泄露密钥、路径和内部配置。

让 AI 输出代码时，可以同时要求它先列出接口假设，再给实现和示例输入输出。这样更容易发现双方对数据结构的理解是否一致。

一次要求 AI 生成完整系统，往往会得到大量无法验证的代码。更稳妥的做法是拆成几个可运行阶段：先实现核心路径，再加入输入校验，再处理异常和边界，最后补充性能、日志和扩展能力。

每个阶段都要有清楚的交付物。例如先提交一个只处理内存数据的函数，并配三组测试；通过后再接文件读写；最后再接网络接口。这样出错时能知道是业务逻辑、环境还是集成部分出了问题。

要求 AI 修改现有代码时，限制修改范围也很重要。可以写：只修改指定文件和函数，不改变公开接口，不做无关重构，保留已有测试；如果发现必须扩大范围，先列出原因和影响。

分步并不意味着慢。每一步都小而可验证，通常比一次生成一大片代码后逐行排错更省时间，也更容易保留可用版本。

只要求输出代码，不要求测试，模型通常会把时间用在主流程上。可以明确要求同时提供正常输入、空输入、边界输入、非法输入和预期结果，并说明哪些测试必须通过。

测试不只是为了证明代码能运行，也是在澄清需求。一个测试用例会迫使团队回答：重复值怎么处理，顺序是否重要，错误是否继续，时间是否包含时区。很多实现争议，在写测试时就能暴露出来。

让 AI 生成测试时，要防止测试只验证自己的实现。可以先给出行为规范，再让它根据规范写测试；要求测试覆盖用户真正关心的结果，而不是只覆盖代码行数。

没有实际运行环境时，AI 只能提供静态分析和建议测试，不能声称测试已通过。Prompt 中要明确区分“应当通过”“已运行通过”和“尚未验证”，这也是可靠性的一部分。

程序运行失败后，不要只把错误信息丢给 AI 并说“修一下”。先补充运行命令、输入样本、完整堆栈、期望结果和已尝试的修改。错误信息离开上下文，很难判断根因。

可以让 AI 先分类问题：语法或类型错误、依赖和环境错误、输入数据错误、业务逻辑错误、并发或性能问题、测试预期错误。先分类再修改，避免用一个表面修补掩盖真正原因。

每次修改都要说明假设和影响。如果只是为了让某个样例通过而改变了通用逻辑，应该提醒风险；如果修复需要改变接口或数据结构，先请求确认。不要让模型不断追加条件分支，把问题越修越复杂。

修复后重新运行原失败案例和相关回归测试。一个错误修好，不代表其他行为没有被破坏。保留失败样本，是后续评估和 Prompt 优化的重要材料。

下面的模板适合让 AI 编写小工具、函数或局部功能。复杂项目应继续拆分，不要把整个仓库的所有目标一次性放进一个 Prompt。

示例 Prompt： 任务：实现【功能名称】，帮助【使用者】完成【具体行为】。 环境：使用【语言和版本】，运行在【平台或框架】；只能使用【已有依赖】，不要修改【受保护文件或接口】。 输入：说明字段、类型、必填项、默认值和示例；非法输入包括【情况】。 输出：说明返回结构、字段类型、成功结果和错误格式。 规则：只修改【文件或函数范围】；保留原有行为；不要编造不存在的接口；如果需求不足，先列出假设。 异常：处理空值、缺字段、错误类型、超范围、文件或网络失败；不要在错误信息中泄露敏感配置。 测试：提供正常、边界、非法和回归用例，并标明哪些测试需要在真实环境运行。 交付：先说明实现思路和假设，再给代码、测试和运行方式；区分已验证与未验证内容。

如果任务是修复现有代码，可以把“交付”改成：先定位可能原因，再给最小修改；说明修改文件和影响；不要进行无关重构；根据原失败案例补充回归测试。

AI 编写程序最有价值的地方，是帮助快速探索实现、解释错误和补充测试；它不能替代环境验证、代码评审和权限控制。把所有代码都当成已经正确，会让生成速度变成返工速度。

好的代码 Prompt 会把需求、环境、输入输出、异常、范围和测试放到同一条链上。每一步都能被运行、检查或复盘，下一轮修改就有依据，而不是继续靠更强烈的语气请求“写得可靠一点”。

从一个小功能开始，先让 AI 复述需求和假设，再生成最小实现，接着运行测试，根据具体失败修改，最后补回归用例。这个过程看起来朴素，却比一次生成一套宏大代码更接近真正可交付的软件工作。