一套价值600万的FDE方案，是怎么做出来的

大家好，我是洋哥。

最近，破局圈友@卓峰做了一套价值600万的FDE方案。

先说明，这里的600万不是项目报价，也不是已经审计的利润，而是按照企业现有人员成本测算，这套方案每年可能释放的成本空间。

他独自进入一家头部企业的APP研发场景，3天做出第一版MVP，随后用大约1个月把方案打磨稳定。最终，他把一条原本依赖大量人力的研发流程，拆成了4个Agent和13个Skill。

这套方案让团队所需人力减少约50%。按企业现有人员成本测算，每年可以节省约600万元。

这组数字的背后，他不是给员工发一个更好用的AI工具，而是重新设计了一遍生产线。

不是员工写得慢，而是整条流程都在消耗人。

这家企业有数百到上千名产品和研发人员。

他们遇到的问题，看起来很常见。

移动端APP与PC端的日活比例大约是7比1，但两个端的研发人力配置却接近1比1。用户主要在APP上，研发资源却没有跟着业务重心移动，结果就是移动端需求越积越多。

想靠招人解决，也不容易。

新员工进入团队以后，往往需要接近一个月才能真正上手。不是他不会写代码，而是公司的业务规则、历史代码、环境配置和协作习惯，大多藏在老员工的脑子里。

企业也尝试过AI Coding。

做Demo时效果不错，一进入真实项目就开始失灵。因为模型不知道某个功能对应哪段历史代码，不理解公司的工程规范，更不知道哪些看似合理的修改会影响现有业务。

所以，问题根本不是少了一个更会写代码的工具。

问题是从配置环境、理解需求、编写代码，到测试、发布，整条链路都在反复消耗人的注意力。

如果只在其中一个环节接入AI，效率提升很快就会被其他卡点吃掉。

这也是很多企业采购了一堆AI工具，三个月后组织和流程几乎没有变化的原因。

企业AI化不是把原来的工作做快一点，而是重新判断哪些工作应该由人做，哪些工作可以交给AI。

3天做出MVP，后面1个月都在解决“小问题”。

卓峰先把整个研发流程拆成4个阶段：环境配置、需求开发、自动化测试和部署发布。

然后，每个阶段做一个Agent，再把员工原来依靠经验完成的具体动作，沉淀成13个Skill。

第一个做的，是环境配置Agent。

它要自动安装项目依赖，统一申请十多个代码仓库的权限，完成项目初始化，还要匹配macOS、Xcode和iOS模拟器的兼容版本。

在技术人员看来，这些都不是最难的问题。

但在真实使用中，第一个让流程卡住的，恰恰是Xcode。

卓峰最初没有专门设计Xcode安装Skill。他以为员工从应用商店下载就可以了，结果到了现场才发现，不同员工的电脑系统版本不同，有些Xcode版本根本不兼容。

一个看起来不值得讨论的小问题，就能让后面所有自动化全部失效。

第一版MVP只用了3天，真正让系统稳定下来却用了大约1个月。后面的时间，大部分不是在写新代码，而是在观察员工怎么用、在哪里停下、为什么报错，以及用了三次以后为什么不愿意再用。

这让我想起很多AI项目的共同问题。

方案是在会议室里设计的，验收是在演示环境里完成的，唯独没有人坐到员工旁边，看他如何完成一天的工作。

真正的业务瓶颈，往往不在方案PPT里，而在一次权限申请、一个版本冲突和一个没人说明白的操作习惯里。

FDE的价值，不只是会搭系统，更是愿意走进现场，把专家看不见的小问题一个个捡起来。

如果你也想进入FDE、AI企培企服这些方向，但还不知道如何从真实业务问题入手，破局俱乐部准备了一套3天体验卡。

3天9小时直播，专业导师会带你拆解不同AI项目的业务逻辑、交付方法和入场路径。扫码即可开始学习。

4个Agent，不是设计出来的，是从员工流程里拆出来的。

环境配置跑通以后，卓峰继续做了开发Agent、自动化测试Agent和部署Agent。

开发Agent要解决的，不只是生成代码。

它先用产品和设计人员熟悉的表达方式收集需求，再把业务功能映射到具体代码、文件和位置。同时，它还要遵守企业现有的工程规范，避免生成一份能运行，却无法继续维护的代码。

测试Agent会根据需求变更生成测试用例，模拟用户完成端到端测试。测试失败后，问题会重新回到开发Agent，修复以后再次测试。

部署Agent则负责打包、构建、发布前检查、版本管理和回滚。

四个Agent连在一起，才形成一条可以持续运行的研发链路。

这里有个特别关键的区别。

很多人把Skill理解成一段提示词，或者一个可以调用的工具。

但在企业里，真正有价值的Skill，本质上是把员工的标准作业流程，变成AI可以稳定执行的能力。

一个Skill解决一个明确动作，多个Skill组成一个岗位角色，多个角色再协同完成一段业务流程。

这条路径不是先研究最新技术，再想办法塞进企业。顺序正好相反。

先看员工每天在做什么，找出哪些步骤高频、重复、耗时、容易验证，再决定AI应该进入哪里。

技术只是最后一环。

最聪明的方案，最后输给了两条命令。

这个项目里，我最喜欢的细节，是连接iOS模拟器的方案选择。

团队一共评估了三种方式。

第一种，开发一个VS Code插件，自动化程度很高，但在不同环境里容易出现兼容问题。

第二种，让Skill全自动完成连接，但企业算力高峰期速度慢，也可能失败。

第三种，保留两条人工执行的命令，用一份极简SOP引导员工操作。

最后，他们选择了第三种。

它不够炫，甚至没有做到全自动，但员工只用30到60秒就能稳定完成，维护成本也最低。

很多人做AI方案，会不自觉地把自动化率当成成绩单。

只要还有一步需要人来点，就觉得方案不够先进。为了消灭最后10%的人工，不断增加系统复杂度、故障率和维护成本。

可企业真正关心的，从来不是自动化率看起来有多漂亮。

它关心的是，这一步能不能更快、更稳、更便宜，出了问题能不能及时恢复。

如果两条命令比一个复杂Agent更可靠，两条命令就是更好的方案。

如果80%到90%的自动化加上一套人工兜底，已经能获得最高投入产出比，就没有必要为了100%自动化继续堆成本。

AI化是一道ROI题，不是一场技术表演。

一年600万，不等于简单裁掉一半人。

这组数据也很容易被误读。

同样的业务需求下，人力需求减少约50%，不等于企业一定要裁掉一半研发人员。

更准确的理解是，原来需要多人反复完成的配置、检索、测试和发布工作，被沉淀进了系统。被释放出来的人，可以去处理更多需求，补足移动端产能，或者投入更需要判断力和创造力的工作。

而且，600万元是按照企业现有人员成本做出的年度测算，不是一张已经审计完成的财务账单。

但它仍然说明了一件很重要的事。

当AI从个人工具进入完整流程，它带来的变化，不再只是某个员工每天节省半小时，而是整个团队如何配置人力、如何积累经验、如何交付结果。

以前，新员工要用一个月向老员工学习隐性知识。现在，这些环境配置、业务映射、工程规则和验收标准，可以逐渐沉淀为可复用的Skill。

以前，一个需求要在多个角色之间来回传递。现在，Agent可以接住其中标准化程度最高的部分，让人把注意力放在需求判断、异常处理和最终验收上。

AI真正改变企业的时刻，不是员工第一次打开聊天框，而是岗位边界和业务流程开始重新划分。

普通人怎么找到自己的第一个企业AI场景？

看完这个案例，很多人可能会觉得，头部企业的研发流程离自己太远。

其实，企业大小和行业不同，找场景的方法是一样的。

第一步，找一条正在浪费人力的真实流程。

优先选择高频、重复、耗时，而且结果容易验证的工作。比如报价、客服、资料审核、销售跟进、周报整理和项目交付。

不要先问AI能做什么，先问员工上一次处理这件事花了多久，卡在哪里，出错会造成什么损失。

第二步，把现有SOP画出来。

写清楚输入是什么，中间经过哪些人和系统，最后交付什么结果。哪些步骤依赖固定规则，哪些步骤必须依靠人的判断，也要分开标出来。

第三步，把稳定动作沉淀成Skill，再组合成Agent。

不要一开始就做一个无所不能的大平台。先让AI稳定接住一个具体动作，再把多个动作连成一个角色，最后进入一段完整流程。

第四步，尽快交给真实用户，小范围上线。

观察员工在哪里停下，记录错误和异常，保留人工兜底，再用时间、成本、质量和使用率持续验收。

一个能在真实环境里反复使用的小系统，远比一个只在演示时惊艳的大Demo更值钱。

未来企业最缺的，不会是会写提示词的人。

模型会越来越强，代码会越来越容易生成，工具也会越来越便宜。

真正稀缺的，是能看懂业务、找到瓶颈、重做流程，并且把结果算清楚的人。

卓峰这个案例最值得复制的，也不是3天做出一个MVP。

而是先进入现场，把一条真实生产线拆开，再用4个Agent和13个Skill，一步步把人的经验变成企业可以持续运行的AI能力。

别急着给每个员工配一个更聪明的锤子。

先看看，整条生产线是不是应该重新设计。

如果你也想进入FDE、AI企培企服这些方向，但还不知道如何从真实业务问题入手，破局俱乐部准备了一套3天体验卡。

3天9小时直播，专业导师会带你拆解不同AI项目的业务逻辑、交付方法和入场路径。扫码即可开始学习。