上个月，我让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协助优化。）