那张架构图在白板上挂了两周，我一行代码都没动。
图上画的是最近被聊烂的“软件工厂”：任务从哪来、怎么排队、Agent 怎么领活、失败了怎么重试、谁来跑测试验收。起点其实很小：给 Claude Code 提个 issue，看它自己读上下文、改代码、提 PR，这套动作早就熟了。顺着这个思路，我就想把整条链路串成一个全自动闭环。
结果越画越像在设计一套复杂的分布式调度系统，然后就彻底卡在那儿了。
想通这个问题，是因为我意识到自己犯了一个典型的工程师毛病：我一直在给流水线造复杂的调度器，但流水线的入口根本没有东西可进。
你不缺干活的 Agent，缺的是提 Issue 的人
今天把一个定义清楚的 issue 扔给 Agent，它基本能在几分钟内把 PR 提出来。代码实现这一侧早就不是瓶颈了。
真正卡死整条流水线的是上游：Backlog 里的 issue 是谁写的？
还是你。每天深夜下班，凭着记忆在面板里敲几行“优化一下定价页”、“修一下登录超时”。这种 issue 扔给 Agent，它连报错现场都找不到，只能对着代码库瞎猜。
软件工厂本质上只做两件事：
- Pre-triage：把非结构化的世界（错误日志、用户退订、操作录像），变成结构化的 issue；
- Implementation：把结构化的 issue，变成 PR。
工程师的本能是扑向第二半，试图做出一套全自动的执行引擎。但现实是：只要上游还需要你肉身去盯监控、看录像、手写 issue，你的软件工厂就依然是一家纯手工小作坊。
Pierson Marks 做软件工厂时最聪明的做法，就是拿 Issue Tracker（比如 Linear 或 GitHub Issues）在中间切了一刀，把两半彻底分开。
入口没活，先建“找活儿”的那一半
如果你的 backlog 经常见底，就先别碰任何自动化写代码的逻辑。先建输入端。
输入端的核心，是让 AI 替你盯住那些平时根本懒得看的数据源，自动产出带有“第一现场”的高质量 issue：
- 日志巡检：每天凌晨定时扫一遍 Sentry 和网关日志，发现未捕获异常直接开 issue，自动附带调用堆栈和发生频次。
- 行为回放（Session Replay）：扫一遍用户的操作录像。录像里能清楚看到用户在哪个按钮连续点击（Rage Click）、在哪一步卡住退出。录像一直都在，只是人肉不可能每天看几百条。
- 流失分析：拉取过去 24 小时点击退订的用户数据、退订前的操作链路，分析他是踩了 bug、用量未达预期，还是核心体验受阻，直接生成具体的改进建议。
这种 issue 产出来，天然带着复现路径、报错堆栈和用户上下文。“用户在定价页点击结账 3 次无响应”比“优化定价页”有用得多，因为 Agent 接到手就知道该去看哪段交互。
哪怕后半段完全由你自己手动改代码，你也等于雇了一个每天 24 小时替你看数据、提明确需求的产品经理。
干活的那一半：放权的单位是一张标签
当上游源源不断产生高质量 issue 后，实现侧的触发链反而极短。
不需要复杂的权限系统和流水线总控台，人机协作的边界可以收敛成一个动作：打标签。
- 默认状态：上游巡检开出的 issue，默认不打
auto标签。 - 人工介入：人扫一眼 issue 列表，确认问题真实、复现路径明确，顺手打上
auto标签。 - Agent 动工：Webhook 捕获到标签变更，自动拉起远程 Agent，读 issue、改代码、跑浏览器验证、提 PR。
这一设计的精妙之处在于渐进式交权：
你不需要在“全人工”和“全自动黑盒”之间二选一。刚开始，所有人肉审核打标；等某个巡检（比如明确的 Sentry 报警、前端格式修复）运行稳定了，就允许它自己打上 auto 标签实现全自动闭环。哪天发现它开始瞎提 PR，收回自动打标的权限即可。
放权不需要给整条流水线装总开关，一张标签就够了。
半个工厂就值得建
回头看白板上那张大图，最大的误区在于预设了“必须一次性做完整套闭环”。
真正的做法是按瓶颈分步走：
- 如果你的 backlog 经常见底，今天就挑一个数据源——错误日志、客服对话或退订记录，写一个定时 Prompt 抓问题提 issue，实现侧继续人工做；
- 如果你的 backlog 已经堆满，顺序就反过来：先配一个 Webhook，给打上
auto标签的 issue 自动触发 Agent 改代码，别再让上游造更多待办。
先用 issue tracker 把两半切开，再去自动化真正卡住你的那半个工厂。
这里专注拆解一人软件工厂与工程自动化的落地细节。后面我会持续记录输入端自动化、打标签渐进放权，以及如何用最小的系统复杂度搭建一人流水线。欢迎关注。