Vibe Coding 实战

Vibe Coding 可以加快从想法到第一版的速度，但“页面能打开”不是完成。生产级做法是让自然语言负责表达目标，让仓库规则限制方案，让测试和真实用户流程决定能不能交付。

---

哪些任务适合，哪些需要收紧权限

判断标准不是“AI 会不会写”，而是错误的 blast radius、能否自动验证、能否回滚，以及是否涉及外部副作用。

---

一次 Vibe Coding 迭代

Outcome
  → 给 Agent 目标、背景、约束、验收
  → 让 Agent 读取规则和相邻实现
  → 生成最小 patch
  → 运行窄测试
  → 人检查 diff 与风险边界
  → 运行真实用户流程
  → 保存证据或继续下一轮

一次循环只解决一个可验证行为。不要让“顺便重构、顺便升级依赖、顺便改 UI”进入同一轮。

---

可复用 Prompt 模板

目标：
[用户完成什么结果]

当前行为：
[如何复现，包含 URL、输入和错误]

相关范围：
[允许读取/修改的目录、已有模式]

不能动：
[URL、API contract、数据库字段、其他人的改动]

技术约束：
[框架、设计系统、测试命令、安全要求]

验收：

-   [可观察结果 1]
-   [边界条件 2]
-   [测试和真实流程 3]

先只读分析并给出证据。确认最小修改方案后再编辑。

这比“做得好看一点”更有效，因为它把主观目标翻译成可观察状态：布局层级、移动端行为、交互反馈、加载/空/错状态和视觉规范。

---

从 prototype 到 production 的四道门

1. Behaviour gate

• Happy path 能完成。
• 空数据、错误输入、超时和重复点击有结果。
• 刷新、后退和重新进入不会丢失必要状态。

2. Code gate

• Typecheck、lint 和相关测试通过。
• 没有虚构 import、重复 utility 或无用抽象。
• Diff 只覆盖任务范围。

3. Risk gate

• 权限由服务端验证。
• 写操作幂等，高风险动作有审批。
• Secrets、PII 和内部路径不出现在日志或 UI。

4. User gate

• 在真实 viewport、浏览器或客户端中完成流程。
• 文案对目标用户自然，不暴露内部术语。
• 用户知道下一步、成功状态和失败恢复方式。

---

Quality Gate 不应该是网上抄来的数字

“覆盖率必须 80%”“PR 不能超过 400 行”可能适合某团队，但不是普遍真理。阈值应由仓库风险和历史数据决定。

# 示例：使用项目自己的命令和阈值
steps:
    - name: Format and lint
      run: bun run lint
    - name: Narrow tests
      run: bun test src/path/to/changed-feature.test.ts
    - name: Build
      run: bun run build
    - name: Contract check
      run: bun run test:contracts

CI 只能证明自动化断言；支付完成、消息发布和真实安装等结果仍需要外部 read-back 或设备验证。

---

Review AI 代码的七个问题

1. 是否引用了不存在的函数、配置或 package？
2. 是否绕开仓库已有 helper、组件或错误处理？
3. 是否改变 URL、API contract 或数据库关系？
4. 是否新增隐藏网络请求、写操作或日志数据？
5. 是否把客户端检查误当成授权？
6. 是否用更复杂的抽象解决简单问题？
7. 测试是否覆盖用户行为与失败方式？

让第二个模型 review 可以提供候选问题，但不能替代责任人读 diff、运行代码和确认业务不变量。

---

Debug 时给 Agent 什么

差的输入：

报错了，帮我看看。

可诊断输入：

Command: bun test src/auth/login.test.ts
Expected: invalid password maps to INVALID_CREDENTIALS
Actual: response becomes UNKNOWN_ERROR
First failing assertion: login.test.ts:84
Relevant call path: LoginForm → request.ts → mapApiError
Last known good commit: 1a2b3c4
Constraints: do not change API response shape

错误日志应截取第一处有意义的失败和相关调用链。不要把整个终端历史、.env 或 token 复制进 Prompt。

---

三个可复现故障演练

这些是练习场景，不是假装发生过的“真实事故”。

演练 A：虚构 API

让 Agent 为 UI 引入一个并不存在的 hook。Review 时用 rg、类型检查和 package docs 证明它不存在，再要求复用仓库已有实现。

演练 B：错误并发锁

给多实例订单服务加进程内 mutex。单元测试会通过，但启动两个进程后仍产生重复订单。修复目标是数据库约束、分布式协调或 provider idempotency，而不是相信单进程测试。

演练 C：危险 Migration

生成删除旧字段的 migration，但只允许在 fixture 上 dry-run。要求先证明没有读路径、准备备份与回滚，并在没有生产授权时停止。

---

UI 任务不能只看代码

至少检查：

“组件渲染成功”不能证明页面好用。真实 viewport QA 才能发现断行、重叠、隐藏卡片和错误交互顺序。

---

安全的 Git 节奏

git status --short
git diff -- path/to/files
git diff --check
git add -- path/to/exact-files
git diff --cached --name-only
git commit -m "fix(scope): describe user outcome"

Dirty worktree 中的其他改动属于用户或同事。不要 stash、reset、restore 或 broad-stage 来让自己的任务“看起来干净”。

---

动手练习：一个带空错状态的列表页

1. 写明用户、结果、不能改的 URL 和 API contract。
2. 找仓库里最接近的列表页模式。
3. 让 Agent 只实现默认与 loading 状态，运行测试。
4. 第二轮补 empty 与 error，检查恢复路径。
5. 在桌面和移动 viewport 完成真实流程。
6. Review scoped diff，只提交本次文件和证据。

完成标准

• 自然语言输入包含目标、背景、约束和验收。
• 每轮只处理一个可验证行为。
• 自动化检查与真实用户流程都执行了。
• 高风险副作用没有被 Prompt 授权替代。
• 页面中的案例明确标为练习，不伪造内部事故和指标。

相关阅读

• AI Coding 工作流
• AI Rules 配置
• Claude Code Examples
• Vibe Coding 学习中心

官方参考

• https://code.claude.com/docs/en/quickstart
• https://kiro.dev/docs/specs/
• https://kiro.dev/docs/steering/