理解你的产品实现

3.1 PM的代码库困境

你拥有这个产品，但你看不懂代码。这会形成一个拖慢一切的依赖循环。某位客户反馈你的定价计算器出现了令人困惑的行为，而工程团队正处于冲刺中期。你需要答案——这到底是个bug还是符合设计预期？如果是bug，严重程度如何？修复复杂度有多高？你自己回答不了这些问题，只能去打断工程团队。他们切换上下文、调查问题、然后汇报。他们花两小时，你要等两天。这个bug就这样躺在triage里。

工程团队不应该是你了解自己所负责代码库的唯一途径。你不需要流利地阅读代码，但你需要能够提出问题并获得准确答案，同时不打断别人的冲刺进度。这正是Claude Code所提供的。

工程师上下文切换带来的延迟成本十分高昂，高到不会直接体现在冲刺面板上。每个"快速问题"加上上下文切换的成本后，实际上是一个15分钟的中断。每天五个问题，就等于一小时工程时间加上你自己的等待时间。一个季度下来，你会在那些本可以自己回答的问题上浪费数周的生产力。

图 3.1：调查工作流对比——用于理解直接进行代码库调查相对于传统工程依赖循环所节省的时间。左侧显示旧的工作流需要两天时间，且涉及多次上下文切换。右侧显示通过Claude Code由PM直接进行调查只需10-20分钟。

替代方案不是去学编程。替代方案是通过一个能把实现翻译成产品语言的agent来直接向代码库提问。复杂问题仍然要向上反馈给工程团队，但第一轮调查由你自己完成。本章将教你如何做到这一点。

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

在深入调查具体功能之前，花20分钟了解代码库是如何组织的。这是你的地图。没有它，每一次调查都从零开始。有了它，你就知道该去哪里找，知道该问什么问题。

当你首次在某个新仓库中使用Claude Code时，运行一次这个会话。每季度更新一次，或者在重大架构变更时更新。输出结果会成为一份参考文档，为之后的每一次调查节省时间。

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

cd /path/to/your/repositoryclaude --permission-mode plan

Plan模式在这里至关重要（你是在学习，不是在修改）。使用以下prompt：

Prompt：架构总览

向一位产品经理解释这个代码库的架构。涵盖以下内容：

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

保持非技术性的解释。重点关注那些能帮助我在调查功能时导航代码库的心智模型。

Claude Code会读取关键文件（通常是README.md、包配置文件、目录结构以及一些核心模块的采样），然后提供一个摘要。回复需要5-10分钟，对于典型仓库的成本约为$0.10-0.25。

在输出中可以预期获得以下内容：

组件分解。"前端是位于src/client/中的一个React应用，处理所有用户界面。后端是位于src/server/中的一个Express API，管理业务逻辑和数据库访问。src/shared/目录包含两端共用的代码。"

数据流说明。"当用户提交表单时，React组件会向/api/endpoint发送请求，该请求被路由到src/server/controllers/中的一个控制器，调用src/server/services/中的一个服务来处理业务逻辑，并通过src/server/models/中的模型查询数据库。"

功能定位模式。"面向用户的功能通常实现为src/client/components/中的React组件，对应src/server/routes/中的API端点，以及src/server/services/中的业务逻辑。"

关键抽象。"代码库使用了repository模式：数据库访问通过src/server/repositories/中的repository类进行，而非直接执行查询。身份认证使用JWT令牌，由src/server/middleware/auth.js中的中间件验证。"

这不是一份面面俱到的文档，而是一份入门导向。你在逐步建立关于事物所在位置以及它们如何协作的直觉。当你之后调查"结账流程是如何运作的"这类问题时，你自然会知道去查看客户端组件、服务端路由以及支付服务的集成。

保存输出以供将来参考。将回复内容复制到一个文件中，例如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并使用以下prompt：

Prompt：功能实现

折扣码验证在这个应用中是如何工作的？具体来说：

• 折扣码逻辑在哪里实现？
• 哪些规则决定了折扣码是否可以应用？
• 折扣码能否与其他促销活动叠加使用？为什么可以或不可以？
• 当用户输入无效代码时会发生什么？

请使用产品语言解释，而非代码细节。

Claude Code会从用户操作（输入代码）开始，一直追踪到验证逻辑再到最终结果（折扣生效或显示错误）。你会得到带有文件引用的通俗解释。"折扣验证在src/services/discount-validator.js:45-78中处理。系统会检查代码是否活跃、是否未过期、是否满足最低购物车金额要求。禁止与促销活动叠加使用的规则位于第92行的一个业务规则中——当cart.hasActivePromotion为true时拒绝应用折扣码。"

这为你提供了答案（因为显式的业务逻辑导致不能叠加）以及向客户或利益相关者解释的上下文。它还告诉你了当需求变更时应该去哪里查看。现在你知道了哪个文件负责折扣逻辑。

模式2："[功能]访问了哪些数据？"

理解数据依赖关系有助于你评估变更的影响，并识别隐私或性能方面的顾虑。假如你正在规划一个需要用户购买历史的功能，那有哪些数据可用？它们从何而来？有哪些隐私方面的考虑？

Prompt：数据访问调查

购买历史功能访问了哪些用户数据？请展示：

• 具体读取了哪些数据字段（订单详情、支付信息、收货地址等）
• 这些数据存储在哪里（数据库表、外部API、本地存储）
• 代码中谁有权访问这些数据（哪些服务或组件）
• 我应该了解的任何隐私或安全方面的考虑

你会了解到：购买历史从orders表中拉取数据（订单ID、日期、商品、金额），并与products表做连接以获取当前商品名称，同时出于安全考虑排除支付详情。数据只能由已认证用户查看自己的历史记录，由src/middleware/auth.js:34中的中间件强制执行。这告诉你对于你的新功能，什么是可行的以及有哪些约束条件适用。

模式3："当[条件]发生时会发生什么？"

边缘情况和错误场景对产品质量至关重要，但如果不看实现，很难发现这些情况。当支付在结账中途失败时会发生什么？当用户会话在表单提交过程中过期时会怎样？当库存从加入购物车到完成购买之间耗尽时又如何？

Prompt：边缘情况调查

当支付在结账过程中失败时会发生什么？请带我逐步了解：

• 用户会看到什么（错误消息、页面状态）
• 他们的购物车和订单会发生什么
• 我们是否会重试，还是用户必须重新开始
• 如何处理部分完成的情况（如果订单已创建但支付失败）

Claude Code会阅读错误处理代码、支付集成逻辑以及状态管理来解释具体行为。你可能会发现支付失败时会显示一个通用错误，保留购物车，允许重试而不丢失进度。或者你可能会发现边缘情况未被妥善处理的漏洞，这些就会变成backlog条目。

模式4："为什么会发生[某行为]？"

用户反馈了一些令人困惑或反直觉的现象。在归类之前，你需要知道这是有意为之还是一个bug。为什么点击"显示更多"时搜索筛选条件会重置？为什么时间戳显示的是UTC时间而不是用户所在时区？为什么表单会接受无效电话号码？

Prompt：行为解释

用户反馈说，当他们点击"显示更多"来加载额外结果时，搜索筛选条件会重置。为什么会这样？是故意如此设计还是一个bug？

请解释代码中是什么导致了这种行为，以及是否有产品层面的原因。

你会了解到："显示更多"触发了整页刷新（这是遗留实现），这会重置所有组件状态，包括筛选条件。这不是故意的，而是旧代码的技术限制造成的。现在你可以把它归类为bug，并为工程团队提供关于根因的上下文。

如何让这些模式奏效：

Prompt要具体。"认证是如何工作的？"这个问题太宽泛了。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弥合这一差距：

Prompt：通俗摘要

用通俗语言总结processCheckout函数做了什么。重点关注：

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

输出示例："该函数接收一个购物车对象和支付信息。首先，它验证购物车有商品且金额正确。其次，它通过Stripe集成处理支付。如果支付成功，它在数据库中创建订单记录，发送确认邮件，并清空购物车。如果支付失败，它记录错误并返回失败而不创建订单。如果支付成功后数据库写入失败，它将订单加入队列以进行人工对账。"

你现在无需阅读一行代码就理解了结账流程。你可以向利益相关者解释它，识别改进机会，并就边缘情况提出有意义的问题。

请求流程图和时序图。可视化表示通常比文字更能清晰地呈现复杂逻辑。Claude Code无法生成真正的图片，但可以生成展示流程的文本图表：

Prompt：流程图请求

创建一个基于文本的流程图，展示当用户提交结账表单时会发生什么。显示决策点、成功/失败路径以及外部服务调用。

可能的输出：

用户提交结账表单

↓

验证购物车（商品存在，价格最新）

├─ 无效 → 返回错误给用户

└─ 有效 → 继续

↓

通过Stripe API处理支付

├─ 支付失败 → 记录错误，显示用户消息，保留购物车

└─ 支付成功 → 继续

↓

在数据库中创建订单

├─ DB错误 → 加入人工对账队列，通知团队

└─ 成功 → 继续

↓

发送确认邮件

├─ 邮件失败 → 记录警告（订单仍然已创建）

└─ 成功 → 继续

↓

清空购物车，重定向到确认页面

这向你展示了每一个决策点、失败模式和依赖项。你可以逐一走查客户场景。"如果支付成功但邮件发送失败怎么办？"图表显示订单会创建，邮件失败会被记录但不会阻塞流程。这是重要的产品知识。

识别某个功能的"重要"文件。大型代码库有数百个甚至数千个文件，其中大部分与任一给定功能都无关。让Claude Code来筛选：

Prompt：关键文件识别

我需要理解结账功能。我应该了解哪五个最重要的文件？对每个文件，解释它负责什么以及为什么它对结账至关重要。

Claude Code分析代码库并排出优先级："1. CheckoutForm.tsx——用户交互的React组件，处理表单提交并显示错误。2. checkout.service.js——包含处理结账的业务逻辑，验证购物车并编排支付。3. stripe-integration.js——处理所有用于支付处理的Stripe API调用。4. order.model.js——订单的数据库模型，定义了我们存储哪些数据。5. email-notifications.js——发送确认邮件并处理模板渲染。"

现在，当你调查结账问题或规划改进时，你就知道该去哪里看了。你不再是盲目导航，而是带着上下文开始。

无需了解语法就能构建心智模型。你的目标不是阅读代码，而是理解功能如何运作、数据如何流动以及在何处做出决策。将你的问题聚焦在概念上：

• "用户注册流程中的主要步骤是什么？"
• "应用如何决定向用户展示哪个定价层级？"
• "搜索功能依赖于哪些外部服务？"
• "用户偏好存储在哪里？如何加载？"

这些问题揭示了系统的行为和架构，而无需你解析函数语法、理解循环或追踪变量赋值。Claude Code负责解析，并为你提供概念模型。

AI生成解释的局限性。Claude Code基于它读取的内容来解释代码，但它无法运行代码，也不能保证其解释是正确的。如果逻辑复杂、存在细微的bug或者依赖于Claude Code无法看到的运行时条件，解释可能不完整或错误。

将解释视为高置信度的假设，而非绝对真理。当准确性至关重要时（调试关键问题、评估安全影响、规划重大变更），请与工程团队验证。当需要一般性理解时（回答利益相关者的问题、对bug进行triage、评估可行性），Claude Code的解释足够可靠，可以据此采取行动。

你通过提出正确的问题并以摘要代替语法，做到了"不读代码也能读懂代码"。这足以满足80%的PM需求。剩下的20%（深度调试、安全审计、性能优化）仍然需要工程专家的参与。认清这个边界，你就不会越过界限。

3.5 让Claude Code记住你的上下文

每个Claude Code会话启动时，如果项目中存在CLAUDE.md，它都会先读取该文件。这个文件包含了能够在所有会话之间持久存在的上下文：你的项目中那些不适合放在代码注释或外部文档中的隐性组织知识。

对于PM来说，一个精心维护的CLAUDE.md能将Claude Code从一个聪明的助手转变为了解你产品的团队成员。没有CLAUDE.md的第一次会话需要你解释自己的领域，而有CLAUDE.md的每一个会话从一开始就具备了充分的上下文信息。前期投入的安装时间会立即得到回报。

目的：在会话之间持久存在的上下文。关闭窗口时，Claude.ai会忘记一切。退出会话时，Claude Code会忘记对话历史。但CLAUDE.md会持续存在。你希望Claude Code在每个会话中都知道的任何内容都放在这里。

这不是一个存放所有文档的堆积场，而是能提升调查质量并减少重复性解释的聚焦式上下文。把它想象成一位AI队友的上岗培训文档。

针对PM工作流应该包含的内容：

产品领域术语表。你的产品中有一些在你的领域内模糊或特定的术语，一次性定义清楚：

Product Terminology- Credit：用户通过推荐获得的内部货币，与支付积分无关。- Workspace：一个团队共享的环境。用户可以属于多个工作区。- Pipeline：销售管道，而非数据管道。指CRM中的交易阶段。- Activation：当用户完成个人资料设置并创建第一个项目时。与账户激活（邮箱验证）不同。

这可以防止Claude Code误解具有多重含义的术语。当你问到"activation rates"时，它知道你指的是个人资料完善，而非邮箱验证。

关键用户旅程与代码区域的映射。将产品流程与实现关联起来：

User Journeys### New User Onboarding1. 用户注册 → src/auth/signup.js2. 邮箱验证 → src/services/email-verification.js3. 个人资料设置 → src/components/ProfileSetup.tsx4. 创建第一个项目 → src/services/project-creator.js### Checkout Flow- 入口点：src/components/Checkout/CheckoutForm.tsx- 支付处理：src/services/payment-processor.js- 订单创建：src/models/order.js- 确认：src/services/order-notifications.js

当你需要Claude Code调查onboarding的某一部分时，它无需探索就能直接找到对应位置。这既节省token又节省时间。

团队约定与沟通规范。你的团队如何工作？Claude Code应该了解你的哪些实践？

Team Conventions- 所有面向客户的字符串均使用src/locales/中的i18n系统。不要建议硬编码字符串。- 定价逻辑仅存在于src/services/pricing/中。前端永远不会计算价格。- 我们在commit message中使用Jira ticket ID："Fix checkout bug (PM-1234)"- 数据库迁移在运行前需要获得数据团队的审批- 功能开关在src/config/features.js中管理

这可以防止Claude Code提出违反团队实践的变更建议。如果你需要帮助生成发布说明，它知道要去commit中查找Jira ID。

指向外部文档的链接。指向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文件。首先从你的主目录（~/.claude/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/]

从最小化起步。先添加术语表和一个或两个关键用户旅程。随着时间推移，当你发现哪些上下文能提升调查质量时再逐步扩展。一份50行、内容聚焦且高价值的CLAUDE.md，胜过一份500行的全能知识库。

3.6 知道何时应该向上反馈给工程团队

Claude Code读取代码、解释代码，并用通俗语言表达出来。对于大多数PM需求来说，这表现得非常出色，但你需要认识到它的边界所在。对AI生成的解释过于自信，会在你依据不完整或错误信息采取行动时造成问题。

运行时行为与静态分析。Claude Code读取的是源代码——你的应用程序的静态文本。它无法运行代码、观察实际行为或查看运行时状态。当行为依赖于配置、环境变量、数据库状态或外部服务响应时，这一点就很重要了。

具体例子：你问应用如何决定用户可以访问哪些功能。Claude Code读取权限检查代码并解释逻辑："应用检查user.role是否为'admin'，如果是，则授予对管理员功能的访问权限。"但它无法告诉你生产环境中实际分配了哪些角色、是否存在数据质量问题导致角色值不正确，或者环境变量是否在某些部署中覆盖了该逻辑。

对于理解某事物应该如何工作，Claude Code是可靠的。对于理解它在当前生产环境中实际如何工作，你需要运行时数据：日志、数据库查询、监控面板，或者工程团队的帮助。

配置和环境依赖。应用程序的行为会根据配置文件、环境变量和部署上下文的不同而不同。开发环境、暂存环境和生产环境可能运行相同的代码，但由于配置不同而有不同的表现。

Claude Code可以读取配置文件并识别依赖项，但如果没有被明确告知，它无法告诉你哪个配置在哪个环境中生效。如果你问"我们如何处理支付失败？"，答案取决于Stripe是处于测试模式还是生产模式，那么Claude Code会解释两条代码路径，但可能不会明确指出哪个适用于什么环境。

在调查对环境敏感的功能时，明确指明配置。"在生产环境中我们如何处理支付失败？"这个问题会促使Claude Code去查找生产配置。

何时需要向上反馈给工程团队。你可以独立调查，但某些情况需要工程专家的参与：

安全敏感的问题。"这个认证实现安全吗？"或"一个用户能否访问另一个用户的数据？"这些问题需要安全专家的判断，而不仅仅是代码阅读。Claude Code可以识别明显的问题（明文存储密码、明显的SQL注入漏洞），但细微的安全问题需要人工审查。

性能问题。"为什么这个功能很慢？"这类问题涉及性能分析、数据库查询分析以及运行时行为观察。Claude Code可以通过阅读代码识别潜在的高成本操作（嵌套循环、N+1查询），但实际性能取决于数据量、数据库索引以及它无法看到的底层基础设施。

复杂调试。如果一个bug是间歇性的、依赖于数据的，或者涉及竞态条件，Claude Code的静态分析将无法找到根本原因。你可以利用它进行初步调查（缩小相关代码区域），然后带着上下文移交给工程团队。

架构决策。"我们应该将其重构为微服务吗？"或"对于我们的规模来说，这是合适的数据库吗？"这些问题需要工程团队在权衡各方面利弊、团队能力和长期维护成本后做出判断。Claude Code可以解释当前架构并识别痛点，但它无法做出战略性的技术决策。

生产系统访问。任何需要数据库查询、日志分析或监控面板审查的事情都在Claude Code的能力范围之外。它与代码和文件打交道，而不是与实时系统。

避免对解释过于自信。将Claude Code的解释视为高置信度的解读，而非绝对真理。当准确性至关重要时（面向客户的沟通、路线图决策、安全评估），在行动之前与工程团队验证你的发现。

使用这个心智模型：Claude Code就像一位初级工程师，能读代码并解释所看到的内容，但没有生产经验，也没和原作者交流过。你信任他阅读的结果，但对任何关键信息都要进行核实。

PM使用的实操边界：

图 3.3：反馈升级边界——用于了解何时自行调查以及何时需要工程团队参与。左侧列显示Claude Code的领域（结构和行为问题）：X是如何工作的、哪些文件实现了Y、Z访问了哪些数据。右侧列显示工程领域（质量、性能、生产问题）：X是否安全、为什么Y在生产中很慢、我们是否应该重构Z。

你可以通过Claude Code处理向工程团队升级功能X是如何工作的？功能X是否安全？哪些文件实现了Y？为什么Y在生产中很慢？Z访问了哪些数据？我们是否应该重构Z？配置A在哪里定义？配置A在生产环境中是什么？用户执行B时会怎样？为什么B对某些用户失败？能否将功能C与D结合？我们应该如何构建C+D的集成？E的边缘情况有哪些？我们如何在暂存环境中测试E？

其中的规律是：关于存在什么以及结构如何的问题是Claude Code的领域；关于质量、性能、正确性和生产行为的问题则需要工程团队介入。

这并不会削弱Claude Code的价值，而是将你的使用聚焦在高回报的调查上，同时对AI的局限性保持适当的谦逊。你仍然可以通过自己处理第一轮调查来节省大量工程时间，只是要避免将AI的解释视为神谕般的真理这个陷阱。

现在，你可以在不必依赖工程团队回答每个问题的情况下调查你的代码库了。你理解了如何通过架构总览定位自己、应用功能调查模式、在不阅读代码的情况下构建心智模型、在CLAUDE.md中创建持久化上下文，以及识别何时需要向上反馈。第4章将向你展示如何将这些能力具体应用于bug调查——在这一PM工作流中，代码库的访问能力能带来立竿见影、可衡量的价值。