双 Agent 协同复盘：AI 建站背后的工程方法论
不教操作、不讲代码——复盘一次让两个 AI Agent 分工建站的经历，提炼出真正可复用的工程方法：怎么分工、怎么验收、怎么让 AI 的产出有质量。与《30 分钟、1.36 RMB：从零搭建 CyanLabs 原型》互为姊妹篇：那边是第一次的经历，这边是沉淀下来的方法。
你正在看的这个网站，是两名 AI Agent 分工协作、从一个空目录里一步步搭出来的。不过这篇文章不是操作手册——具体怎么第一次上手、花了多少钱，我在《30 分钟、1.36 RMB：从零搭建 CyanLabs 原型》里已经写过。这篇想聊的是更值得沉淀的东西：一次让 AI 建站的真实经历，能提炼出哪些通用的工程方法？
先回答一个根本问题：为什么要自建站
在讲方法之前，得先讲动机——因为方法是为目标服务的。当初没有把内容丢到现成的平台上，而选择自己建站，理由有四个：
- 多主题叙事——AI 与本地算力、摄影与光学、量化交易、生活省钱。跨度这么大的内容，需要一个能各自成体系、又能统一品牌的内容架构，现成平台给不了这种自由度。
- 极致的访问性能——静态站的页面几乎都是秒开，对内容站来说是实打实的阅读体验与流量杠杆。
- 近乎为零的维护成本——纯静态内容放到免费的静态托管上，没有服务器要养，个人项目可以长期「躺平」。
- 内容即代码——文章以结构化文件管理，配合强类型校验，字段写错会在发布前被拦住，而不是上线后变成一处隐性事故。
但作为独立开发者，最稀缺的资源是时间。所以真正的命题不是「要不要建」，而是「怎么用最少的工程投入建出来，还保持能打的品质」。这正是双 Agent 协作登场的理由——而我后来才意识到，这件事真正有价值的产出不是网站本身，而是逼出了一套「怎么让 AI 干出工程活」的方法。
为什么一个 AI 不够：指挥与执行的分裂
很多人第一次用 AI 干活都会撞上同一堵墙：同一个 AI，既当大脑又当手，常常两头都做不好。
聊天式的 AI 是出色的顾问——出主意、讲道理、给方案，头头是道；可真让它坐进文件系统里，老老实实建出几十个文件、一遍遍跑命令直到成功，它就容易「使唤不动」。反过来，一个能真正操作电脑和目录的 Agent 很能埋头干活，但让它同时把握全局架构，又容易陷进细节里出不来。
这不是哪个模型不行，而是两种能力天然互相干扰：全局规划需要「站得高」，精细执行需要「扎得深」，塞进同一个上下文里，彼此都是噪音。
解法不是换一个更强的 AI，而是拆开：
一个 Agent 当「总指挥」：负责架构决策、任务编排、流程跑通、质量验收——它站得高，但不陷进像素级实现。 另一个 Agent 当「焊工」：每次只接一个定义清楚的精细任务，把细节做到位——它扎得深，但不碰全局。
最贴切的比喻是船长和焊工：船长决定航线，焊工打磨焊缝。让船长去焊每一道缝，全局就开始漂移；让焊工去定航线，他会执着于当前这块板的完美，忘了整条船要去哪。
方法一：类型即契约——把「正确」提前到能自动检查的地方
AI 写文章、写代码，最让人不放心的就是「看起来对，实际错」。与其事后人肉校对，不如让错误根本没有藏身之处。
这次建站给我的第一课：内容不是一堆散乱的 Markdown，而是有「契约」的结构化数据——每篇文章必须声明标题、日期、分类这些字段，字段的类型和取值范围被提前定义死。谁违反了契约，构建命令直接红字拒绝，根本走不到上线那一步。
这套思路可以平移到任何 AI 协作场景：
- 给 AI 的任务，先定义清楚「交付物必须长什么样」（结构、字段、边界），而不是一句模糊的「帮我写一篇」
- 凡是能被机器检查的（格式、类型、必填项），一律让机器检查——人眼只留给你真正在乎的质量问题
- 契约越早定越好。先定「什么是合格」，再让 AI 开工，返工率会断崖式下降
方法二：验收是命令，不是感觉
双 Agent 协作里最微妙的关系是信任：AI 说「我做完了」，凭什么信？
我的答案是：不信它的嘴，信命令的退出码。
每一个子任务交付后，总指挥不靠「看代码感觉还行」，而是跑一遍统一的自动化验收——编译、检查、全站构建，任何一环报错就地打回，修到全绿才算完。规则对两个 Agent 一视同仁，包括总指挥自己。
这条原则的价值怎么强调都不过分：
- 「完成」有了客观定义，AI 的自我评估和人类的模糊感觉都不再算数
- 返工成本被前置——错误在本地被抓住，而不是上线后变成 404 或乱版让读者看见
- 多 Agent 之间有了共同语言——「过没过」一句话就能对齐，不需要互相读代码
让机器当裁判，人才能从「盯过程」里解放出来，只做真正需要判断力的事。
方法三：任务书要把「美学」翻译成「规则」
AI 干活最常见的失败模式不是不会做，而是「自由发挥过头」——你说「做个好看的卡片」，它给你 17 种风格各异的卡片。
解法是把模糊要求脱水成可执行的硬规则。这次实践里，每个精细组件下发时都带着一份任务书，里面写死的不是形容词，而是可检验的规则，例如：
- 主指标用什么字号、什么层级，写成具体的规格
- 数值的「好/中/差」怎么分档、每档什么颜色——把「健康感」翻译成阈值和色值
- 回撤超过多少要标红、加什么符号——把「警示」翻译成条件
- 能用纯样式解决的，不许引入额外依赖——把「轻量」翻译成约束清单
规则化之后，焊工 Agent 可以零追问地开工，交付物一次通过率肉眼可见地提高。你在意什么，就把它变成可检查的规则；规则覆盖不到的，才是 AI 的发挥空间。
方法四：切面要小，边界要硬
多 Agent 协作最怕「越权捣乱」——焊工写着写着，顺手把全局配置改了；总指挥手痒，跳进组件里改了两行样式。单看都是小事，累积起来就是架构漂移。
三个纪律，这次踩过之后固化成习惯：
- 任务切面要小——一次只让执行者碰一个文件、一个组件，污染面从源头被限制住
- 权限要写进任务书——明确告诉执行者「只写目标文件、不装依赖、不动全局配置」，越权即返工
- 收口必须回归——任何子任务合入前，由总指挥统一跑一遍全站验收，不合格就地打回
这套纪律的本质是让每个 Agent 都待在它的能力半径内——总指挥不写像素，焊工不碰架构，各守边界，整体才不会乱。
踩过的坑 & 三条建议
- 别让总指挥写像素——全局决策和局部实现混在一起，是双 Agent 项目最大的坑。任务书里连「只允许用什么技术、禁止引入什么」都要写清，模糊是返工的温床。
- 先定契约，再开工——交付标准（结构、类型、验收命令）是后面所有工作的「法律」，越早定义，后面越顺。边干边定规则，等于让 AI 在流沙上盖楼。
- 把验收做成一条命令——「完成了」不是任何一方说了算，而是自动化验收的退出码说了算。这一条能同时救你、救 AI、救协作里的信任。
结语：这套方法比网站本身更值钱
回头看，双 Agent 协作建站最大的收获不是「省了几天」，而是验证了一套可持续运转的 AI 工程方法：分工有哲学、交付有契约、验收有命令、边界有纪律。CyanLabs 之后每一篇新文章、每一次改版，都跑在这套系统上——而且这套方法不绑定任何特定工具，两个互补的 Agent、快慢搭配的模型组合，谁都可以这么搭。
这个站点本身就是活着的证明——你现在读到的排版、双主题、四大专栏的骨架，都是这套工作流的产物。至于第一次上手时的真实体验、那个连自己都惊讶的成本账本，去看姊妹篇吧：
姊妹篇：《30 分钟、1.36 RMB：从零搭建 CyanLabs 原型》——一个 AI 爱好者第一次让 Agent 干活的完整经过。
建站日记系列：缘起：一个视频和一篇旧博客 · 30 分钟原型 · 双 Agent 方法论 · 上线与收录
本文由「总指挥 + 焊工」工作流中的总指挥执笔，记录于 CyanLabs /ai 专栏。