如果你身处软件开发行业，一定被这样一种焦虑裹挟：AI写代码的速度越来越快，有人甚至宣称“一天能完成过去一周的工作量”，随之而来的，是“AI即将淘汰程序员”的恐慌论调。更让人揪心的是，越来越多团队跟风用AI提速后，项目失败的速度也跟着翻倍，这不禁让人追问：为什么用AI写代码越快，项目死得越快？
很多人把这归咎于AI不够强大，或是自己用得不够熟练。但真正的核心症结，从来不在AI本身，而是绝大多数公司，自始至终都没有践行过真正的软件工程。AI不过是一个放大镜，把这个被行业长期掩盖的真相，赤裸裸地暴露在了所有人面前，也让“提速即找死”的困境愈发凸显。
本文的核心观点，来自一位拥有四十余年从业经验的资深软件工程师。他的文章《人工智能并没有简化软件工程：它只是让糟糕的工程变得更容易》在 Hacker News 上引发了超百条行业热议，而所有争议的核心，都指向同一个问题：AI 到底是在取代工程师，还是在放大行业早已存在的系统性问题？
一、行业循环：AI 只是“裁员叙事”的新剧本
这已经是行业循环的第N个复刻版本。每隔几年，软件行业就会经历一次完全雷同的循环：新的开发工具出现，演示效果足够惊艳，企业随即启动大规模裁员。但后续的走向永远如出一辙：系统复杂度彻底失控，最终发现项目还是离不开人的深度参与。上世纪90年代的Visual Basic是这样，2010年代兴起的低代码平台，同样没能跳出这个循环。
（同一个故事的第 N 个版本）
这位资深工程师提出，AI 成了企业掩盖糟糕商业决策的最新借口。但这句话只说对了一半。背后的真相更加残酷：老板和投资人，永远需要一个能讲下去的商业故事。这就像足球赛场上的点球博弈。专业研究早已证明，点球大战中，守门员站在原地不动，扑出点球的成功率其实更高，但现实里几乎所有守门员，都会奋力扑向左右其中一侧。原因很简单：如果站在原地被进球，全场观众都会骂你消极怠工、毫无作为；但如果奋力扑向一侧哪怕没接住，至少你证明了自己“尽力了”。
（守门员为什么总往反方向扑？）
企业的技术决策，本质上也是同样的逻辑。我们都见过，像QQ这样的国民级产品的更新日志，永远只有“优化了部分内容”“提升了用户体验”这类空话。那为什么团队还要耗费巨大精力，去做底层架构的大版本重构？因为团队需要有事可做，项目需要有故事可讲，老板需要有规划可落地，投资人需要有新叙事可听。
裁员，本身就是这个故事里的关键一环。从来不是 AI 真的能替代工程师，而是“用 AI 替代工程师降本增效”这个叙事，比直白地说“我们业务不行了”，要好听太多了。
二、核心误区：写代码≠软件工程
行业里有一个长期存在的误区：人们总以为写代码是软件开发中最难的事。但事实恰恰相反，真正的核心难点，是定义系统的行为边界、厘清组件间的交互逻辑，以及在系统复杂度持续增长的过程中，始终保证架构的可控性。
AI 能提速的，仅仅只有“写代码”这一个环节，而软件工程里的核心难题，它一个都没有解决。
我们可以用一个更通俗的类比来理解：你请了一支装修队，他们砌墙速度极快，一天就能完工一面墙。但他们从来不看施工图纸，不管水电管线的走向，也完全不考虑房屋的承重结构。速度确实快了，但这样装出来的房子，你真的敢住吗？
这就是当下很多团队使用 AI 开发的真实状态：代码产出速度确实上去了，但没人关心这些代码是否符合系统整体设计，是否覆盖了所有边界情况，是否能被下一个接手的人看懂和维护。
这里必须澄清一个行业最核心的误解：很多人把“写代码”直接等同于“软件工程”，这是一个根本性的认知偏差。真正的软件工程，至少包含三个核心层级：①规格层：明确定义系统应该做什么、不做什么，划定清晰的能力边界；②验证层：设计完整的校验体系，证明系统确实在执行预设的行为；③实现层：通过代码完成系统的落地执行。
AI 目前能提供辅助的，只有最末端的第三层。如果前两层完全是空白的，第三层的速度越快，反而越危险——就像一辆没有方向盘和刹车的跑车，踩油门的力度越大，失控的概率就越高。
三、致命陷阱：AI 正在加速的规格漂移
接下来是全文最精华的部分。这位资深工程师提出了三角对齐模型：一个可靠的软件系统，必须保证三个核心要素始终保持一致：①规格：定义系统该有怎样的行为；②测试：验证系统是否符合预设行为；③代码：执行系统的对应行为。
一旦这三者出现偏离，系统就会丧失完整性，这个现象，就是行业里常说的规格漂移。规格漂移有三种最常见的表现形式：①代码实现迭代了，但对应的规格说明没有同步更新；②业务规格持续进化，但测试用例还冻结在旧版本；③系统行为在一次次微调中逐步偏离，最终没人能说清系统的原始设计意图。
开发初期，大家会觉得靠猜测和口头沟通就能解决问题，但这些未经校准的猜测会持续累积，最终让系统彻底偏离预设轨道。
AI 的出现，让这个行业顽疾变得更加危险。过去纯手动开发的模式，天然限制了代码变更的速度，即便出现规格漂移，进程也相对缓慢，团队还有时间追踪和修正。但现在，AI 可以在几秒钟内生成一个完整模块，代码看起来逻辑通顺、能正常编译、甚至能通过基础测试，但三者之间的对齐关系，可能已经彻底丢失了。表面上看是生产力的飞跃，实际上，是在加速系统的全面失控。
四、社区争议：AI 到底放大了谁？
这篇文章在技术社区引发了激烈的讨论。
一方观点认为，AI 本质上是一个“行为放大器”：它能让优秀的工程师效率翻倍，也能让不合格的工程师制造的灾难指数级放大。有人甚至用阿姆达尔定律来解释这个现象：优秀的工程师使用 AI 时，依然会花大量时间验证产出的可靠性；而不合格的工程师，会直接跳过验证环节。最终的结果就是，AI 对“烂工程”的加速效应，远大于对“好工程”的提效作用。
其中最扎心的一条评论是：“它让坏工程变得极度容易，让好工程只是稍微容易了一点。以至于很多原本做好工程的人，选择去做三倍量的坏工程，而不是多做10%的好工程。”
而另一方观点则认为，绝大多数开发场景根本不需要完美的工程规范：比如一次性使用的脚本、内部自用的小工具、用于快速验证的业务原型，代码质量好坏无关紧要，能跑通需求就足够了。
其实争论的双方，说的根本不是同一件事。乐观派谈论的，是AI的上限可能性：它确实能在特定场景下实现10倍级的效率提升；悲观派谈论的，是行业的普遍概率：绝大多数人会用AI制造更多低质量的工程，而不是打磨优质的系统。
两边的观点都成立，但这从来不是问题的核心。真正的关键问题是：谁来判断，什么时候可以“够用就行”，什么时候必须“严谨到位”？如果团队本身就缺失这种判断能力，AI 只会让错误的选择来得更快、影响的规模更大。这才是这位行业老兵，真正担心的事情。
五、破局核心：建立对抗 AI 漂移的工程机制
老兵说的都对。但他是站在"规格漂移不可避免"的角度说的。问题是：规格漂移真的不可避免吗？
未必。关键在于有没有建立对抗漂移的工程机制。
以米多产研团队的实践为例，早在AI大规模介入开发之前，团队就在推进一件核心工作：产品规格说明书（SRS）的结构化重构。核心逻辑非常简单，如果需求方案本身足够清晰、无歧义，AI 就根本没有“漂移”的空间。
除此之外，我们还建立了两套专门对抗AI漂移的核心机制：
1、插旗论：把 AI 的“抽卡式生成”，变成可控的标准化产出
AI 开发有一个非常残酷的特性：完全相同的需求，今天能给你生成完美可用的代码，明天可能就给你输出一堆无法维护的逻辑垃圾。这就是典型的“抽卡式生成”。
插旗论的核心逻辑，就是彻底终结这种不可控性：当AI产出符合预期的优质结果时，立即进行固化——保存完整的提示词与上下文语境，记录完整的生成路径和关键设计决策点，同步制作可演示的原型页面，最终沉淀为可复用的标准化设计模板。
比固化更重要的，是开发节奏的管理。团队需要设定固定的周度插旗节点，每一次插旗，必须同步交付四项核心产物：可访问的在线Demo、完整的功能说明文档、清晰的接口定义、明确的依赖关系说明。
这样做的好处是双重的：一方面，团队每周都有可见的、可验证的具体进展，能给管理者和投资人清晰的进度反馈；另一方面，一旦发现开发方向出现偏差，最多只会损失一周的工作量，绝不会等到项目末期，才发现需要全盘返工。
2、AI 实时验证机制：把校验从末端，前置到编写过程中
传统的方案评审，是写完文档后等待人工审核；而这套机制，是在方案编写的过程中，就用AI做前置校验。具体的执行逻辑非常简单：方案写完后，先让AI根据方案描述生成对应的产品效果图。如果AI能精准还原方案预期，说明需求描述足够清晰无歧义；如果AI生成的结果出现偏差，就能立刻定位到方案里描述模糊、逻辑缺失的环节。
这就像谷歌验证码的设计逻辑，用一个已知的“测试钩子”，同时解决两个未知数：AI 是否真正理解了需求，以及需求描述本身是否足够清晰。
这些方法本身并不复杂，难的是全程严格执行的纪律。真正的问题从来不是 AI 会不会发生漂移，而是团队有没有提前建立起对抗漂移的完整机制。
六、端对端编程：信息损耗的终极解法
老兵担心的"规格漂移"，本质上是一个信息损耗问题。传统的软件开发流程是这样的：业务需求 → 产品方案 → 开发理解 → 代码实现 → 测试验证。每一次传递，信息都在丢失。
产品经理写方案时，脑子里想的和写出来的不完全一样——这是第一次信息损耗；
开发者读方案时，理解的和产品方案的不完全一样——这是第二次信息损耗；
开发者写代码时，实现的和自己理解的又不完全一样——这是第三次信息损耗；
遇到问题回去问产品经理，产品经理的解释和原始想法又有偏差——这是第四次信息损耗；
这些偏差没有被记录下来，越没被记录越习惯问产品，问的越多占用产品时间越长，到后面反正都要问干脆方案不必那么细，下一个接手的人，损失死循环。到最后，代码和最初的业务需求之间，隔着四层信息衰减。难怪系统会漂移。
而端对端编程，正是为了解决这个核心问题而生。
1.什么是端对端？
在机器学习领域，端对端指的是：使用者直接输入原始材料，直接得到可用的结果，不用关心中间产物。比如传入一张照片，直接识别出人脸，不需要先提取特征、再分类、再匹配。
迁移到软件开发领域，端对端编程的理念是：从需求发起，到需求满足，全程不换手。这不是说产品经理要自己写代码。而是说，产品经理直接用自然语言描述意图，AI 直接生成可运行的结果，中间不需要"翻译"成技术文档、再"翻译"成代码。
2.意图编程是端对端的具体形态。
传统编程是"过程式"的：告诉计算机先做 A，再做 B，然后做 C。意图编程是"声明式"的：告诉计算机我想要什么结果，让它自己去想怎么做。这听起来像科幻，但已经在发生。
当产品经理说"用户上传 Excel 文件，3 秒内看到销售趋势图，可以下载 PDF 报告"，AI 直接生成可运行的代码这就是意图编程。没有中间的技术文档，没有开发者的"二次理解"，信息从起点直达终点。
3.端对端编程的真正价值不是效率，而是保真度。
当然，现阶段的 AI 还做不到完美的端对端。但方向已经很清楚了：减少信息传递的层级，就是减少漂移的机会。这也解释了为什么那些"AI 提效 10 倍"的案例往往发生在个人项目或小团队。因为信息传递链条本来就短，端对端的条件天然具备。
而大公司的困境在于：流程越长、层级越多、信息损耗越大，AI 能弥补的就越有限。AI 不是在替代人，而是在逼着组织重新思考信息传递的方式。
七、终局判断：AI 不会淘汰工程师，只会淘汰不懂软件工程的人
这位行业老兵的警告，我们需要分层理解。AI 的使用，从来不是“一刀切”的选择，而是要基于场景判断：个人自用工具、业务原型快速验证，AI 完全可以做到“够用就行”；但一旦软件变成客户依赖的商业产品——尤其是涉及支付交易、敏感数据存储的核心系统，工程规范的标准就会完全不同。真正的危险，从来不是使用AI，而是把这两个场景的标准彻底搞混。
AI 时代，开发者必须看清的三个真相。
1. 警惕代码审查的隐形成本，避开生产力陷阱
AI可以在几分钟内生成几百行代码，但团队要审查这些代码、确认它完全符合系统设计、规避潜在风险，所花费的精力，往往比自己从头编写还要多。最终的结果就是，代码产出速度上去了，但业务的实际交付速度反而变慢了——这就是AI时代最隐蔽的生产力陷阱。
2. 中级工程师的两极分化，已经开始
当一个开发者开始依赖AI“生成代码”，而放弃自己“理解代码、设计系统”的核心能力时，两条截然不同的路就已经铺开：
一条路是退化：把自己变成AI的复制粘贴员，逐步丧失独立的系统设计和逻辑思考能力，这条路的终点，就是被AI彻底替代。
另一条路是进化：从“写代码的执行者”，变成“定义业务意图的设计者”。真正理解端对端编程的本质，学会用最短的信息链条，表达最准确的业务需求，让AI成为意图的执行器，而不是自己思考能力的替代品。
AI 从来不是在抹平开发者之间的差距，而是在把差距拉得越来越大。选哪条路，最终取决于你如何定义自己的核心价值。
3. 被淘汰的永远不是程序员，而是只会做单一环节的从业者
四十年前，这位资深工程师刚入行时，行业里就在传言“高级语言会让程序员失业”；二十年前，有人说“开源框架会让程序员失业”；十年前，又有人说“云计算会让程序员失业”。
每一次技术变革，被淘汰的从来都不是程序员这个群体，而是那些“只会做单一环节工作”的从业者。
这一次也不会例外。
AI永远不会替代真正的软件工程师，它只会替代那些，从来没有理解和践行过真正软件工程的人。
原文：https://robenglander.com/writing/ai-did-not-simplify/HN 讨论：https://news.ycombinator.com/item?id=47377262
关于米多
米多公司成立于2014年，是国内领先的营销数字化整体解决方案提供商，在营销领域致力于以企业业务能力（EBC）为核心，构建基于“立体连接、数据共通、流量共享、全景共鸣、全域赋能、全链共赢”的产业互联网营销服务平台，赋能企业通过“网络协同”和“数据智能”双螺旋引擎，用数字化驱动业务增长。累计服务酒类行业、快消行业、日化家清行业、化工建材行业、茶叶行业等品牌类企业逾3000家，包括茅台、可口可乐、宝洁、高露洁、维达、立白、雪花啤酒、劲牌、绿箭、嘉士伯、美涂士、华新集团等。
如想获取“营销数字化解决方案”，请私聊我~
热门跟贴