---
title: "AI 编程还在等待自己的 Spring Boot"
author: "Shawn Jiang"
lang: zh
date: 2026-08-12
canonical: https://tplog.dev/zh/essay/ai-programming-before-frameworks/
translations:
  en: https://tplog.dev/en/essay/ai-programming-before-frameworks/
  ja: https://tplog.dev/ja/essay/ai-programming-before-frameworks/
---

# AI 编程还在等待自己的 Spring Boot

AI 编程已经跨过“模型能不能写代码”的阶段，却还没有跨过“团队怎样稳定交付”的阶段。

Prompt、Context、Memory、Tool、MCP、Sandbox、Workflow、Eval，这些零件越来越齐全。真正缺少的是一条被广泛接受的默认路径：人怎样描述目标，Agent 可以看什么、改什么，任务中断后怎样继续，结果拿出哪些证据才允许合并。

这很像 Spring Boot 出现前的 Java Web。能力都有，项目也能跑，只是每支团队都在重复处理启动、装配和部署。AI 编程正在等待的“Spring Boot”，同样不会靠某个更强的模型自动出现。

## 框架的价值是减少重复判断

Tomcat 解决了 Web 应用在哪里运行，Spring 解决了对象怎样组织，Spring Boot 又把依赖选择、常用配置和运行环境装进一组默认值。Rails 走得更直接，用目录、命名和连接方式上的约定，换掉每个项目从头讨论的自由。

这些框架通过减少重复判断创造价值，代码量的下降只是结果。它们把大量实践压进概念、结构和默认值，同时在必要处留下向下穿透的入口。新人可以先沿着一条正确率较高的路做出应用，遇到问题再逐层理解容器、事务和网络。

AI 编程目前恰好缺少这种压缩。SDK 可以调用模型，Agent 可以使用工具，但团队仍要自己发明 Context 的组织方式、权限边界、状态恢复和验收标准。大家拥有相似的零件，却没有共同的开发模型。

下面这棵树展示了现有能力的分布。枝叶已经茂密，连接它们的工程契约仍然稀薄。

<figure>
  <a href="/diagrams/ai-programming-tree.png" aria-label="打开 AI Native Software Engineering 能力树原图">
    <img
      src="/diagrams/ai-programming-tree.png"
      alt="AI Native Software Engineering 能力树，从根节点向模型能力、执行环境、Agent 框架、验证体系与应用产品五个方向分支"
      width="1817"
      height="866"
      loading="lazy"
      decoding="async"
    />
  </a>
  <figcaption class="figure-caption">AI Native Software Engineering 的能力树，移动端可横向滑动或点击查看原图</figcaption>
</figure>

## 真正缺的是反馈架构

如果只看“能否完成任务”，今天的 Agent 已经相当好用。可软件交付还要回答另一组问题：它为什么这样改，哪些约束得到检查，测试覆盖了什么，失败发生在哪一层，出了事故能否恢复。

因此，AI 编程的框架不能只是 Agent 编排器。它更像一套反馈架构，把一次模糊委托变成可检查的闭环：目标写成可执行的 Specification，Context 有明确来源，工具遵守最小权限，Runtime 保存任务状态，测试与 Eval 给出验收证据，最终改动仍能追溯到人的责任。

> 让 Agent 在清楚的约束下产出可以验收的软件，并让失败可以定位，过程可以追查。

成熟以后，开发者或许不再频繁手拼 Prompt、维护 Agent Loop，正如 Spring Boot 用户不会每天装配 Servlet 容器。常见选择会成为约定，复杂状态交给 Runtime，只有异常情况才要求人向下穿透。

这套反馈架构还有一个容易被忽略的用户：正在学习编程的人。

## 新人缺少的是反馈

过去，Junior 从修 Bug、写 CRUD、补测试开始。任务不难，却会持续暴露真实后果：测试为什么挂，事务在哪里失效，接口怎样被误用，线上回滚意味着什么。工程判断就是在这些短反馈里长出来的。

Agent 正在接走这批工作。新人几分钟就能得到完整功能，却未必知道哪些决定可靠，哪些风险只是还没触发。让他直接审核 Agent 代码也解决不了问题，因为审核所需的判断，正是他尚未获得的能力。

新的学习路线只能从更高的抽象层起步，再主动向下钻取。先让 Agent 完成真实功能，然后追踪一次请求、检查一个事务边界、解释一项权限选择。失败时，区分目标理解错误、Context 缺失、工具受限和代码 Bug。框架应当显露这些边界，让完整代码同时带着可追查的过程。

交付需要的可观测、可验证和可恢复，恰好也是学习需要的反馈，无需另设一层教学功能。一个好的中间层可以同时服务团队和新人。

## 我们还不知道它叫什么

它可能像 Spring Boot，把运行环境、依赖与默认配置接在一起；也可能像 Rails，用鲜明约定减少选择；甚至可能不是传统意义上的代码框架，因为它组织的是目标、状态、权限和验收，代码只是产物之一。

这个类比也有边界。模型输出带有不确定性，Agent 还能调用工具、改动外部世界，所以验证、隔离和权限必须比传统 Web 框架更靠前。我们能借鉴的是框架如何沉淀经验，不能照搬它的答案。

模型还会快速变化，今天流行的操作技巧也会过时。Specification、Runtime、Eval、权限和恢复却会反复出现。某个环节总要靠人手工补齐，或者同一种失败在不同团队持续重演，那里通常就缺一层合适的抽象。

这层抽象出现以后，团队不必每次重新发明任务状态、权限和验收方式，新人也能顺着同一套证据理解一次交付为何成功或失败。在此之前，AI 编程拥有越来越强的 Agent，却仍然缺少自己的默认开发路径。

## 资料来源

- [Apache Tomcat 官方项目说明](https://tomcat.apache.org/)
- [Spring Framework 依赖注入文档](https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-collaborators.html)
- [Spring Boot 官方项目说明](https://spring.io/projects/spring-boot)
- [Ruby on Rails 官方设计理念](https://rubyonrails.org/doctrine)