面向产品经理的 Claude Code——理解你产品的具体实现

3.1 PM 的代码库问题

你负责产品，但你不会读代码。这会形成一个依赖闭环，让所有事情都慢下来。客户反馈你的定价计算器行为很奇怪，工程团队正处在 Sprint 中段，你急需答案：这是 Bug 还是按设计如此？如果是 Bug，严重程度如何？大概要多复杂才能修？这些问题你无法自己回答，于是你去打断工程师。他们切换上下文、排查、再反馈。对他们来说是 2 小时，对你来说是等 2 天。这个 Bug 就一直躺在分诊队列里。

工程团队不应该成为你与自己负责的代码库之间的唯一接口。你不需要流畅读代码；你需要的是能提问题，并在不打乱别人 Sprint 的情况下拿到准确答案。Claude Code 提供的就是这个能力。

工程师被频繁“上下文切换”的延迟成本，贵在它通常不会出现在 Sprint 看板上。每一个“快速问一下”，算上切换上下文，基本都是一次 15 分钟打断。一天 5 个问题，就是 1 小时工程时间，再加上你自己的等待时间。按一个季度算，你会在本可以自己回答的问题上烧掉数周生产力。

图 3.1：排查工作流对比——用它理解“直接排查代码库”相对“依赖工程团队闭环”的时间节省。左侧是旧流程：多次上下文切换，耗时两天。右侧是 PM 通过 Claude Code 直接排查：10–20 分钟。

替代方案不是“去学会写代码”。替代方案是：通过一个能把实现细节翻译成产品语言的智能体，直接向代码库提问。复杂问题你仍然需要升级给工程团队，但第一轮排查你可以自己做。本章会教你怎么做。

3.2 建立你的代码库心智地图

在排查具体功能之前，先花 20 分钟理解代码库是怎么组织的。这就是你的地图。没有地图，每次排查都要从零开始；有了地图，你就知道该看哪里、该问什么。

当你第一次在新仓库里使用 Claude Code 时，跑一遍这个会话即可。之后按季度更新一次，或者在有重大架构变更时更新。输出会变成一份参考文档，帮你在后续每次排查里省时间。

在仓库根目录用 plan 模式启动 Claude Code：

cd /path/to/your/repository
claude --permission-mode plan

这里 plan 模式很关键（你是在学习，不是在修改）。使用下面这个提示词：

提示词：架构总览（Architecture Overview）
请向一位产品经理解释这个代码库的架构，覆盖以下内容：

• 主要组件有哪些、各自负责什么
• 数据如何在系统中流动
• 面向用户的功能通常在哪里实现
• 前后端如何连接（如果适用）
• 我应该理解的关键抽象或模式

请保持解释非技术化。重点给我能帮助我在排查功能时导航代码库的心智模型。

Claude Code 会读取关键文件（通常是 README.md、包配置、目录结构，以及一部分核心模块样本），然后给出总结。对典型仓库来说，这个回复大约花 5–10 分钟，成本约 $0.10–0.25。

你可以期待输出里有这些内容：

• 组件拆分（Component breakdown）
  “前端是 src/client/ 下的 React 应用，负责 UI。后端是 src/server/ 下的 Express API，负责业务逻辑和数据库访问。src/shared/ 目录放的是前后端共用代码。”
• 数据流说明（Data flow explanation）
  “当用户提交表单时，React 组件会请求 /api/endpoint，路由到 src/server/controllers/ 里的 controller，再调用 src/server/services/ 中的 service 执行业务逻辑，最后通过 src/server/models/ 的模型访问数据库。”
• 功能位置规律（Feature location patterns）
  “用户可见功能通常会以 src/client/components/ 中的 React 组件实现，并对应 src/server/routes/ 的 API endpoint，以及 src/server/services/ 的业务逻辑。”
• 关键抽象（Key abstractions）
  “代码库使用 repository pattern：数据库访问通过 src/server/repositories/ 中的 repository 类，而不是直接写查询。认证使用 JWT token，由 src/server/middleware/auth.js 中的中间件校验。”

这不是完整文档，而是一个起始定位。你要建立的是“东西大概都在哪、怎么连起来”的直觉。之后当你要排查“checkout 怎么工作”时，你就知道该优先看前端组件、后端路由和支付服务集成。

把输出保存起来，供后续参考。可以把回复复制到 docs/architecture-overview.md，或者写进你的 CLAUDE.md（见 3.5 节）。这会成为你的速查指南。三个月后你要回忆时，读文档即可，不用再跑一遍会话。

有价值的追问：
在拿到初始总览后，再问一些和你产品域直接相关的问题，会更有价值，例如：

• 用户认证在哪里发生？系统如何判断已登录用户能访问什么？
• 支付是怎么处理的？我们接入了哪些第三方服务？
• 定价逻辑在哪里实现？在前端、后端，还是两边都有？

这些追问再花 5–10 分钟、 $0.10–0.20，但会补足对你产品最关键的细节。泛化架构没那么重要，真正重要的是知道核心业务逻辑在哪里。

什么时候这个会话不够用：

• 小仓库（少于 50 个文件） 且结构清晰：没必要专门做这一步，你在后续排查中顺带就能熟悉布局。
• 超大单体仓库（上千文件） ：一次总览不够，你需要多次聚焦会话，分别理解不同子系统。

这次“对齐会话”是你的地基。它第一次回本，往往就在你第一次排查某个功能时——因为你已经知道该聚焦哪些目录。工程师之所以能排查快，是因为他们每天都在代码库里，有这张地图。你在做的是建立同样的心智地图，只不过你的方式不是读代码，而是通过对话建立。

3.3 四类问题，几乎能回答一切

PM 对代码库的大部分问题，其实都落在四种模式里。掌握这四种模式，你就能在不依赖工程师的情况下排查几乎所有事情。

图 3.2：四种排查模式——用它来组织你的代码库提问。这个 2x2 覆盖了：

• “X 是怎么工作的？”（功能实现）
• “X 会访问哪些数据？”（数据依赖）
• “当 X 发生时会怎样？”（边界场景）
• “为什么会出现 X 行为？”（行为解释）

这四种模式能覆盖 90% 的 PM 排查。

模式 1：“[功能] 是怎么工作的？”

你需要理解实现，才能回答产品问题。客户问：为什么折扣码不能和促销叠加？工程团队做了这个功能，但你不知道背后的原因。与其让工程师抽空解释，不如直接问代码库。

在 plan 模式下启动 Claude Code，使用这个提示词：

提示词：功能实现（Feature Implementation）
这个应用里的折扣码校验是怎么工作的？请特别说明：

• 折扣码逻辑实现在哪里
• 哪些规则决定一个折扣码是否可用
• 折扣码能不能和其他促销叠加？为什么能/不能？
• 用户输入无效折扣码时会发生什么

请用产品语言解释，不要展开代码细节。

Claude Code 会沿着功能路径追踪：从用户动作（输入折扣码）→ 校验逻辑 → 最终结果（折扣生效或提示错误）。你会拿到带文件引用的结果和白话解释。比如：
“折扣校验在 src/services/discount-validator.js:45-78。系统会检查折扣码是否启用、是否过期、是否满足最低购物车金额。与促销叠加被一条业务规则禁止：第 92 行在 cart.hasActivePromotion 为 true 时直接拒绝折扣码。”

这不仅给你答案（不能叠加是明确业务逻辑），也给了你解释客户或对齐干系人的上下文；同时还告诉你如果需求变了，该改哪一块逻辑。你现在知道折扣逻辑归哪个文件管。

模式 2：“[功能] 会访问哪些数据？”

理解数据依赖能帮助你评估变更影响，也能识别隐私或性能风险。你在规划一个需要“用户购买历史”的功能：现有数据有哪些？从哪里来？隐私约束是什么？

提示词：数据访问排查（Data Access Investigation）
购买历史功能会访问哪些用户数据？请给我看：

• 会读取哪些具体字段（订单详情、支付信息、收货地址等）
• 这些数据存在哪里（数据库表、外部 API、本地存储）
• 代码里谁能访问这些数据（哪些服务或组件）
• 我需要知道的隐私/安全注意事项

你可能会得到这样的结论：购买历史从 orders 表读取（订单 ID、日期、商品、总价），再 join products 表以拿到当前商品名称，并且出于安全考虑不返回支付详情。数据只允许已认证用户查看自己的历史，这由 src/middleware/auth.js:34 的中间件强制执行。这样你就知道：新功能能用哪些数据、会受到哪些限制。

模式 3：“当 [条件] 发生时会怎样？”

边界场景和异常路径对产品质量很关键，但如果看不到实现，通常很难发现。比如：结账中途支付失败会怎样？用户提交表单时 session 过期会怎样？加入购物车后到付款前库存卖完会怎样？

提示词：边界场景排查（Edge Case Investigation）
当用户在结账时支付失败，会发生什么？请按流程说明：

• 用户会看到什么（报错文案、页面状态）
• 购物车和订单会变成什么状态
• 系统会重试，还是用户必须重来
• 如果出现部分完成（例如订单已创建但支付失败），系统如何处理

Claude Code 会读取错误处理代码、支付集成逻辑和状态管理逻辑，然后把行为解释清楚。你可能发现：支付失败会展示一个通用错误，购物车会保留，用户可以重试且不丢进度；也可能发现某些边界场景没处理好，这就可以直接变成 backlog 项。

模式 4：“为什么会出现 [行为]？”

用户反馈某个行为很迷惑或反直觉。你需要先判断这是产品有意设计，还是 Bug，才能正确分诊。比如：为什么点“Show More”后搜索筛选条件会被重置？为什么时间戳显示 UTC 而不是用户时区？为什么表单能接受非法手机号？

提示词：行为解释（Behavior Explanation）
用户反馈：点击 “Show More” 加载更多结果后，搜索筛选条件会被重置。为什么会这样？这是有意行为还是 Bug？

请解释代码里是什么导致了这个行为，以及是否存在产品层面的原因。

你可能会得到：Show More 触发了整页刷新（历史遗留实现），导致组件状态被重置，包括筛选条件。这并非有意设计，而是旧代码造成的技术限制。现在你就能把它按“有根因上下文的 Bug”来分诊，而不是只写一句“用户说不好用”。

让这四种模式真正好用的做法

提示词要具体。
“认证怎么工作？”太宽了。Claude Code 可能会读 20 个文件，给你一份系统级总览，而你其实只想知道一个细节。
把它收窄成：
“用户访问受保护页面时，应用如何判断他是否已登录？”
这样更聚焦，也更容易拿到直接答案。

明确要求产品语言。
总是加上“请用产品语言解释”或“聚焦用户可见行为”，避免它默认走技术细节输出，导致你看不懂。Claude Code 不加约束时，通常会偏技术化。

一定追问。
第一轮回答给你方向，追问才会给你深度。比如：

• “你提到第 92 行有一条业务规则，这条规则的业务原因可能是什么？”
• “你说支付失败会保留购物车，这段逻辑具体在哪实现？”

引用文件位置与工程沟通。
Claude Code 会给出文件路径与行号。当你需要工程帮助时，带着这些去沟通：
“我排查了折扣码问题，逻辑在 discount-validator.js:92。能解释一下为什么要禁止和促销叠加吗？”
这比“你好，折扣码到底怎么工作的？”有效得多。

这四种模式能处理 90% 的功能排查。你不是在读代码；你是在提有结构的问题，并让实现细节被翻译成产品上下文。一次排查可能花 10–20 分钟、成本 $0.15–0.50，但它能回答那些原本需要打断工程师、或让你长期对实现现实一无所知的问题。

3.4 不读代码，也能“读懂代码”

你可以在不解析语法的前提下理解实现。Claude Code 能把代码翻译成概念、流程图和白话说明。本节讲的是：如何从你无法直接阅读的代码库里，建立可用的心智模型。

让它输出白话总结

代码很精确，但不透明；自然语言容易理解，但可能有歧义。你要做的是让 Claude Code 在两者之间搭桥：

提示词：白话总结（Plain English Summary）
请用白话总结 processCheckout 函数在做什么，重点说明：

• 它按顺序执行了哪些步骤
• 它需要哪些输入
• 它返回或产出什么
• 可能出错的地方，以及它如何处理错误

输出可能像这样：
“这个函数接收一个购物车对象和支付信息。首先，它会校验购物车里是否有商品、总价是否正确。其次，它通过 Stripe 集成处理支付。如果支付成功，它会在数据库中创建订单记录、发送确认邮件，并清空购物车。如果支付失败，它会记录错误并返回失败，不会创建订单。如果支付成功后数据库写入失败，它会把订单加入人工对账队列。”

这样你不用读一行代码，就能理解 checkout 流程。你可以把它解释给干系人、识别改进机会，也能对边界场景提出有意义的问题。

让它输出流程图或时序图（文本版）

复杂逻辑很多时候用图比用文字更清楚。Claude Code 不能直接生成图片，但它能生成文本形式的流程图，帮助你看清流程：

提示词：流程图请求（Flow Diagram Request）
请生成一个文本版流程图，展示用户提交 checkout 表单后会发生什么。请包含决策点、成功/失败路径，以及外部服务调用。

输出可能是：

用户提交 checkout 表单
    ↓
校验购物车（有商品、价格为最新）
    ├─ 无效 → 返回错误给用户
    └─ 有效 → 继续
        ↓
    通过 Stripe API 处理支付
        ├─ 支付失败 → 记录错误、展示用户提示、保留购物车
        └─ 支付成功 → 继续
            ↓
        在数据库中创建订单
            ├─ DB 错误 → 加入人工对账队列、通知团队
            └─ 成功 → 继续
                ↓
            发送确认邮件
                ├─ 邮件失败 → 记录警告（订单仍已创建）
                └─ 成功 → 继续
                    ↓
                清空购物车，跳转确认页

这个图会把所有决策点、失败模式和依赖都显出来。你可以直接用它走客户场景：
“如果支付成功但邮件发送失败会怎样？”
图里已经告诉你：订单照样创建，邮件失败只记日志，不会阻断完成。这就是很关键的产品知识。

识别某个功能的“关键文件”

大代码库里有成百上千个文件，但对某个功能来说，大部分都不相关。让 Claude Code 帮你先做筛选：

提示词：关键文件识别（Critical Files Identification）
我需要理解 checkout 功能。请告诉我最重要的 5 个文件分别是什么，并说明：每个文件负责什么、为什么它对 checkout 重要。

Claude Code 会分析代码库并给出优先级，比如：

1. CheckoutForm.tsx —— 用户直接交互的 React 组件，负责表单提交和错误展示
2. checkout.service.js —— checkout 的业务逻辑，校验购物车并编排支付流程
3. stripe-integration.js —— 处理所有 Stripe API 调用
4. order.model.js —— 订单数据库模型，定义存储字段
5. email-notifications.js —— 发送确认邮件并处理模板渲染

这样当你后续排查 checkout 问题或规划改进时，就知道先看哪里，而不是盲目乱找。

在不懂语法的前提下建立心智模型

你的目标不是学会读代码；你的目标是理解功能如何行为、数据如何流动、以及决策在哪里发生。把问题聚焦在“概念”上：

• “用户注册流程的主要步骤有哪些？”
• “应用是怎么决定给用户展示哪个价格档位的？”
• “搜索功能依赖哪些外部服务？”
• “用户偏好数据存在哪里？加载流程是什么？”

这些问题会暴露系统行为和架构，而不要求你去解析函数语法、理解循环，或追踪变量赋值。Claude Code 负责做语法解析，再把你要的概念模型给你。

AI 解释的局限性

Claude Code 是根据它读到的代码进行解释，但它不能真正运行代码，也不能保证自己的解释一定正确。如果逻辑非常复杂、存在隐蔽 bug，或者依赖它看不到的运行时条件，它的解释可能不完整甚至错误。

把这些解释当成高可信假设，而不是绝对真相。

• 当你需要高精度（调试关键问题、评估安全影响、规划重大变更）时，仍然要和工程团队验证。
• 当你只是需要一般性理解（回复干系人问题、做 bug 分诊、评估可行性）时，Claude Code 的解释通常足够可靠，可以据此行动。

你是在通过“问对问题 + 接受总结而不是语法”，实现“不读代码也能读懂代码”。这足够覆盖 PM 80% 的需求。剩下 20%（深度调试、安全审计、性能优化）仍然需要工程专业能力。知道这个边界，你就不会越界。

3.5 让 Claude Code 记住你的上下文

只要你的项目里存在 CLAUDE.md，Claude Code 每次会话开始时都会先读取它。这个文件存放的是会跨会话持久化的上下文：属于你项目的“机构知识（institutional knowledge）”，但又不适合写进代码注释或外部文档。

对 PM 来说，维护得好的 CLAUDE.md 会把 Claude Code 从“聪明助手”变成“懂你产品的团队成员”。没有 CLAUDE.md 的第一次会话，你得先解释业务领域；有了 CLAUDE.md 的每次会话，Claude Code 一开始就带着上下文。配置时间很快就会回本。

目的：跨会话持久化上下文

Claude.ai 关掉窗口就忘光；Claude Code 结束会话后也会丢失会话历史。但 CLAUDE.md 不会。凡是你希望 Claude Code 每次会话都知道的东西，都应该放这里。

它不是“把所有文档都塞进来”的垃圾场。它应该是能提高排查质量、减少重复解释的聚焦型上下文。把它当成给 AI 队友的 onboarding 文档。

PM 工作流里该放什么

1) 产品领域术语表（Product domain glossary）

你的产品里一定有一些容易歧义、或在你领域里有特定含义的词。一次性定义好：

## Product Terminology

- **Credit**: 用户通过邀请获得的内部积分，不是支付信用额度
- **Workspace**: 团队共享工作空间。一个用户可以属于多个 workspace
- **Pipeline**: 销售 pipeline，不是数据 pipeline，指 CRM 中的商机阶段
- **Activation**: 用户完成资料设置并创建第一个项目（不同于账号激活/邮箱验证）

这样可以避免 Claude Code 把多义词理解错。比如你问 “activation rates”，它就知道你说的是资料完善+首个项目创建，而不是邮箱验证。

2) 关键用户旅程到代码位置的映射

把产品流程和实现位置连起来：

## User Journeys

### 新用户引导（New User Onboarding）
1. 用户注册 → `src/auth/signup.js`
2. 邮箱验证 → `src/services/email-verification.js`
3. 资料设置 → `src/components/ProfileSetup.tsx`
4. 创建第一个项目 → `src/services/project-creator.js`

### Checkout 流程
- 入口：`src/components/Checkout/CheckoutForm.tsx`
- 支付处理：`src/services/payment-processor.js`
- 订单创建：`src/models/order.js`
- 确认通知：`src/services/order-notifications.js`

之后你让 Claude Code 排查 onboarding 某一步时，它无需先探索目录，直接就知道去哪找。省 token，也省时间。

3) 团队约定与协作规范（Team conventions）

你的团队怎么做事？Claude Code 需要知道哪些“不要建议错方向”的规则？

## Team Conventions

- 所有面向客户的字符串都走 `src/locales/` 的 i18n 系统，不要建议硬编码文案
- 定价逻辑只允许放在 `src/services/pricing/`，前端不计算价格
- Commit message 必须包含 Jira ticket ID，例如：`Fix checkout bug (PM-1234)`
- 数据库迁移执行前必须获得数据团队审批
- Feature flag 配置在 `src/config/features.js`

这样 Claude Code 就不会给出违反团队规范的建议。比如你让它帮你生成 release notes，它会知道去 commit 里找 Jira ID。

4) 外部文档链接（Links to external documentation）

把 Claude Code 访问不到、但你又经常要参考的资源列出来：

## External Resources

- API 文档: https://docs.internal.com/api
- 设计系统: https://www.figma.com/design-system
- 产品策略文档: [Google Docs 链接]
- 分析看板: https://analytics.internal.com

讨论功能时，请考虑与设计系统一致性，并检查是否与产品策略对齐。

这些链接不会直接帮助 Claude Code（它未必能访问），但会提醒你在决策时别忘了去核对这些资源。

放在哪里：CLAUDE.md 的位置

首选、也是推荐位置，是项目根目录：/path/to/your/repo/CLAUDE.md。这样仓库里所有人都能看到，也更容易把它当成团队文档。

Claude Code 会按层级读取 CLAUDE.md：

1. 先读 home 目录（~/.claude/CLAUDE.md，放跨项目通用的个人偏好）
2. 再读项目根目录的 CLAUDE.md

你也可以在子目录里放 CLAUDE.md，为某个子系统提供局部上下文，不过这种情况不常见。

对大多数 PM 场景来说，项目根目录一个 CLAUDE.md 就够了。你放进去的内容（领域知识、用户旅程映射、团队约定）不仅能帮助 Claude Code，也能帮助工程师和设计师。所以让它可见，并把它当作团队共同维护的活文档。

随着理解加深，持续更新 CLAUDE.md

把这个文件当成活文档来维护。你每次排查功能、学到了有价值的信息，就加进去；团队约定变了，就更新；你发现 Claude Code 总犯同一个错（比如反复误解某个术语、老是漏掉某个模式），就补一条澄清。

它的回本时刻往往很直接：只要它能避免你重复解释一次，或能帮助新 PM 通过阅读 CLAUDE.md 快速建立产品上下文，它就已经值了。版本控制还能记录它的变化，让你看到“团队理解是如何演进的”。

一个面向 PM 的 CLAUDE.md 示例结构

# Product Context for Claude Code

## About This Product
[2-3 句：这个产品做什么？谁在使用它？]

## Product Terminology
[关键术语及其在你领域里的特定含义]

## User Journeys
[关键用户流程到代码位置的映射]

## Business Rules
[代码里不明显、但很重要的产品逻辑：
- 为什么我们把 X 限制为 Y？
- Z 行为背后的原因是什么？
- 功能 A 有哪些约束？]

## Team Conventions
[团队如何协作、避免建议什么、遵循哪些实践]

## External Resources
[文档、设计、策略、分析资源链接]

## Common PM Questions
[常见排查问题的速查入口：
- “定价逻辑怎么做？” → 看 `src/services/pricing/`
- “邮件内容在哪里管？” → `src/templates/email/`]

一开始先从小做起。先加术语表，再加 1–2 条关键用户旅程。随着你发现“哪些上下文能显著提高排查质量”，再逐步扩展。一个 50 行、内容聚焦且高价值的 CLAUDE.md，远胜于一个 500 行、把所有东西都堆进去的大杂烩。

3.6 知道什么时候该升级给工程团队

Claude Code 能读代码、解释代码，并把它翻译成白话。这对大多数 PM 场景都非常好用，但它有边界，你必须识别出来。对 AI 生成解释过度自信，会在你基于不完整或错误信息采取行动时制造问题。

运行时行为 vs. 静态分析

Claude Code 读取的是源代码——也就是应用的静态文本。它不能真正运行代码、观察实际行为，也看不到运行时状态。当行为依赖配置、环境变量、数据库状态或外部服务响应时，这一点就很关键。

一个具体例子：你问“应用如何决定用户能访问哪些功能”。Claude Code 会读取权限校验代码，并解释逻辑：“应用会检查 user.role 是否为 admin，如果是就授予管理员功能访问权限。”但它无法告诉你：生产环境里实际分配了哪些角色、是否存在数据质量问题导致角色值错误、或者某个环境变量是否在某些部署里覆盖了这段逻辑。

如果你的目标是理解“它按设计应该怎么工作”，Claude Code 很可靠。
如果你的目标是理解“它此刻在生产环境里实际上怎么工作”，你需要运行时数据：日志、数据库查询、监控看板，或者工程师协助。

配置与环境依赖

应用会因为配置文件、环境变量和部署上下文而表现不同。开发、测试、生产环境可能跑的是同一份代码，但由于配置差异，行为并不一样。

Claude Code 可以读取配置文件并识别依赖关系，但如果你没有明确告诉它，它无法知道“哪个环境当前启用了哪套配置”。例如你问“我们怎么处理支付失败”，而答案取决于 Stripe 是测试模式还是生产模式时，Claude Code 可能会把两条代码路径都解释出来，但不一定会明确说明每条路径适用于哪个环境。

在排查对环境敏感的功能时，把环境说清楚。比如直接问：
“我们在生产环境里如何处理支付失败？”
这样能引导 Claude Code 去关注生产配置。

什么时候必须升级给工程团队

你可以独立做很多排查，但有些情况就是需要工程专业能力：

• 安全敏感问题
  比如“这个认证实现安全吗？”、“用户是否可能访问到其他用户的数据？”这类问题需要安全专业判断，而不只是读代码。Claude Code 也许能识别明显问题（如明文存密码、明显的 SQL 注入风险），但更隐蔽的安全问题仍需要人工审查。
• 性能问题
  比如“为什么这个功能很慢？”这通常涉及 profiling、数据库查询分析和运行时观察。Claude Code 能通过读代码识别潜在高成本操作（嵌套循环、N+1 查询等），但真实性能取决于数据量、索引、基础设施等它看不到的因素。
• 复杂调试
  如果 Bug 是间歇性的、依赖特定数据状态、或涉及竞态条件（race conditions），Claude Code 的静态分析通常无法定位根因。你可以先用它做初步排查（缩小相关代码范围），然后带着上下文交给工程团队。
• 架构决策
  比如“我们该不该重构成微服务？”、“这个数据库还适不适合我们当前规模？”这类问题需要工程判断，包括权衡取舍、团队能力、长期维护成本。Claude Code 能解释现状和痛点，但不能替代战略级技术决策。
• 生产系统访问
  任何需要数据库查询、日志分析、监控看板查看的事情，都超出 Claude Code 的能力边界。它处理的是代码和文件，不是在线系统。

避免对解释“过度自信”

把 Claude Code 的解释当成高可信解释，而不是绝对真相。当准确性很重要时（例如对客户沟通、路线图决策、安全评估），在行动前先让工程团队验证结论。

一个实用心智模型是：
把 Claude Code 当成一个能读代码、也能解释自己看到内容的初级工程师（junior engineer），但他没有生产经验，也没和原作者沟通过。
你可以信任它的“阅读能力”，但关键事项仍然要做验证。

PM 使用中的边界（实操版）

图 3.3：升级边界——用它判断什么时候可以独立排查，什么时候该拉工程师参与。左列是 Claude Code 适合处理的范围（结构与行为问题）；右列是工程团队范围（质量、性能、生产问题）。

你可以用 Claude Code 处理	应升级给工程团队
功能 X 是怎么工作的？	功能 X 安全吗？
哪些文件实现了 Y？	为什么 Y 在生产环境很慢？
Z 会访问哪些数据？	我们该不该重构 Z？
配置 A 在哪里定义？	生产环境里的配置 A 到底是什么？
用户执行 B 时会发生什么？	为什么只有一部分用户执行 B 会失败？
功能 C 和 D 能不能组合使用？	C+D 集成应该怎么设计实现？
E 的边界场景有哪些？	我们该怎么在 staging 验证 E？

规律很清楚：
关于“系统里有什么、结构如何、逻辑怎么写”的问题，是 Claude Code 的地盘。
关于“质量、性能、正确性、生产行为”的问题，需要工程团队。

这并不会削弱 Claude Code 的价值，反而会让你把它用在高回报的排查上，同时对 AI 的局限保持应有的谦逊。你仍然能通过自己做第一轮排查，为工程团队节省大量时间；只是你会避开一个常见陷阱：把 AI 的解释当成“神谕真相”。