Part III 技术选型
Discovery 跑完了，FDE 手里有 outcome、评估集 v0.1、SOW。下周一开始，客户 CTO 会问一个非常具体的问题：你们准备用什么模型、放在哪、怎么调用、谁来编排。
这一刻，新手 FDE 最容易掉进两个坑。一个是过度选型——花两周横向比较五个向量库、三个 Agent 框架、四个 LLM，会议开了一堆，一行业务代码没写。另一个是零选型——抓起最熟的那套就开干，六周后才发现选错了，回退成本巨大。
Part III 给第三条路：把”技术栈”拆成五个独立维度，按先后顺序锁定，让第一周的选型变成一项可控的工程任务，而不是一场无止境的辩论。
第 6 章讲第一周怎么把模型、托管、编排在一张纸上锁定。核心是一张五维结构图（D1 托管、D2 模型、D3 调用模式、D4 编排、D5 评估），上层依赖下层，所以必须从下到上拍板。这一章用一个虚构的制造业客户案例（合昇精密重工）做演示，AWS Bedrock 是动手平台，但选型框架本身和平台无关。
第 7 章讲 D3 调用模式那一层——RAG / Fine-tune / Prompting / Agent 该用哪个、什么信号触发切换。这一章给的不是”谁更好”的判断，是一棵决策树：数据更新频率、答案确定性、推理预算、合规约束这几个维度组合起来，自然会落到某一种模式上。读完这章，再有人跟你说”我们应该用 Agent”，你能立刻反问回去。
第 8 章讲 D5——评估和可观测。评估这件事的难点不在工具，在纪律：把评估集真的接进 CI，让它每个 PR 跑分、低于上周不能 merge。这一章把 Part I 第 2 章的 Eval-driven 铁律落到具体工程动作上，是 Part III 通向 Part V 生产化的关键。
Part III 的输入是 Part II 的评估集和 SOW，输出是一套能跑分、能演示、能继续迭代的最小闭环。Part V 的生产化、Part VI 的 Agent 都建立在这套闭环之上。