最近在使用 SpecCoding 模式与 AI 结对编程的深夜里，我突然悟出了一个互联网大厂黑话的真谛——“签字画押”。
以前总觉得这词儿充满官僚气，现在才惊觉，我在撰写 Spec 文档的那一刻，本质上就是在给 Agent 接下来的开发工作签署一份“免责声明”。这感觉就像是与魔鬼签契约：“Spec 我写了，字我签了，要是你因为规范没写清楚而拉出一坨‘屎山代码’，后果我自负。”
最绝望的时刻莫过于此：看着那堆跑不起来的代码，刚想掀桌子骂娘，手停在半空却发现根本掀不动——谁让我懒得自己写代码？又谁让我的水平也就半桶水呢？这杯苦酒，含着泪也得咽下去。
一、 Vibe Coding：魔法失效的时刻
回望 2023 年底，我第一次让 Cursor 写代码。
“帮我写个 Python 脚本，批量重命名文件夹里的图片。”
30 秒后，一个完整的脚本赫然在目。能跑，零 Bug。那一刻的震撼无以言表——编程的门槛，似乎被彻底打破了。
那段时间，Twitter 上充斥着类似的狂欢。有人让 AI 写贪吃蛇，有人生成 SQL 查询，还有人直接重构 React 组件。这种“凭感觉编程”的方式被戏称为 Vibe Coding——不需要精确的需求文档，只要把脑子里的想法倒出来，AI 就能“领悟”并交付代码。
数据也佐证了这种乐观。到 2025 年初，GitHub Copilot 用户突破 1500 万，是 2023 年的 4 倍。绝大多数开发者在拿到授权的第一天就开始全盘接受 AI 的建议。统计显示，AI 甚至代写了开发者近一半的代码。
但蜜月期总是短暂的。
当我试图用 AI 重构一个包含 15 个文件的老项目时，魔法消失了。仅仅聊了三轮，AI 开始“失忆”——它忘了我用的是 TypeScript 还是 JavaScript，搞混了接口名称，甚至幻觉出一个根本不存在的 npm 包。
这就是 Fred Brooks 在 1986 年提出的经典论断：软件工程存在“本质复杂度”和“偶然复杂度”。
AI 可以极速消灭“偶然复杂度”——生成模版代码、修复语法错误、检索 API 文档；但它在“本质复杂度”面前依然是个孩子：这段代码该归属哪个模块？接口设计是否为了未来扩展？用户真正的痛点是什么？
Vibe Coding 在简单任务上有效，是因为这些任务的“本质复杂度”极低。一旦进入真实的软件工程——多文件协作、模块化架构、遗留系统重构——AI 就会从天才变成一个只会背书却不懂理解的实习生，吐出一堆看似完美实则逻辑崩坏的代码。
我们，撞墙了。
二、 Spec Coding：工业化的觉醒，还是陷阱？
痛定思痛，社区开始反思：也许是我们跟 AI 说话的方式错了。
2023 年起，资深开发者们将 SOLID 原则、TDD、DDD 等工程经验搬进了 AI 交互。Cursor、Windsurf 乃至后来的 Kiro 爆火，正是因为它们原生支持这种“给 AI 立规矩”的工作流。
Spec Coding 的逻辑非常硬核：拒绝模糊指令，先写“技术规格说明书”。明确库版本、定义 Interface 和 Schema、用 .cursorrules 锁定项目结构。开发者被迫从“代码编写者”转型为“架构师”和“审查员”。
这种模式确实有效。但随着依赖加深，我发现自己在做一件极其诡异的事：我写文档的时间，竟然比写代码还多。
根据工具特性的不同，目前的 Spec Coding 大致可以分为三派。每一派都有狂热信徒，也都有致命短板。
文档契约派：OpenSpec
核心逻辑：先立字据，后干活。
OpenSpec 要求在写代码前生成标准化的 Markdown 规格文件，像法律合同一样锁定所有接口、数据结构和业务逻辑。
- 优势：确定性极高。特别适合老系统重构，能清晰对比“现状”与“规格”的差异，是对抗 AI 胡编乱造的最强盾牌。
- 短板：容易沦为“文字游戏”。当代码跑不通时，AI 会摊手：“我是严格按文档写的，跑不通是你的文档逻辑有问题。”这把用户从创造者降级成了文档校对员。
流程引导派：SpecKit
核心逻辑：给 AI 装上铁轨。
通过 /plan、/tasks 等指令，强制 AI 严格遵循“需求分析 -> 计划拆解 -> 任务执行”的流水线，禁止跳步。
- 优势：战术执行力强。对中型项目，能有效防止 AI 跑题。将大任务拆解为原子任务，成功率显著提升。
- 短板：僵化。本来两句话能解决的小功能，非要逼你走完一整套流程仪式。试图用线性的工程流程去管束非线性的 AI 思维，无异于“戴着镣铐跳舞”。
拟人代理派：BMAD-METHOD
核心逻辑：赛博人海战术。
BMAD 试图在机器世界复刻敏捷团队，引入 AI 产品经理、AI 架构师、AI 测试员等近 20 种角色。
- 优势：上下文分治。不同 Agent 关注不同细节，解决了单体 AI 记不住大规模项目细节的问题。这是最接近未来 Agentic 形态的尝试。
- 短板：赛博官僚主义。修一个简单的 Bug，可能需要 5 个 AI 开个会。这种复杂的“分包体系”带来了巨大的 Token 消耗和延迟。你想快点出活，系统却在忙着“走行政流程”。
三、 真正的问题：复杂度的恶意转嫁
这三种工具的困境，指向了同一个核心矛盾：Spec Coding 将 AI 的认知负担，转嫁给了人类。
回到那个深夜。AI 生成了 500 行能跑的代码，但界面丑得让人崩溃。Spec Coding 的解决方案是什么？让我先写一份详细的 UI 规范文档——按钮间距 16px，色值 #3B82F6，圆角 8px。
但这恰恰是悖论所在：如果我能精确描述所有细节，我还需要 AI 干什么？
Conway 定律在 1968 年指出：系统的设计受限于组织的沟通结构。这条定律在 AI 时代依然成立：工具的设计反映了创造者的组织逻辑。目前的 Spec 工具，本质上是将传统软件工程的“分工协作”逻辑强加给了人机交互。结果就是，工具变得不可避免地官僚化。
更致命的是，Spec Coding 极大地抬高了门槛。如果这就是未来，AI 编程将变成一场精英游戏。初级开发者效率提升 40%，资深开发者仅提升 7% 的数据已经说明了问题——现在的 AI 是“导师”而非“专家助手”。它能帮新手执行指令，却无法替资深开发者做架构决策。
Spec Coding 解决了“偶然复杂度”，却把“本质复杂度”包装成“最佳实践”，全部推回给了人类。
四、 未来：是“对齐”，而非“契约”
未来的 AI 编程应该是什么样？
我的答案是：让 AI 更懂人，而不是让人更懂如何“喂养” AI。
Everett Rogers 的创新扩散理论提到，跨越“早期采纳者”到“早期大众”的鸿沟是技术普及的关键。Spec Coding 正卡在这道鸿沟里。 它是 13.5% 极客的玩具，却因认知负担过重而无法走向主流。
要让 AI 编程真正普及，必须超越文档和测试用例，走向更自然的人机对齐。
拒绝说明书，给我看产品 (WYSIWYG 2.0)
自然语言和技术文档本质上都是信息的“有损压缩”。未来的 Spec 不应该是枯燥的文字，而应该是 可视化原型。
想象这样的场景：你向 AI 描述需求，它直接生成 3-4 个不同方向的可交互原型。你不需要写 CSS 规范，只需要说：“我喜欢方案 A 的布局，但要方案 B 的配色”。
Spec 依然存在，但它是 AI 在后台维护的元数据，不需要你去显式编写和审查。这就是**“选择即定义”**。
别写测试用例，看着我怎么用 (VLM Reviewer)
测试全绿，但界面丑陋？这说明单元测试覆盖不了“美感”和“体验”。
未来的解决方案是引入视觉语言模型 (VLM) 充当“审查员”。一个 Reviewer Agent 像人类一样看着运行界面的截图，指出“按钮太小”、“对比度不够”、“风格过时”。然后 Coder Agent 根据视觉反馈自动修正。
Gemini 3 Pro Image 等多模态模型已经具备了这种能力。差的只是把它们整合进编程工作流。
AI 不是实习生，是技术合伙人
真正的协同编程，AI 不应是等待指令的实习生，也不应是只认文档的外包团队，而应该是你的 Technical Co-Founder。
它不该问你“确不确认这个文档”，而是直接告诉你：“老板，你这个功能会导致页面加载变慢，建议换种方式。”它会主动发现问题，给出方案，甚至在上线后自动监控并回滚版本。
这才是“对齐”。不是你把意图翻译成精确的文档，而是 AI 主动理解你的目标和约束。
五、 写在最后
回到凌晨两点。
如果是 Vibe Coding，我会继续跟 AI 说“把界面改得好看一点”，然后得到一个依然难看的盲盒结果。
如果是 Spec Coding，我得花一小时写 UI 规范，等 AI 执行，再花半小时对照文档查错。
但如果是未来？
Vibe Coding 是充满灵感的手工作坊，难以规模化；Spec Coding 是严谨的流水线工厂，却把管理重担压在了人身上。而未来的 AI 编程，应该是智能工厂与合伙人制度的结合——
人类的审美和直觉，直接耦合 AI 的执行力，中间不再隔着那张冷冰冰的 Spec 文档。
Spec Coding 这种显式的文档模式终将消亡，但它背后的“结构化思维”会内化进 AI 的模型里。那时候，我们才算真正越过了那道鸿沟。
