99%代码由AI写:他们拆了整个开发工作流程,从零重建

大家好，我是寂寞的熊猫。

最近在 X 上刷到一个帖子，CREAO 的 CTO Peter Pang 写的。他说他们 25 人的团队，99% 的生产代码由 AI 生成。

他举了个例子：上周二上午 10 点上线新功能，中午做 A/B 测试，下午 3 点数据不好直接下线，傍晚 5 点上改进版。三个月前，这种节奏要六周。

先说结论：

这不是给 IDE 加 Copilot 那种故事
他们把整个工程流程拆了重建，流程、架构、团队角色全变了
OpenAI 给这种做法起了个名字叫 Harness Engineering：工程师的主要工作不再是写代码，而是让 AI 能写对代码
方向没问题，但这个故事有它不能忽略的前提

真正的变化不是 AI 帮你写代码，是你帮 AI 搭好写代码的脚手架。

AI-Assisted 和 AI-First 是两回事

AI-Assisted 就是"AI 辅助"，AI-First 就是"AI 优先"。听着差不多，实际差很远。

大部分团队现在在做的，叫 AI-Assisted。工程师打开 Cursor 写代码，PM 用 ChatGPT 写需求，QA 试试 AI 生成测试。流程没变，效率多个 10-20%。

CREAO 做的是另一件事，叫 AI-First。Pang 说得很直白：不是问"AI 怎么帮工程师"，而是问"怎么把一切重新设计成让 AI 来建，人做判断"。

这两者的差别不是加不加工具，是乘不乘得起的问题。

Pang 还举了个例子。如果 PM 花几周规划一个功能，但 AI 两小时就能实现，那规划流程本身就是瓶颈。如果 QA 测试要三天，但 AI 两小时写完了，QA 就成了下游的卡点。哪个环节还停在人的速度，哪个环节就拖住整条线。

这个判断我同意。而且不是只有他在说。

Peter Steinberger——就是 OpenClaw 背后的那个开发者——之前提过一个概念叫 Agentic Engineering。核心观点一模一样：不是让 AI 随便写，而是搭好验证体系，让 AI 的输出可检查、可回滚、可持续。

OpenAI 后来把这套东西总结成了 Harness Engineering。名字不同，说的都是同一件事。

他们具体做了什么

Pang 在帖子里把做法拆成了三块。每一块都有点反直觉。

把代码合成一个 Monorepo

他们之前代码分散在好几个仓库。对人来说还凑合，对 AI 来说就是瞎的。跨服务的影响它推理不了，集成测试跑不了，因为它看不到全貌。

Pang 用了两周把所有代码合进一个 Monorepo。原因只有一个：让 AI 能看到所有东西。

他原话说得很好："A fragmented codebase is invisible to agents. A unified one is legible." 碎片化的代码库对 Agent 来说是隐形的，统一的才是可读的。

这步听着简单，实际很难。历史包袱、团队边界、代码归属全是阻力。但如果你想让 AI 真正接手工程，这步绕不过去。

搭了一条工程流水线

这是整套方案里最重的一块。

每个 PR 触发三组 Claude Opus 4.6 的并行审查：代码质量、安全扫描、依赖检查。不是建议，是硬门，不通过就过不去。

每天早上 9 点（UTC），一个自动化流程跑一轮。Claude Sonnet 4.6 查 CloudWatch 日志，分析错误模式，生成分摘要发到 Teams。没人要求它跑，它自己跑。

一小时后，分级引擎启动。把 CloudWatch 和 Sentry 的错误聚类、按九个维度打严重度分、自动在 Linear 开工单。每个工单带上样本日志、受影响用户、受影响接口、建议排查路径。

如果之前已经有类似工单，它去重。如果之前关掉的工单又出现了，它检测回归并重新打开。

工程师推修复。同样的审查流程、同样的六阶段部署管线。部署后，分级引擎再查一轮。错误消失了，工单自动关掉。

检测、分级、修复、验证。一个闭环，极少需要人工干预。

这个设计思路其实我们见过。之前写 Claude Code 源码泄露那篇，里面有个 autoDream 模块——用户空闲时后台偷偷消化记忆。OpenClaw 后来把这个功能开源实现了，叫 Dreaming 系统。思路一脉相承：不是等人来处理，是系统自己循环。

重新定义了工程师角色

Pang 提了一个判断：未来只有两类工程师。

架构师。一到两个人。设计 AI 工作的标准流程，搭测试基础设施，定系统边界，决定什么叫"好"。核心能力不是写代码，是质疑 AI。AI 提了一个方案，架构师要找出它漏了什么失败模式，跨了什么安全边界，欠了什么技术债。

操作员。其他人。AI 分配任务，人去执行。分级系统发现 bug、开工单、给诊断。人去验证、审批修复。AI 提 PR，人审查有没有风险。

Pang 有物理学博士背景。他说读博最有用的训练不是具体的物理知识，而是质疑假设、压力测试论证、找漏洞的能力。质疑 AI 的能力，会比你写代码的能力更值钱。

他还说了一个事：初级工程师比老手适应得更快。因为新人没有十年的习惯要改，老手看着自己两个月的工作量被 AI 一小时做完，这事很难接受。

几个前提

CREAO 的案例有说服力。但有几个前提。

25 人团队，10 个工程师，CTO 可以一个人拍板重构。大公司做不到。你试试说服三个部门合并代码库、重做 CI/CD、取消每周站会？

Pang 说他的管理时间从 60% 降到了 10% 以下。代价是他每天从早上 9 点干到凌晨 3 点。这不算"AI 让人轻松了"。AI 让一个人扛了原来一百个人的活，但这个人得扛得住。

老工程师比新人更难适应。这话的反面是：这些人积累的领域知识和架构经验，恰恰是 AI 短期内替代不了的。Pang 说的"架构师"角色，需要的正是这种能力。

还有技术门槛。CREAO 的技术栈——AWS 自动伸缩、六阶段 CI/CD、三重 AI Review、CloudWatch 全链路监控——搭这套东西本身就不简单。中小团队没有这个基建能力，也不一定有 API 调用预算。

团队管理文化不一样，合规要求不一样，AI 服务访问也有限制。Pang 描述的那种"CTO 一人拍板、两周重构完"的效率，在大公司可不能那么快容易落地。

别急着重组

不用一步到位。

先从一个环节开始。AI Code Review 最容易被接受。不改流程，加一层自动审查。GitHub Actions + Claude API，半天能搭好。

测试护栏比堆 AI 能力重要。Pang 反复在强调：快速部署的前提是验证也快。AI 写了代码但测试跟不上，你只是在快速积累技术债。

会质疑 AI ，比会用 AI 更稀缺。能写代码的人越来越多。能判断 AI 输出质量、发现它遗漏的失败模式和安全风险的人，反而越来越值钱。

写在最后

CREAO 的故事说明了一件事：AI 能力足够强的时候，工程组织的形态会变。架构师负责方向和判断，AI 负责执行，操作员负责验证和审批。

25 人小团队的极端案例，不能直接套到 500 人的公司。CTO 每天干 18 小时不代表你也应该。他们用的是 Opus 4.6，不代表你现在用的模型也能做到同样的事。

该关注的是方向。Agent 在进化，AI 编程在成熟，工程组织在跟着变。这条线上的每一步都有真实案例在验证。

如果对AI个人提效，以及副业感兴趣，而不只是围观，也推荐加入 IDO 老徐 的知识星球：AI 落地实战 · DeepSeek · OpenClaw。

里面会持续分享 OpenClaw 相关内容、AI 工作流搭建、商业化落地和各种实战避坑经验。

有需要交流AI信息的，AI编程，AI绘画，AI视频等等，都可以可以添加微信

我是寂寞的熊猫，程序员，职场努力升职，业余时间探索副业，寻找第二曲线，聚焦AI绘画、 AI 编程、智能体方向副业探索与变现。