UNSEEN · 认知报告 · 批判分析 · 广场
把模糊现象先转写为可观察、有边界、有验收标准的问题说明，是让 AI 的方案能被检验的前提；问题说明越清晰，AI 才能把速度用在对的方向上。
原文速写
一篇关于如何与 AI 协作解决问题的说理文。以「搜索太慢」为引子，指出用户真实痛点可能是新品两小时搜不到，而非响应时间，借此说明模糊需求会误导优化方向。随后给出一套问题说明框架：把现象说成可观察的问题、明确目标与验收、列出不能破坏的边界、区分已知与未知。文中用一份购物搜索场景的示例说明如何落地，并强调说明长短视问题规模而定，目的是让 AI 把精力用在查证与实现上，而非在错误方向上快速产出。结尾指向下一步：准备与问题相关的 Context。
这篇内容真正讨论什么
原文设定场景为「搜索太慢」这一模糊需求被直接交给 AI，AI 很快围绕缓存、分页和索引优化给出方案；作者以新品上架后两小时内搜不到为例，提出在动手前先完成问题定义。原文未给出具体系统、代码或运行数据，也未标注所涉功能的具体年份信息；下文时间表述以原文发布时间 2026-09-16 为锚。
逻辑质量分析
优势
- 用一个具体反例把「表述听起来明确」与「问题被正确定义」区分开，使抽象主张落到可检验的差别上，而不是停留在「要写清楚」的口号层面。
- 展示了对因果的克制：把索引每两小时运行一次列为已知事实，同时把两小时间隔为何如此设置「能否增加增量更新」留在未知中，没有由一条相关事实直接跳到根因结论。
- 把「未知」的功能定位为定向检索而非自我穷举，避免把「先查完」设为方法的前置门槛，显著降低了该建议的执行阻力。
- 主动为方案设定可证伪条件：给出不能破坏的边界与可观察的验收方式，使后续方案有明确的检验标准，而非仅凭「改得漂亮」来判断。
- 对自身方法作了适用范围限定，承认篇幅随问题复杂度变化，并在结尾处为结论保留修正通道，避免了方法绝对化。
不足
- 核心因果主张以方向性断言给出，缺少中间机制说明：为何清晰度提高会让速度用在对的方向上、为何模糊就必然把错误方向做成完整产物，文中未展开，且其支撑主要来自单一个案，属于以例代证的归纳跳跃。
- 从搜索索引这一案例推广到全称命题，未讨论问题在动手前不可定义的情形（根因未知、目标需在探索中修正），此时「先回答四个问题」可能产生虚假的确定性或拖慢生成。
- 文本把新品上架后两小时内搜不到作为已知现象直接写入说明，但未交代从「搜索太慢」这一抱怨到该现象的转写依据；这一步本身是诊断，若它同样未经检验，就会与文中被批评的「我猜是缓存问题」属于同一类判断，只是位置更靠前。
遗漏
- 缺少对问题说明本身写偏的检测机制：文中的检验标准只作用于 AI 给出的方案，却没有说明由谁、依据什么来确认这份说明捕捉到的是真问题。
- 未讨论写说明的成本与收益权衡——在简单或时间敏感的任务上，先完成四项定义是否仍是净值正的选择，文中未作区分。
- 未处理多方对现象、目标描述不一致时的收敛方式，而文本已将问题说明定位为「所有参与者都能检查」的协作产物，这一前提需要额外的协调机制支撑。
反向视角
- 原文的方向性判断依赖一个未验证的前提：问题表述的清晰度是决定 AI 输出方向的主导变量。但 AI 迅速给出缓存、分页、索引方案，也可能主要来自模型先验分布——「搜索慢」在训练语料中的高频解法本就是这些。若方向偏差主要来自先验，清晰的问题说明降低的是纠偏轮次，而不是首发方向的错误率，「题目越清楚，AI 越能把速度用在后续查找和实现上」在首轮生成上可能不成立，只在多轮迭代中成立。这是待验证的问题，不是结论。
- 同一份说明同时承担 AI 执行输入与人类复核载体，这两个功能的要求可能相反：为了让人类能复核，说明里需要写入因果假设与背景；而任何写进说明的假设都会立即成为 AI 的方案前提，这正是原文用未知栏要隔离的东西。若二者冲突，则文档越便于人类复核，越容易把猜测制度化为前提。原文未处理这一冲突。
替代性解释
- 另一种解释是，AI 快而偏的原因不是缺少问题定义，而是缺少即时反驳：生成之后没有任何东西能立刻否证它。若验收可以自动化（写成可执行的检查），问题定义完全可以由生成与被反驳的循环反推出来，前置定义并非唯一路径。这取决于验证成本能否压到低于定义成本；原文场景中验收需要连续观察数天，这一点原文未展开讨论。
- 也可能「先把抱怨说成能处理的问题」的主要收益不在认知层（选对方向），而在协作层：它把争议对象从谁的需求更急，换成哪份说明与观测更吻合，从而改变了组织内争论的载体。若如此，其收益应随利益相关方数量上升，而与技术复杂度关系不大——这与原文按复杂度（小 bug 到多系统改动）来界定篇幅的说法并非同一来源。
核心洞察
- 把抱怨转写成问题说明，并没有消除验证成本，而是把它从方案层搬到了问题层——而原文只给方案层配了验收装置。清单里目标有对应验收，现象却是被直接写成既定事实的：那条现象来自对抱怨的一次解读，而不是一次观测。若解读有误，说明书写得越清晰，错误框架传播得越快，因为它以「已确认的问题」的面目出现，比模糊抱怨更难被察觉。L2 · 发现隐藏变量置信 · 中
为什么：原文中验收条目检验的是改动结果——「验收：上架测试商品后十分钟内可搜到，并连续观察三天。」；而「现象：新商品上架后的两小时内无法通过名称搜索到，老商品正常。」是被直接列入清单的，从抱怨到该现象之间的转写依据原文未给出。原文把「可观察」当作这一步完成的标准——「先把模糊现象变成可观察的问题」——可观察与已核实是两件事，原文未作区分。
意义：这意味着这道工序的收益上限由现象转写的正确率决定，而不由说明的详细程度决定。把现象条目当作待验证假设而非分析起点，是「先定义问题」能否真正减少返工的关键；否则它只是把一次昂贵的错误从改动后提前到了说明阶段，并未真正拦截。
- 未知栏里混着两类可获得性完全不同的东西：一类答案在代码、配置与运行数据里（可行性、代价），一类答案在人的决策历史里（当初为什么这么设计）。原文对二者给出同一种处置——让 AI 去查。但对后一类，AI 检索不到答案，只能生成一个自洽的事后叙事；一旦这个叙事填进清单，它就披着解释的外衣进入方案前提，比原先那种「我猜」式的猜测更隐蔽。L2 · 发现隐藏变量置信 · 中
为什么：原文列出的未知项是「还不知道的是，能否在保留批量任务的前提下增加增量更新、代价多大，以及两小时间隔最初为什么这样设置。」其中前两项的答案存在于系统内部，第三项的答案通常不在系统内部。而原文给出的处置是统一的一句：「把未知写出来，不是要求你自己先查完。它告诉你下一步该让 AI 查什么」。它正确地把未知定位为检索方向，但没有区分哪些方向机器可检索。
意义：未知清单应按「答案在哪里」而不是按「看起来多重要」来分类，这决定哪些未知可以外包给机器、哪些必须留在人这边。在 AI 参与的工作流里，人的判断杠杆主要落在后一类问题上——不是判断力更强的位置，而是机器根本够不到的位置。
- 清单条目的错误暴露度是不对称的：目标错了会在验收环节暴露，边界错了不会。边界在逻辑上先于方案生成起作用——它一次排除掉一整类解法，而被排除的解法永远不会出现在验收视野里，因为验收只回答目标是否达成，不回答是否存在更省的路径。于是把一条偏好写成硬边界，代价不是方案变差，而是方案空间被静默缩小。L2 · 发现隐藏变量置信 · 中
为什么：原文的边界是「边界：不停止现有批量任务，不改变下游报表依赖的输出格式。」，并要求「AI 此后提出的方案，必须在这些条件下接受检验。」；而验收「验收：上架测试商品后十分钟内可搜到，并连续观察三天。」只检测结果。原文没有提供任何判断某条边界究竟是硬依赖还是偏好的方法，也没有为边界项设置证据要求。
意义：同一条清单上，越无法被验收捕获的条目，越需要外部证据支撑（谁依赖这个输出格式、依赖到什么程度、可不可以谈）。把证据要求按是否会被验收抓住来分配，比按条目的重要性来分配更接近实际风险分布。
- 清单条目之间的相容性没有人负责检查：目标是否落在边界允许的范围内，恰恰取决于尚未知的那一项的答案。若增量更新在保留批量任务的前提下不可行或代价不可接受，目标与边界就不能同时满足，方案空间为空；而此时 AI 未必报告无解，更可能交出一个违反某条边界、外观上与合规方案无差别的产物——因为验收只测目标，不测边界是否被违反。L2 · 发现隐藏变量置信 · 中
为什么：「目标：将可搜索时间缩短到十分钟内。」「边界：不停止现有批量任务，不改变下游报表依赖的输出格式。」「未知：能否增加增量更新、代价如何、两小时间隔为什么这样设置。」三项并列在同一份清单中，原文把它们当成可以同时成立的条目。原文的要求是「无论篇幅，动手前至少要回答几个问题。」——要求回答，但没有要求检查答案彼此是否相容。
意义：说明写完只是必要条件，不是充分条件。在交给 AI 之前还需要一次相容性检查：目标在该边界与未知项的约束下是否可达。缺了这一步，一次本可在几分钟内暴露的无解，会被推到方案成型之后才显现，而且以违反边界的形式显现，而不是以「无解」的形式显现。