At the 1024 Model Force Workshop · AI Community Day Main Forum, Lu Yufeng, co-founder and COO of DeepSpace Order, gave a keynote talk titled "FDE: The Core Competitiveness of AI Implementation".
It's worth noting that DeepSpace Order is an AI company co-founded by Lu Yufeng and former DingTalk CEO Ye Jun, focused on the cross-border e-commerce AI business agent Agent Nine.
First, he shared a lesson from an embroidery project: the AI-generated pattern looked good, but when a master craftsman examined it, he found the machine would need to trim and tie threads more than 700 times. The gap between "generated result" and "actually usable" is exactly what the FDE needs to solve on-site.
In this project, the team initially tried to have the AI imitate the master craftsman operating the software, but found that complex craft judgments could not be achieved by copying operations. They then shifted to using annotated data and post-training to directly generate stitch files based on the original image, fabric, and stitch type. According to Lu Yufeng, some medium- and low-difficulty patterns can now be produced in minutes, but specific craft issues still require the team to be stationed at the factory, working alongside the master craftsman through actual pattern-making, repeated verification, and adjustment.
The second case was a customs declaration project in Yiwu, where the team faced scattered, blurry photos and documents. By collecting materials on-site and improving recognition capabilities, they cut the time to prepare most customs declarations from at least 3 hours to about 5 minutes, and the cost per document from a minimum of about 70 yuan to about 10 yuan.
Lu Yufeng emphasized that an FDE cannot just sit nearby listening or record with a device—they must personally do the work once, understand the judgments the master craftsman makes based on experience, and the exceptions that may arise in the process.
The business materials and operational experience collected must be organized into a knowledge base; the solutions should be distilled into reusable Skills, accompanied by test cases covering real scenarios and the customer's operating environment, to avoid "working fine during development but failing at the customer's site."
In his view, delivery results ultimately come down to how much time was saved and how much cost was reduced. The longer-term value of the FDE is turning the experience from one project into product capability, so that the next customer facing the same problem no longer needs the team to solve it from scratch on-site.
Below is the full transcript of Lu Yufeng's talk, corrected and edited by Model Force Workshop without altering the original meaning.
FDE: Work hands-on with the master craftsman, then turn the experience and solutions into Skills
Good morning, everyone! I'm glad to be here to share AI+FDE with you.
Let me briefly introduce myself. I spent many years as an entrepreneur, also worked at Alibaba, and served as CTO at different companies for a total of 14 years. Staying in one role for too long inevitably loses some freshness. After so many years of entrepreneurship, I wanted to try doing business myself, so in my new venture I changed roles and became co-founder and COO of DeepSpace Order.
Now, I go out to do business, sign deals, and drive implementation in specific scenarios. I'm responsible for channel building and ecosystem partner management, and I've also built an FDE team responsible for the delivery and implementation of enterprise Agents.
Today, I'd like to share several projects I've personally experienced during this period and the problems we encountered in them.
I'm not great at starting with lots of concepts, so let's first look at a concrete scenario: embroidery.
Embroidery is a fascinating industry, very well developed in Zhuji, Zhejiang, possibly accounting for 80% of the global market share, or even more.
Why did we enter this scenario? Because we're discussing the implementation of AI in enterprises, and industrial enterprises are part of that.
First look at this image: it's a very pretty fox, with the original image on one side and the embroidery version on the other. Turning a design image into a stitch file that an embroidery machine can use is actually very complex. This process requires a pattern maker to first produce the design, then use an expensive foreign software to spend a long time completing the pattern design. The software is similar to industrial CAD and is called Wilcom.
We tried this software. Initially we considered whether capabilities like Computer Use could be used to perform the operations, but later found it couldn't be done, because the judgments involved are extremely complex.
What craft requirements are involved? For example, different machines have different color schemes, patterns need to be split into many layers, and some require drawing outlines first, then filling. These are the basic craft principles of embroidery.
There are also more complex patterns, like landscape paintings. The fox image just shown is relatively simple—if difficulty is rated 1 to 10, it's at most a 4 or 5; when it comes to faithfully reproducing a human portrait, it becomes extremely complex.
We happened to know an ecosystem partner in Zhuji who had done digitalization for many years. When we discussed this topic, he was also thinking: what can AI do for embroidery pattern-making?
So we conducted a series of in-depth studies and found quite a few problems.
On one hand, it's time-consuming—possibly 5 days—and the software is expensive. On the other hand, much of the pattern-making experience resides in the master craftsmen's heads and has never been systematized into courses. Teaching simple operations, like how to use the software, is no problem; but turning a beautiful image into an embroidery file involves judgment about colors, aesthetics, and embroidery craft design—these are usually not taught and rely mostly on the master craftsman's experience.
So what we need to do is the "distilling the master craftsman" that everyone has been talking about recently. But how many master craftsmen are willing to be "distilled"? This is a very real question: why should I let AI replace my own job?
This is also a problem FDEs often encounter on-site. How do you persuade them to accept that the purpose of AI is not to replace them, but to improve work efficiency, so they can leave work early, get home sooner, and no longer have to carefully watch every stitch with their eyes, pondering how to do it better.
Our initial solution was to use capabilities like Computer Use to simulate the master craftsman's operations on the computer.
We did a lot of screen recordings early on, brought them back for analysis, and wanted to see if we could reproduce them exactly. Later we found that the entire operational process simply could not be fully copied or distilled this way.
So we changed our approach: why keep using the original way of working to complete the task? Why not do it the AI way?
Later, we changed the process to: upload the original image, select the embroidery fabric and corresponding stitch type, such as flat stitch, and then directly generate the stitch file.
Could this be done? We took more than 20,000 sets of relevant data, did extensive manual annotation, and did some post-training work, ultimately achieving minute-level output.
If pattern difficulty is rated 1 to 10, with 10 being the hardest, we believe patterns with difficulty 1 to 5 can already be produced in minutes.
This is the result we achieved after conducting on-site FDE requirements research in the industrial scenario in Zhuji. The output includes the embroidery image and the craft file, which lists information such as color codes and stitch counts.
Of course, we also encountered many problems in the process. Embroidery involves many colors, and changing threads involves tying knots and trimming threads.
At the very beginning, when the master craftsman looked at the image we generated, he found it would require more than 700 thread trims and knots. These are specific craft problems that must be solved by the FDE on-site.
Our FDE spent a long time at the factory, personally doing pattern-making alongside the master craftsman, then using AI to repeatedly train and verify on this image, before achieving the later results.
Now let's look at another FDE implementation scenario: customs declaration.
Yiwu has many foreign trade enterprises, and customs declaration is a very important part of their operations. One of the more complex scenarios we encountered is "1039," a representative customs declaration scenario in Yiwu.
Enterprises can hire outside personnel to prepare customs declarations, with fees mostly ranging from 70 to 200 yuan. Depending on the clarity of the photos and the completeness of the materials, manually preparing a customs declaration takes roughly half a day to a full day.
These are the materials typically received in the "1039" scenario—sometimes just a simple photo, including door locks, warehouse receipts, weighing slips, and so on. There are far more materials than these; they are numerous, messy, and sometimes the clarity is poor.
This is why manually preparing customs declarations takes so long: the materials are extremely chaotic.
Some scenarios can already generate documents online via software or provide electronic files, but the "1039" scenarios we've encountered are still quite complex, with many steps relying on manual work—submitting materials is often just taking a simple photo. So in the past, manually preparing customs declarations took a lot of time.
One of our FDE colleagues spent a long time in Yiwu, collecting the materials and information needed for customs declarations, continuously running and testing the AI agent, and improving its ability to recognize this data.
Looking at the results, the time to prepare most customs declarations can be cut from at least 3 hours down to 5 minutes. The original cost of at least 70 yuan per declaration drops to about 10 yuan or even less with AI.
These are two examples of FDEs conducting on-site scenario research, uncovering needs, and ultimately completing delivery.
Returning to these two cases, what do we think an FDE should do?
When building the FDE department, we thought about the focus of different roles. In the past, R&D focused more on features and scenarios, while product managers focused on how to organize scattered requirements into a complete product. The scope an FDE covers is broader—from scenarios and products to the entire industry, comprehensively understanding and uncovering needs. Sales, meanwhile, turns the product into industry solutions and sells them.
Customers see things differently. The roles above mostly start from the perspective of software or AI products, but customers are embedded in specific industries and businesses, and they care about: what is most beneficial to their industry and business, and what can truly help them?
So what's the first thing an FDE does when entering a customer site? Collect data.
Recently, we've reviewed quite a few failure cases. One pattern is: rushing to get work done right after arriving, fixating on one thing, hoping to break through from a single point.
We had a project that ran into a similar problem before, and the results weren't good. Later, we changed our approach: after the FDE arrives on site, first collect materials and gather as much of the company's context as possible.
This context isn't just the company's existing documents. Some small companies don't have well-organized document management—much of the information sits in WeChat, and some is scattered across different employees' computers. All of this data needs to be collected. The formats may vary, and some special formats require dedicated parsing.
When necessary, we also do data exports to gather materials completely. AI's summarization capabilities are now strong enough to help break down and organize these materials into a company knowledge base, which serves as the knowledge source for subsequent work.
After collecting materials, there's another very important step: the FDE must follow the customer—follow the role corresponding to the problem to be solved—and personally do the work once. Never just do interviews, standing by with a recorder or other device capturing what the customer says. That makes it very hard to truly understand the customer's difficulties. You must get hands-on, walk through the process yourself, to understand the problems involved.
In some places, experienced workers handle things by intuition and don't even consider them problems, but for newcomers, they're actually very difficult.
Whether it's customs declarations, embroidery, or the other foreign trade scenarios we're working on, it's the same: you must do it yourself once to understand the potential problems and exceptions you might encounter.
As a newcomer, you should adopt a learning attitude and ask the experienced workers: why does my approach cause problems? Are there exceptions? You must thoroughly understand these exceptional workflows and verify the handling results.
The hands-on process should also be documented at the end and written back into the knowledge base.
After "distilling" the experience of some role experts, we found the process a bit like Moutai's national standard: the craftsmanship is extremely tedious, but also highly standardized.
All of these processes can be accumulated during implementation. So how should we capture requirements, customer scenarios, and the problems encountered?
Our role is a bit different from what Bi Xuan described earlier. We're not an R&D role, but one focused on business execution.
Still, we emphasize: when delivering, the FDE should also capture the methods they ran and used. At first, you might complete a task with prompts, but once done, you should quickly turn it into a Skill, so your capability library gradually becomes complete.
Our FDE team has a shared Skill repository—everyone uploads what they newly write and also reviews each other's work. When we hit the same problem, we check whether a Skill written by another team member can solve it, and keep trying.
Additionally, you need to build a delivery Harness. Here, you can understand it as: the FDE must collect enough test cases to turn user scenarios into executable tests.
Today, using AI to run tests isn't very difficult. R&D folks mostly test the features, interfaces, and UI they develop, but testing based on real business scenarios must be done by the FDE team.
The FDE needs to collect enough scenario test cases. After R&D completes delivery and the test team finishes testing, we still run everything again with our own Harness and test case library, because these cases come from problems genuinely encountered in the field.
When some bugs are reported to R&D, the two sides may understand them differently. R&D may fix the problem at the underlying principle level, but whether the problem the user actually encountered is resolved isn't guaranteed.
For example, many of us are now used to developing on MacBooks and haven't used Windows in a long time, but almost all of our foreign trade customers use Windows.
Sometimes, after development is done, even if you spin up a virtual machine and it seems fine, problems can still appear at the customer's site: the customer's OS version, firewall, and other runtime environment details all need to be recorded. Developers can't always go on site, so this work needs to be handed to the FDE team. It's an important part of the delivery process.
Finally, you must measure the business results. If something doesn't deliver substantial efficiency gains and cost reductions, its value is fairly limited.
Customers may ask: labor costs are so low now—hiring part-timers, fresh graduates, or even students who haven't graduated yet is cheap—why should I use your product?
A product must deliver substantial efficiency gains and cost reductions to have value. So the FDE's final task is measuring business results.
From implementing features, to delivering specific scenarios, to accumulating capabilities and forming Skills and a Harness—that's the whole process we just described.
A while ago, an OpenAI researcher shared a view on X that I thought was excellent, roughly: if the next customer can solve the same problem without our help, then the FDE team has fulfilled its mission.
I saw a WeChat article summarizing it as "FDEs are eliminating their own jobs," which is a bit clickbait-y. Some of you may have seen it. But after reading it, I believe it's not about making FDEs unemployed, but about forming a feedback loop: OpenAI's FDEs turn the results achieved with customers into better products, and in this way, let the product take over work that originally required them.
That's a different concept from making yourself unemployed from the start.
This last slide is also an ad. We're a new company driving the adoption of enterprise AI agents across various industries. The industries we've entered so far are mainly foreign trade and cross-border e-commerce, which are very thriving industry ecosystems in Zhejiang.
We're also working on bank risk control and the industrial scenarios mentioned earlier. Next week I'll be visiting some industrial customers to learn about needs around CAD drawing generation and more.
I believe that in China, perhaps only one in ten thousand people can truly use AI well, or even fewer. We have a responsibility to help companies whose digital foundations haven't been strong complete their AI transformation—otherwise, they may find it hard to enjoy this wave of AI dividends.
I'm in charge of channels, ecosystem partners, and FDE-related work, and I hope to use this opportunity to connect with everyone. We have some product trial opportunities, and we also welcome collaboration on ecosystem capabilities. Even in the AI era, even with dozens of people running multiple AI agents in parallel for development, we still can't build every feature or solve every business scenario.
So, whether it's an individual FDE with industry background, or a commercial company that has already accumulated mature Skills and digital capabilities in certain industries, we hope to establish connections going forward and work together to solve these problems.
That concludes my sharing. Thank you, everyone.