研究 system prompt，最有价值的是看角色、证据、工具和边界如何配合，而不是把一份声称来自知名产品的长文本直接复制到自己应用。本文用虚构的社区剧院购票说明助手，覆盖提示词拆解、角色行为设计、加固与团队治理。系统提示只是运行系统的一部分，模型能力、工具接口、权限和检索同样影响结果。
先确认资料身份与学习范围
网上提示词集合可能是官方发布、历史版本、用户推测或提取内容，不能仅凭热门仓库宣称完整且代表当前产品。记录来源、取得方式、时间、版本、许可与可核实程度；没有依据就标“来源未核实”，不尝试突破产品限制获取隐藏指令。学习结构不需要复刻品牌身份、内部规则或独有文案。
开始前检索 GitHub 的开源教学方案，参考 Anthropic 的互动提示工程教程与课程仓库，适合学习清晰任务、角色与评估的对照练习。教材中的 API 示例可能有版本前提，采用时查当前官方说明，不将旧 notebook 当所有模型通用接口。本文没有安装课程、调用模型或核验某商业产品的内部提示。
场景一：拆解结构，连到可观察行为
给每段资料做功能标注：稳定职责、当前任务上下文、工具条件、输出要求、失败处理与示例。System/Context/Task/Output 可以作为分析框架，不是所有 API 都存在的四种消息角色。具体产品的指令层级和参数由当前接口决定，不能把四个标题放进同一字符串就认为获得了四层权限。
提取的是机制而非原句。例如“回答需要引用当前票务政策”应拆成来源选择、时效检查和引用格式；“需要时问用户”应拆成哪些信息缺失、哪些可合理默认、哪些动作需要额外授权。检查示例是否与规则冲突，输出格式是否能表达未知，工具描述是否明确副作用。
将提示片段与实际任务对照。剧院助手可以解释退换政策、查演出时间和起草问题清单，但不应仅因用户说“帮我看看”就取消订单。把用户任务、工具返回、网页内容分别作为不同信号，外部资料中的指令不能改变任务或扩大权限。角色语气也不能覆盖事实与操作边界。
拆解表交付段落功能、预期行为、前提、可测试案例与剩余疑点。只从文本推测的行为写推测，不能声称某个产品一定按它运行。长 prompt 中的安全句子与真正执行的服务端权限不是同一件事，复制文本不能复制整套系统能力。
场景二：从真实职责设计角色卡
角色卡先写服务对象、任务、工具与权限，不用“顶级专家”代替定义。剧院助手应诚实说明它是自动化辅助，不冒充客服员工、经理或已经做过人工核验。语气可友好简洁，遇到未知先说明证据缺口，不捏造政策、退款到账时间或私人订单信息。
稳定规则说明职责与边界；当前用户请求提供具体演出、问题和允许动作；检索政策附版本、日期和来源。不要把可能不可信的用户文本或网页片段拼成高优先级指令。变量模板只接受约定字段，缺值时明确处理，不能让一个姓名字段夹带新的工具权限。
可用角色片段是：“依据获准的当前政策解释购票问题。区分政策事实、订单状态和建议。来源冲突或订单状态不可查时说明未知；不要声称已经取消、退款或发送消息，除非工具结果证实相应动作。”它是原创示例，不是已执行测试，也不替代应用侧控制。
若采用循环执行，写清观察、判断、工具调用与验证的状态，不要求模型输出完整内部推理。用户通常需要简短理由、依据和下一步，不需要私密思维过程。工具调用失败或超时要核对实际结果，未知外部状态不盲目重试，设置最大次数、时长与费用。
同一业务可以保留公共要求与模型适配层。先固定验收，再比较不同模型对格式、工具和拒绝边界的表现；不要假定一份提示完全通用，也别未经比较就维护无数分叉。模型版本更新后复测关键任务，记录哪个差异确需专门适配。
场景三：加固要连到运行时控制
提示中的边界有帮助，但不能保证防绕过。将可执行权限、订单归属、允许目的地、输入校验与副作用控制放在应用和工具侧。不要将凭据、敏感数据或真正不能泄露的秘密存进提示，再指望一句“不能透露”提供保护。来源内容与工具结果保持数据身份，不授权其修改系统规则。
设计对照样本：正常政策问题、资料冲突、缺订单权限、诱导冒充人工、外部页面要求改任务、请求暴露内部信息和超时结果未知。静态脚本可查模式与缺项，但不能证明真实模型不会被绕过；行为测试也只覆盖所测输入，二者结果分别记录。
审计报告包含测试环境、提示与工具版本、输入、预期、实际输出、工具动作和证据。区分漏洞、可疑行为与未覆盖。未知或失败不伪装成通过，不用关键词命中直接宣称系统已被攻破。加固修改后跑正常任务回归，避免把所有问题都拒绝掉才获得表面安全。
团队提示库从盘点开始：名称、用途、来源、主机、模型、负责人、版本、权限与最近评测。按任务和受众分组，语义相似但边界不同的提示不要盲目去重。标记正式、试验、退役和替代关系，维护索引，避免业务仍加载旧版本。
每次改动保留差异、原因、样本和接受决定，先小范围试用再推广。月度检查可作为起点，政策、工具权限或模型变化应及时复核。共享库不放私人订单、密钥或真实聊天，访问与发布权限分别管理。回滚要核对实际部署版本，而不是只恢复某个文件。
技能关联与可验证前提
本篇不将原文中的提示拆解器、角色卡或硬化工具名称直接冒充 SkillPI 已核验记录。目录已有提示相关条目也不能仅按关键词视为通用审计器；用途、主机和许可要逐一核对。新增匹配候选时确认公开详情、固定来源、依赖和准确步骤，再更新拆解、设计或审计关联。
发现工具可辅助查找，不能保证每次推荐最优或自动获得安装权限。某个脚本名带 audit 不表示做过安全扫描，来源核对、静态检查、实际运行与行为评测是不同证据。本文只提供工程方案，没有运行审计脚本或部署购票助手。
FAQ 与验收
能直接照抄知名产品吗？先确认来源与许可，学习结构后按自己的工具和任务重写，不把未核实文本当权威。角色写得强是否一定更准？不，证据、工具和检查更关键，角色不能制造专业资质。
system 与 user 是否分别只是怎么做和做什么？这是粗略记忆法，实际消息可以包含多类内容，层级和权限依接口与主机规则。怎样防止绕过？结合最小权限、输入边界、运行检查和实测，不承诺靠提示字句绝对安全。
交付应包含来源拆解表、原创角色卡、变量约定、工具边界、模型对照、正常与异常样本、提示库版本及回滚。明确计划与已运行范围，保证用户能理解当前限制，而不是只交一篇长人设文档。
来源
本文按中英文原文的拆解、角色设计、加固治理三类场景，以原创剧院助手重写，不沿用用户引语、热门仓库真实性和安装量保证。学习参考 Anthropic 互动教程与官方课程仓库。教材适用范围与当前接口需采用时再次核对。