L12. 第一次评审 (Spec Review)：来自 CTO 的拷问
Vibe Coding 宣言：与其被用户骂，不如先被 AI 骂。
0. 为什么这一课至关重要？ (Why It Matters)
- 查漏补缺：你的脑子只有一颗 CPU，AI 有一万颗。它能看到你看不见的死角。
- 免费的专家：以前你要请个技术大牛帮你 Review 方案得花大价钱，现在全免费。
- 信心加倍：经过 AI 严刑拷打后的方案，写起来才不会心虚。
1. 目标 (Goal)
学会让 Claude 扮演 CTO (首席技术官)，对你的 Spec 进行 Review (评审)，找出逻辑漏洞和风险点。
2. 核心概念/装备/指令 (The Core)
2.1 角色扮演 (Role Play)
Claude 是个戏精。你要给它设定人设：
- 严厉的 CTO：只看逻辑漏洞和安全隐患。
- 挑剔的产品经理：只看用户体验流程通不通。
- 资深架构师：只看数据库设计和扩展性。
2.2 评审维度 (The Dimensions)
- 完整性：有没有漏掉核心功能？
- 可行性：技术上能不能实现？成本高不高？
- 安全性：有没有 SQL 注入？Key 有没有泄露？
- 健壮性：异常情况处理了吗？
3. 实战演练 (Action)
Step 1: 提交 Spec
把你之前写的 spec.md (包含 User Story, 流程图, 数据库, API) 全部喂给 Claude。
Step 2: 发起评审
输入以下 Prompt：
markdown
# Context
这是我设计的[比价系统]的技术方案 (Spec)。
# Task
请你扮演一位严厉的资深 CTO，对这份方案进行 Code Review 级别的评审。
请毫不留情地指出其中的：
1. 逻辑漏洞 (Logical Flaws)
2. 安全隐患 (Security Risks)
3. 数据库设计的不合理之处 (Schema Issues)
4. 遗漏的异常情况 (Missing Edge Cases)
# Output
请列出问题清单，并给出修改建议。Step 3: 修改与迭代
Claude 可能会说：“你的爬虫没有考虑反爬策略，IP 被封了整个系统就挂了。” 这时候你要去修改你的 Spec，加上代理池的设计，或者降低抓取频率。 改完后再让它审一次，直到它说“看起来不错”。
4. 常见问题 (FAQ - Vibe Style)
Q: Claude 提的问题太难改怎么办？ A: 权衡 (Trade-off)。 如果它是对的但成本太高，你可以说“这个版本先不修，标记为 Known Issue (已知问题)”。
Q: 它说我的方案完美无缺？ A: 不可能！ 要么你给的信息太少，要么它在敷衍你。追问它：“如果要支持 10 万并发，这个方案哪里会先挂？”
Q: Spec Review 要多久？ A: 半小时足矣。 主要是为了发现致命伤。别纠结细节。
5. 验收标准 (Definition of Done)
- 你有一份经过 AI 评审的
spec_v2.md。 - 你知道你的系统哪里最脆弱。
- 模块二结业：你现在手里拿着一份连 CTO 都点头的施工图纸。
Next Mission: L13. 测试驱动开发 (TDD) 入门：先画靶子再射箭