前几天在技术社区刷到一个帖子标题就一句话编程尚未被解决。我盯着它看了很久越看越觉得有味道。这个行业做了这么多年从你刚开始写第一行Hello World的兴奋到后来熟练地用着各种自动化工具按理说编程应该越来越不是个事儿才对。可真遇到一个稍微复杂的项目你会发现那些最根本的困难一点都没少需求讲不明白、环境跑不起来、系统改一处崩三处、半夜被线上告警叫醒。工具在变困难没变。所以这句话不是悲观反而是一句清醒的实话。编程并不是一道等待被解开的数学题它更像一场永远在施工的工地——你可以优化施工方式、换更好的机械、用更先进的材料但工地永远有新问题永远不可能彻底完工。程序员所面对的工作本质上是把不断变化的人类需求翻译成精确、可执行、在边界条件下还能稳定运行的机器指令这件事的难度是复合的不是某一个工具能一次性抹平的。这篇文章想聊的就是从这句话延伸出去的三层意思第一层编程为什么尚未被解决那些没法被工具替代的难题到底难在哪第二层这些年工具确实解决了一些问题但它们解决的是哪一类问题边界在哪里第三层对一个普通开发者来说清楚这个现实之后应该怎么调整自己的学习方向和工作方法让自己在这场永不完工的工地上干得更稳。适合谁看我自己觉得干了两三年还在迷茫怎么进阶的或者正在焦虑AI会不会让我失业的还有刚入行不知道往哪使劲的新手这篇多少能帮你把心里的乱麻解开一点。1. 先聊明白编程为什么尚未被解决1.1 编程不是一道题而是一个系统问题先打个比方。解一道数学题题干是确定的条件是给定的答案是唯一或有限多个的你只要找到方法往里算就行。编程不一样你面对的是一个开放系统——需求会变、用户会变、运行环境会变甚至你自己三个月后回来看代码思路都变了。所以解决问题在编程里是一个动态短语。你今天解决了一个bug明天可能因为加了新功能又把它触发出来。你今天设计了一个自认为优雅的抽象下周产品说要换个交互方式这个抽象就得推翻重来。这不是你水平不行是软件本身就是这样的东西它活在持续变化的上下文里。这也是为什么编程还没被解决的说法是成立的。我们确实把编程的外围机械化了很多但软件的本质矛盾——需求是模糊的、易变的而代码是精确的、僵硬的——还横在那里谁也没真正越过它。你在代码里写下的每一行都要求极端的明确性类型要匹配、边界要处理、状态要收敛。可是需求的源头本身却充满了含混、歧义和临时变更。这两者之间的翻译鸿沟就是编程这个行业永远有活干的根本原因。1.2 从软件危机喊到今天变没变稍微了解点软件工程史的人都知道一个典故早在60年代末就有人提出了软件危机这个词当时指的就是软件项目普遍延期、超预算、质量不稳定大型系统难以维护。几十年过去了编程语言换代了好几轮开发方法论从瀑布到敏捷再到 DevOps容器、云、微服务把部署门槛大幅度拉低按理说危机该解除了吧现实是软件变得越来越大、越来越复杂问题只是换了个形状而已。以前是系统太大写不完现在是系统互相依赖太深你不敢随便改。以前是内存泄漏找不到现在是微服务调用链里一个超时问题追到天亮。工具解决了大量的中层问题却把头部和尾部的问题变得更加尖锐。我在实际项目里的感受是脚手架和框架解决的是怎么把项目建起来CI/CD 解决的是怎么把代码更好地送上线监控告警解决的是出了问题怎么更快发现。但这个系统到底应该设计成什么样哪些边界条件必须考虑哪些需求其实不该做——这些真正决定项目成败的问题依然需要人脑去扛。工具能帮你把代码跑起来但没法替你想清楚这套代码存在的理由。2. 这些年工具到底帮我们解决了什么承认编程没有被彻底解决不等于说工具没用。恰恰相反工具在持续地解决编程中可以被机械化的一部分。理解了这个边界你就不会对任何工具产生不切实际的期待也不会因为某个工具没替你解决所有问题就否定它的价值。我习惯把编程的困难分成三层表达层、构造层、判断层。表达层指的是你想让机器做什么怎么把想法写成机器能懂的指令。这一层的历史就是编程语言的历史。汇编到高级语言是把内存、寄存器、跳转这些机器细节包起来了面向对象和函数式是把数据和行为怎么组织的问题给出了更高级的答案再到后来的声明式编程、领域特定语言甚至低代码平台本质上都是在说你不需要写这么细你只需要描述意图。构造层指的是怎么把已经写好的零件组装成一个可靠的系统。这一层被框架、库、工具链极大地改善了。你要做个网页应用不用从底层网络协议开始写要处理日期不用自己实现历法算法要发个HTTP请求一行代码就完事。更不用说现代IDE的补全、重构、调试能力极大减少了敲键盘和试错的成本。判断层指的是这个系统该不该这么做、需求到底是什么意思、两个方案权衡下来选哪个、这个改动的影响面有多大。这一层到目前为止基本没有被任何工具真正触及。AI编程助手可以帮你生成一个函数但它不会告诉你这个函数根本不需要存在它可以帮你补全一段正则但它无法判断这段正则背后的业务规则是不是合理的。2.1 高级语言和框架解决的是表达而不是思考有一个很常见的误解既然高级语言这么好用框架这么省事那编程的门槛应该低到人人都能写代码了吧低代码平台的宣传也是这个调调。但真实情况是工具降低了表达的门槛并没有降低思考的门槛。打个比方以前你想盖个房子得自己搬砖、和水泥、砌墙这叫表达层成本。后来有了预制板和模块化建材你把墙板吊上去就行表达层便宜太多了。但房子盖成什么样、地基怎么打、承重墙在哪、厨房厕所怎么排布、邻居会不会投诉、未来会不会加层——这些依然是思考层的难题建材再先进也帮不了你。框架也是一样。各种Web框架解决的是应用的基本骨架怎么写这个表达问题它们让我们不用从零开始造轮子。但需求分析、架构设计、性能优化、故障排查这些环节框架几乎帮不上忙。它甚至会增加一层新的思考负担框架的升级策略、版本兼容、约束与反模式这些在框架出现之前根本不存在。你多用一个框架就多学一套它的脾气。2.2 AI编程助手的真实边界这两年最热的话题肯定是 AI 编程助手。我得先给个结论它确实改变了日常编码的体验但离解决编程还差得很远。我自己的使用感受是这样——它最擅长的是三种活翻译样板代码、生成重复性代码、解释陌生代码片段。你给它一个清晰明确的任务描述它能给你一个质量还不错的初稿省掉大量查阅文档和翻旧代码的时间。但你能明显感觉到它的边界。当你给它一个模糊的需求它会给一个看起来正确但其实想当然的答案当你把一个复杂的系统上下文丢给它它会忽略隐含的约束条件更重要的是它不会为你的代码负责。出了问题背锅的还是你收拾现场的还是你。有个我印象挺深的案例之前让AI助手帮忙写一段数据同步的调度逻辑。单看函数写得像模像样边界条件、重试逻辑都照顾到了。但放到项目里跑了两天发现它没考虑幂等性——重跑一次数据翻倍。你说这代码写得差吗单看质量还行。但它没有上下文不知道这个任务在生产环境里会有重复触发。所以我现在的态度是把AI当高级的结对搭档而不是替你思考的代笔。它可以帮你写得快但没法帮你判断该不该这么写。判断这件事永远得你自己来。2.3 拆解一个典型项目的三层复杂性说点实操的用我之前做过的一个中型订单系统来拆。这个项目不算难但足以暴露编程还没被解决的复杂性。第一层是业务复杂性。业务方给我的需求文档标题叫订单状态流转优化。里面写了六个状态、七八种跳转规则、三种异常情况。看起来清楚吧需求评审时问了几个问题就露馅了退款中的订单如果用户又申请了发票怎么办支付超时是自动取消还是进人工状态变更要不要记录操作人每个问题业务方都要想半天最后给出这个情况我们还没碰到过的答案。你看需求不是写好的是聊出来的、试出来的。这一层的不确定性没有任何编程语言和框架能替你消除。第二层是技术复杂性。系统里有缓存、有消息队列、有定时任务还有背后那张被十几张表引用的大表。改一个状态流转的字段你要考虑缓存同步、消息顺序、事务边界、并发冲突。这一层的账没有任何框架替你算你只能用经验加测试一点一点抠。业务不动的时候系统好像很稳定业务一旦变更所有隐藏的耦合都会浮出水面。第三层是协作复杂性。一个需求会同时牵扯后端、前端、测试、产品、运维。每个人对完成的定义都不一样沟通成本高得离谱任何一环信息不同步都会变成线上问题。这一层也是工具最难解决的——它涉及的是人与人之间的确定性比人与机器之间的确定性难搞得多。代码出错了可以靠调试器找到原因人理解岔了往往扯半天都不知道问题出在哪。3. 实操视角编程里真正难啃的骨头前面聊得有点偏思想现在说点实际的。我把自己这些年写代码的真实体感摊开讲你会发现编程最难的从来不是写代码这三个字本身。3.1 写代码前90%的时间其实都在干别的有句话很扎心一个程序员一天能进入心流、高效产出代码的时间其实不超过三四小时。那剩下时间去哪了开会、看需求、翻旧代码、查文档、拉日志、试错、等构建、跟同事对齐信息。我自己写一个新功能的时候真正的流程大概是先花很久搞清楚现有的代码结构——这个功能应该挂在哪个模块下、哪些公共方法能复用、数据库表长什么样、接口签名有没有现成的。然后写一个最小可验证的草稿代码跑通一个主路径。再然后才开始补各种边界条件、异常处理、日志、注释。最后还要想怎么让代码更容易被后来的人看懂。这一整套下来敲键盘的占比真的不高。而它占时间的部分——阅读理解、判断决策、权衡取舍——才是真正值钱的部分。这也是为什么我一直跟身边人说别老纠结自己打字速度慢、快捷键记不牢那些是表达层的东西练到不会明显拖后腿就够了。真正拉开差距的是你理解一个系统的速度和深度。你能多快看明白一段代码在干什么、一个需求的本质是什么这才是核心竞争力。3.2 改别人代码为什么比写新代码痛苦十倍写新代码好比在空白画布上作画随你怎么折腾。改别人的代码尤其是那种已经运行了好几年、被五六个人摸过的老项目难度完全不一样。你面对的不是一个逻辑清晰的白板而是一个层层叠加的沉积岩。我接手过一个内部工具系统不算大但代码风格极其个性有的模块是事务脚本式有的模块是过度抽象式还有一段核心逻辑被埋在一个看起来像工具类的方法里。最绝望的是这个核心方法被六个模块调用每个调用者都依赖它的副作用。你想优化它得先摸清楚这六个调用场景你给它加个参数得把所有调用点都翻一遍。改这种代码的经验是第一先别急着写先用搜索加断点把调用链摸清楚把谁在用、怎么用记下来。第二改动尽量小步每一次改动都要能单独验证。第三也是最重要的补测试。哪怕不完整至少把当前的行为锁住再动手改。很多老项目的维护者一提补测试就说没时间但真等你改出问题了花的时间远比补测试多得多。这就像在拆炸弹之前先确认哪根线该剪而不是凭手感一刀下去。3.3 那些看似解决实则没解决的经典坑聊几个我踩过的坑每个都是以为工具解决了其实没有的典型。第一个坑是无脑引入框架。刚做项目那几年喜欢用全家桶框架什么都要往里套。结果是被框架的约束牵着走想实现一个简单功能还得去迁就框架的配置和规范。后来学乖了先问自己三句话这个需求是否真的需要这个框架有没有更轻量的替代引入后的维护成本谁来扛这可能是编程尚未被解决最表层的一个体现——框架只是给了你一套骨架骨架里的血和肉还得你自己长。第二个坑是复制粘贴代码。以前图省事从旧项目里复制一段逻辑到新项目结果旧逻辑里的bug也跟着过来了而且因为上下文不同排查起来费了两倍时间。复制本身没错错的是没理解就复制。任何一段代码进到项目里你就得对它负责。你每复制一行代码就欠下一笔理解债这笔债早晚要还而且通常带利息。第三个坑是迷信重构。看了一些讲整洁代码的书之后一度以为重构能解决所有代码腐化问题。后来在一次重构中把查了两周的问题改出来了发现重构操作本身其实没那么难难的是判断哪些要动、哪些坚决不能动。没有充分测试覆盖和业务理解的重构是拆东墙补西墙。重构不是治疗烂代码的万能药更像是一场需要术前检查的手术没有充分诊断就动刀大概率要出医疗事故。第四个坑是日志和告警的狼来了。为了安心把日志打印得满天飞、告警配了一堆结果全是噪音。真正出事那天告警反而不响了——因为大家都在狼来了里麻木了。这也是一个解决了的假象你有监控了不等于你知道系统在发生什么。监控的价值取决于你的梳理和迭代不取决于你有多少探针。后来我学到的做法是每隔一段时间就清理一次告警规则把没用的一律删掉剩下的每条都确保能让人第一时间看懂并行动。4. 面对尚未解决普通开发者可以怎么做说这么多不是劝退。恰恰相反想清楚编程尚未被解决这件事反而能让你心态稳下来。下面是我总结的一些可落地的做法都是自己在项目里试过、有效的。4.1 把解决问题放在完成任务前面这个是最核心的一个转变。很多新手习惯把自己定位成需求执行者产品说什么就做什么做完提测就算完成任务。这种模式在简单项目里问题不大但一旦项目复杂起来就会连环踩雷。因为你没有真正理解需求你只是把话翻译成了代码需求里的坑你一个没绕开。我的习惯是接到需求先问问题问到不能再问为止。目的、场景、边界、反例、验收标准每一个都要明确。业务方如果答不上来那就约定一个最小的验证版本用最快的方式试。代码可以重写方向错了不是不行但发现得越晚代价越大。宁可多花半天把需求问清楚也不要埋头写一周然后发现全白写。还有一个特别实用的小习惯把需求用自己的话复述一遍发给对方让他确认。很多歧义在复述的过程中就暴露了。这招成本极低效果极好。每次我发现我以为的和对方想要的不是一回事都庆幸自己多做了这一步复述。4.2 用测试和简化对抗复杂性前面说过最难的判断层没人替你做但有个工具能帮你把判断的风险降低那就是测试。我现在对没有测试的改动极度抗拒。补测试不是让你把代码覆盖率刷到90%而是把关键路径、关键边界、关键的历史bug场景锁住。这些测试就是你的安全网。有了安全网你才敢重构才敢动老代码才不至于改一行崩一片。另一个对抗复杂性的大杀器是刻意简化。每次设计一个模块先问自己能不能不做能不能拆小能不能用简单的方案代替复杂的方案很多程序员有复杂崇拜的倾向总觉得架构越花哨越高级。我见过不少精心设计过度的项目最后没人能接手维护。相反那些朴实无华、每个模块都能一句话讲清楚的系统往往活得最久。简化不代表不想清楚而是把复杂度控制在当前问题需要的范围内。这部分经验和编程尚未被解决的题目有关——正因为编程本质复杂你更不应该主动制造额外的复杂度。我的一个判断标准是如果三个月后的自己看到这段代码能一眼读懂那这个设计就是合格的。4.3 新手入行建议先练什么给刚入行的朋友几句实在话。第一先把一门语言的基础打得扎扎实实别急着学一堆框架的皮毛。基础扎实的人换框架很快基础虚的人学十个框架也写不出有质量的代码。第二多读别人的代码特别是那些正经的开源项目的源代码。读源码能帮你理解真正的工程实践是什么样的比看一堆二手博客强太多。第三一定要学会调试包括断点调试、日志分析、性能剖析。这是你以后排查问题的主要武器越早练越不吃亏。还有一个想特别提醒的别把自己工具化。现在AI工具很会写代码如果人只会写代码那确实容易被替代。但你要是能懂业务、会判断方案、能设计系统、hold住疑难问题你就不是能写代码的人而是能用代码解决问题的人。这两者的差别就是编程尚未被解决留给我们的活路。机器替代的是翻译替代不了判断。4.4 一种更健康的心态与不确定性共存最后说说心态。我在这个行业待得越久越觉得不确定性就是这一行的底色。你不可能等需求完全确定再动手因为你等不到那天你不可能把所有边界条件都想到因为总有一部分在真实环境里才会暴露你不可能写出永不出bug的代码因为bug本身就是复杂系统的副产品。所以别用彻底解决作为追求那是自己给自己找别扭。正确的心态是把编程当成持续的博弈每轮迭代都尽量降低不确定性用测试、评审、小步快跑、快速反馈把风险压在可控范围内。接受未知是常态之后你的焦虑会少很多判断也会清醒很多。我经常用一句自嘲话来调整状态如果编程真的被解决了大概也就没有我们什么事了。正因为这些难题还在我们才有一口饭吃。这个行业真正的护城河从来不是某个语法的熟练度而是你在不确定性面前依然能稳定输出判断和结果的能力。5. 常见误区与实操速查最后整理几个最常见的认知误区和我自己用来校准的标准方便你对照。5.1 最常见的四个认知误区误区真相有了AI工具写代码不再需要思考AI能帮你写代码片段但它不理解你的业务上下文也无法为结果负责框架选得好项目就成功了一半框架只是脚手架需求理解、架构取舍、团队协作才是成败关键重构能治好一切烂代码没有测试覆盖和业务理解的重构大概率会引入新问题代码写得快编程能力强写得快但总返工远不如想得清楚一次做对可维护性才是真正的产能这张表我建议记下来。每次你觉得自己被某个新工具、新框架惊艳到的时候回来看看第二列能帮你省不少盲目折腾的时间。5.2 三个可复用的判断标准额外给出几个我自己在开发中用来校准的实操问题第一接到一个需求时先问目的是什么而不是怎么实现。目的清楚了方案往往会清晰很多还有很多看似必须做的部分会被直接砍掉。这是我砍无效需求最有效的一招没有之一。第二写代码前如果这个函数你能用一句话说清楚它输入什么、输出什么、依赖什么那大概率设计是清楚的。说不清楚先别说代码回去把接口定义改清楚。第三改别人代码时如果心跳加速、找不着北就先停下动手去补测试或者找同事对齐。宁可慢一点也不要凭感觉硬改。凭感觉的一锤子买卖后面大概率用十倍时间还债。5.3 一个适用面很广的经验清单最后放一个清单算是我这些年沉淀下来的一套备用操作细则写代码的时候顺手过一遍能避开不少坑接需求先复述确认不留模糊地带。写代码前先想好验证方式免得写完没法确认对不对。每次改动尽量小、可单独验证别把十个改动混在一次提交里。关键逻辑一定要有测试保护别裸奔。有技术决策简单记录下当时为什么这么选写进提交说明即可。遇到用时超过半小时的问题先停下来重新读一遍报错信息和代码别在错误方向上加速。再急也不要删掉旧的debug手段线上排查工具永远要留着。连续写代码超过90分钟起来走一圈回回神。状态不好时写出的代码你回头要吸很久的尾气。说句实在话我写这篇内容的时候编程尚未被解决这句话一直在我脑子里转。它让我想到自己刚入行时那种我什么时候才能把编程彻底搞定的天真也想到这些年面对一个个项目时越来越强的一种体感我们不是要打完一场仗而是要接受一场打不完的仗然后把每一天的攻防都做扎实。如果你现在正为某个老项目的烂摊子头疼或者因为AI工具的崛起而焦虑自己的价值我的建议很简单别盯着那些被解决的部分焦虑去看看那些还没被解决的部分——那才是这个行业真正的机会所在。把判断力、系统思维、沟通能力和对业务的理解练起来这些东西一时半会儿还没法外包给任何工具至少在可预见的未来都是这样。 
长河君 · 2026/10/20 20:57:57 · 阅读 1.2k 编程尚未被解决：工具替代不了的核心能力在哪
前几天在技术社区刷到一个帖子标题就一句话编程尚未被解决。我盯着它看了很久越看越觉得有味道。这个行业做了这么多年从你刚开始写第一行Hello World的兴奋到后来熟练地用着各种自动化工具按理说编程应该越来越不是个事儿才对。可真遇到一个稍微复杂的项目你会发现那些最根本的困难一点都没少需求讲不明白、环境跑不起来、系统改一处崩三处、半夜被线上告警叫醒。工具在变困难没变。所以这句话不是悲观反而是一句清醒的实话。编程并不是一道等待被解开的数学题它更像一场永远在施工的工地——你可以优化施工方式、换更好的机械、用更先进的材料但工地永远有新问题永远不可能彻底完工。程序员所面对的工作本质上是把不断变化的人类需求翻译成精确、可执行、在边界条件下还能稳定运行的机器指令这件事的难度是复合的不是某一个工具能一次性抹平的。这篇文章想聊的就是从这句话延伸出去的三层意思第一层编程为什么尚未被解决那些没法被工具替代的难题到底难在哪第二层这些年工具确实解决了一些问题但它们解决的是哪一类问题边界在哪里第三层对一个普通开发者来说清楚这个现实之后应该怎么调整自己的学习方向和工作方法让自己在这场永不完工的工地上干得更稳。适合谁看我自己觉得干了两三年还在迷茫怎么进阶的或者正在焦虑AI会不会让我失业的还有刚入行不知道往哪使劲的新手这篇多少能帮你把心里的乱麻解开一点。1. 先聊明白编程为什么尚未被解决1.1 编程不是一道题而是一个系统问题先打个比方。解一道数学题题干是确定的条件是给定的答案是唯一或有限多个的你只要找到方法往里算就行。编程不一样你面对的是一个开放系统——需求会变、用户会变、运行环境会变甚至你自己三个月后回来看代码思路都变了。所以解决问题在编程里是一个动态短语。你今天解决了一个bug明天可能因为加了新功能又把它触发出来。你今天设计了一个自认为优雅的抽象下周产品说要换个交互方式这个抽象就得推翻重来。这不是你水平不行是软件本身就是这样的东西它活在持续变化的上下文里。这也是为什么编程还没被解决的说法是成立的。我们确实把编程的外围机械化了很多但软件的本质矛盾——需求是模糊的、易变的而代码是精确的、僵硬的——还横在那里谁也没真正越过它。你在代码里写下的每一行都要求极端的明确性类型要匹配、边界要处理、状态要收敛。可是需求的源头本身却充满了含混、歧义和临时变更。这两者之间的翻译鸿沟就是编程这个行业永远有活干的根本原因。1.2 从软件危机喊到今天变没变稍微了解点软件工程史的人都知道一个典故早在60年代末就有人提出了软件危机这个词当时指的就是软件项目普遍延期、超预算、质量不稳定大型系统难以维护。几十年过去了编程语言换代了好几轮开发方法论从瀑布到敏捷再到 DevOps容器、云、微服务把部署门槛大幅度拉低按理说危机该解除了吧现实是软件变得越来越大、越来越复杂问题只是换了个形状而已。以前是系统太大写不完现在是系统互相依赖太深你不敢随便改。以前是内存泄漏找不到现在是微服务调用链里一个超时问题追到天亮。工具解决了大量的中层问题却把头部和尾部的问题变得更加尖锐。我在实际项目里的感受是脚手架和框架解决的是怎么把项目建起来CI/CD 解决的是怎么把代码更好地送上线监控告警解决的是出了问题怎么更快发现。但这个系统到底应该设计成什么样哪些边界条件必须考虑哪些需求其实不该做——这些真正决定项目成败的问题依然需要人脑去扛。工具能帮你把代码跑起来但没法替你想清楚这套代码存在的理由。2. 这些年工具到底帮我们解决了什么承认编程没有被彻底解决不等于说工具没用。恰恰相反工具在持续地解决编程中可以被机械化的一部分。理解了这个边界你就不会对任何工具产生不切实际的期待也不会因为某个工具没替你解决所有问题就否定它的价值。我习惯把编程的困难分成三层表达层、构造层、判断层。表达层指的是你想让机器做什么怎么把想法写成机器能懂的指令。这一层的历史就是编程语言的历史。汇编到高级语言是把内存、寄存器、跳转这些机器细节包起来了面向对象和函数式是把数据和行为怎么组织的问题给出了更高级的答案再到后来的声明式编程、领域特定语言甚至低代码平台本质上都是在说你不需要写这么细你只需要描述意图。构造层指的是怎么把已经写好的零件组装成一个可靠的系统。这一层被框架、库、工具链极大地改善了。你要做个网页应用不用从底层网络协议开始写要处理日期不用自己实现历法算法要发个HTTP请求一行代码就完事。更不用说现代IDE的补全、重构、调试能力极大减少了敲键盘和试错的成本。判断层指的是这个系统该不该这么做、需求到底是什么意思、两个方案权衡下来选哪个、这个改动的影响面有多大。这一层到目前为止基本没有被任何工具真正触及。AI编程助手可以帮你生成一个函数但它不会告诉你这个函数根本不需要存在它可以帮你补全一段正则但它无法判断这段正则背后的业务规则是不是合理的。2.1 高级语言和框架解决的是表达而不是思考有一个很常见的误解既然高级语言这么好用框架这么省事那编程的门槛应该低到人人都能写代码了吧低代码平台的宣传也是这个调调。但真实情况是工具降低了表达的门槛并没有降低思考的门槛。打个比方以前你想盖个房子得自己搬砖、和水泥、砌墙这叫表达层成本。后来有了预制板和模块化建材你把墙板吊上去就行表达层便宜太多了。但房子盖成什么样、地基怎么打、承重墙在哪、厨房厕所怎么排布、邻居会不会投诉、未来会不会加层——这些依然是思考层的难题建材再先进也帮不了你。框架也是一样。各种Web框架解决的是应用的基本骨架怎么写这个表达问题它们让我们不用从零开始造轮子。但需求分析、架构设计、性能优化、故障排查这些环节框架几乎帮不上忙。它甚至会增加一层新的思考负担框架的升级策略、版本兼容、约束与反模式这些在框架出现之前根本不存在。你多用一个框架就多学一套它的脾气。2.2 AI编程助手的真实边界这两年最热的话题肯定是 AI 编程助手。我得先给个结论它确实改变了日常编码的体验但离解决编程还差得很远。我自己的使用感受是这样——它最擅长的是三种活翻译样板代码、生成重复性代码、解释陌生代码片段。你给它一个清晰明确的任务描述它能给你一个质量还不错的初稿省掉大量查阅文档和翻旧代码的时间。但你能明显感觉到它的边界。当你给它一个模糊的需求它会给一个看起来正确但其实想当然的答案当你把一个复杂的系统上下文丢给它它会忽略隐含的约束条件更重要的是它不会为你的代码负责。出了问题背锅的还是你收拾现场的还是你。有个我印象挺深的案例之前让AI助手帮忙写一段数据同步的调度逻辑。单看函数写得像模像样边界条件、重试逻辑都照顾到了。但放到项目里跑了两天发现它没考虑幂等性——重跑一次数据翻倍。你说这代码写得差吗单看质量还行。但它没有上下文不知道这个任务在生产环境里会有重复触发。所以我现在的态度是把AI当高级的结对搭档而不是替你思考的代笔。它可以帮你写得快但没法帮你判断该不该这么写。判断这件事永远得你自己来。2.3 拆解一个典型项目的三层复杂性说点实操的用我之前做过的一个中型订单系统来拆。这个项目不算难但足以暴露编程还没被解决的复杂性。第一层是业务复杂性。业务方给我的需求文档标题叫订单状态流转优化。里面写了六个状态、七八种跳转规则、三种异常情况。看起来清楚吧需求评审时问了几个问题就露馅了退款中的订单如果用户又申请了发票怎么办支付超时是自动取消还是进人工状态变更要不要记录操作人每个问题业务方都要想半天最后给出这个情况我们还没碰到过的答案。你看需求不是写好的是聊出来的、试出来的。这一层的不确定性没有任何编程语言和框架能替你消除。第二层是技术复杂性。系统里有缓存、有消息队列、有定时任务还有背后那张被十几张表引用的大表。改一个状态流转的字段你要考虑缓存同步、消息顺序、事务边界、并发冲突。这一层的账没有任何框架替你算你只能用经验加测试一点一点抠。业务不动的时候系统好像很稳定业务一旦变更所有隐藏的耦合都会浮出水面。第三层是协作复杂性。一个需求会同时牵扯后端、前端、测试、产品、运维。每个人对完成的定义都不一样沟通成本高得离谱任何一环信息不同步都会变成线上问题。这一层也是工具最难解决的——它涉及的是人与人之间的确定性比人与机器之间的确定性难搞得多。代码出错了可以靠调试器找到原因人理解岔了往往扯半天都不知道问题出在哪。3. 实操视角编程里真正难啃的骨头前面聊得有点偏思想现在说点实际的。我把自己这些年写代码的真实体感摊开讲你会发现编程最难的从来不是写代码这三个字本身。3.1 写代码前90%的时间其实都在干别的有句话很扎心一个程序员一天能进入心流、高效产出代码的时间其实不超过三四小时。那剩下时间去哪了开会、看需求、翻旧代码、查文档、拉日志、试错、等构建、跟同事对齐信息。我自己写一个新功能的时候真正的流程大概是先花很久搞清楚现有的代码结构——这个功能应该挂在哪个模块下、哪些公共方法能复用、数据库表长什么样、接口签名有没有现成的。然后写一个最小可验证的草稿代码跑通一个主路径。再然后才开始补各种边界条件、异常处理、日志、注释。最后还要想怎么让代码更容易被后来的人看懂。这一整套下来敲键盘的占比真的不高。而它占时间的部分——阅读理解、判断决策、权衡取舍——才是真正值钱的部分。这也是为什么我一直跟身边人说别老纠结自己打字速度慢、快捷键记不牢那些是表达层的东西练到不会明显拖后腿就够了。真正拉开差距的是你理解一个系统的速度和深度。你能多快看明白一段代码在干什么、一个需求的本质是什么这才是核心竞争力。3.2 改别人代码为什么比写新代码痛苦十倍写新代码好比在空白画布上作画随你怎么折腾。改别人的代码尤其是那种已经运行了好几年、被五六个人摸过的老项目难度完全不一样。你面对的不是一个逻辑清晰的白板而是一个层层叠加的沉积岩。我接手过一个内部工具系统不算大但代码风格极其个性有的模块是事务脚本式有的模块是过度抽象式还有一段核心逻辑被埋在一个看起来像工具类的方法里。最绝望的是这个核心方法被六个模块调用每个调用者都依赖它的副作用。你想优化它得先摸清楚这六个调用场景你给它加个参数得把所有调用点都翻一遍。改这种代码的经验是第一先别急着写先用搜索加断点把调用链摸清楚把谁在用、怎么用记下来。第二改动尽量小步每一次改动都要能单独验证。第三也是最重要的补测试。哪怕不完整至少把当前的行为锁住再动手改。很多老项目的维护者一提补测试就说没时间但真等你改出问题了花的时间远比补测试多得多。这就像在拆炸弹之前先确认哪根线该剪而不是凭手感一刀下去。3.3 那些看似解决实则没解决的经典坑聊几个我踩过的坑每个都是以为工具解决了其实没有的典型。第一个坑是无脑引入框架。刚做项目那几年喜欢用全家桶框架什么都要往里套。结果是被框架的约束牵着走想实现一个简单功能还得去迁就框架的配置和规范。后来学乖了先问自己三句话这个需求是否真的需要这个框架有没有更轻量的替代引入后的维护成本谁来扛这可能是编程尚未被解决最表层的一个体现——框架只是给了你一套骨架骨架里的血和肉还得你自己长。第二个坑是复制粘贴代码。以前图省事从旧项目里复制一段逻辑到新项目结果旧逻辑里的bug也跟着过来了而且因为上下文不同排查起来费了两倍时间。复制本身没错错的是没理解就复制。任何一段代码进到项目里你就得对它负责。你每复制一行代码就欠下一笔理解债这笔债早晚要还而且通常带利息。第三个坑是迷信重构。看了一些讲整洁代码的书之后一度以为重构能解决所有代码腐化问题。后来在一次重构中把查了两周的问题改出来了发现重构操作本身其实没那么难难的是判断哪些要动、哪些坚决不能动。没有充分测试覆盖和业务理解的重构是拆东墙补西墙。重构不是治疗烂代码的万能药更像是一场需要术前检查的手术没有充分诊断就动刀大概率要出医疗事故。第四个坑是日志和告警的狼来了。为了安心把日志打印得满天飞、告警配了一堆结果全是噪音。真正出事那天告警反而不响了——因为大家都在狼来了里麻木了。这也是一个解决了的假象你有监控了不等于你知道系统在发生什么。监控的价值取决于你的梳理和迭代不取决于你有多少探针。后来我学到的做法是每隔一段时间就清理一次告警规则把没用的一律删掉剩下的每条都确保能让人第一时间看懂并行动。4. 面对尚未解决普通开发者可以怎么做说这么多不是劝退。恰恰相反想清楚编程尚未被解决这件事反而能让你心态稳下来。下面是我总结的一些可落地的做法都是自己在项目里试过、有效的。4.1 把解决问题放在完成任务前面这个是最核心的一个转变。很多新手习惯把自己定位成需求执行者产品说什么就做什么做完提测就算完成任务。这种模式在简单项目里问题不大但一旦项目复杂起来就会连环踩雷。因为你没有真正理解需求你只是把话翻译成了代码需求里的坑你一个没绕开。我的习惯是接到需求先问问题问到不能再问为止。目的、场景、边界、反例、验收标准每一个都要明确。业务方如果答不上来那就约定一个最小的验证版本用最快的方式试。代码可以重写方向错了不是不行但发现得越晚代价越大。宁可多花半天把需求问清楚也不要埋头写一周然后发现全白写。还有一个特别实用的小习惯把需求用自己的话复述一遍发给对方让他确认。很多歧义在复述的过程中就暴露了。这招成本极低效果极好。每次我发现我以为的和对方想要的不是一回事都庆幸自己多做了这一步复述。4.2 用测试和简化对抗复杂性前面说过最难的判断层没人替你做但有个工具能帮你把判断的风险降低那就是测试。我现在对没有测试的改动极度抗拒。补测试不是让你把代码覆盖率刷到90%而是把关键路径、关键边界、关键的历史bug场景锁住。这些测试就是你的安全网。有了安全网你才敢重构才敢动老代码才不至于改一行崩一片。另一个对抗复杂性的大杀器是刻意简化。每次设计一个模块先问自己能不能不做能不能拆小能不能用简单的方案代替复杂的方案很多程序员有复杂崇拜的倾向总觉得架构越花哨越高级。我见过不少精心设计过度的项目最后没人能接手维护。相反那些朴实无华、每个模块都能一句话讲清楚的系统往往活得最久。简化不代表不想清楚而是把复杂度控制在当前问题需要的范围内。这部分经验和编程尚未被解决的题目有关——正因为编程本质复杂你更不应该主动制造额外的复杂度。我的一个判断标准是如果三个月后的自己看到这段代码能一眼读懂那这个设计就是合格的。4.3 新手入行建议先练什么给刚入行的朋友几句实在话。第一先把一门语言的基础打得扎扎实实别急着学一堆框架的皮毛。基础扎实的人换框架很快基础虚的人学十个框架也写不出有质量的代码。第二多读别人的代码特别是那些正经的开源项目的源代码。读源码能帮你理解真正的工程实践是什么样的比看一堆二手博客强太多。第三一定要学会调试包括断点调试、日志分析、性能剖析。这是你以后排查问题的主要武器越早练越不吃亏。还有一个想特别提醒的别把自己工具化。现在AI工具很会写代码如果人只会写代码那确实容易被替代。但你要是能懂业务、会判断方案、能设计系统、hold住疑难问题你就不是能写代码的人而是能用代码解决问题的人。这两者的差别就是编程尚未被解决留给我们的活路。机器替代的是翻译替代不了判断。4.4 一种更健康的心态与不确定性共存最后说说心态。我在这个行业待得越久越觉得不确定性就是这一行的底色。你不可能等需求完全确定再动手因为你等不到那天你不可能把所有边界条件都想到因为总有一部分在真实环境里才会暴露你不可能写出永不出bug的代码因为bug本身就是复杂系统的副产品。所以别用彻底解决作为追求那是自己给自己找别扭。正确的心态是把编程当成持续的博弈每轮迭代都尽量降低不确定性用测试、评审、小步快跑、快速反馈把风险压在可控范围内。接受未知是常态之后你的焦虑会少很多判断也会清醒很多。我经常用一句自嘲话来调整状态如果编程真的被解决了大概也就没有我们什么事了。正因为这些难题还在我们才有一口饭吃。这个行业真正的护城河从来不是某个语法的熟练度而是你在不确定性面前依然能稳定输出判断和结果的能力。5. 常见误区与实操速查最后整理几个最常见的认知误区和我自己用来校准的标准方便你对照。5.1 最常见的四个认知误区误区真相有了AI工具写代码不再需要思考AI能帮你写代码片段但它不理解你的业务上下文也无法为结果负责框架选得好项目就成功了一半框架只是脚手架需求理解、架构取舍、团队协作才是成败关键重构能治好一切烂代码没有测试覆盖和业务理解的重构大概率会引入新问题代码写得快编程能力强写得快但总返工远不如想得清楚一次做对可维护性才是真正的产能这张表我建议记下来。每次你觉得自己被某个新工具、新框架惊艳到的时候回来看看第二列能帮你省不少盲目折腾的时间。5.2 三个可复用的判断标准额外给出几个我自己在开发中用来校准的实操问题第一接到一个需求时先问目的是什么而不是怎么实现。目的清楚了方案往往会清晰很多还有很多看似必须做的部分会被直接砍掉。这是我砍无效需求最有效的一招没有之一。第二写代码前如果这个函数你能用一句话说清楚它输入什么、输出什么、依赖什么那大概率设计是清楚的。说不清楚先别说代码回去把接口定义改清楚。第三改别人代码时如果心跳加速、找不着北就先停下动手去补测试或者找同事对齐。宁可慢一点也不要凭感觉硬改。凭感觉的一锤子买卖后面大概率用十倍时间还债。5.3 一个适用面很广的经验清单最后放一个清单算是我这些年沉淀下来的一套备用操作细则写代码的时候顺手过一遍能避开不少坑接需求先复述确认不留模糊地带。写代码前先想好验证方式免得写完没法确认对不对。每次改动尽量小、可单独验证别把十个改动混在一次提交里。关键逻辑一定要有测试保护别裸奔。有技术决策简单记录下当时为什么这么选写进提交说明即可。遇到用时超过半小时的问题先停下来重新读一遍报错信息和代码别在错误方向上加速。再急也不要删掉旧的debug手段线上排查工具永远要留着。连续写代码超过90分钟起来走一圈回回神。状态不好时写出的代码你回头要吸很久的尾气。说句实在话我写这篇内容的时候编程尚未被解决这句话一直在我脑子里转。它让我想到自己刚入行时那种我什么时候才能把编程彻底搞定的天真也想到这些年面对一个个项目时越来越强的一种体感我们不是要打完一场仗而是要接受一场打不完的仗然后把每一天的攻防都做扎实。如果你现在正为某个老项目的烂摊子头疼或者因为AI工具的崛起而焦虑自己的价值我的建议很简单别盯着那些被解决的部分焦虑去看看那些还没被解决的部分——那才是这个行业真正的机会所在。把判断力、系统思维、沟通能力和对业务的理解练起来这些东西一时半会儿还没法外包给任何工具至少在可预见的未来都是这样。