这一篇把 9 位产品公司掌门人/操盘手(开发工具、设计工具、内容公司)2026-03 到 06 在 X 上发的东西,按主题重新拼起来——不是给每个人单独立传,而是把"同一个判断,谁在说、什么时候说"放到一起,方便你抓住跨越具体产品的长效结论:agent 时代怎么定价、设计在"执行变免费"之后凭什么更值钱、什么样的组织和工种会冒出来、SaaS 到底死没死。
这些人都在亲手造 AI 产品并靠它赚钱,所以他们的话比纯评论员的更"带泥点"——会暴露真实的踩坑(比如 vibe code 的东西爆了、安全被攻破、benchmark 测不出真本事)。
何时打开:
- 你在想 AI 产品/功能该怎么定价(按人头?按用量?按结果?),想看一线掌门人怎么吵
- 你是 PM,担心"执行变便宜了我还有什么价值",想要一套关于品味/设计/判断的说法
- 你听到"SaaS 已死""管理已死""一个人就能做十亿美金公司",想知道哪些是真趋势哪些是口号
- 你想理解为什么这帮人都在说"agent 会比人多用 100 倍软件""每个公司都要变成软件工厂"
- 你想给团队讲"AI 不会让我们活儿变少,反而更多"——这里有最完整的论证(Levie)
谁在说话(who's who)
看观点前先认人。下面这几位的"身份+一句话立场"决定了他们说话的角度。
| 人 | handle | 身份 | 一句话立场 |
|---|---|---|---|
| Amjad Masad | @amasad | Replit CEO | vibecoding 让人人能做生意;平行 agent + 垂直整合 = 护城河;反 Apple 抽成 |
| Aaron Levie | @levie | Box CEO | 这一组里最"论点驱动"的人:AI = 杰文斯悖论(活儿更多不更少)、软件变"无头"、瓶颈是数据不是模型 |
| Guillermo Rauch | @rauchg | Vercel CEO、Next.js 作者 | 代码是产出不是输入;软件工厂才是护城河;Web 是 AI 的天然介质 |
| Dan Shipper | @danshipper | Every CEO(AI 媒体+产品)、播客主 | 每 3-6 个月推倒重来;海盗/建筑师;AI 三明治;复合工程 |
| Ryo Lu | @ryolu_ | Cursor 设计负责人(早期 Notion/Stripe) | 执行变便宜后,品味/灵魂更稀缺;"玻璃"透明、人在方向盘上 |
| Nan Yu | @thenanyu | Linear 产品负责人 | 设计是意图不是产出;PM 工作流已 AI 化;反"幻觉式"美观 |
| Peter Yang | @petergyang | Roblox 产品、14 万订阅 AI/产品 newsletter | 你的工作就是把自己的工作自动化;品味推你越过"平均";反 slop |
| Madhu Guru | @realmadhuguru | 前 Google 产品负责人(Gemini/Veo/Nano Banana) | AI 时代 PM 要当"发明家"不是"套路执行者";野心与幸福可兼得 |
| Peter Steinberger | @steipete | OpenClaw 作者("ClawFather") | "如果 token 不要钱我们会怎么造软件";让 agent 当 QA/审查者;给自己造工具 |
信噪比备注:@realmadhuguru 本期只有 4 条推(刚从 Google 离职),量少但每条都很硬,不是低信号——只是覆盖窄。其余 8 位都是高信号大号。
1. 无头软件 & agent 定价(levie + rauchg + amasad)
Why 这是头号主题:如果你做的是 SaaS 或任何"卖软件"的生意,这一节直接关系到你 18 个月后还收不收得到钱。核心判断:软件的主要使用者正在从"人"变成"agent",而 agent 不能按人头收费。
"Agents will use software 100X more than people."(agent 用软件的量会是人的 100 倍)—— Levie [2026-03]。由此推出"无头软件"(headless software)论:软件未来要能让 agent 完全无界面地驱动,软件本身退化成"护栏 + 业务逻辑",人看的那层界面变次要。
"If you're building software that can't work fully headlessly the way agents want, you're not prepared... If you can't connect to wherever agents want to do that work, you're DOA." 译:如果你做的软件没法像 agent 想要的那样完全无界面运行,你就没准备好……连不上 agent 想干活的地方,你就死定了(DOA = 到院已死)。 —— Levie [2026-03]
Levie 问了 20 位 IT 负责人"3-5 年后还会留没有好 API 的供应商吗",全票"不会"[2026-04]。
定价怎么变(Levie [2026-05-01] 那条最系统):
- 人头(seats)留给人,但每个席位必须捆绑 API 用量额度,让 agent 替这个人花;
- agent 如果做"有状态"的持续工作,可能也有"席位",但定价方式完全不同(类似 OpenClaw 那种);
- 超出席位的自动化用量,主流模式是按消耗(consumption);未来还可能冒出按"结果(outcome)"收费的 API。
- 一句口诀:"Seats for the people, consumption for the agents."(人按席位,agent 按用量)
Rauch 从基础设施角度说同一件事:"Every company will become an AI factory, wherein the unit of production is the token."(每个公司都会变成 AI 工厂,生产单位是 token)—— 而 token 带来的是 SaaS 时代没有的"计量/计费"难题。Vercel 为此做了 AI Gateway 的 /v1/report API 专门解决跨模型计费。
Masad 则把矛头指向"按人头的反面极端"——反对销售门槛:"You shouldn't be forced to talk to us to buy the product."(不该被逼着跟我们销售聊一通才能买)[2026-04]。自助购买 + 按用量,是 agent 时代的默认姿势。
给非技术 PM 的翻译:过去你卖软件像卖健身房会员卡(一人一张,按人收)。现在真正的"会员"是 agent,它们 24 小时不睡、可以并行开几百个——你没法给它们也发会员卡,只能按它们用了多少水电(token/调用次数)收费。所以定价模型要变成"人交基础月费 + agent 用多少算多少",甚至"按帮你拿到的结果收费"。
2. 执行变免费之后,设计/品味凭什么更值钱(ryolu + thenanyu + petergyang)
Why:当 AI 能秒出能跑的界面和代码,"会做"不再稀缺。这一节是产品/设计岗的人最该读的——它给你一套"我为什么还不可替代"的硬说法,而且不是鸡汤,是 Cursor/Linear 设计负责人的工作信条。
核心共识:做东西越容易,slop(将就的烂货)就越免费地涌出来,于是"品味/判断/说不"成了瓶颈。
Ryo Lu(Cursor)[2026-03]:"as agents make it easy to add features, design matters more, not less."(agent 让加功能变容易,所以设计更重要,不是更不重要)——设计的角色不再是"推像素",而是决定什么该存在、怎么拼在一起、人怎么保持掌控。
他两篇旗舰长推值得记住:
- "当软件还有灵魂的时候"(when software had a soul)[2026-03]:2005 年左右的 Mac 会"弹跳的 dock、精灵特效"——"none of it strictly necessary. all of it felt like someone cared."(没一样是必需的,但全都让人觉得有人在乎)然后 A/B 测试把棱角磨平了,设计系统把个性标准化掉了,我们"优化进了一个一切都完美运转却毫无感觉的世界"。他的恐惧不是 AI 取代在乎的人,而是 "it will drown them out."(把他们淹没)
- "玻璃 vs 黑盒"(glass vs. black box)[2026-04,Cursor 设计宣言]:AI 把"黑盒"做得更让人上瘾——"you type a wish and pull the lever... you became a product of the model."(你许个愿、拉一下杆……你变成了模型的产物)。"玻璃"= 一切可见可控:agent 可见、diff 在那、计划可改、状态清楚。"as AI gets more powerful, glass gets more important... stay glass."(AI 越强,玻璃越重要……保持玻璃)
- 还有 "overcooking"(炖过头)[2026-04]:不是某个坏决定,而是一堆各自合理的决定累加成的混乱(每个数字都配个 sparkline、每个操作都弹确认框),AI 让"加东西"成本趋近于零,炖过头更严重。解药是"看穿混乱、回到这东西到底是什么、砍掉不服务于它的一切"。
Nan Yu(Linear)从另一个角度补刀:"A design is an intention. Not an image or a prototype. Output without intention is hallucination."(设计是意图,不是图片或原型;没有意图的产出就是幻觉)[2026-04]。他甚至撤回过一个辛苦做出来的生成式 AI 功能,理由是"它太容易让人一按按钮就跳过本该自己做的工作"[2026-03]——AI 功能会短路掉用户本该获得的价值和学习。
Peter Yang 把这件事做成了可传播的金句:"AI gets you to average fast. Your taste is what pushes past it."(AI 让你快速到达平均水平,品味才是推你越过平均的东西)[2026-04]。他还讲了 "slop 复利陷阱":AI 生成的文件有 5% 的 slop,你懒得改;后面的文件引用前面的;"5% slop becomes 10% and then more",最后你守着一堆自己都看不懂的 AI 垃圾 🥲。
给非技术 PM 的翻译:以前"会用 Figma 画图、会写代码"是门槛,现在 AI 一秒给你十版。值钱的东西从"会做"挪到了"判断做得对不对、敢不敢砍、知不知道这东西本质是什么"。三个人用了三个词——Ryo 的"灵魂/玻璃"、Nan 的"意图"、Peter 的"品味"——说的是同一件事:你的价值是当那个"说不"和"定方向"的人,而不是那个"出活"的人。
3. "如果 token 不要钱"——agent 饱和的开发流水线(steipete + danshipper + petergyang)
Why:这是"未来的开发到底长什么样"的最具体样本。即使你不写代码,看懂这套流程能帮你判断"一个小团队靠 agent 能撑多大的产品",以及"agent 当审查者/QA"这个反直觉但好用的招。
Peter Steinberger 最重要的一条:"How would we build software in the future if tokens don't matter?"(假如 token 不要钱,我们未来会怎么造软件?)[2026-05-15]——他直接把 OpenClaw 这个开源项目跑成了答案:~100 个 codex 实例在云上持续运行,审每个 PR、每个 commit 的安全;agent 自动关掉 6 个月没动的老 issue(还附上修复它的确切引用);agent 在临时机器里复现复杂 bug、录前后对比视频贴到 PR 上;agent 听会议、功能一被讨论就主动开 PR。"All that automation allows us to run this project extremely lean."(这些自动化让我们用极少的人维护这个项目)
几个可直接抄的工作模式:
- 对抗式审查(adversarial review):"Ask it to review code for bugs and it will tell you all good. Tell it there is a bug and it will LOOP AND LOOP and will find issues."(让它找 bug 它说没事;告诉它"有个 bug"它就会一遍遍找,然后真找出来)[2026-05-30]。同样的偏见也出现在评测里——他把模型名从评判 agent 里删掉,因为"Claude 老把自己评第一"。
- "Yielding agents is a skill."(让 agent 自己往前推进是一种技能)——配合
/goal+ 自动审查,他的任务从"30-60 分钟"级别变成"4-10 小时"级别。 - "The more skills you give codex, the less you have to prompt."(给 agent 越多 skill,你越不用啰嗦提示)+ skill 要"token 高效、语法放松",别在每个 skill 描述里写一本书塞进上下文。
Dan Shipper(Every)给这套"agent 多到不要钱"的流程配了思维框架:
- 海盗 + 建筑师(Pirate + Architect)[2026-03]:2026 的工程团队就两个角色——海盗疯狂 vibe code 去发现什么有价值能发;建筑师把那个表面变成可靠、结构化的机器。"每个产品都需要海盗,但多数产品在到达 PMF 后只需要建筑师,而且通常不用全职。"
- AI 三明治(the AI sandwich)[2026-04]:模型是夹心(写、测、迭代),人是两片面包(开头框定问题、结尾判断对不对)。"Humans are indispensable at the beginning and end of every process."(人在每个流程的开头和结尾都不可替代)。配套的是复合工程(compound engineering):计划 → 干活 → 审查 → 复合(把教训写回仓库,让 agent 不再犯同样的错),于是一个工程师能像五人小队一样出活。
- "An agent is just a folder."(一个 agent 不过就是个文件夹)——他称这是"绝佳的心智模型"。
Peter Yang 则把这套打法转译给 solo builder:Josh Pigford 的招——用 git worktree 并行开多个功能(防止上下文腐烂、隔离错误)、让 GPT 审 Claude 的活、反过来也一样("GPT 总能找出 Opus 漏掉的 3-5 个 bug")、建一个 /learnings skill 把每次失败提炼成新规则。
给非技术 PM 的翻译:想象你不再是"雇 5 个程序员",而是"开 100 个永不疲倦的实习生,而且实习生工资约等于电费"。这时候真正的活儿变成了给实习生定目标、让一批实习生去挑另一批实习生的毛病、把每次踩的坑写成规矩贴墙上。"对抗式审查"尤其反直觉但好用:你不能问 AI"有问题吗"(它会说没有),要直接说"这里有个问题,找出来"——它就会较真。
4. SaaS 到底死没死 & "管理已死"是真是假(levie + rauchg + danshipper + petergyang)
Why:"SaaS 已死""一个人十亿美金公司""管理已死"是这半年最吵的口号。这一节把口号拆成"哪部分是真、哪部分被夸大",帮你做"要不要还买/还做某个 SaaS"的决策。
Rauch 的"SaaSpocalypse"(SaaS 末日)版本最激进:"Almost every SaaS app inside Vercel has now been replaced with a generated app or agent interface."(Vercel 内部几乎每个 SaaS 都被自生成的 app 或 agent 界面替换了)[2026-03]。但他留了关键的口子——系统级记录(systems of record,如 Salesforce/Snowflake)留下,被替换的是那些"自己生成更漂亮、更贴合业务问题"的工具。他的底层公式:"UI is a function 𝑓 of data, and that 𝑓 is increasingly becoming the LLM."(界面是数据的函数,而这个函数越来越变成 LLM)
但 Dan Shipper 和 Peter Yang 给出了更冷静的"SaaS 没死,只是要变 agent-native":
- Shipper 和 Linear 的 Karri Saarinen 一起讲[2026-04]:Linear 转向同时服务人和 agent(Codex、Coinbase、Brex 都在 Linear 里跑 agent),教训是 ChatGPT 火了之后 Linear 没有跟风做个 me-too 聊天机器人,而是等。后来又用 Figma 补充[2026-06]:"running your own agents makes you more willing to pay for SaaS, not less"(你自己跑 agent 反而让你更愿意为 SaaS 付费,不是更不愿意);"chat 是设计的错误界面";"review is the next bottleneck"(审查是下一个瓶颈)。
- Peter Yang 的分层判断[2026-06]最实用:能干多种活的大型企业 SaaS(如 Figma)大概率没事;只解决一个窄场景的简单 SaaS 难变现了——因为(1)AI skill 能更灵活个性化地解决同样问题;(2)有你上下文/记忆的 AI agent 比孤立的 SaaS 懂你更多;(3)人们愿意为"人工服务"付几百上千,却拿一个 $20/月的 SaaS 跟自己的 Claude/ChatGPT 订阅比。
"管理已死 / 不需要层级了"——多人明确反对:
- Shipper[2026-04]:"organizations don't need hierarchies anymore because of ai is silly... As long as context rot is a thing you're going to need specialization."(说 AI 让组织不再需要层级很傻……只要"上下文腐烂"还存在,你就需要专业分工)——中层会少,但层级不会没。
- Peter Yang 转述的 Ramp CPO 那句 "Management is probably dead... optimize to be the best builder in the world"(管理大概死了……要优化成世界最好的 builder)是另一端的声音——所以这件事本身就有分歧,不是定论。
"一个人十亿美金公司":Masad 直接背书 "One person billion dollar company has been achieved."(一个人的十亿美金公司已经实现)[2026-04],并不断放大 solo builder 的真实 ARR 故事(一个起步 $400 的人一年后做到 $8M ARR)。
给非技术 PM 的翻译:别被"SaaS 已死"吓到,也别当没事。真死的是"只干一件小事、没记忆、没你上下文"的窄工具——那种被 AI skill 一句话替代。活得好的是两类:① 攥着"系统级记录"(你的客户数据、订单数据都在它那)的大平台;② 能同时被人和 agent 调用的 agent-native 工具。判断标准就一句话(Levie 提供的):"当 agent 比人多 100 倍时,软件的哪些部分会因为 agent 干更多活而增长?"——能回答"增长"的就买/就做。
5. AI 不会让活儿变少,反而更多(levie 主场 + petergyang + 旁证)
Why:这是 Levie 整个 feed 最系统、最反直觉、对你和团队心态最有用的一套论证。如果你担心"AI 把工作干完了我们干嘛",或者要安抚团队/给老板讲,这一节是弹药库。
Levie 的核心是杰文斯悖论(Jevons paradox)——效率提升反而拉高总需求:
- "Jevons paradox is happening in real time."[2026-03] 公司(尤其科技以外的)现在能负担以前负担不起的软件项目 → 软件被用到经济里全新的地方。"所有劝你别学工程的建议都是错的。"
- 二阶效应[2026-04]:让一项技能变高效会诱发对它的需求——更多代码 → 更多安全风险 → 更多安全岗;更多 AI 写的法律文书 → 更多律师;10 倍的视频/图形 → 更多媒体人。历史佐证:PC + 互联网都让法律更高效,但美国执业律师从 1975 年的 ~40 万涨到 2025 年的 ~137 万。
- "Don't confuse task completion with eliminating the whole job."(别把"完成一项任务"和"消灭整个工作"搞混)[2026-04]——他叫这个 "Gell-Mann amnesia for AI jobs":你用 AI 干自己的活、看得见所有"最后一公里"的脏活;一看别人的活,就以为 AI 能瞬间替掉。
- 他最火的一条(4.8K 赞)[2026-05-24]:"CEOs are uniquely prone to AI psychosis because they're sufficiently distant from the last mile of work."(CEO 特别容易得"AI 精神病",因为他们离最后一公里的活儿够远)——只看到"看我做了个原型"的快乐路径,看不到上线还要的 10-20 件事。建议:CEO 应该大量亲自用 AI,才能同时体会到上限和真实工作量。
Peter Yang 的"三个前沿"给同一判断加了时间轴:"Coding is the first frontier. Knowledge work is the second. Personal agents are the third."(编程是第一前沿,知识工作是第二,个人 agent 是第三)[2026-05]——并强调 "Human ambition has no ceiling — the economy is changing, not shrinking."(人的野心没有天花板——经济在变,不是在缩)。
Levie 的另一个推论是新工种:FDE / 内部 agent 工程师会成为定义性新岗位——"把最高杠杆的工作流找出来、给 agent 喂上下文、决定人在哪介入、模型/数据变了之后重跑评测"。需要"技术(Skills/MCP/CLI)+ 懂业务"。他说卖 agent "far closer to a customer buying from a professional services firm than implementing traditional technology"(更像客户买专业服务,而不是实施传统技术)——所以每一波技术浪潮都会"催生新一代咨询公司"。
给非技术 PM 的翻译:用一个生活类比——洗衣机出现后,大家洗的衣服更多了,而不是更少。因为洗一次变便宜,你就天天洗、洗更多种类。AI 对工作就是这样:每件事变便宜,你就做更多以前嫌麻烦不做的事,工作总量反而涨。要警惕的陷阱是 Levie 点的:离一线越远(尤其是 CEO/高管),越容易高估 AI、低估"上线前那 10-20 件脏活"——所以最好的解药是自己天天上手用。
6. 散装但值钱的几条长效判断
不成主题、但单独都站得住的几条,留作速查。
- 每 3-6 个月推倒重来(Shipper):"models move so fast that you have to be willing to throw everything out every few months."(模型变太快,你得愿意每隔几个月把一切扔掉重做)——小团队赢,因为没有协调成本、更容易重来。Levie 同款:"你 12 个月前花 6 个月打磨的东西现在已经过时,重置好过抢救。"
- "代码是产出,不是输入"(Rauch):"Code is an output. Nature is healing." 太久我们把代码当输入来美化、IDE 化;现在注意力该回到真正的输入——需求、规格、反馈、设计灵感、生产环境里用户怎么用。"最好的工程师一向把代码看成手段,不是目的。"
- PM 要当"发明家"不是"套路执行者"(Madhu Guru):"A generation of PMs is struggling to adapt to AI because they were trained to execute playbooks. AI requires inventing them."(一代 PM 难适应 AI,因为他们被训练成执行套路;而 AI 要求发明套路)——"你没法靠 A/B 测试测出一个突破性的 AI 产品……PM 需要 unlearn(把旧的忘掉)。"
- CEO 的 AI 失败模式(Madhu Guru):很多 CEO 有 AI FOMO 但"习惯了远程式领导、缺乏亲自上手的肌肉",于是下粗糙笼统的 AI 指令 → 员工交"表演式、低投入的 demo" → "两年没真进展,一个有亲自上手领导的初创把你颠覆了。"
- 采用甜区在"前沿后退一两步"(Nan Yu):"The sweet spot is just a couple steps behind" 最前沿——因为在最前沿你会随行业学习不断改做法;甜区是"相对新但已经熬过 churn(动荡)"的东西。
- 野心与幸福可兼得(Madhu Guru):见过赚了 $10M+ 却痛苦的朋友,也见过赚得少却快乐的——"Whether you're happy is independent of your bank account... 硅谷把野心和幸福当互斥,那是个陷阱,你可以两者都要。"Peter Yang 的版本更扎心:别让墓碑上写"他离了婚、忽略了孩子,但至少在 FAANG 升到了 D2"。
- 安全是 AI 时代的定义性议题(Masad + steipete + rauchg):Masad——"2020s 每个公司是 AI 公司,2025+ 每个公司是网络安全公司";Steipete——AI 生成的安全报告会拖垮一些开源项目(Linux 内核安全报告从两年前每周 2-3 个涨到现在每天 5-10 个);Rauch 的血泪教训——"Deletion does NOT imply Rotation."(删掉密钥 ≠ 轮换密钥;轮换是指在供应商那边作废旧值、换新值)。
History
- 2026-06-05 v1.0 创建 —— follow-builders 日推子系统,founders-products 主题桶 9 位作者(amasad / danshipper / levie / petergyang / rauchg / realmadhuguru / ryolu / steipete / thenanyu)的预制 digest 主题驱动合成。来源为 X 推文 digest(2026-03→06 窗口)。无图。
2026-06 至 09 历史增补：让评测连接真实工作
以下依据本次补齐的本地原推文字，分批精读笔记在 sources；未展开短链、图片或视频。前文身份、模型名称、价格与增长数字均有历史窗口，不应当成今天的产品目录或已核验业绩。新材料中的供应商评测和商业案例同样是作者自述。
先区分能立即验证的事与要等外部反馈的事
Levie 在 6 月 7 日、7 月 16 日及 8 月 3 日反复指出，编程不仅技术成熟，还具有数字化上下文、可运行测试与懂技术的使用者。销售、合同谈判、营销方案可能需要客户反馈，且没有唯一正确答案。因此“代码能连续跑几小时”不能直接证明其他工作也适合无人连续运行。（见批次 01、03、04。）
给 PM 的落点：为任务写清楚验收对象、反馈时机、谁判断结果；把“信息取对了吗”和“建议最终有效吗”分开。反例是拿一份格式漂亮的财务摘要，直接作为分析正确的证据。Box 的历史评测案例涉及起始账期、成本定义、分母与分类权重，价值在提醒我们测试业务口径；这里不把其模型成绩、医疗案例结论搬作通用答案。
评测不能只给老板一个总分
Madhu Guru 8 月的评测系列提出四个可执行改进（批次 04、05）：先把真实失败细分，例如错文档、错段落、无依据回答、该澄清却猜测；再按工作阶段定位问题，粒度细到能够决定下一步改哪一处。测试还要真实且有区分能力，避免所有系统都满分或都失败。
单一均分可能掩盖关键场景退步；加权总分也没有消除权重背后的人为取舍。因此，保留有优先级的分项结果和失败样本。随着用户从短文摘要转向多文件分析、从被动问答转向持续监测，评测也需要路线图。系列目录中只抓到链接的文章，未假装读完。
原型先看上限，生产再看每个合格任务的总成本
Guru 8 月 5 日建议先用强模型验证用户体验，再优化延迟与成本；Levie 多次讨论以强模型做规划、较便宜模型完成已明确的子任务。这样做的前提是任务边界与验收标准已经清楚。原文“6–8 周追上”“15 倍节省”分别是预测与特定实验转述，不能当预算承诺。（批次 02–04。）
Masad 6 月 14 日反对 token 消耗排行榜，Rauch 9 月 1 日强调按用户治理预算；两者提醒：消耗量只是成本和活跃信号，不是成果。生产决策应同时看合格完成率、延迟、重试和人工复核，而不是只比 token 单价。提示词也可能积累过时规则；Guru 的“每次更新删一半”应理解为检查提示债的提醒，实际删除须用回归测试验证。
2026-07 至 09 历史增补：工作流、权限与人机交互
一个入口可以连接许多专业代理
Rauch 8 月 3 日描述 Vercel 内部 @v：作为统一入口路由子代理，同时保留少数专用入口。要解决的是员工记不住几十个机器人，而不是取消专业分工。Nan Yu 7 月一面支持并行工作，一面反对炫耀同时开十个窗口，关注的是人类微操负担。（批次 02、03。）
长任务跑完只说两段总结也会让人失去掌控，Shipper 7 月 4 日明确提到这个问题；Steinberger 展示求助时补充上下文的提示。对 PM，可把“做了什么、证据在哪里、卡在哪里、现在需要你决定什么”作为结果和求助界面的内容标准。减少烦人的措辞同样影响完成任务：Nan Yu 9 月 2 日将其称为对话与修辞设计机会。不能仅因为后端模型更强，就忽视用户中途退出。
数据能访问，不代表授权已解决
Guru 7 月 25 日追问：员工生成的代理与子代理继承什么权限、任务结束后何时失效、如何审计。Levie 7 月 15 日提醒企业敏感信息的权限并不一致，把内容训练进共享模型不能替代外部访问控制；Rauch 8 月 11 日区分计算隔离与网络隔离。这些都是设计问题，所引安全事件未外部复核。（批次 02–04。）
适用场景是代理开始跨团队读写资料。先明确代表谁、访问哪些数据、允许做哪些动作，再谈共享记忆和自动改进。ZDR（零数据保留）是 Levie 8 月经验中帮助采用的一项供应商条件，不代表所有场景自动合规，也不等于审计、权限和可靠性可以省略。
从需求信号到可转述的价值
Guru 8 月回忆早期用户提示里已有“为我做一个应用”，虽然当时模型不擅长完成；没有被满足的请求也可以暴露用户真正想要的结果。他同时批评让普通用户先学模型、MCP、上下文等术语才开始做事。可抽象掉模型选择，但必须以场景评测和持续维护支撑，不能隐藏用户需要决策的费用和数据用途。（批次 04、05。）
Nan Yu 7 月 10 日强调营销故事不只给第一位读者看，还要能由销售传给客户、用户传给购买者、推动者传给组织。对 PM：帮助试用者讲清楚具体任务、实际变化与限制，比只展示技术名词更利于内部传播。自愿晒出的成功案例和涨粉数字不构成总体成功率。
2026-06 至 09 历史增补：让用户参与判断，让代理依证据继续
哪些摩擦值得保留
Nan Yu 在 6 月 20 日回顾项目更新功能：一次性代写虽然省步骤，却让使用者逐渐不再思考；改为询问“最重要的是什么、要强调什么、还缺什么背景”，反而帮助用户给出更有意图的更新。适用条件是关键信息和判断仍在人手里。反例是对明确、低风险的小操作重复盘问，徒增负担。批次 09 （本地参考资料）
Guru 同期对 PM 的建议也不是多产几份文档，而是亲自做研究、分析、多个原型，再对为何做和做什么承担判断。7 月 28 日他把好的产品评审定义为让懂领域的人提前检验方案；它应产出新的认识，而不是只做汇报。但会议里的模拟反应仍需真实用户验证。Nan 8 月还补充：先追问同事想法背后的问题，有些好方案是多种想法融合后的结果。批次 09 （本地参考资料）、10 （本地参考资料）、11 （本地参考资料）
从自动修复到可恢复的工作流
Nan 在 8 月 1–2 日描述 Linear 的 Issue→Agent→PR→Release 实践：先结合监控与日志研究根因；证据不足时，留下带上下文的问题，请报告者补复现信息，回答到达后继续。他自报约 30% 的 bug 走完该流程，不能作为其他团队的完成率或自动发布承诺。PM 应明确“继续、求助、停止”的条件，而非只给代理一个一直干下去的目标。批次 10 （本地参考资料）
Rauch 6 月指出 agent 既有模型输出变化，也有外部 API 失败、限流等分布式系统问题。因此排查记录要区分模型判断、工具返回和环境故障。Steinberger 8 月给 UI 改动 PR 加录像、分享会话记录，是降低审阅理解成本的做法；仍要按实际验收标准检查结果。Rauch 9 月提倡把可执行检查和技能一起供 agent 使用，例如设计规范检查器；检查通过只覆盖规则表达出的部分。批次 09 （本地参考资料）、11 （本地参考资料）
为模型变化保留选择，为共同工作设权限
Guru 7 月把模型可替换性拆成三件事：业务评测、按质量/成本/延迟选择模型、统一工具和结果处理的执行层。既保留不能退步的基本任务，也保留目前还做不好的目标任务。原型探索新体验时先看强模型上限；若是替代已经清楚定义的传统机器学习任务，小模型也可能适合。两种建议的任务条件不同，并不矛盾。批次 08 （本地参考资料）、10 （本地参考资料）
评测还要观察执行轨迹：完成同一任务用了哪些步骤、哪些重复调用没有增益；步骤更少不自动等于结果更好。服务商说路由“最优”时，要核对评价目标和商业激励。开放权重、本地部署、第三方托管也是不同的数据流，不能靠模型产地或“开源”二字判断数据去了哪里。批次 06 （本地参考资料）、10 （本地参考资料）
Levie 6 月的共享工作区建议包括计划、政策、草稿、纠错和决策，价值在让协作有连续上下文；群聊中的 agent 则应有适合该群体的独立角色和权限，不能自动继承某个成员全部个人能力。8–9 月他继续强调稳定的软件控制、文档分类和异常访问告警。共享记忆提高效率，并未取消访问控制的需要。批次 09 （本地参考资料）、11 （本地参考资料）
成果、投入与体验要分别观察
模型基准、平台 token 份额、支出份额、调用速度不是同一个指标。Rauch 的 Gateway 数据只描述该平台；Levie 转述工程导向企业的人均投入也带样本偏向。可用来发现待验证趋势，不能直接外推市场份额或给团队定预算。批次 07 （本地参考资料）、11 （本地参考资料）
Shipper 的节目简介用反复改邮件提示“互动多不等于有价值”；Granola 预生成大量未被打开的会前简报，则提示主动服务还要观察使用收益和生成成本。这里只读取本地节目介绍，并未把时间戳目录当作完整访谈。Guru 也区分人享受过程的消费活动和想尽快完成的负担：同一个人对不同任务可能有不同自动化偏好。批次 07 （本地参考资料）、09 （本地参考资料）