上个月, 我让Claude帮我撸了一个客户后台。十分钟后, 漂亮的React组件摆在我面前, API结构清晰, 登录验证在我本地跑得飞快。那一刻我差点以为自己是哈利波特。

两天后, 我们把这玩意儿给真实用户用, 灾难现场就上演了: API在并发下直接跪了, 登录令牌一半时间在用户操作中间就过期, 数据库查询在我测试数据只有10条时还很快, 真数据一上来, 30秒都查不出来。

代码美得像艺术品。用?也能用——勉强算是。但本质上, 这就是定时炸弹, 我只能怪自己。需要建筑师的时候, 我却只找了个瓦匠。

看起来像摩天大楼, 没人敢住

想象一下建一栋摩天大楼。你得有两波人:

建筑师和结构工程师负责设计。他们要琢磨承重墙放哪, 电线水管怎么绕, 什么材料能抗住高空风, 地震来了楼会不会晃歪。还得考虑消防通道, 电梯井, 甚至人怎么进出都要细细盘算。画一大堆图纸, 标一堆标准。

施工队才是真正搬砖的。他们会搅拌混凝土, 焊钢筋, 装玻璃窗。只要给他们详细蓝图, “这儿用几号钢筋, 间距6英寸, 混凝土48小时别动”, 他们就能盖出结实安全的楼。

有意思的是, 施工队也懂点门道: 知道钢筋混凝土才牢靠, 承重墙不能乱打洞, 材料遇热会膨胀。虽然不会算具体受力, 但知道哪些事千万不能做。

所以, 理论上, 如果你让施工队不用图纸直接干, 他们也能盖出个楼来: 墙能立起来, 水电能接, 屋顶也有。

能撑一阵。

但真有人住进去, 地震来了, 着火了, 你才发现——电路乱成一锅粥, 水压上不去, 消防门找不到, 风一吹楼就晃。外表像楼, 其实不结实, 不安全, 没法住, 是个"高价装修的危楼"。

你真的需要工程师和建筑师。

我们把两份工混成了一份

回到软件圈。其实我们也有两种角色, 但现在大家已经傻傻分不清。

软件工程师应该主导系统设计, 琢磨扩展性, 可靠性, 安全性, 可维护性。定规范, 立规矩, 想各种情况: 一万用户同时访问会咋样?部分功能挂了怎么办?数据一致性怎么保证?凌晨3点出bug怎么排查?这些人给出"蓝图", 决定你的代码到底能不能上线, 能不能扛住大场面。

程序员则负责写代码。他们擅长语法, 算法, 设计模式, 能把需求转成具体实现。只要有好规范和架构, 他们能写出高质量, 维护方便的代码。

但问题来了: 工程师也得写代码啊!不会写代码的建筑师, 设计出来的楼根本站不住。同理, 不懂代码运行原理的软件工程师, 也架不住"代码打脸"。

于是, 两份工混成了一份: 大多数公司说"我们招软件工程师", 其实是招"设计+实现一肩挑"的全能型选手。大家脑袋里画蓝图, 手上撸代码。这么搞了好多年, 竟然还行。

欢迎AI程序员闪亮登场

现在, 大语言模型 (LLM) 能写代码了。我的感受是: LLM是顶级程序员, 但完全不是工程师。

LLM像那位啥都能盖的施工大哥, 你说"给我做个Todo List", 它立马给你写好。代码优雅, 结构清晰, 变量名感人, 跑起来贼顺溜。

但工程的部分全没了:

• 不考虑负载: 用内存数组存Todo, 测着快, 用户一多直接爆炸
• 没处理异常: 数据库断了咋办?代码八成直接挂
• 安全感人: 有登录验证, 但防不住常见攻击, SQL注入一查一个准
• 性能盲点: 每次都遍历所有用户的todo?等着内存爆炸吧
• 运维无视: 日志, 监控几乎没有, 出事了只能靠烧香

代码看起来像模像样, 规范也全对, 理想情况下能跑。但一旦遇到真实世界的幺蛾子——并发, 网络断, 奇葩输入, 恶意攻击——它就跟那座没人敢住的摩天楼一样, 外表光鲜, 里头一团糟。

这事儿到底意味着啥

以前我觉得"工程师"和"程序员"的区分纯粹是咬文嚼字。现在我明白了, 这区别比你想的要命。

你让LLM"写个认证系统", 其实就是让施工队"盖个楼", 却没给任何要求。比如:

• 楼里住几千人还是一户人家?
• 抗不抗地震, 火灾?
• 消防标准咋定?
• 水电怎么布?
• 预算多少?

LLM肯定给你盖出来点啥, 样子还挺唬人, 但根本不靠谱。因为, 没人做"工程师"的活。

举个我司Empath Legal的真实例子。我们帮律师做陪审团筛选工具。我要是让LLM来: “写个API, 分析陪审员问卷, 给出洞察。”

LLM能写出能用的东西:

• 解析问卷
• 调用LLM分析文本
• 格式化结果返回
• 代码结构合理

但它绝对不会主动考虑这些:

业务需求

• 问卷50多页, 律师要30秒内出结果
• 用户是律师, 一切都得有出处, 不能瞎编
• 分析结果必须有确定性, 法庭上要靠得住
• 按用量计费, 得严格追踪消耗

技术护栏

• 问卷得按章节分块, 不能随便拆
• 得有流式输出, 不能让律师30秒看个空白
• 需要缓存, 防止重复分析白烧钱
• LLM API偶尔抽风, 异常要兜底
• 全链路审计, 合规要查

系统设计

• 用同步还是异步? (异步, 30秒要求)
• LLM中途挂了怎么办? (幂等重试)
• LLM供应商限流咋办? (排队+背压)
• 数据一致性怎么保证? (部分完成咋处理)

LLM能写"通路", 但如果我不自己做工程设计, 梳理约束, 定架构, 那代码上线一秒钟就翻车。

新的分工时代

这不是说LLM不行——它们太厉害了。但我们得搞清楚它们在干啥。

LLM是超级程序员: 给定明确需求和约束, 能写出一手好代码。会用模式, 能优化, 能调试, 能写文档。

人类要做工程师: 理解业务, 设计系统, 搭好护栏, 预判边界和异常。要问: “我们到底要解决什么?会出啥乱子?怎么扩展?”

想开点: 繁琐的底层活可以丢给AI, 我们只用搞定"人性化需求, 系统设计, 架构取舍"这些有趣的活儿。

但前提是: 你得先做工程师的活。如果只是"LLM, 给我造个X", 不给上下文, 不提约束, 不画蓝图, 出来的就是只可远观的危楼。

跟AI编程工具打交道的正确姿势

我的经验:

烂提示:

“给我写个SaaS的支付系统”

优质提示:

“写个支付系统, 满足这些需求:

• 支持按积分计费 (用户买积分, 功能扣积分)
• 必须安全处理并发扣除 (两次API不能都扣成功, 积分只够一次)
• 需要账单审计, 方便对账
• 支付渠道挂了要优雅降级 (走缓存积分, 记录日志后续补算)
• 性能要求: 每次扣积分延迟<50ms

数据库用PostgreSQL行级锁扣积分。操作需幂等, 重试不重复扣。全链路日志方便排查。”

第二种提示才是"工程师干的活":

• 业务模型 (积分制)
• 核心约束 (并发安全)
• 合规要求 (审计)
• 可靠性 (故障降级)
• 性能指标 (延迟)
• 技术方案 (PostgreSQL行锁)
• 运维考虑 (可排查)

这样, LLM才能写出上线无压力的代码, 因为你给了它"蓝图"。

一点扎心的真相

很多老开发, 其实早就习惯了"脑中设计+手上实现"一条龙。每次写代码, 都是先做工程师, 再做程序员, 帽子换得飞快。

但有了LLM, 编程部分AI包了。你如果不认真做工程师的活, 只会下"魔法提示", 最后得到的, 是个只在demo里能用, 真环境就翻车的项目。

扎心的是: 很多自称工程师的, 其实只是程序员。代码写得贼溜, 但从没真正搞过系统设计, 要么一直在实现别人的架构, 要么项目本身太小没啥复杂度。

在LLM时代, 这个区别终于变得重要了。单纯的写代码技能正在被AI取代。真正有价值的是"工程思维": 理解需求, 设计架构, 权衡取舍, 预判故障。

该怎么进化你自己

如果你正在学编程, 不要只学语法和框架。学会像工程师一样思考:

• 写完功能, 问问: “一千个人同时用会咋样?”
• 写代码前, 先想: “都有啥可能出错?每种情况该怎么兜底?”
• 研究真实系统设计, 不要只看教科书里的小例子
• 学会写别人能看懂, 能实现的详细需求说明
• 不光要会"怎么做", 更要懂"为什么这么做"

如果你已经在开发岗位, 注意分清自己干的是哪一头。只是对着规范写功能?那你就是程序员, 未来LLM会把这工作抢走。赶紧加强工程能力: 系统设计, 需求分析, 架构思维。

如果你在面试招人, 别再考"能不能写FizzBuzz", 改问"设计个URL短链系统, 能扛1000请求/秒, 故障咋办?“写代码的活儿越来越自动化了, 剩下的全靠脑子。

最后的笑点

说个小秘密: 这篇文章, 其实是我和Claude合写的。不是我不会写, 而是Claude作为"写作程序员"比我还专业。我给它核心思路, 写作架构, 风格要求 (要有建筑比喻, 要举案例), 它写得比我快还顺。

Claude写了优美的段落。但那些最关键的决定——讲什么, 怎么安排, 用什么例子, 读者能不能get到——全是"工程师"我来定的。

未来的软件开发, 不会是"全自动无人区”。而是人类做擅长的事——理解复杂需求, 做取舍, 设计健壮系统;AI做擅长的事——把规范变成精美, 可靠的代码。

但前提是: 你得记得自己是工程师。否则, 盖出来的, 还是那种没人敢住的高楼。

这种故事, 咱都不想再听第二遍吧。

你用AI编程工具踩过什么坑?你发现自己开始更多地思考工程问题, 还是还停留在"写个X就行"?欢迎留言分享——翻车现场往往比成功故事更有料!

(本文由人类原创, 部分内容参考AI协助优化。)