企业官网建设流程全解析

如果你最近常听人聊 Vibe Coding（氛围编程），又在某个深夜被 AI 批量生成的代码坑到返工，那 Superpowers 技能框架、TDD 契约驱动和工程纪律闭环这套组合，可能是你真正需要的东西。Vibe Coding 不是罪，问题在于大多数团队只拿到了 AI 的“速度”，却没拿到驾驭它的“纪律”。我用这套思路重构过一个濒临失控的项目，也带身边几个团队从“代码雪崩”里爬出来，今天把这些拆解和操作细节完整写下来。

1. “氛围编程”的坍缩路径：为什么 AI 写代码会引发雪崩

1.1 甜头：一句提示词就能跑起原型

Vibe Coding 的魅力是真金白银的。我自己第一次用自然语言让 AI 在半小时内搭出一个带登录、列表和筛选的页面时，确实有“这行要变天”的感觉。你不需要先写接口文档，不需要纠结目录结构，甚至不用把状态管理想清楚，把需求往对话框里一扔，一段能跑的代码就出来了。

问题恰恰出在“能跑”这两个字上。原型能跑，和工程能维护，中间隔着十万八千里。Vibe Coding 默认的工作模式是“你说一句，我改一版”，这个模式对零散素材、一次性脚本、演示 Demo 非常合适，但一旦进入长期维护的代码库，它会在极短的时间内制造出大量没有被验证、没有被记录、彼此之间靠“运气”连接的代码块。

我见过最典型的场景是：产品经理说“加一个优惠券功能”，AI 很配合地加了字段、改了接口、动了页面；第二天说“优惠券要分类型”，AI 又改了一遍；到第三天，原有的订单列表开始莫名报错，因为第一天的改动给订单状态留下了一个隐式假设。没人记得这个假设是什么，AI 自己也说不清。这就是氛围编程的第一块多米诺骨牌。

1.2 暗雷：未固化契约的代码假设

理解雪崩，必须先理解“契约”这个词。传统工程里，函数签名、接口定义、数据库表结构都是一种契约，它清清楚楚写着“我这里接收什么、返回什么、依赖什么”。有了契约，两边才能独立开发，互不踩脚。

但 Vibe Coding 里很大一部分代码是没有契约的。你让 AI“把用户列表改成支持搜索”，它不知道列表页被多少个模块引用，也不知道搜索参数在不同页面的语义是否一致。它只能根据周边代码猜，猜对了是运气，猜错了是埋雷。更麻烦的是，它会顺手重构掉一些看起来“没用”的代码，而那些代码可能正是某个老功能的关键分支。

这种没有契约的开发方式，很像在没有图纸的情况下不断往一栋楼上加楼层。在第五层加一个卫生间，第七层就可能会漏水；在第十层加一道承重墙，第三层的结构就要改。代码越堆越高，底层假设越积越多，直到某一天，任何一个微小改动都会引发连锁反应——这就是“代码雪崩”。

1.3 雪崩的三个阶段

我用过三个词概括这个过程：甜蜜期、膨胀期、雪崩期。

甜蜜期的典型特征是所有人都很兴奋，因为 AI 的产出速度远超人力。你会觉得“自然语言编程”终于不是概念了。进入膨胀期后，代码量上去了，但每次新增功能都必须小心翼翼，因为改动一个入口，出口会连带变化。这时候团队里开始流行一句话：让 AI 自己看上下文，它能处理。可它处理的方式往往是多打补丁，而不是重构根基。

雪崩期来的时候毫无征兆。可能只是改了一个字段名，结果十几个测试失败，整条业务链路瘫痪。更可怕的是，没有人敢让 AI 再改了，因为谁也不知道下一次修改会炸掉哪个模块。氛围编程带来的不是效率，而是失控。

经历过这个过程之后，我非常确定一件事：AI 写代码的强大能力本身没问题，问题在于我们用单次对话的方式去要求一个需要多步验证的工程过程。我们需要把“氛围”变成“流程”，把“灵感”变成“契约”。Superpowers 技能框架就是干这件事的。

2. Superpowers 技能框架：给 Agent 装上“操作手册”

2.1 它不是插件，而是一套“技能包”

Superpowers 并不是一个传统意义的库或者插件，它更像是一套可以被 AI 编程代理加载的“技能包”。以 Claude Code、Cursor 这类 Agent 环境为例，你可以在工作区里放一组技能目录，里面每一个技能都是一份结构化的操作说明，告诉 AI 在某个场景下应该按照什么步骤干。

有人会问：我给提示词里写“请遵守 TDD”不就行了？还真不行。“请遵守 TDD”是一句正确的废话，AI 可以答应你，然后继续按照旧习惯一次性生成大段代码。Superpowers 的思路是把工作流拆成可执行的技能，比如“目标澄清”“任务拆解”“测试驱动开发”“系统化调试”“Code Review”，每个技能内部都包含明确的检查点，AI 走一步验证一步。

这也是它名字的由来：让 AI 拥有“超能力”之前，先让它掌握“基本功”。写代码的基本功是什么？是想清楚再动手，是每次只改一小块，是每块都有测试兜底。

2.2 核心技能拆解：从目标澄清到 TDD

我实际用得最多的 Superpowers 技能有这么几个，今天逐个说清楚它们解决什么问题。

第一是目标澄清技能。它强制 AI 在动手前先用自己的话复述需求，并且问出模糊点。比如你只说“优化登录逻辑”，它会追问“优化是指减少请求次数、提升接口响应，还是改善错误提示？”这一步看起来啰嗦，但能避免 80% 的方向错误。氛围编程里最贵的就是返工，而返工往往不是因为 AI 写错，是因为需求没说清。

第二是任务拆解技能。它能把一个大需求切成若干个小任务，每个任务都有独立的验收条件。注意，不是简单的“第一步做 A，第二步做 B”，而是每一条都要可以被测试验证。比如“登录逻辑”会被拆成“用户名密码正确时返回 token”“密码错误时返回明确错误”“连续失败五次后触发锁定”这样的行为条目。

第三是 TDD 技能。这是整套框架的核心，也是我接下来要单独用一章展开的内容。简单说，它要求 AI 先看到失败测试，再写最小实现，最后重构。顺序不许乱，红灯不过，绿灯不许大改。

第四是系统化调试技能。它把调试过程变成“复现问题、找最小复现路径、提出假设、验证假设、修复并补回归测试”的科学流程，而不是让 AI 盲目改代码碰运气。这直接降低了“修 A 坏 B”的概率。

2.3 为什么技能框架能止住“氛围编程”的失控

因为技能框架改变了 AI 的默认工作模式。Vibe Coding 默认是“一次对话、一次产出”，Superpowers 默认是“一个流程、多个检查点”。

我做个不恰当的比喻：Vibe Coding 像是让一个很有天赋的实习生直接上手写核心模块，他下笔飞快，但他不知道自己不知道什么；Superpowers 则像是给这个实习生一本标准作业手册，里面有步骤、有检查点、有验收标准。他快，但每一步都被约束在安全范围内。

这套框架还有一个隐藏优势：把人的约束变成了流程约束。你不需要每次都在提示词里苦口婆心地说“记得写测试”“记得别改无关代码”。只要 Agent 进入对应技能，它就会按流程执行。换句话说，你是在用流程对抗模型的不确定性。

3. TDD 契约驱动：把“AI 觉得懂了”变成“AI 证明懂了”

3.1 契约先行：先定行为，再写实现

TDD 的核心不是“写测试”这三个字，而是“用测试定义契约”。所谓契约驱动，就是先约定行为边界，再让 AI 在边界内自由发挥。

我拿一个贴近业务的例子说明。假设你要让 AI 写一个计算购物车总价的函数。如果是 Vibe Coding，你会说“帮我写一个计算购物车总价的函数，要考虑折扣和运费”。AI 会立刻生成一版代码，看起来像那么回事，但你不知道它有没有处理空购物车、折扣能不能叠加、金额保留几位小数。所有规则都藏在它的假设里。

契约驱动的做法正好相反。你先把行为写成测试，让测试成为唯一的权威定义：

import { describe, expect, it } from 'vitest'; import { calculateCartTotal } from '../src/cart-total'; describe('calculateCartTotal', () => { it('空购物车返回 0', () => { expect(calculateCartTotal([])).toBe(0); }); it('商品金额相加并保留两位小数', () => { expect(calculateCartTotal([{ price: 10.005, qty: 1 }])).toBe(10.01); }); it('折扣券按比例抵扣，运费在折后计算', () => { expect( calculateCartTotal( [{ price: 100, qty: 1 }], { couponRate: 0.8, shippingFee: 5 } ) ).toBe(85); }); });

这份测试文件就是“契约”。它没有告诉 AI 怎么算，只告诉它“什么是对的”。AI 可以自由选择实现方式，但最终必须让这些测试全部通过。沟通成本因此大大降低：人只需要评审测试写得对不对，而不需要去读 AI 的每一行内部实现。

3.2 RED-GREEN-REFACTOR：限制 AI 的单步半径

TDD 的完整循环是 RED-GREEN-REFACTOR，三个词分别对应“红”“绿”“重构”。

红灯阶段，只写一个测试，跑一遍确认它是失败的。这一步很关键，是在证明“这条测试确实是用来约束新行为的，而不是一个拿了就过的摆设”。让 AI 只写测试、不写实现，很多初用者做不到，因为模型默认会顺手把实现补出来。我的办法是在提示词里单独强调“本轮只写测试，禁止修改源文件”。如果它还是没忍住，就直接终止当前对话，回滚改动，重新开始。

绿灯阶段，让 AI 写刚好能让测试通过的最小实现。注意“刚好”这两个字。不要让它顺手抽象出一个基类，也不要让它顺带重构相邻模块。这一轮改动的目标只有一个：让红灯变绿灯。

重构阶段，在测试保持绿色的前提下调整代码结构。因为已经有测试兜底，你不用担心重构过程中把某个隐藏逻辑改坏。这也是 TDD 和“随意让 AI 改代码”最大的区别：每一次重构都有自动验证，而不是靠人肉眼检查。

[[注意]] 不要让 AI 跨越三个阶段一次性完成。一旦它把“写测试、写实现、重构”全塞进同一轮，测试就失去了过程约束力，最后你只会得到一套“看起来有测试，实际没验证过程”的代码。

3.3 契约落地在哪几个层面

真正要用好契约驱动，不能只停留在函数测试层面。我一般会把契约分成四个层次，每一层防住一类雪崩。

第一层是接口契约，规定函数或 API 的输入输出。第二层是数据契约，规定对象结构、必填字段、枚举范围。第三层是行为契约，也就是测试用例里描述的边界条件与业务规则。第四层是流程契约，规定一份代码要达到什么标准才能算完成，比如“必须通过全量测试”“必须包含新增行为的回归测试”“类型检查必须通过”。

这四个层次像四道闸门。Vibe Coding 之所以雪崩，是因为只有“看起来能跑”这一道很粗的闸门；引入层级化契约之后，每道闸门都在拦截一小部分错误，最后真正落到主分支的代码已经经过多层验证。下面这张表是我在团队里做培训时常用的总结。

4. 工程纪律闭环：从一条失败测试到一次安全交付

4.1 闭环三要素：定义、执行、验证

Superpowers 技能框架给了 AI 操作手册，TDD 契约驱动给了代码行为边界，但要让这套东西真正稳定运转，还需要一个工程纪律闭环。闭环有三个环节：定义、执行、验证。

定义阶段做的事情是把业务需求翻译成可验证的契约。这个阶段人必须参与，因为只有人懂得业务意图。执行阶段是让 AI 在技能框架的约束下，按照 TDD 小步前进。验证阶段则是全量回归、Code Review、契约检查。三个环节形成一个循环，每次循环结束后的代码库，都应该比循环开始前更稳定、更清晰。

闭环的意思不是“做一遍就结束”，而是“每一次新需求都从上一个稳定点开始”。有了稳定基线，新改动即使出错，你也可以快速回滚；没有稳定基线，你永远不知道上次成功是在哪一刻。

4.2 可直接抄走的 AI 协作流程

下面这套流程是我自己在多个项目里验证过的，可以直接复制进团队协作规范。

1. 拉取最新代码，跑一次全量测试，确认当前基线是绿色的。如果基线本来就是红的，先修好再谈新功能。
2. 把需求拆成若干行为条目，每条对应一个或多个测试用例。这个阶段不写实现代码。
3. 将测试用例填入测试文件，运行一次，确认新增测试是红灯。这是契约生效的标志。
4. 把红灯测试和最小任务描述交给 AI。提示词里明确要求：进入 TDD 模式，一次只让一条红灯变绿。
5. 测试通过后，人工检查这次 diff 是否越界。如果 AI 顺手改了无关代码，立即回滚。
6. 让所有测试通过，再做小步重构。重构结束后再次全量回归。
7. 提交代码，提交信息里写明本次变更由哪些测试约束，例如：feat: 购物车支持折扣券，由 cart-total.test.ts 三个用例覆盖。

我给 AI 的任务描述模板一般是这样的：

当前任务：实现购物车总价计算 契约文件：tests/cart-total.test.ts 请先运行测试确认失败，然后只编写让失败测试通过的最小实现。 不要重构，不要修改无关文件，不要新增额外功能。

这段提示词信息密度很高。“先运行测试确认失败”锁定了 TDD 的顺序，“最小实现”锁定了改动范围，“不要重构”锁定了本轮边界。把这三个约束写清楚，AI 的失控概率会大幅下降。

4.3 闭环里的“人工守门员”

工程纪律闭环离不开自动化，但也不能完全交给自动化和 AI。我在实践中保留了三个人工守门员。

第一个守门员是测试评审。AI 生成的测试未必是好的契约，它可能只是照着实现代码反推出来的“镜像式测试”。这种测试测不出回归，因为实现变了它也会跟着变。所以我会先审测试用例，确保每条用例描述的是业务行为，而不是内部实现细节。

第二个守门员是 diff 边界控制。AI 最让我头疼的习惯是“顺手优化”。一次只让它加一个优惠券字段，它可能会顺手把订单状态枚举重构一遍。这种顺手优化在氛围编程里是雪崩的重要来源。我的策略很简单：只要 diff 里出现与当前任务无关的文件改动，直接回滚。

第三个守门员是回归测试的沉淀。每次出现线上 bug，都必须补一条回归测试再修复。没有回归测试的修复等于没修。这条规则写进团队约定后，同类 bug 的重复率显著下降。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

在使用 Superpowers + TDD + 契约驱动的过程中，我遇到过不少问题，也帮别人排查过不少问题，整理成一张高频问题速查表。

5.2 我踩过的三个坑

第一个坑是“让 AI 同时写测试和实现”。一开始我觉得这样效率高，结果它生成的测试总是恰好匹配它的实现，犯了错误也发现不了。后来我改成“人写契约测试、AI 写实现”，或者至少分两轮进行，效率反而更高，因为返工少了。

第二个坑是“一次任务塞太多行为”。我曾经把折扣、运费、积分抵扣三件事放进一个任务里，结果测试失败之后完全分不清是哪段逻辑出了错。正确做法是一次只让一条契约生效，其他行为留在下一轮。

第三个坑是“对 Vibe Coding 一刀切”。经历雪崩之后，有一段时间我对氛围编程非常抗拒，后来才想明白：Vibe Coding 适合用来做原型探索和一次性脚本，只要不进入主分支，它对效率提升的帮助很大。真正危险的，是把它当成唯一开发方式。

6. 最小落地配置与团队约定

6.1 一套可运行的 Agent 工作区配置

如果你现在就想把这套闭环用起来，不需要导入什么复杂平台，只需要把项目目录结构整理清楚。一个最小可运行的 Agent 工作区大概长这样：

project/ contracts/ cart-total.test.ts src/ cart-total.ts skills/ superpowers/ tdd.md todo-break.md AGENTS.md

contracts目录专门放契约测试，src目录放实现代码，skills/superpowers保存技能文件，AGENTS.md写项目级约定。这里的目录名可以按团队习惯调整，核心是“契约和实现分开”“技能和项目约定集中管理”。Agent 在开始任务前会读取AGENTS.md，相当于一进项目就先被提示了规则。

AGENTS.md里不用写太多，三到五条就够。我常用的是这几条：所有新增功能必须由契约测试驱动；任何测试失败时优先修复失败，而不是在失败基础上新增功能；改动不允许超出任务描述的范围；提交前必须跑全量测试。

6.2 适合团队的纪律约定

个人能约束自己，团队必须靠约定。我建议团队落地这样几条纪律。

新增功能必须有对应的测试契约，否则 PR 不通过。不要求 100% 覆盖率，但核心业务路径必须有行为测试。任何一次分支合并前，全量测试必须绿色，类型检查必须通过。出现线上 bug 时，先补回归测试，再修复代码。让 AI 工作前，明确告诉它本轮边界，越界改动一律回滚。

这几条约定看起来很基础，但恰恰是氛围编程环境里最容易被放弃的部分。先把基础约定立住，再考虑更复杂的架构设计或更高级的自动化。

6.3 我自己实际落地的体会

系统用上 Superpowers 技能框架和 TDD 契约驱动之后，我最大的改变不是“测试变多了”，而是“猜测变少了”。以前看 AI 生成的代码，我会盯着屏幕想“它这里为什么这么写”；现在我会先跑测试，用结果说话。测试绿了，代码即使写得不够优雅，也是安全范围内的技术债；测试红了，再让 AI 继续修，直到修绿为止。

我也慢慢意识到，Vibe Coding 的“氛围”和工程纪律的“枯燥”并不是对立关系。氛围适合开场，纪律负责收尾。先让 AI 在宽松的环境里发散思路，再用契约和测试把思路钉在一个稳定的轨道上。这套组合留存了创作效率，也堵住了失控的缺口。

如果要给刚开始尝试这套方法的人一句话建议，我会说：先别急着让 AI 写功能，先让它跑一遍你亲手写下的失败测试。那一抹红色，才是整个工程纪律闭环真正的起点。