读懂代码
你将学到什么
- 如何在 5 分钟内读懂一个 PR 的改动范围和风险
- 如何读懂 API 文档并判断对接可行性
- 如何快速扫描技术方案文档并提出有价值的问题
为什么重要：PM 不需要写代码，但必须能读懂改动的影响范围，才能做好需求验收和风险把控。
一、读 PR Diff（5分钟掌握）
Pull Request 是工程师提交代码改动的地方。你需要能看懂变更的范围和意图，不需要理解具体实现。
Diff 语法速查
diff
- 红色行（减号）：被删除的代码
+ 绿色行（加号）：新增的代码
灰色行：未变化的上下文PM 读 PR 的三个核心问题
问题 1：改动了哪些文件？
文件路径透露关键信息：
| 文件路径 | 含义 | PM 关注点 |
|---|---|---|
api/ 或 routes/ | 接口层改动 | 可能影响前端调用，需确认接口文档是否更新 |
components/ 或 pages/ | 前端 UI 改动 | 需要验收视觉和交互 |
config/ 或 .env | 配置改动 | 注意环境差异（开发/测试/生产） |
prompts/ 或 system_prompt | Prompt 改动 | AI 行为会变，需要回归测试 |
migrations/ 或 .sql | 数据库变更 | 高风险，需确认数据兼容性 |
问题 2：这个改动和我的需求对齐吗？
不需要看懂代码逻辑，只需确认：
- ✅ 新增的接口名称/参数是否符合你在 PRD 里写的
- ✅ 删除的代码是否是你说要下掉的功能
- ✅ 改动的配置是否和你预期的一致
问题 3：有没有意外的副作用？
关注以下风险信号：
| 风险信号 | 含义 | PM 应对 |
|---|---|---|
| 改动了公共函数（被多处调用） | 影响范围大 | 要求工程师说明影响范围和测试覆盖 |
| 删除了大量代码而不是修改 | 可能是重构 | 确认功能不受影响，回归测试 |
| 修改了数据库 Schema | 数据结构变更 | 关注数据迁移方案和回滚策略 |
| 改动了认证/权限相关代码 | 安全风险 | 需要安全测试，确认不会误开权限 |
实战示例
diff
// api/chat.py
- def call_model(prompt: str) -> str:
- return openai_client.complete(prompt)
+ def call_model(prompt: str, temperature: float = 0.7) -> str:
+ return openai_client.complete(prompt, temperature=temperature)PM 能读出的信息：
- 函数签名增加了
temperature参数，有默认值 0.7（向后兼容） - 这可能是为了支持 PRD 里某个"创意模式/精确模式"的需求
- 需要确认：前端调用的地方是否也会传这个参数？
快速检查清单
在 PR 评审时，用这个清单快速扫描：
- [ ] 改动的文件路径符合预期（前端/后端/配置）
- [ ] 新增/删除的功能和 PRD 一致
- [ ] 没有改动高风险文件（数据库/认证/支付）
- [ ] PR 描述清楚说明了改动原因和测试方法
二、读 API 文档（10分钟掌握）
AI 产品几乎都有 API 对接需求。能自己读懂 API 文档，是 PM 的基础能力。
API 文档的标准结构
1. Endpoint（接口地址） POST https://api.example.com/v1/chat
2. Headers（请求头） Authorization: Bearer {api_key}
3. Request Body（请求体） JSON 格式的参数
4. Response（返回值） JSON 格式的结果
5. Error Codes（错误码） 4xx 客户端错误 / 5xx 服务端错误读 OpenAI 兼容 API 示例
json
// 请求
POST /v1/chat/completions
{
"model": "gpt-4o",
"messages": [
{"role": "system", "content": "你是一个助手"},
{"role": "user", "content": "你好"}
],
"temperature": 0.7,
"max_tokens": 1000,
"stream": true
}
// 返回（非流式）
{
"choices": [{
"message": {"role": "assistant", "content": "你好！有什么可以帮你？"},
"finish_reason": "stop"
}],
"usage": {
"prompt_tokens": 20,
"completion_tokens": 15,
"total_tokens": 35
}
}PM 需要关注的关键字段
| 字段 | 含义 | 产品决策相关 |
|---|---|---|
model | 使用的模型版本 | 成本/性能平衡，GPT-4o 贵但好，GPT-4o-mini 便宜但弱 |
max_tokens | 最大输出长度限制 | 影响回答完整性，设太小会被截断 |
temperature | 随机性（0-2） | 0 = 精确一致，1 = 创意多样，2 = 非常随机 |
stream | 是否流式输出 | true = 打字机效果（用户体验好），false = 一次性返回 |
usage.total_tokens | 本次消耗 Token 数 | 成本计算依据，1K Token ≈ ¥0.01-0.1（视模型） |
finish_reason | 停止原因 | stop = 正常结束，length = 被截断（需调大 max_tokens） |
常见 HTTP 状态码速查
| 状态码 | 含义 | PM 应对策略 |
|---|---|---|
| 200 | 成功 | 正常 |
| 400 | 请求参数错误 | 检查前端传参，可能是字段缺失或格式错误 |
| 401 | 未授权（API Key 无效） | Key 过期或权限不足，联系供应商 |
| 429 | 请求过多（限流） | 触发了 Rate Limit，需要加队列或降频 |
| 500 | 服务端错误 | 后端问题，找工程师排查日志 |
| 503 | 服务不可用 | 模型供应商故障，关注官方状态页 |
常见踩坑
- 忽略
finish_reason：如果是length，说明回答被截断了，用户看到的是不完整的内容 - 不看 Rate Limit：很多 API 有 RPM（每分钟请求数）限制，高并发场景容易触发 429
- 不处理 503：模型供应商偶尔会故障，产品需要有降级方案（如切换备用模型）
互动练习：读懂这个 API 错误
json
{
"error": {
"message": "This model's maximum context length is 4096 tokens. However, your messages resulted in 5200 tokens.",
"type": "invalid_request_error",
"code": "context_length_exceeded"
}
}这个错误说明了什么？PM 应该怎么处理？
查看答案
错误原因：输入的对话历史 + 当前问题超过了模型的上下文窗口（4096 Token）。
PM 应对方案：
- 短期：截断对话历史，只保留最近 N 轮对话
- 中期：实现智能摘要，压缩历史对话
- 长期：升级到更大上下文的模型（如 GPT-4o 支持 128K Token）
产品设计建议：在 UI 上提示用户"对话过长，已自动精简历史记录"，避免用户困惑。
三、读技术方案文档（5分钟扫描法）
工程师写的技术方案（Tech Design Doc）是 PM 对齐需求的关键文档。
快速扫描框架
第 1 分钟：看背景和目标
- ✅ 解决什么问题？和 PRD 的目标一致吗？
- ✅ 有没有明确的成功指标？
第 2 分钟：看架构图或流程图
- ✅ 数据从哪里来，经过什么处理，到哪里去
- ✅ 有没有外部依赖（第三方 API、数据库）
第 3 分钟：看方案对比
- ✅ 工程师通常会列出 2-3 个备选方案，看他们为什么选了这个
- ✅ 被放弃的方案往往藏着重要的约束条件
第 4 分钟：看风险和限制
- ✅ 明确写出的风险要重点关注
- ✅ 看 edge case（边界情况）的处理
第 5 分钟：看时间估算
- ✅ 工期是否合理？有没有 Buffer？
- ✅ 依赖哪些外部资源（其他团队、三方服务）
PM 在技术评审中应该提的问题
✅ 好问题（从用户/产品视角）
- "这个方案在高并发下，用户会感受到延迟上升吗？"
- "如果第三方 API 挂了，我们的降级策略是什么？"
- "这个改动会影响已有用户的数据吗？需要数据迁移吗？"
- "AB 测试怎么设计？怎么衡量成功？"
- "这个方案的成本是多少？和预算对齐吗？"
❌ 不好的问题（越俎代庖或太模糊）
- "为什么不用 X 技术？"（除非你有充分理由，否则是质疑而非讨论）
- "这里能不能优化一下？"（太模糊，帮不上忙）
- "为什么要这么写？"（质疑而不是好奇，容易引起对立）
- "能不能加个功能 Y？"（评审不是需求变更会，应该在 PRD 阶段提）
互动练习：技术方案评审
假设工程师提出以下方案：
"为了降低成本，我们把所有用户的对话历史都用 GPT-4o-mini 做摘要，然后存到数据库。每次对话时，先读取摘要，再拼接当前问题，发给 GPT-4o。"
作为 PM，你会提什么问题？
查看参考答案
好问题示例：
- 用户体验："摘要会丢失哪些信息？用户会感觉 AI '忘记'了之前说的话吗？"
- 成本核算："摘要的成本是多少？和直接用完整历史对话相比，能省多少？"
- 边界情况："如果用户的对话历史很短（只有 1-2 轮），还需要摘要吗？"
- 降级方案："如果摘要 API 失败了，是直接用原始历史，还是拒绝服务？"
- AB 测试："怎么验证摘要方案不会降低用户满意度？"
为什么这些是好问题：
- 从产品视角出发（用户体验、成本、风险）
- 具体可执行（不是泛泛而谈）
- 帮助工程师完善方案（而非质疑技术能力）
检查点
在继续之前，确保你能回答：
- [ ] 能在 5 分钟内读懂一个 PR 的改动范围和风险点
- [ ] 能识别 API 文档中的关键字段（model、temperature、max_tokens）
- [ ] 能判断 HTTP 状态码的含义并提出应对方案
- [ ] 能用 5 分钟扫描法快速读完一份技术方案
- [ ] 能在技术评审中提出有价值的产品视角问题