提示词要当代码保存 — 以及它不是安全边界
这一章讲一对相反相成的结论: prompt 要像源码一样对待(保存、版本化、审计); prompt 又绝不能当安全边界用(它没有执行力)。中间还夹着一件事: 当 prompt 开始像代码一样被保存、共享、复用,它就继承了代码供应链的全部风险。 读完你能回答:出了安全事故,你拿什么还原「当时到底给模型看了什么」?
1. 这一章讲什么
前一章的结论是「控制装在模型外的程序层」。这一章处理一个随之而来的实务问题: 那 prompt 算什么?它写着意图和约束,看起来很像配置、很像代码—— 原书这一节给出两个结论,方向相反、缺一不可:
- prompt 要当代码保存:它是系统行为的第一手解释;
- prompt 不是安全边界:它是引导,不是执行。
2. 顶层全景
同一个 prompt,两种身份:
┌─ 当「源码」看 ─────────────┐ ┌─ 当「攻击面」看 ────────────┐
│ 意图:想让它干什么 │ │ 它是文本,会被注入 │
│ 约束:不许干什么(引导) │ │ 它会被共享 → 供应链环节 │
│ 控制流:先做什么后做什么 │ │ 它会被复用 → 错误跟着传播 │
│ → 要版本化、归档、可回溯 │ │ → 要扫描、要审查、要最小化 │
└──────────────────────────┘ └──────────────────────────┘
↘ ↙
唯独不能当「安全边界」:
文本管不住文本之外的世界
图说:三种身份三套对策,混用任何两种都会出事。
3. 核心原理
3.1 prompt 就是源码:为什么这个类比成立
书里的论证很直接:prompt 之于 LLM,功能上相当于源码之于可执行程序—— 你能在 prompt 里读到意图、预期约束和控制流**(先做什么、后做什么的顺序安排),而不必只盯着输出反推行为**1。 传统程序出 bug,你打开代码看逻辑;AI 系统行为怪异,你打开 prompt 看「它被告知了什么」。
书里又给了第二个类比:infrastructure-as-code(基础设施即代码——把服务器的 配置写成代码文件管理,而不是手工在界面上点):prompt 存下来、反复打磨, 就成了对系统行为的半可复现、可检视的描述;版本、追踪、迭代(一轮一轮地改进)这三件事 对调试至关重要,而且详细的完整指令产出,一贯好过一句话的随手 prompt1。
一句话:随手聊天的 prompt 是消耗品,作为工程资产的 prompt 是源代码。 书里的原话甚至更重:把它们当随手聊天记录,是「日后调试与事件响应时 会回来咬你的错」(原书小结处,第 12 章引用)。
3.2 具体怎么存:书里的两个实例
实例一,工具的原生行为。Claude Code(Claude 的编程 agent)在
.claude/history.jsonl 文件里原生保存你的 prompt 历史——
每条记录关联项目、会话 ID、时间戳(精确到秒的记录时刻),量相当可观2。
实例二,书里给了一条可以直接抄的 prompt 模板:要求模型每次收工时,
把本次工作写成 git commit -m 的提交说明,并把你的原始 prompt 连同对应输出、
按当前会话 ID 存进提交记录3。效果是:每一版代码旁边,永久挂着
「这一版是被哪句话驱动出来的」。
3.3 主走查:一场事故的回溯,全靠这份存档
三个月后,安全审计发现:某个 AI 参与的服务,把内部调试接口(系统对外开口的服务端点)暴露在了公网。 组织要回答:这个缺陷是哪里来的——prompt 写错了?模型生成的?还是人改坏的? (场景为演示所编;机制照书:16 章将要求「能回溯缺陷源于 prompt、生成物还是人工修改」, 本章先演示回溯的抓手长什么样。)
抓手一:git 提交记录(3.2 节实例二的产物)
commit 8f3c2e1 的说明里挂着:
prompt: "给 /debug 接口加个开关,方便线上排查问题"
session: a91f... 时间: 2026-05-12 14:22
→ 一眼看到:原 prompt 只说了「加开关」,没说「仅内网可用」。
约束缺失发生在 prompt 层。
抓手二:.claude/history.jsonl(3.2 节实例一)
按 session a91f... 检索,找到完整对话:
14:22 用户原话 → 14:23 模型生成的路由代码 → 14:31 人工小改(变量重命名)
→ 三段各自可辨:模型生成的代码就没带访问控制;人工修改没加也没有删。
缺陷主因:prompt 没写约束;次因:生成代码未经安全评审(09 章的课题)。
如果这两份存档不存在:
代码在库里,prompt 早已随聊天窗口消失;
「谁在什么意图下写的这段」永久不可考——复盘变成考古。
走查的价值在对照:同样的故事,第 05 章是「监控+日志让你还原事故经过」, 这一章是「prompt 存档让你还原意图」。事故响应要回答的不止「发生了什么」, 还有「为什么会被造成这样」。
3.4 存起来、共享起来之后:prompt 成了供应链
一旦 prompt 开始被保存、复用、共享(团队共享的 prompt 库、社区流传的 「神级 prompt」),它就站上了代码供应链的位置——而 prompt 会被解释, 解释可能导致代码执行,所以它和代码一样怕注入、怕操纵4。
书里点了一个正在发生的形态:可复用的 prompt 库正在演化成可共享的 skill(技能包:给 agent 的成套指令,常附带脚本)。作者的主张:skill 必须像 软件供应链的其他环节一样被审视——上静态扫描(不运行代码、只分析文本的自动检查), 找密钥、找后门、找漏洞、找错误配置,还要扫 prompt 里常见的注入关键词, 免得供应链随时间被慢慢污染5。
书里还点了两个已经存在的扫描工具:skill-scanner 与 razin,并预测这类功能 会逐步并进主流安全产品5。
这个趋势我们有自己书架上的印证(补充,不在书里,依据我们的 protocol 书架):
Agent Skills 规范里,skill 的 scripts/ 目录放的就是 agent 会直接执行的
脚本代码——「skill = 文本」是错觉,它从来都是「文本 + 可执行代码」的合体。
依据: shelf=ai-protocol-reference/agent-skills-spec#01-spec-format.md @69ef37e9424c0a7ea9dd2293b559e43ec8176379 事实=规范规定 skill 目录下 scripts/ 为可执行代码(Python/Bash/JS),agent 按正文指示直接运行。
扫描这件事也有现成形态(补充,不在书里,依据我们的 agent 书架):LlamaFirewall—— 一个开源(源码公开、谁都能查)的注入扫描框架。
其中的 PromptGuard 扫描器,用一个 86M 参数的小分类器(只回答「像不像攻击」的 小模型)在本地给文本打分。
它判断的是不是提示注入(02 章走查的那种攻击的行业叫法)——「扫 prompt」 已经是可落地的工程件,不是设想。 依据: shelf=ai-agent-reference/llamafirewall#02-scanners.md @4be64c3a24442b51c76175e6ec67722cc3f5fe38 事实=PromptGuard 用 Llama-Prompt-Guard-2-86M 本地分类器给文本打注入概率分,命中即 BLOCK。
3.5 反方向的铁律:prompt 不是安全边界
现在是本章的另一 半,书里加粗强调过的话:prompt 不是安全边界, 不应被当作权限的决策者6。
推理链是:prompt 是程序执行的引导机制;它可以描述意图与约束, 但保证不了被遵守——原因上一章讲过了,模型对文本的服从是概率性的。 书里给这个错误起了个名字:「靠 prompt 条件做安全」(security through prompt conditions),并把它类比到安全领域的老概念 security through obscurity (靠隐匿求安全:把机制藏起来当防御——藏得住一时,藏不住攻击者的一次探索)6。
配套的口诀值得背下来:「security through text, fails under stress」 ——文本撑不住压力。顺境里 prompt 约束看着都挺管用;在注入、诱导、上下文 超载的压力下,文本约束第一个碎6。
真正的控制在哪?书里数了家底:程序化检查、文件系统权限、网络控制、 限定范围的 API 授权——由系统在 prompt 之外强制执行的东西,才最终决定 这个程序「超出 prompt 意图之外」还能干什么6。
4. 作者的判断与证据
- 可操作的实证:
.claude/history.jsonl的存在、Claude Code 对新仓库的警告 (打开陌生仓库会提示——因为跑不可信 prompt 和跑不可信代码一样危险)7, 都是当下产品的真实行为,读者可自查; - 作者的判断:「prompt 库 → skill → 必须当供应链审」是趋势判断;扫描工具 只点名两个,没给评测数据5;
- 作者强调的原则:「prompt 不是安全边界」在书里重复了两次以示强调6。
5. 边界与局限
- 「prompt 是源码」的类比有个边界:源码是精确的,prompt 是模糊的—— 同一份 prompt 配上不同的上下文,行为可以不同(上一章)。类比在 「可检视、可版本化」这层成立,在「行为可由文本唯一决定」这层不成立;
- skill 扫描器的具体能力(误报率、能扫出哪几类注入)书里没讲;
- 书里没有讨论 prompt 的合规面(里面若含个人数据,存档本身就是数据留存问题);
- 「注入关键词扫描」是黑名单思路,可绕过性天然存在,只能 当纵深防御的一层, 别当唯一防线——这是我们的补充判断。
6. 可带走的
- prompt 当源码:保存、版本化、与产出绑定;随手聊天是消耗品,工程资产要归档;
- 事件响应的黄金问题「缺陷源于 prompt、生成物还是人工修改」,答案全在存档里;
- 工具现成:
.claude/history.jsonl在记;把 prompt 挂进 git 提交说明是低成本高回报的习惯; - prompt 库与 skill 是供应链:审它、扫它(密钥/后门/注入关键词),像审依赖一样;
- skill 不是纯文本——常带可执行脚本,审 skill 至少要按审代码的标准来;
- 永远记住:prompt 不是安全边界;权限与硬约束必须由程序层执行;
- 「靠 prompt 条件做安全」= 「靠隐匿求安全」;口诀:文本撑不住压力;
- 详细完整的 prompt 本来就比一句话 prompt 产出好——存档与效果,一箭双雕。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| prompt=源码、infrastructure-as-code、版本迭代 | The Importance of Saving our Prompts | text/14-fm-the-importance-of-saving-our-prompts.txt:3(搜「source code」) |
| .claude/history.jsonl 原生存档 | The Importance of Saving our Prompts | text/14-fm-the-importance-of-saving-our-prompts.txt:5(搜「history.jsonl 」) |
| git commit 挂 prompt 的模板 | The Importance of Saving our Prompts | text/14-fm-the-importance-of-saving-our-prompts.txt:7(搜「git commit -m」) |
| 共享 prompt=攻击面、不可信 prompt=不可信代码 | The Importance of Saving our Prompts | text/14-fm-the-importance-of-saving-our-prompts.txt:9(搜「untrusted code」) |
| skill 供应链、静态扫描、skill-scanner/razin | The Importance of Saving our Prompts | text/14-fm-the-importance-of-saving-our-prompts.txt:11(搜「skill-scanner」) |
| prompt 不是安全边界、隐匿类比、真控制在哪 | The Importance of Saving our Prompts | text/14-fm-the-importance-of-saving-our-prompts.txt:13(搜「security through obscurity」) |