---
title: "软件工厂建不动：你缺的不是 Agent，是提 Issue 的人 | 行开心的颠倒世界"
description: "软件工厂卡住往往不是 Agent 不会写代码，而是上游没有高质量 issue。用 issue tracker 把工厂切成两半：上游用定时 loop 抓日志和录像自动提需求，下游用 auto 标签触发 Agent 开 PR。Backlog 见底先建上游，堆满先做标签触发。"
canonical: "https://xingkaixin.me/posts/one-person-software-factory/"
language: "zh-CN"
---

# 软件工厂建不动：你缺的不是 Agent，是提 Issue 的人

软件工厂卡住往往不是 Agent 不会写代码，而是上游没有高质量 issue。用 issue tracker 把工厂切成两半：上游用定时 loop 抓日志和录像自动提需求，下游用 auto 标签触发 Agent 开 PR。Backlog 见底先建上游，堆满先做标签触发。

2026年9月4日·1,389 字·4 分钟

[AI Agent](https://xingkaixin.me/tags/AI%20Agent/)[软件工程](https://xingkaixin.me/tags/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B/)[工程效率](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E6%95%88%E7%8E%87/)[独立开发](https://xingkaixin.me/tags/%E7%8B%AC%E7%AB%8B%E5%BC%80%E5%8F%91/)

![问题证据进入 issue 后，空转的执行端才启动](https://xingkaixin.me/cover/one-person-software-factory.webp)

那张架构图在白板上挂了两周，我一行代码都没动。

图上画的是最近被聊烂的“软件工厂”：任务从哪来、怎么排队、Agent 怎么领活、失败了怎么重试、谁来跑测试验收。起点其实很小：给 Claude Code 提个 issue，看它自己读上下文、改代码、提 PR，这套动作早就熟了。顺着这个思路，我就想把整条链路串成一个全自动闭环。

结果越画越像在设计一套复杂的分布式调度系统，然后就彻底卡在那儿了。

想通这个问题，是因为我意识到自己犯了一个典型的工程师毛病：**我一直在给流水线造复杂的调度器，但流水线的入口根本没有东西可进。**

## 你不缺干活的 Agent，缺的是提 Issue 的人

今天把一个定义清楚的 issue 扔给 Agent，它基本能在几分钟内把 PR 提出来。代码实现这一侧早就不是瓶颈了。

真正卡死整条流水线的是上游：**Backlog 里的 issue 是谁写的？**

还是你。每天深夜下班，凭着记忆在面板里敲几行“优化一下定价页”、“修一下登录超时”。这种 issue 扔给 Agent，它连报错现场都找不到，只能对着代码库瞎猜。

软件工厂本质上只做两件事：

1.  **Pre-triage**：把非结构化的世界（错误日志、用户退订、操作录像），变成结构化的 issue；
2.  **Implementation**：把结构化的 issue，变成 PR。

![issue tracker 连接产生、存放和完成工作](https://xingkaixin.me/posts/images/one-person-software-factory/one-person-software-factory-01.webp)

工程师的本能是扑向第二半，试图做出一套全自动的执行引擎。但现实是：**只要上游还需要你肉身去盯监控、看录像、手写 issue，你的软件工厂就依然是一家纯手工小作坊。**

Pierson Marks 做软件工厂时最聪明的做法，就是拿 Issue Tracker（比如 Linear 或 GitHub Issues）在中间切了一刀，把两半彻底分开。

## 入口没活，先建“找活儿”的那一半

如果你的 backlog 经常见底，就先别碰任何自动化写代码的逻辑。先建输入端。

输入端的核心，是让 AI 替你盯住那些平时根本懒得看的数据源，自动产出带有“第一现场”的高质量 issue：

-   **日志巡检**：每天凌晨定时扫一遍 Sentry 和网关日志，发现未捕获异常直接开 issue，自动附带调用堆栈和发生频次。
-   **行为回放（Session Replay）**：扫一遍用户的操作录像。录像里能清楚看到用户在哪个按钮连续点击（Rage Click）、在哪一步卡住退出。录像一直都在，只是人肉不可能每天看几百条。
-   **流失分析**：拉取过去 24 小时点击退订的用户数据、退订前的操作链路，分析他是踩了 bug、用量未达预期，还是核心体验受阻，直接生成具体的改进建议。

这种 issue 产出来，天然带着复现路径、报错堆栈和用户上下文。“用户在定价页点击结账 3 次无响应”比“优化定价页”有用得多，因为 Agent 接到手就知道该去看哪段交互。

哪怕后半段完全由你自己手动改代码，你也等于雇了一个每天 24 小时替你看数据、提明确需求的产品经理。

## 干活的那一半：放权的单位是一张标签

当上游源源不断产生高质量 issue 后，实现侧的触发链反而极短。

不需要复杂的权限系统和流水线总控台，人机协作的边界可以收敛成一个动作：**打标签**。

1.  **默认状态**：上游巡检开出的 issue，默认不打 `auto` 标签。
2.  **人工介入**：人扫一眼 issue 列表，确认问题真实、复现路径明确，顺手打上 `auto` 标签。
3.  **Agent 动工**：Webhook 捕获到标签变更，自动拉起远程 Agent，读 issue、改代码、跑浏览器验证、提 PR。

![issue 打上 auto 标签后触发 agent 开 PR](https://xingkaixin.me/posts/images/one-person-software-factory/one-person-software-factory-02.webp)

这一设计的精妙之处在于**渐进式交权**：

你不需要在“全人工”和“全自动黑盒”之间二选一。刚开始，所有人肉审核打标；等某个巡检（比如明确的 Sentry 报警、前端格式修复）运行稳定了，就允许它自己打上 `auto` 标签实现全自动闭环。哪天发现它开始瞎提 PR，收回自动打标的权限即可。

**放权不需要给整条流水线装总开关，一张标签就够了。**

## 半个工厂就值得建

回头看白板上那张大图，最大的误区在于预设了“必须一次性做完整套闭环”。

真正的做法是按瓶颈分步走：

-   如果你的 backlog 经常见底，今天就挑一个数据源——错误日志、客服对话或退订记录，写一个定时 Prompt 抓问题提 issue，实现侧继续人工做；
-   如果你的 backlog 已经堆满，顺序就反过来：先配一个 Webhook，给打上 `auto` 标签的 issue 自动触发 Agent 改代码，别再让上游造更多待办。

先用 issue tracker 把两半切开，再去自动化真正卡住你的那半个工厂。

* * *

这里专注拆解一人软件工厂与工程自动化的落地细节。后面我会持续记录输入端自动化、打标签渐进放权，以及如何用最小的系统复杂度搭建一人流水线。欢迎关注。

## 版权声明

作者

XingKaiXin

标题

软件工厂建不动：你缺的不是 Agent，是提 Issue 的人

发布时间

2026年9月4日

文章链接

[https://xingkaixin.me/posts/one-person-software-factory/](https://xingkaixin.me/posts/one-person-software-factory/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

导览

展开导览