第13章
失败模式与边界
你已经读了十一章关于 Claude Code 能做什么的内容。本章讲述什么地方会出错、何时该停下、以及 PM 使用的边界在哪里。每个工具都有局限。在撞到它们之前就知道，比通过代价高昂的错误来学习更便宜。
从 Claude Code 中获得持久价值的团队都有一个模式：他们快速失败，识别失败模式，并调整。挣扎的团队不断撞到同一堵墙，因为他们没有识别出模式。本章命名这些模式，以便你能打破它们。
13.1 常见的 PM 失败模式
五种失败模式是大多数 PM 对 Claude Code 感到挫败的原因。每种都是可预测的，每种都有警告信号，每种都有直接的补救方法。
PM 使用 Claude Code 的五种常见失败模式
13.1.1 需求文档倾倒
表现：你将整个 PRD 粘贴到 Claude Code 中，要求它"实现这个功能"或"为所有内容创建用户故事"。回复要么流于表面、过于笼统，要么 Claude Code 提出太多澄清性问题，你做的工作比自己写故事还多。
为什么失败：Claude Code 最适合专注的、有范围的请求。一份 15 页的 PRD 包含数十个隐含的决策、未声明的假设和你脑海中的上下文。全部倾倒并期待奇迹只会产出垃圾。
模式：大输入加模糊指令产生大输出加模糊效用。
修复方法：将 PRD 分解为具体的、可操作的请求。"为第 3.2 节描述的认证流程创建用户故事"是有范围的。"基于第 5 节中的错误处理需求，识别 src/errors/ 中哪些现有错误消息需要更新"将 PRD 与代码库调查结合了起来。逐节处理 PRD，每一步都获得有用的输出，而不是指望一次大规模综合。
警告信号：你的提示词超过 500 字，而你的指令少于 20 字。翻转这个比例。
13.1.2 对代码分析过度自信
表现：Claude Code 解释了你的代码库中认证是如何工作的。你将这个解释当作事实带给工程团队。工程指出分析遗漏了一个关键的中间件层，或误解了一个异步模式，或描述的是已弃用的流程而非当前流程。
为什么失败：Claude Code 静态地读取代码。它看不到运行时行为、依赖配置的路径或哪些代码路径在生产中实际被使用。它也不知道代码库的哪些部分是积极维护的，哪些是没人碰的遗留垃圾。它的分析通常是正确的，但"通常"不是"总是"。
模式：静态分析被当作运行时真相，产生自信但错误的结论。
修复方法：将 Claude Code 的分析框架为假设，而非结论。当你与工程分享发现时，使用这样的语言："根据我的调查，认证流程似乎是这样工作的。你能确认吗？"这邀请纠正，而不是迫使工程师反驳你。你的调查通过缩小问题空间来增加价值，而不是通过提供最终答案。
警告信号：你即将仅基于 Claude Code 的代码分析做出产品决策或承诺，而没有工程验证。停下来先验证。
13.1.3 上下文耗尽
表现：你进入会话三十分钟了。Claude Code 的回复变得不太连贯。它开始建议你已经尝试过的东西。它"忘记"了之前读过的文件。它引用了会话早期不正确的细节。
为什么失败：你发送的每条消息和 Claude Code 读取的每个文件都在上下文窗口（一个保存你整个会话的 200,000 token 缓冲区）中累积。随着上下文填满，Claude Code 必须总结或丢弃较早的内容来容纳新内容。重要细节在压缩中丢失。
上下文如何在一个会话中累积以及质量如何下降
现代 Claude 模型不会静默截断你的上下文。它们返回错误而不是隐蔽地降级。但在达到那个硬限制之前，质量会随着上下文填满而下降。用户报告 Claude 在上下文压缩后变得"明显更笨"，忘记它在检查哪些文件，重复会话早期已经做出的纠正。
模式：长会话累积上下文直到连贯性下降，然后下降加速。
修复方法：主动使用 /clear。为不相关的任务启动新会话，而不是继续一个马拉松式的单次会话。如果你需要继续而上下文很大，使用 /compact 并指定要保留的内容：/compact Focus on the authentication flow analysis; discard the earlier database investigation.
警告信号：
- /cost 显示上下文接近 150,000+ token
- Claude 重复你已经拒绝的建议
- Claude 问你已经回答过的问题
- Claude 错误引用文件或将不同代码路径混淆
13.1.4 工具错配
表现：你在用 Claude Code 回答一个 Claude.ai 同样能处理的问题。你启动了一个会话，等待启动，输入你的问题，等待它并不需要的文件扫描，得到的是一个不需要任何代码库访问的答案。你花了两分钟完成一个在 Claude.ai 中只需三十秒的任务。
为什么失败：Claude Code 的优势在于文件系统访问、代码库调查和制品生成。对于不需要这些能力的问题，它增加了开销而没有价值。在不必要的 Claude Code 会话中花费的每一分钟，都是没有花在真正需要这个工具的工作上的一分钟。
模式：将 agentic 工具用于对话式任务，产生摩擦而没有收益。
修复方法：在启动 Claude Code 之前，问自己："这个任务需要读取文件、生成制品或执行命令吗？"如果不需要，使用 Claude.ai。第一章的决策矩阵适用于你整个使用过程，而不仅仅是初始采用时。
更适合 Claude.ai 的常见 PM 任务：
- 头脑风暴功能创意
- 优化演示文稿要点
- 编辑邮件草稿
- 解释一般概念（非代码库特定）
- 不需要文件输出的快速竞争研究
警告信号：你将 Claude Code 作为默认 AI 界面使用，而不是基于任务匹配来选择。将工具匹配到任务。
13.1.5 技能过度工程
表现：你花了三个小时构建一个用于生成季度业务回顾的综合 skill。它有五个参考文件、一个复杂的输出模板，并处理了你想到的边缘情况。你只用了它一次。下个季度，需求变了，skill 需要重新修改，花费的时间比从头创建 QBR 内容还长。
为什么失败：Skill 通过重复使用提供 ROI。一个需要两小时构建、每次使用节省三十分钟的 skill 需要四次使用才能回本。如果任务频繁变化，或者你每年只做一次，skill 永远无法收回创建成本。
模式：为一次性任务构建基础设施，产生维护负担而没有效率增益。
修复方法：在构建 skill 之前应用"三次"规则。这个任务你已经做了至少两次了吗，并且下个季度你至少还会再做一次吗？如果不是，使用提示词模板代替。将提示词保存到文本文件以备将来参考，而无需 skill 结构的开销。
警告信号：你兴奋地在真正手动完成底层任务之前构建 skill。先手动做。理解什么会变、什么不变。然后（也许）将其编码为 skill。
13.2 知道何时你已经榨取了可用价值
每个会话都有自然的生命周期。超过它只是浪费时间和 token 而没有额外价值。
你已经榨取可用价值的信号：
答案开始重复。Claude Code 用不同的措辞重述已经告诉过你的事情。你在问同一个问题不同变体，希望得到新洞察。代码库中没有更多洞察了。你已经找到了那里有的东西。
你理解了问题的轮廓。你能解释相关代码区域、数据流、潜在的故障点。你可能不理解每一行，但你可以与工程进行有见地的对话。进一步调查的边际回报很小。
你的问题变得比代码库能回答的更具体。你在问"团队为什么选择这种方法？"或"如果 10,000 个用户同时这样做会怎样？"这些问题需要人的上下文或生产测试，而不是代码阅读。Claude Code 已经给了你静态分析能提供的一切。
你的假设是可测试的。你对 bug、架构或实现有一个具体的理论。下一步是通过工程审查、测试或生产观察来验证，而不是更多调查。
"再一个提示词"陷阱：在有价值的调查之后，有一种再问一个问题、再探索一个文件、再获取一个摘要的诱惑。有时这能带来价值。但更多时候，它是伪装成彻底的拖延。你已经有足够的信息来行动，但你只是还没有准备好行动。
自我测试：如果有人现在问你"你学到了什么？"你能给出一个连贯的答案吗？如果能，你很可能已经有足够的信息了。记录你的发现并继续前进。
会话时长指南：
| 任务类型 | 典型有用时长 | 何时停下 |
|---|---|---|
| 快速问题 | 2-5 分钟 | 第一个有用的答案 |
| 功能调查 | 15-30 分钟 | 你能解释流程 |
| Bug 分类 | 20-40 分钟 | 你有一个可测试的假设 |
| 研究综合 | 30-60 分钟 | 主题已识别并文档化 |
| Skill 构建 | 45-90 分钟 | Skill 持续产生有用输出 |
| 深度代码探索 | 60-90 分钟 | 每个提示词的新信息递减 |
如果你超过这些范围而没有获得明确的价值，你很可能处于收益递减中。长会话并非本质上是坏事；有些调查确实需要深度。但如果你到了九十分钟仍然没有找到答案，答案可能不存在于代码中，或者你问了错误的问题。
何时重新开始：在以下情况使用 /clear 并开始新会话：
- 你完成了一个任务并开始一个不相关的任务
- 出现上下文耗尽的症状
- 你走上了一条无成效的路径，想尝试不同的方法
- 你的提示词变得又长又绕，试图提供 Claude 已经"应该"拥有的上下文
- 会话开始以来超过两小时
重新开始只会花费你重新定位的三十秒。继续一个降级的会话则要花费持续的挫败感和日益加重的困惑。
13.3 属于工程领域的任务
无论工具如何，有些任务超出了 PM 的范围。Claude Code 不改变谁拥有什么。它改变的是你在你的范围内工作的效率。
PM 领域与工程领域之间的边界
13.3.1 需要工程所有权的任务
编写生产代码。Claude Code 可以生成代码。它甚至可以生成能工作的代码。但运行在生产环境中的代码需要工程审查、测试和所有权。即使你能直接合并代码，你也不应该。问题不在于能力；而在于问责制。当那段代码在凌晨 3 点出故障时，被呼叫的是工程师，不是你。
架构决策。你的调查可能发现认证系统很绕，或数据库 schema 不够优化。Claude Code 甚至可能建议改进方法。这些是工程决策的输入，而不是决策本身。架构选择有长期后果，需要工程判断。
性能优化。Claude Code 的静态分析可以识别潜在的性能问题，但不能测量实际性能。优化需要对生产负载进行性能分析、理解使用模式以及做出影响系统行为的权衡。工程拥有这一块。
基础设施变更。部署配置、数据库迁移、服务器供应：这些是工程领域。Claude Code 可以帮助你理解现有基础设施或起草关于它的文档，但更改它需要工程所有权。
13.3.2 你应始终升级处理的安全工作
认证和授权审查。如果你在调查认证流程或访问控制逻辑，你的发现是安全审查的假设，不是结论。安全 bug 可能暴露客户数据、损害声誉并产生法律责任。即使 Claude Code 的分析看起来正确，安全审查必须涉及专家。
密钥和凭据的处理。Claude Code 可能揭示你的应用如何存储 API key 或管理 token。这些信息是敏感的。不要大范围分享。如果你发现潜在的安全问题（硬编码的密钥、不足的加密），升级给工程和安全团队。不要试图修复。
合规相关代码。如果代码涉及合规要求（GDPR、HIPAA、SOC 2、PCI DSS），Claude Code 的分析是合规审查的输入，不是替代品。合规错误会产生监管后果。
13.3.3 为什么生产环境访问是禁区
对生产数据的数据库查询。第十章讲解了数据库 MCP 集成，并给出了明确指导：使用只读副本，绝不用生产数据库。即使对生产数据库的读操作也可能导致性能问题，任何写操作都可能破坏数据。Claude Code 能生成 SQL 的能力并不意味着它应该在生产环境上执行。
生产日志和监控。如果你需要读取生产日志进行调查，通过你组织既定的访问模式来读取，而不是通过 Claude Code MCP 连接。生产环境访问通常需要 Claude Code 会绕过的特定权限和审计追踪。
实时客户会话。调试客户问题可能引诱你访问他们的实际数据。不要。使用匿名化的导出数据、测试账户或 staging 环境。客户数据访问有隐私影响，不管你的意图如何。
13.3.4 在分析中保护隐私
分析中的 PII。当你将客户反馈提供给 Claude Code 进行综合时，先去除个人身份信息。姓名、电子邮件地址、电话号码：在处理之前删除。Claude Code 的分析不会因 PII 而改善，你也能避免隐私风险。
原始支持工单。支持工单通常包含客户姓名、账户详情和敏感信息。提取相关内容（bug 报告、功能请求）而不带识别包装。你的综合是关于模式，而非个人。
出口管制。如果你的产品服务于受监管行业，了解什么数据可以被外部 AI 服务处理。一些组织禁止将某些数据类型发送给云 AI 提供商。本地运行的 Claude Code 与 API 调用不同，但请与你的法务和安全团队确认。
13.3.5 满足监管要求
审计追踪。Claude Code 会话存储在本地机器上。如果你的组织对某些决策或文档要求审计追踪，Claude Code 的会话历史可能不满足这些要求。将输出捕获到你组织的官方记录系统中。
更改文档。如果你使用 Claude Code 生成影响产品决策的文档（PRD、用户故事、需求），这些文档应经过你正常的审查和批准流程。Claude Code 生成了草稿；你对内容负责。
受监管的沟通。一些行业要求客户面向文档有特定格式或审查流程。Claude Code 可以帮助起草内容，但内容在发布前必须经过既定的批准工作流。
13.4 使 Claude Code 长期奏效的习惯
在数月数年里有效使用 Claude Code 需要习惯，而非英雄行为。
每周使用回顾。每周花十分钟回顾：
- Claude Code 帮助了什么任务？
- 什么做得好？什么令人沮丧？
- 我碰到了任何失败模式吗？哪些？
- 我的 skill 仍然准确吗？还是需要更新？
这种反思会产生复利。一个月后，你会识别出你的个人模式：Claude Code 擅长什么任务、你容易陷入什么失败模式、值得维护什么 skill。没有反思，你会无限期地重复错误。
成本监控习惯。对于 API 用户：第一个月每周检查你的 Anthropic 仪表板，之后每月检查。对于订阅用户：在会话结束时偶尔检查 /cost 来了解你的使用模式。两组用户：审查支出是否与获得的价值对齐。如果成本相对于价值显得高，你在用 Claude Code 做错误的任务。如果成本相对于价值显得低，你可以更主动地使用它。
Skill 维护计划。Skill 会腐烂。你的代码库变化，需求演变，更好的方法出现。每个季度审查每个 skill：
- 这个 skill 仍然产出有用的输出吗？
- 它自动化的任务有显著变化吗？
- 它可以简化或与其他 skill 合并吗？
- 它应该被淘汰吗？
Skill 是一种投资。像所有投资一样，它们需要维护才能保持有价值。
紧跟 Claude Code 更新。Claude Code 定期更新，带来新功能、行为变化和改进的模型。每月检查 changelog（code.claude.com/changelog 或 CLI 中的发布说明）。新功能可能解决你目前正在绕弯子的问题。行为变化可能破坏你依赖的工作流。
如果可用，订阅更新频道。当你遇到意外行为时，在假设你做错了什么之前，先检查是否有最近的更新。
可持续的节奏：每周反思，每季度 skill 审查，每月更新检查。这些习惯每月总共花费三十分钟。它们防止你个人 Claude Code 使用中技术债务的积累：过时的 skill、重复的错误、错过的能力。
你现在知道了五种常见的 PM 失败模式及其补救方法，如何识别收益递减以及何时停下，PM 使用在哪里有硬边界，以及如何建立可持续的长期实践。本章不如关于能力的章节那么令人兴奋，但知道何时停下以及何处不应该去，正是区分有效用户和挫败用户的关键。
这完成了第六部分和本书的主要内容。接下来的附录提供了参考资料：命令语法、skill 模板、CLAUDE.md 示例文件以及供你工作中快速查阅的提示词模板。