🧠 Inside Claude Code：产品经理 Cat Wu 深度访谈实录

—— Anthropic 团队如何打造 AI 原生的开发者工具

🎙️ 采访者：Peter

💬 受访者：Cat Wu（Claude Code 产品经理）

🧭 一、起源：从内部实验到“AI 原生”工具

Peter： 能先讲讲 Claude Code 的愿景和起点吗？

Cat Wu： 一开始只是 Boris 的一个实验。他想测试 Anthropic 的内部 API，看看 Claude 能不能真正“写代码”，于是就做了一个简单的命令行工具。

没人想到它会传播得那么快——最初是工程师在用，接着研究员、数据科学家、甚至产品经理和设计师都加入进来。

我当时负责强化学习的实验环境，自己也用 Claude Code，发现它完全改变了我的工作节奏：代码生成、日志分析、甚至写报告都更顺了。

当我们决定正式对外发布时，我毫不犹豫加入了项目。Claude Code 对我来说不仅是工具，而是一种新的工作范式——它代表“AI 原生团队”真正的样子。

💻 二、设计哲学：极简、可扩展、无 onboarding

Peter： 终端体验很简洁，是刻意为之吗？

Cat Wu： 是的。Claude Code 的设计初衷就是“极简 + 可扩展”。

终端是最纯粹的开发环境，它能访问用户几乎所有的上下文信息，比如 GitHub CLI、Datadog CLI、Docker、Kubernetes 命令行等。

这意味着我们可以不需要任何花哨 UI，就能让用户在自己最熟悉的空间中直接和 AI 协作。

我们团队常说：如果一个功能需要说明文档，那它就还不够好。

因此我们坚持三个原则：

1. 🚫 无 onboarding 原则：命令名必须自解释，用户看到就能用。
2. 🧩 极简但可扩展：通过 Hooks、子 Agent、自定义命令，让用户把 Claude Code 变成自己的开发环境。
3. 🎮 逐步解锁体验：第一次使用时感觉“哦，这就是个命令行工具”，但越用越发现它能写代码、分析日志、理解项目架构。

🧑‍💻 三、团队与角色：工程师主导的快速迭代

Peter： 团队的工作方式是怎样的？

Cat Wu： 我们的团队和传统科技公司很不一样。

Claude Code 是一个由**产品工程师（Product Engineer）**主导的项目——他们既写代码，也思考用户体验和产品策略。

团队文化是“Build Fast, Learn Fast”：

• 💡 有想法就开干，不写长文档；
• 🧪 自己先用，内部 dogfooding；
• 💬 收到反馈立刻迭代；
• 🚀 好用就上线，不好就删掉。

我作为 PM，更像是一个方向引导者。我不下命令，也不会排详细的 backlog。我的职责是：

• 帮团队确定大的产品边界（例如：哪些功能该做，哪些会让 CLI 变得臃肿）；
• 平衡灵活性和易用性；
• 负责定价、包装、和面向外部用户的策略。

说实话，Claude Code 团队像是一群黑客组成的迷你创业公司，我们只是碰巧待在 Anthropic 里面。

⚙️ 四、功能评审与实验机制

Peter： 有正式的产品评审流程吗？

Cat Wu： 有，但非常轻量。

大功能（比如 VS Code、IntelliJ 集成）会经过正式的目标讨论，我们会明确它能为开发者带来什么增益，比如“能否让 Claude Code 访问项目上下文、直接补全代码”。

小功能完全不一样——像 To-Do List、Plan Mode 这种，都从一个下午的实验开始。

我们相信**“原型比文档更有说服力”**。如果工程师能在一天内把想法跑通，我们就会立刻在内部试用。

Claude Code 的很多功能都是这样诞生的。

🧾 五、功能故事：To-Do List 的诞生

Peter： To-Do List 功能是怎么来的？

Cat Wu： 这是个特别有趣的故事。

我们发现 Claude 在执行长任务时经常“中途忘记目标”——比如修一个 Bug 会停在一半。

于是工程师 Sid 提出了一个灵感：“那就让 Claude 像人一样写 To-Do 清单吧。”

于是 Claude 开始先生成任务列表，再一步步执行。

这简单的机制极大提升了任务完成率，成了 Plan Mode 的前身。

后来我们又加了 /todo 命令，让用户能持久查看任务列表，甚至在不同 session 间同步。

最神奇的是：这不是我们提前设计的功能，而是从一个“模型行为漏洞”中成长出来的解决方案。

💬 六、反馈系统与优先级

Peter： 面对大量反馈，你们如何决定优先级？

Cat Wu： 内部有上千名员工在用 Claude Code，他们的反馈就是我们的雷达。每 10 分钟 Slack 群里就会冒出一个新建议。

外部还有十几家核心企业客户和活跃的 Twitter 社区，我们的开发者会直接发 PR 或写插件。

我们没有传统的“优先级打分系统”，只有一句话：

“如果 10 个人都提到它，那它就是下一件事。”

我们还用 Claude Code 自己来处理反馈：

• 自动汇总 Slack、GitHub、客户邮件；

• 自动生成文档初稿；

• 自动检测重复问题；

• 自动分类（UI、性能、Bug、Feature）。

  这也是我们团队 AI 原生化的体现——连产品管理都交给 AI 了。

🧱 七、文档与协作方式

Peter： 你们不用 Google Docs 吗？

Cat Wu： 基本不用。我们的知识都“长在代码里”。

Claude Code 可以直接问：“这个函数为什么这么写？” 它会去查 commit 历史和 PR 讨论，给出完整解释。

这让我们几乎不需要维护独立文档。

Peter： 那你自己写代码吗？

Cat Wu： 会。比如我们做 “vibe command” 时，我写了一半。

这在以前不可能发生——但 Claude Code 让 PM、设计师都能快速试验新想法。

现在设计师 Megan 也经常提 PR，我们的协作方式更像“多人和 Claude 一起 pair program”。

🧪 八、Evals：评估体系

Peter： 你们如何评估模型表现？

Cat Wu： 我们有两种评估：

1. 📊 端到端评估（E2E）：像 SWE-bench 这样的标准基准，检测整体表现。

2. ⚡ 触发评估（Triggering Evals）：测试 Claude 是否在恰当时机调用工具（比如什么时候该用 web search）。

   还有一种比较困难的叫“能力评估（Capability Evals）”，主要用于数据分析、科研、系统设计等任务。

   我们的目标不是让模型“拿高分”，而是理解模型能做什么、不能做什么。

   这种对模型边界的直觉，是我们所有产品决策的基础。

🎉 九、团队趣事与文化

Peter： 有没有有趣的小故事？

Cat Wu： 太多了（笑）。

我们有个彩蛋：用户输入 “stickers” 或 “swag” 时，会自动跳出贴纸申请入口。

结果 500 人真的填了地址，我们花了一个下午寄贴纸😂。

后来我们还做了 “Think Harder”“Ultra Think”等系列贴纸。

团队氛围特别轻松。我们相信“快乐的团队能造出聪明的产品”。

几乎每个新想法都从一句玩笑开始。

比如 Plan Mode 一开始只是有人在 Slack 里调侃“Claude 能不能学会写计划”，结果第二天功能就上线了。

💼 十、招聘新 PM

Peter： 你们现在在招 PM，对候选人有什么要求？

Cat Wu： 我们在找能“和 AI 一起工作”的人，而不是传统意义上的项目经理。

理想的候选人要：

• 深入理解开发者生态，最好有代码经验；
• 理解 SDK，能帮助我们把 Claude Code 扩展成更大的生态；
• 愿意建设社区，让用户贡献自己的插件和命令；
• 最好是 Claude Code 的重度用户，真正热爱工具本身。

在面试时，我们更看重候选人是否能提出独立见解。

比如，如果你体验过 Claude Code，我们会问：“哪一个地方最打动你？哪一个地方你会重做？”

这类讨论比“写不写代码”更有价值。

因为对我们来说，PM 不仅是项目协调者，更是产品灵魂的共同塑造者。

💡 十一、使用技巧与实践经验

Peter： 有没有一些使用 Claude Code 的小技巧？

Cat Wu： 当然。这里是我最常和用户分享的三点：

1. “Demo 胜于文档” 📄

   如果你有想法，不要去写提案，直接用 Claude Code 开个分支、跑个原型。Claude 能理解上下文、生成代码，还会帮你写 commit message。

2. 把 Claude 当作新同事 🤝

   Claude 特别擅长执行清晰的任务，但它不是读心者。

   最好的方式是先给它明确的上下文和目标，再不断迭代。

   就像带一个新工程师入职一样，它学得快、执行力强，但需要方向。

3. 投资你的 Cloud.md 文件 🧠

   我们给每个用户推荐一个 Cloud.md 文件，记录项目结构、依赖、测试方式、以及你喜欢的风格。

   这让 Claude 理解你的习惯，成为真正“懂你”的 AI 合作者。

🪄 十二、Plan Mode 的故事

Peter： Plan Mode 是怎么来的？

Cat Wu： Plan Mode 的灵感来自一个简单的用户反馈：“别急着写代码，先告诉我你的计划。”

我们一开始觉得可以通过自然语言解决，但用户更喜欢显式模式，于是我们立刻上线 /plan。

现在 Claude 会先输出清晰的分步计划，再去实现。

很多用户告诉我们，这种“思考可视化”的体验让他们重新掌控了工作流。

我们也认为，这代表 AI 协作的新方向：不仅是帮你做，更要让你理解它怎么做。

🚀 十三、未来方向与愿景

Peter： Claude Code 未来会往哪走？

Cat Wu： 我们的目标有三个方向：

1. 🧩 强化 CLI 核心体验

   我们希望它永远是最强的命令行助手，性能稳定、上下文更长、交互更自然。

2. 🧱 构建 SDK 生态

   我们正打造 Claude Code SDK，让任何人都能快速创建属于自己的 AI Agent——无论是法律助手、财务工具、还是科研助理。

3. 🌍 走出终端，触达更多人

   我们计划把 Claude Code 的核心能力带入非开发者的场景。

   比如产品经理、设计师或市场人员，也能在 Claude 的帮助下自动生成方案、写报告、分析用户反馈。

举个例子：一个不会编程的同事，只需输入“帮我做个用户调研工具”，Claude Code 就能自动创建一个小应用，并解释怎么运行。

这正是我们对“AI 原生软件”的理解——让智能成为操作系统的一部分。

📱 十四、移动端与远程使用

Peter： 有没有计划让 Claude Code 在手机上用？

Cat Wu： 这是很多人关心的。

我们已经在探索“远程运行”的模式——比如当 Claude Code 等待输入时，可以自动通过 Slack 或短信提醒你继续。

Hook 系统的出现最初就是为了解决这个问题。

我们希望无论你是在办公室、家里，还是在地铁上，都能无缝继续和 Claude 协作。

🧭 十五、时间尺度与产品哲学

Peter： 你们会写三年规划文档吗？

Cat Wu： 不会（笑）。

AI 产品的生命周期太快了，三年后的模型能力、交互方式都完全不可预测。

我们的哲学是：“只构建今天我们真正想用的东西。”

我们一般只规划 6 个月，因为那是我们能感知到的未来。

当下的每一个版本，都是一个最好的实验。

所以我们不靠文档驱动，而靠真实的使用体验。

🧠 十六、对 AI 产品经理的建议

Peter： 给想做 AI PM 的人一些建议？

Cat Wu： 现在的 AI 产品经理，需要具备以前从没要求过的能力——判断模型边界的直觉。

你要能分辨：

• 模型是理解错了问题？
• 还是你给的上下文不够？
• 还是这件事模型现在根本做不到？

举个例子，如果模型已经能做到 80%，那你完全可以用 prompt 设计补足剩下 20%；

但如果模型只做到 10%，那就别硬搞，等三个月后模型升级再回来试。

AI 产品经理最重要的品质是好奇心和耐心。

你要和模型一起成长。

每一次失败都不是 bug，而是一次理解模型边界的机会。

当你真正理解这些边界时，你的产品直觉就会变得非常强。

✨ 十七、结语

Claude Code 团队用极高的反馈速度、开放的工程文化和强大的执行力，

创造了一个真正意义上的 AI-Native 产品开发团队。

他们不追求宏大的计划，也不写厚厚的愿景文档。

正如 Cat 最后说的那句话：

“我们不写三年愿景文档，我们只构建今天想要的产品。”

“Dogfood first, feedback fast, ship what users love.”