从一个 bug 开始，构建智能体软件工厂
我们来用一些技能和一份 AI 订阅，搭建一个智能体软件工厂。从一个 bug 开始，建立一个能复用到后面上百个 bug 的流程。这个工厂本质上是给编码智能体的一套可重复工作流：接一个 bug 报告，复现问题，做出修复，最后交给你一个经过测试的 PR 来审查。过程中，我们会给智能体一个可靠的测试环境，让它做出的改动容易审查，并搭建一个反馈循环，用来抓住它漏掉的问题。如果你已经在用编码智能体，这些步骤大部分你可能都手动做过。你找到一份报告，解释问题，把智能体指向代码，然后检查它返回的结果。我们要把这套日常操作变成可以反复运行的东西，不用每次重新解释整个流程。我们用一个更大规模的同类工作流来维护 Agent-Native，那是我们免费开源的框架和一系列应用。下面是那套设置的演示。不看视频也能跟上文章；我们会一步步搭建，慢慢引出有用的部分。
从一个 bug 开始，但为后面上百个做好准备
第一个 bug 可以帮我们检验这个工厂本身。它能读懂报告、复现问题、修复，并给出足够证据让我们审查改动吗？一旦跑通，我们就可以把同样的流程套用到下一个报告上。
想象这样一份报告：
我把一张卡片移到另一张卡片下面。当时看起来对了，但刷新之后，它又回到了原来的位置。
这是个有用的起点。我们清楚用户做了什么、发生了什么、期望是什么。排序应该在刷新后保持不变。我们可以在改动前后分别测试，对比结果。
“编辑器用起来怪怪的”这种反馈，就需要再追问一轮。哪个编辑器？你想做什么操作？你的工厂要能判断：什么时候信息够用了，什么时候该继续追问。
从你维护的仓库里挑一个报告。它要足够小，小到你能理解行为，也能判断修复对不对。调查、测试和审查的指令，我们会重复使用。下次变的只是报告本身。
给智能体一个真正能测试的地方
把 bug 交出去之前，先确认智能体能跑起产品来。一个有经验的同事知道怎么绕过别扭的登录流程、哪个数据库有能用的测试数据、终端里哪个报错可以忽略。但一个全新的智能体会话，这些都得从头摸索。如果环境搭建依赖口口相传，那每处理一个问题你都要把这些经验重讲一遍。我把它称为「智能体体验」：让一个没有团队历史背景的智能体也能理解并使用这套环境。这份投入，在你每开一个新会话时都会得到回报。
一个好的起点是：每次改动都配一个预览部署，用 Netlify 或 Vercel 之类的服务，连接一个独立的测试数据库，里面放有代表性的数据。记录类型、关联关系、权限场景，都要跟真实产品一致。如果数据库是空的，那些只在有卡片存在的看板上才出现的 bug，就根本复现不了。智能体还需要用有对应权限的测试用户登录、打开受影响的界面、查看浏览器报错和服务端日志。把这些命令和搭建步骤写进代码仓库，下一次会话才能照着重复。如果你更想全部在本地跑，也可以。关键在于智能体能从一份干净的代码检出，走到它要测试的那个行为。
对我们那个卡片排序 bug 来说，光「应用能构建成功」还不够。智能体需要一块能编辑的看板、一条可用的保存路径、以及重新加载已保存状态的方法。否则它可能只是把代码里看得见的问题改了，却永远不知道原来的毛病有没有消失。
信任也正是在这里开始变得实际。Lauren Tan 在那场关于编码智能体的演讲中提到，验证、过硬的技能、以及智能体能驾驭的架构，是信任更多智能体的部分答案。我们可以从一个智能体开始实践：给它一个可靠的方法来自查，也给自己一个方法来核对结果。
安装技能，挑第一个问题
Factory 的技能包把那些反复出现的工作打包好了：收集反馈、调查问题、跟进 PR、回顾哪里出了错。
它们是可复用的指令，直接喂给编码智能体（coding agent），所以不必为每个 bug 都重写一大段提示词。在仓库里运行：
npx @agent-native/skills@latest add
选择 Factory 和你的智能体客户端。智能体需要能访问仓库、你选定的反馈来源，以及刚配置好的环境。先用 /factory 配置工作流。第一轮，只挑一个反馈来源、一个仓库，并限定一类范围较窄的工作：能复现、能修复、能验证，且不需要产品决策的 bug。同时指定一个人，负责审核和合并产出的改动。然后做一次试运行：
/factory-collect
先拿这个 issue 空跑（dry run）一次：[issue URL]。告诉我它算不算合适的候选，以及你打算怎么复现，再动手干活。
看看它挑中了什么、为什么挑这个。如果它把「刷新后订单会重置」理解成「重新设计看板」，那就把范围收窄。如果它找不到出问题的那一页，就把这段上下文补上。如果期望的行为本身有歧义，先把歧义解决掉，再让它出补丁。这些修正只要对以后的 issue 有帮助，就该写进共享配置或指令里。我们希望下一次运行时能沾上这一次的光。
让 bug 走一遍工厂
空跑结果说得通了，就让工厂去处理这个 issue，并准备好一份 PR 待审。流程由各项技能承担，你的指令可以很短：
处理这个 issue。复现它、修复它，然后准备一份已验证的 PR。
供人工审核。合并和部署交给我们。给每个修复单独分配一个 Git 工作树（worktree）。工作树就是同一个仓库的另一个工作目录，有自己的检出分支。这样一个代理在修卡片排序的 bug 时，另一处改动可以在别的地方同时进行。如果你还没用过工作树，Vishwas 的《Git Worktrees Explained Simply》是一篇不错的入门教程。
放在我们的例子里，复现必须包含刷新这一步。仅仅把卡片拖动成功，只验证了报告的一半。代理应该改变顺序、重新加载页面，然后看保存的顺序有没有保留下来。如果它复现不了故障，就让它说明尝试了哪些操作、缺了哪些信息。也许这个报告依赖某个特定权限、浏览器，或者已有的记录。这样在动代码之前，你就有具体的东西可以查了。
一旦它能展示出故障，就可以倒推原因。界面可能更新了却没保存，保存请求可能失败了，重新加载可能返回了旧的顺序。代理应该顺着证据走，针对查到的原因做出改动。然后把最初的检查再跑一遍，一直走到刷新那一步。能捕捉到故障的地方就补一个回归测试，再跑一遍和这次改动相关的现有检查。如果补丁动了共享的排序逻辑，那还要检查这段逻辑的其他使用场景。
结果应该让你能把出问题的行为和改动后的行为对比出来。如果是浏览器 bug，可以是一段简短录屏，配上自动化检查。如果是数据 bug，可以是一个失败的测试、补丁，以及同一测试在修复后通过的结果。
让结果易于审核
你不需要读完整个代理对话，才能判断这个修复合不合理。让代理把有用的证据整理到一起：原始报告、它找到的原因、相关的 diff，以及它重走用户步骤时发生了什么。它没法检查或者需要帮忙的地方，也要写进去。这样在改动还容易修改的时候，不确定性就一目了然了。
对于 UI 相关的工作，一份视觉回顾能帮上大忙。把改动前后的行为放在说明旁边，再附上预览链接。
我们在《别盯着智能体干活》里讲过这套做法：先用一个可视化计划对较大的改动达成一致，再用一份回顾检查实际做出来的东西。对于小 bug，简单说明加清晰证据可能就够了。
代码审查的工作在 PR 打开之后还在继续。factory-babysit-pr 跟踪单个 PR 走完 CI 和审查反馈，factory-review-prs 处理一批 PR。学习这个工厂怎么运作时，先从单 PR 流程开始。观察智能体是否能看懂一条审查意见、是否把修复控制在这一处、改完之后有没有重新跑受影响的检查。最终结果能不能合并，仍由审查者决定。
拿另一个 bug 再走一遍同样的流程。然后再来一个。接着换一份不同的报告，流程不变，只换输入。你会从这里了解到第一次运行里哪些环节是可复用的。也许你之前得手动填页面 URL；也许报告说的是浏览器问题，智能体跑完单元测试就停了；也许它开了 PR 就再也没管过失败的 CI 任务。在这些缺口处动手，让下一次运行能受益。把环境搭建写进仓库，在共享指令里写清验证要求，或者补上缺失的 PR 跟进步骤。再拿一个问题试试，看同样的干预是否仍然必要。
也要记录人的工作量。一个工厂产出五个 PR，却需要五次长时间的救火，这和一个工厂产出五个 PR、每次审查都很顺畅，传达的信息完全不同。你反复介入的地方，就是下一步该改进的地方。
我们一开始是手动跑这些流程的。当你反复启动同样的步骤并且能得到有用的结果后，就把这套流程挂到调度上，跑在你的智能体宿主里。一开始范围要窄。先搞清楚现有反馈源和问题类型的行为，再添加新的反馈源或新的问题类型。
持续使用产品，持续报告出问题的地方。工厂需要关于用户真正在用的产品的稳定信息供给。我们用自家的应用，遇到问题就报。
队友在真实工作流中卡住，往往能暴露测试套件或短暂预览检查漏掉的问题。这类反馈应该和最初那个 bug 走同一个接收渠道。工厂可以从两个方向利用这些反馈：特别留意那些在「问题已修复」之后又冒出来的报告。如果卡片排序反复出问题，那再给最新的例子打一个补丁，很可能治标不治本。把新的报告和之前的改动放在一起看：它们是不是同一段共享代码里的不同故障？测试是不是漏掉了页面重载、另一个用户，或者第二种修改排序的方式？factory-lookback 专门用来处理这类历史记录。它会翻查之前的活动，找出反复出现的问题和值得深挖的模式。在我们规模更大的工厂里，反复出现的聊天和拖拽问题就是典型例子——下一次排查可能需要找出多个报告背后的共同原因。把你学到的东西反哺回实现代码、回归检查和智能体使用的指令。合并一个 PR 是一个有用的结果；而弄清楚同一个 bug 为什么反复出现，能让整个工厂变得更好。
给卡住的智能体搭把手
同时运行的任务一多，你还得注意智能体什么时候停止了推进。这里有好几种情况：修复可能已经就绪，但交付流程卡住了；智能体还在干活，却朝着没用的方向使劲；或者好几个已完成的修复犯了同一个错误。这些技能给不同任务起了不同的名字。factory-watchdog 负责检查交付是否停滞，并帮助恢复那些已经授权的任务。agent-watchdog 可以审计另一个智能体的工作，在宿主平台支持的情况下，还能协助监督整个会话。lookback 则负责处理历史中的模式。
这样你就能有选择地安排监督。如果你的智能体宿主允许为不同的执行者和审查者挑选模型，你可以试着用较小的模型处理定义明确的修复，等排查卡住或者改动需要另一种意见时，再换上更强的模型。不妨验证一下这种搭配是不是真的减少了你的时间和总成本——Factory 技能不会替你做这个决定。