01
FROM OBSERVATION TO ENGAGEMENT
不要隔岸观火，进入问题发生的地方。
总部的模型、架构和标准 API 可以描述“应该怎样”，却无法提前知道客户几十个遗留系统怎样互相牵制，也无法替业务人员说出尚未被说清的需求。
客户说：“我们需要一个智能调度大模型。”↓FDE
先问：“到底是哪一个业务节点，让结果没有发生？”
✳ FDE / PHILOSOPHY
FDE 与「在世存在」
不是站在现实之外设计答案，而是进入现实之中，让答案在行动里显现。
海德格尔的 Dasein / Being-in-the-world 提醒我们：人并不是一个隔绝于世界、再去观察世界的旁观者。对 FDE 而言也是如此——真正的问题、工具与结果，都只会在具体的业务现场、系统约束与人的协作中显现。
“真理不在象牙塔的图纸里，而在双手磨破的交互中；意义不是被设计出来的，而是在泥泞的现实里显现出来的。”
传统视角现成在手把世界看成已经摆好的对象：数据、模型、API、需求。
→
FDE
的位置在世存在进入局势、利益、数据、权限与工作流，让问题在使用中被理解。
→
行动状态上手状态像真正使用工具一样工作：敲代码、接系统、跑流程、验证结果。
FDE PLAYBOOK / 05
哲学不是抽象的装饰，而是 FDE 的工作方式。
0102030405
核心本质团队架构产品探索AI
时代经济模型
BEING-IN-THE-WORLD × FDE
只有进入现场，
你才真正知道问题是什么。
FDE 与“在世存在”的相似，不是把哲学术语贴在工程师身上，而是两者都拒绝一种脱离情境的认知方式：先在纸面上定义世界，再要求现实服从设计。
把问题当成一个对象。
需求、数据、模型、系统彼此分离，仿佛只要把正确组件拼起来，答案自然就会出现。
在使用中理解关系。
真正的认知发生在敲代码、接权限、跑流程、与用户协作和处理异常的过程中。工具只有进入行动，才显出它真正的边界。
THE FRONTLINE
总部看见“系统”。FDE 看见“局势”。
数据为什么缺失？谁拥有权限？谁会反对？哪个环节最贵？哪个异常一旦发生就必须人工接管？这些不是方案文档里的附属条件，而是问题本身。
THE FDE ATTITUDE
“把自己扔进世界里，问题才会开始说话。”
所以 FDE 不是“懂技术的人去支持业务”，而是一种工作姿态：进入现场 → 与现实摩擦 → 让问题显形 → 亲手改变它 → 用结果重新理解它。
FDE / FIVE PROPOSITIONS
五个命题理解 FDE
从“FDE 是什么”到“为什么这种工作方式能够持续产生价值”，五个命题把前线工作、产品探索、AI 时代与经济纪律串成一条完整逻辑。
01CORE ESSENCE
核心本质与定义
FDE 的核心，是把“能力”变成“采用”。
当一个领域还没有成熟标品、需求高度异质时，FDE 不等待标准答案，而是主动进入现场，把工程能力直接接到最重要的问题上。
规模化做“不可规模化的事”
走进客户现场，一起工作，手动打通关键环节，把早期产品发现中的高触达做法变成可重复的交付方式。
解决 CEO Top 5 优先事项
不从“客户想要什么功能”开始，而从组织最重要的业务优先级开始，让工程投入直接连接 Outcome。
填补 Capability → Adoption 的鸿沟
模型能做什么只是起点；流程、数据、权限、部署、评估和组织协作，才决定企业能不能真正用起来。
SaaS MODE标准化之后规模化找到 PMF 后，以标准产品保持距离并持续扩张。
→
FDE MODE贴近现场，再不断扩展High-Touch 先把结果做出来，再通过
Land & Expand 扩大价值。
适用边界更适合新兴技术、没有成熟现成标品、客户需求差异大且需要持续 Product Discovery 的领域；若标准 SaaS
已能直接解决问题，就不需要人为增加 FDE 环节。
02TEAM ARCHITECTURE
Palantir 团队架构与岗位分工
前线需要两种力量：
理解问题的人，做出结果的人。
材料中的 Echo / Delta 分工，把领域理解、客户沟通与工程交付组合起来，让“发现问题”和“解决问题”形成同一条链。
ECHO TEAM
领域理解 × 客户关系
嵌入业务现场，洞察客户痛点，识别高价值用例，理解客户语言，做 Demo，并持续维护决策层的 Buy-in。
需求发现行业理解客户沟通
+
DELTA TEAM / FDE
快速编码 × 现场交付
高速度编码、工程解决和部署验证，在极短时间内做出可运行 Prototype，并把现场反馈带回产品。
快速编码部署验证Eat pain
创始人训练营FDE 同时面对客户、技术与商业结果，像一个拥有产品杠杆的小型创业团队，因此持续训练全栈判断、交付和商业落地能力。
03PRODUCT DISCOVERY
产品探索与双向抽象
先走“碎石路”，再把路修成“高速公路”。
一次客户交付只是起点。FDE 真正形成杠杆，要让现场反复出现的模式被看见、被抽象、被产品化。
先把一个客户做通
针对单一客户快速打通可用方案。可以粗糙，但必须真实可用、能验证结果。
→
再为下一个客户提炼通用能力
从多个部署中识别共性，把反复出现的模式做成稳定、可扩展的平台能力。
ONTOLOGY / ABSTRACTION
Ontology：不要把一个客户做成一条死路。
把具体流程提升到更高一层的抽象：用“对象 · 属性 · 链接”描述共性，让不同客户的差异落在表达层，而不是不断改写核心系统。
Pop up a level of abstraction ↑对象→属性→链接
内部市场机制前线 FDE 追求快速 Hack，产品团队追求通用架构。让 FDE
参与通用功能设计；当平台提供的杠杆高于手工定制，前线就会自然选择使用平台。
04AI ERA
AI 时代的新契机
模型能力越强，“能用起来”越需要 FDE。
AI 的 Capability 变化很快，但企业采用仍然受真实业务环境限制。能力与采用之间的空白，正是新的产品探索和工程机会。
能力上限快速前进
前沿模型不断打开新的可能，但“模型能做到”不等于“企业已经能做到”。
真实环境高度异质
数据、权限、系统、流程、评估和组织协作，都必须进入现场才能真正解决。
高价值 Outcome 支撑高触达
当 AI 能带来的业务价值足够高，高合同价值可以支撑前期的 High-Touch FDE 部署。
风险为什么不对称？大企业对内部执行和外部初创公司均缺乏信任，企业既不确定初创公司能不能执行，也常常不确定自己能不能把项目执行下去。
FDE 如何破局？先承担一部分执行风险，尽快展示 Outcome；围绕 CEO Top 5 Priority 切入，再逐步走向 Outcome-Based Pricing 与
Land & Expand。
05ECONOMICS & DISCIPLINE
经济模型与咨询化陷阱
FDE 可以从“重”开始，但不能一直这么重。
前期用高触达换产品发现，长期靠更高的抽象度与 Product Leverage，让每一次部署都比上一次更轻。
CONSULTING TRAP
如果每个项目都从头做，
如果每个项目都从头做，
FDE 就只会越来越忙。
核心纪律：每次部署，都应该让下一次部署更轻。
只围绕 CIO 或中层的“容易赢”项目，而没有进入真正重要的业务转型。
客户说什么就原样实现，而没有继续追问真正需要解决的问题。
第三个部署仍需要和第一个一样多的手工投入，说明产品抽象与复用没有发生。
THE 4C / FINAL DEFINITION
“4C”将FDE落到一次真实交付。
理解 FDE 最后不需要再记更多概念，只需要记住这四个动作，以及它们形成的闭环。
01现场 · Context
深入客户的真实环境：业务流程、数据、权限、决策和失败成本。问题不是“客户要什么功能”，而是真正的业务结果卡在哪里。
做正确的事02代码 · Code
亲手接入数据、构建 Agent、处理权限与审计、部署上线。不停在 Demo、PPT 或配置层，而是在真实基础设施上运行。
到位交付03校准 · Calibration
用真实业务指标与失败模式做 eval，关注正确率、覆盖率、越权率、人工接管率、采用率等，让“上线”变成“被验证有效”。
真有效04回流 · Compounding
把现场反复出现的摩擦沉淀成连接器、模板、评估集和产品需求，让下一次部署更快、更稳、更容易复制。
可复制
FDE / FINAL DEFINITION
在真实现场理解问题，用代码完成交付，用校准证明结果，再把经验回流成可复用的产品能力。
所以，FDE 的完整闭环不是“做完一个项目”，而是：正确的事 → 到位交付 → 真有效 → 会复制。
TAKE THE NEXT STEP