与AI合作：从 Know-How，到 Know-Why

260801 再看
回头再看，几条技巧都没那么重要了。AI 进化的速度比人类快很多。

前言

本文将从我们比较关心的奇技淫巧入手，从方法到背后的原因，希望能够让你能更深入的了解 AI。

很多人说“AI 的东西现在不学，以后就不需要学了”。但我认为有两个东西是不会过时的，感性上是手感，理性上是原理。

也许现阶段 AI 只是自行车，你有可能会摔倒、在过程中会有挫败感，也许后面会有更快、更安全、更方便的载具出现。但我们也能在骑自行车时熟悉一下手感，有一些方向感。

其次，只要 AI 的范式还是 LLM（没有记忆、没有语境、不会主动提问的对话工具），有一些事情是不会过时的。

不预设语境

人与人的交流布满语境——共同的教育背景、文化、专业，省去了大量铺垫。但 AI 对此一无所知。与它对话，把事情交代清楚：

• 目标：你要什么结果
• 参考：有什么现成的可参照（文件路径、文档链接、设计稿）
• 约束：什么不能动（技术栈、已有接口、不希望改的模块）
• 追加一句”给出两个方案并解释理由”——这把 AI 从”猜你想要什么”切换到”帮你比较优劣”。

推荐：“改一下登录页的提交按钮颜色，从蓝色换成 #2D5BFF。其他按钮不要动。设计规范文件在 docs/design-system.md 里。给出两个方案并说明理由。”

不推荐：“帮我改个东西”——然后花五分钟解释你到底在说什么。

Know-Why

LLM 是一个无状态函数。输入 = 当前对话的全部文本历史，输出 = 下一个 token。没有数据库，没有持久化记忆。每次对话，皆白纸一张。

隐性信息显式化 → 输出精准。

给 AI 擅长的格式

将文档转为 AI 的原生语言：\

• Markdown（.md）
• 纯文本（.txt）
• 代码文件（.py, .js, .ts, .json, .yaml 等）
• CSV / 结构化数据

图片与 PDF 是”外部文件”——需经视觉编码，占大量 token，编码质量不及纯文本。长 PDF 把上下文窗口打满，AI 便降了智。并非不愿好好回答，是它”记不住”前文。\

当然，有的时候一图胜千言，随着模型能力和 Agent 能力变强，这一条也许会过时。

Know-Why

这背后是 LLM 的上下文窗口机制。Transformer 的自注意力（Self-Attention）需对窗口内所有 token 两两计算注意力权重，复杂度 O(n²)。
窗口若塞满PDF 视觉编码的冗余像素信息，则注意力被稀释，分不清何为重点、何为格式垃圾。
一页 PDF 经视觉编码，所耗上下文远超等量纯文本。一本 200 页的 PDF 足以把上下文窗口打爆——超出部分根本不会进入推理。

使用多 Agent

主 Agent 统揽需求但不动手执行：

• 主 Agent：负责定义技术框架与任务拆解，输出标准化的协作文档，不直接执行代码。
• 执行 Agent：接收主 Agent 输出的文档片段，执行具体模块，并在文档中同步进度。
• 你：负责与主 Agent 沟通需求、统筹全局。

两个好处：上下文隔离（前端窗口无后端噪音，推理质量更高）、易于 debug（出问题知其所出）。

别这样做：一个对话硬塞万事，最后需求找不到，AI 胡言亦不知其故。

Know-Why

仍是上下文窗口的问题。Transformer 的自注意力使每个 token 皆”看见”窗口内所有其他 token——这意味着噪声非局部，而是全局污染。一个对话塞进前端、后端、数据库、部署四个领域，各领域的概念、报错、中间产物相互拉扯注意力分布。\

与技巧 2 同根：干净的上下文 = 最高信息密度 = 最少 token 浪费 = 最优推理质量。\

此外，出 bug 更易定位——你可以循文档找到结症。把任务拆为前后端，纵是两座屎山，分开开发至少让山的面积减半。

合理分配模型

不管什么任务都丢给同一个模型。写代码用它，翻译用它，总结文档用它，闲聊还用它。然后有些事就是做不好。

• 粗糙法则：深度推理（复杂代码、方案设计）用最强模型
• 速度优先（格式化、翻译、简单问答）用轻量模型
• 长文任务（总结长文档、分析大段文本）用上下文窗口大的模型。

别这样做：所有任务无差别丢给同一个模型，然后抱怨质量不稳。

Know-Why

不同”版本”是完全不同的神经网络。差异来自三个层次