拒绝Vibe Coding：Matt Pocock的AI编程工程化实践

最近有个GitHub仓库特别火，八万多Star，叫Skills，作者是前Vercel工程师Matt Pocock。这个仓库的副标题特别有意思，叫'Skills for Real Engineers'——给真正的工程师用的技能。它本质上是在说一件事：现在大家都在聊Vibe Coding，凭直觉让AI随便生成代码，但这条路可能走偏了。 对，Vibe Coding这个概念是Andrej Karpathy今年初提出来的嘛，就是你用自然语言跟AI说你想要什么，它直接给你生成代码，你甚至都不用去看生成的结果。说实话，做快速原型的时候确实爽，效率惊人。但Matt Pocock的观点恰恰相反——他认为在AI时代，软件工程的基础不仅没过时，反而比以往任何时候都更重要。 这个判断挺反直觉的。很多人觉得有了AI，门槛降低了，不用那么讲究了。他为什么会得出相反的结论？ 因为他观察到AI编程有三个致命痛点。第一个是需求对齐失败。你跟AI说'做一个登录页面'，它立刻就开始写HTML和CSS，但忘记密码怎么办？第三方登录要不要支持？错误提示怎么设计？这些关键场景它完全没考虑。你以为它懂了，其实它根本没懂。 嗯，这个我深有体会，经常返工。 第二个痛点是术语混乱。AI被空降到一个项目里，它不了解你团队的业务语言，只能用通用词汇去猜，生成的代码命名乱七八糟，风格也不统一。第三个是最要命的——架构退化加速。你想啊，以前人写代码，敲键盘的过程本身就是一个思考的过程，相当于一个天然的减速带。但AI每秒能生成几百行代码，完全绕过了这个思考环节。原本清晰的代码结构，在AI的高速输出下，迅速变成一座'屎山'。 这个比喻太形象了。其实就是热力学第二定律在软件工程里的映射——系统的混乱度总是趋向增加，AI只是把这个过程加速了十倍。 没错，Matt有句话说得特别狠：如果你不懂软件工程，AI只会帮你以十倍的速度制造垃圾代码。以前写一段烂代码可能要几天，现在AI几秒钟就能生成成百上千行烂代码，不加控制的话，整个项目很快就会被拖垮。 所以他的解法是什么？我看他这个Skills仓库里有好几个核心技能。 他最受欢迎的一个技能叫GrillMe。Grill在英文里是盘问、考问的意思。启用之后，AI不再是那个只会说'好的马上写'的顺从助手，而是变成一个严厉的面试官。你说要做登录页面，它不会马上动手，而是反过来问你：用户忘记密码怎么办？需要第三方登录吗？登录失败的提示怎么设计？它会不断追问，逼着你把模糊的想法具象化，直到每一个分支都理清楚。 这个思路很妙啊，等于是把需求分析这个环节强制前置了。不是AI来猜你想要什么，而是AI逼着你把自己想要什么说清楚。 对，而且他还有一个进阶版叫GrillWithDocs。这个就涉及到领域驱动设计的思想了。简单说，就是AI在考问你的同时，还会去检查项目里已有的领域语言和Context.md文件。比如你的团队管'用户'叫'客户'，管'订单'叫'交易'，AI读了这些文档之后就会自动用团队的术语，不会再自己编造词汇。而且当你用了模糊或冲突的术语时，它会当场追问，然后把确认的术语沉淀到文档里。 这就不只是解决一次对话的问题了，而是在积累可复用的项目上下文。 你看，这就是工程化思维和Vibe Coding的本质区别。Vibe Coding是一次性的，聊完就完了；而Matt的方法是把每次讨论的成果都固化下来，变成团队的知识资产。 那架构退化的问题呢？他怎么解决AI写代码太快、架构跟不上的问题？ 他用了一个非常经典的方法——测试驱动开发，TDD。他设计了一个TDD技能，引导AI遵循'红-绿-重构'的循环。不是一口气写完所有代码，而是一个行为、一个测试，按垂直切片推进。AI先写一个会失败的测试，然后实现功能让测试通过，再重构优化，然后循环往复。这样每一行代码都有明确的存在理由，防止AI一次性生成大量未经验证的代码。 相当于给AI装了一个节拍器，强制它一步一步来，而不是一口气狂飙。 哈哈这个比喻好，说到音乐还真挺应景的——Matt在成为顶尖工程师之前，其实是一名声乐教练。 等等，声乐教练？这跨界也太大了吧。 是啊，但你仔细想想，声乐教练最核心的能力是什么？是沟通和表达。而人机协作最关键的问题，恰恰就是怎么把需求准确地传达给AI。所以他对这个问题的敏感度是天然的。 有意思。他还有一个架构审查的技能对吧？ 对，叫Improve Code-Based Architecture。他建议开发者定期运行这个技能，让AI从全局视角审视整个代码库，找出那些接口复杂、难以测试、容易出bug的地方，然后提出改进方向。就像给代码库定期做体检，在技术债务累积到不可收拾之前及时干预。另外还有Diagnose技能用于结构化地排查bug，To PRD技能可以把对话整理成产品需求文档直接发到GitHub Issues或者Linear上。 听下来，这些其实都不是什么新发明——TDD是Kent Beck二十多年前提出的，领域驱动设计是Eric Evans零三年的东西，架构决策记录也是十几年前的实践。Matt做的事情，本质上是把这些经典方法论适配到了AI工作流里。 你说到点上了。这也是Matt带给我们最大的认知反转。很多人以为有了AI就不需要懂架构、不需要写测试了，但事实恰恰相反。AI是一个极其强大的执行者，但它缺乏对复杂系统的全局把控能力。这跟Fred Brooks在《人月神话》里说的一样——软件工程的核心困难不在编码本身，而在概念完整性和系统设计。AI解决了编码效率的问题，但概念完整性的挑战反而因为生成速度的提升变得更尖锐了。 所以最聪明的AI编程方式，反而是限制AI的自由度。 对，通过流程化、规范化、可验证化，让AI在约束中发挥最大价值。人类负责定义问题、设计架构、制定规范；AI负责编写代码、生成测试、执行重构。这才是健康的人机协同范式。 其实这个道理放到任何领域都成立——完全不受约束的自由不会带来最优输出，反而会导致系统失控。未来真正厉害的工程师，不是被AI替代的码农，而是知道什么时候该让AI自由发挥、什么时候该严格约束它的人。软件工程的基本功，在AI时代反而成了最核心的护城河。