ARTICLE · 1146485

从FDE到AIOPC:AI正在改变的不只是开发方式,还有组织方式

发布时间：2026-10-09 17:55:16 最近访问：2026-10-09 17:55:17

当模型能力越来越普及，真正稀缺的可能是那些能站在业务现场、把问题做成结果的人

我是技术出身。

所以最开始理解AI，注意力很自然地放在“生产效率”上。

Coding Agent能不能把开发周期缩短一半？

一个工程师能不能同时处理产品、前端、后端、测试？

过去需要一个小团队才能完成的事情，现在一个人能不能先做出MVP？

这些变化都已经在发生。

但真正开始跑企业、做AI项目以后，我越来越觉得：

AI落地真正难的地方，往往不是“把代码写出来”

一家企业说：

“我们想用AI提高销售效率。”

这句话距离一个真正能够上线、创造价值的AI系统，中间还隔着很远。

到底是客户资料检索慢？
方案写得慢？
报价慢？
销售跟进缺少提醒？
还是大量时间浪费在重复整理信息上？
数据在哪里？
哪些流程允许AI进入？
用知识库、Agent，还是一个普通工作流就够了？
最后又用什么指标判断项目真的有效？

这些问题没有想明白，模型再强，也很容易做出一个漂亮Demo。

这也是为什么最近我越来越关注一个角色：

FDE（Forward Deployed Engineer，前沿部署工程师）。

以及它和AIOPC之间可能产生的关系。

AI时代，最缺的可能不是“会调用模型的人”

FROM TOOLS TO BUSINESS

现在AI工具已经足够多。

模型、Agent平台、知识库、工作流、Vibe Coding……

很多原来有技术门槛的能力，都在迅速产品化。

这意味着单纯“会使用AI工具”本身，很可能越来越难形成长期壁垒。

真正困难的事情开始往前移动：

你能不能理解业务？
能不能判断一个问题值不值得用AI解决？
能不能把模糊需求拆成一个可以实施的技术问题？
能不能把模型接进真实系统，最后对结果负责？

这恰恰是FDE这个角色让我感兴趣的地方。

FDE不是传统意义上坐在后方等需求文档的工程师。

它更接近业务现场。

既要听得懂客户说什么，又要知道技术到底能做到什么。

企业说的是：

“销售效率太低。”

技术系统需要的却是：

数据源、业务流程、权限、知识库、模型、接口、评估指标。

中间必须有人完成一次“翻译”。

把业务问题翻译成AI可以解决的问题，再把AI能力翻译成企业真正能用的产品。

这可能会成为未来AI落地最重要的能力之一。

“AI行业翻译官”，其实和FDE在解决类似的问题

最近我去温州参加2026人工智能OPC创业生态共建大会。

大会发布的很多政策当然值得关注，但从技术人的视角，我反而对一个词特别感兴趣：

AI行业翻译官。

温州这次首批释放了246个应用场景，并提出通过AI行业翻译官，把企业需求进一步转化成标准化“微订单”。

我觉得这件事很有技术意味。

需要说明的是，“AI行业翻译官”并不等同于FDE，两者的职责定义也不完全一样。

但它们实际上在解决一类非常接近的问题：

怎样把行业语言，翻译成可以被技术实现和交付的问题。

一家制造企业说：

“我们想做AI质检。”

这还不是一个项目。

继续往下才是：

检测什么？
现有数据够不够？
准确率要求是多少？
漏检和误检哪个代价更大？
部署在云端还是本地？
怎么接现有产线？
谁来验收？

这些问题梳理清楚之后，一个“AI想法”才开始变成一个工程任务。

所以相比再增加多少个AI产品，我反而越来越关注：

有没有足够多的人能站在行业与技术之间，把需求真正拆清楚。

从246个场景到“微订单”，本质上是一次任务拆解

BREAK DOWN COMPLEXITY

这一点也很像软件工程。

一个复杂系统不会直接丢给某个开发者一句：

“你把整个系统做完。”

正常的工程过程是先理解业务，再划分边界、拆模块、定接口、明确验收。

企业AI需求也是如此。

一个大型企业说“我们要做AI营销”，背后可能包含：

内容生成
客户洞察
销售辅助
知识库
数据分析
智能客服……

一个只有两三个人的AI团队，很难一次性吃下整个项目。

但如果先把问题拆开，形成一组边界清晰、结果可验收的任务，小团队就有机会参与。

所以我觉得“微订单”真正有意思的地方，并不是把订单金额做小。

而是：

把复杂业务拆成更适合专业节点交付的任务颗粒度。

这和微服务的逻辑有一点相似。

不是让一个服务包办所有事情，而是把边界拆清楚，让每个节点做好自己最擅长的部分。

这也是我理解AIOPC的一个重要变化。

AIOPC不是“一个人什么都会”，而是组织能力开始解耦

现在提到One Person Company，很容易被理解为：

一个人 + AI = 把整家公司所有事情做完。

我越来越不认同这种理解。

一个做了十几年制造业的人，最值钱的是行业Know-how。

一个设计师最重要的仍然是审美。

一个销售真正难复制的是对客户的理解。

工程师的价值，也不仅是代码生成速度，而是判断什么应该做，以及怎样才能稳定交付。

AI应该放大这些长板，而不是逼每个人重新成为一个“全栈人类”。

所以我现在更愿意用一个简单的结构理解AIOPC：

核心能力 × AI杠杆 × 协作网络

一个人的核心组织可以越来越轻。

但它背后能够调用的能力应该越来越丰富。

过去公司获得能力的方法是：

招人，把能力固定在组织内部。

未来可能越来越多的是：

需要什么能力，就在合适的时候调用什么能力。

这和软件从大型单体系统逐渐走向API、SaaS、云服务很像。

应用可以越来越轻。

但背后的基础设施反而越来越强。

从这个角度看：

AI正在让一部分组织能力，从“固定拥有”走向“按需调用”。

公司可能变小。

组织没有消失，只是换了一种存在方式。

71家能力团队和“企鹅搭子”，让我想到服务发现与任务路由

温州这次的能力清单首批汇集了71家本土AI企业和技术团队。

如果只是把71家公司名字做成一个Excel，价值其实有限。

真正值得研究的是：

以后能不能知道每一个节点真正擅长什么。

谁做过制造业？
谁擅长智能体？
谁真正交付过企业知识库？
谁有成熟的AI视频生产能力？
谁在跨境、电商或者文旅里积累更深？

技术上，这很像一个分布式系统里的服务发现。

节点很多并不重要。

重要的是：

系统能不能知道谁提供什么服务，在需要的时候准确调用。

再往前一步，就是这次落地温州的腾讯SSV赋能OPC订单平台“企鹅搭子”。

它开始触碰另外一个问题：

需求怎样找到合适的能力。

如果把它放进整条链路，会出现一个很有意思的结构：

企业场景 → 行业翻译 → 任务拆解 → 能力发现 → 项目匹配 → 交付

这已经不只是“做一个OPC社区”。

它开始有一点像在搭建一套面向轻型创业者的协作基础设施。

当然，这套机制还处在很早期。

但方向值得技术人观察。

OPC可能成为AI进入产业的“轻量交付节点”

今天AI产业有一个很明显的问题。

上面是越来越强的大模型、大厂平台和基础设施。

下面是数量巨大的真实企业。

中间还有非常长的一段距离。

一个通用大模型并不知道一家陶瓷企业具体怎么卖货。

也不知道一家制造企业内部的采购、生产、销售流程。

更不知道一家地方文旅公司的内容体系和经营目标。

越进入真实产业，问题越碎，行业上下文越重。

这也是为什么我越来越觉得：

大平台和小型OPC之间，未来可能不是竞争关系，而是一种分工关系。

大型平台负责：模型、算力、工具和通用能力。

OPC或者小型FDE团队负责：进入现场、理解业务、完成集成和持续交付。

也就是说：

大平台提供底层能力，小型专业节点完成最后一公里。

如果这个结构成立，中国大量产业带、制造企业、小微企业，可能会出现非常多“小型AI交付节点”。

它们未必需要很多人。

但必须真正懂一个行业，并且能对结果负责。

未来很多企业AI型OPC，可能越来越像“小型FDE团队”

我觉得这可能是技术创业者特别值得关注的一条路径。

不是所有OPC都是FDE。

但如果一个OPC做的是企业AI应用，它很可能越来越需要FDE式能力。

假设一家企业找到你，说：

“帮我们做一个AI销售助手。”

最差的做法，是第二天直接给客户演示一个Agent。

更成熟的路径可能是：

先进入销售流程
看销售每天在做什么
找到真正耗时、重复、可以量化的问题
确认数据和系统边界
判断到底需要Agent、RAG、普通工作流，还是根本不需要大模型
做一个小范围原型
定义指标
接入业务
再根据真实使用不断迭代

这时候，技术人员的工作已经不只是：

“完成一个需求。”

而是在承担：

从问题定义到结果交付的完整闭环。

这就是FDE思维真正有价值的地方。

这对技术人的要求，其实变高了

AI Coding让写代码越来越快。

表面上看，工程师的门槛好像下降了。

但如果代码本身越来越容易生产，那么技术人的价值就会继续向上移动。

过去我们可能更关注：

框架熟不熟？
API会不会写？
数据库怎么设计？

这些依然重要。

但未来可能越来越需要另外一组能力：

能不能理解业务？
能不能和客户沟通？
能不能定义问题？
能不能做技术取舍？
能不能把AI系统接入现有流程？
能不能定义效果并持续优化？

换句话说：

技术人正在从“对代码负责”，逐渐增加到“对业务结果负责”。

这并不意味着每个程序员都必须变成销售或者产品经理。

而是工程师需要更理解：

自己写的系统，最终为什么存在。

我觉得这也是AI时代FDE重新受到关注的重要原因。

从FDE再看AIOPC，真正稀缺的是“闭环能力”

过去我们评价一个技术团队，很容易看：

有多少开发者
技术栈是什么
做过多少系统

但AIOPC时代，一个很小的团队可能也能够拥有很强的生产能力。

那么新的竞争力是什么？

我越来越倾向于看三个东西：

第一，是否真正理解一个垂直场景。

不是“什么AI都能做”，而是知道某一类客户的问题究竟在哪里。

第二，能否把AI能力工程化。

不是Demo，而是数据、权限、系统集成、评估、上线和维护。

第三，能否完成商业闭环。

客户愿不愿意付钱？
项目能不能交付？
效果能不能验证？
能不能继续复用？

这三个东西加起来，其实就是：

懂业务 + 懂AI + 能交付

也许这会成为未来一批技术型AIOPC最核心的能力模型。

从“一人公司”到“一座城市”，逻辑其实是一样的

这次我在温州分享的最后一页写了一句话：

AI+OPC，是给每个人、每座城新的机会。

从FDE和工程落地的视角回头看，我对这句话又多了一层理解。

所谓“给每个人机会”，不是每个人都要创业。

而是AI正在让个人第一次能够调用过去只有大型组织才能拥有的一部分生产能力。

所谓“给每座城机会”，也不是所有城市都去复制杭州、深圳。

而是每座城市都可以从自己原有的产业出发，找到那些能够被AI重新放大的环节。

温州有自己的制造、跨境和民营经济。

江西也有自己的陶瓷、家具、制造、软件、电子信息等产业场景。

AI不会替城市凭空创造产业。

但它可能把原本沉淀在地方产业里的知识和经验，重新产品化、软件化和服务化。

从这个角度看，真正重要的仍然不是AI本身。

而是：

谁能把AI翻译进真实产业。

总结

如果只看模型能力，我们很容易认为：

AI越强，需要的人越少。

但真正走进企业以后，我反而越来越觉得：

AI能力越强，越需要有人把它和真实业务接起来。

模型不会自动理解一家企业。

Agent不会自动定义正确的问题。

一个Demo，也不会自己变成可持续的商业系统。

中间仍然需要那些愿意走到业务现场的人：

理解问题
拆解问题
选择技术
完成系统
验证结果

这也是为什么我越来越关注FDE，也越来越重新理解AIOPC。

未来真正有竞争力的技术型OPC，也许不是一个“什么都会一点”的超级个体。

而是一支核心团队很小，却具备FDE式闭环能力，又能通过AI和外部专业网络快速调用资源的轻型组织。

公司可以很小。

但问题理解、工程能力和交付责任不能变轻。

对于技术人来说，这可能也是AI时代一个值得认真研究的新机会。

关于作者

莫西AI（MyAction2023），江西AI圈发起人、OPCxCity江西主理人，技术研发背景，长期关注企业AI应用、AIOPC、FDE以及AI与地方产业的真实落地。

这次在温州，我也只是看到了其中一个正在发生的样本。

如果你也在做企业AI、FDE、Agent或者技术型AIOPC，欢迎在评论区交流。尤其想听听技术人的看法：

当写代码越来越快之后，你认为工程师下一阶段最重要的能力是什么？

相关学习资料