技术章节到此结束。这一章回答一个更日常的问题：AI 应用架构师的工作日到底长什么样？答案可能会让期待「画架构图」的人意外：架构师的大部分时间，花在三种决定上——结构、边界、时机。
结构的决定：编排，而不是堆叠
真实的 AI 系统很少是「一个模型回答一切」，而是多个不同档位、不同职责的模型加传统代码的编排。架构师设计的结构，常见形态是分层：便宜的小模型做分流、意图识别、格式转换这些「体力活」；旗舰模型只处理真正需要推理的环节；确定性代码（规则、校验、数据库）把守所有不能错的关口。
分层的原则在前面各章已经分别出现过，这里把它们收拢成一条：确定性优先于模型，小模型优先于大模型，检索优先于记忆，提示词优先于微调。每一层升级都意味着成本和复杂度的跃迁，架构师的工作就是挡住不必要的跃迁。一个「只用了一个模型加一个提示词」的设计，往往比「五个智能体协同」的设计更能体现功力——简单是省出来的，不是偷懒出来的。
边界的决定：AI 管什么，人管什么，代码管什么
每个 AI 系统里都有一条三权分立的边界要划：
- 代码管确定性的事：金额计算、权限校验、流程流转。能用 if 写清楚的，绝不让模型投票。
- 模型管判断与生成：理解意图、起草内容、在非结构化信息里找答案。
- 人管不可逆的事：第五章的工具分级在这里放大成组织设计——哪些动作永远要人点头，出错时谁接手，责任怎么界定。
这条边界划错是架构师最严重的失误：让模型管了不该管的（自动审批大额退款），是事故；让代码硬写本该交给模型的（拿正则解析用户意图），是返工。划对了，系统里每个部件都在自己最可靠的位置上。
时机的决定：什么时候做，什么时候忍
架构决策里最被低估的是时机。同样的方案，时机不同，对错相反：
- 什么时候把临时方案固化：提示词里的补丁攒到什么程度该微调（第九章的五个信号）；脚本跑到什么量级该变成正式服务。
- 什么时候容忍不完美：评估通过率 92% 够不够上线？答案从来不是技术问题——它取决于答错那 8% 的代价落在谁身上。架构师要能把这个代价翻译成业务语言，和产品、运营一起拍板，而不是躲在「技术上还不完美」后面无限延期。
- 什么时候拥抱新东西：模型半年迭代一代。架构师要有纪律地跟踪（自己的评估集就是最好的新模型试金石——新模型发布，跑一遍评估，分数说话），也要有纪律地不追：生产系统的稳定收益，常常大于新版模型 3% 的提升。
一个隐藏的职责：让团队不依赖你
最后是架构师最不像技术的技术职责：把判断力沉淀成系统，而不是沉淀成「问你」。评估集、降级链、成本看板、上线检查清单——这些东西的共同作用是让团队在你不在场时也能做出八十分以上的决定。一个凡事都要亲自把关的架构师不是资产，是瓶颈。
到这里，书的技术主线和岗位画像都完整了。最后一章回到你身上：这条路具体怎么走，每一步怎么验证自己走到了。