专题 F：AI 编程实战指南
补充专题 | PM 必读的 AI 编程认知
作为产品经理，你不需要亲自写代码。但你需要理解 AI 编程能做什么、不能做什么、怎么做——因为你的工作产出（PRD、需求文档）正在成为 AI 的直接执行规范。
这个专题整理了当前关于 AI 编程最重要的四篇行业文章的核心观点，帮你建立完整的认知框架。
一、Vibe Coding 的真相
"Vibe Coding"是 OpenAI 联合创始人 Andrej Karpathy 在 2025 年初提出的概念。他描述了这样一种工作方式：用语音和 AI 对话，描述想要什么，AI 生成代码，不仔细看差异就直接全部接受，遇到报错就把错误信息贴回去让 AI 自己修。
Karpathy 说："对于一次性的周末项目来说还不错……我只是看东西、说东西、运行东西，它大部分时候都能工作。"
Vibe Coding 到底是什么
Vibe Coding 不是所有 AI 辅助编程的总称。它是一种特定的、极端的方式：主要依赖 LLM 构建软件，且把代码审查明显后置。
普通的 AI 辅助开发中，你用 Copilot 或 Claude Code 生成代码，但你仍然会审查、测试、集成。Vibe Coding 把这个审查步骤大幅削减了——你更像一个提示给予者和测试者，AI 完成大部分编码。
什么时候可以用 Vibe Coding
- 低风险项目和原型：快速验证一个想法，不需要关心长期维护
- 探索性编程：就像传统的"写一个扔掉"的原型，只是更快了
- 个人工具：给自己用的小工具，出 bug 不影响他人
- 学习实验：想看看 AI 能做到什么程度
什么时候绝对不能用
- 生产环境的代码：面向真实用户的产品，任何 bug 都可能造成损失
- 涉及安全、支付、隐私的功能：这些领域容错率为零
- 需要长期维护的核心系统：如果你不理解代码，出问题时无法修复
- 团队协作项目：你不能把你自己都不理解的代码交给同事
一句话总结：Vibe Coding 是原型阶段的加速器，不是产品开发的方法论。Demo 和 Product 之间的差距，就是你审查、测试、理解的深度。
二、70% vs 30%：AI 能做什么，你必须做什么
Addy Osmani（Google 工程师）提出了一个关键观察：AI 能搞定大约 70% 的编码工作，但剩下的 30% 决定了产品的成败。
AI 擅长的那 70%
- 生成样板代码、常规功能实现
- 处理软件的"偶然复杂性"——重复性、机械性的编码工作
- 快速产出第一版可运行的方案
- 写测试、修 bug（在明确指导下）
你必须搞定的那 30%
| 能力 | 为什么 AI 做不了 | PM 的角色 |
|---|---|---|
| 系统设计和架构 | AI 不会为复杂问题选择最佳架构，它只重新组合已知模式 | 理解高层设计，确保架构符合产品方向 |
| 边界情况和模糊性 | AI 默认处理一般情况，不主动考虑异常输入和竞态条件 | 在 PRD 中明确所有边界情况 |
| 理解和维护上下文 | AI 不了解项目历史、决策理由、业务约束 | 你是"上下文承载者"，确保 AI 的输出符合实际 |
| 代码审查和质量判断 | AI 输出表面合理但可能有隐藏缺陷 | 验证结果，把住质量关 |
| 创造性判断 | AI 不会发明新的抽象或策略 | 决定什么值得做、做到什么程度算够 |
Osmani 的结论：AI 是力量倍增器，不是替代品。它放大的，是你的产品判断力和工程素养。 在 AI 时代，强大的产品技能比以往任何时候都更有价值——因为只有拥有专业判断力的人，才能有效利用 AI 的力量。
三、如何为 Coding Agent 写好规范
这是最直接与你相关的一节。你在第二章学到的 PRD 方法，在 AI 编程场景下有一个专门的延伸——为 Coding Agent 写规范。
核心原则：说清楚"如何做"，而不仅仅是"做什么"
把 Agent 理解成一位需要明确上下文的编码搭档。简单任务直接描述目标就够了；任务一旦复杂，从一开始就把你偏好的做法讲清楚。
不好的规范："添加单元测试"
好的规范："添加单元测试，重点覆盖：空输入、超长输入、快速重复点击、网络请求失败时的降级处理。使用 Jest 框架，测试文件放在 tests/ 目录下。"
规范应该包含六个部分
- 命令：项目怎么构建、怎么运行测试——完整的命令（如
npm test、npm run build） - 测试：用什么框架、测试文件放哪里、覆盖率期望
- 项目结构：哪个目录放什么——"
src/放应用代码，tests/放测试，docs/放文档" - 代码风格：命名约定、格式规则——一个实际的代码示例比三段描述文字更有用
- Git 工作流：分支命名、提交消息格式、PR 要求
- 边界：Agent 绝对不能碰的东西——密钥、生产配置、特定文件夹
规范应该先写后做
和你在第 5 课学到的"方案先行"一样——先让 Agent 输出技术方案，确认后再写代码。修改方案比修改代码成本低得多。
帮我做一个待办清单应用。
门控工作流：把规范变成流程
GitHub 的 AI 团队推广了一套四阶段工作流：
- 指定：你描述"构建什么、为什么构建"，Agent 生成详细规范
- 规划：你提供技术栈和约束，Agent 生成技术方案
- 任务：Agent 把方案拆解为可独立实现和测试的小任务
- 实现：Agent 逐个完成任务，你逐个审查
你的角色：在每个阶段验证。规范是否符合你的意图？方案是否考虑了约束？任务拆解是否合理？在规范验证通过之前，不让 Agent 进入下一阶段。
四、AI 加速产品探索
Cagan 写《启示录》的时候，原型需要设计师和开发者的协作。现在，AI 让 PM 可以独立完成从想法到可交互原型的全流程。
AI 对探索阶段的改变
速度大幅提高。 过去"做原型 → 测试 → 调整"一轮可能需要一周，现在可能只需要一天。你可以在一次用户访谈结束后，当场修改原型，立刻给下一个人测试。
可以探索更多方案。 过去因为成本限制只能试 2 个方向，现在可以试 5 个。更多样化的探索意味着更高的概率找到正确的方向。
但要警惕"原型很美，产品很难"。 AI 生成的原型看起来很好——但实际开发可能涉及复杂的后端逻辑、数据迁移、性能优化。原型验证的是"用户是否需要这个"，不是"技术上是否容易实现"。
PM 可用的 AI 工具速览
| 工具 | 适合做什么 | 不适合做什么 |
|---|---|---|
| v0 / Lovable | 快速生成前端 UI 原型，适合验证交互体验 | 复杂后端逻辑、数据库设计 |
| Replit | 全栈快速原型，前后端+部署一条龙 | 需要精细化控制的企业级应用 |
| Claude Code / Cursor | 在已有代码库中开发功能、修 bug、写测试 | 从零开始的全站构建（需要先有架构） |
| Bolt / Tempo Labs | 设计稿转代码、可视化编程 | 复杂业务逻辑 |
本专题小结
AI 编程时代，PM 和代码的关系变了——你不再只是"写需求的那个人"，你的 PRD 正在成为 AI 的直接执行规范。理解 AI 能做什么、不能做什么、怎么做，不是"开发的事"，是你的事。
四个核心认知：
- Vibe Coding 是原型的加速器，不是产品的方法论——能在几小时内验证想法，但不能把 vibe-coded 的代码直接上线
- AI 搞定 70%，你必须搞定关键的 30%——产品判断、架构决策、边界情况、质量审查
- 规范的质量决定输出的质量——你写得越清楚，AI 做得越准
- AI 让你的探索速度快了 10 倍——但探索的目的没变：用最小成本验证核心假设