面向国内政企项目的大模型分层选型教程

一、教程目标：解决“选型难、指令一走样、又慢又贵”的工程问题

在一些政企信息化项目中，出于数据安全与合规审查要求，境外商业大模型及其配套的模型调用框架往往被明确限制使用，团队只能在本田可用的境内模型中选择。于是一类典型困境出现了：

• 选型靠榜单：公开评测分数接近，实际写业务代码时体验差距明显。
• 指令容易走样：需求里漏掉一个边界条件，生成的代码“能跑通测试”，却偏离了设计初衷。
• 性能与成本难以平衡：能力较强的大参数模型推理慢、资源占用高，简单任务也交给它处理，既拖慢开发节奏，又浪费算力。

本教程要帮助读者完成以下工作：

1. 建立一套不依赖第三方品牌、可复用的模型选型评测方法，用真实业务需求替代榜单分数；
2. 把开发任务按“理解与设计”与“执行与改写”分层，设计大参数模型与小参数模型的协同工作流；
3. 掌握契约化提示词的编写方法，让模型严格遵守项目的架构约束、事务边界与编码契约；
4. 完成统一模型接入层的搭建与验证，并针对常见问题形成排查思路与优化策略。

读者对象：应用开发者、后端与架构工程师、技术负责人、运维与安全合规人员，以及负责政企项目技术选型的团队。

二、适用场景与能力边界

2.1 适用场景

• 强合规项目：合同或安全审查要求模型推理与数据处理在境内完成，且禁止使用境外模型及配套调用框架；
• 复杂业务系统：数据与档案、流程与权限、台账与报表等实体关系复杂，并发控制要求高的管理系统；
• 长期演进项目：代码需要多人维护、长期迭代，架构一致性与可读性比“一次性生成速度”更重要；
• 资源受限环境：需要本地化或专有云部署，算力规模有限，必须在质量与成本之间精细权衡。

2.2 需要明确的边界

1. 本文讨论“如何选、如何配、如何验证”，不涉及对任何具体模型版本的能力评价；
2. 模型能力持续迭代，文中的分层原则与评测方法可长期沿用，具体模型归类应随每次评测结果动态调整；
3. 所有示例均为通用示意，落地时须替换为团队实际使用的模型接口与技术栈。

三、核心原理：为什么榜单分数接近，实际体验却不同

原始讨论中一个关键观察是：大参数模型往往能“猜透”开发者没有明确说出的真实意图。这背后有三个可解释的工程原因。

3.1 参数规模与意图推断能力

小参数模型的知识容量和推理深度有限，更倾向于“按字面意思执行”：指令写了什么就做什么，没写的部分按最常见的默认做法补全。大参数模型能在更长、更杂乱的上下文中捕捉隐含线索，例如从表结构推断实体关系、从既有代码推断团队编码风格，从而把模糊需求“补全”到更接近开发者本意的方案。

需要强调：这并不意味着小参数模型“理解不了”，而是补全隐含意图所需的上下文成本更高——必须把每一条边界条件都显式写进指令。

3.2 指令模糊度决定了对模型规模的要求

可以用一个粗略的判断框架：

当任务描述中“需要显式交代的边界条件数量”较少时，小参数模型足以胜任；当隐含约束多、跨模块关联复杂、且错误代价高时，应由大参数模型承担。

例如“给这个函数补一批单元测试”属于前者；“在现有并发控制体系下，为数据与档案操作设计一致性方案”属于后者。

3.3 “通过测试”不等于“设计正确”

小参数模型的典型失效模式，不是写不出能运行的代码，而是在缺失约束处自行选择了一个看似合理的默认解。这个解可能通过功能测试，却违反架构设计，并在特定并发时序下暴露严重问题。下文的加锁案例将具体说明这一点。

四、前置准备：环境、权限、数据与评测基线

4.1 确认合规边界与可用模型清单

1. 梳理项目约束：查阅合同、安全审查意见与内部规范，明确哪些模型来源、部署形态（公有云服务、专有云、本地化部署）被允许或禁止；
2. 形成模型清单：为每个候选模型记录部署形态、上下文长度上限、并发限制、数据是否用于训练等关键属性，作为后续选型的输入；
3. 确认配套工具链：智能体执行框架、代码托管平台、制品库、镜像仓库等同样需要纳入合规审查，避免“模型合规、工具链不合规”。

4.2 准备算力与运行环境

• 推理资源：按候选模型的显存需求与预期并发量估算 GPU 卡数与显存余量。常见经验是，为峰值并发预留 30%～50% 余量，避免排队导致交互延迟不可接受；
• 服务组件：模型服务、统一接入层（网关）、日志服务、监控告警等组件应具备容器化部署能力；
• 网络策略：若要求推理不出内网，需提前规划离线镜像仓库、内网域名解析与访问控制策略。

4.3 准备评测数据

评测集质量直接决定选型结论是否可靠。建议从真实项目中脱敏抽取 30～50 个任务，覆盖三类：

类别	目的	示例
意图补全类	考察隐含意图推断	只给表结构与业务背景，要求设计并发控制方案
契约遵循类	考察对显式约束的遵守	给出 10 条编码规范，要求逐条落实
缺陷定位类	考察分析与表达能力	给出一段含缺陷的代码，要求说明原理、影响范围与边界条件

每个任务预先由资深开发者给出“参考解”和“评分要点”，避免评价主观化。

4.4 建立评测基线

在接入任何自动化流程之前，先用人工方式对同一批任务分别运行大、小参数模型，记录首次通过率、约束违反次数、平均响应时长与 token 消耗。这组数据就是后续所有优化的比较基准。

五、实施步骤：从任务分层到协同接入

步骤一：对开发任务做能力分层

做什么：把日常 AI 辅助开发任务划分为两类。

• A 类（理解与设计型）：需求澄清、架构方案设计、数据模型设计、并发与事务边界设计、疑难缺陷根因分析、代码评审意见提炼；
• B 类（执行与改写型）：样板代码生成、单测批量补全、格式规范化、注释生成、已有代码的机械式重构、日志与文档整理。

为什么：A 类任务的核心难点是“在信息不完整时做出正确取舍”，依赖意图推断与跨模块推理；B 类任务约束明确、上下文局部、错误容易通过测试发现。

注意：分层不是按代码量划分。一个只有 20 行的并发控制模块可能属于 A 类，而 500 行的接口样板代码属于 B 类。

步骤二：为两类任务分别选定模型

做什么：结合步骤四的评测基线，为 A 类任务选定 1～2 个意图推断与契约遵循表现更好的大参数模型作为主力，为 B 类任务选定 1 个响应快、资源占用低的轻量模型；每个类别保留 1 个备选，避免单一模型服务故障导致工作流中断。

为什么：政企项目中“大参数模型做设计、轻量模型做执行”的组合，可以在保证关键设计质量的同时，把大部分高频调用的成本压到较低水平。

注意：同一模型在不同部署形态下的表现可能有差异（如量化精度不同），评测必须在实际生产部署形态下进行。

步骤三：编写契约化提示词模板

做什么：把项目中稳定不变的技术契约固化为可复用的提示词模板，而非每次口头补充。推荐结构如下：

【角色】你是本项目的后端开发工程师，遵循团队既有架构。
【目标】<一句话说明本次要完成什么>
【上下文】<相关表结构、已有模块接口、既有实现片段>
【必须遵守的约束】
  1. <技术栈与目录分层规范>
  2. <事务边界与锁粒度要求>
  3. <错误处理与日志规范>
  4. <命名与注释规范>
【禁止事项】
  1. 不得引入未在依赖清单中的第三方库
  2. 不得修改公共基类的既有行为
  3. 不得以“更简洁”为由改变锁的粒度
【输出要求】
  先复述你理解到的全部约束（逐条列出），再给出实现方案与代码
【自检清单】
  实现完成后逐条核对：约束是否全部满足？是否存在未处理的并发时序？

为什么：这一步是弥补小参数模型意图推断能力不足的关键手段。把隐含约束显式化，可以显著降低“自由发挥”的空间。“先复述约束再实现”迫使模型在生成代码前完成一次约束对齐。

注意：约束条目应可验证。写“加锁要正确”无效，写“锁的资源标识必须是业务数据主键，不得为目录或文件夹标识”才可检验。

步骤四：搭建统一模型路由层

做什么：在业务代码与模型服务之间加入一层统一抽象，屏蔽不同模型的接口差异，并实现按任务类型分派。

# 通用路由示意，接口名称需按实际模型服务替换
def dispatch(task):
    if task.category == "DESIGN" or task.ambiguity_level >= 2:
        return large_model_client   # 意图理解与设计类
    return light_model_client       # 机械执行类
def run(task):
    client = dispatch(task)
    prompt = render_contract_template(task)  # 注入契约化提示词
    for attempt in range(MAX_RETRY):
        try:
            resp = client.generate(prompt, timeout=REQUEST_TIMEOUT)
            return validate(resp, task)       # 结构校验 + 契约校验
        except TransientError:
            backoff(attempt)                  # 指数退避
    return fallback(task)                     # 降级到备选模型或人工

为什么：路由层把“选哪个模型”从人工判断变成可配置策略，同时集中处理超时、重试、限流与降级，避免每个业务模块各自对接模型接口。

注意：ambiguity_level（模糊度等级）建议由需求评审环节人工标注，不要交给模型自评——小参数模型的自我评价往往不可靠。

步骤五：为高风险任务增设“评审”环节

做什么：对 A 类任务的产出，增加一次独立评审：把“需求 + 约束清单 + 模型输出”交给另一个模型（或同一模型的独立会话）做审查，重点检查约束违反、并发时序漏洞与边界条件缺失。

为什么：单模型自查存在“确认偏差”，倾向于认可自己的输出。独立评审能捕获相当一部分契约违反问题，这也是大参数模型在“提炼重点、辨析原理与边界”方面相对更有优势的场景。

注意：评审意见仍需人工确认。模型评审用于发现问题，不用于替代责任判断。

步骤六：接入日志、监控与成本核算

做什么：在路由层统一记录每次调用的任务类别、模型标识、输入输出 token 数、耗时、重试次数与校验结果，并配置以下告警：

• 单模型错误率或超时率超过阈值；
• 单位时间 token 消耗超出预算基线；
• 契约校验失败率异常上升（通常意味着提示词模板与代码规范脱节）。

为什么：没有度量就无法判断分层策略是否真正带来收益，成本优化也会变成盲目削减。

六、关键配置项说明

配置项	含义	取值逻辑	风险提示
温度（Temperature）	输出随机性	设计与评审类取较低值以保证稳定；创意性命名可略高	过高会导致约束遵循不稳定
最大输出长度	单次生成上限	按任务类型分档，代码类任务需覆盖完整文件	过小会截断代码，产生“看似完成实则缺失”的输出
上下文窗口	可输入的最大 token 数	装配相关模块代码而非整库代码	超出后早期约束可能被“挤出”，导致遗忘
请求超时	单次调用等待上限	交互场景建议数十秒级，批处理可放宽	过短导致长任务频繁重试，反而放大负载
重试与退避	失败恢复策略	仅对可重试错误退避重试，最多 2～3 次	对参数类错误重试无意义，且会放大故障
并发限流	单位时间请求上限	参照推理服务实际承载能力设定	超限排队会显著抬升交互延迟
路由阈值	分派到大模型的判定线	由评测数据校准，宁可略偏保守	阈值过高会让高风险任务流入轻量模型
结果缓存	相同请求复用结果	仅对确定性高的模板类任务启用	缓存键需包含提示词版本，避免规范更新后仍命中旧结果

关于“慢”的取舍：大参数模型推理耗时更长，这是由其规模决定的客观特性，不能靠调参消除。可行做法是用分层把慢限制在小范围：高频的机械任务交给轻量模型，只有设计与评审环节承受较长等待。若交互延迟仍不可接受，可考虑对 A 类任务采用“先给方案概要、再异步补全细节”的两段式交互。

七、示例说明：一个加锁粒度案例揭示的契约风险

7.1 业务背景

某企业档案管理系统采用“数据 + 档案”的父子结构：一条业务数据记录下可挂载多个档案文件，档案记录依附于数据记录存在，不能独立存在。为保证操作一致性，对数据及其档案的操作需要加排他锁。

7.2 一个典型的“能过测试但设计错误”的实现

若指令中未明确指出锁的资源标识，小参数模型常见的默认选择是：

# 存在设计缺陷的示意实现
def delete_record(record_id):
    archive_dir_id = query_archive_dir_id(record_id)
    with exclusive_lock(f"archive_dir:{archive_dir_id}"):
        db.delete_record(record_id)
        storage.delete_archives(record_id)

功能测试大概率全部通过：单用户顺序操作时，加目录锁与加数据锁效果一致。但该实现存在两个问题：

1. 锁粒度与设计不一致：锁的是档案目录而非数据主键，与“数据为聚合根”的模型设计相矛盾，其他模块若按数据主键加锁，二者互不感知，互斥失效；
2. 存在并发删除窗口：若后台批处理任务按数据主键加锁执行数据变更，而此处锁的是目录标识，两者可在同一时刻进入临界区，出现“记录已被删除、档案操作仍在执行”的悬挂状态。

7.3 符合设计意图的实现

def delete_record(record_id):
    # 锁的资源标识统一为业务数据主键，档案操作随之排他
    with exclusive_lock(f"data_record:{record_id}", wait_timeout=5):
        record = db.load_for_update(record_id)
        if record is None or record.deleted:
            return Result.skipped("记录不存在或已删除")
        storage.delete_archives(record_id)
        db.mark_deleted(record_id)

这样做的收益是：锁键统一、逻辑收敛，所有涉及该条数据的读写路径共享同一把锁，无需在各模块中重复判断目录关系；同时因为在同一临界区内重新读取记录状态，天然规避了删除竞态。

7.4 契约化提示词该如何写

【必须遵守的约束】
  2. 事务边界与锁粒度要求：
     2.1 所有涉及“业务数据 + 其档案”的操作，必须以业务数据主键作为锁的资源标识；
     2.2 禁止以档案目录、文件夹或任何派生标识作为锁键；
     2.3 进入临界区后必须重新加载并校验记录状态，不得沿用临界区外的读取结果；
     2.4 锁等待必须设置超时，超时后返回明确失败原因，不得无限等待。
【禁止事项】
  3. 不得以“更简洁”或“覆盖更多路径”为由扩大或改变锁的粒度。

7.5 如何验证该契约被遵守

1. 静态检查：检索代码中所有加锁调用点，确认锁键前缀唯一且为数据主键；
2. 并发用例：编写测试，让一个线程执行数据删除、另一个线程执行档案上传，断言二者串行执行，且后到者能观察到前者的提交结果；
3. 契约校验器：在路由层的 validate() 中实现轻量规则检查，例如“加锁调用的键参数中不得出现目录类标识”，未通过则触发重试或转人工。

八、结果验证：如何判断分层策略是否真的有效

1. 评测集回归：在固定评测集上重跑，A 类任务的约束违反次数应显著下降，B 类任务首次通过率不应低于人工基线；
2. 缺陷逃逸率：统计上线后由测试或线上发现的、由 AI 生成代码引入的缺陷数，与引入分层策略之前的周期对比；
3. 契约遵循率：统计“输出通过契约校验的比例”，这是比功能通过率更贴近设计意图的指标；
4. 成本与时延分布：确认大模型调用量占比在预期范围内（通常应显著低于轻量模型），且高频路径的平均响应时间在可接受区间；
5. 人工抽检：每周抽取若干 A 类任务产出做人工评审，重点看“是否有更优解被模型忽略”“是否擅自简化设计”。

九、常见问题与排查思路

现象	可能原因	排查与解决
模型忽略已写入提示词的约束	上下文过长导致早期内容被挤出；约束表述模糊	将约束清单置于提示词末尾并重复关键条目；把不可验证的表述改为可验证条目
生成代码“能跑但设计错”	缺失关键边界条件，模型自行选取默认解	补齐锁粒度、事务边界、幂等要求；引入契约校验器与并发用例
回答“和稀泥”，回避结论	任务被分派给了能力不足的小模型；提问本身缺少判断标准	路由层提高模糊度任务的模型等级；提问时明确要求“给出结论 + 理由 + 边界条件 + 不适用场景”
复杂需求下模型答非所问	需求描述冗长、重点分散	先让小模型做信息抽取（提取实体、约束、验收标准），再由大模型基于结构化输入设计
交互等待时间过长	简单任务误路由到大模型；推理资源并发不足	校准路由阈值；错峰处理批处理任务；扩容推理实例
长任务频繁超时重试	超时阈值过短；对不可重试错误也做了重试	按任务类型分档设置超时；仅对可重试错误做指数退避
提示词更新后仍返回旧结果	缓存键未包含提示词版本	缓存键加入提示词模板版本号与模型版本号
生成代码引入未在清单中的依赖	禁止事项未被强调或未做校验	在提示词中显式列出允许依赖清单；在流水线中加入依赖白名单扫描

十、优化建议

• 性能：对 B 类任务启用结果缓存与批处理；A 类任务采用异步化交互，避免阻塞主流程；
• 安全：所有进入提示词的业务数据须脱敏；在网关侧统一做输入输出内容审查与敏感信息拦截；模型服务与业务网络隔离，按最小权限授予访问凭证；
• 稳定性：每个任务类别至少保留一个备选模型；网关实现熔断与降级，模型服务不可用时回退到人工流程而非直接失败；
• 可维护性：提示词模板纳入版本管理，与代码规范同源维护；每次代码规范调整都同步更新模板并触发一次评测回归；
• 成本：定期统计各任务类别的 token 消耗分布，将“被高估为 A 类”的任务下调路由等级；对小模型无法胜任的任务，优先补全提示词而非直接升级模型；
• 合规：模型清单、评测记录、调用日志按项目要求归档，形成可追溯的选型依据。

十一、总结

原始讨论中的核心判断——“大参数模型更擅长理解意图，小参数模型更适合执行干活”——在工程实践中可以转化为一套可执行的方法：

1. 先划边界：确认合规允许的模型与工具链范围，形成清单；
2. 再分任务：把开发任务拆为“理解设计型”与“机械执行型”，按类别配模型；
3. 契约先行：把锁粒度、事务边界、依赖白名单等稳定约束固化为可验证的提示词模板；
4. 路由统管：通过统一接入层实现分派、重试、限流、降级与日志度量；
5. 验证闭环：以真实业务评测集、契约校验器与并发用例替代主观判断。

由此，“大参数模型 + 轻量模型”的分层组合不再是简单的贵与便宜之争，而是一套以设计意图一致性为目标的工程分工。后续可继续深入的方向包括：面向具体技术栈的契约校验规则库建设、评测集的自动化扩充与回归、以及模型能力持续迭代下的路由阈值动态校准。