Conveyor：用「软件工厂」管理 AI 编码智能体

随着大模型生成代码的成本持续降低，开发团队面临的瓶颈已从「写得出」转向「看得懂、改得动」。当多个 AI 智能体并行提交改动时，单个工程师已无法逐行阅读所有产出，传统的 code review 流程也难以跟上节奏。Show HN 上的开源项目 Conveyor 给出的应对方案，是把智能体的产出搬上一条类似制造业的流水线，用文档、任务、评审和测试证据构成可追溯的知识图谱。

把 AI 编码当作「软件工厂」来运营

Conveyor 的核心比喻是 software factory：工厂不逐颗检查螺丝，而是在可能出错的关键工序设置检验点，并让每一件产品都可回溯到上游零件。它把这一思路映射到代码生产：

工作来源是「需求（Requirements）」、「系统设计（System Design）」与「决策记录（Decision）」三类文档；
人类操作员确认这些文档，必要时审批智能体给出的执行计划；
运行在本地机器上的智能体（如 Codex、Claude 等）按任务计划、实现代码并互相 review。

Conveyor 项目本身自 2026 年 7 月起就用这套流程开发自身，体现了「自举」的工程思路。

知识图谱：把每一次改动链接到意图

Conveyor 的关键设计是一张将「意图」与「实现」对齐的知识图谱：

每个任务（Task）由确认过的需求和设计文档驱动，产出一个具体改动（Delivered change）；
系统会比对改动与意图的差异，同时把仓库的实际状态（Observed repository）纳入对照；
一旦发现不一致，Conveyor 会发出信号（Signal），由操作员裁定是误判还是发起后续工单；
仓库漂移（drift）和合并后失败也会触发同样的信号机制。

Conveyor 不会自行改写代码或文档，所有纠偏动作都需要人类在工单中显式批准。

架构与部署方式

Conveyor 由两个 Go 二进制组成：

conveyord：服务端进程，提供 REST API、仪表盘、事件日志，依赖 PostgreSQL 15+ 存储事件、文档、链路投影与 River 队列；
conveyor worker：部署在开发者本机的守护进程，调用本地已有的智能体 CLI（沿用用户自己的认证凭据），并通过 Git worktree 管理仓库与 PR。

前端是一个 React 仪表盘，智能体则通过 MCP（Model Context Protocol）工作单接口领取任务、提交计划并完成 review。

部署要求比较克制：

一台运行 PostgreSQL 15+ 的工厂主机；
本机具备 Git、已认证的 gh CLI；
一个 OpenAI 兼容模型端点的 API Key；
想使用的智能体 CLI（如 Codex、Claude 等）。

官方提供一条 curl 安装命令，会在替换二进制前校验发布版本的 checksum，无需 sudo。文档中分别覆盖了单机版与多人协作版的搭建流程。

现状、许可与适用场景

Conveyor 仍在积极开发中，其事件日志会同时记录缺陷、修复工作和成功合并，便于事后复盘。项目以 MIT 协议开源，仓库地址为 github.com/kidus-tiliksew/conveyor。

对于已经在使用 AI 编码助手、又希望引入更结构化流程的小型团队或独立开发者，Conveyor 提供了一种「轻量工厂」的实践模板：通过文档驱动和人工在关键节点的把关，把越来越快的智能体产出纳入可治理、可追溯的软件工程体系。