从编写者到管理者：智能体如何改变开发者的工作

智能体大幅降低了编写代码的成本，却没有降低弄清楚要构建什么、检查结果是否正确的成本。因此，与智能体协作最值得关注的部分发生在写代码之前和之后：谁来定义任务，谁来判断结果好不好，以及该把多少工作交给智能体。

下面会梳理过去两年的研究和报告如何描述这件事：与智能体协作的四种方式、如何按任务选择方式，以及所谓的"意图与质量标准"。后半部分会谈谈，为什么开发者的职责不再局限于编写代码。数据截至 2026 年 9 月。数字分别列在带有来源链接的说明框中。转述作者观点时会注明出处，我自己的结论也会明确标出。

与智能体协作的四种方式

2026 年 5 月，Microsoft 的 Jared Spataro 提出了一个很清晰的框架，描述人和 AI 如何分工。这个框架不难理解，开发者也能从中认出自己使用工具一路走来的历程。

层级越高，您亲自写的越少，事先做决定、事后检查的工作就越多。编写者在写代码时把质量标准放在心里。主管看不到代码是怎样逐步写出来的，因此凡是对他重要的内容，都要在开工前说清楚，并在完成后检查。这里提到协调者只是点到为止：这是一个涉及专门工具的大主题，等前三种方式运转稳定后再深入也不迟。

按任务选择方式，而不是爬梯子

很容易把这个框架看成一架梯子：先当编写者，再逐步成为协调者，爬得越高就越好。Spataro 明确表达了相反的观点。目标不是把每项任务都升级到第四种方式，而是为每类工作流选合适的方式。

实际选择时，主要看四个问题：

• 目标有多明确。如果您自己还不知道预期结果是什么，现在就把整个任务交出去还太早；
• 结果能否自动检查。完善的测试能让您放心地多交一些工作给智能体，因为检查可以捕获错误，不必全靠您自己盯着；
• 出错的代价有多大。提示文字里的拼写错误很容易修正，金额算错则代价高昂；
• 任务是否重复出现。一次性任务不值得单独搭建流程，每周都要做的任务则完全值得。

看看具体任务如何选择：

我觉得这些数字值得记在心里。大多数人保持谨慎，不代表他们落后：大家会根据出错的代价选择协作方式，这样做很合理。如果您在错误代价高的任务中采用编辑者的方式，并不算"没有充分利用"智能体。

在 Claude Code 中，您可以直接设置这种协作方式。Plan mode 和权限规则就像一个由您亲自调节的控制器。任务出错代价高时，就让智能体先出计划再动手，并要求高风险操作前先确认；日常任务则可以把更多工作交给智能体。

意图与质量标准

交给智能体的工作越多，开始前说清楚要求就越重要。Microsoft 的研究这样表述：最有效的 AI 用户，不是做得更多、更快的人，而是围绕只有人能做到的事情建立自身价值的人。具体来说，就是明确表达意图（描述期望的结果和质量标准），并想清楚如何在人与 AI 之间分配工作。

在软件开发中，这个想法早有熟悉的叫法。意图就是规格说明：要做什么、为什么做。质量标准就是验收条件，也就是 Scrum 所说的 Definition of Done：一份说明何时算完成的条件清单。下文就简称为完成标准。

Microsoft 的 Daniel Epstein 运用 Agile 构建智能体，他在 Agentic-Agile 系列的第一篇文章中用一句话概括（2026 年 5 月 19 日）："Every capability is an issue. Every issue has acceptance criteria." 每项能力都是一个 issue，每个 issue 都有验收条件。

把任务写成面向两类读者的内容很方便。面向人，说明为什么需要这项工作、为谁解决问题；面向智能体，写清楚要做什么、如何检查，以及哪些内容不要动。下面用一个教学示例，看看同一条请求修改前后的样子。修改后的第一段写给人看，其余内容写给智能体。

修改前：

做一个把开支导出为 CSV 的功能，弄得正常一点。

修改后：

目的：会计每个月都要手动把团队开支抄到自己的表格里。要花一个小时，还容易算错金额。

任务：在月度开支页面添加"导出为 CSV"按钮。

完成条件：
- 文件可以在表格软件中双击打开，中文名称无需手动设置编码就能正常显示；
- 每行对应一笔开支，第一行是列名；
- 无需修改单元格，就能用公式汇总金额。

不要修改：开支的存储格式和现有列表页面。
先给我看计划，以及每项条件的检查方法。

修改后的请求几乎没有给智能体留下猜测空间。更重要的是，您有了对照结果的依据：三项条件手动检查只需几分钟。修改前的"正常一点"无法验证，只能相信它做到了。

智能体不知道怎样才算好

从这里开始，主要是我根据数据得出的结论，并非数据本身。先说明这一点，免得把观点说成研究结果。

智能体能做很多事：阅读陌生项目、查找错误原因、编写实现、运行测试，还能解释自己做了什么。但有一件事它做不到：自行判断对这些用户和这项业务来说，怎样才算"做好了"。没有明确标准时，它会选一个看起来说得过去的中规中矩方案，然后信心十足地汇报说已经完成。代码可能写得很整洁，解决的问题却仍然不对。

代码里没有"好"的定义。好不好取决于谁会使用结果、这个人最在意什么，以及哪些错误不能接受。在导出示例中，智能体完全可能生成技术上正确的 CSV，但会计打开后看到的却是一堆乱码。从代码的角度看一切正常；从任务的角度看，却没有达标。

结论很直接：设定标准，并据此检查结果，是无法委派的一部分工作。智能体可以帮您拟定标准、提出澄清问题、建议检查方法。但标准是否合适，仍由您来判断。

先了解业务流程

质量标准从哪里来？几乎从来不是从代码里来的，而是来自业务流程：谁会打开文件，接下来会怎么处理；如果漏了一行，或者金额四舍五入错了，会发生什么。

"中文名称无需手动设置就能正常显示"这条要求，并非因为 CSV 就该这么写。它来自有人询问会计如何打开文件，发现对方只是双击文件，并没有使用导入向导。了解业务流程的开发者会立即写下这条标准；不了解流程的人，则要等一个月后从投诉中得知。

企业已经注意到这一点，并开始调整岗位分工。

关于这件事，也有相反的观点，值得了解。例如，咨询公司 Converteo 在自己的博客中把产品经理、设计师和 AI product builder 的角色描述为互补，而非竞争：产品经理负责回答"为什么做"，设计师关注用户，AI product builder 则快速把想法变成可用原型。Converteo 自己也销售这方面的服务。我不会押注其中任何一种说法。对您来说，实际结论都一样：懂得客户业务流程的开发者，比等着收到完美编写的 ticket 的人更有价值。

沟通也是工作工具

过去，soft skills 常被说成技术能力之外的加分项。智能体改变了这一点。质量标准存在于人的头脑中，而不是代码仓库里。要弄清楚这些标准，只能通过沟通。

实际上，下面这些都成了工作的一部分：

• 询问。别只问"要做什么"，还要问"您会怎样使用结果"，这样得到的回答更准确；
• 澄清。边界情况还没变成 bug 时就问清楚：没有类别的开支该怎么处理？
• 记录。只留在对话里的约定，智能体看不到，同事也会忘记；
• 确认范围。说清任务包含什么、不包含什么；有人要求"顺便改一下"时，要能说明"这是另一个任务"；
• 解释取舍。"不选时间范围，一天能完成；加上时间范围，则需要三天"。决定权在客户手里，但由您提供选项。

这些技能都与代码无关，却都会直接影响智能体的工作。换句话说，您与人的沟通质量，会转化为任务说明的质量。

每个人都有点像 CEO

把这些内容放在一起，就能看到一个熟悉的模式：设定目标、定义标准、分配工作、检查结果并为结果负责，这些都是管理者的工作。与智能体协作时，开发者每天都会做这些事，只是规模小一些。

CEO 这个比喻有一个优点：它准确指出了责任归属。CEO 几乎可以把所有事情都委派出去，唯独不能卸下对结果的责任。智能体也是如此。如果智能体导出的文件弄坏了会计的表格，承担责任的不会是智能体。

也要说明这个比喻不代表什么。它不意味着升职，也不会有人因为启动了三个智能体就成为管理者。更可能的是，管理者的技能会比以往更早派上用场，第一份工作就需要。还有一个风险：开发者过去长期通过亲手写代码来成长，而这条路正在改变。理解您从智能体那里接收的代码仍然必不可少。否则，检查就会变成一句"看起来能用"。

如何看待这些数据

以上数据都由销售 AI 或相关产品的公司发布。这不代表数据是假的，但阅读时值得把这一点考虑进去。简要汇总如下：

这里所有百分比都是人们在某一时点的自我评估。它们反映人们的想法和预期，而不是实际发生的事情。Work Trend Index 2026 的作者明确指出，分析中的关联是统计关联，不代表因果关系。

看到任何关于 AI 和工作的数字，都可以问三个问题：谁为这项研究付费？具体测量了什么，是观点、预期还是实际结果？调查了哪些人，他们和您相似吗？如果答案让您信服，就可以参考这个数字；如果不能，它仍可能有参考价值，只是分量要轻一些。

这一切的意义

上文那些听起来像报告术语的内容，在使用 Claude Code 时会转化为一些具体习惯：

• 修改前先制定计划 - 这就是表达意图。先请智能体说明准备修改什么、如何修改，再与您的预期对照；
• 在请求中写明验收条件 - 这就是您的完成标准。用两三个可检查的条件代替"弄得正常一点"；
• 工作模式和权限规则 - 用来选择协作方式。错误代价越高，智能体就越应该停下来征求确认；
• 查看 diff 并认真检查 - 根据您的标准评估结果，而不是只看智能体的报告；
• 简要总结：完成了什么、如何检查、哪些尚未检查 - 对结果负责，这份责任无法转交给智能体。

数据截至 2026 年 9 月。这个领域的研究频繁发布，数字往往比结论更快过时。