Published on

重新思考 AI 原生时代的架构

Authors
  • avatar
    Name
    俞凡
    Twitter

在 AI 原生时代，传统的软件开发工作流程正面临前所未有的挑战。本文探讨了如何重新审视架构设计与开发流程，以适应这一范式转变。原文：Rethinking Architecture in the AI-Native Era: Why Your Traditional Workflow Is Becoming Your…

本来我以为已经弄明白了这个可预测的节奏：定义架构，反复修改需求，与设计师争论，忍受痛苦的代码审查，最后发布一个半成品（因为已经修改了三次目标）。

然后就出现了 Cursor，完全不同的打法。不是因为它能写更好的代码，而是迫使我重新审视所有关于完成工作的假设。

这场看似普通的冲刺已经响起了警报。我看着手里的业务需求，通常需要两周的开发时间，而团队的工作已经很饱和了。但这次我做了不同的事情：没有像往常那样做架构规划，而是用简单的英语对 Cursor 描述业务目标，按下 Tab，90 分钟后就有了包含前端、后端、数据流、图表和响应式设计的可运行原型。

真正的工作才刚刚开始 —— 但并非如所预期的那样。

我们拒绝命名的架构危机

令人不安的事实是：当市场要求并行执行时，传统软件开发本质上是串行的。

回到标准的工作流程，每个阶段都有限制。选错了框架？经过数周下游工作的努力，终于在代码审查中发现了这个问题。误解了某个需求？在集成测试中才被痛苦的发现。这不是低效率，而是结构性问题，是适应智力工作的工业流水线。

看看这些数学：

  • 架构选择：3天（猜错了，乘以2）
  • 需求审查周期：5天（因为利益相关者总想“再做一件事”）
  • 设计交接与 UI 优化：4 天（设计师和开发者对“响应式”定义不同）
  • 代码审查挑战：3天（关注越多，“这应该重构”的评论越多）

总计：中等功能至少需要 15 个自然日。到了第 8 天，业务需求已经发生变化，精心设计的解决方案现在只能解决昨天的问题。

还有一个隐形开销：认知残留（cognitive residue）。团队花了 70% 的脑力在实现上，而真正重要的架构决策 —— 缓存层、数据库分区策略、API 契约设计 —— 只占 20% 的关注度，剩下 10% 用于承诺“下季度”还清的技术债务。

AI 原生登场：不是辅助，而是范式的颠覆

需要明确指出，公司采用这些工具的方式存在危险的模式。

错误做法（经常看到）：让 AI 生成代码块，人类把它们缝合在一起。结果？每个代码块可能能节省 20% 到 30% 的工作量，但总工作量不变。更糟的是，又多了一个新的瓶颈 —— 验证 AI 的输出。

正确做法：彻底颠倒输入输出关系。

不是：

  • 架构 → 需求 → UI → 代码

试试：

  • 业务目标 + 约束条件 → 端到端 AI 生成（0–80分）→ 人类优化（80–100分）

这才是实际工作的样子。

上周，一位客户需要为其 SaaS 平台提供实时分析仪表盘。时间预算：10 天，绝对够了。工作通常包括：数据层设计（2 天）→ API 合约（2 天）→ 前端框架搭建（1 天）→ 组件开发（3 天）→ 调优（2 天）。

而现在可以：

第 0–2 小时：向 Cursor 介绍业务目标：“实时仪表盘显示客户激活指标，按队列、地区和订阅层级筛选。性能：任何查询均低于 200 毫秒。安全：行级访问控制。”

第 2–3 小时：Cursor 生成完整代码栈：带有分区的 PostgreSQL 模式，带缓存策略的 Node.js API，带状态管理的 React 前端，以及响应式网格布局。并不能立马投入生产，但已经完成了 70% 的工作，这才正是重点。

第 4-8 小时：我的专业知识接管了工作：

  • 重构数据层，增加实体化视图，将查询时间从 450ms 缩短到 80ms（这才是实际的业务价值）
  • 注入团队安全模式和认证流程
  • 为可观测栈添加监控钩子
  • 重构了代码库以匹配代码检查规则和命名规范

第二天：与实际用户一起推出并迭代。

什么改变了？我们从“10 天的基础设施工作”变成了“用 8 小时搭建脚手架，然后用 1 天做架构”。

时间不仅被压缩，还被重新分配。可以不再让团队在模板上苦苦挣扎，而是专注于真正重要的事情：可扩展性决策、性能优化和技术弹性，做那些以后很难挽回的事情。

真正的生产力悖论（以及为什么测量错误）

这里需要挑战大家引用的报告数字。

麦肯锡报告称，AI 驱动的团队生产力提升了 16% 至 30%。谷歌 DORA 2025 报告显示，80% 以上的开发者报告生产力有所提升。Cursor 的营销宣称每天生成 10 亿行代码，专业工程师接受率高达 40%。

数字是真的，但隐藏着关键的信息。

当你深入研究（特别是 2025 年 METR 对有经验开发者进行的研究），情况变得复杂起来。使用先进 AI 工具如 Cursor Pro 和 Claude 3.7 的开源开发者，实际上完成任务的速度比没有 AI 时慢了 19%，尽管他们认为自己更快（他们预计会提升 24%）。他们都是很有经验的开发者，对代码非常熟悉，并且配备了最先进的模型。

为什么？研究指出了五个关键因素：

  1. 隐性需求 —— 人类直觉上知道，但 AI 却不知道。代码质量标准、测试覆盖率和文档深度等。AI 生成了可以编译的东西，但缺少 40% 的上下文相关工作。
  2. 审核开销 —— AI 代码需要验证，这种验证往往需要耗费和从零开始写差不多的精力。
  3. 调试 AI 输出 —— 当 AI 生成一个看似合理的解决方案时，调试可能比实施已知良好方案更耗时。
  4. 上下文碎片化 —— AI 在处理范围较小的问题时效果最佳，更大的系统上下文实际上会拖慢 AI 的速度。
  5. 提示工程学习曲线 —— 大多数团队并不是提示工程师，他们需要反复试验学习，消耗了时间。

那么，出路在哪里？

出路不在于输出原始代码，而是释放出人类注意力。

当 AI 处理从 0 到 60 的工作（CRUD 操作、模板模式、简单集成），架构团队就能专注于从 60 至 100 的真正有价值的工作：性能优化、可扩展性设计、技术债务策略。

当你从端到端而非逐项进行衡量时，生产力会加倍提升。

重新定义三层架构的价值

这就是改变一切的转变。15 年后，工作可能分为三个不同区域，需要完全不同的思考方式。

第一层：通用功能（0–60分）

  • CRUD 操作、模版、标准模式
  • AI 完全有能力处理，不要浪费高级工程师来做这些事情。
  • 节省时间：80–90%（但仍需花时间验证）
  • 举例：构建用户认证模块。Cursor 会生成电子邮件验证、密码重置和 JWT 令牌，然后花 20 分钟确保符合安全政策，就完成了。

第二层：工程（60–80分）

  • 集成逻辑、优化与代码库标准化
  • AI 具备 70–80% 的能力，需要人工架构参与
  • 节省时间：50–70%（人力层面带来的差异）
  • 举例：推荐引擎运行得太慢，AI 生成了多种优化方法：缓存策略、查询优化，甚至算法改进。团队进行评估，选择适合当前场景的方案，然后进行测量。AI 建议了路径，而人类进行选择。

第三层：战略（80–100分）

  • 可扩展架构、关键优化、技术风险管理
  • AI 最多只有 20% 到 30% 的能力（“生成选项”部分）
  • 节省时间：10% 到20%（得不到多少帮助，但能帮助我们清晰思考）
  • 举例：系统需要从 100 万用户扩展到 1 亿用户。这不是编码问题，而是包括重塑数据库、数据流水线、缓存层级和边缘策略。AI 可能会提出方法，但完全需要人类进行决策，这就是我们真正的市场价值所在。

当前正在发生的生态系统转变

这个数据只是当前的行业数据，而一切都进展很快。

截至 2025 年 11 月：

  • 90% 的开发者在工作流中使用 AI（2024年为 76%）。这已经不再是采用阶段了，我们已经深入其中。
  • 仅 Cursor 每天在全球就生成 10 亿行代码，大型公司的专业工程师提交的 40% 的代码现已由 AI 生成。这不是趋势，这就是基础设施。
  • 质量和生产力同时提升，但前提是团队实施自动化审查。使用 AI 进行代码审查的团队报告质量改进率为 81%，而未进行持续审查的团队仅有 55%。
  • 成本暴跌。运行 GPT-3.5 级 AI 的推理成本在 2022 年 11 月至 2024 年 10 月间下降了 280 倍。硬件成本每年下降 30%。开放权重模型与封闭模型的差距从 8% 缩小到 1.7%。

经济信号相当强烈：商品化 AI 现在已经非常稳定，如果不用的话就意味着要为入门级产品支付更高价格。

但至关重要的一点是，那些尚未内化 AI 原生工作流的架构师，自己也变成了昂贵的商品。

如何重组团队工资手册

当你意识到旧的工作手册已经过时，不会逐步引入新的，而是立马推翻。

以前（两周冲刺）：

  1. 第 1 周：讨论架构 + 设计
  2. 第 1 周：“其实，需求变了。”
  3. 第 2 周：疯狂编码
  4. 第 2 周：代码审查揭示设计缺陷
  5. 第 3 周：修复并重新部署
  6. 结果：团队精疲力竭，时间延误，技术债务增加

以后（AI 原生循环，2–3 天）：

  1. 第 0–1 小时：清晰阐述业务目标 + 成功标准

  2. 第 1 至 3 小时：AI 生成完整原型（UI、API、数据层）

  3. 第 4 至 8 小时：由人来优化三项重要因素：

    • 架构深度：缓存、分区、查询优化
    • 团队标准：日志记录、错误处理、命名规范
    • 业务逻辑：算法、验证规则、边缘案例

  4. 第 2 天：团队用真实数据评估，反馈周期是数小时，而非几天

  5. 结果：更快交付，团队专注于难题，避免技术债务

时间不仅被压缩，还被重新分配到思考真正发生的地方。

推动转变的三个决定

决策一：停止微观管理组件生成。

我们过去对所有内容都有代码审查标准 —— 按钮组件、辅助功能、基础处理程序，这从来不是瓶颈。瓶颈在于架构决策需要数周验证。

现在？AI 根据规格生成组件，而我们只需要一次 30 分钟的验证，替代了原本需要几天的反复讨论。

决策二：引入“AI 审查作为必需层”。

当 AI 生成代码时，生成的代码是：

  • 通过基本的 linting（但经常使用占位变量名）
  • 可编译（但可能存在细微的逻辑错误）
  • 看起来是生产就绪的（但没有文档或测试覆盖）

我们增加了一个必备步骤：使用 SonarQube + Qodo 等工具进行 AI 辅助代码审查。这能捕捉 40% 因内容过于庞杂而未通过人工审核的问题。结果：质量提升了 16%（以缺陷逃逸为单位），审核时间实际上缩短了，因为 AI 会发现真正的问题。

决策三：架构师关注 AI 完成的 80% 与生产就绪的 100% 之间的差距。

这就是改变游戏规则的关键。任务不是“构建这个功能”，而是：“这是 AI 生成的内容，而产品需要这些，解决中间的差距。”

这正是专业知识的用武之地：

  • 性能调优（AI 选择解决方案，而你让它快 10 倍）
  • 错误边界设计（AI 处理主路径，而你为混乱设计）
  • 数据模型演进（AI 创建模式，而你做出匹配增长的设计）
  • 团队可扩展性（AI 编写代码，而你构建理解架构）

当 AI 拖慢了速度（这很重要）

有很多关于生产力放缓的研究，很多人都忽略了。

是的，有经验的开发者使用先进 AI 有时完成任务会比较慢。但这不是缺陷，而是选择性偏差。当你在处理从 80 到 100 的问题（架构决策、复杂集成）时，AI 实际上会降低速度，因为你需要在人类思维和 AI 错误的建议之间切换上下文。

放弃 AI 不是解决方案，因为它本来就不是用来做第三级工作的。

AI 在以下方面非常出色：

  • 生成测试套件（平均节省 37.8% 的时间）
  • 写文档（48.9%）
  • 调试已知问题模式（62.2% 采用率，节省 48.9% 时间）
  • 代码重构（28.9% 采用率，有意义但节省时间较低）

AI 在以下方面表现较弱：

  • 数据库架构（仅节省 15.6% 时间）
  • API 集成（报告节省 8.9%）
  • 系统范围优化（11.1% 采用率，11.1% 时间节省）

研究结论是，效率来自任务匹配，而非工具复杂度。

对跟不上的架构师说几句话

我对那些对这种转变感到焦虑的架构师说：你的工作并没有消失，而是正从“写好代码”演变成“人类可以推理的架构系统，而 AI 负责执行”。

这其实是个更难的问题。

当每个工程师理论上都能生成 10 倍于当前的代码时，系统层面的选择就更重要了：数据库设计、API 合约、可观测性架构、故障模式。如果代码在三年里被两个团队接手，会发生怎样的演变？

在 2025 年及以后依然蓬勃发展的架构师是这些人：

  • 别再写模板了。说真的，如果你手写 CRUD 端点，你不是在架构，只是在打字。
  • 投入时间在系统约束上。性能预算、数据库规模限制和缓存策略。AI 负责生成，但人类必须做出选择。
  • 拥有从 80 到 100 的判断力。可扩展性、韧性、团队能力，这些决定具有跨十年的影响，没有任何 AI 准备好应对这种情况。
  • 熟练掌握 AI 的限制。不要责怪工具，而要知道什么时候该用，什么时候该思考。这正是区分资深架构师和初级架构师的真正技能。
  • 先建立可观察性。如果无法衡量，就无法改进。AI 代码库需要更好的工具，而不是更少。

真正重要的数字

以衡量一个具体结果为基础。

在 AI 原生工作流出现之前：

  • 中等功能：10 天
  • 团队倦怠：高
  • 新增技术债务：约 8 个故事点
  • 代码审查周期：3–4 天
  • 因需求不匹配而重做：30%

AI 原生工作流程：

  • 中等功能：2.5 天（同一范围）
  • 团队倦怠：明显降低
  • 新增技术债务：约 1 个故事点
  • 代码审查周期：4–6 小时
  • 因需求不匹配而重做：8%

节省的时间是真实的，但模式转变的意义更大：我们并不是在同一件事上更快完成工作，而是在处理不同的问题。

我们用每个功能节省下的 7.5 天做了：

  • 为了提升 3 倍性能（架构，不是代码）而重写数据层
  • 实现断路器和重试逻辑（弹性工程）
  • 升级基础设施以提升可观测性
  • 培训团队新技术

这才是真正的投资回报率所在。

关于盲点的警告

需要指出一个没人谈论的事实：AI 原生开发可能制造一种虚假的速度感，掩盖了架构债务。

如果团队的功能发布速度快了两倍，却无法解释系统为什么会有某种行为，说明你只是在快速堆砌。代码是 AI 生成的，人类批准了，但没人知道为什么。

这时，像 Qodo 和 SonarQube 这样的工具就变得不可或缺。它们不只是看代码的工具，而是“速度”与“推理”之间的纽带，迫使你在部署代码之前明确说明代码存在的原因。

此外，文档在 AI 工作流中不再变得无关紧要。当人类写代码时，糟糕代码是显而易见的。当 AI 写代码时，功能很可能是正确的。这意味着解释意图的注释现在是架构决策，而非表面装饰。

三年展望

思考 2027 年和 2028 年会走向何方。

到那时，预计会：

  1. 代理式工作流负责 60–80% 的开发工作。不仅仅是代码生成，而是完整闭环：测试、集成，甚至一些部署决策。
  2. 架构决策是稀缺资源。代码是免费的，稀有度（架构）决定价值。
  3. 团队逆转。不再是 10 个开发者 + 1 个架构师，而是 3 个开发者 + 2 个架构师。因为架构对于大规模推理来说更重要，而开发者需要验证 AI 的输出并实现边缘用例。
  4. 高性能架构成为标准竞争优势。如果每个人的代码都是生成的，区别就在于生成内容的选择。

致正在阅读本文的架构师们

如果你已经有 15 年经验，突然怀疑自己是否还有用，直说吧：你从未如此重要。

但需要做出选择。要么：

A）成为一名普通架构师 —— 花时间向初级工程师讲解架构，争论设计模式，优化在 5% 的性能。而这些将在三年内实现自动化。

B）成为战略架构师 —— 拥有重塑系统演变方式的决策、性能合约、可扩展性路线图、技术风险、关于标准化工具的采用决策。这正是市场价值所在的地方。

区别不在于代码质量，关键在于如何分配决策带宽。

底线

十五年前，我以为成为一名伟大的架构师意味着设计更好的系统，然后有了更快的编程工具，又有了更快的 AI。

之前对架构的理解错了。

真正的架构不是关于优雅或设计的完整性，关键是减少团队需要思考的决策面，同时最大化系统的扩展潜力。

前者由 AI 处理，我们负责后者，这就是新的游戏规则。

说实话，这比争论抽象基类有趣多了。