先问你一个问题：同样一个需求——「给我们的客服系统加一个 AI 自动回复」——一个 AI 应用工程师和一个 AI 应用架构师，拿到的反应有什么不一样？
应用工程师想的是：怎么把它做出来。调哪个 API、提示词怎么写、回复格式怎么解析、错了怎么重试。这些是「实现」层的问题，答案大多有对错。
架构师想的是另一组问题：这个东西该不该这样做。客服场景里答错的代价是什么？是答非所问让人烦，还是报错退款金额造成真金白银的损失？需要多高的正确率才够上线？用贵的大模型还是便宜的小模型，省下的钱够不够覆盖错误率的上升？这个问题到底是提示词能解决的，还是要喂更多上下文，还是——到了某个点——应该自己训一个专用模型？
大白话：工程师回答「怎么做」，架构师回答「做不做、做成什么样、用什么换什么」。后者没有标准答案，只有权衡。
三个岗位，三种判断力的范围
把这条路上的三个台阶摆在一起看：
- AI 应用工程师：把模型接进产品。判断力覆盖「一次调用」——提示词、参数、解析、重试。产出是可用的功能。
- AI 应用架构师：设计整个 AI 系统。判断力覆盖「一个系统」——多个模型怎么编排、数据怎么流、成本怎么算、可靠性怎么保证、什么时候该微调。产出是能在真实世界长期跑、扛得住流量和意外的系统。
- 算法岗（训专用模型）：当现成模型不够用，自己造一个。判断力覆盖「一个模型本身」——数据怎么造、训练怎么配、训出来的模型到底变好了没有、值不值那笔算力钱。产出是别人训不出来的能力。
注意一个规律：台阶越高，判断力的范围越大，但每一级都建立在下一级之上。没见过提示词怎么在线上崩掉的人，设计不出可靠的系统；没算过推理成本账的人，判断不了「自己训一个模型」到底划不划算。所以这不是三条平行的职业路线，而是一级一级叠上去的。
为什么差的不是「会的工具多」
很多人以为升级就是学更多东西：学 LangChain、学向量数据库、学 PyTorch、学 CUDA……工具清单越列越长，人越来越焦虑。
但工具是结果，不是原因。架构师和工程师真正的差别在于：架构师脑子里有一张「代价地图」。他知道每个选择背后牺牲了什么。用更大的模型，牺牲的是钱和延迟；用更复杂的智能体编排，牺牲的是可调试性；自己训模型，牺牲的是时间和维护成本，换来的是效果、成本和数据主权。
大白话：工具半年一换，权衡十年不变。这本书只讲权衡，工具顺带提。
贯穿全书的一个问题
这本书要回答的问题只有一个：
一个现在只会调 API 的应用工程师，怎么一步步长出「这个系统该这样设计、这个模型该这样训」的判断力？
我们的走法是顺着判断力范围的扩大走：先吃透一次调用里每个旋钮到底在拧什么（第二章）；再把它当成接口设计来对待（第三章）；然后把视野扩大到上下文、工具、评估、可靠性、成本这四到八章的系统层面——到这里，你已经具备应用架构师的完整视野。第九章是一个分水岭：什么时候提示词这条路走到头了？答案指向数据、微调、自训专用模型（十到十二章），也就是算法岗的核心。最后两章把整条线收拢成一张能力地图。
每一章只讲透一件事，并且回答上一章留下的疑问。现在，从最小的一次调用开始。