过去一段时间，我一直在思考一件事：
AI 已经变得“很容易用”， 但为什么“真正用好”却越来越难？
早期，我们关注的是：
- 去哪里用 AI
- 如何获得模型能力
- 使用门槛为什么这么高
但现在，这些问题基本被解决了：
- 大模型能力快速提升
- 各类工具与平台持续涌现
- API 与应用形态逐渐成熟
于是，一个新的问题开始变得更加明显：
“如何用上 AI”正在被解决， “如何真正用好 AI”才刚刚开始。
一、问题已经发生转移
在真实项目中，问题很少再是：
- 模型够不够强
- 能不能调用 API
而更多变成：
- 为什么系统效果不稳定？
- 为什么线上表现和 Demo 差异很大？
- 为什么成本总是不可控？
- 为什么系统一复杂就开始失控？
这些问题，很少是“模型问题”。
更本质的是：
工程问题。
二、门槛并没有消失，只是转移了
表面上看：
AI 的门槛在降低
但实际上：
门槛正在向“工程能力”转移
真正决定系统上限的，不再是：
- 是否能调用模型
而是：
- 是否理解系统链路
- 是否具备架构能力
- 是否能定位问题来源
- 是否能在效果、成本与性能之间做取舍
换句话说：
AI 不再只是“用”，而是“构建”。
三、为什么我开始做「技术深潜」
在接触越来越多实际系统之后，我逐渐意识到：
很多问题，并不是因为不会用 AI 而是因为没有真正理解 AI 系统
比如：
- 一次请求到底发生了什么？
- 检索结果为什么会不稳定？
- 延迟是在哪一层产生的？
- 系统为什么在规模上升后失控？
这些问题，如果只停留在：
- 工具使用
- Prompt 调整
是很难解决的。
必须向下走：
进入系统本身。
四、什么是「技术深潜」
“技术深潜”不是讲概念，也不是做工具推荐。
它更接近于：
把系统拆开，理解它是如何被构建出来的。
包括：
- 执行链路如何组织
- 模块如何协同工作
- 代码层是如何实现的
- 系统在真实环境中如何表现
以及更重要的：
一个系统如何运行 如何出错 又是如何被修正
五、接下来会写什么
围绕真实工程问题，我会逐步拆解：
- 一次完整的 RAG 请求链路（源码级）
- 为什么 RAG 在业务中经常不稳定
- 一次请求的延迟是如何产生的
- AI 系统如何在性能与成本之间平衡
- 开源项目的结构与设计决策
这些内容不会刻意降低门槛，也不会停留在表层。
因为如果你正在构建 AI 系统，这些问题是绕不开的。
六、这不是转型，而是向下
如果说 AI 的第一阶段是：
让更多人用上 AI
那么接下来更重要的是：
让 AI 真正成为系统的一部分，并稳定运行
这不是重来，而是一种自然的延伸。
最后
如果你也在关注这些问题：
- 系统是如何构建的
- 问题是如何产生的
- 又是如何被修正的
那接下来这一系列内容，应该会对你有帮助。
技术深潜，从这里开始。
