编译｜江宇
编辑｜漠影
智东西 4 月 15 日报道，近日，前苹果机器学习专家、前 Meta GenAI 科学家、硅谷 AI 创企 CreaoAI 联合创始人兼 CTO Peter Pang，在 X 上发了一条热帖，阅读量突破百万，引发业内广泛讨论。
1、人在 AI 时代可能成为障碍。
产品经理花几周设计需求，而 AI 两小时就能实现；QA 测试需要三天，而 AI 写代码只用两小时；团队人数有限，远比不上竞争对手。效率的提升被传统流程严重限制。
2、AI-first 意味着把人从日常构建链条中解放出来。
AI 可以独立完成代码编写、审查、自动测试、部署上线和监控状态，出现问题自动回滚。每天 AI 定时扫描日志、发现问题、分配任务、跟踪修复，人只在关键节点做判断。
3、AI-first 的成功依赖五个前提条件：自动化测试、CI/CD 全流程自动化、A/B 测试与线上监控、任务管理和清晰的系统架构。
任何环节做不到，AI 的速度优势就无法释放，AI-first 也只是 " 一纸空谈 "。
4、AI-first 的真正目标是提升决策和流程效率，而非让 AI 干所有工作。
它强调在每次决策时思考 AI 能做什么、缺失哪些条件，并建立扎实的基础设施，使 AI 能力真正释放。
5、小白更容易受益。
在 AI-first 转型中，适应能力比积累的经验更重要。要训练批判性思维，学会评估论证、发现漏洞、质疑假设。学习什么是好的设计，能力会逐步累积。
以下是该文章的全文翻译（智东西在不改变原意的前提下，做了简单的编辑）：
我们 99% 的生产代码是由 AI 完成的。上周二上午 10 点，我们上线了一个新功能，中午进行了 A/B 测试，下午 3 点因为数据不支持而下线。晚上 5 点，我们上线了一个更优版本。
三个月前，这样一个周期至少需要六周。但我们围绕 AI 重新构建了整个流程，改变了团队计划、开发、测试、部署和组织的方式，改变了公司中每个人的角色。
CREAO 是一个 Agent 平台。团队中有 10 名工程师。我们从 2025 年 11 月开始构建 Agent，但从两个月前，我从底层重构了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月提出了一个概念，与我们的做法不谋而合。他们称之为：Harness Engineering（Harness 工程）——工程团队的主要职责不再是写代码，而是让 Agent 能够执行有用工作。
当出现问题时，解决方案从来不是 " 更努力 "，而是：" 缺失了哪项能力？如何让 Agent 可以理解并执行？"
我们自己也得出了这个结论，只是当时没有名称。
1、AI-First 并不等于使用 AI
而 AI-first 意味着你要重新设计流程、架构和组织，假设 AI 是主要的构建者。你要问 " 如何重构一切，让 AI 完成构建，工程师提供方向和判断？" 这种区别是指数级的。
我看到一些团队声称自己是 AI-first，但他们只是把 AI 加到循环里，并没有重构循环。
一个典型例子就是所谓的 "vibe coding"，这只能产生原型。生产系统需要稳定、可靠和安全，你需要一个能保证这些属性的系统，prompt 是一次性消耗品。
2、我们为什么必须改变
去年，我观察团队工作，发现三个瓶颈，如果不解决，会扼杀效率：
产品管理瓶颈
PM（产品经理）们几十年如一日，花数周研究、设计、撰写规格说明。但 Agent 能在两小时内实现一个功能。花数月考虑问题，然后在两小时内实现功能是没有意义的。
PM 必须进化为快速迭代的产品架构师，通过 " 原型—发布—测试—迭代循环 " 进行设计。
QA 瓶颈
Agent 上线后，QA 团队花几天测试边缘情况。开发两小时，测试三天。我们要用 AI 生成的测试平台取代了人工 QA，验证必须与实现速度一致，否则新的瓶颈会出现在原瓶颈下游。
人数瓶颈
竞争对手可能有 100 倍以上的人力，我们无法通过增加人数来追赶，只能通过 AI 重构来实现。三个系统必须由 AI 贯穿：产品设计、实现、测试。任何一个保持手工操作，都会限制整个流水线。
3、大胆决定：统一架构
我必须先修复代码库。
旧架构分散在多个独立系统中，一处修改可能需触碰 3-4 个仓库。人类工程师尚可管理，但对 AI Agent 而言，太不透明，无法推理跨服务的影响，也无法在本地运行集成测试。
我必须把所有代码统一到一个 monorepo 中，让 AI 能看到全部内容。
我花一周设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。另一周用 Agent 重构整个代码库。
4、技术栈
以下是我们的技术栈及每部分的作用。
基础设施：AWS
我们在 AWS 上运行，使用自动扩缩容容器服务和熔断回滚机制。指标下降时，系统自动回。CloudWatch 是中枢神经系统。每个服务的日志结构化，可查询，25 个报警，指标每天由自动化工作流查询。AI 如果无法读取日志，就无法诊断问题。
CI/CD：GitHub Actions
每次代码变更经过六阶段流水线：验证 CI →构建部署开发环境→测试开发环境→部署生产环境→测试生产环境→发布
每个阶段必不可少，也不能手动跳过。流水线是确定性的，因此 Agent 可以预测结果并推理失败原因。
AI 代码审查
每次 PR 触发三次并行 AI 审查：代码质量、安全扫描与依赖核查。
这些审查门槛是 " 硬性需求 "，人类无法全量关注每个 PR。工程师还可在 GitHub Issue 或 PR 中 @Claude，Agent 能看到整个 monorepo，上下文跨对话传递。
5、自愈反馈循环
核心机制为：
每天 UTC 9:00，会运行自动化健康工作流，分析所有服务的错误模式，并生成执行摘要发至团队。
一小时后，分诊引擎运行。聚类生产错误，按九个严重性维度评分，自动生成 Linear 任务，包含日志样本、受影响用户和端点、建议调查路径。
系统去重。如果同样错误模式已存在任务，更新它；若已关闭任务再次出现，检测回归并重新打开。
工程师推送修复，流水线同样处理，三次 Claude 审查、CI 验证、六阶段部署，部署后分诊引擎重新检查 CloudWatch，如原错误解决，Linear 任务自动关闭。
6、从功能想法到生产
新功能流程
架构师定义任务（结构化 prompt + 代码库上下文、目标、约束）
Agent 分解任务、计划实现、写代码、生成测试
PR 打开，Claude 三次审查，人类审查战略风险
CI 验证（类型检查、lint、单元 / 集成 / 端到端测试）
Graphite merge queue 重跑 CI，合并通过
六阶段部署流水线推进开发和生产环境的测试。
功能门控为团队开启，逐步增加比例并监控指标。如有问题，可用关闭开关立即下线，严重问题触发熔断回滚。
Bug 修复路径
CloudWatch 和 Sentry 检测错误
Claude 分诊引擎评分，生成 Linear 任务
工程师调查，AI 已完成诊断，人工验证并提交修复
走同一套严格的代码审查、验证、部署和监控流水线
分诊引擎复核，任务解决自动关闭
7、成果
14 天内，每日平均 3-8 次生产部署。旧模式下，两周可能连一次发布都没有。
错误功能当日下线，新功能当日上线。A/B 测试实时验证效果。
8、新工程组织
新组织将存在两类工程师：
架构师
1-2 人。设计 SOP 教 AI 工作，构建测试、集成和分诊系统，决定架构和系统边界，定义 Agent" 好 " 的标准。需要深度批判性思维，质疑 AI、发现漏洞、分析潜在安全和技术负债。
操作员
负责具体执行任务的团队成员。他们的工作仍然关键，但流程和责任与传统角色有所不同。AI 分配任务，分诊系统生成任务并指派给合适人选，人类调查、验证、批准修复。
任务包括 Bug 调查、UI 优化、CSS 改进、PR 审查、验证。需要技能和专注，但不要求传统架构推理能力。
9、谁适应得最快
在 AI-first 转型中，团队发现初级工程师适应得比资深工程师更快，因为他们没有长期的传统工作习惯包袱，可以更自然地利用 AI 工具放大影响力。
而资深工程师则适应较慢，他们过去需要两个月完成的工作，现在 AI 一小时就能完成，这对长期习惯深厚的人来说，是一大挑战。
在这个转型中，适应能力比积累的经验更重要。
10、人类层面
管理工作减少
两个月前，我 60% 时间用于管理。现在低于 10%。从管理转向构建，工作时间从早 9 点工作到凌晨 3 点点，设计 SOP 和架构，维护 Harness。
虽然更累，但我更享受构建的过程。
争论减少，关系改善
以前团队交流多为会议、争论、权衡，现在非工作话题更多，关系更好。
不确定感真实存在
在转型过程中，部分团队成员感到不确定：CTO 不天天交流意味着什么？我在新模式下的价值是什么？
有些人花更多时间在讨论 AI 能否替代他们的工作。
我的原则是，无论是人还是 AI 出现问题，都不因为一次错误就惩罚责任方。团队会通过改进审查流程、加强测试和增加约束条件来解决问题，从而保证系统安全和稳定。
11、跨越工程之外
其他部门仍手工操作会成为瓶颈。工程、产品、市场和增长团队运行在统一的 AI-native 流程中。如果某个职能按 Agent 速度运作，而另一个按人工速度运作，慢的那部分就会限制整体效率。
12、对工程师的启示
价值从代码产出转向决策质量。快速写代码越来越不重要，而评估、批判和指导 AI 变得更重要。
产品感觉和判断力也关键：能否在用户反馈前发现问题，并提前做出调整？
我告诉 19 岁的实习生：训练批判性思维。学会评估论证、发现漏洞、质疑假设。学习什么是好的设计。这些能力会逐步累积。
13、对 CTO 与创始人的启示
如果你的 PM 流程耗时超过构建时间，从这里开始着手。
在扩展 Agent 前先构建测试 Harness。快速的 AI 输出如果缺乏验证，会产生快速累积的技术债务。
先从一个架构师开始，一个人构建系统并证明其可行。系统稳定后，再让其他人进入操作员角色。
推动 AI-native 进入每个职能。
做好心理准备：有些人会反对。
14、对行业的启示
OpenAI、Anthropic 及独立团队在结构化上下文、专业 Agent、持久记忆和执行循环方面达成共识。Harness Engineering 正成为行业标准。
模型能力是驱动这一转变的时钟：Opus 4.5 做不到的事情，Opus 4.6 可以完成。下一代模型还将进一步加速。
我相信一人公司模式将会普及：一个架构师带 Agent 即可完成 100 人工作，许多公司无需第二名员工。
15、我们仍处于早期
我接触的大多数创始人和工程师仍在按传统方式运作。有人在考虑转型，但很少有人真正实践。
工具对任何团队都是可用的。我们的技术栈没有专有限制。竞争优势在于决定围绕这些工具重构一切，并且愿意承担成本。
成本是真实存在的：员工的不确定感，CTO 每天工作 18 小时，资深工程师重新审视自身价值，旧系统消失而新系统尚未完全验证的两周过渡期。
我们承担了这些成本。两个月后，数据说明一切。
林俊旸的观察与思考
在 Peter Pang 的 AI-first 实践之后，前阿里通义千问团队负责人林俊旸也分享了他对 AI-first 战略的理解：
批判性思维至关重要
在 Agent 时代，人类需要与 AI" 辩论 "，通过列举理由、分析问题，达成更深入的认知和全面的判断。
健康且结构良好的组织与系统必不可少
完善的体系与高效工具能让人类与 AI 协作效率成倍提升，同时为员工争取更多时间照顾身心、探索新机会。
新人更容易受益
因为经验包袱较轻，对当前困难的恐惧少。资深工程师则需仔细甄别哪些经验值得保留，哪些与第一性原则相符。
林俊旸总结道：" 无论如何，AI-first 都是极其令人兴奋的机会。"
