《AI 渐进编程》之二十七：抽象之后，精确性去了哪里？

C 可以让程序员在不想关心硬件的时候不必关心硬件，而在需要关心硬件的时候，又保留继续向下控制的手段。

这其实是一种很好的抽象。

它隐藏复杂性，但没有取消控制权。

今天 AI 编程把抽象又提高了一层，但也带来了一个新的问题：

当我们越来越不需要直接面对代码时，会不会也逐渐失去对代码的精确控制？

1. 好的抽象，不应该切断底层

在 C/C++ 中，你可以直接使用：

cpp 复制代码

std::vector<int> data;

不必关心内存如何分配。

但如果真的需要优化，你仍然可以继续研究：

指针
栈和堆
内存布局
cache
SIMD
汇编

也就是说，C/C++ 的逻辑不是：

你不需要再关心硬件。

而是：

你可以在不需要的时候不关心硬件。

这两者差别很大。

好的抽象应该减少认知负担，而不是剥夺下钻的能力。

2. AI 改变了抽象的性质

传统编程语言中的抽象通常建立在明确接口上。

例如：

cpp 复制代码

sort(v.begin(), v.end());

程序员可能不知道内部具体执行了哪些指令，但这个调用的含义是明确的。

大致可以表示为：

text 复制代码

意图
↓
形式化接口
↓
确定性执行

AI 编程则不同。

现在可以直接说：

text 复制代码

把这个页面改得现代一点。

或者：

text 复制代码

帮我优化一下登录模块。

于是过程变成：

text 复制代码

意图
↓
AI 对意图的解释
↓
程序实现

问题就出现在"解释"这一层。

什么叫现代一点？

什么叫优化？

什么叫保持原有结构？

这些都不是严格定义。

因此 AI 的抽象比传统编程更高，但也更模糊。

3. 精确性往往就丢在这里

AI 编程中很多问题，并不是 AI 不会写代码。

而是它写的不是你想要的那个版本。

例如你说：

text 复制代码

优化这个页面。

AI 可能顺手：

改组件结构
换 UI 库
加依赖
调 CSS
改接口
删除它认为多余的代码

每一个动作可能都有理由。

但组合起来，就可能越界。

所以 AI 编程中的一个核心问题不是：

AI 会不会写。

而是：

AI 能不能只做该做的事情。

这就是精确性问题。

4. Markdown、测试和边界，其实都在补回控制权

这也是为什么 AI 编程项目里开始出现越来越多这样的东西：

text 复制代码

project_map.md
current_task.md
state.md
revision_log.md
agent.md

它们表面上是在给 AI 提供上下文，实际上是在重新建立控制接口。

例如：

text 复制代码

只允许修改 src/login/

禁止修改 database/

不能新增依赖。

现有 API 不得变化。

这已经比"帮我优化登录"精确得多。

测试则更进一步。

自然语言还需要 AI 自己理解，而测试可以直接给出：

text 复制代码

PASS

或者：

text 复制代码

FAIL

所以 Markdown、测试、schema、权限、状态机这些东西，看起来不同，其实都在解决同一个问题：

AI 提高抽象之后，如何重新把精确性补回来。

5. AI 编程真正需要的是"可下钻"

未来好的 AI 编程系统，不应该只是更会理解模糊语言，还必须允许人不断收紧控制范围。

可以从：

text 复制代码

帮我做一个登录系统。

逐步下钻到：

text 复制代码

只改认证模块。
不要改数据库。
只修改 auth.ts。

必要时甚至回到具体函数和代码。

如果 AI 很难在开放空间里保持这种精确性，另一条现实路径就是模板化：先固定工程骨架、接口、schema、测试和权限，再让 AI 在有限范围内生成和修改。

这很像过去的 MFC。可靠性提高了，但程序也可能重新变得冗余，因为很多结构不是为了业务本身，而是为了告诉 AI：

text 复制代码

哪里能改。
哪里不能改。
输入输出是什么。
修改后必须满足什么条件。

所以 AI 未必会让程序变短，它可能只是让人少写程序。

真正需要的不是单纯提高抽象，而是：

Abstraction without loss of controllability.

C 让程序员可以远离硬件，却没有失去硬件。

AI 编程真正成熟的标志，也应该是：

让人远离代码，却没有失去对代码的控制。