Q1：作为FDE，你应用AI的具体场景是什么？在这个场景下遇到的具体问题长什么样？
我接触这家企业时，第一反应是他们提出的需求一点都不“高大上”。
这是一家做外贸礼品的公司，产品包含起瓶器这类小商品，一年销售额大概有几个亿，但整个团队只有十几个人。公司业务跑了很多年，问题在于数据太多、太散，而且其中相当一部分是图片，比规整的文字和表格更难整理。
电脑里有样图、美工图、参考图、客户交付图，还有各种产品模板，分散在不同电脑、不同文件夹里。
所以老板一开始给我的需求非常具体：能不能以后我直接跟AI说一句话，比如“帮我找一下某个客户之前用过的某个模板”，AI就直接把东西找出来？
除了文件搜索，他还有几个需求。比如，希望AI能够看到阿里国际站的数据，告诉他今天哪些关键词表现怎么样，要不要换词；希望AI帮公司网站持续发文章；还有产品海报，以前需要把产品图交给人处理，他希望以后直接给AI一个产品，就能自动放进已有模板里。
这些事情单独看都不复杂。但真正的问题，其实藏在这些“小需求”下面。
首先是企业的数字资产并没有真正被组织起来。文件虽然都在电脑里，但AI不知道这些文件之间是什么关系，人自己也未必知道。
其次是企业缺少AI可以直接运行的环境。你不能说今天买一个大模型账号，明天企业就AI化了。网络、电脑环境、权限、文件结构、工作流程，这些都会影响AI到底能不能真正进入业务。
第三个问题反而最重要，就是信任。
很多老板已经听过不少AI概念，甚至知道Agent是什么，但他们不知道这些东西跟自己每天遇到的问题到底有什么关系。所以FDE进去以后，我觉得第一件事是找到一个老板真正关心的问题，然后告诉他：这个问题，AI能不能比你原来的方式解决得更好？
这才是起点。
Q2：在你参与之前，这个问题过去是怎么解决的？
这家公司之前已经为数字化和AI相关服务花过钱。
比如，老板花过大约5万元购买相关服务，对方可以基于国际站拿到一些数据，也搭建过外贸网站。这个产品本身有一定价值，但更接近一个标准化产品。企业遇到个性化问题以后，后续没有人继续陪他往下走，也没有人告诉他这个工具怎么和自己公司的工作方式结合。
我后来一直在想，为什么传统的软件和外包方式以前能够运行？
因为过去企业的问题相对明确。我要一个网站，就找人做网站；我要一个ERP，就买ERP；我要一个设计稿，就交给美工。一个问题对应一个工具或者一个人。
这种方式本身没有错。但随着业务越来越复杂，老板开始发现，公司里同时存在几十个、几百个非常碎的小需求。如果每一个需求都找一个外包团队开发，成本根本承担不了。
更关键的是，很多问题甚至没有清晰到可以直接写成需求文档。老板知道“这里不太顺”，但他自己都不知道应该开发什么。
我印象很深的是，这个外贸老板当时碰到一个客户需求。客户给了他一个类似三角尺的产品，上面有一排不规则的刻度。他们找过美工，也做过3D打样，但一直没有搞清楚这排刻度到底是什么，甚至准备人工照着抄，但又抄不准。
图1：现场给老板解决查询产品信息
如果按照以前的工作方式，这可能又要找人、搜索资料、反复确认。
我当时没有给他开发任何软件。我直接把照片丢给AI，让AI判断这是什么产品，如果不知道就继续找相关资料、生产厂商以及附加文件，再分析如果要把这个产品做出来需要哪些信息。
大概10分钟，AI把产品找到了，也搞清楚了那排所谓“不规则的刻度”其实代表的是角度。
老板当时很惊讶。因为按照他原来的思路，这件事情可能要研究一两天。
这个瞬间其实非常重要。他第一次意识到，AI不需要被当成一个需要单独学习的新软件，它本身就是一种完全不同的解决问题方式。
图2：AI十分钟跑出来的结果
Q3：后来你使用AI解决这个问题的整体思路和关键步骤是什么？
真正开始做以后，我反而没有急着开发功能。
第一步，先处理现场环境。
我们决定直接使用最顶尖的大模型，但到了企业现场才发现，他们内部的网络环境经过历年来自己不断的调整，非常复杂：4台路由器、2台光猫、1台交换机，还有一个软路由，整个网络串得很乱，也时常不稳定。所以，为了让Agent具备更稳定和灵活的内网访问权限和工具，我第一天几乎是在当网络工程师。
图3：客户现场的网络环境
这个开头也说明，企业AI落地的第一件事，常常是先把以前留下来的基础设施问题解决掉。公司内网不通、设备环境不一致，再好的Agent也跑不起来。
第二步，重新整理企业文件。
网络解决以后，我做的第二步是整理企业的文件。
这一步比简单地把文件塞进一个所谓“知识库”要复杂得多。我们的做法，是重新组织散落在各台电脑上的资料，建立文件之间的关系，让AI知道哪些文件属于哪个客户、哪个产品、哪个项目，以及不同资料之间是什么关系。
但这里马上遇到了一个现实问题：这些资料不能直接交给我们。
对于老板来说，电脑里的合同、客户资料、产品文件，本身可能就是公司最核心的资产，有些东西甚至不会给公司其他员工看，更不可能全部打包发给一个外部FDE。
图4：老板关于资料杂乱的反馈
图5：老板关于统一数据的需求
第三步，把数据留在企业，把开发能力送进去。
按照传统做法，我们会把数据打包拿回来开发，但到了现场才发现这条路走不通。
于是我们调整了思路，先把一套Harness整理成任务包，把框架、原则、规范和Demo一起部署到客户自己的Codex里，再让客户本地的Codex按照我们的规范，在他的电脑和文件环境里继续完成开发。
我们前期花了几十个小时把框架做好，然后让客户侧的Codex继续跑大约40个小时。跑出来以后，老板开始测试。
测试产生的日志、问题和记录，再由客户侧的AI整理给我们，我们根据这些反馈继续修改规范和任务，再让客户侧的AI完成适配。
这个过程对我来说很重要。因为它改变了过去“驻场工程师必须一直守在客户电脑旁边”的工作方式。数据不需要离开企业，开发和适配却仍然可以继续。
第四步，让交付沉淀成企业自己的能力。
更重要的是，我们不想永远替企业做这些需求。
我的目标是把文件文档化，把资料关系梳理出来，把知识沉淀下来，再建立工作流、Skill和Agent。这些东西逐渐沉淀以后，企业自己就能解决越来越多的问题。
我更希望最后交付的是企业自己解决下一批问题的能力，让企业以后不必每遇到一个问题都来找我。
Q4：相比传统方式，使用AI后的实际效果如何？
如果只从一个软件项目的角度看，现在其实还很难给这个案例下一个“效率提升了多少百分比”的结论，因为项目本身还处在第一阶段，交付也还没有全部完成。
不过，这个项目已经发生了几个非常明显的变化。
第一个变化，是企业开始真正理解AI能做什么。
那个角标尺问题，老板本来以为要研究一两天，我们现场用AI大约10分钟就找到了产品来源和刻度含义。后来他觉得矢量图很难做，我们又直接问AI应该用什么工具，当场把矢量图做了出来。
这个结果真正重要的地方，是老板开始意识到，以前很多他以为必须找专业人员、必须走固定流程的问题，现在可以换一种方式解决。
图6：老板自己开始学会用AI解决日常问题
第二个变化，是信任建立以后，企业开始主动释放更多需求。
一开始，老板只愿意拿一个很小、很具体、试错成本比较低的问题给我们。但在做出一些交付以后，他很快又提出了十几到二十个新的需求。
这个变化比单纯的效率指标更能说明问题。因为它意味着企业已经从“我要不要试一下AI？”，变成了“我公司还有哪些问题可以这样解决？”
图7：第一个需求完成后，老板给出了更全面的需求
第三个变化，是老板对AI的判断开始从“买一个工具”，变成“重新思考公司怎么工作”。
我后来慢慢确信，对这类企业来说，FDE最大的价值未必是帮他少雇一两个人。
真正有价值的是，通过几个具体项目，让老板看到一种新的工作方式，从而改变他后面的战略判断。
尤其是我们接触的很多企业，本身正处于业务快速增长、人力跟不上的阶段。在这个时候，老板如果意识到未来新增业务不一定都要靠增加人力解决，这种认知变化带来的价值，可能远远超过某一个工具本身节省的成本。
Q5：在部署AI过程中，是否遇到了新问题或挑战？你是怎么解决的？
做这个项目的过程中，有三个挑战让我印象最深。
第一个挑战，是现场环境不一致。
我们自己的程序在本地跑得很好，到了客户电脑上就会出现各种报错。原因也很简单，每一台电脑的环境都不一样。
最开始经常发生这样的情况：我发一个安装包，对方说报错；他截图给我，我修改以后再发一个；结果又出现新的错误。这些在标准软件工程里可能是很基础的问题，但到了真实企业现场，它就是会实实在在拖慢整个项目。
所以后来我们把环境当成了第一现场问题，进去之后先花时间把每台电脑的网络、权限、运行环境摸清楚，尽量提前统一，后面来回返工才少了很多。
第二个挑战，是数据和隐私。
AI要真正发挥作用，就必须接触企业最有价值的资料。但恰恰是这些资料，老板最不愿意交出去。
所以我们换了一种方式，把开发能力和任务规范送到他的环境里，让客户自己的AI在本地完成工作，数据始终不离开企业。
第三个挑战，是老板和员工的时间与配合。
图9：老板经常没有时间配合，我们需要找到更高效的方式
老板要处理业务，产品做好以后需要他测试，他又可能几天都不在公司；员工白天要工作，我们又需要调试他们的电脑。
但定制化产品必须有人真正使用，我们才能知道哪里不符合需求。有一段时间，我们甚至一直在催老板：“你有时间用一下，至少给我们留一点记录。”
后来我们自己开发了一个远程通道，让我们的AI可以在后台连接客户电脑上的AI，在不影响员工正常工作的情况下完成一些任务。很多长任务放到晚上跑，双方都节省了大量沟通和等待时间。
回头看，这三个挑战没有一个直接关于模型，但每一个都能决定项目能不能真正跑起来。FDE必须进入业务现场，原因就在这里。
Q6：根据你的经验，我们怎么才能更好地把AI部署到实际业务中？
做完这些项目，我慢慢看清了一件事：FDE不能把自己理解成一个“AI外包”。
如果只是帮客户开发一个小软件，我们一定会陷入和传统外包的比价，而且专业的软件外包公司很可能比我们做得更成熟。
FDE真正应该解决的是另外一个问题，就是怎么让AI这种通用能力进入一家具体的企业，并且最终留下来。
第一，从一个非常小、非常具体的问题开始。
不要一上来跟老板讲多Agent协作、Harness或者企业智能体。老板真正关心的是：“我现在这个问题，你能不能解决？”
而且这个问题最好是他正在为之付出时间、成本，甚至正在影响业务的。把这个问题解决以后，信任自然就会出现。
我们在实践中看到的也是这样：很多老板一开始只愿意拿一个点试，做出结果以后，才会把后面的十几个、几十个问题交出来。
第二，不要只讲AI，要现场解决问题。
现在很多企业老板已经听过太多AI概念了。真正有效的是，把他眼前关心的问题拿出来，让他亲眼看到你的思考过程。概念听过以后很容易忘，但一个真实问题被当场解决，老板会立刻知道AI跟自己有什么关系。
第三，要把交付目标从“做一个工具”变成“沉淀企业能力”。
我希望企业以后不用每遇到一个问题都来找我。做完一次项目，企业带走的应该是一套自己继续解决问题的方法，一个具体的工具反而不是重点。这样交付几次以后，企业遇到新问题时，第一反应会从“找人”变成“自己先试”。
第四，FDE要接受一个事实：大量工作并不“AI”。
你可能要修网络，要处理Windows环境，要梳理文件命名，要解决权限，要等老板开会回来，要催员工测试。这些看起来都不是AI技术，但它们决定了AI到底能不能进入真实业务。
FDE最稀缺的能力，是能不能站在真实业务问题面前，把所有阻碍AI发挥作用的环节一个个拆掉。“懂多少个模型”反而是次要的。
最后，我觉得最理想的FDE，是让客户越来越独立。
有一天企业会发现：以前一个需求出现以后，我要去找软件公司、找外包、找顾问；现在这个需求出现以后，我自己的数据、工作流和AI能力已经在那里了，我可以先自己解决。
到这一步，AI才真正变成了企业自己的能力，而不再只是采购清单上的又一个软件。