03 · 第三关：工程炼金术 · 开发环境治理与模型适配

“三级环境隔离保证发布安全，模型阶梯分流平衡成本与时延；Schema 契约校验是结构化输出的确定性护栏。”
—— 一位百雀羚前线交付工程师的备忘录

001

⚔️ 本关作战任务（Context & Quest）

工作场景：FDE 单机开发沙箱与预发布联调网关
工程挑战：“直接在生产环境调试排错”、“全量请求直连大参数模型的成本与延迟瓶颈”、“模型输出非预期文本导致的格式解析异常”
Text-First 阶段映射：
- Stage 3: Context Compilation & Targeted Execution（上下文定向编译与执行）
- 核心工程准则：Rule 2: Don't Feed Raw Prompts, Compile Context（不喂散装 Prompt，编译定向上下文）
- 核心原则：Principle 7: Context is Compiled, Not Re-explained（上下文动态编译，拒绝反复口述）
通关目标：
1. 掌握并搭建 Dev / Staging / Prod 三级环境物理隔离体系；
2. 实现基于脱敏数据的轻量 Mock 数据库，实现单机自包含开发；
3. 掌握模型阶梯分流法则（Model Tiering）：在延迟、成本、推理深度之间取得工程平衡；
4. 运用 Pydantic / Schema 构筑输出确定性防线，拦截一切非法枚举与数值超界；
5. 掌握 AI 时代的双轨并行开发协同规范（Two-Track Parallelism），打破“一人写代码一人围观”的内耗；
6. 运行并通过 labs/lab03-env-isolation-tier/ 实操验证。

💣 现场惨案还原（The Murder Scene）

真实案情回顾（参见：

案例一：缺乏中间环境隔离，生产数据遭测试数据污染

项目第一周，为了追求所谓“极速交付”，团队只设置了“本地开发电脑”与“线上生产 ECS”两层。开发人员在本地写好代码，直接推送到生产机器上运行。随后业务测试人员进场验证功能，直接在生产系统上频繁提交测试用例：“测试订单 99999 元”、“测试取消订单 50000 元”。第二天清晨，电商数据看板显示部分区域指标异常激增，排查后确认正是前一天写入的测试脏数据。开发团队不得不耗费半天时间手动清理数据表并修正统计，影响了正常的业务分析。

案例二：过度依赖大参数模型，响应时延与调用成本上升

在实现自然语言问数功能初期，团队曾尝试所有查询均直接调用高参数大模型：

用户只要输入文字，无论内容简单与否，后端全部交由数十亿参数的模型处理；
对于“你好”、“在吗”等基础交互，响应时间达到 4 秒以上，用户端体验较为迟滞；
模型在返回结构化数据时偶尔夹杂发散性自然语言分析，导致前端反序列化失败并报错。后续团队对模型调用成本与性能进行了测算，意识到必须引入阶梯式分流与强类型 Schema 拦截。

案例三：AI 时代分工失灵，双人并行沦为“一人敲代码一人围观”

在项目冲刺期，团队投入了两名全栈 FDE，试图通过增加人手实现效率翻倍。然而现场出现极其尴尬的一幕：

一位 FDE 正在用 Copilot 快速生成前后端脚手架与 API 逻辑；
另一位 FDE 按照传统技术栈切分试图去写前端页面，却发现接口尚未完全稳定，频繁被代码改动打断；
由于两人都在改同一个业务仓库，多开编辑窗口与合并 Git 频频踩踏，导致在很长一段时间内实际上只有一个人在真正产出有效代码，另一人只能在旁围观或者打杂。直到团队紧急重构分工：一人负责确定性前后端系统底座工程，另一人抽离出来专门负责与业务专家对账、提炼指标 DAG 并深度调优 AI 问数提示词与 Eval 评测，交付吞吐量才实现指数级飙升。

🧠 核心心法与底层原理（The Mental Model）

1. Dev / Staging / Prod 三级隔离是系统交付的铁律

DDIA 中有一条铁律：未经验证的写操作绝不能触碰生产存储。在 FDE 体系中，三级环境必须各司其职：

Dev（单机沙箱）：开发人员在本地用 Docker 启动 MySQL、Redis、FastAPI，数据全靠脚本合成，哪怕全删了也毫无心理负担；
Staging（预发布隔离带）：这是给客户业务总监走查功能、核对财务报表的唯一指定安全场地。在这里即便测出 Bug，生产大盘也岿然不动；
Prod（神圣生产）：只接受经过 Staging 验证并打上 Git Release Tag 的自包含离线镜像。

2. Text-First 原则 7：不喂散装 Prompt，编译定向上下文

为什么模型会生成格式混乱的回答？因为你给它喂了垃圾上下文！如果直接在 Prompt 里贴上 10 张大宽表的完整 DDL（几千行文本），模型的注意力会被严重稀释，产生“迷失在中间（Lost in the Middle）”现象。

在 Text-First 架构中，上下文必须经过动态编译（Context Compilation）：

3. 模型阶梯分流法则（Model Tiering）

工业级 AI 系统绝不能搞“一刀切”。必须根据任务的计算密度与复杂度推行分层治水：

模型分层	典型参数规模	适用场景	响应延迟	成本估算	确定性要求
Tier 1 (轻量模型/正则规则)	1.5B ~ 7B 或规则引擎	意图分类、单实体抽取、简单问候、敏感词过滤	< 200ms	几乎为 0	100% 结构化
Tier 2 (代码特化模型)	14B ~ 32B	Text-to-SQL、多条件过滤转换、简单报表汇总	1s ~ 2s	较低	严格遵循 Schema
Tier 3 (深度思考大模型)	70B+ / 深度推理模型	跨渠道综合归因诊断、经营预警策略、高管洞察分析	3s ~ 8s	较高	允许富有洞察的长文本

4. Pydantic 强类型防御：守门员原则

任何大模型的输出都必须被当作**“不可信的用户输入”**。严禁用 json.loads() 裸解析！必须使用 Pydantic BaseModel 进行双重强校验：

静态类型断言：字段类型必须严格吻合；
业务枚举约束：例如 channel 必须且只能是 Literal["TMALL", "JD", "DOUYIN", "DAIXIAO"]；如果大模型擅自发明了 "PINDUODUO"，Schema 必须当场报错并熔断降级。

5. 双轨并行开发模式（Two-Track Parallelism）：解耦底座与业务

在传统研发时代，前后端按技术栈水平切分（一个写 UI、一个写 API）。但在 AI Agent 编程时代，单个全栈工程师配合 GitHub Copilot 能在极短时间内完成前后端垂直闭环。此时若盲目强行分工，两个人会频繁在同一个仓库里踩踏代码、互相等待未冻结的接口，导致严重的“通信内耗 > 产出提升”。

现场 FDE 团队的最佳协作模式是重塑组织拓扑，推行**“双轨异构垂直切分”**：

确定性工程底座轨（Platform Track）：主攻系统脚手架、环境部署、数据库迁移、安全组网关与 Trace 可观测性；其目标是高确定性、零停机与安全防护；
概率性业务效果轨（Eval & Domain Track）：主攻业务现场对账、提炼指标 DAG、优化 Prompt 与 Eval 评测套件；其目标是问数准确度与业务验收通过率；
契约先行（Contract-First）：双方仅需在第一天敲定 Pydantic Schema / OpenAPI 契约，即可借助 Mock 数据各自独立飞奔，彻底根除“一人写代码，一人干瞪眼”的协作僵局。

🛠️ 动手实验室（Hands-on Lab 03：编制模型阶梯与契约网关提示词工件）

实验信息

沙箱路径：labs/lab03-env-isolation-tier/
任务目标：分析 context/model_benchmarks.json 中的时延与成本反差，在 starter/prompt.md 中编写结构化提示词工件（交代 Tier 1 轻量小模型优先路由、低置信度升阶 Tier 2、Pydantic Schema 强类型约束枚举），指挥 AI 生成 gateway.py，并由 AI 依据本关 rubric.md 统一评分，验证其拦截大模型幻觉的能力。

核心提示词与验收断言要点

在 labs/lab03-env-isolation-tier/starter/prompt.md 中完整定义：

Pydantic 契约定义：限定渠道为 TMALL, JD, DOUYIN, DAIXIAO，限定置信度 0.0 <= confidence <= 1.0；
阶梯分流逻辑：Tier 1 置信度 >= 0.85 快速返回（<200ms），复杂归因升阶 Tier 2；
输出契约：导出 QueryIntent 与 route_and_validate(query)，必须通过非法渠道（如 PINDUODUO）与数值超界拦截断言。

触发 AI 评分

补全 starter/prompt.md 后，对 AI 说：

“用 fde-lab-scoring 技能，给 lab03-env-isolation-tier 评分并写改进建议。”

AI 依据本关 rubric.md（含 Tier 分流与 Pydantic 强枚举防幻觉要点）逐维打分并给出改进建议：

text

# 📊 实验评分单 · lab03-env-isolation-tier
致命漏项裁决：✅ 未命中（Pydantic 强契约拦截幻觉枚举、Tier 阶梯分流均已交代）
五维合计：91 / 100 → 🎉 PASS

统一评分技能见 labs/_scoring/。

🥊 避坑指南与常见死法（Antipatterns & Pitfalls）

反模式一：大模型返回空字符串直接当 0 处理

现象：大模型没有在数据库查到结果，输出 "" 或者 null，后端的 float(result) 直接抛出 ValueError。
解法：在 Pydantic 字段中使用 default=0.0，并在反序列化前通过预处理验证器（@field_validator）强制转换。

反模式二：把生产数据库连接串硬编码在代码或镜像中

现象：开发者本地测试直接连测试库，打包时把连接写在代码常数里，推到客户机器上跑引发网络不可达。
解法：12-Factor 原则。所有环境差异（数据库 IP、密码、API Key）严禁写入镜像，统一通过外部挂载的 .env 环境变量文件注入。

反模式三：双人协作在同一分支多窗口并行修改核心文件

现象：现场两位工程师在同一个主干分支上同时拉起多个 AI Agent 窗口分别改动前端和后端，导致本地未提交文件频繁被覆盖、Git 冲突不断。
解法：推行 git worktree 物理隔离 与 底座 vs 业务双轨制。涉及 Prompt 优化与测试集扩充的内容收敛在 prompts/ 独立目录，与底座核心代码解耦，互不干扰。

🏆 通关验收卡与装备获取（Checkpoint & Loot）

📋 本关通关自检清单

[x] 理解了三级环境隔离机制，规范发布与测试流程；
[x] 掌握了模型阶梯分流思想，实现成本与延迟优化；
[x] 熟练运用 Pydantic 作为大模型与前端之间的结构化约束层；
[x] 掌握了底座与效果双轨并行开发模式，消除人际内耗；
[x] 通过了 AI 依据 labs/lab03-env-isolation-tier/rubric.md 的统一评分（🎉 PASS）。

🎁 本关掉落装备

装备名称：【工程性能天平】
装备属性：Token 账单大幅优化，问数基础响应控制在 200ms 以内
装备描述：在轻量模型与深度模型之间自如切换平衡，并用强类型契约保障输出稳定性。

环境治理就绪，模型调用更加稳健！接下来我们将面对复杂的现场网络环境——《第四关：内网大突围 · 目标基础设施联调与高可用防御》！

03 · 第三关：工程炼金术 · 开发环境治理与模型适配 ​

⚔️ 本关作战任务（Context & Quest） ​

💣 现场惨案还原（The Murder Scene） ​

真实案情回顾（参见： ​

案例一：缺乏中间环境隔离，生产数据遭测试数据污染 ​

案例二：过度依赖大参数模型，响应时延与调用成本上升 ​

案例三：AI 时代分工失灵，双人并行沦为“一人敲代码一人围观” ​

🧠 核心心法与底层原理（The Mental Model） ​

1. Dev / Staging / Prod 三级隔离是系统交付的铁律 ​

2. Text-First 原则 7：不喂散装 Prompt，编译定向上下文 ​

3. 模型阶梯分流法则（Model Tiering） ​

4. Pydantic 强类型防御：守门员原则 ​

5. 双轨并行开发模式（Two-Track Parallelism）：解耦底座与业务 ​

🛠️ 动手实验室（Hands-on Lab 03：编制模型阶梯与契约网关提示词工件） ​

实验信息 ​

核心提示词与验收断言要点 ​

触发 AI 评分 ​

🥊 避坑指南与常见死法（Antipatterns & Pitfalls） ​

反模式一：大模型返回空字符串直接当 0 处理 ​

反模式二：把生产数据库连接串硬编码在代码或镜像中 ​

反模式三：双人协作在同一分支多窗口并行修改核心文件 ​

🏆 通关验收卡与装备获取（Checkpoint & Loot） ​

📋 本关通关自检清单 ​

🎁 本关掉落装备 ​