ARTICLE · 1303967
AI浪潮 | 软件工程师的转向
AI浪潮 | 软件工程师的转向一、一个正在发生的变化 前些天改一个老模块，按以前的节奏，梳理逻辑、写代码、调试，怎么也要一两天。这次我把设计思路想清楚，写了一份详细的需求说明交给 AI，四十分钟后我看完了它生成的代码——能跑，结构还行，注释齐全。 那一刻我忽然意识到：写代码这件事，正在从“核心技能”变成“基础素养”。 就像二十年前，会用搜索引擎是加分项；十年前，会用框架是加分项；而今天，这些都在快速贬值。当 AI 能在几分钟内写出我们过去要写一天的代码时，“会写代码”就不再是护城河了。 那什么是？我想了很久，答案是两个词：架构和约束。 二、AI 是一个极快但极听话的工人 很多人把 AI 当“更聪明的同事”，这是误解。AI 更像一个能力极强、极其听话、但完全没有立场的工人： - 你让它往东，它绝不往西； - 你没说清楚的地方，它会替你做决定，而且做得看起来很合理； - 它不问“为什么”，也不承担后果。 这三条，最后一条最可怕。 人工写的代码烂了，作者会被 review 打回来、会在深夜排查 bug 时痛骂自己。而 AI 生成的代码，没有人为它失眠。它可以把一个越界读写得天衣无缝，把一个字节序问题藏在最不起眼的循环里，把一个并发隐患埋在“看起来能跑”的路径中——每一个都是要在生产环境里爆的雷。 所以问题从来不是“AI 写得好不好”，而是：你有没有能力划定边界，让它只能在边界内写？ 三、架构：先把“想清楚”和“写出来”分开 我们这代人学编程，是从“怎么写”开始的：怎么操作寄存器，怎么调 API，怎么压性能。这些肌肉记忆让我们习惯了一拿到需求就扑向代码。 但 AI 时代恰恰要求反过来：动手之前，想清楚的部分要占大头。 什么是想清楚？无非是几个老问题： 1. 边界在哪——哪些东西进这个模块，哪些东西绝对不许进来？ 2. 接口是什么——模块之间靠什么对话？数据怎么流？ 3. 坏了怎么办——哪个部分可以挂，哪个部分绝对不能挂？ 4. 半年后谁最可能变——把易变的东西隔离起来，把稳定的东西沉下去。 这些问题，AI 一个都替你回答不了。你答得好，AI 写出来的东西就是一个系统；你答得含糊，AI 写出来的就是一堆能跑的代码碎片——而且是以你没想到的方式碎掉。 架构的本质，是把人的判断力固化成结构。AI 负责在结构里填肉，人负责结构本身。分工从来没这么清晰过。 四、约束：比生成更重要的能力 如果说架构是“画格子”，约束就是“立规矩”。AI 时代真正值钱的，是你能不能把规矩立得让机器无法越界。 我自己的体会，约束分三层： 第一层：说清楚。给 AI 的任务描述，本质上是一份契约。“写一个登录功能”和“写一个登录功能：参数校验在入口层做，错误码沿用现有的表，禁止在业务层直接碰数据库，所有 IO 必须带超时”，产出物是两个物种。**约束写得多细，自由度就剩多小，惊喜（或者说惊吓）就有多小。 第二层：机器可查。人 review 代码靠眼睛，会累、会漏。所以能变成自动化检查的东西，全部变成自动化检查： - 编译警告全开，静态分析常驻； - 单元测试覆盖核心路径，改一行跑一遍； - CI 里挂上 lint、边界检查、规范扫描。 这些不是“工程质量锦上添花”，它们是给 AI 划的硬边界——AI 可以写得飞快，但每一行都要过检查点的闸门。规则在这里，越线就红灯，不需要你熬夜盯梢。 第三层：验证闭环。最重要的约束是那条终极问题：“你怎么知道它是对的？”对嵌入式的同行来说这个问题尤其具体——代码能编译、测试能通过，不代表板子上不出事。时序、功耗、干扰、极限工况，都是 AI 摸不到的物理世界。所以除了代码层的约束，还要有实机验证的流程约束：什么必须上真机测，什么必须跑长时间老化，什么改动必须双人复核。 三层约束立起来，你会发现一个奇妙的变化：你不再是写代码的人，而是设计“让代码被正确地写出来”这套系统的人。这就是从程序员到架构师的转变。 五、会“描述”，才会“驾驭” 立架构和约束，落到操作层面，考验的是一种被严重低估的能力：精确描述。 给 AI 布置任务，像给新来的实习生写交接文档——你以为你写清楚了，其实漏了十个默认假设。你默认它知道项目的历史包袱，默认它知道哪个接口有坑，默认它知道“这个地方图省事以后会死人”。它统统不知道。 所以每次 AI 的产出跑偏，先别怪 AI，回头看看自己的任务描述：是不是留下了太多“自由发挥”的空间？ 我的习惯是，一个复杂的任务，先让 AI 复述一遍它理解的方案，确认无误再让它动手。这一步看起来慢，实际上是把未来排障的时间提前花掉——划算得多。 说到底，这和带团队是一回事：好的管理者不是最能干的人，而是最能说清楚要求的人。AI 时代，这个道理同样适用于管理一个“不知疲倦的编码机器”。 六、写给正在焦虑的人 很多人焦虑“AI 会不会取代程序员”。我的看法是：AI 取代的不是程序员，而是“只会把需求翻译成代码”的那部分工作。 翻译工作没了，但翻译之前的需求澄清、边界划分、方案取舍，和翻译之后的验证、审查、兜底，不但没消失，反而变得更重了。这些加起来，恰恰是“工程师”这个词原本的含义——只是过去我们花在这上面的时间太少，被写代码占去了大半。 所以不必焦虑，但要做几个转变： - 从“写代码的人”变成“定规则的人”**——把设计文档、接口定义、约束清单看得比代码实现更重； - 从“追求写出来”变成“追求说清楚”**——能把一个复杂系统讲得让外行听懂，本身就是稀缺能力； - 从“怕出错”变成“系统防错”——不靠个人小心，靠流程和工具兜底； - 把 AI 当杠杆，不当拐杖——用它加速验证你的想法，而不是替代你的思考。 写代码的年代正在过去，但构建可靠系统的年代才刚刚开始。这个年代的主角，是那些既能俯下身看清细节、又能站起来划定边界的人。 工具永远在变，而把混沌变成秩序的能力，永远值钱。 愿我们都能在机器飞快写代码的时代，做一个想得足够慢、足够深的人。
