### [Codex No.1教程:喝茶聊天谈合同，最速项目一天交付，代码称斤时代已经到来](https://dashen.wang/article/319) **Published:** 2026-09-05T08:46:02 **Author:** 大神 **Excerpt:** 不是安装 Codex 然后等它写代码。人握住目标和最后的控制，合同被收成能验收、能恢复的交付。 > 这不是一篇“安装 Codex、输入提示词、等待它写代码”的入门文章。 > 这是一套已经在真实软件接管、并发开发、自动测试、客户交付和系统自举中使用过的方法：人类掌握目标与最终控制权，Codex 负责架构、调度和收口，多家 CLI 按能力与额度协同，合同与原始素材被编译成任务图、验收标准和可恢复的软件交付链。 **写这篇文章的起因是，我要去做其他事情了。** **而且你也不一定选Codex做主脑（猪脑）** **怎么便宜怎么来。** **我的蜂群上线已经到了4096,还算是浪漫的数字吧。** **未来就是不死鸟。** 说了不写教程真的是打自己的脸蛋啊。🧐 主要要点流量，最近要搞搞宣发。 ![图像](https://i.dashen.wang/wp-content/uploads/2026/10/x-inline-5271d58d69ab9fb4c43a.webp) > **Codex No.1教程：别再把 Codex 当聊天框，用蜂群OS把合同、素材和多 CLI 编译成一支高速 AI 开发团队** ## 一、为什么市面上大多数 Codex 教程还停留在“玩具阶段” 最近关于 Codex 的教程越来越多，但大量内容仍然围绕几个初级动作：安装 CLI、选择模型、写一段很长的 Prompt、接入几个 MCP、让 Agent 修改一个文件，然后展示一句“测试通过”。 这些内容不能说错，但它们回答的只是“一个 AI 能不能帮我写代码”，没有回答真正进入生产后必然出现的问题： - 一个项目有几十个任务时，谁决定先做什么？ - Codex、Claude、Kimi、GLM 等多个 CLI 同时可用时，谁应该接单？ - 某个模型额度不足、登录失效或者响应变慢时，任务怎样换人但不降级？ - 多个 Agent 同时写代码，怎样避免相互覆盖？ - 聊天窗口关闭、电脑重启或某个 CLI 崩溃后，任务怎样恢复？ - Agent 说“完成了”，它到底完成的是代码、测试、部署，还是客户真的能用？ - AI 开发 AI 自己时，怎样避免候选版本把唯一稳定版本一起弄坏？ - 合同、访谈、客户素材、旧系统和数据库，怎样进入工程，而不是沦为 Prompt 附件？ 真正的分水岭，不是你会不会写提示词，而是你有没有一套“Agent 可以读取、执行、验证和恢复”的工程环境。 OpenAI 在介绍 Codex App 时已经把方向说得很明确：开发正在从“和单个编码 Agent 配对”，转向“监督多个 Agent 完成设计、开发、发布和维护的全生命周期”，并且使用独立 Worktree 让多个 Agent 在同一仓库并行工作而不相互冲突。[OpenAI 对 Codex App 与多 Agent Worktree 的说明](https://openai.com/index/introducing-the-codex-app/) OpenAI 后来把这种工作称为 Harness Engineering：工程师的核心工作不再只是亲手写每一行代码，而是设计环境、表达意图、构造反馈循环，让 Agent 能可靠地完成工作。[OpenAI：Harness engineering](https://openai.com/index/harness-engineering/) 蜂群OS的出发点与此一致，但再往前一步： > 不把 Codex 当成一个更聪明的代码补全工具，而把它当成 AI 开发组织的主入口；不把其他模型当成聊天备胎，而把它们当成需要入职考试、权限、额度、岗位和验收记录的工程成员。 本文所谓“Codex No.1”，不是宣称某个模型永远占据排行榜第一。模型排名会变化，价格会变化，额度会变化，入口也会变化。这里的 No.1 指的是一条第一原则： > **人类控制目标，系统控制流程，模型负责执行，证据决定完成。** ## 二、蜂群OS到底是什么：不是模型套壳，而是一家可执行的 AI 公司 蜂群OS（SwarmOS）是一层位于人类目标和各类 AI 执行器之间的开发操作系统。它的兼容内核可以叫 DeliveryOS，团队内部可以叫 Agent 军团，但其逻辑只有一套： text ```text 人类蜂王主脑 │ 目标、边界、最终批准 ▼ 蜂群OS 控制面 │ 项目、任务图、身份、策略、Session、事件、证据 ├───────────────┐ ▼ ▼ 质量路由器 耐久调度器 能力/质量/额度 队列/重试/恢复 └───────┬───────┘ ▼ 本机或远程 Worker │ Codex / Claude / Kimi / GLM / 其他合格 CLI │ ▼ Worktree → 测试 → 审查 → 候选版本 → 交付证据 ``` 这里有四个经常被混淆的身份。 第一，人类是唯一蜂王主脑。人类决定业务目标、资金动作、最终风险接受程度和版本晋级。AI 可以处理大量日常事务，但不能把“安装了一个插件”解释为“获得了全局治理权”。 第二，蜂群OS Core 是控制面。它保存项目、任务依赖、运行状态、权限、派单结果和证据。这些状态不能只活在某个聊天窗口里，否则换一个平台、关掉一个会话，整个团队就失忆。 第三，Worker 是执行节点。它可以是当前电脑、另一台工作站、服务器，也可以是未来接入的临时算力节点。Worker 只执行获批任务，不拥有全局调度权。 第四，CLI 是可替换的员工入口。Codex、Claude、Kimi、GLM 或其他模型渠道都只是适配器。它们使用设备所有者自己的账号、登录和额度；蜂群身份凭据只负责证明“谁有权接什么任务”，绝不能复制或冒充模型账号。 这一区分极其重要。没有它，多 Agent 系统很容易变成一堆脚本互相调用：任何脚本都能改策略，任何节点都能发任务，任何模型都能自称审查通过。看起来热闹，实际上没有组织。 ## 三、AGENTS.md 不是提示词，而是这家 AI 公司的工程宪法 很多人把 AGENTS.md 理解成“告诉 Codex 代码风格的地方”。这只用了它很小的一部分价值。官方资料也建议用 AGENTS.md 给 Codex 持续提供仓库级上下文，例如代码组织方式、测试方法和工程约定。[OpenAI：Codex 与 AGENTS.md](https://openai.com/index/introducing-codex/) 在蜂群工程里，AGENTS.md 应该承担四层职责。 ### 1\. 身份层：谁能决定什么 markdown ```markdown - 用户是唯一 controller，拥有项目创建、Worker 批准和版本晋级权。 - worker 只能执行被分配的任务并回传证据。 - standalone 只能管理本机范围，不能自动加入全局蜂群。 ``` 这不是“建议”，而是运行时权限合同。界面隐藏按钮不算权限控制，API、MCP 和 Core 必须真正拒绝越权请求。 ### 2\. 行为层：哪些事情自动做，哪些事情必须停下 好的 Agent 团队不应该每三分钟问一次“我可以继续吗”。普通安装、依赖修复、测试、进程重启和候选部署，应当在明确范围内自主完成。真正需要人类确认的是付款、整机重启、整机关机、不可逆数据删除、正式版本晋级等少数动作。 授权边界越清楚，Agent 越快。模糊的权限不会带来安全，只会带来两种坏结果：要么 Agent 什么都问，团队失去速度；要么 Agent 自己猜，风险反而更大。 ### 3\. 工程层：怎么写、怎么并行、怎么验证 markdown ```markdown - 写任务必须拥有唯一文件范围。 - 多个写入型 Agent 默认使用独立分支与独立 Worktree。 - 一个提交只包含一个可解释、可验证、可回退的变化。 - “进程启动”不等于“功能完成”；必须验证真实用户入口。 - 不覆盖唯一稳定版本，候选版本单独安装和验收。 ``` 这里最关键的不是“写 TypeScript 还是 Python”，而是把并发边界写清楚。真正的并行不是让四个模型一起改同一个文件，而是把任务拆成互不重叠的所有权：一个负责数据面，一个负责 API，一个负责前端，一个负责部署，一个只读审查。 ### 4\. 记忆层：让错误变成下一次的能力 每次失败都必须留下可复用记录：症状、根因、无效尝试、最小解法、验证方法、回滚方式和防复发动作。否则同一个团队只是拥有很多上下文很长、但每天都会失忆的聊天机器人。 因此，一个成熟仓库至少应该有这些事实源： text ```text AGENTS.md 全局治理与工程规则 README.md 管理入口 catalog.yaml 资产索引 projects//PROJECT 项目定义 projects//TASK-GRAPH 可执行任务图 projects//LEDGER 时间、成本、错误、证据账本 members/ 设备、服务、模型、插件档案 runbooks/ 可重复操作方法 logs/ 已发生事件 evidence/ 测试与验收结果 ``` ## 四、最快的 AI 开发，不是从 Prompt 开始，而是把现实“编译”成工程 软件项目最原始的输入，通常根本不是代码。它可能是一份合同、四个压缩包、一堆截图、客户语音、旧数据库、产品原型、历史聊天记录，以及一句“帮我尽快上线”。 普通做法是把这些材料扔进模型，让它总结需求。蜂群方法不是“总结”，而是“编译”。 为什么要用编译这个词？因为编译有源文件、有中间表示、有类型检查、有错误、有目标产物。原始合同不能在模型总结之后消失；模型的推断不能伪装成客户事实；模糊条款必须成为待决问题；每一项交付要求必须能追到验收动作。 完整链路如下： text ```text 合同 / 原始素材 / 旧系统 / 客户访谈 │ ▼ 第一层：原件保全 哈希、只读副本、版本、来源、时间、缺失项 │ ▼ 第二层：事实抽取 角色、业务对象、流程、接口、数据、非功能约束 │ ▼ 第三层：交付定义卡 本期做什么、不做什么、什么叫可演示、什么叫可交付 │ ▼ 第四层：验收 Oracle 可重复执行的业务、权限、性能、恢复和客户体验判定 │ ▼ 第五层：任务 DAG 依赖、Owner、能力角色、写入范围、输入、输出、失败条件 │ ▼ 第六层：Agent 执行与证据回写 Session、Worktree、提交、测试、部署、日志、成本 ``` ### 原件保全：先确保 AI 没有“理解错后毁掉证据” 接管旧项目时，不要先运行格式化，不要先删除“看起来没用”的文件，更不要为了 Git 状态漂亮直接清理现场。应该先记录： - 原始包和关键归档的 SHA-256； - Git Bundle 或仓库历史是否完整； - 未提交、已删除、未跟踪内容； - 数据库和容器卷是否可恢复； - 原平台实际入口与运行版本； - 哪些数据源才是业务权威。 AI 时代最昂贵的错误，经常不是代码写错，而是把唯一原件覆盖后，所有 Agent 都在错误事实之上高速前进。 ### 交付定义卡：把“做完”变成类型，而不是情绪 一个项目至少要区分四种状态： 1. code-complete：代码已实现，局部测试通过； 2. integrated：与主链合并，回归通过； 3. preview：真实入口可访问，目标角色能操作； 4. deliverable：备份恢复、迁移、客户文档、公网入口和最终验收全部完成。 很多 AI Demo 的问题，是把第一个状态叫成第四个状态。页面打开了，就说系统交付了；接口返回 200，就说业务闭环了；容器在运行，就说部署成功了。 蜂群OS要求每个状态都有证据，状态不能靠 Agent 的语气推进。 ### 验收 Oracle：在写代码之前定义“机器如何判案” Oracle 不是一句“请确保质量良好”，而是可执行判定。例如： yaml ```yaml task: appointment-concurrency input: appointment_id: seeded-fixture-01 action: concurrent_requests: 2 expected: success_count: 1 conflict_count: 1 audit_records: 1 final_status: confirmed ``` 当两个请求同时修改一个预约时，究竟应该发生什么？如果这个问题没在任务开始前说清楚，两个模型可能分别写出“看起来合理”的实现，而集成时才发现业务语义冲突。 ## 五、任务图：把“帮我做完项目”变成可以并行的依赖网络 大目标不能直接平均切成四份。任务图必须先找依赖，再找可以并行的边界。 yaml ```yaml waves: - id: W0 name: 事实冻结 tasks: - id: contracts mode: readonly outputs: [业务合同, 角色矩阵, 数据字典] - id: W1 name: 基础内核 depends_on: [W0] tasks: - id: api-kernel write_scope: [apps/api/**] - id: plugin-sdk write_scope: [packages/plugin-sdk/**] - id: W2 name: 领域并行 depends_on: [W1] tasks: - id: health-domain write_scope: [domains/health/**] - id: finance-domain write_scope: [domains/finance/**] - id: report-ai write_scope: [domains/reports/**] - id: W3 name: 集成与交付 depends_on: [W2] ``` 一个任务节点至少包含：目标、依赖、角色、读写模式、唯一写入范围、输入版本、输出、测试、超时、重试、回退、成本影响和证据位置。 模型名称不应该成为业务合同。任务写的是“需要通过后端并发角色实测的实现者”，而不是永远写死“必须某模型”。今天最强的模型，明天可能额度不足；今天失败的渠道，明天可能升级。供应商是路由层的决定，不是产品层的依赖。 ## 六、多 CLI、多模型调度：谁空闲、谁合格、谁有额度，谁上 “多模型协作”最容易被写成一张华丽的架构图：一个模型负责规划，一个模型负责代码，一个模型负责审查。问题是，现实中的渠道不是永远在线的。额度会重置，账号会掉登录，代理会波动，CLI 会升级，模型身份会漂移，某个擅长前端的模型也未必适合财务并发。 所以蜂群调度不能固定成一张供应商座位表，而要像生产调度系统一样，每次派单重新计算。 ### 第一道门：角色资格 模型必须先通过对应岗位的真实考试。例如： - implementation/frontend：能否理解现有设计系统、完成响应式页面、通过构建和浏览器测试； - implementation/backend：能否处理事务、幂等、状态机、并发和迁移； - review：能否找到可复现的问题，而不是只输出风格意见； - research：能否区分官方资料、二手线索和本机实测； - mechanical：能否稳定完成 Schema、格式、批量边界检查。 没有通过岗位实测的模型，即使便宜、空闲、额度很多，也不能接这个岗位。质量资格永远先于成本。 ### 第二道门：当前身份与健康 调度器要确认实际调用的模型是谁、CLI 版本是什么、登录是否有效、网络和代理路径是否可用、最近一次真实调用是否成功。配置文件写着“高级模型”不代表当前运行的就是它。 ### 第三道门：可信额度 “我感觉还有额度”不能用于自动派单。额度记录至少要包含： - 已使用和剩余比例； - 额度窗口与重置时间； - 官方数据、会话消耗还是本地估算； - 采集时间和是否过期； - 是否需要人工登录； - 保留线。 未知额度的渠道可以被人工点名做健康探测，但不能加入自动路由。某渠道达到保留线后停止接收新任务，保留给关键收口或用户直接使用。 ### 第四道门：空闲槽位与重复消费保护 同一个任务必须有稳定的幂等键。即使控制面超时，也要先查询后端是否已经接受，不能因为“没看到回复”就再派一次，导致两个模型同时写同一任务、消耗两份额度。 可以把路由逻辑简化为： python ```python eligible = [ worker for worker in workers if worker.role_certified(task.role) and worker.model_identity_verified and worker.login_healthy and worker.quota.is_fresh and worker.quota.above_reserve and worker.available_slots > 0 and task.provider_pool.allows(worker.provider) ] selected = rank(eligible, by=[quality, latency, cost, load]).first() ``` 这里最容易犯的错误是“显式指定模型就绕过其他规则”。正确语义应该是取交集：用户点名的 Provider 仍然必须属于项目允许池，仍然必须通过角色、额度、健康和权限门禁。空 Provider 池意味着禁止任何模型自动执行，不能因为请求里又写了一个模型名就把它重新塞回来。 ### 不平均分配，也不浪费已购买渠道 蜂群不是为了追求“每个模型今天都用一次”。平均分配看似公平，实际会把关键任务交给不合适的模型。正确目标是单位墙钟时间内的有效交付： - 合格、空闲、有可信额度的成员优先； - 多个合格者同时存在时，按质量、速度、成本和负载排序； - 某渠道需要反复弹网页登录，就标记为手动，不让它拖住后台队列； - 同一模型连续失败不无限重试，按预设 cascade 换人； - 实现和最终独立审查使用不同供应方； - 主脑模型也在规则内，不应把自己额度打空再让其他 CLI 闲置。 ## 七、连接层改用 Tailscale：让蜂群跨设备，但不把控制权交给网络 蜂群从单机扩展到工作站、服务器、手机和异地节点后，首先需要解决的是私有连接。目标不是“所有设备互相 ping 通”，而是让正确身份只能访问正确端口，并且节点更换网络后仍能被稳定发现。 蜂群OS下一版连接层采用 Tailscale，但必须明确两层身份不能混为一谈： text ```text Tailscale 身份：这台设备能否到达某个 IP/端口 SwarmOS 身份：这台设备能否接任务、改策略、批准 Worker、晋级版本 ``` Tailscale 负责加密网络、设备发现和网络访问策略；蜂群OS Core 仍负责 controller、worker、standalone 权限。一个节点能连接 Core，不等于它有权创建全局项目。 ### 推荐拓扑 text ```text Tailscale tailnet ┌──────────────────────────────────┐ │ │ 蜂王控制端 只读观察端 tag:swarm-controller tag:swarm-observer │ │ ├──── Core API / Event Stream ─────┤ │ ├──────────────┬──────────────┐ ▼ ▼ ▼ 开发工作站 GPU/模型节点 部署服务器 tag:swarm-worker tag:swarm-worker tag:swarm-prod ``` 新 tailnet 如果没有自定义访问策略，不能想当然地认为已经完成最小权限。Tailscale 当前推荐新配置使用 Grants；Grants 可以按用户、组、标签、目标和端口声明访问能力。[Tailscale：Grants](https://tailscale.com/docs/features/access-control/grants) 下面是概念示例，不是可直接复制到任何账号的生产配置： jsonc ```jsonc { "tagOwners": { "tag:swarm-controller": ["autogroup:admin"], "tag:swarm-worker": ["tag:swarm-controller"], "tag:swarm-observer": ["autogroup:admin"] }, "grants": [ { "src": ["tag:swarm-controller"], "dst": ["tag:swarm-worker"], "ip": ["tcp:22", "tcp:8890"] }, { "src": ["tag:swarm-worker"], "dst": ["tag:swarm-controller"], "ip": ["tcp:8890"] }, { "src": ["tag:swarm-observer"], "dst": ["tag:swarm-controller"], "ip": ["tcp:8890"] } ] } ``` 真实配置必须进一步区分“控制 API”“只读事件流”“部署入口”，不能让观察端因为能打开控制台就自动拥有修改权。 ### 节点入网方式 人工设备可以通过交互登录加入；服务器适合使用带标签的 Auth Key，临时容器或一次性 Worker 使用 Ephemeral Key。长期自动化不要把永不过期的密钥写进仓库，可以使用受限 OAuth Client 动态生成 Auth Key。Tailscale 的服务器部署指南也建议用标签约束服务器访问，并针对长期自动化使用 OAuth Client。[Tailscale：设置服务器](https://tailscale.com/kb/1245/set-up-servers) [Tailscale：OAuth Clients](https://tailscale.com/kb/1215/oauth-clients) 蜂群档案中只记录凭据引用、用途和恢复方法，不输出密钥本身。 ### 从现有连接迁移到 Tailscale 的正确顺序 不要一上来卸载旧网络。生产迁移使用双轨法： 1. 只读盘点现有节点、地址、服务、路由和防火墙； 2. 安装 Tailscale，但保留旧连接； 3. 给控制端、Worker、服务器分配清晰标签； 4. 写 Grants，并用策略测试验证允许与拒绝路径； 5. 让 Worker 通过 Tailscale 完成一次真实任务领取、执行、证据回传； 6. 模拟 CLI 失败、节点掉线和控制端重启，验证恢复； 7. 更新资产档案和 MagicDNS 名称，不把临时 IP 写死在项目里； 8. 观察稳定后再停止旧路径； 9. 回滚窗口结束后，旧网络才进入退役，而不是直接删除。 如果需要更强的节点加入保证，可以评估 Tailnet Lock，由受信节点签署新节点密钥；但它属于后续安全增强，不应在功能迁移的每一步反复打断开发。[Tailscale：Tailnet Lock](https://tailscale.com/docs/features/tailnet-lock) ## 八、Session、Worktree 和事件流：让并行开发可恢复，而不是靠聊天记忆 每次可恢复工作都必须拥有 Session ID。Session 不是聊天标题，而是一条工程记录： yaml ```yaml session_id: 20260902T150626Z-glm-xxxxxx team: fast-development task: report-data-plane provider: glm mode: write repo: health-platform branch: agent/swarm/... worktree: /isolated/worktrees/... write_scope: - apps/reporting/** started_at: ... status: running final_commit: null evidence: [] ``` 写入型 Agent 默认使用独立 Worktree。只读研究可以共享仓库，但不能写。每个文件范围只有一个 Owner；其他 Agent 可以审查该范围，却不能同时改它。 任务运行时，控制面追加事件： text ```text control/created control/approved control/dispatch_claimed control/dispatched-by-core control/observed running verification/command_started verification/command_completed control/observed succeeded ``` 为什么要追加事件，而不是只保存一个 status=succeeded？因为最终状态无法解释发生了什么。一个任务可能在后端已接受后网络超时，如果控制面误以为没派出去，又重新派一次，就会形成重复消费和并发写入。事件流让系统判断“从未接受”“已接受但确认未知”“Worker 已开始”“Worker 已结束”这些完全不同的状态。 更重要的是，进度终于可以给人看。用户不应该面对一个沉默七小时的黑箱。控制台至少要展示：当前波次、正在执行的任务、负责人、模型、Session、Worktree、开始时间、最近事件、测试进度、额度状态、阻塞原因和下一验收点。 ## 九、狗粮循环：蜂群OS必须先能安全地开发自己 狗粮循环不是一句“我们也使用自己的产品”。真正的自举必须让当前稳定版创建候选版，并且候选版不能覆盖唯一可用版本。 蜂群OS的发布链是： text ```text stable 稳定版 → 创建自举项目与任务图 → 独立 candidate Worktree → 合格且有额度的 CLI 实现 → 自动测试 → 异源 Provider 功能审查 → 独立安全审查阶段 → 插件清单与 Skill/MCP 验证 → 使用新 cachebuster 并行重装候选插件 → 干净新会话重新发现与真实调用 → 蜂王主脑批准晋级 → 新 stable ``` ### 为什么必须重新安装 源码通过测试，不代表用户实际加载的插件就是这份源码。插件缓存、版本号、Skill 发现和 MCP 配置都可能仍指向旧版本。因此候选必须使用新版本标识安装到独立缓存，并比较源码与安装产物；当前稳定缓存保留，出现问题可以恢复。 ### 为什么必须用干净新会话 当前聊天可能已经加载旧 Skill、旧工具清单和旧说明。只有新会话从零发现插件、识别蜂群身份、读取最新 AGENTS.md，并完成一次真实任务，才能证明“下一位用户真的拿到了新版本”。 ### 为什么安全审查放在功能完成之后 高速开发不等于没有安全。正确做法是阶段化：日常实现先完成业务功能和自动测试，项目功能收敛后再启动一次独立安全审查。这样安全审查面对的是稳定候选，不会在每个小步骤上重复检查尚未成形的代码。 只有三类事件允许中途紧急拦截：正在发生的凭据泄露、不可逆数据损失风险、权限越界。其余安全检查进入收尾阶段，由异源 Provider 或独立安全角色执行，开发者不能自我批准。 ### 一次真实自举暴露了什么 在蜂群OS自举测试中，曾出现一个很有代表性的竞态：调度后端已经接受任务，Worker 启动得非常快，抢在 Core 持久化标准执行对象之前进行了恢复。任务本身成功了，但发布门禁需要的“由 Core 确认派单”事件缺失。 如果只看最终状态，这个任务是绿色的；如果看事件链，它不具备可证明的主脑调度路径。 修复不是简单地“多等几秒”，而是同时建立三条规则： 1. Worker 给 Core 一个短暂的优先确认窗口； 2. Core 晚到时，只能对 attempt、claim、execution 和 idempotency key 完全一致的恢复结果做幂等确认； 3. 发布门禁必须绑定当前这一次 execution，旧尝试留下的成功事件不能替新任务过关。 另一次独立审查发现：项目已经明确给出空 Provider 池，但请求又显式指定模型时，路由器把该模型重新加入了候选。所有自动测试当时都通过，因为测试只覆盖了“空池+自动选择”，没有覆盖“空池+显式模型”。异源审查提出反例后，路由语义改为交集，并补上正反回归。 这就是狗粮循环的价值：不是为了证明系统永远不出错，而是强迫系统在开发自己时，把隐藏假设变成运行时规则和防复发测试。 ## 十、脱敏实战：某大健康 SaaS 如何把一天压缩成可交付 V1 下面的数据来自一个真实的大健康软件接管与交付项目。为保护客户和业务数据，项目名称、域名、账号、机器地址、仓库路径、患者信息、报告内容和凭据全部省略；保留的只有任务类型、时间跨度、测试数量和可验证结果。 ### 起点不是空仓库，而是约 4.5GB 的复杂现场 输入包括两套 Git 历史、多个容器卷归档、旧平台的未提交现场、ERP/医疗业务引擎，以及客户要求保留的原始资料。团队首先完成哈希校验和恢复演练，把正式 Git 开发工作区精简到约 86MB，同时保留原件、未跟踪交付物、已删除现场痕迹和原始数据卷。 这一步没有直接产生新页面，却决定了之后的所有高速开发是否可回滚。 ### 并发不是一句口号，而是十条独立 Session 开发队把任务拆为数据面、API、前端、AI 报告链、任务与预约、生产容器、独立审查和最终集成等边界，共留下 10 条可恢复 Session。Kimi、GLM、Claude 与 Codex 使用不同分支和 Worktree，Codex 主要承担架构、集成、关键修复和最终验收，而不是把批量编码全部压在一个渠道上。 已登记的第一条并发开发 Session 在当晚 23:06 启动。到次日 01:40，生产化前端入口、API 反向代理、容器健康检查和发布包更新已经形成提交：关键开发窗口的墙钟跨度约 **2 小时 34 分**。 到次日 12:30，专业 V1 最终提交形成：从第一条 Session 到最终提交的墙钟跨度约 **13 小时 24 分**。这个数字包含模型执行、集成、返工、容器构建和测试等待，不应解释为单个 Agent 连续编码 13 小时，也不等于从商业立项到客户签收只需 13 小时。它说明的是：当任务边界、环境和验收足够清楚后，一支多 CLI 团队可以把大量原本串行的工程工作压入同一夜和半天。 ### 真实速度不只看“写了多少代码” AI 报告链使用脱敏 PDF 和 JPG 进行真实端到端测试：上传、OCR、AI 结构化处理、医生审核发布、用户读取与提问、时间线回读全部跑通。桌面路径用时 **54.9 秒**，移动路径用时 **57.3 秒**。服务重启后，7 份已发布报告仍然存在。 这比“接口响应 200”更接近用户感知速度：一分钟内完成一条完整业务链，而且结果经过重启持久化验证。 ### 最终验收规模 专业 V1 收口时，机器证据包括： ![图像](https://i.dashen.wang/wp-content/uploads/2026/10/x-inline-14122105acbf7164fef3.webp) 此外还完成了财务开单、收款、应收结清和总账回读，库存入库、出库、盘点调整与流水回读，备份与隔离恢复演练，以及公网多角色登录与关键业务读取。 ### 独立审查为什么没有拖慢项目，反而节省返工 异源审查复现了预约状态转换的并发问题：两个并发请求可能同时成功并产生两条审计。实现者自己的常规测试没有暴露它。修复使用原子条件更新，并新增六项并发与边界回归。 这说明 review 的价值不是每做一步就让同一个人再看一遍，而是在功能和自动测试形成后，由不同模型主动构造反例。一次有效的异源审查，远比十次“代码看起来不错”的自我检查有价值。 ### 这个案例也暴露了流程损耗 真实项目并非完美演示。最大的时间浪费不在写代码，而在以下内容确定得太晚： - “Demo”“V1”“可交付”“客户可用”的口径不同； - 客户入口、账号和文档标题反复变更； - 开工前没有保存所有模型的额度基线，无法严谨计算项目净消耗； - 客户手册和验收脚本接近结尾才集中制作； - 身份库与业务权威数据源一度被混淆。 因此蜂群OS后来把交付定义卡、客户验收 Oracle、入口冻结点、四层成本账本和错误事件流提升为开工门禁。真实项目的意义，不是提供一个漂亮的成功故事，而是让下一次开发少走同样的弯路。 ## 十一、如何估算 AI 项目：别再只说“几个人天” 传统人日仍可用于商务沟通，但它不再是最准确的工程单位。蜂群项目应同时报告三种时间： 1. **机器执行时间**：所有 Agent、测试、构建累计消耗的时间； 2. **关键路径墙钟时间**：从开工到满足下一门禁的现实时间； 3. **外部等待时间**：登录、付款、平台审核、客户反馈、DNS 生效等非工程等待。 再分别给出 P50 和 P90。假设三条独立任务各需一小时，并行执行后机器时间是三小时，关键路径可能只有一小时；但如果最后必须等待一次人工批准，关键路径仍由批准时间决定。 AI 时代真正稀缺的资源往往不是生成 Token，而是人类注意力、清晰决策、可测试环境和可靠反馈。OpenAI 的公开工程实践也强调，随着 Agent 吞吐提高，人类 QA 会成为瓶颈，因此需要让 UI、日志、指标和测试本身对 Agent 可读。[OpenAI：Harness engineering](https://openai.com/index/harness-engineering/) ## 十二、一个团队如何从单个 Codex 升级为蜂群 不需要第一天就搭建完整平台。可以按四个阶段升级。 ### 阶段一：让单个 Codex 可预测 - 写一份简洁但强制的 AGENTS.md； - 固定真实测试命令； - 记录项目事实源； - 每个任务明确写入范围； - 要求结果附带验证证据。 ### 阶段二：让多个 Agent 可并行 - 为写任务创建独立 Worktree； - 定义文件 Owner； - 使用任务 DAG，而不是共享待办清单； - 把实现和审查分给不同 Agent； - 建立小而完整的提交规范。 ### 阶段三：让多个 CLI 可调度 - 为每个 CLI 建能力档案； - 做岗位实测，不照抄厂商宣传； - 接入官方额度、健康和登录状态； - 设置保留线、手动渠道和失败 cascade； - 用幂等键防止重复派单与重复消费。 ### 阶段四：让团队可跨设备、自举和发布 - 用 Tailscale 连接控制端与 Worker； - 网络标签与蜂群身份分层； - 状态离开聊天窗口，进入 Core 与事件存储； - 稳定版和候选版并存； - 建立完整狗粮循环； - 只有人类 controller 能批准晋级。 ## 十三、可以直接复制的项目开工清单 markdown ```markdown ## 目标 - 客户最终拿走什么？ - 哪些角色使用？ - 什么叫 code-complete / preview / deliverable？ ## 原始输入 - 原件路径与哈希 - 合同版本 - 权威数据源 - 已知缺失和冲突 ## 边界 - 本期明确包含 - 本期明确不包含 - 必须人工批准的动作 - 不可触碰的稳定资产 ## 任务图 - 依赖 - 能力角色 - 唯一写入范围 - Session / Branch / Worktree - 验收 Oracle ## 路由 - 合格 Provider 池 - 当前额度和采集时间 - 保留线 - 手动渠道 - 失败回退链 ## 发布 - 自动测试 - 异源功能审查 - 独立安全审查 - 候选安装 - 干净会话验收 - 回滚路径 - controller 晋级批准 ``` ## 最后：提示词会过时，工程闭环会复利 如果只是让 Codex 帮你改一个按钮，当然不需要蜂群OS。但当你开始接管真实项目、处理合同和原始数据、同时使用多个 CLI、连接多台设备、需要客户验收并且不能破坏稳定版本时，单个聊天窗口很快会到达极限。 这时真正决定速度的，不是再写一段更神奇的 Prompt，而是建立一套可读、可执行、可恢复、可验证的组织： - 合同和素材被编译成事实、任务和 Oracle； - AGENTS.md 把治理意图固化成工程宪法； - Tailscale 提供跨设备私有连接，蜂群身份继续控制业务权限； - 多 CLI 按能力、质量、额度、健康和空闲动态上岗； - Session、Worktree 和事件流让并行工作可恢复； - 自动测试决定功能事实，异源审查寻找反例； - 狗粮循环保证系统先能可靠地开发自己； - 最终版本只能由人类蜂王主脑晋级。 模型会越来越强，单次生成会越来越便宜。真正长期增值的，是你的合同编译器、任务图、测试 Oracle、错误知识库、模型能力档案和发布闭环。它们会让下一批 Agent 比上一批更快，让每次失败都变成团队资产。 这才是 Codex No.1 的含义：不是把一个模型捧上神坛，而是让 Codex 成为一支可管理、可替换、可证明的软件蜂群的第一入口。 ## 资料与数据口径 - Codex、Worktree、AGENTS.md 与 Harness Engineering 的产品方向，参考 OpenAI 官方公开资料；文中蜂群OS架构、路由、狗粮循环和项目流程来自实际工程实践。 - Tailscale 部分依据其官方 Grants、服务器部署、OAuth Client 和 Tailnet Lock 文档撰写；示例为目标架构，实际迁移必须在节点盘点、双轨验证和回滚准备后执行。 - 案例来自内部项目账本、Session 档案、Git 提交时间和验收日志。为了脱敏，删除了项目名、客户名、域名、账号、设备、路径、提交号、健康数据和凭据。 - “2 小时 34 分”和“13 小时 24 分”均为已登记 Session 启动时间到对应提交时间的墙钟跨度，不是单模型纯推理时间，也不用于推导传统团队必然需要多少人日。 来源：[https://x.com/dashen\_wang/article/2096157899554693239](https://x.com/dashen_wang/article/2096157899554693239) **Categories:** AI 实践 ---