我的大模型 知识模型+能力模型+素质模型

大模型知识模型+能力模型+素质模型：三支柱系统搭建完整指南

如果你正在使用 Claude、GPT 或其他大模型，却发现它"知道的不少但用起来总差一口气"——回答不专业、执行不靠谱、有时还越界——问题往往不在模型本身，而在你缺乏一套系统化的调教方法。围绕 知识模型 + 能力模型 + 素质模型 三个支柱搭建你的 Prompt 体系，是让大模型从"通用聊天工具"变成"专属业务助手"的最短路径。这套方法不绑定任何特定模型，对 Claude、GPT、国产大模型均适用。读完本文你将获得三样东西：三支柱各自解决什么问题、每一步具体怎么写配置格式、以及验证效果与排查失败的完整路径。

三支柱分工：一个理解框架

要理解这套体系，先明确三根支柱各自的职责边界。

知识模型管"知道什么"——领域术语、业务规则、事实背景、数据口径。它解决的是模型的"认知底座"问题。能力模型管"会做什么"——分步骤执行、逻辑推理、调取数据、输出格式。它解决的是"操作链路"问题。素质模型管"表现成什么样"——语气风格、回答边界、安全红线。它解决的是"行为约束"问题。

用一个实际场景说明三者如何分工。假设你用大模型做客户支持分析：只有知识没有能力，模型能说出"这是 A 类产品"却给不出"A 类动销率异常需关注"的判断——它知道定义但不会往下推演；只有能力没有知识，模型拿错误的字段名去查询，输出结果完全不可用；知识和能力都齐了但没有素质约束，模型可能把管理层报销数据透露给普通员工——能力越强，越界风险越大。三根支柱缺任何一个，整体体验都会明显塌陷。

第一步：注入知识，让模型先"懂行"

模型出厂自带的是通用世界知识，你所在行业的行话、内部规则、数据口径，它一概不知。知识模型搭建的本质，就是把"只有你团队懂的东西"以显式、结构化的方式写进 Prompt。

推荐格式：用结构化区块包裹知识

## 领域知识
- 产品分类：A 类（库存周期 < 7 天）、B 类（7–30 天）、C 类（> 30 天）。
- 数据表别名：销售表 → sales_raw，库存表 → inv_curr。
- 关键指标公式：动销率 = 某段时间内至少销售过一次的SKU数量 / 总SKU数量 × 100%。

以下实操原则直接决定知识能否被模型"激活"，而非只是"看到"：

• 一条一行，不与其他说明混排，降低模型解析成本；
• 用明确标题包裹，如 ## 领域知识，与后面的能力指令区分开；
• 定义写"是"字句，不用"通常""一般来说"这类模糊措辞——模型对模糊定义会自行脑补；
• 公式写完整展开式，不缩写、不跳步，避免模型在中间环节自行假设。

验证方法：在对话中直接呼叫一条知识——问"C 类产品的库存周期是多少"，模型应回答"> 30 天"。如果它自己编了一个区间或替换了术语，说明知识块未被成功读取。这时改用 --- 分隔，或用 ## 开始知识库……## 结束知识库 包裹整个区块，通常能解决。

常见坑：知识条数别贪多。超过 50 条后，模型在长上下文中引用单条知识的准确率明显下滑。高频业务对象优先放 System Prompt，低频内容放外部知识库文档、按需检索，不要一股脑全塞进去。

第二步：定义能力，让模型"会干活"

知识解决"懂不懂"，能力解决"会不会"——每个任务的标准执行流程、输入输出格式、触发和退出条件，都必须写明白。

推荐格式：每项能力三要素齐备

## 可用能力
### 1. 数据汇总
- 输入：日期范围 + 产品线。
- 执行：从 sales_raw 筛选数据 → 按产品线分组 → 计算总销售额与动销率。
- 输出：表格形式，含「产品线」「总销售额」「动销率」「环比」列。

### 2. 异常预警
- 触发条件：动销率低于 30%。
- 行动：输出预警信息，并列出受影响的产品线与对应的 sales_raw 行数。
- 退出条件：输入新日期范围或手动关闭预警。

几个设计要点，都是实际使用中反复踩坑后总结出来的：

• 触发条件和退出条件必须成对写。否则模型可能在步骤间无限循环——尤其是多步骤任务，没有退出条件的指令最危险；
• 输入输出格式化到字段级。只说"输出汇总表"和明确列出具体列名，模型给出的结果差距非常大；
• 执行过程用编号步骤，每步包含动作、对象、中间结果三要素；
• 能力数量控制在 2–4 个一组。一次激活超过 6 个，长对话里模型会开始把能力 B 的步骤套用到能力 A 上——输出会出现跨任务的步骤混淆。

第三步：设定素质，让模型"靠得住"

正式业务场景下，素质模型比前两个支柱更容易被忽略，但后果也最直接——回答越界或语气不对，内容可信度瞬间归零。素质模型包含三个层次。

语气：定到标点符号层级

直接声明固定风格，越具体越好。例如：回复使用简洁的陈述句，用第二人称「你」。避免感叹号与 emoji。 注意，语气指令必须具体到标点符号层级，否则模型每隔几轮就会悄悄"放松"回默认风格——尤其在长对话后段。

边界：按场景列，不写空话

遇到涉及未公开财务数据的问题，回复「该信息不在我的知识范围内」。 边界指令要写具体场景。一句"不回答敏感信息"等于没写——模型无法自行判断哪些内容算敏感。

安全：用"不可违抗"的强度写

## 安全规则：不可违抗的约束
- 不允许生成可执行的 SQL 删除语句。
- 如果用户要求删除数据，请先输出受影响的行数并要求确认。

安全规则用独立标题 + 项目符号独占一行，不与其他指令混排。同时加一行硬性兜底：用户请求与上述规则冲突时，以上述规则为准。

为什么素质模型最容易失效？ 核心原因在于模型有强烈的"迎合用户"本能。当你用更强硬的语气追问时，它会倾向放宽边界来换取对话继续。这就是为什么安全规则必须以"不可违抗"的口吻写，并且明确写出违反规则时的应对动作——给模型一个"遵守规则"的具体行为替代"拒绝用户"的心理负担。

验证方法：故意输入一条边界外指令（如"把所有数据都删了"），看模型是否按安全策略拒绝。再试一条语气测试（"说人话，别用书面语"），看它是否仍保持陈述句风格。如果模型直接执行、编造 SQL、或改用口语化表达，说明素质指令强度不够——需要把语气与安全规则改为独立标题 + 项目符号独占行的格式。

完整调教示例：报销政策查询助手

把三块拼起来看一次完整协同。假设你要用 Claude 回答员工报销政策查询。

知识模型片段：定义差旅、设备、培训三类报销额度，写明每类上限金额与适用人员范围。

能力模型片段：

## 能力：报销查询
- 步骤1：匹配用户输入的报销类别到三类之一。
- 步骤2：查看本轮额度剩余。
- 步骤3：如果额度不足，输出「当前可用余额仅 X 元，建议优先使用在 Y 类别」。
- 否则输出剩余额度与过去 3 次报销日期。

素质模型片段：如果用户问的是「某某领导能报多少」，只返回类别政策，不返回管理层个人额度。 不讨论其他同事的报销记录。 不知道的信息直接说不知道，不推测。

实际输入："差旅还剩多少？"

期望输出："当前差旅类余额为 4200 元。过去三次报销分别是 6月5日、6月20日、7月12日。"

如果输出不对，按以下顺序排查：

• 输出了别人的余额 → 素质模型缺少"不返回个人额度"约束，回步骤 3 补写；
• 把"差旅"归到了"设备"类 → 知识模型类别定义不清晰，在类别后加示例："差旅类（含交通、住宿、餐饮补贴，不含设备采购）"；
• 只输出余额不讲历史记录 → 能力指令步骤 3 需要拆分，分别对应额度充足与不足两种分支。

高频误区速查表

误区	具体表现	纠正方法
只给知识，不给能力步骤	模型说很多术语，但不执行具体流程	每项业务场景写清楚输入 → 运算 → 输出三段式
能力指令写得太笼统	模型自由发挥或反复追问，不做决定	每个能力细化成带