AI 协作原则与实践方法论
记录一些自己对于 AI 使用和协作的经验和思考，从自己与 AI 的问答中进行批判性思考提炼总结，而不是无脑收录进来。
反思自己与 AI 的交互方式，以及思考如何在 AI 时代下更有效地提升自我。
此外，这里更希望能够记录一些能够经得起实践检验的方法论和原则，而不是单纯的哄模型技巧或容易过时的技巧。
一、验证：判断它说得对不对
这套方法对任何单一信息源都适用，不限于 AI。
- 看有没有可验证的锚点： 文档链接、能跑的代码、具体来源。只给"通常""一般来说"的，按未验证处理。
训练数据里的产品知识经常是错的或过时的，没有查证来源默认不要相信。
- 看确定性与事实性质是否匹配。 概念、原理、数学相对可靠；产品功能、版本号、时效信息必须现查。对一件会变的事表现得很确定、又没有查证动作——危险信号。
一些不会变的东西更可靠，时效性和长尾知识需要额外考虑，慎重使用；
- 交叉验证靠外部来源，不靠继续追问。 追问"你确定吗"只会得到两种错误：为维持一致而坚持错误，或因施压软化成另一个错误。
- 手段： 官方文档、自己跑一遍、换一个模型问同一个问题。
"are you sure?"由于模型底层用了 RLHF 人类反馈强化学习，导致模型会发现附和以及遵循用户意志是得分最快最高的方式，从而对模型的回答客观性进行强干扰。
这是底层模型训练带来的倾向，对模型提出质疑后，并不是每一次得到的答案都是正确的，可能需要交叉验证。
- 区分"解释共识"与"下判断"。 解释一个广为人知的概念，可靠度较高；针对我的具体场景给的建议是观点，当参考视角，不当结论。
AI 做一个判断或预测（比如"对你这个场景，手动比自动好"），其实只是他的观点，不是事实，应该当作"一个值得参考的视角"而不是"正确答案"。
- 模型对自身机制的自述不可信，只信可观察的行为。 "我有某种内置倾向""你纠正一次我后面就会收敛""我给前几个问题分配了较多注意力"这类自我描述无法验证——它连自己的产品功能都常说错。识别它的行为模式靠自己观察，不靠它交代。
还是同一个问题，AI 存在幻觉，不是所有他的回答都能够作为后续推理的基础，对于一些产品特性和具体使用功能，需要自己想办法交叉验证。
- 前提来自 AI 时，链式推理前先验前提。 我曾把它的一个比喻（"注意力预算"）当真实机制往下推，推到了比喻失效的地方。在没验证的前提上做多步推理，错误会被放大。
之前这块 AI 说的没有给出验证锚点，自己又专注在思考上，没有意识到前面说的东西并不一定严谨；
二、提问的结构：覆盖、深度、顺序
- 覆盖靠编号。 埋在段落里的子问题容易被整段吞掉——被漏答过的那个问题，恰恰是没有独立编号的。
- 深度靠显式声明，格式给不了："第 3 题重点展开，其余简短"。最重要的问题单独发一条，让它没有别的问题来摊薄输出。
这点确实是要学习的，因为之前让 AI 对复杂文档总结前先进一步追问需求时，他也会提到要对里面的哪几点内容进行深入探讨；以后 AI 对自己的追问的维度要再多注意下。
- "写成段落能让深问题自动获得更多权重"不成立。 回答的深浅主要是输出端的生成现象，由长度先验、显式要求、措辞是否暗示展开、同时抛出的问题数量决定，不是输入端"注意力按难度分配"的结果。
- 串行提问还是并行提问： 顺序由依赖关系决定。
- 后一问会因前一答而改写的，串行发。打包会失去根据回答调整下一问的机会；
- 互相独立的问题，打包并编号，省轮次。（ 独立但各自需要深度的，还是要单独发）
三、提问的姿态：先亮判断，再要答案
- 贴一段材料只问"帮我看下 / 对吗"，是让对方替你读：你看到的是它的读后感，自己的解读能力没被调用。
- 改进方法： 所有"对吗 / 行吗 / 可以吗"之前，先写两句——"我的判断是 ___，因为 ___。"判断错了也要写，被纠正比不判断学得快。
- 代价： 先亮判断会锚定模型、诱发附和（见"识别谄媚"）。对冲：写明"我判断错了就直说"，并用信息增量检验它的同意——只会复述我的理由是附和，给出我没想到的理由才算独立判断
四、对输出提要求：给标准，少而具体
- 平铺十几个评价维度，得到的是每项都浅、表演式填满的清单——和人被迫填 KPI 表的状态一样。
- 有效问法是强迫优先级判断："找出最致命的一个，引用原文，给出重写版本。"
- 充分利用角色设定和给出标准： 角色设定里起作用的是它隐含的标准，例如"资深安全工程师"有效的部分是对抗立场和挑剔程度。
- 能显式写出的标准——受众、篇幅、立场、挑剔度——显式写比套身份可靠；
- 角色只在需要一次带入一整套立场时当简写。
- 交互契约也是标准：**"只告诉我哪里错了，不要给完整答案，我想自己改。"**把修改的练习量留给自己。
"不要给完整答案"会逼 AI 把你推回驾驶座；
- 收到批评就辩护，评价方后续会软化。
五、识别谄媚
对人也适用。符合任一特征的夸奖，按无效处理：
- 没有信息增量。 有用的反馈会具体到哪里好、哪里不好、怎么改。
- 出现在回答开头。 真正的评价要想完才下得了，开头就夸是反射。
- 评价词可以贴在任何问题上： "很准""很犀利""好问题"。
模糊但情绪积极。
- 评价与后文不匹配： 如果你的问题真的很犀利，AI 应该直接进入那个犀利点；
"AI 谄媚" 是模型底层训练带来的因素，不是个人可以控制的，需要对其回答内容多点批判性视角看待。
六、长对话的交接
- 直接说 "忘记之前说的"是无效指令： 上下文物理存在于窗口里，指令改变不了。清空靠开新对话，不靠指令。
- 全文搬运 ≠ 压缩。 把原始记录整段塞进新对话，只是让噪音换个地方发作。
- 转录和提炼是两种工作：转录主要是搬运，对状态要求低；提炼吃判断力。所以旧对话只做结构化转录（按主题不按时间、标注已被纠正的说法、列出悬而未决的问题），提炼放进新对话的干净窗口，并让它先复述理解、再反问关键问题。
- 一般化：需要判断力的工作，放在认知状态最好的地方做。
七、给 Agent 排任务
- 每一步落在可验证、可回退的稳定点上，不让它一次跨越多个不确定环节。任何一步崩了，退回上一个稳定点，而不是推倒重来——小步提交、频繁验证。
- Agent 的默认行为是给结果，不是给过程。想要过程透明度（每步改了什么、为什么），必须显式索取，它不会自发汇报。
透明度是要你花 prompt 字数去「买」的。
它不会自发地把过程拆开、在每步停下汇报，因为没人要求它这么做，而且一路做完通常更「高效」。
八、项目上下文文档（CLAUDE.md 一类）的本质
- 它回答的是：一个聪明但对本项目一无所知的协作者，不知道什么就会帮倒忙。每一条对应一类"不说就会犯"的错。
CLAUDE.md 里的每一条,都是「这个项目的某个关键决策或约束,一旦协作者不知道就会破坏它」
- 所以它是红线清单加隐性知识补丁，不是项目介绍。装的是对你显而易见、对他完全不可见的隐性知识：依赖方向、不能碰的约束、刻意保留的简化（如 e2ee 项目的"服务器不接触明文"——不写，协作者可能好心加条日志就把它摧毁）。
- 骨架通用：是什么 / 怎么跑 / 架构与职责 / 红线 / 已知坑 / 风格约定。内容完全由项目决定。
九、沉淀与内化
- 沉淀是提取，不是保存。 大部分对话不值得留；强行归档只会生产"看起来有用、永远不会再看"的东西。
- 载体是自己的笔记仓库。平台的记忆功能只是辅助：内容不可控，不可迁移。
- 沉淀动作绑在显式触发上（对话结束时的一个固定动作），不指望"到时候自然会记得"——条件触发对模型和对自己都不可靠。
- 用自己的话重写，是过滤、检验、内化三合一： 写不进去的是没价值的，写不清楚的是没懂的。粘贴等于收藏，不等于学会。检验标准：不看笔记，能用大白话给外行讲明白。
- 单次对话只有一个样本，看不出思维惯性；要看自己的提问模式和盲区，得把多次对话的记录放在一起看。
- 对真想精进的事，少一点自动化，多一点手动控制。
- 判断提示词好坏，三个信号够用：命中（说到点上）、意外（有没想到的洞察）、可行动（下周真能照做）。个人工作流的提示词凭这三个信号调整就行；正式的版本管理和量化评测，留给生产环境里有评测集的提示词。
- 产品机制类知识（Skill、Memory、上下文管理的具体行为）半衰期短，不能在主线任务还没有做完的时候，花太多精力学习沉淀。
- 先用最简陋的版本验证自己会不会真用，再考虑搭系统。
快速尝试、快速失败、快速重建!