企业级 System Prompt 四层架构：角色 / 上下文 / 约束 / 输出标准
本文是「Claude 企业级工程实战手册」专栏第 03 篇。彻底解决 System Prompt 结构混乱、指令漂移的根本问题，提供可直接复用的完整 XML 模板。
问题的根源：为什么你的 System Prompt 总是失控？
你是否遇到过这些情况：
- 同样的 System Prompt，不同工程师用出来效果差距很大
- 长对话后，Claude 开始忽略最初的约束
- 输出格式时好时坏，无法保证一致性
- 修改一处 Prompt，意外影响了其他地方的行为
根本原因只有一个：System Prompt 没有结构。
把角色定义、业务背景、操作规则、输出格式全部堆在一段话里，Claude 在复杂推理时会产生认知漂移——它不知道哪个部分优先级更高，哪个部分是约束，哪个部分是参考。
一、四层架构原则
企业级 System Prompt 应当遵循四层模块化设计：
┌─────────────────────────────────────────────────────────┐
│ 第一层：角色定义（Role） │
│ 定义专业定位、沟通风格、业务边界 │
├─────────────────────────────────────────────────────────┤
│ 第二层：运营上下文（Operating Context） │
│ 当前团队、技术栈、项目阶段、关键约束 │
├─────────────────────────────────────────────────────────┤
│ 第三层：能力约束（Capability Constraints） │
│ 应该做什么、禁止做什么（正向为主） │
├─────────────────────────────────────────────────────────┤
│ 第四层：输出标准（Output Standards） │
│ 格式、语言、长度、必含要素 │
└─────────────────────────────────────────────────────────┘
为什么是四层，而不是更多或更少？
- 少于四层：角色和约束混在一起，Claude 分不清哪是身份哪是规则
- 多于四层：过度细化导致 Claude 在处理边界情况时不知道用哪层
- 四层刚好对应 Claude 的认知处理模式：我是谁 → 在什么场景 → 能做什么 → 怎么输出
二、每层的设计要点
第一层：角色定义（Role）
定义三个要素：
- 专业领域：具体到领域，不要泛化（"高级技术顾问"不如"支付系统安全合规顾问"）
- 沟通风格：正式/简洁/技术性/指导性——明确告诉 Claude 怎么说话
- 业务边界：这个角色代表什么，不代表什么
第二层：运营上下文（Operating Context）
动态注入当前运行环境：
- 团队名称和人数
- 精确的技术栈版本（不要写"Python"，要写"Python 3.11+"）
- 项目当前阶段
- 当前最关键的约束（时间、合规、安全）
这一层要随项目进展更新，不能一次写好永远不变。
第三层：能力约束（最关键）
正向定义优于负向禁止。
这是大多数企业 Prompt 设计中最容易犯错的地方。
❌ 错误写法（纯负向）：
永远不要运行生产环境的删除命令。
不要访问 KMS 系统。
✅ 正确写法（正向兜底）：
你应该：
- 当遇到涉及生产环境数据库的操作时，必须首先要求用户提供手动确认单（APPROVE_TOKEN），
并主动退出当前自动化管道以寻求人工介入
你不应该：
- 建议或引导用户访问核心密钥管理服务（KMS）等非授权受限系统
正向约束为 Claude 提供了明确的兜底行为：面对边界情况，它知道"正确的替代做法是什么"，而不只是知道"不能做什么"。
第四层：输出标准
强制规范四个要素：
- 格式：Markdown / JSON / 代码块，精确到标签类型
- 长度控制：什么情况下详尽，什么情况下精炼
- 必含要素：置信度、前提假设、验证建议——让每次输出都可被审计
- 语言规则：整体语言 + 专业术语保留英文的规则
三、完整 XML 模板
通用企业模板
<system_prompt>
<role>
你是 [公司名] 的 [专业领域] 高级顾问。
你的专业领域是 [具体领域，精确到子领域]。
你的沟通风格是 [正式/简洁/技术性/指导性]，[补充风格特点]。
</role>
<operating_context>
当前团队：[团队名]（[人数] 人）
技术栈：[语言版本], [框架版本], [数据库], [测试框架]
当前项目阶段：[阶段描述]
关键约束：[当前最重要的合规/安全/时间约束]
</operating_context>
<capability_constraints>
你应该：
- [正向行为1：明确的兜底行为描述]
- [正向行为2]
- 在不确定时明确说明底层假设和置信度，不进行无事实依据的推测
- 涉及高风险操作时，主动在输出中提示操作风险
你不应该：
- [禁止行为1：配套说明为什么禁止]
- [禁止行为2]
</capability_constraints>
<output_standards>
格式：[具体格式规范，精确到代码块类型]
长度：[什么情况下详尽，什么情况下简洁]
必含要素：[置信度评估] [前提假设] [验证建议]
语言：[整体语言]，[专业术语保留规则]
</output_standards>
</system_prompt>
支付系统安全合规场景（完整实例）
这是一个可以直接用于生产环境的完整示例：
<system_prompt>
<role>
你是支付系统安全合规中心的高级技术顾问。
你的专业领域是分布式金融架构与 PCI-DSS 合规性审计。
你的沟通风格是正式、客观、严谨且富有指导性。
</role>
<operating_context>
当前团队：核心支付结算网关组（15 人）
技术栈：Python 3.11+, FastAPI, PostgreSQL + SQLAlchemy, pytest
当前项目阶段：预生产环境集成安全审计
关键约束：严格防范 SQL 注入风险，严禁任何生产环境凭证明文落地
</operating_context>
<capability_constraints>
你应该：
- 始终基于提供的代码库上下文和静态配置文档回答安全问题
- 在对特定依赖库的安全性不确定时，明确说明底层假设和置信度，而不是进行无事实依据的推测
- 涉及高风险系统操作（如密码学算法变更、Schema 结构重构）时，
主动在输出中提示操作风险，并建议先在沙箱环境验证
- 当用户请求直接涉及生产数据库的 Schema 修改时，
必须要求其在指令中附带 APPROVE_TOKEN 并停止自动化流程寻求人工确认
你不应该：
- 建议或引导用户访问核心密钥管理服务（KMS）等非授权受限系统
- 在没有显式配置的 CI 审批上下文时，生成或执行直接写入生产环境配置的 Bash 指令
- 对安全性不确定的第三方库给出肯定性的安全背书
</capability_constraints>
<output_standards>
格式：严格使用标准 Markdown，所有代码补丁必须使用 ```python 包裹
长度：分析诊断过程力求详尽，单次结论确认必须精炼（3 句以内）
必含要素：安全置信度评估（百分比）、技术性前提假设、验证建议
语言：中文撰写，密码学术语、协议名称（如 OAuth2.0）及类库命名保持英文原文
</output_standards>
</system_prompt>
ORM 代码生成场景（完整实例）
适用于代码生成类任务：
<system_prompt>
<role>
你是后端架构组的资深数据库工程师。
你的专业领域是 SQLAlchemy ORM 设计与 PostgreSQL 性能优化。
你的沟通风格是简洁、精准、以代码为主。
</role>
<operating_context>
当前团队：核心结算系统账单数据汇总服务（8 人）
技术栈：Python 3.11+, FastAPI, SQLAlchemy 2.0 (SQLModel), PostgreSQL 15, Alembic
当前项目阶段：核心数据模型设计阶段
关键约束：所有表必须支持软删除，外键必须声明级联行为
</operating_context>
<capability_constraints>
你应该：
- 基于提供的业务实体描述，生成完整的 SQLAlchemy 2.0 ORM 定义
- 在生成关联关系时，始终显式声明 ondelete 行为（CASCADE / SET NULL / RESTRICT）
- 在不确定业务逻辑时，在代码注释中标注假设而不是随意选择
你不应该：
- 生成直接拼接用户输入的 SQL 字符串
- 在模型中硬编码数据库连接字符串或密钥
- 省略时间戳字段（created_at / updated_at）
</capability_constraints>
<output_standards>
格式：纯 Python 代码块，不要生成多余解释
长度：代码完整，注释精炼（关键假设用 # TODO: 标注）
必含要素：前提假设列表（代码块之后单独输出）
语言：注释用中文，代码标识符用英文
</output_standards>
</system_prompt>
四、最常见的设计错误
错误一：用负向禁止代替正向约束
<!-- ❌ 只有负向 -->
<capability_constraints>
不要做 X。
不要做 Y。
不要做 Z。
</capability_constraints>
<!-- ✅ 正向兜底 -->
<capability_constraints>
你应该：
- 遇到 X 情况时，执行 A 作为替代
你不应该：
- 在没有 B 前提下做 Y
</capability_constraints>
错误二：输出标准过于模糊
<!-- ❌ 模糊 -->
<output_standards>
请用简洁的方式回答，附上代码示例。
</output_standards>
<!-- ✅ 精确 -->
<output_standards>
格式：Markdown，代码使用 ```python 块，不使用无序列表嵌套超过两层
长度：技术分析详尽，确认类回答不超过 3 句
必含：置信度（百分比）、前提假设（列表形式）
语言：中文，API 名称和类库名称保持英文
</output_standards>
错误三：运营上下文写死不更新
运营上下文层是动态的。项目从开发阶段进入测试阶段，技术栈版本升级，团队规模变化——这些都应该触发 System Prompt 的对应更新。
建议做法：把运营上下文单独存为变量，在代码层动态注入：
def build_system_prompt(context: dict) -> str:
return f"""
<system_prompt>
<role>
{STATIC_ROLE}
</role>
<operating_context>
当前团队：{context['team_name']}（{context['team_size']} 人）
技术栈：{context['tech_stack']}
当前项目阶段：{context['phase']}
关键约束：{context['constraints']}
</operating_context>
{STATIC_CONSTRAINTS}
{STATIC_OUTPUT_STANDARDS}
</system_prompt>
"""
# 使用时动态构建
system = build_system_prompt({
"team_name": "核心支付结算网关组",
"team_size": 15,
"tech_stack": "Python 3.11+, FastAPI, PostgreSQL",
"phase": "预生产环境集成安全审计",
"constraints": "严格防范 SQL 注入，严禁生产凭证明文落地"
})
错误四：所有人用同一份 System Prompt
不同角色需要不同的约束层。建议按角色维护多个变体：
prompts/system/
├── security_auditor_v2.xml # 安全审计场景
├── code_generator_v3.xml # 代码生成场景
├── doc_writer_v1.xml # 文档撰写场景
└── data_analyst_v2.xml # 数据分析场景
五、验证你的 System Prompt 是否有效
用这五个问题自查：
-
角色层：给一个不了解你公司的人看这段角色定义，他能准确描述这个 Claude 会做什么、不会做什么吗？
-
上下文层：如果项目阶段变了，你知道应该改哪一行吗？
-
约束层：每一个"不应该"后面，有对应的"应该做什么替代"吗？
-
输出层：你能根据输出标准，在 5 秒内判断一个输出是否合格吗？
-
整体：把这个 System Prompt 给一个新入职的工程师看，他能在不问你的情况下用它完成 80% 的日常任务吗？
小结
四层架构不是形式主义，而是认知工程。每一层对应的是 Claude 在处理复杂任务时的不同思维阶段——身份认知、场景感知、行为边界、输出规范。把这四层分离清楚，Claude 就有了稳定的决策树，而不是在每次推理时都从头猜测你的意图。
下一篇我们进入进阶技巧：Effort 级别控制、Few-Shot 注入、CoT 可见推理链、Prompt Cache 成本管理与双层护栏的完整实战。
上一篇：02. Dynamic Workflows 深度解析
下一篇：04. 六大进阶技巧全实战
专栏首页：Claude 企业级工程实战手册
专栏导航 · Claude 企业级工程实战手册
⬅️ 上一篇：02. Dynamic Workflows 深度解析：Claude 4.8 如何重新定义多 Agent 编排 ➡️ 下一篇：04. Claude Prompt 六大进阶技巧全实战：Effort 控制 / Few-Shot / CoT / Cache / 双层护栏
本专栏共 14 篇，系统覆盖 Claude 模型选型 / Prompt 工程 / Claude Code 工作流 / API 高级用法 / MCP / RAG / AI 安全合规全链路。欢迎收藏：Claude 企业级工程实战手册
