AI-First 不是装个 Cursor，而是重写整条工程流水线

很多团队说自己在做 AI-first，其实只是把 AI 塞进旧流程里：PM 还在写长规格文档，工程师还在按老节奏开发，QA 还在人工回归，发布还是低频大版本。效率当然会提升一点，但架构和组织并没有变。

Peter Pang 这篇长帖给了一个更狠也更实在的判断：真正的 AI-first，不是“AI 帮工程师写代码”，而是“把公司重构成 AI 是主要建造者，人类负责方向、约束和判断”的系统。

这不是一句口号，而是对产品设计、代码仓库结构、CI/CD、监控、告警、代码审查、回滚机制、功能开关、团队分工的整套改造。

这篇帖子的核心观点

作者来自 CREAO，一个 25 人团队、其中 10 个工程师的 agent 平台公司。他们在 2025 年底开始用 agents，两个月前彻底重构了产品架构和工程流程。结果是：

• 99% 的生产代码由 AI 编写
• 新功能可以在当天完成开发、A/B 测试、数据判断和回滚
• 两周内平均每天发布 3 到 8 次
• 以前要 6 周的迭代，现在一天内能跑完一轮

关键不在于“提示词更会写”，而在于他们把整个系统改造成了一个 harness engineering 体系，也就是让 agent 能稳定做事的一整套操作系统。

不是 AI-assisted，而是 AI-first

作者把这两者区分得很清楚：

• AI-assisted：旧流程不变，只是在某些环节加 AI
• AI-first：默认 AI 是主要执行者，所有流程围绕这个现实重建

这两者差别不只是 10% 到 20% 的提效，而是数量级变化。

一个常见误区是所谓 vibe coding。开着 Cursor，一路 prompt 到“能跑”为止。这对原型有用，但对生产系统不够。要让 AI 写的代码能长期进生产，你必须给它稳定的约束系统，而不是把希望押在 prompt 灵感上。

他们先砍掉了三个瓶颈

1. Product Management 瓶颈

当 agent 两小时就能做出一个功能时，PM 再花几周研究和写规格，就成了新的慢点。作者的结论很直白：产品设计必须从“先想很久再造”切到“快速原型 → 上线 → 测试 → 迭代”。

2. QA 瓶颈

AI 两小时写完代码，人工 QA 三天回归，这根本不匹配。所以他们改成 AI-built testing platforms test AI-written code，让验证速度跟上实现速度。

3. Headcount 瓶颈

他们的竞争对手人数是自己的 100 倍以上，没法靠招人追平，只能靠重构系统。只要设计、实现、测试里有一个环节还是手工，就会卡住整条流水线。

他们做对的第一件事，是把代码库变得“对 AI 可见”

作者强调，原来的系统散在多个 repo 里，一个改动可能要动三四个仓库。对人类工程师来说还能勉强驾驭，但对 agent 来说这就是黑箱。AI 看不全系统，就推不出跨服务影响，也跑不了完整集成测试。

所以他们先做了一件非常关键但很多团队不愿做的事：把系统收进一个 monorepo。

这背后其实就是 harness engineering 的底层原则：

你让 agent 能看见、能验证、能修改的系统部分越多，它能创造的杠杆就越大。

分裂的系统，对 agent 来说几乎等于隐形。统一后的系统，才是可推理、可验证、可自动化的。

他们的 AI 软件工厂长什么样

作者给出的栈不神秘，但组合方式很说明问题：

• AWS 负责基础设施和自动扩缩容
• CloudWatch 做结构化日志、告警和指标
• GitHub Actions 跑六阶段 CI/CD
• Claude 做三路并行 PR 审查（代码质量、安全、依赖）
• Sentry 收异常
• Linear 接自动生成的问题单
• Statsig 做 feature flags 和 A/B test
• Graphite 管理 merge queue 和 stacked PRs

六阶段发布流水线是：

1. Verify CI
2. Build and Deploy Dev
3. Test Dev
4. Deploy Prod
5. Test Prod
6. Release

重点不是工具名单，而是每一环都被做成 确定性、可预测、可恢复。这样 agent 才能知道失败意味着什么，而不是像人在雾里猜。

这套系统最值钱的是“自愈闭环”

每天 9:00 UTC，Claude Sonnet 会自动读取 CloudWatch，生成健康摘要发给团队。一小时后，另一个 triage engine 会把生产错误聚类、按九个维度打严重度分数，然后自动在 Linear 里建调查 ticket，带上样例日志、影响用户、涉及端点和排查建议。

如果已有 open issue，就更新；如果以前修过又复发，就自动识别回归并重开。修复代码提交后，还是走同一套评审、CI、部署、监控链路。部署完成后，triage engine 再复检，如果原始错误消失，ticket 自动关闭。

这才是真正像“AI 软件工厂”的地方：不是单次写代码，而是把 发现问题 → 聚类 → 诊断 → 修复 → 验证 → 关闭 也做成可重复的系统。

作者对团队角色的判断，很值得细品

他认为未来会分成两类工程角色：

1. Architect

只有一两个人，负责设计 SOP、测试基础设施、集成系统、triage 系统、架构边界，以及定义 agent 的“好工作”标准。这个角色最重要的能力，不是写代码，而是批判 AI、找漏洞、识别失败模式和技术债。

2. Operator

其余人更多是在系统中做调查、验证、UI 调整、CSS 改进、PR 审核和风险把关。工作仍然重要，但结构变了，很多高层次架构判断被上移到了 Architect 层。

这个观点未必适用于所有团队，但它很诚实地指出了一件事：AI-first 不是简单替代人，而是重新切分“谁做什么”。

对技术团队真正有用的，不是口号，是这 6 个动作

如果你想把自己的团队从“会用 AI”推进到“按 AI-first 方式工作”，这篇帖最值得抄的不是措辞，而是下面这些动作：

1. 把 repo 结构做成 agent 可见、可验证的形状，优先收拢上下文
2. 把测试和发布做成确定性流水线，别让 AI 在模糊流程里瞎撞
3. 让日志、告警、错误都结构化，因为 AI 只能消费可读信号
4. 功能默认走 feature flag，让上线、A/B test、回滚都变轻
5. 把 triage 自动化，不要让“发现 bug”还靠人肉盯着看
6. 重新定义工程角色，让最强的人设计系统，而不是反复搬砖

这篇帖真正打中的地方

很多人谈 AI 编程时，只看模型能力。但这篇内容提醒我们，决定上限的往往不是模型，而是 harness。

模型会变强，工具会变快，但如果你的组织、代码库、测试、发布、监控还是旧时代那套，AI 最多只能在局部提效。你不重写系统，系统就会把 AI 的能力稀释掉。

所以这篇帖最该记住的一句，不是“99% 的代码由 AI 编写”，而是：

真正的 AI-first，是把工程系统本身重构成适合 agent 工作的形状。

Source

Original thread: https://x.com/intuitiveml/status/2043545596699750791?s=46&t=XvnC7kQ9xNYY6xAO-1HzbQ