--- title: "AI优先战略为何可能是错误的：一家 25 人公司的工程实践分析" source: wechat url: https://mp.weixin.qq.com/s/bM-ZXmUmsq2Jghq3U0g0Cg ingest_date: 2026-07-04 vxc: 64 stars: 4 sha256: 54fdd981d160f17ec5ca6be6bb17454c93a06bbf9cd903bd13c9bb338752df87 --- # 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：产品设计方式、产品实现方式、产品测试方式。任何一个环节保持人工，就会约束整个流水线。 ## 统一架构：单仓库的设计决策 代码库的统一是首要任务。 旧架构分散在多个独立系统中。单次变更可能需要触及三到四个仓库。对人类工程师来说这是可管理的，但对 AI 代理来说是不透明的。代理无法看到完整画面，无法推理跨服务的影响，无法在本地运行集成测试。 统一为单仓库的核心原因是：让 AI 能够看到一切。 这是驾驭工程原则的实践：将系统越多地拉入代理可检查、验证和修改的形式，获得的杠杆就越大。碎片化的代码库对代理是不可见的，统一的代码库是可读的。 整个系统的设计耗时一周：规划阶段、实现阶段、测试阶段、集成测试阶段。代码库重构使用代理完成，耗时另一周。 CREAO 是一个代理平台。他们用代理重建了运行代理的平台。如果产品能够构建自己，那么它就可行。 ## 技术栈详解 ### 基础设施：云服务 运行在云服务平台上，使用自动扩展容器服务和熔断回滚机制。部署后指标退化时，系统自动回滚。 云监控服务是中枢神经系统。结构化日志覆盖所有服务，超过 25 个告警，自动化工作流每日查询自定义指标。每个基础设施组件都暴露结构化、可查询的信号。AI 无法读取日志，就无法诊断问题。 ### CI/CD：GitHub Actions 每次代码变更通过六阶段流水线： - - 验证 CI - - 构建并部署开发环境 - - 测试开发环境 - - 部署生产环境 - - 测试生产环境 - - 发布 每次拉取请求的 CI 门禁强制执行类型检查、代码检查、单元和集成测试、Docker 构建、通过 Playwright 的端到端测试，以及环境一致性检查。没有阶段是可选的，没有手动覆盖。流水线是确定性的，代理可以预测结果并推理失败。 ### AI 代码审查：Claude 每次拉取请求触发三个并行的 AI 审查流程，使用 Claude Opus 4.6： 第一遍：代码质量 ——逻辑错误、性能问题、可维护性 第二遍：安全 ——漏洞扫描、认证边界检查、注入风险 第三遍：依赖扫描 ——供应链风险、版本冲突、许可证问题 这些是审查门禁，不是建议。它们与人工审查并行运行，捕获人工在大规模下遗漏的内容。每天部署八次时，人工审查者无法在每次拉取请求中维持注意力。 工程师还在任何 GitHub 问题或拉取请求中标记 @claude，用于实现计划、调试会话或代码分析。代理看到整个单仓库。上下文在对话中延续。 ### 自愈反馈循环 这是核心组件。 每天上午 9:00 UTC，自动化健康工作流运行。Claude Sonnet 4.6 查询云服务监控，分析所有服务的错误模式，并通过IM工具向团队提交执行健康摘要。不需要任何人请求。 一小时后，分类引擎运行。它将来自云服务监控和 Sentry 的生产错误聚类，在九个严重性维度上对每个聚类进行评分，并自动生成 Linear 调查工单。每个工单包含示例日志、受影响的用户、受影响的端点和建议的调查路径。 系统去重：如果开放问题覆盖了相同的错误模式，它会更新该问题。如果先前关闭的问题再次出现，它会检测到回归并重新打开。 工程师推送修复后，相同的流水线处理。三次 Claude 审查评估拉取请求。CI 验证。六阶段部署流水线通过开发和生产进行推广，每个阶段都有测试。部署后，分类引擎重新检查云服务监控。如果原始错误已解决，Linear 工单自动关闭。 每个工具处理一个阶段。没有工具试图做所有事情。每日周期创建一个自愈循环，错误被检测、分类、修复和验证，人工干预最小化。 ### 功能标志和支撑栈 Statsig 处理功能标志。每个功能在门后发布。部署模式：对团队启用，然后逐步百分比推广，然后完全发布或终止。终止开关立即关闭功能，不需要部署。如果功能导致指标退化，数小时内下线。不良功能与上线同日死亡。A/B 测试通过同一系统运行。 Graphite 管理拉取请求分支：合并队列在 main 分支上变基，重新运行 CI，仅在绿色时合并。堆叠的拉取请求允许在高吞吐量下进行增量审查。 Sentry 在所有服务中报告结构化异常，与云服务监控由分类引擎合并，用于跨工具上下文。Linear 是面向人工的层：自动创建的工单，带有严重性评分、示例日志和建议的调查。去重防止噪音。后续验证自动关闭已解决的问题。 ## 功能从想法到生产的路径 ### 新功能路径 - - 架构师将任务定义为结构化提示，包含代码库上下文、目标和约束 - - 代理分解任务，规划实现，编写代码，生成自己的测试 - - 打开拉取请求。三次 Claude 审查评估 - - 人工审查者检查战略风险，而非逐行正确性 - - CI 验证：类型检查、代码检查、单元测试、集成测试、端到端测试 - - Graphite 合并队列变基、重新运行 CI、绿色时合并 - - 六阶段部署流水线通过开发和生产推广，每个阶段都有测试 - - 功能门对团队开启。逐步百分比推广。指标监控 - - 终止开关可用。严重问题时熔断自动回滚 ### Bug 修复路径 1.云服务监控和 Sentry 检测错误 2. Claude 分类引擎评分严重性，创建带有完整调查上下文的 Linear 工单 3. 工程师调查。AI 已完成诊断。工程师验证并推送修复 4. 相同的审查、CI、部署和监控流水线 5. 分类引擎重新验证。如果解决，工单自动关闭 两条路径使用相同的流水线。一个系统。一个标准。 ## 结果 14 天内，每天平均三到八次生产部署。在旧模式下，整个两周期间甚至不会产生一次生产发布。 不良功能上线当日被拉下。新功能在构思当日上线。A/B 测试实时验证影响。 人们假设以质量换速度。用户参与度上升。支付转化率上升。结果比以前更好，因为反馈循环更紧密。每日发布比每月发布学得更多。 ## 新型工程组织 将存在两种类型的工程师。 ### 架构师 一到两人。他们设计教授 AI 如何工作的标准操作程序。他们构建测试基础设施、集成系统、分类系统。他们决定架构和系统边界。他们为代理定义"好"的样子。 这个角色需要深度的批判性思维。批评 AI，而非跟随。当代理提出计划时，架构师发现漏洞：遗漏的失败模式？跨越的安全边界？积累的技术债务？ 物理学博士训练中最有用的是质疑假设、压力测试论证、寻找缺失内容的能力。批评 AI 的能力将比生成代码的能力更有价值。 这也是最难填补的角色。 ### 操作员 其他所有人。工作很重要。结构不同。 AI 分配任务给人类。分类系统发现 bug、创建工单、呈现诊断、分配给合适的人。人员调查、验证、批准修复。AI 创建拉取请求。人工审查是否存在风险。 任务包括 bug 调查、UI 优化、CSS 改进、拉取请求审查、验证。需要技能和注意力。不需要旧模式要求的架构推理。 ## 适应速度的模式 初级工程师比高级工程师适应更快。 拥有较少传统实践的初级工程师感到被赋能。他们可以使用放大影响力的工具。他们没有十年的习惯需要摒弃。 拥有强大传统实践的高级工程师最难适应。AI 一小时完成两个月的工作，这是多年积累稀缺技能后难以接受的事实。 这不是评判，而是观察到的现象。在这种转变中，适应能力比积累的技能更重要。 ## 管理层的转变 ### 管理架构 两个月前，60% 的时间用于人员管理：对齐优先级、召开会议、提供反馈、指导工程师。 现在：低于 10%。 传统 CTO 模式说要赋能团队做架构工作、培训、委托。但如果系统只需要一到两名架构师，就需要亲自执行。从管理转向构建。每天上午 9 点到凌晨 3 点编码。设计系统的标准操作程序和架构。维护驾驭层。 压力更大。但享受构建，而非对齐。 ### 减少争论，改善关系 与联合创始人和工程师的关系比以前更好。 转型前，与团队的大多数互动是对齐会议：讨论权衡、辩论优先级、就技术决策产生分歧。这些对话在传统模式中是必要的，但也很消耗精力。 现在仍然与团队交流。讨论其他话题：非工作主题、休闲对话、户外旅行。相处得更好，因为不再就系统可以轻松完成的工作产生争论。 ### 不确定性是真实的 不是每个人都快乐。 停止每天与人交谈时，一些团队成员感到不确定。CTO 不跟我说话意味着什么？我在这个新世界中的价值是什么？合理的担忧。 有些人花更多时间辩论 AI 是否能完成他们的工作，而不是实际工作。转型期产生焦虑。没有干净的答案。 原则是：不因为工程师引入生产 bug 而解雇。改进审查流程、加强测试、添加防护。同样的原则适用于 AI。如果 AI 犯错，构建更好的验证、更清晰的约束、更强的可观测性。 ## 超越工程 其他公司采用 AI 优先工程，但其他环节保持人工。 如果工程以小时为单位发布功能，但营销需要一周时间宣布，营销就是瓶颈。如果产品团队仍然运行月度规划周期，规划就是瓶颈。 CREAO 将 AI 原生操作推入每个职能： - • 产品发布说明：从变更日志和功能描述 AI 生成 - • 功能介绍视频：AI 生成动态图形 - • 社交日常帖子：AI 编排和自动发布 - • 健康报告和分析摘要：从云服务监控和生产数据库 AI 生成 工程、产品、营销、增长在一个 AI 原生工作流中运行。如果一个职能以代理速度运行，另一个以人类速度运行，人类速度的职能约束一切。 ## 对行业的意义 ### 对工程师 价值从代码输出转向决策质量。快速编写代码的能力每月都在贬值。评估、批评和指导 AI 的能力在增值。 产品感知或品味很重要。能否在用户告知之前看到生成的 UI 有问题？能否在代理遗漏时看到架构提案中的失败模式？ 培训批判性思维：学习评估论证、发现差距、质疑假设。学习良好设计的样貌。这些技能会复合增长。 ### 对 CTO 和创始人 如果产品管理流程比构建时间更长，从这里开始。 在扩展代理之前构建测试驾驭层。没有快速验证的快速 AI 是快速移动的技术债务。 从一名架构师开始。一人构建系统并证明可行。系统运行后将其他人纳入操作员角色。 将 AI 原生推入每个职能。 预期阻力。有些人会推回。 ### 对行业 OpenAI、Anthropic 和多个独立团队收敛于相同的原则：结构化上下文、专业化代理、持久记忆和执行循环。驾驭工程正在成为标准。 模型能力是驱动这一切的时钟。CREAO 的转变完全归因于过去两个月。Opus 4.5 无法做到 Opus 4.6 能做的事。下一代模型将进一步加速。 一人公司将变得普遍。如果一名架构师与代理可以完成百人的工作，许多公司不需要第二名员工。 ## 早期阶段 大多数创始人和工程师仍然以传统方式运作。有些人在考虑转变。很少有人已经完成。 一位记者朋友谈过约五人这个话题。她说 CREAO 比任何人都更超前："我认为没有人像你们这样完全重建整个工作流。" 任何团队都可以使用这些工具。栈中没有专有内容。 竞争优势是围绕这些工具重新设计一切的决策，以及吸收成本的意愿。成本是真实的：员工的不确定性、CTO 工作 18 小时、高级工程师质疑自己的价值、旧系统消失而新系统未被证明的两周时间。 已经吸收了这些成本。两个月后，数据说明一切。 构建一个代理平台。用代理构建它。