结构化思维》第一、二章 → prompt review skill 优化启发清单

《结构化思维》第一、二章 → prompt review skill 优化启发清单

用途：把黎甜《结构化思维》第一、二章的方法论，逐条映射为 prompt-review-skill-v2.md 的具体改动项。

标注：建议立刻改 / 可选。

一、来自第一章的启发

启发 1：规则有"事实"和"要求"两种性质，混写就是歧义源头（建议立刻改）

书中依据： A 先生与 B 女士的案例。同一个"他是非常负责的人"，B 女士当作事实陈述，同事当作背后夸赞。一句话的性质不同，随后的看法和行为完全分化。第二节又明确：很多人的认知停留在"看法"上，忽视了言行本身就是思考的结果。

迁移到 prompt： 一条规则同样有两种性质------

• 事实型： 描述客观约束（"会员等级由后端返回的 level 字段决定"）；
• 要求型： 表达写作者的期望（"回答要专业一点""语气友好"）。

要求型规则没有可判定标准，模型只能猜。这正是林宇翔现场说的"规则很细但不严谨"的根源。

落地改动： 在 5.3 判定前新增一步规则性质分类，并规定：

要求型规则必须转为可判定条件，否则记 P1。

反例："回答要专业一点" → 正例："回答不得使用口语化表达，不得出现'大概''可能'等模糊词"。

启发 2：识别"继承来的废弃规则"（路径依赖）（建议立刻改）

书中依据： 5 只猴子与香蕉的实验。高压水撤掉之后，笼中猴子全换过一遍，却没有一只敢碰香蕉------规则还在被执行，但执行它的理由早就消失了。

迁移到 prompt： 项目里的 prompt 规则也存在路径依赖------从别的模块复制过来、当时针对的 bad case 早已不适用，但规则还留着。这类规则比"没用的段落"更隐蔽，因为它看起来是正经规则。

落地改动： 在 5.5 工程性检查中，把"失效内容残留"升级为两类：

检查项	判定方法	结论
废弃段落残留	整段规则是否还被引用	存在 N 处
失效规则残留	每条规则追问"它针对的是哪个 bad case？该场景还存在吗？"	存在 N 处（列规则编号与行号）

判定锚点：无法给出具体针对场景的规则，一律视为失效候选，但不直接判删除------标注为"待确认"，由业务方决定。

启发 3：报告要给"判断方法"，不能只给"结论"（建议立刻改）

书中依据： 第一节的核心论证是"改变思维才是改变一切的源头"------三胞胎的悲剧不是事实造成的，是思维方式造成的。而第四节那句更适合直接引作 skill 的立论：

"文笔是从 60 分到 90 分的利器，而思维结构却是能不能及格的关键。"

迁移到 prompt： 如果 _summary.md 只输出"这里错了、那里要改"，写作者下次还会犯同样的错------你改变的是他的这一份文档，不是他的思维方式。

落地改动： _summary.md 的每条问题，在"建议"之后增加一个字段：

• 可复用判断法： 把这条问题抽象成一句可自查的问句，供写作者下次自己使用

例：问题"示例与 schema 不一致" → 可复用判断法："我给的示例，能不能直接通过我定义的 schema 校验？"

二、来自第二章的启发

启发 4：审核输入的信息全面性，决定结论的正确性（建议立刻改）

书中依据： 看房与选手机两个案例（只多一条"房龄"或"网络支持"，决策就反转）。书里的结论是------

我们最容易获得的信息，通常是别人希望我们看到的信息。如果我们只是在别人的框架里思考，其实是被别人用信息控制了我们的感觉和认知。

迁移到 prompt： skill 现在只要求一个 prompt_file。但 prompt 从来不是孤立的------真正的约束来自调用方代码、上游 schema、需求文档、下游解析逻辑。只看单个文件就下结论，等于在看"别人整理好的那张表"。

落地改动： 两处。

1. 输入参数新增 context_refs（可选，但强烈建议提供）：

参数名	key	含义	必填
上下文参考	context_refs	调用方代码、schema、需求文档等路径	否（缺失时须在报告中声明审核边界）

2. 在 5.1 之后新增信息边界声明（强制）：

## 审核边界
- 已读取：[文件列表]
- 未获取：[缺失的上下文]
- 因此以下结论置信度受限：[列条目]

并明确规定："无法判断"是合法结论。信息不足时必须写"因缺少 XX 无法判定"，不得凭推测给结论------这直接对齐第一章"不臆断"的作业准则。

启发 5：问题条目的六要素（建议立刻改）

书中依据： 记录事件类信息要用"逻辑线"，关键点是人物、地点、时间、起因、发展、结果六要素。

迁移到 prompt： 审核报告的问题条目，现在只有"原则/位置/问题/建议"四项，缺了"起因"和"结果"------也就是这条规则当初为什么这么写、它现在造成了什么后果。缺了这两项，问题看起来就像审核者的个人偏好。

落地改动： 问题模板升级为六要素：

### P1-1
- **位置：** `[文件:行号]`
- **现象：** [原文中的具体表现]
- **起因：** [推测或可查证的引入原因，如"为修复某 bad case 追加"]
- **影响：** [会导致什么后果：解析失败 / 输出漂移 / 维护困难]
- **依据：** [对应第五节的哪条规则编号]
- **建议：** [具体可执行]
- **可复用判断法：** [抽象成自查问句]

启发 6：一字之差，情境天差地别 ------ 模态词检查（建议立刻改）

书中依据： 记录金句"强调的是完整性"------

"暗香浮动月黄昏"比"暗香浮动近黄昏"更有意境，而我们往往就缺这一字之差的境界。

迁移到 prompt： 提示词里最容易一字之差改变语义的，就是模态词和连接词。

落地改动： 新增 5.6 措辞精度检查。

检查项	判定方法	结论
模态强度一致	同一约束在全文是否统一为"必须/应当/可以"之一	一致 / 漂移（列位置）
连接词明确	"且/或""和""以及"是否会产生歧义（如"活动或讲座"是并列还是择一）	明确 / 歧义
量词明确	"全部/部分/至少/至多/所有"是否可判定	明确 / 模糊
例外条件明确	"除非/否则/除...之外"是否给了完整条件	明确 / 缺失

典型反例：同一份 prompt 里，输出格式一处写"必须输出 JSON"，另一处写"建议输出 JSON"------模型会按弱约束执行。判 P1。

启发 7：规则原子性------一条规则只承载一个约束（建议立刻改）

书中依据： 加工处理·分解。"我喜欢吃榴梿"包含"我""喜欢""榴梿"三个信息点；再复杂一点------"我喜欢吃榴梿，也喜欢吃鸡，但是不喜欢吃榴梿鸡"。书里明确：信息点越多，理解速度越慢、效果越差。

迁移到 prompt： 一条规则里塞两个可独立违反的约束，就变成了复合规则------模型满足其中一半，也算"遵守了"。

落地改动： 5.3 新增原子性检查。

• 判定方法： 把规则按"可独立违反的最小约束"拆分计数；若一条规则含 ≥2 个可独立违反的约束，判为复合规则。
• 结论： 原子 / 复合（需拆分，列 Rn.1 / Rn.2）
• 示例： 不得向用户提供未经验证的优惠信息，也不得引导用户绕过身份核验 → 拆为两条独立规则，分别可违反、分别可测试。

启发 8：理解规则要问三次"为什么"（建议立刻改）

书中依据： 理解那一节的范本------上司说方案"过于全面了"，作者连问三次为什么：为什么这么说 → 说明面面俱到；面面俱到是好事为什么不是夸奖 → 说明有缺点；为什么会是缺点 → 重点不突出、冗长。最后再去确认："您是说我的方案写得太长、没有重点吗？"

同节还有五个馒头的笑话：大汉不理解填饱肚子靠的是五个馒头，而不是第五个馒头------理解不能停留在表面。

迁移到 prompt： 审核时最常犯的错，是把表象当根因。看到"示例格式不对"就写"改示例"，但真正的根因可能是"这份 prompt 是模型生成的，示例从未与 schema 校对过"。

落地改动： 对每条 P0/P1 问题，强制走归因三问：

1. 这条规则/写法当初想解决什么问题？
2. 为什么用现在这个写法，而不是更直接的写法？
3. 这个写法为什么会失效？（落到具体机制，如"示例引导模型照抄"）

只有能回答第三问，才可以写"建议"；答不上来就标为"待确认"，不得给修改建议。

启发 9：审核者自己也有筛选偏差（建议立刻改）

书中依据： 筛选那一节的数据与案例------

人脑每秒接收约 1000 万比特，每秒只能处理约 50 比特；如果 1 秒接收的是 1 杯糖，同等时间只能处理 10 个糖晶粒。

我们会只看到符合自己观点的信息，从而忽视那些能验证自己"是错的"或"不够好"的信息。

书中给的三个解法：先收集资料而不是急着判断（至少三种渠道）、主动寻找背道而驰的信息、咨询旁观者。

迁移到 prompt： 两个方向。

（1）对提示词本身------这段数据是"上下文卫生"最硬的量化依据。之前 v2 里"规模合理性"是个模糊判断，现在可以给出机制解释：提示词越长，单条约束被"注意"到的概率越低，有效信息被稀释。

（2）对审核者------审核者也有确认偏差：熟悉的几类问题反复报，不熟悉的类别直接跳过。三个防治措施：

书中解法	落地为
至少三种渠道收集信息	每条结论至少两类证据：原文行号 + 调用方代码/schema/需求文档
主动寻找背道而驰的信息	反证步骤：对每个判为"有问题"的项，先找一遍"这个写法可能是正确的"的证据（上游要求、历史约束、下游兼容）
咨询旁观者	报告中单列「需人工复核项」，标出审核者置信度低、需要业务方确认的问题

并且明确规定：5.1--5.6 每一项都必须产出结论（含"无问题"），不得跳项------防止只审自己熟悉的那几类。

启发 10：用"联想四法"重做 MECE 排查（建议立刻改）

书中依据： 联想那一节给出四种方式------相关、相似、对比、因果，并说明"这四种联系就是联想的桥梁"。咏雪案例中，谢朗想到"撒盐"（相似），谢道韫想到"柳絮"（不仅相似，还把轻灵的感觉也传神描绘出来）。

迁移到 prompt： MECE 的"不重复、不遗漏"在 v2 里写得偏抽象。用联想的四种桥梁去套，正好把每一类都变成可执行的排查动作：

联想类型	排查问句	对应问题类型
相关	这条规则与哪些规则相关？拆分方式/归属判断是否一致？	MECE 遗漏
相似	是否存在表述不同但语义相同的规则？	MECE 重复
对比	是否存在与它相反或互斥的规则？	MECE 冲突
因果	条件与动作的因果链是否成立？（"如果 X 就 Y"，X 真能推出 Y 吗）	新增：因果错配

"因果错配"是本轮新发现的一类问题，v2 里没有覆盖。例如：如果用户询问停车位，则返回 transport-agent 的导航结果------条件与动作之间的因果并不成立（问停车位不等于要导航）。判 P1。

启发 11：只给结论的路由规则不可复用（建议立刻改）

书中依据： 演绎那一节，三段式的结构是 大前提（客观事实）→ 小前提（属于事实的子范畴）→ 结论（根据相关性得出）。书里的正论示例：独生子女开放了二胎政策（大前提）→ 我是独生子女（小前提）→ 我可以生二胎（结论）。作者还强调：在三段式推理中规则是最重要的，如果一开始的规则错了，推理也就全是错的。

迁移到 prompt： 路由类规则最常见的写法是只给结论------"活动类归 events-agent"。这不可复用，因为新场景出现时无法判断它算不算"活动类"。好的写法必须把大前提写出来。

落地改动： 5.3 新增路由规则可复用性检查：

• 判定： 该规则是否给出了判定依据（大前提），还是只给了归属结果？
• 只给结论、没给判定依据的，判 P1，并给出改写建议：补一句"凡属于 X 类（判定依据）的内容，归 Y-agent"。
• 这正是会上张永超说的"按统一维度分类"在单条规则层面的落地形式。

启发 12：关键约束要能"存进多个抽屉"（可选）

书中依据： 存储那一节------大脑像抽屉一样存储信息，将相似信息归类，通过线索提取；提高存储量的办法之一是"充分调动原有信息并产生联想，让信息存入多个抽屉"；短时记忆可用"组块"扩大容量。

迁移到 prompt： 两个可用点。

1. 组块命名： 把反复出现的约束组合命名，全文统一引用。例如把"不臆断、不猜测、信息不足先追问、不确定就说原文未提供"命名为「不可臆断」，在角色、输出、错误处理三处引用同一名称。命名组块比重复长句更容易被稳定识别，也让后续维护只需改一处。
2. 多抽屉呼应： 关键约束不能只出现在一处。反例------只在"错误处理"里写"信息不足先追问"，但"输出"章节没提，模型在生成输出时不会回头看那一节。

判定：同一约束在多处出现但表述不一致（术语漂移），判 P1。

启发 13：skill 自身要闭环 ------ PDCA 与迁移运用（建议立刻改）

书中依据：

• 行动那一节的 PDCA：在第一个 PDCA 里发现的问题，会成为第二个 PDCA 循环里的一部分------比如实施培训时发现学员手册可以修改，那么第二次培训的规划里，修改学员手册就成为计划的一部分。
• 迁移运用三步骤：迅速把无关的东西联系、从不同的事情里识别共同模式、借用新资源整合现有资源就是创新。
• 作者的评价：迁移运用是真正的脑力上的勤奋，很多人还停留在体力的勤奋上。

迁移到 prompt： 这正是会上张永超说的"共性问题可以不断补充到审核规则里"的方法论依据。skill 现在只有"审核 → 输出"，缺了 Check 和 Act。

落地改动： 两处。

1. _summary.md 末尾新增一节（强制）：

## 规则库回流建议
本次发现的问题中，以下情形未被第五节的任何现有规则覆盖：
- [问题描述]
- [建议新增的规则条目与判定方法]

2. skill 自身增加一个轻量的 PDCA 说明：每次审核都是一轮循环，回流建议累积后按季度修订第五节------让 skill 从"单次审核工具"变成"团队知识沉淀容器"。

三、优先级排序（如果只做三件事）

顺序	改动	理由
1	信息边界声明 + "无法判断"合法化（启发 4）	这是可信度的地基。信息不全却给出斩钉截铁的结论，比不审核危害更大
2	规则性质分类 + 原子性检查 + 模态词检查（启发 1、6、7）	三条都指向同一件事：把"要求"变成"可判定条件"。直接决定 P0/P1 判定的稳定性
3	审核者反证步骤 + 规则库回流建议（启发 9、13）	让 skill 从"一次性工具"变成"会自己变强的工具"，也是团队最需要的沉淀能力

四、一句话总结

前两章给 skill 的启发可以归成一句话：

审核不是找错，是重建判断的依据。

第二章讲的是"信息 → 加工 → 呈现 → 迁移"这条链路，而 skill 现在的漏洞恰恰集中在链条两端------入口端信息不全面（启发 4）、出口端只给结论不给判断方法（启发 3、13）。中间那些加工动作（分类定性、分解、理解、筛选、联想、归纳、演绎）反而可以直接搬过来当审核规则，因为审核一份 prompt 和处理一条信息，本质上是同一件事。