FDE 不是只会 vibe coding，真正难的是把工具变成业务结果

最近我一直在想 FDE 这件事。

一个朋友问过一个很关键的问题：如果企业内部员工自己也会 vibe coding，自己也会用 n8n、Zapier、Dify 这类工具搭自动化，那外部 FDE 还有什么价值？

这个问题不好回避。

因为现在 AI coding 的门槛确实在下降。以前一个小工具可能要找程序员写几周，现在一个业务人员如果会描述需求、会看结果，也许一天就能搭出一个能跑的原型。

如果 FDE 的价值只是“我会用 AI 写代码”，那这个角色会很快变便宜。

会做工具会被冲击

低端 FDE 会被冲击。

这点我觉得没必要回避。

如果一个人只是帮企业做这些事：

• 把表格自动发到群里；
• 用 n8n 搭一个消息提醒；
• 用 AI 生成日报；
• 写几个小脚本；
• 教员工怎么问豆包或 ChatGPT。

这些事情以后企业内部员工越来越能做。

尤其是那些本来就爱折腾的员工，他们一旦发现 AI 可以帮自己省时间，就会自己做一些个人提效工具。

所以只靠“工具熟练度”是不够的。

内部员工为什么又很难推动公司级提效

但反过来，企业内部员工能做个人提效，不代表能推动组织级提效。

这里面的阻力很现实。

第一，本职工作压力。
员工自己还有 KPI、项目、交付和领导安排。让他额外研究 AI、做工具、维护流程，本质上是新增工作。

第二，激励不匹配。
他把流程优化了，公司受益，但他不一定涨工资，反而可能多责任。甚至他可能会担心：我把活做少了，会不会影响自己和同事的位置。

第三，权限不够。
很多 AI 落地要碰公司资料、客户数据、历史项目、财务、OA、ERP、文件权限。普通员工不一定能推动。

第四，跨部门难。
一个流程往往涉及多个岗位。某个员工做了工具，别人不一定愿意改习惯。

第五，维护没人管。
内部小工具刚开始能跑，后面表格格式变了、接口失效了、员工换人了，就容易死掉。

所以内部员工更容易做“我自己的提效”，而不是“公司可复用的流程能力”。

这就是外部 FDE 仍然有空间的地方。

真正的价值不是 code

我现在更愿意把 FDE 的价值拆成几层。

第一层是工具能力。
会用 AI coding、会写脚本、会搭自动化。这是基础，但不够。

第二层是业务翻译。
能听懂业务人员说的麻烦，把“我们资料很乱”“报告很烦”“客户跟进靠记忆”拆成输入、处理、输出和验收。

第三层是产品判断。
知道哪个流程值得做，哪个流程不值得做。不是所有能自动化的东西都应该自动化。

第四层是交付闭环。
能把原型、测试、上线、培训、反馈、维护串起来。

第五层是组织落地。
让老板、业务人员、内部技术或外部协作方都知道这个工具怎么用、谁负责、怎么衡量效果。

这几层叠起来，才像一个真正有价值的 FDE。

小工具只是入口

我自己现在能做的，坦白说还处在“小工具、原型、流程试点”这个层级。

但对外表达时，不能只说我会做小工具。

因为老板不关心小工具。

老板关心的是：

• 能不能减少返工；
• 能不能缩短交付周期；
• 能不能让同样的人处理更多项目；
• 能不能把老员工经验沉淀下来；
• 能不能让项目管理更清楚；
• 能不能降低新人上手成本。

小工具只是实现形态，业务结果才是卖点。

所以更准确的说法应该是：

用 AI 和自动化，把企业里重复、耗时、容易错的流程，改造成可复用、可检查、可迭代的工作流。

这比“我会 vibe coding”更接近 FDE 的价值。

我现在的判断

FDE 不会因为企业内部员工会用 AI 就消失。

但 FDE 会分化。

只会搭工具的人，会越来越卷。
能进入业务现场、判断流程价值、设计试点、推动使用、验证效果的人，反而会更重要。

AI 降低了开发门槛，但没有降低业务落地门槛。

这句话我现在很认同。

未来我如果继续往这个方向走，不能只练“怎么更快做工具”。还要练：

• 怎么访谈老板和业务人员；
• 怎么判断高价值场景；
• 怎么设计 PoC；
• 怎么衡量 ROI；
• 怎么处理数据安全和责任边界；
• 怎么把工具交接给企业内部使用。

代码可以越来越便宜。

但把代码变成业务结果，仍然很贵。