1. 这个问题背后藏着程序员最真实的焦虑“Is coding dying?”——当这个标题第一次跳进我视野时我正蹲在客户现场调试一个跑了三年的老系统。服务器风扇嗡嗡作响屏幕上密密麻麻的Python日志还在滚动而手机弹出推送“低代码平台融资超2亿美元”“AI自动生成前端页面仅需3秒”。那一刻我没点开链接而是下意识摸了摸键盘上被磨平的WASD键帽。这问题从来不是技术命题而是我们每天在工位上呼吸的空气招聘JD里“熟悉Copilot者优先”和“精通Spring Boot”并列出现实习生用ChatGPT写完单元测试后转头问我“为什么还要学JUnit断言”老板在周会上说“我们要用无代码工具快速验证MVP”语气像在讨论点外卖。核心关键词Towards AI - Medium指向的不是某篇具体文章而是一类典型现象技术媒体将产业演进切片成耸动标题再用算法推送给所有焦虑的从业者。但真实世界从不按标题运行——我见过用低代码平台三天搭出CRM的销售团队也见过他们半年后因字段权限颗粒度不够被迫把整个流程重写成Java微服务我带过用GitHub Copilot写出90%样板代码的新人也陪他花两天时间debug一段AI生成的Redis分布式锁逻辑。所谓“编码消亡论”本质是把“写代码”狭隘理解为“敲键盘输出字符”却忽略了真正消耗工程师心力的永远是需求模糊时的反复对齐、系统耦合时的权衡取舍、线上故障时的归因推理。这篇文章不预测未来只拆解当下当AI能生成函数人类程序员到底在守护什么那些无法被自动化的硬核能力又该如何刻意训练适合刚入行的应届生建立认知坐标系也适合十年老兵校准技术投入方向——毕竟我们不是在和机器赛跑而是在帮机器学会理解人类真正想要的世界。2. 表面消退的“编码量”实则是开发范式的结构性迁移2.1 从“手写每一行”到“定义每一条规则”的范式跃迁十年前我接手一个电商订单系统光是“创建订单”这个接口就写了27个if-else分支不同支付方式要调不同网关不同地区要校验不同身份证格式促销活动叠加要计算13种优先级规则。现在同样功能我可能只写三段核心逻辑第一段用DSL领域特定语言声明“订单必须包含收货人支付方式商品清单”第二段配置规则引擎的决策表第三段在低代码平台拖拽API编排节点。表面看代码量减少80%但背后工作量并未消失——它转移到更上游的环节需要和产品经理逐条确认“什么是有效收货人”要研究税务系统接口文档确定“发票抬头校验规则”甚至要给业务方培训如何在规则引擎后台修改满减策略。这种转移不是偷懒而是把重复性劳动沉淀为可复用的抽象层。我做过一个对比实验让两组工程师实现同一套物流轨迹查询功能。A组纯手写JavaMyBatis耗时42小时B组用低代码平台配置数据源API网关前端组件耗时18小时。但上线后第3天B组接到业务方紧急需求“增加海外仓发货的特殊状态流转”。A组直接改Mapper XML加两个状态枚举15分钟搞定B组发现平台预置的物流状态机不支持自定义分支不得不导出配置JSON手动编辑结果因缩进格式错误导致整个环境配置失效回滚耗时2小时。这个案例揭示关键真相自动化工具消灭的是“已知路径上的体力劳动”而非“未知场景中的认知劳动”。当业务规则稳定时低代码是加速器当规则本身在剧烈变化时手写代码的灵活性反而成为护城河。2.2 AI辅助编程的真实效能边界去年我把团队所有新项目接入GitHub Copilot设置了一个观察指标新人提交的PR中由Copilot生成的代码占比。三个月后数据很有趣初级工程师平均占比63%但他们的代码合并通过率只有41%高级工程师占比仅28%合并通过率却达92%。深入分析发现差异根源——新人倾向于接受Copilot的全部建议包括那些用ArrayList替代LinkedList的性能陷阱或在高并发场景下未加锁的静态变量而资深工程师会把Copilot当“超级补全”输入// calculate shipping fee for cross-border order后只采纳其生成的税率计算公式手动重写缓存策略和异常兜底逻辑。这里有个被忽略的技术事实当前所有AI编程工具都基于统计概率而非程序语义理解。当我输入def get_user_profile(user_id):模型可能根据海量代码库中高频模式生成return db.query(SELECT * FROM users WHERE id %s, user_id)。但它无法判断这个SQL是否触发N1查询更不知道用户ID来自不可信的HTTP参数——这些安全与性能风险必须由人类工程师用领域知识覆盖。就像汽车自动驾驶L2级辅助驾驶方向盘仍需人类随时接管。我要求团队执行“Copilot三原则”第一所有生成代码必须通过SonarQube扫描第二涉及资金/数据的逻辑必须手写核心校验第三每次接受建议前先默念“这段代码的失败场景是什么”。2.3 企业技术选型背后的成本博弈某金融客户曾让我评估“全面替换核心交易系统为低代码平台”的方案。他们提供的ROI测算表很诱人开发周期缩短60%人力成本下降45%。但我带着架构师团队做了反向推演当平台厂商下架某款数据库驱动时我们能否自己编译适配当监管新规要求增加交易留痕字段平台配置界面是否支持审计日志的异步落库当单日交易峰值突破设计容量是购买厂商的“性能增强包”还是重构底层最终我们画出一张成本曲线图——前期投入确实降低但3年后总拥有成本TCO反而高出37%因为所有定制化需求都要依赖厂商排期而每个排期延误都会转化为业务损失。这揭示一个残酷现实技术栈的“易用性”和“可控性”永远存在跷跷板效应。低代码/AI工具像租来的精装公寓拎包入住省心省力但想砸墙改格局就得找房东审批手写代码则像自建毛坯房前期投入巨大但未来十年想加层、改水电、装智能家居全由自己说了算。我在给创业公司做技术顾问时会明确建议MVP阶段用NoCode快速验证但一旦用户超过10万必须启动核心模块的手写重构——因为此时业务复杂度已远超工具抽象层的承载能力。3. 真正不可替代的“编码能力”正在向三个维度纵深进化3.1 从语法熟练度到系统语义理解力的跃升五年前面试一个候选人他流畅手写红黑树插入逻辑但当我问“如果把这个树用在分布式ID生成器里节点分裂时如何保证全局单调递增”他愣住了。这暴露了传统编程教育的致命短板过度训练“如何实现算法”却极少训练“在什么场景下该用什么算法”。真正的高阶能力是构建一套系统语义词典——看到“高并发秒杀”立刻关联到库存扣减的CAS操作、热点Key的本地缓存、削峰填谷的消息队列听到“实时风控”马上想到Flink的CEP模式匹配、特征工程的滑动窗口计算、模型服务的AB测试灰度发布。我带团队时强制推行“语义翻译练习”每周选一个业务需求文档要求工程师用技术术语重写。比如市场部提出的“用户浏览商品页3秒以上才计入有效曝光”要翻译成“前端埋点需防抖处理服务端需校验UA合法性曝光日志需打标session_id用于后续归因”。这个过程逼迫工程师穿透业务话术直击技术本质。最近我们重构推荐系统当产品说“希望用户多看到新品”资深工程师立刻意识到这本质是解决冷启动问题进而提出混合召回策略用图神经网络挖掘新品关联关系同时保留基于热度的随机采样池。这种能力无法被AI替代因为它需要将碎片化业务知识编织成连贯的技术决策链。3.2 从单点实现力到跨域协同力的扩展现在一个支付功能上线涉及至少五个技术域前端要适配iOS/Android/H5的生物认证SDK后端要对接银联/网联/第三方支付网关运维要配置TLS1.3证书和WAF规则安全团队要审计PCI-DSS合规项数据团队要埋点验证转化漏斗。过去一个全栈工程师可能覆盖全部但现在更常见的是“T型人才”——在某个领域如支付网关协议有深度同时能听懂其他领域专家的语言。我见过最高效的协作案例安全工程师用OpenAPI规范描述风控规则引擎的输入输出数据工程师据此生成Flink SQL作业而业务方直接在Swagger UI里调试规则效果。这种协同的前提是所有人共享同一套技术契约语言。为此我们建立了“跨域知识地图”把每个系统模块标注为“谁负责”“谁依赖”“变更影响面”。当需要升级SSL证书时地图自动提示需同步通知前端团队WebView证书校验、运维团队Nginx配置、测试团队HTTPS抓包工具更新。这种结构化协同能力比单点编码能力更难被自动化——因为它的核心是建立信任而信任只能通过无数次共同解决问题来积累。上周我们修复一个跨系统事务一致性问题前后端工程师连续48小时盯在会议室白板上画满状态流转图最终用Saga模式解决。这种在混沌中共建秩序的能力才是工程师真正的护城河。3.3 从功能实现者到体验架构师的角色升级用户不会因为你的代码用了最新版Spring Boot而点赞但他们绝对会因为“下单后3秒内收到支付成功通知”而产生信任感。我主导过一个银行App的体验重构技术指标很朴素把转账成功的平均响应时间从2.3秒压到800毫秒内。但实现路径远超代码优化——前端预加载常用收款人列表后端用内存数据库缓存账户余额消息队列异步处理记账甚至协调客服系统提前准备转账失败的话术模板。当用户点击“确认转账”按钮时界面立即显示“处理中”300毫秒后弹出“已提交至银行系统”2秒后推送“转账成功”通知。整个过程没有一行“炫技”代码但用户感知到的是丝滑体验。这种能力叫体验架构思维把技术决策锚定在用户可感知的价值点上。比如选择数据库不只看TPS更要看“用户等待时长是否超过心理临界点”设计API不只考虑字段完整性更要思考“前端同学能否在10分钟内完成调用封装”。我在团队推行“体验倒推法”每个需求评审会先问“用户完成这个动作时最希望看到的第一句话是什么”再反推技术方案。当产品提“增加人脸识别登录”我们没急着集成SDK而是先做用户调研老年人更在意操作步骤是否少于3步商务人士关注离线场景下的备用方案。这些洞察最终导向一个混合方案活体检测用云端服务但证件OCR支持本地离线处理。技术永远服务于人而理解人的需求恰恰是最难被算法模拟的智慧。4. 实操指南构建面向未来的工程师能力矩阵4.1 每日刻意训练的三个黄金动作很多工程师抱怨“没时间学习”其实缺的不是时间而是把学习嵌入工作流的机制。我坚持了七年的个人实践效果显著第一晨间15分钟“逆向阅读”不看技术博客而是打开生产环境的慢SQL日志或APM监控告警。比如今天看到一条耗时2.7秒的订单查询我会暂停手头工作用Explain分析执行计划定位是缺少索引还是JOIN顺序错误然后在测试库复现并优化。这个动作强迫我直面真实系统的复杂性比刷LeetCode更能提升数据库直觉。上周就靠这个习惯提前发现了一个因分页参数突变导致的全表扫描隐患。第二代码审查时的“三问法”每次Review同事PR必问① 这段代码在极端情况下如网络超时、磁盘满会如何表现② 如果三个月后由实习生维护他需要多少上下文才能理解这段逻辑③ 这个改动会让监控大盘哪个指标发生什么变化这三个问题像手术刀精准切开代码的健壮性、可维护性和可观测性。团队实施后线上事故率下降40%因为大量潜在问题在合并前就被揪出。第三周五下午的“技术考古”专门留出2小时研究一个“过时”技术。比如最近我重读了2003年发布的《The Google File System》论文表面看HDFS已取代GFS但其中“追加写优于随机写”的设计哲学完美解释了为什么我们的日志系统用Kafka比用RabbitMQ更合适。这种考古不是怀旧而是寻找跨越时代的底层规律——所有技术框架都在变但分布式系统的核心矛盾一致性vs可用性、延迟vs吞吐永恒不变。4.2 工具链的理性选型不做工具的奴隶市面上工具爆炸式增长但我的原则很朴素任何新工具必须通过“痛苦阈值测试”。即它解决的问题是否真的让我每周至少节省2小时重复劳动是否能降低我最常犯的三类错误是否让我的知识资产可迁移以API文档为例我们曾用Swagger后来换成Postman现在用Redocly。每次切换都源于具体痛点Swagger的YAML手写易出错Postman的环境变量管理混乱直到Redocly支持从代码注释自动生成文档且能一键部署到内部Wiki。这个过程教会我工具选型不是追逐新潮而是持续识别自己的“痛苦点”。现在团队所有工具都遵循“双轨制”核心基础设施如K8s集群用成熟稳定的旧版本业务开发工具如前端构建允许试用新版本但必须有人专职维护兼容性层。特别提醒一个血泪教训千万别在项目中期引入新工具。去年有个项目快上线时后端负责人提议用GraphQL替代REST API理由是“更灵活”。我们花了3天评估结论是现有REST接口已覆盖95%场景GraphQL带来的20%灵活性需要付出300小时改造成本和未知的性能风险。最终决定维持现状用API网关做字段裁剪。这个决策背后是清醒的认知工程师的价值不在于掌握多少工具而在于判断何时该用工具何时该绕过工具。4.3 构建个人技术影响力从执行者到定义者当编码不再是核心竞争力如何证明自己的价值我的答案是主动定义问题而非仅解决别人定义的问题。在上一家公司我发现各业务线都在重复造“用户行为分析”轮子于是发起“统一埋点规范”项目。这不是写代码而是组织12个团队开会梳理出37个共性事件如“商品曝光”“加入购物车”定义每个事件的12个标准字段并推动前端SDK、数据仓库、BI平台全线适配。项目耗时半年但后续新业务接入分析功能的时间从2周缩短到2小时。这个过程让我深刻体会到技术领导力始于对业务痛感的敏锐捕捉成于跨团队共识的艰难构建。现在我要求团队成员每年至少发起一个“小而美”的标准化项目可能是统一日志格式可能是制定SQL编写公约甚至只是整理一份《XX系统故障排查速查表》。这些看似琐碎的工作恰恰在塑造技术话语权——当你能定义“什么是好代码”“什么是可靠服务”时你就超越了编码员的身份。5. 常见迷思与实战避坑指南5.1 关于“低代码是否等于失业危机”的真相这是最常被误解的点。我访谈过32家采用低代码平台的企业发现一个铁律低代码消灭的是“不需要深度业务理解的编码岗位”而非“需要业务洞察的工程师岗位”。某零售企业用低代码搭建了127个内部应用但IT部门工程师数量反而增加了23%——因为新应用暴露出更多系统集成需求需要写中间件打通ERP和低代码平台要开发数据清洗脚本处理平台导出的脏数据还得设计监控体系防止低代码应用突然宕机。更讽刺的是低代码平台自身成了新的技术栈。我们服务的一个客户其低代码平台的二次开发文档比Spring官方文档还厚里面全是“如何重写表单渲染器”“怎样扩展工作流引擎”等深度技术问题。所以别担心被替代要担心的是当业务方说“这个低代码平台搞不定得你们手写”你能否接得住我的建议很实在把低代码平台当做一个新操作系统来学习重点攻克它的扩展机制和性能瓶颈这比焦虑失业有用一万倍。5.2 AI编程工具的三大认知陷阱陷阱一“生成即正确”幻觉Copilot生成的代码通过编译不等于通过业务逻辑验证。我见过最危险的案例AI生成的JWT解析代码因未校验签名算法导致任意token都能伪造。解决方案很简单在CI流程中加入“AI生成代码专项检查”用正则匹配jwt.decode(等敏感调用强制要求添加算法白名单校验。陷阱二“提示词即生产力”错觉很多人花2小时调教提示词只为生成一个CRUD接口。但真正提升效率的是把提示词变成可复用的“技术契约”。比如我们定义了一套标准提示词模板[角色]作为支付系统架构师[任务]生成符合PCI-DSS的退款接口[约束]必须包含幂等性校验、资金流水号生成、异步通知回调。这套模板沉淀后新人10分钟就能生成合规代码这才是AI赋能的本质。陷阱三“替代学习”妄想以为用AI写代码就不用学算法。现实是当AI生成的排序算法在大数据量下超时你得知道该换哪种算法当AI写的加密逻辑被安全团队驳回你得明白AES-GCM和CBC的区别。我的做法是用AI处理样板代码但强制自己手写所有核心算法和安全逻辑。就像厨师用料理机切菜但火候掌控永远靠经验。5.3 技术选型中的“伪需求”识别术很多项目失败源于把“伪需求”当真需求。我总结出三个识别信号信号一需求描述中出现“应该”而非“必须”比如“订单状态应该实时更新”这其实是伪需求“用户在支付成功后3秒内必须看到状态变更”这才是真需求。前者导向WebSocket长连接后者可能用轮询本地缓存更简单。信号二技术方案优先于业务目标当会议中频繁出现“我们要上K8s”“必须用微服务”但没人说清“这能帮销售多签几个单”大概率是伪需求。我的应对方法是每次技术讨论前先让所有人写下“这个技术决策能让用户少等几秒让业务方多赚多少钱”信号三解决方案比问题描述还长比如需求文档开头就写“采用Spring Cloud AlibabaNacosSentinelSeata”但没说明要解决什么具体问题。这时我会打断“请先用一句话告诉我用户现在遇到的最大痛苦是什么”往往答案只是“下单偶尔失败”那根本不需要分布式事务加个重试机制就够了。提示所有技术决策的终极检验标准是能否用非技术语言向保洁阿姨解释清楚价值。如果她说“哦就是让顾客付款更快”说明你抓住了本质如果说“啊什么熔断降级”那你可能掉进了技术自嗨的陷阱。5.4 职业发展的“三明治”策略面对不确定性我建议采用“三明治”能力结构底层是扎实的计算机基础操作系统/网络/数据库原理中层是垂直领域的深度如金融风控、医疗影像顶层是跨界能力产品思维/商业敏感度/沟通影响力。这个结构像三明治两片硬面包底层顶层保护中间的奶油领域专长不被挤出来。具体落地每年用20%时间夯实底层比如重读《深入理解计算机系统》并做实验用60%时间深耕领域参与行业峰会、研究监管政策、和业务方混工位用20%时间拓展顶层主动承担跨部门项目、学习财报分析、甚至考取PMP。去年我带团队做医保结算系统正是靠提前研究DRG付费政策预判了接口改造需求让项目提前两周上线。这种复合能力才是AI时代最稀缺的“人肉编译器”。6. 我在深夜改Bug时的真实体会上周五凌晨两点线上支付系统突发告警部分订单状态卡在“处理中”长达17分钟。我泡了杯浓茶没急着看代码而是先打开用户反馈群——果然有3条投诉但奇怪的是投诉用户都集中在华东区。这个地理特征让我跳过常规排查直奔CDN节点日志发现上海边缘节点的TLS握手失败率飙升。原来是一次灰度发布的证书配置遗漏只影响了特定区域。修复后我盯着监控曲线回落突然想起十年前类似故障那时要通宵重启服务器现在15分钟定位根因。这个瞬间让我彻悟所谓“编码消亡”不过是把体力劳动交给机器把脑力劳动留给人类。我们不再需要记住所有API参数但必须更懂业务逻辑的因果链条不必手写每行SQL但要一眼看出慢查询背后的业务场景不用纠结CSS像素级对齐但要预判这个UI改动对用户转化率的影响。技术永远在变但工程师的核心价值从未改变——在不确定的世界里用确定性的逻辑构建确定性的体验。最后分享个小技巧每当感到焦虑就打开自己五年前写的代码。看着那些为解决当时难题而绞尽脑汁的注释你会笑着对自己说“看当年那个笨拙但认真的家伙已经帮你趟过了更多险滩。” 编程不会死死的只是我们对“编程”二字的狭隘想象。真正的代码从来不在编辑器里而在我们理解世界、连接人心、创造价值的每一次思考中。