---
title: "AI First？不，这明明是软件工程 First！"
source: wechat
url: https://mp.weixin.qq.com/s/rJQ8ubfhmQSfXLxI78pPYg
ingest_date: 2026-07-04
vxc: 49
stars: 4
sha256: cefe272c8b0a49462ba792c5867705db88743e6d70d662cf9e3e9509d1b49795
---

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

**来源**: 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，本质上是一场彻头彻尾的“软件工程革命”。

# 01 所谓 AI First，其实是“把人踢出执行链条”

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

- •
  需求的漏斗：
  过去产品经理（PM）花两周做调研、写文档，工程师开发要一个月。现在 AI 开发只要两小时，PM 那两周的决策过程就成了公司的“成本黑洞”。

- •
  测试的堤坝：
  AI 可以在瞬间产出成千上万行代码，如果 QA 还在靠人工点点点，或者写那种半自动化的脚本，测试周期会从“天”变成“周”，AI 节省的时间全被填进了测试坑里。

- •
  人力的诅咒：
  传统的“人海战术”在 AI 面前失去了规模效应。25 人的精锐团队配合成熟的 AI 流水线，产出能轻易碾压几百人的大工厂。

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

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

# 02 落地 AI 之前，先看这五块“工程压舱石”

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

- 

- 自动化测试：AI 的“安全带”

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

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

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

AI 目前还啃不动“大而模糊”的需求。你必须具备将业务目标拆解为“原子级任务”的能力。这就要求管理者的逻辑必须极度严密。任务生命周期的跟踪、多 Agent 协作的冲突处理，这些都需要在 Jira 之外有一套更敏捷的任务分发引擎。
9. 5. 系统架构：AI 的“思考地图”

这是我最想强调的一点。
   烂架构是 AI 的噩梦。

如果你的代码耦合严重，就像一团乱麻，AI 在理解上下文时会迅速耗尽 Token，且改动风险不可控。

这里我们要引入 DDD（领域驱动设计）的思想。
   只有边界清晰、领域自治的架构，才能让 AI 像拆乐高一样进行模块化迭代。架构师的工作，就是把这幅“地图”画好，让 AI 在既定的航道里航行。

# 03 场景辨析：哪些场景是 AI 的死穴？

Peter Pang 的成功有其特殊性。他做的是 Agent 平台，本质上是 后端逻辑驱动 。但并非所有领域都能如此激进。

- •
  AI 的舒适区：
  后端逻辑、数据处理、API 服务、内部工具。这些领域逻辑确定，可以通过自动化测试形成闭环，用户对界面的“审美”要求不高。

- 

•
  AI 的深水区（慎入）：

- 

•
  UI/UX 密集型产品：
  AI 可以写 CSS，但它很难理解“这个按钮往左挪 2 像素带来的呼吸感”。复杂的交互细节、视觉还原和易用性，目前依然需要人类设计师的“直觉”。

- •
  高安全性与重合规领域：
  银行结算、在线支付、医疗诊断。AI 的“幻觉”在这些领域是致命的。回滚只能解决程序错误，解决不了已经流失的真金白银。

# 04 架构师的进化：从“码农”到“π型人才”

原文中一个最残酷的观察是： 资深工程师反而更难适应这套流程。

因为资深工程师的价值过去体现在“手艺”上——对 API 的熟练度、对语法糖的运用、手动调试的经验。但在 AI 面前，这些“产量”技能正在迅速贬值。

未来我们需要的是“π型人才”： 

 一横是广博的业务洞察和 AI 工具运用能力，两纵分别是 深厚的架构功底 和 严密的逻辑批判思维 。

- •
  从写作者变成审核员：
  你的工作不再是把代码敲出来，而是去审视 AI 的逻辑。它是否遗漏了边界条件？它是否引入了循环依赖？它是否为了实现功能而牺牲了扩展性？

- •
  质疑 AI 的能力比使用 AI 更重要：
  AI 永远会给你一个答案，但那个答案可能是一个优雅的陷阱。架构师必须具备“一眼看穿漏洞”的直觉，这需要多年的工程实践沉淀。

# 05 结语：别在沙子上盖摩天大楼

AI First 的方向绝对正确，但它不是买几个 Copilot 账号那么简单。它是一场对公司底层工程能力的“大考”。

如果你现在的团队还在为环境配置发愁，还在靠人工写周报对齐进度，还在因为代码没写注释而互相埋怨，那么强行推行 AI First 只会让你在沙子上盖楼，楼越高，崩塌得越快。

AI First 的终点，未必是让 AI 干所有的活，而是借着 AI 的这股大潮，把你一直想做、但一直没动力做的“工程改进”真正推动起来。

把测试补齐，把架构理顺，把流程自动化。当这些脚手架搭好了，AI 的能力自然会像洪水一样灌溉进来。

仰望星空，脚踏实地。 先做一个顶级的软件工程师，再去谈 AI 战略。

# 附表：传统研发 vs AI 优先研发模式对比

维度
传统研发模式 (Legacy)
AI 优先模式 (AI-First)

核心生产力
程序员的脑力和体力
AI Agent 的算力 + 架构师的决策力

交付周期
以“周/月”为单位的 Sprint
以“小时/天”为单位的连续迭代

质量保障
人工测试 + 抽样覆盖
全自动测试脚手架 + AI 审计

人员结构
金字塔型（大量初中级执行人员）
哑铃型（少量核心架构师 + 自动化工具）

失败成本
高，修复和重新部署周期长
低，支持瞬时回滚和灰度决策

核心壁垒
代码实现的复杂度
系统的可观测性与架构设计的整洁度

💡 互动留言： 

 在你的业务场景中，哪一个环节是目前 AI 介入的最大阻碍？是架构债太重，还是测试自动化程度太低？欢迎在留言区分享你的看法。