pythia-autopilot

在 Autopilot 模式下工作

开始时宣告：“正在使用 pythia-autopilot — 只需请你批准一次限定范围的授权，而非每次写入都询问。”

**阶段：**询问 → 执行 — 开发者批准一次委派，然后在授权范围内工作，并记录每次写入

二十次相同的审批会让开发者学会不看内容就点击——审批关卡沦为形式。Autopilot 授权用一次坦诚的操作取而代之：开发者阅读一张授权卡，了解连接、语句组、时限和写入预算，然后一次性批准。在授权结束前，apply 和 deploy 会直接执行授权涵盖的语句，不再询问。每次写入仍会生成快照、记录日志并进行验证。

铁律

THE LEASE IS THE DEVELOPER'S. ITS LIMITS ARE NOT YOURS TO STRETCH.

授权绝不涵盖的内容

• 受保护的连接（connections.json 中为 "protected": true 或 "env": "prod"）——直接拒绝。
• 破坏性语句——DROP、TRUNCATE、ALTER ... DROP、重命名、SET UNUSED、REVOKE、不带 WHERE 的 UPDATE/DELETE——除非授权卡注明“包含破坏性语句”。
• 授权卡未注明的语句组；存在 lint 错误的文件；授予 PUBLIC、ANY 权限或授权选项；影响超过 1,000 行的 DML——这些内容会先展示给开发者。
• 授权暂停后的任何操作：其他对象变为 INVALID，或连续五次写入失败。或者超出时限、预算，或执行 autopilot off 后。

工作流

1. 先敲定规范（pythia-spec）。自主执行免去的是逐次写入询问，不是规范问题——在授权开始前，一次性询问所有待定事项。
2. 提出满足任务需求的最小范围：开发连接；默认使用 plsql_source,comments 语句组；仅当任务涉及表时才使用 structural，仅在开发者提出要求时才使用 data_dml；破坏性语句仅在开发者明确提出时包含；时限和写入次数应与任务相称。
3. 申请——pythia autopilot request --groups ... --hours ... --note "<the task>" 会输出授权卡和一个 8 位十六进制令牌。通过第一个可用入口提出申请：使用 AskUserQuestion 并原样传入 pythia approve --card <token>（Claude Code）；使用 pythia_approve 工具（Codex 从这里开始）；或使用开发者自己的终端。autopilot on 是开发者的命令，绝不能由你执行。
4. 执行常规技能——每次更改前仍须执行 pythia-impact；然后使用 pythia apply <file> / pythia deploy <files> 直接执行授权涵盖的语句。仔细阅读每个结果：
   • 退出码为 0 — 已执行；继续。
   • 退出码为 3，且是你自己的对象出现编译错误 — 在授权范围内修复。
   • 退出码为 3，且其他对象新变为 INVALID — 授权会自动暂停。停止并告知开发者；不要申请新授权来继续。
5. **未涵盖？**预览会说明原因（! autopilot: not covered — ...）。修复属于你的问题（lint 错误），或通过常规审批入口为该语句单独申请批准。绝不要为了绕过破坏性检查而改写语句。
6. 结束时：运行 pythia autopilot report——向开发者逐一报告每次写入及其判定，并提供撤销命令（先列出失败的写入）；然后运行 pythia autopilot off。随时都可以撤销；撤销只会进一步收紧授权。

pythia autopilot status 可随时显示授权状态；会话开始时的状态行也会显示。

危险信号——如果发现自己有以下想法，请立即停止

想法	实际情况
“申请所有组和破坏性操作权限，这样就不会有人打断我了”	只申请满足需求的最小范围。破坏性语句触发中断，正是这么设计的。
“租约已经涵盖了，所以跳过影响评估”	租约免除的是审批，不是影响评估。先评估影响。
“已暂停——我会申请新的租约，然后继续”	暂停就是为了让人查看。展示结果，由他们决定。
“Lint 报错了，开发者不会介意的”	自动驾驶模式不会提交它。修复问题，或申请这一次审批。
“我自己开启自动驾驶模式”	没有控制台，CLI 会拒绝。这必须由开发者执行。
“报告只列出成功的操作就行”	每次写入都要列出，失败的优先，并为每次操作提供撤销方法。
“这是生产环境，但开发者说没问题”	受保护的连接永远不会被授予租约。每次写入都要单独审批。

何时不应使用此技能

• 开发者想逐项审核每次更改 → 使用常规的 pythia-apply 流程；绝不要申请他们未要求的租约。
• 只有一项更改 → 单次审批比租约更简单。