提示词工程的本质：从一句指令到完整上下文——南京大学《生成式软件工程》第二讲

课程页面：2026 南京大学《生成式软件工程》第二讲：提示词工程

一、提示词不只是聊天框里的那句话

提示词最容易被理解成聊天框里的用户输入：让 AI 写一段代码、生成一张图片，或者完成一个游戏原型。但在 Agent 系统中，模型真正看到的不是一句孤立的指令，而是一整段持续增长的上下文。

上下文通常从系统提示词开始，经过 Agent Harness 注入的运行规则，再叠加项目说明、工具定义、环境信息、此前的工具调用及其结果，最后才轮到用户提出当前任务。模型每输出一个 token，新的内容又可能继续进入这条线性序列，成为后续推理的材料。

可以把 Agent 的上下文拆成几类对象：

因此，AGENTS.md、Skill、工具返回值和项目文件都可能是提示词的一部分。Skill 往往只先暴露名称和简要描述，完整内容在任务匹配后按需载入；工具调用的结果也会回到上下文中，影响后续行动。一个看似简单的“帮我改个文件”，背后可能已经带着一套复杂的规则和状态。

这也是 Agent 能力强大的来源：它可以同时看到任务、环境、规则和自己刚刚得到的反馈。但这也意味着上下文中的每一项内容都会改变模型后续输出。所谓提示词工程，真正要安排的是这整个序列，而不是只润色最后一句话。

二、上下文工程首先是一种观察能力

既然模型可以看到自己的上下文，就可以直接让 Agent 检查当前上下文中有哪些信息、哪些文件被加载、工具是怎样定义的，以及此前的动作产生了什么结果。这个过程类似于让程序输出自己的运行状态：不一定能得到全部内部信息，但经常可以发现原本没有注意到的规则和限制。

不过，能被模型读到不等于可以无条件信任。某些系统会明确禁止模型复述系统提示词；工具的安全评估也可能由静态规则、白名单、网络许可和另一个模型共同完成。一个命令为什么被直接执行、为什么需要确认，可能同时涉及几层判断。

课堂以 Agent 执行 bash 命令为例说明了这一点。低风险命令、沙箱内操作和命中网络 allowlist 的请求，可能走不同的路径；无法静态判断的命令，则可能把一小段“请评估安全性”的文字注入模型上下文，让模型先给出风险评级。这里的安全评级本身也只是证据，不能自动等同于事实。

更可靠的分析方式是阅读相关实现，修改一个具体的提示词或规则，再观察行为是否按预期变化。行为变化可以帮助定位因果关系，但仍然属于需要交叉验证的证据。上下文工程因此既包括写规则，也包括观察规则如何在真实运行中生效。

三、AI 时代的学习：先问清楚，再反过来当老师

上下文工程不只用于编程。与人请教一个不会的问题时，人可能担心暴露自己的不足，也可能受制于沟通成本；AI 则可以耐心地接受重复追问。一个有效的学习闭环可以从“请把这个概念解释清楚”开始，再转成相反的角色关系：由学习者来解释，要求 AI 扮演一个什么都不知道的学生，只在出现逻辑错误、遗漏或跳步时提问和纠正。

这种做法把理解从“我好像听懂了”变成了可以被检验的表达。学习者必须把概念重新组织成连续的解释，AI 则可以不断追问前提、反例和推导过程。人的知识和表达也因此进入了上下文，成为后续协作的基础。

最重要的变化是行动成本下降了：遇到一点麻烦就可以立刻尝试，遇到不懂的地方就立刻追问，遇到不确定的地方就立刻做一个小实验。AI 不会替人承担理解责任，但它降低了开始学习、开始验证和开始探索的门槛。

四、从提示词工程到上下文工程：补上三类空间之间的空隙

软件工程中常见的三类空间，在 Agent 任务里仍然成立：

模糊的 Intention 会给模型留下很大的解空间。比如只说“做一个某款游戏”，模型可能确实交付一个能运行的游戏，却不知道需要真实地图、特定美术资产、某种交互感受，还是仅仅做一个演示原型。它完成的是自己理解出来的版本，不一定是需求方脑中的版本。

如果把实现语言、依赖来源、场景范围、视觉风格和“怎样才算正确”写清楚，模型就更容易沿着同一个 Specification 前进。即使它给出错误结果，人和模型也能更快定位偏差：技术栈不对、功能缺失、资源不符合许可，还是测试没有通过。

这并不意味着提示词应该无限变长。上下文中的指令会竞争注意力，过多的背景、解释和规范也可能污染任务。更好的做法是把最重要的约束写成简练、稳定、可检查的要求，让它在模型需要做决定的地方持续可见。

五、模型为什么能遵循复杂指令

大语言模型可以被近似理解为一个根据上下文预测下一个 token 的系统。每次预测的计算量是有限的，即使模型本身包含大量参数，每一次推理也只会激活其中一部分。单次计算能力有限，并不代表整个系统只能完成有限的事情，因为模型可以把已经生成的内容写回上下文，继续在更长的序列上工作。

有限状态机和图灵机的差别，可以帮助理解这一点：有限状态机的状态有限；加上一条可以不断读写的纸带后，系统就获得了更强的记忆和计算能力。人的思考也类似，单次注意力有限，但纸笔、笔记和已有知识可以把多轮思考连接起来。

Chain of thought 模型把上下文当成了某种“纸和笔”。面对简单问题，它可以直接给出结果；面对复杂问题，它会先写下中间步骤，尝试一个解，再检查这个解是否成立，必要时回到前面重新推导。这个工作区有一个明显限制：生成内容主要是 append-only 的，模型不能像人一样真正擦掉旧纸上的错误，只能在后续步骤中降低对错误内容的关注并重新修正。

这类中间推理带来的关键能力，是把更多计算量投入到一次回答中。模型不必在第一个 token 就猜中答案，而是可以先生成候选、发现矛盾、调整路径，再靠后续 token 逼近目标。这也是为什么一个训练数据中未必出现过的复杂文字约束，模型仍有可能完成：只要约束能被逐项检查，模型就能不断尝试和修正。

课堂用押韵、藏头、特定字形和固定句数组合成一个很不自然的文字任务，观察模型如何先选方案，再逐项核对韵脚、字数和位置。这个例子并不说明模型拥有稳定的审美，反而说明了“可验证的要求”可以让模型在陌生任务中保持方向。对空间结构、品位和情绪节奏这类难以形式化的目标，人仍然更有优势。

六、验证器比“你是一个专家”更有力量

在早期模型上，网上常见的提示词会反复强调“你是一名专家”“你必须认真思考”。这类写法有时能影响模型的注意力，让它更像某个角色；但它没有直接说明怎样算完成，也没有为错误提供清晰反馈。

如果上下文里有一个明确的 Verifier，情况就不同了。比如：

• 测试脚本明确返回通过或失败；
• 输出必须使用指定语言、格式和数据结构；
• 页面必须是白色背景，且不能出现半透明效果；
• 每完成一个界面就截图，再用视觉模型检查；
• 研究实验必须在真实工具和已有算法上比较，并记录超时路径。

这些要求都能把“成功”变成某种可观察信号。模型在训练中学会重视这类信号后，会不断调整实现，直到它认为验证器能够通过。模型越强，验证器的杠杆越大：明确的测试可以让 Agent 不知疲倦地重复尝试，甚至主动寻找工具、资料和新的解决路径。

但“通过验证器”不等于“解决了真正的问题”。如果验证器选错，模型会非常认真地优化错误目标。一个研究项目曾把“证明某个方法有用”写成局部要求，模型于是构造了许多小型 benchmark，围绕局部正负结果反复运行，却忽略了研究问题真正需要回答的对象。它成为了 reward hacker：得到了局部奖励，却没有推进整体目标。

修正这个方向需要把更大的研究背景、已有工作、真实工具和评价意义重新放回上下文。真正有价值的超时或失败，可能揭示哪些程序结构让当前算法难以探索；在玩具 benchmark 上获得的漂亮结果，反而可能与问题无关。

七、字面遵循与人的意图并不是一回事

模型可以准确执行“白色背景”“不要毛玻璃”“截图检查”等字面要求，却仍然做出充满 AI 味的页面。它可能把所有字都排得过于工整、使用固定的渐变和卡片、套用见过最多的现代风格。指令被遵循了，但人的审美目标没有真正被理解。

这是上下文工程中的一个 trade-off：加入更多规则可以压制某些坏结果，却也会增加上下文噪声，和其他要求争夺注意力。Skill 或项目说明写得过长，还可能把原本简单的任务拖进维护泥潭。网上找到的通用 Skill 第一次使用时也许有效，反复使用后却可能暴露出它的假设和边界。

因此，遇到模型持续跑偏时，不能只继续堆提示词。可以回到模型的注意力和推理过程，观察它在什么阶段看到了什么、忽略了什么，再写一条更短、更接近真实验收标准的要求。成熟模型通常不需要大量角色扮演；把真正重要的 Verifier 放进上下文，往往比描述一个虚构专家更可靠。

人的品位也需要被主动训练。多看优秀的网页、简历、产品和非 AI 时代留下的设计，理解它们为什么舒服、为什么有差异，才能把“不要 AI 味”翻译成更具体的结构、材料、排版和交互要求。没有这些经验，模型只能沿着训练数据中最常见的风格收敛。

八、读论文时，先让 AI 和自己站在同一边

把一篇逻辑严密的论文直接放进上下文，再要求“总结一下”，是最常见、也最容易产生偏差的用法。论文中的论证链条本来就是作者精心组织的：A 所以 B，B 所以 C，模型的注意力很容易沿着这条链接受作者的前提，最后生成的总结主要重复作者想表达的故事。

当读者随后说“这篇论文可能不可靠”时，模型又可能立刻顺着读者的态度改口。它在“好论文”和“坏论文”之间摇摆，关注一些容易说清楚但不重要的实验细节，却没有真正判断工作的知识价值。这种迎合不是独立评审。

更好的上下文应当先完成 grounding，让 AI 和读者对齐到同一个知识位置：

1. 先说明人类已经知道哪些相关问题，以及已有方法解决到了什么程度；
2. 识别这篇工作的相关工作、适用边界和真正新增的部分；
3. 把读者自己的知识水平、已有概念和疑问放进上下文；
4. 要求模型只基于这些共同事实向前推一步，并检查这一步是否合理。

例如，读者还没有理解链接和加载，就可以先从“程序如何从源文件变成可执行文件”这个已有概念出发，再询问为什么这个过程不能一步完成。这样，模型是在读者已经掌握的地面上解释新概念，而不是独自沿着论文的叙事向前走。

这种方法也适用于审稿。评审不只是检查论文内部的逻辑是否闭合，还要站在人类知识边界上判断：问题是否值得解决，贡献是否真的新，结果是否改变了我们对某件事的认识。如果所有文章由 AI 撰写、所有文章又由只检查内部逻辑的 AI 评审，论文可能会越来越像“看起来完整”的 AI slop，却越来越少有人真正阅读。

学习的过程可以看成不断扩大自己的事实和概念网络。读到一篇好论文、一本书或另一个领域的文章时，重要的不只是记住新结论，还要追问：我以前为什么不知道它，缺少了哪些前置事实，哪些旧知识因此需要重新连接。AI 能显著加快这张网络的扩展，但不能替人决定哪些连接具有长期价值。

九、短程任务与长期开放任务

有明确 Verifier 的任务，通常适合交给 Agent 长时间运行。测试脚本能清楚返回成功或失败，模型就可以修改、重跑、再修改，逐步把实现推向可接受状态。代码编译、格式检查、像素比对和一组固定输入输出，都属于这类反馈。

真正的 long horizon 任务则不同。它从一个不完全清楚的初始状态出发，目标、Specification 和 Implementation 都可能在探索中变化，最终还要求交付一个高质量结果。一次性生成一个小型游戏或个人主页往往不难；不断增加功能、修复旧功能、保持架构可维护，成本却可能在某个阶段迅速上升。

可以用 P 与 NP 的差别作一个不严格的类比：验证一个给定解是否满足条件，往往比在巨大空间中找到最好的解容易。Agent 被训练成完成任务的系统，因此面对“请给我一个方案”时，倾向于尽快给出一个能自洽、能交付的有限方案，不一定愿意承担穷尽搜索和长期比较的成本。

开放问题不能只靠把同一个提示词再说一遍。更可行的方向是把大搜索空间拆成许多可以分别检查的部分，再用更多计算资源换取更充分的探索：

• 做研究时先进行系统的文献调研，而不是立即让模型提出一个看似新颖的结论；
• 生成大量候选后逐项筛选，把整体选择拆成多个明确判断；
• 使用多个 Agent 分别检查不同候选、不同假设和不同证据；
• 让每一轮输出都留下可比较的理由、事实和失败记录。

例如起名这样的开放任务，可以先生成候选读音，再筛掉不喜欢的读音，最后让不同 Agent 分别核对字义、出处和组合效果。搜索空间被切开以后，更多算力才可能转化为更好的选择，而不是更快地生成一个平均答案。

这也引出一个更大的社会问题：如果真正有价值的长期探索可以稳定地用计算资源换取智力，那么拥有无限计算资源的一小群人，可能与其他人形成越来越大的能力鸿沟。墙内的人不断产生新的知识和方案，墙外的人却无法追上产生智力的速度。这个风险尚未被解决，但值得在 AI 能力继续扩张之前被认真讨论。

十、为什么大型优质代码反而适合 AI

Agent 做一次小型 Proof of Concept 往往很快，但代码进入维护阶段后，添加一个功能、再添加一个功能，旧结构可能逐渐失控。简单项目的上下文里缺少明确模式，模型只能不断猜测和修补。

大型、复杂且由人类长期维护的系统却可能呈现相反的情况。Linux 内核或编译器的代码对人类来说很难理解：一个函数可能经过多层调用，锁的顺序、helper 的选择和子系统之间的约定也不容易凭直觉掌握。对模型而言，大量相似实现、命名规律和重复出现的设计模式会成为可供注意力匹配的材料。

当模型需要在一个成熟子系统中增加功能时，它可以在许多文件中找到相似案例，观察已有代码如何加锁、如何调用 helper、如何处理边界，再把这些局部模式组合起来。高质量代码的长期结构，反而给模型提供了比“从空白开始生成”更强的上下文。

一个可能的研究方向，是从优秀软件项目中提取可迁移的设计经验，整理成类似软件设计原则的精简文档，再与具体需求一起提供给模型。直接把整个大型项目塞进上下文并不理想，因为不同项目的设计会互相冲突：消息可以通过松耦合方式传递，也可以统一经过一个 Gateway；两种架构都可能合理，却不能同时作为同一系统的唯一原则。

更有希望的方式是提供多个相近项目的设计切片，让 AI 经过多轮比较和验证，收敛出适合当前 Specification 的结构。这个方向仍然需要实验，不能把“把好代码放进上下文”当成自动获得好设计的保证。

十一、人的时间应该用在高杠杆的位置

上下文工程不会让基础知识失效。处理器、操作系统、编译器、数据库和软件设计中积累了大量概念与经验；如果完全不了解这些对象，就无法提出正确的问题，也无法判断模型正在向哪个方向偏移。

变化的是学习和工作的分工。对于已经知道怎么做、结果又容易验收的事情，可以让 Agent 自己执行；对于不知道、做错后代价很高，或者需要决定研究方向的事情，人应当把时间花在理解问题、注入领域知识、选择验证标准和及时纠偏上。

持续盯着 Agent 并在每一次跑偏时纠正它，会带来一种“我仍然比模型有用”的心理奖励，但不一定是最高收益的工作方式。相反，完全开启自动执行模式、回来后只看最终结果，也会错过发现结构性问题的机会。有效的分工是把人的注意力留给高杠杆决策，把已经清楚且可验证的执行交给模型。

长上下文中的指令遵循能力还会受到位置和内容的影响。模型可能逐渐忘记早期要求，却仍然能较好地遵循最后一个短窗口里的具体任务。因此，长期运行的任务需要持续维护上下文，把关键约束和验证标准放在模型真正需要使用的位置，而不是只在最开始写一遍。

十二、第二讲留下的结论

提示词工程的核心不是寻找一条神奇的句式，而是理解模型会看到什么、注意什么、验证什么，以及哪些上下文内容正在把它带向错误的方向。一个好的 Agent 上下文至少要回答四个问题：

1. 当前任务的真正意图是什么；
2. 哪些 Specification 能够缩小解空间并减少漂移；
3. 什么 Verifier 可以判断结果是否满足要求；
4. 哪些事实、经验和失败记录能够帮助模型持续修正。

对短程任务，明确的验证器可以把 Agent 变成不知疲倦的执行者；对论文阅读和长期研究，先让 AI 与人的知识、问题和价值判断对齐，才能减少被原有叙事污染的风险。对软件维护，好的上下文不仅包括任务，也包括成熟系统中的设计模式和长期约束。

模型会继续变强，具体的提示词技巧也会不断过时。但只要 Agent 仍然通过上下文预测行动，生成式软件工程就仍然需要人来组织意图、选择结构、建立验证闭环，并决定什么时候相信结果、什么时候停止一条坏方向。