我在产品工作中使用的Claude Code工作区是一个几乎没有代码的文件夹。它包含一个上下文文件夹，其中包含关于公司的所有信息：产品、用户、竞争对手、我喜欢的工作方式。每个项目一个文件夹，任务与交付物分开。一组技能，每个技能完成一项重复的工作：状态更新、PRD审查、访谈综合。当我给出反馈时，它会记录在一个文件中，并附带说明原因，我永远不会再给出那个反馈。我并不是设计这个系统的，而是通过先搞错然后逐步优化它。搞错的过程教会了我支撑整篇文章的道理。在掌握基础后，Claude Code的效果不再依赖于你提示的质量，而是依赖于你整理文件的能力。一个好的提示只能改善一次会话；而一个好的文件则能改善之后的每一次会话。你之前阅读的关于提示调优的建议在整理开始变得重要的那一刻就不再有效。所以我没有描述我的系统，而是将其打包了起来。入门工作区在GitHub上是公开的：文件夹、上下文模板和五项PM技能，由一次设置访谈个性化定制。你不需要技术背景就能跟随；每个步骤都有详细说明，包括安装工具。虽然我举的例子是一个产品工作，但相同的架构适用于任何以上下文为重的工作：设计负责人的研究库、数据团队的指标定义、创始人的所有文件夹。以下是路径。切换。我将给你展示聊天模式和Cowork无法提供的东西，以及为什么终端对于产品经理来说是值得的。入门工作区。下载它，运行一个设置技能，然后给它一个真实的任务：六个步骤，每个步骤都在屏幕上显示。实践。六个动作让系统复合，每个动作都具体说明要做的事情和你能得到的回报。节奏。这就是系统内部正常工作日的样子，从第一次简短的提示到持续两分钟的整理习惯。收益是具体的。一次操作让你启动：安装工具，下载工作区，回答设置访谈，交付一个首次真实任务。你不再每次会议都重新解释公司的情况，每个你所做的修正都变得永久。每个步骤都在下面。是时候打开文件柜了。你可能今天通过Claude的聊天进行产品工作：一个浏览器标签或桌面应用，可能使用Cowork来处理有效任务。这有效，但这正是陷阱所在。每次对话都从零开始。上次上传的战略文件消失了，你耐心解释的上下文在一个你再也找不到的线程中，您喜欢的输出被困在对话中，而不是存放在文件中。聊天是思考的好地方，但却是累积信息的坏地方。对于偶尔的问题来说这没问题。但对于日常产品工作，这意味着每天早上都得支付相同的设置成本。Claude Code是同样的Claude，但有一个不同的家：你机器上的一个文件夹，它可以读取、导航和写入。上下文存在于持续的文件中。重复的工作通过可以按需运行的技能存在。输出作为文档保存，而不是消息滚动查找。在我的日常使用中，我以前在聊天或Cowork中做的所有事情在这里运作得更好，因为没有任何事情会被解释第二次。这是我自己工作的观察，而不是一条法律，但这几个月一直成立。实际上改变我工作的部分是底层的终端。Claude Code原生支持GitHub，无需连接器：它可以提取公司库并回答相关问题，也可以推送你自己的工作。让它获取你产品背后的库，并解释一个功能标志具体是做什么的。将你的工作区推送到一个私有库，并且团队成员可以克隆它并继承你的先机。对于产品经理来说，这是一条直接进入代码库的路线，也是分享你整个系统的一种方式，而这些在聊天中是根本无法做到的。没有人告诉你的是使这一切复合的整理系统。Anthropic的最佳实践指南是用它自己的话写的，“为在各种代码库、语言和环境中使用Claude Code的工程师提供的”，而工程师可以免费获得他们的结构：代码库已经组织成上下文。现有的PM指南，例如Sachin Rekhi的指南，被大家普遍知晓，正确地告诉你“将所有产品数据和文档存储在本地markdown文件中”，然后继续讨论。如何组织？如果没有答案，你就会得到我曾经的结果：四十个散乱的文件和一个过时的设置。入门工作区就是那个答案，预构建的。让我们来设置它。入门工作区是我自己产品工作运行的结构，清理成一个模板：文件夹、带有指导占位符的上下文文件、一个示例项目和五项已经安装的技能。整个过程是免费的，公开的：claude-code-pm-starter。六个步骤让你从无到有，完成首次真实任务，且这些步骤都不要求技术背景。在你开始之前有一个前提条件的备注。你需要一个付费的Claude计划来使用Claude Code。