他让 AI 写代码先“自我约束”：Vibe Engineering 的反直觉实战

大多数人还在教 AI 怎么多写点代码时，Michael Arnaldi 做了一件更狠的事：先给 AI 立规矩。这场关于 Vibe Engineering 的工作坊，核心不是更聪明的模型，而是如何用“Effect + 规则”让 AI Agent 不犯低级错、持续产出可维护代码。

反直觉的开场：问题不在模型不够聪明

一上来，Michael 就泼了盆冷水：我们总把大语言模型当“人脑”，这是用错方式的根源。模型并不是不知道怎么写代码，而是不知道什么不该写。他点破一个行业幻觉——把仓库 clone 给模型、指望它“看懂文档”，并不能解决过时知识和坏模式的问题。真正的难点是：当模型产生看似合理、但长期会腐蚀代码库的模式时，谁来阻止它？

从空仓库开始：让 AI 在规则里创作

工作坊的演示极其克制：一个完全空的项目，初始化仓库，然后才引入 Agent。关键动作不是“多喂上下文”，而是逐步加入 effect 作为子树，把“好代码的边界”编码进去。当 AI 生成坏模式时，不是事后 review，而是通过规则直接拦截。这种做法的隐含逻辑是：与其让模型记住所有最佳实践，不如让它在违规时立刻被纠正。

真正的主角：Effect、HTTP API 和 Linter

随着实现 HTTP API，Michael 给出了一个非常工程化的结论：这个仓库里最强的默认 effect，是先定义共享的 HTTP API，再从中派生 OpenAPI。注意这里的顺序——不是先写实现，而是先定契约。他甚至提到，在某些项目中会直接禁止类型强转，避免模型“偷懒”。而当 linter 介入后，AI 不再只是生成器，而是被纳入持续约束系统的一部分。

AI Agent 的现实用法：不是自动驾驶，是防撞系统

在查找持久化策略时，Agent 会主动去 effect 仓库和 AI 文档里找思路，这一幕很“未来”。但 Michael 的态度非常清醒：Agent 更像一个装了护栏的驾驶员。测试、规则、llinter 插件，都是为了一个目标——让你敢于 commit。不是因为代码完美，而是因为系统会持续把它拉回正确轨道。

总结

这场工作坊给 AI 工程师的最大启发不是某个工具，而是一种心态转变：不要指望模型自律，要用工程手段约束它。如果你在做 Agent、自动写代码或复杂系统，下一步不该是换更大的模型，而是思考：哪些模式必须被禁止？哪些 API 是全局真理？把这些变成 effect 和规则，AI 才会真正“好用”。留给你的问题是：如果你的代码库明天全交给 Agent，它最先会在哪犯错？

关键词： Vibe Engineering， AI Agent， Effect， 大语言模型， 工程约束

事实核查备注： 需要核查：1）视频中提到的模型版本“GPT 5.4”的准确性；2）Michael Arnaldi 的身份与所属项目 Effectful；3）工作坊的完整时长与具体演示顺序。