# 与其说 AI First，不如先把测试、CI/CD 和监控这些软件工程的基础搭好

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

- 来源：X · @dotey（宝玉）
- 发布时间：2026-04-14T06:17:41.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/3542
- 原文：https://x.com/dotey/status/2043936713618104582

## 摘要

这篇文章的核心判断是：AI First 不是买几个 AI 工具订阅就能跑通的，它首先是一道软件工程题。AI 两小时写完代码，如果审查、测试、部署、监控和回滚还得靠人慢慢排队，瓶颈就从写代码转移到了 QA 和运维，25 人的团队照样快不起来。作者列出了几个硬性前提：自动化测试覆盖得够，不然每次 AI 提交你都得人工回归；CI/CD 流水线要全自动跑通，代...

## 推荐理由

这是一篇从业者视角的评论，不是新闻事件。H 分给那个反直觉的标题翻转，K 分给具体的工程前提和适用边界，R 分给瓶颈转移的痛点论述。分数停在 75 左右，因为正文没有给出具体案例、一手测试数据或团队规模外的量化验证，更像经验判断。

## 锐评

这篇文章的贡献是把“AI First”从口号拆成了工程清单。作者没在聊模型能力，而是在聊交付流水线：自动化测试覆盖不够，AI 每次提交你都得人工回归；CI/CD 没全自动跑通，代码写得再快也堆在那儿等人处理；没有 A/B 和线上监控，AI 一天产五个功能你都不知道该留哪个。这些判断是实在的，但文章自己也划了边界——这套打法只适合后端逻辑为主、界面不复杂的产品，比如 API 服务、内部工具。UI 密集、功能质量敏感或高安全要求的场景玩不转，作者拿 Anthropic 和 OpenAI 自家的核心产品举例，说他们也不敢让 AI 全自动迭代。

信息缺口也明显：正文没给出任何实际团队跑通这套流水线后的量化数据，比如部署频率、回滚率、人工介入次数，所以“一天部署好几次”更像理想态描述。另外，任务管理那块提到“拆到合适粒度”，但没展开怎么拆、谁来拆，这对多 Agent 协作是核心难题。整体看，这篇文章适合拿来对照自己的工程基建做体检，但别把它当迁移方案直接用。