AI Coding 现状：蒸汽机拉马车

一个真实的场景

昨天我让 Cursor 帮我重构一个 Node.js 项目。它很快给出了漂亮的代码：解耦了逻辑、优化了性能、还加了类型注解。

然后我花了两个小时：

• 手动调整 40 多个 import 路径
• 重跑一遍单元测试（因为 AI 不知道我用 Jest 还是 Mocha）
• 解决三个版本冲突（AI 用了新 API，但我的依赖是旧版）
• 重写 README（AI 生成的文档没法直接用）

AI 写代码只用了 3 分钟，我善后用了 2 小时。

这让我想起历史课上的一个故事：19 世纪初，英国人造出了蒸汽机车，但铁路还没普及，怎么办？把蒸汽机装在马车上。

结果呢？马车的轮子承受不了蒸汽机的重量，路面被压坏了，转弯半径还不如马。

这就是现在的 AI Coding：用 2025 年的 AI，拉着 1995 年的马车。

---

我们的”马车”有哪些？

1. 文件系统：AI 的噩梦

AI 生成代码很快，但它不知道：

• 你的项目用 src/ 还是 lib/？
• 工具函数在 utils/ 还是 helpers/？
• 配置文件叫 config.js 还是 settings.json？

每次 AI 生成代码，你都要：

1. 把代码复制到正确的文件
2. 调整 import 路径
3. 手动合并已有代码

这不是 AI 的问题，是文件系统的问题。

文件系统是 1960 年代为人类设计的：你看到 src/components/Button.tsx，大脑自动知道这是组件目录下的按钮。

但 AI 看到的只是字符串。它不知道 Button.tsx 和 button.tsx 是不是同一个文件（Linux 上不是，Windows 上是）。

2. 依赖管理：版本地狱

AI 给你一段代码：

import { useQuery } from '@tanstack/react-query'

function UserList() {
  const { data } = useQuery('users', fetchUsers)
  // ...
}

看起来没问题。但：

• 你的项目用的是 React Query v3，这是 v4 的语法
• 你还装了 swr，现在项目里有两个数据请求库
• AI 不知道你用 npm 还是 yarn 还是 pnpm

你需要：

1. 检查 package.json
2. 升级依赖（或者降级 AI 的代码）
3. 重新安装
4. 祈祷没有 breaking changes

依赖管理系统是为手工编程设计的，假设人类会仔细阅读 changelog、一个个升级依赖。AI 生成代码的速度是人类的 100 倍，但依赖管理的速度还停在 2010 年。

3. 测试：AI 不知道你在测什么

AI 写完代码，你问：”帮我写测试。”

它生成：

describe('Calculator', () => {
  it('should add two numbers', () => {
    expect(add(1, 2)).toBe(3)
  })
})

但：

• 你的测试用 Vitest，不是 Jest（虽然语法一样，但 import 不同）
• 你的项目约定：测试文件放 __tests__/ 目录，不是 .test.js 后缀
• 你的 CI 要求覆盖率 >80%，AI 只测了最简单的场景

测试系统假设你在”写完代码后补测试”，但 AI Coding 的节奏是”边生成边测试”。我们需要的是实时验证，不是事后补作业。

4. Git：AI 不懂你的提交规范

AI 改了 10 个文件，你现在要 commit。

但你的团队约定：

• commit message 要用 feat: / fix: 开头
• 每个 commit 只改一个功能
• 需要关联 Jira ticket

AI 不知道这些。它只是改代码，不管你怎么 commit。

你要么手动拆分 commit（费时），要么一把梭提交（被 code review 骂）。

---

为什么会这样？

因为我们的开发工具链，是为人类手工编程设计的：

传统假设	AI Coding 现实
程序员一行行写代码	AI 一次生成几百行
修改前会读现有代码	AI 只看上下文窗口（有限）
了解项目的整体结构	AI 对项目架构理解有限
会记住上次的修改	AI 每次对话都重新开始
慢慢写，慢慢测	AI 快速生成，人类慢慢善后

我们用 21 世纪的引擎，跑在 20 世纪的道路上。

---

真正的 AI-Native 开发是什么样的？

1. 抛弃文件系统，拥抱知识图谱

不要再用 src/utils/formatDate.js，而是：

知识图谱：
- [Function: formatDate]
  - 类型：工具函数
  - 依赖：[dayjs]
  - 被使用：[UserProfile, OrderList]

AI 不需要记住路径，它只需要知道：”formatDate 是个工具函数，依赖 dayjs，在 UserProfile 里用到”。

文件系统只是知识图谱的序列化形式（为了 Git 能追踪），但不应该是开发者和 AI 的主要界面。

2. 声明式依赖

不要再用 package.json，而是：

我需要：
  - 数据请求：快速、支持缓存、TypeScript 友好
  - 状态管理：简单、不要太多 boilerplate

AI 推荐：
  - TanStack Query v5 (满足你的需求)
  - 已处理版本兼容
  - 已配置好 TypeScript

AI 根据你的意图选择依赖，而不是你手动搜索、比较、安装、配置。

3. 实时验证代替单元测试

不要写 add.test.js，而是：

实时约束：
  - add(1, 2) 必须等于 3
  - add(负数) 要有明确行为
  - 性能：处理 1000 次调用 < 10ms

AI 生成代码时，实时检查这些约束，而不是生成代码 → 写测试 → 跑测试 → 失败 → 改代码。

4. AI 直接管理版本控制

不要手动 commit，而是：

AI：
  - 功能：添加用户搜索
  - 影响文件：3 个
  - 关联：JIRA-1234
  - 风险：中（修改了核心查询逻辑）
  - 建议：先部署到 staging

AI 自动生成符合规范的 commit message、自动拆分 commit、自动关联 issue。

---

我们离 AI-Native 还有多远？

技术上：3-5 年。

已经有一些早期尝试：

• Replit 的 Agent：不需要你管文件路径，Agent 自己找
• val.town：代码写在云端，依赖自动处理
• Cursor 的 Composer：可以同时编辑多个文件

但这些都是”更好的马车”，不是火车。

真正的火车需要什么？

1. 新的项目组织方式（不是文件系统）
2. 新的依赖管理（不是 package.json）
3. 新的验证机制（不是单元测试）
4. 新的协作方式（不是 Git + PR）

这需要整个生态系统的重建，不是某个 AI 编辑器能单独解决的。

---

现在我们能做什么？

在新生态成熟前，我们可以：

1. 建立 AI-Friendly 的项目规范

不好：

project/
  src/
    components/
    utils/
    pages/
    hooks/

更好：

project/
  README.AI.md  # 告诉 AI 项目结构、约定、注意事项
  src/
    每个目录有 README.md 说明用途

2. 减少隐式约定

不好：
“我们团队约定 utils 只放纯函数”（AI 不知道）

更好：
在 ESLint 规则里写死：utils/ 目录禁止副作用

3. 用工具强制规范

• commit message → commitlint
• 代码格式 → prettier
• import 顺序 → eslint-plugin-import

AI 不擅长记住隐式规则，但工具可以强制执行。

4. 接受”不完美”

AI 生成的代码不会 100% 符合你的风格。与其花时间调整格式，不如专注于逻辑正确性。

完美是好代码的敌人。

---

结语

蒸汽机拉马车的时代没有持续太久。很快，人类意识到：要发挥蒸汽机的威力，需要铁路、火车站、信号系统——一整套新基础设施。

AI Coding 也一样。

现在我们还在用 AI 生成代码，然后手工调整路径、修依赖、写测试、拆 commit。这很低效，但这是过渡期的必然。

真正的变革，不是更好的 AI 模型，而是为 AI 设计的全新开发基础设施。

那时候，开发者的工作不再是”写代码”，而是”定义意图、验证结果、做架构决策”。

代码生成、测试、部署——这些都是 AI 的事。

我们正站在这个转折点上。

蒸汽机已经装上马车了，铁路还会远吗？