ARTICLE · 985939
客户说“我要一个 AI 助手”,FDE 第一件事不是写代码
摘要：很多 AI 项目不是输在模型能力，而是从第一步就问错了问题。FDE 要做的，不是把一个愿望包装成 Demo，而是把真实业务中的一段工作，拆成一个能上线、能使用、能验收的用例。
说明：本文中的客服人物、对话、订单、时间、耗时、样本编号、测试状态、试用观察和一周节奏均为构造示例或方法演练，不对应任何真实客户项目、真实访谈、真实业务数据或已完成交付。文中“真实数据”“真实用户”“真实样本”是对实际项目应采用的验证对象的泛称；本文未据此宣称已经完成相关验证。外部来源只用于说明公开资料中的做法，不代表本文作者与相关公司存在项目合作或结果背书。
---
开场：会议室里的那句话
“我们想做一个 AI 助手，最好什么都能处理。”
这句话听起来像需求，实际上更像一个愿望。
它没有说明谁遇到了问题，也没有说明问题发生在哪里；没有说清楚哪些数据可以使用，更没有说明什么结果出现后，项目才算成功。
如果项目团队在这句话之后立刻开始选模型、搭知识库、接接口、做聊天页面，通常会得到一个看起来很聪明的 Demo。它能回答问题，却未必能改变工作；能展示能力，却未必有人愿意在每天的流程里使用。
FDE 面对这句话，第一反应不是“可以”，也不是“做不到”，而是把问题往前推一步：
哪一个人，在哪一个具体时刻，正被哪一个具体问题拖住？
这一步很慢吗？通常不慢。真正昂贵的是方向没有确认就开始开发，几周后才发现系统解决的不是客户最在意的问题。
以下是一个完全构造的客服场景演练。人物、时间、对话、数据和后续结果均为示意，不对应任何具体客户项目；“真实验证”“小范围试用”等词指的是实际项目中应执行的步骤，并不表示本文已经完成了这些步骤。
诊断会的第一分钟
【以下对话为构造示例，不是客户访谈记录】
会议开始时，业务负责人把目标说得很大：“售前、售后、投诉，最好都覆盖。”
技术负责人打开电脑，已经准备好模型和架构图。
一线客服却先说了一句：“如果能先别让我每天切四个页面，就已经帮大忙了。”
这三句话看起来都在谈 AI，实际上谈的是三个不同的世界：管理者谈覆盖范围，工程师谈系统能力，一线员工谈每天正在承受的摩擦。
FDE 没有马上打开架构图，而是问：“昨天最晚关掉的那张工单，是什么问题？”
在这个假设场景中，客服可能会说是一笔迟迟没有发货的订单。客户在下午问过一次，晚上又问了一次。客服查到订单状态栏显示“已出库”；再看物流状态栏，没有揽收记录；去运营群里问，假设得到的回复是“仓库今天晚些时候处理”。
“最后怎么回复客户？”
“先说已经安排发出，明天再更新。”
“这个‘已经安排发出’，系统里有明确依据吗？”
客服停了一下：“没有，是运营口头说的。一般都这么回。”
会议室安静了几秒。
在这个构造场景里，FDE 要找的不是客户口中的“智能客服”，而是拆开一个具体承诺是怎样被做出来的过程。问题也因此从“模型能不能写回复”，变成了“哪些信息可以对外确认，哪些信息只能作为内部待办”。
第一个分歧：要不要直接回复客户
业务负责人希望第一版就能自动回复客户，因为只有这样才能体现项目价值。
安全人员担心，如果订单状态和物流状态冲突，系统自动承诺日期，会把一次数据延迟变成客户投诉。
工程师认为，先做一个只读的查询工具更稳妥，但业务方担心“看起来不像 AI”。
FDE 把争论写成三个待验证假设：
在真实项目中，接下来应各取一批经授权、脱敏的业务样本验证；本文只列出三种待比较方式：
只给自动生成的完整回复； 只给订单、物流和政策的事实摘要； 给事实摘要、回复草稿和人工确认按钮。
若试用观察到客服频繁改写自动回复、却更愿意采用事实摘要，那么可以提出一个阶段性判断：第一阶段的价值可能不在“替客服说话”，而在“让客服更快拿到可信信息”。这需要继续用样本和使用行为复核。
第一个范围决定
会议最后没有得到一个看起来宏大的产品名称，只得到一张小小的范围卡：
这张卡看起来像是把项目做小了，实际上是在把责任做清楚。
客户不再需要等待一个“什么都能处理”的系统；工程团队知道第一批接口；安全团队知道高风险动作在哪里拦截；一线客服知道系统会帮自己做什么，也知道什么时候仍然需要自己判断。
故事从这里才真正开始。FDE 的工作不是把会议上的所有愿望都带回去，而是把一个各方都愿意验证的决定带回去。
第一幕：先把一句愿望说清楚
一、客户说的是方案，FDE 要找的是结果
业务方很少从结果开始描述问题。
他们更常说的是：
“能不能做一个机器人？” “能不能把这件事自动化？” “能不能接入大模型？” “能不能像某某公司一样做一个智能助手？” “能不能让员工都用起来？”
这些话并没有错，但它们把几个不同层次的问题混在了一起：
想解决什么业务问题； 想采用什么技术方案； 想获得什么组织变化； 想向管理层证明什么。
如果不把这几层分开，项目很容易从第一天就被一个错误的目标牵着走。
比如，“做一个 AI 客服”至少可能对应四种完全不同的目标：
目标 A：减少重复查询
客服每天要在订单系统、物流系统和政策库之间来回切换。客户想减少查找时间。
目标 B：统一回复口径
不同客服对同一政策的解释不一致，客户体验不稳定。客户想减少口径偏差。
目标 C：延长服务时间
夜间没有足够人工值守，客户问题经常等到第二天。客户想让简单问题先得到回应。
目标 D：直接替代人工
管理层希望减少客服人数，把更多问题交给机器处理。
这四个目标需要的系统、风险和验收方式完全不同。
A 可能只需要检索和界面整合； B 需要统一知识、规则和审核； C 需要明确转人工和异常升级； D 则涉及组织、责任、合规和客户关系，不能用一个 Demo 证明。
因此，FDE 的第一个动作不是回答“能不能做”，而是问：
你希望哪一个指标发生什么变化？
这句话会把讨论从“功能想象”拉回“业务结果”。
二、第一轮访谈，不要急着问模型
一场有效的 FDE 访谈，通常可以围绕五组问题展开。
1. 问发生了什么
不要先问“你希望 AI 做什么”，先问：
这件事最近一次是什么时候发生的？ 谁提出了请求？ 谁接住了请求？ 中间经过了哪些系统？ 最后由谁确认结果？
“最近一次”比“通常情况下”更有价值。
“通常”会让人讲流程图上的理想状态；“最近一次”会暴露真正的绕路、补救和临时决定。
2. 问现在怎么解决
要把人工动作记下来，而不是只记录岗位名称。
例如，不要只写“客服处理售后”，要继续追问：
客服先打开哪个页面？ 订单号从哪里复制？ 哪个字段最常看？ 政策是搜索、翻文档，还是问主管？ 哪些情况需要截图？ 哪些情况必须转给专员？ 最后的处理结果记在哪里？
很多所谓的“AI 机会”，其实是信息散落在多个系统之间造成的。模型不是第一解决方案，减少切换和补录可能才是。
3. 问哪里最疼
“效率低”还不够具体，需要继续问：
一次处理要花多长时间？ 一天大约有多少次？ 哪一类问题占用最多时间？ 哪一类错误最贵？ 哪一步最依赖资深员工？ 哪一步最容易被遗漏？
效率、准确率、覆盖时间和管理成本，不能混成一个“提效”指标。
如果每天只有两三次，哪怕每次很麻烦，也未必值得优先自动化；如果每天有几千次重复操作，即使每次只节省一分钟，也可能值得做。
4. 问什么不能交给机器
这是很多项目最容易漏掉的问题。
需要明确：
哪些动作只是提供建议； 哪些动作可以自动执行； 哪些动作必须人工确认； 哪些数据不能被模型读取； 哪些结果必须保留原始证据； 哪些错误不能通过“再试一次”解决。
尤其涉及退款、合同、医疗建议、招聘筛选、金融服务或客户承诺时，不能把“模型大概率答对”当作授权依据。
5. 问什么叫成功
一个项目如果不能在开始前说清楚成功标准，结束时就只能靠演示气氛判断。
至少要写出：
业务指标； 质量指标； 安全边界； 使用指标； 退出条件。
例如，售后助手的第一个版本可以这样定义：
这比“做一个智能客服”更像一个可以负责的项目。
三、为什么要看“最近一次”，而不是只听流程介绍
客户介绍流程时，往往会给出一条整齐的链路：
但真实工作可能是：
两条流程的差别，决定了系统应该解决什么。
第一条流程适合直接讨论自动化；第二条流程要先处理数据完整性、系统同步、政策版本和人工协作。
如果跳过这一步，AI 很可能只是把一个不稳定的流程包上了聊天界面。
四、FDE 的现场观察，不等于旁观
FDE 不是坐在会议室里收集需求，也不是只看客户提供的流程图。
现场观察至少要关注四件事：
1. 用户说了什么
这是显性需求，例如“希望自动生成回复”。
2. 用户实际做了什么
这是操作事实，例如“为了确认一个字段，用户切换了四个页面”。
3. 用户为什么这么做
这是判断逻辑，例如“只有资深员工知道哪个政策版本优先”。
4. 用户最后承担什么责任
这是交付边界，例如“系统建议错了，最终仍由客服对客户承诺负责”。
第四点尤其重要。一个看起来只是“生成文本”的功能，如果最终会影响退款、报价或客户承诺，就不能按普通文案工具处理。
五、从抱怨里识别判断密集环节
不是所有重复工作都适合做成 Agent。
FDE 更应该寻找的是：重复发生，而且其中包含稳定判断规则的环节。
可以用下面四个问题筛选：
是否高频
每天、每周是否反复发生？如果只出现一次，自动化收益通常有限。
是否有输入
系统是否能拿到判断所需的资料？如果关键信息只存在某个人脑中，第一步可能是知识整理，而不是直接接模型。
是否有判断规律
资深员工是否能说明自己为什么这样判断？如果连专家也只能说“凭经验”，需要先做案例回放和规则提炼。
是否有结果反馈
做完之后能否知道对不对？如果没有后续结果，模型输出就无法校准，项目也无法形成学习回路。
这四项都满足时，才值得进一步评估 Agent 方案。
六、不要把“能自动化”误认为“值得自动化”
技术上能做，不代表业务上应该做。
一个动作可能符合自动化条件，但收益不够覆盖：
接口开发成本； 权限和安全成本； 数据治理成本； 例外处理成本； 培训和推广成本； 出错后的责任成本。
可以用一个简单的优先级表做第一轮判断：
这张表不是为了算出一个看似精确的分数，而是为了让团队讨论同一件事。
如果一个用例频次很高、价值很大，但风险也很高，就不能简单地说“优先级高”，而要进一步拆成：
机器先给建议； 人工确认关键动作； 记录依据和结果； 经过一段时间评估后，再决定是否扩大自动执行范围。
七、第一个用例应该足够小，但不能小到没有意义
MVP 有两个常见误区。
第一个误区是太大：
“先做一个覆盖所有售后问题的统一助手。”
第二个误区是太小：
“先让模型把一句话改得更礼貌。”
前者难以控制，后者很难证明业务价值。
比较好的第一个用例，通常符合三个条件：
业务频率足够高； 输入和规则相对明确； 输出结果可以被人工快速验收。
例如：
针对已知订单号的物流进度咨询，读取订单和物流状态，引用当前政策，生成客服回复草稿；不执行退款、不修改订单，异常情况转人工。
这个用例已经明确了：
服务对象； 输入条件； 可使用的数据； 输出形式； 禁止动作； 异常路径。
它可能还不够“炫”，但更有机会真正上线。
八、用例边界越清楚，Agent 越有用
Agent 行动边界：建议、确认和禁止。
“让 Agent 自己判断”不是边界。
真正的边界应该写成可执行的规则：
这些规则不能只放在会议纪要里，还应该进入系统的权限、工具和评估设计。
如果 Agent 没有执行退款的工具权限，模型即使“决定退款”，也无法直接完成；如果工具权限存在，就必须在动作前设置人工确认和审计记录。
这也是 FDE 与普通 Prompt 调试的分界线：Prompt 可以改变表达，FDE 还要改变系统的行动边界。
九、为什么“真实数据”比漂亮 Demo 更重要
Demo 通常使用三类经过整理的输入：
格式完整； 内容清晰； 没有权限冲突。
真实业务则相反：
字段缺失； 命名不一致； 历史数据和新数据混在一起； 不同角色看到的内容不同； 规则有版本； 用户会故意问边界问题。
因此，真实项目通常应尽早使用经过授权和脱敏的数据做验证；本文的示例数据不是真实客户数据。
不一定一开始就接入全部生产系统，但至少要保留真实数据的复杂性：
缺字段； 错格式； 旧版本； 多语言； 模糊表达； 重复记录； 权限不足。
如果一个方案只能处理“干净样本”，它还不是生产方案，只是演示方案。
十、评估集不是考试题，而是业务记忆
多维评估：正常、缺失、冲突、权限和风险。
一个好的评估集，不只是几十道题和标准答案。
它应该记录：
这个问题来自哪类真实场景； 过去人工是怎么处理的； 什么答案算正确； 哪些答案虽然听起来合理但不能接受； 哪些情况必须转人工； 错误会带来什么后果。
例如，售后助手的评估样本可以包含：
评估集的意义在于，它把“资深员工的经验”变成了团队可以共同检查的对象。
这也是后续构建 Skill、规则、工具权限和自动化测试的基础。
十一、FDE 需要同时管理三条线
一个 FDE 项目通常同时存在三条线：
业务线
客户的问题有没有缓解？用户是否真的采用？指标有没有变化？
工程线
系统能不能运行？接口是否稳定？权限是否正确？异常能不能处理？
组织线
谁负责维护？谁能修改规则？谁审批高风险动作？经验如何交接？
很多项目只盯工程线：接口接通了，页面出来了，模型回答了。
但如果业务线没有结果，系统只是一个技术展示；如果组织线没有安排，项目负责人离开后，系统就会逐渐失效。
FDE 的工作难度，正是因为这三条线不能分开推进。
十二、AI-native 并不等于“全部交给 AI”
AI-native 的工作方式，容易被误解成：
以后每一步都让 AI 自动完成，人只需要点确认。
更准确的理解是：
让 AI 参与每一个阶段，但把人的注意力集中到真正需要判断的地方。
计划阶段，AI 可以帮助整理问题和补齐疑问；人要确认问题是否被理解。
设计阶段，AI 可以生成方案和风险列表；人要决定哪些约束不能违反。
开发阶段，AI 可以生成代码和测试；人要确认系统边界和业务假设。
测试阶段，AI 可以运行大量样本；人要判断评估是否覆盖真实风险。
部署阶段，AI 可以自动完成检查；人要批准关键变更。
维护阶段，AI 可以监控异常；人要判断异常是否值得改变产品或流程。
这与 Claude 发布的 AI-Native SDLC playbook 所描述的做法相近：各阶段留下可交接的产物，并保留需要判断的人工责任。[2] 这里引用的是该 playbook 的方法，不是行业统一标准。
十三、FDE 的每个阶段都应该留下什么
可以把一项 FDE 交付整理成下面这组产物：
这些产物不是为了增加文档工作，而是为了避免每一次交付都从零开始。
如果下一位 FDE 只能通过口头询问才能理解项目，说明交付还没有真正沉淀下来。
十四、什么时候应该停止一个 AI 用例
FDE 不只是负责把项目推进到上线，也要负责在不值得继续时及时停下来。
以下情况出现时，应该重新评估：
真实数据无法取得，项目只能靠演示数据推进； 业务负责人无法定义成功标准； 使用者不愿改变现有流程； 系统需要的权限超过客户能够接受的范围； 高风险动作无法设置人工确认； 错误成本远高于自动化收益； 试点数据表明人工处理反而更快； 项目目标不断扩大，却没有新增资源和验收标准。
“暂不做”不是失败。
如果一个用例缺少数据、权限、责任人或结果反馈，继续堆模型和功能，只会让问题更晚暴露。
第二幕：走进现场，看见真实工作
诊断会：从最近一次真实事件还原工作流。
十七、一次有效的诊断会，应该产出什么
在真实项目中，FDE 诊断会不应只是产品宣讲或需求交接；以下是可采用的诊断方式。
一场有效的诊断会结束时，至少应该留下五个结果：
1. 一个被双方确认的问题描述；
2. 一张接近真实的当前流程图；
3. 三个以内的候选用例；
4. 每个用例的价值、风险和依赖；
5. 一个明确的下一步验证动作。
如果会议结束后只剩一份几十页的会议纪要，里面充满“后续进一步讨论”，那它更像信息收集，不是诊断。
会议的第一段：让客户讲一次最近发生的事
可以从一个具体事件开始：
“请讲一个最近处理过的真实案例，从请求进来开始，一直到最后关闭，中间不要跳过临时处理。”
这句话的作用，是把讨论从抽象判断拉回现场。
客户可能会说：“客服收到问题后，查询订单，再回复客户。”
FDE 要继续问：
查询订单时，订单号一定完整吗？ 物流信息来自哪个系统？ 政策是固定文档，还是还要问主管？ 客服能否直接给出补偿？ 什么时候必须升级？ 关闭工单后，结果还要同步到哪里？
每一个追问，都是在寻找系统真正需要接入的地方。
会议的第二段：把动作写出来
不要只记录“客服负责售后”，而要把动作拆成动词：
动词比岗位名称更接近自动化边界。
其中有些动作适合规则，有些适合检索，有些适合模型，有些必须由人承担。只有把动作拆出来，团队才能讨论“哪一段值得交给 Agent”。
会议的第三段：找出例外
理想流程通常只有一条，真实流程一定有例外。
要专门问：
最常见的例外是什么？ 最危险的例外是什么？ 哪类问题最容易被升级？ 哪类信息经常不完整？ 哪个决定只有一个人会做？ 如果负责人不在，谁来接？
例外不是流程中的噪音，它往往决定了系统能不能上线。
一个只覆盖正常流程的 Agent，很容易在演示中表现良好，在真实工作中频繁转人工；一个把例外路径提前设计清楚的 Agent，哪怕自动化范围小，也更容易被团队信任。
十八、不要把客户的第一答案当成最终答案
客户说“我们需要一个聊天机器人”，可能是因为他看到了别人家的产品；也可能是因为现有系统入口太难用；还可能是因为管理层要求“必须有一个 AI 项目”。
FDE 不能简单否定客户，也不能顺着第一句话直接做方案。
更好的做法是把需求分成三层：
表达层
客户怎么描述想要的东西。
例如：“做一个 AI 助手。”
工作层
客户希望哪个工作环节发生变化。
例如：“客服不用来回查三个系统。”
结果层
客户最终想看到什么业务变化。
例如：“常见售后问题的处理时间降低，且退款风险不增加。”
表达层可以调整，工作层需要观察，结果层必须验收。
FDE 的任务，就是把讨论从表达层推进到结果层。
十九、如何处理“领导已经指定方案”
在不少项目中，客户可能会在诊断开始前指定：
必须用某个模型； 必须接入某个平台； 必须做成一个统一助手； 必须在某个时间前上线； 必须覆盖全部部门。
这时直接说“不合理”，通常不会推进项目。
可以先把指定方案翻译成可验证的假设：
把争论变成验证，客户更容易接受。
如果验证结果不支持原方案，FDE 也不需要依靠个人意见说服所有人，直接把数据、样本和失败边界摆出来即可。
二十、FDE 如何选择工具，而不是被工具选择
工具选择应该发生在问题定义之后。
一个简单的判断顺序是：
先判断是否需要模型
如果问题只是把几个系统的信息集中展示，可能不需要 Agent。
再判断是否需要生成能力
如果输出有固定模板，规则和模板引擎可能比模型更稳定。
再判断是否需要检索
如果答案依赖政策、合同、订单或知识库，就要先解决资料来源、版本和权限。
再判断是否需要工具调用
如果 Agent 要查询、写入或触发动作，就要定义工具权限、参数校验和人工审批。
最后判断是否需要多步 Agent
只有当任务确实需要连续判断、调用多个工具和根据结果调整路径时，才值得引入更复杂的 Agent 编排。
“能用 Agent”不等于“应该用 Agent”。
越复杂的系统，越需要更多评估、监控、权限和维护。FDE 追求的是合适的复杂度，不是最大的技术栈。
二十一、从 MVP 到生产，最容易漏掉的四件事
PoC 到生产：数据、权限、评估和监控。
1. 谁来维护规则
政策会变，产品会变，客户的说法也会变。
如果没人负责更新知识和规则，系统会慢慢变成旧答案生成器。
2. 谁来处理失败
Agent 失败时，不能只显示“抱歉，请稍后再试”。
要明确：
转给谁； 携带哪些上下文； 是否保留已经完成的动作； 是否需要通知客户； 是否应该记录为新的评估样本。
3. 谁能看到哪些数据
同一个问题，不同角色可能拥有不同权限。
如果系统为了方便，把所有数据都交给模型，短期看似省事，长期会引入严重风险。
4. 谁决定扩大范围
一个用例跑通后，不代表可以直接覆盖所有部门。
扩大前至少要重新确认：
数据是否相同； 规则是否相同； 风险是否相同； 使用者是否相同； 原有评估集是否仍然有效。
生产不是 Demo 的放大版，而是新的验证阶段。
二十二、FDE 和客户一起定义“可用”
“可用”不是一个抽象评价，而应该有观察指标。
可以分成四类：
质量指标
回答是否引用正确资料； 关键字段是否正确； 是否出现编造； 是否识别出需要转人工的场景。
效率指标
单次处理耗时； 人工切换页面次数； 重复录入次数； 人工复核耗时。
采用指标
用户是否真正使用； 建议回复被保留的比例； Agent 结果被改写的比例； 用户主动绕开系统的比例。
业务指标
投诉处理时间； 转化率； 退款错误率； 线索响应时间； 工单关闭率； 客户满意度。
不同项目的指标不同，但有一条原则不变：不能只看模型回答得像不像人。
二十三、为什么采用率有时比准确率更重要
一个回答准确率很高的系统，如果用户不愿意使用，仍然没有业务价值。
用户不用，可能有很多原因：
入口离原有工作路径太远； 回复速度不稳定； 用户看不到依据； 修改结果比自己重写还麻烦； 系统不能处理最常见的例外； 使用结果不会被纳入原有系统。
所以 FDE 需要观察用户如何使用，而不只是观察模型如何回答。
有时一个“准确率稍低，但能嵌入现有工作流、并且依据透明”的工具，比一个“实验室准确率更高、但需要用户改变全部习惯”的工具更容易产生价值。
二十四、如何把用户反馈变成下一轮改进
“用户觉得不好用”不是可执行的反馈。
需要把反馈分类：
找不到入口； 不知道什么时候用； 输出格式不对； 事实依据不够； 需要的字段没取到； 需要人工判断； 权限限制导致无法完成； 结果不错，但还要重复复制粘贴。
每类反馈对应不同的解决办法：
入口问题，改流程和产品界面； 格式问题，改模板和示例； 依据问题，改检索和来源； 权限问题，改工具边界或人工审批； 重复复制问题，改系统集成； 判断问题，补充规则、案例和评估集。
这就是 FDE 的反馈价值：不是把所有问题都归因于模型，而是把问题放回正确的层级。
二十五、FDE 的工作节奏：短周期、强反馈
FDE 项目不适合几个月不见结果，最后一次性交付。
更合理的节奏是：
每一轮都应该有一个可以被观察的结果。
不是每天都要发布新功能，而是每一轮都要减少一个关键的不确定性：
不确定客户真正要什么，就先做访谈； 不确定数据是否够用，就先做样本盘点； 不确定模型是否稳定，就先做评估； 不确定用户是否采用，就先做小范围试用； 不确定能否上线，就先验证权限、日志和异常路径。
二十六、不同角色如何参与 FDE 项目
多方协作：业务、用户、FDE、工程、安全和产品。
FDE 不是一个人包办所有工作，而是一个需要多方协作的角色。
业务负责人
负责确认问题优先级、资源和最终业务指标。
一线用户
负责提供真实流程、例外情况和使用反馈。
FDE
负责把问题转成可交付方案，推进构建、验证和上线。
平台或工程团队
负责基础设施、权限、数据接入和长期维护。
安全与合规团队
负责识别不能妥协的边界，参与高风险动作审批。
产品团队
负责识别哪些现场需求可以沉淀为通用产品能力。
如果每个角色都只完成自己的局部任务，项目会重新变成传统交接链；FDE 的作用，是让这些角色围绕一个真实结果持续协作。
二十七、FDE 不是“客户说什么就做什么”
有些人把客户成功理解成满足客户所有要求。
但如果客户提出的要求会带来不可接受的风险，FDE 应该把问题讲清楚：
这个动作为什么不能自动执行； 哪些数据当前不能接入； 哪个指标暂时无法承诺； 哪些范围需要拆成下一阶段； 哪个方案看似快，但后续维护成本更高。
拒绝不等于对抗。
更好的拒绝方式，是同时提供一个可行替代方案：
“不建议第一阶段让 Agent 直接执行退款。可以先读取订单和政策，生成有依据的处理建议，由客服确认后执行；等积累足够的真实样本，再评估是否扩大自动化范围。”
这比一句“技术上有风险”更有帮助，也更容易让项目继续向前。
二十八、FDE 的价值，最后要回到客户的日常
一个系统上线后，客户不会因为架构图漂亮而长期使用它。
他们只会问：
今天用它是不是比以前快； 出错时能不能找到原因； 我能不能看懂它为什么这样建议； 它会不会替我做出我不想承担的决定； 同事离开后，这套方法还能不能继续运行。
如果这些问题有清楚答案，FDE 的工作才算完成了一大半。
剩下的一半，是让系统不断从真实使用中变得更稳，把一次交付变成团队以后可以复用的能力。
这也是为什么 FDE 的交付物不只是代码：还包括问题定义、流程地图、评估集、权限边界、操作手册、失败样本和下一阶段建议。
第三幕：把模糊需求拆成一个小用例
需求拆解：把“万能助手”拆成可验收的小用例。
二十九、完整案例：一个“智能客服”是怎样被拆成第一个用例的
构造案例：从客户消息走到第一个用例。
下面用一个构造的典型场景，演示 FDE 如何走一遍工作过程。
这个案例不讨论某一家公司的具体名称，也不把它当作任何客户的公开成绩。它只用于说明：面对相似的业务诉求，FDE 如何一步一步把问题拆到可以验证的程度。
业务方的第一句话
“我们想做一个智能客服，覆盖售前、售后和投诉，最好可以 24 小时自动处理。”
这句话里同时包含了：
售前咨询； 售后查询； 投诉处理； 全天候服务； 自动执行。
如果直接把它拆成产品菜单，可能会得到一个很大的项目：知识库、对话页面、订单接口、工单接口、用户画像、智能分流、自动退款、数据看板，一项接一项。
但这并不能说明项目真正解决了什么问题。
第一次追问：最近一次是什么情况
FDE 不先展示产品，而是请业务方讲三个最近发生的案例：
一个处理得很顺利的案例； 一个花费时间较长的案例； 一个最后需要升级或返工的案例。
第一个案例通常能看出正常流程；第二个案例能看出效率损失；第三个案例能看出风险边界。
为演示这种问法，下面虚构一个案例；以下内容不是访谈记录：
看起来只是一个物流问题，实际上至少涉及：
订单系统； 仓库状态； 物流数据； 运营群协作； 客户承诺； 工单记录。
如果 Agent 只会检索订单状态，它并不能解决真正的工作阻塞。
第二次追问：哪个动作最耗时
FDE 会让业务方把这次处理按时间拆开：
这时会发现，真正的耗时可能不是生成文字，而是：
信息在多个系统之间分散； 物流状态和仓库状态不同步； 客服不知道哪个信息可以对外承诺； 处理结果还要再录入一次。
如果把所有资源都投入到“让模型说话更自然”，可能解决不了最主要的问题。
第三次追问：哪些信息可以被系统信任
不能因为一个系统里有字段，就默认它是可靠来源。
FDE 要逐项确认：
订单状态由哪个系统产生； 仓库状态多久更新一次； 物流信息是否可能延迟； 售后政策哪个版本有效； 运营群里的口头回复能否作为正式依据； 客服是否有权引用内部备注； 不同角色能看到哪些字段。
如果这些问题没有答案，Agent 的回答即使语言流畅，也可能建立在不可靠的信息上。
因此，第一版可能不应该自动向客户承诺发货时间，而应该生成一份给客服看的建议：
这不如“机器人直接回复客户”看起来自动化程度高，但更符合真实业务责任。
第四次追问：哪类问题最适合先做
把客服问题按频次和风险画成二维表：
这样一来，“智能客服”被拆成了一组有先后顺序的用例，而不是一个无限扩张的目标。
三十、把第一个用例写成一页纸
一个适合启动的用例，可以写成下面这样：
这一页纸有几个作用：
让业务方知道第一阶段不做什么； 让工程师知道需要哪些接口； 让安全团队知道哪些动作必须限制； 让评估人员知道应该测哪些样本； 让管理者知道项目如何判断成败。
三十一、从用例到最小版本，不要先做完整平台
最小版本可以只有四个组件：
它甚至不需要一开始就拥有独立的复杂聊天页面。
如果客服原本就在工单系统里工作，第一版可以把建议嵌入工单页面；如果客户还没有稳定的订单接口，第一版可以从一批授权的样本数据开始验证检索和边界，但必须明确这只是验证阶段，不能写成已经接入生产。
FDE 要避免一个陷阱：为了证明“系统很完整”，先建设大量平台能力，最后才发现用户不愿意改变工作方式。
应该先验证最重要的假设：
客服是否愿意在当前工作路径中使用这份有依据的建议？
如果连这个假设都不成立，继续增加 Agent 数量和工具数量，只会把错误方向做得更大。
三十二、第一轮测试应该怎么设计
测试不能只准备“标准问题”。以下记录格式为构造示例，不是本文项目的实测结果。
可以把样本分成六组：
A 组：完整且正常
订单号完整，订单和物流状态一致，政策明确。
目标：验证基本流程是否可用。
B 组：信息缺失
订单号缺失、字段为空、客户只提供了模糊描述。
目标：验证系统是否会先补信息，而不是直接猜测。
C 组：数据冲突
订单状态栏显示已出库，物流状态栏显示未揽收；或者政策文件存在新旧版本。
目标：验证系统是否识别冲突并转人工。
D 组：权限差异
不同角色访问同一订单时，能够看到的字段不同。
目标：验证模型不会因为回答需要而绕过权限。
E 组：高风险请求
客户要求退款、补偿、改地址或绕过政策。
目标：验证系统能否区分建议和执行。
F 组：对抗和情绪输入
客户使用强烈措辞、重复催促或故意提供错误信息。
目标：验证系统是否保持事实边界，不被语言压力带偏。
每组都要记录：
输入； 可用上下文； Agent 动作； 使用的工具； 返回内容； 人工判断； 是否需要转人工； 错误后果。
三十三、测试结果不能只写“通过”
“通过”没有足够信息。
更好的结果记录是：
这样的测试记录，才可以指导下一轮开发。
它还会产生一个重要变化：失败不再只是“模型答错了一道题”，而会被追溯到具体层级：
数据没有拿到； 数据版本不对； 检索没有找到； 工具参数错误； 权限边界不清； 模型推理错误； 回复模板不合适； 人工流程没有接住。
找到问题所在，才知道该修模型、修数据、修工具，还是修流程。
三十四、上线试用时，先看用户绕不绕开
用户采用：使用、修改、绕开和反馈。
如果进入小范围试用，重点不应是让客服完成更多演示，而应在获得授权的前提下观察实际工作行为。
需要看：
客服是否主动打开助手； 是否把真实问题输入进去； 是否查看依据； 是否直接复制回复； 哪些结果被频繁修改； 哪些场景被直接绕过； 遇到失败后用户是否知道下一步怎么办。
“用户没有报错”不等于“用户觉得好用”。
有些用户遇到问题不会提交反馈，只会悄悄回到旧流程。因此，使用日志、操作路径和人工访谈都需要结合起来看。
三十五、上线后的第一轮改进，往往不是换模型
为说明如何解读试用反馈，假设一组示例观察结果如下（非真实项目数据）：
订单状态回答基本正确； 客服经常修改回复里的承诺时间； 客服很少点击政策依据； 大量问题仍然需要去运营群确认； 用户喜欢事实摘要，不喜欢过长的解释。
这时最应该改的，可能是：
把未确认的时间单独标出来； 把依据放在回复草稿旁边； 增加运营确认入口； 缩短输出格式； 将“事实、待确认、建议动作”分栏展示。
如果只把模型换成更强的版本，未必能解决这些问题。
FDE 要从用户行为判断问题在哪一层，而不是把所有反馈都归结为模型能力不足。
三十六、第二阶段何时扩大自动化范围
在真实项目中，只有当第一阶段经评估能够稳定完成以下事项，才可以讨论下一阶段；本文没有给出已完成项目的验收结论：
查询订单； 获取物流状态； 引用有效政策； 生成事实准确的回复草稿； 在异常情况下转人工；
才可以讨论下一阶段。
下一阶段也不应该直接跳到“自动退款”，而可以依次扩大：
1. 自动识别问题类型；
2. 自动补齐查询所需字段；
3. 自动生成工单摘要；
4. 自动推荐处理路径；
5. 在低风险场景下发送标准回复；
6. 对特定动作提供人工确认按钮；
7. 在积累充分证据后，再评估更高权限动作。
每扩大一步，都要重新做样本、权限、责任和业务指标检查。
三十七、如果项目最后没有继续，也能留下什么
不是所有试点都会进入正式生产。
如果评估后发现：
数据同步成本太高； 用户改变流程的成本太大； 自动化收益不足； 风险无法被合理控制； 人工处理已经足够高效；
项目可以停止，但诊断成果不应该消失。
至少可以留下：
当前流程地图； 数据问题清单； 失败样本； 权限边界； 未来适合自动化的候选点； 不适合自动化的原因。
这些内容会帮助下一次项目少走弯路。
FDE 的价值不只体现在“上线了一个 Agent”，也体现在让团队知道：为什么现在不应该上线，下一次需要先补什么。
三十八、把一个项目沉淀成下一次的起点
能力复用：现场经验沉淀成模板和 Skill。
项目完成后，应该问三个问题：
哪些内容可以复用
例如：订单查询工具、政策版本检查、客服回复模板、评估样本格式。
哪些内容只能留在当前客户
例如：客户独有的系统接口、内部政策、角色权限和业务术语。
哪些内容应该回流产品
例如：多个客户都遇到的字段映射问题、通用的人机协作模式、常见的异常处理和评估方法。
这一步把 FDE 从“项目交付者”推进成“现场经验的生产者”。
Palantir 对 FDSE 的介绍提到，现场工程师会把技术经验和配置的解决方案反馈给业务开发及产品开发团队，并称部分产品补充源于这一过程。[1] 这可以作为“现场经验回流产品”的一个公开示例，但不等于所有 FDE 项目都会形成通用能力。
Claude 对 Skills 的介绍将其描述为一种封装可重复流程、标准、参考资料和示例的方式，使相关任务可以按预先定义的方法处理。[3] 对本文而言，它可作为交付经验结构化沉淀的一个工具示例。
OpenFDE 的客户案例页列出多个按行业和任务描述的 Agent 案例，例如承接咨询、自动随访、核对库存和识别预约意图。[4] 这些公开案例可作为“按具体业务任务描述 Agent”的示例；不能据此推断所有项目都已形成可持续复用能力。
三者的共同点是：项目不能只留下一个演示链接，还要留下下一次可以继续使用的知识和结构。
三十九、为什么 FDE 的工作很难被一份模板完全替代
模板可以帮助团队少漏问题，但不能替代现场判断。
同样是“客服自动化”，不同客户可能有不同情况：
一个客户的订单系统很稳定，物流系统经常延迟； 另一个客户的物流数据稳定，但政策版本混乱； 一个客户允许客服处理小额补偿； 另一个客户所有补偿都必须审批； 一个客户的用户主要通过电话咨询； 另一个客户主要在私域和社群咨询。
模板可以提供问题清单，不能预先决定哪一个问题最重要。
FDE 的专业性，恰恰体现在面对差异时能够快速建立判断：
哪些约束必须保留； 哪些差异值得定制； 哪些需求可以暂缓； 哪些经验可以抽象； 哪些结果还不能承诺。
四十一、FDE 现场最常见的三种误判
误判一：把最响亮的问题当成最重要的问题
会议里声音最大的人，未必代表问题影响最大的人。
管理层可能最关心“有没有 AI”；一线员工最关心“每天要不要重复录入”；技术团队最关心“接口能不能接通”；客户最终关心的，却可能是响应时间和承诺是否准确。
FDE 需要把不同人的关注点放在同一张图上：
这五个角色可能完全不是同一个人。
如果只听提出需求的人，容易做出管理层喜欢、使用者不愿意用的系统；如果只听一线用户，又可能忽略预算、权限和组织责任。FDE 的工作，是让不同角色围绕同一个可观察结果达成一致。
误判二：把最容易展示的问题当成最值得解决的问题
“让模型写一段回复”很容易演示，效果也容易看起来不错。
但真正影响业务的，可能是：
回复依据不完整； 订单状态不一致； 关键动作没有审批； 处理结果没有回写； 一线人员还要手动复制三次。
演示价值和业务价值不是一回事。
FDE 应该问：
“如果这个功能明天消失，谁会立刻感到损失？”
如果没有人会感到损失，它可能只是一个漂亮的功能，而不是优先级高的用例。
误判三：把最先进的方案当成最合适的方案
多 Agent、复杂编排、长上下文和自动执行，听起来都很有吸引力。
但一个客户可能只需要：
一个清晰的查询入口； 一套统一的政策资料； 一个能显示依据的回复模板； 一个简单的人工确认按钮。
如果简单方案已经能够解决问题，复杂方案只会增加维护和故障成本。
FDE 的技术判断，不是把系统做得尽可能复杂，而是让系统在当前约束下足够可靠。
四十二、如何向客户解释“第一阶段不做什么”
范围管理最难的部分，通常不是写下要做什么，而是说明暂时不做什么。
客户可能担心：
不做是不是能力不够； 不做是不是以后也不做； 不做会不会错过机会； 为什么别人可以做，我们不可以做。
可以用三个维度解释：
当前证据不够
例如，还没有足够真实样本证明系统能稳定处理某类问题。
当前责任不清
例如，系统可以给出建议，但没有明确的人负责批准最终动作。
当前收益不够
例如，自动化成本高于人工处理成本，暂时不值得投入。
“不做”不是把需求关掉，而是把它放到一个有条件的后续判断里：
这样既没有假装所有事情都能马上完成，也没有把未来空间直接关死。
四十三、FDE 如何写一份客户真正会使用的方案
方案文档不应该从技术架构开始。
客户更需要先看到：
1. 现在的问题是什么；
2. 第一阶段解决哪一段；
3. 用户会怎样使用；
4. 系统会读取什么；
5. 系统会做什么；
6. 系统不会做什么；
7. 怎样判断是否值得继续。
可以采用下面的结构：
架构图、模型说明和技术栈可以放在后面，但不能代替前面的内容。
如果业务负责人读完文档，仍然不知道“明天谁会怎么用”，说明方案还停留在技术语言里。
四十四、FDE 的方案评审，不是把所有人拉来投票
评审会最容易变成观点堆积：
业务方说要更多功能； 工程师说接口有风险； 安全团队说需要更多审批； 产品团队说未来可以统一； 管理者问什么时候能看到结果。
FDE 需要提前把评审问题写成决定项：
每个决定项都要有：
当前事实； 可选方案； 各自代价； 推荐选择； 最终负责人。
这样评审才是在做决定，而不是让所有人表达一次意见后继续悬而未决。
四十五、FDE 如何面对“先做出来再说”
“先做出来再说”有时是合理的，因为很多问题不做就无法知道答案。
但先做也需要边界。
可以把它分成两类：
可逆实验
使用脱敏数据； 只读访问； 不触发外部动作； 有固定样本； 可以随时删除或回滚。
这类实验可以快速开始。
不可逆动作
修改生产数据； 对外发送承诺； 执行退款和付款； 改变权限； 影响客户权益； 自动创建大量外部记录。
这类动作必须先完成审批、审计和回滚设计。
FDE 并不反对速度，而是把速度用在可逆的地方，把谨慎用在不可逆的地方。
四十六、一个好的 PoC，应该回答三个问题
PoC 不是为了证明“技术可以运行”，而是为了降低关键不确定性。
至少要回答：
能不能解决目标问题
不是能不能回答，而是能不能减少某个具体工作成本或错误。
能不能被目标用户采用
不是产品团队觉得好不好，而是一线用户是否愿意在真实工作里使用。
能不能继续进入生产
数据、权限、性能、成本、异常和责任是否有可行路径。
如果 PoC 只回答了第一个问题，仍然不能直接上线。
四十七、PoC 结果应该如何向管理者汇报
管理者通常不需要听完整的调试过程，但需要知道：
做了什么； 解决了什么； 没解决什么； 风险在哪里； 下一步需要什么决定。
可以使用四段式汇报：
不要只汇报成功样本。
失败样本往往更能帮助管理者判断项目是否成熟：
哪些场景系统会主动停下； 哪些场景必须人工接管； 哪些问题是数据问题； 哪些问题需要改变流程； 哪些问题暂时没有经济性。
四十八、FDE 如何证明价值，而不夸大结果
AI 项目很容易出现“效率提升明显”“大幅降低成本”这类表达，但如果没有前后对照，结论不够可靠。
价值证明至少要建立基线：
还要注意样本是否可比：
问题难度是否相同； 参与人员是否相同； 业务高峰和低谷是否混在一起； 是否因为试用期有额外培训； 是否有其他流程变化同时发生。
不能因为上线后某个数字变好了，就把所有改善都归因于 Agent。
稳妥的表达是：
若在限定样本和试用流程中观察到处理时间下降，可写为：“在本次限定样本和试用流程中，观察到处理时间下降；该结果还需要在更长周期和更大样本中复核。”本文未提供该结果。
这比一句“效率提升某个百分比”更可信，也更能经得起复盘。
四十九、FDE 如何把“用户不满意”变成工程任务
客户说“这个不好用”，需要被转换成具体问题。
可以追问：
是找不到入口，还是入口太慢？ 是答案不准确，还是依据不透明？ 是生成结果不符合格式，还是操作路径太长？ 是系统经常失败，还是失败后没人接？ 是结果不值得信任，还是用户没有权限查看依据？
不同答案，意味着不同修复方式。
这一步把情绪反馈转成工程任务，也把工程团队从“模型又不行了”的模糊判断中解放出来。
五十、FDE 的成长，不只是学更多技术
FDE 当然需要技术能力，但技术不是唯一的成长方向。
还需要逐渐建立四种判断：
问题判断
能否分辨客户说的功能和真正的业务问题。
范围判断
能否找到最小但有价值的第一步。
风险判断
能否知道哪些动作必须停下来，哪些风险可以通过实验降低。
复用判断
能否从一次客户交付中发现下一次可以复用的模式。
这四种判断决定了 FDE 能否从“接需求做项目”，成长为“发现问题并推动结果”。
五十一、这也是 AI-native 工作方式真正改变的地方
AI-native 的重点，不是让每个人都变成 Prompt 工程师，也不是把所有岗位都换成 Agent。
它改变的是工作的组织方式：
问题不再只停留在会议里； 意图可以被写成共享文件； 设计可以被持续修改和追踪； 代码和测试可以更快生成； 评估可以持续进行； 线上异常可以重新进入问题定义； 经验可以沉淀成 Skill、模板和产品能力。
FDE 恰好是最适合采用这种方式的人群之一，因为他们本来就要在业务、工程和交付之间不断切换。
但 AI-native 不会自动带来好结果。
如果问题定义错了，AI 会更快地做错；如果权限边界不清，AI 会更快地扩大风险；如果评估标准缺失，AI 会更快地产生大量无法判断的输出。
因此，速度越快，判断和验证越重要。
五十二、第一章的延伸清单
如果你准备开始做一个 FDE 项目，可以先准备这六份材料：
1. 问题卡
写清楚谁遇到什么问题，问题发生频率和当前代价。
2. 流程图
画出实际操作，而不是理想流程。
3. 用例表
列出候选用例、价值、风险、数据依赖和优先级。
4. 边界表
写清楚允许、需要确认和禁止的动作。
5. 评估集
收集正常、缺失、冲突、越权和异常样本。
6. 复盘表
记录哪些结果被采用，哪些被修改，哪些被绕过，以及原因是什么。
这六份材料不需要一开始就写得很复杂，但必须真实、可更新、有人负责。
五十三、给准备转 FDE 的人的一句提醒
不要把转型目标设成“学会所有 AI 框架”。
更有效的准备方式是，找一个真实工作问题，完成一次完整的小交付：
找到真实使用者； 记录现有流程； 找到一个高频小环节； 用真实样本验证； 设置明确边界； 让用户试用； 记录失败； 复盘是否值得继续。
这个过程比单纯做一个聊天机器人更能说明你是否具备 FDE 的基本能力。
因为 FDE 面试和实际工作最终都会追问：
你解决了谁的问题？你是怎么判断的？遇到什么失败？最后怎么证明结果真的有变化？
五十四、第一章的公开表达边界
FDE 内容很容易写成两种极端：
一种是把岗位包装成高薪风口，只讲职位名称、公司和薪资；另一种是把内部项目写得过于具体，暴露客户、数据和交付细节。
更稳妥的公开表达应该做到：
讲方法，不泄露客户机密； 讲场景，不虚构成功案例； 讲指标，不把局部结果写成行业结论； 讲失败，不把失败包装成成功； 讲工具，但不让工具抢走业务问题； 讲经验，但明确哪些是通用方法，哪些只是特定项目的判断。
公开内容的可信度，不来自细节越多，而来自边界说得清楚。
第四幕：让结果能够留下来
交付链：从问题、流程到上线和复盘。
五十六、客户、FDE 和 Agent，三者到底怎么分工
很多人第一次接触 Agent 项目时，会把三者的关系想成：客户提出需求，FDE 写好系统，Agent 自动完成工作。
真实情况要复杂一些。
客户负责提供方向和判断标准
客户最了解业务现场：谁在工作，流程如何运转，什么结果有价值，什么错误不能接受。
客户不一定知道应该用什么模型，也不一定能把需求写成技术规格，但必须参与确认：
问题是否真实存在； 优先级是否合理； 结果是否有业务意义； 哪些边界不能突破； 试用后是否愿意改变工作方式。
FDE 负责把方向变成交付
FDE 把业务问题转换成：
可验证的用例； 可执行的流程； 可接入的数据； 可控制的权限； 可观察的指标； 可复盘的结果。
FDE 不是替客户决定所有业务，也不是把所有事情都交给 Agent，而是负责让项目在现实约束下继续推进。
Agent 负责执行被定义好的工作
Agent 可以理解任务、调用工具、生成结果、观察反馈和继续下一步，但它的能力受以下条件约束：
上下文是否完整； 数据是否可靠； 工具是否可用； 权限是否足够； 规则是否清楚； 结果是否被检查。
把 Agent 想象成“什么都能自己决定的数字员工”，会掩盖系统真正的边界。
更准确的说法是：Agent 是一套能够在给定上下文、工具和权限下执行多步任务的系统，它仍然需要被设计、评估和监督。
五十七、为什么 FDE 必须同时懂业务和工程
只懂业务，容易提出一个很有价值但无法落地的方案；只懂工程，容易做出一个能运行但没人需要的系统。
FDE 的工作需要在两种语言之间来回翻译：
翻译不是把业务词换成技术词，而是确保两边谈的是同一个问题。
如果工程团队解决的是“如何调用模型”，业务方关心的是“为什么客户还在等待”，项目就会出现方向偏差。
五十八、FDE 需要建立自己的问题账本
一个项目不会只有一个问题。
在交付过程中，FDE 可以维护一份问题账本，把每个问题记录成五项：
问题账本的价值是让团队不再依靠印象推进。
随着项目变化，问题可以被标记为：
已确认； 待验证； 已解决； 暂缓； 不建议处理。
每次会议都围绕问题状态变化展开，而不是重新从头描述背景。
五十九、FDE 需要建立自己的证据链
一个结论如果没有证据，就只能算观点。
例如：
“客服不喜欢这个工具。”
可以继续拆成：
有多少客服使用过； 使用了几次； 哪一步退出； 输出被修改了多少； 哪些问题最常被绕开； 用户访谈怎么说； 是否还有其他系统或培训因素影响结果。
同样，
“模型已经足够准确。”
也要继续问：
在什么样本上； 哪些错误被排除； 是否包含缺失和冲突输入； 是否包含权限限制； 是否测过高风险动作； 是模型回答准确，还是业务结果真的改善。
FDE 的专业性，很大一部分来自不轻易接受未经拆解的结论。
六十、好的 FDE 交付，应该让客户越来越独立
如果项目必须长期依赖外部人员才能运行，说明能力沉淀还不够。
交付过程中需要逐步完成移交：
客户知道系统解决什么问题； 客户知道系统不解决什么问题； 客户知道如何查看依据； 客户知道什么时候转人工； 客户知道如何补充评估样本； 客户知道谁可以修改规则； 客户知道上线后看哪些指标； 客户知道出现异常时如何回滚或暂停。
这不意味着 FDE 交付后完全不再参与，而是客户不能只能依靠“某个专家记得怎么做”。
真正成熟的项目，会把判断标准、操作路径和失败边界留下来，让更多人能够接手。
六十一、把本章方法压缩成一张工作卡
这张工作卡没有复杂术语，但它覆盖了 FDE 最重要的七个判断点：问题、流程、用例、边界、验证、上线和沉淀。
交付现场的四个取舍
FDE 的工作常常不是在好方案和坏方案之间选择，而是在几个都不完美的方案之间做取舍。
速度与可靠性
只读查询、建议生成和人工确认，通常可以先快一点；自动修改、自动承诺和自动付款，则必须慢一点。速度应该优先用于降低不确定性，而不是跳过责任边界。
定制与复用
为一个客户做得越深，当前项目可能越顺，但以后越难复用。FDE 要记录哪些部分是客户独有的，哪些部分是多个项目都会出现的模式，避免把一次性改动误认为通用能力。
自动化与可解释
完全自动执行看起来效率更高，但用户未必敢用。很多场景先给出事实、依据和建议，让人保留最终判断，反而更容易进入日常工作。
完整与可交付
功能越多，依赖越多，越容易延期。一个范围小、边界清楚、失败可接住的版本，往往比功能完整却没有明确责任人的平台更接近真正的交付。
每次取舍都应该写下理由。理由不是为了给方案增加仪式感，而是为了让下一次复盘知道：当时掌握了什么证据，接受了什么代价，留下了哪些待验证问题。
交付结束时，怎样才算真正交接
很多项目在演示会结束后就宣布交付，但客户真正接手时才发现：不知道资料放在哪里，不知道规则由谁更新，也不知道出现异常时该暂停哪一部分。
一份能被接手的交付包，至少要有四层内容。
第一层是使用说明：谁在什么场景下打开系统，输入什么，看到什么结果，遇到什么情况转给谁。
第二层是判断边界：哪些结果可以直接采用，哪些必须核对来源，哪些动作必须人工批准，哪些情况只能停止。
第三层是维护方法：资料多久检查一次，政策更新后如何重跑评估，模型或接口变化后谁负责确认，错误样本如何加入下一轮测试。
第四层是复盘记录：项目解决了什么，暂时没有解决什么，哪些指标发生变化，哪些变化还不能归因，下一阶段需要什么前置条件。
交接不是把文件发出去，而是让接手的人能够完成一次真实操作，并知道自己为什么可以相信这个结果。FDE 如果离场后客户只能继续寻找原来的那个人，说明项目交付的是依赖，而不是能力。
公开分享时，哪些细节应该留下
FDE 的工作天然接近客户现场，但公开写作不能把“细节丰富”误解成“把现场全部讲出来”。可以留下的是问题类型、判断过程、技术边界、评估方法和可复用模板；应该隐藏的是客户名称、业务数据、内部链接、权限配置、具体账号、未公开指标以及能够反推出客户身份的细节。
一个好的公开案例，不需要证明某家公司有多成功，而要让读者看懂一个判断是如何形成的：当时有哪些选择，为什么先做这一小步，什么风险被挡住，什么结果仍然需要继续验证。这样的内容既有现场感，也不会把保密信息当成故事素材。公开文章最重要的不是细节数量，而是判断过程足够清楚、边界足够诚实、读者能够带走下一步行动。
这也是第一章的写作边界：不把客户项目包装成传奇，不把构造示例写成真实战绩，不把一个团队的做法外推成所有公司的标准。把能证明的写清楚，把不能证明的留在边界之外，文章反而更可信。
一个用例的一周推进节奏
一周推进：每天减少一个关键不确定性。
为了让前面的原则更具体，可以把一个低风险、只读型用例放进一周的交付节奏里。这里的“一周”不是所有项目的固定承诺，而是一种帮助团队减少等待、快速暴露问题的工作方式。
第一天：只做问题和流程
上午确认目标用户、最近一次真实事件和当前流程；下午把流程中的系统、人工判断、例外和责任人标出来。当天的产物只有问题卡、流程图和问题清单。
第二天：确定一个小用例
把候选问题按频率、价值、数据可得性和风险比较。优先选择输入相对清楚、输出容易检查、失败后可以转人工的环节，并明确第一阶段暂时不做什么。
第三天：确认数据和权限
准备第一批真实样本，确认字段、脱敏范围、资料版本和操作权限。接口不存在、字段含义不一致、文档没人维护等问题，要进入风险清单，不能藏在开发过程中。
第四天：做一个可观察的最小版本
最小版本不追求完整，而要能看见输入、上下文、工具调用、输出结果和人工接管点。如果只能看到最后一段回答，却看不到依据和状态，就很难定位问题。
第五天：用真实样本跑评估
把正常、缺失、冲突、权限和高风险样本放在一起跑。结论不只写“准确率不错”，还要写哪些样本可以继续、哪些必须转人工、哪些暴露了数据或流程问题。
第六天：让少量真实用户试用
让一线用户在原有工作路径中使用，观察他们是否打开、查看依据、修改结果或绕开系统。用户绕开系统不是“不配合”，而是系统没有降低工作成本的反馈。
第七天：做决定，而不是写漂亮总结
一周结束时，只做三个决定：继续扩大、带着问题继续验证，还是暂缓项目。继续扩大要写清新增范围和证据要求；继续验证要写清还缺哪一个答案；暂缓也要保存流程、样本和失败结论。
收束：真正的开工，是问题终于变清楚
本章总结：问题、边界、证据和责任。
FDE 的工作不是把 AI 推进客户公司，而是把客户真正需要改变的那一小段工作，推进到一个可以运行、可以观察、可以改进的状态。
从一句“我要一个 AI 助手”开始，最后必须落到这些具体问题：
谁在什么场景下遇到了什么问题； 当前流程如何运行，哪里真正卡住； 第一个用例为什么值得先做； 系统能读取什么，能执行什么，必须拒绝什么； 真实用户是否愿意采用； 什么证据足以支持上线或扩大； 项目结束后，哪些经验会留下来。
模型只是其中一个环节。真正决定项目能不能落地的，是问题是否清楚、数据是否可用、权限是否合理、用户是否愿意改变工作方式，以及团队能否持续观察结果。
客户说“我要一个 AI 助手”时，FDE 不急着回答“可以”。他会先问：
哪个人，在哪个时刻，正被哪一个具体问题拖住？
这个问题找到了，AI 才有进入业务的入口。读者如果只记住一件事，可以记住这张顺序表：先问谁被什么问题拖住，再看问题如何发生；先选一个能验证的小环节，再谈模型和工具；先写清楚系统不能做什么，再讨论自动化能做到什么；最后用真实使用结果决定是否扩大。顺序一旦反过来，项目就容易从解决问题变成展示技术。读者可以把这张顺序表当作一次最小诊断：如果其中任意一项答不上来，就先别急着把项目命名为智能化，先把缺失的事实补齐，再决定下一步。真正值得推进的项目，不一定最复杂，但一定能说清楚问题、边界、证据和责任。也只有这样，项目才有机会从一次试点，变成可以持续改进的业务能力，也才值得进入下一轮投入。好的 FDE 项目，永远会留下下一步的依据和清晰边界。
延伸阅读
[1] Palantir：A Day in the Life of a Palantir Forward Deployed Software Engineer
https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1
[2] Claude：The AI-Native SDLC Playbook
https://claude.com/blog/the-ai-native-sdlc-playbook
[3] Claude：Teach Claude your way of working using Skills
https://claude.com/resources/tutorials/teach-claude-your-way-of-working-using-skills
[4] OpenFDE：客户案例
https://openfde.net/zh/cases
关注，继续看 FDE 如何把 AI 从演示推进到真实业务。回复 「FDE」，获取本文的“AI 用例拆解四问”清单。