跳转到内容
FDE 成长手册FDE 成长手册

FDE 作品集：用交付证据证明你能上线

FDE（Forward Deployed Engineer，前线部署工程师，也常译作前沿部署工程师）作品集最有效的做法，是用一个端到端旗舰项目证明：你找对了问题、做出了合理取舍、交付了可运行系统、验证了业务结果，并为上线后的风险负责。它的任务不是证明“我会调用模型 API”，而是让陌生人能沿证据复核这五件事。

核验日期：2026-08-19。 本页依据公开 FDE/FDSE 岗位描述中反复出现的客户协作、端到端工程交付与生产落地职责，给出作品集制作方法；它不是任何公司的官方录用标准。

如果时间有限，先做 一个证据完整的旗舰项目，不要堆三个只有聊天界面的演示。可从企业 RAG + MCP 项目开始，把每一阶段的交付物留在仓库中。

最低证据标准

标题“最低证据标准”

一个可发布的 FDE 案例至少应覆盖下面九项。每项都应指向文件、测试结果、演示或仪表盘，而不是只写一句结论。

需要证明什么 最低可接受证据 更强的证据
问题真实且值得解决 目标用户、当前工作流、失败成本与约束 访谈纪要、基线数据及经确认的 Discovery Brief
范围可交付 in/out scope、验收标准、时间盒 需求变更记录和为什么拒绝某些功能
方案有判断 架构图及至少一项关键取舍 ADR 中比较备选方案、成本与风险
系统能复现 README、环境示例、种子数据、一条启动命令 CI、自动化测试、预览环境或录屏复现
效果经过评测 数据集说明、指标定义、基线与结果 分切片结果、失败分类、回归集和原始运行记录
权限与数据受控 数据分级、威胁清单、无密钥提交 RBAC/租户隔离测试、审计日志与攻击性测试
上线后可运营 结构化日志、健康检查、故障处理说明 SLO、追踪/仪表盘、告警演练和回滚证据
交付能被接住 操作说明、限制和交接清单 试点反馈、培训材料及后续负责人确认
你的贡献可辨认 明确个人负责与协作边界 commit、决策记录或带日期的工作日志

证据强度四级

标题“证据强度四级”
  • L0 — 声称： “系统很稳定”“答案准确”。没有测量方法，不能作为证据。
  • L1 — 展示： 截图、架构图或一次成功演示。能说明做过，但无法复核。
  • L2 — 可复现： 有数据、命令、版本和预期输出，别人可以重跑。
  • L3 — 经使用验证： 有真实或明确标注的试点用户、基线、结果与限制。

旗舰项目的核心链路至少达到 L2。若没有真实客户，不要把同学测试或合成数据写成“生产落地”：明确标注为模拟企业场景，记录数据来源、假设和外部有效性限制，同样可以展示严谨度。

推荐的仓库证据结构

标题“推荐的仓库证据结构”

文件名不必完全一致，但读者应能在两次点击内找到关键证据。

your-fde-project/
├─ README.md                    # 结果摘要、演示、快速开始
├─ docs/
│  ├─ discovery-brief.md        # 用户、流程、问题、范围、指标
│  ├─ architecture.md           # 系统边界、数据流、部署图
│  ├─ decisions/                # 关键 ADR
│  ├─ threat-model.md           # 数据、权限、滥用与缓解措施
│  ├─ runbook.md                # 告警、排障、降级、回滚
│  └─ handoff.md                # 培训、限制、负责人、下一步
├─ evals/
│  ├─ README.md                 # 数据来源、指标与运行方式
│  ├─ dataset.jsonl             # 去敏后的黄金集/回归集
│  └─ results/                  # 带版本和时间戳的原始结果
├─ src/                         # 实现
├─ tests/                       # 单元、集成与权限边界测试
├─ .env.example                 # 仅变量名，不含秘密
└─ SECURITY.md                  # 报告漏洞和安全边界

README 首屏只需要完成四件事：一句话说明为谁解决什么问题；给出演示入口；列出经过测量的结果；提供最短复现路径。技术栈清单放在这些内容之后。

用“决策链”讲项目

标题“用“决策链”讲项目”

项目叙事不要从“我用了 React、Python 和某模型”开始。按下面顺序写，能让技术与商业价值互相印证。

  1. 场景： 谁在什么工作流中做什么决定？原来的耗时、错误或风险是什么？
  2. 模糊点： 一开始缺少哪些信息？你如何通过访谈、数据抽样或原型把它们变成可验证假设？
  3. 边界： 本次明确做什么、不做什么；四周版本与理想终局有何区别？
  4. 关键决策： 列出至少两个真实选项、选择依据，以及你主动接受的代价。
  5. 交付节奏： 先验证了哪个最大风险？客户或测试用户的反馈如何改变了下一版？
  6. 结果： 与同一数据集上的基线比较，并同时报告质量、延迟、成本、安全或采用情况。
  7. 运营与交接： 谁会收到告警、如何降级、如何回滚、谁拥有后续维护权？
  8. 复盘： 哪些结论仍不确定？如果再有两周，你会先验证什么？

可以把案例摘要压缩为这一段：

为 [用户] 的 [工作流/决策]，我在 [约束] 下交付了 [范围]。相比 [同口径基线]，系统在 [数据集/试点] 上使 [指标] 从 [A] 变为 [B]，同时守住 [质量/安全/成本门槛]。我负责 [个人范围]；当前限制是 [限制]，完整证据见 [链接]。

如果 A、B 尚未测得，就写“待测”，并展示测量计划。诚实的空白比虚构百分比更有说服力。

结果页应该展示什么

标题“结果页应该展示什么”

不要只给一个总体准确率。至少同时展示：

  • 业务结果： 任务完成率、处理时间、返工率或被采纳率；说明口径和样本量。
  • 质量结果： 按关键场景切片，尤其展示高风险、长尾与失败样本。
  • 系统结果： 端到端延迟、错误率、单任务成本和依赖故障时的行为。
  • 安全结果： 越权、提示注入、敏感数据泄露等测试是否通过。
  • 变化解释： 哪一次决策带来了变化，是否存在质量与成本之间的交换。

保留失败样本。FDE 的可信度来自你能界定系统何时不可靠，并为此设计人工复核、降级和停止条件。

发布前做一次红队式自检

标题“发布前做一次红队式自检”
  • 仓库从全新环境能否按 README 启动？链接是否公开可访问？
  • 结果是否带数据版本、代码提交、模型/提示版本、日期与运行配置？
  • 是否误提交客户名称、个人信息、访问令牌、内部 URL 或受限数据？
  • 架构图是否与当前实现一致，而不是最初设想？
  • 所有数字是否能追溯到原始结果？样本量和失败项是否同时展示？
  • 团队项目中，是否清楚区分你的工作、同伴工作与第三方能力？
  • “生产”“企业级”“实时”等词是否有对应证据？没有就改成准确表述。
  • 是否提供字幕/文字版演示、清晰标题与图片替代文本？

用仓库中的 templates/portfolio-rubric.md 自评，再请一位不了解项目的人只按链接复核。对方找不到的证据，等同于不存在。

从作品集到机会

标题“从作品集到机会”

为不同读者准备同一证据的三种入口，而不是维护三套故事：

入口 长度 读者要带走什么
简历项目项 2–3 行 问题、你的动作、可核验结果与项目链接
案例页 3–5 分钟阅读 决策链、关键证据、限制和你的贡献
深入材料 可复现 代码、评测原始结果、运行手册与决策记录

教程站负责让学习者和同行验证你的方法；个人主站负责承接真实案例与合作判断。想看这套证据如何出现在实际 AI 落地中，可以查看作者的项目案例；如果你的团队已经有场景、但问题边界或验收方式仍不清楚，可以讨论一次项目诊断。

完成后进入面试准备，把每份作品集证据转换成可追问、可演示、可诚实回答边界的故事。

来源与边界

标题“来源与边界”

岗位名称、职责和招聘流程会随公司、团队、地区与时间变化。投递时以目标岗位当日发布的信息及招聘方沟通为准。