1.1 选择对的工具，每周能省下好几个小时
有客户反馈你们的结账流程出现了一个严重 Bug。工程团队正埋头冲季度路线图。你需要做分诊（triage）：这是真 Bug 还是用户误操作？影响范围多大？该由哪个团队负责？你只能等工程团队从当前工作中抽身、切换上下文、去排查、再把结论反馈给你。两天过去了。这个 Bug 还卡在分诊队列里。
或者：你在代码仓库里打开 Claude Code，问："结账校验是怎么工作的？给我指出 null 的支付方式可能从哪里漏过去。"10 分钟内你就拿到带文件引用的结果，以及通俗易懂的英文解释。你把排查结论写下来，标注到具体的代码位置。工程团队确认后直接修复，不再需要探索阶段（discovery phase）。总耗时：15 分钟。
这两种场景的差异只有一个：选对了工具。大多数 PM 因为 Claude.ai 用起来熟悉，就默认拿它解决所有问题，然后又疑惑为什么 AI 没有改变自己的工作流。Web 界面确实很擅长对话式任务，但它在 PM 最关键的工作上会失灵：排查代码库、生成要落在仓库里的产物，以及搭建可复用的流程。
你有三种方式使用 Claude：Claude.ai 的 Web 界面、API，以及 Claude Code。API 面向工程师做集成；Claude.ai 和 Claude Code 都适合 PM，但它们解决的是不同问题。选错的代价很高。
Claude Code 是一个具备文件系统访问、可执行 Shell 命令、并能跨会话持久化上下文的智能体（agent）。当你的工作涉及文件、仓库，或需要反复执行的流程时------无论你是否"职业写代码"------这些能力都非常关键。
下面是选错工具的隐藏成本：你在 Claude.ai 里花 30 分钟解释代码库背景，让它分析存放在 CSV 里的客户反馈，再让它输出一份综合文档。它给了你一份很有想法的回复。你把内容复制粘贴到 Google Doc。两周后你要对新一批反馈做同样分析，你只能从头开始：同样 30 分钟的背景解释、同样手动导出、同样复制粘贴。你已经在同一类任务上花了 1 小时，而 Claude Code 可以用一个可复用的"技能"（skill）在 5 分钟内完成。
图 1.1：工作流对比------用它来理解"选错工具"的隐性成本。左侧：手工复制粘贴的工作流，每次都要重复提供上下文、手动导出、手动重排格式。右侧：基于技能的自动化，初始化只做一次，后续每次运行 5 分钟而不是 30 分钟。
再比如：你需要理解结账流程到底怎么跑，因为来了一个严重 Bug 报告。你问工程，但他们在做 Sprint Planning。你试 Claude.ai，但你无法上传整个代码库，缺少上下文时，它的回答就会很泛。你只能继续等。工程团队明天给你回复，这个 Bug 又在分诊里多躺一天。要是你用的是 Claude Code，你 10 分钟就能拿到一个"根因假设"（root cause hypothesis），而且带上具体涉及的文件和函数引用。
工具选择的问题，本质在于任务的可持续性（persistence）与数据可访问性（data access） 。当工作内容落在文件里、需要迭代、或会反复发生时，Web 界面会强迫你做越来越多的手工开销，而且每次重复都会叠加。Claude Code 通过直接在你的工作区里运行，把这些开销消掉。
多数 PM 都是通过"浪费"才意识到这一点的：他们先用 Claude.ai 用了几周，才发现自己在每段对话里反复粘贴同样的背景、手工重排输出格式、重复做本该自动化的工作。切换成本看起来很高：安装、学命令、理解权限模式。但浪费的成本更高，而且是悄无声息地持续累积。
这个决策并不取决于你有多"技术"。它取决于：你的工作是否涉及你会反复触碰的文件，还是一次性问题。你诚实回答这个问题，工具就会自己选出来。
1.2 Claude Code 如何工作：从"对话"到"自主执行"
Claude Code 是一个 agentic runtime （智能体运行时）。对产品经理来说，这意味着 Claude 不只是"回答"，而是能够"行动"。你问 Claude.ai，它思考并回答；你问 Claude Code，它会思考、读文件、跑命令、生成产物、检查结果，然后再回答。差异在于：自主性（autonomy） 。
这很重要，因为 PM 的工作大量是把分散的信息做综合：需求在 Jira，客户反馈在 Zendesk 导出文件里，实现细节在代码库，市场调研在书签 URL 和凌乱笔记里。想得到一个连贯答案，手工把这些拼起来会烧掉大量时间。
Claude Code 在你的项目目录里工作，具备五项 Claude.ai 本质上没有的能力。理解这五项能力，就能判断你什么时候需要"智能体"，而不是"对话"。
图 1.2：五项核心能力------用它来理解 Claude Code 能做而 Claude.ai 做不了的事：文件系统读写、Shell 命令执行、通过 CLAUDE.md 持久化项目上下文、通过子智能体并行处理、通过 MCP 连接外部系统。这些能力支撑代码库排查、产物生成与可复用工作流。
- 文件系统读写访问
Claude Code 能打开你项目里的任何文件，读取、理解，并写入新文件或修改现有文件。听起来很基础，但 Claude.ai 需要你把内容全都复制粘贴进去。想在分析反馈时引用一份 PRD？用 Claude.ai，你得粘贴 PRD、粘贴反馈、让它综合，再手动保存输出。用 Claude Code，你只要指向docs/prd.md和data/feedback.csv，它会把analysis/synthesis.md直接生成到仓库里。没有剪贴板、没有手工排版、也不会因为粘贴失误引入错误。
对 PM 来说，这意味着排查结果会落在它该落的地方：版本库里，和它引用的代码放在一起，团队可读、可评审、可迭代。你的代码库分析可以变成一个工程同事能直接读、评论、更新的 Markdown 文件。
- Shell 命令执行
Claude Code 能运行终端命令。对 PM 而言，最常用的是 Git 操作（看历史、比对分支、查谁改了什么）以及运行你不会亲自写、但能描述需求的分析脚本。
一个具体例子：你想知道某个功能是什么时候引入的、是谁做的。你可以找工程师跑 git log 并解释结果，也可以直接问 Claude Code："结账流程的两步验证是什么时候加的？当时的理由是什么？"它会自己跑 Git 命令、读相关 commit 和 diff，然后把"故事线"讲清楚。无需打断工程师。
这等于把终端能力用自然语言"外包"出来，不需要你具备终端专家级技能。
- 通过 CLAUDE.md 持久化项目上下文
每次打开 Claude.ai 你都得从零开始。每次在项目目录启动 Claude Code，它会读取（如果存在）CLAUDE.md：一个用于跨会话保存项目特定上下文的文件。
对 PM 来说，这个文件可以放：产品领域术语表、关键用户旅程到代码区域的映射、团队约定、外部文档链接、常见排查问题的答案。你把上下文搭一次，以后每次会话都"开箱即懂"。不再需要每次都先解释"我们产品是什么、怎么做的"。
这就是"聪明助理"和"团队成员"的差别：团队成员有上下文。维护良好的 CLAUDE.md 能让 Claude Code 也具备上下文。
- 子智能体（subagent）生成
Claude Code 可以启动额外的 Claude 实例并行处理子任务或进行专门化分工。作为 PM，你很少需要显式调用，但它是复杂工作流的底层能力。
例子：你让 Claude Code 做一份竞品分析，比较三个竞品在功能、定价、定位上的差异。它可以并行启动三个子智能体（每个竞品一个）同时研究，然后把结果汇总成对比矩阵。原本你要 3 小时不断切 Tab 才能完成的事，可能 10 分钟搞定。
这里确实有成本（你同时运行多个 Claude 实例），但对于高价值研究任务，节省的时间常常足以覆盖成本。
- 通过 MCP 集成外部系统
Model Context Protocol 让 Claude Code 连接外部工具：Jira、Slack、Figma、数据库、分析平台等。这是最新也最不必急着上手的能力，但它能消灭最拖慢节奏的"导出---导入"循环。
与其把 Jira 工单导出成 CSV、上传到 Claude.ai、再把结果复制回去，Claude Code 可以直接查询 Jira、就地分析、再把结论回写到工单里。工作流保持在同一环境中。第 10 章会细讲；现在你只需要知道：这条路是通的，而且很强。
这五项能力有一个共同模式：消灭"思考"和"执行"之间的手工交接。Claude.ai 负责思考，你负责执行；Claude Code 既思考也执行，然后把结果交给你审批。一锤子买卖的问题，两者都行；可复用的 PM 工作流，会明显受益于这种自主性。
Claude Code 的底层机制是所谓的 agent loop（智能体循环）。你给它一个目标，它会规划路径，执行一步（读文件、跑命令、生成产物），观察结果，判断要不要继续迭代，最后汇报。
图 1.3：智能体循环------用它来理解 Claude Code 如何运作：持续循环------接收目标 → 制定方案 → 执行一步（读文件/跑命令/生成产物）→ 观察结果 → 决定迭代或停止 → 汇报结果。正因为这个循环，Claude Code 的会话体验才会和 Claude.ai 的对话不同：你是在看一个智能体"做事"。
这也是为什么 Claude Code 的会话一开始会显得"啰嗦"（比如"我现在要读这个文件"）：它在建立信任。你能在它真正改动之前看到它要做什么。
对习惯了"要么全手工、要么全黑盒"的 PM 来说，这种中间态需要适应：Claude Code 一边展示过程，一边把事做完。你保留对关键动作的否决权，它则承担具体执行。
总之：Claude Code 是一个具备工作区访问与持久化能力的智能体。模型本身和 Claude.ai 可以是同一个，但能力不同：文件操作、Shell 命令、上下文保留。正因为这些能力能解决 PM 的特定问题，下一节才会给出一个决策框架，帮助你选对工具。
1.3 决定什么时候用哪种工具
在 Claude.ai 和 Claude Code 之间做选择，归根结底就是三个问题：这个任务是否需要读取或写入文件？你是否还会再做一次这个任务？输出结果是否需要进入版本控制（version control）？只要其中任何一个答案是"是"，就从 Claude Code 开始。如果三个答案全是"否"，用 Claude.ai。
大多数 PM 恰好反过来：因为 Claude.ai 熟悉，就默认用它，然后在需要引用文件或重复跑一个流程时才发现阻力。起手就选对工具，能省掉后面迁移的成本。
图 1.4：工具选择决策树------用它来为每个任务选对工具。三个问题：是否需要文件？是否会再做一次？输出是否需要版本控制？任意"是"→ Claude Code；全部"否"→ Claude.ai。不确定时，默认用 Claude Code 的只读模式。
下面是 12 个常见 PM 场景的参考表。把这一页加书签。
| 任务 | 工具 | 理由 |
|---|---|---|
| 起草给干系人的邮件 | Claude.ai | 一次性的对话任务，不需要文件 |
| 在能访问代码库的前提下排查 Bug 报告 | Claude Code | 需要读代码、看 git 历史、产出可落地的文档/产物 |
| 头脑风暴功能点 | Claude.ai | 探索式对话，不需要持久化 |
| 分析客户反馈 CSV | Claude Code | 有文件输入、需要结构化输出、很可能可复用 |
| 基于文档解释技术概念 | Claude.ai | 快速问答，不涉及文件操作 |
| 基于 git 历史生成发布说明（release notes） | Claude Code | 需要跑 git 命令、输出文件、每月可重复 |
| 基于调研笔记写 PRD 某一段 | Claude.ai | 如果笔记在你脑子里；如果在文件里则用 Claude Code |
| 理解功能 X 是怎么实现的 | Claude Code | 需要在代码库里导航，并依赖上下文持久化 |
| 竞品功能对比 | Claude Code | 如果要重复做；一次性的可以用 Claude.ai |
| 综合用户访谈逐字稿 | Claude Code | 多文件输入、需要结构化输出成产物 |
| Review 并给 API 文档提改进建议 | Claude Code | 需要读仓库内文档，并提出文件级修改建议 |
| 从零生成用户画像（persona） | Claude.ai | 初稿是对话式的；如果依赖数据驱动则用 Code |
规律是：Claude.ai 用来"思考"，Claude Code 用来"做事" 。凡是需要把输出再复制到别的工具里的任务，通常都更适合 Claude Code。
"我会不会再做一次？ "这个启发式规则是最快的决策法。如果你要每周跑一次分析、每月出一次报告，或反复排查同类型问题，那么 Claude Code 的初始化成本会立刻回本。即便第一次会更慢（学命令、把提示写结构化、把 skill 保存下来），第二次也会快 10 倍。
PM 往往系统性低估"重复性"。你以为自己只是做一次竞品分析，但实际上你是在建立一个季度复盘流程。你以为自己只写一个 user story，但实际上你是在定义一个接下来要用 50 次的模板。只要有任何可能会重复，偏向 Claude Code，现在就把可复用流程搭起来。
反过来，如果这件事确实就是一次性的（比如起草某条具体消息、探索一个很模糊的概念、要一个快速答案），Claude.ai 更快：零配置、无学习曲线，直接问完就走。只有当你能摊销启动 Claude Code（进入目录、授予权限、规划文件输出）的开销时，这些动作才划算。
当你真的不确定时，默认用 Claude Code 的只读模式 。用 --permission-mode plan 标志启动，它会阻止任何修改。你先问问题；如果 Claude Code 的回答涉及"我会去读这些文件并生成这个产物"，说明你在用对工具；如果答案完全是对话式、没有任何文件引用，那本来用 Claude.ai 也行。久而久之，这种校准会变成本能。
有一个边界情形：协作型工作 。如果输出需要工程评审、要放进仓库，或要喂给 CI/CD 流程，不管是否重复，都必须用 Claude Code。把排查总结放在 docs/ 里、并和引用的代码放在一起，比把同样内容丢在 Slack 线程里更有价值。基于文件的产物能长期保留、能链接到特定 commit、也能自然融入团队工作流；对话输出则会消失。
这个框架的目的，是把工具能力和任务需求匹配起来。两个工具用的是同一个模型，差异在于文件访问、命令执行和持久化。绝大多数 PM 工作都涉及文件、迭代和协作。Claude.ai 能优雅覆盖大约 30% 的 PM 用例，而 Claude Code 覆盖另外 70%------也就是那些真正改变你工作方式的部分。
1.4 三类 PM 用例必须用 Claude Code
有三类 PM 工作离不开 Claude Code 的能力。只要你的任务落在其中任何一类，选择就已经定了。
图 1.5：三类 PM 用例------用它来识别 Claude Code 何时是"必需品"：代码库排查（不用读懂代码也能理解实现）、上下文型产物生成（能引用并与代码同步的文档）、可重复工作流（把周期性的 PM 流程编码成 skill）。只要涉及任何一类，Claude Code 就会变成关键基础设施。
代码库排查（codebase investigation） 。你需要理解某件事怎么工作，但你不擅长读代码，而工程团队有更高优先级。这是 PM 使用 Claude Code 的经典场景。
客户反馈：折扣码本不该叠加，却叠加了。工程团队正埋头冲季度目标。你需要分诊：这是 Bug 还是用户误操作？如果是 Bug，严重程度如何？影响范围可能多大？
在仓库里打开 Claude Code，问："折扣码校验是怎么做的？指出多张折扣可能在一次订单里被应用的路径。"几分钟之内，你就能拿到文件引用、用大白话解释的函数逻辑，以及对 Bug 的一个假设。你把排查结论写下来，标注具体代码位置。工程团队看到报告后确认问题并修复，不再需要传统的探索阶段。PM 总耗时：15 分钟。工程节省的时间：至少 1 小时排查 + 多轮来回澄清。
这种模式会不断重复："认证怎么做的？""支付失败会发生什么？""应用在哪里检查订阅状态？"这些问题都需要读代码、追数据流、理解实现细节。Claude Code 把这些能力通过自然语言问答提供给你。
而且输出会落在 docs/investigations/ 或关联工单旁边。未来的你在遇到类似问题时会受益；未来的队友也能从文档化的"机构知识"（institutional knowledge）里受益。排查变成了一个"产物"，而不是一段消失的对话。
上下文型产物生成（contextual artifact generation） 。你需要写一份会引用代码库、引用外部调研、或必须随代码变化保持同步的文档。这个文档的价值来自它与仓库的集成。
例子包括：PRD 引用当前 API 能力并链接到相关文件；从 git 历史和 Jira 工单生成发布说明，用你的产品口吻写；按季度更新、固定结构、并放在 research/competitors/ 下的竞品分析；随着实现演进而持续更新的文档。
Claude.ai 当然也能写这些文档，但你得手动提供上下文、手动保存输出、当东西变化时再手动更新。Claude Code 则能直接读仓库内容，通过 MCP 拉外部信息，在原地生成产物，并在下一次更新时复跑同一工作流。
第一次季度竞品分析，可能要花 30 分钟把它搭成一个 skill；第二次运行只要 5 分钟；第三、第四、第五次也都是 5 分钟。你就建立了一个可复用流程，输出一致，并且文档在版本控制里，团队能看到它的演进过程。
可重复工作流（repeatable workflows） 。你会规律性地做同一类事情：每周反馈综合、每月发布规划、每季度路线图更新、针对每个功能写 user story。输入会变，但过程相对稳定。
这里就是 skill 发挥作用的地方。skill 是一个存放在 .claude/skills/ 里的"文档化工作流"，Claude Code 可以按需执行。你把流程定义一次：需要哪些输入、执行哪些步骤、输出格式是什么、质量标准是什么。然后你只要调用它："对 data/customer-feedback-nov-2024.csv 运行 feedback-synthesis。"Claude Code 就会把整个流程跑完。
没有 skill，你每次都得重复同样的指令（解释分类口径、输出格式、综合深度）。有了 skill，流程被编码了：你只管提供输入、审阅输出。认知负担从"回忆上个月我到底怎么做的"变成"跑一下那个流程"。
第 8、9 章会深入讲 skill。现在你只需要知道：如果一件事你要做超过两次，就值得考虑做成 skill；通常第三次运行开始，你就能把投入赚回来。
这三类用例（代码库排查、上下文型产物生成、可重复工作流）覆盖了 Claude Code 对 PM 的大部分高价值应用。如果你的工作完全不涉及它们，Claude.ai 可能就够了；如果三类都涉及，Claude Code 就会变成必不可少的基础设施。
1.5 开始之前先看清取舍
Claude Code 能解决真实问题，但它也会带来 Claude.ai 避开的成本与约束。
学习曲线。 你需要安装它、理解权限模式、学习基础命令，并形成"什么时候该用哪种能力"的直觉。这需要数小时的上手练习。Web 界面不需要安装，打开就能用。对那些偶尔需要 AI 帮助、但很少接触代码仓库的 PM 来说，切换成本可能大于收益。
你会觉得第一周很低效。你会在命令上手忙脚乱，想用只读模式时却忘了设置，还会怀疑到底值不值得。到第二周------前提是你用在了合适的任务上------效率提升会开始变得明显。到第四周，你会开始不情愿再用 Claude.ai，因为相比之下它会显得"受限"。但最开始那几次会话，确实就是尴尬且别扭。
成本可见性与预算。 Claude.ai 是订阅定价：每月固定费用，在速率限制内可不限量使用。Claude Code 走 API 计费（按消耗的 token 付费）。对"探索型"PM 工作而言，token 消耗可能难以预测。读一个大型代码库、同时拉起多个子智能体、或做复杂的综合任务，都可能在你不知不觉中烧掉月度预算------而订阅模式会把这种波动"遮住"。
第 2 章会详细讲成本管理。简版建议是：典型 PM 用量按每月 50--150 美元 做预算；每次会话后用 /cost 监控；当成本开始上升时用 /compact 压缩上下文。如果你对可变成本不舒服，或者你没有预算权限，那么尽管 Claude.ai 有局限，固定价格可能更适合你。
企业落地。 很多组织会限制 API 访问，对具备文件系统访问权限的工具要求安全评审，或禁止连接外部服务。Claude Code 需要 Anthropic API Key，并且会在本地文件权限下运行。如果你们公司的安全策略不允许，那你只能用他们批准的官方工具（通常就只剩 Web 界面）。
这不是 Claude Code 自身的限制，而是企业 IT 治理的现实。推动合规使用是可行的------尤其是你先在个人项目上证明价值------但要预期审批流程会以"周"为单位推进。
什么时候 Claude.ai 确实更好。 快速问答、头脑风暴、你把内容粘贴进去想要对话式反馈的草稿评审；以及任何探索性工作------你还没定义清楚输出长什么样、也不需要文件操作。Web 界面打开更快，不需要在权限上花脑力，也不需要安装，任何设备都能用。
如果你发现自己用 Claude Code 去做那些更适合 Web 界面的任务，那说明你优化错方向了。两个工具同时存在，是因为它们分别服务不同需求。别强行把所有事情都塞进你更偏好的界面里；每个任务选对工具就好。
1.6 "两种工具"的心智模型
两种工具，同样的智能，不同的能力。选择应基于任务需求，而不是哪个界面更熟悉。
Claude.ai：对话式助手。 你说，它答。每次对话都从零开始。输出留在对话记录里，除非你手动复制到别处。适合用来把问题想清楚、拿一个快速答案、起草不需要和文件或仓库集成的内容。零配置成本、零学习曲线、订阅固定价格。
Claude Code：具备工作区访问能力的自主智能体。 你给目标；它会读文件、跑命令、生成产物，并汇报结果。对话会基于 CLAUDE.md 的项目上下文持续累积。输出会落在你的文件系统里，可纳入版本控制、团队可访问。适合代码库排查、产物生成、可重复工作流。需要安装与学习、API 成本可变、认知开销更高。
决策框架如下：
- 这个任务涉及文件吗？→ Claude Code
- 我会再做一次这个任务吗？→ Claude Code
- 输出需要落到仓库里吗？→ Claude Code
- 这是一次性的对话任务吗？→ Claude.ai
- 我是在没有明确输出的情况下做头脑风暴吗？→ Claude.ai
大多数 PM 都会经常两种工具都用：Claude.ai 解决约 30% 的任务，Claude Code 解决剩下的 70%。真正的错误，是因为 Claude.ai 更省事就拿它干所有活，然后又疑惑为什么 AI 并没有真正改变你的工作流。能改变工作流的，往往是那些"产物很重要、重复很重要、与仓库集成很重要"的流程。
Claude Code 正是为这些流程而生。这也是这本书存在的原因：教你识别这些流程、把它们搭对，并随着时间推移让价值复利增长。第 2 章会讲安装与安全。我们开始把你跑起来。