第 4 章 · 零基础技术底座
本章你会学到：FDE 的技术底座由哪五层构成，每层「必须懂什么、够用就好什么、可以先跳过什么」，以及怎么用大约 90 小时把这张底座搭起来。
一句话：FDE 的技术能力不是「会多少算法」，而是「能不能独立把一条请求从用户点下去，追到数据库，再追回来」。
一个现场片段
以下是合成场景，用于说明典型情境，不对应任何真实客户。
周三下午四点，客服中心。主管指着屏幕上转圈的页面说：「工单列表打不开了，刚才还好好的。IT 说他们上午调整了安全策略，但跟我们有什么关系？」
你没急着回答，先问了三个问题：什么时候开始的？所有人都这样，还是只有个别人？最近改过什么配置？答案很一致：十分钟前开始，整个客服组都这样，上午 IT 做过一轮账号权限调整。
你打开浏览器开发者工具，切到 Network 面板，刷新页面。GET /api/tickets 返回 500，响应体只有一行 {"error":"internal"}。你把这条请求复制成 curl 命令重放，结果一样，说明问题不在浏览器。接着翻服务日志，堆栈最后一行写着 permission denied for table tickets；再查服务的环境变量，发现它连接数据库用的账号被安全策略收紧了权限。
你给 DBA 发消息，十分钟后权限补齐，页面恢复。主管松了口气，问：「所以到底是什么坏了？」你说：「数据库账号权限被安全策略改掉了，接口本身没问题。」
这个片段里没有一行算法代码，但这就是 FDE 每天做的事：把客户嘴里的「坏了」，翻译成系统里的「哪一段链路、哪个环节、被什么改动影响了」。
技术地图：五层，不是五个专业
很多新人把技术底座理解成一长串书单：操作系统、计算机网络、数据库原理、分布式、机器学习……然后被劝退。方向错了。FDE 需要的不是五个专业，而是一张有优先级的五层地图：每层知道它负责什么、坏了会在哪个症状上表现出来、自己能验证到哪一步。深度按需补，宽度先铺开。
┌──────────────────────────────────────────────┐
│ 第 5 层 安全与可观测 │
│ 最小权限 / PII / 提示注入 / 审计 / 告警 │
├──────────────────────────────────────────────┤
│ 第 4 层 AI 与 LLM │
│ token / 提示词 / RAG / 工具调用 / 评测 │
├──────────────────────────────────────────────┤
│ 第 3 层 云与部署 │
│ 环境 / 密钥 / 日志 / 容器 / CI-CD │
├──────────────────────────────────────────────┤
│ 第 2 层 数据 │
│ SQL / 表结构 / 管道 / 口径 │
├──────────────────────────────────────────────┤
│ 第 1 层 计算机与网络 │
│ HTTP / API / JSON / DNS / TLS │
└──────────────────────────────────────────────┘
▲ 下层坏了，上层一定出症状；上层的问题，要从下层找原因| 层 | 你至少要懂 | 够用就好 | 现在可以跳过 | 自测动作 |
|---|---|---|---|---|
| 1 计算机与网络 | HTTP 方法、状态码、JSON、命令行、Git、一次请求要经过谁 | DNS、TLS、反向代理、超时与重试 | 内核调度、TCP 拥塞控制细节 | 用 curl 调通一个公开 API，并解释返回码 |
| 2 数据 | 写 SQL、看表结构、问清口径、抽样看数据 | 数仓分层、批/流处理、向量检索 | Spark 调优、数据治理全体系 | 从两张表关联出一张按天分组的报表 |
| 3 云与部署 | 区分环境、管密钥、看日志、跑容器、走一次发布 | Kubernetes 常用命令、基础设施即代码 | 多云架构、大规模成本优化 | 把一个小服务跑起来，改配置连另一个数据库 |
| 4 AI 与 LLM | token、上下文、提示词、RAG、工具调用、评测、幻觉 | 微调、agent 编排、成本优化 | 训练大模型、分布式推理 | 做一个能引用原文、会承认「不知道」的问答 demo |
| 5 安全与可观测 | 最小权限、PII、提示注入、越权、审计、告警 | 合规流程、等保基本概念 | 安全测评细节、渗透测试 | 找出一个越权风险并修掉，留下记录 |
学习顺序建议从下往上，但不必学完一层再进下一层。更有效的节奏是：每层都走三遍——先复现，再改，最后从零搭一个最小版本。能造，才算真的会。
第一层：计算机与网络——把「转圈」拆成链路
一个页面打不开，可能坏在十个地方。按链路一段段排除，一次请求要经过：浏览器解析域名（DNS）→ 建立加密连接（TLS）→ 网关或反向代理 → 应用服务 → 数据层 → 外部依赖 → 响应返回。
HTTP、API 与 JSON
HTTP 就是「客户端问一句，服务端答一句」。至少要能看懂请求的方法、地址、头、体，以及响应的状态码、头、体。状态码是最省时间的排障线索：
| 状态码 | 含义 | 通常是谁的问题 | FDE 的第一动作 |
|---|---|---|---|
| 200 / 201 | 成功 / 已创建 | — | 核对返回结构是否符合预期 |
| 400 | 请求格式不对 | 调用方 | 检查 JSON 字段、类型、必填项 |
| 401 | 没认证或凭证过期 | 调用方 | 查 token 是否过期、是否带对 |
| 403 | 认证了但没权限 | 权限配置 | 查账号角色与数据权限 |
| 429 | 被限流 | 调用方节奏 | 退避重试、降频、申请配额 |
| 500 | 服务内部异常 | 服务端 | 看日志堆栈，不要只盯着页面 |
| 502 / 504 | 上游服务挂了 / 超时 | 网关或上游 | 查依赖服务健康与超时设置 |
JSON 是接口之间最常见的「合同」。养成三个习惯：先拿一条真实响应看结构，别凭字段名猜；给空值和缺字段留位置；记住分页。
curl 是 FDE 的分水岭：它让你把「页面报错」从浏览器里剥离出来，单独验证服务端。
# 看完整响应头和状态码
curl -i https://api.github.com/repos/vitepress/vitepress
# 带鉴权头调用，只看返回体（地址是示意，换成你要排查的接口）
curl -s -H "Authorization: Bearer $TOKEN" \
"https://api.example.com/v1/tickets?page=1&size=20"判断标准很简单：你能不能让同一条请求脱离 UI 独立重放，并读到可解释的错误。
超时、重试与幂等
「失败就重试」听起来很稳，但如果请求是「创建订单」「发送短信」「扣款」，重试就可能变成重复下单、重复发送、重复扣款。
- 超时：每个外部调用都要设上限，默认值是灾难。
- 重试：只重试可重试的错误（网络抖动、429、5xx），并指数退避。「重试三次」常常是线上事故的直接原因，不是解决方案。
- 幂等：同一请求重复执行与执行一次结果相同，常用做法是带一个唯一的
request_id。写重试前先问：重复执行会不会多出一笔钱、一条消息、一条记录？
命令行与 Git
命令行（CLI）是远程排障的入口：登服务器、看进程、查端口、翻日志都靠它。Git 是协作与回滚的基础：拉代码、建分支、提交、开 PR、解决冲突、回退版本。两者都讲究每一步可重放、可追溯——至少要能在没有图形界面的机器上完成一次部署。
第二层：数据——先问口径，再写 SQL
AI 项目里，模型很少是第一个坏掉的环节，数据才是。Nabeel Qureshi 在 2024 年的一篇公开反思里提到（单一来源，原文细节待核），数据问题里九成五不是模型问题，而是接入、清洗和关联。这句话在真实项目里会反复被验证。
FDE 面对的不是教科书里的「大数据」，而是三类现实：找不到的数据、对不上的数据、没人说得清口径的数据。
必须会写的 SQL
不需要成为数据库管理员，但这些必须能独立写出来：
select / where / order by / limit：取数、过滤、排序。join，尤其是left join：把散在两张表里的信息拼起来，并处理「右表没有」。group by+count / sum / avg：做最基础的指标。case when：把原始码值翻译成业务分类；时间过滤：按天、按周聚合。- 窗口函数入个门：用
row_number()取「每个用户最新一条」。
-- 示例：每天各分类的工单量（示意表结构，不是真实客户数据）
select date(created_at) as d,
category,
count(*) as ticket_count
from tickets
where created_at >= date '2026-01-01'
group by 1, 2
order by 1 asc, 3 desc;数据管道与数据质量
一条数据从源系统走到你手里，通常要经过抽取、清洗、标准化、落表、加工指标。这条链上任何一段都会出错，所以你必须能回答四个问题：
- 这份数据从哪个系统来？谁是 owner？
- 多久更新一次？失败会不会有人知道？
- 字段口径是什么？空值代表「没有」还是「不知道」？
- 权限够不够、合不合规？有没有不该拿的个人信息？
拿到一张新表，先做「四查」：空值（关键字段空值率、集中在哪）、重复（主键是否唯一）、时间范围（从哪天到哪天、有没有断档）、分布异常（默认值、测试数据、机器人账号）。然后随手抽 20 条亲眼看一遍。这一步花不了十分钟，但能避免你基于错误理解做一周的活。
第三层：云与部署——让它在别人机器上也能跑
「在我电脑上是好的」最伤信任。FDE 的标准是：它在客户的测试环境里、用客户的账号、跑在客户的数据上，也是好的。
环境、配置与密钥
至少分三套环境：开发（dev）、预发/测试（staging）、生产（prod）。它们应该同构，区别只在配置和数据。你要能一眼回答：这个程序现在连的是哪个数据库、用哪个账号、调哪个模型服务。
配置和密钥永远不要写死在代码里。三条底线：不把密钥提交进 Git；不把密钥打印进日志、贴进群聊或演示 PPT；不用个人账号跑生产服务，用独立服务账号按最小权限授权。
日志与可观测
日志不是「出事了才翻的东西」，而是还原现场的唯一证据。规范日志至少包含时间、级别、请求 ID、路由、耗时、结果或错误码；涉及用户时用脱敏标识。日志要能回答：走到哪一步、调了谁、花了多久、在哪失败。字段固定下来，排查时间会从几小时降到几分钟。
容器与 CI/CD（持续集成 / 持续交付）
容器解决的是「环境一致」：镜像里装好运行所需的一切，到哪都能跑。你不需要成为 Kubernetes 专家，但要会写一个能跑起来的 Dockerfile、用一条命令构建镜像、用环境变量注入配置、看容器日志。
CI/CD 解决的是「每次改动都能安全地到线上」。一条最小可用的流水线只需要六步：
提交代码 → 静态检查/测试 → 构建镜像 → 部署到测试环境
→ 冒烟验证 → 人工批准 → 部署生产 → 保留回滚点判断一个人是否真的会部署，不看他会多少命令，看他在上线前能不能回答：**这次变更如果坏了，怎么在五分钟内退回去？**数据库结构变更、模型版本升级、配置修改这三类往往最难回滚，要提前设计。
第四层：AI 与 LLM——够用版
这一层的要求很具体：不用训练模型，但要判断需求该不该用模型、用什么形态、怎么证明有效。
token、上下文与成本
模型读写的单位是 token。上下文窗口（context window）是一次能塞进去的 token 上限，包含提示词、检索资料、历史和输出。
三件事要同时算账：质量、延迟、成本。成本约等于（输入 + 输出 token）× 单价；上下文越满，单次成本越高，模型对中段内容也越容易忽略——别把整本手册都塞进去。
提示词、RAG、工具调用与 agent
- 提示词（prompt）：把角色、任务、输入、约束、输出格式写清楚。要求结构化输出时，给出 JSON 结构，比说「请详细回答」有效。
- 检索增强生成（RAG, Retrieval-Augmented Generation）：先检索你的资料片段，再让模型基于片段回答并给出引用。它解决「模型不知道你公司的事」和「答案要出处」两个问题。
离线：文档 → 清洗 → 切块 → 向量化 → 建索引（附元数据：来源、权限、更新时间）
在线：问题 → 向量化 → 检索 top-k → 重排/过滤 → 拼上下文 → 生成答案 + 引用RAG 最常见的失败不是模型不行，而是切块碎了语义、检索没捞到正确片段、引用对不上原文、权限没隔离导致越权。
- 工具调用（tool / function calling）：模型输出「调用哪个工具、参数是什么」，你的程序执行后把结果交回。要严格控制工具白名单、参数校验、超时和权限。
- 智能体（agent）：让模型在「观察 → 思考 → 行动」的循环里多步完成任务，适合步骤不固定的任务；流程固定时，确定性流水线更稳、更便宜。
微调、评测与幻觉
**微调（fine-tuning）**不是万能药。它适合格式固定、风格要求高、分类边界专门训练、想用小模型降本的场景；不适合知识常变、需要引用、数据不足的情况。
| 需求特征 | 优先方案 | 代价 | 不要用它来做 |
|---|---|---|---|
| 规则明确、字段固定 | 规则/正则/映射表 | 维护成本随规则增长 | 处理模糊语义和长尾表达 |
| 需要引用内部资料 | RAG | 切块与检索调优、权限隔离 | 让模型凭空记住全部文档 |
| 风格/格式/分类边界稳定 | 微调小模型 | 标注数据、训练与版本管理 | 频繁变化的知识 |
| 任务复杂、通用能力不足 | 换更强模型或拆任务 | 成本与延迟上升 | 掩盖数据或流程问题 |
评测是最容易被跳过、也最不该跳过的一环。最少 30 条覆盖真实分布的测试用例，每次改提示词、换模型、调检索都跑一遍。没有评测集，你只是在凭手感调参。
**幻觉（hallucination）**指模型生成流畅但没有依据或错误的内容。它无法彻底消除，只能管理：给出处、限制范围、允许说「资料里没有」、高风险输出做结构化校验和人工复核。
第五层：安全与可观测——默认拒绝
安全不是上线前补的一张表，而是设计时的默认值。FDE 至少要守住五条线：
- 最小权限：服务只拿真正需要的权限；能只读就不给写，能按行授权就不给全表。
- 个人信息（PII, Personally Identifiable Information）：先识别哪些字段是个人信息，再决定能不能进检索库、日志、评测集。
- 提示注入（prompt injection）：用户输入、检索到的文档、网页、邮件都可能是攻击载荷。防御思路：不把外部内容当指令、工具白名单、高风险动作人工确认、输出校验。
- 越权访问：RAG 最容易踩的坑是「检索到了用户不该看的文档」。权限必须在检索前过滤，而不是生成后再删。
- 审计：谁在什么时候、用什么输入、得到什么输出，要能追溯；高风险动作必须留痕并尽量可回滚。
可观测性（observability）在 AI 场景还要记录：检索命中、有无引用、是否走「无答案」分支、用户反馈、人工修正、单次成本——这些就是评测素材。
上线前必须能回答的三个问题
- 这个功能被滥用时，最坏会发生什么？谁能一键关掉它？
- 用户数据会不会出现在日志、评测集或第三方请求里？谁批准过？
- 出了错误输出，多久能被发现、多久能修正、谁负责通知用户？
90 小时技术底座计划
90 小时分三段，每段 30 小时：每周 7-8 小时约 12 周，每周 5 小时约 18 周。关键不是时长，而是每段都留下可验证的产出。
| 阶段 | 小时 | 内容与每周动作 | 交付证明 |
|---|---|---|---|
| 基础 | 30 | 网络与接口 12h、命令行与 Git 8h、调试与日志 10h。第 1-4 周：用 curl 调通 3 个公开 API、跑通一个开源项目、记录 3 次真实排障 | 接口排障笔记 + 本地运行记录 |
| 数据与云 | 30 | SQL 14h、数据管道 6h、容器与 CI/CD 10h。第 5-8 周：写 10 条查询、清洗一份 CSV、把 demo 打成镜像并配自动构建 | 数据分析报告 + 可一键启动的仓库 |
| AI | 30 | 模型 API 与提示词 10h、RAG 与工具调用 10h、评测与安全 6h、复盘 4h。第 9-12 周：做一个带引用的问答、写 20 条评测、红队测试自己的 demo | RAG demo + 评测与安全记录 |
FDE 必会 20 个动作
只能「看别人做过」不算。逐条打勾，并在作品集里留下证据。
- [ ] 1. 用 curl 调用一个需要鉴权的接口，并解释返回的状态码
- [ ] 2. 在浏览器 Network 面板复现一次请求失败，定位到具体请求
- [ ] 3. 看懂一段完整报错堆栈，判断是应用、依赖、网络还是权限问题
- [ ] 4. 画出从用户点击到数据库的请求链路，标出 5 个可能失败的点
- [ ] 5. 给一个调用加上超时、有限重试和幂等保护
- [ ] 6. 用 Git 建分支、提交、开 PR，并解决一次合并冲突
- [ ] 7. 把别人的开源项目在本地跑起来，并说清它的依赖
- [ ] 8. 把写死在代码里的密钥挪到环境变量或密钥管理服务
- [ ] 9. 写 3 条有业务含义的 SQL，至少一条含 join 和分组
- [ ] 10. 检查一张新表的空值、重复、时间范围和异常值
- [ ] 11. 通过结构化日志还原一次请求的完整路径
- [ ] 12. 为一个接口写一份最小数据字典（字段、类型、口径、负责人）
- [ ] 13. 把一个服务打成容器镜像并在本地运行
- [ ] 14. 配一条 CI 流水线，让代码提交后自动跑测试
- [ ] 15. 走一次发布流程，并说明这次变更怎么回滚
- [ ] 16. 搭一个最小 RAG，能引用原文并处理「资料里没有」
- [ ] 17. 用工具调用让模型完成一次真实操作，并限制权限
- [ ] 18. 写 20 条评测用例，跑出基线并记录每次改动
- [ ] 19. 复现一次提示注入，并给出至少一条有效防御
- [ ] 20. 写一份上线前安全检查清单并逐条验证
常见误区
| 误区 | 典型表现 | 后果 | 正确做法 |
|---|---|---|---|
| 从训练模型开始 | 一上来学微调、买 GPU、跑开源权重 | 三个月过去，没有能用的业务功能 | 先用现成模型 + RAG 跑通价值，再谈微调 |
| 只会调 API，不会排障 | 接口一报错就等后端，日志看不懂 | 在客户现场失去可信度 | 把「20 个动作」当硬门槛练 |
| 把 demo 当生产 | 假数据演示很顺，真实数据一跑全是问题 | 承诺兑现不了，项目在试点阶段崩塌 | 从第一天起就用真实数据、真实用户、真实指标 |
| 先学完再上手 | 收藏了几十门课，一个项目没做 | 学习没有反馈，越学越虚 | 每个阶段都以一个可运行的小项目收尾 |
| 迷信新框架 | 什么新追什么，半年换三套技术栈 | 时间和维护成本被吃光 | 优先选客户环境能承接、团队能维护的方案 |
一句话判断标准
学完任何一项技术，问自己：**我能不能在客户现场、没有同事帮忙的情况下，用它定位或解决一个问题？**能，就是够了。
本章小结
- 技术底座是五层地图：网络与接口、数据、云与部署、AI 与 LLM、安全与可观测。下层坏了，上层一定出症状。
- FDE 的深度按需补，宽度必须先铺开；判断标准是「能不能独立排障和验证」，不是「学完了多少门课」。
- 每层的节奏相同：先复现，再修改，最后从零搭最小版本，并留下可验证的产出。
- 90 小时计划分三段：30 小时基础、30 小时数据与云、30 小时 AI；20 个必会动作是硬门槛。
练习
- **用 curl 调公开 API。**分别请求成功、不存在的资源、不带鉴权的私有接口，记录状态码并解释各是谁的问题。判断标准：三行状态码都能说清原因，并能把请求重放给别人看。
- **读日志找错误。**找一段真实或公开的报错日志，按「时间—请求 ID—错误码—堆栈—依赖」复原事件，写 200 字排障记录。判断标准：别人照着记录能复现定位过程。
- **写 3 条 SQL。**用任意公开数据集，写按天分组、两表 join、取每组最新记录各一条。判断标准：都能跑通，并写明业务含义和口径。
- **画一个请求链路。**选一个你常用的系统，画出从点击到数据返回的链路，标注 5 个可能失败的环节和排查方法。判断标准：没有跳步，失败点都有检查动作。
下一章：第 5 章 · 业务、数据与价值：先找痛，再找数，最后证明价值。
相关：实战 Lab 总览 · Lab A · 客服工单分流 · 附录 A · 术语表 · FDE 自评 · 第 8 章 · 生产化、评测与安全