上周有篇文章「AI is a tool and using it well takes skill」在 Hacker News 上引起了广泛的讨论。它讨论了一个问题：现在的 LLM 到底还是一种工具，还是已经开始替人完成越来越多工作。
作者认为，就算模型能写代码、查资料、调用工具，人还是要告诉它具体要做什么，也要验收最后的结果。出了问题，还得继续让 AI 调整方向、重新处理。AI 能做到什么是一回事，最后能发挥到什么程度，也和使用者本身有很大关系。
AI 工具越来越强之后，很容易让人产生一种感觉：大家用的模型都差不多，开发者之间的差距应该也会跟着缩小。但同一个 Agent，到了不同人手里，效果还是可能差很多。
有人已经习惯让 Agent 负责大部分具体实现，自己主要定方向、检查结果；也有人和 AI 来回沟通很久，最后还是得自己改一遍代码。这里面当然有模型能力的原因，也和任务怎么交代、给到的信息够不够、最后有没有认真检查有关。
所以看 AI Coding，光看模型能写多少代码还不够。开发者怎么用它，也会影响最后能做成什么样。
代码之外
现在的 Coding Agent 已经很擅长处理边界清楚的任务了。
比如改一个接口、补几组测试，或者照着现有写法加一个相似功能。只要项目结构清楚，Agent 一般都能很快做完你派给它的任务。遇到报错的时候，它还会自己读日志、改代码、重新跑测试。过去一些需要开发者反复操作的事情，现在没有人类介入，Agent 自己也能接着往下做。
当中比较麻烦的是那些一开始就没那么清楚的任务。
像是“这里加个权限”“把登录流程优化一下”“这个页面偶尔会卡”此类任务，看起来只有一句话的需求，真正做起来可能会涉及很多东西。哪些接口还在被其他服务占用着，为什么这么设计现有逻辑、需要兼容哪些行为，发生冲突时优先保留什么……这些信息一般不会一开始就完整地写进需求里。
过去，开发者自己会在写代码的过程中慢慢把这些问题弄明白。现在，Agent 是接走了不少本该由开发者完成的具体代码实现，但对项目和需求的理解还是得由人来完成。
如果开发者自己都没想清楚，就把一个模糊的需求交给 Agent，它只能根据现有信息继续往下推。虽然多数时候，Agent 交付的东西八九不离十，但问题往往就出在差的那部分。
HN 评论区里就有人提过这么一个例子：同事用 Claude 分析一个 helpdesk 的问题。Claude 给的整体方向基本上没错，但它没有仔细核对过文档就自己补了一个配置参数的默认值，结果就是这个默认值出了问题。
这种错误很麻烦，因为一切看起来很没啥问题。既没有明显的报错信息，前后的逻辑也解释得通。如果 AI 使用者对这部分项目不熟的话，很容易就把 AI 给的东西当作真实前提，让它继续往下做。而错误只会越滚越大。
所以，现在看 AI Coding 除了看 Agent 能不能把代码写出来，还得看任务本身有没有先想清楚。
使用差距
这也解释了为什么大家聊 AI Coding 的效率时，体验差别会如此之大。
有人觉得 AI 提效明显，原来一周才能做完的事情，现在一天甚至更短时间就能完成；也有人觉得 Agent 经常跑偏，算上花在 AI 交付结果上的检查时间和返工时间，其实效率并没有比自己动手高多少。
这两种情况都存在，其中一个很大的区别，就是开发者对任务和项目本身有多熟。
如果是在熟悉的代码库中，用 Agent 往往会很顺。你知道这个功能大概会涉及到哪些地方，也知道哪些方案一看就不太对。Agent 可以帮你做掉大量的具体实现，你只需要在几个关键节点上看看方向有没有偏。
比如同样是“重构这块逻辑”，熟悉项目的人可能会先告诉 Agent 哪些接口不能动，让它先检查依赖，再补测试，最后才改实现。整个过程甚至不用特别复杂的 Prompt，只是因为他知道哪些信息应该提前说清楚。
但换到一个开发者完全陌生的项目里，情况就不一样了。
Agent 还是能很快给出代码，但你很难马上判断出它选的库合不合适，这种写法有没有问题，为什么这里要多加一层抽象。它每往前走一步，你都可能要重新查资料、补背景、确认方案。
代码生成得很快，理解和确认这些代码的时间却不一定会跟着少。
所以 AI Coding 到底能提效多少，很难只看模型本身。开发者越熟悉眼前的问题，越容易判断 Agent 给出的结果，也越容易把它的速度真正变成自己的效率。
这件事经常会被简单归结成“会不会写 Prompt”，但差别其实更多出在开发者对任务本身的理解上。
哪些信息要提前说，任务做到什么程度算结束，Agent 卡住时是该补信息，还是让它自己继续查资料，这些判断原来就一直存在于开发工作里。现在多了 Agent，这些原本用于沟通、设计和排查问题的经验，也开始影响任务该怎么交给 AI。
结果验证
AI Coding 还有一个明显的变化，代码生成得越快，后面的检查就越重要。
以前开发者自己写一个功能，很多判断其实是在写的过程中完成的。代码写到一半发现接口不通，开发者立马就能开始调整；写到某个模块，发现某个依赖忘记处理了，立马就能补上。理解、实现和检查，在之前的开发工作中很多时候就是混在一起的。
但 Agent 的节奏不太一样。
它可能十几分钟就改完一批文件，再把结果一次性交给你。以前分散在几个小时里的那些判断，现在更多会落到最后的 review 上。
如果开发者对项目很熟，看到一大段 diff，通常也不会真的从头到尾逐行看。他知道哪些修改只是顺带产生的，哪些模块风险更高，哪些地方可能影响其他调用方，所以能比较快地抓住重点。
但如果对项目本身不熟，能依赖的判断就会少很多。最后可能只能看测试有没有通过、程序能不能跑，再参考一下 Agent 自己的总结。
问题是，很多软件问题并不会马上表现出测试失败。
权限有没有被放宽，异常情况有没有漏掉，接口虽然还能用，但有没有破坏原来的约定，这些都需要对系统有一定了解以后，才能知道该往哪里看。
HN 那篇文章里也提到类似的问题：使用 AI 时，人还是要继续看结果、找错误，再根据反馈做调整。很多人愿意把 Agent 接入真实的开发环境中，也不是因为它永远不会犯错，而是因为出了问题以后，自己能比较快地看出来。
如果检查一遍的成本明显低于自己从头实现一遍，那这件事就值。反过来，如果连它写得对不对都很难判断，生成得再快，也不一定真的省时间。
这也是为什么有经验的开发者，很多时候更容易从 AI Coding 里拿到稳定的收益。Agent 帮他省掉了大量具体实现，而过去积累下来的经验，刚好可以用来判断哪些结果能接受，哪些地方还得再看一遍。
能力迁移
HN 评论里也有人提了另一种看法：今天还需要一点技巧才能做好的事情，过几个月模型升级以后，可能几句话就能完成。Prompt Engineering 去年还被看成新的专业能力，但现在回头看，很多技巧的有效期其实并不长。
这类变化一直都在发生。
以前不少事情要手把手告诉模型怎么做，现在 Agent 已经会自己规划任务、搜索代码库、调用工具。有些过去要反复调整的 Prompt，随着模型能力的提升，很快就没那么重要了。
如果所谓“会用 AI”，只是记住一套提示词和操作方法，那这部分能力确实很容易过时。
但 AI Coding 里真正会拉开差距的，还是那些和开发本身有关的判断。
你能不能看懂眼前的问题，知不知道什么方案算合理，能不能发现一个看起来没什么问题的结果里哪部分不对……这些判断能力，即使后面模型越来越好用，Prompt 越来越简单，也依旧少不了。
AI Coding 越来越强以后，开发者的能力也在慢慢换位置。过去很多经验体现在“代码怎么写”，现在有一部分开始转到“任务怎么交”和“结果怎么看”上。
虽然随着 AI 的发展，后面这种分工会继续发生变化。现在很多任务还得开发者自己拆，代码也要自己 review。再往后，这些工作里的一部分大概率也会继续交给 Agent，甚至让不同 Agent 互相检查。
但至少现在，AI Coding 还没有把所有开发者拉到同一个水平。
大家可以用同样的模型，也可以用同样的 Agent，但最后做出来的效果还是会有差别。更多时候，差别来自你对任务理解得有多深，知道哪些地方可以交给 AI，哪些地方还得自己判断。
AI Coding 用得好，本身就是一种技能。只是这项技能越来越少体现在“怎么和模型说话”，更多还是体现在你对开发本身有多熟。
