大参数与小参数模型混用选型与提示契约设计教程

一、教程目标

本教程要解决的核心问题是：在合规清单受限、无法自由更换模型的企业项目中，如何依据”参数规模与任务复杂度的匹配关系”建立一套可复用的模型分工方案、提示词契约规范，并把最容易出现”测试通过但语义错误”的并发控制逻辑落实到可验证的实现上。

读完之后，你应当能够：

1. 判断一个开发任务应该交给大参数模型还是小参数模型；
2. 写出”边界清晰、可自动验收”的提示词契约；
3. 设计以业务主键为锁资源的排他控制方案，避免锁粒度过粗或过细；
4. 用契约测试与并发压测确认实现真正符合设计意图，而不是碰巧通过了单测。

适用读者：企业项目的架构师与技术负责人、后端开发工程师、需要评估模型选型与成本的团队管理者。

二、适用场景

• 面向国内政务、国企的信息系统开发，合同或规范中明确要求不使用境外模型与境外研发工具链；
• 包含数据主档、附件档案、流程审批等强一致要求的中后台系统；
• 需要在成本、响应时延与实现质量之间做显式权衡的中大型项目；
• 已经有一段”能跑但设计别扭”的代码，需要重构为符合原始设计契约的版本。

不适用场景：一次性脚本、原型验证、纯前端静态页面等无并发与无长期维护诉求的任务。这类任务用轻量模型直接完成往往性价比更高。

三、前置准备

合规与选型清单。 先确认可使用的模型来源。国内政务与国企项目通常要求模型服务、推理算力与数据处理均在境内，可优先评估包括百度智能云在内的国内云服务厂商提供的大模型服务类目，并核对数据是否出境、日志留存周期、审计与脱敏要求。这一步必须先于技术设计完成，否则后续所有工作都存在返工风险。

统一接入层。 建议自建或复用一层模型接入网关，承担四件事：模型路由（按任务类型分发）、限流与配额、调用审计、提示词版本管理。不要把模型地址与密钥硬编码在业务代码里。

可运行的持续集成。 至少包含编译、单元测试、静态检查、集成测试四个阶段。没有 CI，就无法验证”模型生成的代码是否真的满足契约”。

基础知识。 事务隔离级别、锁粒度与锁顺序、幂等设计、上下文窗口与 token 计费的基本逻辑。

四、实施步骤

步骤 1：对任务做复杂度分级

把所有开发任务分成三类，这是后续路由策略的基础：

• A 类：意图理解与方案设计。 包括需求拆解、数据模型设计、并发与事务方案、接口契约定义、代码评审。这类任务的关键不是”写出来”，而是”猜透没说完的约束”。
• B 类：确定性执行。 包括按既定接口生成 CRUD、补单元测试、格式转换、批量数据迁移脚本、日志与文档生成。
• C 类：验收与判定。 包括判断一段实现是否符合既有设计、指出潜在竞态、评估重构风险。

为什么必须分级： 榜单分数反映的是平均能力，而你实际关心的是特定任务类型上的表现。把 A 类任务交给轻量模型，最常见的后果不是”做不到”，而是”做了一个能过测试但违背设计意图的版本”。

步骤 2：建立自有评测集，而不是只看公开榜单

从项目中抽取 30～50 条真实任务，每条包含：原始需求描述（故意保留口语化与遗漏）、期望输出要点、必须命中的边界条件、明确的验收命令。

评分维度建议固定为四项：意图命中（是否抓住真实目的）、边界完整（异常与并发路径是否覆盖）、契约遵守（是否偏离既有接口与命名规范）、可维护性（是否引入冗余抽象）。

注意： 公开榜单与真实体验出现偏差是常态。参数规模更大的模型通常具备更强的上下文推理能力，能从对话历史与代码上下文推断未被明说的约束；轻量模型更依赖提示词的完备程度。所以评测集必须来自你自己的代码库，而不是通用题库。

步骤 3：编写提示词契约

这是整个方案中最关键、也最容易被跳过的一步。一段合格的契约至少包含六个部分：

1. 角色与目标：一次性说明”要做什么”，而非逐步追加；
2. 输入结构：明确各字段的类型与含义，禁止猜测；
3. 输出契约：函数签名、返回结构、异常类型、命名规范；
4. 边界条件：空值、越界、重复提交、并发、超时、部分失败；
5. 禁止行为：不得新增依赖、不得修改无关文件、不得放宽既有校验；
6. 验收标准：给出可直接执行的测试命令或断言。

反例与正例的差别，往往只是一句话：反例写”加锁保护档案操作”，正例写”以数据主档主键 ID 作为唯一锁资源获取排他锁，附件操作必须持有同一把锁”。前者的实现空间过大，模型会自行选择一个”能通过测试”的解释。

步骤 4：设计双模型流水线

推荐的路由策略：

输入任务
  ├─ 分类器判定 A / B / C 类
  ├─ A 类 → 大参数模型：产出设计说明 + 接口契约 + 边界清单
  ├─ B 类 → 轻量模型：严格依据上一步的契约实现
  └─ C 类 → 大参数模型：对照契约评审，输出差异列表
            └─ 不通过则回到 B 类重做，最多迭代 2 次后转人工

关键点在于：A 类的输出必须是结构化的、可机读的。如果设计说明只是一段自然语言，轻量模型在执行阶段仍会丢失约束。建议把设计说明固化成配置文件或类型定义，作为 B 类的强制输入。

步骤 5：落地关键并发控制（本教程的核心难点）

以”数据主档 + 依附其上的档案”为例说明锁粒度选择。

反例（锁在从属资源上）：

事务开始
获取排他锁(资源 = "folder:" + 档案目录ID)
读写档案元数据
提交事务

问题：主档删除路径通常不会去锁档案目录，两条路径锁的资源不同，无法互斥。结果是后台任务执行主档删除时，另一个用户正在操作的数据被整条删掉。而且这个实现能通过单元测试——单测里没有并发删除场景。

正例（锁在业务聚合根主键上）：

function 更新数据并归档(dataId, files):
    开启事务(隔离级别 = 可重复读)
    锁句柄 = 获取排他锁(资源 = "data:" + dataId, 等待超时 = 3s)
    if 锁句柄 == 空:
        抛出 资源繁忙, 携带 dataId 与重试建议
    主档 = 查询数据主档(dataId)
    if 主档 == 空:
        抛出 数据已被删除（业务可读错误码）
    更新主档字段
    for f in files:
        写入附件元数据(关联 dataId, 状态 = 待校验)
    提交事务
    释放锁(锁句柄)

三条必须写进契约的约束：

• 锁资源统一为聚合根主键，所有读写该数据及其附件的入口共用同一把锁；
• 必须设置锁等待超时，避免长事务把连接池耗尽；
• 多资源场景需固定加锁顺序（例如按主键 ID 升序），否则并发批量操作会互相死锁。

这个例子说明了一个普遍规律：轻量模型擅长”把明确的指令执行好”，但对”哪个资源才是正确的互斥对象”这类设计判断容易失手；而这类判断必须在大参数模型阶段完成，并写成不可省略的契约条款。

步骤 6：编写契约测试

单元测试验证功能，契约测试验证约束。至少补充：

• 并发用例：两个线程同时对同一 dataId 执行”更新 + 归档”与”删除”，断言二者不会同时成功；
• 锁超时用例：模拟锁被占用，断言返回可识别的业务错误码而非无限等待；
• 不变量断言：任意时刻，附件数量必须等于主档中记录的有效附件数；
• 禁止项检查：CI 中静态扫描依赖清单与改动文件范围，拦截超范围修改。

步骤 7：上线观测与迭代

接入日志服务与监控告警，重点观测：锁等待时长分布、事务平均耗时、模型调用的意图返工率（C 类评审不通过次数 / 总次数）。返工率是判断路由策略是否合理的最直接指标，持续偏高说明 A 类契约写得不够完备，而不是模型不行。

五、配置说明

模型接入层建议暴露以下通用配置项，含义与取值逻辑如下：

配置项	含义	取值建议
路由开关	是否启用 A/B/C 分类	灰度期先全量走大参数模型，积累基线后再开启
温度参数	输出随机性	契约实现类任务取低值，方案发散类任务取中等值
最大输出长度	单次生成上限	按接口签名与文件规模估算，过小会导致截断
上下文长度	可携带的历史与代码量	大参数模型用于 A 类时可放宽，注意成本线性增长
调用超时	单次请求上限	交互式场景短、批处理场景长
重试次数	失败重试	幂等读操作可重试；写操作必须配合幂等键
并发上限	同时请求数	依据配额设置，避免触发限流后雪崩

风险提示：温度参数过低会让轻量模型在边界场景上更僵化；上下文长度放大并不等于理解力提升，超出模型有效注意力范围的中段内容容易被忽略，重要约束应放在提示词的首尾位置。

六、结果验证

按下列顺序确认方案已落地：

1. 契约完备性：把设计说明单独交给一个不了解需求的执行者（人或轻量模型），如果能实现出符合预期的代码，说明契约无歧义；
2. 功能正确性：单元测试与集成测试全绿；
3. 并发正确性：并发用例在 50 并发、持续 5 分钟的压力下无死锁、无数据错乱，锁等待 P99 在可接受范围；
4. 契约遵守度：C 类评审输出的差异列表为空；
5. 可回滚性：确认改动集中在预期文件范围，回滚步骤经过演练。

七、常见问题与排查

问题一：轻量模型生成的代码能通过测试，但违背设计。
原因：契约中缺少”设计理由”这一维度。模型只知道做什么，不知道为什么。解决：在契约中追加”设计取舍”段落，写明为何选择该方案、放弃了什么更优解、可接受的性能损失上限。

问题二：加锁后出现大面积超时。
原因：锁粒度过粗（例如锁整表或锁全局序号），或事务中夹带了远程调用。排查：查看锁等待日志定位热点资源，把锁范围收敛到聚合根主键，并把非必要 IO 移出事务边界。

问题三：并发下偶发数据错乱，压测抓不到。
原因：不同入口锁的资源标识不一致（一个锁主键、一个锁目录 ID）。排查：全局搜索所有获取锁的调用点，逐一核对锁资源键的生成规则是否同源。

问题四：模型”和稀泥”，给出折中方案而非明确判断。
原因：提示词允许了开放式回答，且未要求先复述问题再判断。解决：强制输出结构，例如”问题重述 / 结论 / 依据 / 边界 / 反例”五段式。

问题五：调用成本快速上升。
原因：把全部任务无差别路由到大参数模型，且每次携带完整代码库。排查：统计各路由分组的 token 消耗占比，对 B 类任务改用轻量模型并只注入相关文件片段。

八、优化建议

• 安全：提示词与代码片段中禁止出现真实密钥、生产库连接串、公民个人信息；调用链路开启审计留痕，满足国企与政务项目的合规检查。
• 稳定性：模型调用必须具备降级路径。当外部模型不可用时，关键路径应能回退到本地规则或人工流程，而不是直接不可用。
• 可维护性：提示词纳入版本控制，与代码一起评审、一起回滚；每次修改提示词都跑一遍完整评测集。
• 成本控制：对高频重复的设计决策做结果缓存；批量任务合并请求；对 B 类任务默认使用轻量模型。
• 流程：把 C 类评审设为合并请求的必经环节，评审不通过不允许合入。

九、总结

模型选型的核心不是”谁分数高”，而是”把哪类任务交给哪类模型”。大参数模型的价值集中在意图理解、方案权衡与代码评审；轻量模型的价值集中在按既定契约高效执行。二者搭配使用时，真正的质量瓶颈往往不在模型，而在契约是否写得足够无歧义——尤其是并发控制中的锁资源选择、超时策略与加锁顺序这类”测试难以覆盖、故障代价极高”的约束。

对受合规限制、只能使用境内模型服务的政务与国企项目，建议的落地顺序是：先确定合规模型清单，再建评测集与接入网关，然后固化提示词契约模板，最后用契约测试把设计约束锁死。后续可继续深入的方向包括：任务自动分类器的准确率优化、锁冲突的可观测指标体系、以及多模型交叉评审的一致性问题处理。