douxian123/codex-autopilot

给 Codex 装一个总输入框。你把零散、即时的感受丢进去——「这里视觉不对」「这个流程别扭」「又冒出个 bug」——归类、排期、追踪、收口由它接手。你不用再想这条需求发哪个对话、开哪个分支。
> 你现在大概也这样：一个复杂项目要同时开几十个对话、几十个分支，每个对话结尾还都追问你「这个分支要不要合、等谁先合」。做了左边忘了右边，共享检出越来越脏，人成了整条链路里唯一被反复打断的那一环。Codex 自动挡要干掉的就是这一环：散需求只有一个入口，分支由它自己串行收口，真需要你拍板的只剩改方向、删数据、发布。
## 它是什么
Codex 自动挡是一层装在本机的项目编排，把「管一个复杂项目」从人脑搬到一本账和一组守护进程上，由 Codex 自己推进。
它分两层，职责不混：
1. 插件层（~/plugins/codex-autopilot/）：一个 skill + 一组 MCP 工具 + 一份自带的运行时代码（纯 Python 标准库）。运行时代码跟着插件走，所以插件升级后不会出现「skill 说支持新工具、实际跑的还是项目里那份旧脚本」。目标项目里不需要放运行时代码。
2. 账本层（你项目里的 ops/tasks/、ops/truth/、ops/context/、docs/）：唯一入口、问题台账、主线 / 决策 / 进展 / 验收。全是纯文本 + JSONL，可读、可 diff、可提交。
它不是新模型，不是新 IDE，也不改 Codex 二进制。用的全是 Codex 公开的扩展点（skill / MCP / plugin）。
它是 Codex 的自动挡。手动挡下，拆需求、分分支、盯合并、验收全靠你盯着；自动挡下这些交给编排层，只有改方向、删数据、发布这类事才停下来问你。
## 为什么做这个
今天用的 Agent 形态还很雏形，不是面向人交互的最优解。
模型侧，下一个突破普遍被说成 RSI——模型自己训练自己。工程侧对应的应该是 自追踪、自运行：AI 自己拆任务、自己分派、自己跟进、自己验收，把人的干预减到最少。
但现在的 coding agent（Codex 也一样）恰恰没做到。它要求你：自己把需求拆成一条条；自己决定每条发哪个对话、开哪个分支；自己盯每一条链路；每一步手动验收；再自己收拾散落在几十个对话和分支里的「左脚踩右脚」的合并。模型有能力处理这些，缺的是把它们串起来、闭环跑通的那层工程。
所以有一条第一性的要求：
> 不该让用户把需求发进各种各样的对话和分支，弄得支离破碎、左脚绊右脚。Codex 应该是一个万法归一的输入框，承接模糊需求，把它拆成最优解。
用户摸索时会不断冒出零散、即时的东西：视觉摸到的问题、体验和功能架构摸到的问题、bug 摸排查出的 bug。这些不该要求用户自己归类——归到哪个对话、新建哪个分支、派给哪个角色，应该由编排本身来做，给出统一的最优解，而不是让用户迁就那些分支。
顺着这个思路，一个复杂项目真正需要持续管的就四类东西：
产品主线：PRD、讨论与决策进展。
问题清单：bug、反馈、体验问题，自动归类、存档、追踪。
开发进展：最近一次干了什么，离主线还差多少。
验收清单：各模块 / 验收项的进度，以及需要你注意的项。
Codex Autopilot 就是把这四类收进一本账，让 Codex 自己推进。
## 它解决什么问题
一个人同时开几十个对话、几十个分支做复杂项目，效率不是被「写代码」吃掉的，是被这四件事吃掉的：
1. 输入碎：零散需求不知道发哪，随手开个对话，做了左边记不住右边。
2. 分支海：每条对话一个分支，谁跟谁能合、合了会不会互相覆盖，没人说得清。
3. 工作区脏：共享检出里叠着十几个任务的半成品，谁都不敢提交。
4. 人肉验收：每一步都要人 check，人成了瓶颈。
传统解法是写一沓规范（AGENTS.md、workflow 文档）。但规范不会自己动手：再多文字，也不会主动把一句「这里视觉坏了」记进台账、判断该进哪条泳道、在没有冲突时把它落进 main。这套东西把最贵的几个动作做成了命令和守护进程，而不是又一份文档。
## 做完之后自动回写
上面说的都是「输入怎么进来」。用户还有一半痛点在「事情做完之后没人记得、又得人肉把零散对话攒成 PRD」。这些回写补的是那一半：
产品状态：产品今天实际怎么工作。改到行为的会话在同一轮写进 ops/truth/productstate.json（truthctl product set），人验收只看它相对主线的变化，不读实现。
自验证：合入前逐条真跑配置里的验证门禁，把 命令 + cwd + 退出码 写进 acceptance.jsonl。没配门禁就标 todo，不伪造 verified——所以「已验证」永远对应一条能照着复核的证据。
判断逻辑蒸馏：每轮收口后回看人额外说了什么，只把「为什么这么判断」写进 judgments.jsonl（truthctl distill add）。记的是判断逻辑，不是一次性细节——下次换个地方也不用重新讲。
问题闭环：用户报的 bug / 视觉 / 体验 / 架构问题收进 ledger.jsonl 后，由 agent 推进修复 -> 验证 -> truthctl close " "。关闭时带 commit、证据，并自动追加一条进展；回归了用 truthctl open 重开。问题不会一直挂在 open，也不靠用户自己记。
自动实现需求（autoexec，默认关闭）：打开后，没关闭的台账条目会由自动挡在独立 worktree 里启动一个真实 codex exec 会话去实现；实现完显式提交，过 kgctl land 的同一道验证门禁后落盘，再自动 truthctl close 收口。每轮最多派一条；超时、门禁失败会保留分支和 worktree，不丢在途工作。它仍然遵守三条边界：不改产品方向、不删数据、不发布。
主线综合：每轮收口跑一次 truthctl synthesize，把决策 / 进展 / 问题 / 验收 / 产品状态综合成 docs/PRODUCTMAINLINE.md。产品讨论和零散需求自动长成产品叙事，人只读这一页就知道现状、最近在推什么、还差什么。
产品路线与验收分堆：mainline.json 里的 roadmap 记录产品预期怎么一步步走完；验收台账分出「需要人拍板」和「机器已自证」。人只需要看人工项，并照着 steps 复核，不用从实现和日志里倒推。
它们一起形成「做完 → 验证 → 收口 → 综合 → 蒸馏」的闭环：产品行为可 diff、验收可复核、问题可闭环、主线可综合、判断可累积。
## 怎么装
两步。在插件仓库里跑一次：
bash
# 1) 装插件 + 绑定项目（不带参数则绑定本仓库自身）
./install.sh --refresh-plugin /path/to/your-project
# 可选：指定落盘用的主干 worktree；完全不动项目里已存在的文件用 --no-seed
./install.sh --state-root /path/to/your-project --trunk /path/to/your-project-trunk
# 2) 重启 Codex 桌面端 / CLI，打开 Plugins → Personal → 安装「Codex 自动挡」
install.sh 做三件事：
1. 把插件装到 ~/plugins/codex-autopilot/，连运行时代码一起复制（ops/.py）。
2. 把插件登记进 ~/.agents/plugins/marketplace.json（原文件备份为 .bak-codex-autopilot）。