AI 3年,很多人依然用不好这个工具

前些天跟朋友聊天，他跟我分享了一件很有意思的事。

朋友做的是倒卖 Token 的生意，服务对象基本都是 B 端客户。按理说，这几年 AI 已经从最初的 Prompt Engineering 发展到 MCP、Context Engineering、Skill，再到如今最火的 Harness Engineering，行业里各种工程实践层出不穷，企业落地 AI 应该已经不是什么难事，但现实却让他有些哭笑不得。

在给客户提供服务的过程中，经常有人向他反馈AI 的效果不理想。有人抱怨编程能力不行，明明接入的是顶级模型，生成的代码却总是有问题；有人觉得指令遵循性很差，明明已经说了需求，AI 还是经常跑火车；还有人发现，把模型接入 Agent 或工作流之后，效果甚至还不如直接在官方 chatbot 里聊天。

这些问题让他挠破了脑壳，因为他的上游干净，理论上不应该出现这么多低级故障。于是他开始查日志、看调用记录、咨询同行，连续折腾了好几天，结果最后发现问题根本不在模型身上。

那些抱怨编程效果不好的客户，使用的并不是模型官方提供的 Coding Agent，而是各种第三方皮包工具。那些抱怨指令遵循差的客户，他们家的程序员发给 AI 的指令只有一句话：“帮我修一下这个 Bug。”

至于那些接入 Agent 或工作流的客户情况也差不多，他们只是简单地把 API 接进去，然后就等着巴啦啦小魔仙自动“变变变”。既没有围绕具体业务场景设计 Prompt，也没有定义任务流程、上下文结构和验收标准，更谈不上什么 Context Engineering 或 Harness Engineering。

朋友知道原因之后差点被逗乐了，他原本以为自己遇到了什么复杂的模型问题，结果查来查去，最后发现居然是两三年前 Prompt Engineering 时代就已经讨论过的问题。最后实在没办法，他只能专门录了几个教学视频发给客户，教他们如何正确地向 AI 提问题。

这个故事多少有些颠覆我对国内“AI 落地”现状的刻板印象。过去几年，自媒体几乎把 AI 炒成了硅基菩萨。AI 程序员、AI 员工、AI 创业者、AI 公司，各种概念层出不穷。很多宣传内容都在疯狂暗示人们只要接入 AI，再复杂工作都能心想事成。

但朋友遇到的问题却告诉我，很多企业甚至还停留在两年前最基础的阶段。

我无意深挖这种“事实”背后的原因，也懒得再嘴臭那些不说人话的自媒体，只想大概讲讲“如何正确使用 AI”这件事。

要用好 AI ，就必须要对大语言模型这种工具的能力边界有足够的了解。我们现在讨论的 AI ，指的就是大语言模型这种技术，而不是想象中某种无所不能的人工智能或硅基生命体。Anthropic 虽然一天到晚发布“LLM 要拥有自我进化能力”这种狼来了的营销报告，但事实还离着十万八千里。而只要是工具就必然有它的局限性。

言简意赅，第一点，AI 没有记忆。

大模型并不像人类一样拥有持续、稳定、长期存在的记忆，它能够知道什么，取决于当前上下文里有什么。你关闭一个对话窗口，再开启一个新会话，它通常就不记得你是谁，也不记得你之前聊过什么。即便一些产品提供了所谓的“记忆功能”，也只是把部分历史信息存储下来，然后在合适的时候重新塞回上下文。

在一些 Agent 里，用户每次发给 AI 的指令，不仅包含用户当前的指令，还包括当前对话窗口中的所有信息，和系统内知识库、记忆系统、环境信息、repo搜索等一系列方法获得的，与当前指令相关性较高的信息。

因此，很多用户发现，昨天明明告诉过 AI 的事情，今天为什么又忘了？因为它本来就是脑袋空空的黑箱，每次用都要重新填充信息。

第二点，AI 依然会产生幻觉。

人的记忆是短暂的，很多人经过自媒体洗脑，早就已经把 3 年前被 AI 骗得裤衩子都没了的经历忘得一干二净。

大语言模型的本质，是一套黑箱作业的概率预测系统。它的每一次生成，都是基于相关性，预测更贴近正确答案的信息。它最擅长的是“一本正经地胡说八道”，只不过因为技术迭代到现在，逼近正确答案的能力越来越强，让人以为它生成的都是事实。

其实连 AI 本身都不知道什么是事实，它又怎么可能生成事实呢？

“只要鸡蛋好吃，就不要纠结是哪只鸡生下来的。”我们在使用 AI 时，主要基于实用性考虑，只要它给的结果有用，一般会忽略它生成结果的机制。但不代表我们可以交托所有信任，全盘接受它的生成结果。

第三点，是上下文过长带来的注意力漂移。

这是一个当上下文过长，AI 会遗忘前面信息的现象。虽然这几年各家厂商都在卷上下文长度，但上下文长度和注意力质量是两码事。AI 能读取越来越多的内容，并不意味着它能始终把注意力放在重要信息上。

很多人应该都被坑过，跟 AI 刚开始的几轮对话效果很好，越聊到后面越发现它会胡编乱造。明明前面已经高屋建瓴、调度指挥下达过各种底线、前瞻、命令、指示，到后面它总是会丢三落四把越来越多的要求抛诸脑后。甚至如果任务比较复杂，变更比较多，还会出现目标飘逸、重点错位、信息混淆等问题。很多 Agent 做项目做到后面越来越不稳定就是这个原因，上下文越长，不代表注意力越集中。

唠唠叨叨一大堆不好听的，接下来讲讲通用的抽象方法，如何用好 AI 。

我在一年前写过一些如何用好 AI 的方法，有兴趣的可以翻这个合集，看的时候请忽略叙利亚排版：

归纳下来其实就 3 点：澄清问题、定义约束条件、设计验收标准。问题决定方向，条件决定边界，验收标准决定结果。

澄清问题，意思是你需要提出具体的问题。

举例来说，你口渴了希望老相好帮你拿杯水，你可以说“我渴了”。对于老相好来说是具体的问题，因为你们之前肯定进行过无数次类似的对话，他知道你说这句话的意思是帮你拿杯水过来，甚至他知道你的喜好，拿给你之前还会给你放冰块，插上一片柠檬片。

但对于 AI 来说“我渴了”不是问题，而是你的状态。它对从你这句话里获得的信息是你口渴了，然后就没有然后了。

所以你不能用跟自然人说话的方式跟 AI 说话，你需要明确告诉它你的需求，把你的问题澄清为具体的要求。所以你要说“我需要你现在帮我拿杯水过来给我，水里加 3 块冰块，杯口插上一篇 2 mm厚的柠檬片”。

同样的，你也不能跟 AI 说“帮我修一下这个bug”，你要告诉它在哪个页面、或哪个服务，在运行时出现什么样的报错信息。

定义约束条件，就是告诉 AI 你有什么工具或它有什么工具解决问题。

回到口渴问题，AI 帮你拿水之前，并不知道你家的水壶在哪里，不知道冰块在哪里，更不知道 2 mm的柠檬片在哪里。所以你同时要告诉它，水壶在厨房里，厨房是出门左转第三个房间；冰块在冰箱里，冰箱在厨房里；柠檬片在储物柜里，储物柜在客厅里，客厅在出门右边第一个房间。

在一些 Agent 里，这些约束条件是 terminal 信息，是代码依赖，是 worktree 等等。但是如果你用 Chatbot 而不是 Agent ，最好把这些信息和你的问题一并提供给它。

设计验收标准，就是明确你希望得到一个什么样的结果。

在口渴问题里其实已经提到了这点，冰水、柠檬片都是你的验收标准。其余问题也类似，“修复这个bug”的验收标准是“运行时不再出现报错信息”。

如果你要求 AI 帮你写一篇营销方案，这种相对较复杂、又缺乏计算机环境约束的任务，需要你明确定义这篇营销方案的具体验收标准。你的方案长度是多少？要覆盖什么模块？方案里是否需要包含人财物预算？有哪些必要元素需要出现在方案里？是否需要插入成功案例？

验收标准越明确，AI 的输出越容易被判断，也越容易被修正。否则你就等着它给你灌一堆垃圾信息吧，词不达意都是轻的，用火箭发动机帮你拉马车也不是什么奇怪的事。

只要把最基本的这三件事做好，即使不用什么复杂的提示词技巧，AI 的输出结果通常也不会差。

另外，如果你想知道更具体的实操方法，可以看这篇文章：

AI 3年，模型越来越强，上下文越来越长，Agent 越来越复杂，但很多人遇到的问题和 3 年前没有什么两样。很多人其实并不缺各种 AI 使用的奇技淫巧，只是一时没转过弯来，被各种硅基神教自媒体污染了信息环境，以为 AI 真是什么必须有求必应的技术。

其实它只是一个更好用的工具，古惑仔用扳手收大耳窿，机械工程师能用扳手拧螺丝，同样的工具在不同人的理解里有不同的作用，但关键依然是使用工具的方法。古惑仔要知道把扳手抡起来，工程师也需要知道要把螺丝夹紧。

无论你用 AI 解决何种问题，了解工具的特性永远是最重要的第一步。

我是orangeburn，一个什么都懂一点的流浪产品经理，喜欢研究商业、科技应用和AI。

无热点，不焦虑，只希望能为你提供看待问题的另一个视角。

如果你喜欢我的文章，欢迎点赞转发，或关注我的公众号支持我。

你们的支持对我非常重要。

也欢迎在评论区留下你的看法。