同样的 AI，差距为何这么大？

一个真实的案例。

在操作系统发行版管理平台上，想增加一个对某一个产品的所有软件信息一键导出csv功能。

同事 A 让 AI 写一个导出功能，输入只有一句：

帮我在产品页面上添加一个导出功能

AI 很勤快，路由、控制器、Service、DTO、工具类全生成了一遍。看起来工作量不小，问题也不少：字段对不上，格式不是 CSV，分页没处理，还顺手改了已有接口。A 修了两个小时，这里按下去、那里翘起来。最后得出结论：“这东西不太行。”

同事 B用AI比较多，让帮忙指导一下。 B直接回退了修改，然后改了一版任务说明：

在 ReportController 里加一个 CSV 导出接口。
参考 UserController 的分页查询模式，调用 ReportService.queryReports 获取数据。
导出字段：日期、类型、金额、备注。
不要改 Service 层，不要改已有接口签名。
在数据看板页面顶部操作栏添加“导出”按钮，通过上述接口实现 CSV 文件导出。
完成后请编译、运行相关测试；如果项目里接了浏览器调试 MCP，请验证按钮点击和文件下载正常。

这一次，AI 的改动范围明显收敛，结果也靠谱了不少，简单微调后就跑通了业务。

世界，有时候就是这么区别对待！

你打个响指，啪一声；Tony 老师打个响指，飞来一套 Mark 3 动力装甲...

为了像Tony老师那样驾驭AI，得先学会和AI对话，让它懂得 啪一声 的含义！

AI 的思考方式

知己知彼，方能百战不殆。

为了驯服AI，得先摸清AI的脾气秉性。首先，要了解AI 的思考方式。

说起 "AI 的思考方式"...

呃，我想说的是，鬼知道... 什么深度学习，什么神经网络，什么卷积积分 我一个都没学过...

不过，听说， 神经网络模型，就是模拟的人的思考方式。

可以看看下面几个问题，直观感受一下...

（1）你的第一直觉，KF 是什么的缩写？

我问了办公室30个人

• 主要集中在 咖啡（最常见，最保险的答案，有9个），开发（毕竟是软件团队，有5个）, 开...呃，看房（有4个，如果用测谎仪，我敢打赌有15个人以上）
• 其他符合的词有：客服, 开封，卡费，开服, 扣分等
• 还有一些莫名其妙的： 肯德基，付费， 科幻， 挎包,空调

(2) 如果你现在医院，纸上写着 KF， 那可能是什么意思？

同样30个人， 空腹得分12， 康复得分11， 口服得分6， 还有一个是客房

(3) 医生开了一瓶药，贴了一个便签，上面写着 "外涂，不可 KF"， 这个KF 可能是什么意思？

毫无意外，大家都回答的是 口服。

你看，同样是 KF 两个字母：呃，看房，咖啡是大家生活中接触最多，因此在无限定场景下，是首选；但，扔给一群程序员，他们脑子里 开发 个词的权重就蹭蹭往上飙，虽然这并不是一个非常大众化的词汇；限定到医院场景里，空腹、康复 、口服就成了鼎立之势；再加上 外涂的参照，就只剩一个 口服 的选项了。

大模型骨子里就是这么一回事。它没有真正的脑子，只有几万亿个参数，每一个参数都在说："根据我训练过的数据，接下来这个词出现的概率大概是 0.009527%..."。 它就像一个读过全网所有文档的超强赌徒，永远在赌下一个字最可能是什么。

这带来了两个关键认知：

第一，它天生就有随机性。 你问它同一句话两次，它可能在"咖啡"和"呃，看房"之间犹豫，一次选了前者，一次选了后者。这就是为什么你跟 deepseek 聊同一个话题，它每次给的东西都像七大姑八大姨聊村里的时事：主旨大差不差，细节千奇百怪。行话叫"采样温度"（Temperature），感受就是：你永远不知道它这次是喝了咖啡还是喝了假酒。

第二，极度依赖语境。 KF 本身毫无意义，但只要加上"医院"、"外涂"，它就从一个无意义的字母串，变成了大概率指向"口服"的明确信号。你喂给模型的每一个词，都在悄悄改变它大脑里所有词语的概率分布， 我们将这些词称叫"提示词（Prompt）"。它们是给模型一个指导作用，让模型通过更多的上下文进行关联，从而更了解你的意图。
提示词多一点少一点，结果可能天差地别——就像你把"医院场景"换成"咖啡馆场景"，KF 瞬间从空腹变成了咖啡。

so， AI 的思考方式，就是像游戏 你比它猜： 你给它更多、更有价值的提示（更清晰、更明确的提示词），它给你一个 更靠谱 的答案！

AI的记忆缺陷

AI就像刚得了老年痴呆的超级社会学家： 对世界的方方面面都了解，唯独对刚刚发生过的事情没有任何记忆。

你可以和它聊编程，聊天文，聊母猪的产后护理，它都可以如数家珍，说得头头是道。

但给它说，“昨天在页面上添加的导出功能有点问题，帮我修复一下”。

这次它没有立刻回答，而是把工程中的文件挨个读了一遍，然后弱弱的问了一句 "项目中有错误报告导出，软件CVE报告导出，风险报告导出，你说的是哪一个？”

AI大模型的“金鱼记忆”：无状态 API

AI 模型本身没有 “昨天” 这个概念。每一次你按下回车键，都是一次全新的、独立的计算。

我们之所以感觉AI在“连贯聊天”，其实是应用层（Agent， 如ChatGPT网页版、Cursor等工具）在背后默默做了一个“抄笔记”的动作。

比如，你跟AI聊天 ，你发了第一句：

KF 最可能是什么的缩写？

大模型回你：

可能是咖啡、开发或其他词汇。

你发第二句：

呃，是不是看房？

此时，AI应用并不只是把这句 "呃，是不是看房？"发给模型，而是把之前的问答内容都发给大模型。如果将模型交互的原数据打出来，可能长这样：

{
"model": "deepseek-chat",
"messages": [
    { "role": "system", "content": "你是一个AI助手" },
    { "role": "user", "content": "KF 最可能是什么的缩写？" },
    { "role": "assistant", "content": "可能是咖啡、开发或其他词汇。" },
    { "role": "user", "content": "呃，是不是看房？" }
],
"temperature": 0.7
}

AI应用程序会在你看不见的地方，把你刚才说的第1句话、AI的回答，连同现在的第2句话，打包成一个巨大的“剧本”，重新塞给AI。

这个剧本，就是上下文（Context）。 也是AI 大模型的 金鱼记忆。

不幸的是，这个 上下文 的长度是非常有限的。

现在主流模型如 GPT-5.5 、ops-4.7、Deepseek-v4.0 上下文长度为 1M Tokens，而GLM-5.1 及很多相对老一点的模型通常仅有200K Tokens。

Token 就是大模型“识字”的基本单位，可以认为一个中文字、一个英文单词、一个数字、一个标点符号都被视作一个 Token。

一旦上下文超出了模型的“视野”极限（即上下文窗口），最早的那部分对话就会被残忍地截断、遗忘。于是AI的痴呆症就犯了，开始前后错乱，胡言乱语...

Agent的“暂存记忆”：Session 机制

为了缓解AI大模型 金鱼记忆 症状，AI工具（Agent）会为每一次对话做一个记忆账本，称为 Session。

可以把 Session 理解为给这段临时关系开了一个档案记录。将你发给AI的每一个问题，以及AI的应答都记录下来，作为下一次对话的全部内容统一投递给AI。比如刚才报了什么错、你否决了哪个方案、确定了哪个字段名——都被暂存在里面。它能基于这份档案灵活读写，给你“它越来越懂你”的感觉。

首先于大模型的上下文长度限制， 这个档案记录的长度也必然是有限的。 一旦这个档案记录的长度超过模型能处理的长度限制，Agent就不得不截断 或者压缩档案。于是又会出现信息失真，细节丢失，前后失调的问题。

另一方面，Session终究是“暂存”的。
一旦你关掉窗口去吃了个饭，或者在其他工程做同样的事情，基于Session 里的记忆就全丢了.....

工程思维的“永久纹身”：Rules 与 Readme

记忆缺失是痛苦的！

像印度经典复仇片《未知死亡》里的主人公桑杰 —— 他头部受创，每15分钟记忆就会被清空一次。为了复仇，他把仇人的名字、爱人的遭遇，以及一步步的行动计划，用针一针一针地刺在自己的身体上。每当他神志恢复、低头看到那些刺青，就立刻重新知道了自己是谁、要找谁复仇、下一步该做什么。这具肉身，就是他不灭的备忘录。

既然 AI的记忆缺陷与生俱来，那真正的高手就要学会把 "复仇计划" 纹在 AI 随时能看到的地方。

这就是工程上下文的力量——这是最高级的记忆术，把会话级的记忆缺陷，转变成项目级的永久规则。

agent.md（或 claude.md）在里面用自然语言写下铁律：“永远使用 Vue 3 组合式 API”、“禁止修改 /core 下的基础库”、“数据请求统一用 useRequest 封装”。每次 AI 执行任务时，工具会把这个纹身直接注入它的提示词里。AI 不再需要记忆，因为它睁眼就能看见这些 “出厂设置”。

readme.md：这是项目的藏宝图。它告诉 AI 项目是干什么的、怎么启动、目录结构是什么鬼。如果不挂载这个，AI 连你用的是 React 还是 Vue 都不知道，开局全靠猜。

早期的玩家需要手动把这些路径写到提示词里，比如“请参考 readme.md 的结构”，但这很费劲，且一旦脱离当前对话，记忆就又没了。

而现在，像 opencode 这些Agent工具已经进化出了自动上下文承接能力。当你 @ 一个文件，或者在 Agent 模式下，它会自动去读取项目根目录的规则文件、最近的代码改动、甚至报错信息。它把“记忆”变成了“条件反射”——不用你每次长篇大论，它自己会去翻看你们共同约定的“账本”。

如何与AI对话？

前面啰嗦了这么多，无非让大家明白：

• AI对问题理解和处理时的不确定性是刻在基因里的。你必须提供必要、准确、足够的信息，它才能较为准确的理解你的意图，然后做恰当的执行。
• AI的记忆缺陷是与生俱来的。你必须学会用好会话级记忆，工程级记忆，尽量把事情控制在一个会话上下文能够解决的程度。

基于这两个关键限制，我们在与AI对话时，需要采用一些技巧。为此，我冲了 10块钱的 deepseek 的会员，用专家模型+深度搜索，郑重问了这个问题：

如何给AI描述任务，使得AI能够更好的理解意图，并做好执行和交付？

deepseek这样说：我把这套方法总结为 “补记忆、定边界、给范式、设质检” 四步法。

第一步：补记忆 —— 默认AI已失忆，主动注入上下文

默认，AI对本次会话之外的事情一无所知。所以每次下达任务，都要像电影《未知死亡》里的桑杰一样，把自己需要的信息全部“纹”出来。

不要这么说：

"帮我加个导出功能。"

而要这么说：

"参考 UserController 的分页查询模式，在 ReportController 里加一个CSV导出接口。调用 ReportService.queryReports 来拿数据。"

实战技巧：

• 明确引用对象：直接告诉AI去看哪个文件、哪个函数。用 @文件名 或直接在对话里贴关键代码片段。
• 注入项目常识：在对话开头或 agent.md 里声明技术栈、关键约定，比如"本项目使用 Vue 3 + TypeScript，状态管理用 Pinia"。
• 复现现场环境：遇到 Bug 时，别只说“修一下”，而是把报错信息、相关日志、甚至截图直接喂给它，这就是在帮AI快速"读取你的记忆"。

第二步：定边界——给AI画地为牢

AI能力很强，所以破坏力也很强。你必须明确告诉它：什么是你该做的，什么千万别碰。
像文章开头同事 A 的失败案例，就是因为他没有划定边界，导致AI顺手改了已有接口和 Service 层。

实战技巧：

• 使用否定句式建立“安全区”：

• “不要修改 Service 层的任何文件。”
• “不要改变现有接口的签名。”
• “只允许修改 src/views/report 目录下的文件。”
• “不要引入新的第三方库。”

• 明确修改范围：

• "这是一个仅限前端的改动，后端接口已就绪。"
• "你的任务是集成，不是重写。尽量复用 utils/request.ts 中的现有方法。"

定边界就像孙悟空给唐僧画的圈，在这个圈里你可以尽情发挥，但有妖魔鬼怪要进来，你也别出去惹事。

第三步：给范式——好的规范胜过千言万语

AI最擅长模仿。与其用一长段抽象的话描述风格，不如直接丢给它一个“参考答案”。
这就是我们之前说的上下文的力量——一个具体的例子，能瞬间让AI脑子里的概率分布指向你想要的风格。

实战技巧：

• 引用已有代码样本（这点在上一讲上下文原理中已验证过）：

• “新接口的权限校验逻辑，请完全参照 OrderController.checkAuth 的实现方式。”
• “按钮样式请使用和页面上'新建'按钮一样的 <primarybutton> 组件。”
• "生成的测试用例，结构模仿 OrderService.test.ts。"

• 直接贴出理想输出格式：

• 如果希望它导出某个格式的CSV，直接贴出表头："日期, 类型, 金额, 备注"。
• 如果希望它写文档，就给它一个你满意的历史文档作为范例。

第四步：设质检——让AI自验证、自交付

这是从“能跑就行”到“生产级交付”的关键一跃。不要等AI把活儿干完你再手动去查去测，要把“质检标准”直接写进任务里。

这一步是压倒文章开头同事A的最后一根稻草——他的交付物没有被验证，坑全留给了自己。

实战技巧（直接要求可交付的具体动作）：

• 要求编译检查： “完成后请编译项目，确保没有TypeScript类型错误。”
• 要求运行测试： “为新增的导出方法编写单元测试，并运行 npm run test，保证全部通过。”
• 要求自验证（如果有MCP工具加持）： “如果项目里接了浏览器调试 MCP，请验证按钮点击和文件下载正常。”
• 附加交付清单： "最后，请列出你修改了哪几个文件，以及每个文件修改的要旨。"（这可以逼着AI自我审视一遍，也方便你人工快速Review。）

写再最后

看了上面的条条框框，你是不是又犯嘀咕：这糟老头子坏得很！ 这看着比我自己撸代码还麻烦，也好意思拿出来讲...

呃，想要把AI用好，确实也不是有手就行的事儿.....

好在，开源社区已经帮我们做了很多工作，出了很多具备工程化实践的工具和方法论，能够极大的简化、规范我们与AI的交互。

我们下一课接着聊如何用openspec skill 让AI按章办事！