做了十年后端，我越来越不敢说自己会写代码
前几天，一个刚入职的年轻同事问我：“哥，你会写代码吗？”我愣了几秒，最后说：“我在写，但我不太敢说自己会。”他笑了，以为我在谦虚。只有我自己知道，这不是谦虚，而是一种被十年生产环境反复教育后的条件反射。做了十年后端，我越来越不敢说自己会写代码。不是因为我写不出功能，而是因为我越来越清楚，“会写”这两个字背后，藏着一整套关于责任、边界、代价和不确定性的东西。
一、会写代码，曾经是一个很轻的答案
十多年前，我刚入行时，对“会写代码”的理解非常简单：掌握一门语言，熟悉一个框架，能按需求文档把功能做出来，就算会。那时候，我在简历上写“精通 Java”，在面试里说“熟悉 Spring、MySQL、Redis”，心里并不虚。因为我能用代码解决眼前的题目，能让页面动起来，能让接口返回数据。对当时的我来说，代码是手艺，是工具，是通往职业未来的门票。
2016 年前后，我参与了一个从零到一的系统。那是我第一次完整地经历需求评审、表设计、接口定义、联调、上线。上线那天，我盯着监控，看到请求量一点点上涨，心里有一种朴素的骄傲：这是我写的。那时候，如果有人说我不会写代码，我一定会不服气。我会列出自己会用的技术栈，会说自己排过多少 bug，会强调自己能在 deadline 前交付。那种自信很真实，也很脆弱，因为它建立在“能跑起来”之上。
但十年后回头看，那种“会”，其实只是最表层的会。它像一个人会拿笔，就宣称自己会写作；会按琴键，就宣称自己会弹琴。能写出代码，和能写出好代码，能写出活得久、扛得住、对别人负责的代码，中间隔着无数个深夜、无数次事故、无数次推翻重来。代码从来不是孤立的字符，它一旦进入生产环境，就会和流量、数据、用户、金钱、组织发生关系。那时我不懂这些，所以敢说“我会”；现在我懂了，所以不敢。
二、第一次不敢说：生产事故教我重新定义“会”
第一次让我对“会写代码”产生怀疑的，是一次线上事故。那是一个看起来再普通不过的缓存逻辑。测试环境没问题，预发环境没问题，上线后前两个小时也没问题。直到晚高峰，缓存集中失效，数据库连接池瞬间被打满，订单接口开始超时，用户重复提交，客服电话被打爆。我们一群人盯着屏幕，像在急诊室里抢救一个突然心梗的病人。
最后定位到问题，只改了一行代码。但那一行代码背后，是并发、缓存、超时、重试、幂等、降级、容量评估等一整套知识的缺失。那一刻我才明白，会写代码不是“能跑起来”，而是知道它什么时候会不跑；不是“功能实现了”，而是知道它在极端情况下会怎样失败。测试通过只是最低标准，生产环境才是真正的考试。你可以在本地写出完美的逻辑，但线上会用最残酷的方式告诉你，完美只是幻觉。
从那以后，我再看自己的代码，总会多问几个问题：如果流量涨十倍呢？如果依赖服务挂了？如果消息重复？如果时钟回拨？如果数据库主从延迟？如果用户疯狂点击？这些问题没有出现在需求文档里，但它们才是后端工作的日常。会写代码，首先要会想象失败。一个只会写成功路径的人，不能算会写代码；一个能设计失败路径、兜底方案和恢复机制的人，才刚摸到后端的门槛。
三、第二次不敢说：代码是负债，不是资产
很多公司把代码量当成产出，把系统数量当成成绩。但做了十年后端，我越来越觉得，代码更像负债。每一行代码，都是一份未来要维护、要理解、要测试、要迁移、要修 bug 的承诺。它今天帮你实现功能，明天就可能成为别人绕不过去的坑。写得越多，负债越多；改得越急，利息越高。代码不是写完就结束，而是写完才开始计息。
所以我现在评审代码时，最常问的不是“这个能不能实现”，而是“这个能不能不写”。能不能用配置解决？能不能用现有能力组合？能不能改流程？能不能让业务方接受一个更简单的方案？如果一个需求必须写代码，那就要问：能不能少写一点？能不能把复杂度关在一个边界清晰的模块里？能不能让未来的人一眼看懂？这些问题听起来像拖延，其实是负责。因为多写的那部分，未来一定会有人付出代价。
真正成熟的工程师，不是写代码最多的人，而是知道什么时候不该写的人。删掉一千行代码，往往比增加一千行代码更有价值。因为删除意味着你理解了系统，敢于做减法，敢于承担“少即是多”的风险。会写代码的人很多，会删代码的人很少。而后者，才是团队真正的稀缺品。我曾经为了“以后可能有用”保留了一堆抽象，结果三年后没人敢动；也曾经删掉一个废弃模块，让整个服务的启动时间少了一半。那次删除给我的成就感，超过很多次新增。
四、第三次不敢说：AI 让“写”变便宜，让判断变昂贵
2026 年，AI 辅助编程已经像当年的 IDE 一样普及。你描述一个需求，模型几秒钟就能生成一版代码；你贴一段报错，它能给出修复建议；你甚至可以让它写测试、写文档、写迁移脚本。表面上看，写代码的门槛被大幅拉低了。于是有人问：以后是不是人人都会写代码？我的回答是：写代码这件事确实变便宜了，但判断代码是否正确、安全、可维护，反而变得更昂贵。
模型可以生成一个排序函数，但它不知道你的数据里有一百万条重复记录；可以生成一个接口，但它不知道这个接口会被移动端和高并发定时任务同时调用；可以生成一个 SQL，但它不知道线上表有十亿行、索引选择性极差。它会自信地给出答案，而工程的责任仍然落在你身上。会用 AI 写代码，不等于会写代码。就像会用计算器，不等于会数学。工具越强，使用者的判断力越重要，因为错误也会被包装得更像正确。
在 AI 时代，后端工程师的核心能力正在从“记忆语法”转向“提出好问题、定义边界、审查结果、承担后果”。提示词写得再漂亮，也不能替代对业务的理解、对风险的预判、对系统的敬畏。模型可以帮你写，但不能帮你负责。所以当别人说“AI 都会写代码了，你还有什么价值”时，我更愿意说：我的价值恰恰在于知道哪些代码不该让 AI 写，哪些生成结果必须推翻，哪些边界必须自己守住。AI 可以加速产出，但不能替你承担凌晨三点的告警。
五、第四次不敢说：分布式系统里，没有“会写”这回事
单机时代的“会写代码”，至少还有确定性。一个函数输入固定，输出大体可预期。但到了分布式系统，确定性成了一种奢侈品。网络不可靠，时钟不可信，节点会宕机，消息会重复，顺序会错乱，部分失败是常态。你以为自己在写函数，其实是在写协议；你以为自己在调接口，其实是在设计状态机。
我做过一个跨服务的数据同步。最初的设计很直观：A 服务变更后发消息，B 服务消费消息更新数据。听起来没问题，但很快遇到重复消费、消息丢失、消费延迟、顺序颠倒、版本冲突。每一个问题单独看都不复杂，组合在一起就变成了泥潭。最后我们不得不引入幂等键、版本号、补偿任务、对账机制、人工兜底。那套系统没有一行代码是“随便写写”的，每一行都在回答同一个问题：如果一切都不按预期发生，怎么办？
在分布式系统里，“会写代码”这个说法太轻了。你不仅要会写，还要会设计失败路径，会做容量规划，会定义一致性级别，会权衡延迟与正确性，会在没有全局锁的情况下保证数据最终一致。你写的不是代码，是一套关于信任和风险的制度。越深入，越不敢说自己会。因为你知道，任何一个“应该不会发生”的假设，都可能在某个凌晨变成事故报告里的第一行。
六、第五次不敢说：不懂业务，代码只是语法正确的猜测
刚入行时，我以为后端工程师只需要面对技术。后来才发现，代码是业务的投影。你不懂业务，写出来的东西可能语法正确、测试通过、性能优秀，但就是不对。比如什么叫“有效订单”？退款后算不算？部分退款呢？跨月呢？风控拦截呢？这些定义不在代码里，在业务规则里，在财务口径里，在合同条款里，在客服的话术里。
我曾经做过一个优惠券系统。技术方案很漂亮：规则引擎、缓存预热、库存扣减、异步发券。上线后却发现，业务方要的是“先到先得”，我们做成了“先扣减后确认”；业务方要的是“退款不退券”，我们做成了“退款自动退券”。结果系统越稳定，错误越稳定。那一刻我明白，技术上的正确，不等于业务上的正确。会写代码，必须会问问题，会把模糊需求翻译成清晰规则。
十年下来，我越来越不敢在没搞懂业务之前写代码。因为我见过太多“技术很牛、业务很痛”的系统。真正会写代码的人，不是把需求文档当成圣经，而是能走到业务现场，理解用户怎么用、钱怎么流、风险在哪里、合规红线是什么。代码只是最后一步，前面的理解才是决定性的。你能写出优雅的代码，但如果优雅地解决了错误的问题，那只是更高级的浪费。
七、第六次不敢说：可观测性才是后端的第二语言
年轻的时候，我以为写完代码、测完用例、发上线，任务就结束了。后来才知道，上线只是开始。一个系统如果没有日志、指标、追踪、告警，就像一架没有仪表盘的飞机。你飞得再快，也不知道油还剩多少，发动机温度是否正常，前方有没有风暴。会写代码，必须会写可观测性。
我经历过一次线上排查，问题表现为偶发超时。没有明显错误日志，没有 CPU 飙升，没有数据库慢查询。我们像侦探一样，从入口网关查到服务 A，再到服务 B，再到缓存、消息队列、第三方接口。最后发现是一个看似无害的重试逻辑，在特定网络抖动下放大了流量。如果没有链路追踪和细粒度指标，这个问题可能永远找不到。代码写完了，不等于系统可理解；系统不可理解，就等于不可维护。
所以我现在写代码时，会顺手想：这里要不要打日志？日志级别是什么？指标怎么定义？追踪上下文怎么传？告警阈值怎么设？出问题时，值班的人能不能在五分钟内知道发生了什么？这些问题看起来不产生业务价值，但它们决定了系统能不能活过第一个故障。会写代码，也包括会写“让未来的人能看懂系统”的代码。监控不是运维的专属，而是工程师的良知。
八、第七次不敢说：架构没有银弹，只有代价
做了十年后端，我见过太多架构潮流：SOA、微服务、中台、云原生、Service Mesh、Serverless、事件驱动。每一种都有成功案例，也有失败废墟。年轻的时候，我会追新，觉得用了新架构就是先进。现在我不敢了，因为我知道架构没有银弹，只有代价。微服务换来独立部署，也换来分布式复杂度；事件驱动换来解耦，也换来最终一致性和调试困难；Serverless 换来弹性，也换来冷启动、厂商锁定和可观测性挑战。
架构师的工作，不是选最酷的技术，而是选最合适的 trade-off。你要知道团队能力、业务阶段、流量规模、成本预算、合规要求、演进路径。一个十人团队维护三十个微服务，可能不如一个模块化单体；一个日订单几百的系统，上 Kafka 和分库分表，可能只是自嗨。会写代码，必须会做技术决策，而技术决策的本质是取舍。
所以我越来越不敢轻易说“这个我会”。我会写某个服务，不代表我会设计整个系统；我会用某个中间件，不代表我能在生产环境把它运维好。真正的“会”，是知道它的边界、代价、失败模式，以及什么时候不该用它。承认不会，反而让我在做架构决策时更谨慎。因为架构的影响不是一天，而是三年、五年，甚至更久。
九、第八次不敢说：代码审美是长期主义的体现
代码首先是写给人看的，顺便给机器执行。这句话我年轻时听过，但没真正懂。后来维护过别人留下的系统，也维护过自己三年前写的代码，才明白代码审美有多重要。命名是否清晰，函数是否单一，依赖方向是否合理，边界是否明确，抽象是否过度，注释是否解释“为什么”而不是“是什么”。这些细节不影响功能，却影响一个团队的长期效率。
我见过一个类有三千行，方法名从 doSomething 到 doSomething2，再到 doSomethingNew。也见过为了“复用”而层层抽象，最后改一个字段要跳转十几个文件。还见过没有测试、没有文档、没有类型约束的系统，靠口口相传维持。这样的代码能跑，但每改一次都像拆炸弹。会写代码，不是能写出让机器跑的代码，而是能写出让人敢改的代码。
代码审美不是洁癖，而是对未来的善意。你今天多花十分钟起一个好名字，可能为未来的人省下十个小时。你今天多写一个测试，可能避免一次凌晨三点的告警。你今天克制住过度设计的冲动，可能让系统多活五年。十年后，我越来越不敢说自己会写代码，因为我见过太多“能跑但不敢改”的代码，也见过太多因为审美缺失而付出的代价。代码的美，最终会变成团队的速度。
十、第九次不敢说：知识半衰期越来越短
后端技术的更新速度，让人既兴奋又焦虑。十年前流行的框架，今天可能已经无人维护；五年前的最佳实践，今天可能已经被云服务封装；三年前需要自己搭建的组件，今天可能只是一个托管服务。你刚学会一个工具，它就可能被新的范式取代。知识半衰期越来越短，意味着“会”这个状态本身就不稳定。
但我也慢慢发现，真正不变的东西很少，却很重要：计算机基础、网络原理、数据结构、操作系统、数据库原理、分布式共识、抽象能力、调试能力、学习能力。框架会变，协议会变，部署方式会变，但如何定位问题、如何拆解复杂度、如何权衡取舍，这些底层能力可以迁移。会写代码，不是会某个版本的 API，而是能在变化中抓住不变。
所以我不敢说自己会写代码，因为我知道今天的“会”可能只是暂时的。但我敢说自己还在学习，还在更新，还在保持对未知的诚实。承认知识会过期，反而让我不那么焦虑。与其追求“全部都会”，不如建立一套快速学会、快速验证、快速放弃的学习机制。十年后端，我最大的收获不是掌握了多少技术，而是知道自己永远需要重新开始。
十一、第十次不敢说：责任比能力更重
代码写到第十年，我越来越意识到，后端工程师手里握着的不只是逻辑，还有责任。一个支付 bug 可能让用户损失金钱，一个权限漏洞可能泄露隐私，一个限流缺失可能拖垮整个平台，一个数据迁移错误可能让业务停摆。代码一旦上线，就不再是个人作品，而是社会系统的一部分。你写的每一行，都可能影响真实的人。
这种责任让我不敢轻狂。年轻的时候，我会说“这个简单，我马上搞定”；现在我会说“让我先确认边界、影响范围和回滚方案”。不是我变慢了，而是我知道快和稳之间需要平衡。医生不会说包治百病，律师不会说稳赢官司，成熟的工程师也不该说“所有代码我都会写”。敬畏不是软弱，而是专业。
我仍然热爱写代码。解决问题、让系统跑起来、把混乱变成秩序，这些依然让我有成就感。但我不再轻易用“会”来概括它。因为“会”意味着承诺，而承诺需要能力、经验、判断和运气。十年后端，我学会了对代码保持敬畏，也学会了对自己的无知保持诚实。能力让你写得更快，责任让你知道什么时候该慢下来。
十二、我仍然写代码，但不再轻易说“会”
说了这么多“不敢”，容易让人误以为我在自我否定。其实不是。我依然每天写代码、读代码、评审代码、删代码。我依然会因为一个优雅的设计而兴奋，会因为一个难缠的 bug 被解决而满足，会因为系统平稳运行而安心。我只是不再把“会写代码”当成一个可以轻易贴在自己身上的标签。
如果今天有人问我：“你会写代码吗？”我可能会这样回答：“我会写一些代码，也知道很多代码我写不好。我会实现功能，也会评估风险。我会用 AI 提高效率，也会对它的输出保持怀疑。我会追求性能，也会考虑成本。我会做架构，也会承认架构有代价。”这不是圆滑，而是十年经验之后更准确的自画像。
我更愿意说：我在学习如何让代码少一点、好一点、活得久一点。少一点，是克制；好一点，是审美；活得久一点，是责任。会写代码不是一张证书，而是一种持续的承诺。你写下代码，就要为它的未来负责。你删掉代码，也要为删除的决定负责。你选择不写，更要对业务和团队负责。
十三、给年轻同事的几句话
如果你刚入行，正在努力成为“会写代码”的人，我想分享几点不一定正确、但足够真诚的建议。第一，不要以会多少框架为荣，以解决了什么问题为荣。技术栈会过时，解决问题的能力不会。第二，学会读代码、删代码、写测试、写文档。写代码只是工程的一部分，维护才是大头。第三，尽早理解业务、成本和用户。不懂业务的技术，容易变成精致的自嗨。
第四，拥抱 AI，但不要依赖 AI。让它帮你查资料、写样板、做重构，但关键逻辑、边界条件、安全审查必须自己把关。第五，培养判断力。知道什么该做，什么不该做，什么现在做，什么以后做。判断力来自实践，也来自复盘。第六，保持敬畏。线上无小事，一行代码可能改变很多人的一天。
最后，不要害怕承认自己不会。真正的成长，往往从“我不会”开始。最危险的状态，不是不会，而是以为自己都会。技术世界太大，没有人能全部掌握。你能做的，是在自己的领域里足够深，在边界之外足够诚实，在变化之中足够坚韧。
结语：不敢，是一种清醒
做了十年后端，我越来越不敢说自己会写代码。因为“会”太轻，“代码”太重。代码连接着业务、用户、金钱、隐私、安全和社会运转。它既是创造，也是负债；既是艺术，也是责任；既需要自信，也需要敬畏。2026 年的技术世界比十年前更快、更复杂、更智能，但我依然相信，真正稀缺的不是会敲键盘的人，而是知道为何敲、何时不敲、敲完如何负责的人。
所以，如果你问我到底会不会写代码，我会说：我在写，也在学；我做过很多，也还有很多不会；我不敢轻易说“会”，但我会继续认真对待每一行。也许，这才是“会”的真正开始。