以前只有写代码的人在搭这种自动循环

今年 6 月起，写代码的人里流行起一种做法：搭一套会自己跑的循环，让循环去催 AI 干活，人不再一句句对着 AI 提要求。这套做法有个名字，叫 loop engineering。Addy Osmani 在 6 月那篇长文里把一个循环拆成了五样东西，再加一份记忆。

这六样东西全长在编程工具里，用它们的人也基本是开发者。Loops 换了对象，接的是产品团队每天在干的那些重复运营活。

右边这三件事的流程本身都是清楚的，卡的地方在于：得有人盯着进来的变化，做一次判断，然后动手。那 Loops 要怎么把这类活接过去？先看它长什么样。

一个 loop 是由哪几样东西拼起来的

建一个 loop 只要两步：用大白话把这件事描述清楚，然后选它是到点跑还是被事件叫醒。展开看，一个 loop 身上挂着四样东西。

一个叫 Product standup prep 的 loop，挂在 Product 团队下。触发方式选的是排程：从 2026 年 7 月 15 日起，每 2 周晚上 9 点前后跑一次。下面 Instructions 框里就是一段大白话指令。来源：Linear 发布页

Prepare the agenda for the next Product team standup.

Review the last 2 weeks of product activity and surface the key things the team should talk about live.

Focus on:
- decisions to make
- open questions
- risky assumptions

它跑一次到底做了什么

每次触发，Linear Agent 重新读一遍这个 loop 的指令，自己决定这一次该做什么。它能拉的上下文包括 Linear 里的 issue、项目和文档，接进来的代码库，挂上的 MCP 工具，还有这个 loop 之前几次跑的结果。所以它能处理例外、能在信息不全的时候先去问、能在几条路里挑一条。

官方文档里有个现成的例子，看得比较全：一个叫 RideShare 的工作区，一个叫 Bug investigation 的 loop。先看它的指令。

When an issue enters Triage, run only if it either has the Bug label or uses the bug report template.

Review the issue description, labels, comments, attachments, linked issues, related customer requests, and recent relevant issues across the workspace.

First, determine whether there is enough information to continue triage. The minimum needed is:
- expected behavior
- actual behavior
- reproduction steps
- device and OS information

If materially important information is missing, leave a short comment asking the user for the missing information.

If enough information is present, assess:
- severity as critical, high, medium, or low, with a short justification
- regression risk as likely, possible, or unclear
- duplicate risk as likely, possible, or none found
- the most likely team
- the most likely owner

这条指令值得多看两眼，因为它示范了写 loop 指令的三个手法。第一个是前置门：开头那句「只在带 Bug 标签或者用了 bug 模板的情况下才跑」，把不该它管的 issue 直接挡在外面。第二个是把输出锁成有限选项：严重程度只能选 critical、high、medium、low，回归风险只能选 likely、possible、unclear，不给它自由发挥的余地，结果才能被后面的流程直接拿去用。第三个是信息不够时不许硬猜：先列清最少需要哪四样，缺了就去评论区问人，而不是凭想象填一个严重程度。

再看它跑一次的结果。7 月 9 日晚上 11 点 04 分那次，它干了 3 分钟。在 RIDE-10663 这条 issue（飞行模式重连之后加载不出行程历史）上发了一条分派总结，把它关联到 RIDE-10639，按评估结果改了团队、负责人、优先级和工作量预估。这两条 issue 的标题一字不差，属于疑似重复。然后它多走了一步：拿现有的那个修复去验报告里说的 iPhone 17 加 iOS 27 重连路径，结论是修复看着没问题、不用改代码，合并之前还差一次构建加一次真机上的飞行模式复现。

Bug investigation 这个 loop 的运行历史。左边一列是每一次运行的时间，上方那个开关叫 Show successful runs，控制成功的运行要不要一起列出来；右边上半部分是它的指令，下半部分是这一次做了什么，末尾挂着那条对应的修复分支。来源：Linear 官方文档

这张图里还有个容易被漏看的细节：这个 loop 是被事件叫醒的，所以跑得相当频繁。光是 7 月 9 日那一天，图上能看见的运行就有 16 次，从下午 5 点 49 一直排到晚上 11 点 12。每一次都单独留一条记录，事后想知道它当时读了什么、动了什么，逐条翻得到。这个频率后面还会再提一次，因为 Loops 是按运行次数收钱的。

你能给它开多大的口子

这是一个没人盯着的 Agent，跑在公司的工作区里。所以权限这排开关决定了两件事：它能摸到多少东西，以及它能不能把里面的内容送出去。建 loop 的时候逐项开，用不上的就别开。

新建 loop 最后一步的权限面板，图上是六项，上面列的第七项「改触发它的那条 issue 之外的东西」不在这个面板里，只写在文档正文中。另外这张图上第二项的开关名写作 Web search，官方文档正文里把同一项叫 Web access。图上外部同步线程和外部来源触发两项是关着的。来源：Linear 官方文档

工具是另一条口子，但它的边界比权限开关窄。给 loop 挂一个工具，等于授权这个 loop 到那个服务里去动手；能动到哪一步，取的是两个范围的交集：那个集成本身被配置成能干什么，以及这个 loop 的数据范围有多大。另外每个工具还得工作区先批准才能用，工作区管理员在安全设置里定一份允许清单。

这个 loop 挂了 Datadog、GitHub、Intercom 三个工具。下面灰条里那行提示：用个人凭据接一个 MCP 服务器，等于让这个 loop 拿到你的个人数据。来源：Linear 官方文档

团队现在拿它干什么

上一节那个 bug 排查 loop 就是第一个场景，这里不再重复。除它之外，发布页和官方文档一共给了这几种，其中带标记的四条在文档页面上是现成的，点一下「Build this loop」就能照着建一个。

When an issue enters this team's triage queue, investigate its likely root cause with Code Intelligence. If you think you can fix it, start a coding session.

Every Monday afternoon, review projects that had their first update in the last week or were mentioned as newly kicked off in @Weekly sync document. Send a Slack message to the #product-marketing channel so they're aware of what's coming.

When an issue is created in team Mobile, create separate issues for the iOS and Android teams, if relevant.

跑一次 Loops 要花多少钱

Loops 在 Business 和 Enterprise 套餐上可用。从 7 月 20 日起，跑一次要扣工作区的 AI credits。这池钱不是套餐里包的，得管理员另外充；也不是所有 AI 功能都在用它，只有编码会话和 Loops 走这池，其余 AI 功能算在套餐里。它按实际用量扣，不按人头收。

把这个价目表和上一节那个数字放在一起看，才知道一个事件触发的 loop 实际会花多少钱。那个 bug 排查 loop 光 7 月 9 日一天就被叫醒 16 次，按不开编码会话算是一天 1 块 1 到 3 块 2 美元；可它的指令里明写着「路子清楚就直接起编码会话去修」，只要有一次真动手，那一次就是 3 到 5 美元。这也解释了那条指令为什么开头就写「只对带 Bug 标签或者用了 bug 模板的 issue 跑」：前置过滤既是为了结果准，也是为了别乱花钱。

还有几件跟钱有关的事：用 AI credits 是自愿的，工作区一直不充值，就用不了 Loops 和编码会话，也永远不会被扣钱；额度归零或者促销额度过期之后 loop 会暂停，除非管理员开了自动补额或者另外买了额度，只有开了自动补额工作区才会被自动扣款；充值走 Stripe，跟 Linear 订阅账单分开开票；花在哪个功能、哪个人身上，在设置的账单页能看到实时明细。

建一个 loop 有两条路

第一条路是先在聊天里试出来，满意了再把它定成 loop：按 ⌘/Ctrl + J 打开 Linear Agent 聊天，把你想要的结果先调对，不满意就继续提要求，直到产出的东西格式和内容都合适，然后让 Linear 把这段变成一个 loop，缺的字段它会提示你补。文档给了一段现成的开场白，场景是每周四要开项目 check-in 会的负责人：

Check the project Slack channel, open questions in the last update, and any issue threads that seem relevant. Add a new section in the Meetings project document with those details, using a format like [...]

第二条路是直接在界面上建：侧边栏工作区那一组里点 Loops，建的是工作区级的；点团队名进去再选 Loops 标签页，建的是这个团队的。之后依次选触发器、写指令、可选挂工具、过一遍范围和权限。

谁能建和管 loop 也是可控的：工作区所有者在安全设置里管工作区级的 loop，团队所有者在团队的访问与权限里管本团队的。

以后 Linear 打算再加更多触发方式和上下文来源，以及给工作区和团队管理员的治理控制。

Linear 在 7 月 20 日上线了 Loops。你把一件想让它反复做的事用大白话写清楚，再选它是到点跑、还是被某条 issue 的变动叫醒，它就在整个工作区里一直跑下去。原来要人守着的那次判断，现在写成了一段话。

同一套写法还能干别的：新需求进来自动派生 iOS、Android、Web 三边的子任务；每天下班核对项目和发布计划文档，变了就改并留一句为什么改；一次事故关掉之后做根因分析、把该跟进的建成新任务。问题也随之而来，这么一段话，它每次被叫醒时是怎么变成动作的？

一个 loop 身上挂四样东西：触发器（到点，或者 issue 符合条件时）、一段大白话指令、可选的外部工具、一排权限开关。它不是照着脚本走固定步骤，每次被叫醒，它重新读一遍你写的那段话，再看当下的材料，自己决定这一次该做什么。下面这张图跟着官方文档里那条真实 bug 走一圈，它来自 Linear 文档展示的一个叫 RideShare 的工作区。

Loops 不按人头收，按被叫醒的次数扣钱。花销大小主要看一件事：你有没有让它动手改代码。还是文档里那条排查 loop，7 月 9 日那天它被叫醒 16 次，两种开法的日成本差出一个量级。

门槛：要有 Business 或 Enterprise 工作区；这池钱套餐不包，得管理员主动充，手动一次最少 10 美元，余额归零 loop 就暂停。以上价格与额度均出自 Linear 官方计费文档，第三方无从核对。