先给结论：FDE 是前线责任，不是一个人的全栈神话
FDE 需要在客户现场理解问题，也需要把问题推进到可以运行的系统。但这不等于一个人应该同时承担业务调研、数据接入、应用开发、安全审批、生产值守和产品路线图。FDE 可以跨越多个领域，完整的交付却仍然需要明确的责任面。
把项目包装成“一个 FDE 从头做到尾”听起来很有速度，实际往往会把隐性工作藏起来：谁批准 Agent 的动作？谁维护生产代码？谁接住夜间故障？哪些现场定制应该进入产品，哪些必须留在客户边界？这些问题没有答案，项目就只能依靠个人记忆和临时救火。
把交付拆成四个责任面
一个稳定的 FDE 交付单元，至少要把下面四类责任说清楚。一个人可以暂时兼任其中两类，但不能因此省略责任边界。
| 责任面 | 核心问题 | 应该留下的证据 |
|---|---|---|
| 业务 Owner | 要改善哪项工作？谁承担结果和风险？ | 业务基线、目标流程、验收指标和决策人 |
| FDE | 真实工作如何运行？用户愿不愿意把它放回日常流程？ | 上下文地图、工作流边界、用户反馈和采用观察 |
| 交付工程 | 数据、工具、权限、部署和异常如何稳定运行？ | 代码仓库、测试、日志、权限矩阵、回滚和运行手册 |
| 核心产品或平台 | 哪些差异值得标准化？哪些需求应该明确不支持？ | 产品决策、连接器、评测集、平台能力和版本记录 |
为什么“一个英雄 FDE”会在生产前后失速
现场理解和系统维护不是同一种工作
跟着用户走完一次任务，问出真正的业务约束，需要耐心和现场判断；处理接口超时、幂等、权限变更和回滚，又需要另一套持续的工程纪律。把两者都压在一个人身上，最先被牺牲的通常是文档、测试和交接，而这些正是生产系统最需要的部分。
项目成功和产品复用不是同一个目标
FDE 可能为了让当前客户尽快跑起来而接受一段定制逻辑，核心产品团队则要判断这段逻辑是否值得进入通用能力。两种判断都合理，但必须在同一条反馈链中讨论。如果现场团队没有产品入口，经验会留在聊天记录里；如果产品团队只看抽象需求，又会错过真实的失败模式。
生产责任不能靠口头约定
项目交付时要明确代码进哪个仓库、谁能发布、谁接收告警、谁批准扩大动作范围，以及 FDE 何时退出。没有这些约定，“上线”很容易变成把一个仍然需要原作者盯着的系统交给客户。
从项目第一天就把边界写出来
- 先做责任矩阵：把业务结果、工程实现、风险批准、生产运营和产品反馈分别指派给具体角色，不用“团队共同负责”替代名字。
- 再冻结代码与运行归属：写清仓库、部署环境、凭证、日志、告警、值班和回滚路径。FDE 负责推动问题解决，不代表永远是唯一值班人。
- 让反馈进入产品决策：每个重复出现的问题都要标记为客户专属、共享交付基线、产品能力或明确不支持，而不是默认继续定制。
- 为退出定义条件：当业务 Owner 能在边界内运营、异常有接管路径、指标有观察窗口、版本有维护人时，FDE 才算完成了一次可交接的交付。
企业评估交付团队时，可以直接问这七个问题
- FDE 写的生产代码进入哪个仓库，谁拥有长期维护权？
- 业务 Owner、风险批准人和生产值班人是否是明确的不同责任？
- Agent 的哪些动作只读、可逆、需审批或被禁止？
- 故障发生时，客户能否在没有原作者在线的情况下接管？
- 现场发现的问题如何进入产品或平台的决策队列？
- 上一个项目留下了哪些经过脱敏、测试和版本管理的资产？
- 项目结束后，团队用什么证据判断用户还在使用，而不是只完成了部署？
如果对方只能展示 Demo、方案书或一份泛泛的能力清单，却无法回答代码归属、生产责任和反馈机制，那么“FDE”很可能只是交付岗位的新名称。反过来，团队人数多少也不是关键；关键是每个不可省略的责任是否有人真正承担。
FDEr.ai 的判断：速度来自边界清楚，不来自个人超载
FDE 的价值在于把现场问题带进工程系统，但 FDE 不应成为组织缺口的遮羞布。好的交付单元让客户、FDE、交付工程和核心产品各自承担能被验证的结果，再用共同的反馈机制把它们连起来。
这也是我们把“上下文到生产”和“交付资产化”分成两条方法线的原因：前者保证当前场景安全落地，后者确保项目经验不会继续锁在个人身上。可以先阅读客户业务上下文到生产，再用交付资产化检查项目结束后留下的东西。