第12章
与工程团队协作
你已经使用 Claude Code 好几周了。你的 bug 调查更快了，你的功能问题不用中断 sprint 就能得到解答，你的 PRD 引用了实际的实现。然后工程团队也开始使用 Claude Code：相同的仓库、相同的会话、相同的工具。当两个角色在同一个 AI 增强的工作空间中工作时会发生什么？
做得好时，这种重叠能放大双方的角色。PM 调查更快，工程师在交接时获得更好的上下文，共享制品减少沟通错误。做得不好时，它会制造领地摩擦、重复工作和 CLAUDE.md 文件中的冲突指令。本章涵盖 PM 与工程团队 Claude Code 使用的接口：共享什么，何时交接，以及如何维持高效的边界。
12.1 PM 与工程使用的重叠之处
PM 和工程师以不同的方式使用 Claude Code。理解这些差异可以防止相互干扰。
互补的使用模式。工程师使用 Claude Code 编写和修改代码：实现功能、修复 bug、重构系统。他们的会话涉及文件编辑、测试运行和部署任务。PM 使用 Claude Code 进行调查和生成制品：理解实现、综合研究、创建文档。大多数 PM 会话在 plan 模式下运行；大多数工程会话不是。
PM 和工程团队在并行工作流中使用 Claude Code。PM 进行调查、生成制品并在 plan 模式下工作。工程师编写代码、修复 bug 并使用完全访问权限。中间的共享上下文连接双方。
这种自然的分工意味着重叠很少见。一个工程师修改 checkout.service.js 不会与一个 PM 要求 Claude Code 解释 checkout 如何工作产生冲突。PM 读取；工程师写入。不同的工具权限、不同的输出、不同的工作流。
重叠创造价值的地方在于共享上下文。当双方通过同一个工具理解同一个代码库时，交接变成会说同一种语言的人之间的对话。PM 说"我调查了 discount-validator.js:45-78 中的折扣验证逻辑，发现当 cart.hasActivePromotion 为 true 时它会拒绝折扣码。"工程师知道确切要看哪里以及 PM 理解了什么。不需要翻译层。
避免领地冲突。当角色边界模糊时会产生冲突。开始编辑代码的 PM（即使是出于好意）会造成所有权混淆。因为"你不懂代码"而否定 PM 调查发现的工程师会破坏协作。
清晰的边界防止摩擦：
- PM 调查和解释；工程师验证和实现
- PM 建议问题可能在哪里；工程师确认根本原因
- PM 创建产品制品（PRD、发布说明）；工程师创建技术制品（ADR、代码注释）
- PM 使用 plan 模式进行探索；工程师使用完全访问权限进行实现
当你想要越过边界（编辑配置文件、运行数据库迁移、推送一个"简单修复"）时，停下来改为交接。你节省的五分钟不值得造成谁拥有什么的混淆。
共享制品和版本控制。Claude Code 生成的制品供两个角色使用。发布说明、架构文档、功能解释、调查摘要：这些与代码一起存放在仓库中。将它们视为任何其他版本化资产。
Claude Code 创建的文件应遵循现有的仓库规范。如果你的团队使用 docs/ 存放文档，Claude Code 输出放在那里。如果 commit 消息遵循某种格式，保持一致。AI 生成的内容没有什么特殊；它只是需要遵循规则的内容。
使用 git commit 跟踪谁在何时创建了什么。Claude Code 默认在 commit 中添加 Co-Authored-By: Claude
就 AI 辅助工作进行沟通。当你分享调查发现或生成的制品时，对过程保持透明。"我使用 Claude Code 调查了这个问题，以下是我的发现"设定了适当的期望。读者知道要验证技术细节，而不是将其视为权威。
这种透明度是双向的。当工程师使用 Claude Code 生成文档或分析时，他们也应注明。目标不是推卸责任（你仍然对输出负责），而是表明它是如何产生的，以便审查者适当调整他们的审查强度。
12.2 转换工作而不丢失上下文
PM 与工程的边界不是一堵墙。它是一个过渡区。良好的交接使这个过渡顺畅。
PM 调查何时结束，工程何时开始。第四章涵盖了何时停止调查 bug。相同的原则适用于所有 PM 到工程的交接。当你能够解释流程、有一个可测试的假设、识别了相关文件并知道你不知道什么时，你已经收集了足够的上下文。
对于功能调查，当你能够回答你的产品问题时停止。"checkout 如何工作？"在你理解流程到足以做出产品决策时得到回答。你不需要理解每个函数。
对于问题报告，当你有可供工程操作使用的上下文时停止。文件路径、可疑代码区域、复现假设、开放问题。工程从那里接手。
对于制品生成，当你有一个值得审查的草稿时停止。不要无限迭代试图完善发布说明。从工程获取准确性反馈，然后定稿。
交接时机是当额外的 PM 调查收益递减而工程调查收益加速时。你擅长上下文收集和假设形成。他们擅长验证和实现。在拐点处过渡。
PM 到工程的交接工作流。PM 调查阶段包括上下文收集、假设形成和文件定位。中间的交接包记录了触发调查的原因、发现的内容、尚未确定的内容以及需要工程做什么。然后工程处理验证、根本原因分析和实现。
为交接包装信息。为工程消费结构化你的交接：
调查摘要应包括：
- 触发调查的原因（用户报告、产品问题、规划需求）
- 你调查了什么（阅读的文件、追踪的流程、询问的问题）
- 你发现了什么（解释、假设、相关代码位置）
- 你无法确定什么（运行时行为、数据依赖逻辑、配置问题）
- 你需要工程做什么（验证、根本原因确认、实现）
制品的草稿应包括：
- 使用的源材料（git 历史、反馈数据、竞争研究）
- 方法（你使用了什么提示词，Claude Code 分析了什么）
- 开放问题（准确性疑虑、缺失的上下文、需要的验证）
- 请求的反馈（技术准确性、完整性、语气）
糟糕的交接："我觉得 checkout 有个 bug。你能看看吗？"
良好的交接："用户报告扣款但没有订单确认。我调查发现支付处理发生在 payment-processor.js 中，订单创建在之后的 order.service.js 中。如果支付成功后订单创建失败，payment-reconciliation.js 中的对账队列应该捕获它。假设：对账队列未在处理，或者错误未被处理。你能验证队列状态和最近的失败吗？用于调查的客户 ID：[ID]。"
良好的交接通过提供消除发现工作的上下文来尊重工程时间。
将 Claude Code 输出作为对话起点，而非结论。你的调查发现是假设，不是事实。Claude Code 基于静态分析解释代码。它没有运行代码、检查生产数据或咨询原始作者。
相应地框架交接。"我认为这可能是问题所在"而非"这就是 bug"。"代码似乎是……"而非"代码就是……"工程应在行动前验证。
这种框架不是虚假的谦虚。这是准确的认识论定位。你进行了彻底的调查，形成了合理的结论，但你是基于不完整的信息工作的。工程拥有运行时数据、部署上下文和你没有的深层系统知识。他们可能确认你的假设，也可能发现不同的东西。两种结果都是有价值的；错误的是将 PM 调查当作工程分析来行动。
尊重工程专业知识和判断。你为工程节省了数小时的发现工作，但这不让你成为工程师。当他们不同意你的假设时，倾听。当他们解释代码为什么不按 Claude Code 描述的方式工作时，学习。当他们基于你不理解的实现复杂性做出与你预期不同的优先级排序时，信任他们的判断。
PM 代码库调查的目标不是取代工程。而是减少角色之间的沟通负担。你可以在不能实现解决方案的情况下进行有见地的对话。这就是边界。保持在你的一侧。
12.3 维护两个角色都能使用的上下文
CLAUDE.md 文件在多个会话间保持上下文。当多个人在同一个仓库中工作时，维护共享上下文成为协作责任。
两个角色都受益的产品知识。一些 CLAUDE.md 内容为所有人服务：
CLAUDE.md 内容所有权以重叠圆圈显示。PM 特定内容包括研究方法和利益相关者沟通规范。工程特定内容包括构建命令和部署配置。共享中心包含领域术语、架构概览、业务规则和用户旅程到代码的映射。
领域术语防止任何 Claude Code 用户的误解。无论是 PM 在调查还是工程师在实现，知道"credit"意味着内部货币（而不是支付信用）很重要。
架构概览帮助 PM 理解在哪里查找，帮助工程师引导新团队成员。组件边界和数据流的简要描述服务于双方受众。
业务规则和约束属于共享上下文。"折扣码不能与促销活动组合"和"免费层用户限制 5 个工作区"是代码应当遵守的产品规则。两个角色都需要这个上下文。
用户旅程映射到代码帮助 PM 调查，帮助工程师理解更改的产品影响。从"checkout 流程"到"CheckoutForm.tsx → checkout.service.js → payment-processor.js → order.service.js"的映射服务于双方。
PM 特定的内容（研究方法、利益相关者沟通规范）可能属于个人 ~/.claude/CLAUDE.md 或 docs/pm-workflow.md 文件而非共享的 project CLAUDE.md。
将维护准确性作为共同责任。CLAUDE.md 内容会过时。代码路径改变，术语演变，业务规则更新。需要有人维护准确性。
像对待任何文档一样对待 CLAUDE.md。当你发现错误时，修正它。如果 checkout 流程现在在支付和订单创建之间包含欺诈检测步骤，更新用户旅程映射。如果团队将"credits"重命名为"coins"，更新术语。在常规工作中进行小修复可以防止大偏差。
对于重大变化（新产品领域、架构大改、重大术语变更），创建文档任务。不要让 CLAUDE.md 的准确性持续偏离，直到有人注意到 Claude Code 给出了错误建议。
CLAUDE.md 内容的冲突解决。当 PM 和工程的视角在 CLAUDE.md 应包含什么上有分歧时，基于使用模式来解决。
偏好具体性而非全面性。一个有 50 行高价值内容的专注 CLAUDE.md 胜过一份 500 行什么都涵盖的文档。包括改善 Claude Code 响应的内容；排除好但不常用的内容。
偏好准确性而非愿景。记录事物实际如何运作，而非它们应该如何运作。如果代码有技术债务你计划处理，不要将未来状态描述为当前状态。Claude Code 读取代码，冲突的 CLAUDE.md 指令会造成困惑。
偏好共享理解而非角色特定的细节。只有 PM 使用的内容可能不属于共享 CLAUDE.md。只有工程师使用的内容可能也不属于。共享上下文意味着帮助这个仓库中所有使用 Claude Code 的人的内容。
当冲突持续时，尝试两种方法几周，看哪个产生更好的结果。CLAUDE.md 不是不可更改的。它是通过使用来改进的迭代文档。
审查节奏和所有权。季度 CLAUDE.md 审查与其他文档维护节奏对齐。一个人应负责审查：通常是使用 Claude Code 最频繁的 PM，或最理解架构上下文的 tech lead。
审查检查清单：
- 所有文件路径仍然准确吗？
- 任何术语定义改变了吗？
- 用户旅程映射与实现最新同步吗？
- 业务规则有变化需要更新文档吗？
- 有文档化但不再存在的内容吗？
- 有新的应该被文档化的内容吗？
30 分钟的季度审查防止 CLAUDE.md 逐渐变得无用。将它视为任何活文档：通过使用来维护，定期审查，增量更新。
12.4 构建服务整个团队的技能
技能（第八章）在共享时变得更有价值。PM 构建了一个效果很好的反馈综合 skill；工程也能从中受益。工程师创建了发布说明 skill；PM 用于客户沟通。仓库中的 .claude/commands/ 目录存放两个角色都能调用的团队工作流。
服务多个角色的技能。一些工作流使所有人受益：
发布说明生成将 git 历史转化为面向客户的沟通。PM 想要可读的摘要；工程师想要准确的更改归属。一个 skill 以适合受众的输出服务两种需求。
文档审计比较文档与实现。PM 想要知道产品描述是否符合现实；工程师想要发现过时的技术文档。相同的审计逻辑，相同的收益。
架构总结解释代码库结构。PM 用于上手和调查；工程师用于新团队成员上下文和跨团队协作。
将这些共享 skill 存储在 .claude/commands/ 中，使用清晰的名称：generate-release-notes.md、audit-documentation.md、summarize-architecture.md。团队中的任何人都可以用 /project:generate-release-notes 调用它们。
贡献指南。共享 skill 需要一致性：
命名规范使 skill 可发现。一致使用动词-名词格式（generate-release-notes、audit-documentation、analyze-feedback）。
文档要求解释每个 skill 做什么。包含带有目的、预期输入和输出格式的头部注释。第一次遇到该 skill 的人应该在不阅读完整实现的情况下理解其功能。
测试期望确保 skill 在团队采用前可工作。用真实数据运行 skill，验证输出质量，并文档化限制。一个 80% 时间有效且失败模式不清晰的 skill 造成的挫败感大于价值。
版本控制跟踪更改。用清晰的 commit 消息提交 skill 修改。当 skill 行为变化时，团队成员应该能够追溯原因和时间。
共享 skill 的质量标准。在将 skill 添加到共享库之前，验证：
- 它解决一个重复出现的问题吗？一次性任务不需要 skill。
- 它可靠吗？需要不断调整的 skill 还不能分享。
- 它有文档吗？用户应该理解输入、输出和限制。
- 它足够通用吗？只适用于某个 PM 特定工作流的 skill 可以保持个人使用。
共享 skill 的质量标准高于个人 skill。你的个人工作流容忍粗糙边缘，因为你知道那些怪癖。共享 skill 需要对所有人可预测地工作。
弃用和清理。不再使用的 skill 应该被移除。出问题的 skill 应该被修复或弃用。功能重复的 skill 应该被合并。
季度 skill 库审查（与 CLAUDE.md 审查对齐）防止积累破损或未使用的工作流。检查使用情况（git log 显示谁调用了什么），验证当前功能，移除不再服务团队的内容。
Skill 库是团队资产。以与生产代码相同的关心对待它：提交前测试，审查更改，维护质量，弃用不再使用的。
你现在理解了当双方都使用 Claude Code 时如何与工程团队有效协作。互补的使用模式防止领地冲突。清晰的交接协议在高效共享上下文的同时尊重专业边界。共享的 CLAUDE.md 实践维护两个角色都受益的持久知识。团队 skill 库编码服务整个组织的工作流。
第十三章讲解了失败模式：PM 在使用 Claude Code 时常犯的错误以及如何识别你已到达收益递减点。