夜雨聆风今天早上读了一篇X上分享AI- first的实践文章。最近公司正在尝试将AI应用在工作流里，这篇文章提供很多很实际的失败尝试及解决思路。
核心观点写在前面：真正的“AI-first”不是用 AI 提高效率，而是把整个软件工程流程重构为以 AI 为核心。代码主要由 AI 生成，人类工程师的角色转向定义问题、评估风险和做决策。为此，他们重建了从产品设计、开发到测试和部署的全流程，用统一架构、自动化测试、严格 CI/CD 和 AI 审查，构建出一个可以自动发现问题、修复并验证的“自愈系统”。
这种模式带来了极高的迭代速度（一天多次发布）和更快的反馈循环，使小团队也能产生很高产出。本质上，是把工程从“人写代码”变成“设计让 AI 高效工作的系统”。
这是一种很前沿且有潜力的实践，特别适合需要快速试错的产品型团队。但它高度依赖强大的系统设计能力和工程基础，否则容易失控，也不一定适用于高安全或超复杂场景。总体来看，它代表了一种可能的未来方向，但目前仍属于少数团队能成功落地的模式。
以下是译文，原文在文章底部。
我们 99% 的生产代码由 AI 编写。上周二，我们上午 10 点发布了一个新功能，中午做了 A/B 测试，下午 3 点因为数据不理想直接下线。下午 5 点我们又发布了一个更好的版本。三个月前，这样一个周期需要六周。
我们并不是通过在 IDE 里加一个 Copilot 就做到这一点的。我们是把整个工程流程拆掉，然后围绕 AI 重建。我们改变了规划、开发、测试、部署和团队组织的方式，也改变了公司里每个人的角色。
CREAO 是一个智能体平台。公司有 25 人，其中 10 名工程师。我们在 2025 年 11 月开始构建 agent，两个月前我从底层彻底重构了整个产品架构和工程流程。
2026 年 2 月，OpenAI 发布了一个概念，正好描述了我们一直在做的事情。他们称之为“harness engineering（编排工程）”：工程团队的主要工作不再是写代码，而是让智能体能够完成有用的工作。当出现问题时，解决方案不再是“再努力一点”，而是：缺了什么能力？如何让这个能力对 agent 可理解、可执行？
我们是自己得出这个结论的，当时甚至还没有名字。
AI-First 不等于使用 AI
大多数公司只是把 AI 加到原有流程里。工程师打开 Cursor，产品经理用 ChatGPT 写需求，QA 用 AI 生成测试。流程没变，效率提升 10%～20%，但结构没有变化。
这叫 AI 辅助。
AI-first 则意味着：你围绕“AI 是主要构建者”这个前提，重设计流程、架构和组织。你不再问“AI 如何帮助工程师”，而是问：“如何重构一切，让 AI 来构建，而工程师提供方向和判断？”
两者的差距是乘法级的。
很多团队自称 AI-first，但仍然用相同的 sprint、Jira、站会、QA 审批。他们只是把 AI 加进循环，而没有重构循环。
常见的一种形式叫“vibe coding”：打开 Cursor，不断 prompt，直到能跑，然后提交、重复。这适合做原型。但生产系统需要稳定、可靠、安全。你需要一个系统，在 AI 写代码时也能保证这些属性。系统才是关键，prompt 是消耗品。
为什么我们必须改变
去年我观察团队工作方式，发现三个致命瓶颈：
1. 产品管理瓶颈
PM 花几周时间做调研、设计、写需求。但 agent 两小时就能实现功能。当开发时间从几个月缩短到几小时，几周的规划反而成了瓶颈。
花几个月思考，再用两小时实现，是不合理的。
PM 必须进化为“具备产品思维的架构师”，以迭代速度工作，否则就退出构建流程。设计必须通过“快速原型-上线-测试-迭代”，而不是委员会评审文档。
2. QA 瓶颈
功能两小时完成，但 QA 要三天测边界情况。
我们用 AI 构建的测试平台取代人工 QA，让 AI 测 AI 写的代码。验证必须和实现同速，否则只是把瓶颈往后挪。
3. 人数瓶颈
竞争对手人数是我们的 100 倍。我们只有 25 人，无法靠招聘追赶，只能靠重构。
产品设计、实现、测试三个系统都必须 AI 化，任何一个环节是人工，都会限制整体。
关键决策：统一架构
我先从代码库开始。
旧架构分散在多个系统，一个改动可能要动 3～4 个仓库。对人类工程师来说可管理，但对 AI 来说是“不可见”的。
agent 看不到全局，无法推理跨服务影响，也无法本地跑集成测试。
所以我把所有代码统一到一个 monorepo——让 AI 能“看见一切”。
这是 harness engineering 的核心：系统越可观察、可验证、可修改，AI 杠杆越大。碎片化代码对 AI 是隐形的，统一结构才是“可读的”。
我用一周设计新系统（规划、实现、测试、集成测试），再用一周借助 agent 重构整个代码库。
我们用自己的 agent 重建平台本身——如果产品能自我构建，它就成立。
技术栈
基础设施：AWS
自动扩缩容 + 熔断回滚。指标变差自动回滚。CloudWatch 是“中枢神经系统”：结构化日志、25+ 告警、自定义指标。所有系统都输出可查询信号——如果 AI 读不懂日志，就无法诊断问题。
CI/CD：GitHub Actions
六阶段流水线：
验证 → Dev 构建部署 → Dev 测试 → Prod 部署 → Prod 测试 → 发布
CI 强制执行：类型检查、lint、单测、集成测试、Docker、Playwright E2E、环境一致性检查。无人工绕过。
AI 代码评审：Claude
每个 PR 三轮 AI 审查：
代码质量（逻辑、性能、可维护性）
安全（漏洞、认证、注入风险）
依赖（供应链、版本、许可证）
这是“门槛”，不是建议。
自愈反馈循环（核心）
每天 UTC 9:00 自动运行健康检查：
Claude 分析 CloudWatch
输出健康报告到 Teams
一小时后：
聚类错误（CloudWatch + Sentry）
按 9 个维度打分
自动生成 Linear 工单
自动去重、自动复开回归问题。
修复后：
AI 审查 → CI → 部署
再检测
问题解决自动关闭工单
形成“检测 → 分析 → 修复 → 验证”的闭环。
Feature 流程
架构师写结构化 prompt
agent 拆解任务、写代码、生成测试
PR + AI 审查 + 人类评估风险
CI 验证
合并队列
六阶段部署
feature flag 渐进发布
出问题立即 kill / 自动回滚
Bug 修复也是同一流程。
结果
14 天内：
每天 3～8 次生产发布
过去两周甚至发不出一个版本
坏功能当天上线当天下线
新功能当天上线
A/B 测试实时验证
用户参与度 ↑
付费转化 ↑
不是牺牲质量换速度，而是因为反馈更快。
新的工程组织
Architect（架构师）1～2 人负责：
SOP
测试系统
架构设计
定义“什么是好”
核心能力：批判 AI，而不是跟随 AI。
Operator（操作员）
其他人
AI 分配任务，人类负责：
验证
修复
UI 调整
PR 审核
谁适应最快
出乎意料：
初级工程师适应更快
资深工程师更难适应
因为前者没有旧习惯，后者需要“卸载”多年经验。关键不是经验，而是适应能力。
人的变化
管理减少
我从 60% 管理 → <10%
现在主要在：
写代码
设计系统
争论减少
以前大量时间在对齐、争论
现在系统解决这些问题
人与人关系反而更好
不确定性
不是所有人都适应，有人开始怀疑自己的价值。
但原则是：
不因为 bug 责怪人，而是优化系统
AI 出错 → 加强约束和验证
不只是工程
如果工程提速，但市场、产品不变——它们会成为瓶颈。
所以我们把 AI 引入所有职能：
发布说明：AI 生成
产品视频：AI 生成
社媒：自动发布
报告：AI 生成
这意味着什么
对工程师
价值从“写代码” → “判断能力”
更重要的是：
批判 AI
判断设计好坏
发现系统漏洞
对 CTO / 创业者
PM 流程 > 开发时间 → 优先改
先建测试系统
从一个架构师开始
全面 AI 化
对行业
OpenAI、Anthropic 等已经收敛到同一模式：
结构化上下文
专用 agent
持久记忆
执行循环
我们还在早期
大多数公司仍是传统模式
真正彻底重构的很少
工具不是壁垒
真正的壁垒是：
是否愿意重构
是否承受成本
成本包括：
员工不安
CTO 高强度工作
组织震荡
我们承受了这些。两个月后，结果说明一切。
我们构建的是一个 agent 平台。
而我们用 agent 构建了它。
原文链接https://x.com/intuitiveml/status/2043545596699750791?s=46
