知识变便宜了，但知识之间的接缝没有——一个把问题描述到位的提示词

先说结论：AI给的答案质量，取决于你描述问题的精度，而精度往往来自一个你没听过但恰好命中要害的术语。 我管这叫「接缝」——两坨知识之间的连接处，AI不会替你补。

分享一下我最近一直在用的提示词框架，效果立竿见影：

你把下面的【问题描述】拆一遍：
- 先列出问题涉及的技术域（比如电信、硬件、网络协议）
- 再列出你判断中可能缺失的关键术语——尤其是那种"一旦知道了，整个问题描述都会被重写"的术语
- 最后给出 3 个"我需要先去查明白什么"的建议，而不是直接给解决方案

【问题描述】
（这里写你遇到的问题，越详细越好）

为什么这个有用？因为它强迫模型先暴露你的"半懂"，再动手写答案。我踩过最大的坑就是——AI给你的是中间答案，直到你缩小范围。我原来描述电话线对接问题，给的回应都是SIP库、软交换、音频路由，全都合理但全都没用。直到自己去翻了硬件手册，找到FXO和FXS这两个词——模拟电话接口的两端——整个问题立刻被重写，答案当场变了。

模型没变，变的是我终于拿到了指向问题的那个词。AI不会教你不知道的东西，它只会帮你完成半懂的事，那半懂还得你自己来填。

顺手的踩坑记录：把树莓派的shell交给模型跑，它一路正常，碰到coreutils直接崩没了。损失一台玩具板子无所谓，但暴露了一个关键判断逻辑——我的底线不是"某些代码永远不让AI碰"，而是爆炸半径。改日志的二十行和碰设备控制器的二十行，在diff里看起来一模一样，但在生产环境里是两种完全不同的东西。这个判断，得你自己做。

还有个变通：生成太快、人读太慢，差距越来越大。我搞了个自用的skills，让模型把每次改动跑一遍后用人话汇报调用路径和复杂度，我只看报告不看源码。老实说，等于是把验证交给和生成同一个系统的AI——这是真实的弱点，但我选了这个权衡。