AI 工程化不是多写代码：从生成到验收的闭环
AI 写出一个能运行的页面，往往只需要几分钟。真正困难的部分从这之后才开始：需求变了还能不能修改，模型换了会不会退化，错误发生后能不能定位，另一个人接手时能不能理解。界面跑起来只能证明一次生成成功，不能证明系统已经可以交付。对我来说，AI 工程化要解决的正是这段差距。
代码生成为什么不等于软件交付
大语言模型提高了代码产量，也降低了进入陌生技术栈的门槛。这种杠杆是真实的，我自己也从中受益。但产量提高并不会自动带来正确的架构、清晰的状态管理和稳定的异常处理。模型可以生成看起来合理的代码，却不知道团队没有写进上下文的历史约束，也不承担上线后的维护责任。
GitHub 在审查 AI 生成代码的指南中，把编译、自动测试、静态分析、依赖检查、架构一致性和人工判断放在同一条审查链上。它还特别提醒开发者关注不存在的依赖、被跳过的失败测试，以及“看起来正确但不符合真实意图”的实现。这说明问题不只是模型会不会犯错，而是我们有没有一套机制，让错误在进入生产环境前暴露出来。
因此，我更愿意把 AI Coding 看成生产环节，而不是质量体系。它负责加速探索和实现；验收标准、权限边界、回归测试与最后的责任，仍然属于整个软件系统和使用它的人。
AI 工程化需要约束哪些不确定性
传统软件也有缺陷，但相同代码在相同输入下通常可以复现。生成式 AI 又增加了一层概率性：提示词、上下文顺序、模型版本、工具结果和采样参数都可能改变输出。只测试接口是否返回 200，无法回答结果是否仍然有用。
我目前会把需要约束的对象分成四层：
- 代码层：能否编译，测试是否通过，依赖、安全和性能有没有明显问题。
- 模型层：在一组代表性任务上，输出是否达到质量基线，模型或提示词变化后是否退化。
- 工作流层：工具调用、状态保存、失败重试、人工审批和业务系统写入是否按预期发生。
- 结果层：用户是否更快完成目标，错误成本是否可接受，业务指标是否真的改善。
这四层不能互相替代。单元测试通过，不代表回答有业务价值；离线评测优秀，也不代表权限和重试机制安全。NIST 的 AI 风险管理资源把测试、评估、验证与确认放进完整生命周期，并要求形成可重复、可记录的方法。Google 的生产 ML 指南也把数据、模型版本、基础设施、集成和线上监控分开检查。它们共同指向一个朴素事实：模型只是系统的一部分。
从生成到验收，需要一条闭环
一套可执行的闭环不必一开始就很重。对小型项目，我倾向从六个动作开始。
第一，先写验收条件。让人和 AI 都知道什么叫完成，包括正常路径、边界条件和明确不能发生的行为。没有验收条件，模型只能优化“像完成了”。
第二，保存规则和项目状态。聊天记录不是可靠的项目记忆。架构决定、数据结构、禁止修改区、发布流程和历史失败，应放进版本化文件或外部状态，而不是依赖某次对话还留在上下文里。
第三，分开测试与评测。确定性的代码交给测试、类型检查和静态分析；概率性的结果使用固定样例、评分标准和人工抽检。OpenAI 对评测的实践也强调，测试结果必须说明测试了什么系统、使用了哪些工具与预算，以及结论能够支持到什么范围。
第四，把检查放进变更流程。不是开发结束后偶尔检查一次，而是在每次重要修改后运行。GitHub 建议先执行自动测试和静态分析，再检查上下文、意图、可维护性与依赖。AI 可以参与自审，但不能因为审查者也是 AI，就把它的意见当成最终批准。
第五，记录运行与失败。至少保留输入版本、关键决策、工具结果、耗时、错误和人工干预点。日志不是为了堆数据，而是为了回答：这次失败发生在哪里，能不能重放，修复后如何证明没有复发。
第六，为上线保留回滚和人工边界。高风险写入、发布、付款、合同和设备操作，不应由一次生成直接决定。先生成、再确认、后执行，虽然牺牲了一部分“全自动”的想象，却换来了明确的责任边界。
工程规范也可能变成新的形式主义
但我也必须承认，流程越多不等于工程越成熟。小工具如果还没有用户，就建立庞大的评测平台和审批系统，可能只是把时间花在没有被验证的问题上。测试覆盖率也可能很好看，却没有覆盖真实失败；日志可以非常完整，却没有人阅读；规范写得很严，实际变更仍然绕过它。
所以工程化不是把每个项目都改造成大型平台，而是让约束与风险相匹配。一个只读的内部摘要工具，可以依靠样例评测和人工抽检；一个会向 CRM 写客户记录的 Agent，需要幂等、权限和审计；一个能够影响报价或合同的系统，还需要更严格的审批和回滚。系统越接近现实后果，验收成本就越不能省。
我正在验证的不是“AI 能不能写”，而是“系统能不能接住”
我还没有建立一套经过大量长期项目验证的成熟 AI 工程方法论。现阶段更准确的说法是：我正在把过去项目中的问题，逐步整理成可检查的工程假设。例如 AI Code Debt Radar 对技术债记忆的探索，关注的是变更历史和错误模式如何留下来；WordPress AI 交付体系，尝试把需求、模块、截图验收和上线检查组织成流程。它们都是证据的一部分，不是方法已经成熟的证明。
我对 AI 工程化的核心判断 没有改变：真正的价值不是让不确定性消失，而是让它变得可观察、可评估、可恢复。提示词也只是控制与评测闭环的一部分，不是系统本身。
接下来值得检验的问题很具体：如果明天更换模型、修改提示词或交给另一个人维护，我们能否在不依赖原作者记忆的情况下，判断系统有没有变差？如果答案是否定的，那么项目可能已经会运行，但还没有真正进入可交付状态。