把那件事定下来
需求收敛四段演示；三档任务：写四行需求、用五个真实输入试它、划一条人机分界线
本页解决的问题
先给结论「把那件事定下来」要解决的关键问题是什么？
需求收敛四段演示；三档任务：写四行需求、用五个真实输入试它、划一条人机分界线
跟着交接处走，不要只看 Demo。 系统是否可靠，往往取决于模型、工具、状态、权限和人的交接处。把每次交接都当成可以观察、测试和恢复的地方。
为一个自动化步骤写清输入、负责人、审批和恢复动作。
一次运行成功了，却说不清发生了什么，也无法安全重放。
大多数人给 AI 布置任务，停在第一段就交卷了：「帮我处理一下周报」。这句话没错，只是它没法验收。你不知道什么样的输出算成功，自然也不知道该不该改提示词。往下推三段，它才变成一个真需求。
从一句愿望到一个能验收的需求
一句愿望
「帮我处理一下周报」，想法有了，但也只是想法
定输入输出
进：一周的零碎记录；出：三段结论加一份下周计划
定什么算对
三段都能直接发给老板，一个字不用改
挑压幻觉的方案
要引具体数字，那就走 RAG，别让它凭记忆编
第四段为什么要单拎出来
这一章你学了四种压幻觉的办法：改提示词、RAG、调 Temperature、加评测。选哪个，看你的活儿会在哪儿出错。这不是四选一的偏好题。要引具体数字和条款，走 RAG；格式老是飘，改提示词再把 Temperature 调低；要长期跑、怕它悄悄变差，那就得有评测。选错了不要紧，但一开始就不选，等于把幻觉留给用户去发现。
调不了 Temperature，不代表少了一条路。它是 API 上的参数，ChatGPT、豆包这类对话产品里压根没这个开关。四种办法本来就彼此独立，缺这一个，另外三个照样单独成立。想把格式钉死，就在提示词里给一份模板加一个完整例子，写明「只输出这几个字段，不要解释」；同一句话连跑三遍看它稳不稳，比拧参数更能暴露问题。真到了非精确控制不可的程度，那本身就是该走 API 的信号。
这一章的动手清单
0 / 3 已完成
把那件事写成四行
15 分钟 所有人照着上面四段，写下你最想交给 AI 的那件事：一句愿望、输入是什么、输出长什么样、什么算对。写在便签、备忘录、随便哪儿都行，但必须是写下来的字，不能只是脑子里的想法。
什么算做完了
用 5 个真实输入试它一遍
1 小时 想先验证可行性别用编的例子。翻出五份真实材料丢给它，一次一份，提示词保持一模一样。重点是看它在哪一类输入上开始胡说，答得好不好先放一边。材料太长？信息缺失？有内部专有名词？把出错的那一类记下来。
什么算做完了
划一条人机分界线
半天 准备真做一个把这件事拆成「AI 做」和「你做」两半，写清交接点长什么样。比如：AI 出初稿并标出所有它不确定的数字，你只核对被标出来的那几处。分界线划在哪儿不重要，重要的是它必须能被检查。
什么算做完了
「先看清楚 · 需求要收敛到什么程度才算数」为什么能找到相关内容
「大多数人给 AI 布置任务，停在第一段就交卷了：「帮我处理一下周报」。这句话没错，只是它 没法验收 。你不知道什么样的输出算成功，自然也不知道该不该改提示词。往下推三段，它才变成一个真需求」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「这一章你学了四种压幻觉的办法：改提示词、RAG、调 Temperature、加评测。选哪个， 看你的活儿会在哪儿出错 。这不是四选一的偏好题。要引具体数字和条款，走 RAG；格式老是飘，改提示词再把 Temperature 调低；要长期跑、怕它悄悄变差，那就得有评测。选错了不要紧，但 一开始就不选，等于把幻觉留给用户去发现」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
先区分找得到和找得准
把「建造日志会一路陪你到协作方法论篇。六个里程碑填满，你手上就是一份完整的 Agent 设计说明。内容存在你自己的浏览器里，随时能导出成 Markdown」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「先看清楚 · 需求要收敛到什么程度才算数」走到「动手清单 · 挑一个开始，勾掉它」
「先看清楚 · 需求要收敛到什么程度才算数」先把问题落在「大多数人给 AI 布置任务，停在第一段就交卷了：「帮我处理一下周报」。这句话没错，只是它 没法验收 。你不知道什么样的输出算成功，自然也不知道该不该改提示词。往下推三段，它才变成一个真需求」上；到了「动手清单 · 挑一个开始，勾掉它」，讨论继续推进到「照着上面四段，写下你最想交给 AI 的那件事：一句愿望、输入是什么、输出长什么样、什么算对。写在便签、备忘录、随便哪儿都行，但必须是 写下来的字 ，不能只是脑子里的想法」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「先看清楚 · 需求要收敛到什么程度才算数」：大多数人给 AI 布置任务，停在第一段就交卷了：「帮我处理一下周报」。这句话没错，只是它 没法验收 。你不知道什么样的输出算成功，自然也不知道该不该改提示词。往下推三段，它才变成一个真需求
- 「动手清单 · 挑一个开始，勾掉它」：照着上面四段，写下你最想交给 AI 的那件事：一句愿望、输入是什么、输出长什么样、什么算对。写在便签、备忘录、随便哪儿都行，但必须是 写下来的字 ，不能只是脑子里的想法
- 「最后的要点」：建造日志会一路陪你到协作方法论篇。六个里程碑填满，你手上就是一份完整的 Agent 设计说明。内容存在你自己的浏览器里，随时能导出成 Markdown
最后的「最后的要点」把讨论落到「建造日志会一路陪你到协作方法论篇。六个里程碑填满，你手上就是一份完整的 Agent 设计说明。内容存在你自己的浏览器里，随时能导出成 Markdown」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。