https://jyywiki.cn/GSE/2026/lect2.md 讲讲这个

回复 群友 3892 这是 jyy 南京大学 GSE 2026 第二讲，内容主题是：从 prompt 到 context engineering。下面我按结构来讲： 一、开篇澄清“没有 token 的 CS 学生应该立即退学”这句话。这句话从上节课流传出来，在热搜上被断章取义了，他本人说这是要推动同学立即实践：不要把等待完美工具、等待别人给评价，变成一直不开始行动的理由。这一讲本身就是这个观点的示范，很多任务现在就能交给 agent 去做。 二、为什么 prompt engineering 变成 context engineering。 对聊天界面来说，prompt 是对话框里的一句话；但对 agent 来说，指令分散在很多地方：harness 给系统指令和工具说明，仓库里 AGENTS.md 定了项目规则，skill 提供方法，用户会在过程中不断补充目标，此外代码、文件、历史消息和工具返回也全在上下文里。模型下一步生成什么，取决于整份上下文，而不是只看最后那句话。所以关键从「怎么写好那句话」变成「模型做决定时能看到什么」，也就是分清目标、约束、证据、过时过程记录，以及来源和优先级。特别点出了指令和材料的区别：工具返回的一篇文章是分析对象，不会因为它出现在上下文里就获得了给 agent 下命令的资格。 三、指令写了不等于实现了。为什么有的命令会弹确认、有的不会？不能只说「模型觉得安全吗」，还有外围程序在查权限和审批规则，操作系统在执行访问限制。提示词里的要求和程序里的机制一起决定行为，一句「请遵守规则」不等于有执行边界。 四、Intent / Spec / Impl 的缺口。 「一句话生成极品飞车」，模型给你的是能移动会碰撞有速度感的网页，你心里想的是有真实地图、特定资产、某种驾驶手感的赛车游戏。它没违背任何一条指令，只是一连串默认选择之后做出了另一个产品。「现代风格的主页」里「现代」也没排除多少可能。经验法则：写清楚你的指令，承担一切「不明确」的后果；没说明的地方，等于把决定权交出去了。可检查的验收标准像这样：「页面首先展示研究方向和近期工作，手机上无需横向滚动，所有项目入口都能打开」。完成的语义还包括失败：关键条件验不了，就该报告哪里没完成、缺什么证据，而不是交一段肯定的总结。 五、模型怎么同时满足很多约束。一次前向的深度有限，但它可以把中间结果写进上下文当草稿纸继续算，token 多了计算深度就多了。然后他给了三道故意刁难的写作题来把难度摆出来：八句中文诗藏头「计算机学院真牛逼」、嵌「二零二六九月一日」、押韵还得讲动物故事；一句话十八个汉字全部同偏旁且有故事（「洪涝淹没江港渔浦，油污漂浮，沈涛泅渡济溺」）；全同音写现代背景的文言故事。检查时能逐项对：藏头对上、字数对上、偏旁对上，但「方向」的「向」和别人韵脚不齐、句子明显为凑约束；「都含三点水」和「词典里同部首」是两个不同规格；「同音」要不要同声调也没定。形式能检查的部分它过了，通顺和文学性不会自动跟着来，软件测试也是这个边界。 六、提示词有副作用。你说「白色背景，不要半透明效果」，模型可能把它变成代码注释写进去。修补冲动是再加一条永久规则禁止把要求写进注释，但每遇一次问题加一条规则，上下文越来越长、约束越来越难协调，这不是免费增强。该分开：长期稳定的简短约定放项目层，特定任务的方法按需加载，能直接检查的要求落到代码和验证结果——白背景用样式和渲染结果确认，别靠越来越长的劝诫。删掉一段无关说明，有时候和加一条关键要求同样有效。 七、论文审稿的例子最能说明方法论的分量。让它扮 ICSE 审稿人写一千词 review，它很容易写出像模像样的总结、优点、缺点、接收建议，但「扮演审稿人」只给了语气和结构，没给一个好审稿人的方法。论文信息密度高，作者连问题、术语、比较对象和衡量标准都替你选好了，顺着读完很容易在作者划的场地里打转，还以为自己在批判思考。可行做法是拆三条独立路线：从判据出发还原贡献并问标准与证据；审查证据把主张、实验、未验证假设、替代解释一一对应；站复现者或反方位置重算关键结果、找最小反例、明确什么观察能推翻结论。价值来自问题不同，如果一开始共享同一个总体印象，最后只是同一判断的三份润色。这套东西做多了再沉淀成 skill——skill 真正值得存的是搜索策略、判断标准和检查点，而且不是越长越好，塞满了它自己就变成一道藏头诗。 八、一个反直觉的观察：从零做个小产品，AI 会在某个点开始不断翻车；进一个成熟大系统反而能做出相当复杂的修改。原因是成熟代码库已经替你做了很多决定——命名、分层、错误传播、测试位置，当前任务里需要自由选择的事更少；空项目每次局部实现都顺手做成了长期设计决定，群友 8334混乱的惯例又被后续生成当上下文，AI slop 就层层叠加。代码库本身也是提示词。但不能推成「大仓库一定好改」，它也会模仿历史包袱。他还留了个未经实验验证的猜测：给 agent 看一个相近领域、设计优雅的成熟系统，能否提高实现质量？这有待实验——相近领域到底多相近、读整个项目还是几个关键例子、参考项目的约束不同会不会把不合适架构也学过来；可以设无参考、完整参考、精选参考三种条件比修改代价和缺陷，而不只看第一版能不能跑。 九、长程任务靠反馈闭环。改、构建、测试、观察、再修。但给更强模型更多 token 不保证收敛，他讲了个研究失败案例：优化符号执行引擎，把想法和 benchmark 一起丢给 agent，烧了很多 token 没出结果。原因没查明，但待检验的解释有两个：一是总 benchmark 分数反馈太粗，看不出到底卡在求解器、路径搜索、缓存还是新增开销，下一步试什么没法判断；二是任务被定义成「把这个想法实现好」，而研究真正要回答的是「这个想法是否成立」，假设本身错了，实现再完善也没用——一个能否定原想法的实验比更多代码更有价值。更好的起点是先测主要瓶颈，把想法写成可被实验推翻的预测，做快速反馈的小实验，确认局部机制有效再放回完整系统看收益还在不在。研究的推进可以是缩小未知，也可以是排除一个方向。 十、人该不该随时干预。他的经验是：明知道怎么让某任务更快完成，反而越来越少干预了。因为单任务完成时间和一天能完成多少任务是两个目标，agent 走点弯路但能完成，人就能去看别的事，机器多花时间换回人的时间。边界是：接口看过、结果可检验、坏了能换，就放手；会扩散到很多模块的接口决定、昂贵或难恢复的动作，就值得提前盯。人的注意力按决策影响和返工代价分配，不按行数平均撒。 十一、长任务上下文膨胀后指令遵循会下降，最近的要求和刚加载的方法更容易被执行。工程上要缩短「关键要求」到「关键决定」的距离：阶段切换时重确认目标、接口和未决问题；把可检查的不变量写成测试；让错误在传播前暴露。上下文压缩要保住当前约束和证据，别只写成流水账。 十二、没有确定路线的任务怎么办。说「帮我考虑几种方案」常常过早结束——给出几个听起来合理的答案就满足了数量要求，更有意思的可能在没走到的方向。用取名当例子：直接要几个，模型给的是它偏好的高概率组合，大家同时问就迎来新一代「子涵」。可以先划空间（典故、音韵、方言、时代感），再查出处、谐音、书写和偏好；也可以让多个 agent 独立出候选或专门挑错，关键是它们是否看了不同方向、问了不同问题，不是开了几个看起来一样的窗口。给更多名字解决数量，留下哪些需要评价标准——没有分辨率的筛选只是把一个平庸答案变成一百个平庸答案。探索空间和评价方法要一起设计。人类一直靠这个扩展视野：舍友、会议、别人的提问，价值在于暴露自己的默认前提。 十三、最后那个不安的问题：算力能持续转成探索和判断能力的话，「墙里面是超人，墙外面是动物世界」怎么办。这是对可能性的追问，不是终局。对在读的人来说落点很实际：让模糊愿望有可检查的表达，把有效经验沉淀成可复用方法，需要探索时主动扩展方向，再用证据筛结果。 跟前一讲连起来看，第一讲讲的是「token 即算力、agent 已经能做很多事」，这一讲回答「怎么驾驭」，答案不是把句子写得更好，而是组织好它做决定时能看到的东西，并且用能检查的结果去接住它。