FDE 为什么不该交付workbuddy？企业 AI 落地交付请 FDE 省钱@张北其人

其实一直在谈“壁垒（交出去了是不是就不需要我了）”、“信任（我花这么多钱给了个市场上的产品/给就给了个文档包？”、“不稳定性（业务不会用怎么办，用错了怎么办）”
——这都是作为一个FDE的销售端考虑的事情
（当然，稳定性比较特殊，因为拥抱不稳定性，重视业务敏捷性，可能会成为企业内很多场景重要的共识）
但其实抛去这些，我们从产品端来看，不得不承认一点，这些门槛正在降低/消失，所谓需要请FDE的场景，也许会被几个校招的业务，或者拥抱新事物的新员工，来击碎——这种击碎不是整体性的，而是蚂蚁蚕食大象，今天这个小功能被瓦解，明天那个东西不需要了。
当各种办公IM、企业软件、workbuddy里面出各种功能，业务点了一个东西，发现居然真的能解决我的一个问题，转变思想的时候——这家公司的FDE的需求就是瓦解的时候。

在我看来，交付workbuddy和codex也不是不行。但需要提前为该公司的业务场景和岗位需求做系统打通以及业务流程到SKILL或者工作流的封装。虽然这样会有功能冗余和潜在的一些算力资源的浪费，但好处是没有什么后期维护成本，以及因为后续FDE团队产生变动，而企业有新需求迭代而带来的错位问题，可以降低成本和风险。仅仅是帮忙部署和教企业成员怎么用这些通用agent已经能给企业提效一大截了，而且这种成本-收益的比例，也是绝大多数中小企业能承担的。现在从企业组织根源上的AI化，国内还早的很呢。这就跟信息化时代，通用Saas和定制系统的差别

比如你举一个具体的场景

前后逻辑有点矛盾了，对于一个产品，在成本固定的情况下，稳定性和灵活性是互斥的。文章前面说要少用通用agent，少用模型，保持稳定；后面又说“他交接的Agenty一定会随着数据自我进化”，“自进化”的灵活性是远在“通用”之上的。。。这样的产品很难做到稳定

对于FDE来说，交付的东西要么是灵活但没那么稳定；要么是定制化的产品，稳定但欠缺灵活性。如果你要求最终成功既稳定又灵活，方便扩展，还能自进化，这样的产品不是一个FDE 能够搞定的，还是需要按照完整的产品开发项目流程来进行，需要完整的设计开发测试流程进行保障

积累的是数据，他的逻辑不变，进化的是随者数据增多他的参考纬度和内容。你就是理解成prompt越来越详细。这和人做一个岗位越久经验越丰富一个道理。但这不影响一个节点的一个垂直agent还是只做一件事，只是他和llm交流的内容更详细了

时间，成本，才是决定产品形态的核心因素。甲方给100万12个月，可以给它定制Agent，梳理独有工作流；甲方就给10万1个月，使用现成的通用Agent+Skill才是最稳定的。

我们筛选客户群的标准是1个亿以上营业额，100万以上预算

回复 红豆泥：这企业很稀奇吗

是交付workbuddy/codex，抑或是“只”交付workbuddy/codex？
你说的是agent？还是harness？你可以说这两个东西重，但有没有用，跟他们重不重其实没关系。
它通用，跟是否能应付垂直的问题也没有关系。
可能你做个电商答问agent，主力是在做记忆图谱。做答问库，均衡速度，成本和精度。
也可能办公流，要按业务去设置围栏，知识库抓取，授权和自己更新中台的路由规则。
但这些东西真的完全是harness之内的吗？在基层办公端口，你本身就是需要agent去协助过滤规整非规范的语意，中间层再做信息清洗，标准化的。
你可以说workbuddy重，也可以说它真的慢。但不管在对于国内各种现成的mcp对接，聊天对话中的可视化输出，工具便捷性方面，我用过各种的的东西workbuddy绝对是目前开箱最容易上手也最舒服的。
项目落地，要解决的不光是准不准，对不对。更多时候是怎么样让素质不一，治理不完善的基层愿意有积极性去用。要垂直的话，回去做sap就好了。包定制的。
不是哪个工具行还是不行，而是究竟你在吐槽的是harness？是交付逻辑？还是什么东西？？？？
展开

将我的内容放入codex他会告诉你

我们核心区别、你还是想要基层去用，我是要精简基层甚至清理掉一些层面的人员。我的目的是让剩下的人只做一些必要的审核或者协助。如果还是让他用，达不到Agent化的目的。还在用，就不是Agent化。

回复 张北其人：那既然谈业务，就按业务来谈。agent化是因为需要agent改造这个环节，不是为了替代。
重新改个业务流程很难吗？可能会也可能不会，这个取决于客户和业态需求。但有一件事，是很难替代的，那就是前线的信息采集端口。你要让agent治理，就首先要有数据，不是所有数据都能够被直接采集，也不是能靠中间衔接的管理层去验证的，否则大家光是去每天验证这个原始信息准不准就已经不用干其他事了。
举个例子，给一个连锁便利店企业做agent。agent可以统合信息，整合采购，统一调货，完成所有偏前台的运维决策。但agent不知道究竟你这个牌子卖不好，是因为对面开了个大型超市，刚好同样sku的产品在打7折。
可以去取代很大一部分区域甚至市级的中间层，因为他们过往很大一部分工作就是做这些非标信息的统合，升维汇总然后向上去给意见方向，再按决策方向去向终端下达指令的。但不是替代基层，没基层，哪来的数据源？不方便基层，怎么让他们配合去尽量让数据干净？
展开

人总是井底之蛙。懂技术是可以说人做的垂直agent被codex完爆，但如果说fde直接交付codex，那就是完全不懂商务，不懂人性。fde交付codex给b端客户，就等着b端客户业务部门反弹吧。b端老板会说你交付个codex那我为什么要采购，你在需求分析侧的贡献瞬间清零。业务部门会因为codex的强大通用能力直接导致agent蔓延，连大专都没毕业的客服可不一定用得来通用agent带来的信息过载。fde的核心工作就是剪枝，本质上还是开发工程师和产品经理之间的认知偏差，拥有的还是开发的通用式思维而非产品经理的产品式思维。做出来的东西是要给b端用户用的，这说明“最厉害”就不是这个产品的需求，“给我的部门用最贴合”才是。
作者赞过

对嘛，别光表达观点，说点理解

回复 张北其人：秉承一个思想，用AI交付项目和交付一个AI项目是两个维度
不是说你能用AI能交付一个代码级项目就能交付好一个AI项目

回复 九桶水大师兄：这不就是fde的主流方案？你不把codex当底座直接交付codex？

回复 Leon：那你上面写的几百字有表达这个意思？

我觉得还是可控吧，如果只是Codex的话，企业内部应该是请咨询专家分析业务来做建设；如果是现在大家对FDE的理解，应该是定开。其实还是FDE这个岗位的定位和理解问题，都不算是技术的事情。

你们不觉得agent很啰嗦吗，让agent把核心数据处理下或者整理下，再展示出来就可以了

数据主权、成本平衡点、法律合规、业务分离，通用模型+skill交付都是达摩克里斯之剑

小白提问，那为什么不让大模型生成一个能【精确处理】的代码呢？

单从技术角度来说，个人或小团队开发的agent只能算demo，能力、扩展性、稳定性都差很多，codex、WorkBuddy这些成熟的harness产品好用多了

很赞同作者的那个观点，确定的东西就直接走代码，不确定的模糊的东西交给模型。

那干脆只做聊天ai就行了，现在最终问题还是在llm的底层问题，再过5年吧。

是啊，你最厉害，codex的开发者都比不上你，腾讯系的workbuddy开发者都比不上你，问题核心是：信任背书；你拿什么给你个人开发的的code背书

医生给你看完病忌口，你想让家里人给你做点什么养身体的饭，这叫做定制，你家人给你点开麦当劳，说你有啥忌口不点忌口的就行了。你说的不就是这样的吗？codex workbuddy也有很多种存在模式，你是非得把这俩安装包给客户说干完活了？再怎么也得封装一下调对应cli，有个标准对接的网页或者什么的，你这是干活吗

于是就变成了：借助现在 AI 写脚本的效率，帮客户把原本的一些工作流程自动化，最终交付产物甚至可能是个一次 llm 都不会调用的纯脚本流程。本质上这个活就变成了帮客户完成一些 dirty work 的外包。

客户越是不能接受错误，产物就越倾向于我说的

企业Agent本身就是伪命题，99%的公司用不到，毕竟99%的公司自己公司的业务情况都理不清楚，还想着靠FDE理，太扯淡了。而能理清楚的公司，本身它的能力（系统、员工、流程等）也不需要新的Agent介入，或者说是它们本身就有很多成熟的Agent在业务上跑了。

所以要做的是筛选企业，别的地方我不太清楚，但是我们在深圳对企业的标准是亿以上营业额，100万以上的预算。目前看，需求不少。

作者是想说通用agent对于垂直业务太重，有很多不必要组件和过度harness吧。但是在大多数现场开发者的能力远差于这些专业团队的情况下，这种包袱代价显然是可以被考虑接受的，不能过于理想化

如果你真的有一天邀请到人送你去机场，最后他开汽车送你去的，而不是人力黄包车，放心，你被骗了！

最终交付通用agent加上skills，这是趋势！不同意作者观点。

这种趋势的依据是什么

回复 张北其人：成本、效率、以及AI未来持续迭代能力质变提升。

无知真可怕

用skills你换个基模可能会炸，特别是复杂skills，不亚于写操作系统，你指望AI在这种情况下不犯错，痴心妄想。

我也想知道，我们也尝试用skill交付，但是skill一给对方，对方不就知道你的全部了吗；第二个方面，随着模型的更新，skill能做的事情会有波动，可能最终就偏离了原始目标

不是，代码可以稳定运行，消耗极低，大模型能吗

如果都不是部署公司定制产品、回流行业经验沉淀、升级通用产品这种流程，为什么要叫FDE?
就应该叫项目SI架构开发实施团队啊

所以我不知道地下在杠什么

上海和北京的FDE岗位和需求这么火热吗，我在南京都很少听到

我在深圳

哈哈哈，行业乱象。折腾一阵子，然后又让软件大厂疯狂招人！国内企业强在应用，而这背后恰恰是有无法估量的定制化内容，你以为搞一个FDE入住公司，提高了所谓业务流程，固化经验，可以裁员了，殊不知你所谓固化的内容恰恰是传统ERP类软件实现的固定流程，真正业务端的内容还是要靠专家和前端销售以及交付体系去撑起来。
这里插个眼，半年后咱再验证！

FDE交付的是一个产品，不一定是一个AI Agent,不是说给你一个自己定制的Agent,就一定是一个牛逼的FDE。

自己做个ui ，跟 workbuddy codex做个ui 有毛区别啊， 你所有代码不都可以写mcp skill和 服务吗，不要执着在表层啊，核心是你交付的东西吧。

高论

认可核心观点。但是现在的环境属于混沌期，估计还得个半年后才有比较清晰的真实落地产物、验收标准

支持你的核心观点，要将业务真实AI化的核心还是在让不同的工具专注擅长的领域。
作者赞过

我觉得要是把企业级 AI 做成让 Agent 自由发挥，把工作流程做成 Skill，那就是蠢且笨了
作者赞过

我觉得现在一个概念的热度撑不过八个月就死了。

其实就是选择少，市面上找不到好用的B端harness

因为不存在通用的，如果存在那就真是AGI了

不是选择多少问题，B 端需求就是要面向特定企业自身需求或者特定业务范围约束下的 AI 服务。单纯用通用型 agent+知识库/skills 等是没法非常针对性满足 B 端客户需求，而且通用型 agent 强依赖正确有效提出准确的问题，这对于 B 端用户大多数情况下是一种极大的负担，而且并不见得高效（反而很多时候是低效场景）。
作者赞过

回复 张北其人：所以不要想做过于通用的东西

回复 数形演绎：是的，不然也不会产生FDE了

极其认同

当你说“交付Codex、workbuddy”，我就可以断定你压根不懂AI，使用工具和交付形式先搞明白再去谈FDE吧

你好，我想请教一下怎么去找您说的“使用工具和交付形式”的信息呢，我正好找一些市面上在AI板块做的比较好的样例，参考学习一下

回复 序：您是真心交流还是嘲讽我哇，Anyway，这个问题其实不复杂，您直接问AI就行

回复 须臾：真心交流，我想知道fde做的比较好的交付形式是怎样的，因为我本身也是做fde的

FDE这个岗位就是扯淡

你比现在顶尖的模型公司先进入RSI吗，什么叫自我进化能力？

不以agent为中心的转型都是假转型

其实不管怎么样，客户满意，你也挣到钱就可以了，什么实现或者套壳什么的没必要在意，企业要的是业务精准梳理，安全，稳定，以及后续的服务。合作共赢

高中低端开发者都可以用，越高端越用定制化的。通用的强大首先在于对命令的分析和理解，但这也是弊端，让ai碰数据简直就是找屎，哪怕配十个审核agent。简单划分使用者分三类，一类只会说大白话我称之为小白，二类会写伪代码脑子里有流程图逻辑性强我称之为产品经理，三类就是正经的开发者和ai结对编程，可以省事可以学习也不至于自己废掉

现在的编程 说白了就是用普通话。简单程序企业内部自己搞因为熟悉业务比外聘的IT快多了，而且自己边用边迭代更方便。请啥FDE，都是浪费钱。自编的程序请IT帮忙优化下代码 外加实在搞不定的程序花钱请人就行了

交付一堆skill也不代表这堆skill是通用的啊，和后面说的任务尽量少交给大模型又不矛盾，看不懂这逻辑

他是说外面的壳太重了，比如你使用WorkBuddy+Skill，就受限于WorkBuddy的使用场景；而且WrokBuddy作为通用Agent，里面的Harness包含的内容过多。
作者应该是倾向于使用自己的定制Agent做工作流。但就是要花费更多时间。核心问题还是预算，你给我100万，我可以给你定制Agent，但只给10万，就划不来了。

人能做的，它都可以很快做到，在于用它的人。

本质上是实施驻场，换个名头。

看情况吧，有的一些非标需求不太好做的，我们拿workbuddycodex糊弄糊弄，让他们自己来也挺好
比如他们想写合同、做PPT这种非标需求，作为企业内训的一部分还是蛮好的

这该分好的坏的吗？ 这就不是FDE，蹭热度骗钱的。你也不懂FDE

站在甲方立场，就该强制乙方交付技能包+豆包、workbuddy或DSH，才能最少的被乙方套路。站在乙方立场，当然是乙方的智能体能更好的套路住甲方。
已无更多数据
暂无评论