为什么你用 AI 调代码总感觉在绕圈子？其实是你没找到那个关键术语

很多开发者在用 AI 解决复杂技术问题时，经常会陷入一种诡异的循环：你描述了问题，AI 给了几个看起来很专业的方案，但你试完之后发现全不对。然后你继续修正描述，AI 继续给方案，直到你绝望地意识到，其实根本不是模型写不出代码，而是你压根没问对问题。

我最近在处理一个连号模拟线路的协议解析，被卡了整整三天。最讽刺的是，最后解决问题的那个瞬间，并不是因为我给 AI 喂了更复杂的 Prompt，而是我终于在硬件手册里翻到了两个词：FXO 和 FXS。

这两个词代表了模拟电话接口的两端。在我没提到这两个词之前，我描述的是“电话线对接问题”，AI 给我推的是 SIP 库、软交换、音频路由。从技术逻辑上看，这些答案全部正确且合理，但对我当下的具体场景来说，它们全是废话。一旦我把 FXO 和 FXS 这两个精准的术语丢进对话框，整个问题的维度瞬间被重写，答案当场就对了。

这件事让我意识到一个残酷的真相：AI 能够提供海量的知识，但它无法替你补齐知识之间的“接缝”。所谓的接缝，就是那些你没听过、但恰好命中要害的专业术语。AI 不会教你那些你完全不知道的东西，它只能帮你完成那些你“半懂”的事。如果你的描述精度不够，AI 给你的是一个概率分布上的“中间答案”，而这个答案往往在正确方向的边缘徘徊，却永远无法击中靶心。

为了解决这个问题，我给自己设计了一套提示词框架，核心逻辑是强迫模型在给出方案前，先暴露我的“认知盲区”。你可以尝试把这段话发给它：

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

【问题描述】
（这里详细写你遇到的具体问题）

这套框架的精妙之处在于，它禁止 AI 直接跳到“解决方案”这一步，而是强迫它扮演一个“知识地图引导员”。它会告诉你：在这个领域里，可能存在某个你不知道的专业名词，而这个名词才是解题的钥匙。

当然，在依赖 AI 提升效率的同时，开发者必须建立一套关于“爆炸半径”的判断逻辑。我之前有个教训：把树莓派的 shell 权限交给模型去跑，结果在处理 coreutils 相关操作时直接导致系统崩溃。虽然损失一台开发板无所谓，但它揭示了一个关键点：在 diff 对比中，修改日志文件的 20 行代码和修改设备控制器的 20 行代码看起来没有任何区别，但在生产环境下，两者的风险等级完全不同。这种对风险边界的把控，目前依然必须由人类工程师独立完成。

最后分享一个我的实用技巧。现在 AI 生成代码的速度太快，而人类阅读和验证的速度太慢，这导致了严重的认知不对等。为了缓解这个问题，我写了一个自用 skill，要求模型在每次执行代码改动后，必须用自然语言汇报具体的调用路径和时间复杂度，我只审核报告，不直接读源码。虽然这相当于把验证工作交给了生成者本身，存在一定的逻辑闭环风险，但在极高频的迭代中，这种权衡能极大提升我的心智带宽。