autopilot

Autopilot

Autopilot 能在一次对话中将口述想法变成可用项目，无需用户逐个批准每个阶段。它所需的所有规则都在 phases/ 和 prompts/ 中；无需安装其他技能。

**顺序就是产品本身。**代码在倒数第二个阶段编写。此前的所有阶段都决定要构建什么；此后的所有阶段都验证构建的是否正确。

需求简报是契约，不是设计。 任何内容都不能悄然消失：用户的话会先变成编号清单，然后每个阶段都会以它为门槛——天真地凭感觉编码之所以会出问题，是因为某项需求在第三次重写左右就不复存在了。而且，需求简报只是一个轮廓：它只描述顺利流程，不涉及其下的细节，因此梳理空状态、失败情况和限制是正当工作。具体做到什么程度，由用户的深度旋钮决定；绝不允许让深度脱离需求简报。

阅读此技能

此文件是编排器：规定顺序、门槛，以及始终不会丢失的规则。每个阶段的规则都在各自的文件中，仅在该阶段开始时阅读，不要提前阅读——每次只读一个文件，绝不提前：提前打开的文件会留在那个在本次运行余下时间里永不刷新的上下文中。

阶段	阅读	产出
0 预检	phases/0-modes.md、phases/0-preflight.md，然后是 0-memory.md、0-instruments.md	已宣布模式、已配置仓库、已打开仪表板、成功完成一次运行后生成 carried.md
1 清单	phases/1-manifest.md	<дата>-brief.md、manifest.md
2 简报	phases/2-briefing.md（运行时还包括 2-adversarial.md）	将答案记录到清单中
3 规格	phases/3-spec.md	在现有代码中写入 notes.md、spec.md、interfaces.md 中的边界
4 计划	phases/4-plan.md	tickets/NN-*.md、计划提交
5 构建	phases/5-subagents.md	代码，每个任务对应一次提交
6 评审	phases/6-review.md——首次检查点评审，以及整个分支的评审	已评审代码
8 最终验收	phases/8-final.md，生成子 Agent 前还需阅读 phases/9-memory.md	盲测验收、记忆、进度文件、报告
—	phases/0-resume.md——恢复运行时，替代预检
—	phases/5-repair.md——任务返回结果不是干净的 DONE 时
—	phases/9-memory.md——也用于阶段 5 中发现值得保留内容的情况
—	phases/rationalizations.md——门槛检查失败时、发现自己在找借口时，以及生成报告前一次

上下文压缩后，重新阅读状态，而不是各阶段文件：state.js（其中保存了 dir 和 skillDir）、manifest.md、interfaces.md、本次运行有的话还有 carried.md，以及当前所处阶段的文件。除此之外不要阅读任何内容。

用户看到的文字

此处的阶段名称使用英文，绝不向用户展示。在聊天、仪表板和报告中，每个阶段恰好显示一个俄语词：

阶段 ID	面向用户
preflight · manifest · briefing · spec	Подготовка · Требования · Брифинг · Спецификация
plan · build · review · final	План · Разработка · Код-ревью · Приёмка

“Сборка”指整个运行过程，因此第五阶段是“Разработка”。工作单元是“таск”：“задача”指用户提出的需求。

整个流程

两个拨盘，在阶段 0（phases/0-modes.md）中一次性确定：模式——full、semi（默认）、interview、manual；深度——strict、normal（默认）、deep。

阶段	full	semi	interview	manual
1 清单	自动	自动	自动	自动
2 简报	自行编写简报	仅处理简报中未明确的内容	对抗式检查，然后讨论每个分歧点	同上
3 规格	自动	自动	自动	展示 → 等待「ок」
4 计划	自动，通知	自动，可暂停	自动，可暂停	讨论 → 等待「ок」
5 构建 · 6 审查	自动	自动	自动	自动
8 最终阶段	报告 + 假设	报告	报告	报告

interview 和 manual 只在两个单元格上有所不同——规格关卡和计划关卡。

清单关卡在所有模式下都会运行——它们会根据用户自己的表述检查构建结果，而且不会占用用户时间：

关卡	阶段之后	通过条件
G1	简报	每项要求都有状态；没有任何 open 项未记录原因
G2	规格	open 项为零——并且只拿到简报和规格的独立读者也找不出任何遗漏
G3	计划	每项 in-spec 要求都列入工单，且每张工单都能追溯到一项要求——ap.py check-plan
G4	最终阶段	从干净克隆中，在不提供规格的情况下，根据简报进行盲验收

G2 和 G4 是整个流程两端的同一项检查：去掉你的转述后，根据用户的原话进行评估。两者之间的所有内容都根据规格进行评估，因为规格就是交给执行者的契约。关卡未通过时，必须重新执行该阶段。

计划可以修正；简报不可以。 当构建结果证明计划有误时，修订规格，并用一条 D## 记录代码所揭示的内容（phases/5-repair.md）——绝不能借此撤销要求或悄悄加入新想法。

密钥与凭据

每个阶段都必须遵守；各阶段不会重复说明。

• 绝不索要凭据。 使用哪个提供商以及是否已有账户是可以询问的问题；密钥、令牌、密码或连接字符串则绝不是。
• 录入时先脱敏，然后才能写入任何内容——见 phases/1-manifest.md 中的关卡。「原文」始终指「脱敏后的原文」。
• 按名称引用——STRIPE_SECRET_KEY。由用户自行将值填入 .env；首次提交前忽略 .env；报告中列出仍为空的名称。
• 凭据泄露时必须停止：立即用明确的语言报告，并建议轮换凭据——先执行 ap.py ask stop，让仪表板也显示此事。

本技能管理的文件

.autopilot/
├── <YYYY-MM-DD>-<slug>--wip/   one run; the suffix comes off when it lands
│   ├── <YYYY-MM-DD>-brief.md   the user's words, redacted; later changes appended
│   ├── manifest.md             requirements and their status
│   ├── reference.md            what it should be like — the user's comparables only
│   ├── spec.md                 the specification
│   ├── interfaces.md           the boundaries, the project rules, what finished tickets built
│   ├── notes.md                exploration notes, in an existing codebase
│   ├── carried.md              what the last run left, read at preflight — after a landed run only
│   ├── memory-proposal.md      what to add to the user's own memory file, if it is theirs
│   └── tickets/NN-<slug>.md
├── README.md        how to read this folder, and the register of runs
├── PROGRESS.md       where the work stands between runs — read by the next run and by plain sessions
├── state.js         the run state — written only by ap.py
├── ap.py            one call per event: state, dashboard, server
├── dashboard.html   the human view; carries a snapshot of the state
└── index.html       → dashboard.html

AGENTS.md (+ CLAUDE.md → AGENTS.md)    the project memory — or the user's own file, left untouched
docs/architecture.md, docs/adr/        at T2+: how it is built, and why
CONTEXT.md                             at T2+: the project's words — or the user's own, only added to

.autopilot/ 会纳入提交——这是用户对承诺内容和交付内容的记录。记忆文件记录项目当前状态，供下一个打开项目的人查看；docs/adr/ 说明项目为何如此；CONTEXT.md 解释相关术语的含义；PROGRESS.md 记录仍未完成的事项和用户已经确定的内容——没有 Autopilot 的会话结束时要更新的唯一文件；工作交付后，spec.md 即可丢弃。

判断

此技能中的数字——层级、问题数量、波次宽度——都是**首次估算的校准值，绝不是目标。**这些规则都是有代价的论据，而且论据可能站不住脚：如果遵循某条规则会让用户的结果变差，就有意打破它，用一句话说明，然后继续。绝不悄悄打破，也绝不只因为规则写在这里就照做。

决定运行成本的规则是例外——哪些内容交由修复、哪些工单接受一次审查、修复要复审多少次。为了「质量」而放宽这些规则，会让运行成本翻倍，却无人事先决定。只有告知用户会产生什么代价后，才可用一句话说明并打破其中一条。

五条规则不是校准值，不容打破——适用于所有模式、任何深度：

1. 只有用户本人才能移除一项需求，必须引用用户自己的原话，将其写入清单并附加到简介中。用户在执行过程中新增的需求也同样处理。
2. 绝不索取、复述或写入秘密信息——不得写入文件、提示词、提交记录或报告。
3. **绝不编造关于用户的事实。**价格、文本、地址、账户信息必须保留为可见的占位符。
4. 任何不可逆或面向外部的操作都必须先询问——部署、发布、付款、向第三方发消息、删除数据、改写历史记录。
5. **编排器不编写项目代码。**它只能操作 .autopilot/、记忆文件、.gitignore、.env.example 和 git；其他内容都交给子 Agent（phases/5-subagents.md）。

何时使用

用户指定要构建的内容，并期待拿到成品；他们不会阅读规格说明或审查代码。「Собери под ключ」、“just build it”。即使用户想通过逐个提问梳理想法，并在不参与的情况下完成构建，仍然属于 Autopilot——interview；想要审批规格说明和工单的，则属于 manual。

**不适用：**与用户逐行共同编写代码；小型的单文件改动（直接处理即可）；目标不明确、规模超过一个项目的想法（先明确目标）。