上一章结尾留了个尾巴：你坐在方向盘后面，知道要去哪，也知道副驾驶靠谱在哪不靠谱在哪——那接下来，怎么把「要去哪、路上有哪些坑」准确地说给它听？这就是本章要拆的手艺。它听起来平平无奇，却是整条链子上最容易被人偷懒、也最直接决定成败的一环。
先记住一句话，本章其余全是它的展开：AI 输出的质量，有一个天花板，这个天花板不是它有多聪明，而是你把问题描述得有多清楚。你喂进去的东西封顶了它能吐出来的东西。
老话新说：垃圾进，垃圾出
计算机行业有句祖训。
GIGO：输入是垃圾，输出必然是垃圾（Garbage In, Garbage Out）。
意思是：机器不会替你把烂输入变好。你给它一堆脏数据，它算得再快，算出来的也是一堆脏结果，而且算得又快又理直气壮。机器只负责忠实地加工，不负责替你把关。
过去这句话说的是数据脏——你拿一张填错了一半的表去做统计，统计结论当然是错的，怪不得统计软件。到了 AI 时代，这句老话升了个级，说的不再只是数据，而是你那句话本身：你把问题描述得多含糊、漏掉了多少必要的背景，AI 就以同样的含糊程度、加上它自己的脑补，还给你一坨看着体面、其实跑偏的东西。
而且——接着上一章那个更阴险的点——AI 时代的垃圾输出，是穿着西装的垃圾：格式工整、注释齐全，你一眼看不出它其实解错了题。所以这一环偷的懒，藏得特别深，往往要等上线出事才浮出来。
同一个请求，两种说法，两个世界
空讲没用，上例子。假设你想让 AI 帮你优化一段代码。
第一种说法，你八成也这么说过：
「帮我优化一下这段代码。」
AI 会怎么办？它不知道你说的「优化」是指哪个方向——是要更快、更省内存、更好读、还是更少 bug？这四个目标常常互相打架（为了快，可能要牺牲可读性）。它也不知道这段代码跑在哪、瓶颈在哪、什么东西碰不得。于是它只能按「全世界最常见的优化长什么样」给你猜一个，顺手把你的变量名改了、把你依赖的某个副作用给「清理」掉了，代码是漂亮了，一上线业务逻辑错了。
第二种说法，同一段代码，你换成这样：
「这个函数在每次用户刷新页面时被调用，现在单次要跑 800 毫秒，太慢了。目标是压到 100 毫秒以内。它跑在浏览器里，数据量大概一万条。不能动的是它的函数签名和返回结构，上游有十几个地方在调它。我怀疑瓶颈在那个双重循环。我已经试过加缓存，但数据每次都变，缓存没用。给我几个思路，别改我的其它函数。」
你自己读一遍这两段，就知道它俩会得到天差地别的结果，根本不用我解释。第二段里，AI 的猜测空间被你压得很小——方向定死了（要快，不是要好看），红线画死了（签名别动），战场标出来了（那个双重循环），死胡同排除了（缓存试过没用）。它剩下要做的，几乎只是在你圈定的这一小块地里找解法。你不是在「求」它，你是在给它铺一条只能通向正确答案的窄路。
「上下文」到底指哪些东西
第二段之所以好，是因为它带上了上下文。
上下文就是「这件事的现场情况」——环绕着问题本身的那一圈背景信息。同一句「优化代码」，在你的现场和在别人的现场，正确解法可能完全相反，区别全在这圈背景里。
这个词太容易被说空。我把它拆成五样具体的、你能照着填的东西，你可以当成一张检查清单：
- 目标：你到底要什么？不是「优化」，是「从 800 毫秒压到 100 毫秒以内」。目标必须是能拿尺子量的，含糊的目标等于没说。
- 约束：什么东西不能动？跑在什么环境里（浏览器还是服务器、多大内存、什么版本）？这条最常被漏掉，而它恰恰是 AI 最不可能猜对的——因为约束来自你们家这摊事的特殊处境。
- 已有的坑：这地方有哪些已知的雷？「这段历史代码没人敢删」「这个接口偶尔会返回 null」。你不说，AI 就会一脚踩上去。
- 你试过什么：哪些路走过发现是死胡同？不说，AI 大概率把你已经试过失败的方案又给你推荐一遍，你俩一起原地打转。
- 什么算成功：怎么验证这活儿干成了？「刷新页面时这个函数不超过 100 毫秒，且十几个上游调用点行为不变」。有了这条，AI（和你自己）才知道什么时候该停手。
这五样不是让你每次都写满一大篇。而是当结果不对劲时，你回头一看，多半是这五样里漏了某一样——补上那一样，结果立刻就顺了。它是一张排错清单，不是作文模板。
为什么这活儿必须是人来干，AI 替不了
你可能会想：既然上下文这么重要，那能不能让 AI 自己去把上下文补全？这里有个绕不过去的坎，也是本章的题眼：
AI 知道的是全世界的平均情况，只有你知道现场的真实处境。
这两样东西的差别，是天堑。AI 读遍了全世界的公开代码，它知道「一般来说」优化这类函数该怎么做——这叫平均情况。但它不知道你这个函数的返回结构被十几个地方依赖着、不知道你上周刚被这段代码坑过、不知道你老板下周就要上线所以「先能用」比「最优雅」更重要。这些信息从来没进过它的训练数据，因为它们只活在你的现场，活在此时此地这一个具体的摊子里。
打个比方。AI 像一个读过全世界所有旅游攻略的向导，哪条路一般怎么走它门儿清。但你脚下这条路今天塌方了、这座桥限重、你还带着个走不快的老人——这些「此时此地」的实况，攻略里没有，只有站在现场的你看得见。向导给的是通用最优，你要的是此地可行。
所以补全上下文这件事，天然只能由人来做，而且只能由身处现场的那个人来做。这不是 AI 不够强的临时问题，是信息在源头上就只存在于你这儿，不在它那儿。你越是那个最懂现场的人，你在这一环就越不可替代。
掌舵：定义问题的人，握着方向盘
把这一章收束到全书那根主线上。
一辆车，AI 是发动机——马力大得吓人，一脚油门能把你送出很远。但发动机不决定车往哪开。决定方向的，是那个把目的地、把路况、把「哪条路不能走」输进导航的人。你给的问题和上下文，就是这台导航的输入。输入一个模糊的目的地，再强的马力也只是把你飞快地送到错误的地方——错得还特别高效。
这就是为什么本章的手艺，看着像「怎么把话说清楚」这种小事，实则是掌舵。谁定义问题、谁提供上下文，谁就握着方向盘；AI 只是那台听话的、强悍的、但自己不知道要去哪的动力。它跑得越快，方向盘在谁手里就越是生死攸关——方向对，它十倍地帮你；方向错，它十倍地帮你翻车。
所以下次你张嘴（或者动手打字）之前，停三秒，别只丢一句「帮我搞定这个」。花一分钟，把目标、约束、坑、试过什么、什么算成功，哪怕只补上最关键的一两条，递过去。这一分钟，是你从「乘客」坐回「驾驶座」的那一分钟。写代码的手在贬值，但定义问题、说清现场的这颗脑子——它握着方向盘，而方向盘，从来不会因为发动机变强而贬值，只会更值钱。