我们 99% 的生产代码都是 AI 写的。上周二，我们早上 10 点上线了一个新功能，中午前就完成了 A/B 测试，下午 3 点因为数据不支持把它下线了。下午 5 点，我们又上线了一个更好的版本。三个月前，这样一个周期还要花六周。
我们并不是靠把 Copilot 装进 IDE 才走到今天的。我们是把整个工程流程拆掉，再围绕 AI 重新搭建了一遍。我们改变了规划、开发、测试、部署以及团队组织方式。我们也改变了公司里每一个人的角色。
CREAO 是一家 agent 平台公司。公司 25 个人，10 名工程师。我们从 2025 年 11 月开始构建 agents，而在两个月前，我又把整个产品架构和工程工作流从底层彻底重做了一遍。
OpenAI 在 2026 年 2 月提出了一个概念，恰好概括了我们一直在做的事。他们把它叫做 harness engineering：一个工程团队最核心的工作，不再是写代码，而是让 agents 能真正完成有价值的工作。当某件事失败时，修复方式绝不是“再努力一点”。真正的问题是：到底缺了什么能力？我们该如何把它变成 agent 能理解、能遵守、能被强制执行的东西？
我们是自己走到这个结论的。只是当时还没有这个名字。
AI First 并不等于会用 AI
大多数公司只是把 AI 贴到现有流程上。工程师打开 Cursor。PM 用 ChatGPT 写需求文档。QA 尝试用 AI 生成测试。整个工作流本身并没有变化。效率提升了 10% 到 20%。结构上什么都没变。
这叫 AI-assisted（AI 辅助）。
而 AI-first，意味着你要重新设计流程、架构和组织，前提是假设 AI 才是主要的构建者。你不再问“AI 能怎么帮助工程师？”，而是开始问：“我们该怎么重构一切，才能让 AI 来负责构建，而工程师负责方向与判断？”
两者的差距不是线性的，而是乘数级的。
我看到很多团队自称 AI-first，但仍然跑着同样的 sprint 节奏、同样的 Jira 看板、同样的每周 standup、同样的 QA 签字流程。他们只是把 AI 加进了环路，却没有重新设计这个环路。
一个常见版本，就是人们所谓的 vibe coding：打开 Cursor，不断 prompt，直到某个东西看起来能跑，提交，然后重复。这样可以做出原型。但生产系统需要稳定、可靠、安全。你需要的是一整套系统，能在 AI 写代码时仍然保证这些属性。真正该构建的是系统本身，prompt 只是消耗品。
为什么我们非改不可
去年，我观察团队是怎么工作的，然后看到了三个迟早会拖死我们的瓶颈。
产品管理瓶颈
我们的 PM 要花数周去调研、设计、写功能规格。几十年来，产品管理一直是这么运作的。但现在 agents 两小时就能实现一个功能。当构建时间从几个月塌缩到几小时，长达数周的规划周期本身就变成了瓶颈。
你不可能一件事想几个月，然后两小时把它做完，这完全不合理。
PM 必须进化成有产品判断力的架构师，以迭代的速度工作；否则就该退出构建环节。设计不该再通过委员会式审阅的规格文档完成，而应该通过“快速原型—上线—测试—迭代”的闭环推进。
QA 瓶颈
逻辑是一样的。一个 agent 刚交付完功能，我们的 QA 团队还要花几天去测边角场景。开发时间：两小时。测试时间：三天。
于是我们用 AI 搭建的测试平台去测试 AI 写出来的代码。验证速度必须和实现速度一致。否则，你只是把旧瓶颈往下游平移了十英尺而已。
人头瓶颈
我们的竞争对手做的是差不多的事，但人数往往是我们的 100 倍甚至更多。我们只有 25 个人。我们不可能靠招人追平，只能靠重构系统追平。
有三个系统必须让 AI 真正贯穿其中：产品设计、产品实现、产品测试。只要其中任何一个环节还停留在人工模式，它就会卡死整个流水线。
一个大胆的决定：统一架构
我得先修代码库。
我们旧的架构散落在多个彼此独立的系统里。一个改动，可能要改三四个仓库。对人类工程师来说，这还算可控；但对 AI agent 来说，这就是不透明。它看不到全局，无法推理跨服务影响，也没法在本地跑完整的集成测试。
所以我必须把所有代码统一进一个 monorepo。原因之一很直接：这样 AI 才能看见全部。
这就是 harness engineering 在实践中的样子。你把系统中越多的部分拉进 agent 可检查、可验证、可修改的形式里，你获得的杠杆就越大。碎片化代码库对 agents 来说是不可见的；统一之后，系统才变得可读。
我先花了一周设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。接着又花了一周，借助 agents 把整个代码库重构了一遍。
CREAO 本身就是一个 agent 平台。我们用自己的 agents 去重建这个运行 agents 的平台。如果一个产品连自己都构建不了，那它就不算真的有效。
我们的技术栈
下面是我们的技术栈，以及每一部分在做什么。
基础设施：AWS
我们运行在 AWS 上，使用自动扩缩容的容器服务，并配有 circuit-breaker 回滚机制。如果部署后指标恶化，系统会自动回退。
CloudWatch 是整个系统的中枢神经。所有服务都输出结构化日志；配置了 25 个以上告警；自动化工作流每天查询自定义指标。基础设施中的每一个部分都必须暴露结构化、可查询的信号。AI 如果读不懂日志，就不可能诊断问题。
CI/CD：GitHub Actions
每一次代码变更都要经过一个六阶段流水线：
Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release
每个 PR 上的 CI 闸门都会强制执行类型检查、lint、单元测试、集成测试、Docker 构建、通过 Playwright 跑的端到端测试，以及环境一致性检查。没有任何阶段是可选的，也没有人工特批。整个流水线是确定性的，因此 agents 可以预测结果，也能对失败进行推理。
AI 代码评审：Claude
每个 PR 都会触发三条并行的 Claude Opus 4.6 评审链路：
Pass 1：代码质量。检查逻辑错误、性能问题、可维护性。
Pass 2：安全性。扫描漏洞、检查认证边界、识别注入风险。
Pass 3：依赖扫描。检查供应链风险、版本冲突、许可证问题。
这些不是“建议”，而是真正的评审闸门。它们和人工评审并行运行，以规模化方式捕捉人类会漏掉的问题。当你一天部署八次时，没有任何一个人工 reviewer 能在每一个 PR 上都保持同样的注意力。
工程师也会在任何 GitHub issue 或 PR 里直接 @claude，请它给出实现方案、参与调试或做代码分析。agent 能看到整个 monorepo，上下文也可以跨对话延续。
自愈式反馈闭环
这是整个系统的核心。
每天 UTC 时间早上 9 点，一个自动健康检查工作流会运行。Claude Sonnet 4.6 会查询 CloudWatch，分析所有服务中的错误模式，然后生成一份高管级健康摘要，通过 Microsoft Teams 发给团队。没有人需要先开口提问。
一小时后，分诊引擎启动。它会从 CloudWatch 和 Sentry 聚类线上错误，对每个错误簇按九个严重性维度打分，并在 Linear 里自动生成调查工单。每个工单都附带示例日志、受影响用户、受影响接口以及推荐的排查路径。
系统还会自动去重。如果某个错误模式已经有未关闭的 issue，它就更新原 issue；如果一个已经关闭的问题再次出现，它会识别回归并重新打开。
当工程师推送修复后，同一条流水线会继续处理。三个 Claude 评审通道先审 PR，CI 再验证，然后六阶段部署流水线依次推进 dev 和 prod，并在每个阶段都测试。部署完成后，分诊引擎会再次检查 CloudWatch。如果原始错误已经消失，对应的 Linear ticket 就会自动关闭。
每个工具只负责一个阶段，没有任何工具试图包办一切。这样一来，日常循环就形成了一个自愈闭环：错误被发现、被分诊、被修复、被验证，而人工介入被压到最低。
我曾对 Business Insider 的记者说过一句话：“AI 会去创建 PR，人类只需要审查其中是否存在风险。”
Feature Flags 与配套系统
Statsig 负责 feature flags。每一个功能都会在开关后面发布。典型 rollout 模式是：先给团队内部打开，再逐步按比例放量，最后要么全面发布，要么直接砍掉。kill switch 可以瞬间关闭功能，无需重新部署。如果某个功能把指标拉坏了，我们几个小时内就会撤掉。糟糕的功能会在上线当天就被终止。A/B 测试也跑在同一个系统里。
Graphite 负责 PR 分支管理：merge queue 会先把分支 rebase 到 main，再重新跑一遍 CI，只有全绿才允许合并。stacked PR 让高吞吐场景下的增量评审成为可能。
Sentry 负责汇报所有服务中的结构化异常；分诊引擎会把它和 CloudWatch 合并，形成跨工具上下文。Linear 是面向人的一层：自动创建的 ticket 附带严重性评分、示例日志和建议调查路径。去重可以抑制噪音，而后续验证则能自动关闭已解决问题。
一个功能如何从想法进入生产
新功能路径
- 架构师把任务定义成结构化 prompt，其中包含代码库上下文、目标和约束。
- 一个 agent 拆解任务、规划实现、写代码，并生成自己的测试。
- 系统开启 PR。三条 Claude 评审链路进行审核。人工 reviewer 检查的是战略层面的风险，而不是逐行检查正确性。
- CI 验证：类型检查、lint、单元测试、集成测试、端到端测试。
- Graphite 的 merge queue 负责 rebase、重跑 CI，绿灯才合并。
- 六阶段部署流水线依次推进 dev 和 prod，并在每个阶段都做测试。
- feature gate 先对团队打开，再逐步按比例放量，并持续监控指标。
- 如果任何指标变差，就可以立刻触发 kill switch；更严重时则由 circuit-breaker 自动回滚。
Bug 修复路径
- CloudWatch 和 Sentry 发现错误。
- Claude 分诊引擎为严重性打分，并在 Linear 创建附带完整调查上下文的 issue。
- 工程师开始排查。AI 已经完成初步诊断，人类要做的是验证并推送修复。
- 然后走同样的评审、CI、部署和监控流水线。
- 分诊引擎再次验证，如果问题已解决，ticket 自动关闭。
两条路径共用同一条流水线。一个系统，一个标准。
结果
在 14 天里，我们平均每天向生产环境部署 3 到 8 次。按照我们旧的模式，整整两周甚至还不够产出一次正式上线。
糟糕的功能会在上线当天被撤掉。新的功能会在被想到的当天进入线上。A/B 测试能实时验证影响。
很多人以为我们是在拿质量换速度。事实恰恰相反：用户参与度提高了，付费转化提高了。我们的结果比以前更好，因为反馈回路更紧。你按日发布时学到的东西，远远多于按月发布。
新的工程组织
未来只会剩下两类工程师。
架构师（The Architect）
只需要一两个人。他们负责设计标准操作流程，让 AI 学会如何工作；他们负责搭建测试基础设施、集成系统和分诊系统；他们决定架构和系统边界；他们定义 agents 的“好”到底意味着什么。
这个角色需要极强的批判性思维。你要批评 AI，而不是跟随它。agent 提出方案时，架构师要能看出漏洞：它漏掉了哪些 failure mode？跨越了哪些安全边界？积累了哪些技术债？
我有一个物理学博士学位。博士训练里最有价值的一件事，并不是学到某个专业知识，而是学会质疑假设、压力测试论证、寻找遗漏。未来，批判 AI 的能力，会比产出代码的能力更值钱。
这也是最难招到人的角色。
操作员（The Operator）
其他所有人都归于这一类。工作依然重要，只是结构变了。
AI 会把任务分配给人类。分诊系统发现 bug、创建 ticket、给出诊断并分配给合适的人。人去调查、验证并批准修复。AI 发起 PR，人类只审查其中是否存在风险。
这类任务包括：bug 调查、UI 微调、CSS 改进、PR 审查、验证。这些工作依然需要技能和专注力，但不再要求旧模式下那种架构级推理能力。
谁适应得最快
我观察到了一个出乎意料的模式：初级工程师适应得比资深工程师更快。
传统训练较少的初级工程师，反而更容易获得“被放大”的感觉。他们手里多了能放大影响力的工具，也没有十年的习惯包袱需要先被卸掉。
而传统功底很强的资深工程师，适应起来最困难。过去他们两个月的工作，如今 AI 一小时就能做完。对一个靠稀缺技能积累多年的人来说，这非常难接受。
我不是在做价值评判，我只是在描述我看到的事实。在这场转变中，适应力比积累多年的技能更重要。
人的一面
管理工作塌缩了
两个月前，我 60% 的时间都花在管理人：对齐优先级、开会、给反馈、辅导工程师。
现在？低于 10%。
传统 CTO 模式会告诉你，要授权团队做架构工作、训练他们、再把事情委派下去。但如果整个系统最终只需要一两个架构师，那我就必须先亲自把这件事做起来。我从“管理”重新回到了“构建”。大多数时候，我每天从早上 9 点一直写到凌晨 3 点。我在设计整个系统的 SOP 和架构，也在维护这套 harness。
压力更大了。但我更享受构建，而不是对齐。
争论变少了，关系反而更好了
我和联合创始人、工程师之间的关系，比以前更好了。
转型前，我和团队之间的大多数互动，都是各种对齐会议：讨论权衡、争论优先级、在技术决策上意见不合。这些在传统模式里当然必要，但也极度消耗人。
现在我依然会和团队交流，只是我们聊的更多是别的事情：工作之外的话题、轻松的日常、线下出行。我们相处得更好了，因为我们不再围绕那些已经可以被系统轻松完成的工作不停争执。
真实的不确定性
我不会假装每个人都很开心。
当我不再每天都跟大家说很多话时，有些团队成员会感到不安：CTO 不再主动找我，这意味着什么？在这个新世界里，我的价值是什么？这些担心完全合理。
也有人花更多时间在争论 AI 是否会取代自己的工作，而不是去做工作本身。转型期确实会制造焦虑。我没有一个漂亮而完整的答案。
但我有一个原则：我们不会因为某位工程师引入了线上 bug 就开除他。我们会去改进 review 流程、强化测试、增加 guardrails。对 AI 也是一样。如果 AI 犯错，我们就去构建更好的验证机制、更清晰的约束和更强的可观测性。
不只是工程
我看到很多公司在工程侧推行 AI-first，但其他部门依然完全停留在手工模式。
如果工程几小时就能发布功能，但市场团队要花一周才能对外宣布，那市场就是瓶颈。如果产品团队还在跑每月一次的规划节奏，那规划就是瓶颈。
在 CREAO，我们把 AI-native 的运营方式推进到了每一个职能：
- 产品发布说明：由 AI 根据 changelog 和功能描述自动生成。
- 功能介绍视频：由 AI 生成 motion graphics。
- 社交媒体日更：由 AI 编排并自动发布。
- 健康报告和分析摘要：由 AI 基于 CloudWatch 和生产数据库自动生成。
工程、产品、营销和增长，全都运行在同一套 AI-native 工作流中。只要有一个职能跑在 agent speed，另一个还停留在人类速度，那么这个“人类速度”的职能就会限制一切。
这意味着什么
对工程师来说
你的价值正在从“代码产量”转向“决策质量”。写代码快这件事，每个月都在变得更不值钱；而评估、批评和引导 AI 的能力，则越来越值钱。
产品感和审美会变得重要。你能否看到一个生成出来的 UI，就在用户开口前判断它是错的？你能否看到一个架构方案时，就立刻意识到 agent 漏掉了哪个 failure mode？
我会对我们 19 岁的实习生说：去训练批判性思维。学会评估论证、发现空白、质疑假设。学会辨认什么是好的设计。这些能力会不断复利。
对 CTO 和创始人来说
如果你的 PM 流程比构建时间还长，就先从那儿动刀。
在扩大 agent 规模之前，先把测试 harness 搭起来。快的 AI 如果没有同样快的验证，本质上只是高速积累技术债。
先从一个架构师开始。让一个人把整套系统搭起来，证明它能工作。等系统跑通后，再把其他人逐步纳入 operator 角色。
把 AI-native 推进到每一个职能里。
也要做好面对阻力的准备。总会有人反对。
对整个行业来说
OpenAI、Anthropic 以及多个独立团队，正在收敛到同一组原则：结构化上下文、专门化 agents、持久记忆以及执行闭环。Harness engineering 正在变成一种标准。
模型能力是推动这一切的时钟。我会把 CREAO 这次转变几乎全部归因于过去两个月的模型进步。Opus 4.5 做不到 Opus 4.6 能做到的事。下一代模型只会把这件事进一步加速。
我相信“一人公司”会变得越来越常见。如果一个架构师加上一组 agents 就能完成 100 个人的工作，那很多公司根本不需要第二个员工。
我们还很早
我接触的大多数创始人和工程师，依然还在按传统方式工作。有些人开始思考要不要转变，但真正做完这次转变的人，极少。
一位记者朋友告诉我，她就这个主题采访过大概五个人。她说我们走得比任何人都更远：“我不觉得有人像你们这样，把整套工作流彻底重建了一遍。”
任何团队都已经拥有做这件事所需的工具。我们的技术栈里，没有任何东西是专有的。
真正的竞争优势，在于你是否愿意围绕这些工具重新设计一切，也在于你是否愿意吞下这其中的成本。这个成本是真实存在的：员工的不确定感、CTO 连续 18 小时的工作强度、资深工程师对自身价值的怀疑、以及那两周里旧系统已经被拆掉、新系统却还没被证明有效的真空期。
这些成本，我们扛下来了。两个月后，数据已经自己说明了一切。
我们做的是一个 agent 平台。而我们就是用 agents 把它做出来的。