Laurel CPO：如何用Claude Code搭建一套公司操作系统丨Aakash Gupta

Laurel CPO：如何用Claude Code搭建一套公司操作系统丨Aakash Gupta Laurel CPO：如何用Claude Code搭建一套公司操作系统丨Aakash Gupta Modified June 29 🔗 原文链接： https://mp.weixin.qq.com/s/cV GGCVd... 原创 Capihom Capihom 晚点再听LaterCast2026年6月28日 20:30 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "你有那 1% 的 AI 用户，也有剩下 90% 到 99% 不知道什么时候该用什么工具的人。" "公司 OS 不一定一开始就是 OS，它从第一个自动化的小工作流开始。" "基本原则从未改变，甚至比以前更重要；彻底改变的是工具和你的工作方式。" Jiaona Zhang是Laurel的CPO，她做过 Airbnb、Dropbox、Webflow、WeWork 的产品负责人，也在 Stanford、Yale 和 Reforge 教产品。 很多产品负责人和创业团队现在卡在同一个地方：公司里总有一个人很会用 AI，能写 prompt、搭 agent、自动化掉一堆杂活；可其他人每天仍在问，该用 Claude、Slack automation、Dust，还是继续复制粘贴。Laurel 的做法，是把少数高手的操作沉淀成全公司都能调用的技能。 两件事把这期对话从工具分享拉回组织变化：JZ 的产品团队已经能把前端和后端功能端到端推到生产；她面试候选人时，会让对方直接共享屏幕，现场展示自己怎样使用 AI。公司 OS 已经进入团队分工、招聘标准和 PM 交付判断。 先把公司的活画成一张工作地图 JZ 打开的第一个画面是 GitHub。它看起来不像常见代码仓库，更像按公司职能拆开的工作目录：customer success、data science、design、engineering、finance、legal、marketing。每个职能下面继续拆动作，比如客户成功里的续约、追加销售、office hour、培训和 onboarding。文件夹里放着一组可以被 Claude 调用的 skill，也保留团队约定和参考资料。 Laurel 先做了一件事：把每个部门每天做的活拆到类别和任务，再标出哪些活希望人多花时间，哪些活应该交给自动化。销售、市场、客户成功、设计、工程、产品，每个部门都有自己的工作地图。产品团队那一栏尤其直观：竞品分析、stakeholder 写作、反馈整理、约人访谈、信息归档，过去都占 PM 大量时间，如今正在被重新分配。 "你有那 1% 的 AI 用户，他们高度 AI 化；也有剩下 90% 到 99% 的组织成员，不确定什么时候该用什么。" 公司 OS 的目标，就是让那 1% 的经验不要锁在个人电脑里。一个客户成功同事早上打开日程，看到今天的 check in、onboarding、handoff，同时看到每个环节该调用哪个 skill。一个 PM 开始处理需求，也能在同一套地图里看到 playbook、模板、自动化入口和负责人的分工。 这套目录还会进入 Claude 的组织设置。员工在 Claude 里处理一天的工作时，不需要重新解释公司怎么做续约、怎样准备客户会议、怎样写某类交付材料；skill 已经把团队约定、参考资料和步骤带进去。个人习惯被翻译成公司级的默认动作，团队才有机会用同一种声音服务客户。 先从一个烦人的重复动作开始 Aakash 问她，普通公司从哪里开始？JZ 给出的起点很小：先找一个团队反复做、又厌烦到不想再做的动作。比如反复写同一类邮件，反复往 CRM 填数据，反复在 Slack 里追问一条 feature request 的背景。 她举了一个产品团队每天都会遇到的场景。销售或客户成功在 ask product 频道里丢来一个需求：某个客户要某个功能。传统处理方式，是 PM 来回问：这个需求被提过多少次？有没有 Gong 录音？客户影响有多大？该分给哪个 PM？多久给回复？Laurel 把这些追问做成 Slack automation：自动收集信息、分派负责人、创建 ticket，并给 requester 一个可追踪的回执。 小自动化的好处很具体。PM 不再把一天切碎在“补一下背景”“给我录音”“这个客户 ARR 多大”这些追问里；销售也不用猜产品团队想要什么材料。字段被提前设计好，负责人与 SLA 自动生成，需求从一句 Slack 消息变成可处理的队列。公司 OS 的第一块砖，常常就是一张不再漏信息的表单。 "公司 OS 不一定一开始就是 OS，它从第一个自动化的小工作流开始。" 50 页 playbook，要拆成可调用的 skill 很多团队已经有 playbook。客户实施、销售话术、onboarding、续约支持、用户培训，动不动就是几十页。JZ 说 Laurel 的 GTM 团队也有 50 多页的 playbook，里面写着怎样帮客户上线，怎样给不同角色做培训，哪些场景需要人亲自参加电话，哪些材料可以提前准备。 文档写完只是前半段。更麻烦的是，团队是否真的照着做，哪些步骤交给人，哪些步骤交给 agent 或自动化工作流。Laurel 的第二步，是审计 playbook：把需要判断、需要现场沟通、需要客户关系的动作留下；把邮件草稿、LinkedIn 搜集、市场信息整理、RFP 支持、销售问题准备这类可重复动作，拆成一个个 agent。 JZ 提到他们会用 Dust 这类 agent builder。每个 agent 对应 playbook 里的某个环节；但团队成员不需要记住所有名字。前面再包一层大的 GTM agent，销售和客户成功随时发起请求，由它把任务路由给合适的子 agent。员工看到的入口仍是一条请求，后面的查资料、套 playbook、生成建议、回写记录由系统完成。playbook 从静态文档变成一组可执行的动作。 她还特别提到，有些步骤应该被产品化，有些步骤更适合交给 agent。比如客户成功经理反复起草邮件、销售反复搜 LinkedIn、市场团队反复整理行业信息，这些都可以从 playbook 里拆出来。上门沟通、判断客户关系、处理复杂承诺，仍要由人来做。OS 要给团队一张分工图：哪些事自动触发，哪些事必须留给人。 入口必须留在 Slack 和邮箱里 Laurel 的经验很现实：让员工去一个新界面里找 agent，采用率会掉。销售在 Slack，客户成功在 Slack，很多请求从邮箱来，入口就要回到这些地方。JZ 反复强调交付位置：工具做出来只完成一半，另一半是让人不用离开日常工作场。 公司 OS 和普通知识库的分界在这里。知识库等人搜索，OS 嵌进一天的动作里。早上看日程时，它提醒你会议准备可以调用哪个 skill；客户问题进 Slack 时，它自动收集缺失信息；PM 处理 feature request 时，它已经把字段、负责人和 SLA 整理好。员工不需要先成为 AI 高手，才能享受 AI 高手沉淀下来的做法。 Aakash 在对话里追问了一点：很多公司也有 agent 工具，为什么用不起来。JZ 的回答很直接，换界面的摩擦会杀死习惯。团队成员已经在 Slack 和邮箱里接活、交付、同步，AI 入口离这些场景太远，就会变成演示时惊艳、月底没人打开的工具。Laurel 把按钮、表单、agent 调度和结果回写放在员工已经停留的地方，让一次请求从发起到记录都能闭环。 AI Ops 不能只靠大家顺手做 Laurel 曾经让全公司参加 hackathon，目的是打掉一个心理门槛：非技术岗位也能做出东西。但 JZ 更看重后续的组织安排。她建议公司给 AI tooling、workflow 创建和日常工作自动化配一个全职岗位，写进 charter，别再塞进每个人待办清单角落。 "很多时候，当你说它是每个人的责任，它最后就成了没有人的责任。" 她把 AI Ops 叫作新的 Biz Ops。过去 Biz Ops 像瑞士军刀，帮公司看市场、看数据、补各种空缺。现在这类人要换一组肌肉：强好奇心，愿意试最新工具，对效率改造很执着。Laurel 一开始有 Sasha 这样的人证明效果，很快每个部门都会说，我也想要自己的 Sasha。于是 go to market、product、finance 都可能出现自己的 AI operations 人选。 Laurel 还有一个来自 CEO 的前置选择。公司 2018 年成立，早期产品围绕 timekeeping；后来创始人 Ryan 判断，在 LLM 和 AI 的世界里，手动填时间、靠集成拼接上下文会变得落后，于是推动公司和产品一起转向 AI native。JZ 说，CEO 的信念当然重要；但部门负责人也能从自己的职能开始，把每一项工作逐行标出：哪一块要 AI enabled，哪一块仍要人亲自负责。 她给了一个很普通的部门动作：营销负责人可以把 copywriting、视频制作、素材整理逐项标色。哪些工作已经不该手写，哪些地方只需要人来编辑和判断，先在自己的职能里画清楚。 产品团队会变小，但负责人要更能打 JZ 在 Laurel 的产品组织很小：5 个 PM，4 个设计师。她以前管过几百人，现在反而没有理由扩张。因为每加一个人，协作损耗也增加，端到端 ownership 变弱。Laurel 使用 captain model：每个 feature 有一个 captain，从发现、设计、实现到上线一口气负责；captain 不固定属于某个职能，而是由最能解决本次最难部分的人担任。 Captain model 也改变了产品评审。团队不再把一个 feature 拆成 PM 写需求、设计师画稿、工程师排期的长链条；负责的人要把最难的部分推进到底。如果最难的是客户洞察，PM 可能是 captain；最难的是交互和视觉，设计师可以接手；最难的是架构，工程师来牵头。Claude Code 这类工具让负责人能补上更多实现细节，ownership 反而更清楚。 她描述的 PM 也更像 product builder。Laurel 的 PM 会 ship 前端和后端功能，范围已经覆盖 billing 和 time entry 这类核心逻辑，有人甚至把相关功能端到端推到生产。JZ 说，经验丰富、判断扎实、又愿意亲手下场的人从来没有这么兴奋，因为过去消耗大量时间的协调和杂活正在减少。 招聘也随之变了。JZ 会让候选人 screen share，直接展示他们怎么用 AI。她把成熟度分成四级：第一级是在 ChatGPT 或 Claude 里聊天；第二级能自动化一个工作流；第三级开始为自己搭 app；第四级做 shared app，甚至能 ship 给客户。简历里写 AI pilled 很容易，打开屏幕后，60 秒就能看出对方停在哪一级。 "一个 PM 现在能做的事比以往任何时候都多，但同时，真正具备这些技能、判断和好奇心的人并不多。" 速度变了，PM 101 反而更硬了 JZ 最后回到 PM 的老基本功。她在 Stanford 和 Reforge 教课，发现 AI leadership 的课程每个月都在变，PM 101 的底层原则却稳定得多：先看 problem space，不要太快跳到 solution；先知道为谁做、为什么做、成功长什么样，再开始建东西。 她提到 Reforge 的 AI leadership 课程每 6 个月开一次，两次之间内容变化巨大；可当她回去教产品入门课，反而会提醒自己重新检查日常动作：客户距离够不够近，问题空间有没有想清楚，会不会因为能快速 build 就急着做解决方案。速度变快之后，PM 更需要守住这些慢功夫。 "基本原则从未改变，甚至比以前更重要；但工具、运作方式，以及你穿过官僚环节的速度，已经彻底改变。" 产品负责人可以先查三件事：团队每天的重复动作有没有地图，高手的做法有没有变成 skill，入口有没有回到 Slack、邮箱和日程里。公司 OS 更像一种运营方式，把判断、动作和入口连起来，让团队在更快的速度里仍然贴近客户和问题。 写在最后 如果你暂时还建不出一整套公司 OS，先选一个每天都在重复、又总要来回追问的工作。把输入字段写清，把负责人分配清，把交付出口接回 Slack。AI 改造团队的入口，往往就是那个没人愿意再手动做的小动作。 内容来源："How to Build a Company OS in Claude Code"丨Aakash Gupta（嘉宾：Jiaona Zhang） 原视频：https://www.youtube.com/watch?v=qsDX0PMKcaE No access 32aaa7884ed944bfbc020b1be5f5baad 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/cV GGCVd... 🔗 原文链接： https://mp.weixin.qq.com/s/cV GGCVd... https://mp.weixin.qq.com/s/cV GGCVd... 原创 Capihom Capihom 晚点再听LaterCast2026年6月28日 20:30 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "你有那 1% 的 AI 用户，也有剩下 90% 到 99% 不知道什么时候该用什么工具的人。" "公司 OS 不一定一开始就是 OS，它从第一个自动化的小工作流开始。" "基本原则从未改变，甚至比以前更重要；彻底改变的是工具和你的工作方式。" Jiaona Zhang是Laurel的CPO，她做过 Airbnb、Dropbox、Webflow、WeWork 的产品负责人，也在 Stanford、Yale 和 Reforge 教产品。 很多产品负责人和创业团队现在卡在同一个地方：公司里总有一个人很会用 AI，能写 prompt、搭 agent、自动化掉一堆杂活；可其他人每天仍在问，该用 Claude、Slack automation、Dust，还是继续复制粘贴。Laurel 的做法，是把少数高手的操作沉淀成全公司都能调用的技能。 两件事把这期对话从工具分享拉回组织变化：JZ 的产品团队已经能把前端和后端功能端到端推到生产；她面试候选人时，会让对方直接共享屏幕，现场展示自己怎样使用 AI。公司 OS 已经进入团队分工、招聘标准和 PM 交付判断。 先把公司的活画成一张工作地图 JZ 打开的第一个画面是 GitHub。它看起来不像常见代码仓库，更像按公司职能拆开的工作目录：customer success、data science、design、engineering、finance、legal、marketing。每个职能下面继续拆动作，比如客户成功里的续约、追加销售、office hour、培训和 onboarding。文件夹里放着一组可以被 Claude 调用的 skill，也保留团队约定和参考资料。 Laurel 先做了一件事：把每个部门每天做的活拆到类别和任务，再标出哪些活希望人多花时间，哪些活应该交给自动化。销售、市场、客户成功、设计、工程、产品，每个部门都有自己的工作地图。产品团队那一栏尤其直观：竞品分析、stakeholder 写作、反馈整理、约人访谈、信息归档，过去都占 PM 大量时间，如今正在被重新分配。 "你有那 1% 的 AI 用户，他们高度 AI 化；也有剩下 90% 到 99% 的组织成员，不确定什么时候该用什么。" 公司 OS 的目标，就是让那 1% 的经验不要锁在个人电脑里。一个客户成功同事早上打开日程，看到今天的 check in、onboarding、handoff，同时看到每个环节该调用哪个 skill。一个 PM 开始处理需求，也能在同一套地图里看到 playbook、模板、自动化入口和负责人的分工。 这套目录还会进入 Claude 的组织设置。员工在 Claude 里处理一天的工作时，不需要重新解释公司怎么做续约、怎样准备客户会议、怎样写某类交付材料；skill 已经把团队约定、参考资料和步骤带进去。个人习惯被翻译成公司级的默认动作，团队才有机会用同一种声音服务客户。 先从一个烦人的重复动作开始 Aakash 问她，普通公司从哪里开始？JZ 给出的起点很小：先找一个团队反复做、又厌烦到不想再做的动作。比如反复写同一类邮件，反复往 CRM 填数据，反复在 Slack 里追问一条 feature request 的背景。 她举了一个产品团队每天都会遇到的场景。销售或客户成功在 ask product 频道里丢来一个需求：某个客户要某个功能。传统处理方式，是 PM 来回问：这个需求被提过多少次？有没有 Gong 录音？客户影响有多大？该分给哪个 PM？多久给回复？Laurel 把这些追问做成 Slack automation：自动收集信息、分派负责人、创建 ticket，并给 requester 一个可追踪的回执。 小自动化的好处很具体。PM 不再把一天切碎在“补一下背景”“给我录音”“这个客户 ARR 多大”这些追问里；销售也不用猜产品团队想要什么材料。字段被提前设计好，负责人与 SLA 自动生成，需求从一句 Slack 消息变成可处理的队列。公司 OS 的第一块砖，常常就是一张不再漏信息的表单。 "公司 OS 不一定一开始就是 OS，它从第一个自动化的小工作流开始。" 50 页 playbook，要拆成可调用的 skill 很多团队已经有 playbook。客户实施、销售话术、onboarding、续约支持、用户培训，动不动就是几十页。JZ 说 Laurel 的 GTM 团队也有 50 多页的 playbook，里面写着怎样帮客户上线，怎样给不同角色做培训，哪些场景需要人亲自参加电话，哪些材料可以提前准备。 文档写完只是前半段。更麻烦的是，团队是否真的照着做，哪些步骤交给人，哪些步骤交给 agent 或自动化工作流。Laurel 的第二步，是审计 playbook：把需要判断、需要现场沟通、需要客户关系的动作留下；把邮件草稿、LinkedIn 搜集、市场信息整理、RFP 支持、销售问题准备这类可重复动作，拆成一个个 agent。 JZ 提到他们会用 Dust 这类 agent builder。每个 agent 对应 playbook 里的某个环节；但团队成员不需要记住所有名字。前面再包一层大的 GTM agent，销售和客户成功随时发起请求，由它把任务路由给合适的子 agent。员工看到的入口仍是一条请求，后面的查资料、套 playbook、生成建议、回写记录由系统完成。playbook 从静态文档变成一组可执行的动作。 她还特别提到，有些步骤应该被产品化，有些步骤更适合交给 agent。比如客户成功经理反复起草邮件、销售反复搜 LinkedIn、市场团队反复整理行业信息，这些都可以从 playbook 里拆出来。上门沟通、判断客户关系、处理复杂承诺，仍要由人来做。OS 要给团队一张分工图：哪些事自动触发，哪些事必须留给人。 入口必须留在 Slack 和邮箱里 Laurel 的经验很现实：让员工去一个新界面里找 agent，采用率会掉。销售在 Slack，客户成功在 Slack，很多请求从邮箱来，入口就要回到这些地方。JZ 反复强调交付位置：工具做出来只完成一半，另一半是让人不用离开日常工作场。 公司 OS 和普通知识库的分界在这里。知识库等人搜索，OS 嵌进一天的动作里。早上看日程时，它提醒你会议准备可以调用哪个 skill；客户问题进 Slack 时，它自动收集缺失信息；PM 处理 feature request 时，它已经把字段、负责人和 SLA 整理好。员工不需要先成为 AI 高手，才能享受 AI 高手沉淀下来的做法。 Aakash 在对话里追问了一点：很多公司也有 agent 工具，为什么用不起来。JZ 的回答很直接，换界面的摩擦会杀死习惯。团队成员已经在 Slack 和邮箱里接活、交付、同步，AI 入口离这些场景太远，就会变成演示时惊艳、月底没人打开的工具。Laurel 把按钮、表单、agent 调度和结果回写放在员工已经停留的地方，让一次请求从发起到记录都能闭环。 AI Ops 不能只靠大家顺手做 Laurel 曾经让全公司参加 hackathon，目的是打掉一个心理门槛：非技术岗位也能做出东西。但 JZ 更看重后续的组织安排。她建议公司给 AI tooling、workflow 创建和日常工作自动化配一个全职岗位，写进 charter，别再塞进每个人待办清单角落。 "很多时候，当你说它是每个人的责任，它最后就成了没有人的责任。" 她把 AI Ops 叫作新的 Biz Ops。过去 Biz Ops 像瑞士军刀，帮公司看市场、看数据、补各种空缺。现在这类人要换一组肌肉：强好奇心，愿意试最新工具，对效率改造很执着。Laurel 一开始有 Sasha 这样的人证明效果，很快每个部门都会说，我也想要自己的 Sasha。于是 go to market、product、finance 都可能出现自己的 AI operations 人选。 Laurel 还有一个来自 CEO 的前置选择。公司 2018 年成立，早期产品围绕 timekeeping；后来创始人 Ryan 判断，在 LLM 和 AI 的世界里，手动填时间、靠集成拼接上下文会变得落后，于是推动公司和产品一起转向 AI native。JZ 说，CEO 的信念当然重要；但部门负责人也能从自己的职能开始，把每一项工作逐行标出：哪一块要 AI enabled，哪一块仍要人亲自负责。 她给了一个很普通的部门动作：营销负责人可以把 copywriting、视频制作、素材整理逐项标色。哪些工作已经不该手写，哪些地方只需要人来编辑和判断，先在自己的职能里画清楚。 产品团队会变小，但负责人要更能打 JZ 在 Laurel 的产品组织很小：5 个 PM，4 个设计师。她以前管过几百人，现在反而没有理由扩张。因为每加一个人，协作损耗也增加，端到端 ownership 变弱。Laurel 使用 captain model：每个 feature 有一个 captain，从发现、设计、实现到上线一口气负责；captain 不固定属于某个职能，而是由最能解决本次最难部分的人担任。 Captain model 也改变了产品评审。团队不再把一个 feature 拆成 PM 写需求、设计师画稿、工程师排期的长链条；负责的人要把最难的部分推进到底。如果最难的是客户洞察，PM 可能是 captain；最难的是交互和视觉，设计师可以接手；最难的是架构，工程师来牵头。Claude Code 这类工具让负责人能补上更多实现细节，ownership 反而更清楚。 她描述的 PM 也更像 product builder。Laurel 的 PM 会 ship 前端和后端功能，范围已经覆盖 billing 和 time entry 这类核心逻辑，有人甚至把相关功能端到端推到生产。JZ 说，经验丰富、判断扎实、又愿意亲手下场的人从来没有这么兴奋，因为过去消耗大量时间的协调和杂活正在减少。 招聘也随之变了。JZ 会让候选人 screen share，直接展示他们怎么用 AI。她把成熟度分成四级：第一级是在 ChatGPT 或 Claude 里聊天；第二级能自动化一个工作流；第三级开始为自己搭 app；第四级做 shared app，甚至能 ship 给客户。简历里写 AI pilled 很容易，打开屏幕后，60 秒就能看出对方停在哪一级。 "一个 PM 现在能做的事比以往任何时候都多，但同时，真正具备这些技能、判断和好奇心的人并不多。" 速度变了，PM 101 反而更硬了 JZ 最后回到 PM 的老基本功。她在 Stanford 和 Reforge 教课，发现 AI leadership 的课程每个月都在变，PM 101 的底层原则却稳定得多：先看 problem space，不要太快跳到 solution；先知道为谁做、为什么做、成功长什么样，再开始建东西。 她提到 Reforge 的 AI leadership 课程每 6 个月开一次，两次之间内容变化巨大；可当她回去教产品入门课，反而会提醒自己重新检查日常动作：客户距离够不够近，问题空间有没有想清楚，会不会因为能快速 build 就急着做解决方案。速度变快之后，PM 更需要守住这些慢功夫。 "基本原则从未改变，甚至比以前更重要；但工具、运作方式，以及你穿过官僚环节的速度，已经彻底改变。" 产品负责人可以先查三件事：团队每天的重复动作有没有地图，高手的做法有没有变成 skill，入口有没有回到 Slack、邮箱和日程里。公司 OS 更像一种运营方式，把判断、动作和入口连起来，让团队在更快的速度里仍然贴近客户和问题。 写在最后 如果你暂时还建不出一整套公司 OS，先选一个每天都在重复、又总要来回追问的工作。把输入字段写清，把负责人分配清，把交付出口接回 Slack。AI 改造团队的入口，往往就是那个没人愿意再手动做的小动作。 内容来源："How to Build a Company OS in Claude Code"丨Aakash Gupta（嘉宾：Jiaona Zhang） 原视频：https://www.youtube.com/watch?v=qsDX0PMKcaE No access 32aaa7884ed944bfbc020b1be5f5baad 00:00 No access 32aaa7884ed944bfbc020b1be5f5baad 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣