生成式软件工程第二讲笔记：提示词、上下文与探索的组织方式

这篇是南京大学蒋炎岩老师《生成式软件工程》第二讲的学习笔记。视频标题是“提示词工程”，课程网站将这一讲命名为“提示词与上下文工程”。这个变化概括了课程的方向：我们需要组织模型做决定时掌握的信息，也需要安排它怎样探索、怎样检查结果。

资料说明：本文由 AI 辅助整理，归入 vibe watching，结合课堂视频音轨转录、官方讲义与 PPT 抽样画面核对，按主题重组。文末另列资料处理范围；实践清单为整理后的应用方法。

从一句要求，到模型眼前的整个环境

开场 PPT 先回顾了 prompt 这个词的来历：ChatGPT 让大众熟悉了它，但更早的 GPT-2、GPT-3 相关材料已经讨论用输入文本控制续写，以及少量示例如何影响输出。要记住的是，提示词并非聊天产品出现后才发明的一套口令，它原本就与条件生成有关。

使用聊天产品时，容易把 prompt 理解为输入框里的一句话。进入 Agent 场景以后，这个理解就不够了。

模型接受的信息可能包括运行系统提供的指令、工具说明、项目规则、任务需要的 Skill，以及用户历次补充的要求。代码、检索到的文章、文件内容和工具执行结果也会进入上下文。下一步生成什么、调用哪个工具，受到这些信息共同影响。

讲义沿用第一讲的表达 Pr[token | context]：每次生成都是在当前上下文的条件下进行的。因此，排查“为什么它没有按我的意思做”，不能只重读最后一条消息，还应检查它是否看到了所需材料、是否沿用了过时假设、是否被无关内容干扰。

PPT 用 working set 来描述理想状态：模型眼前保留一组尽量精简、足够新、来源清楚、能够验证的信息。上下文窗口变大，只说明容纳能力增强，不能据此假设注意力利用也同样可靠。组织上下文时，需要同时考虑内容、出现顺序与使用时机。

这里还需要区分要求它遵循的指令和要求它分析的材料。一篇文章可以是研究对象，却不因为进入上下文就获得指挥 Agent 的资格。信息来自哪里、适用于什么范围、应当怎样使用，本身也是上下文的一部分。

这使提示词工程的工作范围扩大了：

要组织的内容	需要回答的问题
目标	最后要产生什么结果？
约束	哪些条件必须满足？
现有材料	哪些代码、资料和实例对当前决定有用？
证据	哪些判断已经验证，哪些仍是假设？
过程记录	哪些历史信息值得保留，哪些已经失效？

课堂提到一种认识工具的办法：请 Agent 按类别说明当前任务受到哪些目标、工具规则和项目约定影响。不过，模型对自己的解释只能作为观察线索。要确认实际行为，仍需看能够访问的配置、程序和执行结果。

比如，执行命令前是否需要批准，不一定是模型独自判断的结果。外围程序可以检查权限，操作系统也会限制访问。自然语言约定和程序机制共同影响行为，不能把一条文字要求等同于已经实现的技术边界。

AI 给学习带来的变化：更容易开始，也更容易检验

课堂先把话题落到学生的日常学习：推导中不理解的一步、数字电路里看不懂的数据流、链接过程里一直含糊的概念，都可以立即变成一个具体问题。

以前，寻找解释的成本很高。一个小疑问可能被拖到期末，最终演变成一大片理解空白。Agent 可以协助构造最小例子、逐步推导或运行代码，让第一次尝试更容易发生。

但读懂一份解释和自己掌握知识仍有差别。讲义建议的学习过程可以整理为：

带着具体问题，请 AI 解释或演示。
暂时放下答案，用自己的话重述。
请它追问不清楚的地方，或者寻找反例。
回到原文、推导和程序运行结果，核对自己的解释。
修正后再讲一次。

口头讲解还强调，要先对齐学习者已经掌握的知识。如果某一章一直解释不清，可以告诉 AI 自己学过什么、能理解到哪一步，请它用这些已知概念重新组织内容。必要时保存一份学习背景，下一次就不用从零介绍自己。

这个循环的价值在于主动暴露理解缺口。答案读起来很顺，不代表自己能够在新场景里使用；复述卡住的位置，往往才是下一步应当学习的地方。

因此，AI 在这里既提供解释，也成为一个随时可以交谈的听众。它缩短了获得反馈的距离，人仍需要参与提问、解释和验证。

把“完成了”变成可以判断的状态

强指令遵循能力必须遇到足够明确的指令，才能发挥作用。

课堂举了赛车游戏和个人主页两个例子。让模型生成赛车游戏，它可能迅速交付一个可以移动、转向和碰撞的网页；用户想要的却可能是特定地图、驾驶手感、美术资产和镜头表现。让模型制作“现代风格”的主页，也可能得到任何一种带卡片、渐变和装饰的模板。

这些结果未必明显违反了字面要求。问题出在大量决定没有表达出来，模型只好连续补全。每个局部选择都有道理，组合起来却成为另一个产品。

这延续了第一讲的三个概念：

Intent：真正想实现的目标。
Spec：对行为、质量和限制的明确描述。
Impl：最后实际运行的实现。

意图转成规格时会遗漏期待，规格转成实现时又会留下选择空间。我们不可能提前写出所有细节，但需要知道哪些决定可以交给模型，哪些会直接影响成败。

判断规格是否足够明确，可以做一个简单检查：让另一个人只看要求与产物，能不能独立判断任务完成了？

“更专业”“更高级”“更好用”很难直接验收。信息出现的顺序、手机上的可读性、入口是否可用、具体交互是否存在，则可以观察。审美不必完全数字化，也可以用参考、对比和多轮反馈逐渐说清楚。

PPT 还用两个历史案例帮助理解规格的重要性：经度问题的奖励围绕可检验的误差条件设置，而轻骑兵冲锋的命令案例展示了共享现场信息不足时，文字指令如何被执行成另一种行动。这两处是课程的类比：表达目标时，要考虑执行者实际掌握的上下文，不能假设对方看到了自己眼前的一切。

失败也是一种需要定义的结果。 如果缺少关键资料，或者某项条件无法验证，合理的交付应说明缺口，而不是用肯定语气把不确定性盖过去。知道什么时候继续、什么时候报告受阻，是完成标准的一部分。

PPT 在这里连接了 Brooks《No Silver Bullet》对软件复杂性的讨论：即使实现过程变便宜，问题建模、规格、设计与确认结果是否符合目标，仍需要判断。若把衡量方式定错，AI 可能很努力地优化一个替代指标，却没有改善真正关心的产品结果。

思维链：让中间结果参与后续计算

如果语言模型逐个预测 token，为什么能完成包含很多约束的任务？讲义给出的直观解释是：单次前向计算虽然有限，已经生成的内容却可以成为后续计算的输入。

模型可以先列条件，形成一个候选，检查发现问题，再修改候选。中间文本起到了保存状态的作用。整个生成过程因此能够包含多轮尝试，而不是只靠一次计算完成全部工作。

PPT 特别提醒，不要把模型内部的 Mixture-of-Experts 想象成一组正在开会的小人；它首先是一种计算结构。可观察到的多步尝试来自连续生成、上下文更新以及工具反馈，不能仅凭“专家”这个名字就赋予它人类团队的运作方式。

这也说明更多 token 为什么可能带来更强的推理能力：它提供了继续分解、搜索和修正的机会。但机会能否变成进展，取决于中间步骤是否有效，以及错误能否被识别。

课堂用寻找答案与验证答案的难度差异来帮助理解这个过程。这里应当把它看成搜索方法的直观类比，不宜据此推出复杂性理论上的证明。

三个写作实验：形式条件与实际质量需要分开看

讲义保留了三道故意增加约束的语言任务。它们的重点在于观察模型如何同时处理多个条件。

第一道是藏头、嵌字、押韵与叙事同时存在的八句诗。 句首要按顺序拼出指定的八个字；每句还要依次包含日期文字；内容需要讲动物故事，并考虑押韵。检查时应分别竖读句首、寻找指定字、检查韵脚和理解故事。满足前两项，并不能自动保证诗句自然、韵律统一。

第二道是十八字、同偏旁、有情节的一句话。 讲义中的结果围绕洪水、油污和救人展开，用带三点水的字拼出故事。这个例子看似容易机械验证，仍藏着规格问题：要求所有字都含有同一偏旁，和要求字典将它们归入同一部首，并不是一回事。要写检查器，必须先消除这种歧义。

第三道是同音字组成的现代背景文言故事。 生成材料用 yi 音字描述翻译设备的误译与修复。它暴露的歧义是“同音”是否包括声调一致。文字可以依靠不同字形帮助理解，朗读时却可能失去大部分区分信息。

课堂还讲到把课程制作成数字化讲解片段的尝试。相比检查字数，怎样定义“讲得好”困难得多：声音是否自然、何时制造意外、怎样安排节奏、何时与听众建立共鸣，都难以压缩为一个简单的通过条件。这也是形式任务与教学任务之间的重要差异。

这三个例子共同展示了两种评价：

形式上可逐项检查的条件	仍需要综合判断的质量
字数、句数、藏头顺序	表达是否自然
指定字是否出现	情节是否连贯
偏旁、读音是否符合约定	是否有趣、是否有美感

软件验收也有相似边界。通过已有测试，证明的是测试覆盖的条件；没有被测试的性能、可维护性或使用体验，并不会随之获得保证。

上下文不是越长越好

把要求放进项目规则或 Skill，可以提高模型在相关时刻看到它的机会。但“已经写进去”不代表“每次都会执行正确”。

讲义讨论了一个很具体的副作用：用户提出背景颜色和视觉效果要求，模型可能把这段沟通话语直接带入代码注释。样式做对了，产物里却多了原本没有必要保留的说明。

直觉上的补救是再增加一条规则，禁止出现这种注释。然而，每发生一次问题都加一条永久规则，会让上下文越来越臃肿。规则还可能彼此重叠或冲突，最后连遵循规则本身都变成复杂任务。

可以按用途组织信息：

长期稳定的项目约定保持简短。
当前任务的细节留在当前任务里。
特定方法需要时再加载。
能够自动检查的要求落实为脚本或测试。
参考资料单独保存，在真正需要时读取。

课堂对直接拿来使用的 Skill 也保持了保留：一次改善，不代表换一个任务后仍然有效。如果不断叠加规则却越来越困惑，可以退回当前任务，重新观察输入、模型行为和结果之间的关系，再判断究竟需要哪条指令。

这里的关键是信息对当前决定是否有帮助。删掉一段过时说明，可能比再补一段提醒更有效。

从“扮演专家”到交给模型一套方法

课堂使用论文审稿说明角色提示的局限。要求模型扮演 ICSE 审稿人、阅读论文、写约一千英文词的意见并给出接收建议，很容易得到一份形式完整的 review。它会有贡献总结、优点、不足和结论，但这些结构并不能证明判断深入。

论文作者已经选择了问题定义、术语、比较对象和评价方式。读者如果完全顺着文章走，可能接受了作者的所有前提，最后只在既定框架内提出几条小修小补。

口述里更具体的方法是，先与 AI 建立评判工作的共同起点：这个领域已经知道什么，已有工作解决到了哪里，新论文究竟试图推进哪一小步。把材料放回既有知识边界，才能判断贡献的意义，而不只是判断作者的故事是否自洽。

课堂用了一个抽象的性能优化例子：整体任务分为 A1 与 A2，如果 A1 已占据绝大部分成本，那么对 A2 做出局部提升，即便实验真实，也未必足以支撑对整体价值的宣称。检查要回到完整问题与收益量级。这是讲者说明审稿方法的例子，不是对某篇未公开论文的独立评审。

讲义据此整理了几种相互补充的审查方向：

检查判断标准：论文声称贡献了什么？这些贡献分别需要满足哪些条件？
核对证据链：核心结论由什么实验支持？哪些前提没有验证？是否存在其他解释？
尝试反驳或复现：能否重算关键结果、构造反例，或者明确一个足以推翻结论的观察？

这里很适合使用独立的 Agent，但独立要体现在方法上。如果所有 Agent 先接受同一份总体评价，再各自写意见，可能只得到同一种观点的多种措辞。先独立判断，再比较分歧，更容易发现盲点。

课堂也担心一种循环：AI 生成论文，读者再让 AI 总结，审稿人也让 AI 按论文自己的框架判断。如果没人认真检查贡献与外部知识的关系，局部自洽的文本可能不断增长，阅读却没有带来相应的新认识。这是讲者对学术实践的担忧，不宜扩展为所有 AI 辅助论文都没有价值。

当一套方法在多次任务里有效，就可以把它沉淀成 Skill。值得保存的是搜索路径、判断标准、检查方法和失败处理。角色名称可以帮助组织表达，方法才能影响工作过程。

Skill 也需要维护。把所有可能想到的限制都塞进去，会让它变成另一道复杂的多约束题。机械重复的部分交给脚本，稳定的方法保持清楚，参考内容按需加载，通常更容易复用。

成熟代码库本身就是一种上下文

一个看似反常的课堂观察是：AI 在成熟的大型项目里做复杂修改，有时比从空项目开始更顺利。

大型系统已经积累了很多决定：模块如何组织、名字怎么取、错误如何处理、测试放在哪里。Agent 可以沿着相邻代码的模式完成局部工作。仓库虽然大，当前问题需要临时决定的事情却可能更少。

空项目缺少这种约束。每次实现都可能顺手决定一种长期结构。早期选择如果混乱，后续生成又以这些代码为参考，就可能不断放大混乱。已有实现会影响未来实现，这让代码质量同时成为上下文质量的问题。

这并不意味着大仓库必然好改。模型同样可能学到历史包袱。讲义记录了一个尚未验证的设想：先让 Agent 阅读相近领域的优秀系统，再实现新需求，是否有助于改善设计？这个想法值得实验，但不能直接当成已经证实的方法。

PPT 对这个设想给出了比讲义更具体的限制：相似性、候选筛选和信息检索，可能比整仓库塞入上下文更关键。课件引用 RepoCoder 和 CodeRAG-Bench 作为延伸资料，强调项目相关信息可能有帮助，但这并不等于证明任意外部大仓库都能提升任务表现。这里记录的是课件用来限定猜想的观点，并未独立复现这些研究。

可以设计三组对照：不给示例、提供完整参考仓库、只提供三至五条精选实现路径。任务、模型、token 预算和随机因素尽量保持一致，再比较通过率、修改范围、审查时间、后续缺陷和代码克隆情况。这样检验的才是参考材料带来的变化，而不是把模型差异误认为方法收益。

真正有意义的比较，还应观察后续修改成本和缺陷，而不只是第一版能否运行。参考项目与当前任务的约束不同，也可能带来不适用的架构。

PPT 引用 Bainbridge 的《Ironies of Automation》补充这个问题：自动化接管常规工作之后，人剩下的可能恰好是更少见、更棘手的异常。因此，学习目标也会转向能否识别问题、提出边界与失败模式、解释某个候选答案为什么不对。

因此，学习操作系统、编译器、数据库等系统里的设计方法仍有价值。理解接口、状态、不变量和失败方式，才能判断该让模型借鉴什么，又应该舍弃什么。

长程任务：有反馈的修复与没有路线的研究

编程 Agent 能持续工作，一个重要原因是环境不断提供反馈：编译失败、测试失败、程序异常，都能帮助它选择下一步。修改之后再运行，形成循环。

但研究任务不一定有这么明确的反馈。讲义记录了一个尝试：把优化符号执行引擎的初步想法和 benchmark 交给 Agent，投入很多 token，最终仍没有得到想要的结果。

音轨里的复盘比官方讲义更具体。讲者指出，任务中出现了“想证明这个方法有用”这样的目标，Agent 随后围绕证明想法展开工作，不断构造小型 benchmark、做局部调整，却没有提供足以回答整体研究问题的证据。学生得到很多反馈，也无法判断这些反馈的意义。

讲者将这个偏差描述为 reward hacking：模型努力满足了眼前的目标，却偏离研究真正需要解决的问题。这是课堂对该案例的解释，本文没有独立复现相关实验。

他给出的纠正方向是，回到真实工具、现有算法和有代表性的任务中观察行为。即使某个案例运行几小时仍然超时，其中的搜索路径也可能提供重要信息：哪些程序结构让现有方法陷入困难？问题真正出现在哪里？这样的证据，比为了展示局部提升而构造的小例子更能支撑研究判断。

这不等于否定小实验，而是要求小实验与真实问题有联系。先确定要解释的现象，再选择能够区分假设的实验；不能先认定想法有效，再只寻找支持它的场景。排除一条错误路线，也是研究进展。

人的干预应该落在哪里

讲义记录了另一种效率判断：即使知道怎样帮助 Agent 更快完成单个任务，也不一定每次都要插手。

原因是人的注意力有限。机器多尝试一段时间，如果最终仍能完成，就可能换回人处理其他任务的时间。单个任务最短耗时，与一整天完成更多有效工作，是两个不同目标。

讲者还提醒自己警惕一种心理满足：发现 AI 犯错、立即纠正，会让人感觉仍然比机器有用；但这种感觉不等于时间花得值得。真正值得投入的，是自己还不理解、需要学习和判断的部分。已经知道怎样验收、机器也能够自行完成的工作，可以考虑交出去。

这个取舍依赖任务边界：接口清楚、结果可检查、内部实现容易替换时，放手的成本较低。会影响许多模块的设计决定，以及返工代价很高的动作，则值得提前关注。

长任务还会产生大量日志、补丁和中间材料。讲义提醒，上下文窗口装得下，不代表模型始终能同样有效地使用其中每条要求。阶段切换时，可以重新明确目标、接口与未解决的问题；重要不变量应尽可能获得可执行的检查。

PPT 还以丰田生产方式中的自动化与异常停线作类比：一个人可以看顾多台机器，但要有机制及时暴露异常。放到 Agent 上，可以对应为持续检查、报警、权限边界和停止条件。少干预的前提是任务能够并行、错误能够发现、失败能够低成本恢复；否则只是把问题延迟到以后。

上下文整理也不应只是压缩流水账。真正需要传给下一阶段的，是仍然有效的约束、已经取得的证据、关键决定与当前缺口。

探索能力来自不同方向，也来自筛选方法

有些任务无法一开始就给出清晰规格。取名字、做研究、寻找产品方向，都需要先探索，再逐步形成标准。

课堂用给孩子取名举例。直接索要几个好听、有寓意的名字，模型可能很快交出常见组合。如果很多人都接受同类答案，推荐结果反而容易趋同。

PPT 把过早停止与 Herbert Simon 的 satisficing 联系起来：找到一个足够可接受的方案后，搜索就可能停止。对于必须探索的任务，需要主动约定什么时候继续拓宽候选、什么时候才进入筛选，而不能把模型主动结束当成搜索空间已经被穷尽。

扩大搜索可以从划分方向开始：典故、音韵、方言、年代感、书写体验，各自提供不同候选；再核对出处、谐音与个人偏好。不同 Agent 可以独立生成，也可以分工挑错。

但增加候选数量只解决一半问题。如果筛选标准仍很粗，一百个候选也可能只是更多平庸结果。探索方向与评价方法必须一起设计。

这里有两种不同的计算投入：

沿同一条思路继续深入，争取理解得更细。
主动选择不同的出发点，争取发现原先没看到的可能。

多 Agent 的价值更多取决于第二项是否真正发生。相同材料、相同提问、相同预设，可能只是把一次思考复制多份。

讲义将这与人的交流联系起来：不同经历、教育背景和生活圈，让每个人注意到不同的问题。讨论的价值不只是获得答案，也包括发现自己的默认前提。Agent 协作同样需要差异，随后还需要证据来处理分歧。

PPT 在讨论人类视野时提到 Richard Sutton 的 Big World Hypothesis，并提醒群体协作也不会消除所有偏见。不同方向之间的冲突可能是有价值的信息；汇总的目标不必是尽快达成同一个看法，也可以是保留仍有竞争力的假设，等待进一步验证。

课程最后把问题推向未来：如果算力能够不断转化为探索和判断能力，资源差异是否也会变成巨大的智力资源差异？这是一个开放问题，不是课堂已经证明的终局预测。

把这一讲转成自己的工作方法

以下清单是根据讲义整理的实践版本，并非讲者原样给出的模板。

开始前，写出任务的边界。 说明目标、可用材料、关键约束和完成证据。对尚未决定的部分，明确哪些允许探索，哪些应先讨论。

执行中，优先改善反馈。 编译器与测试适合回答实现是否满足部分条件；基准测量适合定位性能问题；参考实例可以帮助表达设计偏好。反馈越具体，模型越容易判断下一步。

出现偏差时，先检查上下文。 必要信息是否缺失？规则是否过时？当前代码是否正在示范一种坏模式？不要把所有问题都归结为提示词还不够长。

需要专家工作时，提供方法。 要求审稿，就明确贡献、证据、反例和复现的检查路线；要求设计，就明确比较维度。多次有效后，再把方法做成 Skill。

需要探索时，设计差异。 让不同 Agent 从不同问题出发，先独立形成判断，再汇总。评估它们是否发现了新证据，而不只看意见数量。

长任务结束时，保留可继续工作的状态。 记录已经验证什么、还有什么未知、哪些假设失败，以及下一步最有区分力的实验。这样下一轮获得的是有效起点，而不是一段听起来完成度很高的总结。

资料与署名

蒋炎岩：《提示词工程》课堂视频。
蒋炎岩 / Yanyan’s Wiki：《提示词与上下文工程》官方讲义，本文课程内容的主要依据。
南京大学《生成式软件工程》2026 秋季课程主页。

视频约 98 分钟，整理时阅读了完整音轨的本地自动转录，并逐一核对约第 1 至 97 分钟、每隔两分钟抽取的 49 个画面。自动转录存在错字，术语与例子优先用讲义和可读课件交叉确认；抽帧不覆盖每一秒，也不保证收录所有短暂出现的页面。讲者在口述中说明，PPT 的部分星标内容由 AI 补充，因此本文将相应内容写作“PPT 提到”或“课件补充”，不把它们统一表述为讲者的逐字原话。

原讲义采用 CC BY-NC 4.0 许可。本文进行了主题重组、概括和解释，并增加了实践清单；课程观点归原作者，整理中可能的理解偏差由本文承担。