AutoDesign：外部脚手架如何让弱模型逼近前沿模型

AutoDesign 这个方向的核心命题并不复杂：当团队没有足够的预算调用前沿模型，或者对数据隐私有严格要求、必须把模型部署在私有环境时，能不能通过一套外部脚手架，把弱模型（weak model）的能力拉高，使其在特定任务上的表现逼近前沿模型（frontier model）？在不少团队的实践中，这类方案已经从纯提示工程演变为包含任务拆分、知识检索、结果校验和自动回退的完整工程范式。AutoDesign 要解决的问题，就是让这套脚手架不再依赖人工反复调试，而是由系统根据任务自动设计出来。

这篇文章面向正在做私有化模型落地的工程师、大模型应用开发者，以及想理解“小模型如何通过外部机制弥补能力不足”的学习者。读完可以收获三件事：第一，理解脚手架为什么能补足弱模型的能力缺口；第二，掌握一套可运行的最小脚手架实现；第三，学会用对比实验和日志验证“逼近前沿模型”是否真的成立。

1. 先理解 AutoDesign：为什么弱模型需要脚手架

1.1 弱模型与前沿模型的差距在哪里

弱模型并不是“完全不能用”，而是它的能力边界相比前沿模型更明显。参数规模小的模型，在记忆世界知识、长上下文推理、指令跟随、复杂格式生成和错误自纠正上都会出现断档。前沿模型之所以强，并不只是参数量大，而是训练数据、对齐方式、工具调用能力以及推理能力都被调整到了更高水平。对应用开发者来说，最直接的感受是：同一个提示词，强模型能一次生成可用的结果，弱模型可能需要多轮修正，或者直接生成错漏内容。

要设计脚手架，先要清楚差距分布在哪。下面表格列出常见差距维度，后续模块会对照着解决。

这里的主线是：把模型做不好的部分外包给系统，而不是继续训练它。

1.2 脚手架的本质：把模型能力缺口转移到外部系统

脚手架（scaffold）在软件工程里的原意是临时支撑结构，帮助主体完成施工过程，完成后可以拆掉。在 AutoDesign 里，它指一套不依赖模型自身能力的流程：输入一个复杂任务后，由旁路系统完成拆分、检索、校验、重试和兜底，模型只负责其中“生成候选内容”这一环。

这样做有两个好处。第一，弱模型还是同一个模型，不需要重新训练，成本和部署方式都不变，只是调用方式变了。第二，质量风险从模型内部移到了外部流程，外部代码可以被测试、被回滚、被监控，比调整模型权重更容易定位问题。它把“模型能力不够”的问题，转换成“流程设计不够好”的问题，而后者是工程团队更习惯处理的。

需要强调一个容易误解的点：脚手架不是提示词套壳。提示词只是把上下文拼接好，脚手架还要负责决策下一步动作。例如，模型生成了一个 JSON，提示词层只能提示“请输出合法 JSON”，脚手架却可以解析 JSON、发现字段缺失、把错误信息连同原结果一起送回模型要求补全。

1.3 AutoDesign 的定位：自动设计脚手架

如果脚手架是手工搭建的，那么每个新任务都需要人工写拆分规则、选检索字段、定义校验条件。AutoDesign 把这一层也自动化：给一个任务描述，系统自动选择一个合适的流程，或者搜索一组子模块配置。这种自动化可以有很多具体形式：

• 配置搜索：把拆分粒度、检索 top-k、校验规则、最大重试次数作为超参数，在样例集上自动寻优。
• 流程生成：让强模型离线生成不同任务的拆分模板，再在弱模型上评估模板效果。
• 反馈学习：记录每次校验失败的原因，逐步调整下一次的提示词或拆分方式。

AutoDesign 不一定要求全部自动。实际项目里可以先从“半自动”开始：人工搭一套脚手架，AutoDesign 负责针对新任务自动调参。这样既能获得自动化收益，又不至于在核心链路上失去控制。

2. 脚手架的四个核心模块：拆分、检索、验证、回退

2.1 任务拆分：把复杂问题降维

弱模型处理长任务的失败率很高，原因之一是模型注意力在长上下文中会漂移，二是复杂任务需要多步决策，任何一个中间步骤出错都会导致最终结果失败。任务拆分的作用是把一个高方差任务变成多个低方差子任务，再把子任务的结果合并。

拆分的常见做法有三种。第一种是模板拆分：根据任务类型套用固定结构，比如写代码任务固定拆成“设计数据结构、实现函数、编写测试”。第二种是模型拆分：用强模型或一个专门的调度模型把用户请求拆成子任务清单。第三种是规则拆分：通过正则、标题识别、语义分段等方式把长文本拆分。实际工程里往往混合使用。

一个关键参数是拆分粒度。拆得太粗，子任务仍然复杂，弱模型仍然失败；拆得太细，子任务之间的依赖变多，合并成本高，还会放大错误传播。建议的原则是：每个子任务能被一条清晰的指令描述清楚，并且弱模型单独执行时能达到可接受成功率。表格式速查：

2.2 知识检索：补充模型缺失的上下文

弱模型的参数化知识通常不如前沿模型丰富，尤其在特定业务域、产品文档、私有数据等场景下。知识检索模块就是为了补充这部分上下文。常见方式是 RAG：把文档切块，用 embedding 模型转换成向量，查询时召回 top-k 片段，再拼到提示词里给模型参考。

这里要注意，检索不是“越准越好”。如果召回的片段和问题相关性弱，反而会干扰模型生成。建议在检索后增加重排步骤，并对上下文容量做裁剪。弱模型能够承载的上下文长度往往有限，不能把大量检索片段全部塞进去，否则会挤占生成空间。核心参数包括：

在 AutoDesign 里，检索模块的参数也应当成为可调项。搜索目标不是“召回准确率最高”，而是“最终答案质量最高”。

2.3 校验器：给弱模型装上质量守门员

弱模型生成错误后往往没有自我察觉能力，因此必须引入外部校验器。校验器可以有多种形态：

• 规则校验：检查 JSON 合法性、必填字段、长度限制、格式正则。
• 可执行校验：代码任务运行单元测试，SQL 任务在测试库执行并比对结果。
• 模型校验：使用一个小分类器或同一模型的另一个提示词判断答案是否满足要求。这种做法要小心，弱模型自评容易高估自己。
• 逻辑一致性校验：对数学问题用符号计算验证，对结构化输出用 schema 校验。

校验结果需要同时包含“通过/不通过”和“错误细节”。错误细节会被重新注入到模型的提示词中，让模型知道哪里需要修改。迭代上限通常设置为 1-3 次，超过后进入回退流程，避免模型无限重试。

注意：校验器的核心价值不是过滤坏结果，而是提供可执行的反馈信号。如果没有反馈，重试只是重复犯错。

2.4 回退策略：让异常分支有兜底

即使有拆分、检索和校验，也不能保证每次生成都成功。脚手架必须预定义回退策略。常见的回退路径有三种：

• 同模型重试：清空部分上下文，换一个提示词模板重新生成。
• 升级模型：当校验连续失败，降级到更强的模型接口，只对失败子任务调用，控制成本。
• 人工介入：把失败样本写入队列，由人工修正后回填。

在生产系统中，回退策略要和成本配额关联。例如，弱模型重试 2 次失败后，允许调用 1 次前沿模型；前沿模型也失败时，返回可读错误并记录样本。这个配额可以通过配置中心动态调整。

3. 最小可运行示例：用脚手架让弱模型完成一个复杂任务

3.1 场景选择与实验设计

为了把概念落地，这里用一个最小场景演示：让弱模型输出一个包含指定字段的 JSON 配置，并且字段值要来自外部知识库。直接让弱模型生成时，它常常漏字段，或者把字段值猜错。加上脚手架后，流程会变成：

1. 拆分器识别出需要生成的是“服务器部署配置”。
2. 检索器从配置文件样例里召回默认端口、协议、超时时间。
3. 弱模型基于检索结果生成 JSON。
4. 校验器解析 JSON，检查必填字段和值类型。
5. 如果失败，把错误信息返回给模型重试，最多 2 次。

这个示例不是为了展示完整生产系统，而是为了让理解 AutoDesign 的人能快速跑通闭环。实际项目中，替换成自己的任务和校验规则即可。

3.2 环境准备与依赖

建议使用 Python 3.9 及以上版本。下面的 requirements.txt 只包含演示所需依赖，如果只是本地跑 mock，可以不安装真实模型 SDK。

openai>=1.0.0 pydantic>=2.0.0 python-dotenv>=1.0.0

如果还没有模型 API，可以把模型调用函数写成 mock，返回容易出错的固定结果，用来观察脚手架如何纠正。这样也可以完整跑通流程。

3.3 脚手架主流程代码

下面代码用一个Scaffold类封装拆分、检索、生成、校验、重试流程。为了方便阅读，每个模块都写成一个子函数。

import json from typing import Any def weak_model_generate(prompt: str) -> str: """弱模型生成函数。 真实项目里这里替换为本地模型或 API 调用。 这里使用 mock 模拟一个容易漏字段的弱模型。 """ if "配置示例" in prompt: return ( '{"server_name": "demo", "port": 8080, ' '"protocol": "HTTP", "timeout": 30}' ) return '{"server_name": "demo"}' def retrieve_context(query: str) -> str: """从外部知识库检索配置示例。""" return ( "标准部署配置示例：\n" "server_name: 必填，字符串\n" "port: 必填，整数\n" "protocol: 必填，HTTP 或 HTTPS\n" "timeout: 选填，整数，默认 30" ) def validate_json_config(content: str) -> tuple[bool, str]: """校验生成的 JSON 配置是否满足要求。""" try: data = json.loads(content) except json.JSONDecodeError as exc: return False, f"JSON 解析失败: {exc}" errors = [] if not isinstance(data.get("server_name"), str): errors.append("server_name 缺失或类型错误") if not isinstance(data.get("port"), int): errors.append("port 缺失或类型错误") if data.get("protocol") not in {"HTTP", "HTTPS"}: errors.append("protocol 必须是 HTTP 或 HTTPS") if errors: return False, "; ".join(errors) return True, "OK" def run_scaffold(task: str, max_retries: int = 2) -> dict[str, Any]: """脚手架主流程。""" query = task context = retrieve_context(query) prompt = ( f"任务：{task}\n\n" f"参考信息：\n{context}\n\n" "请只输出一个 JSON 配置，不要输出其他内容。" ) last_error = "" for attempt in range(max_retries + 1): generated = weak_model_generate(prompt) ok, message = validate_json_config(generated) if ok: return { "success": True, "attempt": attempt + 1, "output": json.loads(generated), "error": "", } last_error = message prompt = ( f"任务：{task}\n\n" f"参考信息：\n{context}\n\n" f"上次输出：\n{generated}\n\n" f"错误原因：{message}\n\n" "请修正后重新输出 JSON。" ) return { "success": False, "attempt": max_retries + 1, "output": None, "error": last_error, } if __name__ == "__main__": result = run_scaffold("生成一个服务器部署配置") print(json.dumps(result, ensure_ascii=False, indent=2))

代码里的weak_model_generate故意写得比较简单，目的是让没有 API 的读者也能运行。真实场景中，应该把它替换成你的弱模型接口，并把校验逻辑改成贴合任务需求的规则。

将scaffold_demo.py保存后运行：

python scaffold_demo.py

正常会输出类似下面的 JSON：

{ "success": true, "attempt": 1, "output": { "server_name": "demo", "port": 8080, "protocol": "HTTP", "timeout": 30 }, "error": "" }

如果第一次生成就是完整 JSON，只有一次尝试；如果第一次漏字段，会重试并显示attempt: 2。这正好能观察到校验器如何工作。

3.4 关键参数说明

脚手架的核心参数决定了它在“速度”和“效果”之间的取舍。下表列出最需要关注的一组参数：

参数之间是联动的。例如增加max_retries会提高成功率，但会线性增加延迟；增加top_k能补更多上下文，但可能引入噪音。AutoDesign 的自动调参就是在这些参数上做搜索。

注意：参数不是越大越好。真正的评测应该看端到端任务成功率，而不是单个模块的指标。

4. 运行验证：如何判断弱模型真的逼近了前沿模型

4.1 评测指标怎么选

判断“逼近”不能只看一两条例子，需要定义指标。对于生成类任务，常见指标包括字段完整率、格式正确率、内容准确率和人类评分。对于问答任务，可以用准确率、F1、pass@k。下面给出一个适合多次复用的指标表：

不要只记录成功率，还需要记录 token 消耗和延迟，因为逼近前沿模型的同时如果成本已经超过直接调用前沿模型，就需要重新权衡。

4.2 对照实验设计

建议至少设置三组基线：

• 弱模型直出：只用一条提示词，不加任何脚手架。
• 弱模型 + 脚手架：使用本文描述的完整流程。
• 前沿模型直出：直接调用更强模型作为上界参考。

每组使用同样的测试集，固定temperature为 0，固定随机种子。如果测试集只有几十条，结果波动会很大，建议至少 50 到 100 条。统计时记录每个样本的成功率、平均延迟和平均成本，最后汇总成表格。

4.3 预期结果与日志分析

演示场景下，假设 100 条配置生成任务的结果如下：

这里不是真实产品数据，只是说明对比口径。可以看到脚手架让弱模型从 68% 提升到 87%，虽然没有完全超过前沿模型，但已经明显逼近，且成本低于强模型。如果成功率仍然不够，可以从日志中看失败集中在哪个环节：拆分失败、检索不到、校验不通过，还是重试耗尽。

日志建议至少包含以下字段：task_id、模块名、耗时、重试次数、校验错误、是否回退、最终成败。这批日志既是排查依据，也是后续 AutoDesign 自动调参的训练数据。

5. 常见问题与排查路径

5.1 问题：拆分后子任务仍答错

现象：任务已经拆成多个子任务，但合并后结果仍然错误，甚至子任务单独输出就是对，合并后就不对。

可能原因有三个：拆分时的上下文丢失；合并阶段没有把子任务结果完整传入；子任务之间存在依赖，但拆分器没有体现顺序。

检查方式：打印每个子任务的输入输出，单独核对。先在合并阶段只拼接不修改，检查是否因为提示词压缩导致信息丢失。如果子任务之间有依赖，需要在上游输出中保留中间结果供下游使用。

解决方案：在拆分模板中显式声明依赖关系；合并前让模型基于子任务结果重新组织，而不是直接拼接；给每个子任务增加“输出格式要求”，减少合并时的歧义。

5.2 问题：脚手架比直接调用强模型还慢

现象：虽然成功率上来了，但端到端延迟比直接调用前沿模型更高。

原因：重试次数太多、检索模块耗时高、子任务串行执行，或者模型本身响应慢。

检查方式：在日志里统计各模块耗时占比，确认主要瓶颈。如果 60% 时间都花在重试上，说明第一步的提示词或检索不够好；如果花在检索上，考虑缓存和向量索引优化。

解决方案：增加缓存，相同问题直接返回历史结果；把可并行的子任务改成并发执行；提高首次生成质量，减少重试。生产环境还可以把 rate limit 和超时拆开配置，避免单次调用拖垮整体。

5.3 问题：校验器误判严重

现象：有的结果实际是正确的，但被校验器判为失败；有的结果生成时没问题，却因为格式错误被要求重试。

原因：校验规则过严，把答案中的合理变体也过滤掉；校验规则过松，导致错误内容进入最终结果；校验器只检查表面结构，没有检查语义。

检查方式：抽样看被拒绝的样本，判断拒绝理由是否合理。记录“准召回失败”和“假阳性”，对比校验器通过后的最终结果质量。

解决方案：把校验器拆成“硬校验”和“软校验”，硬校验负责格式和必要字段，软校验只做降权提示，不直接重试。对可执行任务，优先用测试用例代替规则判断，因为测试结果比文本规则更可靠。

5.4 常见坑汇总

6. 落地 AutoDesign 的最佳实践与扩展方向

6.1 学习环境与生产环境的差异

学习环境可以只关注流程跑通，但生产环境要补很多工程保障。下面表格列出差异：

生产环境尤其要注意：不要把模型返回结果直接拼到提示词里，先做 HTML 转义或 JSON 转义，防止提示词注入。如果脚手架内部使用强模型离线生成拆分模板，要防止模板中的敏感信息在日志中泄露。

6.2 可复用的设计清单

在开始设计 AutoDesign 前，可以参考下面的清单逐项确认：

• 是否已经明确了任务的成功标准？没有标准，后面所有调优都无法判断。
• 是否列出了弱模型最常失败的三类现象？脚手架要优先覆盖它们。
• 每个子任务是否都有独立的输出格式和校验逻辑？不要用一个总校验器处理所有问题。
• 是否设置了重试上限和回退路径？系统不能依赖“多试几次”来解决问题。
• 是否收集了失败样本？失败样本是最有价值的调优数据。
• 是否对比了成本？脚手架总成本不能超过直接调用前沿模型太多。
• 是否做了回归测试？每次修改脚手架后，跑同一套测试集比较结果。

6.3 扩展方向：从提示词脚手架到自动化工具

AutoDesign 的最终形态是让脚手架自动生长。常见扩展路径有三个。一是参数搜索：在评测集上自动搜索 top_k、max_retries、temperature 等参数。二是流程搜索：让强模型离线生成多种候选拆分模板，在弱模型上评估后保留最优模板。三是闭环反馈：把每次校验失败原因写入样本库，定期用样本库更新检索知识库和校验规则，让系统随时间越来越稳定。

在实际项目里，建议先用最小步骤验证收益。第一步，只加一个校验器和重试机制，看弱模型成功率提升多少；第二步，加入检索或拆分；第三步，才考虑 AutoDesign 的自动调参。不要一开始就试图做到完全自动化，因为缺乏可观察的中间指标时，自动化只会放大错误。

一个值得记住的原则是：弱模型逼近前沿模型，不是靠让弱模型变得更聪明，而是靠让执行任务的系统变得更稳定。AutoDesign 的意义不在于取代强模型，而在于提供一种工程上的中间路线：当你无法承担前沿模型成本，或者必须私有化部署时，用它把弱模型的效果推到可接受水平。

最后，如果要给初学者一个练习建议，可以从“不加脚手架”和“加校验重试脚手架”两组对比实验开始。先体会差距，再从失败样本里找下一个模块应该补在哪里。这条路没有捷径，但每补一个模块，都能看到可量化的提升。