从去年年底开始，我做了一个新的尝试：每天下午出门跑步之前，把一批活派给 AI，然后出门。等我跑步回家，它还在持续工作。偶尔，心情来了，给同学们开直播，让大家围观 AI 是如何自主干活的。
刚开始，AI 自主干活的时长稳定在 30 分钟到 3 个小时，而最近几个月，这个时长不断被突破，慢慢地，3 个小时已经极为稳定了，9 小时也不在话下，甚至时不时持续工作到 36 个小时以上。
这种你不在电脑前、甚至在睡觉时，AI 依然在勤勤恳恳替你干活的感觉，只要体验过一次，你就再也回不到从前了。业界喜欢用「harness」这个词，我自己更愿意叫它 AI 自主系统（Autonomous AI System）。在一次访谈中，我甚至谈到，「衡量当前 AI 发展到了什么水准，就看一件事：在没有任何人类介入的前提下，它能独立工作多久、能不能交付高质量的成果。」
那么，如何实现一个好的 AI 自主干活系统呢？分享一些经验。
任务编排
这个环节，是为数不多需要人类介入的一环，因此极为重要：给 AI 恰到好处的任务、恰到好处的上下文，以及恰到好处的任务执行流程编排。
技巧 1：合并同类项
指令示例：请你读取任务清单上所有尚未关闭的问题，然后请合并同类项，确保每轮执行的都是同一组问题。继而按照任务复杂度从低到高排序，控制在 12 小时能干完的工作量。
对新手来说，我建议任务清单不要写在本地，更建议写成一条又一条 issue，效果更好。AI 非常擅长处理 issue，而没那么擅长处理本地的自定义格式的任务清单。这里的 12 小时也可以下调为 3 小时或更短时间。
这条技巧背后的原理是尽量减少上下文切换。AI 自主干活，最怕任务杂。 让它一会儿修 bug、一会儿写文案、一会儿做表格，上下文反复横跳，交付质量必然差。同类任务则不然。它能把上一个任务里建立的模式、踩过的坑，顺势复用到下一个，越干越顺。
那么，为何还要按照复杂度排序呢？答案其实很简单，让 AI 先用简单任务「热身」，把这一类问题的套路摸熟，再去啃复杂的，成功率更高。AI 与人类有非常类似的一面：成功带来成功。反之，一个新手，则会不断打断 AI 干活，最后 AI 交付的质量也会越来越差。
技巧 2：确定性分流
指令示例：请你在实际动手干活之前先判断：你是否已拥有足够的上下文？你是否明白你要实现的目标或解决的问题了？你是否已经对你的目标或问题进行过元反思了，是否需要重新定义问题？如果你的确清楚，就直接干；如果不清楚，请先调研，把关键决策点列给我，等我拍板再干。
每次，我跑步之前，都会这么问它一轮，是否明白今天要自主干的这批活的目标，以及是否拥有足够上下文了？然后再让它提供关键决策点，我决策后就安心出门。
这就是 AI 自主干活系统的核心设计：把人介入的点，前置到「开工前」，而不是「返工时」。
很多人用 AI 的痛苦在于，AI 闷头干了半天，方向是错的。事后盯得更紧没用，关键是让 AI 在开工前先自我分流：高确定性的活，一句话确认就放手；高不确定性的活，先停下来，把拿不准的几个关键决策摆到你面前，你拍完板它再走。该自主的地方彻底自主，该请示的地方绝不自作主张。
技巧 3：开工前，先确认世界没变过
指令示例：开工前先确认一下当前的真实状态（最新的进度、版本、数据），别拿上一次缓存的旧状态当真相。
AI 干活的一个隐藏陷阱是：它手里的「事实」，往往是上一次对话开始时的快照。可这期间，别人可能已经改过了，后台可能已经自动合并过了。基于过期状态干活，轻则白忙，重则覆盖掉别人在途的工作。
因此，我的 AI 自主干活系统设定了一个 boot 原则，第一步永远是「先核对现在的真相」。放到任何协作里都一样：动手前，先确认世界没在你不知道的时候变过。
实现开工
这一组技巧极为反直觉，也体现了 AI 自主系统和传统工作流的根本不同。
技巧 4：干了再说，边干边对齐
指令示例：别在计划上无限纠缠。先把最小可用的版本跑起来，让产出本身说话；过程中每隔一段，就拿我们最初的意图回来对一次，看跑偏没有。
传统工程教育告诉你：先写详尽的计划，再动手。但在 AI 自主系统里，我越来越确信一件事——计划永远不是唯一的真相，实际产出（比如代码）才是。
复杂的活当然也写计划，但计划只是一次性的脚手架，别当成金科玉律。需求往往是「干」出来的，靠「想」想不全。用 AI 快速迭代原型，跑通四五个大版本之后，你才真正知道自己想要什么。这个阶段，人多反而是负担：你没法跟人解释「为什么又要推翻重来」，但 AI 不需要你解释，它马上帮你验证。
所以实现阶段的纪律就四个字：先跑起来。计划写得再周全，也不如让产出先长出来，再拿意图反复校准它。所谓对齐，是让意图和不断生长的产出互相补全，而不是让产出去迁就一份僵死的计划。
技巧 5：worktree 并行分身
指令示例：把这个大活拆成几块，每个分身负责一块，注意给每个分身都利用 git worktree 创建一个隔离的工作副本，让它们同时干、互不干扰，干完再合到一起。
普通人开两个 AI 改同一个项目，立刻就冲突打架。更大的提速，来自让一群分身同时干同一个大活。 单个 AI 的吞吐有上限，杠杆就在「并行」二字。
技术上的实现，就是 worktree。worktree 这个由 pclouds 主导开发的新功能，早在 2015 年就诞生了。但在 git 中却并非一个常用命令。如今，得益于 AI 的进步，它成了 AI 自主系统的标配了。
使用 worktree，几乎所有的人都不适应，因为人类大脑不是这么工作的，我们格外不擅长多线程切换，以及管理多线程。所以，这里的关键是，如何将 worktree 的工作流程约束在人类的工作记忆与认知负荷以内。
技巧 6：补齐测试
指令示例：干完别急着交。把各类测试、尤其是端到端测试补齐，功能必须真的跑通，而不是看起来跑通。
AI 擅长自我欺骗，很多时候，没有实际测试，就宣称工作完成。或者只测容易的场景，没有测复杂的场景；或者只考虑常见的数据，没有考虑到边缘数据。因此，我们得提前约束 AI 必须进行更复杂的各类测试。比如，端到端、多样本、真环境。 测一个不算数，要拿不同类型的样本各测一遍，确保产出跨场景都稳。
迁移到非编程类任务也一样：一篇稿子、一份方案，别只在你设想的理想读者身上「跑通」，要拿几类真实场景来进行压力测试。
自检与评审
认知科学中有一个著名的元认知错觉，就是我们以为自己知道，然而实际并不知道。同样，AI 作为一种新型智能体，也存在类似的元认知错觉。因此，我们需要让它进行自检与第三方评审。
技巧 7：对抗性自检
指令示例：请派几个分身，分别扮演最挑剔的评审者（或：你见过最严格的评审者），从互不相同的角度找漏洞：一个查重复和冗余，一个查并发和边界，一个查有没有破坏旧功能。各自把问题写下来。
这个技巧需要注意：
1）务必多视角。不要只一个视角。自检不是「再读一遍」。再读一遍，AI 只会再一次确认自己是对的。有效的自检，是把自己分裂成几个互不相同、互相对抗的视角同时审。 一个专挑冗余，一个专挑边界，一个专挑「为了实现新目标而破坏了旧功能」。视角越分化，越能逼出单一视角看不见的问题。
2）沉淀项目专用的自检 Skill。这里的「重复和冗余」「并发和边界」「是否破坏旧功能」，仅仅是举例。你可以根据自己项目的实际情况，替换为自己的自检维度。我建议每个项目，都沉淀一个专门的自检 Skill，将这个项目容易出现的一些错误都沉淀在里面。你可以调用 42plugin cli 的 skill 生成器自动生成。
技巧 8：换一个不同谱系的模型来评审
指令示例：请调用 Codex 进行评审，注意命令为：'codex exec -m gpt-5.5 -c model_reasoning_effort=medium'，评审提示词为
这是我认为最被低估的一步，也是大多数人很少尝试的一步。为什么仅仅依赖干活的 AI 大模型自检还不够？因为它的上下文已经被任务细节污染了，同时任意一个大模型的能力都会受限于训练数据与 Agent 提示词的设定，存在天然局限。
更好的做法是换一个干净的、不同谱系的 AI 大模型：一个全新的上下文，最好来自另一家公司、用不同训练数据和不同推理风格训出来的旗舰模型。
我一般是在 Claude Code 中用 Opus 4.8 模型干活，我设定的 AI 自主干活系统，必然有一个步骤，调用 Codex 的 GPT-5.5 模型来进行独立的第三方评审。很多人不知道，Claude Code 可以直接调用 Codex 做代码评审，但你需要指定模式为：'codex exec -m gpt-5.5 -c model_reasoning_effort=medium'。
技巧 9：分级修复，每轮给出通过信号
指令示例：请把所有问题按 P0/P1/P2 分级，一轮一轮修。每修完一轮，都要给我一个明确的「通过 / 不通过」信号，不许含糊地说「差不多了」；不通过就继续，直到通过为止。
评审的结论，必须落到一个可判定的信号上，而不是一句模糊的「应该可以了吧」。
这背后有个微妙的风险：让两个 AI 一起评审，最大的危险是它们会互相说服——干活的那个解读评审结论时，会下意识往「通过」的方向偏。所以我从不让干活的模型自己解读评审结果，而是设一个明确的判据：通过就是通过，不通过就接着改。同时，每一轮都必须是真修，不许原地打转重复提交。问题分级（P0 必修、P1 必修、P2 酌情），一轮轮收敛，直到通过。
需要注意的是，每轮修复，都要把教训沉淀成一条可复用的规矩，下次开工前先读一遍。把评审中学到的东西制度化，是让 AI 自主干活系统越用越聪明的飞轮。
自动续航
前三组技巧让 AI 能把「一件事」干漂亮。这一组，让它在你离场后，自己一件接一件地干下去。
技巧 10：看门狗
指令示例：请用 CronCreate 帮我创建一个看门狗，定时读取记录工作进展的文件，找到下一个未完成的步骤立即执行，不要问我任何问题。
看门狗是这套系统里最简单、却最关键的一招，正是它让我们摆脱「人在回路」。这样，哪怕你去睡觉，它也会一步步把活往下推。类似的还有「心跳监控」：让它定时读 memory 文件，有待办就立即执行，没有就回一句 HEARTBEAT_OK。
技巧 11：意外处理矩阵
指令示例：遇到任何卡死、修不动、不可恢复的情况，不要停在那里等我。把情况记进状态文件，跳过它，继续下一个。永不停摆。
仅仅依赖看门狗又不够，它依然会报错、卡住。因此，我们要提前预设意外处理矩阵。这是我的某个项目的真实意外处理矩阵示范：
如果：codex 评审超时（> 5 min 不返回），那么：kill 进程 + 记录 + PR 留着不合 + 跳下一个
如果：codex 持续 REQUEST_CHANGES（≥ 2 次），那么：PR 留着不合 + 评论附 codex 输出 + 跳下一个
如果：测试 fail 修不动，那么：PR 不开，分支保留 + 在 issue 评论标 BLOCKED + 跳下一个
如果：调用 /simplify Skill 改完测试 fail，那么：撤改动重新做 + 仍 fail 标 BLOCKED
如果：任何 unrecoverable，那么：记 .claude/notes/autonomous-state.md + 跳下一个
就像人类设定执行意图能大幅提高行动力一样，提前预设「意外处理矩阵」，其实就是给 AI 预设执行意图，从而大大提高了行动力。
撰写「意外处理矩阵」的核心原则是：永不停摆。 一批任务里，总有一两个会卡住。如果一卡就停，这个 AI 自主干活系统也太弱了吧？所以规则必须是：单条卡住，就跳下一条，绝不阻塞整体推进。 卡住的那条标记好、留着，等你回来手工处理；其余的继续往前。
这个原则在设计 AI 自主系统的时候，几乎处处可见：为失败预设绕行路径，别让局部的卡顿拖垮整体。
技巧 12：状态持久化
指令示例：请维护一个状态文件，把「已完成 / 进行中（当前在哪一步）/ 卡住 / 待开始」实时写进去，每进入一个新阶段就更新一次。这是看门狗醒来后唯一的真相源。
AI 没有跨对话的长期记忆，上下文一重置就「失忆」。解法是把记忆外置成一个文件。 这个状态文件是整个 AI 自主系统的唯一真相源：看门狗醒来，先读它，就知道上次跑到哪、下一步该干什么；中途任何一次中断，都能从断点无缝恢复。
它还有一个常被忽略的作用：收尾时给你一份人话。 AI 自主干完一整夜，你最怕回来面对一个黑箱。所以这套流程要求它最后产出一份汇报：哪些完成了、哪些卡住了、做过哪些关键判断。让你一眼就能接管，而不是从头重新理解一遍。
小结
这轮 AI 发展足够快，整个社会还来不及适应，带来了很多新问题。最突出的新问题是：人有人的节奏：要吃饭、要睡觉，注意力是有限的；AI 有 AI 的节奏：可以持续运行，但上下文也会被塞满。
当这两套节奏开始一起工作，问题就变成了：哪些事你要亲自做？哪些事可以交给 AI 持续推进？怎么让人的「碳基作息表」和 AI 的「硅基作息表」更好地协同？而更本源的问题是：如何让越来越强的 AI 增强人类，而不是削弱人类的自主感与意义感？因此，需要我们从单点思维跃迁到系统思维，我提出的 AI 自主系统就是尝试正面回应这类问题。
真正的答案是什么？也许它不在那些确定的、高效的、可被自动化的回答里，而在人类面对 AI 这类快速生长的技术巨物时的恐惧之中，在它所带来的颠覆面前的踌躇之间，在一时不知如何自处的茫然之际。当 AI 把确定的事越做越快、把不确定留给人类，恰恰是这份恐惧、踌躇与茫然，见证着人类之所以为人类。