AI Coding 流行后，代码生成飞快，写代码变得像呼吸喝水一样容易，以至于更多的人焦虑：程序员的门槛是不是变得越来越低？过几年我是不是要被 AI 取代了？

我的观点是，AI 正在降低“写代码”的门槛，同时抬高“做好软件”的门槛。且随着 AI Coding 越来越强，这个差距会越来越明显。

AI 写代码带来的新问题

AI Coding 有个关键问题绕不开：AI 写的烂代码该怎么办？AI 拉了一地浮毛碎屑，谁收拾？

可能有人讲：“管代码质量怎样，只要能跑，结果对就好了，用户又无感知代码健壮性。”

问题在于，软件会不断迭代。Agent 处理代码确实快，也确实聪明，但是和人类一样，也会受到烂代码的影响。代码烂到一定程度，Agent 就处理不了，开始原地打转，最后把烂摊子越搞越大。

而如果一直让 Agent 做下去，不去清理烂摊子，不还技术债，它的速度反而会越来越慢。比如说让 Agent 改一个接口，它改完后发现某个测试挂了；修测试的时候又破坏了其他地方，再修再破坏，再破坏再修，最后不停绕圈子。

而现实这种情况确实存在：公司普遍讲究 AI 渗透率，以至于项目对开发者来讲越来越像黑盒，我们对项目的熟悉程度在变弱，背负了很多隐蔽的技术债。

于是大家开始往 AGENTS.md 里堆规则

发现 Agent 开始搞事情以后，人类当然不会坐视不管。

最直接的办法是什么？写规则。

于是很多项目开始出现越来越长的AGENTS.md：在 AGENTS.md 堆规则，每逢一处坏代码加一条。

到了最后，你的 AGENTS.md 可能是这样的：

规范守则:不要修改公共接口。不要随意增加依赖。不要重复实现已有逻辑。必须编写测试。不要违反单一职责原则。不要引入循环依赖。必须保持向后兼容。......整洁代码要求:控制每个方法的圈复杂度。一个方法不能太长。一个类不能承担太多职责。避免过深的嵌套。不要使用魔法数字。......

看起来严肃，但这些模型对待规则的态度，有时像《加勒比海盗》里海盗法典一样，听起来是规则，但对它们来说更像是一堆建议。

背后是存在技术原因的：这和 Lost in the Middle 现象有关。

简单讲，模型对于上下文中不同位置的信息，利用能力并不是完全均匀的。模型的上下文窗口越大，放在最前面和最后面的内容就更容易被关注，而夹在中间的内容更容易被忽略，甚至像消失了一样。

比如你写了一段很长的提示词，开头三句它记得很清楚，当作高优先级指令，但到了第五十句、第八十句，这些内容可能就被丢到上下文中间的某个角落了。

引入多 Agent 解决加勒比海盗问题

尝试多个 Agent 彼此协作、相互交接是一种解决上下文失效的方法：一个负责写代码，下一个负责审查，再下一个负责测试和强化。虽然有巨大的通信开销，但整体速度仍然比人类快得多。

第一，可以并行运行多个 Agent；第二，当任务聚焦在单一任务时，可以更好地控制上下文窗口，Lost in the Middle 的问题会减轻。你甚至可以设置这样一套机制：让 Agent 出生，完成任务，消失，下一个 Agent 进来时，面对的是干净的上下文窗口。

其优点是最终得到的程序质量会非常高；缺点是因为引入了通信成本导致启动时间更长，一个 Agent 可能需要 10 到 15 秒才能启动，并且理解上下文。给单个 Agent 任务，可能五分钟就完成了，但是结果是否可靠很难说。而采用以上流程，可能需要一个小时。

但是依然划算，因为让人类完成同样的工作可能需要半天。

AI 降低了编码门槛，却提高了工程门槛

所以我越来越倾向于认为：AI 并没有真正降低软件开发的门槛，它只是改变了门槛的位置。

过去的门槛是：你能不能写出这段代码？

现在越来越变成：你能不能判断这段代码该不该这样写？

过去我们关心：怎么实现一个功能？

现在越来越需要关心：

这个功能应该放在哪里？应该由谁实现？哪些东西不应该改？什么时候应该拆任务？什么时候应该停下来重构？什么时候 Agent 已经开始犯错？

这就像计算器普及以后，人们并没有不再需要数学，只是我们不再把大量精力放在手算987654 × 123456上。

真正重要的是：你知道什么时候该计算、算什么、为什么算，以及如何判断答案是否合理。

AI Coding 也是一样。

真正稀缺的能力在向上移动

当代码生成速度提升到夸张的数量级，代码变便宜，什么变珍贵？

可能其他人已经讲过很多次：组织复杂性的能力、判断代码质量的能力、识别问题的能力、建立约束的能力、做最终决策的能力......

我最近在思考的是，对于刚入行的程序员，既然 AI 已经吞掉了大量写码工作，该如何提升自己的编程能力？

我的想法是：作为资历尚浅的新人，不应该全盘丢掉“古法编程”，也不应该一上来就把自己变成 Agent 的产品经理。

首先程序员学习编程的方式都应该是写代码。一个新人应该先写上至少一年的代码，这样才能真正知道 Agent 究竟在处理什么问题。

下一步，当入职一家大量使用 Agent 的公司时，你可以把自己 “cosplay” 成一个 Agent。你的 leader 负责设计架构拆解任务等等，你负责和 Agent 一样的任务，让你接受和 Agent 一样的确定性工具约束。接需求 -> 阅读代码 -> 修改代码 -> 自测并提交 -> 接受 review 并修改，在这种状态下待上几个月，虽然产出很低，但是能够学到非常多东西。

等通过了这种严酷考验，也许你才会被信任去亲自运行一个 Agent。新人不能完全丢掉代码。在学习的路上，我们都必须从最基础的东西开始，再到处理 Agent 级别的工作，学习使用确定性工具，最后才能在监督下真正开始运行 Agent。