Inside the Dark Factory: AI That Ships Code Solo
三句話摘要
Tessal如何用「暗工厂」（Dark Factory）让AI agents自主完成软件开发，解决代码审查瓶颈并大规模提升开发效率。 暗工厂的真正价值不在于生成速度，而在于把工程师从手动驱动转向系统思维——定义清晰的质量原则、编码进Verifiers、让agents替你扩展品味，最终达成可持续的大规模自动化开发。 从单人驱动到队列驱动的思维转变 — 之前工程师用local agent逐个完成ticket，现在要学会把工作分解成小任务、堆叠在队列中，让暗工厂周末无人值守运行。这不是代码生成变快，而是根本上改变了工作流。Rob提到"坏的周五是没为周末准备足够的工作"，说明思维方式完全反转。
重點整理
重點- 1
从单人驱动到队列驱动的思维转变 — 之前工程师用local agent逐个完成ticket，现在要学会把工作分解成小任务、堆叠在队列中，让暗工厂周末无人值守运行。这不是代码生成变快，而是根本上改变了工作流。Rob提到"坏的周五是没为周末准备足够的工作"，说明思维方式完全反转。
- 2
Verifiers成为信任的基础 — 单靠CI和人工审查无法处理95%无人看过的代码。他们创新性地用自然语言描述验证规则（如"这个文件只能从library导入"），由LLM判断是否符合，成本低且可被持续改进。这相当于把senior工程师的品味编码进去，让所有agents自动遵守。
- 3
失败即学习：从60个PR churn到形式验证 — 早期PR comment重复导致队列混乱，两周内发了60个fix PR反复失败。最后用一天时间和Fable建立了队列的形式验证模型，彻底解决问题。这说明代理系统需要比人工更严格的验证，不能依赖"隐性上下文"。
- 4
采用路径必须是渐进式的 — 从改进repo context开始，再加测试和verifiers，最后才部署完整的dark factory。信任是赚取的，不是启用的。新人需要对"agents是新的工作模式"有思维转变，不能只看做加速，要看做根本改变工程实践。
實用技巧與重點
乾貨- 数据指标
- 周末150 PRs（仅2人，无需值守，完全auto merge）
- 一周516 PRs，另一周608 PRs
- 整体：65-70% PR来自暗工厂
- 生产代码：40% PR来自暗工厂（全部需人工审查）
- 暗工厂自身代码：95% 无人审查（全部auto merge）
- PR审查通过率：仅5%的暗工厂代码曾被人工批准
- 核心工具与组件
- 编排器（Orchestrator）：连接Linear和GitHub的Python队列
- Coding agents：运行在Daytona sandbox（隔离、安全、支持完整测试）
- 审查agents：CodeRabbit + 内部review agents（3套skills：安全、可读性、功能正确性）
- Tessal CLI工具集：change-review、change-verify（Verifiers）、change-risk
- 暗工厂内部名称：Gikimora
- 验证机制三层
- 确定性linting规则（最便宜，无LLM成本）
- Verifiers（LLM作为判断，仅在diff上验证单个概念）
- 通用代码审查agents（最后的catch-all）
- 工作流程
- 在Linear中新建ticket，标记项目和优先级
- 标记为"to do"时，暗工厂自动拾取
- Agent在沙箱中完整执行：checkout代码 → 实现 → 本地测试 → 截图/视频上传
- PR创建后，CodeRabbit和内部审查agents并行检查
- CI失败或agents发现问题 → 重新唤醒agent自动修复
- 如标记auto-merge → 所有检查通过后自动merge
- 如需人工审查 → 在PR surface上评论（agent可响应）
- 早期故障案例
- PR comment重复计数导致队列重复执行（60个fix PR无效循环）
- 标签路由验证缺失（unit test有，end-to-end test没有）
- Elixir重写尝试：验证层不完整，生产环境变更未支持
- 采用建议
- 第一步：改进repo context（文档、架构说明、最佳实践指南）
- 第二步：写完整的测试（单元、集成、端到端、行为测试）
- 第三步：引入Verifiers编码品味和架构原则
- 第四步：考虑完整的dark factory自动化
結論
結論“暗工厂的真正价值不在于生成速度，而在于把工程师从手动驱动转向系统思维——定义清晰的质量原则、编码进Verifiers、让agents替你扩展品味，最终达成可持续的大规模自动化开发。”
完整解析
詳細Tessal的故事开始于一个尖锐的问题：当代码生成变便宜后，真正的瓶颈在哪里？Rob Willoughby的团队早年用local agents加速编码，但很快发现人工代码审查成了新的瓶颈——一个工程师一天能生成20个PR，整个团队就要花一整天审查这20个PR，然后审查者自己也要生成PR，形成恶性循环。最糟的是，没人真正理解所有这些代码在做什么。
为了解决这个问题，他们构建了暗工厂——一个将Linear ticket自动转化为完整PR的系统。核心思想很简单：用编排器（orchestrator）监听Linear中标记为"to do"的ticket，启动一个编码agent在隔离的Daytona沙箱中工作。这个agent能做真实工程师能做的一切：完整编译测试、启动UI、截图验证。关键创新是他们没有试图让一个agent一次性完美完成，而是建立了一个反馈循环：agent推送PR后，CodeRabbit和内部的三个审查agents（分别关注安全、可读性、功能正确性）同时运行，发现问题就自动重新唤醒agent修复。
最有趣的部分是Verifiers——他们将工程团队多年积累的品味和原则编码成自然语言规则。比如"这个库文件不应该导入其他模块代码"这种难以用正则表达式表达的架构约束，就用一句人类可读的描述，由LLM判断是否符合。每晚系统自动检查人工审查发现的问题，有可能变成Verifier的就提升为CI规则——这相当于把品味审查成本从"每个PR手工检查"降到"自动验证"。
但信任不是免费的。他们遇到过灾难性故障：PR comment重复计数导致同一ticket被多个agent并行处理，产生race condition，整个队列陷入混乱。解决方案是用一天时间和Fable建立了队列的形式验证模型——这在人工时代根本不值得投资，但在agent时代成了必需品。他们还尝试了大胆的实验：只用Verifiers和集成测试（没有单元测试），让Elixir agent从头重写整个队列系统，结果失败了，因为太多边角case只在单元测试中验证，没被end-to-end测试覆盖。这给了他们重要启示：自动化系统需要比人工系统更严格的验证。
如今Tessal每周生成500多个PR，其中65-70%来自暗工厂。生产代码要求人工审查，但暗工厂自身的代码95%无人看过。Rob坦诚这让他有时会惊讶于某些改变如何进入了系统，但他们的哲学是"向前修复而不是回滚"——找出验证缺口，加入Verifier或测试，让系统变得更聪明。对其他公司的建议是不要试图一步到位，而是从改进context、完善测试、引入Verifiers开始，逐层积累信任，最后才考虑完整自动化。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
