从提示到生产：管理 AI 生成代码的软件生命周期

用 AI 生成代码是容易的部分。困难的部分是之后的一切：验证代码工作正常、通过审查、无事故部署以及长期维护。大多数关于 AI 在软件开发中的讨论都聚焦在生成阶段，但真正的挑战——以及真正的机遇——在于后续的生命周期。

本文追踪 AI 生成代码从初始提示词到生产部署及之后的路径。每个阶段都有与传统人工代码生命周期不同的具体考量，理解这些差异是在生产系统中有效使用 AI 的关键。

阶段 1：生成——为成功奠定基础

AI 生成代码在后期的质量很大程度上取决于它是如何生成的。带着特定的测试计划、清晰的约束和明确的输出格式生成的代码将顺利通过测试和审查。用模糊的提示词生成且没有考虑如何验证的代码会在后续每个阶段制造问题。

在生成阶段你能做的最重要的事情是提前考虑验证。在写提示词之前就决定你将如何验证输出。什么测试应该通过？什么行为应该是可观察的？哪些边界情况应该被处理？将这些纳入提示词——无论是显式地还是通过输出契约——为后续所有阶段奠定基础。

• 在生成代码之前定义验收标准，而不是之后。
• 让 AI 在生成实现的同时生成测试。
• 指定输出格式，以便在审查期间不需要手动重新格式化。
• 在原始提示词中包含边界情况和错误场景。

生成阶段也是像 PromptWake 这样的本地优先捕获工具在生成本身之外增加价值的地方。通过自动记录提示词、响应和结果差异对比，这些工具创建了使后续阶段——尤其是审查和维护——大大更容易的审计追踪。

阶段 2：测试——AI 代码需要而人工代码不需要的

AI 生成的代码在三个领域需要额外的测试关注，而人工编写的代码通常不需要。第一，幻觉依赖：AI 可能使用不存在的库、函数或 API，这些只有通过运行代码才能被捕获——再多代码审查也抓不到一个看起来真实但从未发布过的函数。

第二，隐含假设：AI 可能嵌入关于环境、配置或数据形状的假设，而这些在你的代码库中并不成立。代码可能在隔离环境中完美工作，但在集成时失败，因为它假设的数据库模式、文件结构或服务配置与实际情况不符。

第三，非确定性输出：AI 模型在不同的运行中从相同的提示词产生不同的输出。如果你生成了一次代码，审查了它，然后合并了它，通过审查的代码正是被合并的代码。但如果你或队友稍后重新生成了类似的代码，结果可能不同——可能带有不同的 bug。这使得可复现的生成对于测试和审计很有价值。

# AI 生成代码的测试清单

# 1. 集成测试——它能与实际依赖一起工作吗？
npm test -- --integration

# 2. 契约测试——它匹配期望的接口吗？
npm run typecheck

# 3. 边界情况测试——它能处理意外输入吗？
node -e "const fn = require('./output'); console.log(fn(null)); console.log(fn(undefined));"

# 4. 回归测试——它破坏任何已经工作正常的东西吗？
npm test -- --changedSince=main

阶段 3：代码审查——带上下文审查

在不访问产生代码的提示词的情况下审查 AI 生成的代码，就像在不知道要求开发者构建什么的情况下审查人工代码。这是可能的，但迫使审查者从代码中逆向工程意图，效率更低且更容易出错。

解决方案是将提示词和响应纳入审查上下文。一些团队通过将提示词粘贴到 PR 描述中来做到这一点。另一些使用自动将差异对比链接到产生它们的 AI 交互的工具。无论机制如何，审查者应该能够看到被要求了什么、AI 产生了什么、以及开发者在生成后做了哪些更改。

审查本身应使用代码审查指南中介绍的 AI 特定检查清单：检查幻觉的 API、缺少错误处理、风格不匹配、过度工程、安全问题和架构一致性。这份清单确保没有遗漏任何内容，并且每个 AI 生成的 PR 都按相同的标准审查。

阶段 4：预发布——在类似生产的环境中验证

AI 生成的代码有一种倾向：在开发者的本地环境中工作，在预发布环境中失败。原因通常是环境特定的：库版本不同、配置值被假定而非验证、或者存在于开发环境但不存在于预发布环境的服务端点。

预发布部署应包括针对 AI 生成更改的额外验证步骤。冒烟测试验证应用程序启动、关键页面加载和关键 API 端点响应。集成测试验证新代码与实际服务和数据库一起工作。金丝雀发布在完全推出之前将一小部分流量路由到 AI 生成的代码。

这也是监控 AI 生成代码是否出现意外行为的最有价值阶段。AI 可能生成了完美处理快乐路径但在罕见输入上产生奇怪行为的代码。在预发布环境中在合成负载下观察代码可以在这些问题到达生产环境之前浮现出来。

阶段 5：生产——运维 AI 生成的代码

一旦 AI 生成的代码到达生产环境，它需要与任何其他代码相同的运维考虑——外加一项。团队需要能够将生产事故追溯回产生问题代码的 AI 交互。这正是本地优先捕获工具的审计追踪变得运维关键的地方。

当生产事故发生时，第一个问题通常是改了什么。对于 AI 生成的代码，第二个问题应该是哪个提示词产生了这个变更。如果团队能够访问每个 AI 生成变更的完整提示词-响应-差异对比三元组，事后分析就可以将根因追溯到特定的提示词、缺少的约束或 AI 的幻觉。

当 AI 生成的代码导致生产事故时，问题不仅仅是代码改了什么。问题还在于哪个提示词产生了那段代码——因为修复方式往往是改变提示词，而不仅仅是代码。

生产监控还应该追踪 AI 生成代码的特定指标：部署失败率、回滚频率以及与 AI 生成变更的事故关联性。这些指标告诉团队他们的 AI 实践是否在随时间改进，以及审查和测试流程是否抓住了正确的问题。

阶段 6：维护——长尾

AI 生成的代码不会自我维护。AI 生成的功能上线六个月后，一个没有参与原始实现的开发者需要修改它。那个开发者将无法访问原始的 AI 对话，除非它被捕获并链接到代码。

正是这个阶段，捕获和上下文的投资产生了最显著的回报。当一个开发者打开一个文件，看到它是 AI 生成的，并调出产生它的确切提示词和响应时，他们立刻理解了代码背后的意图。他们知道给出了什么约束、考虑了哪些替代方案、以及原始范围是什么。

没有这个上下文，AI 生成的代码就成了维护负债。原始开发者可能已经离开或忘记了 AI 交互的细节。代码能工作，但它背后的推理丢失了。维护者不得不逆向工程代码和 AI 的逻辑，这比维护带有清晰提交信息的人工代码工作量更大。

构建完整的流水线

这里描述的六个阶段形成了 AI 生成代码从提示词到生产的完整流水线。关键的洞察是，流水线只有在每个阶段都针对 AI 特定的考量进行设计，而不仅仅是改编自人工代码工作流时才能工作。生成应预期测试。审查应包括提示词上下文。预发布应验证 AI 特定的风险。生产应追溯回提示词。维护应保留 AI 交互历史。

构建了这条流水线的团队报告，他们对 AI 生成代码的信心显著提升——不是因为 AI 生成了更好的代码，而是因为团队有了系统化的验证方式。流水线不能消除 AI 生成代码的风险，但它使这些风险变得可见和可管理。而在软件开发中，可见性和可管理性是信心的前提。