AI Coding is a framework, and...

piglei在AI Coding Is a “Framework”中提出了一个精准的观察：AI Coding本质上是一个框架，具有框架的所有固有问题 – 抽象泄漏和控制权丧失。他进一步建议我们应当以library而非framework的心态来使用AI，保持对程序结构的控制权。

这个「框架」视角值得继续展开。除了「怎么用」之外，还有一个问题：如果AI Coding确实是一个框架，这个事实本身意味着什么？

人们在使用AI编程的时候，实际上是在用自然语言调用一个框架。观察一下AI Coding的使用方式：你描述意图（自然语言API），提供上下文（配置），AI根据内部机制生成代码（框架行为），你review输出（验收）。这和调用Spring、React、Rails的模式是同构的 – 区别只是接口从编程语言变成了自然语言。

一旦接受这个前提，很多关于AI编程的困惑就有了框架理论下的自然解释。

框架的铁律：抽象必然泄漏

Joel Spolsky在2002年提出的抽象泄漏定律(The Law of Leaky Abstractions)指出：所有非平凡的抽象都会在某种程度上泄漏。SQL隐藏了查询计划，但你迟早要理解索引。React隐藏了DOM操作，但你迟早要理解reconciliation。Spring隐藏了对象生命周期，但你迟早要理解Bean的作用域和循环依赖。

AI Coding也不例外。它隐藏了”把设计变成代码”的过程，但这个抽象会泄漏。而且它的泄漏方式比传统框架更棘手：

传统框架泄漏时，你有trace。 Spring抛异常时有完整的stack trace，React的DevTools能让你看到组件树和渲染周期。你知道泄漏发生了，也知道去哪里找原因。

AI Coding泄漏时，你没有trace。 它生成一段看起来正确的代码，编译通过，基本功能正常，但在某个边界条件下会静默出错。你甚至不知道泄漏已经发生了 – 直到生产环境暴露问题。这种概率性的、无信号的泄漏，比传统框架的确定性错误更难应对。

想做好饭，有了现代厨具（烤箱、空气炸锅、微波炉）以后，入门门槛降低了，但想做出真正好的菜，最终还是要理解美拉德反应、水分蒸发速率、蛋白质变性温度。厨具降低了操作门槛，没有降低原理门槛。框架也一样。

框架的API：自然语言

传统框架的API有类型签名、参数校验、返回值定义。你调错了会编译失败或抛异常。

自然语言作为API没有这些约束。同一句话在不同context下可能触发完全不同的行为。没有类型检查告诉你”你的需求描述缺少了关键参数”，没有编译器提醒你”这个意图是歧义的”。

这意味着使用AI Coding这个框架的调试成本,集中在输入侧而非输出侧。传统编程中bug出在代码里，你调试代码。AI编程中”bug”经常出在你的描述里 – 你以为说清楚了，其实有三种合理的解读，AI选了你没想到的那种。

Context engineering、AGENTS.md、rules文件 – 这些实践的本质是在为一个没有类型系统的API补充约束。它们是自然语言框架下的”类型声明”。

框架的使用效率不对称

作为生产力工具来看,AI Coding有一个反直觉的特征：它帮助强者更多,帮助弱者更少。

大多数生产力工具是反过来的。拼写检查对拼写差的人帮助更大。代码格式化工具对所有人效果差不多。这些工具的共同特征是缩小差距。

AI Coding则放大差距。有经验的开发者能快速分解任务、设定清晰的约束、评估生成代码的质量、在泄漏发生时诊断问题。他们把AI当作一个被良好配置的框架来使用，获得5-10倍的效率提升。经验较少的开发者缺乏这些能力，往往在”生成-不对-重试”的循环中消耗大量时间，效率提升远小于预期。

这恰恰是框架的行为模式，而非工具的行为模式。熟悉Spring原理的人用Spring如虎添翼，不熟悉的人被Spring折磨。这个规律在AI Coding上完全成立。

以局部、定义良好的任务来看，AI Coding确实表现为生产力工具 – “把这个函数从回调改成async/await”、”给这个接口写单元测试”，这些任务规约完整，输出容易验证，谁用谁快。但在系统级任务上 – “重构这个模块的错误处理”、”设计一个消息消费者的重试策略” – 规约天然不完整，输出的正确性依赖领域知识来判断。此时AI就是一个框架，使用者的水平直接决定产出的质量。

分界线在于：任务的规约是否完整。 规约完整时是工具，规约不完整时是框架。而大多数有价值的工作，规约天然是不完整的。

“一句话做产品”：过度抽象

“一句话做产品”是框架思维下的自然推论走到了极端：如果AI是一个可以用自然语言调用的框架，那能不能只用一句话调用一次，就得到一个完整产品？

不能。原因不是模型能力不够，而是抽象层级过高，泄漏是必然的。

产品不是由一句话定义的，而是由上万个微决策构成的。”任务逾期了怎么通知”、”用户删除数据后保留多久”、”并发编辑时冲突怎么解决”、”移动端和桌面端的交互差异”。这些不是实现细节，而是产品本身。每一个未被显式规约的决策，框架都会用默认行为填充 – 而默认行为约等于”AI对这个问题的平均想象”。

这就像你不可能用一行配置文件驱动Spring做出一个完整的业务系统。不是Spring不够强，而是那些业务规则无法被压缩进一行配置。函数签名容纳不了那么多信息。

“一句话做产品”的尝试者通常会进入一个循环：生成 -> 不是我想要的 -> 补充描述 -> 还不对 -> 再补充 -> … 这个循环的本质是在做需求分析 – 把模糊的意图逐步精确化为规约。他们没有跳过产品设计，只是换了一种方式在做产品设计，而且是一种效率很低的方式，因为自然语言没有类型系统来帮助他们发现规约中的遗漏。

复杂度守恒

框架不消灭复杂度，只搬运复杂度。这是软件工程几十年来反复验证的规律：

• 汇编到高级语言：消灭了手动内存管理的复杂度，搬到了理解垃圾回收和运行时行为上
• SQL：消灭了手写查询计划的复杂度，搬到了理解索引设计和查询优化上
• No-code平台：消灭了写代码的复杂度，搬到了平台约束和定制化困难上

AI Coding：消灭了”把设计变成代码”的复杂度，搬到了”规约是否精确”和”输出是否正确”的判断上。

每一代工具都把复杂度从操作层搬到了认知层。以前你需要能写代码（操作），现在你需要能判断代码对不对、设计合不合理（认知）。操作可以被工具替代，认知很难。

这也解释了为什么AI Coding作为框架是不对称的：操作能力的差距被工具抹平了，但认知能力的差距被暴露出来了。以前你可以通过”写出能跑的代码”来证明自己的价值，现在这一步几乎免费了，你需要通过”判断代码是否正确、设计是否合理、系统是否可靠”来证明价值 – 这些东西以前被实现成本掩盖着，现在无处可藏。

And…

回到标题。AI Coding is a framework, and:

…抽象必然泄漏。 泄漏时你需要能接住，这需要理解抽象之下的东西。

…框架放大使用者之间的差距。 善用框架需要比框架知道的更多，这在所有框架上都成立。

…一句话做不了产品。 因为产品是上万个微决策的集合，一次函数调用容纳不了这些信息。

…复杂度不会消失，只会搬家。 从操作层搬到认知层，从实现搬到规约和判断。

…理解原理变得更重要，而不是更不重要。 当实现成本趋近于零时，瓶颈暴露在设计和验证上。这些能力的根基是对系统行为、失败模式、抽象边界的理解 – 即原理。

程序员不需要恐惧AI Coding这个框架，就像不需要恐惧Spring或React一样。需要做的是理解它的工作方式、边界在哪里、什么时候会泄漏、泄漏时怎么办。这是使用任何框架的基本功。

而理解一个框架最好的方式，从来都是自己造一个。构建自己的Agent SDK、Agent CLI，哪怕只是一个简单的tool calling loop，都会让你对context window的限制、tool dispatch的成本、prompt与行为之间的映射关系有切身的体感。这种体感是任何文档和教程都给不了的。

这也是我在做ya-agent-sdk时的感受：当你亲手处理过context截断、subagent协调、tool权限控制这些问题之后，再回到使用侧，你对框架泄漏的嗅觉会完全不同。不是因为你变聪明了，而是因为你见过抽象之下的东西。