播客摘要：对话 Cat - Claude Code 产品负责人

• Claude Code 最初是工程师 Boris 为了更好地理解公司 API 和探索软件工程增强能力而开发的个人项目。
• 产品负责人 Cat 最初作为 20% 时间的贡献者，发现该工具能极大提升自己添加 RL 环境的效率，并提供了大量产品反馈。
• 该工具在内部迅速传播（病毒式传播），从工程团队扩展到研究、数据科学、产品管理等技术邻近角色，在公开发布前就已获得高度认可。
• 核心产品原则：
  1. 简洁至上 (Simplicity)： 利用终端（Terminal）作为极简的交互界面，迫使团队对展示哪些功能做出“残酷”的选择，避免用户初次使用时感到不知所措。
  2. 无缝上手 (Intuitive Onboarding)： 新功能应该无需复杂的引导教程，通过名称和一句话描述就能让用户直观理解并开始使用。
  3. 高度可扩展 (Extensibility)： 开发者环境千差万别，产品必须提供工具（如 hooks, 自定义斜杠命令, sub-agents）让每个团队都能进行定制，以适应复杂需求。

团队奉行一种高度务实、工程师驱动的开发文化，旨在最大化迭代速度和反馈质量，同时最小化流程开销。

开发工作流程 (The Workflow)

1. 1. 工程师驱动的原型 (Engineer-led Prototype) 许多核心功能并非来自高层战略或详细的产品需求文档(PRD)，而是源于一位工程师对某个想法的快速原型实现。工程师拥有端到端的自主权。 💡 原因： 团队认为，对于开发者工具，最好的验证方式是直接构建一个可用的东西，而不是纸上谈兵。这能最快地检验一个想法的可行性和潜在价值。
2. 2. 内部“Dogfooding”大规模测试 原型完成后，会立即发布到内部的 "Dogfooding" 环境，供全公司约一千名员工自愿试用。 💡 原因： 在公开发布前，通过大规模内部使用来承受压力测试。这不仅能发现 Bug，更重要的是能收集到关于功能是否直观、是否真正解决问题的真实反馈，从而有效降低发布风险。
3. 3. 基于高频反馈的快速迭代 团队通过内部聊天渠道，以极高的频率（约每10分钟一条）收集反馈。一个功能在公开发布前，通常已在内部迭代了2-3个版本。 💡 原因： 这种紧密的反馈循环是产品打磨的关键。工程师可以直接与“用户”对话，快速理解问题并进行修改，确保最终发布的功能是经过市场检验且备受喜爱的。
4. 4. 灵活的决策机制 对于小型功能，如果内部反馈积极（“人们就是喜欢它”），就会被快速通道批准发布。而对于大型、战略性的项目（如VS Code和IntelliJ的IDE集成），则会经过更正式的产品审查流程。 💡 原因： 流程应服务于目的。对于探索性功能，速度和灵活性最重要；对于重大投入，则需要更周全的规划和共识。这种差异化的方法兼顾了效率与稳健。

核心工具链 (The Toolchain)

• GitHub (Issues & Pull Requests) 不仅用于代码托管，更是核心的异步协作和文档沉淀工具。许多功能的最初灵感和设计决策都记录在 Pull Request 的描述中。 💡 原因： 奉行“代码即是最终事实来源 (The source of truth is the codebase)”的理念。将文档与代码放在一起，确保了信息不会过时，任何人都可以通过追溯 PR 来理解历史背景。
• 内部聊天工具 (如 Slack) 这是最主要的实时反馈收集渠道。一个有上千名员工自愿加入的专属频道，是产品灵感和问题反馈的“活水之源”。 💡 原因： 提供了最直接、最快速、最真实的“用户之声”。相比于整理过的报告，原始、未经过滤的对话能带来更深刻的洞察。
• Markdown (.md) 文件 (存放于代码库中) 团队几乎不使用 Google Docs 等外部文档工具。所有的文档、说明都以 Markdown 文件的形式与代码一同存放在版本控制系统中。 💡 原因： 保证了文档和代码的同步性，易于版本管理，且所有开发者都能方便地访问和修改。这进一步强化了以代码库为中心的协作模式。
• Claude Code 本身 团队深度使用自家的产品来辅助开发。例如，使用 Claude Code 连接 Slack 和 GitHub，来自动总结、去重和跟进收到的反馈。 💡 原因： 这是最极致的“Dogfooding”。在解决自身问题的过程中，不仅提升了团队效率，也为产品找到了新的应用场景和改进方向。

• 内部反馈渠道极其活跃：一个有上千名员工自愿加入的内部聊天室，平均每10分钟就会产生一条新的、高质量的反馈。
• 团队极度渴求负面反馈，而非客套话。他们想知道产品哪里不好用。
• 与约10家企业客户保持紧密合作，这些客户是外部最高信噪比的反馈来源。对于高优问题，团队承诺在一到两周内修复。
• 使用 Claude Code 自身来处理反馈：通过集成 Slack 和 GitHub，可以快速综合分析不同渠道的类似反馈，并自动化处理如文档更新、关闭重复issue等任务。

• 模型评测非常困难，团队关注两类评测，且两者都不完美。
• 端到端评测 (End-to-end Evals)： 类似于在 SWE-bench 上运行测试，以确保对代码的修改不会降低整体性能。但缺点是粒度太粗，分数变化的原因不明显，需要深入分析日志。
• 触发式评测 (Triggering Evals)： 评估模型在“何时”使用特定工具（如网络搜索）的决策能力。例如，不希望模型对每个问题都进行网络搜索。这类评测相对容易构建和评分，因为触发条件和结果是明确的。
• 最难的是能力评测 (Capability Evals)，例如评估模型在“数据科学工作”上的表现是否提升，这需要复杂的测试环境和明确的“黄金标准答案”，很难实现。
• 除了自动化评测，高度参与的用户社区是保持产品质量的最终防线，用户的直接反馈非常宝贵。

• 给 AI PM 的核心建议：最难得的技能是精准直觉——深刻理解当前模型的能力边界。要能判断一个功能构想是模型已具备80%能力（可通过提示工程补足），还是仅有10%（应等待3-6个月后再看）。
• Claude Code 使用技巧：
  1. Demos not Docs (演示胜于文档)： 与其花时间写长篇文档，不如用 Claude Code 快速构建一个功能原型，亲身感受其价值。
  2. 把它当作一个热切的新手工程师： 当它犯错时，不要放弃，而是像指导新人一样直接给出反馈和纠正。它对反馈的接受度很高。
  3. 投资你的 `Claude.md` 文件： 这个文件是 Claude Code 的“记忆”，每次启动都会加载。把项目的架构、注意事项、测试方法等关键信息写进去，如同给新同事做 onboarding。

• 未来几个月的计划分为三大支柱：
• 1. 核心CLI代理： 持续打造最强大的编码代理，并围绕其高度可定制性构建一个生态系统，让用户可以分享和一键安装各种配置。
• 2. 发展SDK生态： 将 Claude Code SDK 推广为构建各类AI代理 (不仅仅是编码) 的最佳方式，支持法律、行政、健康、金融等领域的代理开发。
• 3. 走出终端： 探索新的产品形态，让 Claude Code 的核心能力能够服务于更广泛的用户，包括数据科学家、产品经理、设计师，甚至市场和销售人员，降低使用门槛。
• 由于模型技术迭代太快，做超过6个月的长期规划非常困难。团队更专注于为下一代模型构建产品。