这一年，AI 把我的工作一项一项地接过去了。我并没有因此感到慌张，因为我做的事情已经变了：我不再盯着某一段代码，而是盯着整件事怎么跑起来。

我已经很久没有亲手写过任何一行代码了。倒不是写不动，而是看上去不划算。我一晚上指挥 AI 干活，比我自己一周写的还多。这一年我干的事情越来越不像具体的 coding，更像是同时盯着一群 AI 在干活，看哪个地方可能出问题，哪个地方做得不对。

我想从一件很小的事情讲起，因为这件事情就是我转变的开端。

那天我让 AI 帮我做了一个输入框，类似 SQL 编辑器那种：打字时弹出提示，让你选字段、选函数。它改了三遍，每一遍都很差。光标停在某个地方，该弹的提示不弹，或者弹出的内容不对。

直到我让它改到第四遍的时候，我突然想到一个问题。我问它："你这一块到底是怎么实现的？为什么会有这么多问题？"

它说它会用正则去匹配光标前面的字符串，匹配上哪个模式就弹哪个提示。我瞬间就明白了。因为最开始我的想法根本就不是一个正则，它应该是一棵树，有层级，光标的位置、该弹出的内容，都应该从当前这棵树的状态里面推导出来。

这应该是状态机的模式，而正则模式只能获得 80% 的功能，剩下 20% 的功能怎么都没办法实现，因为那 20% 不是靠字符串匹配能完成的，它缺乏了很多状态。

在这一刻我才意识到，原来它没有改错，它改得倒是挺诚实的。问题出在我最开始给它的方案——我脑子里想到的是一棵树，但我说给它的可能就是一个"类似开源 SQL 的会弹提示的输入框"。它就按着这一句话，老老实实地用了它能想到最简单的方法，也就是正则。

我脑海里的那些逻辑并没有告诉它，它只能按照我输出的这一点点内容去猜。后来真正让我琢磨的不是这个输入框，而是我自己的反应。我没有因为"它写不了"就自己上手写，而是回过头去问它："你是怎么写的？"

过去的我遇到自己实现不了的问题，往往是自己上手。但到那一天，我没有想着要自己做，我想的是告诉它应该怎么做。

这篇文章想要记录的，就是我怎么完成了这样一个思维转变。我并不是要说自己做得多好，而是给自己做个记录，把来时的路想清楚：我是怎么一步一步，从每一行代码都自己写，走到最后任何一行代码都不再亲自动手的。

一、我不再自己写代码了

过去的我相信一件事：代码得是我自己一行行写出来的，我才放心。

这不是固执。你自己写的东西，每一处为什么这么写，你都清楚；出了问题，你知道去哪儿找。这种心里有底的感觉，是一个干了很多年的人最看重的东西。

现在我不写了。我让 AI 写，我只看它写出来的东西对不对。

刚开始我很不适应，总忍不住去读它写的每一行，一读就想动手改。但我很快发现根本读不过来——它一晚上写的代码，比我一周写的还多。我要是逐行读，那还不如自己写。

被逼到这个份上，我才认真想了一个问题：我到底应该 review 什么。

想清楚之后，我就不读代码了，我改成看功能。

我不管它里面怎么实现的，我只问一件事：我能想到的那些边界情况，它有没有都处理到。还拿那个输入框来说，我就一个场景一个场景去试：光标在中间删字符会怎么样，粘贴一大段进来会怎么样，中文输入法还没上屏的时候会怎么样。这些都过了，我就不去管它底下是用树还是用正则了。

这么一来，事情的性质就变了。

读代码的时候，我的工作量是跟着代码量涨的，它写得越多，我越读不完。可看功能的时候，我的工作量只跟着"边界情况有多少"走。而边界情况有多少，是我说了算的，是有数的，是我一个人能扛住的。

再往后，我连一个一个去试的活都不太干了。现在我经常同时让一批 Agent 并行跑，它们自己写、自己测、自己 review。

说"我什么都不管"，听上去像撒手不干。但其实我盯的东西，换到了更上面。我就看三件事：这一批 Agent 什么时候会崩；崩的时候，它停在哪、留下的记录够不够我重新接上去，还是得从头再来；以及整批跑完，离我要的结果还差多少。看完这三样，我回头去改的，不是某一段代码，而是这套流程本身——哪里该加一道检查，哪里该把任务拆细一点，哪里该让它早点停下、别带着错往下跑。

到这一步，我已经不在写代码这一层了。我盯的是这批 Agent 整体跑得稳不稳、崩了能不能自己缓过来、结果按时出没出。我改的不再是代码，是这套让它们自己跑起来的流程。

但有句老实话得先说在前头：我敢这么放手，是因为"哪儿容易出问题"这张图，在我脑子里。哪些场景要试、哪个地方最容易出事、一批 Agent 崩起来通常崩在哪儿——这些是我这些年一个一个 bug、一次一次半夜被叫起来踩出来的。这张图我没办法直接塞给一个新人。后面我还会回到这件事，它是这整套做法里最不踏实的一块地基。

二、我不再先写清楚再动手了

过去的我还相信一件事：先想清楚、写清楚，再动手。

这是教科书里的规矩，也确实是好习惯。需求对齐好，规格写明白，然后照着做，返工最少，最稳。

但我现在基本不写详细的规格了。我就跟 AI 说个大概的思路，它差不多就能给我搭出一个雏形，剩下的我再慢慢拨。

这事我一开始也觉得是自己偷懒、不够专业。直到我老老实实算了一笔账。

写规格这件事，听起来很美好，真做起来全是窟窿。你以为该讲清楚的地方，它没当回事；你觉得根本不用提的细节，它反而给你铺一大堆。说到底，你跟它对一件事的理解天生就有缝，不是写了规格这缝就没了。更何况，你费劲写出来的那份规格，其实没什么人会从头读到尾——包括 AI，也包括三个月后的你自己。

所以这笔账是这么算的。一条路，是前期把规格抠到极致，指望它一次做对，代价是花掉大量对齐的时间，而且对齐完了它照样可能只给我 80%。另一条路，是我只说个大方向，拿个雏形，然后挑错、改正，省掉了前期对齐，代价是后面多纠几轮错。

算下来，第二条路更划算，所以我选了它。

但我不是把规格扔了，规格还在，只是换了个地方放。

有一部分，放进了代码里。像那个输入框的状态机，逻辑全在代码上摆着，没有藏着的隐含逻辑，我根本不担心它会"忘"——要参考，它去读代码就行，代码本身就是那份不会过期、也不会读错的规格。

还有一部分，放在我脑子里。就是那 20% 的判据：什么算对，什么算错，哪儿是它最容易偷懒糊弄的地方。这些我没写下来，因为写下来的成本，比我每次验收时在脑子里过一遍要高得多。

所以说到底，规格没有消失。它只是从"动手之前的一份文档"，变成了"动手之后我心里的一把尺子"。

但这条路有个我必须承认的前提：它之所以便宜，是因为我的眼力在替它兜底。

我敢只说个大方向就放它去跑，是因为雏形拿回来，我一眼能看出那 20% 错在哪、该怎么拨回去。换一个刚入行的人走这条路，会摔得很惨——他看不出那 20% 错在哪，会把 80% 当成 100% 收下，然后那 20% 在某个深夜的线上事故里爆开。对他来说，纠错的成本几乎是无穷大，因为他根本不知道要纠什么。

所以我敢不写规格，靠的是脑子里那套判断标准还在。说到底，敢不写规格和敢不自己写代码是一回事，靠的都是我自己那点判断力。

三、我不再手把手带人了

过去的我觉得，经验是要手把手传的。老人带新人，坐一块儿，一个 bug 一个 bug 地讲，讲透了，人就带出来了。

这事我现在也不太做了。倒不是不想带人，是我发现人传人这条路损耗太大。每个人的判断标准不一样，你觉得天大的事，他觉得没什么；同一句话，传到第三个人那儿，就全变味了。

我现在做的，是给团队搭一套系统，让大家都在这套系统里用 AI。我不去一个个校准每个人脑子里的标准，我去校准那套系统。

系统里头，传承靠的是让 AI 自己留记录。它干完一件事，会写下它具体做了什么、踩到过什么坑、最后怎么绕过去的。下一个人——准确说，下一个人手里的 AI——接手时，能把前面几任留下的记录全翻出来看。前面的人栽过的跟头，后面的人不用再栽一遍。

关键在这儿：这些记录，不是给人看的，是给各自的 AI 看的。AI 记得住就行，人不需要自己记。

这一下，传承这件事的主角换了。过去是老工程师教新工程师，现在是上一个 AI 给下一个 AI 留笔记。为什么这条路反而更靠谱？因为人和人之间传东西会失真——每个人的理解都带着自己的滤镜。可 AI 和 AI 之间传的是文本，是白纸黑字。它不会因为"我以为你懂"就把话说一半。

光有记忆还不够，这套系统还得有规矩。我给团队立了三条，每一条都不是凭空想的，是我自己一次次摔出来的：

第一条，任务直接交给 AI 去跑，不许自己上手写。 这条主要是给老手定的，也包括我自己。一个干了很多年的人，看 AI 磨磨蹭蹭，最容易忍不住一把接过来，"我自己两分钟就写完了"。可你一接手，就又退回到了自己写代码的状态，这套系统对你就白搭了。忍住不去抢这一手，是进门的第一关。

第二条，验收必须自己亲手跑一遍。 不许它说一句"我测过了，没问题"你就收下。它说它好了，和你亲眼看它好了，是两回事。你可以不读它的代码，但你必须亲眼看见那个功能在你面前跑对。这一条，是专门用来挡掉那种看个 demo 就过的习惯的。

第三条，也是最狠的一条：你不许直接去把问题解决掉，你得先退一步，看是系统哪里不够细，才让 AI 没能自己解决。 一个 bug 摆在面前，人的本能是上去把它修了。但在这套系统里，这是不许的。你要问的是：它为什么没能自己修好？是上下文里缺了什么？是哪条要求没说清楚？然后你去补那个系统层面的东西，让这一类问题，它下次自己就能解决。

第三条，其实就是开头那个输入框故事的延伸。同一个地方反复出问题，别忙着一遍遍去修它，得想想是不是这套东西本来就不该这么设计——我把当年那个一闪而过的念头，变成了团队里一条不许违反的规矩。

当然，这套系统现在还很糙。AI 写的那些记录质量参差不齐，该记的没记，不该记的记一堆，还得有人时不时去盯一眼、收拾一下。它离"能自己转起来"还差得远。但这个方向我是认的，也一直在调它。

至于最核心的那个判断力——什么是好、什么是坏，什么时候该停下来问一句"你这是怎么做的"——这个我承认，现在没法教。它跟写规格是一个道理：你交代不清楚的地方，它就做得差。这东西长在人心里，传不出去。

四、每交出去一份活，我接回一份更高的活

把前面这三件事连起来看，我这一年的方向其实已经清楚了。

我不再自己写代码，改成看 AI 写得对不对；我不再先写规格，改成事后凭经验判断它做得好不好；我不再手把手带人，改成给团队搭一套能自己积累经验的系统。

这里有个我后来才看明白的规律：我每把一份活交给 AI，并不是把这份活白白丢掉，而是从它那儿接回了一份更高维度的活。写代码交出去，我接回了对功能的判断；写规格交出去，我接回了对取舍的判断；带人交出去，我接回了对整个系统的设计。每一次交出去，换回来的都是更值钱的东西。

到现在，我已经不太关心某一段实现跟我想的一不一样了。我看这件事的角度更高了——说得书面一点，有点像控制论：把这一群会自己做决定的 AI 当成一个系统来设计，让它跑得又快又不出格。这两年大家管这个叫 harness，叫 agentic engineering，名字不重要，重要的是我做的事变了——我从一个在系统里干活的人，变成了一个设计这个系统的人。

我愿意把这个过程叫"赢"。

但这个"赢"字我得说清楚，不然听着像吹牛。

我赢的不是"我学会了用 AI"，那不叫赢，那叫没掉队。我赢的是这个：同样一件事——AI 把我手里的活接走了——慌的人会说"我的工作被它抢了"，而我说的是"它帮我把脏活接走了，我腾出手去做更值钱的事"。我们看到的是同一件事，说出来的是相反的话。

我也不想把这个"赢"说得多漂亮。这一年我没少认怂，没少算账。我不写规格，不是因为我境界高，是因为我算过账，写了不划算。我能做现在这些事，靠的是前面那些代码我全自己写过、那些坑我全自己踩过。说白了，能接回更高的活，前提是你在底下扎扎实实干过很久。

我还没交出去的那样东西

说一句老实话：我上面讲的这一整套——只看结果不看实现、让 AI 自己积累经验、用控制论的角度去设计整个系统——它现在还没真正建成。

我敢只看结果不看实现，靠的是我脑子里那张"哪儿会出事"的图，这东西交不给下一个人。AI 之间传经验，靠的是它自己写的、质量飘忽的记录，还得人盯着。至于那套用控制论搭起来的系统，现在还只是个方向，不是个能用的东西。这中间缺的基础设施，是一大块。我知道它重要，但我现在也没太多精力把它推起来。

所以这篇文章，与其说是在讲一件我已经做成的事，不如说是在记一个我看见了、但还没真正走到的方向。该走的路我大概知道在哪，但路还没修好。

最后，还有一样东西，我到现在也没交出去——判断。

什么是对、什么是错，什么时候该停下来问一句"你这是怎么做的"，这个我还攥在手里。写代码、写规格、带人，我都交出去了，就这一样，还在我手上。

这件事听起来可能有点矛盾。我的判断力，是从我自己的工程经验里长出来的；而我现在搭的这套系统，靠的是反复调试。但说到底，调试调到哪儿、什么时候停，还是得靠我的判断。判断和系统，不是两件事，是一件事的两头。

可这里有个让我有点发怵、又有点兴奋的念头。判断是怎么来的？是踩坑踩出来的。而我现在正想亲手搭一个系统，让 AI 自己去踩坑、自己记下来。那么，那个我嘴上说"教不了、只能靠人自己踩出来"的判断力，会不会有一天，也被这套系统一点一点，从人脑子里挪出去？

真到了那一天，我今天站的这个位置——控制论也好、设计系统也好——也不过是个临时的落脚点。它接走了我写代码的活，接走了我写规格的活，接下来会不会连"判断"也接走？

到那时候，人还能干什么？

我不知道。但有一件事我知道：今天的我，已经不是去年那个一撒手就慌的人了。这一年我把写代码、写规格、带人一样一样交了出去，每交一样，都从 AI 那儿接回了一份更高的活。判断要是哪天也能交出去，那我就去接它再上面那一层——我还不知道那是什么，但我赌它在。