Vibe Coding
术语边界: Vibe Coding 不是统一标准术语. 本章采用本书工作定义: 用自然语言快速生成和迭代软件产物, 再由工程师通过运行结果, 测试, 审查和风险门禁收口. 该词由 Andrej Karpathy 在 2025 年的公开讨论带火, 其原始表述属于术语出处和个人观点, 不能替代平台事实或工程标准.
适用范围: 本章用于 AI-assisted software delivery 教学和面试表达; 不定义行业标准, 也不代表任一产品版本或能力. 核验日期与来源见文末.
本章是 AI Coding 四章的概览入口:
- 本章: 适用场景, 风险和基本闭环.
- Harness Engineering: 如何配置 instructions, tools, permissions, evals 和审计.
- AI Coding 工程化进阶: context, tool calling, MCP, 隐私和供应链治理.
- Loop Engineering 与前沿 Vibe Coding: 可观察, 可验证, 可终止的反馈循环及产品趋势.
学习目标
完成一次从任务定义到人工审查的受控小改动, 并能指出 prompt 缺少上下文时为什么不能直接执行. 本文的流程是工作示例, 不宣称任一 AI 产品必然具有相同功能.
一, 本书如何定义 Vibe Coding
开发者用自然语言描述目标和约束, AI 生成代码, 页面, 脚本或方案, 人再根据真实反馈修改. 它强调探索速度, 但不转移质量责任. 如果没有检查需求, diff, 测试和运行结果, 就只是未受控生成, 不是可靠的软件交付流程.
二, 最小工作流
- 写清目标, 非目标, 平台版本, 可改范围和验收标准.
- 让 AI 读取真实代码和项目规则, 而不是只凭一段 prompt 猜测.
- 生成最小 patch, 避免顺手升级依赖或重构无关模块.
- 运行与改动匹配的测试, 构建, 静态检查或设备路径.
- 人工审查业务不变量, 生命周期, 安全, 隐私和维护成本.
- 记录证据和剩余风险; 不满足终止条件时回退或升级人工处理.
三, 适合和不适合的场景
| 适合 | 不适合直接无人审查 |
|---|---|
| 原型, Demo, 重复样板, 文档草稿 | 支付, 身份, 密钥, 隐私和发布配置 |
| 测试骨架, API 使用探索, 局部重构 | 上下文不完整的大范围架构改造 |
| 日志和堆栈摘要, 排障假设清单 | 生产事故中未经复现和验证的盲改 |
四, 端到端 walkthrough: 修复旋转后重复加载
** 练习任务 (示例, 不是某仓库的真实缺陷):** 搜索页旋转后重复发起请求. 目标是同一 query 在状态已恢复时不重复网络加载; 非目标是更换架构, 升级依赖或改导航. 验收为单元测试覆盖恢复分支, 相关 UI / 设备路径验证, diff 仅在约定范围内.
- ** 定义任务.** 写下 write scope (例如
feature/search), 禁改项, 当前分支 / commit, 风险 (生命周期, 缓存一致性) 和停止条件 (缺少测试环境或发现跨模块 API 变更则升级人工). - ** 收集最小上下文.** 读取项目 instructions, SearchViewModel, state 数据类, Repository 接口, 现有测试和 Gradle 测试命令; 记录这些文件的版本. 不要把整个仓库, 密钥或无关 issue 放进上下文.
- ** 写 prompt.** 要求 agent 先概括当前状态 owner 和请求触发点, 再提出最小 patch; 禁止它臆测不存在的类, 执行写范围外动作或声称未运行的命令.
- ** 审阅 patch.** 检查
SavedStateHandle/持久化边界只保存 query 或可恢复参数, 而不保存网络 Job; 确认已加载 key, 取消和异常状态的迁移一致; 确认没有把 “旋转” 误当 “进程死亡”. - ** 验证.** 先让新增测试在旧实现失败, 再应用 patch 并运行允许的单元测试; 有环境时补旋转 / 重建设备路径. 记录命令, 环境, 结果和未执行原因.
- ** 人工审查和收口.** 检查 diff, 线程 / 协程取消, 错误态, 访问控制和范围外文件; 满足验收才合入, 否则回退 patch 或转为人工排查.
上下文片段: 好与坏 prompt 对比.
坏:搜索页旋转重复请求,修好并运行所有测试.
它没有模块, 状态 owner, 非目标, 验收或权限, 容易诱发大范围猜测.
好:仅修改 feature/search.先读取 AGENTS.md,SearchViewModel,SearchUiState,
SearchRepository 和对应单元测试.目标:恢复已有 query 时不重复 load;非目标:不升级
依赖,不改导航.先说明当前触发链和你的最小方案,再给 patch.新增测试必须能在旧实现
失败.只运行 ./gradlew :feature:search:testDebugUnitTest;若命令或文件不存在,停止并报告,
不要猜测或扩大范围.报告 diff,命令结果和未验证风险.
这里的类名和命令只是示例. 真实仓库必须用实际模块, 允许命令和已验证符号替换.
五, Android 场景的质量边界
| 场景 | AI 适合做 | 人和流水线必须兜底 |
|---|---|---|
| ViewModel 状态机 | 生成 runTest/Turbine 用例草稿 | 断言是否覆盖真实业务不变量和恢复路径 |
| ANR/Perfetto 排查 | 摘要线程栈, 锁等待和耗时片段 | 回到 trace, 源码和真实设备验证根因 |
| 权限适配 | 梳理 Photo Picker, 通知, FGS 等迁移点 | 版本矩阵, 商店政策和隐私法律复核 |
| Gradle 报错 | 解释依赖冲突和兼容性候选 | 不为了过编译而盲目升级 AGP/Kotlin/AndroidX |
| Compose 页面 | 生成 Preview, 状态样例和测试骨架 | 生命周期, 重组, 无障碍, 截图和设备表现 |
按验证层级从单元测试到设备矩阵的分层清单, 见 Harness Engineering 的验证阶梯.
AI 产物进入 PR 前至少检查:
- 是否引用不存在的 API, 依赖或设计系统组件.
- 生命周期, 线程, 协程取消和进程恢复是否正确.
- 是否新增权限, SDK, 网络域名, 敏感日志或数据出境.
- 测试是否验证用户可见行为, 而不是只验证 mock 被调用.
- 结论是否有模型版本, 工具版本, 命令输出或人工证据支撑.
六, 常见失败模式
- 幻觉: 编造 API, 参数或产品能力.
- 上下文污染: 过期文档和错误记忆覆盖当前代码事实.
- 过度设计: 为局部问题生成难维护的抽象.
- 弱验证: AI 自己写弱断言, 再用它证明自己的实现正确.
- 权限扩大: 为完成任务读取秘密, 修改发布配置或执行高风险命令.
控制方式不是 “再写一个更长的 prompt”, 而是最小充分上下文, 小步 diff, 最小权限, 独立验证, 人工 gate 和可回滚提交.
七, 面试怎么答
我把 Vibe Coding 当作快速探索方式, 不是交付标准. 我会让 AI 先读项目规则和真实代码, 生成小范围 patch, 再用测试, 构建, trace, 截图或设备路径验证. 支付, 隐私, 权限, 发布和依赖升级必须人工审批. AI 提高吞吐量, 但工程师仍对需求判断, 证据质量和最终结果负责.
高频面试题
Q1: Vibe Coding 等于所有 AI-assisted programming 吗?
不等于. 业界没有统一定义. 面试时应先声明采用的工作定义, 再说明受控工程流程与 “凭感觉接受输出” 的区别.
Q2: 最大风险是什么?
不是单一 “幻觉”, 而是错误假设在缺少验证, 权限边界和人工审查时进入生产.
Q3: 如何证明 AI 真正提效?
在固定任务集上保留基线与样本再对比, 不能只展示一次成功 Demo; 具体评估指标维度详见 Loop Engineering 第六节.
练习与预期证据
选择一个低风险 bug, 写任务卡, 最小 context pack, 好 prompt 和坏 prompt 各一份. 预期证据是: 范围内 patch, 旧实现失败的新测试, 验证命令及结果, 人工审查项和剩余风险; 未运行的检查必须明确标记.
版本与参考资料
- 最后核验: 2026-08-07.
- 稳定性: “Vibe Coding” 的语义仍在演化; 本章定义仅用于本书教学和面试表达.
- Andrej Karpathy 的公开讨论可作为术语出处, 不作为工程标准.
- Simon Willison 对 vibe coding 与一般 AI-assisted programming 的区分可作为观点参考, 不作为产品事实来源.
- 工程落地以具体模型/API/工具的官方文档, 仓库约束和团队 eval 结果为准.