AI编程时代，程序员真的“要被煮熟了”吗？

一个Reddit热帖引发的行业焦虑

最近，Reddit上一个标题为“We're cooked”的帖子在开发者社区迅速发酵。发帖人描述了一种让许多同行既羡慕又不安的日常：登录工作，花30分钟给Claude写提示词、审查它生成的代码，然后开会，剩下的时间全用来捣鼓个人项目。他坦言自己已经一年没正经写过代码，但完成的故事点却是同事的两倍，经理甚至把他当成“10x工程师”。

这种状态的荒诞感在于：他一边享受着AI带来的巨大杠杆，一边陷入深深的自我怀疑——“我牺牲了一切才成为好开发者，现在该去考个水管工执照吗？”帖子最后他问了一个很多人的心声：我们还有多少时间？

AI到底替代了什么样的编码工作？

仔细拆解这个案例，会发现AI替代的并非全部编程活动，而是代码生成环节。Claude等大模型擅长根据自然语言描述输出结构清晰、语法正确的函数或模块，这恰恰是传统开发中耗时且重复度较高的部分。发帖人之所以能轻松完成两倍故事点，是因为他把“写代码”转化成了“审代码”。

但这并不意味着工程能力归零。审查AI代码需要快速识别逻辑漏洞、边界条件、性能瓶颈和安全风险，这些能力仍然是资深开发者的护城河。问题在于，当生成变得廉价，审查和调试的瓶颈反而被放大了。很多团队发现，AI能写出80分的代码，但最后20分要花比从头写更多的时间。

故事点（Story Point） 是敏捷开发中用于估算任务相对复杂度的单位，而非绝对工时。它通常参考斐波那契数列（1、2、3、5、8等），由团队通过计划扑克等方式共同确定。故事点的核心假设是：估算应该基于工作量、复杂度和风险的相对大小，而不是具体花费多少小时。正因如此，故事点天然带有主观性，不同团队之间不可直接比较。在AI辅助编程的语境下，故事点的局限性被进一步放大：一个开发者可以用AI快速生成大量代码，让任务看起来“完成”了，但代码质量、可维护性和后续返工成本并未被纳入估算。发帖人声称自己完成的故事点是同事的两倍，这个数字只能说明他在当前团队的估算体系下显得产出更高，并不能直接等同于两倍的真实工程价值。

公司的“后知后觉”与效率幻觉

发帖人提到一个关键观察：“公司已经跟上了，但反思需要时间。”这句话揭示了当前企业采用AI的典型节奏——先拥抱工具，再调整流程，最后才重新定义绩效。

眼下，大多数公司仍用故事点、代码行数、PR数量来衡量产出，这些指标在AI辅助下极易被“刷高”。一个善于写提示词的工程师可以在短时间内生成大量看起来不错的代码，但系统的长期可维护性、架构一致性、技术债务却可能悄悄恶化。

更微妙的是，经理眼中的“10x工程师”可能只是提示词工程师加上快速审查者。这种效率提升是真实的，但它是否可持续？当所有人都学会用AI，这种比较优势就会消失。

技术债务（Technical Debt） 是沃德·坎宁安提出的隐喻，指团队为了短期速度而选择次优方案，从而在未来需要付出额外成本来修正。就像金融债务一样，技术债务会“产生利息”——随着时间推移，修复成本越来越高。AI生成的代码尤其容易制造隐性技术债务：它可能语法正确、测试通过，但在架构一致性、错误处理、日志规范、边界条件等方面留下隐患。当这些代码大量涌入代码库，审查者又因为“看起来没问题”而放行时，债务就在无声中累积。更危险的是，传统技术债务通常由开发者主动决策产生，团队至少知道“这里欠了债”；而AI辅助下的债务往往分散在大量微小决策中，缺乏统一的记录和意识，等到系统出现性能退化或故障频发时，追溯和偿还的难度会显著增加。

水管工执照是个隐喻，但方向错了

帖子里“去考水管工执照”的玩笑，折射出技术从业者对技能贬值的恐惧。但把AI编程等同于“编程已死”是过度反应。历史上，高级语言、框架、云服务都曾引发类似焦虑，结果只是提高了抽象层级。

AI编程工具真正改变的是开发者技能组合的权重。写样板代码的能力在贬值，而系统设计、需求拆解、质量把关、跨团队沟通的价值在上升。发帖人能在30分钟内完成工作，恰恰说明他具备将模糊需求转化为精确提示词的能力，以及快速判断代码质量的眼力——这些不是“不会编程”，而是编程的形式变了。

抽象层级（Level of Abstraction） 是理解编程演进的关键概念。从机器码到汇编语言，再到高级语言、框架、云服务，每一次技术跃迁都在提高抽象层级：开发者不再直接操作底层细节，而是用更接近人类思维的方式描述意图，由工具链负责翻译和执行。AI编程工具延续了这一趋势，把“自然语言描述”作为新的抽象入口。但抽象层级提升并不意味着底层知识变得无关紧要——相反，当抽象层出现泄漏（如性能问题、安全漏洞、边界异常）时，能够向下穿透、定位根因的人仍然稀缺。发帖人能在30分钟内完成工作，正是因为他站在足够高的抽象层级上，同时保留了向下审查的能力。把AI编程简单理解为“编程已死”，本质上是把“写代码”等同于“编程”，忽略了编程活动在抽象层级上的迁移。

我们还有多少时间？

发帖人问“How much time do we think we have?”这个问题没有统一答案，但可以分角色来看。

对于初级开发者，纯靠刷题和写CRUD入行的路径正在收窄，因为AI最擅长做的就是这类工作。对于中级开发者，如果不主动向上游（架构、产品理解）或下游（运维、安全）移动，压力会逐步增大。对于资深开发者，AI是杠杆而非替代，但需要重新证明自己的价值不在写代码本身，而在判断力。

至于时间窗口，与其猜测“还有几年”，不如关注两个信号：一是公司是否开始用AI产出直接考核绩效，二是招聘需求是否从“会写代码”转向“会审查和设计”。这两个信号已经在部分公司出现，但全面铺开仍需时间。

把焦虑转化为具体的行动

面对AI编程的冲击，空泛的焦虑没有意义。更实际的做法是：

重新定义自己的核心能力——把“能写多少代码”换成“能解决多复杂的问题”。主动承担需要跨模块协调、权衡取舍的任务，这些是AI短期内难以独立完成的。

成为AI代码的质量守门人——深入研究代码审查、测试策略、安全审计，让AI的产出经过你的手变得更可靠。这是当前最稀缺的能力之一。

保持对底层原理的接触——即使不天天写代码，也要理解运行时、网络、数据结构和系统设计的基本原理。否则你无法判断AI给出的方案是否合理。

发帖人最后更新说自己在做个人项目DebriefReconstructed，这其实是个积极的信号：当日常工作被AI压缩，释放出的时间可以用来探索更有创造性的方向。与其问“我们还有多少时间”，不如问“这段时间我用来做什么”。