我最近用 AI 写了一个导出 Gemini 聊天记录的插件，我把 Gemini 网页的源码粘贴给它之后，告诉它要把网页中的聊天记录导出成 markdown，然后它很快就写完了。但我测试后发现它导出的聊天记录没有保留 markdown 格式，于是提醒它要保留 markdown 格式，比如标题和列表，它照做了。结果它只处理标题和列表，表格、链接什么的都给丢了。这时我就知道问题出在哪里了，它只是照办我的指令，因为我只提到了标题和列表，我的本意是想保留所有的 markdown 格式，可是谁能把所有格式一个个说全呢？我期望它通过我的两个例子能理解我真正的意思，但失败了。
为什么 AI 听不懂我的话？有人可能会想：“你 prompt 写的不清晰呗，你要说必须尽可能完整地保留所有的原始格式”。我当时也是这么想的，结果就是它只把我给它的示例页面中的 HTML 格式都保留了，换个页面还是有遗漏的格式没处理。我才明白，问题可能不在于我没说清楚，而是这个要求本身，对 AI 来说太难了。难道 AI 是太菜了吗？
关键在于换一个问法。AI 其实一直都在遵循我的指令，它确实保留了所有的页面格式，问题在于，我给它的例子里，并没有包含所有的格式。所以问题就变成了：到底要怎么给 AI 足够的信息？
有人可能会说，那你把包含了所有 HTML 格式的网页都提供它就行了呀。这个建议听起来不错，但一想到具体要怎么做，就发现全是坑。我上哪里找包含了所有 HTML 格式的网页？假设我真找到了，那 AI 实现这么多种格式转换的函数能保证兼容性吗？那我是不是还要找一下 HTML 转 markdown 的规范文档给它？这么多内容提供给 AI，它的上下文窗口够用吗？要是真的顺着这个思路搞下去，问题只会越来越多，可能你的 Cursor 会员额度用完了都搞不定。我猜，大部分没编程经验的新手估计都是这么卡住的。
那我们换个思路，回到没有 AI 的时候，一个程序员会怎么解决这个问题：核心的诉求是要把网页的所有格式都转换成对应的 markdown 格式，我去看看别人是怎么做的，用的是什么库。搜索“HTML 转 markdown js 库”，找到“Turndown”，然后调用这个库，问题解决。
你看，这就是程序员解决问题的思路。主要就两点：“这事儿别人做过没？”，以及“有没有现成的轮子可以用？”。这就是软件工程的哲学：不要重复发明轮子。你想象一下，一个现成的库（轮子），是无数人踩过坑、优化过的精华。它的信息密度极高。而我们用自然语言提的需求呢？信息不全，还容易有歧义。让 AI 用现成的轮子，和让它从零根据你的描述造一个，这难度根本不是一个级别的。
同样是给 AI 提供上下文，有人想把所有相关的网页都喂给它，烧了十几万 token 问题还是没搞定，有人用一句：搜索“HTML 转 markdown js 库”就轻松解决了问题。区别就在于你是不是学到了软件工程的精髓。所以下一次你发现 AI 听不懂你的话时，先不要着急优化你的描述，而是问自己：这个问题是不是已经有“轮子”了？我应该如何引导 AI 找到它？当你开始这么想的时候，你就不再是只是一个 AI 的“用户”，而更像一个“架构师”了。你不是在提需求，而是在指挥 AI 去找到最好的解决方案。这可能才是 AI 时代，我们最值钱的能力。