一个优秀 FDE 的一天：从老板需求到 AI 上线，只用 48 小时

周一早上九点，老板把技术负责人、售后经理和 FDE 叫进会议室，只说了一句话： “最近售后回复太慢，能不能做个 AI，今天就开始？”

传统项目的下一步，可能是写需求、立项、评审、排期。FDE 的下一步却不是打开电脑写代码。他先拿起白板笔，连续问了五个问题：慢在哪一步？什么工单最耗时？回复错了会发生什么？现在怎么衡量？谁愿意明天真的使用？

48 小时后，一个只对五名售后工程师开放、每条回复都要人工确认、可以随时停掉的 AI 工单助手进入试运行。

这听起来像一篇效率爽文，但我先把边界说清楚： 下面是把多个常见企业 AI 项目压缩后的合成场景，时间、样本和结果数字均为方法示意，不对应某一家真实企业，也不构成通用效率承诺。

这里的“上线”是受控试运行，不是完成了安全审计、灾备、全量集成和组织推广的企业级生产上线。

我们要看的，是一个优秀 FDE 如何在两天里缩小问题、构建系统、保护风险，并获得第一轮真实反馈。

售后经理最初的方案很具体：做一个聊天机器人，把所有设备手册都放进去，让工程师遇到问题就问。

FDE 没有直接同意。他请三名售后工程师打开昨天的工单，现场演示从收到问题到发出回复的全过程。

很快发现，真正耗时的不是“不会写回复”，而是三次切换：先根据设备序列号找型号和软件版本，再到几个文件夹搜索对应手册，最后翻历史工单确认这个故障是否出现过。简单问题五分钟能处理，复杂问题可能半小时；最危险的不是慢，而是引用了旧版手册，给出过期操作步骤。

因此，问题被重新定义为： 针对一个设备系列的技术咨询工单，自动找出对应版本的手册片段和相似历史记录，生成一份带证据的回复草稿，由售后工程师确认后手工发送。

这次改写做了四个重要减法：只做一个设备系列；只处理技术咨询，不碰退货和安全事故；只生成草稿，不自动发给客户；每个结论必须带来源。

FDE 同时写下第一版指标：准备一条回复需要的时间、证据引用正确率、工程师采纳或修改情况、高风险错误数量。老板要的“快”，终于变成了一个能够验证的问题。

10:30：他坐到一线旁边，而不是回工位开需求会

接下来一个半小时，FDE 不断追问例外。

设备序列号有时录错怎么办？同一个型号为什么有三个手册版本？历史工单里有没有客户隐私？售后工程师什么时候必须升级给高级专家？哪些词出现时绝不能由 AI 建议处理？

一线用户会自然说出文档里没有的规则：如果工单提到异响、过热或安全联锁，必须立即转人工专家；如果设备固件版本无法确认，只能给排查问题，不能给操作步骤；如果引用没有页码，工程师不会相信。

这些不是“后续优化”，而是第一版系统的设计输入。

FDE 在白板上画出最小流程：工单进入后先判断范围与风险；范围外直接退出；范围内根据设备信息筛选资料版本；检索手册和相似记录；生成带页码的草稿；工程师选择采纳、修改或拒绝；所有动作留日志。

此时还没有一行代码，但项目最重要的工作已经完成了一半： 知道什么不做，知道什么算错，知道谁拥有最终决定。

12:00：拉数据不是“把所有文档扔进去”

中午，数据工程师和 FDE 一起准备最小数据包：一个设备系列的现行手册、旧版本停用清单、经过脱敏的历史工单，以及设备型号和固件版本的映射表。

他们没有把整个知识库开放给模型，也没有把历史工单直接复制到个人工具。先确认数据授权，在受控目录内脱敏客户名称、电话和地址；给文档增加版本、适用型号、生效日期和页码；从历史工单中挑出一组覆盖常见问题、长尾问题和风险词的测试样本。

在这个合成场景中，可以把样本想象成 300 条历史工单，其中一部分用于开发，一部分封存用于第二天盲测。具体数量并不重要，重要的是不能拿开发时反复看过的几个漂亮案例，同时充当上线证据。

测试标准也不只是“回答像不像”。团队分别检查范围识别、版本匹配、证据可追溯、草稿可用性与高风险退出。只要出现一条本应升级人工却给出明确操作建议的错误，试运行就暂停。

14:00：Codex 和 WorkBuddy 上场，但人仍然负责判断

下午两点，FDE 才开始真正构建。

他让 Codex 先读取经过授权的项目目录和接口约束，生成一个最小 Web 应用骨架：工单输入、设备信息校验、资料检索、带引用的草稿、人工确认按钮和审计日志。随后让它补测试、评估脚本、容器配置和最小部署说明，并逐项审查变更。

OpenAI 对 Codex 的当前描述已经覆盖从有针对性的修改到设计、构建、发布和维护的软件生命周期工作；官方也展示过从设计稿到功能原型的协作方式。但“能生成”不等于“可以不审”。模型如何访问数据、接口能否写入生产、什么命令需要批准，仍由工程师明确。

腾讯 WorkBuddy 在这个故事里承担另一部分工作：读取授权目录中的会议记录、流程截图和测试表，整理成需求摘要、风险清单、用户试用说明与测试报告；Coding Mode 也可辅助前端页面和问题修复。腾讯官方将其定位为能规划执行多步骤任务、操作授权本地文件并交付可验证结果的 AI 工作台。实际可用功能会随版本、账号和权限不同，团队仍要检查每个产物。

这里有一个很关键的工作方式：FDE 不会给两个工具一句“做个售后智能体”然后等待奇迹。他把任务拆成可验证的小块，每一块都附带输入、限制和验收方式。代码代理失败时，也不只是重复提示“再试一次”，而是检查缺少了数据说明、测试样本、工具接口还是环境约束。

17:30：第一次评估失败，真正的项目现在才开始

第一版很快能跑，但结果并不好。

系统在常见工单上给出的草稿很流畅，却有两类问题：一是检索结果混入旧版手册，二是遇到固件版本缺失时仍然给出了过于肯定的步骤。

如果团队只准备做 Demo，这个版本已经足够在会议室展示。FDE 关注的是它能否进入现场。他先把文档版本从“提示词提醒”升级为检索前的硬过滤；再把固件版本缺失设为明确退出条件，只允许系统追问信息；风险词命中后不再生成建议，直接显示升级路径。

第二轮评估里，语言可能没有第一版那么“聪明”，但行为边界更清楚。这正是企业 AI 经常被忽略的取舍：可靠系统并不追求每次都回答，而要知道什么时候不能回答。

20:30：晚上部署，但只打开四道门中的第一道

晚上八点半，团队把系统部署到内部测试环境。它只能读取经过筛选的资料，不能写回 CRM，不能自动发送消息，只有五个指定账号可以登录，每条草稿都必须由工程师确认。日志记录输入、检索证据、模型版本、输出、用户动作和错误；一个开关可以立即关闭服务。

OpenAI 公开的 Codex 安全实践强调，要限制代理可以访问什么、对高风险动作要求人工批准，并保留足够的遥测来解释行为。NIST 的 AI 风险管理框架也要求在部署前测试、运行中监控、定义人类监督和停用机制。

因此，两天“上线”合理的定义是有限用户、有限数据、有限动作、有人监督和可回滚。

如果系统能直接操作设备、自动承诺赔付、读取大量敏感数据，或者错误会造成人身与重大财务风险，48 小时就不应该进入真实流程。快不是绕过审批，快是把第一阶段的风险半径设计得足够小。

Day 2，09:00：不用演示数据，先做一轮盲测

第二天早上，团队取出前一天封存的测试集。FDE 不只看总体正确率，而是按失败类型逐条过：范围外工单是否拒绝，设备版本是否匹配，引用能否回到原文，高风险词是否触发升级，草稿是否需要大幅重写。

在一个示意性的测试记录里，团队可能看到这样的结构：大多数常见问题可以给出可追溯草稿，一部分需要工程师修改，少数因信息不足或风险词被系统正确拒绝。真正决定能否试用的，不是一个漂亮总分，而是没有越过事先定义的红线，并且所有失败都能被记录和解释。

十点半，五名售后工程师开始使用真实的新工单。FDE 坐在旁边，不指导他们怎样“正确使用 AI”，只观察他们何时打开、是否信任引用、为什么修改、什么时候直接绕过系统。

很快又出现一个代码之外的问题：工程师不是不信 AI，而是不愿意把设备信息重复输入一遍。FDE 当场把工单中的设备字段自动带入页面，并让 Codex 补上字段校验和测试。另一个用户希望自动发送回复，FDE 明确拒绝，因为当前阶段没有足够证据取消人工确认。

15:00：现场验证的不是模型，而是工作流

下午，团队开始看到第一轮真实反馈。

有的草稿内容正确，但引用展开方式太慢；有的历史案例很相似，却因为客户环境不同不能直接复用；高级工程师不需要完整答案，只想先看到最可能的两份手册。FDE 一边记录，一边区分三个层次：界面问题今天改，数据口径问题交给数据工程师修，涉及风险策略的问题留到阶段评审。

他还看采用行为。用户点击了“采纳”，是否真的节省时间？被修改的段落集中在哪里？被拒绝是系统错误，还是工单本就超出范围？如果用户复制草稿后在别处大改，界面上的采纳率会虚高，必须补充观察。

FDE 的现场感就在这里。模型评估告诉你系统在测试集上表现如何，一线行为告诉你它是否进入真实工作。

17:00：48 小时结束，交付物不是一个 Demo

第二天下午五点，FDE 没有用炫酷演示收尾，而是交出六样东西：可运行的受控应用；带版本和权限的数据包；测试集与评估结果；风险红线和停用开关；五名用户的采用与失败记录；下一阶段的决策建议。

在合成场景里，合理的结论可能是“继续，但不扩到全公司”：再用两周覆盖更多型号，修正文档版本治理，接入只读 CRM 字段，保持人工确认；只有高风险错误持续为零、引用质量稳定、用户确实节省准备时间，才讨论扩大账号。

失败也可能是好结果。如果真实数据证明资料版本混乱、用户需求太分散，或者人工确认反而更费时间，团队可以停止项目，把资源转向更适合的流程。48 小时发现“不值得继续”，往往比两个月后交付一个没人用的系统更有价值。

一个优秀 FDE 的快，到底快在哪里？

第一，缩小问题快。老板说“做 AI”，他能在半天内压缩成一个用户、一段流程、一组数据和一个可验证结果。

第二，建立证据快。不是等系统做完再测试，而是先定义样本、红线和基线，让每次构建都能得到反馈。

第三，修改路径快。FDE 保留从业务到代码的上下文，现场问题不用经过多层转述才能进入产品。

第四，控制风险快。权限、人工确认、日志和停用不是上线前最后补的材料，而是一开始就决定试运行能否发生的条件。

第五，作出决策快。继续、调整或停止都有证据，不用靠更大的愿景掩盖不确定性。

最后，48 小时不是神话，也不是承诺

企业 AI 的大量项目不可能两天完成。遗留系统集成、数据治理、安全评审、压力测试、灾备、合规和组织变革都需要时间。把这些工作删掉，再说“48 小时上线”，只是在重新命名 Demo。

但一个优秀 FDE 确实可以在 48 小时里做成一件重要的事：让模糊需求第一次接触真实数据、真实用户和真实约束，并产生一个可验证、可撤销的下一步。

他使用 Codex、WorkBuddy 或其他工具提高构建速度，但真正稀缺的仍是人的判断：选什么问题，什么不能做，什么算成功，什么时候应该停。

FDE 的一天看起来很杂：开会、看流程、拉数据、写代码、部署、坐在用户旁边、改方案。把这些动作连起来，你会发现他始终只在做同一件事——缩短业务问题与生产反馈之间的距离。