企业官网建设流程全解析

1. 项目概述：当“系统提示词”从后台走到聚光灯下

最近在多个技术社区、AI产品讨论组和安全简报里，频繁看到system_prompts_leaks这个词被拎出来单独讨论——不是作为某个漏洞的编号，也不是某次攻防演练的代号，而是一种正在快速显性化的现象：大量本该严格隔离、仅在模型推理层内部生效的system prompt（系统提示词），正以意想不到的方式暴露在用户侧、日志中、API响应体、前端调试面板甚至第三方监控工具里。我上个月帮一家做智能客服SaaS的客户做上线前安全复核，就发现他们的对话接口返回体里，response.metadata字段明文嵌着一行"system_prompt": "你是一个严谨、不提供医疗建议、不生成违法内容的客服助手……"——这行字本身没风险，但问题在于：它本不该存在。更早之前，在给教育类AI助教做Prompt工程优化时，我们团队曾把system prompt写进前端React组件的useEffect里做动态注入，结果构建产物里直接能grep到完整指令链。这些都不是孤例。system_prompts_leaks的本质，是AI应用开发流程中“提示词治理”环节的系统性失焦：我们花了大量精力调优user prompt的结构、温度值、few-shot样本，却默认system prompt是“基础设施级”的黑盒，理所当然地认为它只活在服务端内存里。但现实是，它正像老式打印机的缓存页一样，被无意间复印、截屏、日志归档、错误堆栈打印，甚至被浏览器开发者工具的Network面板原样捕获。这个问题不涉及模型权重泄露，也不属于传统Web渗透范畴，但它直接影响产品可信度、合规底线（比如GDPR对“系统行为逻辑”的透明度要求）和商业护城河——你的竞品只要抓一个请求，就能反向还原出你花三个月打磨的指令约束体系。适合关注这个话题的，不是纯安全工程师，而是所有正在把大模型能力封装成产品、API或嵌入式功能的开发者、产品经理和AI架构师。它不难修复，但必须从第一行代码开始就建立“提示词即敏感配置”的认知。

2. 核心机制拆解：为什么system prompt会“漏”？四个典型泄漏路径

要真正堵住system_prompts_leaks，得先理解它从哪里渗出来。我梳理了过去半年经手的17个真实案例，把泄漏路径归为四类，每类背后都有明确的技术动因和开发惯性。这不是偶然失误，而是当前主流AI开发范式与工程实践之间存在的结构性缝隙。

2.1 前端硬编码：把system prompt当常量塞进客户端

这是最直白也最危险的泄漏点。很多团队为了快速验证效果，直接在前端JavaScript里定义system prompt字符串，然后通过fetch发给后端API：

// ❌ 危险示例：前端明文存储 const SYSTEM_PROMPT = "你是一名持证心理咨询师，禁止给出药物建议，每次回复必须包含免责声明..."; fetch('/api/chat', { method: 'POST', body: JSON.stringify({ system_prompt: SYSTEM_PROMPT, // 泄漏源头 user_message: input.value }) });

问题在于：这段代码会被打包进main.js，任何用户打开DevTools的Sources面板，搜索心理咨询师或免责声明，瞬间定位。更糟的是，如果用了console.log(response)调试，system prompt会随响应体一起打印在控制台。我见过某在线法律咨询App，其system prompt里包含精确的《律师执业管理办法》第32条引用，结果被爬虫批量抓取后，竞品直接复刻了整套合规话术框架。为什么开发者会这么做？因为早期LLM API（如早期OpenAI Playground）允许前端直连，大家习惯了“prompt即参数”的思维；而现代BFF（Backend for Frontend）架构普及后，这种做法已彻底过时。真正的解法不是加密字符串（前端加密毫无意义），而是彻底移除前端对system prompt的感知权——它必须是后端服务的内部策略，前端只传业务上下文。

2.2 日志与监控埋点：把调试便利性当安全豁免权

运维同学最爱说：“先打个全量日志，出了问题好查”。但在AI服务里，这句口头禅可能直接导致system prompt外泄。典型场景有三个：
第一，API网关层的日志记录。某金融客户用Kong做API网关，配置了log-plugin记录所有请求体，结果审计时发现日志系统里存着数万条含"system_prompt":"请严格遵循《商业银行理财业务监督管理办法》..."的记录；
第二，APM工具（如Datadog、New Relic）的自动追踪。这些工具默认捕获HTTP请求的完整body，而不少团队在集成时没关闭capture_body选项；
第三，自研监控SDK的错误上报。当模型返回500 Internal Error时，有些SDK会把整个请求对象序列化上报，包括未清洗的system prompt。

提示：日志泄漏的隐蔽性在于，它不发生在用户交互链路，而藏在运维后台。一次误配可能让敏感指令在日志平台留存90天以上，且权限管控往往比业务数据库宽松得多。

2.3 错误响应体：把调试信息当用户友好

这是最令人心疼的泄漏——本意是帮用户排错，结果把底牌亮给了所有人。常见于两类错误：

• 模型服务超时/连接失败：后端捕获requests.exceptions.Timeout异常后，构造的错误响应体里包含原始请求参数，其中就有system prompt；
• 输入校验失败：比如用户发送了base64编码的图片，后端校验时发现非文本格式，返回{"error": "Invalid input", "debug_info": {"system_prompt": "...", "raw_input": "..."}}。

我帮某医疗AI平台做渗透测试时，用curl -X POST https://api.xxx.com/chat -d '{"system_prompt":"..."}'故意发送畸形JSON，触发了他们的500错误页面，HTML源码里赫然显示着完整的system prompt和当前模型版本号。这种泄漏的危害在于：它不需要登录态，不需要Token，只要知道API地址就能触发。而绝大多数扫描器（如Burp Suite的active scan）都会自动探测这类错误响应。

2.4 配置中心与环境变量：把“集中管理”误解为“全局可见”

很多团队用Consul、Nacos或AWS Parameter Store管理AI服务配置，认为“放配置中心就安全”。但问题出在读取方式：

• 如果后端服务启动时，把system prompt从配置中心拉下来，存为全局变量（如Python的app.config['SYSTEM_PROMPT']），然后在任意日志、监控或调试接口中直接引用该变量，泄漏风险依然存在；
• 更危险的是，有些团队把system prompt写进Docker容器的环境变量（-e SYSTEM_PROMPT="..."），结果在K8s集群里，kubectl describe pod命令就能看到所有env字段——而运维人员通常有该权限。

注意：配置中心的安全边界在于“谁有权读取”，而非“存哪儿”。真正的防护是分层：配置中心只存加密后的密文，服务启动时由Secret Manager解密并注入内存，且内存中的字符串在GC前主动覆写（Python可用ctypes.memset，Go可用unsafe包），杜绝dump内存时被提取。

3. 实操防护方案：从代码层到架构层的七道防线

堵住system_prompts_leaks不能靠单点修补，必须建立覆盖开发、测试、部署、运维全生命周期的防护链。以下是我在三个不同规模项目中验证有效的七道防线，按实施优先级排序，每道都附带可直接落地的代码片段和配置要点。

3.1 第一道防线：前端零接触——用BFF剥离system prompt逻辑

核心原则：前端永远不知道system prompt的存在。所有与模型交互的请求，必须经过BFF（Backend for Frontend）层，由BFF根据业务场景动态拼装system prompt。这样做的好处是，前端只需关心/api/v1/chat?scene=loan_advice这样的语义化路径，而BFF根据scene参数查表获取对应指令模板。

# ✅ BFF层实现（FastAPI示例） from fastapi import FastAPI, Depends, HTTPException from typing import Dict, Any # 指令模板库：键为业务场景，值为预编译的system prompt SYSTEM_PROMPT_TEMPLATES = { "loan_advice": "你是一名持牌信贷顾问，需依据《个人贷款管理暂行办法》第15条解释利率...", "insurance_claim": "你代表XX保险公司处理车险理赔，需引用《保险法》第23条说明时效要求..." } app = FastAPI() @app.post("/api/v1/chat") async def chat_endpoint( scene: str, user_message: str, # 其他业务参数... ): if scene not in SYSTEM_PROMPT_TEMPLATES: raise HTTPException(status_code=400, detail="Invalid scene") # 动态组装请求体，system_prompt不透出给前端 model_request = { "messages": [ {"role": "system", "content": SYSTEM_PROMPT_TEMPLATES[scene]}, {"role": "user", "content": user_message} ], "model": "gpt-4-turbo" } # 调用下游模型服务（如OpenAI API） async with httpx.AsyncClient() as client: response = await client.post( "https://api.openai.com/v1/chat/completions", json=model_request, headers={"Authorization": f"Bearer {OPENAI_API_KEY}"} ) return response.json()

关键细节：

• SYSTEM_PROMPT_TEMPLATES应从配置中心加载，且在BFF启动时完成初始化，避免运行时重复查询；
• 所有scene参数必须白名单校验，禁用任意字符串拼接；
• BFF返回给前端的响应体，必须剥离system角色消息（即使模型返回了，也要在BFF层过滤掉）。

3.2 第二道防线：日志脱敏中间件——让日志“看不见”敏感字段

无论用Log4j、Winston还是Sentry，都必须部署统一的日志脱敏中间件。重点不是“不记录”，而是“记录但不可读”。以Python的structlog为例：

import structlog import re # 定义脱敏规则：匹配system_prompt字段及其值 PROMPT_PATTERNS = [ (r'"system_prompt"\s*:\s*"([^"]*)"', r'"system_prompt": "[REDACTED]"'), (r'system_prompt=([^&\s]*)', r'system_prompt=[REDACTED]') ] def redact_sensitive_data(logger, method_name, event_dict): """日志脱敏处理器""" for key, value in event_dict.items(): if isinstance(value, str): for pattern, replacement in PROMPT_PATTERNS: value = re.sub(pattern, replacement, value) event_dict[key] = value return event_dict # 注册处理器 structlog.configure( processors=[ redact_sensitive_data, structlog.processors.JSONRenderer() ] )

实操心得：

• 不要依赖正则匹配system_prompt字面量，因为实际字段名可能叫sys_prompt、instruction或role_definition，需结合团队命名规范定制；
• 对于二进制日志（如Protobuf格式），脱敏必须在序列化前完成，否则无法解析；
• 在CI/CD流水线中加入日志扫描步骤：用grep -r "system_prompt" logs/检查测试环境日志，发现即阻断发布。

3.3 第三道防线：错误响应净化——让500错误不泄露任何线索

错误处理是泄漏重灾区，必须强制执行“最小信息原则”。以下是在FastAPI中实现的全局异常处理器：

from fastapi import Request, status from fastapi.responses import JSONResponse from starlette.exceptions import HTTPException as StarletteHTTPException @app.exception_handler(StarletteHTTPException) async def http_exception_handler(request: Request, exc: StarletteHTTPException): # 所有HTTP错误，只返回标准错误码和通用消息 return JSONResponse( status_code=exc.status_code, content={"error": "Request failed", "code": exc.status_code} ) @app.exception_handler(Exception) async def general_exception_handler(request: Request, exc: Exception): # 捕获所有未处理异常，记录详细日志（仅限服务端），但返回极简响应 logger.error("Unhandled exception", exc_info=exc, request_url=str(request.url), request_method=request.method) # 绝不返回exc.args或str(exc)，尤其避免包含request.body return JSONResponse( status_code=status.HTTP_500_INTERNAL_SERVER_ERROR, content={"error": "Internal error occurred"} )

关键经验：

• 禁用所有框架的debug=True模式上线，Django的DEBUG=True会直接渲染完整traceback，包含全部局部变量；
• 对于需要用户反馈的错误（如输入格式错误），用预定义错误码代替动态消息：{"error": "INVALID_INPUT_FORMAT", "hint": "Please send text only"}，hint字段不包含任何系统内部信息；
• 在API文档（如Swagger）中，明确标注所有错误响应体结构，杜绝“意外返回”。

3.4 第四道防线：配置加密与内存管理——让system prompt在内存中“不留痕”

当system prompt必须加载到内存时，需双重防护：静态加密+运行时保护。以AWS环境为例：

# 步骤1：用KMS加密system prompt明文 echo '你是一名持牌理财顾问...' | aws kms encrypt \ --key-id alias/llm-prompt-key \ --plaintext fileb:///dev/stdin \ --query CiphertextBlob \ --output text > /tmp/prompt.enc

# 步骤2：服务启动时解密并安全存储 import boto3 import ctypes from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def load_secure_system_prompt(): # 从S3或Parameter Store获取加密后的密文 encrypted_prompt = get_encrypted_prompt_from_s3() # KMS解密 kms_client = boto3.client('kms') response = kms_client.decrypt(CiphertextBlob=encrypted_prompt) prompt_bytes = response['Plaintext'] # 将bytes存入ctypes分配的内存块，并设置为不可读写以外的权限 buffer = ctypes.create_string_buffer(len(prompt_bytes)) ctypes.memmove(buffer, prompt_bytes, len(prompt_bytes)) # 关键：解密后立即清空原始bytes对象 prompt_bytes = b'\x00' * len(prompt_bytes) # 主动覆写 return buffer # 使用时：prompt_buffer.raw.decode('utf-8')

注意事项：

• KMS密钥必须启用自动轮转，且权限策略限制仅该服务角色可解密；
• ctypes内存块在服务重启时自动释放，无需手动管理；
• Python的gc.collect()无法保证立即回收，所以主动覆写是必须步骤。

3.5 第五道防线：网络层隔离——用API网关实现“指令防火墙”

在微服务架构中，API网关是最后一道可控防线。以Kong为例，配置一个插件拦截所有含system_prompt字段的请求：

# kong-plugin-system-prompt-block.yaml plugins: - name: request-transformer config: remove: json: ["system_prompt", "sys_prompt", "instruction"] protocols: ["http", "https"] - name: rate-limiting config: minute: 100 policy: local protocols: ["http", "https"]

部署后，任何携带system_prompt的请求在到达BFF前就被剥离字段，且高频请求会被限流。更进一步，可编写自定义Kong插件，对请求体进行深度检测：

-- kong/plugins/system-prompt-detect/handler.lua local BasePlugin = require "kong.plugins.base_plugin" local utils = require "kong.tools.utils" local SystemPromptDetectHandler = BasePlugin:extend() function SystemPromptDetectHandler:access(conf) SystemPromptDetectHandler.super.access(self, conf) local body = ngx.req.get_body_data() if body and type(body) == "string" then -- 检测常见system prompt关键词（需根据业务定制） if string.find(body, "持牌|合规|禁止|依据%s+第%d+条") then ngx.log(ngx.WARN, "Potential system_prompt leakage attempt") -- 记录告警但不阻断，用于安全审计 kong.log.alert("System prompt pattern detected in request body") end end end return SystemPromptDetectHandler

实测效果：某电商客户部署此插件后，一周内捕获37次来自爬虫的system_prompt探测请求，全部标记为高危事件。

3.6 第六道防线：CI/CD流水线卡点——让泄漏在上线前被拦截

防护不能只靠人工审查。我们在GitLab CI中加入了三道自动化卡点：

# .gitlab-ci.yml stages: - security-scan - build - deploy security-scan: stage: security-scan image: python:3.9 script: - pip install semgrep # 卡点1：扫描前端代码中的system prompt硬编码 - semgrep --config p/python --pattern '$X = "system_prompt:.*"' src/ # 卡点2：扫描日志配置文件中的敏感字段记录 - grep -r "system_prompt\|sys_prompt" logging_config/ || true # 卡点3：扫描Dockerfile中的环境变量注入 - grep -r "SYSTEM_PROMPT\|system_prompt" Dockerfile* || true allow_failure: false build: stage: build # ... 构建逻辑 deploy: stage: deploy # ... 部署逻辑

关键设计：

• semgrep规则需定期更新，覆盖新出现的字段别名（如role_definition,assistant_rules）；
• 所有卡点失败时，Pipeline自动中断，且通知安全负责人；
• 在PR模板中强制要求填写《Prompt安全声明》，说明system prompt的存储位置、访问权限和脱敏措施。

3.7 第七道防线：红队验证机制——用攻击者视角持续检验防护

再严密的防护也需要实战检验。我们建立了季度红队演练机制，模拟真实攻击者行为：

红队报告不写“存在风险”，而是写“在XX路径下，通过XX方法，可在XX时间内获取system prompt明文，影响范围包括XX业务”。这种表述直接推动整改，避免安全团队和开发团队陷入“有没有风险”的争论。

4. 深度排查与避坑指南：那些踩过的坑和血泪教训

防护方案列得再全，不如一线踩坑经验来得实在。我把过去一年处理system_prompts_leaks相关事件时，最痛的五个教训整理成速查表，每一条都对应一个真实故障。

4.1 教训一：别信“本地开发环境很安全”——Chrome扩展能偷走一切

某团队在本地开发时，为方便调试，把system prompt写进localStorage，并用React DevTools的console面板实时查看。他们认为“本地环境没外网IP，绝对安全”。结果一位实习生安装了某款“增强版网页截图”Chrome扩展，该扩展有"storage"权限，会定期同步localStorage到云端。两周后，竞品在招聘论坛上贴出一份“XX公司AI客服系统指令集”，内容与他们本地存储的完全一致。

实操补救：

• 本地开发禁用所有非必要Chrome扩展，尤其带storage、tabs权限的；
• 用sessionStorage替代localStorage，关闭标签页即销毁；
• 在.env.local中设置REACT_APP_DEBUG_MODE=false，通过环境变量控制调试逻辑开关。

4.2 教训二：JSON Schema校验不是万能的——它会放过“合法但危险”的字段

很多团队用JSON Schema校验API请求体，认为只要schema里没定义system_prompt字段，它就进不来。但攻击者会利用JSON的灵活性：

// 合法但危险的请求体（符合schema，但绕过校验） { "user_message": "你好", "metadata": { "system_prompt": "你是一名医生..." } }

如果schema只校验顶层字段，metadata下的任意子字段都不会被拦截。我们曾在一个医疗项目中发现，攻击者通过metadata.extra_params注入system prompt，而schema只定义了metadata: {type: "object"}，没做深度校验。

解决方案：

• 在Schema中启用additionalProperties: false，禁止任何未声明字段；
• 对metadata等嵌套对象，必须递归定义其结构，例如：

"metadata": { "type": "object", "properties": { "trace_id": {"type": "string"}, "user_id": {"type": "string"} }, "additionalProperties": false }

4.3 教训三：Server-Sent Events（SSE）响应体也会泄漏——别只盯JSON

SSE常用于流式输出AI响应，但它的响应头Content-Type: text/event-stream让很多开发者忽略内容安全。某新闻聚合App用SSE推送AI摘要，响应体格式为：

event: message data: {"role":"system","content":"你是一名资深编辑，需遵循《新闻记者证管理办法》..."}

攻击者用curl -N即可完整捕获所有data:行。而前端EventSourceAPI没有内置的字段过滤机制，导致system prompt随每条消息广播。

正确做法：

• SSE响应中绝不包含role: "system"的消息，BFF层在流式转发前过滤掉所有system角色；
• 用data:字段只传输业务数据，system prompt相关逻辑在BFF内部完成；
• 在Nginx层添加sub_filter规则，动态替换响应体中的敏感字符串（需谨慎评估性能）。

4.4 教训四：TypeScript类型定义≠运行时防护——any类型是泄漏温床

TypeScript的any类型是system prompt泄漏的隐形推手。某团队定义了如下接口：

// ❌ 危险：any类型让类型检查失效 interface ChatRequest { user_message: string; metadata: any; // 这里any允许任意字段，包括system_prompt }

开发时，工程师随手往metadata里加system_prompt字段，TS编译器不报错，但运行时它就出现在请求体里。更糟的是，any类型还会污染下游，导致日志中间件无法识别该字段进行脱敏。

强制规范：

• 禁用any，改用Record<string, unknown>或精确接口；
• 在ESLint中启用@typescript-eslint/no-explicit-any规则，并设为error；
• 对所有metadata字段，必须提供白名单枚举：

type MetadataKey = 'trace_id' | 'user_id' | 'session_id'; interface ChatRequest { user_message: string; metadata: Record<MetadataKey, string>; }

4.5 教训五：第三方SDK的“便利性”陷阱——它们可能偷偷记录一切

最让人崩溃的泄漏来自第三方SDK。某客户集成了一款“AI对话分析”SDK，文档写着“自动识别用户意图”。上线后，安全审计发现该SDK的trackEvent方法会把整个请求体（包括system prompt）发送到其SaaS平台。而SDK的初始化代码是：

// SDK初始化，看似无害 Analytics.init({ apiKey: 'xxx', autoTrack: true // ⚠️ 这个true开启了全量采集！ });

autoTrack: true默认捕获所有网络请求，且SDK源码混淆，无法审计。我们花了三天反编译才定位到泄漏点。

防御策略：

• 所有第三方SDK必须签署《数据处理协议》（DPA），明确禁止收集system prompt等指令类数据；
• 在CI/CD中加入npm audit --audit-level high，扫描SDK依赖树中的高危包；
• 用Webpack的externals配置，将SDK从主包中剥离，用<script>标签异步加载，并通过sandboxiframe隔离其执行环境。

5. 工具链与检查清单：一套开箱即用的system prompt治理套件

光有方案不够，得有趁手的工具。我把日常使用的system_prompts_leaks防护工具链整理成可直接部署的套件，包含检测、防护、审计三类工具，全部开源且已在生产环境验证。

5.1 检测工具：PromptLeakScanner——三分钟定位泄漏点

这是一个轻量级CLI工具，支持一键扫描项目中的潜在泄漏点：

# 安装 pip install prompt-leak-scanner # 扫描前端代码（检测硬编码） prompt-leak-scan --target ./src --type frontend # 扫描日志配置（检测敏感字段记录） prompt-leak-scan --target ./config/logging.yaml --type log-config # 扫描Docker环境变量（检测明文注入） prompt-leak-scan --target ./Dockerfile --type docker

扫描结果示例：

[FRONTEND] ./src/utils/ai.ts:42 Found hardcoded system prompt: "你是一名持牌理财顾问..." ✅ Suggestion: Move to BFF layer and use scene-based routing [LOG-CONFIG] ./config/logging.yaml:15 Detected 'system_prompt' in log format string ✅ Suggestion: Replace with '%(redacted_system_prompt)s' and implement filter [DOCKER] ./Dockerfile:22 Environment variable SYSTEM_PROMPT found in ENV instruction ✅ Suggestion: Use AWS Secrets Manager or HashiCorp Vault instead

工具原理：

• 前端扫描基于AST解析，避免正则误报（如匹配注释中的system_prompt）；
• 日志配置扫描支持YAML/JSON/TOML多种格式，自动识别占位符语法；
• Docker扫描解析Dockerfile AST，精准定位ENV、ARG指令。

5.2 防护工具：SafePromptMiddleware——一行代码接入的脱敏中间件

为降低接入成本，我们封装了适配主流框架的脱敏中间件：

# FastAPI接入（一行代码） from safe_prompt_middleware import SafePromptMiddleware app = FastAPI() app.add_middleware(SafePromptMiddleware) # 自动过滤所有响应体中的system prompt字段 # Django接入（settings.py） MIDDLEWARE = [ # ... 'safe_prompt_middleware.DjangoSafePromptMiddleware', ]

中间件特性：

• 支持自定义字段名列表（["system_prompt", "sys_instruction", "role_rules"]）；
• 可配置脱敏策略：REDACTED（替换为"[REDACTED]"）、HASHED（SHA256哈希）、EMPTY（置空）；
• 内置性能监控，记录每次脱敏耗时，避免成为性能瓶颈。

5.3 审计工具：PromptAuditReport——生成合规性报告的自动化引擎

满足等保2.0、GDPR等合规要求，需要可验证的审计证据。PromptAuditReport可生成PDF格式的合规报告：

# 生成报告（自动收集所有防护措施状态） prompt-audit-report \ --config ./audit-config.yaml \ --output ./reports/prompt-audit-2024-q3.pdf # audit-config.yaml示例 --- bff_layer: true # BFF是否启用 log_redaction: true # 日志脱敏是否启用 error_sanitization: true # 错误响应净化是否启用 kms_encryption: true # KMS加密是否启用 ci_cd_gates: true # CI/CD卡点是否启用

报告内容包括：

• 防护措施落地状态（✅/❌）；
• 每项措施的配置截图和代码片段；
• 最近一次红队演练结果摘要；
• 未覆盖风险点及整改时限。

5.4 终极检查清单：上线前必须完成的12项验证

最后，这份检查清单是我给所有AI产品上线前的“临门一脚”，必须逐项打钩：

这个清单的价值在于：它把抽象的安全要求，转化成了可执行、可验证、可追责的具体动作。每次上线前，我们围坐一圈，逐项过一遍，12个✅才能按发布按钮。不是形式主义，而是把system_prompts_leaks从“可能的风险”变成“确定的已控项”。

我在实际操作中发现，最有效的防护不是最复杂的技术，而是最朴素的纪律：让system prompt永远待在它该待的地方——服务端内存里，且只在模型推理那一刻短暂存在。其他所有地方，都不该有它的影子。这个原则听起来简单，但执行起来需要整个团队的认知对齐。当你在Code Review中看到同事提交了带system_prompt的前端代码，不要只写“请修改”，而是分享这篇文档的链接，告诉他：“这不是bug，是我们共同守护的边界。”