Anthropic 员工、Claude Code 相关负责人 Boris Cherny 在一场面向开发者的公开对谈中表示，过去一年里他已经没有再亲手写过一行代码，但每天仍会提交几十个 PR，最高一天达到 150 个。
按他的说法，自己手机上的 Claude 应用会同时开着 5 到 10 个会话，每个会话下又挂着一批智能体。白天同时运行的智能体有数百个，到了夜间则会扩展到数千个，继续处理更深层的工作。代码由模型完成，他本人不再直接写代码。
几千个智能体同时改代码，核心在 Loop
Boris Cherny 给出的关键词是“循环（Loop）”。他称，这是自己见过最简单、也最好用的机制，并认为 Loop 才是未来。
Loop 的做法，是让 Claude 通过定时任务去调度一项可重复执行的工作。执行频率可以按每分钟、每 5 分钟或每天设定，运行起来后基本不需要持续干预。
他说，自己手上常年运行着几十个 Loop，包括：
- 一个专门盯着 PR，自动修复持续集成（CI）问题并自动变基；
- 一个负责保持 CI 健康，发现不稳定测试后自行处理；
- 还有一个每 30 分钟去 X 抓取一次用户反馈，完成聚类整理后再提交给他。
在一次数据查询任务中，模型还会主动提出：因为发现数据持续变化，所以准备启动一个 Loop，每 30 分钟生成一份报告。Boris 只回复“可以”，并要求把结果发到 Slack，模型随后自行完成。
他此前还提到，自己已经不再写 prompt，而是转向写 loop；接下来，连 loop 本身也可能不再需要人工逐条定义。
工作方式变化：从逐句提问到搭建自动化系统
这套方法背后，变化的不只是编程工具，而是“干活”的方式本身。
过去更常见的模式，是用户写一句，AI 回一句，再继续下一轮交互。现在的做法则更接近于先搭一个会自己找活、自己执行、自己交付结果的小系统，然后让它持续运转。
文中提到，Anthropic 前不久上线了 Routines，把类似机制放到服务器端，即使用户合上电脑，任务也可以继续运行。
在 Boris Cherny 的描述里，“工程师”这个角色也随之变化。模型负责写代码，他本人则负责搭系统和做验收。每天几十个甚至上百个 PR 由智能体生成，他真正需要处理的是判断哪些可以合并，哪些需要退回。
他将这种变化概括为：不是“AI 取代工程师”，而是人从操作执行者，转向自动化系统的设计者。工作的重点，从“把这一行代码写对”，转向“搭一套能自己把代码写对的系统”。
他还预测，再过一年，防提示注入、命令校验、人工审批等安全环节的重要性会下降，因为模型会越来越自觉地完成正确操作。
Anthropic 内部：几乎没有手写代码，AI 还会在 Slack 上相互对齐
按 Boris Cherny 的说法，这种工作方式并不只属于他个人。公司内部几乎已经没有手写代码这回事，连 SQL 也是由模型生成，整个公司里很难找到几行仍由人手工敲出来的代码。
更进一步的是，当他的几个 Claude 在 Loop 中写代码时，它们还会跑到 Slack 上，与同事的 Claude 对话，对齐一些尚未完全明确的问题。多组 AI 在 Slack 群里开会、分工，再各自返回执行，在 Anthropic 已经成为日常。
他提到的团队构成也不局限于传统工程岗位。工程经理、产品经理、设计师、数据科学家、财务和用户研究员都在写代码。职能分工还在，但每个人都增加了一层“调度 AI 去干活”的通用能力。
/goal 是 Loop 的验收机制
一个可以持续自行运行的 AI，为什么不会演变成高速批量制造 bug 的系统，Boris Cherny 给出的答案是“验收”。
Loop 能持续运行而不偏离目标，依赖的是一套目标驱动机制。在 Claude Code 中，这对应 /goal 命令。
用户先定义一个目标，例如“/tests/ 目录下所有单元测试通过，lint 结果干净”。每完成一步，系统都会调用一个独立的小模型进行判断：目标是否已经达到；如果没有，就继续执行；达到后则停止。
这个负责判断是否达标的模型，并不是实际干活的那个模型。文中将这套设计视作整个 loop 的核心。
如果没有这层独立验收，一个持续运行整夜的 Loop 很可能会不断批量提交垃圾代码。
Boris Cherny 之前在分享工作流时也给过类似建议：如果想把 Claude Code 的能力发挥到极致，最重要的一步就是给它提供一种能够验证自己工作的方式。按他的说法，一旦反馈闭环建立起来，产出质量通常能提升 2 到 3 倍。“让 AI 自己检查自己”这个动作，带来的效果甚至可以抵得上换一代模型。
Fable 5 教程：真正关键的是 /goal 和 /loop
文中还引用了一份在 X 上广泛传播的 Fable 5 教程。该教程作者在实测 3 周后认为，多数人仍在用普通 Claude 的方式使用 Fable 5，因此没有真正用到它最值得付费的部分。
教程先总结了 Fable 5 与以往 Claude 模型的三项差异化能力：
- 长期自主执行任务；
- 自我校验；
- 读懂密集图表。
第一项能力，是它能连续处理几天的工作，而不是只执行几分钟。教程称，以往模型更像短跑选手，Fable 5 则是第一个为“长期自主干活”而设计的模型。在 Claude Code 中，用户可以把一个跨越多天的项目整个交给它，由它自己分阶段规划、分派子智能体，并持续执行到达标为止。
第二项能力是自我检查。任务完成后，它不会立刻交付，而是先自己写测试、运行测试、发现错误并修复，再回报“已完成”。
第三项能力是识别密集图表。按照教程作者的实测，在财报表格、嵌入 PDF 的图表、架构图和仪表盘截图这类材料上，Fable 5 的表现比 Opus 4.8 更稳定，后者偶尔会出现列识别错误或坐标轴混淆。
不过，教程认为要真正释放这些能力，关键仍是两个命令：/goal 和 /loop。若不使用它们，用户相当于花 2 倍的价格买了一个聊天机器人；如果使用，则更接近于买到一个可以自主工作的员工。
怎么写目标，怎么设循环
/goal 的作用是朝着终点推进，达到目标后自行停止；/loop 则按固定频率反复执行，直到用户手动叫停。
教程给出的原则是，/goal 是否有效，关键在于完成标准必须写得具体，而且要附带一条失败时的退出路径。
例如，“改进这段代码”不是一个好的目标，因为无法验证；而“/tests/ 下所有测试通过，只允许修改 /src 里的文件，修 3 次还不过就停止并汇报”则是一个可验证的目标，因为每一条都能核对。
/loop 则不是奔向某个终点，而是定时反复执行。例如每 30 分钟检查一遍错误日志，筛出严重级别的问题并用通俗语言汇报；或者每小时扫描一次收件箱，总结新邮件并先起草需要回复的内容。
教程把两者的分工概括成三句话：
- 有明确终点，用 /goal；
- 按周期重复，用 /loop；
- 如果需要一直运行到某个条件成立，就把两者叠加使用。
在放手让系统自行运行前，教程还强调了一点：先把花费上限设好。一个没有封顶的 /goal 一旦遇到复杂问题，token 消耗可能会非常快。
20 分钟搭本地上下文，让模型“记住你”
这份教程还提到，多数指南会跳过的一步其实非常重要：Fable 5 本身不会记住用户。
每次开启新会话时，它并不了解用户的业务、写作风格、客户或偏好。要解决这个问题，可以在本地机器上搭建一套上下文系统，教程称整个过程只需要 20 分钟。
具体配置包括一个文件夹、两个 Markdown 文件以及一组技能，整体分为四步。
第一步：建立上下文文件夹
先创建一个上下文文件夹，例如命名为 fable-workspace，把它作为模型每次开始工作前都要读取的“单一事实源”。
文件夹里可以放的内容包括：一页纸的业务与优先事项概要、常用操作规程、正在推进项目的关键信息、常引用的战略文档，以及一份决策日志。教程提醒，每个文件最好控制在一页以内，否则会占用过多上下文窗口。
第二步：建立记忆文件
再创建一个 claude-memory.md 文件，并写下一条规则：每当对话中出现与业务、偏好或当前处境有关的重要信息，就把要点简短更新进去，并标上日期。
这样一来，模型会在后续会话中继续沿用这些信息。比如用户提过一次新客户，下次再开会话时，模型已经能够调用这部分背景。
第三步：建立指令文件
接着创建 claude-instructions.md，明确每次会话的行为规则，例如：开工前先读记忆文件；给建议前先查看以往决策；不确定时先提问，不要自行猜测；任务完成后主动汇报，并标出需要人工复核的部分。
第四步：在 Claude Code 中接入
最后，在 Claude Code 里通过 /add 指向这个文件夹，或者把相关内容写入 CLAUDE.md。接入后，每次会话开始时，模型都能自动带上完整背景。
教程还提到，这样配置的另一个好处是，如果未来更换别的 AI 工具，这套上下文也可以直接打包迁移。
Fable 5 的使用边界与成本分层
在成本控制上，教程给出的建议是采用“二八打法”：只把 Fable 5 用在那 20% 真正需要其长处的任务上。
在 Claude Code 中，Fable 还可以把一部分更便宜的执行工作交给子智能体完成。也就是说，它负责提出方案，Sonnet、Haiku 等模型负责执行，最后再由它回到验收环节。
按文中的总结，Boris Cherny 的“夜间 AI 军团”拆开看，核心其实只有三样：一个能自主干活的模型、一套定义“什么叫做完”的标准，以及一个按时运转的循环。
模型和循环已经具备，真正稀缺的，变成了那个能把“任务做完是什么样”讲清楚的人。