我如何使用 Linear 管理智能体（以及为什么我们都应该构建软件工厂）

Linear 可能是我目前最物有所值的订阅。我支付每月 12 美元的个人用户费用，而公司智能体在过去一个月里已经处理了大约 400 个工单。

我使用 Linear 来组织我的工单，并将它们输入给编码智能体并行处理。Linear 是一个中央协调点，也是一个很好的界面，让我可以在笔记本电脑上或移动中组织工作。

与我期望达到的软件工厂自动化第 5 级相比，我目前拥有的只是一个相当低技术含量且粗糙的原型。不幸的是，它已经足够好地完成了工作，以至于我被迫去开发我的产品，而不是玩软件版《异星工厂》。

工单按成果层级组织

当普通智能体管理工单时，它们会相当有创意地将工单散落在待办事项中，并且经常使用自己晦涩的行话，比如“修复 owned-compute 处理器中的门控访问异常“。

为了我自己能清晰知道需要做什么（这恰恰是 Linear 的意义所在），我让它们维护一个以成果命名的工单层级结构，而不是技术任务。

任务被组织成成果层级。（当智能体开始执行时，它们通常会包含更多技术性子任务。）

任务被组织成成果层级。（当智能体开始执行时，它们通常会包含更多技术性子任务。）

将工单排列成树状结构意味着我可以鼓励智能体完成从史诗级直到根节点的树，这让我对进度有一个高层次的了解。

我发现这在团队中一直很有效，但与智能体合作时效果尤其好，因为与我们大多数人不同，它们非常乐意实际去整理待办事项。

分类收件箱是未来提示的收件箱

智能体一次处理 3-5 个“工作流“，这些工作流被确定不会修改同一代码区域（通过 LLM 工作流）。为了避免中断这个过程，当我发现问题时，我会将问题报告到分类收件箱中，而不是启动新的智能体。

我无需考虑放入分类收件箱的事项的优先级——我只是放下任何我能想到需要做的事情。这个工单最初只是一张截图，后来根据智能体的“工单接收指南“得到了充实。

这个工单最初只是我拖入分类收件箱的截图，然后被智能体扩展得更清晰。分类收件箱已成为我放下需要修复事项的关键方式。

这个工单最初只是我拖入分类收件箱的截图，然后被智能体扩展得更清晰。分类收件箱已成为我放下需要修复事项的关键方式。

为智能体格式化工单

工单是我和智能体之间的契约，有点像计划，但为了使其对人类可读性最大化，它们都包含“目标“、“原因“和“成果“部分。这有助于我清晰记住工单是关于什么的，并让智能体有更好的机会解决真正的需求。

关注目标状态可以避免过度约束实现方法。在定义工单时，代码通常没有经过深入研究，所以确切的方法最好留给执行智能体去决定。与人类团队一样，如果智能体有明确的标准可遵循，执行者的自主权对它们来说效果很好。

为了帮助智能体，还有两个部分：

• 实现方法：我们在这里注入任何关于实现方法的指导，通常来自我。

• 验证：由创建工单的智能体在严格指导下创建，关于新功能的最小测试流程。它们通常总是包括“自动化“、“手动“和“视觉“检查。（我计划将来用自动化检查取代手动检查，以提高可重复性。这些检查将依赖于一个健壮的计算机使用智能体。）

如果清单中的任何项目未勾选，智能体将被阻止关闭任务，以避免作弊或仓促工作。（当然，智能体仍然可以作弊或删除复选框——但实践中它们不会这样做，因为这需要比典型的“我完成了“声明更高程度的不诚实。）

将工作组织成批次

我发现通过将工作组织成 3-5 个并行工作流的批次来达到最佳平衡。根据当天的情况和每个批次中工作的大小，这些批次可能需要 30 分钟到 4 小时以上，一天可以产出 2-4 个批次。

驱动力：我自己的生活质量

这个系统的一个重要理念是我自己的生活质量。批次是无人监督的（并且 Claude 的 AskUser 钩子被阻止——所以它不会在 15 分钟后问一个问题然后闲置 2 小时）。

因为智能体喜欢通过要求你在计算机上执行操作（比如登录浏览器）来让你解除阻塞，所以告诉智能体它们是在无人监督下工作很重要（“但会监控质量和安全”，这是一个微弱但低成本的尝试，以减少作弊或破坏）。

这为我换回了专注力，让我可以批量进行深度工作、审查和启动工作，而不是整天在智能体窗口之间进行令人疲惫的任务切换。

批次如何运作

为了创建一个批次，我使用一个“工作流更新“技能，该技能：

• 确保任何进行中的工作确实在进行中，并使其他工作可供接手。

• 读取从我或其他智能体（通过分类收件箱）进来的任何新工单。

• 加载优先级——专注于完成进行中的工作，查看我的指导和每周目标，并查看是否有任何新事项紧急。

• 提出 4-5 个智能体提示，我将其粘贴到智能体中。

工作流更新本质上是一个文档，以高层上下文开始…

…并包含分配给智能体的 3-5 个任务段。执行工作流更新的智能体被提示使每个部分在代码区域上不重叠，但将工作流分配给能够有意义地推进当前目标的智能体。

之前我说这个系统是低技术含量的，我的意思是：我将每个工作流提示粘贴到 Codex、Claude Code、Cursor 或 Antigravity 中。

要求工作必须完成

在早期迭代中，我遇到了很多问题，不同的智能体未能完成分配的工作。我希望智能体完全关闭工单（包括合并更改），但智能体总是在完整工作完成之前的各个阶段停下来：在提交代码之前，在创建 PR 之前，在标记为可审查之前，在通过测试和审查之前，在成功合并之前，以及在检查工单中所有复选框之前。

为了克服这一点，我付出了很大努力让智能体真正完成工作。当你使用多个工具链并且没有一个简单的 API 来调用智能体时，这是一个更混乱的问题，所以你不得不依赖钩子而不是典型的工作流方法。

在这一点上，智能体通常确实能完成它们的工作。如果没有，它们必须将工单标记为“阻塞“，并根据人类升级标准（见下文）正式升级请求人类帮助。

通过提示和钩子，智能体被要求：

• 注册一个“智能体会话“，关联到工单。

• 将工单标记为进行中。

• 处理工单。

• 提交 PR 并确保它们被合并和部署。

• 确保所有代码已推送并在 PR 中。

• 勾选每个工单中的所有复选框。

• 确保所有工单被标记为已关闭或阻塞。

• 上传会话记录，用于根本原因分析。

• 将智能体会话标记为完成。（如果会话是交互式的——例如，如果我问了一些与工单无关的代码库问题，智能体可以请求“豁免“以遵循通常需要验证完成工单的正式关闭流程。）

钩子对于确保智能体完成任务至关重要。偶尔会有误报，智能体因为一个实际上不需要人类参与的问题而阻塞——例如，当我们的 MCP 服务器不支持它们需要的工具，但它们实际上有能力直接向 MCP 服务器部署一个新工具。但大多数情况下，它们在完成任务方面做得很好。

人类升级

我现在的大部分工作都围绕访问控制——创建账户和将机密从一处移到另一处。

智能体非常不擅长将工作分配给人，因为它们有知识的诅咒——它们通常期望你拥有完全相同的心理状态，并且你知道它们所说的“需要这个来部署组件质量棘轮“的确切含义。

它们还喜欢给你分配需要十五分钟而不是两分钟的任务，通过说“添加一个 GitHub 应用“而不是给出确切的指令和配置。

为了解决这个问题，我提示它们在表述人类升级时要小心，并假设人类非常忙，真的没有心思。人类对代码、正在解决的问题，甚至为什么他们在这里知之甚少。我还要求它们不遗余力地让人类能够快速完成工作而不需要太多思考（例如，通过编写脚本）。

最后，我要求它们确保所有其他未阻塞的工作乐观地进行，这样当人类升级问题解决后，完成任务所需的工作量最小。

Linear + 智能体 quirks

总的来说，Linear 的 MCP 服务器工作得很好，但我确实需要对与 Linear 的接口做三个小的调整。这些调整足以让他们用我们自己的 MCP 服务器替换掉原来的 MCP 服务器：

• 支持通过差异更新工单摘要。 智能体倾向于通过保持工单描述正确来发布它们的更新。这通常是好的行为，但它们倾向于完全覆盖验证标准和原始工单的其他重要细节，这对审查智能体很重要。所以我禁止了直接编辑，但给了 LLM 一个发送差异补丁的工具。

• 给智能体它们自己的身份，而不是我的。 Linear MCP 服务器默认使用你的个人 OAuth。我不得不迅速切换到给智能体一个不同的 MCP 服务器，使用基于应用的身份验证和身份。当智能体向我分配任务时，我没有收到任何通知，因为它们是以我的身份在操作，很多时候我困惑于智能体是否关闭了任务还是我关闭的。

• 小的 ergonomics 改进。 通过普通 MCP 服务器提供的 get_issue 命令并不总是返回足够的环境信息给智能体，包括评论和子任务，所以这确保了它们拥有完整的信息，而不需要“记住“去询问所有东西。

效果如何

这个系统工作得非常好，与我之前试图通过认真思考来分配工单工作并被动监控完成情况的尝试相比，是一个显著的改进。

Linear 在任务管理方面是一种乐趣，在移动中使用尤其出色。智能体通过这个系统做了大量的工作，它们似乎从工单模板中获得的环境信息中受益。

由于格式是经过人性化优化且以成果为导向的，我也很容易验证工单是否要求了正确的事情。总的来说，我的注意力扩展得比我实现这个系统之前好得多。

我能够使用桌面智能体工具链快速搭建这个原型，这很快，但也受到订阅代币便宜得多的限制。我可能会保持这个设置一段时间，因为它很实用，而且不管好坏，软件工厂都不是我的主要业务。

我用来管理从工单到完成代码的状态机的 hack 需要被一个合适的状态机所取代，这样系统就可以更容易地被衡量（例如，完成率和缺陷率）、推进（当事情卡住时）和持续改进。

我想要改进的大部分事情都需要突破使用工具链的限制：

• 用工作流替换钩子。 我为管理“智能体会话“而设置的 hack 非常令人不安。它跟踪哪些智能体是活跃的，但也允许对速度慢或产生不良结果的智能体进行根本原因分析。但这种可憎的实现要求智能体去翻找要上传的记录，这些记录的位置取决于工具链。如果我不依赖于订阅的经济性，那么直接从 Linear 工单通过 API 调用智能体，并通过一个合适的工作流表示来管理智能体会话的后置条件会愉快得多。

• 带度量的工作流。 我是流程管理、持续改进和丰田生产系统的忠实粉丝。所有这些美妙的想法都惊人地适用于软件工厂——剩下的就是捕捉指标（如完成率、缺陷率和方差）并开始系统性地改进低 hanging fruit。

• 评估。 由于我的大部分工作都围绕评估，并且我非常依赖编码智能体，这感觉有点讽刺，因为我没有对自己使用的编码智能体进行评估。能够重复同样的任务在不同的指导下进行，并且至少每周运行整个套件，这将非常有用。但当你使用多个工具链时，设置起来有点麻烦，所以我没有费心。感觉我正在向 OpenAI 标准化，它很方便地不认为这是违反 ToS 的行为，所以这可能很快就会到来，而且现在对我来说可能是低 hanging fruit。

软件工厂是未来，现在是做对的时候了

我有兴趣听到更多关于软件工厂工作的人的意见，所以我想阐述为什么软件工程师应该热情地投身于软件工厂。

对于是否应该朝着软件工厂——即生成生产级软件、让人以最高杠杆工作的系统——努力，存在相当大的分歧，可能还有尴尬的犹豫。

它们是否“真实“，就像 2-3 年前关于智能体是否会广泛用于编码一样存在分歧。那些最好地执行了 LLM 会写出好代码这一信念的公司，在软件世界中创造了巨大的价值——并且以 25 亿到 600 亿美元不等的金额被收购。这表明保持乐观，并在迹象出现时计划成功，可能是有价值的。

今天存在分歧的最大症状是，许多人正在讨论自动化代码审查是否是一个有价值的目标，或者工程师是否应该阅读每一个 PR。“你看代码吗？“这是我经常被其他也在试图找到正确平衡的工程师问到的问题。

我对我们关于软件工厂是未来的犹豫感到惊讶。对我来说，很明显，自动化所有可能自动化的事情是值得的，只要这种自动化能够成功交付生产级软件。

表明这是可能的迹象比以往任何时候都更清晰，虽然我们可能会看到行业级别的工具和模式出现，但所有团队都可以采取一些步骤，从今天开始利用自动化，并朝着隐喻中的“冰球“（市场方向）前进。

为了确保这种自动化对软件工程师作为专业人士有效工作，并构建允许我们从事充满活力工作的工作流，我们应该积极参与塑造它，而不是让它发生在我们身上。我们是想把所有时间花在审查 PR 和批准智能体行动上，还是想设计允许我们进行深度工作和创造力的系统？这两种世界同样可能，并且很大程度上取决于我们在使软件工厂对人友好方面付出的努力。

软件工厂是值得的，就像编码智能体是值得的一样——好处将好到无法忽视，除非你将构建软件作为爱好，否则为了竞争，你将不得不走向那里。