AI优先战略为何可能是错误的：一家 25 人公司的工程实践分析¶

Ch01.1067 AI优先战略为何可能是错误的：一家 25 人公司的工程实践分析¶

📊 Level ⭐⭐ | 5.9KB | entities/ai优先战略为何可能是错误的一家-25-人公司的工程实践分析.md

AI优先战略为何可能是错误的：一家 25 人公司的工程实践分析¶

来源: Unknown

发布日期: 2026-04-15

原文链接: https://mp.weixin.qq.com/s/bM-ZXmUmsq2Jghq3U0g0Cg

当 99% 的生产代码由 AI 编写¶

一家公司的生产环境中，99% 的代码由 AI 生成。某个周二上午 10 点发布的新功能，中午进行 A/B 测试，下午 3 点因数据表现不佳而被下线。下午 5 点，改进版本重新上线。三个月前，这样的迭代周期需要六周时间。

这种效率的提升并非来自在 IDE 中安装 Copilot，而是来自对工程流程的彻底重构——围绕 AI 重新设计规划、构建、测试、部署和团队组织的每一个环节。

CREAO 是一家代理平台公司，团队规模 25 人，其中工程师 10 人。2025 年 11 月开始构建代理系统，两个月前完成了产品架构和工程工作流的重构。

OpenAI 在 2026 年 2 月发表的概念论文中提出了"驾驭工程"（harness engineering）的概念：工程团队的主要工作不再是编写代码，而是让 AI 代理能够完成有效的工作。当出现失败时，解决方案不是"更努力地尝试"，而是识别缺失的能力，并将其对代理变得"可见、可理解、可执行"。

CREAO 独立得出了相同的结论，尽管当时还没有这个名称。

AI 优先与 AI 辅助的本质区别¶

大多数团队采用 AI 的方式是在现有流程上叠加工具：工程师使用 Cursor，产品经理用 ChatGPT 撰写需求文档，QA 团队实验 AI 测试生成。工作流保持不变，效率提升 10-20%。这是 AI 辅助 。

AI 优先 意味着围绕"AI 是主要构建者"这一假设，重新设计流程、架构和组织。问题从"AI 如何帮助工程师"转变为"如何重构一切，使 AI 负责构建，工程师提供方向和判断"。

这种区别是乘法而非加法。

许多团队声称采用 AI 优先，却沿用相同的冲刺周期、Jira 看板、站会和 QA 签出流程。他们只是将 AI 添加到循环中，并未重新设计循环本身。

一种常见的表现是所谓的"vibe coding"：打开 Cursor，通过提示词生成能运行的代码，提交，重复。这种方式能产出原型，但生产系统需要稳定性、可靠性和安全性。需要一个能够保证这些属性的系统，而不是依赖临时提示。

三个必须改变的瓶颈¶

产品管理瓶颈¶

传统的产品管理流程中，产品经理花费数周时间进行调研、设计和需求编写。这种模式运行了几十年，但当 AI 代理能在两小时内实现功能时，数周的规划周期就成为约束。

投入数月时间规划，然后用两小时构建，这种模式不合理。产品经理需要进化为"产品导向的架构师"，以迭代速度工作，或退出构建循环。设计需要通过快速的原型 - 测试 - 迭代循环进行，而不是委员会评审的需求文档。

QA 测试瓶颈¶

同样的动态出现在测试环节。代理发布功能后，QA 团队花费数天时间测试边界情况。构建时间两小时，测试时间三天。

解决方案是用 AI 构建的测试平台来测试 AI 编写的代码。验证速度必须与实现速度匹配，否则只是在下游十英尺处创建了新的瓶颈。

人力瓶颈¶

竞争对手拥有百倍以上的员工规模。无法通过招聘实现平衡，必须通过重新设计实现。

三个系统必须运行 AI：产品设计方式、产品实现方式、产品测试方式。任何一个环节保持人工，就会约束整个流水线。

统一架构：单仓库的¶

→ 原文存档

关联¶

• 相关概念: Harness Engineering