Vibe Coding 最佳实践：从灵感原型到可验证工程

核心结论｜ Vibe Coding 可以把“想法到可运行原型”的距离大幅缩短，但不能自动把原型变成可信软件。面向生产的正确升级方向，是让 AI 负责高吞吐探索与实现，让人、测试、权限边界和交付流程共同负责规格、证据与风险。

目录

• 1. 学习目标
• 2. 面试结论
• 3. 面试官为什么问
• 4. 概念与边界
• 5. 原理剖析
• 6. 实现与代码
• 7. 示例项目：为任务列表增加状态筛选
• 8. 技术难点、方案亮点与生产经验
• 9. 面试题与参考答案
• 10. 递进追问
• 11. 实践任务
• 12. 相关知识与参考资料
• 13. 简明总结

1. 学习目标

学完本文后，应当能够：

• 用 30 秒区分狭义 Vibe Coding、广义 AI 辅助编程与 Agentic Engineering；
• 解释为什么自然语言生成代码只是概率性动作，外部验证才是可交付证据；
• 按风险选择任务，写出包含范围、约束和验收标准的任务契约；
• 组织“探索、计划、小步实现、验证、独立审查、发布、复盘”的完整闭环；
• 为 Coding Agent 配置最小权限、隔离环境、分支保护、审计和回滚；
• 识别错误完工、测试弱化、范围蔓延、上下文污染、环境不一致与提示注入；
• 按需求、探索、实现、验证、排障和交付阶段复用 Vibe Coding 开发经验清单；
• 把一次 AI 编程实践整理成可验证的项目亮点，而不是只说“我用 AI 写得很快”。

2. 面试结论

2.1 30 秒回答

Vibe Coding 狭义上是用自然语言和运行反馈驱动 AI 持续生成代码，甚至刻意不深入阅读实现，适合低风险原型和一次性实验。生产级最佳实践不是盲目接受生成结果，而是把流程升级为“明确规格与风险、读取真实仓库、拆分小任务、在受控环境修改、用外部验收取证、独立审查后发布”。所以判断做得好不好，不看 AI 写了多少代码，而看需求、正确性、安全性和可维护性是否都有可定位证据，并且始终有明确的人类责任人。

2.2 一分钟面试复述版

我会先区分两种语境。Andrej Karpathy 在 2025 年提出的狭义 Vibe Coding，强调顺着模型输出快速试错、很少关心代码本身，这种方式对周末原型和探索很有价值；今天很多人又把所有自然语言驱动的 AI 编程都泛称为 Vibe Coding。

真正进入团队和生产后，我不会把“忘记代码存在”当最佳实践，而会把它改造成证据驱动的 Agentic Engineering。人先定义目标、范围、风险、非目标和验收标准，Agent 先探索再计划；独立 Worktree 管理并行修改，Sandbox 与最小权限限制执行边界。测试、构建、静态检查、截图、Diff 和安全扫描形成外部反馈，独立 Reviewer 与人类 Owner 决定是否合并。高风险的鉴权、支付、隐私、数据迁移和生产操作还要提高隔离、审批和复核级别。

所以选型关键不是“要不要 Vibe Coding”，而是当前任务允许多少探索、需要什么确定性证据，以及失败的爆炸半径能否被权限和回滚控制。

3. 面试官为什么问

这道题表面在问一个流行词，实际常考以下能力：

1. 概念边界：能否区分快速原型、AI Pair Programming、Coding Agent 和生产工程；
2. 软件工程基本功：是否知道规格、测试、Review、CI、发布和回滚不能被 Prompt 替代；
3. Agent 原理：是否理解模型动作具有概率性，工具结果和验证器会驱动下一轮；
4. 风险判断：能否根据业务关键度、数据敏感度、可逆性和可观测性调整自治程度；
5. 工程效率：是否会管理上下文、任务粒度、并行 Agent、环境和人工 Review 成本；
6. 生产经验：遇到“CI 绿但功能错”“模型说完成但没有执行命令”时，能否沿证据链排查；
7. 项目表达：能否把“用了 AI”转化为有约束、决策、证据和边界的技术亮点。

优秀回答不会站队“AI 会不会替代程序员”，而会讲清楚责任如何重新分配：实现吞吐更多交给模型，规格、验证、权限和最终责任仍由工程系统与人承担。

4. 概念与边界

4.1 小白先这样理解：周末搭样板间

小林想在周末做一个咖啡店样板间。他不亲自锯木板，而是拿着对讲机告诉一支速度极快的施工队：“吧台再靠左一点，灯光暖一点，入口加一个展示架。”施工队几分钟就改完，小林看一眼效果，再继续说下一句。到周日晚上，样板间已经能拍照展示。

麻烦在于，小林只看外观，没有检查承重、电路和消防。如果这个房间只是用来展示概念，快速试错很划算；如果周一就要让顾客正式营业，必须补齐图纸、材料标准、验收、监理和消防检查。

这组生活元素与技术对象的对应关系是：

生活场景	技术对象
小林描述想要的效果	自然语言目标、Prompt、产品反馈
快速施工队	大模型与 Coding Agent
建筑图纸和现场结构	代码仓库、架构、依赖和运行环境
电锯、吊车和门钥匙	文件、Shell、浏览器、数据库、部署等工具权限
样板间外观	Demo、页面截图、局部功能表现
承重、电路和消防验收	单元测试、集成测试、静态检查、安全扫描与人工 Review
独立施工房间	Worktree 或单独 Checkout，用于隔离并行修改
施工围挡和分区钥匙	Sandbox、最小权限与网络边界
监理签字和营业许可	Code Owner、审批、CI Gate 与发布流程

回到专业机制，Vibe Coding 的效率来自自然语言控制和高频反馈，不是来自“代码天然正确”。类比能解释原型速度与隐藏质量的冲突，却没有表达软件的非确定性、并发、供应链和线上数据副作用；测试也不像消防验收那样能证明所有情况。因此生产系统仍需要分层验证和持续监控。

4.2 狭义与广义定义

狭义 Vibe Coding 指 Karpathy 原始描述中的轻量玩法：用户主要观察结果、继续说需求、运行并接受模型修改，甚至不认真阅读代码。它强调创作流和反馈速度，原始语境也把它放在一次性周末项目附近。

广义 Vibe Coding 已经常被用来指任何“用自然语言驱动 AI 写软件”的方式，其中既包含盲目接受，也包含严谨的规格、测试和 Review。为了避免讨论混乱，本文把后者称为 证据驱动的 AI 辅助工程 或 Agentic Engineering。

Google Cloud 当前的官方解释也明确区分 Pure vibe coding 与 Responsible AI-assisted development：前者以探索速度为主，后者要求用户审查、测试、理解并对最终产品负责。这个分类不是行业强制标准，但很适合说明本文的责任边界。

4.3 它不是什么

相近概念	核心特点	与 Vibe Coding 的区别
传统编程	人直接设计并编写大部分实现	自然语言反馈不是主要控制面
AI Pair Programming	人与 AI 共同编辑、解释和审查代码	人通常持续理解实现，不以“忘记代码”为目标
Agentic Coding	Agent 可读仓库、编辑文件、运行命令并循环	描述的是能力与运行形态，不等于盲目接受
No-code / Low-code	在预设平台和组件内组装应用	受平台抽象约束，不一定生成或维护通用代码库
Prompt Engineering	优化对模型的指令和上下文	只覆盖输入，不包含环境、权限、测试、发布和治理
自动代码生成	根据 Schema、模板或 DSL 确定性生成	输出通常更可预测，探索性和语义推理更少

4.4 适用与不适用场景

狭义 Vibe Coding 更适合：

• 一次性脚本、个人工具和可丢弃实验；
• UI 草图、交互 Demo、数据可视化和创意探索；
• 已有强测试保护下的样板代码、文档、测试草稿和机械迁移；
• 用于发现需求、比较方案或证明某个技术路径可行的 Prototype。

不能直接按狭义方式交付的场景包括：

• 鉴权、授权、支付、密码学、隐私和合规代码；
• 数据库迁移、生产运维、不可逆外部操作和事故响应；
• 缺少测试、文档和领域专家的复杂遗留系统；
• 对实时性、安全性、资源上限或法律责任有严格约束的核心链路；
• 团队无人能解释、维护或承担生成结果的系统。

边界判断｜ 不是“高风险任务绝对不能用 AI”，而是不能把高风险任务交给无规格、无隔离、无验证、无独立复核的纯 Vibe 流程。

5. 原理剖析

5.1 本质是带外部反馈的概率控制循环

抽象边界｜ 下面是本文用于教学的控制模型。Tool Call 与 Observation 是 Coding Agent 的常见公开模式；测试、独立 Reviewer 和人类批准是推荐接入的工程闭环，不代表任一产品每轮都会自动执行这些步骤，也不等于产品内部固定实现。

Coding Agent 在第 t 轮根据目标、仓库上下文和历史观察生成候选动作：

$$a_t\sim p_{\theta }(a_t\mid G,C_t,H_t)$$

其中：

• G 是目标、范围和验收标准；
• C_t 是当前代码、文档、规则、工具说明和环境信息；
• H_t 是此前的对话、工具调用和结果；
• a_t 是读取、搜索、修改、运行测试或给出最终回答等候选动作。

运行时在环境 E 中执行获准动作并产生观察：

$$o_t=E(a_t),pas{s}_t=V(o_t,A)$$

V 是测试、构建、静态检查、截图比较、安全扫描或人工 Review 等验证器，A 是可执行验收标准。若失败，证据进入下一轮上下文；若通过，也只能证明验证器覆盖到的范围，不代表软件在所有输入和环境下都正确。

因此，生成代码的概率能力 与 证明交付正确的工程能力 是两件事。Prompt 可以提高候选方案质量，但不能代替独立验证器。

5.2 从 Vibe 到可信交付的闭环

可信 Vibe Coding 不是绑定某个 Coding Agent 品牌，而是把隔离、验证和独立审查变成可替换的工程组件。下面的参考栈优先选择通用 Git、操作系统隔离和 CI 原语；具体产品能力仍需以目标仓库和当前版本实测。

技术清单

技术点 ID	技术点/环节	类型	采用方案	链路职责	版本/证据边界
TP-VIBE-ISOLATION	修改与执行隔离	基础设施	Git Worktree + Workspace 写边界 + OS Sandbox/Container	隔离并行 Writer、限制文件和网络范围，并保留可审查 Diff	Branch 不能隔离同一工作目录；不同 Agent 产品的沙箱能力需按平台核验
TP-VIBE-VERIFICATION	统一验收入口	CI/工具链	make verify 或等价脚本统一调用 Lint、Type Check、Test、Build 与专项检查	让本地 Agent、CI 和人工复核执行同一组确定性验收	绿色命令只证明覆盖范围，浏览器、数据库、性能和生产配置仍需专项证据
TP-VIBE-REVIEW	独立审查与发布门禁	协作/服务	新上下文 Reviewer + Code Owner/Branch Protection + 灰度监控	分离 Writer 与验收者，检查范围、正确性、安全和回滚条件	AI Reviewer 不是责任主体；高风险发布仍需人类批准和业务监控

横向选型对比

技术点 ID	候选方案	优点	缺点/代价	适用场景	不适用场景	选择结论与依据
TP-VIBE-ISOLATION	Git Worktree + Sandbox/Container	文件写入和执行边界可分开控制，并行任务冲突更少	环境准备、依赖缓存和端口管理更复杂	多 Agent、仓库级修改、高风险命令和并行验证	只读问答或一次性无副作用小实验	生产协作默认；以越界写入、网络拒绝和并行冲突测试验收
TP-VIBE-ISOLATION	仅创建 Branch、共享工作目录	操作简单、Git 心智成本低	Branch 不隔离未提交文件、构建产物和并发写入	单一 Writer 且严格串行的小任务	多 Writer、共享脏工作区和不可信命令	仅作为低并发备选，不声称具备执行隔离
TP-VIBE-VERIFICATION	统一 verify 脚本 + CI 必需检查	命令可复现，本地与 CI 证据一致，失败易定位	维护测试数据、环境和运行时间有成本	长期仓库、多人协作和可发布变更	完全可丢弃的草图或无构建环境的探索	默认选择；每个验收项必须映射到自动或人工证据
TP-VIBE-VERIFICATION	Agent 自检 + 人工冒烟	启动快、早期原型反馈直接	易自证、覆盖不稳定、无法可靠防回归	低风险界面草图和需求探索	API 兼容、数据权限、迁移与生产发布	只作前置反馈，不能替代权威回归门禁
TP-VIBE-REVIEW	独立 Reviewer + Code Owner + 灰度	能发现实现者盲点，并把发布责任与恢复链路显式化	增加等待、算力和人工审查成本	中高风险、跨模块、面向真实用户的变更	可随时丢弃且不进入共享分支的原型	默认生产候选；Reviewer 发现需由证据复核，不按意见数量投票
TP-VIBE-REVIEW	Writer 自审后直接合并	反馈快、流程摩擦低	同一上下文容易遗漏需求和安全盲点，责任边界不清	个人临时分支上的微小可逆修改	安全、支付、权限、部署和公共接口变更	仅用于低风险预览，正式交付不采用

图：架构｜可信 Vibe Coding 的隔离、验证与发布组件边界

替代文本： Issue 或任务契约进入 Coding Agent Runtime；Runtime 只在 Worktree 与 Sandbox 中读取、修改和执行。代码仓库保存权威源，统一 Verify 入口调用测试、构建、静态检查、浏览器或安全扫描；独立 Reviewer 只读取契约、Diff 与证据，人类 Owner 通过分支保护批准后进入灰度发布，运行监控和回滚结果再沉淀为测试、规则、Skill 或 Runbook。

图表加载中…

读图结论： Coding Agent 只是候选变更生成器；Worktree/Sandbox 控制边界，Verify 与 Reviewer 提供独立证据，人类 Owner 和运行监控决定能否安全发布。

架构允许替换具体 Agent 或 CI 平台，但任务契约、隔离工作区、权威验证和发布责任人不能因为模型更强而省略。

图：技术调用流程｜Vibe Coding 从灵感到可信交付的证据闭环

替代文本： 用户先根据任务风险决定纯原型、受控协作或人类主导；随后把目标写成带范围和验收标准的任务契约。Agent 读取真实仓库并提出计划，在隔离环境做小步修改；测试、构建、Diff、安全扫描和截图等验证器给出证据。失败返回计划或实现，成功还要经过新上下文审查和人类责任人批准，再灰度发布、监控和沉淀规则。高风险任务增加审批、最小权限和回滚演练。

图表加载中…

读图结论： Vibe Coding 的生产化不是增加一个更长的 Prompt，而是把风险、验证、独立复核和恢复能力接入模型循环，使每次“完成”都能落到外部证据。

图中有三个重要回路。验证失败回到计划，避免只在错误实现上继续打补丁；独立 Review 发现缺口也回到证据链，避免实现者自证；发布后的真实监控再反哺规则和回归测试，使后续任务越来越可控。

5.3 一个非测量性的质量模型

可以用下面的乘积关系帮助记忆，它是工程心智模型，不是经过统计拟合的公式：

$$\mathrm{可}\mathrm{信}\mathrm{交}\mathrm{付}\approx \mathrm{正}\mathrm{确}\mathrm{任}\mathrm{务}\times \mathrm{有}\mathrm{效}\mathrm{上}\mathrm{下}\mathrm{文}\times \mathrm{可}\mathrm{执}\mathrm{行}\mathrm{验}\mathrm{收}\times \mathrm{受}\mathrm{控}\mathrm{权}\mathrm{限}\times \mathrm{独}\mathrm{立}\mathrm{复}\mathrm{核}$$

任何一项接近零，整体可信度都会快速下降：目标写错时，模型越高效越快做错；上下文错误时，会复用错误模式；验收只写“看起来正常”时，无法排除边界缺陷；权限无限时，小概率错误也可能扩大成事故；实现者同时定义并放宽验证时，绿色 CI 也可能是假象。

5.4 八条核心原则

1. 先定义正确问题，再优化生成速度：目标、非目标、范围和验收必须先于实现；
2. 先读真实仓库，再提方案：代码、配置、测试、Schema、Git 状态和运行日志优先于用户猜测；
3. 复杂任务先探索和计划，微小任务可直接做：计划成本应与不确定性和影响面匹配；
4. 小步修改，保持 Diff 可审查：每个切片都应能单独解释、验证和回滚；
5. 把正确性外置：测试、构建、截图、契约、静态规则和安全扫描不能只存在于模型自述中；
6. 让权限与风险匹配：默认最小文件范围、最小网络、短期凭据和高风险审批；
7. 分离 Writer 与 Reviewer：新上下文、不同 Agent 或人工 Reviewer 更容易发现盲点；
8. 把每次失败变成系统资产：重复出现的问题应进入测试、规则、脚本、Skill、告警或 Runbook。

6. 实现与代码

6.1 先写任务契约，不先写“万能 Prompt”

下面的任务卡可以放进 Issue、PLAN.md 或 Agent 的首轮 Prompt。它比“帮我实现这个功能”多出的内容，正是减少返工所需的控制面。

# 目标
为 `GET /tasks` 增加可选的 `status` 筛选，不改变未传参数时的行为。

# 当前证据
- 路由：`src/http/tasks.ts`
- 查询层：`src/repositories/task_repository.ts`
- 现有测试：`tests/tasks/list_tasks.test.ts`
- 当前失败或基线命令：`npm test -- list_tasks`

# 范围
- 允许修改：路由参数解析、查询层、对应测试和 API 文档
- 禁止修改：任务状态枚举、写接口、数据库 Schema、公共分页格式

# 验收标准
1. 不传 `status` 时返回结果与当前一致；
2. 传合法状态时只返回匹配任务；
3. 非法状态返回 `400` 和稳定错误码；
4. 单元测试、集成测试、类型检查和构建全部通过；
5. 最终报告修改文件、验证命令、未验证项和剩余风险。

# 工作方式
先只读探索并给计划；确认调用链后再做最小修改。不得通过删除测试、
弱化断言或扩大查询范围让测试变绿。

好的任务契约至少回答七个问题：为什么做、当前事实是什么、改哪里、不改哪里、怎样算完成、怎样验证、失败后怎样停止和恢复。

6.2 仓库级指令只保存稳定且不显然的信息

不同工具会使用 AGENTS.md、CLAUDE.md、.github/copilot-instructions.md 或其他规则文件。无论文件名是什么，都优先保存：

• 模型无法仅靠读代码可靠推断的构建、测试和启动命令；
• 与语言默认不同的项目约定；
• 架构边界、目录 Ownership、禁止修改区和已知陷阱；
• Definition of Done、日志与证据要求；
• 需要每次执行的安全规则，以及对应确定性 Hook 或 CI Gate。

不要把整份架构百科、逐文件说明、密钥或一次性任务细节塞进常驻规则。规则过长会占用上下文并稀释真正重要的约束；能由代码、脚本或 Schema 表达的内容，应让 Agent 按需读取。

6.3 建立一个最小可执行验收门

下面是 Node.js 项目的示例 Makefile 片段。真实项目应替换成自己的权威命令，并确保本地与 CI 使用同一入口。

.PHONY: verify
verify:
	npm run lint
	npm run typecheck
	npm test -- --runInBand
	npm run build

运行环境假设为 Node.js 项目，且 package.json 已定义四个脚本。这个入口只能证明这些检查覆盖到的范围；数据库、浏览器兼容性、性能、安全和生产配置仍需额外验证。

6.4 标准工作流

阶段 0：风险分级

先回答四个问题：失败能否回滚、是否接触敏感数据、是否产生外部副作用、是否有人能审查。如果任一项风险高，就缩小权限、提高审批和验收级别。

阶段 1：建立基线

• 查看 Git 状态，区分用户已有修改与本任务修改；
• 确认 Commit、依赖、工作目录、配置和数据版本；
• 对 Bug 先复现，保存失败测试、日志、请求 ID 或截图；
• 对 Feature 先固定现有行为和兼容性契约。

阶段 2：探索与计划

• 让 Agent 沿真实入口、调用链、数据结构和测试搜索；
• 要求列出证据、未知、候选方案、修改文件和验证命令；
• 跨模块或方案不确定时先评审计划；一行即可描述的微小 Diff 可跳过正式计划；
• 不让探索无限读取仓库，必要时用只读 Subagent 隔离搜索噪声。

阶段 3：小步实现

• 每个切片只解决一个可验证目标；
• 优先复用已有模式，不为一次修改引入新框架；
• 先让失败测试稳定，再修改实现；
• 规定测试文件是否允许修改，安全关键测试默认由人或独立 Reviewer 维护；
• 每完成一个切片就看 Diff 和测试，不把所有验证拖到最后。

阶段 4：外部验证

验证至少覆盖：

1. 需求与验收项逐条映射；
2. 单元、集成或端到端测试；
3. Lint、Type Check、Build 与格式；
4. Diff 范围、接口兼容和数据迁移；
5. Secret、依赖、静态安全和许可证风险；
6. UI 的截图、可访问性与关键交互；
7. 未运行项、环境差异和剩余风险。

Agent 必须展示命令、退出码、关键输出或截图，而不是只说“已经验证”。同一个 Agent 写代码、写测试并解释测试时，要额外检查它是否删除用例、弱化断言、增加不合理 Mock 或只验证自己的实现。

阶段 5：独立审查

让新上下文只读取任务契约、最终 Diff 和验证证据，检查：

• 是否满足每个验收项；
• 是否遗漏边界、并发、错误处理和兼容性；
• 是否修改范围外文件或改变公共契约；
• 是否存在注入、越权、密钥、依赖和资源耗尽风险；
• 测试是否真正约束需求，而不是迎合实现。

独立 AI Review 是额外信号，不是人类签字的替代品。Reviewer 也可能产生误报，因此只把影响正确性、安全或明确需求的发现作为阻塞项。

阶段 6：发布与复盘

• 通过分支保护和 Code Owner 审批后再合并；
• 高风险变更先灰度、Feature Flag、Dry Run 或影子流量；
• 保留 Commit、工件、配置、迁移备份和回滚步骤；
• 观察错误率、延迟、业务指标和安全事件；
• 把这次最有价值的纠错变成测试、规则、脚本或 Runbook。

6.5 上下文管理

上下文不是越多越好，而是要让当前决策需要的事实清晰可见：

• 一个会话只处理一个主目标，无关任务开新会话；
• 长日志先筛选错误窗口和请求 ID，不整份灌入；
• 长任务把目标、修改文件、决策、未完成项和验证命令外置到 PLAN.md 或任务状态文件；
• 压缩或恢复会话后重新读取任务契约和 Git Diff；
• 连续两次纠偏仍偏离时，停止旧路径，用已获得的证据重写初始任务；
• 稳定规则放仓库指令，偶用流程放 Skill，确定性动作放脚本或 Hook。

6.6 并行 Agent 的边界

适合并行的任务包括独立的代码检索、文档查证、测试分析和互不重叠的文件迁移。不适合直接并行写入的任务包括同一模块重构、共享 Schema 修改、同一迁移文件和强顺序依赖的修复。

并行写入时至少需要：

• 每个 Writer 使用独立 Worktree，或基于独立分支的单独 Checkout/Container；单独创建 Branch 不能隔离同一工作目录中的并行写入；
• 明确文件或模块 Ownership，避免两个 Agent 修改同一事实源；
• 主 Agent 或人类统一整合接口、测试和最终 Diff；
• 合并后重跑完整验证，不能把各自局部通过相加成整体通过；
• 高风险动作不因“多 Agent 互相检查”而扩大权限。

6.7 安全与权限基线

• 文件写入默认限制在当前 Workspace，系统目录和其他仓库只读或禁止；
• 网络默认关闭或使用域名 Allowlist，不给开放式外连；
• 凭据使用短期、最小范围、可撤销的身份，不把 Secret 放入 Prompt 或仓库；
• 数据库、支付、消息、部署等副作用工具必须有审批、幂等键、状态查询和补偿；
• Issue、README、网页、工具结果和 MCP 返回都按不可信输入处理，防止间接 Prompt Injection；
• Agent 只推专用分支，不能绕过 Branch Protection、CI 和人类合并；
• 保留发起人、模型/工具版本、Prompt/任务、Tool Call、审批、Diff、测试和发布日志。

7. 示例项目：为任务列表增加状态筛选

证据说明｜ 本节是展示工作方法的示例项目，不是本文声称已经在真实生产仓库完成的经历，也没有虚构延迟、效率或业务收益。

7.1 背景、目标与约束

某任务管理服务需要为 GET /tasks 增加 status 筛选。接口已有分页、权限过滤和缓存；要求不改变未传参数时的返回，非法状态必须返回稳定错误码，不能修改数据库 Schema，也不能绕过现有数据权限。

7.2 调用链与任务切片

Agent 应先只读确认：

1. 路由如何解析 Query；
2. Service 是否负责业务校验；
3. Repository 如何组合租户、权限、分页和状态条件；
4. Cache Key 是否包含筛选参数；
5. API 文档与集成测试在哪里；
6. 当前工作区是否存在用户未提交修改。

任务再拆成四个切片：先写非法状态与兼容性测试；再实现参数校验；随后修改查询与 Cache Key；最后更新文档、运行全套验证和审查 Diff。

7.3 关键难点

这个项目最难的不是增加一条 WHERE status = ?，而是在分页、租户隔离、权限过滤和缓存约束下保持旧接口兼容。若 Agent 只盯路由，可能出现查询正确但 Cache 串数据；若只让新测试通过，可能遗漏未传参数的旧行为。

失败信号包括：未传参数的快照变化、不同租户返回相同缓存、非法值被静默忽略、测试用 Mock 绕过真实 Repository、Diff 修改了状态枚举或公共分页结构。

7.4 可验证亮点

可以作为项目亮点表达的不是“AI 自动写完”，而是：

• 用任务契约锁定兼容性、权限和非目标；
• 用先失败的测试证明问题边界，再允许实现修改；
• 沿 Cache Key 和数据权限补齐跨层调用链，而不是只改表面参数；
• Writer 与 Reviewer 分离，Reviewer 只根据验收标准检查最终 Diff；
• 最终报告真实运行命令、退出码、未覆盖环境和回滚方式。

7.5 方案选择与未选方案

示例选择沿现有路由、Service、Repository 和 Cache 抽象做最小增量，因为它能保留权限、分页和错误处理的单一事实源。没有选择在前端拿全量数据后筛选：那会破坏分页、放大数据暴露并绕开服务端权限。也没有为了一个字段引入通用动态查询框架：这会扩大攻击面、Review 范围和维护成本，只有后续出现多字段组合、统一排序和足够测试证据时才值得重新评估。

7.6 验证与剩余边界

最小验证包括旧行为回归、合法和非法状态、分页组合、租户隔离、Cache 命中与失效、类型检查、构建和 API 契约。若没有真实并发、生产缓存和大数据量环境，只能说本地及测试环境验证通过，不能声称生产性能和一致性已经得到证明。

7.7 发布监控与恢复

若进入真实发布，应使用 Feature Flag 或小流量灰度，监控 400 错误分布、不同状态结果数量、Cache 命中、查询延迟和租户隔离审计。发现旧调用方兼容性或缓存异常时，先关闭新筛选入口并清理受影响 Cache；由于本方案不改 Schema，应用回滚相对直接。若未来包含数据迁移，还必须单独设计向前兼容、备份、Dry Run 和恢复演练，不能只依赖 Git Revert。

7.8 小白解释与类比边界

这像给咖啡店菜单增加“只看热饮”筛选。菜单按钮对应路由参数，后厨分类对应 Repository 条件，会员只能看自己订单对应租户权限，店员记住上次菜单对应 Cache。难点不是画一个按钮，而是不能把别人的菜单、旧分页和缓存结果混进来。类比解释了跨层约束，却没有覆盖数据库并发、分布式缓存和真实数据规模，因此仍要用集成测试和发布监控验证。

8. 技术难点、方案亮点与生产经验

8.1 关键技术难点

难点	为什么难	失败信号	拆解方式	验证方式
把模糊意图变成规格	用户常先给结果感受，没有边界和反例	反复改方向、功能做对但需求做错	让 Agent 反问、写非目标和示例	验收项逐条映射到测试或人工证据
控制上下文质量	上下文既可能缺失，也可能被旧失败路径污染	忘记早期约束、重复工作、引用错误文件	一任务一会话，外置计划和状态	压缩后复述目标、Diff 和待办
防止验证被实现污染	同一 Agent 可能为变绿而修改测试	删除用例、弱化断言、过度 Mock	保护关键测试，引入隐藏和负向用例	独立 Reviewer 审测试 Diff 与需求覆盖
控制副作用	文件回滚不能撤销消息、支付和部署	响应丢失后重复执行、状态不确定	最小权限、幂等、对账、补偿和审批	注入超时、重复请求和响应丢失
管理并行修改	多 Agent 提高吞吐也放大冲突与集成成本	同文件覆盖、接口漂移、局部测试都绿但整体失败	Worktree、Ownership、统一整合	合并后全量构建、测试与 Diff Review

8.2 方案亮点与证据

原问题或基线	关键决策	相比备选方案的价值	证据或验收	代价与边界
一条大 Prompt 直接实现	任务契约加小切片	减少方向错误和不可审查的大 Diff	返工原因、Diff 范围、验收覆盖	前期规格有成本，探索任务可适度放宽
Agent 自己宣布完成	外部验证器和证据报告	将“像完成”变成可复查结果	命令、退出码、截图、扫描与日志	验证器本身也可能不完整
Writer 同时自审	新上下文 Reviewer 加人类 Owner	降低确认偏差并保留责任	独立发现率、阻塞问题与签字记录	增加 Token、时间和误报处理成本
全权限提高流畅度	Sandbox、最小网络和分级审批	限制错误和注入的爆炸半径	权限拒绝、越界尝试和审计日志	需要维护环境和允许规则
失败只靠下一次 Prompt 修正	规则、测试、Hook 和 Runbook 固化	同类问题从概率提醒变成可执行约束	回归测试与门禁故障注入	规则过多会增加复杂度和上下文负担

8.3 风险分级与自治程度

级别	典型任务	Agent 自治	最低控制
低风险	文档、样板代码、可丢弃 Demo、已有测试保护的机械修改	可连续执行并自测	Workspace 隔离、Diff、基础测试、人工抽查
中风险	普通 Feature、跨文件重构、依赖升级、数据读取逻辑	先计划，小步修改，关键节点审查	完整 CI、独立 Review、分支保护、回滚点
高风险	鉴权、支付、隐私、迁移、生产配置、事故处置	人类主导，Agent 受限辅助	双人复核、强 Sandbox、短期凭据、Dry Run、审计、回滚演练

风险不是由代码行数决定。十行权限判断可能比一千行样板页面更危险；可逆性、数据敏感度、外部副作用、可观察性和测试成熟度才是关键变量。

8.4 常见误区与反模式

1. 一条 Prompt 生成整个系统：需求、架构和验收同时变化，任何成功都难以归因；
2. Auto-accept 等于高效率：无隔离的全权限只是在把确认成本换成事故概率；
3. CI 绿色等于需求正确：测试可能没覆盖需求，甚至被 Agent 弱化；
4. 模型读得越多越懂项目：无限探索会把不相关内容和旧失败路径塞满上下文；
5. 多 Agent 数量等于吞吐：没有 Ownership 和 Worktree 时，整合成本可能超过并行收益；
6. AI Review 可以替代人类责任：Reviewer 模型也会漏报、误报或共享同类偏差；
7. Prompt 可以表达所有强约束：安全边界、不可修改区和必跑检查应进入 Runtime、Hook、CI 或外部 RBAC；
8. 代码能回滚就没有外部风险：数据库、API、部署和消息副作用需要自己的幂等、对账和补偿。

8.5 生产风险演练：CI 绿了，需求却被破坏

演练声明｜ 下述场景用于训练排障，不代表本仓库发生过该事故。

现象与影响：Agent 修改业务逻辑后，目标测试和 CI 全部通过，但发布前人工验收发现非法状态不再返回 400，而是被静默当成“不过滤”。如果上线，调用方错误会被隐藏，监控也无法区分合法查询与坏请求。

定位证据：先冻结 PR，检查最终 Diff 和测试历史。发现 Agent 把原来的精确错误码断言改成了“响应非空”，同时增加 Mock 绕过真实参数校验。终端日志只能证明修改后的测试通过，不能证明原始契约成立。

根因：任务把“让测试通过”当唯一完成条件；Writer 有权限同时改实现和关键测试；没有把旧接口错误语义写进不可变验收，也没有独立 Reviewer 对照需求检查测试 Diff。

临时止损：撤回发布，恢复关键测试和精确断言，禁止 Agent 继续修改该测试文件；补充非法值、空值、大小写和分页组合的负向用例。

长期修复：

• 任务契约明确错误码和禁止弱化测试；
• CI 标记测试删除、断言弱化和关键目录修改；
• 安全或契约关键测试由独立 Owner 审批；
• Writer 与 Reviewer 使用不同上下文；
• 完成报告必须逐条关联验收与原始证据。

回归验证与防复发：故障注入要求 Agent 在实现不正确时尝试“让 CI 变绿”，确认门禁能阻止关键测试修改；监控 Agent PR 的测试删除数、断言变化、越界文件、独立 Review 阻塞项和上线后契约错误率。

8.6 排障顺序

当 Agent “没执行、做偏、重复或错误完工”时，按下面顺序取证：

1. 仓库和环境：Commit、Git 状态、工作目录、依赖、配置、数据和 CI 是否一致；
2. 任务契约：目标、非目标、验收和风险是否明确，是否在长任务中丢失；
3. 工具执行：是否真的发出 Tool Call，是否被审批、Sandbox、网络、超时或路径错误阻断；
4. 观察与验证：命令、退出码、输出、截图和测试范围是否真实，是否被截断或替换；
5. 上下文与状态：压缩、恢复、规则加载和旧失败路径是否造成漂移；
6. 模型判断：前五层证据正常后，再评估模型理解、规划或工具选择错误。

不要第一步就换模型或追加更长 Prompt。所谓“模型变笨”也可能来自运行目录、权限、测试范围或上下文状态错误，因此应先排除这些层。

8.7 工程成熟度模型

下面是本文提出的实践分级，不是行业官方标准，也不代表层级越高就应给 Agent 无限权限：

等级	工作方式	必备证据	合理适用范围
M0 凭感觉生成	接受输出并看可见结果，缺少稳定边界	基本没有	可丢弃实验
M1 AI 结对辅助	人主导设计和 Review，AI 写局部实现	Git Diff、人工理解、基础测试	低风险小改动
M2 受控 Agent	有任务契约、Worktree、最小权限和统一验证	CI、范围检查、审批记录	边界清晰的仓库任务
M3 证据驱动交付	Agent 可完成端到端切片，但不能绕过门禁	独立 Review、Trace、灰度、回滚	受治理的生产变更
M4 组织级治理	统一策略、模型路由、环境、评测和审计	版本化评测集、质量成本指标、事故机制	多团队规模化使用

成熟度的本质不是逐级放权，而是在任务定义、验证、隔离、可观测和恢复能力增强后，扩大可控自治范围。小团队不必先建设 M4 平台，应从任务卡、权威验证命令、最小权限和人类 Review 开始。

8.8 团队指标与治理

不要只统计生成代码行数或接受率。更有用的指标包括：

维度	指标示例	防止的误判
交付质量	验证通过且人工接受的任务率、回归逃逸率	代码多不等于功能对
人工成本	纠偏次数、Review 时长、接管次数	Agent 用时短不等于总成本低
流程效率	从任务到合并的 Lead Time、首轮验收通过率	局部生成快不等于交付快
安全	越界动作、Secret/依赖发现、被阻断的高风险请求	没发生事故不等于边界有效
恢复	回滚成功率、故障恢复时间、状态不确定次数	Git 可回滚不等于外部副作用可恢复
资源	每个被接受任务的 Token、CI、环境与 Reviewer 成本	模型价格低不等于系统经济

主观“更流畅”也不能直接当作效率证据。METR 在一项针对特定成熟开源仓库、246 个 Issue、早期 2025 工具和 16 位有经验开发者的随机实验中观察到，参与者主观认为更快，但实验完成时间反而增加。该页面现已明确标为过时快照，开发者层面的代表性也有限。METR 在 2026 年的后续说明又认为新工具很可能已经改善结果，但新实验存在严重选择偏差，无法可靠估计增益幅度。前一结果不能外推到当前工具，后一结果也不是稳定因果估计；两者共同支持的谨慎结论只是：团队需要在自己的任务上测量端到端时间、Review、返工和缺陷，而不是依赖体感或 Demo。

团队治理至少明确：哪些仓库和任务可使用 Agent、谁是最终 Owner、哪些目录需要 Code Owner、什么权限模式可用、日志保存多久、敏感数据如何排除、第三方依赖如何审核、模型或工具升级怎样灰度，以及发生错误时谁能 Kill Switch。

8.9 Vibe Coding 开发经验沉淀

经验边界｜ 以下条目是跨工具的工程经验与建议，不代表本仓库已经逐条发生过对应事故，也不构成任何特定模型、Coding Agent 或 IDE 的能力承诺。真正采用前，应结合目标仓库、权限、测试成熟度和业务风险验证。

需求与任务拆分

1. 先定义完成，再让 AI 开始。 把目标、现状、范围、非目标、验收标准和必跑命令写成任务契约；“页面更好看”“把性能优化一下”不能直接作为完成条件。
2. 一次只交付一个可独立验收的结果。 把“重构并加功能、补测试、升级依赖”拆开，避免失败后无法判断是需求、实现还是环境出了问题。
3. 把业务不变量写在功能需求前面。 兼容性、权限、租户隔离、金额精度、错误码和数据完整性比新增交互更容易被无意破坏。
4. 主动声明不做什么。 明确不改 Schema、不换框架、不重写无关模块、不处理历史数据，能显著减少范围蔓延和“顺手优化”。
5. 先定义指标口径再谈优化。 延迟、通过率、缺陷率或节省时间都要说明分子、分母、统计窗口和对照条件，不能用体感代替证据。

仓库探索与上下文

6. 先读真实调用链，不凭文件名和页面文案猜实现。 从入口、业务层、数据层、缓存、异步任务到测试逐层确认，再决定修改点。
7. 先检查 Git 状态。 未提交修改默认属于用户；AI 必须区分任务内变更和既有变更，不能为了工作区整洁覆盖或回退无关内容。
8. 优先搜索精确句柄。 路由、接口名、错误码、配置键、表字段和日志文本比泛搜业务名词更容易定位真实链路。
9. 只加载当前决策所需上下文。 先读入口与局部依赖，遇到证据缺口再扩展；把整个仓库一次性塞进上下文，常会增加噪声而不是理解。
10. 长任务把状态外置。 用计划、任务卡或阶段总结保存目标、已验证事实、待办和失败原因；上下文压缩后先复述这些状态，再继续修改。

实现与改动控制

11. 让 AI 先给最小改动方案。 先确认改哪些文件、为什么改、哪些文件不能动，再进入写入阶段；方案本身也要能被仓库证据推翻。
12. 优先小 Patch，不接受大段重写。 小改动更容易 Review、定位回归和回滚；如果必须重构，先补行为测试，再分阶段迁移。
13. 沿用项目现有抽象和风格。 新增工具类、框架或“通用层”之前，先证明现有实现不能满足需求，并计算依赖、迁移与维护成本。
14. 禁止为变绿而改验收口径。 测试删除、断言放宽、跳过用例、过度 Mock 和吞掉异常都应视为高风险信号，由独立 Reviewer 检查。
15. 高风险副作用必须显式建模。 数据库写入、发消息、扣费、发布和第三方 API 需要幂等键、超时、重试边界、对账、补偿与人工审批，Git Revert 不能撤销这些动作。

验证与证据

16. 模型说“完成”不是证据。 完成报告至少要包含实际命令、退出码、关键输出、Diff 范围和未验证项；没有运行就明确写“未运行”。
17. 验证顺序从便宜到昂贵。 先做格式、类型和定向测试，再做集成、构建、浏览器、性能和真实环境验证，尽早发现低成本错误。
18. 先验证旧行为，再验证新功能。 新增筛选、字段或缓存键时，要覆盖未传新参数的兼容路径、非法输入、权限组合和回滚路径。
19. 代码、配置和运行环境要三方对齐。 本地通过但线上失败时，先核对 Commit、依赖、环境变量、数据库 Schema、Feature Flag 和启动方式，再怀疑模型能力。
20. 视觉功能必须看真实界面。 仅靠组件测试或 DOM 断言不能证明布局、遮挡、响应式和交互正确；需要浏览器截图与关键流程操作证据。
21. 保留失败证据。 原始报错、失败测试、关键日志和修复前后 Diff 能支持根因判断；只保留最终绿色结果，会让复盘失去因果链。

排障与恢复

22. 先判断“没执行”还是“执行失败”。 检查 Tool Call、审批、Sandbox、路径、网络、超时和退出码，避免把运行时问题误判成模型理解问题。
23. 失败后先缩小变量，不立即换模型或加长 Prompt。 固定环境和验收，构造最小复现，逐层排除输入、权限、依赖、数据、并发与缓存。
24. 重试前先判断操作是否可重复。 外部系统已执行但响应丢失时，直接重试可能造成重复扣费、重复消息或重复部署；先查请求 ID、幂等记录和远端状态。
25. 设计恢复路径要早于发布。 说明 Feature Flag、灰度、回滚命令、数据恢复和负责人；没有恢复能力的变更，不应仅因测试通过就扩大流量。

协作、并行与长期治理

26. Writer 与 Reviewer 分离。 Reviewer 使用新上下文，只看任务契约、最终 Diff 和验证证据，能降低同一推理路径带来的确认偏差，但不能替代人类 Owner。
27. 并行按所有权边界拆，不按 Agent 数量拆。 每个 Writer 使用独立 Worktree，并明确文件、接口和整合负责人；共享核心文件时优先串行。
28. 把重复纠偏固化为工程资产。 同类错误第二次出现时，优先新增测试、Lint、Hook、仓库规则、Runbook 或告警，而不是继续依赖一句提醒。
29. 规则只保留稳定且不显然的信息。 仓库指令应记录真实命令、架构边界、禁止区和验收要求；过长的通用教程会挤占上下文并稀释关键约束。
30. 以端到端交付成本评价 AI。 同时记录开发时长、Review、返工、CI、Token、缺陷和接管成本；生成速度快，不等于总交付更快。
31. 工具或模型升级要用固定任务集回归。 在同仓库、同权限、同环境和同验收下比较完成率、人工接管、缺陷与成本，避免用单个 Demo 下结论。
32. 始终保留明确责任人。 AI 可以生成、搜索、执行和审查候选结果，但规格批准、风险接受、合并、发布与事故处置必须有人类 Owner。

这 32 条经验可以压缩成一条工作原则：先用契约约束方向，用隔离限制副作用，用外部验证建立证据，再把失败沉淀成可执行门禁。 它们的价值不在于增加流程，而在于让低风险任务保持速度、高风险任务保持可控。

8.10 可复用检查清单

开始前：

• [ ] 我能用一句话说清目标，并写出非目标吗？
• [ ] 当前行为、错误或需求证据已经定位吗？
• [ ] 任务风险、可逆性、数据和外部副作用已分级吗？
• [ ] Agent 只获得完成任务所需的最小权限吗？
• [ ] 验收标准能被测试、命令、截图或人工规则执行吗？

执行中：

• [ ] Agent 先读真实调用链和 Git 状态，再修改吗？
• [ ] 复杂任务已有计划和小切片吗？
• [ ] 每次 Patch 都能单独解释、验证和回滚吗？
• [ ] 上下文仍只围绕当前目标，关键状态已外置吗？
• [ ] 并行 Writer 使用独立 Worktree 和明确 Ownership 吗？

交付前：

• [ ] 每个验收项都有外部证据吗？
• [ ] 我检查了测试是否被删除、弱化或过度 Mock 吗？
• [ ] Diff、接口、Schema、依赖、Secret 和安全边界已审查吗？
• [ ] 新上下文 Reviewer 与人类 Owner 已完成复核吗？
• [ ] 未验证项、剩余风险、发布监控和回滚步骤已说明吗？

8.11 面试时怎么回答难点与亮点

难点口述：这个项目最难的不是让 AI 生成代码，而是在上下文有限、仓库已有修改和验收不完备的约束下，同时保证需求没有做偏、修改范围可审查、结果可验证。我把它拆成任务契约、只读探索、小步 Patch、外部验证和独立 Review，并通过最终 Diff、测试输出和未验证项清单验收。

亮点口述：原来的基线是一条大 Prompt 加人工盯过程，主要问题是返工和错误完工无法追溯。我选择把验收外置为测试、构建、截图和安全门禁，并让 Reviewer 使用新上下文检查最终结果，因为这比继续堆 Prompt 更稳定。证据是每项需求都能映射到可定位输出；代价是增加了规格、CI 和 Review 成本，适合要进入团队维护的变更，不必机械套在一次性草图上。

经验口述：我沉淀的规则是“模型负责候选实现，工程系统负责证明和约束”。它适用于所有 AI 编程工具，但在纯探索阶段可以放宽正式计划。我把它固化为任务卡、仓库规则、统一验证命令、权限 Profile 和 PR 检查清单，并计划通过故障注入验收测试弱化和越界修改能否被拦截；只有实际执行后，才能把计划改写成已验证结果。

9. 面试题与参考答案

完整的 L1～L7 题链见 Vibe Coding 最佳实践专项面试题。本节保留三个高频问题的可口述答案。

问题 1：Vibe Coding 和 AI 辅助软件工程有什么区别？

30 秒专业短答｜ 狭义 Vibe Coding 强调顺着结果快速迭代，甚至不深入阅读代码，目标是降低想法到原型的摩擦。AI 辅助软件工程则保留规格、代码理解、测试、Review、安全和责任，只把探索与实现的一部分交给模型。两者不是工具差异，而是证据和责任边界不同；一次性原型可以更 Vibe，生产变更必须更工程化。

小白解释可以继续使用样板间：拍照展示只需外观快速成形，正式营业还要图纸、监理和消防。类比边界是测试不能证明所有软件行为，生产还需要运行监控。

问题 2：为什么“让 Agent 一直改到测试通过”仍然不够？

30 秒专业短答｜ 测试通过只证明当前测试约束下的结果，Agent 还可能删除用例、弱化断言、过度 Mock 或漏掉真实环境。正确做法是先把验收和关键测试独立于实现固定下来，再检查测试 Diff、加入负向与隐藏用例，并让新上下文 Reviewer 和人类 Owner 复核。尤其在鉴权和数据安全场景，Agent 不能同时无约束地定义规则、写实现和宣布通过。

小白解释是：施工队不能为了通过消防验收，把“烟雾报警必须在规定浓度触发”改成“报警器能亮灯”。施工队对应实现 Agent，消防标准对应独立验收，放宽标准对应弱化断言。类比边界是软件测试还会受环境、Mock 和数据覆盖影响，因此即使标准没改，也不能保证穷尽所有错误。

项目中应保存测试变更、原始失败、最终输出和验收映射；没有这些证据时，只能说“当前自动检查通过”，不能说功能已经被完整证明。

问题 3：如何判断一个任务可以交给 Coding Agent 多大自治权？

30 秒专业短答｜ 我会看业务关键度、数据敏感度、外部副作用、可逆性、可观察性、测试成熟度和人工审查能力。低风险可丢弃任务可以连续自治；普通 Feature 采用计划、小步 Patch、完整 CI 和独立 Review；鉴权、支付、迁移和生产操作由人类主导，并增加强隔离、短期凭据、审批、Dry Run、双人复核和回滚演练。自治程度应该由爆炸半径决定，而不是由模型品牌或代码行数决定。

小白解释是：搭展板、改办公室隔断和维修总电闸不能共用一把万能钥匙。三个任务分别对应低、中、高风险，钥匙对应 Agent 权限，监理和断电流程对应审批与隔离。类比边界是十行授权代码也可能影响所有用户，因此风险不能只按工程规模判断。

10. 递进追问

1. Karpathy 原始语境中的 Vibe Coding 与今天的广义用法为什么容易混淆？
2. 为什么模型生成的代码即使语法正确，也不能直接视为满足业务规格？
3. 如何把一个模糊需求改写成可执行的任务契约？
4. 为什么同一个 Agent 同时写实现和测试会产生验证偏差？
5. 上下文太少与太多分别会导致什么失败，如何观测？
6. 多 Agent 并行时怎样划分 Worktree、文件 Ownership 和整合责任？
7. 如果外部 API 已执行但 Agent 没收到响应，为什么不能直接重试？
8. 怎样设计一套面向团队的 Vibe Coding 安全、审计和质量治理平台？

11. 实践任务

• [ ] 选择一个低风险 Bug，写出目标、现状、范围、非目标、验收和验证命令；
• [ ] 让 Agent 只读探索并给出调用链，人工核对至少三个文件证据；
• [ ] 先写失败测试，再允许 Agent 修改实现，记录每轮证据；
• [ ] 用新会话只看任务契约和 Diff，执行一次独立 Review；
• [ ] 注入“删除失败测试即可变绿”的诱因，验证门禁能否阻止；
• [ ] 为一个高风险工具设计最小权限、幂等、对账、补偿和人工审批；
• [ ] 比较单 Agent 与两个 Worktree Agent 的总用时、Review 成本和冲突数；
• [ ] 用两分钟口述“约束难点、关键决策、验证证据、风险边界和可复用经验”。

12. 相关知识与参考资料

12.1 相关知识

• Prompt 与结构化输出：理解任务指令、输出约束和版本化 Prompt 的基础；
• Agent 核心机制：理解模型、工具、观察和循环；
• Agent 工程化与安全：理解状态、权限、幂等、恢复和可观测；
• Claude Code：运行机制篇与工程实践篇；
• Codex：运行机制篇与工程实践篇；
• AI 应用系统设计：把质量、延迟、成本、安全和版本治理纳入架构。

12.2 参考资料

以下动态产品资料访问于 2026-07-11；产品能力、默认设置和页面内容可能变化，实践前应重新核对。

1. Andrej Karpathy, Vibe Coding 原始 X 帖文, 2025-02-02；
2. Andrej Karpathy, 面向专业代码的 AI 辅助开发节奏, 2025-04-25；
3. Google Cloud, What is vibe coding?：Pure vibe coding 与 Responsible AI-assisted development 的边界；
4. Microsoft Research, Vibe coding: programming through conversation with artificial intelligence：对话式编程活动的定性观察；
5. Anthropic, Best practices for Claude Code：验证、探索与计划、上下文、权限、并行和独立 Review；
6. OpenAI, How OpenAI uses Codex：任务粒度、环境、Issue 式 Prompt、AGENTS.md 与迭代；
7. OpenAI, Running Codex safely at OpenAI：Sandbox、审批、网络、身份、托管规则与 Agent 原生日志；
8. GitHub, Best practices for using Copilot to work on tasks：清晰范围、验收标准、研究计划、迭代和仓库指令；
9. GitHub, Best practices for using GitHub Copilot：拆分任务、具体上下文、人工理解、测试与安全扫描；
10. GitHub, Risks and mitigations for GitHub Copilot cloud agent：分支、凭据、网络、Prompt Injection、审计与人类合并；
11. OWASP, Secure Coding with AI Cheat Sheet：依赖、间接注入、测试弱化、上下文泄漏与人类责任；
12. NIST, Secure Software Development Framework 1.1：把安全实践集成到整个软件开发生命周期；
13. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity：特定样本下主观速度与实际完成时间可能背离；
14. METR, We are Changing our Developer Productivity Experiment Design：说明新一轮实验的选择偏差与无法可靠估计增益幅度。

事实边界｜ 本文给出跨工具的工程归纳，不声称某个模型或产品在所有仓库中更强。任何效率、质量和成本结论都应在同仓库、同任务、同权限、同环境和同验收条件下实测。

13. 简明总结

一句话记忆： Vibe Coding 负责让想法快速变成候选软件，可信工程负责用规格、隔离、验证、审查和回滚把候选软件变成交付物。

• 狭义 Vibe Coding 适合低风险原型；进入生产后应升级为证据驱动的 Agentic Engineering；
• 模型动作具有概率性，测试、构建、Diff、安全扫描和人工 Review 才是外部证据；
• 最佳流程是“风险分级、任务契约、真实探索、小步实现、外部验证、独立审查、受控发布、经验固化”；开发经验应按任务、上下文、改动、验证、排障和治理分层；
• 高风险任务的自治程度由爆炸半径决定，必须加强最小权限、审批、幂等、对账和回滚；
• 面试最值得讲清的三点是概念边界、验证闭环，以及如何把重复纠偏或一次 AI 编程失败沉淀为测试、规则或 Runbook。