LLM Prompt 工程方法论：CO-STAR、六段框架与结构化 Prompt 交付模板

归类：Tools / AI 工程化 / Prompt Engineering 发生时间：2026-05-18 状态：✅ 已沉淀

一、什么是 CO-STAR？

CO-STAR 是新加坡政府技术局（GovTech）于 2023 年提出并在业内广泛传播的 Prompt 结构化框架，通过给模型设定六个维度的上下文，系统性地提升 LLM 输出的可控性与一致性。

字母	英文	中文	作用
C	Context	背景	给模型提供任务所在的场景、数据来源和业务上下文
O	Objective	目标	明确模型需要完成的具体任务
S	Style	风格	指定输出的语气、表达风格或格式偏好
T	Tone	语调	设定交流语调（专业/亲切/严谨等）
A	Audience	受众	说明输出内容的目标读者，影响措辞难度
R	Response	响应	定义输出的具体结构（JSON/Markdown/列表等）

核心思想：Prompt 不是一句话，而是一份结构化说明书；越精确的上下文给定，模型产生"幻觉"的空间越小。

二、六段框架与 CO-STAR 的关系

在结构化审核/推理类 Prompt 的落地实践中，CO-STAR 的六个维度往往需要进一步细化，尤其在以下两点上存在明显短板：

Schema 缺失：CO-STAR 没有强调"字段级精确约束"的必要性。当输入数据涉及复杂嵌套 JSON 时，仅靠 Context 描述很难让模型准确理解每个字段的边界。
Few-Shot 缺失：CO-STAR 没有将示例作为一级结构显式定义。对于强约束推理任务（如合规审核），缺少示例会导致模型在边界场景上产生不确定输出。

六段框架（Role-Context-Schema-Rules-Few-Shot-Format）是在 CO-STAR 思想基础上，结合结构化审核场景实践沉淀出来的工程化延伸版本，并非业内固定标准。

维度	CO-STAR 对应	工程化延伸说明
Role（角色）	Audience + Style + Tone	集中为"给模型设定专业身份"，激活领域专属知识
Context（背景）	Context	同源，说明数据来源与任务背景
Schema（数据契约）	❌ CO-STAR 无此段	原创延伸：字段级精确约束，是防止幻觉的核心机制
Rules（规则）	Objective	将目标细化为可逐条校验的业务规则列表，支持占位符动态注入
Few-Shot（示例）	❌ CO-STAR 无此段	原创延伸：正例+反例锚定模型的推理路径，覆盖所有边界场景
Format（输出格式）	Response	同源，强制 JSON 输出，消除后端解析的不确定性

总结：CO-STAR 是"思想"，六段框架是"落地实现"。前者是行业公认的 Prompt 设计理论，后者是结合实际工程约束对其进行的业务侧二次沉淀，并非业内固定标准，可按需裁剪。

三、五条核心设计原则

原则一：Schema 字段级约束 > 自然语言描述

❌ 不好的写法：

json

{ "fieldA": "字段类型" }

✅ 正确的写法：

json

{ "fieldA": "字段类型，完整枚举：枚举值A | 枚举值B | 枚举值C（共N种）" }

原因：模型对"如：某类型、某类型"会进行推断和泛化，导致将语义相近但不完全匹配的值也视为合法值，产生幻觉误判。完整枚举强制模型执行精确的字符串匹配。

原则二：豁免规则必须精确指向字段名

❌ 不好的写法："此类票据不需要匹配"
✅ 正确的写法："若 invoice.fieldX 等于 '精确字符串值'，该条目无需参与校验"

原因：自然语言描述允许模型进行语义推断，把语义相似的内容也视为豁免条件，扩大了豁免范围。精确字段名绑定消除了这种歧义。

原则三：Few-Shot 必须覆盖全部边界场景

示例的数量不等于质量。覆盖矩阵建议：

场景类型	是否必须有对应示例
基础通过（所有规则满足）	✅
单条违规（仅违反规则X）	✅
多条复合违规	✅
每条豁免规则各一个正例	✅
边界歧义场景（如多值字段、空值字段）	✅

原则四：规则与模板分离（参数化设计）

system_prompt_template.txt   ← 模板骨架（含 {task_type} 和 {rules} 占位符）
rules_definition.txt         ← 规则原子件（注入到 {rules}）

优点：

业务规则变更时，只需修改 rules_definition.txt，模板不动
多个业务场景可复用同一套模板骨架，只替换 {task_type} 和 {rules}
降低多端同步成本（前端 Demo/后端 API/算法脚本使用同一母本）

原则五：模型调用参数控制

参数	推荐值	原因
`temperature`	`0.1`	审核/判断场景要求确定性输出，高温度会导致结论漂移
`max_tokens`	按输出格式预估	JSON 输出通常远小于默认上限，适当限制可提升响应速度
重试策略	指数退避（2s/4s/8s）	避免因网络抖动导致单次失败终止整个审核链路
降级策略	本地规则引擎兜底	模型不可用时不应阻塞业务主流程

四、通用六段 Prompt 模板骨架（脱敏版）

以下模板可直接用于适配新业务场景，替换内的占位符即可。

text

# Role
你是一名资深的 {{ 领域专家身份，如"财务审计员"/"合规审核员"/"数据质量检查员" }}，
专注于对提交的 {{ 任务对象名称 }} 进行合规性审核，严格依据给定的规则进行判断，不做任何规则以外的推断。

# Context
你将接收一个 JSON 数据包，包含以下信息：
- `{{ 数据集合A }}`：{{ 集合A的用途说明 }}
- `{{ 数据集合B }}`：{{ 集合B的用途说明 }}
- `{{ 辅助数据C }}`：{{ 辅助数据C的用途说明 }}

# Schema（字段级数据契约）
```json
{
  "{{ 数据集合A }}": [
    {
      "{{ 字段1 }}": "{{ 字段1的含义，格式：YYYY-MM-DD，支持多值时以英文逗号分隔，需逐一校验 }}",
      "{{ 字段2 }}": "{{ 字段2的含义，如：金额，保留2位小数 }}",
      "{{ 字段3 }}": "{{ 字段3的含义，如：名称字符串 }}"
    }
  ],
  "{{ 数据集合B }}": [
    {
      "{{ 字段4 }}": "{{ 字段4的含义，完整枚举：枚举值1 | 枚举值2 | 枚举值3 | ... }}",
      "{{ 字段5 }}": "{{ 字段5的含义，豁免触发条件说明：有值即触发，空字符串不触发 }}"
    }
  ],
  "{{ 辅助数据C }}": ["{{ 数据格式，如：YYYY-MM-DD 字符串数组 }}"]
}

Rules（审核规则）

以下豁免条件下，相关条目可直接跳过校验：

豁免E-1：若 . NaN ""，无需参与
豁免E-2：若 . 等于 "", 无需参与
豁免E-3：若 . 有值（非空字符串），无需参与

Few-Shot（示例）

Example 1：基础合规通过

输入：输出：

Example 2：

输入：输出：

Example 3：豁免场景（E-1）

输入：输出：

Example N：多项复合违规

输入：输出：

Format（输出格式）

只输出以下 JSON，不输出任何其他内容，不包含 Markdown 代码块包裹：

json

{
  "isPass": true/false,
  "auditResult": "自然语言描述审核结论（通过/拒绝原因）"
}


---

## 五、规则变更标准流程

业务方/产品明确新规则细节 ↓
更新 rules_definition.txt（规则原子件，单一事实来源） ↓
更新 system_prompt_template.txt（如涉及 Schema 字段变更） ↓
更新 prompt_full_readable.md（完整版可读文档，供产研交付参考） ↓
全链路同步：前端 Demo / 后端 API 调用代码 / 测试脚本 ↓
Git 提交 + 通知相关团队


---

## 六、反向校验：脱敏检查清单

在将本框架复用到新业务时，用以下清单验证 Prompt 的鲁棒性：

| 检查项 | 验证方式 |
| :--- | :--- |
| 所有枚举字段是否给出完整枚举？ | 在 Schema 中搜索"如："，发现后替换为完整列表 |
| 豁免规则是否精确绑定到字段名？ | 搜索"不需要匹配/无需校验"，确认前有 `field.name === 'value'` 绑定 |
| Few-Shot 是否覆盖每条豁免规则？ | 逐条豁免规则对应一个通过示例 |
| 多值字段（逗号分隔）是否有专项示例？ | 至少1条"全命中"，1条"部分命中"，1条"全不命中" |
| 空字段传 `""` 而非 `null`？ | 代码层面确认，Schema 中注明"统一传空字符串" |
| `temperature` 是否设置为低值？ | 调用侧确认 `temperature ≤ 0.1` |

---

## 七、参考资料

- **CO-STAR 框架**：来源于 GovTech Singapore 2023 年提出，已在各大 LLM 平台提示词文档中广泛引用
- **Few-Shot Prompting**：Brown et al. 2020《Language Models are Few-Shot Learners》，GPT-3 论文中首次系统化验证
- **Prompt Injection 防御**：OWASP LLM Top 10，2023 年版（第一位风险）

LLM Prompt 工程方法论：CO-STAR、六段框架与结构化 Prompt 交付模板 ​

一、什么是 CO-STAR？ ​

二、六段框架与 CO-STAR 的关系 ​

三、五条核心设计原则 ​

原则一：Schema 字段级约束 > 自然语言描述 ​

原则二：豁免规则必须精确指向字段名 ​

原则三：Few-Shot 必须覆盖全部边界场景 ​

原则四：规则与模板分离（参数化设计） ​

原则五：模型调用参数控制 ​

四、通用六段 Prompt 模板骨架（脱敏版） ​

Rules（审核规则） ​

Few-Shot（示例） ​

Example 1：基础合规通过 ​

Example 2： ​

Example 3：豁免场景（E-1） ​

Example N：多项复合违规 ​

Format（输出格式） ​

LLM Prompt 工程方法论：CO-STAR、六段框架与结构化 Prompt 交付模板

一、什么是 CO-STAR？

二、六段框架与 CO-STAR 的关系

三、五条核心设计原则

原则一：Schema 字段级约束 > 自然语言描述

原则二：豁免规则必须精确指向字段名

原则三：Few-Shot 必须覆盖全部边界场景

原则四：规则与模板分离（参数化设计）

原则五：模型调用参数控制

四、通用六段 Prompt 模板骨架（脱敏版）

Rules（审核规则）

Few-Shot（示例）

Example 1：基础合规通过

Example 2：

Example 3：豁免场景（E-1）

Example N：多项复合违规

Format（输出格式）