9000字的博客文章，1.5天写完。
Teresa Torres在屏幕前轻描淡写地说出这个数字时，语气像在讨论今天的午餐菜单。但如果你还在用传统方式写作——花三四天憋出2000字，每写完一段就去刷邮箱，然后一个小时就这么没了——你可能正在用打字机时代的方式工作。
这不是速度的炫耀，这是工作方式的底层重构。
Teresa Torres，「持续发现习惯」的作者，产品管理领域的传奇人物。但今天要讲的不是她的产品方法论，而是她如何把Claude Code变成工作流的操作系统——从早晨生成待办清单，到写作时的实时对话，再到自动维护知识库索引。
她的办公桌前永远开着两个终端窗口。左边是Obsidian笔记本，右边是Claude Code的双窗口。一个负责任务管理，一个负责写作协作。这套系统没有用任何第三方工具，就是Markdown文件加命令行。
「我最开始用Claude Code写代码，就像其他人一样。但我很快意识到，这几乎就是在和Claude结对编程。」她打开终端，「我当时想，为什么不能和Claude结对做所有事情？」
她说这话时，手指已经敲下了「today」命令。
Teresa的一天从输入「today」开始。
这个命令触发的不是简单的日程展示，而是一套自动化工作流：Claude先连接Trello，检查团队是否添加了新任务卡片；然后运行Python脚本，扫描所有任务文件夹，筛选出今天到期和逾期的事项；最后生成一份Markdown格式的「today.md」文件，包含分类清晰的任务列表。
整个过程3秒。
但真正的困境不是速度，而是上下文的碎片化。传统工具链里，待办事项在Trello，写作草稿在Google Docs，知识管理在Notion，代码在GitHub。每次切换工具，上下文就断裂一次。你需要重新解释背景，重新寻找文件，重新建立思路。
Teresa遇到的正是这个问题。作为产品教练，她需要同时管理课程业务、博客写作、客户访谈分析、AI产品开发。每个项目都有独特的上下文需求：写博客时需要了解她的写作风格和目标读者；管理任务时需要知道团队成员的Trello看板地址；开发AI产品时需要掌握她的产品定位和用户画像。
「我发现自己每天在向Claude重复解释同样的背景信息。这太蠢了。」
她需要的不是更快的工具，而是一个能记住她所有工作上下文的系统。
但问题来了。
Claude的对话窗口每次都从零开始。你不可能每次都把9000字的业务背景、团队信息、写作风格指南塞进去——那会直接撑爆上下文窗口。
Teresa的解决方案是三层上下文架构。
第一层是全局偏好文件。这个文件存放在用户目录下的「.claude/claude.md」，会在每次对话中自动加载。但她严格控制这里的内容：只放工作习惯，不放业务信息。比如「在执行任何操作前，先制定计划」「我喜欢先看到完整方案，再逐步细化」。为什么？因为这个文件会被加载到所有对话中——包括「我的狗能吃这个吗」这种日常问题。你不会希望Claude在回答宠物饮食时还记着你的产品定位。
第二层是项目专属配置。每个Obsidian文件夹下都有独立的「claude.md」。任务文件夹的配置文件教会Claude如何创建任务、设置到期日期、使用Obsidian的Front Matter格式；写作文件夹的配置则规定「在每个写作会话开始时，先阅读写作风格指南」「你是思考伙伴，不是代笔者」。
第三层是按需调用的上下文文件库。这是整套系统的核心。Teresa在「llm-context」文件夹里维护了几十个小文件：业务概况、目标受众、营销渠道、团队成员、产品描述。关键是每个文件都很小，专注于单一主题。全局配置文件只告诉Claude这些文件的位置和用途，并明确规定「仅在相关任务时才读取这些文件」。
这种设计很像数据库的索引机制。
想象你在图书馆找一本书。你不会把所有书都搬到桌上再慢慢筛选——你会先查索引卡片，找到准确的书架位置，然后只取那一本。Claude也是如此。当她说「我们来优化故事式访谈课程的落地页」，Claude会自动去读取「课程产品描述」「目标受众」「营销渠道」三个文件，而不会加载「团队成员信息」或「财务系统配置」。
更妙的是，这个上下文库是自我维护的。
每次对话结束时，Teresa都会问Claude：「你今天学到了什么关于我的新信息？我们应该把它加到哪个文件里？」Claude会建议具体的文件路径，甚至直接帮她写入。她从不需要手动更新这些文件——Claude就是她的知识管理员。
这个系统的威力在写作场景中体现得最明显。
「我们现在来写一篇关于Plan Mode的博客。」Teresa在写作窗口输入这句话。
Claude的第一反应是去读「writing/style-guide.md」。这是写作配置文件规定的强制流程。然后它开始提问：「你想重点讲哪个功能？目标读者是谁？」
这不是简单的信息收集。Teresa正在和Claude进行真正的头脑风暴。她输入一些零散的想法：「目标是帮助Claude Code新手做更大的项目」「用产品经理规划新功能作为例子」「少讲功能特性，多讲如何让Claude产出高质量工作」。
Claude立即调整方向：「明白了，这更像是工作方法论而不是工具教程。我们可以用非均匀的结构——用访谈教练扩展功能这个真实案例占40%篇幅，详细展示思考过程，其他步骤精简处理。」
这就是结对工作的感觉。
然后Claude做了一件传统编辑不会做的事：它去网上搜索了30篇相关博客，总结出「大部分文章都是面向开发者的技术教程，很少有人为产品经理写这类内容」，并提供了SEO关键词分析——「claude code tutorial」月搜索量8000，「ai pair programming」月搜索量3200。
Teresa在Obsidian里快速补充大纲结构，Claude同步阅读同一份文件，不需要任何复制粘贴。当她写完引言段落，只需要切换到终端窗口，输入「我写完了引言，给我反馈」。Claude会按照她预设的流程：先说什么地方写得好，再指出可以改进的部分，然后做技术审查（确保没有说错），最后列出发现的拼写错误并询问是否修正。
「这个节奏很重要。」Teresa解释，「以前我写完一段就会去刷邮件，然后一个小时就没了。现在Claude写完反馈就会问『准备好进入下一部分了吗？』——我根本没时间分心。」
这不是效率提升，这是工作状态的保持。
她强调自己仍然手写每一个段落，不让Claude代笔。「好的写作有韵律感，你能听出来。我还没法让Claude完全捕捉到我的声音。」但Claude承担了所有让写作中断的琐事：查找学术文献验证观点、搜索竞品文章避免重复、生成命令参考表、做SEO关键词优化。
最后那篇关于Claude Code安全使用的博客，9000字，覆盖了从文件读取到代码执行的所有权限细节，包含5张详细的命令对照表。1.5天完成，零废话。
但这套系统最精妙的部分还不是写作本身。
当对话窗口的上下文快要用完时，大多数人会让Claude使用内置的「压缩对话」功能。Teresa不会。
「我试过那个功能，它会丢失很多细节，而且你无法控制它保留什么。」她的做法是主动中断：「Claude，我们快到上下文窗口上限了。请写一份总结，让我能在清空对话后从这份总结继续工作。」
她甚至为每个大型项目创建了「process-notes.md」文件。每次会话结束，Claude会更新这个文件，记录「我们做了什么决定」「尝试了哪些方案」「为什么选择这个方向」。这样即使对话被清空，所有关键决策仍然有迹可循。
「我正在写一个子代理（sub-agent）专门负责更新这些流程笔记。」她说这话时眼睛在发光，「这样Claude就能在上下文快满时自动调用那个代理来写文档。」
这就是把上下文管理变成系统工程的样子。
她的Obsidian笔记库里现在有上百个上下文文件。听起来很可怕，但没有一个是她坐下来专门写的。都是在日常工作中，每当需要向Claude解释某个背景时，她就停下来问：「我们是不是应该把这个信息保存下来？」然后让Claude采访她，根据对话内容生成文件。
「每个文件都很小，很专注。」她打开「target-audience.md」，里面只有200字，描述她的读者是跨职能产品团队、关注持续发现方法、大多数没有技术背景。「我从来没有手写过这个文件。是Claude问了我一堆问题，然后总结出来的。」
甚至上下文文件的索引也是Claude维护的。每次新增文件，她只需要问「哪个索引需要更新？」Claude就会自动修改全局配置文件，把新文件加到正确的分类下。
这套系统最终形成了一个自我进化的闭环：工作产生新知识，对话提取新知识，Claude更新知识库，知识库让下次对话更高效。
这背后是什么原理？
想想你最后一次请一个新同事帮你做事。你不会把公司所有文档都扔给他，而是先说「这是我们的风格指南，每次开工前看一眼」，然后在具体任务里再说「你可能需要查一下Q3的销售数据，在财务文件夹里」。Teresa对Claude做的就是这件事——她在训练一个记忆力完美但需要明确指引的同事。
传统的AI使用方式是每次都从头解释。这就像每天早上都要重新培训一遍新员工，告诉他公司是干什么的、你的职责是什么、团队在哪里开会。累，而且低效。
Teresa的方法是分层记忆：全局偏好管「我是谁」，项目配置管「我们怎么合作」，上下文库管「这件事的具体背景」。这不是AI技巧，这是委派任务时的基本原则——给对方刚好够用的信息，不多也不少。
所以她的系统才能扩展。现在她用Claude管理任务、写博客、做客户访谈分析、开发AI产品，每个场景都有独立的上下文配置，互不干扰，却能随时调用共享的知识库。
这套方法的局限在于它需要初期投入。你需要明确自己的工作流程，知道哪些背景信息值得固化，愿意在每次对话后花30秒问Claude「我们今天学到了什么」。对于只是偶尔用AI写个邮件的人来说，这太重了。
但如果你的工作本身就涉及大量上下文切换——写代码、写文档、做分析、管项目——那你每天本来就在做这些信息整理工作，只是用的是大脑而不是Markdown文件。Teresa只是把这个过程显性化了，然后让AI参与进来。
还有一个隐藏限制：这套系统高度依赖Claude对文件系统的理解能力。如果模型突然降级、或者上下文窗口政策改变、或者命令行工具更新导致行为变化，整个流程可能需要调整。她正在承担早期用户的风险。
「但这正是产品经理应该做的事。」Teresa说，「如果我们要在产品里集成AI，就必须生活在这个技术边缘上。我每天遇到的上下文窗口管理问题、权限设置问题、提示词优化问题——这些都会直接影响我开发访谈教练AI产品时的决策。」
她把自己当成了自己的第一个用户。
Teresa没有花一周末坐下来搭建这套系统。
她只是有一天厌倦了重复解释同样的背景信息，然后问了Claude一个问题：「我们能不能把这段对话保存成文件，下次直接读取？」从那时开始，每当她发现自己在重复解释什么，就会停下来创建一个上下文文件。
三个月后，她有了一套能记住她所有工作习惯的AI系统。
现在她每天花在Claude上的费用是100美元/月的订阅费。她说自己最开始甚至犹豫过要不要从20美元升级到100美元。
「但这就是一个全职员工的成本。」她笑着说，「而且是那种永远不会忘记你交代过的事情、可以同时做十件事、凌晨三点也能工作的员工。」
她的终端窗口里，「today」命令已经运行完毕，新的任务列表在Obsidian中展开。接下来她要写的博客是关于Plan Mode的——就是我们刚才一起开始构思的那篇。
她切换到写作窗口，Claude已经在等着了。