他们用AI重建了一切——这是CREAO的故事

一个普通的周二

2026年某个周二上午10点，CREAO的工程团队上线了一个新功能。

没有庆祝，没有仪式。中午，A/B测试数据回来了——数字说不行。下午3点，功能被下线。下午5点，优化版本重新上线。

整个过程不到一个工作日。

三个月前，同样的周期需要六周。

这不是因为他们的工程师变聪明了，也不是因为他们换了更好的工具。而是因为他们做了一件大多数公司不敢做的事：把原有的工程流程彻底拆掉，从零开始，围绕AI重新搭建一切。

CREAO是谁

CREAO是一家智能体平台公司，25名员工，其中10名工程师。

2025年11月，他们开始构建智能体。两个月前，CTO对整个产品架构和工程工作流进行了从头到脚的重构。

规模不大，但做的事情，比很多大公司走得更远。

"AI优先"被滥用了

在讲CREAO的故事之前，有必要先厘清一个被严重滥用的词：AI优先。

大多数声称AI优先的公司，实际上做的是这样的事：工程师打开Cursor，PM用ChatGPT起草需求文档，QA尝试AI测试生成。工作流程没有变，效率提升了10%到20%，结构上什么都没有改变。

这叫AI辅助，不是AI优先。

真正的AI优先，是重新设计流程、架构和组织，基于"AI是主要建造者"这个前提出发。不再问"AI如何帮助我们的工程师"，而是问"我们如何重构一切，让AI来构建，工程师来提供方向和判断"。

两者的差距，是乘数级别的。

还有一种常见的伪装，叫vibe coding：打开Cursor，提示词搓出能跑的东西，提交，循环往复。这能做出原型，但生产系统需要稳定、可靠、安全。CREAO的CTO对此有一个清醒的判断：提示词是消耗品，系统才是真正要构建的东西。

他们看到了三个正在靠近的悬崖

在决定重构之前，CREAO的CTO审视了团队的工作方式，发现了三个会把公司拖垮的瓶颈。

第一个：产品管理

PM花几周时间做调研、写需求文档、等待评审。这套流程运转了几十年。但现在，智能体可以在两个小时内实现一个功能。

当构建时间从数月压缩到数小时，耗时数周的规划周期就从流程变成了障碍。一件事想了好几个月，然后两小时就做出来了——这逻辑说不通了。

第二个：QA测试

同样的问题。智能体两小时上线一个功能，QA团队要花三天测试边界情况。你以为解决了速度问题，却在下游十米处新建了一个瓶颈。

第三个：人员规模

CREAO的竞争对手有100倍甚至更多的人在做类似的工作。25个人对几千人，不可能靠招人追平。唯一的出路是重新设计。

他们得出的结论是：产品设计、产品实现、产品测试，这三个环节必须全部有AI贯穿。任何一个还在依赖人工，整条流水线就被锁死。

一切从代码库开始

在重构工程流程之前，CREAO的CTO先做了一件更基础的事：修复代码库本身。

旧架构分散在多个独立系统里，一个改动可能需要同时修改三到四个代码仓库。从人类工程师的视角看，这还可以接受。但从AI智能体的视角看，这几乎是不透明的——它看不到全貌，无法推断跨服务的影响，无法在本地运行集成测试。

解决方案：把所有代码统一进一个单一代码仓库（monorepo）。

理由只有一个：让AI能看到全部内容。

这后来被OpenAI在2026年2月总结为驾驭工程（harness engineering）的核心原则之一——你把越多的系统整合成智能体可以检查、验证和修改的形式，获得的杠杆就越大。碎片化的代码库对智能体不可见，统一的代码库则是清晰可读的。

CREAO没有从OpenAI那里学到这个原则。他们自己先走到了那里，只是当时没有名字。

整个重构过程：一周设计新系统架构，一周用智能体完成整个代码库的迁移。

值得一提的是，CREAO用的工具是他们自己的产品。他们用自己平台上的智能体，重建了运行这些智能体的平台本身。如果产品能构建自己，说明它真的可用。

系统是怎么运转的

重构后的工程体系，由几个紧密咬合的部分构成。

基础设施采用AWS，配备自动扩缩容和熔断回滚机制——如果部署后指标恶化，系统自动回滚，无需人工介入。CloudWatch是整套系统的神经中枢，覆盖超过25个告警，所有基础设施都暴露结构化、可查询的信号。逻辑很简单：AI读不了日志，就没法诊断问题。

CI/CD流水线采用GitHub Actions，每次代码变更经过六个强制阶段：验证CI、构建并部署Dev、测试Dev、部署Prod、测试Prod、发布。没有可选阶段，没有人工覆盖。流水线是确定性的，智能体可以预测结果并推断失败原因。

每个Pull Request触发三轮并行的AI代码审查，使用Claude Opus 4.6：第一轮查代码质量（逻辑错误、性能、可维护性），第二轮查安全性（漏洞扫描、认证边界、注入风险），第三轮查依赖项（供应链风险、版本冲突、许可证问题）。这些是审查门禁，不是建议。每天部署八次，没有哪个人类审查者能对每个PR都保持高度专注。

功能发布全部通过Statsig的功能标志管理：先对内部团队开放，再按百分比逐步推进，最后全量发布或下线。下线开关可以瞬间关闭一个功能，无需重新部署。坏功能当天死亡，这不是比喻，是字面意思。

系统的心脏：自愈循环

在整套体系里，有一个部分被CREAO视为核心——他们把它叫做自愈反馈循环(Self-healing Feedback Loop)。

每天时间9:00，自动化健康检查工作流启动。Claude Sonnet 4.6查询CloudWatch，分析所有服务的错误模式，生成健康摘要，通过Microsoft Teams推送给团队。没有人需要主动发起请求。

一小时后，分流引擎运行。它聚合来自CloudWatch和Sentry的生产错误，按九个严重程度维度对每个错误集群打分，在Linear中自动生成调查工单——每张工单包含样本日志、受影响用户、受影响接口和建议的调查路径。

系统会自动去重。如果已有未解决的工单覆盖相同的错误模式，就更新那张工单；如果已关闭的问题再次出现，系统检测到回归后会重新打开它。

工程师推送修复后，走同一套流水线：三轮Claude审查，CI验证，六阶段部署。部署完成后，分流引擎重新检查CloudWatch——如果原始错误已解决，Linear工单自动关闭。

整个循环：错误被检测、被分流、被修复、被验证，几乎不需要人工介入。CREAO的CTO曾对媒体说过一句话，精确描述了这套循环下人类的角色："AI来提PR，人类只需要审查有没有风险。"

14天，每天最多8次部署

数字是最直接的证据。

在重构后的14天内，CREAO平均每天部署3到8次。在旧模式下，同样的两周可能连一次生产发布都达不到。

外界的直觉反应通常是：这肯定是用质量换速度。

但CREAO的数据指向相反的方向：用户参与度提升，付费转化率提升。原因也不难理解——每天发布能获得的反馈，比每月发布多得多。反馈循环越紧，学习越快，产品就越好。

文章开头那个周二的故事，不是特例，是日常。

组织也变了

技术架构变了，人的角色也必须跟着变。

CREAO的CTO认为，未来只存在两种工程师。

架构师，一到两个人。他们设计标准操作流程，告诉AI如何工作。他们构建测试基础设施、集成系统、分流系统，决定架构和系统边界，定义对智能体来说"好"是什么样的。

这个角色的核心能力不是写代码，而是批判AI。当智能体提出方案时，架构师要找漏洞：遗漏了哪些故障模式？越过了哪些安全边界？在积累什么技术债？CREAO的CTO有物理学博士背景，他认为博士训练给他最有用的东西，不是技术知识，而是质疑假设、压力测试论点、寻找缺失项的能力。

这也是最难填补的岗位。

操作员，其他所有人。工作本身仍然重要，只是结构变了——AI分配任务给人，人负责调查、验证、审核风险。具体工作包括Bug调查、UI优化、PR审查、验证结果。这些需要技能和专注，但不再需要旧模式下那种系统性的架构推理。

一个意料之外的观察

在这场转型中，CREAO的CTO发现了一个他自己也没有预料到的规律：初级工程师比高级工程师适应得更快。

经验少的初级工程师感到被赋能了。他们有了能放大自身影响力的工具，也没有多年积累的习惯需要遗忘。

反而是拥有丰厚传统经验的高级工程师适应得最慢。他们花两个月才能完成的工作，AI一个小时就搞定了。在积累了多年稀缺技能之后，接受这一点是很难的。

这不是在做价值判断，这是一个观察。在这场转型中，适应能力比积累的技能更重要。

CTO自己也变了

组织的变化，也深刻影响了CTO本人的工作方式。

两个月前，他60%的时间用于管理：对齐优先级、开会、给反馈、辅导工程师。现在这个比例低于10%。

他从管理者变成了建造者，每天从早上9点工作到凌晨3点，设计系统架构，维护驾驭机制。更有压力，但他说，他享受构建，而不是对齐。

一个意外的副产品：团队关系反而变好了。以前，他和团队的大部分互动都是对齐会议，讨论权衡，争辩优先级，在技术决策上产生分歧。那些对话在传统模式下是必要的，但也很消耗精力。现在他们聊别的——非工作话题、随意闲聊、团建旅行。

不再争论那些系统就能搞定的事，人和人之间反而有了更真实的连接。

不确定性也是真实的

CREAO的故事不是一个所有人都皆大欢喜的故事。

当CTO不再每天找人谈话时，一些团队成员感到迷茫：CTO不和我说话意味着什么？我在这个新世界里的价值是什么？这些担忧是合理的，没有被回避，也没有被轻易解答。

有些人花在争论"AI能不能做我的工作"上的时间，比实际做工作的时间还多。转型期制造了真实的焦虑。

CREAO给出的不是一个让所有人都放心的承诺，而是一个原则：我们不会因为工程师引入了一个生产Bug就开除他，我们会改进审查流程。对待AI也一样——如果AI出错了，我们构建更好的验证机制，而不是推卸责任或放弃系统。

工程之外

CREAO没有止步于工程。

他们观察到：如果工程能在几小时内发布功能，但市场营销要一周才能发布公告，那营销就是瓶颈。如果产品团队还在跑月度规划周期，那规划就是瓶颈。

于是，AI原生运营被推进了每一个职能：产品发布说明从变更日志自动生成，功能介绍视频由AI制作，社交媒体每日推送由AI编排并自动发布，健康报告和分析摘要从CloudWatch和生产数据库自动生成。

工程、产品、市场、增长，在同一个AI原生工作流里运转。一个职能以智能体速度运转，另一个以人工速度运转，人工速度的那个就会拖慢一切——这个逻辑对公司的每个部门都成立。

一个记者的评价

曾有一位《商业内幕》的记者采访过CREAO的CTO。她说，她在这个话题上采访了大约五个人，CREAO比任何人都走得更远。

她的原话是："我不觉得有任何人像你们这样，真的把整套工作流全部重建了。"

CREAO的技术栈里没有任何专有的东西，所有工具任何团队都可以用。

差距不在工具，在于做出了那个决定——围绕这些工具重新设计一切——并且愿意承担这个过程真实存在的代价：员工的不确定感，CTO每天工作18小时，高级工程师质疑自身价值，有两周时间旧系统已经拆掉但新系统还没跑稳。

他们承受了这个代价。两个月后，数字说明了一切。

他们构建了一个智能体平台，他们用智能体构建了它。