← 主页 NO.203

第 203 期 · AI 产品 · 收录于 2026 年 8 月 25 日

身为独立创始人,我如何 24/7 管理 15 个 AI Agent——Ryan Carson(Untangle)

Ryan Carson · How I AI

AI 产品产品

视频 44:14 原文约 4.1 万字预计阅读 31 分钟来源视频 ↗ 中英对照全文

原平台热度 YouTube ↗

1.2万观看

276赞

2.2%点赞率

38评论

11万频道订阅

数据截至 8 月 27 日

TL;DR · 三句话

一今天真正的核心技能是「管一大群 agent」，而它靠的是老派的管理功夫——Ryan 一个人同时跑 10-15 个云端 Devin 线程，靠 Bugs / P0 / P1 / P2 文件夹把它们压回人脑能盯住的四五个桶，外加一张手写的周优先级纸；Claire 则反过来给"自己的时间"分块。"你职业生涯里练出来的那些管理能力，现在正好能用在这儿。" → 详细
二两位最"AI 上头"的人，花了大半场在讲 AI 解决不了什么：没有哪个前沿模型"聪明到知道该发什么"，自动改进闭环在产品上"像个笑话"，代码产量和可商业化产品之间存在错配——所以 Claire 刻意压着不多发（"我不觉得能用翻倍的产出换来翻倍的质量"），Ryan 的 PMF 是靠一封外呼邮件和一句"我能去你们办公室吗"问出来的。→ 详细
三管住产出质量的不是更强的模型，而是你搭的验证与放行闸门：Claire 的 Merge Mommy 给每个 PR 打五维风险分、低风险自动合、中高风险 @ 人（为满足 SOC 2 合规）；Ryan 的 land PR 跑两轮自动评审 + 让 agent 录一段带解说的视频走查，他看完说"视频通过"才准 merge。→ 详细

开场暴论：「你还在本地干活，该睁眼了——未来基本是 100% 云端 agent」

Ryan 开场就把话说死："If you're out there listening and you are doing engineering, you're doing your work locally, you really need to open your eyes. I think the future is pretty much 100% cloud agents."（如果你是做工程的、活儿还都在本地干，你真得睁眼看看了——未来基本会是 100% 云端 agent）。他自己补了一句退路："there's going to be some local dev"（还是会剩一部分本地开发），但主战场已经搬走了。→ 详细
他搬家的动因非常朴素：一开始用的是 Cursor、Amp 这类"绑在本机上的 agent"，"我必须坐在自己机器前面"才能干活；而他手头一天到晚是"这儿有个 bug 得修一下""这块数据怎么回事得看看"这种碎活。于是他想——"why isn't cloud? I feel like I should be working on the cloud?"（为什么不能在云上跑？我觉得我应该在云上干活才对）。→ 详细
他挑中的是 Devin（Cognition 公司做的云端编程 agent，可以理解成"一个你派任务给它、它自己开分支写代码提 PR 的远程实习生"）。他坦承自己是带着偏见去试的："刚出来那会儿挺烂的，对吧？但说不定现在好用了。"结果一试就被"这个云端 agent 的成熟度"震住了。→ 详细
主持人 Claire Vo 给了同方向的佐证：一年前那期他俩还在 IDE（代码编辑器）里手把手管 agent，而她现在"好几个月没打开过 IDE 了"，并甩出本期最出圈的一句自述——"What the agents are doing is none of my business."（agent 在干什么，不关我的事。）Ryan 接话："让它们干，我一般就给个目标。" → 详细

一个月烧 2 万美金的 agent 账单，以及他怎么把账单变成 0

具体数字很硬：Ryan 一开始每月在 Devin 上花 5,000 美金，后来涨到 一个月 2 万美金。他被自己的账单吓到了——"等一下，我 Twitter 账号粉丝不少啊"——于是直接去找 Cognition（Devin 背后的公司）要免费额度，对方真给了，现在他每月拿 2 万美金的 Devin 额度。→ 详细
这段的信息量不在"他薅到羊毛"，而在他愿意在找到 PMF 的关键期把 2 万美金/月当成正常人力成本付掉——他的原话是"I went all in"（我全押了）。换算下来这大约是一个中级工程师的月成本，而他买到的是十几个 24 小时不睡的并行 thread。→ 详细
他反复强调"I live in Devin. I live in the cloud"（我就活在 Devin 里，活在云上），几乎所有工程活都在里面跑，同时开着 10 到 15 个 thread。→ 详细

他管 15 个 agent 的核心动作：用文件夹做「分诊」（Bugs / P0 / P1 / P2 / Investors）

他把这件事定义成一门可练的手艺："the skill is managing throngs of agents. Like that is what I do now."（真正的核心技能就是管理一大群 agent，这就是我现在干的活。）而人脑装不下十几条并行线，所以"你基本上只能把这些东西分桶"。→ 详细
分桶的具体形态就是 Devin 里的文件夹，节目里他直接把真实工作台投屏出来：Bugs（有事发生、想较快解决，但不到 P0）、P0（"不管我今天被什么事打断、无论如何都得往前推的事"——也就是作为一门生意的主线，新功能都在这里）、P1（"重要但没那么急"）、P2、以及一个 Investors（投资人）文件夹。他当场点开 Bugs 里一条正在跑的任务："Investigate red error retries"（排查报错重试）。→ 详细
分桶的设计依据他说得很明白，而且是从 Claire 自己的节目里学来的："我记得你有一期节目里，不是你就是你的嘉宾说过，人真正能同时盯住的大概也就四五个并行任务。我同意这个说法。所以我用的办法就是文件夹。"——文件夹不是为了整理，是为了把 15 条线压回到人脑能处理的 4-5 个"桶"。→ 详细
Investors 那一桶他顺手给了条建议："如果你还没用 agent 帮你起草投资人更新、帮你盯着公司的情况，赶紧去做。但关键在这儿：把它做成一个 skill。"他自己就建了一个"投资人更新" skill。他还提到 Devin 里叫 playbooks，并诚实吐槽现在"skills、playbooks 这些概念是有点混在一起、说不太清"。→ 详细

八块屏幕之外的那张纸：一周优先级写在纸上，才不会飘

全场最反差的一幕：Claire 问能不能展示一下工作台，Ryan 举起来的第一样东西是一张手写的纸。Claire 当场吐槽："这就是为什么我们嘴上说要招人类——然后要给你们看的，是我们自己涂涂画画的几张纸。" → 详细
他保持专注靠两套东西并行：一是 Devin 里的 P0 文件夹，二是这张写着"这一周的优先事项"的纸。他的具体处境是"我这儿摆着一台 Dell 52（52 寸带鱼屏），同时开着八个屏幕"——屏幕越多越容易飘，所以需要一个屏幕之外的锚。他说这张纸"能让我一直踩在地上、不飘"（keeps me grounded）。→ 详细
他还用了一套叫 Ugmonk（Analog 卡片式待办）的纸质系统，并主动声明"没人付钱让我这么讲"。→ 详细

两种截然不同的 agent 管理风格：Ryan 的分诊台 vs Claire 的「Slack 甩一条 Sentry 链接」

Claire 主动把两人的差别摆出来当对照组——"你我是两种很不一样的 AI 管理者"。她形容 Ryan："这人也太有条理了吧……你居然不是随手往 token 里一泡、看那头能吐出什么来。" → 详细
她自己的做法则粗放到极点："I just Slack Devin. Like he belongs to me. I just like a Sentry link. WTF question fix."（我就在 Slack 上直接找 Devin，跟他是我的人似的，甩一个 Sentry 报错链接过去，配一句"这什么鬼？修一下"。）Ryan 的回应值得记："and that works. There's nothing wrong."（那也管用，这没什么不对的。）→ 详细
Claire 由此引出本期最值钱的一个判断："the job right now is to figure out how to manage agents"，而为什么是有资历的人现在最容易在 AI 上做出成绩——因为"你职业生涯里练出来的那些管理能力，现在正好能用在这儿，就在当下"：怎么搭结构、怎么组队、怎么定优先级、怎么把活派出去、"当你手下有 500 号人的时候，你怎么还能死死盯住对你最重要的那三件事"、哪里该盯细节哪里该放手——"所有这些东西，到今天依然有回报。" → 详细
Ryan 给这套逻辑找了个更古老的根据："这正是为什么组织当初都被搭成金字塔形——人是没法无限扩张的，谁也带不了一千个直属下属，除非你是 Jensen Huang。" → 详细

Untangle 的转型故事：消费者不想用 AI 离婚，律所却抢着付钱

起点很私人：Ryan 有三个亲姐妹、其中两个正经历"相当难熬的离婚"，他父母也离过婚，而"好像没人在把离婚和 AI 放到一起讨论"。第一版 Untangle 做的是 to C，结果"没人想用 AI 来处理离婚，大家要的是律师"；他的反应是"我年纪够大了，知道别死抱着不放，直接转就完了"。→ 详细
转型动作只有一个：约一位律师（Renee Bower）当面问三句话——"你喜欢它还是讨厌它？它对你是敌是友？" 她的回答是"我很喜欢"，理由是 paralegal（律师助理）严重短缺、离婚案里的 discovery（证据开示，双方依法交换财产文件与记录的流程）"简直是噩梦"，并主动报出"一个特别漂亮的数字"愿意付钱。产品于是掉头做 B2B、卖给家事律所，"业务正在爆发式增长"。→ 详细
代价是他"彻底忙崩了"——他借 SpaceX 术语称自己处在 "max Q"（最大动压时刻，火箭受力最猛的那一瞬），"压力大到我必须招人了"。本期的隐藏结论也在这儿：两位"我一个人全都能搞定"的著名独立创始人，录制前闲聊的竟是"让人后悔、却又迫在眉睫的招人计划"。Ryan 的注脚："招惯了 AI 你是会被惯坏的——你可以一小时给它们提 45 条反馈。" → 详细

Watchdog：把「我不知道公司现在什么状况」的焦虑，做成一个可重复跑的 skill

这是本期最可复制的一招。Ryan 的处境是"我一个人同时在做客户成功、工程和销售"，律所客户越接越多、每家手上案子一堆，"你到底怎么知道这些案子里正在发生什么？客户在哪儿撞上了 UX 的 bug？"于是他做了一个叫 Watchdog 的 playbook（Devin 里的叫法；他特意说明"你要是不用 Devin，做成一个 skill 也一样"）。→ 详细
触发时机是情绪，不是日程——他把这点说得很直白："你要的是这样一个时刻：你突然觉得『我现在必须知道公司里到底在发生什么，我很焦虑，我不清楚状况』——这时候我就跑一次 Watchdog。" → 详细
它的机制是"一个 skill 对每家客户重复跑一遍"：进到每个律所账号里问——这个账号最近怎么样？从上次跑 Watchdog 到现在有哪些动静？报错出在哪儿？Sentry（线上错误监控服务）上的报错在哪儿？ → 详细
最关键的是输出形态，他强调"你要的不只是一堆数据，你要它帮你把数据转个向、筛一遍、排好序"：最终产出是「当前最糟的三件事」，而且每件事还要追问一层——"这个到底修好了没？是正在修？还是有个 PR 开着一直没合进去？"（因为他"一天大概发 40 个 PR"，状态本身就在不停变）。拿到这份三件事，他再在那条线程里往深挖。他的总结："That's how I manage the chaos."（我就是这么管住这一团乱的。）另外他提醒：这东西"迭代了很多轮才成型"。→ 详细

Claire 的决策疲劳解法：不给任务分桶，给「自己的时间」分桶

Claire 自嘲"我是每生一个孩子就开一家公司，三个孩子、三家公司，所以我的决策疲劳可太多了"。她的路子和 Ryan 明确相反："比起给任务分类，我更多是在给自己的时间分块"——一天里有一段专门做"跟 AI 双人驾驶"的具体活儿，另有一段专门用来把任务派出去、或挨个查看进度。她认为独立创业者必须这么切。→ 详细
第二招更值得抄：拿"决策疲劳"本身当优先级启发式——"如果有个我在做的功能，我一直放着让它烂在藤上（let it die on the vine）、迟迟不推进"，那就是一个信号："这个可能并不是我真正在乎、真正相信的那个。"（Ryan 当场接话："that's your symbol.") → 详细

「我是 token maxer，但我刻意压着不多发」——本期最反直觉的一段

Claire 说了一段她自称"别跟别人说"的话："I know I'm a token maxer and you should let your agents run 24 hours a day and ship as much code as humanly possible... And I really don't ship more than I think the market wants."（我知道我主张让 agent 一天 24 小时跑、尽人类所能地多出代码；但我其实真的没有超出我判断的市场需求量去发东西。）她强调这种约束不在质量上、也不在 bug 上，纯粹是产量。→ 详细
她给的理由是一句可以直接当原则用的话："I don't think I get multiples of quality off of multiples of output."（我不觉得我能用翻倍的产出换来翻倍的质量。）所以她"宁愿把那股创造力留给别的事，或者至少先攥在手里，等真有点东西了再拿出来"。→ 详细
落到具体作息：她通宵跑的东西比 Ryan 少得多，跑的多是修 bug、做分诊这类活儿；她还跟一位工程师搭档，两人"来回接力通宵跑"。她明确不做那种"自己找想法、自己解决、然后一律发出去"的循环——"一是它给我自己的负担太重，二是我不觉得它真的创造了价值。" → 详细
两人在这里达成本期最重的共识。Ryan："我其实觉得，要说有哪个前沿模型聪明到知道『该发什么』，我们离那还差得十万八千里"——"那真是差了一百万英里。"Claire："我们当初都想要那种自动改进的闭环，但它在产品这件事上就是行不通"；Ryan 补刀："那玩意儿有点像个笑话。" → 详细
Claire 还把这个判断推到了市场层面，这段值得反复读："这么多智能并没有凭空变出原本不存在的市场——除了 AI 本身那些市场之外。又不是说突然之间冒出来一堆买家。" 所以她认为存在一种"代码产出的数量，跟真能商业化的产品之间的错配"。→ 详细

最「反 AI」的一段：从椅子上站起来，去见活人

Ryan 顺着上一段往下挖："我觉得现在的问题是，大家不够常从椅子上站起来、去跟真实的人聊。"他给出的因果很锋利：正因为我们现在能做出、能发出那么多数字产品，我们反而越来越不肯离开椅子了。 → 详细
他摸到 Untangle 的 PMF 只用了两步，都不涉及 AI：第一步——发一封外呼邮件，跟一个潜在客户开个 Google Meet，聊；第二步——"一把他们签成客户，我马上就问：『我能去你们办公室吗？』我就是想坐在那儿、想跟他们聊。"他自己都说"这些都是很基本的产品常识"，但恰恰是现在最容易被跳过的。收尾两句是本期的口号："Go talk to humans for real. And build something neat." → 详细

被严重低估的用法：云端「编码 agent」根本不只用来写代码

这是 Claire 说对她"是个 game changer"的一点："我觉得大家到现在还是把这些云端编码 agent 归类成『编码 agent』，好像它们唯一的活儿就是给某个软件产品写代码。" 而她的实际用法是——"Devin runs Deal Desk for me."（Devin 在帮我跑 Deal Desk，也就是销售报价台。）具体包括：做定制报价、把运营的事安排起来、写文档、客服工单分流。→ 详细
她给了一个可以直接拿去用的提问模板："如果你身边有这么一个人，他既懂你的代码库，又能写代码解决你业务里的任何问题，你会让他去干什么？"——用这个问题去想，就不会只让它写功能。她的判断是"大家对自己的 background agent 要求太少了，尤其是那些编码能力特别强的"。→ 详细
她还给了一个行业趋势佐证：Cursor（或 Grok，她自己也没记准是哪家）刚发了个 Grokbot，"看到这些编码平台开始往通用的业务 agent 上扩，我一点都不意外"。结论是："不该只有工程师去上手 background agent 和云端 agent，因为它们能相当自主地帮你的业务干太多事。" → 详细

本地 agent 为什么还没死：低延迟 + 能碰你本机浏览器 + 「无限 token」

Ryan 虽然主张 100% 云端，但他自己也开着 Codex（OpenAI 的编码 agent）在本地跑，配合一个转写里叫 goal 的东西（ASR 未确定的专名，原样保留）。他给出的组合优势有三：延迟低、能跟本机上的浏览器配合、以及"基本上是无限的 token"——后半句他还调侃了一句"来自 OpenAI 的……对，这个补贴我就收下了"。→ 详细
本地 agent 的适用场景他说得很具体："我手上有个功能要做、前端 UI 的活儿特别多，我就是需要你埋头猛干一大堆，同时我得守在旁边、多少要手把手带着你。" 这种活儿他认为 "Codex 无可匹敌"。换句话说——要不要用本地 agent，取决于这件事需不需要你在场高频干预，而不是取决于它是不是写代码。 → 详细

Claire 的完整独立创始人配置（本期最密的一段清单）

Codex（她主要待的地方） 用于三类活：① 横跨前后端的大功能——"需要写很多代码、得死磕，而且时不时需要你介入，把它收敛到你想要的那个体验上"；② 长周期重构和架构层面的活；③ 验证——她认为 Codex"做验证特别在行"。→ 详细
她的前端验证流程可以整段抄走：用 goal 配 browser use（让 agent 直接操作浏览器），指令是——"写用户故事，用 Chrome，在 Chrome 里把 preview 分支调出来，以用户的身份走一遍，列出哪些用户故事通过了，找出 bug，一直修到没问题为止。" 后端/核心流程则是"goal 加上一个能在你代码库里跑的 CLI 工具来验证"。→ 详细
background agent（云端） 用于：大量自动修 bug；一次性的临时活——她举了个特别生动的例子，"我在跟客户开会，他们问『你们有这个 MCP 吗？』我就说『现在有了。』"；以及运营类工作。→ 详细
两个专门定制的 agent：PR 评审她大量用 Bugbot；另外她自己做了一个名字起得很促狭的 Merge Mommy——给她的每个 PR 做风险评估，低风险的自动批准，因为她每天发的 PR 也很多。（Ryan 立刻要求对比："跟我讲讲 Merge Mommy，然后我再跟你讲我的 land PR skill。"）→ 详细

Merge Mommy 拆解：给每个 PR 打风险分，低风险自动放行、中高风险才叫人

这是本期最完整的一套"自动化 + 人类闸门"设计，Claire 讲得很细：它是个 EVE agent（转写原样保留的名称），部署在 Vercel 上。触发条件是"PR 被打开、并且通过了全部 CI 检查（包括 Bugbot）"——也就是说它站在所有机器检查的下游，只处理"机器都认为没问题"的 PR。→ 详细
它的动作是"从五个风险维度给这个 PR 打分"，她举的例子是"影响半径（blast radius）有多大、安全性"之类。打分低 → Merge Mommy 直接盖批准章，不需要人批就能合。→ 详细
中风险或高风险 → 在 Slack 里 @ 具体的人（她本人、她同事或其他人），说"这个 PR 该你来 review 了"。她点明了这道人类闸门为什么不能省："因为要满足我们的 SOC 2 合规（一套企业级安全审计标准）和那一整套控制要求，我们必须有由另一个人来复核的 review。" 效果是"清 PR 队列的效率特别高"。→ 详细

Ryan 的 land PR：两轮自动 review + 一段带解说的视频走查 + 人说「视频通过」才合

对照组同样精彩。Ryan 的 land PR 也是 Devin playbook（"你可以把它理解成一个 skill"），触发时机是 agent 回来说"PR 做完了"的那一刻。→ 详细
第一步：在这个 PR 上重新跑一遍 Devin review（Devin 内置的评审产品），最多允许循环两轮——"把所有 bug 找出来，确认所有评论都处理掉了，然后又会冒出来一些新的，再来一遍，一共两轮"。→ 详细
第二步是他最看重的：录一段视频走查。他描述得很具体——"它会在浏览器里录屏，而且还会配上解说，画面上有字幕说明它正在做什么，还有个很酷的小测试清单，一条条列着是红还是绿，这些全都是开箱即用的。" → 详细
最后一道闸门是人："land PR 的核心就是：它必须把那段视频给我看，我看完说『视频通过，合了吧』，它才会去 merge。"——注意他验的是看得见的行为，不是读代码 diff。→ 详细
他借这段说了个"选平台"的观点："你的 code factory（代码工厂）应该自带一套好用的 review，而且得是个真正的 review 产品。" 理由是他自己试过："我以前也试过自己搭一个 code factory 把这些都做出来，然后我就想——我哪有这个时间。" → 详细
一个容易被略过但很重要的结论："这也正是为什么现在 CI/CD 和 DevOps 你得做得更好、而且要真的重视它。" 他们在 GitHub 上用 merge queue（合并队列：PR 排队依次基于最新主干跑一遍检查再合入，避免互相冲突），他"现在特别喜欢 merge queue"。→ 详细

同一个功能，两个人体验天差地别：视频验证 Ryan 完美、Claire 直接趴窝

Claire 当场坦白："我这边 Devin 的视频验证一直跑不通，偶尔能让它截个图，而且在前端这块，它会把我这个 session 的额度全吃光，然后就直接趴窝。"她还很有风度地补了句："这大概率是我自己的问题。AI 上的所有问题大概都是我自己的问题。"随后她真的现场找了个成功案例演示，画面里能看到 Devin 边测边打字幕、"把自己的推理过程都露出来了，超酷，也非常有用"。→ 详细
Ryan 给出了差异的可能原因：他体验"几乎完美"是因为"他们用的是 web app"，而 Claire 是在 Slack 里看 Devin 的预览。（Claire："我从来不进 Devin 的界面，从来不进。"Ryan："有意思的是，我几乎从不进 Slack。"）——同一个 agent 产品，入口不同，能力上限就不同，这是本期一个很实在的暗线。→ 详细

Slack 之争：Ryan 要把它整个砍掉，Claire 说它是最好的「变革杠杆」

Ryan 的立场很激进："我正打算把 Slack 从 Untangle 里彻底砍掉，连带这家公司以后的运作方式也照这个来。" 他的替代方案是：等开始招人，要求多人协作都发生在 Devin 的 thread 里——"大家就在 thread 里讨论当下在做什么。"→ 详细
他给的理由是上下文的归属地问题：这样"你就不用老去找『这件事的上下文在哪儿』——在你的 agent 里？在 Slack 里？在 Google Docs 里？到底在哪儿？"他后面还补了一句更根本的："反正 agent 早晚都需要你聊的这些内容作为上下文，那干脆就在它那儿聊。"→ 详细
他还打算禁掉一对一私聊："我记得是 Jack Dorsey、或者他们公司有人，把 DM 直接禁掉了"（他提到对方发布了 Buzz）。"我不想要任何一对一私聊。真要私下谈，那我就得给你打电话。"结论句："Slack 不是为 AI 时代设计的。" → 详细
Claire 的反驳分两层。表层是情绪层："我喜欢把我的 agent 拟人化。作为一个 solo founder，我需要我的同事有意思一点。"（Ryan 认了："有道理。我就是那种又无聊又刻薄的人。"）她也承认 Slack 和 web app 其实"完全可以互换，你在 Slack 里看到的就是 web app 的一个投影"。→ 详细
深层理由才是硬货，来自她在 LaunchDarkly 的经历：最早在公司内部推后台 agent 时，"把这些后台 agent 放进公开的 Slack thread 里，作为推动变革的一步棋，效果实在太好了"——因为那是她见过的唯一一个"能让写代码这件事实时地、公开地发生"的地方，"这会改变人们的认知：哦，原来 AI 能干这些？我该怎么跟 AI 配合得更好？"她还补了个产品层的观察：Devin 是少数几个"你和同事同时在一个 thread 里说话也不会互相绊住"的多人协作 agent。最后她笑称自己"习惯成自然——当初我逼着所有人把 Devin 的 thread 都塞进公开频道"。→ 详细
两人最终收敛到同一个判断：要干掉的不是 Slack，是 Slack 文化。Ryan："chat 不会消失，因为人本来就喜欢这么沟通；但越来越多的人就算不想干掉 Slack，也想干掉 DM 文化、私密频道文化。"Claire 接："就是那种毫无必要、又什么都产不出来的对话文化。"Ryan 给出标准："Slack 里几乎每一条 thread 都应该最终落成实际的活儿。" 他还搬出自己在 Intel 当员工那段经历作注脚："你会花大量时间去聊那些根本不重要的事，而你又没被授权去做任何决定，那这有什么意义呢？" → 详细

设计这条线：Claude Design 出设计系统 → 丢给 Codex 落成代码 → 再反灌回 Figma

起点是 Ryan 的困惑，他把它称作自己的"第三个平面"（前两个是云端 Devin 和本地 Codex），也就是会用到一点 Claude Code。他给出的理由，一是"感觉像是 token 无限管够"，二是设计："我不是说让它想出全新的设计，那方面我觉得它挺差的；但在把一套设计系统延续下去这件事上，它能做出某种很神奇的东西——而 Codex 在这块差得有点好笑，Devin 的设计也很糟糕，所以我总得回头去用 Claude 做设计。" → 详细
接下来这套四步流程是本期最可直接照抄的工程链路（⚠️ 转写在这一段的发言人标注明显错乱：从"我正在做一门新生意，有新品牌、新设计，这套流程我最近刚刚走过一遍"这句上下文看，讲述者应是 Claire，Ryan 是提问方）——"Claude Design 做设计系统这件事，现在真的是没有对手。" 它擅长的是把一个参考网站或一份 Figma 稿，拆解成"相对不那么粗糙、没有 AI 味"（relative non-slop）的 design token（设计变量：颜色/间距/字号等可复用的基础单位），能复用到整条产品线上。→ 详细
具体四步：① 在 Claude Design 里做出设计稿/设计文件 → ② 把它下载下来交给 Codex，指令是"把这个，再加上 Figma 里的东西，给我真正搭一套技术层面的设计系统出来" → ③ Codex 把所有共享组件建好，并在 monorepo（单一代码仓库）里做出"一套很漂亮的互相引用关系" → ④ 反向回灌：用 Codex 配 Figma 插件，把这些 design token 拉回 Figma 变成能直接用的组件。" 中间那步的交接物被点名为 design.md——"你有了 design.md 之后，就把它导进 Codex"。→ 详细

模型使用体验的真话：「读 Claude 的输出会让我血压升高」，但深度攻坚它还是无敌

Claire 的吐槽非常直白："我对 Claude 的意见是——token 感觉无限、也确实聪明，但我一读 Claude 的输出就火冒三丈，它是真的会让我血压升高。" → 详细
Ryan 附议并说得更狠："我已经受够 Opus 5 了，真的太让人抓狂。它某种意义上还挺吓人的，因为那感觉就是：天哪，情况比我们以为的糟糕得多——方方面面都是。" 但他同时承认这正是它强的地方："它其实真的能指出问题到底出在哪儿，它是真的超级聪明。"（他还说自己听过的唯一一期讲 Opus 5 观点的播客就是 Claire 那期。）→ 详细
结论是一句值得记的行业判断：在"网络安全、设计"这类非常具体的深度攻坚场景里，它"在执行层面基本还是无敌的"；但日常选谁，取决于 harness（外壳/工作台，即包裹模型的那层工具与交互）——"Codex 那套 harness 的使用体验就是高效得多，也用得舒服得多。" 换句话说，这两位重度用户选工具，选的不是模型分数，是 harness 体验。 → 详细

他招第一位工程师的方式：不面谈、不看简历，只看你一段「管 agent 的录屏」

Ryan 有雇过"成百上千号人"的经验，而这次他把招聘整个重做了。他在 Twitter 上的招聘帖大意是："我们要招第一位工程师。你必须是那种超级超级超级拥抱 AI 的人；你住在哪儿我完全不在乎。我要你做的只有一件事——录一段视频，全屏、整个桌面都录下来，内容是你给一个已经存在的 app 做一个新功能。我就想看完整的全过程。" → 详细
他把"不做什么"说得比"做什么"还清楚："我不想跟你面谈，不想开会，也不想先搞清楚我喜不喜欢你这个人。我只想看看你当 agent 管理者的水平如何。" 他的反馈是："收到的这些视频特别有意思，而且非常能看出我到底愿不愿意跟这个人共事。" → 详细
第二轮：给候选人开 Devin 权限，让他们"真刀真枪做点东西出来"，同样录成视频；之后才有一次简单的见面聊；招进来以后，"我就只看他们 agent 的产出，我就这么管人"。他还顺手指出一个副产品：如果他们用 Devin，你本来就能拿到 Devin 那台电脑跑起来的回放视频，等于又省一步。 → 详细
Claire 给了本期最漂亮的一个升维总结："你几乎是在用招 agent 的方式招人……你其实就是在跑一个验证循环（verification loop）。" 她把它和旧方式对比——过去是"我挺喜欢这个人"，然后"我们要给你出一道有点莫名其妙的技术题"——"你想想，这比我们过去那种离谱的招聘方式要好多少。" → 详细

闪电问答 / 收尾

本期没有正式的 lightning round，只有一道收尾提问和 Claire 的打包总结。

Q1｜「你现在真正的 EA（行政助理）是谁？那个替你打理所有 agent 活儿的搭子」

Ryan 的答案：「Paulie the OpenClaw」（Paulie 是他给自己那个 OpenClaw 助理起的名字）。他说自己"还是天天泡在 OpenClaw 里""就认准它了"。→ 详细
Claire 的答案：已经换掉了 OpenClaw——"我很喜欢 OpenClaw，喜欢 Pete，喜欢那个团队，是真喜欢。我只是换掉了。我当时想，管它呢，我就在自己的 Mac Mini 上跑 Claude Code 算了。"而且她还想再换到 Codex，理由很纯粹："我实在是太爱太爱 Codex 的界面了。" → 详细
Ryan 补的这条最实用：Paulie 还跑着，但他现在一直在 Codex 里开着浏览器挂着邮箱，"等于是 Codex 在替我管邮件"——"前几天它一口气把我 Gmail 里 2000 封未读邮件全过了一遍，直接改变了我的人生。" → 详细

收尾｜Claire 的打包总结（本期精华压缩版）

她先讲了那句最反差的："你时间线上最『AI 上头』的这两个人，花了大半场时间在讲——写太多 AI 代码并不会给你带来好产品。" 后接两条"非技术"建议："你应该带着你的肉身走出门去，跟客户聊聊"，以及"把你的优先级写在一张纸上"（Ryan："这招管用。"）→ 详细
技术层面她给了五条：① 把你的后台 agent 搭起来；② 用你自己管得过来的方式给它们的活儿排优先级；③ 每个人都在变成 agent 管理者；④ 你的 coding agent 能替你做的远不止写代码；⑤ 新式面试就是"放手让他们去折腾，顺便开个屏幕共享"。最后是那句自嘲的收尾：两位"单干创始人兼 AI agent 管理者"现在都在招人。→ 详细

联系方式

Ryan Carson：在 X（Twitter）上非常活跃，搜 Ryan Carson 即可，"随时来找我"。→ 详细
产品 Untangle：untangle.us——他的定位原话是"帮人把离婚这件事过得更体面一点，因为离婚这事儿总归会发生"。→ 详细
应聘方式：直接给他发 DM，附上一段你干活（管 agent）的视频；他说"我觉得我们会很快定下人，所以动作快点"。Claire 加码："如果你的视频把 Ryan 打动了，那你八成会成为 How I AI 接下来某一期的嘉宾。" → 详细
节目本身：How I AI（主持人 Claire Vo），往期与更多信息在 howiipod.com，也可在 Apple Podcasts / Spotify 收听。→ 详细

接着读

NO.202 · AI 产品深入解析扩张 AI 算力的三大瓶颈——Dylan Patel(SemiAnalysis) Dylan Patel · 37 分钟 NO.201 · AI 产品打赢战争的从来是异端者,不是流程——Shyam Sankar(Palantir) Shyam Sankar · 33 分钟