10月18日下午，济南绿地·齐鲁之门京沪会客厅三楼，济南首场WorkBuddy开发者沙龙如期举行。

在我印象中是第一次有活动以“出品人”来形容一场活动的发起人，似乎多了一些格调，也更贴切。我是本场活动的出品人，腾讯云开发者星盟济南城市合伙人王通通，作为一个开发者，平时更习惯躲在幕后干活，这次要站到台前把整场活动撑下来，压力不小。

上一篇回顾写的是本场活动的第二位讲者

兰剑智能AI CIO赵振华老师，他刚用一场互动游戏把大家的情绪调动起来，紧接着就轮到来自腾讯云的FDE专家陈大栋老师

。来自腾讯云原厂的技术观点更让人信服，也更有指导意义。

赵振华：只有三页的PPT，和一场关于开发者未来的深度对谈——首场济南WorkBuddy开发者沙龙第二位讲者

我上台介绍他时，特意解释了一下FDE这个岗位的概念。这个岗位名字听着有些陌生，其实工作很具体：去客户现场，把说不清楚的业务需求梳理明白，再想办法把想法做成真正能用的系统。

介绍完，我把话筒交给了陈大栋老师。

他先跟大家打招呼，随后提醒说时间紧，可能会讲快一点。不过PPT会在活动后发出来，没记全也不用着急。

看起来陈大栋老师是个极致讲究效率的人。

陈大栋老师没有直接演示WorkBuddy，而是先说清楚FDE究竟做什么。FDE全称Forward Deployed Engineer，中文叫前沿部署工程师。

一头连着客户现场，要弄清需求、业务限制和现有系统；另一头连着交付后的使用，要把做过的方案沉淀下来，下一次遇到类似的问题不必从零再来。驻场、设计方案、交付，都是这份工作的一部分。

他以前做过服务端开发，后来接触Agent架构、微调、Workflow、多模态和工具扩展。现在在腾讯做FDE，更多时间花在客户实际场景里：看现有系统怎么运转，找到WorkBuddy能接入的位置，再验证方案能不能真正跑起来。

他把完整过程分成五个环节：理解场景、设计方案、技术选型、确定交付标准，最后交付并复用。

前面几项大家多少都熟悉些。他想多讲的是动手之前，比如要先把验收标准说清楚。

至于最后的交付，他的提醒很关键“FDE能不能离场，要看客户自己接不接得住（其实这也涉及到交付边界的问题）”。

系统上线不等于项目做完。开发人员走了客户还能照常使用，才算交付站稳了。

回头看整场演讲，他反复讲的就是标准。技术选型出了问题还能调整，但验收口径如果等做到一半才商量，前面花的工夫很可能要重来。

一个写稿的活，为什么拿到技术沙龙上讲

案例选得挺出乎我意料：AI热点内容生产。毕竟是开发者沙龙，刚听到“写稿”两个字，我也想过，这个业务线条是不是太小了，无法满足现场各种职业的参会嘉宾的胃口？

后来发现这个场景其实也并不简单。回想我自己平时写文章的过程，找资料、辨别真假、生成不同风格的内容、审核，再由人决定能不能发布，Agent项目里常见的难题几乎都碰得到。而我只是因为早已实现了整个流程，忘记了写稿这件事过去有多么繁琐。

需求很容易听懂，当热点来了我们要怎样在有限的时间里查清资料、选好角度，把稿子写出来，再稳妥地审完。

现在一个热点出现，报道和转载很快就铺满屏幕，内容却容易重复。读者除了知道发生了什么，还想知道前因后果，以及这件事可能带来什么影响。以前靠的主要还是编辑一篇篇到处查，梳理脉络补齐这些内容，。

过去大致就是找素材、核对整理、分平台写稿、反复审核。单看每一步也都比较好理解，但整个工作流程一旦成为多人接力共同协作，就很容易出现问题。

最先卡住的是事实的核对。参考的资料散在不同地方，可靠程度也不同。主编把稿子交给审核时，引用依据未必一起交过去。审核只能笼统地说“这段再严谨些”，却不容易指出到底哪条资料不成立。等到问题被查出来，前面写过的内容又得跟着改了。

第二个麻烦是同一件事要写成不同版本。面对新闻读者文风要稳，发到社区的版本要简单易读，写评论视角的文章又得有观点。换一个平台，写作思路可能就得重新整理。

第三个问题发生在审核和修改这两个节点之间。审核的人不知道原稿为什么这么写，作者也不清楚审核意见的依据是什么。两边为了对齐需要不停地来回问，时间就这样耗掉了。

这些听起来是三个问题，但其实都差不多，原因都在于参与的人没有共享同一套事实和工作记录。

陈大栋老师的处理方法是通过AI让主编和审核专家都能查看同一份底稿，这件事在过去我们可能需要多加一个审核岗位来实现多个协作方的观点对齐。任务要求、素材来源、引用记录、稿件版本，放在同一个上下文里，避免不一致。

谁在依据什么做判断，不用再靠猜。

把“什么算做好”总结成四句话

讲到交付标准时，他特意停下来强调：问题找到了，还得先说清楚怎么才算做成。否则系统跑起来，也不知道该按什么验收。

一，在有限时间里交出一篇质量达标的稿子。

说的事实有依据来源，表达对得上我的读者。

不能主编卡在那儿，审核就空转，时间全耗在等待上。

三，在有效期内拿出可审的稿子。

热点就那么几个小时到几天，过了窗口，写得再好也没人看。在速度与质量之间要找到平衡。

生成了多少篇不重要，有多少可以使用才重要。

这四点看起来并不新鲜，但做项目时很容易反过来：先催开发出结果，等验收才发现大家对“做好”的理解不是一回事（这点我们在做FDE交付时也常常遇到，交付边界不清晰，结果理解不相同，最终交付变得遥遥无期）。

有的人可能会介绍专家团来解决这个问题，陈老师先说为什么不直接用一个提示词，或者画一条固定工作流。

单个Prompt或Skill很像一份固定操作说明。可这件事里，写稿和审核的方向不一样，写稿要根据受众打开思路，审核却要收紧事实和合规边界。把两套要求全塞进一条提示词，调起来很容易顾此失彼。内容写活了可能不够严谨，标准卡得太死又容易变得没人愿意读。

固定Workflow也有局限。它适合环节明确、规则稳定的任务；这里审核标准会变，主编和审核还要反复沟通。如果每次调整标准都得重新改流程，维护成本就变得太高了。

所以他最终采用两个专家角色：内容主（文知远）编负责搜集、写作和修改，审核专家（严求实）负责查依据、提问题和复核。各自配置Skill，同时读取相同的上下文。一个改稿，另一个能知道改的是哪一版、依据又在哪里。

从使用者角度看，入口就是话题和写作要求，比如写给谁、采用什么风格、篇幅多长。出口不止一篇文章，还有素材依据和审稿记录。真正发布之前，人要确认关键事实和争议点。

他还讲了后续能怎么扩展：审核通过后接公众号发布，把反复出现的修改要求写回Skill，或者积累长期素材库供后续文章使用。这些可以逐步做，不必在第一版一次堆满，前期想的太全面其实很容易把工具做的不及预期、方向偏离。

如果两份资料相互矛盾，系统应当把矛盾交出来，不擅自做主悄悄替人选一个答案。这其实也是本场的几位专家共同的意见，不要把判断都交给AI。

接下来是效果的演示，输入框里现在只有一句：“郑钦文中网夺冠。”没有指定文章类型，也没有说写给谁。

我们使用传统的agent它会直接开写，因为要求过于模糊，内容也会缺乏指向性。陈大栋老师展示的平台先追问了本文用途，最后确认要一篇面向大众的观点评论。

他想说明的事情很简单，面对用户的需求不完整时要先问清楚，不能替用户猜。

随后他打开素材包。每个事实能找到对应的原始记录，比如某句话引用了哪些record；同时区分原始事实和媒体自己的解读。至于不同来源相互冲突的地方，则单独标出来，不能混成一条貌似确定的结论。

不同文体对应不同的写作要求。观点评论需要明确观点、拿出证据、考虑反面材料，并把仍需人工确认的地方列出来。如果没有明确的限定边界，AI经常会语气写得像评论，仅仅是形似。

审核报告也有明确内容：审核结果、核对方式、适用版本、存在的边界问题，以及逐项修改建议。改稿后还要再审，不能到一份报告生成后就结束了。

真正让我觉得这套东西能落地的，是他现场讲的三处改稿。

第一处，原稿写“运动员的调整往往发生在艰难赢下的比赛里，而不是等一切准备完美才开始”。这句话把郑钦文一个人的经历，说成了所有运动员的规律。一次夺冠是推导不出这个普遍结论的，另外这句话有明显的AI味，不是……而是……结构。要改回收窄的写法：“在这次中网过程中，她的状态不是某一刻突然回来的”。

第二处，原稿写“重新学会打眼前的每一分”。这句话的潜台词是，她之前突然不知道怎么打球了。这是判断，不是事实。改成“继续寻找处理关键分的方法”。他在这儿给了整场最像纪律的一句：

第三处，“据人民日报报道，郑钦文说……”。真实情况是人民日报采访了她。前一种写法读起来更像人民日报自己在报道，后一种是采访。在新闻题材里，这两句不是一回事。

最终交付的除了文章，还包括素材、审核记录和待人工复核清单。这样一来，人到底该检查什么就很清楚了，不必从头再读一遍猜究竟有没有问题、在哪里。

案例讲完，他又说回开发者最关心的事：AI把不少工作接过去之后，人还要做什么？

他表达的观点在本场的前二位专家也都提到了，重复性的步骤能交给工具，人就应该把时间用在判断、创造和承担责任上，去做价值更高的事。

按他的说法，人的位置会往流程的两端移动。

动手之前，人来决定做什么、服务谁、什么程度才算合格。在媒体工作中比如采访当事人，还是需要人亲自去完成。

系统跑完以后，还得有人核对结果、维护Agent、调整标准。尤其是长期使用的Agent，不是部署完就能一直放着不管。业务变了，规则也得跟着改，有升级空间、有改进预案。

中间那些可以重复执行的步骤，再交给Agent去做。

观点并不复杂，但在实际操作中，项目一忙起来还是经常把这些责任混在一起。

最后他放慢节奏，把方法收拢成了三步。

谁来用这个Agent，交付什么，什么标准算合适；再看企业现有的工具够不够AI接入的条件。

workflow、prompt、专家团，还是更高阶的搭建应用。这一层选错，后面全是返工。

审核做扎实，判断哪些东西真能交出去。

顺序很重要。先把要求和验收方式谈清楚，再决定用哪种技术组织任务，最后确定交付到哪里为止。否则做得再快，验收时一句“不是我想要的”，前面就白忙了。

这场没有刻意设计金句，陈大栋老师的介绍没有剧烈的起承转合，留下的却是一些很重要的问题：需求清楚吗、验收标准有吗、互相冲突的目标分开了吗、资料能共享吗、人工复核列成清单了吗、交付后客户接得住吗？这是我们每一个FDE工程师在面对客户需求时首先要确定的。

以前听技术分享，大家最爱问这件事“哪些是难点”。陈大栋老师这场让我们意识到问题的另一面，就是做完以后，凭什么说它合格？这也是欲三更老师提到的究竟怎样定义AI项目的交付边界。

活动复盘时，我把两句话写了进去“先定标准，再动手；人退到两头，中间交给AI”。

从最初一句简单的话题，到能查来源、能审查、能由人确认发布的稿件，这场分享把中间的每一步列出来，展现了实现一个稳定、可持续使用的Agent应用的完整路径，是一个不错的学习范例。

WorkBuddy开发者沙龙济南站10月活动圆满落幕

身处AI智能化转型一线，关注我，获取更多实战内容。

陈大栋：凭什么说一场FDE交付是合格的——首场济南WorkBuddy开发者沙龙第三位讲者

联合发起人

人工智能

开发工具

职业发展

10月18日济南首场WorkBuddy开发者沙龙，腾讯云FDE专家陈大栋详解Agent应用实战：通过AI热点内容生产案例，拆解FDE五步交付法，强调先定标准再动手、人退到两端中间交给AI的核心方法论，为开发者提供可落地的AI项目交付指南。

WorkBuddy 

Agent

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

陈大栋：凭什么说一场FDE交付是合格的——首场济南WorkBuddy开发者沙龙第三位讲者

陈大栋：凭什么说一场FDE交付是合格的——首场济南WorkBuddy开发者沙龙第三位讲者

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐