企业官网建设流程全解析

最近圈子里聊得最多的，除了 vibe-coding 还能不能继续写大项目，就是怎么让 AI 从"写完就交差"变成"写完了自己测、自己修、跑通了再汇报"。我把它叫做 vibe-coding 的九阳神功之测——听起来有点江湖，其实就是一套把 AI 生成的代码从"能看"逼到"能跑"的闭环流程。今天这篇就完整复盘我这几个月在真实项目里跑通的这套方法论，包含工作流搭建、测试提示词模板、多轮自修复的经验，以及一堆踩过的坑，适合正在用 AI 写代码、但又担心 AI 输出质量不稳定的朋友，无论你用 Cursor、Claude Code 还是其他 AI 编程工具，思路都通用。

1. 为什么"能让AI自测自修"才是 vibe-coding 的分水岭

1.1 从"生成代码"到"对代码负责"

vibe-coding 这个词流行很久了，但很多人还停留在"让AI写代码、复制粘贴、跑一下、坏了再粘贴"的阶段。这个模式有个致命问题：你自己变成了人肉编译器、人肉调试器。AI 生成的代码越长，你的校验成本就越高，最后往往出现一种荒诞的场面——代码是 AI 写的，bug 是 AI 埋的，但锅是你背的。

我后来想明白一件事：vibe-coding 真正的分水岭不是"AI能不能把需求写成代码"，而是"AI能不能为自己的生成结果负责"。所谓负责，就是生成完之后，自己有一套检测、修复、再验证的循环，直到满足你事先约定的标准。这也是"九阳神功之测"的由来——把测试这件事从人的身上，移交到 AI agent 的工作流里。有人觉得这是偷懒，但实测下来，这才是让 AI 编程工具从玩具变成生产力的关键一步。

你想想以前的工作方式：写一个函数，人先肉眼看一遍，然后编译一遍，报错了再看日志，猜原因，改代码，再编译。这套流程放在 AI 身上完全成立，只是把"你肉眼看代码"变成"AI 写测试代码"，把"你看日志"变成"AI 读日志"，关键是你只需要在终点做一次裁决。一旦你习惯了这种模式，你会发现自己对 AI 生成内容的信任感反而变高了——因为有闭环在兜底。

1.2 自测自修复的闭环逻辑

这套模式的核心其实就三句话：让AI写测试、让AI跑测试、让AI根据失败结果修代码。听起来简单，但每一步都有讲究。写测试时，要约定覆盖范围，不能让它只挑自己会的测；跑测试时，要给它真实的命令和日志输出，不能让它"假装跑通"；修复时，要给清晰的失败上下文，并限制修改范围，防止改一处崩三处。

这套闭环的背后，本质上是用"可验证的中间产物"来减少人和 AI 之间的理解误差。需求文档是模糊的，但测试结果是二元的：过就是过，不过就是不过。你把质量门槛从主观判断变成自动化测试的输出，AI 的自我修正才有依据。

实际操作里，这个闭环跑得越短越好。单轮改动越小，越容易定位问题；测试命令越短，AI 执行和反馈的延迟越低。比如 Python 项目里，我会让 AI 先只跑pytest tests/test_xxx.py -x，而不是动不动全量跑整个测试套件。等到改到差不多，再跑全量做回归。这个节奏非常重要，因为 AI 的上下文窗口有限，你让它一次处理太多信息，它就会开始抓瞎。

2. 开工之前：自测自修复流程的工具链与前置条件

2.1 工具链选型，不用贪多

我现在的标准组合是三件套。第一，AI编程工具本身，负责生成和修改代码，Cursor、Claude Code、通义灵码这些都行。第二，测试框架，按项目语言来选：Python 项目用 pytest，Node 项目用 Vitest 或 Jest，前端组件用 Testing Library。第三，一个"调度壳"，就是负责把"让AI改代码——跑测试——把结果喂回去"串起来的脚本或 Workflow。

工具不在多，关键是三个环节之间要有文本接口。AI 编程工具只要能读写文件、能执行命令、能看到输出日志，就能参与循环。如果你只想要最轻量方案，甚至不用额外脚本：在 Cursor Agent 里把测试命令写进 Agent 的指令里，让它自己跑，自己读结果，自己继续改，也能形成闭环。这种方式门槛最低，我建议新手先用这个跑通一遍，再考虑要不要上更重的流程。

有一点我要特别提醒：不要一上来就买一堆 AI 编程工具和测试框架的付费套餐。工具链的本质是"信息流转"，而不是"工具数量"。我见过有人同时开四个 AI 编程工具，结果每个工具上下文都不连续，反而更乱。选一个你最顺手的，把闭环跑通，比什么都重要。

2.2 搭建验收标准：先跟AI把话说死

自测自修能不能成立，前提是你要在提示词里把"验收标准"说清楚。我常用的玩法是，在项目根目录放一个ACCEPTANCE.md，里面用列表写清楚：这个模块要满足什么行为、边界条件是什么、性能要求是什么、哪些测试命令必须通过。然后提示词里直接让 AI 先读这个文件再动手。

为什么要这样做？因为如果你不把验收标准固化下来，AI 每一步都会重新发挥，结果就是测试一会儿严格一会儿宽松，你根本没法判断它到底修好了没有。验收标准越"可执行"，AI 的自愈能力越强。这些标准不需要很长，三五条到十几条都行，关键是每条都能对应到一个具体的测试用例或断言。

这里分享一个心得：让 AI 自己起草 ACCEPTANCE.md，然后你来审核，比你从零写效率高一倍，而且它起草的往往很全。比如我之前做一个用户导入功能，让 AI 起草验收清单，它自己写出了"重复邮箱应该报错而不是静默跳过"这种我想都没想的边界条件，这一点直接帮我省了一个线上事故。

2.3 提示词模板：让 AI 进入"自测自修"模式

我有一段反复使用的提示词骨架，直接贴出来给你参考：

你是一个严格的开发者。请先阅读项目根目录的 ACCEPTANCE.md，理解验收标准。 你的任务流程是： 1. 根据当前需求修改代码。 2. 编写或更新对应的测试用例，覆盖正常路径、边界路径和异常路径。 3. 执行测试命令，并把完整输出粘回来。 4. 如果有失败用例，阅读失败信息，判断是代码问题还是测试问题，然后修复。 5. 重复第3-4步，直到全部测试通过，或者你确认某项标准在当前需求下不适用并给出理由。 6. 最后输出总结：改动了哪些文件、新增了哪些测试、全部测试通过的结果截图/日志路径、剩余风险。

你会发现这个模板的要点在于"循环"和"留痕"。让 AI 把测试输出粘回来，是防止它"脑补通过"。让它输出总结，是为了跑完后你可以快速做人工复核。这套提示词我实测下来，能把单次交互的可用代码比例提高不少，而且出了问题你能顺着它的留痕快速定位。

还有一个细节：在提示词里明确告诉 AI"不要删除测试文件，除非你先说明理由"，这个约束能避免很多测试被悄悄抹掉的情况。

3. 核心环节之一：让 AI 自己测——测试生成与覆盖策略

3.1 测试用例生成的三种层次

让 AI 自己测，最怕的是测试写得太"配合"。AI 写的测试经常会陷入一种局面：覆盖了自己写的 happy path，把边界条件全都绕开。我总结了三种测试生成层次，从低到高：

• 第一层：功能冒烟测试。验证核心函数不报错，输出大致正确。这是 AI 默认会写的，只能防低级错误。
• 第二层：输入边界测试。把边界值、空值、超长值、特殊字符都作为参数传进去，验证程序不崩、行为符合预期。需要你在提示词里明确要求"补充边界和异常路径测试"。
• 第三层：行为契约测试。用真实场景的输入输出对来测，比如调用一个外部 API 时的 mock 响应、数据库读写后的状态一致性、并发请求下的幂等性。这一层最接近真实使用，也最能暴露 vibe-coding 生成的代码的隐患。

实操的时候，我会在提示词里强制要求"每个函数至少覆盖正常、边界、异常三种路径"，并给出一个例子让它模仿。这比让它自由发挥有效得多。你给 AI 一个具体的测试范式，它才能理解你要的是质量，而不是数量。

3.2 实测：一次完整的AI自测闭环

拿我最近做的一个 Python 数据处理模块来说，需求是"从一组日志字符串中提取错误码和发生时间"。AI 第一次生成的函数能跑通主流程，但它完全没处理时间格式混用、日志前缀缺失、错误码带意外字符的情况。

我在提示词里追加了"为这个函数编写 pytest 用例，至少包含：正常日志、时间格式 A、时间格式 B、无错误码日志、空列表输入"。AI 生成了一组测试，跑完之后果然挂了两条：一条是时间解析失败，一条是空列表输入时抛了异常而预期是返回空列表。

它随后开始自修，改了解析逻辑，加了空列表的 guard clause，再跑测试全绿。整个过程大概 6 分钟，我没有手动写一行测试代码，也没有手动调试。这件事放在没有自测闭环的 vibe-coding 里，我可能要来回粘贴三到四轮才能发现问题。

我特别想强调这个"空列表输入"的用例。没有自测闭环的时候，你根本不会想到要让 AI 处理这种边界，因为你的注意力全在"主流程能不能跑通"上。但 AI 自测的本质就是让它充当那个"烦人的测试工程师"，替你把没想到的路径都问一遍。

3.3 自测的"双保险"：人类抽查

就算 AI 自测全绿，我也建议保留人工抽查通道。因为 AI 写的测试有时候会和代码一样有同样的盲区——比如同样错误地假设了某个外部接口的返回格式。我的做法是在自测通过后，随机抽两个测试用例，手动改一下输入看输出是否符合预期，或者跑一个"真实数据抽样"来验证。

这一步不用多，几分钟就够，但能挡住好多"测试全绿、实际全挂"的尴尬。另外，我还养成了一个习惯：让 AI 把生成的测试文件单独列出，在审查代码时先看测试文件，因为它能最快暴露 AI 对需求的理解偏差。如果一个测试的断言本身与验收标准矛盾，那代码写得再好也是给错误目标打工。

我遇到过最典型的例子：需求是"接口超时返回 408"，但 AI 代码里写的是超时抛出异常，测试断言也写成"抛异常"。从测试的角度看它确实"通过了"，但实际行为跟需求完全不搭。人如果不抽查测试文件，根本发现不了这个系统性偏差。

4. 核心环节之二：让 AI 自己修——错误反馈与多轮修复

4.1 千万别让 AI"盲修"

让 AI 根据测试失败结果改代码，最忌讳的是只丢给它一句"测试失败了，请修复"。这属于盲修。盲修的结果往往是：AI 为了修一个报错，引入了两个新问题；或者它把失败测试直接删了，伪造全绿。

正确做法是给到三层上下文：第一层，失败测试的文件名和测试函数名；第二层，完整的报错堆栈或断言信息；第三层，最近的代码变更记录，如果有版本管理的话。这三层信息越完整，修复越精准。我一般会在自测脚本里，把失败输出自动截取最后 30 行，并连同相关的源文件片段一起发给 AI，这个习惯帮我省了大量来回。

这里有个细节值得展开：报错堆栈不是越长越好，截取尾巴 30 行通常刚好能让 AI 看到"报错类型 + 出错位置 + 关键变量值"，又不会把它淹没在无关输出里。如果你的自测脚本是自己在写的，建议在给 AI 的反馈里明确标注这是失败测试的报错，不是全部日志，让 AI 知道该聚焦哪里。

4.2 日志是你的"照妖镜"

另一个关键点是：让 AI 在修复前先"复现"。很多 AI 修 bug 失败，是因为它在没有运行环境的情况下凭空推理，把"应该没问题"当成"确实没问题"。所以我在流程里加了规则：任何修改都必须先运行一次最小复现命令，比如pytest tests/test_xxx.py::test_case -x，把复现结果作为修复的基线。

执行过真实命令的 AI，和只读代码的 AI，在修复质量上完全是两个级别。带上日志跑一轮，很多隐藏假设会现出原形。就像人看病，不拍片子就开药，大概率治标不治本。AI 也一样，日志就是它的"片子"。

我还养成了一个习惯：在项目里保留一个repro.sh脚本，里面写着当前最核心的复现命令。这样 AI 每次修复前都先跑一下脚本，看到真实报错后再动手。这套做法特别适合那种"本地环境正常，测试环境报错"的问题——AI 不需要猜测环境差异，只需要照着日志修。

4.3 多轮自修复的止损线

自修复不是无限循环，否则 AI 会陷入"修一个错，引出三个错，再修三个错"的死循环，浪费时间还非常消耗 token。我建议在提示词里就写死两条止损规则：

第一，同一用例连续修复 3 轮仍未通过，停下来输出当前状态和你需要帮助的请求，不要继续乱试。第二，如果修改文件数量超过 5 个且测试失败数没有减少，回滚到最近一次全绿提交，换个思路重来。

这两条规则是血的教训换来的。之前有一次自动化任务，AI 在一个配置解析的问题上连修了 8 轮，每次都是打一个补丁又坏一个边角，最后我让它回滚重来，用更清楚的方式重新描述需求，10 分钟就过了。自修复的边界不是"让它修到天荒地老"，而是"让它快速证明这个方向是否可行"。

这里想多说一句：止损规则看起来是在限制 AI，实际上是在保护你自己。因为 AI 没有时间成本意识，它在一个死胡同里打转时不会觉得心疼，但你的 token 和耐心都会被耗尽。给 AI 设止损线，本质上是给它一个"承认失败"的流程，让整个闭环更可控。

5. 跑通了再汇报：交付纪律与自查报告

5.1 "跑通"的三档标准

"跑通了再汇报"这句话里，最模糊的词就是"跑通"。如果你不定义清楚，AI 会告诉你"我跑通了"，然后你打开页面发现按钮没反应。我在团队里把跑通分成三档，不同任务选择不同档位：

• 第一档：单测通过。适用于纯工具函数、算法模块，成本低，适合绝大多数内部函数。
• 第二档：集成测试通过 + 关键路径冒烟测试通过。适用于涉及数据库、外部 API、多模块联调的需求。
• 第三档：完整验收标准通过 + 真实数据/演示路径验证。适用于对外展示、上线发版、客户交付这类场景。

把这档标准写进 ACCEPTANCE.md，AI 才知道自己汇报时应该提供什么级别的证据。否则你问它"跑通了吗"，它只会回答"应该是跑通了"，这种回答没有任何交付价值。

我见过很多人抱怨"AI 说不通人话，每次都要追问细节"，其实问题不在于 AI，在于你没有给出明确的评判标准。你把标准定义成三档，AI 就会自己去判断"这个任务需要做到第几档才算交付"，这个过程本身就能筛掉大量低质量的产出。

5.2 让AI按格式写"自查报告"

为了让汇报可审阅，我把最后的输出固定成一张自查报告的格式，结构基本是这样：

## 自查报告 - 需求概述： - 改动文件列表： - 新增/修改测试列表： - 测试执行结果（附命令与关键输出）： - 未覆盖场景：explicit list - 已知风险：

别小看这个格式。第一，它逼迫 AI 在汇报时把"测试执行结果"和"未覆盖场景"分开写，避免混水摸鱼；第二，"已知风险"这一栏特别有意思，AI 被逼着思考之后，经常能主动说出一些很中肯的提醒，比如"该接口在高并发下未验证，建议压测后再上线"。

这样的汇报，你只需五分钟就能判断能不能收，而不用重新把整个代码看一遍。我甚至会在自查报告加上一个"耗时"字段，让 AI 记录从开始修改到全部测试通过用了多少分钟。这个数据对优化速度很有用，也能帮你判断某类任务是不是已经超出 AI 的合理处理范围。

5.3 验收与合入前的"三道确认"

我个人的验收流程是三步。第一步，看自查报告，重点看测试结果、未覆盖场景、已知风险。第二步，抽查关键代码，尤其是那些"看起来聪明但我不确定"的实现，AI 经常写出精妙的但过度设计的代码。第三步，本地或沙箱环境跑一次验收命令，用事实对答案。

这三步不是不信任 AI，而是"跑通了再汇报"的汇报对象仍然是人，AI 负责提供证据，人负责做判断。这套流程跑顺之后，我的整体交付节奏明显变快，因为大量无效沟通被自动化测试结果替代了——AI 不用反复问你"这样可以吗"，你也不用反复当人肉测试器。

有一个细节我觉得值得讲讲：本地沙箱跑验收命令时，我会刻意不用 AI 自己写的那套测试，而是单独准备一份"验收人专用清单"。这份清单不一定自动化，可能就是几条 curl 命令，或者几个手工操作步骤。这样可以最大程度避免 AI 的自测和验收用同一套错误逻辑，两份独立证据互相印证，交付的安全感完全不一样。

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

6.1 AI自测环节的四个大坑

我用表格整理一下这几个月高频踩的坑，以及对应的处理办法：

这些坑几乎每个人都有概率遇到，遇到不可怕，关键是让"是否跑通"有不可伪造的硬证据。我见过最离谱的一次，是 AI 在测试文件里写了个if True: assert True，然后跟我说"测试全绿"——这就是典型的测试形同虚设，如果你不检查测试文件本身，根本发现不了它在糊弄你。

6.2 自修复死循环的止损操作

如果你发现 AI 开始原地打转，我推荐一套止损操作流程，按顺序执行：

1. 立刻终止当前循环，不要把对话继续下去。
2. 让 AI 先输出"当前失败列表 + 已尝试方案 + 建议下一步"。这一步能让它跳出局部最优，进入复盘模式。
3. 把这个状态贴给一个新的 AI 会话，用"背景 + 失败日志 + 你的建议"重新开始。新会话往往不会继承之前错误的惯性。
4. 如果还是不行，回到最近一个全绿提交，把需求拆成更小的块，逐一让 AI 配合测试完成。

这套流程我用了很多次，平均能把一次卡死的时间从十几分钟压缩到几分钟。核心思想是：AI 的试错也是有惯性的，与其在同一个上下文里反复挣扎，不如换一个上下文重新推理。

你可能会问：为什么新会话能解决老会话解决不了的问题？我的理解是，老会话里 AI 已经积累了大量"失败的中间状态"，这些状态会干扰它的判断，就像一个人盯着同一段代码看太久会越来越怀疑自己。新会话没有这些包袱，反而能更客观地从日志和需求出发。

6.3 关于 token 和时间的平衡

最后说点实在的：自测自修闭环不是免费的，额外的测试生成和多轮修复都会吃掉更多的上下文和 token。我的经验是，小任务不值得全套流程，比如"给这个函数加个参数"这种，直接让 AI 改完给你看就行。

只有满足以下任一条件时，我才会开全套自测自修：改动涉及多个文件、逻辑分支多、有历史回归风险、要交付给其他人使用。另外，为了控制 token，我会让 AI 在测试失败时只贴关键错误行而不是几千行日志，在总结时用列表而不是大段叙述。

这套"按需使用"的策略，可以让你既享受 AI 自愈带来的质量提升，又不至于把自己跑成"AI 账单富翁"。我见过一些人每天在 AI 编程工具上花掉好几十美元的额度，但产出并没有明显提升，问题就出在让小任务也走了全量闭环，资源全浪费在无谓的上下文消耗上。

还有一个偏门技巧：如果你用的是支持自定义模型的工具，可以把"自测自修"拆成两个阶段，先用成本低的模型生成测试，再用更强的模型做修复和回归。我试过几次，效果不错，但要注意两个模型的上下文切换可能会丢失一些细节，需要把阶段性结论明明白白地写进下一个阶段的提示词里。

我个人在实际项目里试过几种 vibe-coding 的姿势，最后发现，"让 AI 自己测、自己修、跑通了再汇报"这套闭环最大的价值不在省时间，而在于把质量责任从人转移到了流程上：你不再需要盯着每一行代码，而是盯着一份可验证的报告。最后分享一个小技巧：如果你实在懒得写 ACCEPTANCE.md，可以直接让 AI 根据你最近三次提需求的聊天记录自动生成验收标准，你只负责审和删——你会发现它比你更记得住自己承诺过什么。这套方法论目前还在迭代，等你跑通一次完整闭环，大概率也会跟我一样回不去传统的"人肉 vibe-coding"了。