同样的模型别人产出就是好？拆开上下文的六个组成部分和它的工作原理，再给你六个能直接上手的管理技巧
你是不是也遇到过这种情况：看了很多 Vibe Coding 教程，用的是同一个模型、同一个工具，但别人生成的质量就是很高，而你做出来的就很简陋。
其实真正决定生成质量的，并不是你复制粘贴的那一句神奇的 Prompt 提示词，而是完整的 Context，也就是上下文。
你可能会说：上下文不就是我在输入框里打的那句话吗？
当然不是，而且差得远——你打在输入框里的那句话，可能只是很小一块儿。学会管理上下文，才算是真的会用 AI。
这一期就来讲：到底什么是上下文，怎么给 AI 提供正确的上下文，让你也能做到高质量产出。
先搞清楚一件事：你在用 Agent 工具向 AI 发指令的时候，AI 到底加载了哪些上下文？
比如让 AI 记一个文案的思路——注意看它的过程，它并不是直接把这几个字记下来，而是加载了 Skill，还看了项目规则文件、待办 TODO、之前写的其他文案等等。
也就是说，你的指令可能只有几十个字，但它实际加载的内容可能有几万字。你输入的提示词只占它加载内容的很少一部分。而它读的文件、文档、查找的网页资料、调用的工具，全都叫上下文。
举个例子：用大模型工作，就像你招了一个实习生。这个实习生特别厉害，什么都会，学得快，干活也快，但今天是他上班第一天。所谓上下文，就是你让他开始干这个活的时候，他手里拿到的全部东西。
我们一样一样看：
| # | 组成部分 | 相当于什么 | 能不能改 |
|---|---|---|---|
| 1 | 系统级提示词 | 入职时发的通用员工守则，执行任何任务都要先看一遍 | 工具自带 |
| 2 | Agent 工具配的能力 | 读文件、写文件、跑命令、打开网页，跑命令时模型会自己调用 | 工具自带 |
| 3 | 项目级的 AGENTS.md / CLAUDE.md | 当前项目的规矩，每次开始干活都会先扫一眼 | 你能改 |
| 4 | Skill | 一本本工作操作手册 | 你能改 |
| 5 | 它自行选择加载的项目文件 | 你的文档、你的代码、你以前做出来的成品 | 你能改 |
| 6 | 聊天记录 | 眼前这个对话窗口，从第一句到现在的全部内容 | 你能改 |
关于第 4 项补充一句：每次对话它只会加载所有手册的目录，真出现了目录里提到的工作，才照着目录把那一本抽出来仔细阅读。
前两项是工具自带的，剩下四项——项目规则、Skill、项目文件、对话，都是你能直接修改的上下文。
知道了上下文由什么组成，接下来还得搞清楚一件事：上下文在这个过程里到底是怎么工作的？
先说一个很多人都会误解的地方：这个 AI 其实是没有「记性」的。
什么意思？你以为跟它聊了几句，它就能记得之前的内容？真相是——每一次对话，它都要把之前看过的东西再看一遍。
你每说一句话，它都要把项目规则文件、Skill 目录、你输入的文件，再到你们从第一句到现在的全部聊天记录，从头到尾重新读一遍，然后才开始处理。每对话一次，重读一遍。
它写东西的时候，是一边翻着手里这些东西，一边参考着写的。所以同一个模型做出来的东西质量高低，就取决于它现在手里拿着什么样的上下文。
所以管理上下文，不是开场把提示词写好就完事了，而是要管理所有这些输入的内容。
那具体怎么管？下面是六个我常用的技巧。
问题： 很多人下达任务就一句话——「帮我做个什么什么」，然后就等着看结果。
做法： 不要用一句话就让它干活，而是用一个有结构的提示词。每次给任务的时候按下面四段把话讲清楚，产出质量马上就不一样。
| 段落 | 要写什么 |
|---|---|
| 背景 | 我在做什么，这东西给谁用，我手上现在已经有什么 |
| 目标 | 这一次具体要做出个什么东西 |
| 标准 | 什么样算做对了，什么是绝对不行的 |
| 参考 | 跟这件事相关的现成文件、能用的模板、以前做出来的成品 |
千万不要相信所谓「一句话就能做什么」。正确地提供聊天提示词，才是让 AI 高效工作的正确输入。
一个任务干完了，就换个新对话，再开始下一个。
为什么？ 前面刚说过，它没有记性——你每说一句话，它都要把手里的东西全部重读一遍。
所以如果你还在原来那个对话里布置新任务，它每开口一次，都得把早上那件已经做完的工作从头到尾再读一遍，而且它自己没办法控制。堆到后面注意力越来越分散，干活的状态就一路往下走。
换一个新对话，相当于把它恢复出厂设置——手里那些干完的旧工作全清空，回到巅峰状态，再接下一个任务。
比如这里让它做图文的任务做完了，我准备让它写个文案，就新开一个对话开始写文案，就这么简单。
如果你发现描述一个任务很费劲，最好的办法其实是去找一个参考，直接说：照着这个做。
给它一个成品，要比跟它描述「我想要什么样」管用得多。
原因： 参考资料是更具象化、更有信息量的上下文；而你的描述本身可能就很抽象，做出来的东西可能更抽象。
做复杂的、有产出标准的、重复的工作，用 Skill 固化下来。
举个例子：我要给它一篇文章，让它做成一整套图文。尺寸有固定要求，风格要统一，字体大小有明确规定，配图还得让生图模型自己画，整套不超过 18 张。而且细节部分怎么组织语言、怎么规划版面，都有严格的要求。
这种复杂的、有产出标准的、流程很长的任务，就应该让它总结成一个 Skill，以后每次直接按这个 Skill 去执行。
前面讲过，平时 Skill 的使用就像它手里只拿着操作手册的目录，知道哪本手册能解决什么问题就够了，真碰上了才把那一本抽出来。
所以你可以把这本操作手册写得很详细，也可以把用到的工具脚本和示范全都装进这个叫 Skill 的操作手册里。这样在调用的时候，真的只需要一句话，它就能按照这个 Skill 进行产出。
平时你看到的那些「一句话就能做出个什么东西」，很多都是背后有 Skill 在撑着，才能做到。
既然说到 Skill，它其实并不是装得越多越好。
很多人在网上看别人说这个 Skill 好，赶紧装一个；那个不错，也装上——不知不觉一个项目里装了几十个 Skill。
前面说过，每次对话它手里都拿着所有 Skill 的目录。目录本身不长，其实占不了多少地方——真正的问题是，目录越杂，它越容易抽错手册。
你明明是让它写个文案，结果它可能翻出一本剪视频的手册来参考，工作方向就被带偏了，模型的注意力也被影响。跟这个项目没关系的 Skill 装得越多，它被带偏的概率就越大。
像我的话，剪视频的项目、写文案的项目、个人站的项目是完全分开的，每个项目里面只有这个项目才会用到的 Skill，互相不干扰。
从网上下载的 Skill，很多规则、环境、要求和产出其实都不能完美匹配你的需求。那些网红 Skill 具体应该怎么使用，下期内容再跟大家详细展开。
前面五个讲的都是怎么给提示词，这一个正好反过来：有些事你不给提示词，交给它自己处理反而结果更好。
举个例子：你做 Vibe Coding，要让 AI 写一份产品需求文档 PRD。如果你自己没学过产品设计，就千万不要去教它 PRD 应该怎么写、分几个章节、每章写什么。
你直接告诉它——「写一份专业的、可以交付开发的 PRD」，出来的东西反而更好。
它本来就会的事，你非要去教，等于用你的外行水平，把它的专业水平往下拉。这也就是为什么说：模型越强，提示词越少。
那要是碰上它也不太确定的事呢？那就先让它去做调研，把情况摸清楚，再让它自己定标准往下做。
以上就是关于上下文 Context 的全部内容。最后快速回顾一下这六个技巧：
| # | 技巧 | 核心价值 |
|---|---|---|
| 1 | 用背景、目标、标准、参考四段式下任务 | 一句话的输入换来一句话的质量 |
| 2 | 一个任务，一个新窗口 | 清掉干完的旧工作，让它回到巅峰状态 |
| 3 | 用参考代替描述 | 具象的成品比抽象的描述管用 |
| 4 | 复杂重复的工作用 Skill 固化 | 以后一句话就能按标准产出 |
| 5 | 不装和项目无关的 Skill | 目录越杂越容易抽错手册 |
| 6 | 不懂就不要瞎指挥 | 别用外行水平拉低它的专业水平 |
模型是所有人共用的，谁都能用上最新最强的那个。但上下文是你提供的——你手上那些跑通过的流程、你自己定的标准、你以前做出来的成品。
这些东西才是决定产出质量的核心。模型越强，对人的能力要求就越高。