夜雨聆风✅点击上方🔺公众号🔺关注我✅
99%的生产代码是AI写的。上周二，他们上午10点发布了一个新功能，中午做了A/B测试，下午3点因为数据不好直接下线，下午5点就上线了改进版。三个月前，这样的循环需要六周。
作者：Peter Pang（@intuitiveml）｜ CREAO 联合创始人 & CTO
我们不是靠给IDE装个Copilot做到的。我们把工程流程拆掉，围绕AI重建了它——从规划方式、构建方式、测试方式、部署方式到团队组织方式，全部重新来过。
CREAO是一个Agent平台。25名员工，10名工程师。2025年11月开始构建Agent，两个月前完成了一次从零开始的全面架构重组。
OpenAI在2026年2月提出了一个概念，准确概括了我们一直在做的事：harness engineering。工程团队的首要任务不再是写代码，而是构建让Agent能够完成有用工作的能力体系。当出了问题，解决方案永远不是"再努力一点"，而是："缺了什么能力？我们怎么让Agent能够理解并执行？"
我们是自己得出这个结论的。只是之前没有给它命名。
AI-First不等于使用AI
大多数公司把AI附加到现有流程上。工程师打开Cursor，PM用ChatGPT写文档，QA试试AI生成测试用例。流程没变，效率提升10%到20%，结构没有任何变化。
这就是AI-assisted（AI辅助）。
AI-first意味着围绕AI是主要构建者这个假设，重新设计流程、架构和组织。不再问"AI怎么帮到工程师"，而是问"怎么重组一切，让AI做构建，人类提供方向和判断？"
两者的区别是乘法级的，不是加法级的。
我见过很多团队声称AI-first，但运行的还是同样的冲刺周期、同样的Jira看板、同样的周会、同样的QA审批节点。他们只是把AI加入了循环，没有重新设计循环。
这种情况的一个常见版本就是vibe coding：打开Cursor，不停提示直到某个东西能跑，提交，重复。这能做出原型。但生产系统需要稳定、可靠、安全。你需要一套系统来保证这些属性。提示词是一次性的，系统才是核心。
为什么必须改变
去年，我观察团队的工作方式，发现三个会卡死我们的瓶颈。
产品管理瓶颈
PM花几周时间做调研、设计、写需求文档。这个工作方式已经延续了几十年。但现在，Agent两小时就能实现一个功能。构建时间从几个月压缩到了小时级，长达数周的规划周期就成了瓶颈。
花几个月想清楚，再用两小时构建，这个逻辑不再成立了。
PM需要进化成有产品思维的架构师，以迭代的速度工作，不然就退出构建循环。设计应该通过快速的原型→发布→测试→迭代循环来完成，而不是靠委员会评审的需求文档。
QA瓶颈
同样的逻辑。Agent两小时构建完功能，QA要花三天测边界用例。构建两小时，测试三天——你在旧瓶颈下游10英尺的地方又造了一个新瓶颈。
我们用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 & Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release
每个Pull Request的CI门禁强制执行：类型检查、lint、单元测试和集成测试、Docker构建、通过Playwright的端到端测试、环境一致性检查。没有阶段可选，没有手动覆盖。流水线是确定性的，Agent能预测结果，能推理失败原因。
AI代码审查：Claude
每个PR触发三个并行AI审查通道，使用Claude Opus 4.6：
- 通道1：代码质量。逻辑错误、性能问题、可维护性。
- 通道2：安全。漏洞扫描、认证边界检查、注入风险。
- 通道3：依赖扫描。供应链风险、版本冲突、许可证问题。
这些是审查门禁，不是建议。它们和人工审查并行运行，覆盖人工在大规模下容易遗漏的问题。每天8次部署，没有任何人工审查者能在每个PR上持续专注。
工程师也可以在任何GitHub Issue或PR中@claude，获取实现方案、调试会话或代码分析。Agent能看到整个monorepo，上下文跨对话保持。
自愈反馈环
下面这段是整个系统的核心。
每天UTC时间9:00，自动健康工作流启动。Claude Sonnet 4.6查询CloudWatch，分析跨所有服务的错误模式，生成高管健康摘要，通过Microsoft Teams推送给团队。没人要求，它自动发生。
一小时后，分类引擎启动。对CloudWatch和Sentry的生产错误进行聚类，在九个严重维度上打分，在Linear中自动生成调查工单。每个工单包含：示例日志、受影响用户、受影响端点、建议的调查路径。
系统自动去重。已有开放工单覆盖相同错误模式？更新那个工单。之前的工单再次出现？检测到回归，重新打开。
工程师推送修复时，同一管道处理：三个Claude审查通道评估PR，CI验证，六阶段部署流水线推进测试，分类引擎重新检查CloudWatch，原始错误解决则Linear工单自动关闭。
每个工具只处理一个阶段，不让任何工具试图包揽一切。每日循环创造了一个自愈回路：错误被检测、分类、修复、验证，人工介入最少。
我对Business Insider的记者说了一句话："AI会做PR，人类只需要审查是否存在风险。"
功能开关和支持栈
Statsig处理功能开关。每个功能都在开关后发布。推出模式：团队启用→百分比逐步放量→全量或Kill。Kill开关即时关闭功能，不需要重新部署。功能导致指标下降，几小时内就撤掉。坏功能在上线当天死亡。 A/B测试也通过同一系统跑。
Graphite管理PR分支：合并队列rebase到main，重新跑CI，绿色才合并。堆叠PR支持高吞吐增量审查。
Sentry跨所有服务报告结构化异常，由分类引擎与CloudWatch合并，提供跨工具上下文。Linear是面向人工的界面：自动创建的工单含严重性评分、示例日志和建议调查，去重防止噪音，后续验证自动关闭已解决的问题。
功能如何从想法到生产
新功能路径
架构师将任务定义为一个结构化Prompt，包含代码库上下文、目标和约束。
Agent分解任务，规划实现，写代码，并生成自己的测试。
PR打开，三个Claude审查通道评估。人工审查者检查战略风险，不是逐行正确性。
CI验证：类型检查、lint、单元测试、集成测试、端到端测试。
Graphite合并队列rebase，重新跑CI，绿色则合并。
六阶段部署流水线推进，每个阶段测试。
功能开关对团队启用，逐步放量，监控指标。Kill开关随时待命，重大问题熔断自动回滚。
Bug修复路径
CloudWatch和Sentry检测错误。
Claude分类引擎打分，在Linear中创建带完整调查上下文的工单。
工程师调查——AI已经完成了诊断，工程师验证并推送修复。
同样的审查、CI、部署和监控管道。
分类引擎重新验证。解决则工单自动关闭。
两条路径用同一套管道。一套系统，一个标准。
结果
14天内，日均3到8次生产部署。我们的旧模式下，整个两周无法完成一次生产发布。
坏功能在上线当天被撤掉。新功能在构思当天就上线。A/B测试实时验证效果。
人们以为我们在用质量换速度。实际上：用户参与度上升了，支付转化率上升了。反馈循环收紧后，质量反而更好了。你每天发布，比每月发布学到的东西更多。
新工程组织
未来只会存在两种工程师。
架构师
一到两人。职责是：设计教AI如何工作的标准操作程序（SOP）；构建测试基础设施、集成系统、分类系统；决定架构和系统边界；定义Agent眼中"好"的标准。
这个角色需要深度批判性思维。你批评AI，不是跟随它。Agent提出一个方案，架构师要找出漏洞：它遗漏了哪些失败模式？越过了哪些安全边界？正在积累哪些技术债？
我有物理学PhD。PhD教给我最有用的，是如何质疑假设、如何压力测试论证、如何寻找缺失的东西。批评AI的能力，将比写代码的能力更值钱。
这也是最难招的角色。
操作员
其余所有人。工作依然重要，只是结构不同。
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原生化推到了每个职能：
- 产品发布说明：AI根据变更日志和功能描述自动生成
- 功能介绍视频：AI生成动态图形
- 社交媒体每日发帖：AI编排并自动发布
- 健康报告和数据分析摘要：AI根据CloudWatch和生产数据库自动生成
工程、产品、市场、增长在一个AI原生工作流中运行。如果一个职能以Agent速度运转，另一个以人工速度运转，人工速度的那个就是全局瓶颈。
这意味着什么
给工程师
你的价值正在从代码产出转向决策质量。快速写代码的能力每月都在贬值，评估、批评、指挥AI的能力每月都在升值。
产品品味很重要。你能在一张生成的UI上，在用户告诉你之前就知道它不对吗？你能在一个架构提案中，看出Agent遗漏的失败模式吗？
我告诉我19岁的实习生：训练批判性思维。学习评估论证，发现漏洞，质疑假设。学习什么才是好的设计。这些技能会复利增长。
给CTO和创始人
如果你的PM流程比构建时间还长，先重构PM流程。
扩展Agent之前先构建测试驾驭体系。快AI加慢验证等于快速积累技术债。
从一个架构师开始，证明系统可行后再扩展。
推动全职能AI原生化。
预期会遇到阻力。有些人会抵制。
给整个行业
OpenAI、Anthropic和多个独立团队 converge到了同一套原则：结构化上下文，专业化Agent，持久记忆，执行循环。Harness Engineering正在成为标准。
模型能力是驱动这个时钟的时针。我把CREAO的整个转型归功于过去两个月。Opus 4.5做不到Opus 4.6所做的事情，下代模型会让它更快。
我相信一人公司会变得普遍。如果一个架构师加Agent能做到100人的工作，很多公司根本不需要第二个员工。
我们还很早期
大多数创始人和工程师聊下来，还是传统方式运作。有些人在考虑转型，真正动手的少之又少。
一个记者朋友说她聊了大约五个人，她说我们是她见过最领先的："我不认为有人像你们这样彻底重建了整个工作流程。"
实现这一切的工具对任何团队都是现成的。堆栈里没有任何东西是专有的。
竞争优势在于围绕这些工具彻底重新设计一切的决策，以及吸收过渡成本的意愿。成本是真实的：员工的不确定性，CTO每天工作18小时，资深工程师质疑自己的价值，两周的窗口期（旧系统没了，新系统还没被验证）。
我们吸收了这个成本。两个月后，数字说话。
我们构建了一个Agent平台。我们用Agent构建了它。
如果觉得这篇文章有帮助，欢迎点赞、在看、转发！有问题也可以在评论区留言，我会尽量回复！
