Ethan 恩宇 的 X 帖子
@UPing123zzz
这几天学习 AI 工程的时候，我突然意识到一个问题：我们这一代做 AI 开发的人，可能正在跳过大量基础知识，直接进入应用层。
现在打开 GitHub、X，每天都是 Agent、MCP、RAG、Skill、各种自动化框架。
只要你会使用 Codex，懂一点 API，甚至不需要写太多代码，就能快速搭建一个看起来很复杂的 AI 系统。
但有个很基础的问题，我发现自己之前也没有认真思考过：当我们向大模型发送一段 Prompt 的时候，模型到底接收到了什么？
它接收的不是人类直接理解的文字，而是经过 Tokenizer 处理后的 Token ID 序列，再由模型转换成内部的向量表示。
就是这么一个看起来非常基础的概念，却直接影响着上下文窗口、API 成本、RAG 检索、代码生成，以及 Agent 长时间运行时的可靠性。
我最近一直在做企业 AI 落地，涉及 GEO、知识库、Agent 和自动化工作流，越往后做，越发现这些基础问题根本绕不过去。
举个非常简单的例子。当企业给你几百份文档，让你搭建一个知识库问答系统。你把文档导入，做 Chunk 切分，生成 Embedding，再接上一个大模型。然后整个流程跑通了，Demo 看起来也很不错。
但客户真正使用的时候，可能突然发现一个很奇怪的问题：明明答案就在文档里面，为什么 AI 就是回答不出来？
很多人的第一反应可能是模型不够强，Prompt 写得不够好，或者要不要换一个更厉害的 Reranker。
但问题可能根本没出在这些地方。
比如你按字符数量切分文档，却没有检查 Embedding 模型真正支持的 Token 长度，导致部分内容在入库过程中被截断。
或者切分的时候，把一个完整的业务流程拆散了，导致检索出来的内容缺少必要的上下文。
甚至答案根本没有被召回，生成模型从头到尾就没看到正确的证据。
你以为是 AI 不够聪明，实际上可能是你自己设计的系统，根本没有把正确的信息交给它。
Agent 也是一样。一个 Agent 要完成复杂任务，可能需要连续调用十几次工具。每一次工具调用都可能产生大量 JSON、日志、数据库记录。
如果你不管理这些信息，任由它们不断进入上下文，那么 Token 消耗可能越来越大，真正重要的信息也可能被大量无关内容淹没。
最后 Agent 开始出现各种奇怪的问题：遗漏要求、反复调用工具、忘记前面的任务条件，甚至执行到一半就因为上下文限制而失败。
这时候你再去修改 Prompt，可能只是治标不治本。
因为你没有真正理解整个系统的数据是怎么流动的，信息在哪一层被处理，又在哪一层可能丢失。
所以我现在对 AI Engineering 有了一个新的认识。
AI 工程不是简单地把一个大模型接到业务流程里面，而是要确保正确的数据，在正确的时候，以正确的形式进入模型，并且让整个系统的行为可以被观察、验证和修复。
这听起来好像没什么特别的，但真正做起来，涉及的东西非常多。
你要理解 Tokenization，知道不同模型如何处理输入。
你要理解 Context Window，知道系统指令、历史对话、检索结果和工具返回是怎么消耗上下文的。
你要理解 RAG 的切分、召回和重排，知道检索不到答案与模型没有正确生成答案，是两个完全不同的问题。
你还要理解 API、异步任务、状态管理、幂等性、重试机制，以及如何在失败之后恢复系统。
这些知识单独拿出来，可能都没有一个新的 Agent 框架那么吸引人。
但当一个 AI 系统真正进入企业，开始处理真实业务的时候，你会发现，决定它能不能长期运行的，恰恰就是这些不起眼的工程细节。
我觉得这也是现在 AI 开发特别容易出现的一种错觉。
AI 编程工具太强了。你提出需求，模型帮你生成代码，安装依赖，接入 API，甚至自动部署。
最后页面出来了，接口通了，功能也能演示，你很容易产生一种感觉：这个系统我已经会做了。
但如果让你解释其中的每一层为什么这么设计，为什么选择这种切分方式，为什么这次检索失败，为什么 Agent 的成本突然增加，为什么任务重试后出现重复执行，你未必能够回答清楚。
能让 AI 帮你写出一个系统和你真正具备设计、诊断、维护这个系统的能力，根本不是一回事。
这不是说我们必须回到过去，所有东西都要自己从零手写。
恰恰相反，我觉得应该尽可能利用 AI 提高开发效率，把节省下来的时间用来理解架构、分析问题、学习真正重要的工程知识。
因为代码生成越来越便宜，真正稀缺的可能不再是写出某段代码，而是判断应该写什么、不应该写什么，以及系统出现问题后如何定位和解决。
接下来我也准备改变一下自己的学习方式。不再只是看到一个新框架就想着赶紧上手，而是尽量把现有项目往深处研究。
比如检查知识库每个 Chunk 的真实 Token 分布，测试不同切分策略对检索效果的影响；记录 Agent 每次调用的 Token 消耗、延迟和工具返回内容；把一次回答错误拆成数据、检索、上下文、生成几个环节去排查。
这些实践可能没有做出一个炫酷的 AI Demo 那么容易获得关注，但我觉得它们更接近真正的工程能力。
尤其对于想做 FDE、AI Engineer 的人来说，我们最终面对的不是一个能够演示成功的玩具，而是企业真实的业务需求。
客户不会因为你用了最新的 Agent 框架，就接受一个经常出错的系统。客户关心的是能不能解决问题，成本能不能控制，出了故障能不能恢复，以及这个系统到底能不能持续创造价值。
所以我现在觉得，学习 AI 最应该警惕的不是自己跟不上最新的技术，而是每天都在追逐新技术，却始终没有把真正重要的基础知识学扎实。
未来 AI 工程师之间的差距，可能不是谁会调用更多模型、安装更多 Skill、使用更多框架，而是谁能真正理解一个系统为什么能够运行，以及它为什么会失败。
会使用 AI，正在成为越来越普遍的能力，但能够理解 AI 系统、驾驭 AI 系统，并把它可靠地交付到真实业务中，才是我真正想积累的能力。
现在打开 GitHub、X，每天都是 Agent、MCP、RAG、Skill、各种自动化框架。
只要你会使用 Codex，懂一点 API，甚至不需要写太多代码，就能快速搭建一个看起来很复杂的 AI 系统。
但有个很基础的问题，我发现自己之前也没有认真思考过：当我们向大模型发送一段 Prompt 的时候，模型到底接收到了什么？
它接收的不是人类直接理解的文字，而是经过 Tokenizer 处理后的 Token ID 序列，再由模型转换成内部的向量表示。
就是这么一个看起来非常基础的概念，却直接影响着上下文窗口、API 成本、RAG 检索、代码生成，以及 Agent 长时间运行时的可靠性。
我最近一直在做企业 AI 落地，涉及 GEO、知识库、Agent 和自动化工作流，越往后做，越发现这些基础问题根本绕不过去。
举个非常简单的例子。当企业给你几百份文档，让你搭建一个知识库问答系统。你把文档导入，做 Chunk 切分，生成 Embedding，再接上一个大模型。然后整个流程跑通了，Demo 看起来也很不错。
但客户真正使用的时候，可能突然发现一个很奇怪的问题：明明答案就在文档里面，为什么 AI 就是回答不出来？
很多人的第一反应可能是模型不够强，Prompt 写得不够好，或者要不要换一个更厉害的 Reranker。
但问题可能根本没出在这些地方。
比如你按字符数量切分文档，却没有检查 Embedding 模型真正支持的 Token 长度，导致部分内容在入库过程中被截断。
或者切分的时候，把一个完整的业务流程拆散了，导致检索出来的内容缺少必要的上下文。
甚至答案根本没有被召回，生成模型从头到尾就没看到正确的证据。
你以为是 AI 不够聪明，实际上可能是你自己设计的系统，根本没有把正确的信息交给它。
Agent 也是一样。一个 Agent 要完成复杂任务，可能需要连续调用十几次工具。每一次工具调用都可能产生大量 JSON、日志、数据库记录。
如果你不管理这些信息，任由它们不断进入上下文，那么 Token 消耗可能越来越大，真正重要的信息也可能被大量无关内容淹没。
最后 Agent 开始出现各种奇怪的问题：遗漏要求、反复调用工具、忘记前面的任务条件，甚至执行到一半就因为上下文限制而失败。
这时候你再去修改 Prompt，可能只是治标不治本。
因为你没有真正理解整个系统的数据是怎么流动的，信息在哪一层被处理，又在哪一层可能丢失。
所以我现在对 AI Engineering 有了一个新的认识。
AI 工程不是简单地把一个大模型接到业务流程里面，而是要确保正确的数据，在正确的时候，以正确的形式进入模型，并且让整个系统的行为可以被观察、验证和修复。
这听起来好像没什么特别的，但真正做起来，涉及的东西非常多。
你要理解 Tokenization，知道不同模型如何处理输入。
你要理解 Context Window，知道系统指令、历史对话、检索结果和工具返回是怎么消耗上下文的。
你要理解 RAG 的切分、召回和重排，知道检索不到答案与模型没有正确生成答案，是两个完全不同的问题。
你还要理解 API、异步任务、状态管理、幂等性、重试机制，以及如何在失败之后恢复系统。
这些知识单独拿出来，可能都没有一个新的 Agent 框架那么吸引人。
但当一个 AI 系统真正进入企业，开始处理真实业务的时候，你会发现，决定它能不能长期运行的，恰恰就是这些不起眼的工程细节。
我觉得这也是现在 AI 开发特别容易出现的一种错觉。
AI 编程工具太强了。你提出需求，模型帮你生成代码，安装依赖，接入 API，甚至自动部署。
最后页面出来了，接口通了，功能也能演示，你很容易产生一种感觉：这个系统我已经会做了。
但如果让你解释其中的每一层为什么这么设计，为什么选择这种切分方式，为什么这次检索失败，为什么 Agent 的成本突然增加，为什么任务重试后出现重复执行，你未必能够回答清楚。
能让 AI 帮你写出一个系统和你真正具备设计、诊断、维护这个系统的能力，根本不是一回事。
这不是说我们必须回到过去，所有东西都要自己从零手写。
恰恰相反，我觉得应该尽可能利用 AI 提高开发效率，把节省下来的时间用来理解架构、分析问题、学习真正重要的工程知识。
因为代码生成越来越便宜，真正稀缺的可能不再是写出某段代码，而是判断应该写什么、不应该写什么，以及系统出现问题后如何定位和解决。
接下来我也准备改变一下自己的学习方式。不再只是看到一个新框架就想着赶紧上手，而是尽量把现有项目往深处研究。
比如检查知识库每个 Chunk 的真实 Token 分布，测试不同切分策略对检索效果的影响；记录 Agent 每次调用的 Token 消耗、延迟和工具返回内容；把一次回答错误拆成数据、检索、上下文、生成几个环节去排查。
这些实践可能没有做出一个炫酷的 AI Demo 那么容易获得关注，但我觉得它们更接近真正的工程能力。
尤其对于想做 FDE、AI Engineer 的人来说，我们最终面对的不是一个能够演示成功的玩具，而是企业真实的业务需求。
客户不会因为你用了最新的 Agent 框架，就接受一个经常出错的系统。客户关心的是能不能解决问题，成本能不能控制，出了故障能不能恢复，以及这个系统到底能不能持续创造价值。
所以我现在觉得，学习 AI 最应该警惕的不是自己跟不上最新的技术，而是每天都在追逐新技术，却始终没有把真正重要的基础知识学扎实。
未来 AI 工程师之间的差距，可能不是谁会调用更多模型、安装更多 Skill、使用更多框架，而是谁能真正理解一个系统为什么能够运行，以及它为什么会失败。
会使用 AI，正在成为越来越普遍的能力，但能够理解 AI 系统、驾驭 AI 系统，并把它可靠地交付到真实业务中，才是我真正想积累的能力。
这是保存的副本，原帖可能已修改或删除。