Prompt、Context 与 Spec 分别解决什么

一句话收获：Prompt 启动生成，Context 组织环境，Spec 稳定语义；三者都不自动保证正确。

这个场景在解决什么问题

这个场景要把三个经常被混着用的词掰开：Prompt、Context、Spec。原文的做法是拿同一个任务，依次加入提示、完整环境、稳定任务基线，看它们各自解决了什么问题。它值得单独学，是因为很多人以为"把 Prompt 写长一点"就同时解决了环境、规则、验收所有问题，而实际上三者的分工和边界完全不同。

先理清这条判断链（文字版）

这个场景是一条"递进 + 分层"的链：先用 Prompt 让模型开始干活，再用 Context 给它一个完整环境，然后用 Spec 把语义外化成一个可版本化的基线，最后明确真正的硬约束只能靠模型外的机制。验收标准是——能不能说清"哪一层解决什么问题、哪一层不保证什么"。

先看 Prompt 怎么让生成启动（解决"从哪开始"）。
再看 Context 怎么组织完整环境（解决"当前能看到什么"）。
接着看 Spec 怎么把语义外化成可版本化基线（解决"怎么回到同一语义比较"）。
最后明确硬约束只能靠模型外的权限、状态机、Schema 等机制。

逐层详解

第 1 步：Prompt 启动生成

原文：当前目标和要求进入模型，影响这一次输出。

白话：Prompt（提示，你发给模型的文字指令）把"这次要干什么、有什么要求"喂给模型，影响的是这一次的输出。

类比：像你跟同事说"帮我把这份表格按金额排个序"——这句话启动了这一次的具体动作，但不规定公司规章制度。

举例：你给 Agent 发一句"帮我把这个月的销售数据汇总成周报"，模型开始生成周报，这是 Prompt 在起作用。

为什么重要：Prompt 解决从哪里开始——它回答的是"这一轮从哪起步"，而不是"整个系统靠什么维持正确"。

怎么验证（证据点）：

目标出现
输出开始
行为受影响

别踩的坑（边界）：自然语言强语气不能形成程序强制——你在 Prompt 里写"绝对不许删库"、加十个感叹号，都只是影响模型倾向，不是程序级强制。

落地检查：Prompt 的效力是影响概率——落地时把 Prompt 理解成"调整输出概率分布"，而不是"写入一条会被严格执行的规则"。

第 2 步：Context 组织环境

原文：规则、材料、状态、知识、工具和历史共同进入工作包。

白话：Context（上下文）是把规则、材料、状态、知识、工具、历史这些全部组装起来，形成一个完整的工作环境。

类比：像一场会议，Prompt 是"今天开会的议题"，Context 是会议室里摆好的全部资料、白板、到会人员名单和当前进度——议题只起个头，真正决定讨论质量的是这一屋子东西。

举例：同样是"汇总销售周报"这个 Prompt，如果 Context 里装进了正确的销售数据表、周报模板、只读查询工具，模型才能真的把周报做对；少了这些，Prompt 再清晰也没用。

为什么重要：模型行为取决于完整环境，不只取决于一句提示——模型最终表现由整个 Context 决定，不是由那句话说得多漂亮决定。

怎么验证（证据点）：

信息来源完整
状态当前
工具可见

别踩的坑（边界）：信息可见不保证被正确使用——材料都在 Context 里，不等于模型会正确挑出来用。

落地检查：Context 解决当前能看到什么——落地时把 Context 当作"视野管理"：它决定模型能看到什么，不保证它看得对。

第 3 步：Spec 外化语义

原文：目标、事实、范围、异常、停止和验收进入可版本化基线。

白话：Spec（规格说明，把任务语义写成结构化、可版本化的基线）把目标、事实、范围、异常情况、停止条件、验收标准这些东西，固化成一个能追踪版本、能比较变更的基线。

类比：像一份盖了章的"项目需求书"，每次改需求都有版本记录，你可以回看"上一版到底承诺了什么、这一版改了什么"。

举例：一个数据清洗 Agent，Spec 里写清"目标=去重、范围=只处理 2024 年后的订单表、异常=遇到缺失字段标记而非跳过、停止=遇到金额为负立即停止、验收=清洗后无重复主键"。这套东西存成一个版本，多轮工作都能回到同一份语义来对照。

为什么重要：Spec 让多轮工作可以回到同一语义比较——因为语义被外化成固定文本，才能跨轮次、跨人来对齐"到底要做什么"。

怎么验证（证据点）：

基线可加载
变更可比较
验收可定位

别踩的坑（边界）：结构化 Spec 仍然是提示和基线——Spec 写得再结构化，本质上还是"提示 + 基线"，它不是程序约束，不能指望它自己拦住非法操作。

落地检查：Spec 的直接价值是可追踪——落地时把 Spec 当作"可追踪的基线"，用它的版本号和 diff 来定位"哪里变了、验收在哪条没通过"。

第 4 步：模型外约束

原文：权限、状态机、Schema、工具白名单、测试和外部验收负责强制边界。

白话：真正能强制边界的，是模型之外的东西——权限系统、状态机、Schema（数据结构/字段约束）、工具白名单、自动化测试、外部验收，这些不靠模型"听话"，靠程序硬拦。

类比：像银行柜台，柜员（模型）可以提出任何操作建议，但真正决定"这笔转账能不能过"的是后台的风控系统和权限系统，不是柜员的口头承诺。

举例：数据清洗 Agent 就算在 Prompt 里被诱导去删生产库，只要它的工具白名单里没有"删除生产库"这个工具、权限系统也拒绝，这一步就执行不了。

为什么重要：只有模型外机制能阻断不合法候选——因为模型永远可能生成不合法的候选，唯一可靠的是在执行那一层把它拦下。

怎么验证（证据点）：

权限拒绝
状态拒绝
验收独立

别踩的坑（边界）：更多 Prompt 补丁不能替代执行层边界——往 Prompt 里加"禁止""切记"的补丁，永远替代不了执行层的那道硬闸门。

落地检查：提示与约束必须分层——落地时明确分层：提示层负责"引导和减害"，执行层（权限/状态机/白名单/测试）负责"硬约束"，两者都要有，不能只靠提示。

落地可行性小结

本场景涉及的技术栈：Prompt 工程、Context 组装、Spec 作为版本化基线（配合 git 之类做版本管理）、以及模型外约束（权限、状态机、Schema 校验、工具白名单、测试、外部验收）。真实落地做法：把 Prompt 当"启动器"、Context 当"环境装配器"、Spec 存成受版本管理的文件、把权限和状态机放在执行层独立实现。要检查的：Spec 是否有版本号和 diff、工具白名单是否在执行层生效、测试和外部验收是否独立于模型输出。常见坑：指望更长的 Prompt 当安全边界、把 Spec 当程序约束、Context 装满了却没人管它到底对不对。

回顾

Prompt 解决"从哪开始"，只影响输出概率，不构成程序强制。
Context 解决"当前能看到什么"，决定视野，不保证用对。
Spec 解决"语义可追踪"，是版本化基线，但仍是提示而非硬约束。
真正的硬边界靠模型外的权限、状态机、Schema、工具白名单、测试和验收。
提示与约束必须分层，谁也不能替代谁。