内容
我们 99% 的生产代码都由 AI 编写。上周二，我们在上午 10 点发布了一个新功能，中午前完成了 A/B 测试，并在下午 3 点因为数据表现不佳将其下线。下午 5 点，我们发布了一个更好的版本。三个月前，这样一个周期还需要六周时间。
我们之所以能走到今天，并不是因为在 IDE 里加了 Copilot。我们拆解了整个工程流程，并围绕 AI 重新搭建。我们改变了规划、构建、测试、部署以及团队组织的方式。我们改变了公司里每个人的角色。
CREAO 是一个智能体平台。公司有 25 名员工，其中 10 名工程师。我们从 2025 年 11 月开始构建智能体，两个月前，我从零开始重构了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月提出了一个概念，准确概括了我们一直在做的事。他们称之为 harness engineering（约束框架工程）：工程团队的主要工作不再是写代码，而是让智能体能够完成有价值的工作。当某个环节失败时，解决办法绝不是“再努力一点”。真正的问题是：缺失了什么能力，以及我们如何让这种能力对智能体而言清晰可见、可被约束执行？ 我们是自己得出这个结论的。只是当时还没有名字。
AI-First 并不等于使用 AI
大多数公司只是把 AI 硬接到现有流程上。工程师打开 Cursor。产品经理用 ChatGPT 起草需求文档。QA 尝试用 AI 生成测试。整个工作流并没有变化。效率提升 10% 到 20%。但结构上没有任何改变。
这只是 AI 辅助。
AI-first 意味着，你要围绕“AI 是主要构建者”这一前提，重新设计流程、架构和组织。你不再问“AI 怎样帮助工程师？”，而是开始问“我们怎样重构一切，让 AI 负责构建，而工程师负责方向与判断？”
两者的差别是乘数级的。
我看到很多团队自称 AI-first，却依然运行着同样的迭代周期、同样的 Jira 看板、同样的每周站会、同样的 QA 签核。他们只是把 AI 加进了环路，却没有重构这个环路。
一个常见版本就是人们所说的 vibe coding。打开 Cursor，不断提示直到某些东西跑起来，提交，然后重复。这可以产出原型。但生产系统必须稳定、可靠且安全。当 AI 写代码时，你需要一套能够保证这些属性的系统。系统要由你来构建。提示词是一次性的。
为什么我们必须改变
去年，我观察团队的工作方式时，发现了三个会拖垮我们的瓶颈。
产品管理瓶颈
我们的产品经理要花数周时间做调研、设计、撰写功能规格。几十年来，产品管理一直都是这样运作的。但智能体可以在两小时内实现一个功能。当构建时间从几个月压缩到几小时，长达数周的规划周期就成了新的约束。
花几个月思考一件事，然后花两小时把它做出来，这本身就不合理。
产品经理必须进化为具备产品思维的架构师，能够以迭代的速度工作；否则就得退出构建周期。设计必须通过“快速原型—上线—测试—迭代”的闭环来完成，而不是通过委员会式评审的规格文档。
QA 瓶颈
逻辑是一样的。智能体发布完一个功能后，我们的 QA 团队要花几天时间测试各种边界情况。构建时间：两小时。测试时间：三天。
我们用 AI 构建的测试平台替代了人工 QA，让它去测试 AI 编写的代码。验证速度必须和实现速度一致。否则，你只是把旧瓶颈往下游挪了十英尺，造出了一个新的瓶颈。
人员规模瓶颈
我们的竞争对手做着同等量级的工作，但人数是我们的 100 倍甚至更多。我们只有 25 个人。我们不可能靠招聘把人数补齐，只能靠重新设计系统来实现对等。
有三个系统必须全面引入 AI：产品如何设计、产品如何实现、产品如何测试。只要其中任何一个环节还是手工的，它就会卡住整条流水线。
大胆的决定：统一架构
我必须先修好代码库。
我们旧的架构分散在多个彼此独立的系统中。一次修改，可能需要同时动三到四个仓库。从人类工程师视角看，这还算可控；但从 AI 智能体视角看，这几乎是黑箱。智能体看不到全貌，无法推理跨服务的影响，也无法在本地运行集成测试。
我必须把所有代码统一进一个 monorepo（单体代码仓库）。原因之一就是：让 AI 能看见全部内容。
这正是 harness engineering 原则的实际应用。你把系统中越多内容拉进一种可供智能体检查、验证和修改的形式里，它所能撬动的杠杆就越大。碎片化的代码库对智能体来说是不可见的；统一后的代码库则是可读、可理解的。
我花了一周时间设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。接着又花了一周，借助智能体重构了整个代码库。
CREAO 是一个智能体平台。我们用自己的智能体去重建运行智能体的平台。如果产品能够构建自己，那它就真的可行。
技术栈
下面是我们的技术栈，以及每个部分的作用。
| 组件 | 用途 |
|---|---|
| 基础设施 | AWS |
| CI/CD | GitHub Actions |
| AI 代码审查 | Claude |
| Feature Flag（功能开关） | Statsig |
| PR 分支管理 | Graphite |
| 错误追踪 | Sentry |
| 问题跟踪 | Linear |
基础设施：AWS
我们运行在 AWS 上，使用自动扩缩容的容器服务和熔断式回滚机制。如果部署后指标恶化，系统会自动回退。
CloudWatch 是整个系统的中枢神经。所有服务都使用结构化日志；配置了 25 个以上告警；还有由自动化工作流每天查询的自定义指标。每一块基础设施都会暴露结构化、可查询的信号。如果 AI 看不懂日志，它就无法诊断问题。
CI/CD：GitHub Actions
每一次代码变更都必须经过一个六阶段流水线：
- 验证 CI
- 构建并部署到开发环境
- 测试开发环境
- 部署到生产环境
- 测试生产环境
- 发布
每个 Pull Request 的 CI 门禁都会强制执行类型检查、Lint、单元测试、集成测试、Docker 构建、通过 Playwright 进行的端到端测试，以及环境一致性检查。没有任何阶段是可选的。没有人工绕过。整个流水线是确定性的，因此智能体可以预测结果，并对失败原因进行推理。
AI 代码审查：Claude
每个 Pull Request 都会触发三轮并行的 AI 审查，使用的是 Claude Opus 4.6：
- 第一轮：代码质量。检查逻辑错误、性能问题、可维护性。
- 第二轮：安全性。检查漏洞、认证边界、注入风险。
- 第三轮：依赖扫描。检查供应链风险、版本冲突、许可证问题。
这些是审查门禁，不是建议。它们与人工审查并行执行，能够在高吞吐场景下捕捉人类容易遗漏的问题。当你一天部署八次时，没有任何人工审查者能在每个 PR 上始终保持足够的注意力。
工程师也会在任何 GitHub issue 或 PR 中 @ @claude，让它参与实现方案、调试过程或代码分析。智能体能看到整个 monorepo。上下文可以跨对话延续。
自愈式反馈闭环
这是整个系统的核心。
每天上午 9:00（UTC），一个自动化健康检查工作流会启动。Claude Sonnet 4.6 会查询 CloudWatch，分析所有服务中的错误模式，并生成一份高层健康摘要，通过 Microsoft Teams 发送给团队。没有人需要先提出请求。
一小时后，分诊引擎开始运行。它会聚合 CloudWatch 和 Sentry 中的生产错误，按九个严重性维度为每个错误簇打分，并在 Linear 中自动生成调查工单。每个工单都包含示例日志、受影响用户、受影响端点，以及建议的排查路径。
系统会自动去重。如果某个已打开问题已经覆盖相同的错误模式，它就更新那个问题；如果某个之前已关闭的问题再次出现，它会识别为回归并重新打开。
当工程师提交修复后，同一条流水线会处理后续流程。三轮 Claude 审查会评估 PR。CI 负责验证。六阶段部署流水线会依次推进开发环境和生产环境，并在每个阶段进行测试。部署完成后，分诊引擎会再次检查 CloudWatch。如果原始错误已经解决，Linear 工单就会自动关闭。
每个工具只负责一个阶段。没有任何工具试图包打天下。这个每日循环构成了一个自愈闭环：错误被发现、分诊、修复、验证，而人工干预被压到最低。
Feature Flags 与配套技术栈
Statsig 负责功能开关。每个功能都在开关保护下发布。发布模式是：先对团队开放，然后按比例逐步放量，最后要么全量发布，要么下线。Kill switch（熔断开关）可以即时关闭功能，无需重新部署。如果一个功能导致指标变差，我们会在几小时内把它撤下。糟糕的功能会在发布当天死掉。A/B 测试也通过同一套系统进行。
Graphite 管理 PR 分支：合并队列会先 rebase 到主分支，再重新跑 CI，只有全部通过才会合并。堆叠式 PR 让我们能够在高吞吐下做增量审查。
Sentry 负责汇报所有服务中的结构化异常，随后由分诊引擎与 CloudWatch 的数据合并，形成跨工具的上下文。Linear 是面向人的这一层：自动创建的工单带有严重性评分、示例日志和建议调查路径。去重机制防止噪声泛滥。后续验证会自动关闭已解决的问题。
一个功能如何从想法走到生产环境
新功能路径
- 架构师将任务定义为一个结构化提示，包含代码库上下文、目标和约束。
- 智能体拆解任务，规划实现方案，编写代码，并生成自己的测试。
- 系统创建一个 PR。三轮 Claude 审查对其进行评估。人工审查者关注的是战略风险，而不是逐行检查正确性。
- CI 执行验证：类型检查、Lint、单元测试、集成测试、端到端测试。
- Graphite 的合并队列执行 rebase，重新跑 CI，全部通过后才合并。
- 六阶段部署流水线依次推进开发环境和生产环境，并在每个阶段执行测试。
- 功能开关先向团队开启。然后逐步按比例放量。持续监控指标。
- 如果任何指标恶化，可以立即触发 Kill switch。严重问题则由熔断机制自动回滚。
缺陷修复路径
- CloudWatch 和 Sentry 检测到错误。
- Claude 分诊引擎评估严重性，并在 Linear 中创建一个带完整调查上下文的问题。
- 工程师介入调查。AI 已经完成了初步诊断。工程师负责验证并提交修复。
- 后续仍然走同样的审查、CI、部署和监控流水线。
- 分诊引擎重新验证。如果问题已解决，工单会自动关闭。
两条路径共用同一条流水线。一个系统。一套标准。
成果
在 14 天内，我们平均每天进行了 3 到 8 次生产环境部署。按我们过去的模式，整整这两周，甚至都不足以产生一次生产发布。
糟糕的功能会在发布当天被撤回。新功能会在构思当天上线。A/B 测试实时验证效果。
很多人以为我们是在用质量换速度。实际情况是，用户参与度提高了，付费转化也提高了。我们的结果比以前更好，因为反馈闭环更紧密。你每天发布时学到的东西，远比每月发布一次多得多。
新的工程组织
未来会存在两类工程师。
架构师
一到两个人。他们设计标准作业流程（SOP），教会 AI 如何工作。他们构建测试基础设施、集成系统和分诊系统。他们决定架构与系统边界。他们定义智能体眼中的“好”到底是什么。
这个角色需要很强的批判性思维。你要批判 AI，而不是跟着它走。当智能体提出一个方案时，架构师要找出其中的漏洞。它遗漏了哪些失效模式？它跨越了哪些安全边界？它正在积累哪些技术债？
我拥有物理学博士学位。我的博士训练中最有价值的一点，是学会了如何质疑假设、对论证进行压力测试，以及发现缺失之处。未来，批判 AI 的能力会比产出代码的能力更有价值。
这也是最难招到人的角色。
操作员
其他所有人。他们的工作依然重要，只是结构不同了。
AI 会把任务分配给人。分诊系统发现一个 bug，创建工单，给出诊断，并分配给合适的人。这个人负责调查、验证并批准修复。PR 由 AI 发起。人类只需审核其中是否存在风险。
这类任务包括：问题调查、UI 打磨、CSS 优化、PR 审查、结果验证。它们需要技能与专注，但不再需要旧模式下那种高强度的架构推理能力。
谁适应得最快
我发现了一个出乎意料的模式：初级工程师比高级工程师适应得更快。
那些传统训练较少的初级工程师，反而更有被赋能的感觉。他们拿到了可以放大自身影响力的工具，也不需要先抛掉十年的工作习惯。
那些传统能力非常强的高级工程师，反而最难适应。他们两个月的工作量，AI 一小时就能完成。对于一个花了多年才建立起稀缺技能体系的人来说，这很难接受。
我不是在做价值判断。我只是在描述我观察到的现象。在这场转型中，适应能力比积累起来的技能更重要。
人的层面
管理职能塌缩了
两个月前，我 60% 的时间都花在管理人上。对齐优先级、开会、给反馈、辅导工程师。
而今天：不到 10%。
传统 CTO 模式强调，要赋能团队承担架构工作、训练他们、进行授权。但如果整个系统只需要一到两位架构师，那我必须先自己把这件事做好。我从“管理”转向“亲自构建”。大多数时候，我从早上 9 点一直写到凌晨 3 点。我设计系统的 SOP 和架构。我维护这套 harness（约束框架）。
压力更大了。但相比“做对齐”，我更享受“做构建”。
少了争论，关系反而更好了
我和联合创始人、工程师之间的关系，比以前更好了。
在转型之前，我与团队的大多数互动，都是各种对齐会议。讨论权衡、争论优先级、在技术决策上产生分歧。这些对话在传统模式里是必要的，但也非常消耗人。
现在我依然会和团队交流，只是我们聊的是别的事情。非工作的内容。轻松的闲聊。线下活动。我们相处得更好了，因为那些原本会围绕工作展开的争论，如今大多可以由系统轻松完成。
不确定性是真实存在的
我不会假装每个人都很开心。
当我不再每天和大家说话时，一些团队成员会感到不安。CTO 不再来找我，这意味着什么？在这个新世界里，我的价值是什么？这些担忧都很合理。
有些人花了更多时间去争论 AI 是否能取代他们的工作，而不是去完成工作本身。转型期会带来焦虑。对此，我没有一个干净利落的答案。
但我有一个原则：我们不会因为某位工程师引入了一个生产事故就把他开掉。我们会改进审查流程，强化测试，增加护栏。同样的原则也适用于 AI。如果 AI 犯错，我们就构建更好的验证机制、更明确的约束、更强的可观测性。
不止是工程
我看到一些公司采用了 AI-first 的工程方式，但其他一切仍然是手工流程。
如果工程团队能在几小时内发布功能，而市场团队却要花一周时间才能对外宣布，那市场就是瓶颈。如果产品团队仍然按月做规划，那规划就是瓶颈。
在 CREAO，我们把 AI-native（AI 原生）运营推进到了每一个职能中：
- 产品发布说明：基于变更日志和功能描述由 AI 自动生成。
- 功能介绍视频：由 AI 生成动态视觉内容。
- 每日社交媒体内容：由 AI 统一编排并自动发布。
- 健康报告和分析摘要：由 AI 基于 CloudWatch 和生产数据库生成。
工程、产品、市场和增长，运行在同一条 AI 原生工作流中。如果一个职能按智能体速度运转，而另一个职能仍按人类速度运转，那么后者就会限制一切。
这意味着什么
对工程师而言
你的价值正在从“代码产出”转向“决策质量”。快速写代码的能力，每个月都在贬值。评估、批判并引导 AI 的能力，则越来越值钱。
产品感或审美变得很重要。你能不能看一眼 AI 生成的 UI，就在用户反馈之前判断出它不对？你能不能看一份架构方案，就发现智能体遗漏的失效模式？
我会告诉我们 19 岁的实习生：训练批判性思维。学会评估论证、发现漏洞、质疑假设。培养对优秀设计的判断力。这些能力会持续复利。
对 CTO 和创业者而言
如果你的 PM 流程比构建时间还长，就先从那里下手。
在扩大智能体规模之前，先把测试 harness（测试约束框架）搭好。只有快速 AI、没有快速验证，就等于在快速积累技术债。
先从一个架构师开始。一个能够搭建系统并证明其有效的人。等系统跑起来之后，再把其他人纳入操作员角色。
把 AI 原生能力推入每一个职能。
也要预期阻力。有些人一定会反对。
对整个行业而言
OpenAI、Anthropic，以及多个独立团队，都不约而同走向了同样的原则：结构化上下文、专用智能体、持久记忆，以及执行闭环。Harness engineering 正在成为一种标准。
模型能力是推动这一切的时钟。在 CREAO，我把整个转变都归因于过去两个月的模型进步。Opus 4.5 做不到 Opus 4.6 能做到的事。下一代模型会进一步加速这一进程。
我相信“一人公司”会变得普遍。如果一个架构师加上一群智能体，就能完成 100 个人的工作，那么很多公司将不再需要第二名员工。
我们还处在早期
我接触的大多数创始人和工程师，仍然沿用传统方式工作。有些人开始思考是否要转型，但真正动手做的人非常少。
一位做记者的朋友告诉我，她围绕这个话题大概采访过五个人。她说我们走得比任何人都更远：“我觉得还没有谁像你们这样，把整个工作流彻底重建了一遍。”
任何团队现在都具备做到这一点的工具。我们的技术栈里没有任何东西是专有的。
真正的竞争优势，在于你是否决定围绕这些工具重构一切，以及你是否愿意承担这个过程中的成本。这个成本是真实存在的：员工的不确定感、CTO 每天工作 18 小时、高级工程师开始怀疑自身价值、以及那两周里旧系统已经消失而新系统尚未被证明可行的真空期。
我们承担了这些成本。两个月后，数据已经说明了一切。
我们构建的是一个智能体平台。我们用智能体把它构建了出来。