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

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

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

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

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

---

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

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

std::vector<int> data;

不必关心内存如何分配。

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

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

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

你不需要再关心硬件。

而是：

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

这两者差别很大。

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

---

2. AI 改变了抽象的性质

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

例如：

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

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

大致可以表示为：

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

AI 编程则不同。

现在可以直接说：

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

或者：

帮我优化一下登录模块。

于是过程变成：

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

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

什么叫现代一点？

什么叫优化？

什么叫保持原有结构？

这些都不是严格定义。

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

---

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

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

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

例如你说：

优化这个页面。

AI 可能顺手：

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

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

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

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

AI 会不会写。

而是：

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

这就是精确性问题。

---

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

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

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

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

例如：

只允许修改 src/login/

禁止修改 database/

不能新增依赖。

现有 API 不得变化。

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

测试则更进一步。

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

PASS

或者：

FAIL

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

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

---

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

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

可以从：

帮我做一个登录系统。

逐步下钻到：

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

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

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

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

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

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

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

Abstraction without loss of controllability.

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

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

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