代码现在由智能体来写。开发者这份工作，变成了下面这样。

只要家里有个做开发的，饭桌上迟早会冒出这个问题：既然代码机器会写了，那还剩下什么？

老实说，这个问题问错了地方。写代码从来就不是这份工作的全部。它只是看得见的那部分，是从工位后面路过的人眼里唯一像在干活的那部分。而且在大多数星期里，它还是占比最小的那部分。

被自动化掉的那部分，从来就不是工作的全部

任何最终上线的东西，都要走完六个环节：

1. 有人想要点什么，而且说得很糟。
2. 有人判断这事值得做，以及什么时候做。
3. 有人把它变成一段足够精确、可以直接照着动手的描述。
4. 有人把它做出来。
5. 有人确认它没有碰坏别的东西。
6. 有人把它发布出去，并回话给最初提要求的人。

智能体拿走的是第四环。它拿得很有说服力，而且只会越做越好。几乎没人明说的是这件事对另外五环的影响：它们变重了，不是变轻了。

原因是吞吐量。当“把它做出来”要花两周时，周围这五环也就有两周的时间慢慢走。它们慢，是因为中间那一环慢，所以没人发现它们慢。当“把它做出来”只要一个下午，其余的一切就在同一时刻变成了瓶颈。

一环塌了下去。它原本挡住的重量，现在压在另外五环身上。

整件事就是这样，而这篇文章余下的部分，讲的是这五环每天真正落到手上时，各自长什么样。

环节 1：听见要做什么，而且别丢掉一半

新的失败方式很具体，代价也很实在：什么都做得出来，于是你把错的东西做得更快了。

需求从四面八方冒出来。客服会话里的一条消息。会议结束前的一句话。社交媒体上的一句抱怨。一份其实是功能需求、只是套了个 bug 外壳的报告。以前这没什么要紧，反正你两周也只做得动一件事，而最显眼的那件通常就是对的。现在你一周能做五件，选对的那五件和选错的那五件之间的差距，就是你一年里的绝大部分。

有两件事必须发生，而它们是两件不同的事。

第一，对提需求的人来说，提交这个动作本身必须足够便宜。如果用户得先注册账号、再找到一个表单、再把问题描述两遍，多数人根本不会去做，而愿意做的那些人也不构成一个有代表性的样本。一块公开待办看板，任何人都能在上面提需求、附一张截图、追踪它后来怎么样了，这层摩擦就没了。用产品的人自己写下需求，用他们自己的措辞，上下文一并带着。

第二，归拢必须是自动的，因为原始反馈的保质期很短。二十条其实在说同一件事的消息，在有人把二十条都读完并发现它们是一件事之前，看上去就是二十个问题。而这恰好是谁都腾不出时间去做的活。Idea Radar 是我们给出的答案：原始信号原样落进来，自动聚成主题，重复项在变成两份工作之前就被对上，每个想法都带着有多少个不同的人提过它这个数字。原文从不被改写，因为对方用的那些确切措辞本身就是数据。

这一环产出的不是一份待办清单，而是一份你读得下去的语料。

环节 2：决定做什么，现在最稀缺的就是这个

一块想法看板不是计划。把前者变成后者靠的是判断，而这个判断以前稀稀拉拉地摊在一个季度里，现在每周都得做一次。

这里有两个动作真正起作用。

晋级是一个刻意的动作。一个想法变成待办工单，是在有人判断它值得做的那一刻，而不是在它被提交的那一刻。其余的想法留在雷达上，带着提过它的人数，这才是诚实的状态：听到了，但没排期。八成条目永远不会被做的待办清单不是计划，那是一份排版具有欺骗性的档案。

范围界定发生在动手之前，不是动手过程中。含糊的反馈先变成一张确认过的效果图，提需求的人可以直接看着它点头。五分钟的确认，胜过一个下午做错一个页面，而当这个下午从你的一个下午，变成本可以用在别处的一个下午的智能体时间之后，这笔账变得划算得多。

环节 3：写任务简报，取代打字的那门手艺

真正的手艺跑到这里来了。

智能体不会像同事那样，对一条含糊的指令提出异议。它不会说“等等，你指的是两条支付流程里的哪一条”。它会用一个看起来合理的猜测把空缺填上，然后交给你一份自洽而错误的东西。含糊的代价以前是一次对话，现在是一份 diff。

拿到好结果的人和一整天都在跟智能体较劲的人，差别不在提示词写得多巧，而在有没有可复用的上下文。一共四种，按回报从高到低排。

智能体在动手探索之前就会读的上下文。 提交进仓库的约定文件（CLAUDE.md、AGENTS.md），以及一份项目记忆，里面装着架构决策、踩过的坑，还有事情为什么长成现在这样的原因。写一次，之后每台机器上的每个智能体都会读，一直读下去。这是今天开发者写下的、杠杆最高的文字，而几乎没人给它排时间。

把流程存成流程。 当你第十次讲解自己的发布检查清单时，你不是在写任务简报，你是在重打一遍字。一个技能库能把一段反复出现的流程变成智能体在任务对得上时自动加载的东西，而一个提示词库对任务简报本身做同样的事。

给它看，而不是描述给它听。 一段描述某个按钮没对齐的文字，比不上一张这个按钮没对齐的图。直接发一块屏幕区域过去，或者在上面画两笔指出你说的是哪个东西。如果是网页，把实时的 DOM 交给智能体，永远好过向它描述。

说出来，而不是打出来。 一段三句话的口述简报，比你原本愿意打下来的那一句承载的细节多得多。快速下一条指令用语音听写，想在不碰键盘的情况下来回沟通就用语音模式。这听起来像个舒适度功能。实际上它是个带宽功能：人说出来的总比打出来的多，而智能体的上限就是你告诉它的那些。

前三种每做一个任务都要重新付一次。第四种只付一次，之后一直在收。

环节 4：把活跑起来，跑在对的机器上

一个智能体是工具。多个智能体是系统，而系统需要有人来操作。

真正要回答的问题都不体面，而它们就是这份工作本身。哪些活可以并行跑，而不会出现两个智能体同时改同一个模块？哪个任务在运行期间值得你盯着，哪个不值得？你睡觉的时候，应该有什么在跑？

最后这个问题决定了活在哪里执行。任何你可能需要中途打断、纠正或者掰回方向的事情，都留在你面前这台机器上。又长、交代得清楚、没有模糊地带的活，应该丢到别处去：另一台你自己的电脑，或者一台通过 SSH 连上的服务器，这样一个两小时的任务就不会把你的笔记本扣为人质。反复出现的活交给定时任务。决定性的问题从来不是算力，而是你需要介入的概率有多大。

当一件活里的各个阶段确实性质不同时，单个智能体就是错误的形状。一件要先做出来、再测试、再审查的工作，是三份需要三套本事的活，而智能体团队让你把这几次交接明确画出来，不必在每一步重新解释一遍上下文。

而且因为这一切都不要求你坐在那儿，用手机来指挥也就不再是个噱头。在火车上花二十秒读完智能体的提问并回答它，决定了这个任务是做完了，还是等了你四个小时。

环节 5：审查，责任落在这里

这一环没法交给别人，原因不是技术上的。

逐行阅读这件事，大部分已经被智能体接走了。它们接不走的是签字。责任不会转移到一个模型身上。当一次迁移在生产环境上删掉一列数据时，“这是智能体写的”不是一句谁会接受的话，也不该是。

变的是审查的形态，不是它存不存在。每一行都读这条规矩，在五个智能体并行跑起来的那一刻就撑不住了；而一个人在晚上六点快速扫过九百行的 diff，产出的是一个签名，不是认识。真正站得住的规矩是按影响范围审查：文案和样式扫一眼就过，而身份验证、支付、权限、个人数据和数据库迁移，每一次都要由一个本来就写得出这些代码的人逐行读完。

有两件事让这套做法真的跑得起来。能够按智能体分别看 diff，而不是面对一堆合并在一起的改动，在三个智能体动过同一个仓库的时候，它能告诉你谁改了什么。而把对话附在提交上回答的是半年之后真正费时间的那个问题，那个问题从来不是“改了什么”，而是“为什么”。

只要涉及界面，检查就不能停在 diff 上。一个能操作真实浏览器的智能体，可以把它刚做出来的流程完整走一遍并汇报它看到了什么，这能抓住那一类在源码里读起来毫无问题的 bug。

关于这份注意力该花在哪里，我们专门写过一整篇：你还需要审查 AI 智能体写的代码吗。

环节 6：发布，然后把循环闭上

发布是这一环里容易的那一半。被跳过的那一半，是回话给最初提要求的人。

它也是回报最高的那一半。一个报了问题、后来听说它已经上线的用户，下一个问题还会来报。一个报完之后只收获沉默的用户会停止上报，而你也就失去了喂养第一环的原料。当一张源自公开需求的工单被关闭时，提交它的人应该会收到消息，而不需要任何人记得去发一封邮件。

在这之前，通常还有个人需要亲眼看到它跑起来，而这个人手上没有你的开发环境：一位客户、一位设计师、一位在另一个大洲的同事。一个指向你本机的公开 HTTPS 网址，把这件事从一次部署变成了一条链接，而回来的反馈直接进入第一环。

链条闭合了。正是这一点让它成为一份工作，而不是一条排队的队列。

真正缩水的和真正膨胀的

老实读完这张表，焦虑就换了个形状。缩水的那些部分，恰恰是最容易招到人的部分。膨胀的那些部分，需要一个真正理解系统、理解用户、理解后果的人。这是一份更难的工作，不是一份更小的工作，而且比整天埋头打字的那个版本要热闹得多。

AgentsRoom 在这里面处在什么位置

我们做的是能把整条链条兜住的那个工具，因为另一种选择是六个彼此不认识的工具。

具体地说：需求落进一块看板，自动归拢成想法，被晋级成工单，被界定成一份智能体不会读错的说明，由一个智能体或者一支智能体团队在你的机器上或者一台远程机器上执行，按智能体分别审查、对话一并附上，最后在关闭时通知最初提要求的人。一个窗口，一个能反映工作真实状态的地方。

单块的零件别处都有。没人做出来的是它们之间的连接，而工作正是从这些连接处漏掉的。

大家真正会问的问题

AI 会取代软件开发者吗？

它取代的是打字，不是这份工作。写代码是一条链条上的一环，这条链条上还有：听见用户需要什么、判断什么值得做、把它写得足够精确、盯住执行、验证、发布。智能体把其中一环的成本压塌了，于是另外五环成了瓶颈。以后为产出代码行数而拿钱的人会更少，而为决定哪些代码行应该存在、并在它们上线之后为其负责而拿钱的人会更多。

代码由智能体来写之后，开发者具体在做什么？

六件事，而其中只有一件以前会显示在一屏代码上。你收集大家提出的需求，你决定什么值得做以及按什么顺序做，你把任务简报写到智能体不可能读错的精度，你同时推进好几件活而不丢线索，你按每个改动可能造成的破坏程度来审查，然后你发布并回话给最初提要求的人。手艺从产出改动，转移到了把它讲清楚并为它负责。

还需要会写代码吗？

需要，而且在“读”这件事上比以前更需要。你不再需要背下一门一年只碰两次的语言的语法，那由智能体来写。但你需要打开一份 diff，在几秒钟之内判断出一次迁移能不能回滚、一处身份验证有没有被挪走、一条查询在十倍流量下扛不扛得住。看不懂代码的人审查不了智能体，而审查不了智能体的人不是在指挥它，只是在祈祷。

把写代码交给智能体之后，最先崩掉的是什么？

是优先级排序。当做一件事从两周变成一个下午，做错东西的成本就从视野里消失了，于是它真的被做了出来。团队最后拿到的是更多已发布的功能，而解决掉的问题一个都没多。第二个崩掉的是反馈闭环：用户的需求来得比任何人整理得动的速度都快，于是它们堆在聊天记录里被弄丢，同一个需求被做了两遍，因为没人发现那是同一个。

在这套新的工作方式里，最难的本事是什么？

把任务简报写到智能体不可能读错。智能体不会像同事那样对一条含糊的指令提出异议，它会用一个看起来合理的猜测把空缺补上，然后交给你一份自洽而错误的东西。拿到好结果的人靠的不是提示词写得多巧，而是他们一直在维护可复用的上下文：提交进仓库的约定文件、每一件反复出现的任务都存下的一份流程、一份智能体在动手探索之前就会读的项目记忆，以及用截图或草图代替整段描述界面的文字。

编码智能体应该跑在本机还是远程机器上？

两者都要，按任务来选。任何你想盯着看、想中途打断或者纠正的活，都放在你面前这台机器上。又长、交代得清楚、没有模糊地带的活，放到另一台你自己的电脑或者一台通过 SSH 连上的服务器上，这样一个两小时的任务就不会把你的笔记本扣为人质。做决定的问题不是算力，而是你需要介入的概率有多大。

简短版本

这份工作没有消失。它从编辑器里搬了出来，搬进了围着编辑器的那条链条。

如果这个月你只打算改一件事，那就选第一环。一旦对准的是错的问题，它下游的一切都是白费力气；而这也是唯一一个环节，在这里你一小时的注意力，仍然以一个没人量得出来的倍数胜过一小时的智能体时间。