Tldr
CREAO 把整个工程流程拆了重建，围绕 AI 是主要构建者重新设计：monorepo + 六阶段 CI/CD + 三路 AI 代码审查 + 自愈反馈循环 + 特性开关。AI 优先 ≠ 使用 AI；前者是重新设计循环，后者是把 AI 加进现有循环。14 天内日均 3-8 次生产部署。
我们 99% 的生产代码由 AI 编写。上周二，早上 10 点上线一个新功能，中午做完 A/B 测试，下午 3 点数据说不行，直接砍掉。下午 5 点，改进版上线。三个月前，这样一个周期要六周。
我们不是靠在 IDE 里装个 Copilot 走到这一步的。我们把工程流程拆了个干净，围绕 AI 重建了一切。规划、开发、测试、部署、团队组织——全都变了。公司里每个人的角色都变了。
CREAO 是一个 AI 智能体（AI Agent）平台。二十五个人，十名工程师。我们从 2025 年 11 月开始做智能体，两个月前，我从零开始重构了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月发布了一个概念，精准描述了我们一直在做的事。他们把它叫做 Harness 工程（Harness Engineering，指工程团队的核心职责从写代码转变为构建让 AI 智能体高效工作的基础设施和规范）：工程团队的首要工作不再是写代码，而是让智能体能做有用的事。当某个环节出了问题，答案永远不是”再试试”。答案是：缺了什么能力？怎么让智能体看得懂、管得住？
我们独立走到了同一个结论。只是当时还没给它起名字。
AI 优先不等于使用 AI
大多数公司是把 AI 硬塞进现有流程。工程师打开 Cursor，PM 用 ChatGPT 写需求文档，QA 试着用 AI 生成测试用例。工作流没变，效率提高了 10% 到 20%。结构性的东西纹丝未动。
这叫 AI 辅助（AI-assisted）。
AI 优先（AI-first）意味着你围绕”AI 是主要构建者”这一假设，重新设计流程、架构和组织。 你不再问”AI 怎么帮工程师干活”，而是问”怎么重新组织一切，让 AI 来建造，工程师提供方向和判断”。
两者的差距是乘法级的。
我见过不少团队声称自己是 AI 优先，同时照旧跑 sprint、用 Jira 看板、每周开站会、走 QA 签核流程。他们把 AI 加进了循环。但他们没有重新设计这个循环。
一种常见的变体是所谓的凭感觉编程（Vibe Coding）。打开 Cursor，一直 prompt 直到跑通，提交，重复。这能产出原型。但生产系统需要稳定、可靠、安全。你需要一套体系来保证——当代码是 AI 写的时候，这些属性依然成立。你构建的是体系。Prompt 是一次性的。
为什么我们必须变
去年，我观察团队的工作方式，发现了三个会要了我们命的瓶颈。
产品管理瓶颈
我们的 PM 花好几周时间调研、设计、撰写需求规格。几十年来产品管理一直是这么干的。但智能体两小时就能实现一个功能。当构建时间从数月坍缩到数小时，一个长达数周的规划周期就成了约束。
花几个月去想一件事，然后两小时建完——这说不通。
PM 需要进化成具备产品思维的架构师，跟上迭代的速度，否则就得退出构建周期。设计应该通过快速的”原型→上线→测试→迭代”循环来完成，而不是在委员会里审评规格文档。
QA 瓶颈
同样的问题。智能体交付一个功能后，我们的 QA 团队要花好几天测试边界情况。开发时间：两小时。测试时间：三天。
我们用 AI 构建的测试平台替代了人工 QA，让 AI 写的测试去验证 AI 写的代码。验证必须和实现跑在同一个速度上。否则，不过是把瓶颈往下游挪了几步。
人力瓶颈
我们的竞争对手有 100 倍甚至更多的人在做类似的事。我们只有 25 人。没法靠堆人来填补差距。只能靠重新设计来追上。
三个系统必须有 AI 贯穿其中：产品设计、产品实现、产品测试。任何一个环节还停留在手工阶段，就会拖住整条流水线。
大胆的决定：统一架构
我得先把代码库修好。
原来的架构散落在多个独立系统里。一次改动可能要碰三四个仓库。对人类工程师来说，还行。对 AI 智能体来说，这是黑箱。它看不到全貌，无法推理跨服务的影响，无法在本地跑集成测试。
我把所有代码统一到了一个单一代码仓库（Monorepo）。原因之一：让 AI 能看到所有东西。
这就是 Harness 工程原则的实践。你把越多的系统拉进一种智能体能检视、验证和修改的形态，你获得的杠杆就越大。碎片化的代码库对智能体来说是隐形的。统一的代码库才是可读的。
我花了一周设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后又花了一周，用智能体重构了整个代码库。
CREAO 是一个智能体平台。我们用自己的智能体重建了这个运行智能体的平台。如果产品能构建自身，它就是能用的。
技术栈
这是我们的技术栈，以及每个部分的作用。
基础设施：AWS
我们运行在 AWS 上，使用自动伸缩的容器服务和熔断回滚（Circuit-breaker Rollback）机制——部署后指标一旦恶化，系统自动回退。
CloudWatch 是中枢神经系统。所有服务的结构化日志，超过 25 个告警，自定义指标每天被自动化工作流查询。每一块基础设施都暴露结构化、可查询的信号。如果 AI 读不了日志，就诊断不了问题。
CI/CD：GitHub Actions
每次代码变更都要经过一条六阶段流水线：
验证 CI → 构建并部署 Dev → 测试 Dev → 部署 Prod → 测试 Prod → 发布
每个 PR 上的 CI 门禁强制执行类型检查、lint、单元和集成测试、Docker 构建、基于 Playwright 的端到端测试，以及环境一致性检查。没有哪个阶段可以跳过。没有人工覆盖。流水线是确定性的，所以智能体能预测结果并推理故障原因。
AI 代码审查：Claude
每个 PR 触发三路并行的 AI 审查，使用 Claude Opus 4.6：
第一路：代码质量。逻辑错误、性能问题、可维护性。
第二路：安全。漏洞扫描、认证边界检查、注入风险。
第三路：依赖扫描。供应链风险、版本冲突、许可证问题。
这些是审查门禁，不是建议。它们和人工审查并行运行，在规模化场景下抓住人类遗漏的问题。当你一天部署八次，没有哪个人类审查者能对每个 PR 保持注意力。
工程师也可以在任何 GitHub issue 或 PR 中 @claude，让它做实现方案、调试会话或代码分析。智能体能看到整个 monorepo。上下文在对话之间延续。
自愈反馈循环（Self-healing Feedback Loop）
这是核心。
每天早上 UTC 9:00，一个自动化健康检查工作流开始运行。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，生成一份高管级别的健康摘要，通过 Microsoft Teams 发送给团队。没人需要主动去问。
一小时后，分诊引擎（Triage Engine）启动。它从 CloudWatch 和 Sentry 中聚类生产环境错误，按九个严重性维度对每个聚类评分，并在 Linear 中自动创建调查工单。每张工单包含样本日志、受影响用户、受影响端点和建议的调查路径。
系统会去重。如果一个已打开的 issue 覆盖了相同的错误模式，它会更新那个 issue。如果一个之前已关闭的 issue 再次出现，它会检测到回归并重新打开。
当工程师推送了修复，同一条流水线接管。三路 Claude 审查评估 PR。CI 验证。六阶段部署流水线在 dev 和 prod 之间逐级推进，每个阶段都有测试。部署之后，分诊引擎重新检查 CloudWatch。如果原始错误已解决，Linear 工单自动关闭。
每个工具负责一个阶段。没有哪个工具试图包揽一切。每日循环形成一个自愈闭环——错误被检测、分诊、修复、验证，人工干预降到最低。
我跟 Business Insider 的一位记者说过：“AI 会提交 PR，人类只需要审查是否有风险。”
特性开关与配套工具链
Statsig（一个特性开关和 A/B 测试平台）管理特性开关（Feature Flag）。每个功能都在一个开关后面上线。发布模式：先对团队开放，然后逐步按百分比灰度，最后全量发布或直接砍掉。紧急关闭开关（Kill Switch）可以立即关闭一个功能，无需重新部署。如果某个功能导致指标恶化，我们几小时内就会把它撤掉。糟糕的特性上线当天就被砍掉。A/B 测试跑在同一套系统上。
Graphite（一款 PR 管理工具）管理 PR 分支：合并队列（Merge Queue）把 PR rebase 到 main，重新跑 CI，只有绿了才合并。堆叠 PR（Stacked PRs）支持在高吞吐下进行增量审查。
Sentry 报告所有服务的结构化异常，与 CloudWatch 的数据由分诊引擎合并，形成跨工具的上下文。Linear 是面向人的那一层：自动创建的工单带有严重性评分、样本日志和建议的调查方向。去重机制防止噪声。后续验证自动关闭已解决的 issue。
一个功能从想法到生产的旅程
新功能路径
- 架构师将任务定义为一个结构化 prompt，包含代码库上下文、目标和约束。
- 智能体分解任务、规划实现、编写代码、生成测试。
- PR 打开。三路 Claude 审查评估。人类审查者检查战略风险，而非逐行正确性。
- CI 验证：类型检查、lint、单元测试、集成测试、端到端测试。
- Graphite 的合并队列 rebase、重跑 CI、绿灯后合并。
- 六阶段部署流水线在 dev 和 prod 之间逐级推进，每个阶段都有测试。
- 特性开关对团队打开。逐步按百分比灰度。监控指标。
- 如有恶化，可用紧急关闭开关。严重问题触发熔断自动回滚。
Bug 修复路径
- CloudWatch 和 Sentry 检测到错误。
- Claude 分诊引擎评估严重性，在 Linear 创建工单，附带完整的调查上下文。
- 工程师介入调查。AI 已经完成了诊断。工程师验证并推送修复。
- 走同样的审查、CI、部署和监控流水线。
- 分诊引擎重新验证。如果已解决，工单自动关闭。
两条路径用同一套流水线。一套系统。一个标准。
成果
14 天内，我们平均每天 3 到 8 次生产部署。在旧模式下，同样的两周甚至连一次生产发布都完不成。
糟糕的功能上线当天就被砍。新功能从构思到上线在同一天完成。A/B 测试实时验证效果。
有人以为我们是在用质量换速度。实际上，用户参与度上升了。支付转化率上升了。我们的产出比以前更好，因为反馈循环更快了。每天发布比每月发布能学到更多东西。
新的工程组织
未来会存在两种工程师。
架构师（Architect）
一到两个人。他们设计标准操作规程（SOP），教 AI 如何工作。他们构建测试基础设施、集成系统、分诊系统。他们决定架构和系统边界。他们定义什么是”好的”——给智能体定标准。
这个角色需要深度的批判性思维。你批评 AI，而不是跟从它。当智能体提出一个方案，架构师找漏洞。它漏掉了什么失败模式？它越过了什么安全边界？它在积累什么技术债？
我有物理学博士学位。读博教给我最有用的东西，是如何质疑假设、压力测试论证、寻找缺失项。批判 AI 的能力，将比写代码的能力更有价值。
这也是最难招到的角色。
操作者（Operator）
其他所有人。工作仍然重要。只是结构不同了。
AI 给人类分配任务。分诊系统发现一个 bug，创建工单，呈现诊断结果，分配给合适的人。人去调查、验证、批准修复。AI 提交 PR。人审查是否有风险。
这些任务包括 bug 调查、UI 打磨、CSS 改进、PR 审查、验证。它们需要技能和专注。但不需要旧模式下那种架构级的推理能力。
谁适应得最快
我注意到一个出乎意料的规律。初级工程师比资深工程师适应得更快。
传统实践经验较少的初级工程师感到如虎添翼。他们拥有了能放大自身影响力的工具，也不用卸下十年的惯性。
传统实践经验丰富的资深工程师反而最难适应。他们两个月的工作量，AI 一小时就能完成。辛苦打磨多年的看家本领，突然不那么稀缺了——这很难接受。
我不是在下判断。我在描述我观察到的现象。在这场转型中，适应力比积累的技能更重要。
人的那一面
管理消失了
两个月前，我 60% 的时间花在管人上。对齐优先级。开会。给反馈。辅导工程师。
现在：不到 10%。
传统的 CTO 模式说要赋能团队做架构工作，培训他们，授权。但如果系统只需要一两个架构师，我得自己先干。我从管理者变成了建设者。大多数时候我从早上 9 点写代码到凌晨 3 点。我设计系统的标准操作规程和架构。我维护 harness。
压力更大了。但我享受的是在建造，而不是在拉齐。
争吵少了，关系好了
我和联合创始人、工程师的关系比以前好了。
转型之前，我和团队的大部分互动是对齐会议。讨论取舍。辩论优先级。在技术决策上各执己见。这些对话在传统模式下是必要的。但也很磨人。
现在我仍然和团队交流。只是我们聊别的了。非工作话题。随意的闲聊。团建出游。我们相处得更好了，因为我们不再为那些系统能轻松搞定的工作争来争去。
不确定性是真实的
我不会假装所有人都开心。
当我不再每天找人聊时，一些团队成员感到不安。CTO 不找我说话了是什么意思？在这个新世界里我的价值是什么？这些担忧是合理的。
有些人花在争论 AI 能否取代自己的时间，比真正做工作的时间还多。转型期会制造焦虑。对此我没有一个漂亮的答案。
但我有一个原则：我们不会因为一个工程师引入了生产 bug 就开除他。我们改进审查流程。我们加强测试。我们加护栏（Guardrails）。对 AI 也一样。如果 AI 犯了错，我们构建更好的验证、更清晰的约束、更强的可观测性。
超越工程
我看到其他公司采用 AI 优先的工程模式，但把其他所有环节留在手工状态。
如果工程团队几小时就能交付功能，而市场团队需要一周才能发布公告，市场就是瓶颈。如果产品团队还在跑月度规划周期，规划就是瓶颈。
在 CREAO，我们把 AI 原生运营推进到了每一个职能：
- 产品发布说明：AI 根据 changelog 和功能描述自动生成。
- 功能介绍视频：AI 生成的动态图形。
- 每日社交媒体帖子：AI 编排并自动发布。
- 健康报告和分析摘要：AI 从 CloudWatch 和生产数据库生成。
工程、产品、市场、增长——跑在同一套 AI 原生工作流上。如果一个职能以智能体速度运行，另一个以人类速度运行，人类速度的那个就会拖住一切。
这意味着什么
对工程师
你的价值正在从代码产出转向决策质量。快速写代码的能力每个月都在贬值。评估、批判和指导 AI 的能力每个月都在升值。
产品感觉——或者说品味——变得重要了。你能不能在用户发现之前，看一眼生成的 UI 就知道它不对？你能不能看一个架构方案，就看到智能体遗漏的失败模式？
我跟我们 19 岁的实习生说：训练批判性思维。学会评估论证、发现漏洞、质疑假设。学会什么是好的设计。这些技能会复利增长。
对 CTO 和创始人
如果你的 PM 流程比构建时间还长，从那里开始。
在扩展智能体之前，先建好测试 harness。快速的 AI 加上缓慢的验证，就是快速增长的技术债。
从一个架构师开始。一个人构建系统并证明它能跑通。系统运行起来之后，再让其他人以操作者角色加入。
把 AI 原生推进到每一个职能。
阻力在所难免。有人一定会反对。
对行业
OpenAI、Anthropic 以及多个独立团队，在相同的原则上汇合了：结构化上下文、专用智能体、持久记忆和执行循环。Harness 工程正在成为标准。
模型能力是驱动这一切的时钟。我把 CREAO 的整个转变归因于最近两个月。Opus 4.5 做不到 Opus 4.6 能做的事。下一代模型会进一步加速。
我相信一人公司会变得普遍。如果一个架构师加上智能体能做 100 个人的工作量，很多公司不需要第二个员工。
我们还很早期
我接触的大多数创始人和工程师仍然在用传统方式运作。一些人在考虑转型。真正做了的极少。
一位记者朋友告诉我，她在这个话题上采访了大约五个人。她说我们比所有人都走得更远：“我觉得没有人像你们这样彻底重建了整个工作流。”
工具就在那里，任何团队都可以做到。我们的技术栈没有任何专有成分。
竞争优势在于那个决定——围绕这些工具重新设计一切的决定，以及愿意承受代价的意愿。代价实实在在：员工的不确定感，CTO 每天工作 18 小时，资深工程师质疑自身价值，以及两周的空窗期——旧系统已经拆了，新系统还没被证明。
我们承受了这个代价。两个月后，数据自己会说话。
我们做的是智能体平台。而这个平台，就是用智能体建出来的。