AI写代码与vibe coding实战指南

写在前面

“vibe coding”这个概念，如果仅仅被理解为“让AI代替我编写代码”，那真是大大低估了它的潜力与意义。

其真正的核心，在于一种完全崭新的人机协作软件开发模式：人类负责提供清晰的意图、明确的约束、相关的上下文和关键的工程决策，而AI则负责将这些抽象的想法，高效转化为具体的原型、可读的代码、完善的文档、全面的测试，甚至是一个能够稳定运行的系统。它极大地降低了从“我有一个想法”到“让代码跑起来”的门槛，但与此同时，它也毫不留情地将需求中的每一个模糊地带、每一个错误假设以及缺失的测试环节暴露无遗。

因此，一种更务实、更准确的理解是：vibe coding 并非让我们“更随意、更草率地写代码”，而是要求我们“更严谨、更专业地表达需求”。过去，工程师的主要精力被消耗在编写代码上；而现在，这部分成本正大规模地向需求前端转移——你需要花费更多时间用于定义问题、拆解模块、阐明约束、审查结果、建立测试、处理联调、沉淀规则，并推动持续的迭代优化。AI可以承担大量的执行工作，唯独不能承担最终的工程责任。这份责任，始终且必须落在使用AI进行开发的人肩上。

1. vibe coding 到底是什么

Collins Dictionary 将“vibe coding”评选为 2025 年的年度词汇，并将其定义为一种通过AI将自然语言转化为计算机代码的软件开发方式。这个术语由 Andrej Karpathy 在 2025 年初带火，它描述的是一种“口头阐述需求，让大模型生成代码，并通过持续对话进行迭代”的开发状态。

然而，具体到实际的工程项目中，我们不能仅仅被其看似轻松的“vibe”所迷惑。如果纯粹凭感觉让AI随意生成，最终得到的很可能是一个“看起来能运行，但实际上没人理解其逻辑、没人敢修改、更没人敢部署上线”的系统。

一个更精确的分类方法，是将vibe coding拆解为两个层次来理解：

第一层是原型阶段的“vibe”。在这个阶段，可以放宽限制，允许方向有所发散，重点在于快速探索各种可能性。例如，UI原型、交互方式、页面布局、产品概念或是信息架构，这些方面都可以让AI生成多个方案，尝试不同的风格。

第二层是工程阶段的“coding”。这时，范围必须明确收窄，约束必须清晰定义，结果也必须可验证。像登录、支付、权限管理、数据库操作、AI agent的状态流转、任务队列、文件上传以及安全策略这些核心功能，绝不能依赖感觉，必须依赖于严格的规格说明、详尽的测试用例和人工审查。

一句话总结：vibe coding 的前半段，可以尽情发散思维、探索可能；但后半段，必须坚决收敛思路、严格把关。

2. 从原型到系统的开发过程

一个实际项目若使用AI进行开发，通常会沿着两条主线并行推进。

第一条是产品与UI设计线。这条线通常不是一步到位的，而是从一张简单的草图开始：首先构建一个能够表达核心流程的粗糙原型，然后逐步补充各种状态、页面和交互细节；在需求发生变化时进行相应调整，直到整个团队能够围绕一个看得见、摸得着的共同版本进行讨论。

这个阶段的重点根本不在于代码质量，而是要将脑海中的想法转变成一个可以实际讨论和评估的对象。许多光靠文字描述难以说清楚的需求，必须通过具体的页面、流程、状态和边界情况呈现出来，团队才能真正明确自己究竟要开发什么。

第二条是工程实现线。这条线不能直接从原型跳到代码实现。一个更稳妥的顺序是：首先将原型翻译成一个可执行的技术方案，然后将其拆解为模块、接口、数据、权限和状态；接着从最小的功能闭环开始实现，逐步补齐后端、前端、联调、AI能力、测试、上线部署和反馈机制。

其中最关键的概念就是“可实现”。原型只是一个想法或蓝图，技术方案是连接想法与现实的桥梁，而代码则是最终的落地成果。没有清晰的技术方案就直接让AI去写代码，很容易产生一个“局部看起来很漂亮，但整体逻辑混乱、难以维护”的项目。

如果这个项目中包含了真正的AI能力，根据目前的经验，投入成本的排序大致如下：

AI系统搭建 > 文档编写 > 测试工作 > 前后端联调 > 后端非AI部分 > 前端页面。

这当然不是绝对的铁律，但它揭示了一个非常重要的点：在AI辅助开发中，最昂贵的通常不是“将代码从无到有写出来”，而是“将一个能演示的系统，变成一个值得信赖、稳定可靠的生产系统”。页面和接口可以快速生成，真正消耗时间的是让输出变得可控、状态可以追踪、失败能够恢复、测试能够覆盖到、协议能够联调通畅，以及文档能够支撑后续的迭代维护。

因此，AI开发项目应该从小闭环起步。不要一开始就让AI去实现一个完整的SaaS系统、一个完美的AI agent、一个全面的后台管理、一套完整的权限体系和全部的支付流程。首先要实现一个最小的功能闭环：一个用户、一个核心流程、一个可验证的结果、一个失败处理逻辑、一个测试入口。小闭环成功跑通之后，再去考虑扩展和集成其他模块。

3. 倒金字塔：越往后越窄

你可以把vibe coding的过程想象成一个倒金字塔的形状。

最顶层非常宽阔：想法、风格、交互方式、模块边界、技术选型，这些都可以是开放的，让AI帮你进行头脑风暴，探索更多可能性。

中间层开始逐渐收窄：确定页面结构、数据结构、接口协议、权限模型、状态机和任务拆分的具体方案。

最底层必须非常狭窄：具体到一个bug的修复、一个接口的定义、一个组件的开发、一个测试用例的编写、一个边界条件的处理、一个PR的提交审查。

许多AI开发项目之所以失败，就是因为团队始终停留在倒金字塔的上半部分。需求一直宽泛且模糊，提示词一直含糊不清，验收标准一直不明确，却期望AI能够交付一个稳定可用的系统。AI拥有的选择空间越大，它就越容易走向你未曾预料的方向。在做原型时，这是优点；而到了做工程时，这就会变成巨大的风险。约束并非限制创造力，而是将AI的强大能力引导至产生正确结果的轨道上。

4. AI写代码的核心材料

用AI写代码，远不止写一句简单的Prompt那么简单。一个比较稳定高效的协同工作组合应该是：可实现文档 + 任务提示词 + 项目公共规则 + 可复用Skill + 插件和工具 + 人工代码审查 (review)。

其中，最核心的就是“可实现文档”。一份优秀的可实现文档至少需要清晰地回答以下问题：

• 这个功能要解决什么问题？
• 用户的完整操作路径是什么？
• 哪些状态是必须出现的？
• 哪些边界条件必须被妥善处理？
• 它涉及哪些页面、接口、数据表、任务和权限？
• 明确的输入和输出是什么？
• 哪些事情是明确不在本次开发范围内的？
• 如何进行结果验收？
• 如何进行有效测试？

AI不是读心术工具。如果你只给它一个“做一个导入功能”的需求，它会自行决定文件格式、校验方式、失败策略和页面交互；但如果你给它的是“在运营后台增加客户线索CSV导入功能，先预览前20行，不预览不落库，确认后创建import job，重复邮箱跳过并返回失败清单，复用现有批处理队列，测试需覆盖空文件、字段缺失、部分成功和重复提交等情况”，它才有可能做出真正符合工程要求的结果。

5. 一个好提示词的结构

我不太建议将提示词理解为一套固定不变的八股文。更好的方式是根据具体问题来裁剪其结构，但大部分工程任务都离不开五类核心信息：

• 目标：明确这次任务具体要交付什么成果。
• 上下文：说明现有系统中已经存在什么，避免AI从零开始重新发明轮子。
• 边界：划定哪些内容可以修改，哪些绝对不能动，哪些场景暂时不做。
• 验收：明确怎样证明任务完成了？最好能具体到一条命令、一个页面路径或一个测试用例。
• 输出：要求AI最后汇报什么，避免它只扔下一句“完成了”就结束。

举个实际的例子：

你接手的是一个B2B CRM的运营后台。
目标：新增“客户线索CSV导入”的最小闭环：上传文件 -> 后端解析 -> 页面预览 -> 用户确认 -> 批量写入 -> 返回导入结果。
先读代码：
- imports 相关 route
- lead service
- 数据库 schema
- 现有后台表格组件
- 项目里已有的 job / queue 用法

这次只做：
- 支持 UTF-8 CSV。
- 必填字段是 companyName、contactName、email。
- 预览阶段只校验字段和格式，不写数据库。
- 确认导入后创建 import job。
- 重复 email 跳过，并在结果里返回行号和原因。

这次不做：
- Excel 导入。
- 字段自由映射。
- 超大文件分片上传。
- 导入历史详情页。

实现约束：
- 复用现有后台上传组件和错误提示样式。
- 不引入新的 CSV 解析库，除非项目没有可用方案，并说明原因。
- 不改 lead 表的无关字段。
- 后端错误格式必须和现有 API 保持一致。

验收：
- 一个正常 CSV 可以预览并导入。
- 缺少 email 的行不能导入，并在预览里标出原因。
- 重复提交不会创建重复线索。
- 至少运行导入相关的单元测试或接口测试。

最后输出：
- 修改了哪些文件。
- 新增或调整了哪些接口。
- 运行了什么验证。
- 哪些能力仍然没做。

这类提示词看起来可能比较长，但它真正减少的是AI自由发挥、做出错误假设的空间。当然，并非每个任务都需要写得如此详细；修复小bug可以很简短，但实现大模块时务必足够清晰。提示词不是魔法，它更像一份压缩版的任务清单。清单越清晰，AI就越少替你做出危险的业务假设。

6. 复杂模块不要一次追求完美

对于复杂的模块，适合采用循序渐进、逐步迭代的方式，不适合妄想一口吃成胖子。

以“AI工单摘要”功能为例：

第一步，能用：客服在工单详情页点击“生成摘要”，系统将对话内容发送给模型，并返回一段可以编辑的摘要文本。

第二步，好用：增加生成中的状态提示（如加载中）、失败重试机制、空对话提示、摘要字数限制，以及人工编辑后的保存入口。

第三步，快用：对同一工单在短时间内的重复生成请求进行缓存；针对长对话先做截断或分段摘要处理，以避免接口超时和成本失控。

第四步，爱用：支持按“客户情绪、待办事项、风险等级”等维度来拆分摘要内容，并将高风险工单自动推送到主管的审核队列。

这个顺序的关键在于：先完成功能和闭环，再优化用户体验；先确保结果正确，再追求代码优雅；先实现可验证的目标，再进行功能扩展。很多人用AI写代码时容易犯相反的错误，一开始就让AI生成“完整、优雅、可扩展、企业级、支持所有场景”的实现，结果往往导致代码量巨大、过度抽象、bug难以被发现、代码审查非常痛苦。AI会放大你的表达，如果你的目标是“全都要”，它就会真的给你生成一大堆可能你并不需要的东西。

7. SDD：让规格成为源头

在AI辅助开发中，SDD可以理解为 Spec-Driven Development，即规格驱动开发。

在传统开发中，代码往往是最主要的事实来源（single source of truth）；而在AI协作模式下，规格文档应该成为更前置、更权威的事实来源。因为AI生成代码的速度太快了，如果没有规格的约束，代码的增长速度会远远超过人能够理解的速度。

一个实用的SDD文档不一定很冗长，它可以很简洁，但必须能够真正指导代码实现。建议每个模块至少包含一份包含以下内容的规格：

# 模块名称

## 目标
这个模块解决什么问题，最终用户是谁。

## 非目标
明确这次不做什么，避免AI自行扩展功能范围。

## 用户流程
用步骤描述用户从入口到结果的完整操作路径。

## 数据模型
涉及哪些表、字段、状态、枚举值。

## 接口契约
请求格式、响应格式、错误码定义、权限要求。

## 状态流转
列出 pending / running / succeeded / failed / canceled 等状态，以及谁能触发状态变化。

## 边界条件
空数据、重复提交、超时、并发、权限不足、外部服务失败等情况。

## 验收标准
什么情况算完成，什么情况算失败。

## 测试计划
单元测试、集成测试、端到端测试、手工验证路径。

对于AI模块，尤其需要写清楚“状态流转”。例如，一次AI run，至少要明确以下内容：run如何创建？什么时候进入running状态？工具调用能否重试？用户取消时如何处理？模型超时怎么办？部分输出是否保存？失败后用户看到什么？日志和trace记录在哪里？哪些数据不能进入prompt？哪些动作必须经过人工确认？AI模块最怕的就是“看起来能运行”。看起来能运行，并不代表它真的具备可恢复、可追踪、可审计、可扩展的能力。

8. CLAUDE.md：公共规则要写下来

公共提示词应该沉淀到 CLAUDE.md 或类似的项目规则文件中。它不应该写成一篇长篇大论，而应该写成稳定、简洁、可验证的工程规则。例如：

## 四个工作原则

### 1. 编码前思考
不要假设，不要隐藏困惑，必须呈现关键权衡。
- 开始修改前，先用 2-5 句话说明你的理解、假设和可能存在的风险。
- 如果需求存在多种解释，列出各种解释并说明推荐选项；无法合理判断时，先向需求方问清楚。
- 如果用户要求的方案明显复杂、脆弱或与现有架构冲突，先提出异议并给出更简单的替代方案。
- 不确定数据库字段、路由前缀、认证语义、AI run 状态流转时，必须先查阅代码再修改。

### 2. 简洁优先
用最少的代码解决当前问题，不做过度推测。
- 不添加需求之外的功能、配置项、抽象层或通用框架。
- 不为一次性逻辑创建不必要的抽象。
- 不为当前业务不可能发生的场景堆叠错误处理代码。
- 如果实现开始变得臃肿，停下来进行简化重构。
- 优先复用现有的 services、routes、stores、components 和类型定义。

### 3. 精准修改
只修改必须修改的代码，只清理自己本次改动造成的问题。
- 每一行修改都必须能直接追溯到用户请求。
- 不顺手重构无关代码、不顺手格式化、不改相邻的无关代码。
- 让修改匹配所在文件现有的代码风格。
- 发现无关的死代码或坏味道时，在回复中指出即可，不主动删除。
- 如果你的改动导致某些导入、变量、函数变成孤儿代码，要同步删除这些由本次改动造成的无用代码。

### 4. 目标驱动执行
把任务转化为可验证的目标，并循环验证直到达成。
- 修 bug: 先明确复现条件，再修复，再验证复现条件消失。
- 加校验: 优先补充或运行覆盖无效输入的检查。
- 重构: 保证重构前后的行为和测试结果一致。
- 多步骤任务要写一个简短计划，每一步都包含验证方式。
- 完成前至少运行与改动相关的最小验证；如果不能运行，说明原因和剩余风险。

9. Skill：把经验变成可复用能力

Skill的价值在于能够跨会话、跨项目地复用个人经验和工程习惯。如果你发现自己经常复制粘贴同一段提示词，就应该考虑把它变成一个Skill。

例如：code-review skill（检查bug、边界条件和测试缺口）、api-design skill（根据项目规范设计接口）、db-migration skill（检查迁移脚本、索引和回滚）、ai-run-debug skill（排查agent状态和prompt问题）、frontend-polish skill（检查移动端适配和状态展示）、release-check skill（上线前检查环境变量和监控配置）。

一个Skill可以很简单：

---
name: code-quality-review
description: 通用代码质量审查 skill。
---

# Code Quality Review

## 工作方式
1. 先确认审查范围：整个改动差异（diff）、某个文件或某个模块。
2. 先阅读项目约定：CLAUDE.md、README、测试配置。
3. 再阅读代码入口和调用链，重点关注数据流和副作用。
4. 输出时按严重程度排序：正确性/安全性 > 可维护性 > 可读性 > 风格。

## 审查维度
- 职责是否单一。
- 边界是否清晰。
- 抽象是否必要。
- 错误处理是否完整。
- 状态是否存在竞态条件。
- 数据是否存在泄漏风险。

## 输出格式
如果是 review，使用：
发现：
- [P1] 问题标题：文件:行。
开放问题：
- ...
总体判断：
...

Skill的本质，就是将个人经验产品化，让AI不仅仅是“会写代码”，而是逐渐学会“按照你的工程习惯和标准来工作”。

10. 四个工作原则

如果把上面的内容进一步压缩，可以将vibe coding的工程纪律总结成四条。这四条原则不是为了限制AI的能力，而是为了确保AI的高速产出不会冲垮项目的整体质量。

10.1 先把不确定性摊开

AI开发最容易出问题的地方，不是模型不会写代码，而是它会自信地将不确定的事情也写成确定的代码。所以在动手之前，应该先把三件事说清楚：我理解这次要解决什么问题？我基于哪些现有事实做出判断？还有哪些地方存在不确定性，以及我准备如何验证？例如，用户说“给报表加一个导出功能”，这至少存在几种不同的解释：导出当前筛选结果、导出全部数据、通过异步任务导出、导出带权限和脱敏的数据。如果AI直接动手写，很可能选错需求。更好的工作方式是先进行沟通，收窄并确认导出语义。

特别是以下这些内容，绝不能靠猜测：数据库字段、路由前缀、认证语义、权限边界、AI run状态流转、队列重试策略、外部服务回调、支付和订单状态、文件上传和存储路径。AI最危险的能力不是不会做，而是它会在不知道正确答案的时候继续编造。

10.2 先用小解法打通

AI很擅长把小需求写成大系统。它会自然倾向于补充配置、添加抽象层、预留扩展点、增加框架感，但很多扩展点在当前阶段根本用不上，只会增加代码审查和维护成本。因此，默认策略应该是：先实现一条最短的可验证路径。例如，要实现“库存不足提醒”功能，第一个版本不需要先构建一套通用的规则引擎。可以在后台配置一个固定阈值，每次库存变更后检查是否低于该阈值，低于阈值时写入一条提醒记录，前端展示提醒状态，测试覆盖库存从高到低、重复提醒、库存恢复等场景即可。等到确实出现多个仓库、多个品类、多个阈值策略的需求时，再进行抽象。不要为了“未来可能”而牺牲当前的清晰度。

10.3 控制改动半径

AI一次能修改很多文件，这既是能力的体现，也是潜在的风险。工程上需要关心的不只有功能是否实现，还要关心改动差异（diff）是否能够被团队成员轻松理解。可以用“改动半径”来判断一次AI修改是否健康：半径1是只修改当前函数或组件；半径2是修改当前模块的service、route、test；半径3是跨模块修改公共类型、状态、协议；半径4是顺手重构架构、格式化大量文件，这通常应该拆分为独立的任务。发现无关问题可以记录在回复中，或者单独开一个任务，不要把“我顺手看到了”变成“我顺手改了”。

10.4 用验证关门

AI说“完成了”没有意义，只有经过验证的完成才有意义。不同类型的任务应该有不同的关门方式：修复bug要看复现条件是否消失；开发接口要看请求、响应、错误码和权限是否都被验证；开发UI要看加载状态、空状态、错误状态、移动端适配是否都已覆盖；开发AI功能要看正常输出、工具调用失败、模型超时、人工取消等场景是否都能正常处理；重构要看行为是否保持不变，测试结果是否与重构前一致。vibe coding的完成标准不是代码生成完毕，而是相关风险被关闭到当前阶段可以接受的程度。

11. Owner意识：AI不负责，人负责

AI需要人类去规划、决策和审查。即使现在很多人都在使用AI开发代码，团队中也必须有人扮演owner的角色。owner不是一个职位头衔，而是一种工作态度和方式。

一个合格的owner至少要盯住六件事：目标是否真的清晰，而不是听起来合理却经不起推敲；任务是否已经拆分到AI可以稳定执行的粒度；风险是否及时暴露给团队，而不是被埋藏在冗长的聊天记录里；结果是否被严格验收，而不是只看AI的完成声明；经验是否回流到文档、规则或Skill中；从需求、实现、联调、测试、上线到反馈，是否有人持续跟踪整个完整链路。

AI可以帮你写代码、补充文档、查找bug、运行测试、生成方案，但它不会为线上事故负责，也不会为需求误解负责，更不会为团队协作成本负责。因此，越是广泛使用AI，越要有owner意识。AI大大降低了执行成本，但并没有降低任何责任成本。

12. 团队中怎么用AI

个人使用AI做demo或原型，可以相对随意一些；但团队使用AI编写生产环境代码，则必须严谨规范。团队中需要统一以下几件事：

第一，统一公共规则。明确哪些文件可以修改，哪些命令必须运行，哪些安全边界不能触碰，哪些代码风格必须遵守，这些都应该写进项目规则文件中。

第二，统一任务颗粒度。不要将“实现完整订单系统”这样一个大任务直接丢给AI，而应该将其拆解为：订单创建、库存锁定、支付回调、订单取消、超时关闭、退款处理、后台查询、测试覆盖等多个独立的小任务。

第三，统一审查标准。AI生成的代码不能跳过代码审查环节，甚至更需要严格的审查，因为它可能写出“看起来非常合理但刚好错了一点点”的代码。

第四，统一验收方式。每个模块完成时，都应该有可运行的测试、可点击的路径、可复现的验证方式，或者清晰的剩余风险说明。

第五，统一沉淀机制。AI犯过一次错误，不要只在聊天中纠正一次，重复出现的问题应该被沉淀到项目规则、Skill或检查清单中。

团队使用AI的关键不是让每个人都变得更快，而是让团队的整体产出率提高、返工率减少、交付质量不下降。

13. 不同阶段应该给AI不同角色

不要让AI在所有任务中都扮演同一个“全能工程师”的角色。在开发的不同阶段，应该赋予它不同的角色和职责。

• 原型阶段：它是产品设计师和前端原型工程师，目标是快速生成可讨论的UI界面。
• 方案阶段：它是技术负责人，目标是将原型拆解为可实现的模块，并指出潜在风险和依赖关系。
• 后端阶段：它是后端工程师，必须复用现有的service、route、schema和测试工具。
• 前端阶段：它是前端工程师，必须匹配现有组件的风格，并覆盖各种交互状态。
• 联调阶段：它是全栈联调工程师，目标是检查接口契约和状态是否同步。
• AI搭建阶段：它是AI系统工程师，重点关注prompt设计、tool配置、memory管理、state machine搭建和人工确认边界。
• 测试阶段：它是测试工程师，重点是复现用户路径、准备边界输入和编写最小验证命令。
• 审查阶段：它是严格的代码审查者，只关注bug、风险和回归问题。角色越清晰，AI的输出就越稳定可靠。

14. 文档为什么排在高投入

在AI时代，文档已经不再是“写给人看的附属品”，而是“写给人和AI共同使用的控制面”。好的文档可以让AI更快地理解项目上下文，减少错误假设；而不好的文档则会把AI带偏，而且它还会偏得非常自信。

项目中至少应该包含几类核心文档：产品需求文档（说明用户、目标和流程）、技术方案文档（说明模块、接口和依赖）、AI规格文档（说明prompt、tools和状态机）、联调文档（说明接口契约和测试账号）、测试文档（说明测试范围和方法）、运维文档（说明环境变量和部署流程）。文档不需要很长，但必须准确。特别是给AI使用的文档，要力求简短、具体、结构化、可验证。

15. 测试会变得更重要

AI写代码的速度越快，测试工作就越发重要。因为代码的生成速度上来了，但人的理解速度、审查速度、联调速度并没有同比提升。如果没有测试的约束，团队很快就会被大量“差一点点就正确”的代码所淹没。Stack Overflow 2025 Developer Survey的数据也印证了这一点：开发者对AI的主要挫败感之一，就是“AI给出的方案几乎正确但并非完全正确”，另一个高频问题是“调试AI生成的代码比想象中更耗时”。

测试在AI开发中发挥着两个核心作用。第一，它是验收工具，AI说完成了不算数，测试通过了才接近完成。第二，它是约束工具，当你让AI修改代码时，已有的测试会明确告诉它哪些行为是不能被破坏的。没有测试的项目，AI将更容易在无意中改变既有行为。最实用的策略并非一开始就追求100%的测试覆盖率，而是优先覆盖核心用户路径、权限和认证逻辑、资金相关逻辑、AI tool调用和状态流转、数据写入和删除操作、bug修复的复现用例、前后端接口契约以及高风险边界条件。

16. 前后端联调的核心问题

AI可以快速生成前端代码，也可以快速生成后端代码，但它未必能保证前后端真的能够完美对应上。联调阶段最常见的问题包括：字段名不一致、枚举值不一致、错误码不一致、空状态没有处理、分页协议不一致、时间格式不一致、权限验证失败时前端没有相应的处理路径、后端返回nullable而前端按必填字段处理、前端缓存导致状态不同步、AI生成mock数据后忘记替换为真实接口等。因此，联调阶段要重点检查“契约”，而不仅仅是看两端各自的代码。

一个简单有效的联调prompt可以这样设计：

你是一名前后端联调工程师。
请检查当前功能的前端调用和后端接口是否完全一致。
重点检查以下方面：
- URL 和 HTTP method
- request body / query 参数
- response 字段名称和类型
- enum / status 值
- error 格式
- auth / permission 处理
- loading / empty / error 状态
- mock 数据是否已替换为真实接口
输出格式：
- 不一致项
- 影响范围
- 推荐修复位置
- 最小验证方式

联调工作不是等到项目最后才进行的步骤，每个小闭环在完成后都应该尽早进行联调验证。

17. 工程阶段怎么约束AI

在工程阶段，开发模式需要从“让AI发挥创造力”切换为“让AI严格遵守规则”。你应该为它设定明确的边界：不准修改无关的文件；不准引入新的依赖，除非说明合理理由；不准凭空发明数据库字段；不准绕过现有的权限控制；不准跳过测试流程；不准吞掉或忽略错误；不准把mock数据当作真实实现；不准用大范围的重构来掩盖小问题；不准在没有确认的情况下执行具有破坏性的命令；不准将敏感信息放入prompt、日志或前端代码中。AI不怕规则多，就怕规则模糊不清。规则要简短、硬性、并且可以进行检查。

最终结论

vibe coding是一个巨大的机会，同时也带来了一份沉重的压力。它让个人能够更快地构建原型，让小团队能够完成过去需要更多人才能完成的任务，也让非专业开发者有机会将自己的想法变成可运行的软件。但它并不会自动带来高质量的工程成果。AI会放大人的能力，同样也会放大人的模糊、懒惰和侥幸心理。

因此，真正值得追求的目标不是“让AI写出更多的代码”，而是建立一套完善的人机协作工程体系：用原型来发现和澄清需求，用文档来收敛团队共识，用提示词来精确表达任务，用公共规则来固化最佳实践，用Skill来复用个人能力，用SDD来约束复杂模块，用小闭环来降低项目风险，用测试来验证最终结果，用代码审查来保持质量水准，用owner意识来承担最终责任。

vibe coding的终点，绝对不是让不会写代码的人随便做出一个能运行的软件。它的最终目标应该是：那些擅长规划、能够做出正确判断、懂得如何验收、勇于承担责任的人，借助AI的力量，更快、更准确地把正确的东西做出来。