写在前面
这是一篇"主观认识"系列的开篇。我是一个做了十年游戏 / 客户端开发的工程师，今年才开始认真碰 AI，水平大致在"能调 API、看得懂科普、论文还吃力"的初级阶段。
这个系列不追求严谨，也不打算教别人什么——只是把我自己对 AI 的一些粗浅但真实的认识记下来，既是梳理，也方便以后回看自己当时有多 naive。
第一篇，先聊一个对我来说很重要的"分法"：把"AI 开发"再拆成两层。
一、AI 开发可以再分两层：算法侧 vs 应用侧
概念：我以前把"做 AI"想简单了
很长一段时间里，我默认"做 AI" ≈ “训练模型”。直到自己真上手去用 AI 做事，才发现这个词底下其实藏着两条几乎不相交的路：
- AI 算法（模型侧 / Algorithm side）：研究怎么"造出那个会思考 / 会生成的东西本身"。它关心模型架构、训练、微调、推理优化、底层框架（PyTorch / JAX 那一套）、数据和数学。这一侧的产出物是"模型 / 能力"。
- AI 应用开发（工程侧 / Application side）：拿到现成的、或别人微调好的模型，把它真正塞进产品和工作流里用起来。它关心 API 调用、Prompt 工程、RAG、Agent 编排、向量数据库、评估与线上监控。这一侧的产出物是"能用的功能 / 产品"。
🔧 技术校准（AI 专家视角）：这个二分法在业界有对应的说法。研究 / 模型侧常叫 ML Research / Deep Learning；把模型落地成系统的那一侧，近年被 Chip Huyen 等人明确称为 AI Engineering，也叫 Applied ML / ML Engineering。需要注意：两层之间并没有一道墙——微调（fine-tuning）、MLOps、模型压缩这些恰好卡在中间，所以"算法"和"应用"更像光谱的两端，而不是非黑即白。
对比：两条路的难度维度根本不同
| AI 算法（模型侧） | AI 应用开发（工程侧） | |
|---|---|---|
| 像什么 | 科研：深、窄、靠硬功 | 工程：广、快、靠整合 |
| 核心门槛 | 懂模型、懂数学 / 系统 | 懂产品、懂怎么把模型用出价值 |
| 周期 | 长，迭代慢 | 短，能快速出 demo |
| 我的位置 | 门外，只浅尝过 | 正在摸门 |
我自己是游戏 / 客户端工程师出身，天然更靠近应用侧：我不需要从零训一个大模型，但我能用"API + RAG"很快把一个知识库变成能对话的东西。一度我因此产生一种错觉——“原来我也能做 AI 了”。后来才意识到，我做的只是应用侧里很薄的一层。
实战：我目前只摸到了应用侧的门
目前我手上的 AI 实践几乎全在应用侧：
- 调各家 API、写（并反复改）Prompt；
- 搭 RAG：把博客 / 笔记喂进向量库，做成能检索的助手；
- 用 Agent 把"查资料 → 整理 → 成稿"的工作流串起来（比如现在这篇，就是我和我的博客 Agent 协作的产物）。
算法侧我只浅尝：跟着跑过几个 Colab notebook、扫过一点训练代码，离"能独立训一个有用模型"还差得远。
但应用侧也不是"调个接口就完事"。我踩过的坑包括：Prompt 看着像玄学其实有方法论；RAG 的上限基本由数据质量决定；Agent 的编排和容错，往往比模型本身更折磨人。
误区：我想纠正自己当初的几个误解
- “会用 ChatGPT / 调 API = 懂 AI” —— 这是应用侧的入门，远不是 AI 的全部。
- “做 AI 一定要数学超好、会训模型” —— 应用侧对数学的要求低得多，更吃工程整合和产品感觉。这也是为什么工程背景的人（比如我）能比较顺地切进来。
- “算法侧比应用侧更高级” —— 两者难在不同的维度。把模型稳定、便宜、可控地用出业务价值，同样极难，绝不"低级"。
后续：这篇之后我还想写
- 为什么我觉得"AI 应用开发"更适合工程背景的人切入；
- 我对 Agent 的主观看法（以及被它坑过的真实经历）；
- AI 帮我提效的几个具体场景；
小结：把"AI 开发"拆成算法侧和应用侧，帮我理清了自己到底在哪儿、该往哪儿使劲。下一篇接着聊——应用侧为什么适合我这种人。