我们 99% 的生产代码是由 AI 写的。上周二，我们上午 10 点发布了一个新功能，中午做 A/B 测试，下午 3 点因为数据显示不行就砍掉了。下午 5 点我们上线了一个更好的版本。三个月前，这样的一个周期需要六周。
我们走到这一步，不是靠给 IDE 加个 Copilot。我们拆掉了整个工程流程，围绕 AI 重建。我们改变了计划、构建、测试、部署和团队组织的方式。我们改变了公司每个人的角色。
CREAO 是一个 Agent 平台。25 名员工，10 名工程师。我们从 2025 年 11 月开始构建 Agent，两个月前我从零开始重组了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月发表了一个概念，精准描述了我们一直在做的事。他们称之为工具链工程（harness engineering）：工程团队的主要工作不再是写代码。而是让 Agent 能够完成有用工作。当某件事失败时，解决方案从来不是”再努力试试”。解决方案是：缺少什么能力？我们如何让它对 Agent 可见且可执行？
我们是自己得出这个结论的。只是当时没有给它命名。
AI优先不等于使用 AI
大多数公司把 AI 螺栓接到现有流程上。工程师打开 Cursor。PM 用 ChatGPT 起草规格。QA 尝试用 AI 生成测试。工作流保持不变。效率提升 10% 到 20%。没有任何结构性改变。
那是 AI 辅助。
AI优先意味着你围绕 AI 作为主要构建者这一假设，重新设计你的流程、架构和组织。 你不再问”AI 如何帮助我们的工程师？“，而是开始问”我们如何重组一切，让 AI 做构建，工程师提供方向和判断？”
区别是乘数级的。
我看到团队声称 AI优先，却运行着相同的冲刺周期、相同的 Jira 看板、相同的周例会、相同的 QA 签核。他们把 AI 加入到了循环中。他们没有重新设计循环。
一个常见的版本是人们所说的 vibe coding。打开 Cursor，不断提示直到某个东西工作了，提交，重复。这能做出原型。生产系统需要稳定、可靠和安全。你需要一个能在 AI 写代码时保证这些属性的系统。你构建这个系统。提示词是一次性的。
为什么我们不得不改变
去年，我观察团队的工作方式，发现了三个会拖垮我们的瓶颈。
产品管理瓶颈
我们的 PM 花费数周进行研究、设计、撰写功能规格。产品管理几十年来都是这样工作的。但 Agent 可以在两小时内实现一个功能。当构建时间从数月压缩到数小时，数周的计划周期就成了制约因素。
花几个月思考然后用两小时构建，这不合理。
PM 需要进化为产品导向的架构师，以迭代的速度工作，或者退出构建循环。设计需要通过快速原型-发布-测试-迭代循环来完成，而不是委员会审查的规格文档。
QA 瓶颈
同样的动态。Agent 发布一个功能后，我们的 QA 团队花数天测试边界情况。构建时间：两小时。测试时间：三天。
我们用 AI 构建的测试平台替换了手动 QA，用 AI 写的代码来测试。验证必须与实现以相同的速度运行。否则你在旧瓶颈下游十英尺处又建了一个新瓶颈。
人力瓶颈
我们的竞争对手有 100 倍甚至更多的人员来做类似工作。我们只有 25 人。我们无法通过招聘来达到同等。我们必须通过重新设计来达到。
三个系统需要 AI 贯穿其中：我们如何设计产品、如何实现产品、如何测试产品。如果任何一个保持手动，它就会制约整个管道。
大胆的决定：统一架构
我不得不先修复代码库。
我们旧的架构分散在多个独立系统中。一个变更可能需要涉及三个或四个代码库。从人类工程师的角度来看，这可以管理。从 AI Agent 的角度来看，是不透明的。Agent 看不到全貌。它无法推理跨服务的影响。它无法在本地运行集成测试。
我不得不把所有代码统一到一个 monorepo 中。一个原因：让 AI 能够看到一切。
这是工具链工程原理的实践。你把系统越多地整合成 Agent 可以检查、验证和修改的形式，你就获得越大的杠杆。分散的代码库对 Agent 是不可见的。统一的就变得清晰可见。
我花了一周设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后又花了一周用 Agent 重新构建整个代码库。
CREAO 是一个 Agent 平台。我们用自己的 Agent 来重建运行 Agent 的平台。如果产品能构建自己，它就成功了。
技术栈
这是我们的技术栈及各部分的功能。
基础设施：AWS
我们在 AWS 上运行，使用自动扩展容器服务和断路器回滚。如果部署后指标下降，系统自动回滚。
CloudWatch 是中枢神经系统。所有服务的结构化日志，超过 25 个告警，由自动化工作流每日查询的自定义指标。每块基础设施都暴露结构化的、可查询的信号。如果 AI 无法读取日志，它就无法诊断问题。
CI/CD：GitHub Actions
每次代码变更都经过六阶段管道：
验证 CI → 构建并部署到 Dev → Dev 测试 → 部署到 Prod → Prod 测试 → 发布
每个 pull request 上的 CI 门禁强制执行类型检查、lint、单元和集成测试、Docker 构建、通过 Playwright 的端到端测试，以及环境一致性检查。没有阶段是可选的。没有手动覆盖。管道是确定性的，所以 Agent 可以预测结果并推理失败。
AI 代码审查：Claude
每个 pull request 触发三个并行的 AI 审查，使用 Claude Opus 4.6：
第一轮：代码质量。逻辑错误、性能问题、可维护性。
第二轮：安全。漏洞扫描、认证边界检查、注入风险。
第三轮：依赖扫描。供应链风险、版本冲突、许可问题。
这些是审查门禁，不是建议。它们与人工审查并行运行，捕获人工在量级上容易遗漏的东西。当你每天部署八次时，没有人工审查者能在每个 PR 上保持注意力。
工程师还可以在任何 GitHub issue 或 PR 中标注 @Claude，获取实现计划、调试会话或代码分析。Agent 可以看到整个 monorepo。上下文在对话间保持。
自愈反馈循环
这是核心。
每天 UTC 时间 9:00 AM，一个自动化健康工作流运行。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，生成一份高管健康摘要，通过 Microsoft Teams 发送给团队。没人需要主动去问。
一小时后，分诊引擎运行。它将 CloudWatch 和 Sentry 的生产错误聚类，在九个严重性维度上对每个聚类评分，并在 Linear 中自动生成调查工单。每个工单包含示例日志、受影响用户、受影响端点，以及建议的调查路径。
系统会去重。如果一个开放工单覆盖相同的错误模式，它会更新该工单。如果之前关闭的工单再次出现，它会检测到回归并重新打开。
当工程师推送修复时，相同管道处理它。三轮 Claude 审查评估 PR。CI 验证。六阶段部署管道通过 dev 和 prod 晋升，每个阶段都有测试。部署后，分诊引擎重新检查 CloudWatch。如果原始错误已解决，Linear 工单自动关闭。
每个工具处理一个阶段。没有工具试图做所有事情。每日循环创建一个自愈循环，错误被检测、分诊、修复，并以最少的人工干预验证。
我告诉 Business Insider 的记者：“AI 将制作 PR，人类只需要审查是否存在任何风险。”
功能开关和支持栈
Statsig 处理功能开关。每个功能都在门控后面发布。推广模式：先对团队启用，然后逐步百分比推广，然后全面发布或砍掉。杀死开关即时切换功能，无需部署。如果功能使指标下降，我们会在几小时内撤下。坏功能在发布当天就会死亡。A/B 测试通过相同系统运行。
Graphite 管理 PR 分支：合并队列 rebase 到 main，重新运行 CI，仅在绿色时合并。堆叠式 PR 允许高吞吐量的增量审查。
Sentry 在所有服务中报告结构化异常，由分诊引擎与 CloudWatch 合并以提供跨工具上下文。Linear 是面向人类的层：带有严重性评分、示例日志和建议调查的去重自动创建工单。后续验证自动关闭已解决的问题。
一个功能如何从想法到生产
新功能路径
- 架构师将任务定义为结构化提示词，包含代码库上下文、目标和约束。
- 一个 Agent 分解任务、规划实现、编写代码并生成自己的测试。
- 一个 PR 打开。三轮 Claude 审查评估它。一个人工审查者检查战略风险，而非逐行正确性。
- CI 验证：类型检查、lint、单元测试、集成测试、端到端测试。
- Graphite 的合并队列 rebase，重新运行 CI，绿色则合并。
- 六阶段部署管道通过 dev 和 prod 晋升，每个阶段都有测试。
- 功能门控对团队开启。逐步百分比推广。监控指标。
- 如有降级可使用杀死开关。严重问题自动断路器回滚。
Bug 修复路径
- CloudWatch 和 Sentry 检测到错误。
- Claude 分诊引擎评分严重性，在 Linear 中创建包含完整调查上下文的工单。
- 工程师调查。AI 已经做了诊断。工程师验证并推送修复。
- 相同的审查、CI、部署和监控管道。
- 分诊引擎重新验证。如果已解决，工单自动关闭。
两条路径使用相同管道。一个系统。一个标准。
结果
在 14 天里，我们平均每天进行三到八次生产部署。在我们的旧模式下，整个两周可能都无法产生一次生产发布。
坏功能在发布当天就被撤下。新功能在构思当天上线。A/B 测试实时验证效果。
人们以为我们在用质量换速度。用户参与度上升了。支付转化率上升了。我们生产出比以前更好的结果，因为反馈循环更紧密。当你每天发布时，你学到的东西比每月发布时多。
新的工程组织
将存在两种类型的工程师。
架构师
一到两人。他们设计标准操作程序，教 AI 如何工作。他们构建测试基础设施、集成系统、分诊系统。他们决定架构和系统边界。他们定义对 Agent 来说”好”是什么样的。
这个角色需要深度批判性思维。你批评 AI。你不跟随它。当 Agent 提出一个计划时，架构师找出漏洞。它忽略了什么失败模式？它跨越了哪些安全边界？它正在积累什么技术债务？
我有物理学的 PhD。PhD 教给我最有用的东西是如何质疑假设、压力测试论证、寻找缺失的东西。批评 AI 的能力将比产生代码的能力更有价值。
这也是最难填补的角色。
操作员
其他所有人。工作很重要。结构不同。
AI 给人类分配任务。分诊系统找到 bug，创建工单，表面化诊断，并分配给正确的人。人调查、验证并批准修复。AI 制作 PR。人类审查是否存在风险。
任务是 bug 调查、UI 优化、CSS 改进、PR 审查、验证。它们需要技能和注意力。它们不需要旧模式要求的架构推理能力。
谁适应得最快
我注意到一个我没有预料到的模式。初级工程师比高级工程师适应得更快。
实践经验较少的初级工程师感到被赋能。他们能够使用放大他们影响力的工具。他们没有几十年的习惯需要遗忘。
具有强传统实践的高级工程师处境最艰难。他们两个月的工作可以被 AI 在一小时内完成。在多年构建稀有技能集之后，这是很难接受的事情。
我不是在做判断。我只是在描述我观察到的。在这个转型中，适应能力比积累的技能更有价值。
人的一面
管理层崩溃了
两个月前，我 60% 的时间用于管理人。对齐优先级。开会。提供反馈。指导工程师。
今天：不到 10%。
传统的 CTO 模式说要授权你的团队做架构工作，培养他们，下放权力。但是如果系统只需要一两个架构师，我需要先自己做。我从管理变成了构建。我大多数日子从早上 9 点工作到凌晨 3 点。我设计系统的 SOP 和架构。我维护工具链。
压力更大。但我喜欢构建，而不是对齐。
更少的争论，更好的人际关系
我与联合创始人和工程师的关系比以前更好。
转型之前，我与团队的大部分互动是对齐会议。讨论权衡。辩论优先级。不同意技术决策。那些对话在传统模式下是必要的。也让人精疲力竭。
现在我仍然与团队交谈。我们谈论其他事情。非工作话题。随意对话。外出旅行。我们相处得更好，因为我们停止了对那些可以轻易被系统完成的工作的争论。
不确定性是真实的
我不会假装每个人都开心。
当我不再每天与人交谈时，一些团队成员感到不确定。CTO 不和我交谈意味着什么？我在这个新世界中的价值是什么？合理的担忧。
有些人花更多时间争论 AI 能否做他们的工作，而不是去做工作。过渡期产生了焦虑。我没有简单的答案。
我有一个原则：我们不会因为工程师引入了生产 bug 就开除他。我们改进审查流程。我们加强测试。我们添加护栏。这同样适用于 AI。如果 AI 犯了错误，我们构建更好的验证、更清晰的约束、更强的可观测性。
工程之外
我看到其他公司采用 AI优先工程，但把其他一切都保持手动。
如果工程在数小时发布功能而营销需要一周来宣布，营销就是瓶颈。如果产品团队仍然运行月度计划周期，计划就是瓶颈。
在 CREAO，我们将 AI 原生运营推入每个功能：
- 产品发布说明：从变更日志和功能描述由 AI 生成。
- 功能介绍视频：AI 生成的动态图形。
- 社交媒体每日帖子：AI 编排和自动发布。
- 健康报告和分析摘要：从 CloudWatch 和生产数据库由 AI 生成。
工程、产品、营销和增长运行在一个 AI 原生工作流中。如果一个功能以 Agent 速度运行而另一个以人类速度运行，人类速度的功能就会制约一切。
这意味着什么
对工程师
你的价值正从代码输出转向决策质量。快速写代码的能力每月都在贬值。评估、批评和引导 AI 的能力越来越有价值。
产品感觉或品味很重要。你能在用户告诉你之前，看一个生成的 UI 就知道它是错的吗？你能看一个架构提案，发现 Agent 忽略的失败模式吗？
我告诉我们 19 岁的实习生：训练批判性思维。学习评估论证、寻找差距、质疑假设。学习什么样的设计是好的。这些技能会复合。
对 CTO 和创始人
如果你的 PM 流程比构建时间长，从那里开始。
在扩展 Agent 之前构建测试工具链。没有快速验证的快速 AI 是快速移动的技术债务。
从一个架构师开始。一个构建系统并证明它工作的人。在系统运行后将其他人纳入操作员角色。
将 AI 原生推入每个功能。
预期阻力。有些人会反对。
对行业
OpenAI、Anthropic 和多个独立团队 converge 到相同的原则：结构化上下文、专业化 Agent、持久记忆和执行循环。工具链工程正在成为标准。
模型能力是驱动这个的时钟。我将 CREAO 的整个转变归因于过去两个月。Opus 4.5 做不了 Opus 4.6 做的事。下一代模型将加速它。
我相信一人公司会变得普遍。如果一个架构师带 Agent 就能做 100 个人的工作，很多公司就不会需要第二个员工。
我们还很早
大多数与我交谈的创始人和工程师仍然以传统方式运作。有些人考虑做这个转变。很少有人已经做到了。
一个记者朋友告诉我，她在这个话题上聊了大约五个人。她说我们比任何人都走得更远：“我不认为有人像你们一样完全重建了整个工作流。”
任何团队都可以使用这些工具来做这个。我们的技术栈没有任何专有东西。
竞争优势是围绕这些工具重新设计一切的决策，以及吸收成本的意愿。成本是真实的：员工的不确定性、CTO 每天工作 18 小时、高级工程师质疑自己的价值、两周的时期——旧系统没了，新系统还没被验证。
我们吸收了那个成本。两个月后，数字说话。
我们构建一个 Agent 平台。我们用 Agent 构建了它。