1. 背景信息

核心问题：如何在生产环境中"负责任地"进行 Vibe Coding（氛围编程）。

具体来说，关于以下几个层面的问题：

• AI 能力指数级增长与人类审查能力不匹配的矛盾：AI 能独立处理的任务长度大约每7个月翻一倍，但人类工程师若坚持逐行审查代码，将成为算力爆发的瓶颈。

• AI Agent 的结构性缺陷：Agent 倾向于在一个会话里完成所有功能，导致留下半成品代码、没有记录、过早宣布完成等问题。

• “信任债务”（Trust Debt）：AI 会填补指令中的空白进行"自信的即兴发挥"，这些未被审计的假设会在未来某个时刻爆发。

• 技术债难以验证：除了通读源码，极难通过系统化手段衡量或验证技术债。

• 传统软件工程体系与 AI 编码时代的脱节：Code Review、架构规范、文档维护等实践都假设人类是代码创作者，当 Agent 一天生成几百个 PR 时，这些假设全部崩塌。

---

2. 解决方案与策略

核心理念：Vibe Coding 不是让 AI 写代码，而是建立一套"可验证的抽象层"来管理 AI 编码。

具体解决方案包括：

• “忘记代码的存在，但不要忘记产品的存在”：不深入每一行代码，而是通过更高层级的抽象来验证 AI 的输出。

• "叶子节点"策略：将 AI 的修改严格限制在不被其他模块依赖的末端功能上，核心架构仍由人类把控。

• 做 AI 的"产品经理"：转换思维，像带教新员工一样为 AI 提供详尽的上下文、需求和限制条件，而非简单地抛出功能指令。

• 建立可验证的检查点：通过验收测试、压力测试、人类可读的输入输出标准来验证系统。

• 拥抱指数级增长：提前适应 AI 能力远超人类审查能力的未来，建立与之匹配的工程范式。

---

3. 核心方法/步骤/策略

策略一：寻找可验证的抽象层

借鉴管理层验证专家工作的方式：

• CTO → 验收测试
• 产品经理 → 使用产品验证
• CEO → 抽查关键数据

策略二："叶子节点"策略

• 聚焦 Leaf Nodes：代码库中不被其他模块依赖的末端功能或附加组件
• 核心架构人工保护：系统主干与底层架构部分，工程师仍需深入理解并严密保护其可扩展性
• 动态边界：随着模型能力提升，AI 可接管的代码层级正在向下延伸

策略三：产品经理式引导

标准前置工作流：

1. 花 15-20 分钟与 AI 互动
2. 让 AI 探索代码库、查找相关文件
3. 共同制定清晰的执行计划
4. 将上下文和规范汇入单独提示词
5. 让 AI 执行

策略四：测试驱动与验证

• 强制规范 AI 写极简的端到端（E2E）测试
• 只关注：快乐路径（happy path）、错误场景 1、错误场景 2
• 测试过关才认为靠谱

策略五：上下文管理

• 在"人类程序员会停下来吃午饭"的停顿点时进行上下文压缩（Compact）
• 先让 AI 制定计划并写入文档，然后立即压缩，丢掉耗费的大量 Token

---

4. 实例分析参考

实例一：Erik Schluntz 的"全自动化办公"经历

• 背景：Erik 摔断手、打了两个月石膏，工作不能停
• 做法：全权交给 Claude 处理
• 结果：成功维持了工作产出

实例二：Anthropic 内部 22,000 行代码生产环境合并

• 任务描述：在强化学习（RL）代码库的生产环境中合并大规模修改
• 代码规模：+22,160 行，-0 行（纯新增）
• 所用模型：Claude（Anthropic 内部测试的新版模型）
• 核心策略：
  1. 耗费数天时间进行前期人工规划与需求梳理
  2. 将代码变更严格限制在"叶子节点"
  3. 核心逻辑执行严格的人工审查
  4. 设计长时间压力测试确保稳定性
  5. 确保系统具备人类可验证的输入输出标准
• 实验结果：原本需要人类工程师两周时间的工作，被压缩到 1 天内完成

实例三：AI 能力增长数据（METR 研究）

• 数据来源：metr.org
• 关键发现：AI 能独立处理的任务长度大约每 7 个月翻一倍
• 具体数据点：
  • GPT-2（~2019）：接近 0 秒
  • GPT-4（2023年11月）：约 5-10 分钟
  • GPT-4o（2024年中）：约 10 分钟
  • o1 preview：约 15 分钟
  • Sonnet 3.5：约 15 分钟
  • Sonnet 3.6：约 30 分钟
  • o1：约 40 分钟
  • Sonnet 3.7：约 1 小时

---

5. 结论

• Vibe Coding 的本质：不是重度使用 AI 工具生成代码，而是"完全沉浸于氛围，拥抱技术发展的指数级增长，并且彻底忘记代码的存在"（Andrej Karpathy 定义）。

• 工程师角色的转变：从"代码创作者"转变为"AI 的产品经理"，核心能力从写代码转向提出正确的问题、提供正确的上下文、建立可验证的抽象层。

• 未来趋势：AI 能力呈指数级增长，工程师必须提前建立与之匹配的工程范式，否则将成为瓶颈。

• 学习方式的转变：借助 AI 可以大大加快学习新事物的速度，进行更多次"试错"，在同样自然时间里学到四倍的经验教训。

• 工具协同：Claude Code 用于主要修改，VS Code/Cursor 用于边走边审查，多工具协同是最佳实践。

---

6. 限制条件

技术限制

• 技术债的可扩展性无法验证：除了通读源码，极难系统化衡量技术债
• 核心架构仍需人工理解：系统主干与底层架构部分不能交给 AI
• 上下文长度限制：长时间会话后 AI 容易"脱轨"，需要定期压缩上下文

安全与风险限制

• 生产环境风险：非专业人士将 Vibe Coding 搬入生产环境，可能导致耗尽 API 额度、绕过订阅验证、随意篡改数据库、API 密钥泄漏等
• 安全前提：需要懂行的人知道什么是危险的、什么是安全的；完全离线运行的任务更安全
• 缺乏"数学证明级别正确无误"的工具：目前缺少能锁死后端关键部分、只留前端沙盒的安全框架

人员能力限制

• 需要懂行的产品经理：不懂代码的人做出的应用存在严重漏洞
• 需要能提出正确问题的人：懒惰的人会蒙混过关，只有愿意投入时间学习的人才能用好 AI
• 不能过度约束模型：不对模型施加过度约束时，它们表现最好

模型能力限制

• 当前边界：AI 生成优质架构的成功率正在提升，但尚未完全可靠
• 测试陷阱：Claude 容易写出过度依赖具体实现的"死胡同测试"，需要人工引导写极简的端到端测试

适用范围限制

• 叶子节点优先：AI 修改应主要限制在不被其他模块依赖的末端功能
• 低风险场景更适合：个人游戏、玩具项目、完全离线任务更适合 Vibe Coding

---

采访问题

序号	问题	核心回答要点
Q1	如何在 AI 时代学习？如何积累知识做好 Agent 的产品经理？	1. 痛苦的底层学习不再必要，如同不用手写汇编 2. AI 加速学习：随时问 Claude 库/技术细节 3. 更多试错机会：2年→6个月验证架构，4倍经验积累
Q2	预先规划时如何平衡信息量？有无标准模板？	1. 取决于关注程度：不关心实现只给需求；熟悉则深入到类级别 2. 不对模型过度约束时表现最好 3. 不建议严苛格式模板，像带教初级工程师一样沟通
Q3	如何平衡有效性与网络安全？不懂代码的人做出漏洞怎么办？	1. 核心：做好 PM，懂行才能分辨危险与安全 2. 漏洞多来自完全不懂代码的人，玩具项目无妨 3. 生产系统需正确引导；22k 行案例因完全离线故安全
Q4	如何让普通人易构建软件又避免 API 密钥泄漏等安全问题？产品需如何改变？	1. 需要"数学证明级别正确无误（provably correct）"的框架 2. 理想模式：后端锁死认证/支付，前端留沙盒 Vibe Code 3. Claude Artifacts 是现有安全例子（仅前端，无权限/支付）
Q5	TDD 有什么技巧？Claude 容易在测试里越陷越深怎么办？	1. TDD 极其有用，帮助 Claude 自洽 2. 问题：Claude 写"死胡同测试"（过度依赖实现） 3. 强制规范：只写 3 个 E2E 测试（happy path + 2 错误场景） 4. 个人实践：Vibe Coding 时唯一看的代码就是测试代码
Q6	"拥抱指数级增长"意味着什么？模型会在每个维度都变好吗？	1. 不仅是持续变好，而是变好速度远超想象 2. 类比：90 年代几 KB → 今天 TB，好了数百万倍 3. 不该想"20 年后好两倍"，而应想"聪明一百万倍会怎样"
Q7	终端（Claude Code）和 VS Code/Cursor 用哪个？多久压缩一次上下文？	1. 两边都用：Claude Code 做主要修改，VS Code 审查代码/测试 2. 压缩时机："人类程序员停下来吃午饭"的停顿点 3. 起手式：先探索→制定计划→写入文档→立即压缩（10万 Token → 几千 Token）
Q8	会同时用多个 Claude Code 会话合并结果吗？面对陌生代码库如何工程化交 PR？	1. 多工具协同：Claude Code 搭框架 + Cursor 收尾修复，已知位置直接手动改 2. 陌生代码库：先探索（问 Auth 代码位置、类似功能、相关类）→ 建立全局视图 → 再动手