Awesome Architecture

简体中文

English

简体中文

English

外观

26 · 协作决策树:何时 vibe、何时 spec-first ​

一句话点题:不是「该不该用 AI 写代码」,而是「这一段,该放手 vibe,还是先把规格立好再让它写」。原型尽情 vibe,生产用判断收口——这一章把前三章(规格 / 审查 / 评测)收成一棵能照着走的决策树,也为 AI 协同设计篇收口。

🤝 AI 协同设计篇最后一章。 你已经走过四段能力:看懂系统、从 0 设计(01–09)→ 驾驭做大做关键的硬骨头(10–17)→ 把方法落到真实 AI 系统(18–22)→ 学会把约束写给 AI、审查它、给它的质量守门(23–25)。这一章把最后三件武器收成一套 workflow。

开场:三件武器,什么时候用哪件? ​

23/24/25 给了你和 AI 协作的三件武器:

   规格(23) ── 事前:把约束写成 AI 能遵守的护栏
   审查(24) ── 事后:拿清单逐条补 AI 漏掉的
   评测(25) ── 持续:用 eval 守住质量分布

但全套武器都掏出来,是有成本的——写 ADR、建 eval、逐条审,都要时间。给一个周末玩具上这一整套,是另一种过度设计。 所以最后一个、也是最重要的判断是:

这一段代码 / 这个系统,到底值不值得「重装上阵」?——还是该放手让 AI 飞?

一、第一个分叉:这东西是什么性质? ​

一切从这个问题开始(17 章 那句「玩具尽情 vibe、生产用判断收口」的展开):

   这段代码/这个系统是什么性质?
        │
        ├─ 玩具 / 原型 / 探索 / 一次性脚本 / demo
        │     → 【尽情 vibe】越快越好,别过度设计
        │        (呼应 04 章「能不用就先别用」、09 章「克制」的审美)
        │        审查?跑通就行。eval?不需要。规格?脑子里有就行。
        │
        ├─ 中间地带(内部工具、不碰钱的小功能)
        │     → 【vibe 出草稿,判断收口】
        │        快速生成 → 挑相关清单项审一遍(24) → 上
        │
        └─ 生产 / 关键路径 / 碰钱碰数据 / 要长期维护 / 多人协作
              → 【spec-first】先把规格立好,再让 AI 在护栏内写
                 规格(23) → 生成 → 审查(24) → eval 门禁(25) → 上线

关键:vibe 和 spec-first 不是「水平高低」,是「场景不同」。 把生产系统当玩具 vibe 上线,是 17 章 警告的危险(把没读过的房子交给用户住);但给一个一次性脚本写一套 ADR + eval,是把时间烧在没有取舍的地方。判断力,首先体现在「认出这是哪种场景」。

二、spec-first 的完整循环(把三件武器串起来) ​

一旦判定「这是生产级」,三件武器就组成一个循环——而且是个会复利的循环(正是 08 章 结尾那个「判断 + 记录」复利循环在 AI 时代的样子):

        ┌──────────────────────────────────────────────┐
        │                                              │
        ▼                                              │
   ① 立规格(23)            ② AI 生成实现                │
   ADR + AGENTS.md     ──▶  在护栏内 vibe 出草稿         │
   + 适应度函数              (实现廉价,放手让它快)        │
        ▲                        │                      │
        │                        ▼                      │
   ⑤ 演进:新约束          ③ 审查(24)                    │
   回写进规格          ◀──  按清单逐条补 AI 漏的          │
        │                        │                      │
        │                        ▼                      │
        └──────────  ④ eval 门禁(25)                     │
                     质量达标才上线,守住不退化 ──────────┘

每转一圈,你的规格库(ADR + AGENTS.md + eval 集)就更厚一层——下一次 AI 写得更合规、审查更省力、退化更难发生。这正是 08 章 说的:判断力在每一圈里复利增长。 区别只是:过去这个循环的执行者是人,现在「实现」那一步交给了 AI,而规格、审查、守门——判断的部分——仍然是你的。

三、把分叉量化:几把尺子 ​

「生产还是玩具」有时不黑白分明。用几把尺子量(它们全是前面章节的尺子):

维度偏向 vibe偏向 spec-first来自
可逆性错了随时删、重来错了难回滚(碰了钱 / 数据 / 已发出去)12
爆炸半径只影响自己 / 一个 demo影响真实用户 / 全站16
碰不碰钱 / 敏感数据不碰碰(钱、隐私、合规)19
寿命一次性 / 短命要长期维护、多人接手08
质量可容忍度偶尔出错无所谓必须稳定、不能退化25

越往右,越值得为它支付「规格 + 审查 + eval」的成本。这张表本质就是 06 章质量属性 的应用:你不是在选「要不要严谨」,而是在判断「这个系统,严谨的收益配不配得上它的成本」。

四、同一个判断,也决定「要不要放飞自主性」 ​

这棵决策树和 22 章 那个「工作流 vs 自主 Agent」是同一个判断的两种形态:

   写代码时:  能确定规格就 spec-first,别全程 vibe 上生产
   建 AI 系统时:  能用确定工作流就别上自主 Agent(22 章)
                  ╲                    ╱
                   都是同一句克制:
            「能用可预测、可控的方式解决,就别选不可控的那种」

无论是「让 AI 写代码」还是「让 AI 在运行时自主行动」,放飞的自由度越大,就越需要规格、护栏、审查、eval、人审来收口。可预测性是工程美德——这条贯穿 04(能单体就别微服务)、22(能工作流就别 Agent)、到本章(能 spec 就别裸 vibe 上生产)。

五、回到原点:你练的到底是什么 ​

走到 AI 协同设计篇末尾,我们回到 01 章 和这个仓库存在的理由:

写代码正在变廉价,而架构判断力,正变得前所未有地稀缺和值钱。

这套教程从头到尾,教的从来不是某个框架、某种语法——那些 AI 几秒就能产出。教的是一种不会贬值的东西:

   会贬值的(AI 正在让它廉价)        不会贬值的(前面这些章节练的)
   ──────────────────────         ──────────────────────────────
   • 记住某个 API / 语法            • 拿到模糊需求,问出对的问题(02/07)
   • 手写样板实现                   • 在取舍中做有据的决策(06/08)
   • 把代码敲对、敲快                • 看清系统会死在哪、该换什么(12/13/14)
                                    • 把约束写给 AI、审它、为它的质量守门(23–25)
   ────────────────────            ──────────────────────────────
   → 交给 AI                        → 这,才是 AI 时代的你

而 AI 协同这一篇(23–26)其实在说一件事:架构判断力,在 AI 时代不仅没过时,还多了一个全新的、极高杠杆的用武之地——通过「规格 / 审查 / 评测 / 决策」这个接口,把你的判断,变成一支 AI 大军的行为约束。 你不再只是「设计一个系统」,而是「设计一套让 AI 持续造出好系统的护栏与流程」。这是判断力的放大,不是替代。

架构智慧:vibe coding 不是判断力的终结,是它的杠杆。 一个有判断力的人 + AI = 十个人的产出;一个没判断力的人 + AI = 十倍速地制造你看不懂、扛不住、改不动的系统。决定结果的,从来不是 AI 多强,而是握着方向盘的人,看不看得清地图。

🎯 随堂检验 ​

🤔周末写一个抓取公开数据、自己用一次就丢的小脚本。按本章决策树,最合理的做法是?
  • A也要先写 ADR、建 eval 集、配 CI 门禁,严谨第一
  • B尽情 vibe——一次性、可逆、不碰钱、爆炸半径只有自己,快速生成跑通即可
  • C不能用 AI 写,必须手写才靠谱
🤔在 AI 时代,这套教程认为开发者最核心、最不可替代的能力是?
  • A比 AI 更快地手写实现代码
  • B架构判断力——问对问题、做有据的取舍、看清系统会死在哪,并通过规格/审查/评测把判断变成 AI 能遵守的护栏
  • C记住尽可能多的框架和 API

本章小结 ​

  • 第一个分叉是「性质」:玩具/原型/一次性 → 尽情 vibe;生产/关键路径/碰钱碰数据/长期维护 → spec-first;中间地带 → vibe 草稿 + 判断收口。vibe 与 spec-first 是场景不同,不是水平高低。
  • spec-first 是个复利循环:规格(23)→ AI 生成 → 审查(24)→ eval 门禁(25)→ 演进回写规格。每转一圈规格库更厚,这是 08 章 判断+记录复利循环的 AI 版——实现交给 AI,判断仍是你的。
  • 用尺子量分叉:可逆性、爆炸半径、碰不碰钱/数据、寿命、质量容忍度——本质是 06 章 的取舍,判断「严谨的收益配不配得上成本」。
  • 同一句克制:能 spec 就别裸 vibe 上生产、能工作流就别放飞 Agent(22)、能单体就别微服务(04)——可预测性是工程美德。
  • 判断力是杠杆,不是被替代:有判断力的人 + AI = 产出放大;没判断力的人 + AI = 十倍速制造扛不住的系统。

🤝 AI 协同篇结语:判断力继续往下走 ​

到 26 章为止,你已经走过一条主线:

   01–09  看懂系统、从 0 设计一个中小系统      —— 建立判断
   10–17  驾驭分布式/失败/规模/演进/组织/安全   —— 驾驭硬骨头
   18–22  把方法落到真实 AI 系统(读→设计→     —— 实战练手
          演进→拆迁→AI 原生)
   23–26  把约束写给 AI、审查、评测、决策协作    —— 与 AI 协同
   ────────────────────────────────────────────────────────
   贯穿始终:  代码会变,框架会换,但「先看清地图再上路」的
              判断力,在你整个职业生涯里持续增值。

这套教程给你的从来不是结论,是提问的能力。当你对每一个技术选择、每一段 AI 产出,都能自然地问出「为什么是它?代价是什么?会死在哪?」——你就已经在用架构师的方式思考了。

继续往下走。 会设计、会协作之后,你还会在真实项目里不断遇到「到底用什么技术」的问题。下一篇 27 · 编程语言与后端框架选型 开始,我们把同一套架构判断力落到技术栈选型上:语言、数据库、缓存、API、部署、观测、AI 基础设施,都不再凭热度拍板。

想要一个「带着走」的教练,就用配套的 architecture-copilot skill——它把这套教程变成在 Claude Code / Cursor / Codex 里一步步引导你做架构判断的交互式伙伴。

相关链接 ​

💬 评论