Recent content in 工程原则 on 张欣耕的个人博客https://shanechang.com/zh-cn/tags/%E5%B7%A5%E7%A8%8B%E5%8E%9F%E5%88%99/zh-cnThu, 20 Nov 2025 00:00:00 GMThttps://shanechang.com/zh-cn/p/why-ai-cannot-engineer/https://shanechang.com/zh-cn/p/why-ai-cannot-engineer/<img src="https://shanechang.com/_astro/cover.CTct8cc3_1GfOkr.webp" alt="Featured image of post 为什么AI无法成为工程师" /><p>上个月, 我让Claude帮我撸了一个客户后台。十分钟后, 漂亮的React组件摆在我面前, API结构清晰, 登录验证在我本地跑得飞快。那一刻我差点以为自己是哈利波特。</p> <p>两天后, 我们把这玩意儿给真实用户用, 灾难现场就上演了: API在并发下直接跪了, 登录令牌一半时间在用户操作中间就过期, 数据库查询在我测试数据只有10条时还很快, 真数据一上来, 30秒都查不出来。</p> <p>代码美得像艺术品。用?也能用——勉强算是。但本质上, 这就是定时炸弹, 我只能怪自己。需要建筑师的时候, 我却只找了个瓦匠。</p> <h2 id="看起来像摩天大楼-没人敢住">看起来像摩天大楼, 没人敢住</h2> <p>想象一下建一栋摩天大楼。你得有两波人:</p> <p><strong>建筑师和结构工程师</strong>负责设计。他们要琢磨承重墙放哪, 电线水管怎么绕, 什么材料能抗住高空风, 地震来了楼会不会晃歪。还得考虑消防通道, 电梯井, 甚至人怎么进出都要细细盘算。画一大堆图纸, 标一堆标准。</p> <p><strong>施工队</strong>才是真正搬砖的。他们会搅拌混凝土, 焊钢筋, 装玻璃窗。只要给他们详细蓝图, “这儿用几号钢筋, 间距6英寸, 混凝土48小时别动”, 他们就能盖出结实安全的楼。</p> <p>有意思的是, 施工队也懂点门道: 知道钢筋混凝土才牢靠, 承重墙不能乱打洞, 材料遇热会膨胀。虽然不会算具体受力, 但知道哪些事千万不能做。</p> <p>所以, 理论上, 如果你让施工队不用图纸直接干, 他们也能盖出个楼来: 墙能立起来, 水电能接, 屋顶也有。</p> <p>能撑一阵。</p> <p>但真有人住进去, 地震来了, 着火了, 你才发现——电路乱成一锅粥, 水压上不去, 消防门找不到, 风一吹楼就晃。外表像楼, 其实不结实, 不安全, 没法住, 是个”高价装修的危楼”。</p> <p>你真的需要工程师和建筑师。</p> <h2 id="我们把两份工混成了一份">我们把两份工混成了一份</h2> <p>回到软件圈。其实我们也有两种角色, 但现在大家已经傻傻分不清。</p> <p><strong>软件工程师</strong>应该主导系统设计, 琢磨扩展性, 可靠性, 安全性, 可维护性。定规范, 立规矩, 想各种情况: 一万用户同时访问会咋样?部分功能挂了怎么办?数据一致性怎么保证?凌晨3点出bug怎么排查?这些人给出”蓝图”, 决定你的代码到底能不能上线, 能不能扛住大场面。</p> <p><strong>程序员</strong>则负责写代码。他们擅长语法, 算法, 设计模式, 能把需求转成具体实现。只要有好规范和架构, 他们能写出高质量, 维护方便的代码。</p> <p>但问题来了: 工程师也得写代码啊!不会写代码的建筑师, 设计出来的楼根本站不住。同理, 不懂代码运行原理的软件工程师, 也架不住”代码打脸”。</p> <p>于是, 两份工混成了一份: 大多数公司说”我们招软件工程师”, 其实是招”设计+实现一肩挑”的全能型选手。大家脑袋里画蓝图, 手上撸代码。这么搞了好多年, 竟然还行。</p> <h2 id="欢迎ai程序员闪亮登场">欢迎AI程序员闪亮登场</h2> <p>现在, 大语言模型 (LLM) 能写代码了。我的感受是: <strong>LLM是顶级程序员, 但完全不是工程师。</strong></p> <p>LLM像那位啥都能盖的施工大哥, 你说”给我做个Todo List”, 它立马给你写好。代码优雅, 结构清晰, 变量名感人, 跑起来贼顺溜。</p> <p>但工程的部分全没了:</p> <ul> <li><strong>不考虑负载</strong>: 用内存数组存Todo, 测着快, 用户一多直接爆炸</li> <li><strong>没处理异常</strong>: 数据库断了咋办?代码八成直接挂</li> <li><strong>安全感人</strong>: 有登录验证, 但防不住常见攻击, SQL注入一查一个准</li> <li><strong>性能盲点</strong>: 每次都遍历所有用户的todo?等着内存爆炸吧</li> <li><strong>运维无视</strong>: 日志, 监控几乎没有, 出事了只能靠烧香</li> </ul> <p>代码看起来像模像样, 规范也全对, 理想情况下能跑。但一旦遇到真实世界的幺蛾子——并发, 网络断, 奇葩输入, 恶意攻击——它就跟那座没人敢住的摩天楼一样, 外表光鲜, 里头一团糟。</p> <h2 id="这事儿到底意味着啥">这事儿到底意味着啥</h2> <p>以前我觉得”工程师”和”程序员”的区分纯粹是咬文嚼字。现在我明白了, 这区别比你想的要命。</p> <p>你让LLM”写个认证系统”, 其实就是让施工队”盖个楼”, 却没给任何要求。比如:</p> <ul> <li>楼里住几千人还是一户人家?</li> <li>抗不抗地震, 火灾?</li> <li>消防标准咋定?</li> <li>水电怎么布?</li> <li>预算多少?</li> </ul> <p>LLM肯定给你盖出来点啥, 样子还挺唬人, 但根本不靠谱。因为, 没人做”工程师”的活。</p> <p>举个我司Empath Legal的真实例子。我们帮律师做陪审团筛选工具。我要是让LLM来: “写个API, 分析陪审员问卷, 给出洞察。”</p> <p>LLM能写出能用的东西:</p> <ul> <li>解析问卷</li> <li>调用LLM分析文本</li> <li>格式化结果返回</li> <li>代码结构合理</li> </ul> <p>但它绝对不会主动考虑这些:</p> <p><strong>业务需求</strong></p> <ul> <li>问卷50多页, 律师要30秒内出结果</li> <li>用户是律师, 一切都得有出处, 不能瞎编</li> <li>分析结果必须有确定性, 法庭上要靠得住</li> <li>按用量计费, 得严格追踪消耗</li> </ul> <p><strong>技术护栏</strong></p> <ul> <li>问卷得按章节分块, 不能随便拆</li> <li>得有流式输出, 不能让律师30秒看个空白</li> <li>需要缓存, 防止重复分析白烧钱</li> <li>LLM API偶尔抽风, 异常要兜底</li> <li>全链路审计, 合规要查</li> </ul> <p><strong>系统设计</strong></p> <ul> <li>用同步还是异步? (异步, 30秒要求)</li> <li>LLM中途挂了怎么办? (幂等重试)</li> <li>LLM供应商限流咋办? (排队+背压)</li> <li>数据一致性怎么保证? (部分完成咋处理)</li> </ul> <p>LLM能写”通路”, 但如果我不自己做工程设计, 梳理约束, 定架构, 那代码上线一秒钟就翻车。</p> <h2 id="新的分工时代">新的分工时代</h2> <p>这不是说LLM不行——它们太厉害了。但我们得搞清楚它们在干啥。</p> <p><strong>LLM是超级程序员</strong>: 给定明确需求和约束, 能写出一手好代码。会用模式, 能优化, 能调试, 能写文档。</p> <p><strong>人类要做工程师</strong>: 理解业务, 设计系统, 搭好护栏, 预判边界和异常。要问: “我们到底要解决什么?会出啥乱子?怎么扩展?”</p> <p>想开点: 繁琐的底层活可以丢给AI, 我们只用搞定”人性化需求, 系统设计, 架构取舍”这些有趣的活儿。</p> <p>但前提是: 你得先做工程师的活。如果只是”LLM, 给我造个X”, 不给上下文, 不提约束, 不画蓝图, 出来的就是只可远观的危楼。</p> <h2 id="跟ai编程工具打交道的正确姿势">跟AI编程工具打交道的正确姿势</h2> <p>我的经验:</p> <p><strong>烂提示:</strong></p> <blockquote> <p>“给我写个SaaS的支付系统”</p> </blockquote> <p><strong>优质提示:</strong></p> <blockquote> <p>“写个支付系统, 满足这些需求:</p> <ul> <li>支持按积分计费 (用户买积分, 功能扣积分)</li> <li>必须安全处理并发扣除 (两次API不能都扣成功, 积分只够一次)</li> <li>需要账单审计, 方便对账</li> <li>支付渠道挂了要优雅降级 (走缓存积分, 记录日志后续补算)</li> <li>性能要求: 每次扣积分延迟&#x3C;50ms</li> </ul> <p>数据库用PostgreSQL行级锁扣积分。操作需幂等, 重试不重复扣。全链路日志方便排查。”</p> </blockquote> <p>第二种提示才是”工程师干的活”:</p> <ul> <li>业务模型 (积分制)</li> <li>核心约束 (并发安全)</li> <li>合规要求 (审计)</li> <li>可靠性 (故障降级)</li> <li>性能指标 (延迟)</li> <li>技术方案 (PostgreSQL行锁)</li> <li>运维考虑 (可排查)</li> </ul> <p>这样, LLM才能写出上线无压力的代码, 因为你给了它”蓝图”。</p> <h2 id="一点扎心的真相">一点扎心的真相</h2> <p>很多老开发, 其实早就习惯了”脑中设计+手上实现”一条龙。每次写代码, 都是先做工程师, 再做程序员, 帽子换得飞快。</p> <p>但有了LLM, 编程部分AI包了。你如果不认真做工程师的活, 只会下”魔法提示”, 最后得到的, 是个只在demo里能用, 真环境就翻车的项目。</p> <p>扎心的是: <strong>很多自称工程师的, 其实只是程序员</strong>。代码写得贼溜, 但从没真正搞过系统设计, 要么一直在实现别人的架构, 要么项目本身太小没啥复杂度。</p> <p>在LLM时代, 这个区别终于变得重要了。单纯的写代码技能正在被AI取代。真正有价值的是”工程思维”: 理解需求, 设计架构, 权衡取舍, 预判故障。</p> <h2 id="该怎么进化你自己">该怎么进化你自己</h2> <p>如果你正在学编程, 不要只学语法和框架。学会像工程师一样思考:</p> <ul> <li>写完功能, 问问: “一千个人同时用会咋样?”</li> <li>写代码前, 先想: “都有啥可能出错?每种情况该怎么兜底?”</li> <li>研究真实系统设计, 不要只看教科书里的小例子</li> <li>学会写别人能看懂, 能实现的详细需求说明</li> <li>不光要会”怎么做”, 更要懂”为什么这么做”</li> </ul> <p>如果你已经在开发岗位, 注意分清自己干的是哪一头。只是对着规范写功能?那你就是程序员, 未来LLM会把这工作抢走。赶紧加强工程能力: 系统设计, 需求分析, 架构思维。</p> <p>如果你在面试招人, 别再考”能不能写FizzBuzz”, 改问”设计个URL短链系统, 能扛1000请求/秒, 故障咋办?”写代码的活儿越来越自动化了, 剩下的全靠脑子。</p> <h2 id="最后的笑点">最后的笑点</h2> <p>说个小秘密: 这篇文章, 其实是我和Claude合写的。不是我不会写, 而是Claude作为”写作程序员”比我还专业。我给它核心思路, 写作架构, 风格要求 (要有建筑比喻, 要举案例), 它写得比我快还顺。</p> <p>Claude写了优美的段落。但那些最关键的决定——讲什么, 怎么安排, 用什么例子, 读者能不能get到——全是”工程师”我来定的。</p> <p>未来的软件开发, 不会是”全自动无人区”。而是人类做擅长的事——理解复杂需求, 做取舍, 设计健壮系统;AI做擅长的事——把规范变成精美, 可靠的代码。</p> <p>但前提是: 你得记得自己是工程师。否则, 盖出来的, 还是那种没人敢住的高楼。</p> <p>这种故事, 咱都不想再听第二遍吧。</p> <hr> <p><em>你用AI编程工具踩过什么坑?你发现自己开始更多地思考工程问题, 还是还停留在”写个X就行”?欢迎留言分享——翻车现场往往比成功故事更有料!</em></p> <p><em>(本文由人类原创, 部分内容参考AI协助优化。)</em></p>Thu, 20 Nov 2025 00:00:00 GMT