1058 字
5 分钟
编号提问是检查表,不是排版习惯

翻了一遍自己的协作记录,两段最密集的会话里,我用编号列问题的形式提问了 936 次。这个习惯最初只是为了把几件事一次问完,后来才意识到它真正起作用的地方在别处:编号把一次回答拆成了若干个必须单独交付的项,哪一项没有被回应,对照一遍就能看出来。我的判断是,编号不是排版习惯,而是提前加在回答上的一张检查表。

段落式提问与编号提问的差别

写成一段话的多个问题会被合并回答#

长段落提问失效,不是因为模型不认真,而是因为连续的文字没有给出「这里有几个问题」这个结构信息。模型需要自己从中切分出待答项,这一步是有损的:相邻的两个问题会被归并成同一个主题,容易回答的那个被展开,需要实际去查证的那个被一句话概括带过。提问的人也不容易察觉,因为答案读起来是完整的。

编号去掉了这一步切分。五条编号意味着五个必须分别落地的回应,缺一条就是结构性缺失,核对一遍即可确认。段落式提问没有这个对照物,要判断回应是否完整,我得先凭记忆重建自己原本问了什么,这件事比核对编号困难得多,也更容易在答案读起来流畅时放过。一次提问的典型形态:

几个问题:
1. 测试集群上跑的是我的代码吗
2. 这个适配器还有需要修改的地方吗
3. 看完之后对比一下
4. 看看是不是还可以优化

发现漏答时,我的处理是把原问题原样贴回去:「你先回答我的问题:『……』?」原样贴回而不是重新表述,是因为重新表述会给模型一个重新解释问题的机会,而这次漏答恰恰说明上一次的解释已经出了偏差。

写不出编号,通常是还没分清要问什么#

这张检查表同时约束提问的一方。把一个复合需求拆成编号项,要求提问的人先完成一次切分:这到底是几个问题、它们之间有没有依赖、哪些只是同一个问题的不同说法。写不出编号,通常意味着自己还没分清要问什么;这种状态下拿到的答案即使完整,也无法判断是否切题。

所以这是同一条纪律的两面:对回答方它是检查表,对提问方它是一次强制的自检。它不依赖具体工具或模型,换一个对话对象同样成立。

编号保证被回应,不保证回应成立#

编号的前提是问题之间互相独立、而且我已经知道该问什么。在探索性的讨论里,需要对方先帮我划出问题空间的时候,编号会提前锁死范围,损失掉我原本想要的信息。这类场合更适合先用一个开放问题换一张地图,等轮廓清楚了再转回编号。

更需要注意的是编号能保证什么。它保证每一条都被回应,不保证回应成立——一条编号项同样可以用一句看似合理的话带过,而且因为它在形式上占了一个位置,反而更不容易引起怀疑。所以编号只是第一道检查,它之后还有两道:回应是否成立,要追问判断依据,AI 复核应当要求推翻,而不是要求确认讲的是这道检查在验证环节的做法;我自己有没有理解对,要用自己的话复述一遍交给对方核对。

三件事不要混为一谈:编号检查的是有没有回应,追问检查的是回应是否成立,复述检查的是我有没有理解对。