某些不适合当程序员的程序员，在 AI 面前现了原形

你好，我是曹犟，欢迎关注我的公众号。

在上一篇《经理不提需求，代码就不能改》中，我写了一个创业做 To B 业务的朋友最近经历的合作冲突。

聊天的时候，他不仅吐槽了合作伙伴的流程，还吐槽了他们的程序员。他们没有使用 AI，手上的内部需求本来就做不完，因此非常排斥外部需求和临时尝试。朋友则觉得，有些想法只是修改几行文档、让 Agent 跑一下的事情，效果不好就回滚，没有必要等到经理正式提出需求才行动。

吐槽的时候，他给出了一个很尖锐的判断。他说，过去互联网行业的高速发展，让很多并不喜欢、甚至并不适合做程序员的人进入了这个行业；现在行业进入新的阶段，这些人开始被自然过滤掉，真正喜欢也适合做这件事的人，跟 AI 一起工作，反而如鱼得水。

这句话很不客气，也很容易伤人。找工作困难当然是真实存在的，企业缩减岗位、初级岗位减少，也不能全部解释成谁不够努力、谁不适合这一行。但他的观察里其实的确有一个值得讨论的问题：

过去二十多年的互联网行业，是不是确实产生了一批不需要真正适合程序员工作，也可以长期留在程序员岗位上的人？

不喜欢和不适合不是一回事

需要先说清楚，我并不认为，一个人必须热爱工作，才有资格从事一份职业。

大部分人工作，首先是为了获得收入、养活自己。只要能够按要求完成职责，对得起自己的报酬，就是合格的职业人。程序员也不是信仰，更没有必要把喜欢加班、周末研究新框架、愿意为公司无条件付出包装成“热爱技术”。

不喜欢编程，也不一定意味着不适合做程序员。有些人对代码本身没有那么强的兴趣，但逻辑清楚、做事严谨、责任心很强，依然可以成为非常靠谱的工程师。反过来，有些人很喜欢研究技术，每天追新热点，却对用户、业务和系统稳定性毫无兴趣，反而未必适合在工业界做程序员。

所以，这里的“适合”，并不是看一个人能不能为了代码废寝忘食，而是看他是否适应程序员这项工作的基本特点：面对不确定的问题，持续学习新的工具，自己判断方案是否合理，并且愿意对最终运行结果负责。

喜欢写代码和喜欢解决问题，并不是一回事。AI 真正拉开差距的，可能是后者。

互联网把程序员变成了流水线岗位

早期的软件开发，并不是一项高度标准化的工作。一个程序员经常需要自己理解问题、设计方案、编写代码、测试上线，再根据真实反馈继续修改。技术只是其中的一部分，更重要的是把一个不确定的问题定义清楚，逐步分解，最终变成能够运行的系统。

互联网行业快速扩张之后，情况发生了变化。大厂、中厂、小厂们，需要在很短时间里组建大规模研发团队，于是，软件开发被拆成了越来越明确的岗位和流程：业务提出问题，产品经理整理需求，架构师设计方案，程序员实现功能，测试人员负责验收，运维人员负责上线。

这种分工当然有价值，它降低了大规模协作的难度，降低了对人的要求。它让经验有限的程序员能够从一个局部模块开始工作，逐步成长。但与此同时，它也产生了一个副作用：程序员可以只对需求负责，不再对问题负责。

需求由产品经理定义，优先级由经理决定，方案由架构师把关，质量由测试人员验收。程序员需要做的，就是把已经整理好的需求变成代码。至于需求本身是否合理、用户为什么需要它、上线之后有没有真正解决问题，都可以被视为其它岗位的职责。

这种分工走到极致，程序员甚至可以不再直接面对代码背后的问题。我听说过一些对日软件外包项目，会把需求、接口、判断分支和异常处理全部拆进 Excel。程序员拿到表格之后，就像填表一样，一格一格地把规格翻译成代码。做到最后，他面对的已经不是一个需要理解和解决的问题，而是一张等待被执行的规格表。

这套方式当然有现实原因。跨公司、跨语言交付，需要尽量减少沟通歧义，把每一步写清楚，确实更容易控制交付质量。但当流程长期替程序员完成了大部分判断，程序员自然也会逐渐退化成机械的执行者。

在这套分工里，一个人即使不喜欢不确定性，不愿意跟用户沟通，不想主动学习新的工作方式，只要能够按时完成分配的模块，依然可以成为一个合格的螺丝钉。

行业高速增长的时候，公司有足够多的需求、预算和岗位容纳这些螺丝钉。只要不断有新项目、新功能和新系统要开发，“把需求变成代码”本身就是一项有价值的工作。一个人适不适合从零开始解决问题，并不会那么快暴露出来。

AI 拿走了岗位分工提供的保护

AI 最先改变的，恰好是那些已经被定义清楚的执行工作。

需求足够明确，AI 可以生成代码；接口和输入输出清楚，AI 可以完成对接；验收标准明确，AI 可以补测试、运行测试，再根据错误继续修改。程序员过去在流水线上承担的很多工作，天然具备数字化、可验证、能反馈和可回滚的特点，也正是 AI 最容易形成闭环的地方。

如果一个程序员的主要价值，就是等待别人把问题定义清楚，再把需求单变成代码，那么，他面对的已经不只是另一个效率更高的程序员，而是一个不休息、可以并行工作、能力还在持续提升、成本还在持续下降的 AI。

这并不是说 AI 已经能够独立替代一个完整的程序员。真实系统里还有大量业务上下文、架构取舍、安全要求和异常情况，需要有经验的人判断。但 AI 至少已经让一件事情变得越来越清楚：

完成一个定义清楚的任务，正在从程序员的核心价值，变成一种越来越容易获得的基础能力。

朋友吐槽的合作方程序员，就是这种变化的一个缩影。对方看到临时想法，首先想到的是内部需求已经做不完，为什么还要增加工作；朋友看到同一个想法，想到的则是修改成本很低，为什么不先测试一下。

两个人的差别当然有工具因素。没有 AI 的时候，每个新想法都意味着额外的分析、开发和测试，排斥临时需求完全可以理解。但差别又不只是工具。一个人把自己理解成需求的执行者，另一个人则把自己理解成问题的解决者。AI 只是让这两种思维方式的差异更快呈现出来。

过去，岗位分工可以把这种差别隐藏很久。现在，AI 拿走了大量执行工作之后，一个人会不会主动发现问题、能不能提出假设、知不知道怎样验证、愿不愿意承担结果，就开始变得很难隐藏。

这种变化也不只发生在某一个程序员身上。前段时间，一篇在朋友圈刷屏的文章用了一个很抓眼球的说法：“第一个被 AI 做空的国家，出现了。”它说的是印度。

这个标题可能有点夸张，但背后的市场反应是真实的。今年 2 月 4 日，在 Anthropic 发布一批面向法律、销售、营销和数据分析等企业场景的自动化工具之后，印度软件出口商股价单日下跌约 6%，创下近六年来最差表现；当周相关股票市值蒸发约 225 亿美元。市场担心的，正是 AI 能力越来越强后，印度 IT 外包长期依赖的大量人力和工时计费模式还能不能维持。

印度 IT 外包过去依靠大规模招聘性价比足够高、又懂英语的程序员，来完成定义清楚的任务；现在 AI 最擅长的，恰好也是完成这些已经被拆解清楚的任务。所以，那个标题所描述的，也许不是印度整个科技行业已经完蛋，而是依靠增加程序员数量、出售人头和工时来增长的传统外包模式，正在被 AI 重新定价。

从这个角度来说，AI 没有让某些程序员突然变得不合格，只是拿掉了原有流程给他们提供的保护。

Coding Agent 的渗透率，可能还远没有到顶

围绕同一个问题，之前我和群里另一位做投资的朋友讨论过 Coding Agent 的渗透率。一位投了 Anthropic 的投资人，最近想卖给他一部分 Anthropic 的股份，兜售时讲的核心故事，就是 Coding 的渗透率还远没有到顶，Anthropic 还有很大的增长空间。

但这位朋友并不相信这个故事。他认为，Coding 虽然是这一轮 AI 最成功的应用，但过去一段时间的高速增长可能已经接近阶段性天花板。

这次听完这个程序员的故事，我又觉得，这个问题可能取决于我们怎样定义“渗透率”。

如果渗透率指的是，有多少程序员听说过 Coding Agent、试用过产品或者购买了订阅，那么新增用户的增长完全可能逐渐放缓。但如果渗透率指的是，有多少程序员真正把 Coding Agent 放进日常工作，又有多少团队为此改变了研发流程，那么，情况可能完全不同。

合作伙伴的那位程序员可能根本没有使用 AI。或者说，哪怕已经使用了，也只是把它当成一个更强的代码补全工具：依然是 PM 负责定义需求，RD 只接收一个明确任务，只不过这个任务中越来越多的代码改由 AI 生成而已。

AI 工具的账号已经开通，代码也确实写快了，但一个人工作的范围、团队的协作方式和最终承担的责任都没有发生变化。

真正更深的 Coding Agent 渗透，是一个程序员可以自己解决相对模糊的问题，自己定义清楚问题，组织好上下文，让 Agent 完成实现，再验证结果、处理异常并安全回滚；团队也允许离问题最近的人发起这种低成本实验，而不是所有事情都等待 PM 或者经理提需求。

Coding Agent 的工具渗透率可能正在放缓，但它对程序员工作方式的渗透还远没有完成。

如果这个判断成立，那么，Agent 对程序员的重新筛选可能也只是刚刚开始。今天的差别还是一个人有没有使用 Agent 来帮自己写代码，接下来的差别则会变成，他有没有因为 Agent 重新定义自己的工作。

真正如鱼得水的人，并不只是代码写得快

朋友说，真正喜欢也适合这一行的人，跟 Agent 一起工作会如鱼得水。我个人认同这个判断的一部分，但需要重新解释一下什么叫“如鱼得水”。

它并不是指一个人安装了最新的 Coding Agent，每天生成的代码量是过去的十倍。代码生成得越多，不代表解决的问题越多；如果问题定义错了，Agent 只会帮助团队用更快的速度做出错误产品，或者在同样的时间内写出更多的 bug。

真正如鱼得水的人，是把 Agent 当成扩大自己工作边界的工具。他原来只会写后端代码，现在可以让 Agent 帮忙完成前端、测试和文档；原来一个想法需要排进开发计划才能验证，现在可以先做一个 demo，拿给真实用户试；原来大量时间花在执行上，现在可以把更多精力放在理解问题、判断方案和验收结果上。

更重要的是，这些人通常并不满足于“需求已经完成”。他会继续追问：用户为什么提出这个需求？现在的方案是不是最简单的？上线之后用户真的在用吗？如果结果不好，是实现错了，还是一开始对问题的理解就错了？

这种工作方式以前当然也存在，只是成本比较高。一个人即使主动发现问题，往往也需要协调产品、设计、研发和测试，才能把想法变成一个可以验证的产品变更。AI 降低了跨越这些岗位边界的成本，所以，那些原本就喜欢独立解决问题的人，能力边界会迅速扩大。

而那些习惯等待清晰任务、只愿意完成岗位范围内工作的人，则只会觉得 AI 带来了更多要求。以前只需要写代码，现在还需要自己理解需求、组织上下文、验收结果、处理错误，甚至要面对客户和业务结果。工具越强，工作反而越累。

AI 对不同人的影响并不对称。它让主动解决问题的人获得了杠杆，也让被动完成任务的人失去了掩护。

会用 AI，也不代表适合当程序员

当然，不能把会不会使用 AI，直接作为判断一个人是否适合当程序员的标准。

有些程序员暂时不用 AI，可能是因为公司不允许、代码不能离开内部环境、遗留系统缺乏必要的文档和测试，或者他承担的工作确实不适合交给当前的模型。这些都是具体限制，跟一个人是否愿意学习、是否有责任心没有直接关系。

反过来，有些人每天都在使用 AI，代码生成得非常快，却不看实现细节、不做测试、不理解架构，也不知道出错之后怎样恢复。这种人看起来非常拥抱 AI，实际上只是把“等产品经理给需求”，变成了“等 AI 给答案”。

以前他依赖产品经理、架构师和测试人员替自己完成判断，现在则依赖 AI。工具变了，工作方式并没有变化。

所以，真正的分界线并不是会不会使用 AI，而是能不能借助 AI 承担一个更完整的问题。能不能说清楚目标和边界，能不能判断产出是否正确，能不能在结果不符合预期时找到原因，也能不能对上线之后的真实结果负责。

这些能力过去就重要，只是在代码生产还很昂贵的时候，企业愿意先为执行能力付费。现在代码越来越便宜，隐藏在代码背后的判断和责任，自然会被重新定价。

找工作困难，不是一场道德审判

朋友原来的表述里还有一句：“现在并不是找工作难，只是在天然过滤不喜欢、不适合的人。”

找工作确实变难了。行业增长放缓、企业缩减岗位、AI 提升人效，都会减少程序员的就业机会。一个优秀的程序员可能因为公司业务失败失去工作，一个愿意学习的年轻人也可能因为缺乏岗位，连证明自己的机会都得不到。就业市场不是一场精确的能力考试，被裁员更不是一个人不适合这项职业的证明。

所以，不能用“自然过滤”解释所有人的处境，更不能站在暂时安全的位置上，把别人的失业归结为不够热爱。

但这并不妨碍我们承认另一件事情：当行业不再高速增长，企业开始重新计算每个岗位的价值，AI 又接管了大量执行工作，那些长期只完成分配任务、不愿意扩大责任边界的程序员，确实会面临越来越大的压力。

这不是对人的道德评价，而是程序员这项工作的内容客观上确实发生了变化。

写在最后

过去很长一段时间，我们习惯用“能不能把需求写成代码”来判断一个人是不是合格的程序员。因为代码生产本身很昂贵，只要能够稳定完成开发任务，就足以创造价值。

现在，AI 正在让代码生产变得越来越便宜。程序员的价值也会逐步回到代码背后的部分：理解一个模糊问题，选择合适的方案，验证真实结果，并且在出错之后承担责任。

有些程序员会因此交付出前所未有的成果，原来需要几个人完成的事情，现在一个人带着 AI 就能干得更好；另一些程序员则会发现，自己过去最熟悉、也最依赖的那部分工作，恰好是 AI 最容易替代的部分。

某些不适合当程序员的程序员，确实会在 AI 面前现出原形。但这场变化暴露出来的，不只是某些人的不适应，也包括程序员这个岗位旧有定义的失效。

没人跟你提需求之后，你还知不知道应该解决什么问题，可能才是 AI 时代更重要的判断标准。