你大概已经在用 Claude 或者 ChatGPT 干活了。但如果诚实一点，多数时候的体感是这样的：你坐在屏幕前一遍遍点"批准"，等它问下一个问题，看它把一件三分钟的事做成三十分钟，然后自己动手重写一遍。

这不是 AI Native，这是在用 AI 加班。

Greg Isenberg 的频道上有一期近一小时的拆解，讲的正是这中间的差距。出镜的是 Theo Taba，他所在的 LCA 长期给全球大企业做 AI 产品和 AI 原生组织改造。整期节目最值钱的地方不在观点，在于他把两条真实在跑的工作流当场跑了一遍——浏览器地址栏、GitHub 目录树、运行日志、部署链接，全都留在画面里。本文按画面复核了一遍，也修掉了几处口头表述与画面不符的地方。

一句话先摆在这：AI Native 由人、Agent、上下文三层构成，多数人卡在第二层，而唯一构成护城河的是第三层。前两层是姿势，第三层是资产。

节目里引了 Demis Hassabis 在 Google I/O 上的一句话，作为整套方法的前提："以每小时一百英里的速度朝错误方向跑，还不如站着不动。"这句话在后面每一节都会重新出现一次——因为这套系统的产出就是速度，而速度本身不是目的。

01 先看清楚：AI 到底吃掉了工作的哪一段

Theo 给 AI Native 组织的定义只有三条：人管理 agent；agent 能读写公司内部的信息；公司随时间越来越聪明。

判断一个团队在不在这条线上，有个很省事的办法：看他们能不能说清楚"人现在具体负责什么"。

AI 之前，一件工作分三段：策略（要做什么、假设是什么、什么值得做）、执行（调研、起草、构建、测试、排版）、判断（够不够好、感觉对不对、哪里要改、下一步是什么）。画面上那张柱状图很直白，时间几乎全堆在中间那一段。

顺带更正一处：不少整理稿把第三段写成"沟通"，画面上写的是 JUDGEMENT。这个词选得比"沟通"准——收尾环节真正稀缺的不是把结果同步出去，是判断它够不够格发出去。

AI 之后，三栏没变，柱状图翻了个个儿：两头高，中间塌下去，塌掉的位置补了一行小字——Humans Managing Agents。图下面那句手写是整节的落点：Everyone's a Manager Now。

这句话听着像鸡汤，但它有一个非常具体的推论。管理者的产出等于团队的产出，所以你的活儿从"把事做完"变成"让一批不会累的执行者把事做对"。你不再是那个熬夜排版的人，你是那个要为别人的产出负责的人。

多数人对"我现在的工作是管理 agent"这句话是认的。问题在于，认了之后并不知道具体该干什么。

02 Agent 自主度分三级，你大概率停在第二级

Theo 引用了 Anthropic 的 Barry Zhang 对 agent 的定义：在一个循环里使用工具的模型。它需要一个环境、一组工具、一组目标。

按这个定义，现实里的用法可以分成三级：

• 第一级：和 ChatGPT 或 Claude 聊天。这是绝大多数人的位置。
• 第二级：部署了 agent，但你必须坐在电脑前，批准、批准、批准，等它问下一步。哪怕开了自动编辑，人还是被钉在椅子上。
• 第三级：像一个已经熟悉业务的员工。前期你带一带，之后它连续跑几天甚至几周，自己带着成果来找你。

第二级到第三级之间隔着的不是模型能力，是四样东西。

画面上这张图把它们摆得很清楚：目标（具体、可衡量、可达成、相关、有时限）、技能（playbook、SOP、可重复、可递归）、工具（MCP、内部的、外部的）、上下文（公司大脑、trace、可递归）。四个框指向中间一个词：Agent Autonomy。

图下面那两行小字才是重点：目标成为意图的标准接口，执行细节交给 agent。

Theo 用了一个类比来说明四样缺一会怎样：一个新人入职第一天，被要求在一周内独立做出一份董事会材料。目标模糊、技能不够、工具不熟、公司情况一无所知——必然失败。但很多人对 agent 提的要求，恰恰就是这个新人版本。

于是就有了那个熟悉的循环：一句提示词没得到想要的结果，断定 AI 名不副实，回去自己干。

03 Skill 就是 Markdown 文件，值钱的是把它们串起来

技能这个概念不复杂。Theo 在画布上直接写了：Skills = Markdown。

真正有意思的是他顺手打开的那个页面——LCA 的技能库不是内部秘密，它是公开的，地址 latecheckout.github.io/lca-skills。

画面里能逐条读出来，这套 Labs 技能包含五项：

• Publish a Prototype Live — 把原型发到 LCA Labs，创建或更新一个实验，拿回可分享的实时链接和二维码
• Set Up a Usability Test — 带着 Claude 走完一次可用性测试的搭建：假设、问题、原型，输出一个能直接发给受试者的链接
• Fetch Test Feedback — 把某次实验里所有参与者的标注拉出来，转成带空间位置和主题分组的结构化 Markdown
• Synthesize Feedback & Rebuild — 综合反馈、按结论改原型、重新发布为下一版
• Generate a Research Report — 把测试数据整理成带优先级的结论和设计建议，推回 Labs 面板

右侧还写着安装方式 /plugin install labs@lca-skills、作者 Paul Loots、版本 v1.2.0、共 11 个文件。页面底部两行说明了这套技能的适用边界：给谁用——跑原型测试循环的设计师和研究员；什么时候用——需要发布原型、查看测试、建立测试或者关闭反馈闭环的时候。

这两行写法值得抄。技能不只是"怎么做"，还得写清楚"什么时候不该调用我"。

skill chain 则是把这些技能按顺序串成一条链。一个宏技能内嵌多个技能，第一个跑完自动触发第二个，依此类推。Theo 的判断是这个概念被严重低估了：当模型和技能都在变强、技能开始能调用技能，agent 的自主性才真正显现。

为什么非得串起来？因为 AI 天生擅长"先假装做到、再真正做到"，而且这个倾向被放大了上千倍。单个技能没有交叉验证，它会把没做完的事说成做完了。链条的存在，就是让下一个技能去检查上一个技能的输出。

这个判断在下一节能看到具体形态。

04 提案 demo：三分钟出稿，值钱的是最后两道闸

第一条工作流演示的是提案。场景设定为 Spotify 是一家谈了几个月还没签的客户，现在对方要一份方案。

传统流程你很熟悉：客户开口 → 你回办公室翻会议记录 → 先回一句"在做了" → 找团队排期 → 几天后交付。等交付的时候，对方的热度已经过去了。

系统里的版本是这样的：邮件进来，系统识别出"要提案"这个信号，触发整条链，跑完之后 Slack 弹一条通知。Theo 说这一段的体感很怪——他在开会，什么都没做，突然收到一条"方案好了"，回头一查才知道刚才有人要过。

这条链在演示里由三个技能串成：先生成提案微站点，再做文案润色，最后质检，然后自动部署上线。

运行日志这一屏是整期节目信息量最大的地方，值得逐行看。它跑完了两道"scrub pass"，每一道都有名字：

第一道闸叫 lca-anti-ai-copy，管的是别写出一股 AI 味。日志里报的检查结果非常具体：零个 em dash（范围值一律改成连字符，比如 51-52%、Day-4）；不许出现套话（"we're excited to"、"transform"、"leverage"、"best-in-class"）；不许三段式排比；不许"partnering"这种客套词；用具体数字和客户自己说过的比喻来承载文案。

第二道闸叫 lca-over-promise-rubric，管的是别把话说满。检查项同样具体：结论性说法必须带条件；关键的提升数字不许进正文；下游效果要写成条件句（"如果这项工作落地"）；信号必须明确标注为"方向性的，不是统计显著的"；必须保留"受控 A/B，不靠弱信号就发版"这一句；不许承诺任何依赖客户团队配合才能达成的最终状态。

这两条闸才是可以直接搬走的东西。它们跟哪个模型无关，写成 Markdown 就能用。

跑完之后系统执行部署：构建、护栏检查、发布到 Vercel，返回 HTTP 200，护栏干净，Slack 通知发到 #demo-spotify-internal。日志最后一句还特意注明：那个作为参照的 golden 版本自始至终没被碰过。

产出的不是一封邮件，是一个微站点。标题是「Spotify × LCA：Home & Discovery sprint for new-listener retention」，正文第一段就把整个方案压成一个问题：一位昨天才注册、系统还不知道他喜欢什么歌的听众，首页应该为他做什么？三个方向、真实听众信号、一个你们团队可以直接接手的编码原型。

顺带说一句，这些页面上的模型和参数也露在画面里：Claude 桌面客户端，模型 Opus 4.8，投入度选的是 Medium。Theo 自己说这是为了录节目才降的档，平时会用更高档位，而且高风险任务一定把权限确认打开——他要亲自看它在造什么东西。

自主是分级的，不是全开或全关。

05 个性化不靠模型记性，靠一份躺在仓库里的会议纪要

提案里有两处细节让 Greg 当场愣了一下。

一处写着："一个让人感觉像家的地方，应该像一位认识你的唱片店店员，他把唱片递给你，然后说'相信我'。"另一处写着："祝十一月的比赛顺利，在第八英里留点力气。"

这两句不是模型编的。它们有出处，而且出处就在硬盘上。

Theo 为这期节目单独开了一个仓库 theo-tabah/personal-brain。所谓"大脑"，展开就是一堆装着 Markdown 的文件夹：客户目录下分 correspondence（往来信件）、design-system（设计系统）、meetings（会议）、proposals（提案）、slack 五个子目录。

meetings 里躺着三个文件，文件名就是索引：2026-02-04_intro-call_maya-chen.md、2026-04-28_discovery-call_…、2026-05-01_scoping-call_…。

点开第一个，是一份 76 行的逐字稿，带时间戳。Maya 在 00:28 说：

我是个黑胶爱好者，尴尬的那种。2020 年开始收，因为实在没别的事做，然后它彻底改变了我对数字化发现音乐的看法……唱片店的关键是柜台后面那个人把东西递给你，说一句"相信我"。那才叫发现，那才是那种感觉。我们太擅长"播放音乐"了，我觉得我们丢掉了一些"某个了解你的人把这个递给你"的魔力，尤其是对刚来的人。

Theo 在 01:34 接了一句："算法就是那个读过你档案、但从没正眼看过你的店员。"

再往下，02:38，她提到自己在为十一月的纽约马拉松训练，"在产品经理的日程表上这是个蠢决定，但我在第八英里的时候思路最清楚"。

这里要更正一处流传的说法。不少整理稿写成"她说第八英里最难熬"——画面上的原话是她在第八英里时思考状态最好；难熬的那一段是 Theo 在下一句里调侃的第二十英里。提案最后写的"在第八英里留点力气"，是把她自己的说法反过来用了一次。

日志里也交代了这几处引用各自的位置：唱片店店员那句放进了机会分析段；她说过的"这个仪表盘是我拿到预算的方式"被改写成"我们为听众而建，不为仪表盘"，用作选择 LCA 的理由；温度最高的那句放在首屏；马拉松那句压在结尾。

这就是上下文层的实际形态。不是模型记性好，是那次通话被转成文字、被归档、被放在 agent 能检索到的路径上。写方案的时候，那个"如果我时间充裕一定会写进去"的细节，就自己浮上来了。

⚠️ 一处必须说明的边界：这个仓库的 README 里明明白白写着 synthetic: true、purpose: demo-scaffolding。Maya 是虚构人物，Spotify 也没有真找他们做这件事。演示的是机制，不是战绩。

06 递归上下文层：四个动作，加两条回流

到这里才进正题。前面两层都好办，难的是这一层。

Theo 现场问了 Greg 三个问题：LCA 提交客户提案的标准流程是什么？Stumble Upon 在 2014 年的战略是什么？两周前谁加入了公司？

Greg 三个都答不上来。Theo 说自己也答不上来，包括那些他亲自参加过董事会的公司。

这不是记性问题。公司乘以 N 个团队和 N 个人之后，任何人对整个组织基本上是盲的。画面上那只闭着的眼睛周围散落着文件、表格、数据库——信息都在，只是没人看得见。

上下文层要做的，就是把这只眼睛睁开：Slack、Gmail、Notion、云盘、看板里的东西被结构化，agent 对公司拥有所谓的"2020 视力"。你想问什么，随时能拿到答案，不用猜，不用发十几条消息去问人，不用等几天。

画面上这张图有个正式名字：The Recursive Context Layer（递归上下文层）。四个方框加一条回路：

• CAPTURE（采集） — 把上下文引进来。标注是 Routine，也就是定时跑的例行任务。Slack、邮件、会议记录、项目看板，每一两个小时收一轮，落进一个类似"大脑收件箱"的地方。Theo 强调这不是普通 cron，它能挂 Claude 或者 Codex 去跑，配置规则也简单。
• CURATE（策展） — 归档之前先过一道"图书管理员"：读它、清理它、归档它、忽略它、或者对它采取行动。最后那条最关键，某些内容本身就是触发器，比如一封写着"能不能看看方案"的邮件。
• STORE（存储） — 存进一个"为 agent 优化过的公司大脑"，这一格的标题写的是 Make Context Legible，让上下文可被读懂。
• EXECUTE（执行） — 人和 agent 在这里干活：定目标、构思与做原型、产出物料、跑技能和任务、评审并交付。

STORE 那一格里的目录树在放大后能读清楚，它就是这套东西的全部物理形态：

knowledge/
├── frameworks/
├── sops/
│   └── by-function/
├── enablement/
├── decisions/   （带事件时间戳）
└── glossary.md  （术语表，图里管它叫"图例"）

没有向量数据库，没有中间件。就是分层文件夹加 Markdown，靠目录结构本身把 agent 引导到正确的位置。Theo 也提到市面上有 Glean、Notion AI 这类打包方案，能省事，代价是底层怎么运作相对不透明；他们选择自己搭这一层。

四个方框之外还有两条回流线，它们才是"递归"这个词的来源：

第一条是 Traces from all work（所有工作留下的痕迹）：决策是怎么做出的、工作的副产品、过程中长出来的洞察。Theo 管这些叫"剪辑室地板上的素材"，也有人叫 exhaust（废气）。一份提案背后有大量被砍掉的方向，那些才是下一轮决策的养料，而在大多数公司里它们直接进了没人再打开的文件坟场。

第二条是 Signal from the market（来自市场的信号）：交付之后用户怎么反应——新功能上线购买涨了没有、新落地页流失快了没有——这些回到工具里，再回到大脑。

最后一格叫 EXPERIENCE，写的是 Context Becomes Value：使用、实现价值、反馈、购买续费推荐留存、把信号送回去。

这里有一条必须守住的纪律：agent 自己产出的东西，不能未经筛选就流回采集层。中间那道人的判断——这条好、这条不好、这条要改——就是防止系统自我污染的闸门。你每次纠正 agent，它写回技能库、更新记忆、把经验沉淀成可复用的课程，这个动作本身就是在给大脑喂料。

07 原型到 V2：五个技能一条链，以及一个必须知道的坑

第二条工作流演示的是产品迭代。Theo 现场用语音说了一段需求：给 Spotify 加一个提升留存的功能，每天推一组三首歌的迷你歌单，入口放首页，进去能看到为什么挑这三首，可以保存、分享、直接播放，十分钟内做完，符合现有设计系统，而且要能测留存。

十分钟后，东西在这儿。

功能叫 Daily Blitz，当天那组歌单叫 Slow Burn，三首歌八分钟，午夜刷新。右侧面板里连产品说明都齐了：给谁用——想要新鲜音乐、但不愿意主动翻找的活跃听众；使用场景——听众从首页打开、读完挑选理由、播放或分享；四步流程也列好了。

页面上那句 "WHY WE BUILT THIS FOR YOU" 下面写着挑歌理由。这一条后来在测试里被验证是整个功能最受认可的部分。

接下来是这条链的第二段：可用性测试。系统生成一个链接，打开是一个正经的受试者引导页——"这是一个早期原型，随便用，没有对错之分"，然后告诉你会经历什么：先几个快问题，再在原型里做一个任务，过程中问几句，最后收个总体感受，大约四分钟。

Greg 在手机上真填了一份。测试结果流进 Signal 面板，面板上先写着假设：我们相信每天一组精选三首歌、每首都说明为什么被选中，会让听众愿意每天回来发现音乐。

点一下"综合"，系统吐出三段结论：期望：用户说"我希望有更多选项"，三首的限制让他觉得不够，建议 v2 试试扩到五首；发现：他愿意每天回来的动因是"我一直需要新音乐"这个长期未被满足的需求，而不是这个形式本身新鲜，所以 v2 应该强调持续的新鲜度；验证：挑歌理由这个设计得到强烈正反馈，v2 必须保留。

然后点 Plan V2，第二版在同一个会话里生成。从想法到 V2，全程没有换过工具。

🔴 但这里有个坑，而且画面自己承认了。这三段结论是在一个样本上生成的——面板原文写的是 "The sole user scored..."（这位唯一的用户……）、"1/1 selecting"。在此之前那个面板还写着"还没有结论，收集到足够信号再来综合"。

Theo 自己也说了正确用法：把链接发给五个、十五个、四十个人，等数据够了再综合。但演示里为了跑通流程，一个样本也照样生成了一份措辞笃定的报告。

这正是 skill chain 最需要警惕的地方。链条会一路跑到底，中间没人喊停，最后那份报告读起来和五十个样本的报告长得一模一样。速度会让结论看起来比它实际更可靠。回到 Demis 那句话，方向错了跑得越快越糟。

08 把这套方法卖出去：三个向量切一个细分

最后一段是创业方向。Theo 给的名字是 Verticalized AI Acceleration Services（垂直化的 AI 加速服务）。

交付形态两种：一种是 30 天冲刺，路径是审计 → 上 agent → 给出加速路线图；另一种是常驻的 AI 加速小队，把系统（人、agent、上下文）搭起来，演示速度的结果，拿出可见的信号，然后沿路线图重复这个循环。

画面上有两句写给乙方的纪律，容易被跳过：定义可达成的 KPI；逐步扩大范围和对"成功"的定义。这两句是在说，别一上来就承诺全公司转型。

切入方式是三个向量交叉，画面上写的是 Cut your niche on three vectors. Start Small. Small is BIG.：

• 行业：商业地产、牙科、保险、物流……
• 职能：销售运营、客户支持、理赔、招聘、财务……
• 公司规模或形态：1000 个单元以下、50 人以下、单门店……

选行业有个约束条件：要足够分散、痛感足够强，但不能小到没有预算。

排优先级用这张 2-Up Prioritization Map。纵轴从细分到通用，横轴从低频到高频，四个格子都编了号：

• #1 从这里开始（细分 × 高频）：确定了细分领域之后，找到那个你熟悉的、高频发生的金矿工作流。
• #2 通用但重要（通用 × 高频）：细分场景跑顺了，再去做高 ROI 的通用任务。
• #3 独特但高价值（细分 × 低频）：需要大量定制，但 ROI 可能很高，也可能长成一个产品。
• #4 低频且通用：要不要碰是个未知数，可能一直放着，或者交给团队处理。

先做 #1 的理由很实际：高频意味着你能在销售电话、提案、内容里一遍遍演示同一件事，重复本身就在累积优势。

09 这套东西的边界，以及从哪里起步

复述一遍核心判断：AI Native = 人 + Agent + 上下文。前两层是姿势，第三层是资产。

需要一起记住的几条边界：

演示是合成数据。 那个 personal-brain 仓库的 README 自己标了 synthetic: true。你看到的是机制跑通了，不是这套机制在真实客户身上产生了这些结果。

链条会掩盖样本量。 一个人填的问卷和五十个人填的问卷，综合出来的报告长得一样自信。所有自动化的终点都要有一处人来看的地方。

自主是分级的。 演示里 Theo 自己把权限确认打开了，理由是高风险任务他要看它在造什么。全自动是配置项，不是目标。

别一次搭全套。 那个上下文层的最小可用版本，就是一个文件夹、一个定时任务、一条把三个技能串起来的链。目录树比工具重要，先能被检索到，再谈聪明。

如果只做一件事，我会选最不性感的那件：把你团队最近三次真实对话——客户通话、内部决策会、一次复盘——转成 Markdown，按 客户/会议/日期_类型_人名.md 归档，然后让 agent 在下一次写东西的时候先读它们。

那份提案之所以能写出"在第八英里留点力气"，不是因为模型聪明，是因为有人在四个月前把那句话存了下来。