AI-Native 软件工程(3):AI Coding 不是写代码,而是一个执行系统上周有个朋友发消息给我，说他用 Claude 写了一个数据同步模块，Prompt 反复调了 7 轮，花了将近两个小时。第一轮生成的代码有类型错误，第二轮修了类型但接口签名跟上游对不上，第三轮改了签名但测试跑不过，第四轮测试过了但跑起来有 race condition，第五轮修了并发问题但破坏了另一个模块的契约——后面几轮他已经记不清改了什么了。最后他说了一句话：AI 写代码挺快的，但我围着它转了一下午。大多数人谈 AI 编程的时候，脑子里的画面是这样的：我输入一个需求，AI 输出一段代码，我复制粘贴，完事。但凡在真实项目里用过超过一周的人，都知道这个画面是假的。AI 写代码这件事本身不难。今天的模型，给它足够的上下文，生成一个函数、一组 API、甚至一整个模块的脚手架，速度都很快。真正难的不是"生成"，而是生成之后的一切——代码能不能跑通，跑通了符不符合系统结构，符合结构了能不能过测试，过了测试上线后会不会炸。我朋友那两个小时里到底在做什么？回头看，他做的事情可以用一个循环来描述。理解需求，让 AI 生成代码，把代码放进项目跑一下，发现问题，反馈给 AI，再生成，再跑，再验证，再修正。Intent → Generate → Run → Verify → Retry。这个循环他手动跑了 7 轮。每一轮他都要自己判断出了什么问题，自己组织上下文，自己决定怎么改 Prompt，自己确认修复是否引入了新问题。你可能会说，这不就是正常的开发流程吗？写代码、编译、调试、测试，程序员一直都在做这件事。传统的开发流程里，编译器、测试框架、CI/CD 管道——这些都是自动化的基础设施。你写完代码，点一下按钮，编译器告诉你哪一行有语法错误，测试框架告诉你哪个 case 没过，CI 管道告诉你能不能合进主干。你不需要自己盯着屏幕一行行看代码有没有拼错，系统替你做了。大多数人的答案是：没有。他们的"执行系统"就是自己的眼睛、自己的脑子、自己的复制粘贴。AI 生成了代码，然后所有验证、运行、反馈、重试的工作，全部由人手动完成。这就是为什么 AI 明明写代码很快，但很多人用起来并不觉得快。生成只是整个链路的第一步，后面四步全靠人扛。有人试过用 Prompt 来解决这个问题。在 Prompt 里加上编码规范、加上项目结构说明、加上"必须通过以下测试"的约束条件，试图让 AI 一次生成就生成对。Prompt 加到 3000 token，模型的注意力开始分散，某些规则会被忽略。加到 5000 token，不同规则之间开始冲突，模型自己都不知道该听哪条。更根本的问题是，Prompt 只能影响一次生成。它管得了"这一轮输出什么"，管不了"输出之后怎么验证"，更管不了"验证失败之后怎么重试"。Prompt 解决的是单次生成问题，不是持续执行问题。用 Prompt 做执行系统，就像用备忘录做项目管理——小任务能凑合，稍微复杂一点就崩了。那真正的 AI Coding 执行系统应该长什么样？其实答案就藏在传统软件工程里。传统工程不只有代码，还有编译、测试、部署。这三样东西的核心价值不是"让代码变多"，而是"让代码成立"。编译确保语法正确，测试确保逻辑正确，部署确保环境正确。AI 编程也需要同样的东西——不是更好的生成，而是更完整的"让代码成立"的基础设施。一个最小的 AI Coding 执行系统包含五个环节。第一个环节是 Intent，意图理解。把用户的需求转化成 AI 能执行的任务描述，包括上下文、约束条件和验收标准。这一步做得好不好，直接决定了后面四步要循环几轮。第二个环节是 Generate，代码生成。这是今天所有人关注的部分，也是整个链路中最不需要操心的部分——模型的生成能力每几个月就在进步。第三个环节是 Run，执行运行。生成的代码必须在真实环境里跑起来，不是在沙盒里假装跑通。类型检查、依赖解析、编译构建，这些都在这一步发生。第四个环节是 Verify，结果验证。跑起来了不等于对了。单元测试、集成测试、接口契约校验、甚至 lint 检查——所有能自动化验证的质量关卡，都应该在这一步拦住问题。第五个环节是 Retry，反馈重试。验证没过的，把错误信息和上下文自动打包，反馈给模型，触发下一轮生成。不需要人去读报错、组织 Prompt、手动重试。这五个环节串起来，就是一个完整的执行循环。我朋友手动做的那些事情，每一件都应该被系统接管。理解了这个结构，你就能看清楚两种截然不同的 AI 编程模式。第一种模式：AI 是工具。你向 AI 提需求，AI 给你代码，你自己跑、自己测、自己改、自己重试。所有的执行逻辑在你脑子里，AI 只负责生成那一下。这种模式下，AI 的价值上限取决于你个人的执行带宽——你能手动循环几轮，AI 就能帮你到几轮。第二种模式：AI 是执行系统的一部分。生成、运行、验证、重试，全部由系统编排。你负责定义意图和验收标准，系统负责把意图变成通过验证的代码。循环跑多少轮、每轮怎么组织上下文、失败了怎么回退，都是系统的事。第一种模式的天花板是人的精力。第二种模式的天花板是系统的设计。这也解释了 Skill 和 Agent 在整个体系里的位置。上一篇我说过，Skill 是能力单元——指令加规则加上下文加工具。Agent 是执行者——拿着 Skill 去完成具体任务。但 Skill 和 Agent 都不是执行系统本身。打个比方，Skill 是锤子，Agent 是工人，但工厂不只是工人加锤子。工厂还需要生产线、质检站、物料配送系统、异常处理流程。执行系统就是这条生产线。它决定了哪个工人在什么节点用什么工具做什么事，做完之后交给谁验收，验收不过怎么返工。没有执行系统，Skill 再强也是单兵作战，Agent 再多也是无序并发。第一，AI Coding 不是写代码，而是设计执行系统。写代码是 AI 的事，设计让代码成立的闭环是工程师的事。工程师的核心产出不再是代码本身，而是 Intent → Generate → Run → Verify → Retry 这条链路的质量。第二，Prompt 解决不了执行问题。Prompt 只能优化单次生成，但 AI 编程的真正瓶颈在生成之后——运行、验证、反馈、重试。把精力花在 Prompt 调优上，不如花在执行基础设施上。第三，AI 编程的效率差距，本质上是执行系统的差距。同样的模型、同样的任务，有人两小时手动循环 7 轮，有人 15 分钟系统自动跑完。差距不在模型智力，不在 Prompt 技巧，在于一个人在人肉做执行系统，另一个人已经把执行系统搭好了。下一篇我会写：为什么 AI Coding 需要一个 Coder Engine。当执行系统的五个环节开始具象化，它到底应该长什么样、怎么跟现有的开发工具链集成、边界在哪里。如果你也在用 AI 写代码，却总觉得"AI 挺快但我不快"——问题大概率不在 AI，而在你还没有把自己从执行循环里解放出来。转发给你身边还在手动跑循环的朋友，这个弯路不必每个人都走。
夜雨聆风