如何用 Claude Code 搭一套公司操作系统——Jiaona Zhang

• JZ（Jiaona Zhang）是 Laurel（播客里也念作 Luro，上亿美元规模的 AI 时间平台，服务按计费工时运作的律所）的首席产品官，在斯坦福教产品管理；此前是 Linktree 的 CPO，还在 Airbnb、Webflow、Dropbox、WeWork 带过产品。 → 详细
• 全片的总命题一句话："产品的基本功和底层原则从来没变过，甚至比以往更重要；但工具和工作方式已经根本性改变了。" → 详细
• 而公司最头疼的问题是：那 1% 的员工"AI 上头"（highly AI pilled）、天天折腾工作流，剩下 90–99% 的人根本不知道什么时候该用什么工具——Company OS 就是为解决这个断层而生。 → 详细

• Level 1：聊天模式——你在跟 ChatGPT / Claude 对话，几乎当搜索用：我问一句，你答一句。 → 详细
• Level 2：自动化一个工作流。JZ 的金句："一个 OS 一开始未必是 OS，它是从第一个自动化开始的"——从一小段所有人都会用的工作流起步。 → 详细
• Level 3：开始构建 app（"这事太繁琐了，我做个 app 让它不繁琐"）；Level 4：构建"共享应用"（shared apps），或者说按完整产品生命周期真正向客户交付。 → 详细
• 这套层级既能自评，也能评估一家公司："这个组织的大多数人处在哪一层？" → 详细

• Laurel 的公司 OS 就是一个 GitHub 仓库：公司每一个职能——客户成功、数据科学、设计、工程、财务、实施、法务、市场——各有一个文件夹，沉淀"这个职能每个工作阶段该怎么思考"。 → 详细
• 职能之下是活动子文件夹：客户成功 → 客户管理（续约、增购）→ 客户赋能（office hours、推广落地、培训 onboarding）；每个活动文件夹里放一个 skill 文件。例：续约（renewals）的 skill 就是教你"怎么正确地和客户走完一次续约流程"；谈判支持的 skill 教你怎么准备材料、找对参考案例。 → 详细
• JZ 特意给不熟 GitHub 的人翻译："它其实就是你电脑上的文件夹结构"——OS 的本体不是什么神秘系统，就是一棵结构化的知识文件树。 → 详细

• 光有文件夹不会带来改变，"说到底，我们每个人的日常都活在邮件或 Slack 里"——所以 OS 必须送到人眼前。客户成功同事每天早上看到的是一份日报视图：日历、所有会议、客户 check-in、onboarding 环节——JZ 称之为"轻量版幕僚长（chief of staff light）"概念，但关键差异是把 skills 集成了进来：交接（handoff）、会前准备（session prep）全是真实 skill，点了就能执行。 → 详细
• 落地方式：在 Claude 的组织设置里把这些 skill 文件全部上传进公司上下文，于是任何人过一天时可以直接说"我今天做这些事，调用这些 skills"，不用再花时间手做 deck、手写邮件——系统清楚什么时候该用哪个 skill。 → 详细
• 背后的经营逻辑：面向客户的团队做的是高度可复用的动作，越能统一口径、说同样的话，客户体验就越一致，"这是品牌的重要组成部分"。 → 详细

• Ontology = 把每个职能的全部工作映射成"类别 → 类别下的一系列任务"的地图；Laurel"做了非常扎实的苦功夫"，把市场、销售、客户成功、实施、设计、工程等每个职能都梳理了一遍——这就是整套 skill 体系的底层依据。 → 详细
• Ontology 的用途是双向的：构建 skills 让你"把我们希望你多做的事做得更多"，同时"把我们不希望你再做的事自动化掉"。 → 详细
• 现状是自动化"非常不均匀"（lumpy）：同一件事某个 PM 自动化得特别好、另一个做得很差。解法就是那句核心金句："把每个职能里那 1% 玩得最溜的人设计出来的东西，铺开传播到组织里其余所有人身上。" daily briefing 里甚至会直接告诉你：你今天哪些环节可以自动化。 → 详细
• Aakash 的总结点题："我们都见过那种把技能修炼到炉火纯青的人，但如果积累只沉淀在他一个人的桶里，其他人受益不到——Company OS 把那份能力带给了所有人。" → 详细

• 判断标准："什么事情特别机械、特别占时间、如果被自动化掉你会开心得不得了？"典型例子：反复写的邮件该有自动触发的模板；CRM 录数据该自动完成。 → 详细
• Laurel 的第一个小工作流是 Slack 功能需求自动化：以前一条需求进来，要来回拉扯地问"这需求被问过几次？发我 Gong（销售通话录音工具）录音听客户原话；对客户影响多大？再给点细节"——现在把"要求别人填写的信息"直接自动问齐。 → 详细
• 自动化还顺手做完分诊（triage）：自动分配给最合适的团队/PM、自动建工单追踪、明确答复需求方的 SLA（响应时限承诺）。JZ 自评"这些都是入门级（101）"——但这就是 OS 的第一块砖。 → 详细

• Laurel 的 GTM（go-to-market，市场进入/营收）团队里，客户成功同事是"时间顾问"，被前置部署（forward deployed）进客户组织帮客户用好产品。给他们写的 playbook 足足 50 页，覆盖实施、上线到用户 onboarding，且按角色（管理员/实际记录时间的人）区分。 → 详细
• 大多数公司卡在："playbook 建好了，怎么让人真的执行？里面多少该人做、多少可以给 agent？"Laurel 的做法是逐条审计：需要人打电话、人飞现场的留给人；其余的"要么产品化，要么建一个 agent 去做"。 → 详细
• 关键溯源：前面展示的 OS 第一版就是从 playbook 长出来的——走进客户成功团队问"一个人可能在做的所有事有哪些"，那些大分类桶大都来自实施、激活客户、客户沟通这些 playbook。先有 playbook，后有 skill 体系。 → 详细

• Laurel 用 Dust（agent 构建工具，同类还有 Glean、Claude 自带的 agent 能力、OpenAI 的工具）为 playbook 的每一个步骤建 agent：起草邮件、抓 LinkedIn、看市场行情、想 prospecting 问题——"55 页的 playbook 没人会读"，但每一步都可以变成一个可触发的 agent。 → 详细
• 最大心得：没人记得住"写邮件调这个 agent、做 RFP 调那个 agent"。解法是做一个包装层"超级 agent"（如 go-to-market agent），销售和客户成功随时调用它，由它把请求路由到底下真正有用的子 agent。 → 详细
• 交付方式决定采用率："哪怕只是让人切换到另一个界面提问，这点摩擦都会挡住人。直接进到大家的 Slack、邮箱里，把 just-in-time 的 playbook 和自动化送到他们面前，才是让人真正用起来的正确路径。" → 详细
• 为什么用 Dust 而不全用 Claude？——纯粹是时间问题：去年秋天开始用时专用工具更成熟，"今天这个差距正在迅速缩小，你不需要再买专用工具了，可以直接在 Claude 里搭"。Laurel 的走向就是把所有 skill 文件直接装进 Claude，在任何工作场景里喊一句 /morning-briefing-product 当场拿到简报，不再经过中间层。 → 详细

• JZ 亲身经历：她给自己设了一大堆 Claude 定时任务，"这个可以自动化→建一个；那个也可以→又建一个"，最后真正置顶的只有几个——"这几乎是过度了（overkill），我们正处在信息过载的世界里"。 → 详细
• 由此得出的公司级设计原则：不能假设每个人会自己搭这些东西，也不能假设他们不会被海量自动化淹没——所以才把一切整合进"全部集中在一个地方"的每日视图，确保 AI 采用度在全组织均匀一致（PM、工程师往往很 AI native，GTM 职能未必）。 → 详细
• 更进一步是产品化的 just-in-time：Laurel 的产品能"检测出你在什么时间正在做什么工作"，在恰当时机把对应 skill 送上来。 → 详细
• Aakash 点破本质："你们沉淀的最重要的东西不是定时任务、不是 Dust 的界面，而是那些 skill 本身——你们让公司里最不擅长 AI 的人也能达到接近 AI native 员工的水平。" → 详细

• 文化必须自上而下："领导层要说：这件事对我们至关重要，它不只是工程的事，是全公司的事。"三个月前的 offsite 上 Laurel 办了全公司 hackathon（有公司每季度/每 6 周办一次），让"人人都是 builder"的预期在全公司成立。 → 详细
• 配套培训：一份"用 Devin 发布功能"的赋能指南（Devin = agent 化的工程师，可派任务；一两年前是实习生水平，今天已是"还不错的软件工程师，虽不到 staff 级"）。 → 详细
• 三个真人案例：Nick（自认偏设计的 PM，非工程出身）端到端交付了"临时事项（temporary initiatives）"——前端+后端兼有、深度牵涉 PMS 等系统交互的复杂功能，工单和 PR 都是他自己消的；Jessica（PM，非计算机科班）做了新用户 onboarding 的空状态页面；Ashley（客户成功团队）和 PM 一起共创了那份 8 页的 Devin 赋能指南——比 PM 还不懂技术的人也能"以安全、可靠的方式发布功能"。 → 详细
• 全部方法论浓缩成一句："搞清楚你在做的工作是什么，把它文档化沉淀下来，然后清晰界定哪些保留以人为中心、哪些该被自动化掉。" → 详细

• Laurel 在 PM 的 ontology 里明确写着与工程师一模一样的条目："我们期望你用 agent 做 feature 开发、亲自 QA 自己的产品并修 bug、把 backlog 一个个啃掉"——"这不是写错了"。 → 详细
• 不希望 PM 再做的：手工综合竞争情报、亲手写事无巨细的 brief、做调研规划/外联/汇总。竞品分析的正确姿势："你的时间应该花在搭一个自动拉取竞品数据的 agent 上，然后只做审核把关，而不是每天亲自做深挖的苦活——把系统搭起来。" → 详细
• 有了 ontology 就能管理时间分配："我们希望绿色部分（该做的事）时间占比上升……我希望你停止做那些繁琐的事——或者至少，每次要做之前先去调用一个 agent。"落地三件套：建 skill 文件、在需要处搭 agentic workflow、把它们呈现在大家日常工作的场景里。 → 详细

• Laurel 对"工程/产品/设计到底是什么"的答案：任何项目都有一个 captain，即"其技能组合对这件事最关键"的人。架构重构 → 工程 captain；移动端交互体验是王道的功能 → 设计师 captain（数据问题则拉数据科学深度参与）。 → 详细
• 判断依据是"这个 feature 最难做对的是什么"：空状态功能"最难的绝对不是工程，甚至不是设计，而是内容——内容和用户、业务、律所息息相关，这是非常经典的 PM 工作"，所以 PM 当 captain。 → 详细
• 非技术者怎么扛前后端？——用 LLM 评估难度：让 Devin / Claude Code / Cursor 看代码库，问"这块代码什么状态"，"它真的能给你相当不错的答案：这部分我建议你小心"；在最有争议、风险最高的部分再拉工程师进来。有风险的代码仍然全部走工程师 code review。结果是"我们所有人都能发布上线——包括客户成功，这真的很疯狂——还有销售"。 → 详细

• 制衡第一条："透明度就是一切"——建一个「ask Devin reviewers」频道，所有用 Devin 发布的东西都在里面可见，@ 前端工程师看这个、@ 设计师看那个。第二条：定基本规则（写进赋能指南、融进 Devin 的使用方式）。支持团队的人有想法可直接发频道做"快速检查"，各方进来给反馈——"把过去需要专门排期、把所有干系人凑进一间会议室的产品评审，直接压缩掉了。" → 详细
• 双轨制（two tracks）：小事（一个产品 builder 能端到端搞定的）不走严格评审，只走 ask-Devin 频道 + 有人看 PR，你对自己功能的端到端测试负全责——顺带治好瀑布模式的老梗："PM 扔给设计、设计扔给工程、工程扔回来，设计师说'这根本不是我设计的东西'"。这条轨道能把产品生命周期压缩到一天甚至一小时。 → 详细
• 大事（如彻底改变活动的展示方式、用户如何在一天里缩放视角——牵动整个交互系统）必须走真正的产品评审 = 产品战略评审 + 架构评审，"把整个产品当作一个系统来讨论，而不是这儿随手加一个、那儿随手加一个"。第一步永远是先分桶：什么事归哪条轨。 → 详细
• JZ 明确反对"AI-native = 不要 roadmap 不要规划"："如果每个人都朝不同方向狂奔，就算跑得再快也到不了任何地方。我见过很多很棒的局部最优，但没有对战略/差异化的严谨思考，很难达到全局最优。"实锤数据点：「临时事项」这种前后端功能没有走产品评审。 → 详细

• 人机分工的底线先划清："这不是'所以我们不招人了'，而是把人放到最重要的事情上。"关系建设——真正的当面拜访、带客户支持者（champion）吃饭、待客之道的惊喜瞬间——"永远无法被 agent 替代"；但现场拜访的排期、来回沟通、活动策划的后勤，全该自动化，"那些琐事根本没人想干"。 → 详细
• 价值观的通病：**"很多公司说'这是我们的文化价值观'，然后它就躺在某个文档里，大家读一遍就忘了。"**Laurel 把 unreasonable hospitality（不合理的好客之道）明文化成硬性要求："不管你是不是天生贴心、来了四年还是四天，你都明白它是我们运营方式的一项要求。" → 详细
• 系统化的具体做法：团队里有人天生会做"听说客户第一次出国去墨西哥，就送上刻字护照夹"这种事，但靠个人天性无法规模化——于是把它做成 OS 里的内置检查项：你马上要和某客户 check-in、且很久没有线下接触时，系统主动弹出"你可以怎么给对方制造惊喜？"并附上从 Gong 通话转录里提取的对方喜好清单和现成点子，连"护照夹去哪刻字"的琐碎都替你办了。 → 详细
• 方法论收束："深入理解你公司的工作，哪些事情让你与众不同？在那些事上把人放在哪里？然后即使在那些时刻，也要让这份工作更容易完成、让那种感受更容易被传递。" → 详细

• 对 Adobe 式传统大公司 PM 的回答："每家公司最终都必须走到这一步，只是时间问题——当所有竞争对手都在以十倍速度前进时，你不可能还在原地做同样的事。"你要做的是走在曲线前沿，而不是干等变化砸到头上。 → 详细
• 若暂时没法发布到生产（"通常不是能力问题，是系统或流程还没到位"），JZ 力推的入门法：去公司里找另一个团队，给他们做一个让生活变好的工具——"组织里总有某个角落渴望产品思维"；同时挑自己工作流里一个耗时环节自动化（客户会前让 agent 端上准备材料、反复写的邮件自动填充）。 → 详细
• playbook 的成本已崩塌："过去被指派写一份 playbook 得几周；现在初稿不到一分钟，真正写对、反映你的业务也就几小时、最多几天。"管理层的杠杆动作：庆祝这些胜利，把 1% 顶尖者的工作流规模化到每一个人——"建立期望并庆祝胜利，你就会得到越来越多这样的行为"。 → 详细

• 结构性建议：把"玩转 AI 工具、自动化大家的工作流"变成一个人的全职章程——"当你说这是每个人的责任时，它就成了没有人的责任。" → 详细
• "AI ops 就是新的 biz ops"：把原本高层务虚、什么帽子都戴的 biz ops"瑞士军刀"角色重新定位，要找的 DNA 是"好奇心爆棚、痴迷折腾最新技术、对挖掘效率毫不松懈"。 → 详细
• 推广机制靠示范：第一位 AI Ops 是 Sasha（今天演示的很多东西都是其搭建的，还是 JZ 斯坦福课上的学生→助教→入职 Laurel），做出成绩后"其他每个职能都会说：我也要我自己的 Sasha"——于是顺势扩展出专管 GTM、产品、财务的 AI Ops，因为"财务、rev ops、产品运营、研究运营全都在剧变"。 → 详细

• Laurel 前身 Time by Ping 创立于 2018 年（AI 革命之前），CEO Ryan"有远见也有勇气"地把整个产品和公司重构为 AI native：计时（timekeeping）从"手动录入/靠集成"变成"看到电脑上发生的一切，跑一遍 LLM 综合出来"。 → 详细
• 不是 CEO 也能干：高管可以在自己职能里"把工作地图逐行过一遍，标注哪些该 AI 化"——例如市场负责人："今天你不该再手写文案，你该做的是编辑；做视频还不用 AI 工具，就是在棚拍上花根本不必花的大钱。" → 详细

• 核心辩题"你是 product manager 还是 product builder"——JZ 的立场：人人都该是 product builder（含设计师、工程师），对应 captain 制和端到端交付。 → 详细
• 招人看两样的组合：千锤百炼的判断力（"穿越过炼狱、发布过没成功的东西"）+ 强烈的好奇心和亲自动手的渴望。资深人群正在分化："一批经验丰富的人几乎是在害怕工作改变，恐惧多于兴奋；另一批从来没这么兴奋过——终于不用做那些耗时无穷、内心毫无意愿的事了。" → 详细
• 有意思的现象：几位前 CPO / VP of Product 加入后以 IC 身份端到端交付，"从来没有因为不用再管团队而这么兴奋过——他们意识到那里面很多只是管理开销、协调成本"。 → 详细
• 组织规模的硬数据：JZ 曾管几百人，今天只有 5 个 PM + 4 个设计师，"没有理由再扩张——每加一个人就多一份协调成本，也更难让人对端到端交付负绝对责任。最好的团队会是精简的，但不能精简到饥饿，找到那条线很重要。" → 详细
• 为什么最好的 PM 拿到更多机会、其余人感到恐惧："一个 PM 现在能做的比以往多得多，但同时具备技能、判断力、懂 AI、又贴近客户的人，韦恩图交集很小——每家公司都想要这样的人。"要找的是编排者（orchestrators）：思考上有大局观、执行上落到细节，"价值千金"；而需要设计师/工程师/许多人来补位的人，"既然一个人就能端到端，为什么还要招那么多人"。 → 详细

• JZ 对每个职能（不只产品/设计）的候选人都要求共享屏幕、现场演示自己怎么用 AI："嘴上说'我很懂 AI'太容易了——那些说法可能是从 LinkedIn 或网上最新看到的东西搬来的；掀开引擎盖一看，其实你只在 Level 1。" → 详细
• 屏幕会立刻暴露层级：只是在跟 ChatGPT 聊天？还是搭了能规模化放大自己的工作流/agent？还是在构建 app、真正交付东西？背后的招聘哲学："宁愿花大价钱请几个非常资深的人，也不要养一大帮普通人。" → 详细

• JZ 在斯坦福、耶鲁、Reforge 教课（"教学 = 热情 + 人才管道"；教 AI 领导力的课程内容"按月在变，每 6 个月一轮之间变化量巨大"），但发现"基本功和核心原则从来没变过：永远不该直接跳到解决方案；现在能以前所未有的速度构建，不意味着什么都要去做——真正重要的是为什么构建、为谁构建、解决什么问题、成功长什么样"。 → 详细
• 教学还是自我提醒："讲完课我会想：JZ，你今天够以客户为中心吗？有没有先看问题空间、而不是先跳到解决方案？" → 详细
• 收束呼应开场："基本功比以往更重要；但工具、运作方式、你冲破官僚体系并获得赋能的方式，已经翻天覆地。"领导者要自问：有没有对的文化、对的团队、给人构建的空间、对的 operating system、以及对大家日常工作的真实了解。 → 详细

本期没有闪电问答环节。收尾要点：

• Aakash 宣布里程碑：YouTube 订阅破 4 万，每期平均收看/收听量破 56.5 万；他号召听众去申请 Laurel 的 PM 岗位（"这可能是你能找到的最酷的 PM 工作"），并预告将在自己的 newsletter 写一篇关于 Company OS 的文章。 → 详细
• 他给传统公司 PM 的建议："如果刚才聊的一切离你有十万八千里，就去找一份跟着 JZ 这样 AI-pilled CPO 的工作——你学到的会远多于四年后被迫补课。" → 详细

• Laurel（前身 Time by Ping）PM 招聘：节目中多次号召直接申请 Laurel。 → 详细
• JZ 的课程：斯坦福产品管理课（湾区可现场上）、耶鲁授课、Reforge「AI 领导力」课程（面向管理者）。 → 详细