1.3 Echo 与 Delta：两种能力侧

概念：判断力与执行力的分工

在 FDE 的工作中，有两种能力侧需要区分清楚。借用一个直觉性的命名：Echo（回声）和 Delta（增量）。

提示

Echo：判断"该做什么"的能力。读懂客户现场，识别真实需求，判断技术路径，做出决策。它本质是判断力 + 领域理解。 Delta：把判断"做出来"的能力。写代码、配系统、调接口、跑测试，把方案落地成可运行的东西。它本质是执行力 + 工程能力。

用一个类比来理解。客户说"我想用 AI 做合同审查"。Echo 能力回答的是："审查什么条款？风险标准是什么？该用 RAG 还是 Agent？走哪个数据源？验收标准怎么定？"Delta 能力回答的是："好，我来把 Prompt 写好、把知识库接上、把流程跑通。"

Echo 是"判断方向"，Delta 是"跑通路径"。 两者缺一不可，但它们的稀缺程度正在发生变化。

🖼 图：echo delta model

用法：能力画像与考核差异

Echo 和 Delta 不仅是能力分类，也对应不同的考核方式。如果你用考核 Delta 的方式去考核 Echo，或者反过来，都会出问题。

示例：一个项目中的 Echo 与 Delta

还是用前面的合同审查项目来说明。

Echo 部分（判断该做什么）：

• 客户说"合同审查"，但 FDE 通过调研发现，客户真正痛点是"标准合同模板不统一，法务审了三遍还有漏"。真正的需求不是"AI 审合同"，而是"把合同标准化 + AI 做合规检查"。

• 判断技术路径：用 RAG 接入历史合同库做相似检索 + Agent 做条款合规检查，而不是纯 Prompt。

• 定义验收标准：合规检查准确率 ≥ 90%，审查时间从 2 小时降到 15 分钟。

Delta 部分（把它做出来）：

• 写 Agent 的 Prompt

• 配 RAG 知识库，接入历史合同

• 调通文档解析接口

• 跑测试、修 Bug、交付

你会看到，Echo 部分的产出是"判断和决策"，它决定了项目的方向对不对。Delta 部分的产出是"能跑的系统"，它决定了项目能不能交付。

**⚠️ 风险提示：**很多人把"不会写代码"等同于"不能做 FDE"。这是一个误区。不会写代码，确实会影响 Delta 能力，但如果你的 Echo 能力足够强（能准确判断需求、选对技术路径、定义合理验收标准），你完全可以在 FDE 团队中承担"判断侧"的角色，Delta 部分由工程能力强的搭档或 AI 辅助工具来补齐。FDE 是一个角色，不等于一个全栈工程师。

为什么 AI 让 Delta 变便宜、Echo 更稀缺

这是理解 FDE 价值的一个关键洞察。

过去，Delta 能力（编码、配置、集成）是稀缺的——会写代码的工程师贵，不会写代码就没法交付。但现在 AI 编码辅助工具（如代码生成、自动配置、低代码平台）正在大幅降低 Delta 的门槛。一个懂业务的人借助 AI 工具，可以完成过去需要一个开发工程师才能做的事。

但 Echo 能力（判断什么对客户有价值、选什么技术路径、怎么定义验收标准）AI 替代不了。因为：

1. 判断需要"现场感" ——你得在客户现场，看到他们皱眉、犹豫、说"这个其实不是我们要的"，才能修正方向。AI 看不到这些。

2. 判断需要"领域经验" ——你得见过 10 个制造客户，才知道第 11 个客户的"特殊需求"其实是通用模式的变体。AI 的训练数据里没有这种长尾的交付经验。

3. 判断需要"价值权衡" ——客户预算有限，做 Agent 还是做 RAG？先上哪个模块？这些权衡需要理解客户的业务优先级。AI 不会替你做这种决策。

所以结论是：AI 时代，Delta 变便宜了，Echo 更稀缺了。 FDE 的核心价值正在从"我能把系统搭起来"转向"我能判断该搭什么、怎么搭、搭到什么程度算成功"。

这也意味着，FDE 团队的人才结构会变化：不需要每个人都是硬核工程师，但需要有人在"判断侧"足够强。