Every 的 AI 一年复盘：Agent 越强，越需要懂业务的人
Every 创始人 Dan Shipper 在 Lenny's Podcast 里讲 AI 预测，听起来更像 Every 过去一年把公司推进 AI 工作流之后的复盘。
Every 现在接近 30 个人，一年前大概 15 个。工程、设计、写作、编辑、销售、客服都在用 Codex、Claude Code、Co-work 做日常工作。按常见想象，这种公司应该越做越轻，人数越来越少。但 Dan 看到的结果反过来：AI 用得越深，工作反而变多了。
个人 agent 很快变成维护负担
OpenClaw 刚出来时，Every 内部也很兴奋，不少人都去搭自己的 agent。想象很迷人：每个人都有一个小 daemon，像挂在肩膀上的个人分身。
但 agent 一旦真的跑起来，就不只是一个工具了。它会坏，需要上下文，需要有人盯着它为什么做错了，需要有人不断把它修到下次少犯错。人们只是想完成工作，很少有人愿意为了一个随时出问题的 harness 去 SSH 到服务器上折腾。
所以 Dan 后来反而更看好公司先有一个总 agent。Shopify 有，Ramp 有，Every 内部也有 Claudie，负责跑他们的 consulting practice。
这个 agent 背后还是人，通常是 forward deployed engineer 这类角色，既懂工程，也懂业务现场，负责把 agent 养到整个组织都能用。
Every 的 Nitesh 就是这种角色。他是 AI engineer，但很多时间已经从传统写代码移到 Slack 里跟 Claudie 对话，追问它为什么做了某个奇怪决定，再把系统修到下次少犯同类错误。表面上是在维护 agent，实际是在给全公司搭一套别人可以安全使用的系统。
浏览器开始被塞进 agent 里
公司级 agent 解决的是异步协作，另一条线发生在个人电脑上。
Dan 觉得 Claude Code 最早抓住的点，是把 agent 放到你的电脑里。它能访问你能访问的文件、命令行、代码、浏览器和本地环境。这个模式一开始看起来像 coding agent，后来慢慢变成知识工作的入口。
他现在的 daily driver 是 Codex desktop app。每个项目一个 thread，里面开着浏览器，写文档时就在 Proof 里写，Codex 能看见他正在改什么，也能做 research、整理邮件、查资料、生成报告。
他以前很难 inbox zero，最近连续 10 天做到了。Codex 先通过 email agent Cora 把邮件拉出来，渲染成一个页面，然后 Dan 对着每封邮件口述处理方式。律师的问题，就让 Codex 去收集过去 4 年的文件，整理成报告再发回去。
SaaS 会被推到新的位置
以前大家想的是把 AI 放进浏览器或 SaaS 工具里，Dan 现在看到的是把浏览器放进你常用的 agent 里。SaaS 仍然存在，只是会运行在 Codex、Claude Code、Co-work 这样的工作面里面。
这样一来，SaaS 公司要服务的就不只是人，还包括人带来的 agent。HTML 要可读，CLI 和 Web 状态要同步，agent 一次改了很多东西时，用户要看得见、能批准、能回滚。用户带着自己的 AI 来用你的工具，token 花在用户那边，SaaS 公司也不用把所有 AI 成本吞进毛利里。
Proof 里已经能看到这种循环。用户遇到问题，不一定自己写 support ticket，他的 agent 会发 bug report，里面有复现步骤、环境信息，甚至对开源代码的初步判断。这个 report 进 GitHub issue 后，公司这边也可以再派 agent 去修。用户侧 agent 和公司侧 agent 之间，开始形成很快的反馈闭环。
代码变多以后，最缺的是会删的人
Dan 对 automation 的判断，来自一个很狼狈的经历。他用 vibe coding 做了 Proof，内部测试还可以，正式发布后服务器每 10 分钟就挂一次。Codex 每次说修好了，结果又带出 4 个新错误。后来他找了两位 senior engineer 分别重写代码库，再拿这些结果去评估模型。
旧模型大概 30 分，人类 senior engineer 是 80 多到 90 多分。GPT-5.5 做到 62 分，差异在于它敢于从第一性原理重写，其他不少 coding model 只会在边缘打补丁。
但 Dan 说，就算模型很快追上这个 benchmark，他也可以立刻改 benchmark，把当前模型重新打到 0 分。benchmark 测的是已经被人框出来、写成 prompt、可以评分的问题。人的工作经常发生在更上一层：发现当前问题的提法就错了，判断系统该不该重写，需求该不该拒绝，PR 该不该合并。
这也是 AI-forward 公司还在招工程师的原因。代码变多之后，PR 也会变多。OpenClaw 的 Pete 可能一天收到几千个 PR，再开很多 Codex instance 去筛。问题从能不能 build，转成哪些东西该 merge，哪些东西该删掉，怎么让产品保持一个完整的整体。
PM 和设计师会被放大
执行变便宜以后，Dan 最看好的两类人反而是 PM 和 full-stack designer。
Every 内部有个 Marcus，原来是 PM，做过 Axios 的 writing product，带到过千万级 ARR。后来休了一年，深度使用 Cursor，现在用 Claude Code。他只算 lightly technical，知道 database migration 是什么，能看懂一些代码，但一年前 Every 绝不会雇他来独立做现在这份工作。
现在 coding model 足够强，他可以把一点技术理解、很强的产品判断、写作 sense、用户 sense 拼在一起。Dan 说 Marcus ship 得比团队里不少人都快，而且每个用户、每次对话、每个反馈在他那里都会变成产品下一步的线索。
设计师也类似。以前设计师做出一个漂亮 interaction，经常卡在工程实现上。现在 full-stack designer 可以直接把想法做出来，甚至直接提 PR。AI 生成的界面很容易长得一样，有审美和交互能力的人，更容易和默认输出拉开差距。
AI 写作会先进入内部文档
Dan 还讲了一个很多人会低估的变化：大家会读更多 AI 生成的文档和邮件，而且会慢慢接受这些 AI 产物。
Every 做季度规划时，用 Notion agent 让每个人回答上一年发生了什么、今年目标是什么、指标是什么、这些目标和公司策略怎么连起来，最后生成每个团队的计划文档。Dan 作为 CEO 要看的，是谁需要跟谁对齐，哪份计划质量低，哪份计划真的能执行。
他对 AI 文档的标准是：AI 写可以，但发的人要知道里面每一行是什么意思。如果一份文档发送者讲不出内容，那就是 slop。
说到邮件也差不多。他说自己现在大部分邮件都由 GPT-5.5 和 Codex 写。有一次 Codex 没按惯例请他确认，直接把邮件发给了投资人。他赶紧去 sent 里看，结果发现那封邮件基本就是他自己会发的版本。作为一个写作者，他仍然在意人类写作，但很多内部沟通更看重意图和判断，句子本身可以交给模型。
最后还是要亲手玩
每次新模型出来，Dan 都会把以前做不了的事情重新翻出来试一遍。senior engineer benchmark 以前做不好，GPT-5.5 出来后就到了 62 分。很多能力边界会突然移动，只有一直在现场的人能第一时间看见。
AI 的前沿在任何一个真人用 AI 做真实事情的地方。模型公司在造工具，但他们不可能知道每个行业、每个岗位、每个具体工作流里最值得保留的用法。
最该做的事情，是把自己的工作流搬进 Codex、Co-work、Claude Code 或类似工具里试一遍。找一个真的困扰你的问题，让 AI 去解决。你一旦找到那个「原来这也能做」的时刻，后面就不太需要靠 FOMO 推着自己学了。