02｜FDE 到底做什么，需要哪些能力？

这个结论会让学习变成没有边界的技术收藏。今天学检索，明天学部署，再补项目管理，却仍然不知道如何开始一个真实项目。更有效的理解方式，是沿着一项工作看责任：问题尚未明确时能否帮助澄清，方案遇到工程限制时能否亲手解决，系统交给用户之后能否继续判断结果。

本系列从三种能力理解这些责任：业务理解与需求判断、Agent 开发与工程化能力、组织落地能力。这是一套学习框架，不是统一的岗位认证，也不要求每个人在每个领域拥有同样深度。

业务能力首先表现为能听懂工作，而不仅是听懂行业名词。客户说“希望销售有一个知识库”，FDE 需要继续问：销售在什么时刻使用？现在向谁求助？最难回答的是技术问题、价格问题还是授权问题？回答之后要支持怎样的客户沟通？

以下用一个企业产品资料问答场景来说明。非技术销售需要解释产品与项目中的专业内容，原来往往要等待产品专家确认。系统要帮助销售及时获得有依据的说明，同时把动态价格、合同约定和其他商业承诺交给有权限的人。目标因此从“建立资料库”转成了“改善专业咨询支持这项工作”。

这种转译影响技术方案。若困难主要是找不到材料，就要检查检索与资料组织；若材料存在但表述过于专业，就要改善解释方式；若价格不断变化，则需要明确权威来源和人工确认。把问题混在一起，容易把所有改进都落到提示词上。

业务判断还包括取舍。第一期覆盖哪些产品、哪些咨询类型？资料不足时是否允许生成初步答复？一句看似合理的回答如果会构成商业承诺，谁负责确认？明确这些边界，往往比增加一个功能更能提高项目确定性。

对应的成果应该是可检查的：问题描述、现状流程、基线、目标指标、范围和待验证假设。一个人是否具备业务能力，可以看他能否拿出支持判断的事实，而不只是看他是否擅长主持会议。

FDE 需要具备亲手建设关键链路的能力。只有知道数据怎样取得、请求怎样流转、权限在哪里控制，才有可能判断客户的约束会给方案带来什么变化。

仍以内部问答为例，回答过程涉及消息入口、用户身份、产品归属、知识检索、上下文、输出和发送。模型生成文本只是其中一段。不同客户的背景不能混用，旧产品资料不能被当作当前事实，媒体材料需要遵守访问边界，发送失败也需要有明确状态。

工程能力可以按四类工作理解。第一类是应用开发：组织上下文、检索、工具调用和多轮交互。第二类是企业集成：连接现有入口、数据、接口和业务记录。第三类是身份与权限：控制谁能读什么、做什么，并让限制真正作用于系统。第四类是验证与运行：检查效果、定位错误、控制成本，并在依赖失效时恢复或转交。

这里的“懂技术”需要体现在选择理由上。现有消息底座若已满足入口和身份需求，复用它可能比重建更合适；当客户出现复杂的租户隔离或审批要求时，又要重新判断原方案是否足够。技术选型服务于现场条件，框架名称本身不能替代这项判断。

工程成果也不限于源代码。一份可运行的窄链、一组接口约定、一份代表性评测结果和一条可以追踪的请求记录，都能说明系统处于什么状态。反过来，仓库里有很多代码，也可能仍缺少一项完整任务的运行证据。

组织落地并不等于“沟通能力好”。它要求把目标、资源、授权和长期维护落实到真实角色上。

知识问答项目中，产品资料负责人可以确认产品事实，销售主管可以安排使用方式，技术人员可以负责版本与故障，但这几类角色不能互相替代。开发者不能自行决定折扣规则；销售也不能仅凭回答流畅，就确认资料隔离和系统恢复能力已经合格。

一个常见问题是“大家都参与了，却没人最终确认”。会议上业务说可以试，技术说已经完成，管理者以为安全团队会把关，安全团队却不知道系统已接入真实数据。角色在场不等于责任成立，必须写清谁执行、谁确认、谁参与协商、谁需要获知结果。

组织能力还体现在使用安排上。让一线人员在原有入口处理有限任务，提供如何补充背景、何时转人工的说明，建立可用的反馈渠道，比一次面向全员的功能演示更接近采用。系统出现异常时，用户知道怎样继续工作，才会愿意把它纳入流程。

最终需要留下的成果包括试用范围、用户验收方式、反馈责任、培训说明和维护安排。它们应当与项目规模匹配。小团队可以用简洁记录，大型组织可能需要正式审批，但关键责任都不能靠猜测维持。

假设销售反馈：“这个答案太长，客户等不及。”业务判断要先确认他正在进行怎样的沟通，是否需要可直接转述的短答；工程判断要检查回答组织与上下文，而不是随意删掉必要依据；组织判断要明确哪些说明可以对外使用，哪些内容仍需专业人员复核。

如果反馈是“引用了另一个产品的说明”，工程团队要检查检索与隔离，产品资料负责人要核对资料归属，业务侧则需要判断错误影响了哪些沟通。三种能力在同一条任务链上共同发生，无法简单按部门切成互不联系的三段。

这也解释了为什么学习顺序不能只按工具排列。先有一项具体任务，才能知道需要什么技术；亲手实现又会暴露数据和环境限制，促使团队修订范围；真实试用再检验前面的判断。能力是在这类往返中形成的。

FDE 与 Agent 开发、产品、解决方案和实施岗位存在交集。职位名称只能提供线索，判断实际职责应当阅读具体动作、交付物与责任范围。

这些是常见关注点，并非固定的岗位边界。成熟的开发者同样可能深入客户业务，产品经理也可能参与验证与交付。FDE 的特点，是在职责安排中持续关注问题到生产结果之间的连接，并在关键技术环节具备建设能力。

国内项目还可能由企业内部团队、外部专业团队或联合团队完成。内部团队熟悉组织，却仍可能受到跨部门接口和资源限制；外部团队有同类经验，也需要重新理解客户的规则。交付形态改变协作方式，不会取消业务、工程和组织三类责任。

入门者可以选一个熟悉的小场景，用六个问题检查当前能力：能否展示真实流程；能否说明改善目标；能否画出人、模型与程序的分工；能否跑通一条完整任务；能否解释一个失败原因；能否找到验收和维护责任人。

不必等技术栈全部学完才开始，也不能用会沟通代替工程实现。选择一个足够小、又有真实用户和后续动作的任务，把三种能力练在同一条链上，更容易知道自己的缺口在哪里。

下一篇将把这三种能力放进时间与决策关系中：一个项目每走到一个阶段，需要完成什么，取得什么证据，又在什么情况下应该返回前面修订。

想先熟悉实际任务，可以通过 AI随心创的AI 助手体验文本、图片和文件输入下的资料整理与问题解答。需要将这些能力放进团队流程时，可以进一步了解工作流设计与试点支持。