原文由 Peter Pang 发布。

Original: https://x.com/intuitiveml/status/2043545596699750791

引言

我们 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
• 产品经理用 ChatGPT 写需求文档
• QA 尝试用 AI 生成测试

但工作流程本身没有改变。效率提高了 10% 到 20%，但结构没有任何本质变化。

这只是 AI 辅助（AI-Assisted）。

AI-First 的意义在于：你要在“AI 是主要构建者”的前提下，重构流程、架构和组织。

你不再问：

AI 如何帮助工程师？

而是开始问：

我们如何重构一切，让 AI 来负责构建，而工程师提供方向和判断？

这种差别是倍数级的。

我看到很多团队声称自己是 AI-First，但依然在运行：

• 相同的 sprint 周期
• 相同的 Jira 看板
• 相同的每周站会
• 相同的 QA 签核

他们只是把 AI 加进了循环，却没有重构整个循环。

一个常见的形式是所谓的 vibe coding：

• 打开 Cursor
• 不断写 prompt 直到结果可用
• 提交代码
• 重复

这可以产出原型。但一个生产系统需要具备：

• 稳定性
• 可靠性
• 安全性

你需要建立一套系统，确保当 AI 编写代码时也能满足这些要求。

你构建的是系统，prompt 是一次性的。

为什么我们必须改变

去年，我观察团队的工作方式，发现了三个会拖垮我们的瓶颈。

1. 产品管理瓶颈

我们的产品经理需要花几周时间做调研、设计和需求定义。这种方式已经沿用了几十年。但 agent 可以在两个小时内实现一个功能。当构建时间从几个月缩短到几个小时，几周的规划周期反而成了限制。

花几个月思考，然后用两小时构建，这已经没有意义。

产品经理需要进化为具备产品思维的架构师，以迭代的速度工作，或者离开构建循环。设计需要通过快速的"原型-发布-测试-迭代"循环完成，而不是在评审委员会上审阅规格文档。

2. QA 瓶颈

同样的动态。agent 发布一个功能后，我们的 QA 团队花好几天测试边界情况。

• 构建时间：两小时
• 测试时间：三天

我们用 AI 构建的测试平台替换了手动 QA，用来测试 AI 写的代码。验证的速度必须跟上实现的速度。否则你只是在下游十英尺处新造了一个瓶颈。

3. 人员规模瓶颈

我们的竞争对手有 100 倍甚至更多的人力在做类似的工作。我们只有 25 人。我们无法靠招人追赶。我们必须靠重新设计来达到同等水平。

三个系统需要 AI 贯穿其中：如何设计产品、如何实现产品、如何测试产品。只要其中一个环节是手动的，它就会制约整个流水线。

大胆的决策：统一架构

我得先解决代码库的问题。

我们旧的架构分散在多个独立的系统中。一次改动可能需要涉及三四个仓库。从人类工程师的角度看，这还可以管理。但从 AI agent 的角度看，这是不透明的。agent 看不到全貌，无法推理跨服务的影响，无法在本地跑集成测试。

我必须把所有代码统一到单个 monorepo 里。原因只有一个：让 AI 能看见一切。

这是 Harness Engineering 原则的实践。你越是把系统的各部分拉到 agent 可以审查、验证和修改的形式中，你获得的杠杆就越大。碎片化的代码库对 agent 来说是隐形的。统一后的代码库是可读的。

我用一周设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后用另一周用 agent 重构了整个代码库。

CREAO 是一个 agent 平台。我们用自己的 agent 来重建运行 agent 的平台。如果产品能自己建造自己，它就真的管用。

技术栈

基础设施：AWS

我们运行 AWS 上的自动扩缩容器服务，带断路回滚机制。部署后如果指标恶化，系统自动回退。

CloudWatch 是中枢神经系统。所有服务的结构化日志、超过 25 个告警、每天由自动化工作流查询的自定义指标。每一块基础设施都暴露结构化、可查询的信号。如果 AI 读不了日志，它就诊断不了问题。

CI/CD：GitHub Actions

每次代码变更经过六阶段流水线：

Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release

每个 PR 的 CI 关卡强制执行类型检查、linting、单元和集成测试、Docker 构建、Playwright 端到端测试和环境一致性检查。没有阶段是可选的。没有手动绕过。流水线是可确定的，agent 可以预测结果并推理失败原因。

AI 代码评审：Claude

每条 PR 触发三轮并行的 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 中自动生成调查工单。每个工单包含示例日志、受影响用户、受影响端点和建议的调查路径。

系统会自动去重。如果已开的 issue 覆盖了相同的错误模式，它会更新该 issue。如果已关闭的 issue 复发，它会检测到回归并重新打开。

当工程师推送修复时，同一套流水线处理一切。三轮 Claude 评审评估 PR。CI 验证。六阶段部署流水线在 dev 和 prod 间推进，每阶段都有测试。部署完成后，分类引擎重新检查 CloudWatch。如果原始错误已解决，Linear 工单自动关闭。

每个工具只处理一个阶段。没有一个工具试图做所有事情。每日循环创造了一个自愈闭环：错误被检测、分类、修复和验证，只需要最少的人工干预。

我对 Business Insider 的记者说：“AI 会创建 PR，人类只需要评审是否存在风险”。

Feature Flags 与支撑栈

Statsig 管理 feature flag。每个功能在开关后面发布。发布模式：先开放给团队内部，然后逐步百分比开放，最后全面发布或下线。kill switch（紧急下线开关）可以立即关闭一个功能，无需重新部署。如果一个功能导致指标恶化，几小时内就能撤销。不好的功能在发布当天就死掉。A/B 测试通过同一套系统运行。

Graphite 管理 PR 分支：合并队列自动 rebase 到主分支，重新跑 CI，仅当所有检查通过时才合并。堆叠式 PR（stacked PRs）支持增量评审，在高吞吐场景下保持 review 质量。

Sentry 收集所有服务的结构化异常，由分类引擎与 CloudWatch 数据合并以实现跨工具上下文。Linear 是人类面对的一层：带有严重性评分、示例日志和建议调查方案的自动创建工单。去重防止噪音。跟进验证自动关闭已解决 issue。

一个功能从想法到上线

New Feature 路径：

• 架构师将任务定义为结构化提示词（附代码库上下文、目标和约束）
• agent 分解任务，规划实现，写代码并生成自己的测试
• 打开 PR。三轮 Claude 评审评估。人类评审者检查的是战略风险，不是逐行正确性
• CI 验证：类型检查、linting、单元测试、集成测试、端到端测试
• Graphite 的合并队列 rebase，重跑 CI，通过后合并
• 六阶段部署流水线在 dev 和 prod 间推进，每阶段有测试
• 功能开关先对团队开放。逐步百分比开放。监控指标
• 如有任何指标恶化，kill switch 可立即下线。严重问题用断路器自动回滚

Bug Fix 路径：

• CloudWatch 和 Sentry 检测到错误
• Claude 分类引擎打分严重性，创建包含完整调查上下文的 Linear issue
• 工程师调查。AI 已经做了诊断。工程师验证并推送修复
• 同样的评审、CI、部署和监控流水线
• 分类引擎重新验证。如果已解决，工单自动关闭

两条路径使用同一套流水线、一个系统、一个标准。

结果

14 天内，我们平均每天 3 到 8 次生产部署。在旧模式下，整个两周的时间连一次生产发布都做不到。

不好的功能在发布当天就被撤回。新功能在构思当天就上线。A/B 测试实时验证影响。

人们以为我们在用速度换质量。但用户参与度上升了。支付转化率上升了。我们产出的结果比以前更好，因为反馈环更紧密了。你每天发布学到的东西比每月发布多得多。

新的工程组织

将来只会存在两类工程师。

架构师 Architect

一到两个人。他们设计标准操作流程（SOP），教 AI 如何工作。他们构建测试基础设施、集成系统、分类系统。他们决定架构和系统边界。他们定义什么对 agent 来说是"好"的。

这个角色需要深度批判性思维。你批评 AI，而不是跟随 AI。当 agent 提出一个方案时，架构师找出漏洞。它遗漏了什么失败模式？它越过了什么安全边界？它在积累什么技术债？

我有物理学博士学位。读博对我最有用的训练是如何质疑假设、压力测试论点、寻找缺失的东西。批评 AI 的能力将比产生代码的能力更有价值。

这也是最难填补的岗位。

操作员 Operator

其他所有人。工作本身仍然重要，但结构不同了。

AI 给人类分配任务。分类系统发现 bug，创建工单，呈现诊断结论，分配给合适的人。这个人调查、验证、批准修复。AI 创建 PR。人类评审是否存在风险。

任务是 bug 调查、UI 打磨、CSS 改进、PR 评审、验证。它们需要技能和注意力。它们不再需要旧模型下的架构推理能力。

谁适应得最快？

我注意到了一个意料之外的模式。初级工程师比高级工程师适应得更快。

传统实践经验较少的初级工程师感到更有力量。他们获得了能放大自己影响力的工具。他们没有携带十年需要卸载的习惯。

拥有深厚传统实践经验的高级工程师最难受。他们两个月的工作量，AI 一个小时就能完成。在花了多年时间建立一项稀缺技能之后，接受这个事实很难。

我不是在评判谁对谁错。我只是在描述我观察到的事实。在这个转型中，适应性比积累的技能更重要。

人的一面

管理消失了

两个月前，我 60% 的时间花在管理人上：对齐优先级、开会、给反馈、指导工程师。今天：不到 10%。

传统的 CTO 模式说你要赋能团队——让他们做架构工作、培训他们、授权他们。但如果系统只需要一到两个架构师，我得先自己来做。我从管理变成了建造。大多数日子里我从早上 9 点写到凌晨 3 点。我设计 SOP 和系统架构。我维护缰绳（harness）。

更有压力。但我享受建造本身，而不是对齐工作。

少争吵，更好的关系

我和联合创始人及工程师的关系比以前更好了。

转型之前，我和团队的大部分互动都是对齐会议：讨论权衡、争论优先级、对技术决策有分歧。这些对话在传统模型中是必要的，但也很消耗人。

现在我仍然和团队聊天。我们聊其他事情——非工作话题、闲聊、团建出行。我们关系更好了，因为不再争论那些系统能轻松完成的工作。

不确定性是真实的

我不会假装每个人都开心。

当我停止每天和团队交流后，一些团队成员感到不安。CTO 不和我说话意味着什么？在这个新世界里我的价值是什么？这些都是合理的担忧。

有些人花更多时间辩论 AI 是否能做他们的工作，而不是实际去做工作。转型期会制造焦虑。我没有一个干净利落的答案。

但我有一个原则：我们不会因为工程师引入了一个生产 bug 就开除他。我们会改进评审流程、加强测试、增加护栏。对 AI 也是一样。如果 AI 犯了错，我们就建更好的验证、更清晰的约束、更强的可观测性。

超越工程

我看到其他公司采用 AI-First 工程，但留下所有其他环节还是手动的。

如果工程几小时就能交付功能，但市场部要花一周来发布公告，那么市场部就是瓶颈。如果产品团队仍然跑月度计划周期，那么计划就是瓶颈。

在 CREAO，我们把 AI-native 操作推到了每个职能：

• 产品发布说明：AI 从 changelog 和功能描述中自动生成
• 功能介绍视频：AI 生成动态图形
• 社交媒体日常帖子：AI 编排并自动发布
• 健康报告和分析摘要：AI 从 CloudWatch 和生产数据库生成

工程、产品、市场和增长运行在同一个 AI-native 工作流中。如果一个职能以 agent 速度运行，另一个以人类速度运行，那么人类速度的职能就会制约一切。

这意味着什么

对工程师而言

你的价值正从代码产出转向决策质量。快速写代码的能力每个月都在贬值。评估、批评和指导 AI 的能力每个月都在升值。

产品感或品味很重要。你能看一眼生成的 UI，在用户告诉你之前就发现不对吗？你能看一眼架构方案，就发现 agent 遗漏的失败模式吗？

我告诉我们 19 岁的实习生：训练批判性思维。学会评估论点、找漏洞、质疑假设。学会什么是好的设计。这些技能会持续复利。

对 CTO 和创始人而言

如果你的 PM 流程比构建时间还长，从那里开始改。

在规模化 agent 之前先建好测试缰绳。没有快速验证的快速 AI 是快速流动的技术债。

从一个架构师开始。一个人搭建系统并证明它能跑。系统跑起来后再把其他人引入操作员角色。

把 AI-native 推入每个职能。

做好遇到抵抗的准备。有些人会反弹。

对行业而言

OpenAI、Anthropic 和多个独立团队都收敛到了相同的原理上：结构化上下文、专用 agent、持久化记忆和执行循环。Harness Engineering 正在成为一个标准。

模型能力是驱动这一切的时钟。我把 CREAO 的全部转变归因于最近两个月。Opus 4.5 做不到 Opus 4.6 能做的事。下一代模型会加速得更多。

我相信单人公司将会变得普遍。如果一个架构师加 agent 能做 100 人的工作，很多公司不再需要第二个员工。

我们还早

我交谈过的大多数创始人和工程师仍然在以传统方式运作。有些人考虑过转型。很少有人已经做了。

一个记者朋友告诉我她大约和五个人聊过这个话题。她说我们比任何人都走得更远：“我觉得没有人像你们这样彻底地重建了全套工作流。”

这些工具对任何团队都是可用的。我们的栈里没有任何东西是专有的。

竞争优势在于围绕这些工具重新设计一切的决心，以及承受代价的意愿。

代价是真实的：员工的不确定性、CTO 每天工作 18 小时、资深工程师质疑自己的价值、旧系统消失新系统尚未被证明的两周真空期。

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

我们是构建 agent 平台的公司。

我们用 agent 构建了它。