Skeleton Coding：用程序结构驯服AI编程智能体

给AI编程智能体提供测试用例和输入输出示例，是当前主流的交互方式。但一个根本性的问题常被忽略：开发者到底需要提供多少规格说明，才能让智能体产出符合预期的程序？最近一项名为“Skeleton Coding”的研究给出了反直觉的答案——这取决于实现结构，而结构恰恰是智能体自己决定的。

当行为规格遇上结构不确定性

传统上，我们通过端到端的行为规格（测试、示例）来约束智能体。但论文指出，智能体首先会承诺一种结构——将程序分解为数据类型、模块和函数——这实质上固定了一类候选程序。行为规格则是在这个类中挑选具体实现。问题在于，对一种结构足够的测试，对另一种结构可能远远不够，需要不同的边界用例甚至指数级更多的示例。

“由于结构由智能体选择，开发者无法确保规格完整，除非从数千行生成的代码中反向工程出结构。”

这解释了为什么有时大量测试仍然无法阻止智能体偏离意图：结构错了，再多行为约束也是事倍功半。

行为规格（behavioral specification）指通过输入输出对、测试用例或断言来描述程序“应该做什么”，而不规定“如何实现”。在软件工程中，它属于黑盒规约：只要程序对所有测试输入都给出正确输出，就被认为符合规格。然而，行为规格的完备性依赖于输入空间覆盖，对于复杂程序，穷举所有边界条件往往不可行。当智能体自行选择程序结构时，同一行为规格在不同结构下对应的测试充分性差异巨大，这正是文中“结构不确定性”问题的根源。

程序结构在此指将功能分解为数据类型、模块、函数及其调用关系的组织方式。结构决定了候选程序的空间：例如，用递归还是迭代、用状态机还是管道、用单一函数还是多模块协作，会直接改变需要验证的边界条件集合。文中“固定了一类候选程序”意味着结构选择等价于在无限程序空间中划出一个子集，行为规格只能在该子集内做筛选。因此，结构错误会导致即使大量测试也无法排除不符合意图的实现。

Skeleton Coding：让开发者与智能体共同指定结构

Skeleton Coding 的核心思想很直接：开发者在提供行为规格的同时，用高层、类代码的格式指定程序结构（即“骨架”）。这样，结构和行为规格共同作用，大幅缩小候选程序空间。

理论层面，论文将AI辅助编程建模为控制问题，并证明骨架可以将开发者需要提供的测试数量指数级减少，从而引导智能体走向可接受的程序。

实证方面，在四个模型和三个基准测试上，表现最佳的骨架规格相比最佳端到端行为规格，平均测试误差降低了48.4%。即使智能体可以查询完整的参考实现，加入骨架后平均测试误差仍相对降低高达27.0%。

骨架（skeleton）在编程语境中通常指仅包含类型签名、模块声明、函数头及关键数据结构的代码框架，不含具体实现逻辑。它类似于建筑图纸中的结构梁柱，规定“有哪些组件、如何连接”，但不决定“每个组件内部怎么砌砖”。Skeleton Coding 中的骨架以“高层、类代码格式”呈现，既足够形式化以便智能体解析，又不过度约束实现细节。开发者提供骨架后，智能体只需填充函数体，从而将搜索空间从“任意程序”缩小到“符合给定结构的程序”。

骨架带来的额外收益：缩小模型差距与降低成本

除了降低测试误差，骨架还带来两个值得关注的效应。

其一，它显著缩小了小模型与大模型之间的平均差距，幅度约为52.4%。这意味着借助结构先验，能力较弱的模型也能产出更接近大模型质量的代码。

其二，实现成本降低了15–26倍。这可能是因为结构明确后，智能体无需在多个可能的结构之间反复试探，减少了生成和验证的开销。此外，骨架平均减少代码侵蚀（code erosion）24.7%，说明生成代码的长期可维护性更好。

代码侵蚀（code erosion）指在迭代开发或智能体反复生成修改过程中，代码逐渐偏离原始设计、可维护性下降的现象，表现为重复逻辑增多、模块边界模糊、命名不一致等。骨架作为显式的结构契约，为后续每次生成提供了稳定的参照系，智能体在填充实现时更不容易引入结构性劣化。因此骨架不仅提升单次生成质量，还能在长期协作中减缓代码库的退化速度。

对开发者的启示

这项研究传递了一个清晰信号：与其把精力全部花在编写更详尽的测试上，不如先花时间勾勒出期望的程序结构。骨架不是要取代测试，而是与测试互补——结构决定候选空间，测试在其中做选择。

对于日常使用AI编程助手的开发者，这意味着一个可操作的实践：在让智能体写代码之前，先用伪代码或模块划分描述你期望的架构。这可能会成为与AI协作的新习惯。

局限与展望

论文的实证覆盖四个模型和三个基准，结论具有参考价值，但骨架的编写本身需要开发者投入认知成本。如何设计既不过度约束又足以引导的骨架，以及骨架在不同编程范式下的通用性，仍是值得探索的方向。