夜雨聆风这是一篇关于“AI-first工程实践”的深度分享。作者是CreaoAI联合创始人Peter Pang（前Meta LLaMA团队成员），他详细介绍了公司如何彻底重构工程流程、架构和团队，让AI代理（agent）成为主要代码编写者，从而实现开发速度的指数级提升。
要点总结：
核心成果（震撼数据）
99%的生产代码由AI完成。
他们能早上10点上线新功能、中午A/B测试、下午3点根据数据直接下线，晚上5点上线改进版。
过去这种完整周期需要6周，现在只需一天。
14天内平均每天3-8次生产部署（以前两周都发不了一次）。
AI-assisted vs AI-first的本质区别
大多数公司只是“加AI工具”（Copilot、ChatGPT辅助），流程不变，效率只提升10-20%。
AI-first是彻底重构：假设AI是主要建造者，工程师只负责方向、判断和系统设计。
他们把这称为“Harness Engineering”（OpenAI后来提出的概念）：工程师的核心工作不再是写代码，而是让AI“看得见、能验证、可执行”整个系统。
他们遇到的三大瓶颈（必须打破的原因）
产品管理瓶颈：PM花几周写需求文档，但AI两小时就能实现功能——规划周期成了新瓶颈。
QA瓶颈：AI两小时出功能，人工测试却要三天。
人力瓶颈：只有25人（10个工程师），无法靠招聘追上竞争对手。
关键变革：统一架构 + 自愈闭环
把分散的多仓库重构为单体仓库（monorepo），让AI能看到完整上下文。
构建自愈反馈循环：每天自动跑健康检查（Claude分析CloudWatch日志）→ 自动聚类错误 → 自动生成Linear工单 → 工程师只验证修复 → AI写PR → 自动部署 → 自动验证关闭工单。
整个流程高度自动化，几乎无人干预。
技术栈与流程（极度工程化）
CI/CD：6阶段流水线（验证→部署dev→测试→部署prod→测试→发布），全部强制通过。
AI代码审查：每次PR触发Claude 3次并行审查（代码质量、安全、依赖）。
特性上线：全部走feature flag + 灰度 + A/B + 监控，差就秒杀（kill switch）。
监控：CloudWatch + Sentry + Statsig + Graphite，形成完整可观测性。
新团队角色分工
Architect（1-2人）：设计整个系统、SOP、测试框架、边界，给AI“可执行的规则”。核心能力是批判性思考（找AI漏掉的失败模式、技术债、安全风险）。
Operator（其他人）：处理AI分配的任务（验证、风险审查、UI微调、CSS等），不需要以前那么强的架构能力。
观察：** junior工程师适应最快**，senior反而最难（要抛弃10年习惯）。
组织与人的变化
管理时间从60%降到<10%，CTO自己变成主要builder。
团队关系反而变好（少了争优先级、争技术方案）。
但有阵痛：部分人感到价值焦虑，过渡期有不确定感。
公司把AI-native扩展到全职能（营销、产品发布、社交发帖、报告等）。
作者的洞见与展望
未来工程师的价值从“写代码速度”转向“决策质量 + 批判性思考”。
产品感、品味、找漏洞的能力会越来越值钱。
1人+AI代理可能干100人的活，一人公司会越来越常见。
他们现在还在早期，大多数公司还没真正开始重构。
一句话总结：
这不是“用AI辅助写代码”，而是把整个公司工程系统重建成AI代理的‘可执行工厂’，让AI快速迭代、自我修复，人类只做最高阶的判断和系统设计，从而实现速度、质量和规模的同步跃升。作者强调：工具已经有了，真正稀缺的是“愿意把一切推倒重来”的决心。
以下是Peter Pang（@intuitiveml）这条 X 帖子的中文译文：
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-First ≠ 使用 AI
大多数公司只是把 AI bolted（强行附加）到现有流程上。工程师打开 Cursor，PM 用 ChatGPT 写需求文档，QA 尝试用 AI 生成测试用例，工作流一成不变，效率只提升 10-20%。结构上没有任何改变。
这是AI-assisted（AI 辅助）。
AI-first（AI 优先）则意味着你围绕“AI 是主要构建者”这个假设，重新设计流程、架构和组织。你不再问“AI 如何帮助我们的工程师？”，而是问“我们要如何重构一切，让 AI 来构建，工程师只提供方向和判断？”
两者差距是数量级的。
我看到很多团队声称自己是 AI-first，却依然在跑同样的 sprint 周期、同样的 Jira 看板、同样的周会、同样的 QA 签字。他们只是把 AI 加进了循环，却没有重新设计循环本身。
一种常见的伪 AI-first 是大家说的“vibe coding”：打开 Cursor，不停 prompt 直到跑通，commit，再重复。这能快速出原型，但生产系统需要稳定、可靠、安全。当 AI 写代码时，你需要一个系统来保证这些属性。你先构建系统，prompt 只是消耗品。
我们为什么必须改变
去年我观察团队工作方式，发现了三个会把我们拖死的瓶颈。
产品管理瓶颈
我们的 PM 花几周时间调研、设计、写规格说明书——这是过去几十年的传统做法。但 Agent 两个小时就能实现一个功能。当构建时间从几个月压缩到几小时后，长达几周的规划周期反而成了瓶颈。
花几个月思考，然后两个小时就建好，这已经说不通了。
PM 需要进化成以产品思维为主的架构师，以迭代速度工作；或者退出构建循环。设计必须通过“快速原型-上线-测试-迭代”的循环完成，而不是靠委员会审核的规格文档。
QA 瓶颈
同样的逻辑。Agent 上线功能后，QA 团队要花几天测试边界情况。构建时间：2 小时；测试时间：3 天。
我们用 AI 构建的测试平台取代了手动 QA，让测试 AI 写的代码也能跟上实现速度。否则你只是在旧瓶颈下游十英尺处制造了一个新瓶颈。
人力瓶颈
竞争对手做同样的事有我们 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 门禁强制执行类型检查、lint、单元测试、集成测试、Docker 构建、Playwright 端到端测试以及环境一致性检查。没有可选阶段，没有人工覆盖。流水线是确定性的，因此 Agent 可以预测结果并推理失败原因。
AI 代码审查：Claude
每个 PR 会触发三次并行的 Claude Opus 4.6 审查：
Pass 1：代码质量（逻辑错误、性能问题、可维护性）
Pass 2：安全（漏洞扫描、认证边界检查、注入风险）
Pass 3：依赖扫描（供应链风险、版本冲突、许可问题）
这些是审查门禁，不是建议。它们与人工审查并行，在高频部署时捕捉人类容易忽略的问题。当你一天部署八次时，没有人能持续保持注意力。
工程师还可以在任何 GitHub Issue 或 PR 中 @claude，让它做实现方案、调试或代码分析。Agent 能看到整个 monorepo，上下文在对话间持续保留。
自愈反馈循环（核心）
这是整个系统的重中之重。
每天上午 9:00 UTC，自动化健康工作流自动运行。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，生成一份高管健康摘要，通过 Microsoft Teams 发送给团队——没人需要主动要求。
一小时后，分类引擎启动。它对 CloudWatch 和 Sentry 中的生产错误进行聚类，按九个严重性维度打分，并在 Linear 中自动生成调查工单。每张工单都包含样本日志、受影响用户、受影响端点和建议调查路径。
系统会自动去重。如果已有开放工单覆盖相同错误模式，就会更新它；如果已关闭的工单再次出现，就会检测到回归并重新打开。
当工程师推送修复后，同样流程处理：三次 Claude 审查、CI 验证、六阶段部署流水线。部署后，分类引擎重新检查 CloudWatch，如果原始错误已解决，Linear 工单自动关闭。
每个工具只负责一个阶段，没有工具试图包揽一切。每天的循环形成了一个自愈闭环：错误被检测、分类、修复、验证，几乎不需要人工干预。
我对 Business Insider 的记者说：“AI 会生成 PR，人类只需要审查是否存在风险。”
特性旗与支撑系统
Statsig 负责特性旗。每个功能都先走门禁上线：先对团队开放，再逐步按百分比放量，最终全量或直接 kill。Kill switch 可以瞬间关闭功能，无需重新部署。如果指标下降，我们几小时内就能下线。坏功能当天上线当天死。A/B 测试也通过同一套系统运行。
Graphite 管理 PR 分支：合并队列自动 rebase 到 main，重新跑 CI，只有绿色才合并。Stacked PR 让高吞吐量下的增量审查成为可能。
Sentry 报告所有服务的结构化异常，与 CloudWatch 一起被分类引擎合并，提供跨工具上下文。Linear 是面向人类的界面：自动创建带严重性评分、样本日志和建议路径的工单，去重避免噪音，验证通过后自动关闭已解决的问题。
一个功能从 idea 到生产的全流程
新功能路径
架构师以结构化 prompt（包含代码库上下文、目标和约束）定义任务。
Agent 分解任务、规划实现、写代码、生成自己的测试。
打开 PR → 三次 Claude 审查 → 人工审查战略风险（而非逐行正确性）→ CI 验证 → Graphite 合并队列 → 六阶段部署 → 特性旗对团队开放 → 逐步放量 → 监控指标 → 必要时 kill switch 或自动熔断回滚。
Bug 修复路径
CloudWatch + Sentry 检测错误 → Claude 分类引擎打分 → 自动创建 Linear 工单（带完整上下文）→ 工程师验证并推送修复 → 同样审查、CI、部署、监控流程 → 分类引擎验证解决 → 工单自动关闭。
两条路径使用同一套流水线，一个系统，一个标准。
成果
过去 14 天，我们平均每天生产部署 3-8 次。在旧模式下，整个两周周期连一次生产发布都做不到。
坏功能当天上线当天下线。新功能当天构思当天上线。A/B 测试实时验证效果。
大家以为我们是在拿质量换速度。但用户参与度上升了，付费转化率也上升了。我们反而得到了更好的结果，因为反馈循环更紧了。每天发货比每月发货学到的多得多。
新的工程组织结构
未来只会存在两种工程师角色。
Architect（架构师）
1-2 个人。他们设计 SOP（标准操作流程），教会 AI 如何工作；他们构建测试基础设施、集成系统、分类系统；他们决定架构和系统边界；他们定义对 Agent 来说什么是“好”。
这个角色需要极强的批判性思维。你要批判 AI，而不是跟随它。当 Agent 提出方案时，架构师要找出漏洞：它漏掉了哪些失败模式？它是否越过了安全边界？它是否在积累技术债？
我有物理学博士学位。博士最有用的训练就是质疑假设、压力测试论点、寻找缺失的东西。批判 AI 的能力，将比产出代码的能力更值钱。
这也是最难招人的角色。
Operator（操作者）
其他人。工作依然重要，但结构完全不同。
AI 把任务分配给人类。分类系统发现 bug、创建工单、给出诊断，并分配给合适的人。人类调查、验证、批准修复。AI 写 PR，人类只审查是否存在风险。
任务包括 bug 调查、UI 打磨、CSS 优化、PR 审查、验证等。这些都需要技能和注意力，但不再需要旧模式下的架构推理能力。
谁适应最快？
我观察到一个意想不到的现象：初级工程师适应得比高级工程师快。
初级工程师传统经验较少，反而感到被赋能。他们拥有能放大自己影响力的工具，不需要抛弃十年的旧习惯。
而拥有强大传统经验的高级工程师最难适应。AI 一个小时就能完成他们两个月的工作。这对积累多年稀缺技能的人来说，是很难接受的事实。
我不是在评判，只是描述我观察到的现象。在这次转型中，适应力比积累的技能更重要。
人的变化
管理时间崩盘
两个月前，我 60% 的时间花在管人上：对齐优先级、开会、给反馈、教练工程师。
现在：不到 10%。
传统 CTO 的模式是赋能团队做架构、培训他们、授权。但如果系统只需要 1-2 个架构师，我必须自己先把系统搭好。我从“管理”变成了“构建”。我现在大多数日子从早上 9 点码到凌晨 3 点，设计 SOP 和系统架构，维护这个 harness。
压力更大，但我更享受构建，而不是对齐。
争论变少，关系更好
我和联合创始人、工程师的关系比以前更好。
转型前，我和团队的大部分互动是 alignment meeting、讨论 trade-off、争优先级、争技术方案。这些对话在传统模式下是必要的，但也很消耗人。
现在我依然和团队聊天，但聊的是其他事：非工作话题、闲聊、团建旅行。我们相处得更好，因为我们不再为系统就能轻松完成的工作争论了。
不确定感是真实的
我不会假装每个人都开心。
当我不再每天和大家聊天时，有些团队成员感到不安：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 使用前，先建好测试 harness。没有快速验证的快速 AI，只是快速制造技术债。
先从一个架构师开始：一个人把系统搭起来、验证可行，再把其他人 onboarding 到 Operator 角色。
把 AI-native 推到每个职能。
对行业
OpenAI、Anthropic 和多个独立团队不约而同地走向了同样的原则：结构化上下文、专精 Agent、持久记忆、执行闭环。Harness Engineering 正在成为标准。
模型能力是推动这一切的时钟。我把 CREAO 的整个转变归因于最近两个月——Opus 4.5 做不到 Opus 4.6 能做的事，下一代模型会进一步加速。
我相信一人公司会越来越普遍。如果一个架构师 + Agent 能完成 100 人的工作，很多公司就不需要第二个员工了。
我们还处于早期
我接触的大多数创始人和工程师依然在用传统方式工作。有些人在思考转型，但真正做到的很少。
一位记者朋友告诉我，她只和五个人聊过这个话题。她说我们走得比谁都远：“我没见过谁像你们这样把整个工作流彻底重建。”
工具已经为任何团队准备好了。我们栈里没有任何东西是专有的。
竞争优势在于决定围绕这些工具重新设计一切的决心，以及愿意承担成本的勇气。成本是真实的：员工的不确定感、CTO 每天 18 小时工作、高级工程师质疑自身价值、两周旧系统已死而新系统尚未被验证的空窗期。
我们承担了这些成本。两个月后，数据已经说明了一切。
我们打造的是一个 Agent 平台，而我们是用 Agent 把它打造出来的。
