当 AI 写代码越来越快，工程师却可能越来越“不知道自己写了什么”

过去两年，AI 编程助手几乎成了软件开发圈的新空气。打开聊天窗口，描述需求，来回改几轮，一段“能跑”的代码很快就出现了。速度确实惊人，尤其对原型开发、小工具、脚手架类任务，体验堪称丝滑。问题也恰恰出在这个“能跑”上：它常常只是能跑，却未必经得起下一次迭代，更别提长期维护。

意大利开发者、技术负责人 Matteo Barbero 最近分享了自己的一套 AI 辅助开发流程，核心观点很鲜明：AI 最擅长的是实现，而不是思考；真正决定软件质量的工作，发生在第一行代码出现之前。这个判断听上去并不性感，甚至有点“反效率”。但如果你经历过那种由 AI 快速拼出来、每个功能都似乎没问题、可一加新需求就开始塌方的项目，就会明白他在说什么。

Barbero 的表述很坦率：他曾经也陷入一种典型困境——功能上线更快了，但对系统的理解反而变少了。边界条件没人认真推敲，架构决策像临场发挥，眼下看似合理，过几周就开始报复团队。这种失控感，正在越来越多使用 AI 编程工具的团队里蔓延。今天大家讨论 Copilot、Cursor、Claude Code，讨论哪个模型补全更快、改 Bug 更准，但真正棘手的问题其实是：当生成速度超过理解速度，软件工程会不会变成一场“高质量错觉”？

他的方法不神秘，甚至有点“老派”：先写清楚，再让 AI 动手

Barbero 的工作流有七步，听起来像把产品经理、技术负责人、开发和审查的动作，重新拆开再缝了一遍。最关键的不是工具名，而是里面的秩序感。

起点不是 prompt，也不是 IDE，而是一份只有自己看的自由文本计划。开发者先用大白话写清楚：问题是什么，自己打算怎么解，已经知道哪些约束，还对什么没把握。这个步骤没有固定模板，不是为了交付文档，而是为了把脑子里那团雾拽到纸面上。说白了，它有点像程序员版本的“写日记”，但作用非常现实：如果你连需求都只能模模糊糊地描述，后面无论 PRD、任务拆解还是代码生成，都会把这种模糊层层放大。

接下来，AI 才开始登场。它先把这份自由计划转成结构化 PRD，再通过一轮近乎“盘问式”的提问，把那些开发者原本略过去的假设一一揪出来：未登录用户怎么办？操作执行到一半失败怎么办？如果新功能取代旧功能，老用户的行为路径会发生什么变化？这一段很像一个永远不嫌烦的审稿编辑，专门盯着你那些“我大概知道怎么回事”的地方反复追问。

我很认同这一环。因为生成式 AI 最大的风险，从来不是它写不出代码，而是它太擅长把模糊意图包装成看起来完整的实现。你以为自己表达清楚了，其实只是模型很会补全；你以为需求已经闭环了，其实只是对方太会顺着你的语气继续演下去。AI 不会天然替你发现业务歧义，它只会在你的歧义上生长出更多代码。

真正聪明的地方，在于它把“任务切片”做成了工程纪律

Barbero 这套流程最有意思的，是从 PRD 再往下拆成 issue 和 task 的方式。他明确反对那种只改数据库、只做接口、只做前端的“水平切片”，而更偏爱纵向切片，也就是每个 issue 都要能打通一条端到端的最小路径，能够单独演示、验证，最好还能独立合并。

这是非常典型、也非常成熟的软件工程思想。很多团队并不是不会写代码，而是太习惯把系统拆成“后端先做完”“前端再联调”“测试最后补”。人类开发时，这种模式就已经容易积累集成风险；AI 介入后，问题只会更明显，因为模型尤其擅长在局部任务上给出看似漂亮的答案，却不天然关心跨层的一致性。一个按钮可能做得很漂亮，但背后的事务顺序错了；一个接口可能能返回数据，但权限边界压根没处理干净。

所以他把 issue 继续拆成更小的 task，而且要求“一个 task 对应一次独立的 AI 会话”，如果一件事不能在一次会话里清晰完成，那就说明任务拆得还不够小。这种做法看似保守，其实非常符合大模型的工作特性。长上下文确实强大，但也极其容易漂移：模型会被前面自己说过的话绑架，沿着既有路径继续生成，而不是老老实实回到当前任务本身。很多开发者都有类似体验，和 AI 聊到第 40 轮之后，整个会话像一列刹车失灵的火车，速度不慢，但已经不太知道开去哪里了。

更妙的是，他把任务说明写成“给 AI 的指令”，而不是“给同事看的备忘录”。这里藏着一个很实际的趋势：未来不少研发文档，第一读者可能不再是人，而是模型。文档的对象变了，写法也必然改变。它不需要花哨，不需要情绪价值，但必须边界明确、文件指向清楚、完成标准可验证。这可能是 AI 时代工程文档最值得关注的变化之一。

这不只是一个个人习惯，它指向了 AI 编程的下一阶段竞争

现在行业里最热闹的，还是模型能力竞赛。谁能写更多代码，谁能自动修更多 bug，谁能把 IDE 变成半自动驾驶舱。可 Barbero 这篇文章提醒我们：下一阶段真正拉开差距的，未必是“谁更会生成”，而是谁更会组织生成。

从这个角度看，他的流程和最近一些大厂在做的事其实暗暗同频。无论是 Anthropic 强调的可控代理（agentic workflows），还是 OpenAI、GitHub、Cursor 不断强化的多步任务管理、审查与上下文切换，本质上都在承认一件事：AI 编程已经不是单次问答问题，而是一个包含规划、拆解、执行、审查、回滚的系统工程。谁能把这条链条治理好，谁才能真正把 AI 变成生产力，而不是 bug 放大器。

Barbero 尤其强调代码审查和最终审计。他设计了六轮代码 review，专门检查逻辑错误、操作顺序、安全问题、魔法值和模式改进。其中“操作顺序”这一项，我觉得说到了 AI 代码最常见、也最隐蔽的痛点：模型很容易写出“每一步都对、顺序却错”的代码。比如事务还没提交就先发通知，输入还没校验就先修改状态，审计日志写在动作之后而不是之前。人眼扫过去往往觉得没毛病，因为每一行都像是合理的，但拼起来就是事故现场。

这一点也让人想到自动驾驶领域的一个老问题：系统不是完全不会开，而是会在看似平静的时刻犯一种非常人类不易察觉的错。AI 编程正在面临类似局面。真正危险的不是明显写挂，而是“看起来像对的”。因此，审查机制正在变得和生成能力本身一样重要。

但这套方法也有代价：它更像工业化开发，不适合所有人

说到底，这不是一套追求“今晚灵感来了，明天产品就上线”的玩法。它前期很重，文档很多，节奏不快。对独立开发者、黑客松、MVP 验证阶段的人来说，这种流程未必划算。你要是只想做个周末工具，先写自由计划、再产 PRD、再拆 issue、再拆 task，可能还没开始编码，激情就被流程消耗掉了。

但如果项目开始涉及多人协作、线上用户、复杂权限、数据库迁移，尤其是要长期维护的时候，这种“先慢下来”的价值就会越来越明显。软件行业这些年一直在两个极端间摇摆：一边是“文档已死，代码即真相”，另一边是流程至上、文档泛滥。AI 的出现，其实把这个老争论重新点燃了。我的看法是，文档当然不会自动带来好软件，但在生成式编程时代，没有结构化文档的团队，迟早会为“上下文失控”付出代价。

更值得玩味的，是这套方法背后的权责划分。Barbero 反复强调，AI 负责加速产出，人类负责审查与判断。这个边界今天看仍然清晰，但未来会不会变化？当模型越来越擅长根据代码库、日志、用户反馈自动修正方案时，人类会不会逐步退化成“签字的人”？如果真走到那一步，工程师最核心的竞争力，也许不再是写代码，而是定义问题、管理风险、拒绝错误答案的能力。

这听起来有点残酷，但也很真实。代码正在被压缩成一种更便宜的产物，真正稀缺的，会是判断力。