最近几个星期我一直在跟一个叫“Understanding AI”的系列内容，它做的事情很纯粹：不追热点，不堆名词，老老实实把大模型、Agent、RAG这些概念拆开来讲，讲原理也讲落地。今天刷社区的时候发现这个系列迎来了新作者 Dan Kagan-Kans，这个变化乍一看只是多了个人写稿，但仔细想想，背后其实是整个栏目在从“解释AI是什么”转向“带着读者把AI用起来”。
这篇文章不打算复述某个发布会或者某个模型的榜单，而是想借“Understanding AI 迎来新作者”这件事，聊聊我一直以来观察到的现象：AI领域信息早就过剩了，但真正能让人看懂、能让人上手去试的内容反而是稀缺品。无论是刚入行的开发者、团队里的技术管理者，还是自己折腾AI产品的人，这篇文章里梳理的框架和踩坑记录，应该都能派上用场。
顺便说一句，如果你也正在学大模型、调提示词、搭RAG，那么下面这几个部分可以按顺序看：先搞清楚栏目为什么值得跟，再聊新作者可能带来的变化，然后是一套我常用的知识框架，最后是几个真实项目里踩过的坑。
1. 为什么“Understanding AI”这类项目越来越重要
1.1 AI信息过载，缺的不是资料而是“理解”
我自己手机里订阅了一大堆科技媒体和AI频道，每天打开都是“XX模型发布”“XX功能上线”，资讯量确实大，但真正消化吸收的内容很少。原因很简单：大多数报道停留在“是什么”和“多厉害”，很少花笔墨讲清楚“为什么这样设计”以及“我该怎么判断这个技术对我有没有用”。
这就是“理解AI”和“看到AI”的区别。看到AI，是知道ChatGPT又能生成长文档了，是知道某个模型跑分又涨了几个点；理解AI，是知道上下文窗口到底受什么限制，是知道RAG为什么能缓解幻觉，是知道Agent执行多步任务时为什么容易跑偏。后者不是靠刷新闻刷出来的，需要有人把工程细节切开，一点点给你看。
我特别喜欢“Understanding AI”这个栏目的一个原因，就是它默认读者是聪明人，不故意简化到失去信息量，也不会用术语把人吓退。每一篇都能看到作者自己在思考的痕迹，而不是把官方文档换了个说法再发一遍。
提示：如果你发现自己收藏了很多AI文章但遇到实际问题还是无从下手，那大概率是缺少“理解”而不是缺少“资料”。解决办法是选几条主线内容精读，而不是继续刷更多碎片。
1.2 这个系列解决了什么问题
“Understanding AI”解决的其实是三个很具体的问题：第一，新概念层出不穷，读者不知道该信任谁；第二，技术文章要么太浅要么太深，中间层内容稀缺；第三，很多人看完理论不知道下一步做什么实验。它做的事情就是站在中间：把论文里的核心思路翻译成工程语言，把社区里的最佳实践归纳成可操作的步骤。
我们做个类比：大模型就像一个功能强大的工具箱，但大多数说明书只告诉你“这有个工具，很厉害”，却不说什么时候该用哪个、坏了怎么修。这个系列更像是老工人的手记——告诉你某个工具在什么场景下会失灵，拧螺丝时掌心要往哪个方向使劲。
所以当看到Dan Kagan-Kans加入时，我的第一反应不是“来了个新名字”，而是“这个系列准备往更深的工程方向走了”。因为单纯做科普已经不能满足老读者的需求，大家更希望有人带自己过一遍真实项目，比如怎么选模型、怎么做评估、怎么让Agent老实干活。
2. 新作者Dan Kagan-Kans：他会带来什么
2.1 从公开信息看他关注什么方向
说实话，我并不是第一批认识Dan的人，是看到他写的几篇关于模型评估和Agent稳定性的内容才开始留意的。从他的写作风格能明显感觉到，他不是把自己关在实验室里推公式的类型，而是愿意把手弄脏、把问题暴露出来的实践者。他喜欢讨论的话题集中在几个方向：AI Agent在真实业务里的边界、大模型应用的可观测性、还有怎么用低成本方案替代昂贵的大模型。
这也是“Understanding AI”目前最需要的补位。原来很多文章还在讲“什么是Transformer”“什么是embedding”，那是对新手友好的基础课。但继续往下走，读者自然会产生更进阶的疑问：我接入了大模型API，但怎么知道它现在回答得好不好？我搭了个Agent，但为什么它总在第三步把事情搞砸？Dan这种偏工程实践的视角，正好补上了这块拼图。
注意：判断一个新作者会不会给栏目带来价值，别只看头衔，要看他有没有拿真实案例说话的习惯。Dan的文章里出现过很多“我试过”“这个方案在某种情况下失效”这样的表述，这种对自己工作不美化的态度，比晒十张截图都有说服力。
2.2 一个新作者能改变一个栏目的生态
一个栏目长期只有一两个作者容易形成路径依赖，大家会不自觉地只写自己熟悉的内容，读者的阅读口味也被固定住。新人加入最直接的影响就是“信息结构的复杂度变高了”：同一件事开始出现不同角度的拆解，比如同样是讲Agent，老作者可能更偏算法原理，新作者可能更偏产品落地，这两种视角一碰撞，读者反而能拼出更完整的图景。
我自己的经验是，写技术文章最忌讳“只有正确答案”。技术领域的正确答案往往有前提条件，不同的部署环境、不同的业务约束下，最优解会完全不同。多一个作者，就多一组“前提条件”，也就多了一批还没被说清楚的真实场景。
另外，Dan的加入也是个信号：说明栏目在主动扩圈。一个能够持续吸引新作者的内容项目，说明它的编辑团队在认真对待读者反馈，也说明它准备长期做下去。对关注者来说，这种“确定性”比单篇爆款还重要，因为学习本来就是个需要时间积累的事。
3. 如何借“Understanding AI”建立自己的AI知识框架
3.1 五个关键台阶：从原理到工程
只看“Understanding AI”的文章不等于理解AI，就像只看菜谱不等于会做菜。我建议每个读者在追踪栏目内容的同时，为自己搭建一个阶梯式的知识框架，这个框架由五个台阶组成。
第一台阶是大模型的两个核心概念：Token和上下文窗口。你可以把Token理解成模型吃进去的最小信息单位，中文里一个汉字大概对应一到两个Token，上下文窗口就是模型能同时“记住”的最大Token数。注意它不是你能传给它处理的上限，而是模型注意力机制的物理边界，超出去的内容模型根本看不到，这和你给它多少字的输入没有关系。
第二台阶是Embedding和向量检索。Embedding是把文字变成一串数字坐标，让语义相近的内容在空间中靠得更近。理解这个概念是理解RAG的前提，你只有把文档变成向量，才能在两亿条知识里快速找回最相关的那几条。
第三台阶是提示词和结构化输出。很多人觉得提示词是“咒语”，其实本质是“给模型做任务说明”。好的提示词要包含角色、任务、输入输出格式、约束条件，还要给模型一个“说不知道”的出口，这样才能把幻觉压制在一定范围内。
第四台阶是RAG，也就是检索增强生成。当大模型不懂你私有知识的时候，你就把相关内容先检索出来，塞进上下文让模型“开卷考试”。RAG不难入门，但做好很难，难在切分策略、召回质量、上下文组装这些细节上。
第五台阶是Agent，意思是让模型具备调用工具、拆解任务、递进执行的能力。它把从“回答问题”变成“完成目标”。这个台阶对工程化能力要求一下子高了很多，你需要考虑模型每一步的决策依据、工具返回结果的校验、失败分支的回退策略等等。
3.2 每个台阶对应的典型工具和实践
有了框架还不够，要真的踩上去才算数。我自己走下来，每个台阶都配了一套最基础的实践路径。
第一台阶建议直接去读几个大模型的设计文档，顺便用OpenAI或Anthropic提供的Tokenizer工具分析几段真实文本，感受一下Token是怎么切的。第二台阶可以跑一个开源的Embedding模型，比如BGE或者MiniLM，拿几十条文本做做相似度检索，亲眼看TopK的结果自己排出来。第三台阶最直接，打开任意一个大模型聊天界面，写一个“给客服工单打标签”的提示词，仔细观察它怎么理解你的指令、错在哪里。第四台阶推荐上手一个成熟的RAG框架，不管是基于LlamaIndex还是LangChain搭的，关键是要把你的私有文档放进去，运行起来，再评估问答质量。第五台阶建议做一个小型Agent，让它调用计算器、搜索引擎或内部API完成一个真实任务。
这里做一个工具选型参考表，都是我实际用过的组合：
| 学习阶段 | 推荐工具 | 适合实践 |
|---|---|---|
| Token基础 | tiktoken、官方Tokenizer | 分析文本长度、控制上下文预算 |
| 向量检索 | Chroma、FAISS、Qdrant | 文档召回、去重、相似搜索 |
| RAG可观测 | LangSmith、Langfuse | 查看检索结果、定位幻觉来源 |
| Agent编排 | Dify、Coze、LangGraph | 快速搭流程、调试工具调用链 |
提示：这个阶段的关键不是“用什么工具”，而是“把输入端和输出端打通”。很多人卡在装了无数框架却从没跑通过一遍完整流程，这会给你一种虚假的熟悉感，真正写代码时大脑还是一片空白。
3.3 我的建议：跟着系列做三个小实验
我特别推荐大家跟着“Understanding AI”这类内容做动手实验，而且实验难度要循序渐进，别一上来就模仿网上那些噱头十足的“AI自动写论文”项目。我的做法是先完成三个小而完整的目标。
第一个实验是文本分类器。给定一批工单或者评论，用大模型API输出结构化标签，比如“退费”“投诉”“咨询”，要求模型返回JSON而不是自由文本。做完这个你就掌握了提示词和结构化输出。
第二个实验是私有知识库问答。准备十几页自己的内部资料，切成几百字的小段，嵌入向量库，然后实现“根据资料回答问题，答不了要明说”。做完这个你就理解了RAG的核心链路。
第三个实验是带工具调用的Agent。给模型接一个天气查询API或者一个简单的计算器，让它根据用户指令自主决定要不要调用工具、怎么解析结果。做完这个你就知道Agent并不是“很神秘”的东西，它就是一套有状态的任务流程。
这三个实验都不需要显卡，不需要私有化部署，花两三百块钱的API费用就能跑透。但它们带给你的“手感”是几十个小时的视频教程换不来的。
4. 落在实处：AI项目实践中的常见坑
4.1 模型选型：不是越大越好
很多朋友第一次接大模型就问“哪个模型最牛逼”，这个问题本身就是错的。大模型的能力是一个多维度的定义，你要考虑推理能力、上下文长度、生成速度、价格以及数据安全边界，不是简单看跑分。
我做过一个真实项目：给公司的售后部门做工单分类。一开始用最强最贵的大模型，效果确实好，但每个月API账单高得吓人。后来我把可能出现的分类结果限制在二十几个固定标签，用一个小模型配合一套写得很细的提示词，准确率不仅没有下降，推理速度还快了很多，成本降到了原来的十分之一。
核心计算思路很简单：算一下你的真实并发量、每条请求平均产生的Token数量、单月调用量，然后拿不同模型的价格表做乘法。很多场景根本用不上顶配模型，中小模型配合好的工作流已经能解决九成问题。
注意：不要只看跑分榜单选模型，要拿自己的真实数据去测。哪怕只测几十条样本，也能暴露出模型在你这个业务场景里的真实水平，比任何Benchmark都有说服力。
4.2 RAG效果不佳，问题多半在切分
RAG最常被问到的就是“为什么我检索出来的东西和问题不相关”。大多数人第一反应是换模型，但实际经验告诉我，十次里有七八次问题出在文档切分策略上。
一种高频错误是切分粒度过大，一个很长的章节塞成一段，Embedding之后向量表示的语义太杂，检索时相关片段被无关内容稀释；另一种高频错误是切分粒度过小，一句话切一段，导致上下文断裂，模型拿到的片段缺乏完整语义。
我的经验是用段落感知切分器，先识别标题和段落结构，再按语义完整性切分。每个切块控制在五百个Token左右，并且保留一段重叠区域，比如相邻切块重叠五十个Token，这样能显著减少跨段信息的丢失。另外，把切块的元数据一起存进向量库，比如来源文件名、章节标题、页码，检索召回后再把这些元数据作为上下文传给模型，让模型的回答有出处可循。
RAG效果好不好，最后一定要做召回质量评估，不能只凭感觉说“好像还行”。建议为每个测试问题准备一条“标准答案”和若干条“应该命中的参考片段”，然后计算命中率。这一步看起来麻烦，但能帮你识别出是切分问题、Embedding问题还是ReRanker缺失的问题。
4.3 Agent不稳定的根源：任务拆解和上下文管理
Agent是很多人觉得最“酷炫”也最容易翻车的地方。我自己搭过好几个Agent，最大的感受就是：Agent不稳定通常不是单点技术问题，而是任务拆得太糙、上下文管理做得太差。
很多Agent框架的设计思路是让模型“自己规划步骤”，但实际上模型一旦面临开放目标，就会开始自由发挥。比如你让它“帮我安排会议室并通知参会人”，它可能会创造出不存在的API参数，或者漏掉通知这一步。解决办法不是去改提示词让模型“别乱来”，而是把任务流程用代码固化下来，允许模型在“分支”内做选择，而不是让它从零到一规划整条路径。
另外一个特别容易被忽视的坑是上下文越长Action越飘。Agent执行多步任务时，每一步的工具返回结果都会被塞进历史记录，几十步之后，原初任务描述已经被淹没在大量工具输出里了。所以我通常会给Agent设置一个短时记忆窗口，定期把历史记录压缩成摘要，或者把任务描述在每轮都会重新注入一遍，确保模型始终记得自己在干嘛。
提示：一定要给Agent加“工具调用日志”和“步骤追踪”能力。哪怕只是打印一下每一步的输入输出，都能帮你快速定位运行到哪一步开始变形的。没有日志的Agent调试起来就是盲人摸象。
5. 给刚接触AI的读者几点参考
5.1 不要把“理解AI”等同于“会调API”
会调API、会对接大模型接口，这叫“工程上手”了，但还不能叫“理解AI”。理解AI是当你拿到一个需求时，能判断该用大模型、小模型、RAG还是Agent；是能解释模型为什么会产生当前结果，以及误差可能出现在哪一环。
我见过一些同学熟练掌握了Prompt编写，却不知道为什么同样的提示词换一个模型效果就崩了；也见过一些工程师把LangChain玩得很转，但遇到LangChain内部封装的概念时只能靠猜。这种“知其然而不知其所以然”的状态，在AI这样快速变化的技术领域里非常危险，因为任何一款底层模型迭代后，你原有的操作习惯就可能整体失效。
所以我的建议是：尽量留出时间做“反操作”练习，比如故意把模型换成另一个参数量的版本，看输出结构有什么变化；比如故意把RAG的切分方式改成一种反直觉的粒度，观察效果如何变差。只有自己亲手把系统推倒过一次，才算真的建起了理解。
5.2 建立自己的测试集，别拿“感觉”当标准
另一件我想跟所有实践者分享的事情是：一定要建立自己的回归测试集。你看完“Understanding AI”里的技术分享，自己动手实现了效果，这不是终点，你还需要一个能持续评估效果的客观标准。
我一开始做RAG问答时，也喜欢“试几条感觉挺好”。后来发现这种“感觉”完全不可靠，因为模型输出本身有随机性，一条问题答得好不代表五十条都能答好。后来我把最常见的三十条问题整理成一个测试集，每个问题写好理想答案和判断要点，每次改完代码就跑一遍这三十条，看过了几个、挂掉几个。这个习惯帮我拦截了无数次“改完以后整体效果反而变差”的尴尬。
你可以用现成的评估框架，也可以像我一样用一个简单的脚本维护这个测试集。重点不是用什么工具，而是建立“模型输入-期望行为-实际行为”的对照意识。做AI应用，没有标准答案的时候就要自己造一个参考系。
5.3 关于写作和分享：每个人都可以是作者
看到Dan加入“Understanding AI”这件事，除了聊技术和内容方向，我还想多说一句关于写作的感受。在AI这个领域里，真正的学习和深度的内化，最有效的路径之一其实就是写作。
把一件事讲明白的前提是你自己想得足够清楚。我许多关于RAG、关于Agent架构的认知，都是在写文章的过程中重新整理出来的。写作迫使你直面那些“其实我也没搞懂”的部分，也迫使你把模糊的直觉变成可复制的步骤。这恰恰是“理解”的最终形态。
如果你也在研究AI，我不太建议你只做读者，找一个细分的主题开始写，可以写给自己看，也可以写给别人看。不用等自己成为专家再动笔，在学的过程中写，效果反而最好。“Understanding AI”迎来新作者这件事给我们的启发正是如此：每一个愿意把自己理解过程记录下来的人，都有可能成为别人理解AI路上的引路人。
