FDE 术语表：一个术语只留一种译法

术语表存在的意义，是约束全站还能怎么写。下表中每个词只对应一种译法，站内所有文章都用这一种，读者学会了「回灌」，就不必在另一篇里猜「反馈闭环」是不是同一个东西。这些选择里有些是可以争的；但重点不是它们不可争，而是这一页给出的定义，能被拿去核对另一页上的说法。

这个岗位本身在中文里有三种写法在流通：前沿部署工程师、现场工程师、前线部署工程师。前两个分别读作「前沿」和「现场」，本站统一用「前线部署工程师」，包括所有链到这里的文章标题。

中文	English	一句话定义
前线部署工程师	Forward Deployed Engineer (FDE)	驻扎在客户环境里、填补「产品能做的事」与「客户真正需要的事」之间那道鸿沟的工程师，从调查一路做到交付。
侦察	Reconnaissance	第一阶段，把客户的「需求描述」证伪成一条可执行的判断，而不是当成信息收集起来。
定义	Definition	第二阶段，在动工之前锁死术语、数据口径、验收口径和 fallback。
交付	Delivery	第三阶段，东西跑在客户的真实数据上，证据一路延伸到业务端点，而不只是系统返回成功。
回灌	Feedback Loop	第四阶段，把一个客户的解法变成组织能用在下一个客户身上的资产，而不是一次性交付。
撤离	Extraction	第五阶段，让客户在没有 FDE 的情况下继续运转，退出条件在项目开始时就已写明。
三张图	Three Maps	钱怎么流、权怎么走、谁会输，顺序固定，因为第三张要等前两张画完才画得出来。
七问清单	Seven Questions	进场头两周必须答完的七个问题，包括客户答不上来的那些。
影子系统	Shadow System	正式系统之外真正在承载工作的那些 Excel、微信群和手写台账。
口径表	Metric Definition Table	五栏固定——指标定义、数据源、统计窗口、剔除规则、争议仲裁人——把指标从「大家心里的共识」变成项目能被判定的依据。
六段解剖	Six-Section Anatomy	一份完成的项目必须写的六段：从公司靠什么赚钱一直写到什么死了。
死因六型	Six Causes of Death	功能死亡的封闭清单，封闭是为了让「什么死了」不能用一个故事糊过去。
四周法则	Four-Week Rule	上线后连续四周仍在被使用才算活；停用率超过 30% 的功能进「未活」清单。
日落条款	Sunset Clause	开工前就写进项目章程的结束条件，包含触发日期，以及谁有权延长。
席位	Seat	编制的最小单位：一名人类加一个配对 Agent。
出环	Out-of-the-Loop	把任务从对话界面迁到接口上，人退出这个循环。
魂与壳	Soul and Shell	一个席位的两层——判断与记忆是魂，工具与界面是壳；壳可以换，迁移时魂必须留住。
校准回路	Calibration Loop	拿第一周的判断和实际结果对照，再把差额喂进下一次判断的那个循环。
判断日志	Judgement Log	四列——第一周判断、实际情况、第几周因为什么信号发现、信号可迁移的部分；写完即锁，只增不改。
影子工作法	Shadowing	坐在真实用户旁边过完他真实的一天，重点看「变通」，而不是他描述的流程。
证据分层	S1–S4 Evidence Ladder	交付有效的四层证据：系统接受请求、系统处理请求、系统完成动作、业务端点收到结果；返回 200 只证明第一层。
断奶	Weaning	按风险从低到高逐步撤掉 FDE 的参与，直到客户内部有人在完全没有外援的情况下把系统跑起来。

这张表不许动的三件事

五阶段名称不得换成同义词。 不写调研、设计、实施、复盘、退场，英文里也不写它们的近亲。一个阶段名背后挂着一整套退出判据和一组已知的死法；换成同义词，判据就掉了，只剩一个词。一篇文章把「侦察」写成「调研阶段」，等于把内容悄悄搬进了一个没有规则约束的阶段。

三张图顺序不变： 钱怎么流、权怎么走、谁会输。谁会输排在最后，因为它是大多数人会跳过的那张；也因为在你搞清钱往哪流、谁签字之前列出来的输家名单，只是一串猜测。

六段解剖不得合并、不得换序。 把「什么活了」和「什么死了」并成一段「结果」，得到的是一段读起来很整齐的文字，每一条死因都被平均数埋掉了。顺序本身在承担论证，光有小标题是不够的。

把它当查表用，它能结束争论：站内哪篇文章的用法和这一页对不上，以这一页为准，那篇文章要改。你需要而这里没有的词，是有意不收的——本站宁可守住 22 个站得住的词条，也不发 60 个各自漂移的。