一个想法进，一个产品出：人不在环内的 AI 软件公司

系列：Idea-to-Production · 实践篇。同系列还有《人不在环内》《十三个阶段与它们的工件》《文档即可执行资产》。

一个人类只提供想法，系统把它交付到生产——组织图、运行手册、审计轨迹全在 git 里。从一条人写的任务开始，经过需求、架构、实现、测试、发布，直到产品上线并被循环照看，全程没有任何一步在等人类批准。

为什么值得看

每个"AI 帮我写 App"的演示都停在同一个地方：人还在开车。总得有人评审 PR、点部署、写发布说明、半夜看错误日志。真正有意思的问题不是"Agent 能不能写一个函数"，而是一整个交付组织能不能无人值守地运转。

我们的答案一句话：人提供想法，系统交付到生产，人不在环内。 本文不讲模型选型和提示词技巧，只讲动机、最难的那个坑、让它成立的架构，并附循环运转中的真实界面。

你将学到三点

1. 用机器关卡替代审批关卡。
    等人签字的环不是自主环。质量要靠自动检查点执行：逐交付物评审、集成面评审门、端到端测试——而不是靠会议。
2. 任务派发分两棒，切在工件边界上。
    需求产出后派发设计类任务；实现计划产出后，才派发构建、测试、发布类任务——每条任务出生即自足可执行。
3. 绝不让 Agent 自己排班。
    谁自己续命下一次触发，谁就在重复产出。周期性工作的所有权在中心调度器，它只推给恰好一个在线实例。

动机：把人从环里请出去

起点是一人公司之梦：创始人只做战略，其余一切——规划、架构、设计、工程、QA、发布、运营、增长、治理——是真的被完成，而不是被"辅助"。

"人不在环内"是精确主张，不是营销话术，因为它逼你解决三件半自动系统永远不必解决的事：

• 没人签字。
   没有 PRD 审批、没有发布 go/no-go、没有人工回滚决策。质量要么机器可执行，要么不存在。
• 没人解卡。
   通知人类只是升级路径——记录并通知，然后继续或干净停止，从不等待回复。
• 没人盯管线。
   所以系统自备审计轨迹和健康报告；可观测性是设计输入，不是事后补丁。

人的岗位随之上移一层：在系统之上读治理报告、改进背后的 Agent、技能、工作流与知识，而不是在系统之内当逐任务的闸门。

最大的挑战：Agent 会逐字执行文档

阶段之间的交接物是文档，而 Agent 会把文档逐字执行——包括其中的歧义："加个基础鉴权"会变成一场幻觉出来的子系统；文档里的一个 TODO 一定会被下游 Agent 执行，那是会跑的废代码；同一规则两处表述略有不同就会无声分叉。

对策沉淀成四条不容协商的不变式：

通用教训：把文档当代码对待——它们有类型化接口、会藏 bug，而且真有人一周 7 天、一天 24 小时在生产环境里运行它们。

它是怎么工作的

系统按变化速度和所有权切成三个仓库：

知识层说"下一步做什么"，调度层说"哪个实例、什么时候、且只有一个工人去做"，档案层存"做出了什么"。

创始人坐在战略位，之上是九个专职角色 Agent：产品与项目管理、工程架构、全栈工程、UI/UX 与文案、QA 与发布、服务与数据运营、市场与增长、行政与财务，外加平台侧看门狗哨兵。每角色一个或多个工作实例，按角色绑定 Agent、技能、工作流与知识库（符号链接，绝不复制），接哪家 AI CLI 由你配置。

工作沿 A–M 共十三个阶段流动：需求 → 架构与 UI 设计（并行）→ 详细设计 → 测试策略 → 实现规划 → 仓库脚手架 → 实现 → 端到端测试 → 发布 → 运营与增长报告。没有人类在场，靠逐交付物评审检查点（没有子代理评审 PASS 就不算 Done）与发布评审门（BLOCK 直接阻断实现到测试的转移）让循环保持诚实。

人类只写一条任务，项目管理 Agent 分两棒派发其余一切：

人类 ──► [阶段 A 任务] ──► requirement.md                                  │                     ┌── 第一棒：派发设计与脚手架 ──┐                     │   B ∥ C → D → E → H → F      │                     └──────────────┬────────────────┘                                    │ plan.md + 仓库骨架就绪                     ┌── 第二棒（带依赖） ───────────┐                     │  I 实现任务（按特性，来自 plan.md）│                     │  J E2E 任务（按特性，Depends On I）│                     │  K 发布任务（Depends On I + J）    │                     └──────────────┬────────────────┘                                    ▼                             终端用户（生产环境） 

实现任务在 plan.md 存在之前根本无法有意义地撰写，所以派发切在 requirement.md / plan.md 的工件边界上——每条任务出生即自足。每个特性的 E2E 任务在该特性真实 UI 完成的那一刻解锁，QA 从不需要等整个应用构建完。

发布不是终点：Initial Launch 之后，常驻循环接管，全部由中心推送，没有一个自己续命：

客户第 3 天报的 bug，随第 15 天的发布上线。issue 关闭是两阶段的：修复提交只打 fix-applied 标签，真正关闭发生在携带该修复的发布完成时——客户永远不会被告知一个还下载不到的"已修复"。

界面实拍：概念落到运行系统里

准备阶段是每台工作站的一次性投入：建实例、绑资源、注册启动，之后舰队按角色自行领活。

人类的全部贡献只有两屏：先创建项目——

再写那条唯一的"想法转需求"任务：

从此看板自己长满——

你可以旁观一个 Agent 的工作现场，实时的工具调用与进程状态：

落地后自动给出运行摘要——耗时、写入文件、最终报告：

控制中心仪表盘一眼看清循环现状——任务按状态与角色分布、在线实例、今日过期锁：

最后一段流程动画，完整回放第一跳"想法到需求"的端到端过程：

取舍与诚实的边界

• 自主比人工团队要求更强的质量机器。
   每删一道人类关卡，就必须原样长出一道机器检查。关卡弱而自主性强，等于以机器速度放大错误。
• 阶段之间用文档工件交接，而不是代码 API。
   换来整个"公司"可检视、客户端无关；代价是文档即可执行资产的纪律必须一直在线。
• 升级通道存在，但被刻意削去了权力。
   缺凭证或判定标准真歧义时通知人类，然后按文档分支继续或停止——环从不阻塞等回复。这是哲学选择：交付的可用性优先于每个决定的确定性。
• "跑通"的定义是一条完整闭环，不是逐项目证明。
   一个真实项目全程无人值守走完一遍，即可认证整个模式。你的技术栈与团队规模上，效果因人而异。

总结

1. 把人请出环不是目的，是逼迫器。
    没人可签字之后，质量被迫机器化、排班被迫中心化、观测被迫内置化——这三样才是真正赚到的东西。
2. 最值得直接搬走的原则是"文档即可执行资产"。
    当 Agent 逐字消费你的规格，歧义就是生产缺陷——给文档一个类型化接口，把漂移当 bug 修。
3. 该问自己的问题
   ：哪一个人类动作，如果写得好，能让整条管线从它生长出来？先把它之后的派发自动化，再在今天停下来等批准的位置逐一补上机器关卡。

你的工作流里，哪个环节还在等人工批准？欢迎评论区聊聊。