很长一段时间，我的博客停更了。

不是没东西写，而是潜意识里有个声音一直在说：你是软件工程师，写代码才是正经事，写文章能证明什么？

这个声音听起来很务实，其实是一种偏见。

直到有一天，我开着车堵在高架上，脑子里突然冒出一句话：

写作就是编程，编程也是写作。

这个念头一开始有些莫名其妙，但越想越觉得准确。

尤其是在 AI 编程工具越来越强的今天，我更加确信：工程师真正的竞争力，从来不是"会敲代码"，而是能够在头脑中建立一个清晰的抽象世界，并把它准确地表达出来。

AI 可以生成代码，但它不会替你完成真正困难的那部分工作——理解问题、建立模型、划定边界、做出取舍，并判断结果是否正确。

这些，才是工程师的护城河。

编程的本质，不是写代码，而是建模

很多非技术人员以为，软件开发的核心动作是"敲代码"。

这种理解，就像认为建筑设计的核心动作是"画图纸"一样，只看到了最后的表达形式，忽略了背后真正复杂的部分。

一个软件系统在被写出来之前，首先应该存在于工程师的大脑里。

你需要想清楚：

  • 系统里有哪些核心实体？
  • 实体之间是什么关系？
  • 状态如何变化？
  • 哪些约束必须始终成立？
  • 哪些操作是幂等的？
  • 并发情况下会发生什么？
  • 网络失败、消息重复、事务中断时，系统应该表现出什么行为？
  • 哪些问题是当前必须解决的，哪些复杂度应该推迟引入？

这些问题的答案，构成了系统的抽象模型。

代码只是这个模型在某种编程语言中的投影。

一个真正清晰的系统，不是从第一行代码开始变清晰的，而是在工程师的头脑中先被想清楚，然后才通过代码固化下来。

反过来，很多混乱的系统，也不是因为代码写得不够优雅，而是因为一开始就没有建立清晰的模型。

实体职责混在一起，状态流转没有定义，业务边界靠口口相传，异常处理依靠经验补救。这样的系统，即使每一行代码都符合规范，也会随着业务演进变得越来越难维护。

所以，编程的第一性原理不是语法、框架或工具，而是建模能力。

AI 不是传统意义上的编译器

AI 编程助手刚流行起来的时候，很多人喜欢用"编译器"来形容它：

以前我们用 Java、Python 写代码，交给编译器翻译成机器指令；现在我们用自然语言描述需求，交给 AI 生成代码。

这个类比很直观，但并不准确。

传统编译器处理的是形式语言。语法规则是明确的，输入和输出之间有严格定义。同一份代码，在相同编译条件下，结果应当是确定的。

而大语言模型处理的是自然语言。自然语言天生模糊，充满省略、歧义和上下文依赖。同一个需求，换一种说法，AI 可能生成完全不同的实现。

这意味着，自然语言并不会因为我们用它来写代码，就自动变得精确。

你对 AI 说：

帮我实现一个用户登录功能。

它可以生成一个看起来完整的接口：接收用户名和密码，校验账号，返回 JWT。

但这离生产可用还差得很远。

一个真正的登录系统，还涉及密码哈希算法、盐值管理、登录失败次数限制、验证码策略、Token 过期时间、Refresh Token 轮换、会话失效、设备管理、权限模型、日志脱敏、防重放攻击、审计追踪等一系列问题。

AI 不知道你的系统边界、安全等级、业务约束，也不知道哪些异常可以接受，哪些事故绝对不能发生。

除非你把这些东西讲清楚。

所以，AI 不是把"任何人说的话"自动变成正确软件的魔法编译器。它更像一个能力很强的实现者：你给它的模型越清楚，它交付的结果越接近你的预期；你脑子里本来就很模糊，它只会把你的模糊放大成一堆看似完整、实则漏洞百出的代码。

工程师的核心竞争力：清晰地抽象，准确地表达

AI 时代，工程师最核心的能力可以浓缩成一句话：

在头脑中建立一个清晰的抽象世界，然后清晰地思考，准确地表达。

这件事听起来简单，实际上非常困难。

所谓"清晰的抽象世界"，不是知道几个设计模式，也不是能画出一张漂亮的架构图，而是能把一个混乱的现实问题，转化成边界明确、关系清楚、可以被验证的系统模型。

它至少包括四种能力。

第一，识别本质问题的能力

很多需求表面上是在说"做一个功能"，背后真正要解决的可能是效率、信任、成本或协作问题。

如果工程师只是机械地接收需求，就很容易把系统设计成一个功能的堆叠。

而优秀的工程师会继续追问：

  • 用户真正要完成的任务是什么？
  • 哪个环节是瓶颈？
  • 这个需求是否只是某种更深问题的表层症状？
  • 有没有更简单的路径可以达到同样的目标？

这种能力决定了你是在"实现需求"，还是在"解决问题"。

第二，建立系统模型的能力

面对一个复杂业务，工程师需要找到核心概念，定义它们的关系，并识别系统里的不变量。

比如设计交易系统，你要知道订单、支付、库存、履约之间如何协作；设计消息系统，你要知道消息状态如何流转，重复投递如何处理，消费失败如何补偿；设计权限系统，你要知道用户、角色、资源和动作之间应该怎样组合。

这些模型不一定一开始就完美，但必须清晰、可讨论、可修正。

模糊的想法无法被可靠地实现，更无法被 AI 可靠地实现。

第三，拆解与组合的能力

工程师既要把大问题拆成小问题，也要保证小问题组合起来之后，仍然构成一个完整的系统。

拆解不是简单地把任务列成 TODO，而是找到合理的边界：

  • 哪些职责应该放在同一个模块？
  • 哪些依赖必须被隔离？
  • 哪些状态应该集中管理？
  • 哪些变化最容易发生，应该通过抽象隐藏起来？
  • 哪些复杂度现在不该引入？

很多人只会拆，不会合。

他们可以把一个系统分成十几个服务，却说不清楚服务之间的数据一致性如何保证；可以把代码拆成几十个类，却无法解释这些类共同表达了什么业务概念。

真正的架构能力，不是"拆得多"，而是拆完之后，整体依然简单。

第四，验证结果的能力

AI 生成代码之后，工程师不能只负责点"接受"。

你需要判断：

  • 这个实现是否真的满足需求？
  • 有没有隐藏的边界条件？
  • 并发下是否安全？
  • 失败时是否会留下脏数据？
  • 性能瓶颈在哪里？
  • 测试是否真的覆盖了关键路径？
  • 日志和监控能否支撑问题排查？
  • 这个方案短期有效，长期是否会成为负担？

AI 可以帮你提高效率，但责任仍然在工程师身上。

越是强大的工具，越需要强大的判断力来驾驭。一个无法验证结果的人，用 AI 写代码，只是在更快地制造风险。

为什么写作能力和编程能力是同一件事

我后来越来越觉得，写作和编程训练的是同一种底层能力。

写文章时，你要先想清楚核心观点，再决定结构：哪些内容先说，哪些内容后说，哪些概念需要铺垫，哪些细节可以省略。

这和设计软件架构几乎是一样的。

文章的核心观点，相当于系统的核心领域模型；文章的结构，相当于模块划分；段落之间的衔接，相当于接口；论据是否充分，相当于测试是否覆盖；读者能否顺畅理解，相当于系统的可维护性和易用性。

写代码时也是一样。

函数名和变量名，是在给抽象概念命名；接口定义，是在表达模块之间的契约；注释和文档，是在说明代码背后的意图；架构设计文档，则是在描述整个系统的心智模型。

一个表达混乱的人，很难写出结构清晰的代码。

因为代码里的混乱，往往不是从键盘开始的，而是从大脑开始的。

同样，一个能把复杂技术问题讲清楚的人，通常也能把系统边界想得更清楚。因为"讲清楚"的前提，是他已经在头脑中完成了抽象、拆解和重组。

写作不是编程之外的闲事，而是编程能力的另一种训练方式。

它训练的不是修辞，而是思维的秩序。

AI 时代，代码变得更便宜，判断变得更昂贵

过去，工程师的大量时间消耗在"把想法翻译成代码"上。

记住 API、熟悉框架、处理语法、排查环境问题，这些工作占据了很多精力。一个人能否快速写出代码，曾经是衡量工程能力的重要标准。

但 AI 正在快速压低这部分能力的稀缺性。

未来，写出一个 CRUD、生成一段正则、补全一个测试用例，甚至搭起一个 Demo，都会变得越来越容易。

真正稀缺的，会变成另外一些东西：

  • 你是否知道应该构建什么？
  • 你是否理解系统真正的约束？
  • 你是否能识别方案中的风险？
  • 你是否能在成本、性能、可维护性之间做出合理取舍？
  • 你是否能把一个复杂系统讲清楚，让团队和 AI 都能沿着同一个模型工作？
  • 你是否能对最终结果负责？

换句话说，代码会变得越来越便宜，但清晰的思考、准确的设计和可靠的判断，会变得越来越昂贵。

这不是说编程能力不重要了。恰恰相反，工程师必须懂技术，而且要懂底层。

否则，你根本不知道该向 AI 提出什么约束，也无法判断它生成的方案是否可靠。

技术能力并没有消失，而是从"亲手写出每一行代码"，升级为"理解每一层抽象，并控制系统朝正确的方向演化"。

同一个需求，不同工程师会给 AI 完全不同的指令

假设你要优化一个接口。

普通表达可能是：

这个接口太慢了，帮我优化一下。

AI 也许能给出一些通用建议：加索引、加缓存、减少查询、异步处理。

但一个成熟工程师会这样描述问题：

当前订单列表接口在 10 万订单数据量下，P95 响应时间约 800ms，目标降低到 200ms 以内。系统使用 MySQL，核心查询按用户 ID 过滤，并按创建时间倒序分页。初步怀疑存在深分页和不合理索引问题。请先分析执行计划，检查是否存在全表扫描、回表过多或 N+1 查询；再给出索引优化、覆盖索引、游标分页和缓存方案，并说明各自的数据一致性风险、改造成本和适用条件。最后补充对应的基准测试方案。

这两个指令得到的结果，完全不会处在同一个水平。

区别不在于谁更会"写提示词"，而在于谁真正理解系统。

提示词只是表达方式，背后仍然是工程能力：问题定位、性能分析、数据库原理、架构权衡、验证方法。

所以，不要把 AI 时代的竞争力误解成"会不会提问"。

提问能力只是表层，底层是你对问题的理解深度。

你思考得越清楚，表达得越准确，AI 交付的结果就越接近你的目标。

写在最后

我现在重新开始写作，不是为了证明自己会表达，也不是为了追逐某种内容红利。

而是因为写作本身就是一种高强度的思维训练。

它迫使我面对那些原本模糊的想法：一个概念到底是什么？两件事之间是什么关系？这个判断的依据是什么？有没有反例？能不能用更简单的结构说清楚？

这些问题，和软件设计中每天遇到的问题，本质上完全相同。

写作是把模糊的思考整理成清晰的文章，编程是把复杂的世界抽象成可运行的系统。

一个输出文字，一个输出代码；一个面向读者，一个面向机器；但它们共享同一个内核：

建立清晰的抽象，并把这种抽象准确地表达出来。

所以，如果你问我，AI 时代工程师最核心的竞争力是什么？

我的答案不是"熟练使用 AI"，也不是"掌握更多框架"，更不是"比 AI 写代码更快"。

而是：

你能不能在头脑中建立一个清晰、完整、可被验证的抽象世界。

AI 可以帮你写代码。

但你必须先想清楚，这个世界应该长什么样。