AI-First Strategy — CREAO 的 Agent 原生工程实践
CREAO(25人 agent 平台公司,10名工程师)的 AI-First 转型复盘。99% 生产代码由 AI 编写,日均 3-8 次生产部署。
AI-First ≠ 使用 AI
| AI-Assisted | AI-First |
|---|---|
| 工程师打开 Cursor | 围绕 AI 是主要构建者重新设计流程、架构和组织 |
| PM 用 ChatGPT 起草 spec | 停止问"AI 如何帮助工程师",开始问"如何重组一切让 AI 做构建" |
| 效率提升 10-20% | 乘数效应,速度从月到天 |
Vibe coding 产出原型;生产系统需要稳定、可靠、安全——需要能保证这些属性的系统。
三个瓶颈
- 产品管理瓶颈:agent 两小时实现功能,PM 花数周调研设计。规划周期必须匹配构建速度。
- QA 瓶颈:构建 2 小时,测试 3 天。必须用 AI 测试平台测试 AI 代码。
- 人头瓶颈:竞争对手 100 倍人力,必须用设计而非招聘弥补。
架构统一:单一代码库
将分散的多仓库统一为单一代码库(monorepo):
- AI 能看到完整图景
- 能推理跨服务影响
- 能在本地运行集成测试
碎片化的代码库对 agent 不可见;统一的代码库对 agent 可读。
技术栈
| 层级 | 技术 | 作用 |
|---|---|---|
| 基础设施 | AWS + CloudWatch | 结构化日志、25+ 告警、自动工作流每日查询 |
| CI/CD | GitHub Actions | 六阶段管道:Verify → Build Dev → Test Dev → Deploy Prod → Test Prod → Release |
| 代码审查 | Claude Opus 4.6 | 三并行审查:代码质量、安全、依赖扫描 |
| 自愈 | Claude Sonnet 4.6 | 每日 9AM UTC 健康检查 → 错误聚类 → Linear 工单 |
| 功能开关 | Statsig | 团队内 → 渐进百分比 → 全量发布或 kill |
| 分支管理 | Graphite | merge queue + stacked PRs |
自愈合反馈循环( centerpiece )
每日健康检查(CloudWatch 查询 + 执行摘要)
↓ 1小时后
错误聚类(CloudWatch + Sentry)→ 9 维度严重度评分 → Linear 工单
↓ 工程师修复
PR → 三阶段 Claude 审查 → CI → 六阶段部署
↓ 部署后
Triage 引擎重新检查 → 错误解决则自动关单
新工程组织架构
| 角色 | 职责 | 数量 |
|---|---|---|
| 架构师 | 设计 SOP、测试基础设施、审查系统、定义"好"的标准。批评 AI,而非跟随 AI。 | 1-2 人 |
| 操作员 | bug 调查、UI 微调、PR 审查、验证。AI 分配任务,人类评估风险。 | 其余所有人 |
意外发现:初级工程师比高级工程师适应更快——没有十年习惯需要抛弃。
管理坍塌
CTO 从 60% 时间管理人 → <10%。从"对齐会议"转向"直接构建"。人际关系反而变好——因为不再争论 AI 能轻松完成的工作。
关键洞察
- 工程、产品、市场、增长必须全部 AI-native:任何人类速度的环节都会约束整个管道
- 先建测试 harness,再扩展 agent:快速 AI 没有快速验证 = 快速技术债务
- 从一位架构师开始:先由一个人构建系统并证明有效,再让其他人作为操作员 onboard
- Opus 4.5 做不到的事,Opus 4.6 做到了——模型能力是时钟驱动力
- 一人公司将成为常态:一位架构师 + agent = 100 人的产出
Sources
- <a href="/wiki/raw/to-learn/why-your-"ai-first"-strategy-is-probably-wrong.md" class="wikilink">Why Your "AI-First" Strategy Is Probably Wrong
- https://x.com/intuitiveml/status/2043545596699750791