大语言模型在用户首条消息之前通常已经接收了系统级指令。这些指令可能涉及角色设定、工具使用、输出格式、内容安全、记忆与任务执行规则。对于研究人员和 AI 应用开发者而言，理解这类预设规则有助于分析模型行为差异；但如果资料缺少版本、来源和验证边界，又容易将特定场景下的文本误作模型长期且完整的行为规范。
system_prompts采用以目录和 Markdown 文件为主的轻量结构。顶层可按模型厂商或产品划分资料，例如对话产品、代码助手、搜索助手与其他 AI 工具；目录下继续以模型名称、产品形态或运行场景细分文件。这样的结构使研究者能够在同一主题下比较不同模型版本，也便于将 Web、API、命令行或特定工具环境中的文本区别开来。
对于系统提示词研究，文件名本身应被视为重要元数据：模型名称、产品入口、捕获时间或版本标签会影响文本的解释范围。将不同环境的提示词混合比较，可能会忽略工具可用性、上下文注入、账户状态或产品功能差异。资料库按目录保存原始文本，能为后续增加版本说明、变更记录和场景标签保留基础。
这类文档库不依赖数据库或专用运行时。使用者可通过 Git 克隆仓库，进入相应目录后使用 Markdown 阅读器或代码编辑器查看文件；贡献者则可借助版本控制提交新增材料和修订记录。对长文本，编辑器的全文检索、差异比较与历史查看能力，比单纯浏览页面更适合进行跨版本分析。
从文本采集到模型行为分析，需要建立验证链路
系统提示词文本能够提供模型行为研究的线索，但不应被直接视为所有环境下均有效的完整规则。模型供应方可能随版本、产品入口、工具集合和服务策略调整指令；同一产品也可能在会话中注入动态上下文。因此，使用 system_prompts 进行分析时，应将文件内容与其标注的模型、产品和时间范围绑定，并保留资料获取方式与版本快照。
较稳妥的研究流程可分为三个层次。第一层是文本层，记录提示词中的角色、约束、工具描述和输出要求；第二层是行为层，以合规的测试输入观察公开产品或自建评测环境中的响应差异；第三层是结论层，明确哪些现象来自文本推断，哪些仅是某次测试中的观察。这样能够避免把单一文本片段扩展为对模型能力、安全策略或厂商意图的绝对结论。
system_prompts 中涉及 API 注入、工具调用和编码助手的资料尤其需要保留场景边界。工具说明通常依赖具体的接口、权限与上下文协议；将它们脱离原有运行环境复用，可能无法得到同样的行为。面向内部 AI 应用的团队可将此类文本转化为审计问题，例如系统指令是否约束了数据访问、工具参数是否存在权限校验、失败处理是否向用户暴露不必要的内部细节。
版本比对支持提示词治理与回归检查
对 AI 产品而言，系统提示词的变化可能影响回答风格、拒绝策略、工具选择和任务执行顺序。将提示词以文件形式纳入 Git 管理后，可以通过提交记录和文本差异识别新增、删除或改写的约束语句。研究者可据此建立变更日志，标注发生变化的模型版本、产品场景及可能受影响的测试用例。
在自建 AI 应用中，也可以借鉴这种管理方式：将业务系统提示词、工具定义与评测用例分开存放，并要求每次修改关联相应的版本说明和回归检查。提示词文本本身不应承载密钥、用户隐私或可直接执行的高权限操作；涉及数据查询、文件访问或外部调用的能力，仍需由服务端权限、参数校验与日志审计承担真正的安全边界。
对于公开收集的文本，维护时应尽量增加可复现的上下文说明，例如文件对应的产品入口、采集日期、原始格式和已知缺失部分。若无法确认内容是否完整或仍然有效，应使用“待验证”或“历史快照”等标识。这样的记录方式有助于使用者理解资料的适用范围，也能降低误读旧版本文本的风险。
使用边界：研究参考不能替代安全控制
system_prompts 适合用于模型行为研究、提示词设计讨论、版本比对和安全评审准备，而不适合被用作绕过产品保护措施的操作指南。系统提示词即使被公开或收录，也只是 AI 系统整体控制的一部分；身份认证、权限控制、数据隔离、工具授权、速率限制和服务端审计仍应由应用架构落实。
在组织内部引用这类资料时，应遵守适用的服务条款、知识产权和数据使用要求，并避免将不确定来源的文本当作事实性证据。对于需要形成正式安全结论的场景，应使用经授权的测试环境、明确范围的评测方法和可审计的证据链，而不是仅凭资料库中的单份文本下判断。
结语
system_prompts 将主流 AI 产品相关的系统提示词资料以可检索的文档结构集中管理，为观察模型行为规则和提示词版本演进提供了研究入口。它更适合作为分析和审计工作的起点：通过明确文件的版本、场景和验证状态，把文本资料转化为可追溯的研究证据，而不是将其等同于模型的全部控制逻辑。
项目地址：https://www.gitcc.com/lufei/system_prompts_leaks-cn
