跳到正文
观猹观猹学社

把结营项目变成 FDE 的下一张门票

把需求、方案、Skill、系统接入和 Eval 证据重新组织，让结营项目成为求职作品或独立交付案例。

✦全文约 6100 字 阅读需 22 分钟 王十一 最近更新 2026.08

01课程介绍#

本节课讨论 FDE 项目完成后的两条路径：进入企业，把项目转化成简历与作品集；或以独立交付者身份，把它转化成第一个真实案例。

课程会从岗位画像、简历、作品集、面试与商业闭环出发，帮助你把技术过程翻译成可信的业务价值。

你将学到什么

  • 识别真正的 FDE 岗位与对应能力模型。
  • 把项目过程整理成可核验的简历、作品集与交付证据。
  • 理解 FDE 面试关注的问题诊断、工程判断与沟通能力。
  • 建立从发现需求、完成交付到获得下一次机会的成长路径。

02课程回放#

正在准备课程回放…
这节加餐课解决什么问题 前五天回答了“怎样完成一次 FDE 交付”，Day 6 回答的是“交付完成后怎样继续往前走”。 一条路是进入企业，把项目转化为求职证据；另一条路是不投简历，把它转化为第一个真实订单。

03课程课件#

完整课件正在载入…

04项目完成后，有两条路#

  1. 求职路线 搞清岗位画像，重写简历，整理作品集，并针对 FDE 的拆解面、学习面、工程面和客户模拟做准备。
  2. 独立路线 从小而真实的需求开始，以付费诊断、目标交付和长期陪跑形成 Solo FDE 的商业闭环。

两条路并不冲突。一个完整、可解释、可量化的交付案例，既能帮助你敲开岗位的大门，也能帮助你获得第一位客户的信任。接下来所有动作，都围绕“如何把项目变成可信证据”展开。

05先看清 FDE 的角色分工#

FDE 是 Forward Deployed Engineer，强调工程师进入业务前线，在高模糊度环境中和客户一起解决问题，并对落地结果负责。它不是“Frontend Deployment Engineer”，也不等于一个人包揽销售、咨询、开发、部署和运维。

课程借用 Palantir 的角色体系，把最小 FDE 小队拆成 Echo 与 Delta。

角色 核心职责 关键能力 典型产出
Echo 发现业务问题、建立客户关系、解释行业规则并翻译需求 行业经验、访谈、判断、沟通与预期管理 问题定义、业务边界、优先级与验收标准
Delta 理解需求、快速做原型、反复打磨并完成生产交付 软件工程、Agent、系统集成、评测与部署 可运行系统、测试证据、上线与运维方案
Solo FDE 在一个熟悉领域中同时承担 Echo 与 Delta 的核心工作 业务与工程双语能力，以及完整商业责任 从诊断、签约到交付和陪跑的完整结果
先判断自己站在哪一侧 行业经验深、擅长发现问题和处理关系，可以先从 Echo 方向切入；工程基础扎实、能快速实现和稳定交付，可以先做 Delta。只有当业务判断和工程交付都经得起真实项目检验时，才适合独立承担 Solo FDE。

为什么 AI 让 FDE 在今天更重要

AI 作为 Echo 助手快速阅读行业材料，连接分散知识，辅助形成更完整的问题地图和方案假设。
AI 作为 Delta 助手通过 AI Coding 加速原型、集成、测试和文档，但工程师仍要为生成代码负责。
AI 作为翻译层把业务对象、关系和动作翻译成数据结构、接口与机器可执行规则。

企业里经常存在三套语言：业务人员说“客户”，系统里写“客户主数据”，管理者口中可能直接说“王总”。FDE 的任务不是机械抄录词语，而是建立同一对象在业务、数据和系统之间的映射。AI 能降低这种本体梳理的成本，但最终定义仍需要行业专家和工程师共同确认。

06识别真正的 FDE 岗位#

国内岗位名称尚未统一。除了 FDE，还可能写成解决方案架构师、交付工程师、AI 应用工程师或 Agent 产品方案工程师。判断时不要只看 Title，要看职责里是否同时出现两个信号：进入客户现场与对落地结果负责。

课程给出的五道压力测试

  1. 薪资是否依赖销售提成如果主要收入来自签单提成，岗位可能更接近售前或销售，而不是交付负责人。
  2. 工程实现是否占足够比重如果完全不写代码、不做系统和评测，通常很难承担 Delta 责任。
  3. 现场经验能否反哺产品真实问题是否能沉淀成平台能力、组件、方法或下一次可复用的资产。
  4. 在签单前还是签单后进场纯签单前演示更像售前；签单后仍持续负责实现、验收和运行，才更接近 FDE。
  5. 有没有需求纠偏权限真正的 FDE 不只是执行清单，还要能指出错误目标、缩小范围并推动客户作出取舍。
高薪背后是高责任 课程展示的海内外岗位和薪资仅代表录课时的公开样本，实际招聘状态与待遇应以最新 JD 为准。FDE 往往伴随驻场、频繁出差、高压沟通和更高燃尽风险，不能只看岗位热度和薪资上限。

07一份 FDE 简历要发出四个信号#

  1. 端到端负责 你是否从模糊问题开始，一直负责到上线、验收或明确停止。
  2. 直接面对客户 你是否和客户或业务方访谈、澄清、管理预期并推动决策。
  3. 进入生产环境 你的成果是否真正被使用，是否处理过权限、异常、监控和运维。
  4. 结果可以量化 是否能用通过率、覆盖率、时间、成本或人工介入比例描述改变。
FDE 简历不是证明你用了多少技术，而是证明你有负责到底的态度，并给客户带来了可以验证的真实改变。

项目描述公式

有责任感的动词 + 你构建的东西 + 客户上下文 + 可量化结果。

写法 示例 问题或价值
弱表达 协助客户搭建数据管道 不知道你负责什么、做到哪一步，也没有结果
强表达 为一家大型零售客户负责端到端数据管道部署，统一 12 个分散数据源，将首次洞察周期从三个月缩短到三周 责任、对象、环境与结果都可以被追问和验证

项目经历尽量使用“我负责”“我设计”“我交付”，不要用含混的“我们”。如果确实是团队协作，要写清你的边界、关键决策和个人贡献。

推荐的简历骨架

  1. 一句话定位写清你服务的场景、能承担的角色和结果，例如“能够进入业务现场完成 AI 应用落地的交付工程师”。
  2. 核心技能只写能经得起追问的能力，例如 Agent、Python、TypeScript、RAG、MCP、Docker、云平台与评测。
  3. 项目经历按业务背景、需求边界、方案选型、量化结果和可复用资产展开。
  4. 工作经历突出与客户、业务和生产系统有关的责任，不重复堆技术名词。
  5. 教育背景保持简洁，为项目证据留出主要版面。

对于 FDE 岗位，交付过什么通常比在哪里待过更重要，因此项目经历可以放在工作经历之前。关键词负责通过机器初筛，真正打动面试官的是完整项目证据。

不要把工具调用包装成工程能力 简历写了 Agent、RAG 或 MCP，就要能解释架构、边界、失败与验证过程。AI 帮你写代码没有问题，但不要用“只会 Vibe Coding”作为能力描述。你需要理解并验证生成结果，对进入生产的每一部分负责。

把 Day 1 到 Day 5 变成能力证据

课程产出 简历中的能力表达 可以附上的证据
Day 1 需求清单与流程图 独立完成企业场景需求挖掘，识别问题、角色与范围边界 访谈记录、现状流程、问题优先级
Day 2 SOW 将模糊诉求拆解为带验收标准、排期与责任人的交付模块 范围、非目标、里程碑与验收表
Day 3 Skill 将业务规则封装为可测试、可复用的 AI 能力单元 Skill 文档、边界案例与调用结果
Day 4 系统接入 完成企业系统的 MCP 或 API 集成，并设计权限与异常处理 架构图、接口说明、失败路径与人工兜底
Day 5 Eval 构建验收测试集，输出量化结论并完成一次回归迭代 测试集、基线、通过率与迭代报告

没有商业数据，也可以量化

质量指标测试通过率、任务成功率、覆盖场景数、专家采纳率。
效率指标单次任务耗时、人工小时、人天对比、首次结果时间和成本变化。
边界指标异常类型数、风险等级、拒答与澄清比例、人工介入点数量。

例如：“验收通过率达到 87%，覆盖 12 类边界场景，其中 3 类设置人工兜底。”这句话没有虚构收入，却能展示工程判断和交付成熟度。

08作品集不是 GitHub 仓库数量#

FDE 作品集的核心是一段完整交付故事：怎样从模糊需求走到可量化结果。招聘方要看的不是页面有多漂亮、Star 有多少，而是你有没有处理过真实约束、失败路径和生产问题。

一个案例至少包含六部分

  1. 业务背景谁遇到了什么问题，这个问题为什么值得解决。
  2. 需求与边界本次解决什么、不解决什么，风险和假设是什么。
  3. 方案与取舍为什么选择当前技术、流程和人机分工。
  4. 交付过程原型、系统接入、评测、上线和客户反馈怎样推进。
  5. 业务结果用质量、效率、成本或边界指标描述结果。
  6. 失败复盘哪些案例失败、如何定位、怎样修复，还有什么暂未解决。
失败案例是可信度证据 只有成功截图的作品集很难判断是否真实。把 Day 3 的 Skill 边界和 Day 5 的失败用例写进去，说明你如何定位、修复、回归，以及哪些风险仍需人工处理，更能体现真实交付经验。

同一个案例，准备三种颗粒度

载体 适用场景 重点
猹馆项目长文 公开传播与完整复盘 过程、判断、证据和个人方法论
GitHub README 技术审阅与项目入口 业务问题、架构、运行方式、评测与已知限制
一页 PDF 投递或面试前快速阅读 背景、职责、方案、数字结果和案例链接

作品集必须守住脱敏红线

客户名称改写为“华东某制造企业”等无法反向识别的行业描述。
业务数据替换为结构相同的模拟数据，不暴露真实金额、账号与交易记录。
页面截图遮挡姓名、联系方式、内部域名、客户标识、金额与敏感字段。
授权边界只有在客户明确书面授权后，才展示可识别名称、数据或聊天内容。
作品集展示的是你的能力结构，不是客户的商业结构。

没有企业客户，怎样获得第一次真实使用

先把“大企业客户”逐级缩小：小微企业、小商铺、亲朋好友，最后也可以是自己。只要需求真实、有人持续使用、有反馈和迭代，就比只为展示而做的 Demo 更有说服力。

训练营项目可以证明你掌握完整方法，但仍缺少真实使用这一块拼图。下一步可以选择一位真实用户，把他的工作流做成小而完整的交付，并记录使用数据、失败案例和二次迭代。

09FDE 面试考的是判断，不是背诵#

维度 普通软件工程面试常见重点 FDE 面试常见重点
问题形式 定义清晰的算法或系统题 目标不完整、约束冲突的真实业务问题
系统设计 规模、吞吐和通用架构 遗留系统、脏数据、权限、合规与时间限制
Coding 算法、数据结构与标准题 解析杂乱数据、写 CLI、接 API、调试陌生代码
沟通 解释方案与协作经历 澄清需求、管理预期、说服客户并承担结果

拆解面的正确起手式

课程给出的示例是：拿到 8000 条出租车运营记录，要求一周内提出并部署一个方案。题目没有说明给谁用，也没有说明要做定价、调度还是欺诈检测。

第一步不是画架构图，而是提问：谁是用户？业务目标是什么？一周内必须验证哪项价值？哪些问题可以暂不处理？怎样算成功？这正是 Day 2 的 Scoping 能力。

考官通常观察七件事

  1. 先澄清，再动手没有把假设当事实，也没有急着炫技。
  2. 切出自然边界能把大问题拆成可独立验证的模块。
  3. 覆盖边缘与失败路径主动考虑脏数据、外部系统失败和人工兜底。
  4. 显式表达假设让面试官知道当前结论依赖什么条件。
  5. 为取舍给出理由能解释一周内先做什么、为什么不做其他内容。
  6. 高压下表达连贯持续同步思路，并能吸收新信息修正方案。
  7. 始终想着最终用户方案服务于业务动作，而不是只追求技术完整。

四种日常练习

  1. 练 Scoping 每周选一个模糊诉求，口述目标、用户、边界、风险和成功指标。
  2. 练 Re-engineering 打开陌生仓库，先预测系统行为，再用运行结果缩小问题范围。
  3. 练 Learning 阅读一个新工具或 DSL 的文档，十分钟后向别人讲清心智模型。
  4. 练行为面 准备所有权、失败、艰难取舍和说服他人的真实故事。

行为面准备 3 到 5 个故事，每个压缩到两分钟，包含背景、任务、行动与结果。训练营中“是否砍掉某个功能”和“Eval 失败后如何排查”就是现成素材。

10Solo FDE 的三段式商业闭环#

  1. 第一段：付费审计 不直接接受一句“我们想上 AI”。先进入现场理解流程，交付一份 AI 落地审计或诊断报告，说明该不该投、先投哪里、预期收益和主要风险。
  2. 第二段：目标交付 不把合同写成无限扩张的功能清单。客户确认目标和边界，FDE 负责实现路径，双方按约定的 Eval、基线和验收标准判断结果。
  3. 第三段：持续陪跑 上线后按月或按年维护评测、知识、模型、系统与员工使用方式，让一次性项目变成持续演进的业务能力。

为什么诊断应该收费

卖结果，不卖学习过程交付一份可独立使用的审计报告，而不是让客户为你“了解业务”付费。
允许抵扣后续项目款客户继续交付时，诊断费可以按约定抵扣，降低首次决策阻力。
计算避免的损失诊断价值在于避免错误投资、无效采购和方向性试错。
筛选客户质量完全不愿为诊断付费的客户，后续也更可能在范围、验收和尾款上反复拉扯。
签约前先锁定四件事 范围、Baseline、验收人和付款条件，往往比技术能不能实现更决定项目是否赚钱。探索不应无限免费，预付款、阶段款、变更流程和验收口径都要写进合同。

每一单都要留下可复用资产

交付结束后安排固定时间做资产抽取，把不含客户秘密的模板、提示词、连接器、测试集结构、异常处理和商务经验沉淀下来。目标不是复制客户方案，而是让同类型的下一单更快、更稳。

独立 FDE 最常见的三个坑

风险 表现 应对
全才幻觉 误以为一个人必须懂所有行业、技术和商务 承认能力边界，和行业 Echo 或工程 Delta 搭档
所有员工陷阱 AI 让每项工作变快，却让一个人同时接下所有岗位 限制并发项目，标准化流程，保留高价值判断
三个月荒废 系统上线后无人维护、没有预算，最终停止使用 交付前验证真实 ROI，并设计负责人、评测和迭代机制

11E-A-D：单干不等于独自完成一切#

课程把适合独立 FDE 的协作方式总结为 E-A-D：

E · Echo掌握行业认知、真实规则、客户关系和业务判断。
A · Agent作为翻译与协作层，把业务上下文整理为机器可执行的任务、结构和规则。
D · Delta做工程判断、系统实现、评测、上线和持续维护。

行业认知留在 Echo，低损耗翻译由 Agent 辅助，工程责任落在 Delta。每个人都不需要成为独角兽，但三层必须形成稳定闭环。没有 Echo 的 Delta 很难进入真实业务，没有 Delta 的 Echo 很难把判断变成可运行结果。

12DeltaEcho：让独立节点形成交付网络#

课程最后介绍了 OpenFDE 旗下、面向 OPC FDE 的 DeltaEcho 社区。它希望连接行业专家和交付工程师，让节点之间可以搭伙、转单、复用资产并共享方法论，而不是再建立一家集中承接所有项目的传统乙方公司。

网络中的三种节点

  1. Echo 提供行业纵深、业务场景、客户信任和规则判断。
  2. Delta 驾驭 AI 和软件工程，把业务痛点交付为可用系统。
  3. Solo FDE 在垂直行业扎根后独立接单，并成为连接新项目与伙伴的节点。

让网络不再松散的四个纽带

  1. 统一协作语言使用 E-A-D 工作方式和共同交付标准，降低临时组队的磨合成本。
  2. 共享可复用资产沉淀脱敏后的模板、提示词、集成模块和评测框架。
  3. 建立利益连接让超出个人产能或能力范围的项目在网络内流转，并明确协作与分成。
  4. 积累共同品牌通过真实案例的脱敏复盘形成可信声量，反哺每一个交付节点。

社区边界与活动

课程提出三条边界：方法内容可以公开，但高投入带练需要收费；实战项目不适合零基础直接进入；不承诺年薪，只承诺围绕真实订单训练交付能力。

活动 核心形式 参与者获得什么
FDE 开放麦 同行复盘真实项目、失败与踩坑 可迁移的经验与风险认知
订单黑客松 真实企业出题，多个团队现场交付 业务验证、项目机会与合作伙伴
Solo FDE 工作坊 补足 Echo 的工程能力和 Delta 的业务能力 跟单实践与进入协作网络的准备
私人定制 FDE 为真实行业从业者完成个人或工作流定制 真实使用案例、反馈和行业边界

这些活动的共同点是离真实需求和真实交付足够近：不以社交数量为目标，而以能否产生案例、反馈、合作和订单为判断标准。