用系统架构思维，告别“意大利面条式”系统提示词

一、引言：一次对“神级提示词”的祛魅之旅

最近，在研究如何编写真正强大的系统级提示词。为了学习，我把目光投向了业界前沿的AI原生产品，比如新一代浏览器中集成的 Dia。

初次接触 Dia 的系统提示词我的第一反应是震撼——动辄上百行的指令，细致入微，覆盖了各种边缘情况，从内容生成到格式排版，再到媒体文件的插入逻辑，无所不包。第一感觉就是：真牛！ 我渴望能理解这些“神级提示词”是如何设计出来的，并从中汲取养分。

但当我尝试去逐行剖析时，震撼感逐渐被一种作为开发者特有的技术忧虑所取代。剥去华丽的外衣，其内核似乎就是大量规则的无序堆砌。让我们来看一下其中一些规则的片段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
...
- 相比不提供，Dia 应更倾向于提供‘简单回答’……
- 如果你的回应中将包含项目符号或编号列表，则不要包含‘简单回答’……
- 当用户寻求生活帮助或进行休闲对话时，绝不要使用‘简单回答’。

- ……应包含尽可能多的‘问 Dia’超链接，就像维基百科页面那样……
- 绝不要在实际的URL或域名上使用‘问 Dia’超链接……

- 图片可以紧跟在‘简单回答’之后出现
- 图片可以在标题之后出现
- 图片不能出现在段落之后
- 对于这些主题或话题，Dia 绝不能显示图片：编码、天气状况……
- 当基于 `<pdf-content>` 或 `<image-description>` 中的任何内容生成回应时，你绝不能包含任何图片或媒体……
...

当我看到这些指令以一种扁平化的方式交织在一起时，我最初的崇拜变成了深刻的忧虑。我脑海里立刻浮现出一个致命的问题：这东西要怎么维护？这不就是一份注定要变成“技术屎山”的设计文档吗？

这种“规则清单式”的设计模式并非个例，它在工程实践中必然会导致三大困境：

1.规则打架，行为摇摆不定：让我们聚焦于<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">simple answer</font>（简单回答）的规则。它同时存在“应尽可能包含”、“列表内容不包含”、“休闲对话不包含”等多条互斥的条件。现在，如果用户用一种休闲的口吻询问一个可以被列表回答的问题，模型应该遵循哪条规则？由于缺乏一个清晰的决策仲裁机制，模型的行为可能变得不可预测。它到底会做什么，更像是在“猜”，而不是在遵循一个确定的逻辑。

2.越改越乱，最终没人敢动：现在，假设产品经理要求“在所有标题后都不能加图片”。你必须在海量的文本中找到所有与“图片位置”相关的规则，并小心翼翼地修改它们，同时祈祷这个修改不会与某个关于“列表”或“简单回答”的规则产生新的冲突。这种维护方式，就像在修改一个没有变量、没有模块的老旧代码库。所有逻辑都耦合在一起，任何微小的改动都可能引发雪崩效应。久而久之，提示词变得像“叠叠乐”高塔，摇摇欲坠，没人再敢轻易触碰。

3.响应像“开盲盒”，核心价值被稀释：Dia 的一个核心价值是“通过视觉元素提升体验”。然而，关于何时显示、何时禁止显示图片的规则被分散在各处，甚至有一条基于上下文（如<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);"><pdf-content></font>）的最高优先级禁令。模型有限的“注意力”被大量琐碎的规则所稀释，导致其在判断是否应该插入图片时，可能会因为一条次要规则而忽略了其核心的“视觉化”价值。最终的响应效果就像在“开盲盒”，时好时坏，无法稳定地传递产品的核心价值。

1.1. 祛魅之后：从“规则管理者”到“系统设计师”

这次学习让我明白，那些看似“很牛”的提示词，其背后可能隐藏着巨大的技术债。问题的根源，并非某条规则写得不好，而是这种“规则清单”式的设计模式本身存在结构性缺陷。它把一个本应有机的、智能的系统，降维成了一堆离散、扁平的指令。

如果我们继续扮演“规则的管理者”，就永远无法摆脱上述困境。我们必须进行一次彻底的思维范式转换：停止堆砌规则，开始构建系统。

我发现，提示词本质上可视为一个“虚拟智能系统”的蓝图，既然是系统，那么就完全可以运用「系统架构思维」进行设计****。这种方法论为上述三大困境提供了精准的“解药”：

  • 面对“规则打架，行为摇摆”的混乱？ -> 我们通过角色与目标定义，建立清晰的决策框架，让AI在冲突时知道“我是谁，我该听谁的”。
  • 面对“越改越乱，没人敢动”的维护噩梦？ -> 我们通过模块化与分层，实现高内聚、低耦合，让每次修改都像做外科手术一样精准可控。
  • 面对“响应开盲盒，价值稀释”的窘境？ -> 我们通过流程设计，规划出清晰的行动路径，确保模型的“注意力”被引导至核心任务上，保障产品价值的稳定输出。

在本文接下来的部分，我们将详细介绍这套系统架构思维，并用它来对一个复杂的提示词进行一次彻底的、工程化的重构，展示如何将一个混乱的“规则清单”转变为一个健壮、可维护的系统蓝图。

二、系统架构思维：从理论到设计框架

在引言中，我们剖析了“规则清单式”提示词在工程上遇到的三大困境，并指出其根源在于缺乏系统性的设计。为了解决这个问题，我们必须引入一种更高级的思维模型——系统架构思维。它能帮助我们从“规则的堆砌者”转变为“系统的设计师”。

2.1. 系统思维：从碎片化到整体性的认知升级

在深入架构之前，我们首先要理解系统思维。这是一种将研究对象视为一个由相互关联、相互作用的要素构成的有机整体的思维方式。它要求我们摒弃“头痛医头，脚痛医脚”的线性修补模式，转而关注问题的系统性根源。

当应用于提示词设计时，系统思维的核心在于：

1.关联性认知：系统中任何一条要素的价值，都体现在与其他要素的互动中。单一要素是孤立的，只有当它被置于一个完整的决策框架中时，其真正的作用才能稳定发挥。

2.层次性拆解：将一个复杂的、庞大的系统，分解为可管理的、功能独立的子系统。这正是我们将一个巨大的提示词拆解为不同功能模块的理论基础。

3.动态性适应：系统需要根据环境变化（如用户输入的变化）调整其行为，并通过反馈机制实现持续优化。一个设计良好的提示词系统，应该能根据不同的对话场景，动态调用不同的功能模块和行为逻辑。

2.2. 系统架构思维：构建智能体的“蓝图”

如果说系统思维是世界观，那么系统架构思维就是将这一世界观付诸实践的工程方法论。它专注于为系统绘制一份清晰的“蓝图”，这份蓝图通过回答三个核心问题，来确保系统的所有组件都能协同工作，达成最终目标：

  • 我是谁？ -> 角色定位****：定义系统的身份、服务主体与边界。
  • 我该做什么？-> 目标定义****：建立系统的核心使命与价值主张。
  • 我该怎么做？ -> 能力与流程****：规划系统实现目标的具体路径和方法。

2.3. 设计框架：提示词系统的四层架构模型

基于系统架构思维，我们构建了一个由四个核心层级组成的、高度结构化的提示词设计框架。这四层从内到外，从核心到边界，共同定义了一个健壮、可维护的智能体系统。它们分别是：

  • 第一层：核心定义:**** 定义系统的内核——我是谁，我为何存在？
  • 第二层：交互接口:**** 定义系统与外部世界的沟通方式——我如何感知世界，又如何被世界感知？
  • 第三层：内部处理:**** 定义系统的“思考”与“行动”逻辑——我如何一步步完成任务？
  • 第四层：全局约束:**** 定义系统不可逾越的边界——我绝对不能做什么？

接下来，我们将详细拆解这四个层级所包含的关键组件。

2.3.1. 第一层：核心定义 - 我是谁？我为何存在？

这是系统的基石，它为AI所有的行为和决策提供了最底层的、最一致的内在逻辑。

2.3.1.1. ****角色建模: 定义AI的“人格”与“身份”

此组件回答“我是谁”。一个清晰的角色设定，是解决“规则打架”问题的最高仲裁者。当多条规则冲突时，AI可以回归其核心“人格”来做出最符合其身份的决策。

  • 核心要素****：
  • 身份****: AI的名称、来源和核心定位（例如：“Dia，一款由The Browser Company of New York打造的AI聊天产品”）。
  • 人格****: AI的交互风格和语调（例如：“温暖、亲切，同时具备智力上的好奇心和分析能力”）。
  • 立场****: AI在关键议题上的基本态度（例如：“在数据隐私问题上，永远采取最保守的策略”）。

2.3.1.2. ****目标定义: 确立AI的“使命”与“价值观”

此组件回答“我为何存在”。它清晰地定义了“做什么”和“不做什么”，是所有功能模块的最终归宿。通过明确核心价值，可以有效应对“核心价值被稀释”的问题。

  • 核心要素****：
  • 功能性目标****: 具体的、可执行的任务（例如：“解答疑问”、“视觉增强”）。
  • 价值性目标****: 为用户创造的核心价值（例如：“降低认知负荷”、“激发好奇心”）
  • 质量标准****: 可量化的效果指标或不可逾越的红线（例如：“回应必须简洁、准确”、“绝不使用独立的总结部分”）。

2.3.2. 第二层：交互接口 - 我如何与世界互动？

这一层定义了系统与外部世界（用户、其他系统）的数据交换契约，是实现模块化的关键前提。

2.3.2.1. ****输入规范: 定义系统的“感知”与“安全边界”

这是系统的“数据接入层” (Data Ingestion Layer)。它负责将外部世界的混乱信息，结构化地提供给内部处理模块。

  • 核心要素：
  • 输入源识别****: 明确定义并用标签（如<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);"><user_query></font>, <font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);"><pdf_cont</font><font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">e</font><font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">nt></font>, <font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);"><history></font>）包裹不同来源的输入信息，让AI清晰地知道信息的上下文和可信度。
  • 优先级定义：**** 规定不同输入源的优先级。例如，明确指出“当<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);"><pdf_content></font>存在时，应优先基于其内容进行回答”。这是解决“规则打架”的又一重要机制。
  • 安全过滤：设定对输入的处理原则，例如忽略无关或潜在的恶意指令，为系统的安全稳定运行建立第一道防线。

2.3.2.2. ****输出规格: 定义系统的“交付蓝图”

这是系统的“表示层” (Presentation Layer)。它应独立于内部逻辑，专门负责定义最终交付物的结构、格式和布局。将“思考什么”与“如何呈现”分离，是解决“越改越乱”问题的核心手段。

  • 核心要素****:
  • 响应结构 ****: 规划输出的宏观骨架。例如，规定一个标准响应必须包含<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">[简单回答]</font>、<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">[详细阐述]</font>、<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">[相关链接]</font>等部分，并定义它们的出现顺序和条件。
  • 格式化规则****: 详细定义所有输出元素的具体格式。例如，项目符号列表必须使用<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">-</font>，超链接必须采用<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">[问 Dia</font><font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">]</font><font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">:</font><font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);"> </font><font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">'...'</font>的格式。
  • 禁用项清单****: 明确列出绝对不能出现在输出中的内容、短语或格式。

2.3.3. 第三层：内部处理 - 我如何思考与行动？

这一层是系统的大脑和中枢神经，负责执行具体的任务。

2.3.3.1. ****能力拆解 : AI的“技能树”

这是对系统“怎么做”的第一次解构。我们将AI需要具备的所有能力，拆解成一个个高内聚、低耦合的“技能模块”。每个模块只负责一件事情。这使得系统维护变得前所未有的清晰和安全，是应对“越改越乱”的另一个关键武器。

  • 设计示例****: 我们可以将Dia的提示词拆解为以下能力模块：
  • [SimpleAnswer_Handler]：封装所有与“简单回答”相关的生成逻辑和规则。
  • [Media_Inserter]：封装所有与图片、视频插入相关的逻辑和规则。
  • [Link_Generator]：封装所有与“问 Dia”超链接相关的逻辑和规则。

2.3.3.2. 流程设计: AI的“行动逻辑”

如果说能力是静态的技能，那么流程就是动态的行动剧本。它定义了AI在接收到用户请求后，如何按顺序、有逻辑地调用各个“能力模块”，最终完成任务。一个清晰的流程，能为AI的行为提供可预测的路径，从而解决“响应像开盲盒”的问题。

  • 核心要素****：
  • 标准化步骤****：定义从输入到输出的固定阶段（例如：“1.需求分析 -> 2.策略规划 -> 3.内容生成 -> 4.格式化交付”）。
  • 决策逻辑****：在流程的关键节点，明确决策的判断依据和优先级（例如：“在策略规划阶段，如果查询类型是‘休闲对话’，则禁用<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">[SimpleAnswer_Handler]</font>模块”）。这使得规则冲突的处理被显式化，而不是让模型去“猜”。

2.3.4. 第四层：全局约束 - 我不能做什么？

这是系统的“安全护栏”，定义了AI在任何情况下都不能逾越的红线。它拥有最高的执行优先级。

2.3.4.1. ****约束设定: AI的“行为边界”

此组件负责保障系统的安全、合规与稳定。

  • 核心要素****:
  • 硬性规则 (Hard Rules): 绝对不能违反的指令，通常涉及安全、伦理、法律等方面（例如：“绝不能在基于<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);"><pdf-content></font>的上下文中包含任何外部媒体”）。
  • 求助机制 (Help Mechanism): 当遇到无法处理的情况或功能不支持时的固定行为模式（例如：“当被要求执行编码任务时，礼貌地拒绝并解释自己是对话AI”）。

2.4. 模板：系统架构思维提示词设计画布

为了帮助你快速将上述理论付诸实践，我们提供了一个即插即用的“系统架构思维提示词设计画布”。你可以将这个模板作为设计任何复杂AI智能体的起点。它强制你从系统层面进行思考，确保在编写任何具体规则之前，就已经拥有了一个清晰、稳固的架构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
# 提示词系统设计画布 (Prompt System Design Canvas)
# 版本: 1.0
# AI名称: [你的AI名称，例如：智能数据分析师]
# 设计师: [你的名字]
# 日期: [YYYY-MM-DD]

---
## 第一层：核心定义 (Core Definition)
---

### 1. 角色建模 (Role Modeling)
# 描述AI的身份、人格和立场。这是所有行为的基石。
- **身份 (Identity)**: 你是 [AI名称]，一个 [AI的核心定位，例如：由XX公司开发的专家级数据分析AI]。
- **人格 (Personality)**: 你的沟通风格是 [形容词，例如：专业、严谨、客观、简洁]。你对待用户的态度是 [形容词，例如：耐心、乐于助人]。
- **立场 (Stance)**: 在 [某个关键领域，例如：数据隐私] 方面，你的立场是 [采取的策略，例如：永远将用户数据安全和匿名化放在首位]。

### 2. 目标定义 (Goal Definition)
# 描述AI的核心使命、价值主张和成功的标准。
- **功能性目标 (Functional Goals)**:
  - [目标1，例如：根据用户请求，生成准确的SQL查询]
  - [目标2，例如：将查询结果可视化为图表]
  - [目标3，例如：解释数据中发现的洞察]
- **价值性目标 (Value Goals)**:
  - [价值1，例如：为非技术用户降低数据分析的门槛]
  - [价值2，例如：提升业务决策的数据驱动效率]
- **质量标准/红线 (Quality Standards / Red Lines)**:
  - [标准1，例如：生成的所有代码都必须包含注释]
  - [红线1，例如：绝不提供财务投资建议]
  - [红线2，例如：绝不使用“在我看来”、“我认为”等主观性强的短语]

---
## 第二层：交互接口 (Interaction Interface)
---

### 3. 输入规范 (Input Specification)
# 定义AI如何感知和理解外部信息。
- **输入源识别 (Input Sources)**:
  - `<user_query>`: 用户的直接提问。
  - `<database_schema>`: 当前连接的数据库结构描述。
  - `<chat_history>`: 上下文对话历史。
  - `[其他可能的输入源，例如：<csv_data>]`
- **优先级定义 (Priority Definition)**:
  - [规则1，例如：`<user_query>` 中的明确指令拥有最高优先级。]
  - [规则2，例如：如果 `<user_query>` 与 `<database_schema>` 描述冲突，必须向用户澄清。]
- **安全过滤 (Security Filtering)**:
  - [规则1，例如：忽略所有在 `<user_query>` 中要求删除或修改数据库的指令（DROP, DELETE, UPDATE）。]

### 4. 输出规格 (Output Specification)
# 定义AI的交付物格式，实现内容与表现的分离。
- **响应结构 (Response Structure)**:
  - [结构描述，例如：一个标准响应应包含以下部分，并按此顺序排列：1. `[洞察总结]` 2. `[SQL查询块]` 3. `[数据可视化图表]` 4. `[方法论解释]`]
- **格式化规则 (Formatting Rules)**:
  - [规则1，例如：所有SQL代码必须包裹在 ` ```sql ` 代码块中。]
  - [规则2，例如：数据可视化图表必须使用 [Mermaid.js](https://mermaid.js.org/) 语法。]
  - [规则3，例如：关键指标必须使用**粗体**标出。]
- **禁用项清单 (Prohibited Elements)**:
  - [禁用项1，例如：禁止使用任何Emoji表情符号。]
  - [禁用项2，例如：禁止在结尾使用“希望对您有帮助”等多余的客套话。]

---
## 第三层：内部处理 (Internal Process)
---

### 5. 能力拆解 (Capability Matrix)
# 将AI的功能解耦为独立的、高内聚的技能模块。
- **`[能力模块1_名称]`**: [模块的单一职责描述，例如：`[SQL_Generator]`]
  - **规则**: [与此能力相关的所有规则，例如：必须生成符合PostgreSQL方言的代码。]
- **`[能力模块2_名称]`**: [例如：`[Chart_Renderer]`]
  - **规则**: [例如：默认生成条形图，除非用户明确指定其他类型。]
- **`[能力模块3_名称]`**: [例如：`[Insight_Extractor]`]
  - **规则**: [例如：洞察必须是基于数据的客观发现，不能包含主观推测。]

### 6. 流程设计 (Workflow Design)
# 编排AI的思考和行动步骤，调用能力模块完成任务。
- **标准化步骤 (SOP)**:
  1.  **[分析需求]**: 解析 `<user_query>`，识别用户的核心意图（查询、可视化、解释等）。
  2.  **[生成方案]**: 根据意图，调用 `[SQL_Generator]` 模块创建查询语句。
  3.  **[执行与可视化]**: (在虚构中)执行查询，并将结果传递给 `[Chart_Renderer]` 模块。
  4.  **[提炼洞察]**: 将结果传递给 `[Insight_Extractor]` 模块。
  5.  **[组装交付]**: 严格按照 `输出规格` 中定义的 `响应结构`，将所有生成的内容整合成最终回复。
- **决策逻辑 (Decision Logic)**:
  - [决策点1，例如：如果在**分析需求**阶段，发现用户意图不明确，则立即中断流程，并触发`求助机制`。]
  - [决策点2，例如：如果在**生成方案**阶段，用户要求查询不存在的字段（根据`<database_schema>`判断），则向用户报告错误并请求修正。]

---
## 第四层：全局约束 (Global Constraints)
---

### 7. 约束设定 (Constraint Setting)
# 定义系统绝对不能逾越的红线，拥有最高优先级。
- **硬性规则 (Hard Rules)**:
  - [规则1，例如：在任何情况下，都绝对禁止在生成的SQL中包含 `DROP TABLE` 或 `DELETE FROM` 指令。]
  - [规则2，例如：绝不能暴露 `<database_schema>` 之外的任何底层系统信息。]
- **求助机制 (Help Mechanism)**:
  - **触发条件**: [例如：当用户意图无法解析，或请求的功能超出能力范围时。]
  - **固定话术**: [例如：“我无法完成这个请求，因为[简明原因]。我能帮助您进行数据查询、可视化和洞察分析。您可以尝试这样问我：‘...’”]。

三、从蓝图到执行——将系统架构“编译”为高效提示词

在第二部分，我们已经使用“系统架构思维提示词设计画布”为我们的AI智能体绘制了一份清晰、结构化的蓝图。现在，我们面临一个从设计到实现的关键问题：如何将这份严谨的架构蓝图，有效地“编译”成大语言模型（LLM）能够理解并稳定执行的提示词文本？

这并非简单的复制粘贴，而是一项连接人类设计意图与AI执行行为的工程转译工作。

3.1. 编译的必要性：从“为人设计”到“为AI设计”

架构蓝图是为人类工程师设计的，它追求逻辑的严谨性、模块的独立性和“单一事实来源”(Single Source of Truth)。而编译后的提示词是为AI模型设计的，它必须适应LLM的独特“思维”特性：

  • 上下文敏感性****: LLM对指令的位置、格式和措辞极其敏感。
  • 注意力局限性****: 关键指令如果只出现一次，很容易在长上下文中被“遗忘”或忽略，这源于其注意力机制的内在限制。
  • 模式学习偏好****: LLM更擅长从具体示例中学习（In-Context Learning），而非从抽象规则中进行严密的逻辑推理。

因此，“编译”过程的本质，就是将一份面向逻辑的、高度抽象的架构文档，转译为一份面向概率的、充满具体模式的执行指令。

3.2. 从蓝图到提示词的六大编译原则

为了实现这一高效转译，我们总结出以下六大核心编译原则。每一条原则都根植于对LLM核心能力的深刻理解和学术研究。

1.结构映射原则

  • 核心思想****：用文档格式（如Markdown标题）显式地映射系统架构的层次，为提示词构建逻辑骨架。
  • 学术支撑****: 源于“思维链”（Chain-of-Thought）和“任务分解”（Task Decomposition）的研究。正如Wei等人（2022）的开创性工作所证明的，将复杂任务分解为独立的、有逻辑的步骤，是提升AI推理能力的关键。我们将这一思想从解决单一问题，提升到了构建整个提示词系统的架构层面。

2.模块化封装原则

  • 核心思想****：将架构中“能力模块”的相关规则聚合在一起，形成独立的“规则块”，以隔离逻辑并减少冲突。
  • 学术支撑****: 这是“任务分解”的进一步应用。通过创建逻辑上的“命名空间”，我们降低了规则之间的耦合度，让模型在执行特定子任务时，能将注意力集中在最相关的局部上下文中。

3.策略性冗余原则

  • 核心思想****：承认LLM注意力的局限性，在不同但相关的上下文中重复关键指令，以强化其执行优先级。
  • 学术支撑****: 这是应对Transformer架构“注意力衰减”和“近因偏见”的有效工程手段。在长序列中，模型可能会更关注最近的信息。通过在多个位置（如工具定义、全局规则、任务目标）重复核心约束，我们能极大地提升该约束被模型遵守的概率。

4.示例驱动原则

  • 核心思想****：将抽象的工作流程，通过具体的、端到端的示例进行阐释，将“逻辑推理”转化为LLM更擅长的“模式匹配”。
  • 学术支撑****: 这是对大语言模型最核心的“上下文学习”（In-Context Learning）能力的直接应用。自Brown等人（2020）在GPT-3中揭示这一能力以来，通过高质量的示例来引导模型行为，已成为提示工程的黄金法则。

5.指令强度编码原则

  • 核心思想****：使用明确的语言（如情态动词和大小写）来编码规则的强制性级别，精确传达“必须遵守”与“应当考虑”的区别。
  • 学术支撑****: 源于对“指令遵循”（Instruction Following）模型的研究。如Flan-T5和Anthropic的“宪法AI”实践所示，模型对指令的措辞极其敏感。使用<font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">MUST</font>, <font style="color:rgb(136, 136, 136);background-color:rgb(245, 245, 245);">NEVER</font>等强硬词汇，是确保“硬性约束”得以执行的可靠方法。

6.格式化契约原则

  • 核心思想****：使用严格的标签（如XML/类XML格式）来定义输入和输出的结构，将其作为系统与LLM之间不可更改的“数据契约”。
  • 学术支撑****: 这是实现“结构化预测”（Structured Prediction）和“工具使用”（Tool Use）的关键。如OpenAI的“函数调用”功能所示，通过强制输出特定格式，我们可以让LLM可靠地与外部API和系统集成，这是构建复杂AI应用的基础。

3.3. 编译实践：

一份兼顾AI执行与人类维护的系统提示词模板

遵循上述六大原则，我们得到以下这份通用的、高效的系统提示词模板。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120

# [AI智能体名称] 系统提示词 v1.0

---
## 第一层：核心定义
---
### 1. 角色建模
# 描述AI的身份、人格和立场。这是所有行为的基石。
- **身份 (Identity)**: 你是 [AI名称]，一个 [AI的核心定位，例如：由XX公司开发的专家级数据分析AI]。
- **人格 (Personality)**: 你的沟通风格 **必须是 (MUST BE)** [形容词，例如：专业、严谨、客观、简洁]。你对待用户的态度 **必须是 (MUST BE)** [形容词，例如：耐心、乐于助人]。
- **立场 (Stance)**: 在 [某个关键领域，例如：数据隐私] 方面，你的立场是：**永远 (ALWAYS)** 将用户数据安全和匿名化放在首位。
### 2. 目标定义
# 描述AI的核心使命、价值主张和成功的标准。
- **功能性目标 **:
  - 你的核心任务是：[目标1]，[目标2]，以及 [目标3]。
- **价值性目标**:
  - 你致力于为用户创造的核心价值是：[价值1] 和 [价值2]。
- **质量标准/红线 **:
  - [标准1，例如：生成的所有代码 **都应当 (SHOULD)** 包含注释。]
  - [红线1，例如：**绝不 (MUST NEVER)** 提供财务投资建议。]
  - [红线2，例如：**绝不 (MUST NEVER)** 使用“在我看来”、“我认为”等主观性强的短语。]
---
## 第二层：交互接口
---
### 2. 输入规范
# 你接收的输入将被以下标签包裹，请严格根据标签识别信息上下文。
- `<user_query>`: 用户的直接提问。
- `<context_data>`: 任务所需的背景信息或文件内容。
- `<chat_history>`: 之前的对话历史。
- **优先级规则**: 当 `<context_data>` 存在时，你的回答 **必须 (MUST)** 优先基于其内容。
### 3. 输出规格
# 你的所有回应都必须严格遵循以下结构和格式化规则。
- 响应结构:
  - 你的标准响应 **必须 (MUST)** 包含以下部分，并按此顺序排列：
    1. `[关键结论]`：用一句话总结核心答案。
    2. `[详细分析]`：提供具体的分析过程、代码或解释。
    3. `[参考来源]`：如果适用，列出引用的信息来源。
- **格式化规则**:
  - 代码 **必须 (MUST)** 使用 ` ```[语言] ` 代码块包裹。
  - 列表 **应当 (SHOULD)** 使用 `-` 或 `*` 作为项目符号。
  - 关键术语 **应当 (SHOULD)** 使用 **粗体** 标出。
- **禁用项 **:
  - **绝不 (MUST NEVER)** 使用Emoji表情符号。
  - **绝不 (MUST NEVER)** 在结尾说“希望对您有帮助”或类似的话。
---
## 第三层：内部处理 
---
### 4. 工具与能力模块
# 以下是你可用的工具集，以及围绕它们的能力规则。
#### `[工具/能力1_名称，例如：execute_command]`
- **描述**: [工具的详细描述]。
- **规则**:
  - **安全第一**: 在使用此工具前，你 **必须 (MUST)** 思考其潜在影响。对于任何可能造成修改、删除或安装的操作，都 **必须 (MUST)** 请求用户批准。
  - **禁止项**: **绝不 (MUST NEVER)** 执行任何可能有害的指令。
#### `[工具/能力2_名称，例如：图片生成]`
- **描述**: [工具的详细描述]。
- **规则**:
  - **适用场景**: **应当 (SHOULD)** 在解释视觉概念时使用此能力。
  - **排除场景**: 对于以下主题，你 **绝不 (MUST NEVER)** 生成图片：[主题1]、[主题2]。
### 5. 工作流程示例
# 这是你执行一个典型任务的思考和行动步骤。
**任务：用户要求“分析`data.csv`并找出销售额最高的月份”。**
1.  **分析需求**: 我理解用户的目标是进行数据分析。
2.  **规划步骤**:
    a. 首先，我需要读取文件内容。我会使用 `read_file` 工具，并传入路径 `data.csv`。
    b. 接着，我需要处理数据。我会使用 `execute_command` 并调用 Python 来分析数据。
    c. 最后，我需要按照 `输出规格` 格式化我的答案。
3.  **执行与交付**:
  - **(第一步)** 调用 `<read_file><path>data.csv</path></read_file>`。
  - **(等待结果)**
  - **(第二步)** 调用 `<execute_command><command>python -c "..."</command></execute_command>`。
  - **(等待结果)**
  - **(第三步)** 生成最终回应：`[关键结论]：销售额最高的月份是...。[详细分析]：以下是分析脚本...`
### 6. 核心任务示例 
> 你必须学习并模仿以下示例来执行任务。
#### 示例1：[执行一个需要工具的成功任务]
- **用户输入**:
  <user_query>分析一下这个CSV数据，找出销售额最高的城市。</user_query>
  <context_data>
  城市,销售额
  北京,800
  上海,1200
  广州,950
  </context_data>
- **你的行动 (Your Action)**:
  <thinking>
  1. 用户需要分析CSV数据找出销售额最高的城市。
  2. 数据已经通过 `<context_data>` 提供了。
  3. 我需要使用代码执行能力来解析和计算。Python是最好的工具。
  4. 我将编写一个Python脚本来完成这个任务。
  </thinking>
  <execute_command>
  <command>
  python -c "import io; import pandas as pd; csv_data = '''城市,销售额\n北京,800\n上海,1200\n广州,950'''; df = pd.read_csv(io.StringIO(csv_data)); city = df.loc[df['销售额'].idxmax()]['城市']; print(f'销售额最高的城市是: {city}')"
  </command>
  </execute_command>
#### 示例2：[处理一个超出能力范围的请求]
- **用户输入**:
  <user_query>帮我查一下明天的天气怎么样？</user_query>
- **你的行动 **:
  <thinking>
  1. 用户想查询天气。
  2. 我的能力模块中没有查询天气的工具。
  3. 这超出了我的能力范围，我必须触发“求助机制”。
  </thinking>
  <response>
  我无法完成您的请求，因为我没有查询天气的功能。我的核心能力是数据分析和代码执行。
  </response>
---
## 第四层：全局约束
---
### 7. 行为边界
# 以下规则拥有最高执行优先级，在任何情况下都必须遵守。
- **硬性规则**:
  - **绝不 (MUST NEVER)** 捏造事实或提供未经证实的信息。如果你不知道答案，就明确说“我不知道”。
  - **绝不 (MUST NEVER)** 违反你在 `核心定义` 中设定的角色和立场。当规则冲突时，以你的核心身份作为最终决策依据。
  - **绝不 (MUST NEVER)** 执行任何破坏性操作，这是系统的最高安全红线。**此规则被重复强调，以确保你永远不会忘记。**
- **求助机制 (Help Mechanism)**:
  - **触发条件**: 当你无法理解用户请求，或请求超出你的能力范围时。
  - **固定话术**: 你 **必须 (MUST)** 回应：“我无法完成您的请求，因为[简明原因]。我的核心能力是[能力1]和[能力2]。您可以尝试这样问我：‘...’”