作者：Peter Pang
简单评述：AI 编程迅速发展，引发了软件工业的革命。原有的大量工作模式、方法，都在迅速重构。
在技术推动之下，生产效率也会飞速提升。
为什么你的“AI 优先”战略很可能错了
我们 99% 的生产代码都是由 AI 编写的。上周二上午 10 点，我们上线了一项新功能；中午就完成了 A/B 测试；下午 3 点，数据告诉我们不行，于是立刻下线；下午 5 点，我们就发布了改进版。要是放在三个月前，这样一个迭代周期得花上六周时间。
我们走到今天，并非只是在 IDE 里加了个 Copilot 插件那么简单。我们彻底拆解了原有的工程流程，并围绕 AI 从头重建。我们改变了规划、构建、测试、部署的方式，也重组了团队结构，甚至重新定义了公司里每个角色的职责。
CREAO 是一个智能体（agent）平台，共有 25 名员工，其中 10 名是工程师。我们从 2025 年 11 月开始构建智能体，两个月前，我彻底重构了整个产品架构和工程工作流。
2026 年 2 月，OpenAI 发布了一个概念，恰好概括了我们一直在做的事。他们称之为“驾驭工程”（harness engineering）：工程团队的核心职责不再是写代码，而是让智能体能够完成有价值的工作。当系统出错时，解决方案绝不是“再努力一点”，而是去思考：“缺失了什么能力？我们如何让这种能力对智能体而言清晰可辨、可强制执行？”
我们是自己摸索到这一结论的，当时甚至还没有一个名字来描述它。
“AI-First” 不等于 “使用 AI”
大多数公司只是把 AI 生硬地嫁接到现有流程上：工程师打开 Cursor，产品经理用 ChatGPT 起草需求文档，QA 团队尝试用 AI 生成测试用例。工作流程本身纹丝不动，效率或许提升了 10% 到 20%，但结构性的东西毫无改变。
这只能叫“AI 辅助”。
真正的“AI 优先”，意味着你必须围绕“AI 是主要构建者”这一前提，重新设计你的流程、架构和组织方式。你不再问“AI 如何帮助我们的工程师？”，而是问“我们该如何重构一切，让 AI 负责构建，而工程师专注于提供方向与判断？”
这两者的差异是倍增级的。
我看到很多团队嘴上喊着“AI 优先”，却依然沿用相同的冲刺周期、相同的 Jira 看板、相同的每周站会、相同的 QA 签核流程。他们只是把 AI 加进了旧循环，并没有重新设计这个循环本身。
一种常见的做法就是人们所说的“氛围式编码”（vibe coding）：打开 Cursor，不断提示直到代码跑通，提交，然后重复。这种方式能产出原型，但生产系统需要的是稳定、可靠和安全。你需要构建一套系统，确保当 AI 编写代码时，这些属性依然能得到保障。你要构建的是系统本身，而提示词（prompts）只是可丢弃的消耗品。
我们为何不得不改变
去年，我观察团队的工作方式，发现了三个会扼杀我们的瓶颈。
产品管理瓶颈
我们的产品经理花数周时间调研、设计、撰写功能规格说明书。几十年来，产品管理一直如此运作。但如今，智能体两小时就能实现一个功能。当构建时间从数月压缩到几小时，长达数周的规划周期就成了制约因素。
花几个月去思考一件事，然后只用两小时就把它做出来，这毫无道理。
产品经理必须进化成具备产品思维的架构师，以迭代的速度工作，否则就该退出构建流程。设计应该通过“快速原型—上线—测试—迭代”的闭环来完成，而不是靠委员会反复评审的规格文档。
质量保证（QA）瓶颈
情况如出一辙。每当智能体上线一个功能，我们的 QA 团队就要花几天时间测试各种边界情况。构建只需两小时，测试却要三天。
我们用 AI 构建的测试平台取代了人工 QA，专门用于测试 AI 编写的代码。验证的速度必须与实现同步。否则，你只是在旧瓶颈下游十英尺处，又制造了一个新瓶颈。
人力规模瓶颈
我们的竞争对手动辄拥有百倍于我们的人力来做类似的工作。而我们只有 25 人。我们无法靠招聘追平差距，只能靠重新设计工作方式来实现。
有三大系统必须全面融入 AI：产品设计、产品实现和产品测试。只要其中任何一个环节仍是人工操作，就会拖累整个流水线。
大胆的决策：统一架构
我必须先解决代码库的问题。
我们原有的架构分散在多个独立系统中。一次简单的变更，可能需要同时修改三到四个代码仓库。从人类工程师的角度看，这尚可管理；但从 AI 智能体的视角来看，却是一片混沌——它看不到全局，无法推理跨服务的影响，也无法在本地运行集成测试。
因此，我决定将所有代码统一到一个单体仓库（monorepo）中。其中一个核心原因就是：让 AI 能“看见”一切。
这正是“驾驭工程”（harness engineering）原则的实践体现：你把越多系统纳入智能体可检查、可验证、可修改的形式之中，你获得的杠杆效应就越大。碎片化的代码库对智能体而言是不可见的；而统一的代码库则是清晰可读的。
我用了一周时间设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。接着又用了一周时间，借助智能体彻底重构了整个代码库。
CREAO 本身就是一个智能体平台。我们用自己的智能体重建了运行这些智能体的平台。如果产品能自我构建，那就说明它真的可行。
我们的技术栈
以下是我们的技术栈及其各组件的作用：
基础设施：AWS
我们运行在 AWS 上，采用自动扩缩容的容器服务，并配备断路器式回滚机制。一旦部署后指标恶化，系统会自动回退。
CloudWatch 是整个系统的中枢神经。所有服务均输出结构化日志，设置超过 25 个告警规则，并由自动化工作流每日查询自定义指标。每一项基础设施都暴露结构化、可查询的信号——如果 AI 无法读取日志，就无法诊断问题。
CI/CD：GitHub Actions
每次代码变更都要通过一个六阶段流水线：
验证 CI → 构建并部署到开发环境 → 开发环境测试 → 部署到生产环境 → 生产环境测试 → 正式发布
每个 Pull Request 的 CI 门禁强制执行类型检查、代码规范校验、单元与集成测试、Docker 构建、Playwright 端到端测试，以及环境一致性检查。没有任何阶段可跳过，也不允许人工绕过。整个流水线是确定性的，因此智能体可以预测结果，并对失败进行推理。
AI 代码审查：Claude
每个 Pull Request 都会触发三次并行的 AI 审查，使用的是 Claude Opus 4.6：
- 第一轮：代码质量——逻辑错误、性能问题、可维护性；
- 第二轮：安全性——漏洞扫描、认证边界检查、注入风险；
- 第三轮：依赖扫描——供应链风险、版本冲突、许可证问题。
这些是审查关卡，而非建议。它们与人工审查并行运行，能在海量提交中捕捉人类容易遗漏的问题。当你每天部署八次时，没有任何人类审查者能持续关注每一个 PR。
工程师还可以在任何 GitHub Issue 或 PR 中直接 @claude，请求制定实现方案、调试会话或代码分析。该智能体能访问整个 monorepo，上下文可在对话间延续。
自愈反馈闭环
这是整个体系的核心。
每天 UTC 时间上午 9 点，一个自动化的健康检查工作流启动。Claude Sonnet 4.6 会查询 CloudWatch，分析所有服务中的错误模式，并生成一份高管级健康摘要，通过 Microsoft Teams 自动发送给团队——无需任何人主动请求。
一小时后，分诊引擎（triage engine）开始运行。它从 CloudWatch 和 Sentry 中聚类生产环境错误，基于九个严重性维度对每个错误簇打分，并在 Linear 中自动生成调查工单。每张工单都包含示例日志、受影响用户、相关接口，以及建议的排查路径。
系统具备去重能力：如果已有未关闭的工单覆盖相同错误模式，就更新该工单；如果一个曾关闭的问题重现，系统会识别为回归并自动重新打开。
当工程师提交修复时，同样的流水线会处理该变更：三个 Claude 审查通道评估 PR，CI 进行验证，六阶段部署流水线依次在开发和生产环境推进，并在每个阶段执行测试。部署完成后，分诊引擎再次检查 CloudWatch。若原始错误已解决，Linear 中的工单将自动关闭。
每个工具只负责一个环节，没有任何工具试图大包大揽。这一日常循环形成了一个自愈闭环：错误被自动发现、分诊、修复并验证，几乎无需人工干预。
我曾对《商业内幕》（Business Insider）的一位记者说：“未来 AI 会写出 PR，人类只需审查其中是否存在风险。”
功能开关与支撑栈
Statsig 负责功能开关（feature flags）。每个功能都默认隐藏在开关之后。发布流程为：先对内部团队开放，再逐步按百分比灰度发布，最后全量上线或直接下线。“关闭开关”可瞬间禁用功能，无需重新部署。一旦某功能导致指标下降，我们几小时内就能将其撤下。糟糕的功能在其上线当天就会被终结。A/B 测试也通过同一系统运行。
Graphite 管理 PR 分支：合并队列会自动 rebase 到主干，重新运行 CI，仅在全部通过后才合并。堆叠式 PR（stacked PRs）支持高吞吐下的增量审查。
Sentry 在所有服务中上报结构化异常，由分诊引擎与 CloudWatch 数据融合，提供跨工具上下文。Linear 则是面向人类的交互层：自动创建的工单包含严重性评分、示例日志和排查建议；去重机制避免信息噪音；后续验证会自动关闭已解决的问题。
一个功能如何从构想到上线
新功能路径（New Feature Path）
- 架构师定义任务：以结构化提示（structured prompt）的形式明确任务，包含代码库上下文、目标和约束条件。
- 智能体执行开发：AI 智能体对任务进行拆解，规划实现方案，编写代码，并自动生成配套测试。
- 提交 Pull Request（PR）：系统自动创建 PR。Claude 启动三轮并行审查，分别评估代码质量、安全性和依赖风险。人类工程师不再逐行检查代码正确性，而是聚焦于战略层面的风险判断。
- CI 验证：流水线执行类型检查、代码规范校验、单元测试、集成测试和端到端测试，确保变更符合标准。
- 自动合并：Graphite 的合并队列将 PR rebase 到主干，重新运行 CI，仅在全部通过后自动合并。
- 六阶段部署：变更通过开发环境到生产环境的六阶段部署流水线，每个阶段均包含完整测试。
- 灰度发布：功能开关首先对内部团队开启，随后按百分比逐步放量，全程监控关键指标。
- 快速回退机制：一旦发现任何指标劣化，可立即通过“关闭开关”下线功能；若出现严重问题，断路器机制将自动触发回滚。
缺陷修复路径（Bug Fix Path）
- 异常检测：CloudWatch 与 Sentry 实时捕获生产环境中的错误。
- 智能分诊：Claude 分诊引擎评估错误严重性，自动生成 Linear 工单，并附上完整的上下文信息——包括日志样本、影响范围和建议排查路径。
- 工程师介入：工程师开展调查。此时 AI 已完成初步诊断，工程师只需验证结论并提交修复代码。
- 统一流水线处理：修复代码同样经过相同的审查、CI 验证、部署和监控流程。
- 自动闭环：分诊引擎在部署后重新验证 CloudWatch 数据。若原始问题已解决，Linear 工单将自动关闭。
统一标准，一套系统
无论是新功能开发还是缺陷修复，两条路径共享同一套工程流水线。
一个系统，一个标准。
这正是“AI 优先”战略的核心：不是把 AI 当作辅助工具，而是围绕 AI 重构整个交付体系，让自动化、可靠性与速度成为默认状态。
成果
在最近14天内，我们平均每天向生产环境部署3到8次。而在旧模式下，整整两周甚至无法完成一次正式发布。
糟糕的功能在其上线当天就会被下线；新功能在其构想当天就能上线；A/B测试可实时验证其业务影响。
人们常以为我们在用质量换取速度。事实恰恰相反：用户参与度上升了，支付转化率也提高了。我们取得了比以往更好的结果——因为反馈闭环更紧密了。每天发布，你学到的东西远胜于每月发布一次。
新型工程组织
未来将只存在两类工程师：
架构师（The Architect）
通常仅有一到两人。他们负责设计标准操作流程（SOP），教会AI如何工作；他们构建测试基础设施、集成系统和分诊引擎；他们划定系统边界，定义架构原则；更重要的是，他们为智能体明确“什么是好”。
这一角色需要极强的批判性思维。你不是追随AI，而是质疑它。当智能体提出一个方案时，架构师要找出其中的漏洞：它忽略了哪些故障模式？越过了哪些安全边界？正在积累哪些技术债务？
我拥有物理学博士学位。读博期间最有用的训练，就是学会质疑假设、压力测试论点，并发现缺失的部分。在未来，批判AI的能力将比编写代码的能力更有价值。
这也是最难填补的角色。
执行者（The Operator）
其余所有人皆属此类。他们的工作依然重要，只是结构不同了。
现在是AI给人类分配任务。分诊系统发现一个bug，自动生成工单，附上诊断结论，并指派给合适的人。该人员负责调查、验证并批准修复方案。AI生成PR，人类只需判断其中是否存在风险。
这类任务包括：bug排查、UI微调、CSS优化、PR审查、结果验证等。它们需要技能与专注力，但不再要求旧模式下那种复杂的架构推理能力。
谁适应得最快？
我观察到了一个出乎意料的模式：初级工程师比资深工程师适应得更快。
那些传统工程经验较少的初级工程师反而感到被赋能——他们获得了能放大自身影响力的工具，且无需摆脱十年积习。
而拥有深厚传统工程背景的资深工程师则面临最大挑战。过去两个月的工作量，如今AI一小时就能完成。对于那些耗费多年打磨稀缺技能的人来说，这很难接受。
我并非在评判优劣，只是如实描述所见。在这场转型中，适应力比经验积累更重要。
人的维度
管理消失了
两个月前，我60%的时间花在人员管理上：对齐优先级、开会、反馈、辅导工程师。
如今，这一比例降至10%以下。
传统CTO模型强调“赋能团队做架构工作、培养人才、授权”。但如果整个系统只需要一两个架构师，那我必须先亲自上手。我从管理者变回建造者——大多数日子从早上9点编码到凌晨3点。我设计系统的SOP与架构，维护整个“驾驭框架”（harness）。
压力更大了，但我享受建造本身，而非无休止的对齐。
争论少了，关系更好了
我与联合创始人及工程师的关系比以往更融洽。
转型前，我和团队的大部分互动都是对齐会议：讨论权衡、争辩优先级、就技术决策产生分歧。这些对话在传统模式下必不可少，但也令人精疲力竭。
如今我依然和团队交流，但聊的是别的事：非工作话题、闲聊、团建旅行。因为我们不再为那些本可由系统轻松完成的工作争吵，关系自然更和谐。
不确定性真实存在
我不会假装每个人都开心。
当我停止每天与每个人交谈后，一些团队成员感到不安：“CTO不找我谈话，是不是意味着我不重要了？”“在这个新世界里，我的价值是什么？”——这些都是合理的担忧。
有些人花更多时间争论“AI是否能取代我的工作”，而不是真正投入工作。转型期必然带来焦虑，对此我也没有完美的答案。
但我有一个原则：我们不会因为工程师引入了一个线上bug就解雇他，而是改进审查流程、加强测试、增设防护栏。对待AI也应如此。如果AI犯了错，我们就构建更完善的验证机制、更清晰的约束条件、更强的可观测性。
超越工程
我看到许多公司推行“AI优先工程”，却让其他职能保持手动操作。
如果工程团队几小时内就能上线功能，但市场团队仍需一周才能发布公告，那么市场就成了瓶颈。如果产品团队还在运行月度规划周期，那么规划本身就是瓶颈。
在CREAO，我们将“AI原生运营”（AI-native operations）扩展到了每一个职能：
- 产品发布说明：由AI根据变更日志和功能描述自动生成；
- 功能介绍视频：AI生成动态图形；
- 社交媒体日常内容：由AI编排并自动发布；
- 健康报告与数据分析摘要：AI从CloudWatch和生产数据库中提取信息并撰写。
工程、产品、市场与增长，全部运行在同一套AI原生工作流中。只要有一个职能以“人类速度”运行，而其他职能以“智能体速度”运行，那么人类速度的职能就会拖累整体效率。
这意味着什么
对工程师而言
你的价值正从“产出代码”转向“决策质量”。
每个月，快速编写代码的能力都在贬值；而评估、批判和引导 AI 的能力则日益珍贵。
产品直觉（product sense）或审美判断（taste）变得至关重要。
你能否在用户反馈之前，就看出 AI 生成的界面哪里不对？
你能否在架构提案中，发现智能体遗漏的故障模式？
我对我们19岁的实习生说：训练你的批判性思维。学会评估论点、发现漏洞、质疑假设，理解什么是优秀的设计。这些能力会复利增长。
对CTO和创始人而言
如果你的产品管理流程比构建时间还长，那就从那里开始改革。
在规模化部署智能体之前，先构建好测试“驾驭框架”（testing harness）。
没有快速验证的快速AI，只会制造高速堆积的技术债务。
从一名架构师开始——一个人构建系统并证明其可行。待系统稳定运行后，再将其他人逐步纳入“执行者”角色。
将“AI原生”理念推广到每一个职能。
同时，做好迎接阻力的准备。一定会有人抵触。
对整个行业而言
OpenAI、Anthropic 以及多个独立团队不约而同地得出了相同的原则：结构化上下文、专业化智能体、持久记忆、执行闭环。“驾驭工程”（Harness Engineering）正在成为新标准。
驱动这一切的是模型能力的演进节奏。CREAO 的全面转型，完全归功于过去两个月的技术跃迁。Opus 4.5 做不到的事，Opus 4.6 可以做到。下一代模型将进一步加速这一进程。
我相信，“一人公司”将变得普遍。如果一名架构师配合智能体就能完成百人团队的工作，许多公司可能根本不需要第二名员工。
我们仍处于早期
我交谈过的大多数创始人和工程师，仍在沿用传统方式。有些人开始思考转型，但真正付诸行动的凤毛麟角。
一位记者朋友告诉我，她就此话题采访过大约五个人。她说，我们的进展远超他人：“我觉得没人像你们这样，彻底重建了整个工作流。”
事实上，任何团队现在都可以做到这一点。我们技术栈中的每一项工具都是公开可用的，并无 proprietary（专有）成分。
真正的竞争优势，在于下定决心围绕这些工具重构一切，以及愿意承担随之而来的代价。
而代价是真实的：
- 员工的不安与迷茫，
- CTO每天工作18小时，
- 资深工程师质疑自身价值，
- 在旧系统已废、新系统未证的两周真空期中艰难前行。
我们承受了这些代价。
两个月后，数据给出了答案。
我们构建了一个智能体平台。
而这个平台，正是由智能体自己构建的。
