今天刷到这篇文章几次，说点不一样的。与其说 AI First，不如说软件工程 First。

这篇文章看着在讲 AI，底下全是软件工程。

抛开后面讲组织和人的部分，原文前半段的重点简单总结一下：

AI 时代，人成了瓶颈。PM 花几周做需求，AI 两小时就能实现，PM 成了瓶颈。QA 测三天，AI 写代码只要两小时，QA 成了瓶颈。团队 25 个人，对手几百人，人力也是瓶颈。

怎么办？把人从链条里拿掉。AI 写代码、AI 审查代码、AI 跑测试、AI 部署上线、AI 监控线上状态，出了问题自动回滚。每天定时扫描日志，自动发现问题、分配任务、跟踪修复。整条流水线跑起来，人只需要在关键节点做判断。

至于文中提到的统一代码库，锦上添花，和 AI First 关系不大。有当然更好，没有也有很多替代方案。

整套方案听下来，逻辑自洽，效果也漂亮：一天部署好几次，功能当天上当天撤，数据说了算。

但先别急着照搬，先对照自己的情况想几件事：

第一，自动化测试。AI 改完代码，你得有办法确认它没搞崩别的功能。测试覆盖不够的话，每次 AI 提交代码你都得人工回归一遍，那速度根本快不起来。

第二，CI/CD 流程。从提交代码到部署上线，中间的测试、审查、发布、回滚，是不是全自动跑通了？这条流水线不通，AI 写得再快，代码也堆在那儿等人手动处理。

第三，A/B 测试和线上监控。新功能上线之后效果好不好，得有数据说话，效果不好得能随时关掉。没有这套机制，AI 一天产出五个功能，你都不知道哪个该留哪个该砍。

第四，任务管理。任务得拆到合适的粒度，生命周期得跟踪得住。一个大而模糊的任务丢给 AI，现在的能力还啃不动。多个 Agent 同时干活的时候，谁做哪个、哪个优先、做到什么程度，这些都得有地方管。

第五，系统架构。架构太乱或者压根没有架构的代码，AI 维护起来跟人一样头疼。上下文塞满了还是搞不清边界在哪，改一处崩三处。

这几条里如果有做不到的，就得靠人去补。补不上，AI First 就只是一句口号。

但假设你全做到了，就能 AI First 了？

还是不行。这套玩法只适合一部分场景。

什么场景适合？后端逻辑为主、界面不复杂的产品，比如 API 服务、数据处理平台、内部工具。功能好不好，跑一下数据就知道，不需要人去盯着每个像素。原文里的就是个 Agent 平台，本质上是后端驱动的产品，可以用这套打法。

再比如早期产品快速试错，功能上了不行就撤，用户预期本来就没那么高，AI 的速度优势能充分发挥。

但很多场景玩不转。

比如 UI 密集的产品。自媒体天天喊前端已死，但你让 AI 做个复杂界面试试，各种易用性问题、交互细节、视觉还原，它搞不定的。否则马斯克靠 AI 早就改了不知道改版 X 多少次了。

比如对功能质量敏感的产品。Anthropic 和 OpenAI 不知道 AI First 吗？他们敢在 Claude Code 和 Codex 上这么搞吗？让 AI 全自动迭代自家的核心产品，用户不骂死才怪。

再比如安全性要求高的场景，银行系统、在线交易平台，AI 代码出个差错，那可不是回滚能解决的。

AI First 的方向没有错，它代表的是一种意识的转变：每做一个决策的时候，想一想这件事能不能让 AI 来做，如果不能，缺什么条件，怎么把条件补上。

但这种意识要落地，靠的不仅是买几个 AI 工具的订阅，还需要把基础搭好。测试、CI/CD、监控、架构、任务管理，这些做扎实了，AI 的能力自然能释放出来。做不好，加再多 AI 也是在沙子上盖楼。

从这个角度看，AI First 的终点未必是让 AI 干所有的活，而是借着这股力量，把你一直想做但没动力做的工程改进，真正推动起来。

仰望星空是好的，但也还要脚踏实地。