跳转到内容
FDE 手册

课程大纲

Design approach: organize the complete knowledge map into modules and lessons without binding it to a fixed number of weeks. Each lesson includes detailed topics, learning outcomes, and estimated total study time. Modules can later be combined flexibly based on a learner’s background, goals, and weekly availability.

Curriculum principles: Less syntax, more systems. Start with the business problem. Add technical complexity only when the problem truly requires it. Puffo/Pavlov can serve as a rapid delivery abstraction layer, while the curriculum also explains the code, tools, state, data, permissions, and production engineering behind it.

生成于 2026-11-03。下载 CSV（英文）

这是公开版：所有模块都列在下面，但只有公开模块的页面可以打开。标有“完整手册”的模块只对 Azure Partners 团队开放。

模块概览

模块课数学习时长目的
M0 · 从这里开始：理解 FDE 角色31.5–3 小时Give readers who don't yet know what an FDE is a map before any engineering: what the role is accountable for, how it differs from neighboring roles, and which module builds the capability each stage of FDE delivery needs. Orientation only, no engineering detail.
M1 · AI 辅助开发与软件系统基础 完整手册628–42 小时Build a mental model of modern software systems for beginners or technically rusty learners, and enable them to read, run, modify, debug, and deploy code with AI coding tools. The focus is system understanding rather than syntax memorization.
M2 · AI 应用工程 完整手册628–43 小时Turn LLMs from “chat tools” into verifiable, integrable application capabilities. Use a Tutor / Customer Support RAG case to build foundations in prompting, RAG, tool calling, evaluation, and guardrails.
M3 · Agent 工程：从提示词到可扩展的 agent 系统 完整手册631–49 小时Define an agent as a job with real boundaries, give it reusable skills backed by code where needed, choose between a workflow, a single agent and multiple agents, and make its state, long-running work and failures manageable. An agent is not simply a prompt, and more agents are not automatically better.
M4 · 企业集成与生产级 AI 完整手册527–42 小时Teach learners that real customer environments involve data, APIs, permissions, security, deployment, observability, cost, and reliability beyond prompts/agents, and develop judgment about when deeper engineering is required.
M5 · FDE 需求发现、咨询与交付 完整手册739–62 小时Train the core capabilities that distinguish FDEs from typical AI Engineers: entering ambiguous customer environments, finding the real problem, defining outcomes, managing scope, making technical/business trade-offs, and driving pilots, acceptance, handoff, and productization.
M6 · 四个代表性 FDE 用例原型427–40 小时Use four realistic cases of increasing complexity to demonstrate the same FDE method repeatedly. Industry is the context; the goal is to understand why different business problems require different technical depth.
M7 · FDE 端到端实战 完整手册652–78 小时Learners choose an approved customer-style use case and complete a full FDE delivery from Discovery through Release/Handoff. This is the core job-search portfolio module and is not tied to a fixed number of weeks.
M8 · 就业准备与 FDE 面试 完整手册415–25 小时Turn real curriculum and practicum outputs into verifiable job-search evidence, and prepare for common FDE interviews in engineering, system design, problem decomposition, customer communication, and project deep dives.
完整路径47248.5–384 小时A complete knowledge and project pathway from near-beginner level to an entry-level / apprentice FDE job-search portfolio.

M0 · 从这里开始：理解 FDE 角色

目标： give readers who don't yet know what a Forward Deployed Engineer is a map before any engineering begins: what the role is accountable for, how it differs from neighboring roles, and which module builds the capability each stage of FDE delivery needs. Orientation only, with no engineering detail; read it first whatever your background.

3 课 · 1.5–3 小时 · Required for every background; read first

第 1 课 · 什么是 Forward Deployed Engineer？

0.5–1 小时

学习成果： Explain what an FDE is accountable for, place any FDE job on the four-responsibility model, and explain why the role needs engineering, AI, delivery and business context at once.

Row ID学习内容资源
M0-L1.1

Forward Deployed Engineer：Forward Deployed Engineer（FDE，前线部署工程师）是嵌入某个具体客户的工程师，他要对一个系统在该客户真实的系统、权限和工作流里跑起来、被用起来、产生可衡量的结果负责。

M0-L1.2

为一个客户交付多种能力：产品工程师为许多客户做一种能力，而 FDE 为一个客户交付多种能力，并帮助把在那里行之有效的东西变成下一个客户能用的产品。

M0-L1.3

FDE 的四类责任：一个完整的 FDE 要对一个由四类责任组成的闭环负责（Discovery、Production、Adoption、Feedback）：选出值得解决的客户问题，让方案在真实环境里安全运行，让真实用户真的用起来，并把一线经验带回产品。

M0-L1.4

Echo 与 Delta 分工：Palantir 把一线工作分成 Echo（驻场分析师，决定解决哪个问题）和 Delta（部署工程师，把它做出来）；很多公司把两者合在一个人身上，所以这种分工描述的是责任，而不是级别或技术栈。

第 2 课 · FDE 与相邻岗位

0.5–1 小时

学习成果： Compare an FDE with each neighboring role on responsibility rather than on who writes code, and use the three role tests to place a real job description.

Row ID学习内容资源
M0-L2.1

FDE 头衔的差异：FDE 这个角色没有行业公认的边界；不同公司用同一个头衔指代做模型优化的工程师、同时服务多个客户的交付工程师和驻场做原型的人，所以要按一个岗位负责什么来判断它，而不是按名字。

M0-L2.2

角色判据：比"写不写代码"更能区分 FDE 和相邻岗位的是三个问题：代码是否进入生产环境，一线经验是否回流到产品，工作是按时间还是按结果计价和考核。

M0-L2.3

FDE 与软件工程师、AI 工程师：软件工程师或 AI 工程师为许多用户构建并改进本公司的产品；FDE 从一个客户的问题出发，在产品之上做出这个客户需要的东西，并对它在那里是否起作用负责。

M0-L2.4

FDE 与解决方案架构师、售前工程师：售前岗位要证明一个方案行得通，以便赢下订单，通常在成交后退出；FDE 要在合同签下之后，对让它在生产环境真正跑起来负责。

M0-L2.5

FDE 与咨询、系统集成商：端到端的咨询公司同样可以把一个项目从 discovery 一路做到生产，所以区别不在谁写代码；FDE 在本公司的产品之上交付，并把学到的东西回流到产品，让服务下一个客户的成本更低。

M0-L2.6

FDE 与实施工程师、外包：实施团队和外包团队交付客户指定的东西，know-how 留在项目里，或者随人离开；一个 FDE 团队是不是换了名字的外包，取决于可复用的部分最后有没有进入产品。

M0-L2.7

FDE 与客户成功经理：客户成功经理让一个已经能用的产品持续被采用、被续约，基本不写代码；FDE 构建那个必须先跑通的客户定制部分，并共同承担让它被采用的责任。

第 3 课 · FDE 交付生命周期与手册地图

0.5–1 小时

学习成果： Name the lifecycle stages in order, say which module builds the capability each stage needs, and pick a reading path through the handbook from your background.

Row ID学习内容资源
M0-L3.1

FDE 交付生命周期：一个 FDE 项目会经历十个阶段（Qualify → Discover → Define → Build → Integrate → Evaluate → Deploy → Adopt → Handoff → Productize），它们归入四类责任：Discovery、Production、Adoption 和 Feedback。

M0-L3.2

生命周期与模块对照：FDE 生命周期的每个阶段都对应本手册的一个具体部分，所以模块零之后的 44 节课是一张能力地图，而不是一串主题。

  • 不需要外部资源。各模块的学时见模块总览，各模块的课程列表见该模块的导言。
M0-L3.3

手册阅读路径：读者根据自己的背景决定每个模块读到多深（Know、Use、Build 或 Design），跳过已经掌握的内容；模块零和模块七的实战项目对所有人都是必修的。

  • 不需要外部资源。大纲里的"背景路径建议"表给出了按模块的完整建议。

M1 · AI 辅助开发与软件系统基础 完整手册

目标： help beginners or technically rusty learners build a mental model of modern software systems and use AI coding tools to read, run, modify, debug, and deploy code. The emphasis is not memorizing syntax, but understanding how systems work.

6 课 · 28–42 小时 · Skip mastered modules based on the entry assessment

第 1 课 · AI 辅助开发

4–6 小时

学习成果： Set up an AI-assisted development workspace; read and modify small codebases; explain what submitted code actually does.

Row ID学习内容资源
M1-L1.1

AI 编程工作流：AI 编程工作流是一个反复执行的循环：说明需求、拆分任务、让 AI 生成代码、运行、检查结果、修改。做什么、结果对不对，始终由人来判断。

M1-L1.2

AI 编程工具：AI 编程工具有不同的形态：一种是自动补全，在你打字时建议下一行；另一种是智能体式工具，能自行读代码库、规划改动、编辑多个文件、运行命令。你用的是哪种形态，决定了在无人看管时你该多大程度上信任它的输出。

开发环境：开发环境是代码运行所需的终端、编辑器、项目文件夹、已安装的包和配置。所有 AI 编程工具都在这同一个环境里工作，而不是替代它。

上下文管理：上下文管理就是决定把什么放进 AI 的上下文窗口，也就是它实际能看到的文本，因为除了眼前的内容，AI 对你的项目没有任何记忆。

M1-L1.3

读懂代码：读代码靠的是模式识别：认出函数、变量、条件判断、循环、异常和模块这些所有主流语言共有的模式。所以你不需要精通某门语言，也能追踪它的代码在做什么。

M1-L1.4

AI 代码审查：审查 AI 生成的代码，就是让 AI 解释它写了什么、列出风险、编写测试，然后通过运行代码亲自确认每一个回答，而不是轻信它的解释。

第 2 课 · Web 应用如何运行

5–7 小时

学习成果： Draw the architecture of a simple application and explain how a request flows through the frontend, backend, database, and external services.

Row ID学习内容资源
M1-L2.1

Web 应用的分层：Web 应用不是一个程序，而是一组运行在不同地方的独立组件，它们来回传递消息，共同产出一个结果。

M1-L2.2

客户端-服务器模型：客户端是主动发起请求、开启一次对话的程序；服务器是等待请求并返回响应的程序。

IP 地址与端口：IP 地址标识网络上的一台机器，端口号告诉这台机器该由哪个程序接收流量。

进程与服务：进程是程序的一个运行实例，有自己的内存；它会一直运行，直到被某种原因停掉，无论是有意还是意外。

HTTP 请求与响应：HTTP 是客户端和服务器约定好的格式，用来交换一个请求和一个响应；两者都是纯文本结构，包含几个必需的部分。

HTTP 方法：HTTP 方法是请求里的动词，告诉服务器客户端想执行哪种动作；选对方法，其他程序才能对这个请求会做什么做出安全的假设。

状态码：状态码是每个 HTTP 响应开头的三位数字，让你一眼看出请求是成功了、失败了，还是需要再做点什么才能完成。

JSON：JSON 是一种用纯文本书写结构化数据的方式，浏览器里的 JavaScript 和后端的 Python 都能准确无误地读写它。

M1-L2.3

逻辑该放在哪一层：Web 应用的每一层运行在不同的机器上，由不同的一方控制；把安全检查或密钥放错层，是真实应用被攻破的常见原因。

M1-L2.4

完整的请求生命周期：在浏览器里点一下，就会触发一整串步骤：DNS 查询、建立连接、加密、发送请求、后端逻辑、返回响应；能顺着这条链路追下去，是找到真正故障点的最快办法。

第 3 课 · API、数据与集成

5–7 小时

学习成果： Read API documentation, call external services, inspect returned data, and diagnose whether integration failures come from authentication, networking, formatting, or business logic.

Row ID学习内容资源
M1-L3.1

REST 设计约定：REST 是一种 API 设计风格：每一份数据都是一个有自己 URL 的“资源”，你通过标准的 HTTP 方法、header 和查询参数来操作它。

API 认证：认证是 API 确认“谁（或什么程序）在调用它”的方式，通常靠每个请求都带上的一个密钥值；授权则是另一个问题：这个身份被允许做什么。

错误响应与超时：失败的 API 调用有两种情况：要么返回了一个状态码和一段你能读的错误响应体，要么在你愿意等待的时间内根本没有返回；这两种情况需要不同的处理方式。

限流：限流是对客户端在一个时间窗口内能发送多少请求（或多少 token）设定的上限，超出上限就会收到 429 响应，而不是正常的结果。

M1-L3.2

CSV 与表格：CSV 是一种扁平的纯文本格式，用来存储一行行数据，不强制类型；而数据库表会强制执行 schema。

关系模型：关系数据库把数据存放在相互关联的表里，这样相关的事实就不用在每个需要它的地方都重复一份。

Schema 与数据契约：schema 是两个系统约定好的某份数据的结构，这个约定就是一份契约，哪怕从来没有人把它写下来。

SQL 基础：SQL（Structured Query Language，结构化查询语言）是你和关系数据库打交道的方式：建表、插入数据，以及查询存储的内容。

M1-L3.3

Webhook 与轮询：轮询是反复问另一个系统“有变化了吗”，而 webhook 是在事情发生的那一刻由另一个系统主动调用你。

集成边界：不是所有系统都通过 REST API 交换数据；大量真实的集成工作靠文件投递、直接读数据库或现成的 SaaS 连接器来传数据，每种方式都有自己的格式、负责方和故障点。

集成故障诊断：调用外部 API 失败时，状态码和错误信息会告诉你问题属于四类中的哪一类：认证、网络、数据格式或业务逻辑。

M1-L3.4

数据规范化：规范化是指组织数据库，让每个事实只存储一次；这个词还有第二层含义：把来自不同来源的数据整理成统一的格式。

第 4 课 · Git、调试、测试与安全

4–6 小时

学习成果： Maintain a traceable code repository, diagnose common errors, and demonstrate basic security and testing awareness.

Row ID学习内容资源
M1-L4.1

Git 心智模型：Git 通过三个区域管理项目文件：你编辑文件的工作区，你标记要保存哪些改动的暂存区，以及永久保存快照的提交历史。

分支与合并：分支是一个指向某个提交、可以移动的指针，它为你提供一条独立的工作线，让你可以安全地修改；合并则把这个分支上的改动并回另一个分支。

Diff 与撤销提交：diff 精确显示一个文件的两个版本之间改了哪些行；revert（撤销提交）通过新增一个提交来抵消某个提交，而不是把旧提交抹掉。

Pull Request 工作流：pull request（PR）是在 GitHub 这类托管平台上发起的请求，要求把一个分支合并到另一个分支，中间加了一道审查环节。

M1-L4.2

日志与堆栈跟踪：日志和堆栈跟踪是程序留下的证据：日志记录程序做了什么，堆栈跟踪告诉你它在哪里崩溃。

复现、缩小范围、最小化：复现、缩小范围、最小化是一套可重复的方法，用来把 bug 一路追查到根因，而不是靠猜来修。

M1-L4.3

测试用例类型：测试就是用已知输入运行程序并检查结果的代码；完整的测试要覆盖正常输入、不寻常的输入，以及应该被拒绝的输入。

单元测试与集成测试：单元测试单独检查一小段代码；集成测试检查真实的各个部分（比如你的代码和一个真实的数据库）能否真正协同工作。

M1-L4.4

密钥管理：密钥（API key、数据库密码、token）永远不应该出现在代码或 git 仓库里，而应该通过专门为此设计的系统来存储和轮换。

输入校验：输入校验就是在使用来自用户、表单或外部服务的数据之前，先检查它是否符合代码的预期。

最小权限：最小权限是指每段代码、每个数据库用户、每个 API key 只拥有完成其工作所需的访问权限，不多给一点。

依赖风险：依赖是你的项目所依赖的、由别人编写的代码；依赖风险则是指这些代码存在已知安全问题、而你自己从未审查过的可能性。

第 5 课 · 容器与部署

5–8 小时

学习成果： Understand core containerization and cloud deployment concepts; deploy an application using existing platforms and diagnose common deployment issues.

Row ID学习内容资源
M1-L5.1

镜像、容器与镜像仓库：Docker 把应用连同它需要的语言版本、库和操作系统文件一起打包成一个整体，这个整体在任何机器上都以同样的方式运行。

卷与持久化：容器自身的文件系统会随着容器被替换而消失，所以任何需要保留下来的东西，比如数据库或用户上传的文件，都必须放在容器之外的地方。

端口映射：容器的端口对外是关闭的，除非你显式地把它连接到宿主机的某个端口上。

M1-L5.2

部署环境：环境是应用的一份独立副本，用于某个工作阶段，比如开发、测试或服务真实用户；把环境搞混，是“昨天还好好的”这类 bug 的常见原因。

计算选项：计算选项指的是代码在云上实际在哪里、以什么方式运行；主要的选择有 Serverless 函数、虚拟机和托管容器服务，它们在控制力、搭建工作量和成本上各有取舍。

M1-L5.3

配置：云上的应用从它所运行的平台读取设置，而不是从开发者笔记本上的某个文件读取，这样同一个镜像在每个环境里都能正确运行。

HTTPS、域名与证书：应用部署到某处之后，还需要一个人能读懂、DNS 能解析的地址，以及一张证明这个地址确实属于它的证书，这样流量才能通过加密的 HTTPS 传输。

M1-L5.4

部署日志：部署就是让应用在一台外界能访问到的服务器上跑起来，而读日志是弄清部署为什么失败的方法。

第 6 课 · 可靠性与扩展

5–8 小时

学习成果： Recognize reliability and scalability issues that appear when moving from demo to real usage, and judge when queues, retries, or concurrency controls are needed.

Row ID学习内容资源
M1-L6.1

同步与异步：同步请求会让调用方一直等到工作完成；异步请求则立即返回，工作另行完成。

队列与 worker：队列存放等待执行的任务，worker 是一个独立进程，负责从队列里取出任务并执行。

M1-L6.2

重试与退避：重试是在失败后再发一次同样的请求，退避则是把这些重试的间隔拉开，让吃力的服务有机会恢复。

超时：超时限定了调用方在放弃之前最多等待多久，而不是无限期地等下去。

幂等性：幂等操作无论执行多少次，最终结果都一样，所以安全地重试它永远不会产生重复。

M1-L6.3

竞态条件：当两件事几乎同时读取并修改同一份数据，而它们碰巧完成的先后顺序会改变最终结果时，就出现了竞态条件。

连接上限与连接池：连接池是应用预先打开、随时可复用的一小组连接，不必为每个请求新开一个连接，因为数据库能同时承受的连接数是有限的。

M1-L6.4

缓存：缓存是把数据的副本放在一个能快速读取的地方，这样每次再需要同样的数据时，应用就不必把慢的工作重做一遍。

负载均衡与水平扩展：当一台服务器扛不住流量时，要么把这台服务器升级得更强（垂直扩展），要么多跑几个副本、把流量分摊给它们（水平扩展），而后者需要负载均衡器。

数据库瓶颈：应用服务器是无状态的，很容易加；但数据库保存着真正的状态，所以应用一旦做了水平扩展，它往往就成了真正的限制。

M2 · AI 应用工程 完整手册

目标： turn LLMs from “chat tools” into verifiable, integrable application capabilities. Use a Tutor / Customer Support RAG case to establish foundations in prompting, RAG, tool calling, evaluation, and guardrails.

6 课 · 28–43 小时 · Skip mastered modules based on the entry assessment

第 1 课 · LLM 应用基础：从聊天到程序化使用

4–6 小时

学习成果： Call an LLM from code, explain model inputs and outputs, and understand that good chat behavior does not equal system reliability.

Row ID学习内容资源
M2-L1.1

大语言模型（LLM）与下一个 token 预测：大语言模型（LLM）是一个用海量文本训练出来的程序，它预测下一小段文本，所以是凭学到的模式一段一段地写出答案，而不是去查找事实。

M2-L1.2

Token 与上下文窗口：token 是语言模型读写的文本片段，上下文窗口则是一个请求所能容纳的固定 token 数量，模型的回复也算在内。

M2-L1.3

LLM API（请求、响应、流式输出、SDK）：LLM API 是你的代码所用的 Web 接口：把模型 ID、指令和消息发送给托管的模型，拿回它的回复、token 用量以及停止的原因，可以一次性返回，也可以流式输出。

M2-L1.4

消息角色、系统提示词与对话历史：LLM 请求是一个有序的消息列表，每条消息都标明了作者是谁；由于模型在两次调用之间什么都不记得，你的应用每一轮都要把整段对话重发一遍。

M2-L1.5

生成参数（temperature、top-p、最大输出 token 数、推理强度）：生成参数是每个请求上都可以调节的旋钮，用来塑造模型的回复：用词有多随机，最长能写多久，在哪里停下，以及先思考多少。

M2-L1.6

幻觉与其他模型输出失败：模型的一条回复可能以四种不同的方式失败（幻觉、格式漂移、指令冲突和上下文缺失），每一种都有各自的成因，也要在系统的不同部分修复。

M2-L1.7

聊天表现与系统可靠性：一次出色的聊天回答只能证明模型有能力完成任务，不能证明它在无人看管、大批量调用、软件又对返回内容照单全收的情况下，每次都能做对。

M2-L1.8

程序化 LLM 接口（输入、输出、错误、重试、日志）：程序化 LLM 接口把一个用自然语言描述的任务（比如“给这封邮件分类”）变成一个普通函数：输入经过检查，输出只有一种结构，错误都有名字，重试有上限，每次调用留下一条日志记录。

M2-L1.9

为现有服务添加 LLM 端点：LLM 端点是在现有后端里新增的一条窄路由（比如 POST /triage）：它在成本限制的把关之下调用模型，把模型的每种结果变成明确的 HTTP 响应，并且可以关掉。

第 2 课 · 提示词、上下文与结构化输出

4–6 小时

学习成果： Design reusable prompts and structured-output contracts, and explain why prompts may fail in different contexts.

Row ID学习内容资源
M2-L2.1

提示词结构：提示词结构是一份清单，列出生产环境的提示词要写明的各个部分（角色、目标、上下文、约束、示例、输出格式和拒答条件），让模型在每个请求上都用同样的方式做同样的事。

M2-L2.2

少样本示例：少样本示例（few-shot examples）是成对给出的示例输入和你想要的精确输出，放进提示词里，让模型照着它们的格式、标签和语气来写，而不用重新训练。

M2-L2.3

可复用的提示词模板：可复用的提示词模板，是只写一次、存成文件的提示词：固定的指令加上带名字的空位，由你的代码在每次请求时填入数据，并在发送前检查。

M2-L2.4

上下文工程：上下文工程就是决定每次调用时模型能收到哪些信息、从哪个来源取、在什么时刻给，让它拿到的事实集合尽可能小，又刚好够完成任务。

M2-L2.5

上下文污染与上下文腐化：上下文腐化是提示词变长后回答质量逐渐下降；上下文污染是提示词里混入无关、过期或相互冲突的内容所造成的质量下降。两者都不会报错。

M2-L2.6

结构化输出与 JSON Schema：结构化输出是指模型按你的代码事先定义好的形状返回数据，通常是由字段、类型和允许取值组成的 JSON Schema，这样软件就能直接使用这份回复。

M2-L2.7

提示词脆弱性与可移植性：脆弱的提示词只在写它的环境里有效，措辞、模型、输入或上下文一变就会失灵；可移植的提示词在这些变化下表现始终一致，而你手上的是哪一种，只有测试才能说明。

M2-L2.8

提示词版本管理与实验：提示词版本管理是给每一次提示词改动一个永久的版本 ID 和一条书面理由；实验则是一次只测试一处改动，并准确记录当时运行了什么、得到了什么。

第 3 课 · RAG 与知识库：辅导 / 客服助手

6–9 小时

学习成果： Build a basic RAG assistant that cites sources, identifies knowledge gaps, and escalates to a human when evidence is insufficient.

Row ID学习内容资源
M2-L3.1

检索增强生成（RAG）：检索增强生成（RAG）是一种模式：对每个问题，应用先在你的文档索引中检索，把最相关的段落放进提示词，再让模型依据这些段落作答并给出来源。

M2-L3.2

知识库准备（来源选择、解析、清洗）：知识库准备就是选定助手可以依据哪些文档作答，把它们转换成保留标题和表格的干净文本，并检查这些文档是否覆盖了真实用户会问的问题。

M2-L3.3

文本块切分：切分就是把每份文档拆成更小、自成一体的片段，这些片段叫文本块；文本块分别做向量化并单独检索，这样检索就能只把能回答问题的段落交给模型。

M2-L3.4

Embedding 与向量检索：embedding（嵌入向量）是一串按含义给一段文本定位的数字，向量检索则找出与问题的 embedding 最接近的已存 embedding。

M2-L3.5

元数据、过滤与新鲜度：元数据是随每个文本块一起存储的标签，比如版本、状态和受众；过滤条件用这些标签来决定哪些文本块有资格被检索，新鲜度则让索引与当前文档保持一致。

M2-L3.6

混合检索、重排序与查询改写：混合检索同时运行关键词检索和语义检索并合并结果，重排序器更仔细地重新排列排名靠前的候选，查询改写则先把问题修正好，这样正确的文本块就能送到模型面前。

M2-L3.7

基于来源与引用：基于来源（grounding）是指答案只能使用随请求提供的来源，引用则把每条陈述对应到它所出自的那个文本块，这样人或程序都能核对。

M2-L3.8

知识缺口与证据不足：知识缺口是指你的来源回答不了的问题；处理它，就是要发现缺失或相互矛盾的证据，回答“这一点不在我们的资料里”而不是去猜，并把缺口记入日志，好让有人去补上。

M2-L3.9

RAG 与替代方案（长上下文、微调、数据库、API）：RAG 是给模型补充所缺事实的方式之一，其他方式还有长上下文、微调、数据库查询和实时 API 调用；好的助手会把每个问题交给对该答案负责的那个来源。

M2-L3.10实践 Practice (no handbook page): turn course materials, FAQs, policies or product documentation into a Tutor / Customer Support Assistant that cites its sources and says so when the evidence is missing.

第 4 课 · Tool calling 与确定性逻辑

5–8 小时

学习成果： Separate model judgment from deterministic execution, design a verifiable tool, and enable the LLM to call it correctly.

Row ID学习内容资源
M2-L4.1

Tool calling（函数调用）：Tool calling，也叫函数调用（function calling），让模型请求你的应用，用结构化参数运行一个指定名称的操作（比如订单查询），而由你的代码决定是否运行，并完成实际工作。

M2-L4.2

工具调用循环与工具 trace：工具调用循环是一种反复进行的往返：模型请求一个工具，你的代码运行它，并以该调用的 ID 返回结果，同时由 trace 记录每一步。

M2-L4.3

模型判断与确定性代码：在可靠的 AI 功能里，模型负责模糊的语言类工作，比如理解意图、从杂乱的文本中提取事实；而凡是正确答案唯一、由规则决定的事，比如金额和日期，则交给普通代码。

M2-L4.4

正则表达式（regex）与校验和：正则表达式（regex）是一个简短的模式，描述一个值必须具有的形状；校验和是对这个值的各位数字做的一个小计算，用来发现手误；因此，一个 ID 格式是否正确，由代码而不是模型来判断。

M2-L4.5

工具 schema 与工具设计：工具定义就是名称、描述和参数 schema 这三样东西，模型靠它们判断何时、如何调用你的代码；好的工具设计让这些调用不容易出错，也容易测试。

M2-L4.6

工具参数校验：工具参数校验，是工具代码对模型提出的每个参数运行的一组检查：在改动任何东西之前，对照真实数据和业务规则，确认这些取值说得通。

M2-L4.7

工具结果与错误返回：工具结果是工具运行后或被拒绝后，你的代码发回给模型的内容；它必须清楚说明工具是成功了、什么都没找到还是失败了，以及下一步该做什么。

M2-L4.8

只读查询工具：只读查询工具让 AI 助手从掌管某个事实的系统里取得一个当前事实，比如成绩、订单状态或工单状态，并且不改动任何东西。

第 5 课 · AI 评测：证明它真的有效

5–8 小时

学习成果： Build a minimum viable evaluation set, document failure cases, and use evidence rather than intuition to judge whether changes improve the system.

Row ID学习内容资源
M2-L5.1

AI 评测：评测是对 AI 功能的可重复测试：用贴近真实的输入，配上事先写好的预期结果，尽可能自动评分，得出的分数可以在每次改动之后拿来比较。

M2-L5.2

评测集（正常、边界、失败、对抗性用例）：评测集是针对某个 AI 功能、带版本管理的输入清单：输入贴近真实，每条都配有它应有的行为，比如附上引用来源作答、拒答、升级转人工，或调用指定的工具。

M2-L5.3

错误分析与失败用例记录：错误分析是指阅读 AI 功能真实输出的一个样本，记下每次失败里出了什么问题，再把这些笔记分组并计数，据此决定先修什么。

M2-L5.4

核心评测指标（准确率、完整性、格式合规、拒答、延迟、成本）：核心评测指标是一次评测运行分别报告的几个数字（准确率、完整性、格式合规、拒答行为、延迟和成本），每个数字都有各自与客户商定的阈值。

M2-L5.5

RAG 评测（检索质量、groundedness、来源支持度）：RAG 评测在整个评测集上分阶段为基于检索的助手打分：检索有没有找到正确的来源，每条陈述是否都有来源支撑，以及每个引用是否真的支持它所对应的那条陈述。

M2-L5.6

人工评测：人工评测是指由人（最好是领域专家）对照书面指南，给一批抽样的 AI 输出打分，每条判定通过或失败并写明理由，用来界定“好”的标准，并产出团队可以信赖的标注。

M2-L5.7

LLM 裁判：LLM 裁判（LLM-as-judge）是指让第二个语言模型按书面评分标准（rubric）对另一个模型的输出大规模打分，并且只有在测出它的判定与人类专家的一致率之后，才信任这些判定。

M2-L5.8

提示词、模型、工具与数据的回归测试：回归测试是指在提示词、模型、工具或已索引的数据发生任何变更之后，用同一个评测集重新运行，并把每个用例与已批准的基线逐个对比，以确认以前能用的现在仍然能用。

第 6 课 · 安全、护栏与人在回路

4–6 小时

学习成果： Define basic safety boundaries and human checkpoints for an AI application, without confusing “the model can answer” with “the model is allowed to act.”

Row ID学习内容资源
M2-L6.1

输入与输出护栏：护栏是写在你自己代码里的检查，针对进入模型的内容、模型输出的内容和它打算执行的操作，所以模型永远没有最终决定权。

M2-L6.2

内容边界与敏感请求：内容边界策略是一份经客户批准的书面清单，列明 AI 助手哪些内容会回答、引导到别处、拒绝，或交给人处理，写得足够精确，能够执行和测试。

M2-L6.3

敏感数据与 PII 保护：敏感数据保护，是指不让个人信息和机密业务数据出现在 AI 功能用不到它们的任何地方，从提示词、模型供应商，到日志、trace 和回复。

M2-L6.4

提示词注入与越狱：提示词注入（prompt injection）是指模型读到的文本（来自用户，或藏在文档、工具结果里）覆盖了你的应用给模型的指令；越狱（jailbreak）则是说服模型越过它自己的安全规则。

M2-L6.5

未授权请求、按用户的访问权限与操作 gate：模型能回答一个请求，不代表它就被允许据此行动，所以任何操作执行之前，都由代码对照已登录用户的权限和硬性上限，检查每一次工具调用。

M2-L6.6

人在回路审批：人在回路（HITL）审批是一个检查点：代码把某个已获许可的具体 AI 操作暂停下来，等有人确认后才放行，只用于代价高昂或难以撤销的操作。

M2-L6.7

拒答与兜底：拒答是请求越界时设计好的回复，兜底是某个环节失败时设计好的回复；两者都会给出简短的理由和下一步。

M2-L6.8

升级通道与人工接管：升级通道是一条设计好的路径，由代码检查触发，把对话从 AI 助手转给合适的人并附上摘要，此后助手保持沉默。

M2-L6.9

记录已知局限：记录已知局限，就是依据证据把 AI 助手做不了、或不能放心交给它的事项写下来，然后在要紧的地方告知用户，并书面告知客户。

M2-L6.10实践 Practice (no handbook page): add escalation on checkable signals (not the model's self-rated confidence), sensitive-request blocking and human takeover to the Tutor / Support Assistant.

M3 · Agent 工程：从提示词到可扩展的 agent 系统 完整手册

目标： define an agent as a job with real boundaries (Profile, with Knowledge kept separate), give it reusable Skills backed by code where steps must repeat exactly, choose between a workflow, a single agent and multiple agents, then make its state, long-running work and failures manageable. An agent is not merely a prompt, and more agents do not automatically mean a better system.

6 课 · 31–49 小时 · Skip mastered modules based on the entry assessment

第 1 课 · 从 Profile.md 开始：定义边界明确的 agent

4–6 小时

学习成果： Define an agent with clear boundaries from business responsibilities rather than writing a one-line role prompt.

Row ID学习内容资源
M3-L1.1

AI agent：AI agent 是这样一种系统：语言模型在循环中自己选择下一步（调用哪个工具、怎样处理结果、何时停止），朝着目标推进，而这一切都发生在代码设定的限制之内。

M3-L1.2

Agent Profile（Profile.md）：agent profile 是一份简短的文档，把 agent 定义成一份工作（角色、目标、职责、禁止操作、输入、输出、升级条件和成功标准），它依据 agent 所服务的业务流程来写，而不是一句话的角色设定。

M3-L1.3

将 agent 知识与 profile 分离：将知识与 profile 分离，是指 agent 的 profile 定义它怎么做事、去哪里查东西，而价格、政策这类事实留在有人负责的来源里，由它在运行时读取。

M3-L1.4

Agent 职责与禁止操作：职责说明 agent 哪些工作自己负责、哪些只起草、哪些留给别人；禁止操作说明它绝不能做什么，每一条都通过不授予工具、代码检查或审批来强制执行。

M3-L1.5

Agent 输入、输出与升级条件：agent 的输入、输出和升级条件是 profile 中的一部分，规定它开始工作需要什么、必须交回什么并附上状态，以及何时停下来把决定交给别人。

M3-L1.6

Agent 成功标准与完成标准：成功标准在构建之前，用可衡量的方式说清 agent 做出的好成果是什么样；完成标准是每次运行在 agent 停止之前必须通过的检查清单。

M3-L1.7实践 Practice (no handbook page): write minimal profiles for Content Research, Draft and Review agents and compare their responsibilities.

第 2 课 · Skill：把 agent 能力拆分为可复用单元

5–8 小时

学习成果： Decompose a complex agent into maintainable, testable, reusable skills and identify where code is required.

Row ID学习内容资源
M3-L2.1

Agent Skills：Skill 是为某一类任务（比如对比同业公司、撰写备忘录）打包的一套有名字、可复用的步骤、检查和可选脚本，agent 只在任务需要时才加载它。

M3-L2.2

SKILL.md 文件与渐进式披露：SKILL.md 文件是打包一个 Skill 的 Markdown 文件：开头有一个简短的头部，说明这个 Skill 做什么、什么时候用，而渐进式披露（progressive disclosure）指的是 agent 只在需要时才读取其余内容。

M3-L2.3

Skill 拆分：Skill 拆分，就是把 agent 越来越长的大一统提示词拆成一个个独立的 Skill，每个 Skill 只负责一个步骤，输入和输出都能命名、能测试，而适用于所有步骤的规则仍留在 profile 里。

M3-L2.4

Skill 输入、输出与检查：Skill 的输入、输出和检查就是它的书面契约：开工前需要什么，交回的结果叫什么、结构怎样固定，以及这个结果在被任何人使用之前必须通过哪些测试。

M3-L2.5

纯指令 Skill 与代码支撑的 Skill：纯指令 Skill 是模型凭自己的判断去遵循的 Markdown 指引；代码支撑的 Skill 还会打包脚本，供 agent 运行那些必须每次完全一致的步骤，比如解析或计算。

M3-L2.6

Skill 组合与版本管理：Skill 组合是把多个 Skill 串成一条流程运行，每个 Skill 的输出交给下一个；Skill 版本管理则给每次改动一个永久的 ID，让生产环境运行经过测试的版本，并且可以回滚。

M3-L2.7实践 Practice (no handbook page): decompose a content-creation flow into research, outline, draft, review and revise skills.

第 3 课 · 工作流、单 agent 还是多 agent？

6–9 小时

学习成果： Choose the simplest viable architecture based on task complexity and risk, and justify the design with business reasons rather than “multi-agent is more advanced.”

Row ID学习内容资源
M3-L3.1

工作流与 agent：工作流由代码决定运行哪些步骤、按什么顺序，模型只负责完成其中的个别步骤；agent 则由模型自己决定下一步，包括用哪个工具、何时算完成。

M3-L3.2

工作流模式（提示词链、路由、并行化）：工作流模式是用普通代码连接模型调用的几种固定方式：提示词链（prompt chaining）按顺序运行各步骤，并在步骤之间加检查；路由把每个输入送上一条专用路径；并行化同时运行多个调用，再合并结果。

M3-L3.3

单 agent 系统：单 agent 系统就是一个 AI agent，带着自己的 profile、Skill 和工具，在一个循环里逐步选择下一步，直到任务完成、需要有人来处理，或者被某个限制叫停。

M3-L3.4

多 agent 系统：多 agent 系统把一个任务拆给多个 AI agent，每个 agent 有自己的指令、上下文和工具，换来并行工作和更干净的上下文，代价是更多的 token 和更难的协调。

M3-L3.5

选择 agent 架构：选择 agent 架构，就是挑出能可靠完成任务的最简单设计（从普通代码到多个 agent），并用风险、成本和可靠性方面的证据来为这个选择辩护。

M3-L3.6

在 agent 之间拆分工作：在 agent 之间拆分工作，是指只有当某项职责需要隔离的上下文、不同的工具或权限、独立审核或并行运行时，才给它单独配一个 agent；否则它就留作 Skill 或函数。

M3-L3.7

交接与 agent 契约：交接是把工作从一个 agent 传给另一个 agent；agent 契约则是这次交换事先约定好、可以检查的格式：任务、必需的输入、结构化的结果，以及带错误信息的状态。

M3-L3.8

审核与 critic 模式：审核或 critic 模式是增加一个步骤：在工作往下走之前，对照明确的标准检查它，把不合格的退回去修改，并在标准通过或达到上限时停止。

M3-L3.9实践 Practice (no handbook page): map a Content Operations flow (Research, Plan, Draft, Review) and mark each step as deterministic code, LLM or human, with a reason for each.

第 4 课 · 状态、记忆与上下文持久化

5–8 小时

学习成果： Design state and memory boundaries for agents, and distinguish “a lot of context” from reliable persistence.

Row ID学习内容资源
M3-L4.1

Agent 状态与记忆类型：agent 依靠五类信息工作（本次调用的上下文、对话、任务进度、关于用户的事实，以及跨任务保留的知识），每一类都有各自的生命周期、负责人和存储。

M3-L4.2

上下文与持久化存储：上下文是模型在一次调用中看到的内容，由你的应用每次重新构建；持久化存储则是进程之外的存储，在崩溃、重新部署或新会话之后，它仍然保有这项任务。

M3-L4.3

对话 thread 与会话：对话 thread（常被称为会话）是一次对话按顺序存储下来的记录，有自己的 ID 和负责人；你的应用每一轮都加载并续写它，聊天才能在以后恢复。

M3-L4.4

任务状态（计划、进度、产物）：任务状态是一项工作进行到哪一步的存储记录（目标、计划、已完成和待办的步骤、输出、待定的决定以及已用预算），它保存在模型之外，由代码更新，这样工作在暂停或失败之后可以恢复。

M3-L4.5

长期记忆与用户记忆：用户记忆是 agent 记下的关于某一个人的信息（偏好、已确认的约束、决定）；长期记忆是 agent 从过往工作中留下的内容（以往的分析、经验教训）；两者都存放在模型之外，由你的代码划定范围并加载。

M3-L4.6

记忆写入策略：记忆写入策略是一组由代码强制执行的规则，用来决定 agent 可以把什么存进记忆、以谁的话为准、附带什么来源和审核到期日，以及新事实如何取代旧事实。

M3-L4.7

记忆污染、过期与隐私风险：agent 记忆会在三个方面出问题：错误的或被人植入的事实不断重新冒出来，本来为真的事实过期了却仍在被使用，个人信息被保存得过久或被展示给了不该看的人。

M3-L4.8

持久化模式（工作区、landing pad、journal）：三种存储模式能让 agent 的工作在重启后保留下来：给单个任务存放工作文件的工作区，让成品等待下一步或等待人来取的 landing pad（成品中转区），以及记录每一步和每个决定的 journal（逐步记录的日志）。

M3-L4.9实践 Practice (no handbook page): let a Content or Finance agent remember prior analysis, user preferences and confirmed constraints, each stored with its source and date.

第 5 课 · 持久型 agent：队列、恢复、并发与人在回路

6–10 小时

学习成果： Understand persistent-agent execution and explain how tasks are queued, recovered, deduplicated, and paused for human approval at critical points.

Row ID学习内容资源
M3-L5.1

持久型 agent：持久型 agent（persistent agent）是任务比一次请求、一个进程活得更久的 agent：工作进入队列，每一步之后都保存进度，任务可以等上几天，也可以扛过崩溃或部署，然后接着做。

M3-L5.2

持久化执行（检查点、重放、恢复）：持久化执行（durable execution）运行多步骤任务的方式是：每个完成的步骤及其结果都保存在进程之外，这样崩溃、重新部署或重启之后，另一个 worker 可以接着做，而不必从头开始。

M3-L5.3

Agent 任务队列与 worker：agent 任务队列把每个 agent 任务保管到 worker 完成为止；配置得当，它能让任务扛过崩溃、把反复失败的任务单独搁置、先处理紧急工作，并让模型调用的节奏与限流相匹配。

M3-L5.4

有界执行（预算、步数上限、触发控制）：有界执行是指由代码给任何 agent 任务能消耗的资源设上限（步数、token、金额和时间），终止陷入循环或停滞的任务，并决定哪些事件可以触发一次模型调用。

M3-L5.5

重复执行与去重：重复执行，就是持久型 agent（persistent agent）在重试、崩溃或收到重复消息之后，把某一步再做一遍；去重则让这次重复认出第一次尝试，于是一笔退款、一封邮件或一次预订只会发生一次。

M3-L5.6

Agent 系统中的并发与过期状态：两次 agent 运行（或一个 agent 和一个人）同时修改同一个任务或记录时，就会出现并发问题；过期状态则是依据读取之后已经变化的数据来行动。

M3-L5.7

暂停 agent 等待人工审批：暂停 agent 等待人工审批，意思是保存它的状态和它提议执行的确切操作，释放原先运行它的 worker，等人在几分钟或几天之后做出决定时，再从那个点继续。

M3-L5.8

恢复测试（故障注入）：恢复测试，就是在任务进行到一半时故意弄坏一个持久型 agent（persistent agent），比如终止它的 worker、丢掉一次模型回复、把一条消息投递两次，再检查它是否从正确的步骤继续，并且没有任何东西被重复发送、重复支付或重复更新。

M3-L5.9实践 Practice (no handbook page): build a recoverable persistent agent on Puffo/Pavlov or an equivalent runtime, kill a worker mid-task, and confirm it resumes with no duplicate side effects.

第 6 课 · Agent 评测、追踪与调试

5–8 小时

学习成果： Locate failures within an agent workflow and use traces/evaluations—not endless prompt rewriting—to fix them.

Row ID学习内容资源
M3-L6.1

Agent 评测（任务、环境、结果）：agent 评测让 agent 在其系统的测试副本里完成完整、真实的任务，评的是那里发生了什么变化，而不是它说了什么，并且每个任务都要重复运行，因为每次运行的结果会有波动。

M3-L6.2

Agent trace（步骤、工具调用、交接、状态变化）：agent trace 是一个任务跨多个 agent 和 worker 的逐步记录：包含每一次模型调用、工具调用、交接和状态变化，附带输入、输出、错误、耗时和 token，全部归在同一个 trace ID 下。

M3-L6.3

Agent 系统中的失败归因：失败归因是指找出 agent 一次运行中第一个出错的步骤，并指明是哪个部分造成的：数据、指令、模型、工具、交接、业务规则、权限或限制。

M3-L6.4

Agent 级指标（任务完成率、交接、工具调用、循环、成本、延迟）：agent 级指标衡量一个 agent 系统完成整个任务的表现：完成的比例有多高，交接和使用工具有多规范，陷入循环的频率有多高，以及每完成一个任务要花多少钱、多少时间。

M3-L6.5

轨迹评测：轨迹评测（trajectory evaluation）给 agent 在一次运行中走过的步骤（调用的工具、参数、顺序、交接）评分，而不只看它最后停在哪里，这样侥幸通过，以及途中的违规，都能被抓出来。

M3-L6.6

Agent 工作流的可重放测试：可重放测试把一次 agent 运行变成可以重跑的场景：同样的输入、同样的初始状态、录制好的工具响应，再对照预期结果和关键步骤进行检查，全程不碰线上系统。

M3-L6.7

用 trace 和评测调试 agent：调试 agent，就是先复现一次失败，在它的 trace 里找到第一个出错的步骤，在原因所在的那一层修复（往往不是提示词），再用一个新测试和一轮评测来证明修复有效。

M4 · 企业集成与生产级 AI 完整手册

目标： show that real customer environments involve data, APIs, permissions, security, deployment, observability, cost, and reliability beyond prompts and agents. Learners should know when deeper engineering is required.

5 课 · 27–42 小时 · Skip mastered modules based on the entry assessment

第 1 课 · 外部 API、MCP 与连接器设计

6–9 小时

学习成果： Explain the difference between APIs and MCP, and connect external data or actions to agents through clear, replaceable interfaces.

Row ID学习内容资源
M4-L1.1

MCP 与传统 API 连接器：Model Context Protocol（MCP，模型上下文协议）统一了模型发现和调用工具的方式，但连接任何外部系统仍然需要做认证（authentication，简称 authn）、网络和失败处理这些实际工作，MCP 替代不了它们。

M4-L1.2

工具注册表、schema 与能力发现：工具注册表列出 agent 可用的工具，每个工具由一份 schema（它的输入、输出和用途）来描述；能力发现则是 client 在运行时了解 server 能做什么的方式，因此第三方工具和商业工具可以接入同一个插槽。

M4-L1.3

API 版本、限流与备用数据源：外部 API 会更换版本，限制你的调用频率，有时还按调用次数收费，所以一个经得起时间考验的集成要固定版本、遵守限流并准备备用数据源，而不是把某家供应商当前的行为硬编码进业务逻辑。

M4-L1.4

设计最小连接器契约：连接器契约是一份简短而明确的定义，说明一个工具或 API 如何暴露给 agent，包括它的输入、输出、错误类型、认证（authentication，简称 authn）和限流；把它设计好，集成才会可预测、可替换、安全。

第 2 课 · 认证、授权、RBAC 与密钥

5–8 小时

学习成果： Design a basic permission model and understand that prompts cannot replace real authentication and authorization controls.

Row ID学习内容资源
M4-L2.1

认证与授权：key、OAuth、会话与 token：认证（authentication，简称 authn）证明调用方是谁，授权（authorization，简称 authz）决定调用方能做什么；常见的机制，即 API key、OAuth token、会话和 JWT，则是系统在每个请求中携带这种身份和权限的具体方式。

M4-L2.2

RBAC、最小权限与读写权限：基于角色的访问控制（Role-Based Access Control）通过角色来授予权限，最小权限是指每个身份只拿到它需要的访问权限，而区分读与写是最基本也最重要的一条界线，尤其是在决定不同的 agent 和用户能查看什么、能执行什么的时候。

M4-L2.3

密钥管理、环境变量与轮换：密钥（API key、密码、token）必须放在代码之外的安全存储里，在运行时通过环境变量或密钥保管库注入，绝不能写进日志，并且要按计划轮换，一旦暴露就立即轮换。

M4-L2.4

与权限绑定的人在回路：高风险操作应当要求明确的人工审批，并由权限系统来强制执行，而不是在提示词里客客气气地请模型照办，因为提示词不是安全控制措施，而一个概率性的系统也不能对后果重大的操作拥有最终决定权。

M4-L2.5

企业 SSO（SAML/OIDC）与服务账号：企业 SSO 让员工通过公司的身份提供方（IdP），使用 SAML 或 OIDC 完成认证；服务账号（service account）则是供机器使用的机器身份，FDE 的集成几乎总是用服务账号来认证，而不是用某个人的身份。

第 3 课 · 真实世界的数据：质量、新鲜度、溯源与实体解析

6–9 小时

学习成果： Identify major risks in real data, design provenance/freshness/entity-alignment rules, and clearly state which conclusions remain unverified.

Row ID学习内容资源
M4-L3.1

脏数据：缺失、重复、过期与冲突：真实的客户数据里有缺失值、重复记录、过期记录、冲突条目和不一致的格式，这与演示所用的干净样例数据有本质区别，假设两者相同，正是方案在生产环境中出问题的原因。

M4-L3.2

新鲜度 gate、溯源与数据血缘：新鲜度 gate 会拒绝或标记旧到不能信任的数据，溯源记录每个值来自哪里，数据血缘（data lineage）追踪数据如何流动和转换，这样系统得出的每个结论都能追溯到可信的来源。

M4-L3.3

实体解析：实体解析（entity resolution）是借助匹配规则和合并策略，判断不同系统里的记录何时指的是现实中的同一个对象（同一个人、公司或产品），并对齐它们的 ID，让数据能跨系统可靠地关联起来。

M4-L3.4

示例详解：医疗机构名录的数据质量：医疗机构名录（医生的姓名、专科和联系方式）集中展现了现实中的每一种数据问题，而把它清洗一遍（去重、专科校验、联系方式新鲜度、人工确认），能让抽象的数据质量概念变得具体。

M4-L3.5

数据契约与 Schema 演进：数据契约是对系统之间所交换数据的字段名、类型和含义达成的一份明确、经过校验的约定；schema 演进则是让这个结构随时间变化，同时不悄悄破坏依赖它的系统。

M4-L3.6

PII/PHI 处理与合规基础（SOC 2、GDPR、HIPAA）：个人信息和健康数据必须做到最小化、受到保护，并遵守法律对存储、写入日志、发送给模型 API 的限制；FDE 需要对 SOC 2、GDPR 和 HIPAA 有基本的了解，才能在医疗和金融项目中安全地开展工作。

第 4 课 · 可靠性、成本、延迟与规模

5–8 小时

学习成果： Make basic performance and cost trade-offs and recognize when a demo architecture can no longer support real users.

Row ID学习内容资源
M4-L4.1

可靠性：超时、重试、降级、熔断器、批处理与缓存：模型和 API 调用会失败、变慢、被限流，所以生产环境的可靠性来自超时、带退避的重试、降级、熔断器、批处理和缓存，这是在某个依赖挂掉时仍能保持自身可用的标准工具箱。

M4-L4.2

成本模型：token、模型选择与何时改用代码：AI 功能按 token、按模型、按 API 调用、按存储和算力的用量花钱，所以控制成本就是衡量 token 用量、为任务匹配合适规模的模型、做缓存，并在确定性代码能胜任的地方改用更便宜的代码。

M4-L4.3

延迟预算与并行化：延迟预算是一次响应允许花费的总时间，而串行的 agent、多轮调用和工具链的耗时会迅速累加，所以要用流式输出、裁剪，以及并行化相互独立的步骤来管理它，并接受并行带来的额外复杂度。

M4-L4.4

扩展概念：并发、瓶颈与水平扩展：扩展说的是许多用户同时涌入系统时会发生什么，关键在于判断力：能看出系统会在哪里成为瓶颈（队列深度、数据库或 API 限流），并且知道通常的答案是水平扩展和队列，而不是靠硬扛，也不需要你自己搭一个巨大的集群。

第 5 课 · 部署、CI/CD、可观测性与生产就绪

5–8 小时

学习成果： Explain what an AI application still needs to move from a local demo to an internal pilot and production, and produce basic deployment/run evidence.

Row ID学习内容资源
M4-L5.1

构建、测试、部署与回滚：CI/CD 基础：CI/CD 是把代码从提交一路送到生产环境的自动化流程：构建、测试、部署，出了问题就回滚；FDE 需要理解并用好这个流程，而不是手工搭建复杂的流水线。

M4-L5.2

日志、指标、trace、健康检查与告警：可观测性就是从外部回答“系统现在在做什么，它健康吗？”，靠的是日志（事件）、指标（随时间变化的数值）、trace（一次请求的路径）、健康检查（它还活着吗？）和告警（出问题时通知我）。

M4-L5.3

版本记录：模型、提示词、数据、工具与配置：把所有影响行为的东西（模型、提示词、数据、工具和配置）的版本都记录下来，才能复现事故发生时系统的确切状态，也才能有意识地改动其中任何一项，而不是悄无声息地改。

M4-L5.4

Demo → MVP → Pilot → Production 成熟度阶梯：软件按 Demo、MVP、Pilot、Production 这几个阶段逐步成熟，每个阶段对工程和治理（可靠性、安全、可观测性、用户支持）的要求都更高，所以知道自己处在哪个阶段，就知道下一步需要什么，也能避免把 Demo 当成产品。

M5 · FDE 需求发现、咨询与交付 完整手册

目标： train the core capabilities that distinguish an FDE from a typical AI Engineer—entering ambiguous customer environments, finding the real problem, defining outcomes, managing scope, making technical/business trade-offs, and driving pilots, acceptance, handoff, and productization.

7 课 · 39–62 小时 · Skip mastered modules based on the entry assessment

第 1 课 · FDE 角色与端到端交付生命周期

4–6 小时

学习成果： Understand the full scope of FDE work, recognize that technical capability is only one part, and complete a personal skill-gap assessment.

Row ID学习内容资源
M5-L1.1

FDE 角色与相邻岗位：Forward Deployed Engineer（FDE，前线部署工程师）在单个客户的系统内构建并交付可运行的软件，解决该客户的具体问题；它不同于 SWE、AI 工程师、解决方案工程师、售前、实施、咨询和外包，这些岗位各自只负责 FDE 工作的一部分。

M5-L1.2

端到端交付生命周期：一个 FDE 项目会走完整个流程：Qualify（立项判断）→ Discover（问题发现）→ Scope（范围界定）→ Design（设计）→ Build（构建）→ Evaluate（评测）→ Pilot（试点）→ Handoff（交接）→ Product Feedback（产品回流），了解整个流程，你就不会在没弄懂问题之前急着动手构建，也不会在工作交接、经验回流之前就停手。

M5-L1.3

对结果负责与按时间计费：FDE 的工作按交付的结果衡量，而不是按计费的工时衡量，所以这个角色不只是“驻场写代码”：你要对客户的问题真正被解决负责，而不只是人到场、代码写完。

M5-L1.4

FDE 能力模型：八个维度：一个 FDE 的能力横跨八个维度：Systems、AI、Agents、Integration、Production、Discovery、Communication 和 Domain，不同的 FDE 岗位对它们的权重不同，所以了解这个模型，能帮你看清“好”是什么样子，以及该往哪里成长。

M5-L1.5

在客户环境中工作：FDE 的工作发生在客户的世界里，也就是他们的系统、数据访问、权限和测试环境；实际的本事是尽早拿到访问权限，并在典型障碍（账号开通延迟、安全审查、缺少测试数据）让构建停滞之前就把它们解除。

第 2 课 · 客户需求发现与利益相关方访谈

6–9 小时

学习成果： Run a structured discovery session, identify key stakeholders, real problems, and information gaps, and produce reviewable interview notes.

Row ID学习内容资源
M5-L2.1

需求发现访谈：需求发现访谈系统地摸清客户的业务目标、当前工作流、痛点、约束、支撑证据，以及实际由谁做决定，让你在提出方案之前先弄懂真正的问题。

M5-L2.2

提问技巧：5 Whys，区分事实、观点与动机：好的需求发现靠开放式问题和“5 Whys”从症状追到根因，并且仔细区分事实、观点与动机，绝不把客户说的第一句话当作需求。

M5-L2.3

利益相关方梳理：利益相关方梳理要找出所有影响项目或受项目影响的人：决策人、用户、技术负责人、数据负责人、安全与法务，以及怀疑者，让你知道需要谁的认同、依赖谁开放访问权限、谁的顾虑可能让项目受阻。

M5-L2.4

调和利益相关方相互矛盾的回答：业务、IT、运营和财务对同一个问题的描述各不相同，调和这些相互矛盾的回答（弄清各方为什么这样看，并找出共同的真相）是需求发现的一项核心技能，而回答相互矛盾并不意味着有人说错了。

第 3 课 · 现状 / 目标状态工作流梳理与需求拆分

5–8 小时

学习成果： Translate ambiguous requests into clear business workflows and identify where AI should actually intervene.

Row ID学习内容资源
M5-L3.1

梳理工作流：参与者、步骤、输入、输出、决策点、交接：梳理工作流，就是把客户的流程拆分成参与者、步骤、输入、输出、决策点、痛点和交接，这样在决定改什么之前，你能清楚地看到工作实际是怎么流转的。

M5-L3.2

分配步骤：自动化、AI、确定性代码还是人工：工作流梳理完之后，每个步骤最适合交给四种处理方式之一：简单自动化、AI 模型、确定性代码或人工，而为每个步骤匹配合适的方式，是设计 AI 辅助工作流的核心。

M5-L3.3

把“构建 AI agent”拆分成原子任务：像“构建 AI agent”这样含糊的需求，必须拆分成原子任务，并标明它们的依赖和失败边界，这样工作就变得可估算、可构建、安全，失败会被限制在明确的位置，而不是连锁扩散。

M5-L3.4

现状与目标状态：记录流程变更：现状（As-Is）是工作流今天的运行方式，目标状态（To-Be）是你的方案上线后它的运行方式；把两者都记录下来，也就是记录业务流程的变更，而不只是软件功能，才能把价值讲清楚，也让这项变更能被采用。

第 4 课 · 范围、PRD/SOW、验收标准与非目标

5–8 小时

学习成果： Write an implementable and testable mini PRD/SOW and protect the project from unlimited scope creep.

Row ID学习内容资源
M5-L4.1

范围：问题、用户、MVP、必须有 / 最好有、非目标：范围界定把需求发现的结果变成一份各方认可的计划，包括问题陈述、目标用户、MVP、必须有 / 最好有的划分、明确的非目标和依赖，让所有人承诺做同一件事，并让最小的有价值版本先交付。

M5-L4.2

PRD 与 SOW：PRD（Product Requirements Document）描述要做什么以及为什么做；SOW（Statement of Work，工作说明书）是一份合同性文件，界定项目范围、双方职责、里程碑、验收证据以及变更的处理方式，一个 FDE 项目往往两者都需要。

M5-L4.3

需求类型：功能需求、非功能需求与约束：需求分为三类：功能需求（必须做什么）、非功能需求（做得多好：速度、可靠性、安全）和约束（数据访问、安全、时间线这类固定限制），把每一条需求分好类并放进 PRD/SOW，就能避免交付一个能用却无法部署的功能。

M5-L4.4

可度量的验收标准：验收标准用可衡量的方式定义什么能证明一项交付物已完成，包括它的输入、预期输出、质量门槛、延迟、风险处理和人工审核要求，让“完成”成为一项客观的测试，而不是一种看法。

M5-L4.5

新请求分类：澄清、变更还是后续阶段：项目进行中收到新请求时，要给它分类（是对现有范围的澄清、对范围的正式变更，还是后续阶段的工作）并据此记录，让范围保持受控，不会悄悄吸收什么，也不会丢掉什么。

第 5 课 · 解决方案架构：选择最简单可行的架构

5–8 小时

学习成果： Choose the minimum viable architecture based on customer value, time, risk, and team capability, and explain how it can evolve later.

Row ID学习内容资源
M5-L5.1

架构决策树：先从可能行得通的最简单架构做起，只在需要时才升级，顺序是规则/脚本 → Web 应用 → RAG → tool calling → 工作流 → 单 agent → 多 agent，因为每上一级都会增加能力，同时也增加成本、延迟和失败面（failure surface）。

M5-L5.2

自建、采购还是配置：对方案的每个部分，决定是自建、采购现成产品，还是配置现有平台；并且知道什么时候该用 Puffo/Pavlov 这类平台，什么时候该用代码库、MCP 或定制服务，从而只把自建的精力花在能创造独特价值的地方。

M5-L5.3

架构假设：假设、风险与技术债：把需求转化成一个明确的架构假设，即“我们相信这个设计行得通，因为……”，并记录它所依赖的假设、可能让它失效的风险，以及你有意背上的技术债，这样就能检验并重新审视这个设计，而不是把它当成事实。

M5-L5.4

避免过早优化（以及哪些不能推迟）：把暂时用不上的工程复杂度往后推，比如规模化、缓存、繁复的抽象，但绝不要推迟安全和数据基线，因为这些基线事后补起来代价高昂甚至根本补不上，一旦跳过还会造成真正的伤害。

第 6 课 · 演示、反馈与变更管理

4–7 小时

学习成果： Run a demo for non-technical stakeholders and clearly explain trade-offs when new requests appear instead of agreeing unconditionally.

Row ID学习内容资源
M5-L6.1

演示驱动开发：演示驱动开发，就是按固定节奏演示一条窄而可运行的端到端路径，而不是攒一堆功能，等最后一次性揭晓，这样误解就能趁修正成本还低的时候尽早暴露。

M5-L6.2

展示真实失败，而不是干净数据的表演：在演示和评审中，要展示系统真实的失败、局限和后续步骤，而不是只在干净数据上演示一条精心挑选的正常路径，因为坦诚地展示失败能建立信任、让问题尽早暴露，而“干净数据的表演”（clean-data theater）会把风险一直藏到进入生产环境。

M5-L6.3

权衡谈判：拒绝而不失信任：当一个请求会突破范围、打乱工期或破坏一个已经跑通的系统时，要摆出技术约束和时间 / 成本方面的选项，就取舍展开协商，用建设性的方式说不（通常是“可以，代价如下”或“这一阶段不做”），而不是要么一味迁就，要么一口回绝。

M5-L6.4

形成闭环：反馈 → issue → 优先级 → 决策 → 变更日志：反馈只有形成闭环才有用：记录成 issue、排出优先级、做出决策，并写进变更日志，这样什么都不会丢，决策可以追溯，客户也能看到自己的意见得到了处理。

M5-L6.5

书面进度沟通：定期的书面进度更新（每周的进展和清晰的风险提示）能让远程的利益相关方不开会也保持步调一致，而把它做好（简洁、坦诚、先讲风险和请求）是面向客户的工作中一项不张扬的超能力。

第 7 课 · 试点、价值、交接与产品化

10–16 小时

学习成果： Design both business and technical metrics for a pilot and use evidence to explain project value and uncertainty. Hand a project over so others can run it and extract reusable assets rather than keeping all knowledge in one person’s head.

Row ID学习内容资源
M5-L7.1

设计试点：试点是面向真实用户、在真实工作中进行的受控上线，有明确的时长、成功标准，以及结束时的 go/no-go 决策，让你在全面投入生产之前，先看清方案在现实中的表现。

M5-L7.2

基线、成功指标、北极星指标与归因：以项目开始前测得的基线为参照来证明价值：用与业务结果挂钩的成功指标，加上一个能概括整体价值的北极星指标，并且如实对待归因，不要把模型指标当成直接的业务价值。

M5-L7.3

用户采用阻力：方案能跑，但没人用，照样失败；采用阻力（工作流的变化、培训需求、信任、人工审核的负担，以及组织层面的阻力）横在“已上线的系统”与“被用起来的系统”之间。

M5-L7.4

衡量价值与 ROI：ROI 把方案的影响翻译成业务语言：时间与成本节省、收入增长、风险降低，同时如实说明证据有多强，以及哪些部分不能归因于这个方案。

M5-L7.5

交接包：交接包是客户团队在没有你的情况下运行这个方案所需要的一切：安装配置、运维、权限、输入 / 输出、常见失败、重启与兜底流程，以及已知局限；你离开之后，你的工作能否延续，取决于它。

M5-L7.6

复盘：复盘是一份诚实的书面回顾：什么出了问题、为什么出问题、改变了什么、怎样避免再次发生；复盘要做到不追责，也绝不能变成成功宣传，这样一个结束的项目（或一次事故）才能留下经得起时间的教训。

M5-L7.7

将客户专属逻辑与可复用资产分离：交付之后，把只属于这个客户的部分与可复用的部分（提示词、Skill、评测集、连接器和模板）分开，让可复用的部分变成资产，使下一个项目更便宜、更快。

M5-L7.8

把一线经验回流到产品：项目里得到的一线经验（客户真正需要什么、产品在哪里不够用、围绕产品不得不另外做了什么），应当以排好优先级、可执行的方式回流给产品团队，这样产品会变好，之后的每一次部署也会更便宜。

M6 · 四个代表性 FDE 用例原型

目标： use four realistic cases of increasing complexity to repeatedly demonstrate the same FDE methodology. Industry is the context; the focus is understanding why different business problems require different levels of technical depth.

4 课 · 27–40 小时 · Skip mastered modules based on the entry assessment

第 1 课 · 辅导 / 客服 RAG

6–9 小时

学习成果： Understand and build one of the simplest enterprise AI applications, and recognize when RAG alone is sufficient.

Row ID学习内容资源
M6-L1.1

案例概览：辅导 / 客服 RAG：辅导或客服助手基于课程资料、FAQ、政策和历史问答来回答问题，为每个答案标注出处；资料没有覆盖的问题会如实说明，该转人工时就转人工。

M6-L1.2

Technical Design：课程客服助手：一份基于来源的客服助手参考设计：版本化的知识库掌管事实，检索提供证据，模型只负责转述和引用，策略代码决定何时回答、拒答或升级。

    M6-L1.3

    PRD：课程客服助手：一份参考 PRD，描述一个辅导 / 客服助手：基于教育机构自己的文档回答学生和客户的问题，为每个答案标注出处段落，拒答文档没有覆盖的问题，并把敏感情况交给人处理。

      M6-L1.4

      参考实现：n8n 版客服 RAG：The Technical Design built as three n8n workflows (ingest, answer, evaluate), with every gate in a deterministic node, every citation checked in code, and a clear list of what n8n does not do for you.

      M6-L1.5

      延伸：从 RAG 到客服 Agent：给助手配上课程状态查询、订单查询、创建工单等工具，只读的 RAG 系统就变成了客服 agent；而每一个会改变数据的工具，都会带来权限、确认和审计的要求。

      第 2 课 · 内容运营

      6–9 小时

      学习成果： Decompose a content-operations process into agents/workflows and understand that multi-agent value comes from separation of responsibilities, not agent count.

      Row ID学习内容资源
      M6-L2.1

      案例概览：内容运营：在 Puffo Marketing Studio 里，营销人员用自然语言提出海报、落地页或幻灯片需求，四个分工不同、模型也不同的 agent 把它变成一份经过审核、基于锁定模板构建的 HTML 素材；营销人员在本地浏览器编辑器中修改并导出 PNG，小改动不调用模型。

      M6-L2.2

      Technical Design：Marketing Studio：一份多 agent 内容工作室的参考设计：事实放在有负责人的文件里，文案和设计是类型化的交接，基于模板构建的 HTML 是唯一母版，独立审核者的批准绑定到具体产物，而联锁由代码执行，而不是靠 agent 记住。

        M6-L2.3

        PRD：Marketing Studio：Puffo Marketing Studio MVP PRD（工程评审草案，2026 年 8 月 27 日）定义了一个单客户、本地优先的系统：四个 agent 生成 HTML 营销素材，不懂技术的营销人员无需接触代码即可编辑和导出。

          M6-L2.4

          迁移：同一流程用于其他行业：Marketing Studio 的模式，即需求受理、依据标准事实撰写、独立审核、模板化设计和人工签发，可以迁移到任何需要持续产出受规则约束内容的业务。

            第 3 课 · 医疗机构研究

            7–10 小时

            学习成果： Break target-customer research and outreach into a verifiable data/automation pipeline and know which information requires human confirmation.

            Row ID学习内容资源
            M6-L3.1

            案例概览：医疗机构研究：Provider Research Factory 把"全美所有泌尿科医生"这样的群体查询变成一份经过核验的数据集：五个 Puffo agent 负责需要判断的工作，确定性的 Python 流水线完成每一次下载、筛选、关联和计数，两道人工 gate 分别卡在高成本和高风险的步骤之前，而系统中没有任何东西能联系执业者。

            M6-L3.2

            Technical Design：医疗机构研究：一份"agent 规划、代码构建"的数据产品参考设计：模型决定数据源、代码集和质疑意见，确定性流水线在会让构建失败的断言之下完成每一次下载、关联和计数，两道人工 gate 分别卡在高成本和高风险的步骤前，合规是一个无法绕过的函数。

              M6-L3.3

              PRD：医疗机构研究：Provider Research PRD（草案，2026 年 9 月 15 日）定义了一个五 agent 的 Puffo 系统：产出一份站得住脚的美国泌尿科医生名单，附定义文档、contact sheet 和构建记录，并且不具备联系任何人的能力。

                M6-L3.4

                迁移：同一流程用于其他目标群体：Provider Research 的方法，即约定的定义、确定性的构建、独立的挑战，以及随数据一起交付的联系规则，适用于任何潜在客户挖掘目标，从医生到学校再到制造商。

                  第 4 课 · 交易研究台

                  8–12 小时

                  学习成果： Understand why complex agent systems need multiple roles, tools, freshness controls, memory, and evaluation, and design a simplified research desk.

                  Row ID学习内容资源
                  M6-L4.1

                  案例概览：交易研究台：Trade Recommendation Desk 是 Puffo space 中由六个 AI agent 组成的团队，每周审阅一个固定的 10 只美股池；每个判断都由后端策略引擎基于两个市场信号生成，agent 负责审阅、挑战和解释，全程不涉及真实资金。

                  M6-L4.2

                  逐层增加复杂度：从一句"这只股票该不该买？"的 prompt 出发，每次只加入某个失败迫使你加入的东西，就会一层一层走到 Sprint 1 的研究台设计；其中每一层都是为了消除一种答案可能出错的方式。

                  Delivery Plan：交易研究台：Trade Recommendation Desk 交付计划把整个构建装进两名工程师的八周时间：拆成 35 个带可核对完成标准的任务，估算 71 天工作量对应 80 天可用时间，并固定了必须按顺序发生的里程碑。

                  M6-L4.3

                  PRD：交易研究台：Trade Recommendation Desk PRD（FDE 实习项目，2026 年 9 月）定义了六 agent 研究台必须做什么、八条永不违反的产品规则，以及团队如何判断项目已完成。

                  延伸：实习项目之后的研究台：研究台的后续阶段会补上这一版有意省略的内容；而它的核心模式，即掌管所有数字的确定性后端、负责解读和提出异议的 agent、发布检查以及按实际结果打分，可以迁移到其他高风险的决策支持问题。

                    M6-L4.4

                    Technical Design：交易研究台：一份在不断变化的数字之上做多 agent 决策支持的参考设计：确定性后端计算并存储每一个数值，agent 通过按角色限定的工具解读和提出异议，时点数据配合每次运行的截止时间，规则在只跑一次的 holdout 之前冻结，每个判断都经过发布检查，并按实际发生的结果打分。

                      M7 · FDE 端到端实战 完整手册

                      目标： learners choose an approved customer-style use case and complete a full FDE delivery from Discovery through Release/Handoff. This is the core portfolio module and is not tied to a fixed number of weeks; learners can progress based on their available effort.

                      6 课 · 52–78 小时 · Skip mastered modules based on the entry assessment

                      第 1 课 · 实战启动：需求发现与项目选择

                      6–10 小时

                      学习成果： Produce an approved Problem Brief and Discovery Pack demonstrating that the project is worth designing and building.

                      Row ID学习内容资源
                      M7-L1.1

                      项目选择：项目选择就是从获批领域中挑一个真实可信的客户问题，确保你能把它从需求发现一路做到交接，并且在动手构建之前让问题简报获得签字批准。

                      M7-L1.2

                      需求发现资料包：需求发现资料包由五份简短文档组成，用来证明你在动手设计之前，已经理解了客户的问题、相关人员、现有工作流、知识缺口和依赖。

                      M7-L1.3

                      项目验证：项目验证是一份书面检查，在你决定动手构建之前，确认项目真实、可解、有价值，并且能在你的时间和数据限制内交付。

                      M7-L1.4

                      Go / No-Go 决策：Go / No-Go 决策是一个检查点：你审视验证证据，从四条路径中选一条：继续推进、缩小范围、更换项目，或先做一次验证实验。

                      第 2 课 · 架构与 MVP 冻结

                      10–14 小时

                      学习成果： Produce an executable MVP design and explain each architecture choice, technical debt item, and deferred feature.

                      Row ID学习内容资源
                      M7-L2.1

                      Mini PRD 与风险登记表：Mini PRD 是一份两页的说明，写清你要做什么、怎么判断它可行；风险登记表列出可能让你停下来的因素，每一项都有负责人和应对措施。

                      M7-L2.2

                      解决方案架构图：解决方案架构图是一页纸的图，画出系统的组件、数据流、工具、记忆和人工检查点，让别人能在你动手构建之前评审它。

                      M7-L2.3

                      配置、Skill 还是写代码：对 MVP 中的每项能力，你都要决定是通过平台配置、可复用的 Skill、自定义代码来实现，还是有意推迟。

                      M7-L2.4

                      MVP 冻结与变更控制：MVP 冻结是在架构评审之后锁定范围；变更控制是一套小流程，决定之后提出的每个请求该怎么处理。

                      第 3 课 · Alpha 构建：打通第一条端到端主路径

                      12–18 小时

                      学习成果： Complete a reproducible Alpha Release proving that the core business path runs from input to output.

                      Row ID学习内容资源
                      M7-L3.1

                      端到端薄切片：端到端薄切片是指在构建其他任何东西之前，先让一个范围很窄的问题走完整个系统，从用户输入一直到最终答案。

                      M7-L3.2

                      可复现的环境搭建：可复现的环境搭建是一份记录下来的“配方”，涵盖 profile、Skill、代码、工具、数据和配置，让别人能从零重建你的 Alpha，并得到相同的行为。

                      M7-L3.3

                      运行日志与失败分诊：运行日志记录系统在每次测试运行中每一步做了什么；分诊是指优先修复那些阻断真实工作流的失败。

                      M7-L3.4

                      Alpha 通过条件：当另一个人只凭你的说明，就能把系统从输入跑到最终输出时，Alpha 就算通过。

                      第 4 课 · 评测与加固

                      10–14 小时

                      学习成果： Complete a Beta with evaluation results, a failure report, and prioritized reliability improvements—not just a successful demo path.

                      Row ID学习内容资源
                      M7-L4.1

                      评测集与基线：评测集是一份固定的测试用例清单，覆盖正常、边界和失败三类情况；基线则是 alpha 版本在你做任何改动之前，在这份清单上拿到的分数。

                      M7-L4.2

                      失败归因报告：失败归因报告针对每个没通过的评测用例，说明是系统的哪个部分导致了失败，这样你修的是原因，而不是症状。

                      M7-L4.3

                      针对性加固：针对性加固是指只在观察到的失败或明确的风险确实需要时，才加上护栏、兜底或重试之类的保护措施。

                      M7-L4.4

                      已知局限与修复清单：已知局限是你没有修复的问题，要如实写下来，并配上一份按优先级排序的后续修复清单。

                      第 5 课 · 试点 / 代理用户测试与候选发布版本

                      8–12 小时

                      学习成果： Use real or proxy-user evidence to determine whether the system is worth continuing and complete a demonstrable Release Candidate.

                      Row ID学习内容资源
                      M7-L5.1

                      代理用户测试：代理用户测试是指请真实用户，或与他们非常接近的人，在你的系统上完成贴近实际的任务，你在一旁观察并记录。

                      M7-L5.2

                      反馈分诊：反馈分诊是把测试者的意见分成个人偏好、真正的 bug 和缺失的需求三类，让你修该修的东西，其余的则是有意识地不做。

                      M7-L5.3

                      回归重跑：回归重跑是指在修复之后再次运行关键评测用例，证明你没有把原本能用的东西弄坏。

                      M7-L5.4

                      候选发布版本：候选发布版本是你认为已经可以交接的版本，它被冻结并打上标签，同时写明了支撑证据、未解决的问题和后续步骤。

                      第 6 课 · 客户演示、利益相关方答辩、交接与复盘

                      6–10 小时

                      学习成果： Complete an end-to-end FDE project suitable for interviews and a portfolio, demonstrating not only agent building but full delivery ownership.

                      Row ID学习内容资源
                      M7-L6.1

                      客户演示叙事：客户演示叙事是讲述项目故事的固定顺序：问题、原有工作流、解决方案、真实运行的系统、证据、局限和价值。

                      M7-L6.2

                      利益相关方压力测试：利益相关方压力测试是一场现场问答：评审人扮演客户，不断抛出新需求和反对意见，而你要用时间、成本和风险来回应，而不是什么都答应。

                      M7-L6.3

                      交接包提交：交接包是你交给客户的一个文件夹，让客户自己的人在没有你的情况下，也能运行、重启并理解这个系统。

                      M7-L6.4

                      个人复盘：个人复盘是你自己对项目写下的回顾：哪里失败了、为什么、你会改变什么，以及哪些部分可以复用到下一个客户。

                      M8 · 就业准备与 FDE 面试 完整手册

                      目标： turn real curriculum and practicum outputs into verifiable job-search evidence, and prepare for common FDE interviews covering engineering, system design, problem decomposition, customer communication, and project deep dives.

                      4 课 · 15–25 小时 · Skip mastered modules based on the entry assessment

                      第 1 课 · Portfolio、Case Study 与 Resume Packaging

                      4–6 小时

                      学习成果： Turn course outputs into a credible, explainable, and verifiable FDE resume and portfolio.

                      Row ID学习内容资源
                      M8-L1.1

                      Case Study 结构：Case study 是按固定顺序写成的一个项目的书面记录——Problem → Discovery → Architecture → Trade-offs → Build → Eval → Failure → Outcome → Next Step——让读者能跟上你的判断，而不只是看到你的产出。

                      M8-L1.2

                      基于证据的简历条目：一条简历 bullet 要写出范围、数据、接口、评估和结果——五个审阅者可以核验的具体事实——而不是"Built an AI agent"这种动词加流行词。

                      M8-L1.3

                      成熟度标注：你展示的每个项目都带四个标签之一——Demo、MVP、Pilot 或 Production——把项目标到高于它实际达到的等级，是最快失去面试官信任的方式。

                      M8-L1.4

                      作品集构成：FDE 作品集是一个写成完整 case study 的深度 capstone，加上三个各证明一项不同能力的小型 case artifacts，全部标注成熟度，全部链接到审阅者能打开的东西。

                      第 2 课 · Coding / Debugging 与 System Design 面试

                      4–7 小时

                      学习成果： Explain and modify code in interviews and complete practical system designs aligned with FDE work.

                      Row ID学习内容资源
                      M8-L2.1

                      实用型 Coding 与 Debugging 轮：FDE coding 轮测的是你能否读懂陌生代码、找到并修复 bug、带着正确的错误处理接入 API，并解释每一个决策——包括你和 AI 编码工具一起做的那些——而不是你能否背出算法套路。

                      M8-L2.2

                      端到端 AI 系统设计：FDE system design 轮要求你设计一次跨 frontend、backend、data、tools、agents、state、auth、deployment 和 observability 的真实客户部署，评分看你说出的取舍多于你画出的框。

                      M8-L2.3

                      MVP 优先的设计演进：设计轮里，你先从证明风险最高部分的最薄端到端路径开始，然后一次加一个组件并说明理由，而不是在前五分钟画出一整套分布式架构。

                      M8-L2.4

                      技术债与架构变更故事：每个候选人都应能解释自己项目里的一条真实技术债和一次真实架构变更——它是什么、为什么接受或做出、代价是什么、学到了什么——因为这两个故事证明项目是真的，而且做决策的人是你。

                      第 3 课 · FDE Case：Problem Decomposition 与 Customer Simulation

                      4–7 小时

                      学习成果： Structure ambiguous customer problems, propose verifiable solutions, and communicate with non-technical stakeholders.

                      Row ID学习内容资源
                      M8-L3.1

                      模糊问题澄清：当客户说"用 AI 提高销售/效率/研究质量"时，前十分钟属于六个问题——目标、用户、workflow、数据、baseline、constraints——面试官评分的是你有没有在提出任何方案之前先问它们。

                      M8-L3.2

                      现场 Scoping：现场 scoping 就是当场说清第一版做什么、不做什么、怎么验证、什么时候停——一份带 non-goals 的口头 PRD，把拆解后的问题变成客户能说"是"或"否"的计划。

                      M8-L3.3

                      Stakeholder 模拟：Client-simulation 轮让你坐到一个角色扮演的怀疑者、技术负责人或业务负责人对面，评分看你是否针对每一位改变解释方式、承诺内容和反驳方式——同时不改变什么是真的。

                      M8-L3.4

                      处理未知：当你不知道时，得分的答案是"我还不知道——这是我一周内弄清它的方法"：承认缺口，说出最便宜的能填补它的实验，给出日期，而不是当场编一个自信的答案。

                      第 4 课 · 岗位匹配、面试叙事与求职策略

                      3–5 小时

                      学习成果： Define a personal job-market position, project narrative, and follow-up skill-gap roadmap, and identify which FDE/adjacent roles fit best.

                      Row ID学习内容资源
                      M8-L4.1

                      FDE 与相邻岗位：Forward Deployed Engineer、Applied AI Engineer、Solutions Engineer、AI Consultant 及其邻近岗位，不是靠"写不写代码"区分，而是靠模块零的三个问题——代码是否进入生产、现场经验是否回流到公司自有的产品、岗位是否按结果考核——知道你想要哪组答案，决定了你投哪里、怎么讲故事。

                      M8-L4.2

                      基于背景的叙事：你的面试叙事是一座从"你已经做过的事"通向 FDE 工作的桥——Domain Expert → FDE、Backend → FDE、AI Engineer → FDE、Startup Generalist → FDE——最结实的桥是"我已经非正式地做过这份工作，这是证据"。

                      M8-L4.3

                      STAR 与项目深挖：Behavioral 轮和项目深挖是同一种能力的两个方向：STAR 给一个 60–90 秒的故事一个形状（Situation、Task、Action、Result），FDE 版本再加上判断、取舍、失败和复盘，让面试官听到你怎么决策，而不只是发生了什么。

                      M8-L4.4

                      技能缺口学习计划：技能缺口计划就是在 FDE 八个能力维度上，用四个熟练度等级——Know、Use、Build、Design——给自己打分，与目标岗位的期望对比，把差距变成一份短小、带日期的"要建的东西"清单，而不是"要读的东西"。