AI First？不，这明明是软件工程 First！¶

Ch01.1177 AI First？不，这明明是软件工程 First！¶

📊 Level ⭐⭐ | 5.1KB | entities/ai-first不这明明是软件工程-first.md

来源: Unknown

发布日期: 2026-04-14

原文链接: https://mp.weixin.qq.com/s/rJQ8ubfhmQSfXLxI78pPYg

最近，Peter Pang 的文章《Why Your "AI-First" Strategy Is Probably Wrong》在技术圈疯传。很多人被“AI 编写了 99% 的代码”这种噱头抓住了眼球，甚至开始制造“程序员失业”的焦虑。

但我反复研读了原文多遍，穿透那些 AI 术语后，我看到的满纸都是四个大字：软件工程。

与其说是 AI 改变了研发，不如说是 AI 像一面照妖镜，逼着我们去直面那些欠了十几年的工程债。真正的 AI First，本质上是一场彻头彻尾的“软件工程革命”。

原文的核心逻辑极其冷酷且高效：在 AI 时代，人已经成为了流水线上最慢的组件。

• 需求的漏斗：过去产品经理（PM）花两周做调研、写文档，工程师开发要一个月。现在 AI 开发只要两小时，PM 那两周的决策过程就成了公司的“成本黑洞”。
• 测试的堤坝： AI 可以在瞬间产出成千上万行代码，如果 QA 还在靠人工点点点，或者写那种半自动化的脚本，测试周期会从“天”变成“周”，AI 节省的时间全被填进了测试坑里。
• 人力的诅咒：传统的“人海战术”在 AI 面前失去了规模效应。25 人的精锐团队配合成熟的 AI 流水线，产出能轻易碾压几百人的大工厂。

作者的解决方案是：Harness Engineering（脚手架工程）。

这要求我们把人从琐碎的执行中拿掉。AI 不只是写代码，它要负责审计、跑测试、部署、监控甚至是故障自愈。而人，退回到“架构师”的位置，只在关键节点做“判断题”。

很多人觉得买个 Cursor 订阅、装个 Copilot 就算 AI First 了。那是“AI 辅助”，不是“AI 优先”。在你想照搬这套玩法之前，请先对照以下五点进行“灵魂拷问”。如果这五点做不到，AI 产出越高，你的系统崩得越快。

如果你没有接近 100% 的单元测试和集成测试覆盖率，千万别让 AI 大规模改代码。AI 最大的问题不是不会写，而是它不知道“改这里会不会崩掉那里”。没有自动化的验证体系，每当 AI 提交一次代码，你都得安排人工回归一遍。这种“人工补位”会迅速抵消 AI 带来的所有效能红利。

原文提到一天部署 8 次。这背后是绝对确定的流水线。从代码合并到灰度发布，中间不应该有人为介入的“审批流”。如果你的发布还需要半夜找运维人工盯着，那 AI 的光速产出就会在发布环节发生“交通拥堵”。

AI 写的代码上线后，效果好不好？有没有产生逻辑漏洞？你需要一套极其灵敏的监控系统（如原文提到的结构化日志）。没有数据回馈，AI 就没有进化的依据。所谓的“自愈闭环”，前提是系统得能像生物体一样感知到“痛”。

AI 目前还啃不动“大而模糊”的需求。你必须具备将业务目标拆解为“原子级任务”的能力。这就要求管理者的逻辑必须极度严密。任务生命周