你不是来写代码的
在工程师团队中，我注意到了一个普遍现象：一旦拿到任务，大多数人的第一反应是打开编辑器、新建分支、开始写代码。但我始终觉得，这可能走错了方向。
二十多年来，我在不同领域构建软件的经历告诉我：真正为项目和公司创造最大价值的工程师，往往不是最高产的程序员。那些最有价值的人，首先做的是思考、提问、对需求提出质疑、进行分析、制定计划。有时在这个过程中，他们发现根本不需要写代码——而这恰恰是最好的结果。
这个习惯曾经很有价值。今年 AI 已经能以远超我们的速度写代码，它的价值变得更加重要：不只靠写代码，也能为公司创造价值。
身份陷阱：别把软件工程等同于代码输出
有一种观念认为，软件工程师的价值取决于他写了多少代码，这其实是一种陷阱。人们习惯用代码行数、合并的 Pull Request 数量、上线的功能数量来衡量工程师的能力。如果按这个逻辑，一个能写代码的计算机程序就足以称为软件工程师，而大多数人就不是了——尤其在 AI 时代，这个观念的问题更加明显。
软件工程师的工作起点，不是想着用什么工具或程序，而是先问几个问题：
- 我们要解决什么问题？
- 我们要帮助谁？
- 为什么解决这个问题很重要？
- 如果不做这件事而做别的，会有什么后果？
只专注于写代码的人，那是"开发者"做的事。软件工程师思考的是工作的最终成果。
写代码时，你关心的是代码能不能正常运行。但软件工程不同——它要求代码在出现问题时能够应对，容易理解和修复，且即便不是原作者，其他人也能够接手维护。它还要考虑对关联系统的影响，像是在看一幅全景图，思考各个部分如何协同工作。
代码是负债，不是资产
这一点需要从一开始就理解清楚。尽管我们日常工作主要围绕代码展开，但我们需要代码，而不是"想要"代码。原因很简单：你写的每一行代码，未来都需要维护，需要被你或同事理解，需要在新需求出现时被修改——这些都不是免费的。代码本身不产生价值，直到它所实现的功能收益超过维护它的成本。
现实中，大量代码从未达到这个盈亏平衡点。代码能力是资产，但代码本身是为了产出那些能力而承担的负债。目标应该是用尽可能少的代码来实现业务能力。
Jeff Atwood 说过：最好的代码就是没有代码。你没写的代码不会有 Bug，不需要测试，永远不需要维护。如果你通过删除代码、改变流程、或使用已有工具来解决问题，那才是真正做好了工作。
这不是反对写代码，而是要知道何时该写。我们需要谨慎对待的恰恰是代码本身，在动手之前应该三思。代码是我们需要克制的对象。
跳过思考环节会发生什么
来看一个具体例子。这种情况我见过很多次： 假设收到一个工单："用户反馈结账页面很慢，我们需要修复性能问题。" 工程师通常会这样处理：查看代码，了解功能逻辑，找出一个慢查询，然后添加索引，可能还会补充测试。问题修复了。
然而三周后，工单被重新打开。原来用户依然没有完成支付——慢查询根本不是真正的问题。用户离开支付表单的原因是表单字段太多，需要填写的内容太繁琐，而不是页面加载慢。没有人事先查看过用户实际使用网站的数据。工程师让结账变得更快，但这并不是用户真正遇到的困难。
那么，如果工程师先花时间思考问题呢？
工程师为什么总忍不住先写代码
度量方式的陷阱
问题根源在于：我们衡量工程师工作的方式，本身就在鼓励"先动手"。
晋升看的是交付了多少功能，而不是解决了多少问题。删除冗余代码、让系统更简单——这些很少有人会得到表扬。然而工程师们都很聪明，他们会遵循能带来奖励的规则行事。这就是Goodhart 定律的典型案例。
组织层面的病症
这不只是个人问题，而是系统性的。在很多团队里，从拿到工单那一刻起，计时就开始了。"有进展"就意味着"在写代码"。结果就是：工程师在还没真正理解问题之前就开始编码，组织还为此给了奖励，最终交付的东西不是大家想要的，然后所有人都一脸困惑。
在信息流通顺畅的小团队中，人们能直接看到用户受到的影响，理解问题相对自然。但在大公司里，一行代码要经过多个团队、多个层级才能体现出业务影响，这种"代码先行"的毛病就更严重。
AI 加速了这一问题
AI 编程工具让代码生成变得极其容易。一个熟练工程师配合 AI 工具，几分钟就能产出过去需要几小时才能完成的初版代码。听起来很美好——但前提是你在使用工具之前已经想清楚了要做什么。
可以把 AI 工具想象成一个按指令干活的工匠：你描述得清楚，它就干得快且对；你自己都没想明白，它照样很快给你造出来，但造的是错的东西。AI 无法判断自己是否在做正确的事，这个责任始终在工程师身上。
2025 年，METR 的一项研究跟踪了一批有经验的开发者，让他们分别在没有 AI 辅助和有 AI 辅助的情况下工作。开发者们事前预测 AI 会让他们快 24%，用完之后自我感觉快 20%。而实际数据显示：他们慢了 19%。研究者指出，主要原因是过度乐观的预期加上 AI 实际可靠性不足。
GitClear 另分析了1.53 亿行代码，发现使用 AI 工具后，复制粘贴的代码量是之前的 4 倍，代码被反复修改的频率也更高了。我们产出的代码越来越多，但真正需要的比例反而在下降。
当然，AI 模型会越来越强。但无论 AI 多厉害，知道什么代码真正需要、什么不需要这一点，永远取决于人。
当工程师在动手前深思熟虑，AI 工具的效果就完全不同了。可以说 AI 工具真正帮助优秀的工程师把工作做得更好——工程师的计划越清晰，AI 工具的产出就越有价值。AI 不会让所有人变得一样，它只是把门槛提高了：工程师需要比以往更会思考。
想清楚再动手，到底该怎么做
不是多开会、多写文档
需要澄清一点："想清楚再写代码"绝不是鼓励开一堆没人看的会、写一堆没人读的文档。
如果把问题解决的工作直接丢给 AI，跳过理解问题的阶段，绕过"为什么"直接跳到"怎么做"——那么如果工程师本身不具备评估架构决策的能力，AI 只会让我们在错误的方向上跑得更快。Anthropic 最近的研究也印证了这一点。
在 AI 热潮中观察到一个现象：人人都在关注执行，却没人关注思考和决策。未来，定义产品和问题的能力将比实现能力更值钱。
一个简单可落地的习惯
我的做法是：动手写非简单任务之前，先在笔记里写一段话，回答三个问题：
- 真正的问题是什么？
- 谁会受到这个问题影响？
- 如何判断问题已经被解决了？
半数情况下，写这段话的过程中会突然发现之前没意识到的问题——因为写作是最好的思考方式。这一步骤帮我把认知差距缩小，甚至在接受需求时就把它拉平，而不是等到写代码之后才发现方向错了。
更大项目的做法
对于复杂项目，我会写一份简短文档，概述问题本身和可选方案，其中必须包含以下四个维度的思考： 弄清楚问题本质——你必须知道自己要解决的是什么。不要只听客户说他们"想要什么"，要深挖他们"真正需要什么"。
理解业务背景——技术决策本质上是业务决策。一个技术上看似很酷、但对业务毫无帮助的方案，纯属浪费时间。
拆解问题——找出共性模式，用抽象思维剥离不重要的细节。
提前规划——在动手之前把思路理顺，最终方案写入文档留存。
背景：代码只是最后一步
软件开发中，最昂贵的错误往往不是敲键盘时的笔误，而是需求本身就没有想清楚。本文是该系列的最后一篇，聊聊 2026 年软件工程师真正该做的事。
充分沟通，把需求当合同
做项目时，需求是工程师、利益相关者和用户之间的契约。在动手之前，必须确保所有人对齐同一个目标。否则项目容易失控，截止日期也会成为空谈。
先做原型，用最小成本验证假设
在投入大量时间和资金之前，先做出最简版本测试想法是否可行。AI 时代尤其如此——验证"这是否值得做"比写代码更重要。
Google 和 Amazon 都在践行这一原则。Amazon 有一个叫 Working Backwards 的流程：在写任何代码、花任何钱、招任何人之前，先写好新闻稿和常见问题清单。目的是在消耗工程资源之前就把不合格的想法拦下来。大多数提案不会通过——这很正常，因为大多数提案本来就不该通过。
软件工程师的真正职责
2026 年软件工程师的工作，不是快速写大量代码，而是理解问题、搞清楚"我们真正需要什么"。这意味着把想法转化为清晰的技术需求，问出别人想不到的问题。
判断"做什么"比"怎么做"更关键
工程师要决定哪些功能值得构建、哪些可以直接跳过。每一个新功能都是风险，必须权衡它带来的好处是否值得后期维护成本。
架构判断同样重要——软件怎么建、往哪个方向演进，如果在早期犯了错，修复代价会非常高。
AI 生成的代码仍需人工审核&查验
工程师还需要持续关注 AI 生成的代码（至少目前是这样），就像审核&查验新团队成员写的代码一样。需要 catch AI 因为不了解上下文而犯的错误。简言之，AI 的输出仍需要人类验证。
有时候，最好的做法是删代码。减少代码本身就可以是一种功能。
AI 写不了的部分，才是真正重要的
AI 能生成大量代码，但无法决定生成什么代码、某个功能是否真的必要、也无法权衡商业决策的利弊。这些都需要人类判断——而这恰恰是工作中更难的部分。
写代码的能力依然重要，但含义在变。它从"写得快"转向"知道什么时候需要写代码"以及"判断生成的代码在业务价值上是否正确"。工程师必须理解系统各部分如何协同工作。
影响与建议
软件开发的昂贵错误很少来自简单的编码错误，更多来自试图解决一个根本没想清楚的问题。当我们真正理解一个问题时，代码只是顺水推舟的事——真正的工程工作在于思考、提问和定义问题。
接到任务时，在动手之前先写下两点：现在的系统实际哪里出了问题，以及怎么才算真正修好了。养成这个习惯，它带来的改变比任何工具或技术都大。
最好的软件工程师早就明白这一点：代码是解决问题的最后一步。最好的代码是根本不写代码。如果必须写，请记住——每一行代码都是你给未来的一份承诺。
评论