最近在做优化的时候涉及到了这块内容，觉得值得写下来，方便以后翻阅。

写在前面

vibe coding 不是“让 AI 替我写代码”这么简单。

更准确地说，它是一种新的软件生产方法：人把意图、约束、上下文、验收标准和工程判断交给 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、完整 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 很隐蔽、review 很痛苦。

AI 会放大你的表达。如果你的目标是“全都要”，它就会确实给你一堆东西。

7. SDD：让规格成为源头

在 AI 开发里，SDD 可以理解为 Spec-Driven Development，也就是规格驱动开发。

传统开发里，代码往往是最核心的事实来源；而在 AI 协作里，规格应该变成更靠前的事实来源。因为 AI 生成代码的速度太快，如果没有规格约束，代码会比理解先增长。

一个实用的 SDD 不一定很重。它可以很短，但必须能指导实现。

我建议每个模块至少有一份这样的规格：

# 模块名称

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

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

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

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

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

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

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

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

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

对 AI 模块尤其要写状态流转。举个例子一次 AI run，至少要明确：

• 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：检查 migration、索引、回滚和兼容性；
• ai-run-debug skill：排查 agent 状态、tool call、trace 和 prompt；
• frontend-polish skill：检查移动端、空状态、加载态、错误态、可访问性；
• release-check skill：上线前检查环境变量、迁移、监控和回滚。

一个 Skill 可以很简单：

---
name: code-quality-review
description: 通用代码质量审查 skill。用于 review 代码、检查封装性/复用性/可维护性、发现过度抽象、职责混乱、边界泄漏、错误处理薄弱、类型设计问题、可读性问题，或在提交前做工程质量检查。适用于前端、后端、全栈、脚本和库代码。
---

# Code Quality Review

## 工作方式

1. 先确认本次审查范围：整个 diff、某个文件、某个模块，还是某个设计方案。
2. 先读项目约定：`CLAUDE.md`、README、package scripts、测试配置、lint/format 配置。
3. 再读代码入口和调用链，不只看被改文件。重点看数据从哪里来、在哪里变形、在哪里产生副作用。
4. 以 bug、维护风险和边界问题优先，不把个人风格偏好伪装成问题。
5. 输出时按严重程度排序：正确性/安全性/数据一致性 > 可维护性 > 可读性 > 风格。
6. 如果用户要求修改，就直接修；如果用户只要求 review，就只给 findings，不擅自改代码。

## 审查维度

- 职责：函数、组件、service、hook、class 是否各自只做一类事。
- 边界：UI、业务、数据访问、网络、存储、权限、配置是否混在一起。
- 抽象：是否解决了真实重复和复杂度，还是为了“看起来高级”而抽象。
- 复用：重复逻辑是否该抽 helper；相似但语义不同的逻辑是否不该硬合并。
- 类型：类型是否表达业务不变量，是否滥用 `any`、宽泛 object、字符串魔法值。
- 错误处理：是否吞错、重复 catch、把用户错误当系统错误、丢失上下文。
- 状态：是否存在竞态、旧请求污染新状态、缓存失效、状态来源不唯一。
- 数据：是否有 N+1、分页缺失、事务边界缺失、跨租户/跨用户泄漏。
- 可测试性：核心逻辑是否被 UI/IO 绑死，是否有可独立验证的边界。

## 何时读取参考

需要更细的检查清单时，读取 `references/review-checklist.md`。

## 输出格式

如果是 review，使用：

text
注意到：

• [P1] 问题标题：文件:行。说明影响、触发条件、建议修复。
• [P2] ...

开放问题：

• ...

总体判断：
...

如果没有发现问题，明确说“没有发现明确 bug 或高风险设计问题”，再列剩余风险，例如“未运行测试”或“只审查了局部 diff”。

### 修改原则

- 小步改动，保持现有项目风格。
- 优先删除不必要复杂度，再考虑新增抽象。
- 不做无关重构，不顺手格式化全文件。
- 把新抽象命名成业务语义，不用 `manager`、`helper`、`utils` 兜底命名。

Skill 的本质是把个人经验产品化。它让 AI 不只是“会写代码”，而是逐渐学会“按你的工程习惯工作”。

10. 四个工作原则

如果把上面的内容再压缩，我会把 vibe coding 的工程纪律总结成四条。这四条不是为了限制 AI，而是为了让 AI 的速度不会冲垮项目质量。

10.1 先把不确定性摊开

AI 开发最容易出问题的地方，不是模型不会写，而是它会把不确定的东西写成确定的代码。

所以在动手前，应该先把三件事说清楚：

• 我理解这次要解决什么问题；
• 我基于哪些现有事实做判断；
• 还有哪些地方不确定，准备怎么验证。

比如用户说“给报表加一个导出功能”，这句话至少有几种解释：导出当前筛选结果、导出全部数据、导出异步任务、导出带权限脱敏的数据。AI 如果直接写，很可能选错。

更好的工作方式是先收窄：

我先确认导出语义：这里应该导出当前筛选后的结果，而不是全量数据；导出字段沿用表格列，但联系电话和邮箱需要脱敏；文件生成走现有 report job，避免同步接口超时。接下来我会先查现有报表查询和 job 代码，再改导出入口。

特别是这些内容，不能靠猜：

• 数据库字段；
• 路由前缀；
• 认证语义；
• 权限边界；
• AI run 状态流转；
• 队列重试策略；
• 外部服务回调；
• 支付和订单状态；
• 文件上传和存储路径。

AI 最危险的能力不是不会做，而是它会在不了解的时候继续编。

10.2 先用小解法打通

AI 很擅长把小需求写成大系统。它会自然倾向于补配置、补抽象、补扩展点、补框架感。问题是很多扩展点在当前阶段根本用不上，只会增加 review 和维护成本。

所以默认策略应该是：先写一条最短可验证路径。

比如要做“库存不足提醒”，第一版不需要先做一套通用规则引擎。更合理的是：

• 后台配置一个固定阈值；
• 每次库存变更后检查是否低于阈值；
• 低于阈值时写入一条提醒；
• 前端在商品详情展示提醒状态；
• 测试覆盖库存从高到低、重复提醒、库存恢复。

等到确实出现多个仓库、多个品类、多个阈值策略，再考虑抽象。不要为了“未来可能”牺牲当前清晰度。

资深工程师对 AI 代码的一个重要动作，就是把“看起来很完整”的代码压回“刚好够用”的代码。

10.3 控制改动半径

AI 一次能改很多文件，这既是能力也是风险。工程上要关心的不只是功能有没有做出来，还要关心 diff 能不能被人理解。

我会用“改动半径”来判断一次 AI 修改是否健康：

• 半径 1：只改当前函数或组件，最容易 review；
• 半径 2：改当前模块的 service、route、test，可以接受；
• 半径 3：跨模块改公共类型、状态、协议，需要更强测试；
• 半径 4：顺手重构架构、格式化大量文件，通常应该拆开。

比如修一个“筛选条件刷新后丢失”的 bug，合理范围可能是查询参数同步和对应测试；如果 AI 顺手重写了整个表格状态管理，就算最后能跑，也会让风险变大。

注意到无关问题可以记录在回复里，或者单独开任务。不要把“我顺手看到了”变成“我顺手改了”。

10.4 用验证关门

AI 说完成了没有意义，验证完成才有意义。

不同类型任务应该有不同的关门方式：

• 修 bug：复现条件消失；
• 做接口：请求、响应、错误码和权限都被验证；
• 做 UI：加载、空态、错误态、移动端至少看过关键路径；
• 做 AI 功能：正常输出、工具失败、模型超时、人工取消都能解释；
• 做重构：行为不变，测试结果不变。

比如修“订单列表偶发重复行”，不要只说“我加了去重”。更完整的闭环应该是：

复现：快速切换分页和筛选时，同一个订单会被追加两次。
根因：请求返回顺序不可控，旧请求覆盖了新筛选状态。
修复：给列表请求增加 request key，只接受最后一次请求结果。
验证：新增并运行并发请求顺序测试，手工快速切换筛选没有再出现重复行。

vibe coding 的完成标准不是代码生成完，而是风险被关闭到当前阶段可以接受。

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

AI 需要人去规划、决策和 review。

即使现在很多人在用 AI 开发代码，团队里也必须有人做 owner。owner 不是职位，而是一种工作方式。

一个合格的 owner 至少要盯住六件事：

• 目标是否确实清楚，而不是只听起来合理；
• 任务是否已经拆到 AI 可以稳定执行的粒度；
• 风险是否及时暴露给团队，而不是藏在聊天记录里；
• 结果是否被验收，而不是只看 AI 的完成声明；
• 经验是否回流到文档、规则或 Skill；
• 从需求、实现、联调、测试、上线到反馈，是否有人持续看完整链路。

AI 可以帮你写代码、补文档、查 bug、跑测试、生成方案，但它不会为线上事故负责，也不会为需求误解负责，更不会为团队协作成本负责。

所以越是使用 AI，越要有 owner 意识。

AI 降低了执行成本，但没有降低责任成本。

12. 团队中怎么用 AI

个人用 AI 写 demo，可以随意一点；团队用 AI 写生产代码，必须严谨。

团队里需要统一几件事：

第一，统一公共规则。

哪些文件可以改，哪些命令必须跑，哪些安全边界不能碰，哪些代码风格必须遵守，这些应该写进 CLAUDE.md 或项目规则。

第二，统一任务颗粒度。

不要把“实现完整订单系统”丢给 AI。应该拆成：订单创建、库存锁定、支付回调、订单取消、超时关闭、退款、后台查询、测试覆盖。

第三，统一 review 标准。

AI 生成代码不能跳过 review。甚至更需要 review，因为它可能写出“看起来很合理但刚好错一点”的代码。

第四，统一验收方式。

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

第五，统一沉淀机制。

一次 AI 犯错不要只在聊天里纠正。重复出现的问题应该进入 CLAUDE.md、Skill、模板或 checklist。

团队用 AI 的关键不是每个人都变快，而是团队整体吞吐变高、返工变少、质量不下降。

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

不要让 AI 在所有任务里都扮演同一个“全能工程师”。不同阶段要给它不同角色。

原型阶段：

你是产品设计师和前端原型工程师，目标是快速生成可讨论的 UI，不追求最终架构。

方案阶段：

你是技术负责人，目标是把原型拆成可实现模块，指出风险和依赖，给出阶段计划。

后端阶段：

你是后端工程师，必须复用现有 service、route、schema 和测试工具，不允许发明新架构。

前端阶段：

你是前端工程师，必须匹配现有组件风格，覆盖加载态、空态、错误态和移动端布局。

联调阶段：

你是全栈联调工程师，目标是检查接口契约、字段命名、错误码、状态同步和真实用户路径。

AI 搭建阶段：

你是 AI 系统工程师，重点是 prompt、tool、memory、state machine、trace、eval、fallback 和人工确认边界。

测试阶段：

你是测试工程师，重点是复现路径、边界输入、回归风险、端到端闭环和最小验证命令。

Review 阶段：

你是严格的 code reviewer，只关注 bug、风险、回归和测试缺口，不做泛泛评价。

角色越清晰，AI 的输出越稳定。

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

AI 时代，文档不是“写给人看的附属品”，而是“写给人和 AI 共同使用的控制面”。

好的文档可以让 AI 更快进入项目上下文，减少错误假设。坏的文档会把 AI 带偏，而且偏得很自信。

项目里至少应该有几类文档：

• 产品需求文档：说明用户、目标、流程和非目标；
• 技术方案文档：说明模块、接口、数据、状态和依赖；
• AI 规格文档：说明 prompt、tools、memory、eval、状态机和安全边界；
• 联调文档：说明接口契约、错误码、字段和测试账号；
• 测试文档：说明测试范围、命令、手工路径和已知风险；
• 运维文档：说明环境变量、部署、监控、告警和回滚。

文档不需要很长，但必须准确。尤其是给 AI 用的文档，要短、具体、结构化、可验证。

15. 测试会变得更重要

AI 写代码越快，测试越重要。

因为代码生成速度上来了，但理解速度、review 速度、联调速度没有同比提升。如果没有测试，团队会被大量“差一点正确”的代码淹没。

Stack Overflow 2025 Developer Survey 里，开发者对 AI 的主要挫败感之一就是“AI 给出的方案几乎正确但不完全正确”，另一个高频问题是调试 AI 生成代码更耗时。这和实际体感十分一致。

测试在 AI 开发里有两个作用。

第一，它是验收工具。

AI 说完成了不算，测试过了才接近完成。

第二，它是约束工具。

当你让 AI 修改代码时，已有测试会告诉它哪些行为不能破坏。没有测试的项目，AI 会更容易在无意中改变行为。

最实用的策略不是一开始追求 100% 覆盖率，而是优先覆盖：

• 核心用户路径；
• 权限和认证；
• 支付、订单、余额等资金相关逻辑；
• AI tool 调用和状态流转；
• 数据写入和删除；
• bug 修复的复现用例；
• 前后端接口契约；
• 高风险边界条件。

AI 生成代码的效率越高，测试就越像刹车和方向盘，而不是额外负担。

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

AI 可以很快生成前端，也可以很快生成后端，但它不一定能保证两边真的对上。

联调最常见的问题包括：

• 字段名不一致；
• 枚举值不一致；
• 错误码不一致；
• 空状态没处理；
• 分页协议不一致；
• 时间格式不一致；
• 权限失败时前端没有路径；
• 后端返回 nullable，前端按必填处理；
• 前端缓存导致状态不同步；
• AI 生成 mock 后忘记接真实接口。

所以联调阶段要重点检查“契约”，不是只看代码。

一个简单有效的联调 prompt：

你是前后端联调工程师。

请检查当前功能的前端调用和后端接口是否一致。

重点检查：
- URL 和 method
- request body / query
- response 字段
- enum / status
- error format
- auth / permission
- loading / empty / error states
- mock 是否已替换为真实接口

输出：
- 不一致项
- 影响
- 推荐修复位置
- 最小验证方式

联调不是最后才做的事。每个小闭环都应该尽早联调。

17. 工程阶段怎么约束 AI

工程阶段要从“让 AI 发挥”切换成“让 AI 遵守”。

你应该给它明确边界：

• 不准改无关文件；
• 不准引入新依赖，除非说明理由；
• 不准发明数据库字段；
• 不准绕过现有权限；
• 不准跳过测试；
• 不准吞掉错误；
• 不准把 mock 当真实实现；
• 不准用大范围重构掩盖小问题；
• 不准在没有确认的情况下执行危险命令；
• 不准把敏感信息放进 prompt、日志或前端。

AI 不怕规则多，怕规则模糊。规则要短、硬、可检查。

最终结论

vibe coding 是一个机会，也是一种压力。

它让一个人可以更快做出原型，让小团队可以做过去需要更多人才能做的事情，也让非专业开发者有机会把想法变成软件。

但它不会自动带来高质量工程。AI 会放大人的能力，也会放大人的模糊、懒惰和侥幸。

所以真正值得追求的不是“让 AI 多写代码”，而是建立一套人和 AI 协作的工程系统：

• 用原型发现需求；
• 用文档收敛共识；
• 用提示词表达任务；
• 用 CLAUDE.md 固化公共规则；
• 用 Skill 复用经验；
• 用 SDD 约束复杂模块；
• 用小闭环降低风险；
• 用测试验证结果；
• 用 review 保持质量；
• 用 owner 意识承担责任。

vibe coding 的终点，不是不会写代码的人随便做软件。

它的终点应该是：会规划、会判断、会验收、会负责的人，借助 AI 更快地把正确的东西做出来。

---

以上就是这次整理的全部内容，希望对你有所启发。如果有不同见解，欢迎在评论区交流讨论。