工程实践

前言 现在用 AI 写代码，最常见的一句话大概是： 帮我修一下这个 bug。 这句话很自然，也很方便。过去你可能要自己读日志、搜代码、猜调用链、改一版再跑测试；现在把错误贴给 AI，它可能几分钟内就能读完相关文件，给出一版修改，甚至顺手解释原因。 但问题也藏在这里。 AI 很容易让人产生一种错觉：它改得快，所以它是可靠的。可在工程里，快不等于对，更不等于可托付。真正关键的问题不是它有没有改代码，而是它能不能证明： 问题被复现过。 根因被定位过。 改动是最小的。 测试真的跑过。 风险被说明过。 失败会被记录下来。 所以我越来越觉得，AI 操作方式正在经历一个很重要的演进： Prompt -> Skill -> Loop Prompt 让 AI 听懂你。Skill 让 AI 按经验做事。Loop 让 AI 做完之后必须留下证据，并从失败中改变下一次行为。 换句话说： Skill 是 Prompt 的工程化。 Loop 是 Skill 的责任化。 一、Prompt 阶段：一次性的意图表达 Prompt 的优点非常明显：低成本、灵活、自然。 你可以直接说： 登录页打开后报错，帮我看一下。 模型会根据当前上下文去理解问题。它可能会读页面组件、查接口调用、看错误栈、修改某个字段名，然后告诉你“已经修好了”。 这个阶段适合探索问题，也适合做一次性的辅助判断。但它有一个根本缺陷：流程是隐含的。 你没有明确告诉它： 必须先复现问题。 必须说明错误从哪里来。 必须只做最小修改。 必须跑哪些测试。 必须列出没有验证的部分。 必须说明改动可能影响哪些地方。 于是模型很容易从“解决问题”滑向“看起来解决了问题”。 它可能直接根据错误信息猜一个原因，改一段代码，给出一段很顺的解释。解释可能听起来合理，但如果没有复现、没有测试、没有 diff 边界，它仍然只是一个未经证明的答案。 这就是 Prompt 阶段的边界：它能让模型开始做事，但不能保证模型按工程流程做事。 二、Skill 阶段：把修 Bug 变成工程流程 当同类任务反复出现时，继续靠 Prompt 就会变得浪费。 ...

最近我们在一次创业项目开发中，遇到了一个很典型的问题。 一开始，大家都觉得 AI 开发很香。 后端同学根据产品图，让 AI 快速生成了一套后台服务；前端同学也根据产品图，让 AI 写出了界面和交互。过去可能要花几周才能搭出来的 MVP，现在很快就能看到雏形。 这也是我一直觉得 AI 有价值的地方：它能让小团队快速补齐不熟悉的领域，能让一个人跨过前端、后端、交互、部署这些原本需要多人配合的边界。 对于创业团队来说，这种速度太有吸引力了。 但开发到后面，我们开始明显感觉不对劲。 前端拿着后端的接口手册，让 AI 去理解并修改页面逻辑；后端也根据自己的理解继续调整服务。看起来每个人都在推进，但大家对系统的理解并不一致。 前端理解的流程，和后端设计的流程对不上。 前端传的参数，和后端期望的参数不一致。 产品图里没有明确表达的状态，被前后端的 AI 分别脑补成了不同的实现。 更麻烦的是，代码量很快膨胀到了四万多行。 到了这个阶段，人已经不太愿意从头读代码了。不是完全看不懂，而是阅读和修改的成本变得很高。就算知道问题大概在哪里，也不敢轻易改，因为不知道改了这里，会不会影响到别的地方。 于是我们进入了一个很危险的循环： 发现问题，描述给 AI。 AI 改一版，继续跑。 又出现新问题，再描述给 AI。 AI 再改一版。 一开始，AI 是开发者的助手。后来，AI 成了代码的主要作者。再后来，人想改代码时，发现自己也只能继续通过 AI 去改 AI 写出来的代码。 这时候，人就有点像上下文搬运工。 产品的问题，要转述给 AI。 接口的问题，要转述给 AI。 前端的报错，要转述给 AI。 后端的文档，也要转述给 AI。 每个人都很忙，但忙的不是在建立系统理解，而是在不同的 AI 对话、代码、文档、报错之间搬运上下文。 我并不反对 AI 开发。恰恰相反，我依然认为 AI 是趋势。AI 能帮助创业团队更快做出 MVP，能让开发者进入自己原本不熟悉的领域。 但这次经历让我意识到一个问题： AI 能帮我们写出更多代码，但不会自动帮团队形成共同理解。 如果没有共同理解，代码增长得越快，团队失控得也越快。 问题不在 AI，而在没有工程护栏 这次最明显的问题，是前端和后端都基于产品图让 AI 生成代码。 产品图能说明用户看到什么，但它不能完整说明系统之间怎么通信。它不会天然定义请求参数、响应字段、错误码、状态流转、边界条件和异常处理。 ...