FDE Case 100 — Text Transcription

Foreword

AI Is Starting to Truly Enter Enterprises

If we placed all enterprises on the same AI map today, we would see a highly uneven picture. Some enterprises are still thinking about what AI can do for them; some are still building their digital foundations; some have already begun bringing large models, agents, and automated workflows into real business operations, and are even attempting to transform their existing ways of working at scale. It is hard to summarize the state of enterprise AI adoption today with a single unified stage.

But over the past period, as we have truly gone into enterprises and interviewed case after case of AI implementation, one thing has become increasingly certain: AI has begun creating value in the real world.

It often does not first manifest as a grand "enterprise AI transformation." More often, it happens in specific, even small scenarios: a process that once required extensive manual handling, a piece of knowledge that depended on a veteran worker's experience, a repetitive information-organizing task, a sales follow-up, a report, a production line, or a problem that was never properly solved because the cost was too high. These changes may not be sensational, but they are already genuinely affecting enterprises' efficiency, costs, and ways of working.

This is why we launched "FDE Cases 100."

What we hope to record is not 100 so-called "standard answers for AI implementation." In fact, no such standard answers exist today. What we want to record more is the exploration being carried out by a group of pioneers: how they discover problems, how they understand the business, how they choose technologies, how they make trade-offs under real-world conditions, and how they gradually integrate AI into the actual business frontline. Some of these explorations have already achieved clear results; others are still in the process of validation and iteration. They are not perfect, and they may not be directly replicable. But it is precisely these practices, bearing the traces of exploration, that let us see the real path of AI moving from technical capability to industrial value. Every major technological transformation needs such a group of pioneers.

In this process, we have also come to realize that AI implementation is no longer just a technical problem. When AI truly enters an enterprise, the questions gradually extend from "can the model do it" to "which problems are worth solving," "how should business departments participate," "how should data and knowledge be organized," "how should new workflows be established," "who will continuously operate the project after launch," and — more importantly — how the enterprise itself can gradually develop the ability to use, understand, and build AI through project after project. This means that the changes brought by AI will ultimately enter the organization itself.

This is also how we understand FDE. FDE is not simply coming to an enterprise to complete a project and then deliver a system. We hope it is more of a co-building relationship: FDE works together with the enterprise to discover problems, define problems, build solutions, and validate value, while helping the enterprise gradually consolidate methods, experience, and capabilities within the organization. The end of a project should not mean the departure of AI capability. Truly valuable AI implementation means that while solving a specific problem, the enterprise also begins to learn how to solve the next one.

Therefore, we prefer to see FDE as a long-term co-building partner in the enterprise's AI transformation journey: standing between technology and business, and between today and the future, jointly completing a journey of transformation exploration with the enterprise.

This case collection is also Datawhale's阶段性 record of this process. We hope to continuously connect real industrial needs, rapidly evolving AI technologies, and the FDE teams and talents willing to go on-site to solve problems, forming an open, trustworthy, and long-growing ecosystem network — so that more real needs are seen, more practical experience flows, and more people willing to enter industry discover opportunities.

Here, we would also like to thank everyone willing to participate in this documentation effort. We thank all the enterprises, FDE teams, and frontline explorers who accepted interviews and were willing to share their real practices. It is precisely because everyone was willing to open up their real processes, experiences, and reflections that we have the opportunity to see a more complete and concrete picture of AI implementation. We also thank every partner who participated in case collection, interviews, compilation, editing, design, and dissemination — thank you for working together to gradually organize these practices scattered across industrial sites into the case collection you see today.

At the same time, we thank the enterprises, communities, and ecosystem partners who have supported the FDE project along the way, as well as the "Dedao AI Learning Circle" for the inspiration and ideas it brought to the presentation of these cases. This case collection could not have been presented without the trust, sharing, and joint commitment of every participant.

Special thanks to [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], [Name], and all partners who participated but could not be listed one by one.

We believe that what will truly transform industry in the future will not only be more powerful models. It will also be the countless enterprises, technical teams, and practitioners exploring together, one real scenario after another. And what we want to do is record these explorations.

Looking back many years from now, perhaps today's imperfect attempts will be seen as the starting point of AI truly entering the industrial frontline.

(This case collection is sorted alphabetically by FDE's first name)

September 6, 2026

From Mentorship to AI-Assisted Training: How an FDE Used AI to Solve the Challenge of Experience Transfer in Manufacturing

Q1: As an FDE, what was the specific scenario in which you applied AI? What did the specific problems in this scenario look like?

At the time, I was serving a parts manufacturing company in Stuttgart, Germany, with roughly seventy to eighty employees. The company had multiple production lines and many different product models.

This industry has a distinct characteristic: much of the production knowledge is extremely detailed. For example, when producing different parts, parameters need to be adjusted, and the ratios of different metal materials are involved. Because the parts ultimately face different operating environments — some may need to withstand strongly acidic environments, others need to be wear-resistant — different material ratios, equipment operations, and production experience directly affect product quality.

What truly made the company anxious was that this knowledge did not entirely exist in standard documents; a considerable portion of the experience was held by veteran workers.

The veteran workers knew how a particular product should be tuned, under what circumstances parameters should change, and how to handle certain equipment states. Much of this belongs to tacit experience formed through long-term practice, which is difficult to fully capture in an operations manual.

The company's biggest worry was: if the people left, would the experience leave with them?

So when I arrived, instead of first asking "which model should we use," I first went to see how they actually trained new employees.

Looking back now, this step was actually more important than the later choice of model. Because what the company initially said was "we want to preserve our veteran workers' experience," but that statement could not yet be directly turned into an AI project.

I had to keep going deeper into the business until it became a more concrete question: what knowledge exactly were new employees missing in their learning process, where was that knowledge, and how could it be found at the moment it was truly needed?

Q2: Before you got involved, how was this problem solved in the past?

In the past, it mainly relied on "people training people."

After joining the company, new employees went through a fairly long training and internship process, in which veteran workers played an important mentoring role. Based on what I learned at the time, training a new employee could take two to three months or even longer.

Much of the experience in manufacturing is formed through long-term practice in the first place. Veteran workers not only know the standard answers, but also know when the standard answers should not be mechanically followed. So the traditional apprenticeship system was actually a very natural way of transferring knowledge.

The real problem was that the company's business environment began to change. On one hand, the veteran workers' own production workloads were heavy, leaving them insufficient time to continuously mentor newcomers; on the other hand, some experienced employees were approaching retirement. Meanwhile, the company wanted to consolidate experience that had previously depended on individuals into knowledge the organization could use over the long term.

So what I did was first preserve the veteran workers' most valuable experience, so that questions that used to require repeatedly asking the veteran workers could get their first answer through another means; truly complex questions requiring judgment would still go back to the veteran workers. This way, the veteran workers' time no longer had to be constantly consumed by repetitive knowledge transfer.

From this perspective, what I did went a step further than "converting traditional training into AI training" — it was about redistributing the role of people in the training process.

Q3: What was your overall approach and the key steps in using AI to solve this problem?

Where the project truly consumed time was actually in how the various stages before and after were connected; building the knowledge base was only one step.

The first step was to enter the business first and put the technology aside.

At the beginning, I was originally accustomed to understanding client needs through interviews — talking with senior management, middle management, and frontline employees alike.

But when actually working on projects, I found a problem: frontline employees aren't necessarily willing to spend a lot of time on interviews, and many details of their daily work may not be fully described by the employees themselves in an interview. So later I adjusted my approach.

Besides interviews, I would directly shadow an employee through their daily workflow, observing what they actually do in a day, where they stop, where they need to ask others, and which questions keep coming up repeatedly.

The problems identified this way are far more specific than simply asking, "What are your pain points?"

In this project, I also started by finding the supervisor, mapped out the production line and the new-hire training process, then compiled the problems new hires most frequently encountered, the knowledge they were most likely to get wrong repeatedly, and which content constituted the tacit experience only veteran workers possessed. Finally, I organized all of this into a knowledge map.

Step two: turn human experience into knowledge that AI can use.

Once the knowledge map was in place, the next step was where knowledge processing actually began.

The enterprise already had some existing knowledge documents, so I first imported these existing materials and processed them through document parsing, RAG, and other methods. But documents alone weren't enough. A more important part of my work was abstracting the tacit experience that had previously lived only in the veterans' heads, so it could enter the enterprise's knowledge system and ultimately be understood and retrieved by AI.

There's a common pitfall here: thinking that once you throw documents in and the AI can answer questions, the knowledge base is done. I did not accept delivery by that standard.

The high-frequency questions identified during the early research naturally became the test set for later stages. For example, at the time I would check whether document parsing reached roughly 95%, whether the accuracy of retrieved answer snippets reached above 80%. Only when a minimal-scope test met the agreed standards did I consider this technical path preliminarily validated.

I think this is exactly where being an FDE differs from pure technical development: the problems discovered early on must ultimately be verified against those same problems.

Step three: put the AI back into the original training process.

Even after the technical pipeline was working, the project wasn't over. If you just give employees a new AI entry point and let them use it on their own, in many cases it simply never gets adopted.

So I kept working it into the business process. The enterprise already had a new-hire training step, so I integrated the AI knowledge capabilities into the platform they actually used, and further designed a training workflow similar to online course check-ins.

New hires could see how much learning content they had completed within the required timeframe; mentors could return to the platform to check each new hire's current learning progress; and each lesson included Q&A checkpoints for a simple verification of learning outcomes. In other words, the AI entered the existing new-hire training process, rather than adding an extra "chatbot."

Step four: stay with the enterprise as it actually puts the AI to use.

After launch, I continued to refine the frontend usability, pages, and actual Q&A performance. This process took more than a day or two—the hands-on support phase alone lasted nearly two months, and the entire project, from initiation and research through final support, took about six months; counting only the time truly invested in the project, it was about four months.

So enterprise AI deployment is rarely "system launch = project complete." Real adoption often happens after launch.

How employees use it, what feels awkward, whether veterans are willing to look at it, whether new hires can understand it—all of these questions ultimately feed back into demands for me to keep improving the product.

Q4: Compared with traditional methods, what were the actual results of using AI?

In terms of actual business changes, several shifts were quite clear.

First, knowledge that had previously been scattered in the personal experience of veteran workers began to be systematically organized. For the first time, the enterprise could gain a fairly complete picture of which experience truly could not be allowed to walk out the door when the veterans retired.

Second, the role of the veterans began to change—from repeatedly answering all questions to focusing on new hires' learning progress and handling more complex problems.

Third, training itself became more trackable. In the past, "where new hires had gotten to" and "how much they had actually mastered" depended largely on the mentor's own observation; now that progress could be clearly seen and tracked on the platform.

For me, the real value of this project was that a process of experience transfer that had previously depended heavily on individuals began to become an organizational process that could be accumulated, retrieved, learned, and tracked.

Q5: Did you encounter new problems or challenges while deploying the AI? How did you solve them?

In this project, I think at least three challenges are worth discussing on their own.

The first challenge: users can't articulate their needs or their experience.

At the start, I used interviews, hoping to understand the problems by talking with employees at different levels. But as I went along, I realized frontline employees aren't necessarily willing to invest much time, and many tacit work habits are hard to fully express through Q&A.

So I later reduced my reliance on pure interviews and instead directly shadowed employees through their daily workflows. It's a small adjustment, but extremely important for an FDE. Sometimes you can't keep pressing the user with "what do you need"—you have to go to the site yourself and watch how they actually work.

The second challenge: technical metrics can't be defined by the FDE behind closed doors.

For example, there's no industry standard you can directly apply for what counts as acceptable document parsing rates or retrieval accuracy. My approach was to first run a small-scope test to see what level was achievable under current conditions, then communicate with the client about what they actually needed, and finally have both sides jointly set the acceptance criteria. So the acceptance criteria themselves are part of the business communication.

The third challenge: even after the technology works, employees aren't necessarily willing to use it.

So I later spent a lot of time adjusting the frontend pages, the learning workflow, and usability. I didn't ask new hires to change their entire work habits to accommodate the AI; instead, I tried to fit the AI into their existing training and collaboration environment.

I've consistently held to this principle in enterprise projects: if the client already has a tech stack, platform, or model that can solve the problem, I reuse it as much as possible, rather than tearing down everything the client has just to show off technical capability. Because, from the client's perspective, clearly understanding "what already works and what genuinely needs to change" is itself a process of building trust.

Q6: Based on your experience, how can we better deploy AI into real business?

After completing this project, I have a clearer understanding that an FDE's most important capability actually doesn't lie in "how many models you know." I prefer to think of the FDE as a team: some people need to truly enter the client's site and diagnose business problems; some need to turn requirements into something that can run in the client's environment; and more specialized technical personnel are needed to ensure architecture, performance, and future scalability.

But no matter how the roles are divided, everyone is ultimately doing the same thing: turning the enterprise's vague problems into deployable, verifiable AI solutions, and then genuinely pushing them into the enterprise's business processes. If I had to compress the lessons from this project, I would summarize them in four points.

First, don't start from "what AI does the enterprise want to build"—start from "how does the enterprise actually work every day."

It's great when users have clear needs, but even without clear needs, as long as their business SOPs are sufficiently clear, I can go through the process step by step and judge where AI fits. So for enterprises, clarifying their core business processes before doing AI is itself extremely important.

Second, don't rush to overturn what the client already has.

When doing early research, I first look at what tech stack, platforms, and models the enterprise is currently using, and which of these can continue to be reused. If existing capabilities can solve the problem, keep using them as much as possible. What an FDE should do is find the solution that best balances the client's cost and business outcomes—there's no need to prove that your technical solution is the most complex.

Third, the problems discovered early on should directly become the testing standards for later stages.

In this case, the new hires' high-frequency questions didn't just sit in a report after the interviews—they were directly turned into the knowledge base test set. I think this is a crucial step. Only this way does the AI's final validation test "can it solve real business problems," with purely technical metrics taking a back seat.

Fourth, the AI must enter the process—it can't stop at the demo stage.

A knowledge base that can answer questions only proves the technical pipeline works. Only when new hires genuinely want to learn, mentors genuinely want to check it, and learning outcomes can be verified does it start to enter the business. That's why I spent nearly two months on hands-on support at the end. For many enterprise AI projects, the truly difficult part is that last mile—how to genuinely connect the AI with the enterprise's existing business processes.

This is my understanding of the FDE role. AI capabilities will keep getting stronger, and the barrier to building AI applications will keep getting lower, but an enterprise's own processes, organization, and real business environment will not automatically become clearer because of this. What the FDE truly needs to solve is the "last mile" problem between AI and the enterprise. In the future, technologies will change, models will change, and service formats will change too, but this ability to "go deep into the field, discover problems, validate solutions, and integrate into workflows" will, I believe, remain valuable for a long time.

<a id="no02"></a>

From Manual Document Review to Automated Case Processing: How an FDE Used AI to Improve the Vehicle Administration Office's Online Processing Efficiency

Q1: As an FDE, what was the specific scenario where you applied AI? What did the specific problems in that scenario look like?

This case is a bit special. At the beginning, the client did not actually raise an "AI requirement." When I first entered the vehicle administration office, it was only to take on a system maintenance project.

At the time, the original system vendor had gone out of business, leaving behind incomplete source code and missing documentation. Moreover, the entire system involved multiple technologies: a .NET client, an Android display program, as well as web-based management and scheduling systems. Many companies evaluated the project and declined to take it on, because this was not a problem that could be solved by simply finding an engineer to do some routine maintenance—it required truly digging into the legacy system and understanding it. I took on the project.

But looking back now, maintenance was just my entry point into the business scene. The truly valuable requirements were only discovered gradually after I got on-site. During my time stationed there, I began observing the office's online business operations.

Zhejiang's government services are already quite digitalized—many things can be handled online by citizens, sometimes without a single in-person visit. But I discovered a very interesting problem: while the front end had been digitalized, the back office still relied heavily on manual work.

After citizens submit business applications online, they upload various documents, such as ID cards, business licenses, contracts, invoices, and so on. These documents are basically all images, and the photo quality varies wildly.

Staff members had to open them one by one, use their own eyes to judge whether the documents were correct and the information complete, and then proceed with subsequent review and data entry. This process had been running this way for so long that people had simply gotten used to it. But from my observation on-site, the problems were actually quite obvious, and can be summarized in three characteristics: slow, exhausting, and unable to scale.

First, slow. A large number of images had to be manually opened, viewed, and checked, and the relevant information then entered into the system. Reviewing a single case from start to finish took about 15 minutes.

Second, exhausting. This kind of work is not complex—it is just highly repetitive. Staff members spent long hours every day staring at photos on screen, and some directly reported that "their eyes couldn't take it anymore."

Third, business volume couldn't grow. Behind the online business of the vehicle administration office, there was also a rather special business relationship. Some services involved an on-site courier company: after the office completed review and certificate production, the courier company handled the subsequent packing and delivery.

The courier company had to invest staff on-site. If business volume was insufficient and labor costs were high, the service itself would face financial pressure.

So on the surface, this issue looked like "staff are too tired from looking at images," but when you break it down further, it actually involves the entire business chain. Review efficiency determines case processing capacity; processing capacity affects citizen services, and also affects the partner's operating costs and whether the entire service model can be sustained.

The longer I stayed on-site, the clearer one thing became: an FDE cannot just wait for the client to write down the requirement as "I want an AI review system" before getting to work. Very often, the real requirement does not jump out on its own. You have to first enter the field, see how the business actually runs, see what people are doing, see which steps repeat every day, and then judge whether there is something there worth rebuilding with AI.

Q2: Before you got involved, how was this problem being solved in the past?

There was no special solution—it was all done by people.

After citizens uploaded their documents, staff would open the images, review them by eye, and then manually handle the subsequent business. This process had been running for a long time, and for the vehicle administration office, it was not even considered a problem that particularly needed solving. I think this point is very important.

Looking back today, we might ask, "Such obvious repetitive labor—why not automate it?" But from the perspective of the business department at the time, it was workable. The staff were there, the process was established, everyone knew what to do each day. It was a bit slow and a bit tiring, but it did not affect the basic operation of the system.

So when I first proposed to the client that visual technology could replace part of the manual review, they did not immediately accept it. Their first reaction was: "The current way works fine, so why spend more money on something new?" Also, they were not confident that AI could actually meet business requirements. Even though there were some ready-made capabilities on the market, on one hand the prices were not low, and on the other hand, no one could guarantee that taking them off the shelf would solve the real problems in the vehicle administration office's actual scenarios.

So the transition from the traditional approach to AI did not happen because the old way suddenly stopped working. The real change came from business conditions. The economic environment changed, and the on-site service company began facing operational pressure, hoping to reduce staffing while increasing business volume. The efficiency problem that was previously "not painful enough" suddenly became real. Only then did the solution we had prepared in advance get a genuine opportunity to be implemented.

So a deep takeaway from my later project work is this: many AI requirements have always existed—they just haven't been painful enough to demand change. What the FDE must do is see the problem in advance, so that when the business truly needs to change, there is already a validated solution ready to go—without forcibly manufacturing demand.

Q3: What was your overall approach and the key steps in using AI to solve this problem?

The project did not start with designing a complete solution and then launching it all at once. In reality, it went through a long process of observation, validation, building trust, formal project approval, and iteration.

Step one: first understand the problem clearly, without rushing to pick a model.

I did not start by telling the client "we're going to deploy AI." I first broke down the business to see what the manual work actually consisted of. Once broken down, you find that the entire review process essentially consists of a few types of work: viewing images, identifying document types, reading key information, judging whether documents meet requirements, filling in relevant data, and moving information between different systems.

Once broken down this way, the technical path naturally emerged. The "seeing" part used machine vision, OCR, and related recognition algorithms; the part requiring information extraction from complex texts like contracts gradually introduced large language models; and the repetitive data entry and cross-system transfer parts were handled with RPA.

So what we ultimately aimed for was one goal: let machines replace humans in completing the repetitive "see, read, fill, and move" work as much as possible.

Step two: gradually hone the capabilities using real business data.

The biggest characteristic of vehicle administration document review is that the data is extremely non-standard. We ultimately worked with about 9 categories of image documents, including contracts, invoices, business licenses, photocopies of ID cards, and so on. For each document type, we had to collect real samples, annotate them, train, and then go live to observe the results. This was completely different from a laboratory environment.

For example, with the national emblem side of an ID card, under normal circumstances the full ID card should be photographed, but some citizens uploaded photos showing only the national emblem. Contracts were even more troublesome: motor vehicle mortgage registration involves a large number of financial institutions, and each company's standard contract format is different. Some, in order to compress the content onto a single page, use extremely small fonts. And many documents are photocopies to begin with, so after being photographed and uploaded, the image quality degrades even further.

So training could not end in one pass—we had to constantly bring back anomalous samples from real business, supplement positive and negative samples, and continue optimizing. The entire development and iteration cycle lasted about six months, and the recognition rate improved bit by bit from just over 70% to around 98%.

Step three: embed the AI back into the original business process, rather than building an isolated tool.

This is what I consider absolutely critical. If you just build a recognition demo that tells staff "this image is X" after recognition, the value is actually quite limited. What really needs to be solved is whether the business can continue to run after recognition.

So we connected the entire chain: recognition, review, form filling, and subsequent system transfers. The office's original business involved different web systems, and after review approval, the data still needed to enter the Ministry of Public Security's unified business system. We did not require staff to learn a completely new, independent way of working; instead, we used RPA to link the different systems together and achieve the data transfer.

In the end, most normal cases could be completed automatically, with staff mainly reviewing results and reports, and only exceptional cases requiring manual intervention for verification. In other words, we turned the AI directly into an execution step within the original business process, so staff no longer had to face a standalone tool.

Step four: first build trust with results, then push for formal project approval.

There's also a very practical issue with government projects: even if the technology works, that doesn't mean it can go live. At the beginning, the client had no confidence in the AI's effectiveness, and formally launching the project involved reports, project approval, budgets, and technical feasibility studies. So we absorbed some of the pre-sales costs early on and started by implementing a few selected scenarios.

Rather than asking the client to believe our PowerPoint, it's better to let them see real results first. At the same time, our original operations and maintenance services kept moving forward. Through delivery after delivery, the client came to see that we weren't just "drawing pies," and our technical and service capabilities gradually gained recognition. Only when the AI solution itself had produced some results, combined with factors like headcount reduction, business efficiency pressures, and the government's innovation needs, did the project finally get the opportunity for formal approval.

So in this project, trust was built through the results of interaction after interaction—knowing people is far from enough. After an FDE enters an organization, the first project is not necessarily the ultimately most valuable one. Sometimes you have to start with a small entry point, do the first thing well, and only then do you get the chance to truly see the needs that lie behind it.

Q4: Compared with the traditional approach, what were the actual results after using AI?

Let's look at efficiency first. A full-process review of a single business case used to take about 15 minutes; now it can basically be shortened to three to five minutes.

As review efficiency improved, the average daily case volume also rose from around 700–800 to about 1,100.

It should be noted here that AI did not create this demand out of thin air. Many citizens already had the need to handle these matters; it's just that in the past, constrained by review capacity, the business couldn't be processed. Only after AI released the capacity that had been stuck in the manual review stage could this demand actually be served.

But I think what matters more than the numbers is that people's work changed. Staff used to spend a lot of time on repetitive tasks like opening images, checking materials, and entering information. After automation, this work decreased, and they could spend their time on citizen inquiries, new business, and things that require human judgment and communication.

For example, when citizens come to the service hall, they have many questions that need explaining. In the past, back-office review consumed a lot of energy; now staff can devote more time to serving citizens. So the essence of this is a reallocation of people's time—making one person review faster is only the surface benefit.

For the partner involved in on-site services, the change was equally obvious. Without increasing headcount—and even with fewer people—the overall case volume was maintained and grew slightly, giving a service model that had been under pressure from high labor costs better room to operate.

As for the vehicle administration office, the project ultimately passed acceptance smoothly, and afterwards new business kept being handed to us. Later, the two sides jointly established an AI innovation lab, and we continued to station personnel on-site to jointly develop new applications. In my view, this may say more about whether the project truly created value than any single technical metric. The true sign of a successful AI project is that after acceptance, the client is still willing to do a second and a third project with you.

Q5: During the AI deployment, did you encounter new problems or challenges? How did you solve them?

If I had to summarize the hardest part of this project, the hardest was organization and rules—algorithms actually come second.

The first challenge was that the material data was far too non-standard, and recognition rates couldn't go up.

The materials at the vehicle administration office aren't as clean as lab datasets. Common documents like ID cards, contracts, and invoices show up in all kinds of unexpected forms when actually uploaded. These problems were relatively clear-cut, but not easy to solve. When recognition rates weren't good enough, we kept collecting samples; when negative samples were insufficient, we added negative samples; when parameters weren't right, we kept optimizing. These issues were troublesome, but they basically all had engineering solutions—the real difficulty came later.

The second challenge was that AI exposed the "leniency" that had existed in manual review.

After automated review started running, we found that some business cases had been subject to a certain degree of "leniency" under manual review. At that point, the question shifted from "can the model recognize it" to "what exactly should be done once it's recognized."

If we enforced technical standards strictly, it could affect the existing business volume and the cooperative relationship; if we kept the previous loose standard, the automated review would lose its meaning. This is not something the technical team can decide on its own. Our approach was to present the problems and data objectively to the client—which materials had issues, how many cases could be processed per day under different review standards, and how business volume would change—and then let the client make the final decision based on actual operations and management requirements.

After running for a while, once everyone had real business data, we gradually found the balance point among efficiency, compliance, and business volume. Here the FDE needs to be very clear about their boundaries. Our responsibility is to build the technical capability, surface the problems, and clearly explain the possible outcomes of different choices; but final decisions involving business interests and management rules must be left to the business owner.

The third challenge was organizational coordination.

When a project first starts, you may only deal with one department and one person in charge. But once implementation truly begins, it involves different departments, different roles, and even external partners. Once informatization, digitalization, and intelligentization genuinely change processes, they will inevitably affect some people's existing work and interests.

So beyond doing technical work, an FDE must also be able to communicate, coordinate, manage projects, and even "do the interest math." You need to let different roles see what this change means for them—who will benefit, whose work will change, and who has the final decision-making authority when conflicts arise. If these issues aren't handled well, even the best model will struggle to truly enter production.

Q6: Based on your experience, how can we better deploy AI into real business?

After finishing this project, I gradually became convinced of one thing: AI applications must grow from within the business—things forcibly layered on from the outside rarely stick.

Now when I talk with many companies, everyone says they have "AI anxiety." The boss knows AI is important, the IT department knows AI is important, but when you ask "what specific problem do you want to solve," many people actually can't articulate it. In that situation, if the FDE immediately starts talking about agents, RAG, and large models, it doesn't mean much.

Now I'm more used to first asking the company a question: can you first list the ten most important problems in your business operations?

If the ten problems can be listed, we then judge together: which can be solved through digitalization, which can be solved through intelligentization, which are worth investing in now, and which aren't worth it even if AI can do them because the return on investment doesn't hold up. This is the real first step an FDE should take. So I believe that when an FDE enters a company, they should first act more like a consultant, and only second as a development engineer.

First, find the real problem before discussing AI.

Don't look for applications starting from "what technology do I have"; start from the problems that genuinely occur in the business every day. To judge whether a problem is worth solving, I look at a few very practical indicators: does it happen frequently, does it affect efficiency, revenue, cost, or service quality, does the business department itself have the will to solve it, and is there a budget. Only when these conditions hold does an AI project have a real foundation for implementation.

Second, enter through a small entry point—don't try to build something "big and comprehensive" right away.

My entry point into the vehicle administration office was, in fact, nothing more than a legacy system operations and maintenance project. But this small project got me onto the ground and let me truly see how the business runs. So don't underestimate the value of the first small project. The significance of a small entry point is building trust, and also gaining the opportunity to observe the business. Only after you've done the first thing well can you gradually move into more core processes and see problems you could never see in a conference room.

Third, the FDE must stay close to the ground for the long term.

Many needs can't be uncovered in a single interview. The material review problem in this case was something I observed bit by bit during operations and maintenance. At first, the client didn't even think it was a problem that particularly needed solving. That's why we now also station personnel at client sites—only by staying close to the ground can you know what staff actually do every day, what takes the most time, and which processes everyone has grown accustomed to but which may be exactly the places most worth transforming with AI.

Fourth, don't just build AI as a tool—embed it into the business process.

Real business value lies in whether the data can flow automatically after recognition, whether the process can continue executing, who handles exceptions, and whether the original staff need to take an extra step. If AI is just an extra page, and in the end someone still has to manually copy the results and paste them into another system, its value is greatly diminished. AI truly lands when it becomes part of the business process, with no separate AI tool sitting alongside it.

Fifth, organizational capability often determines a project's success or failure more than technical capability does.

Technical ability certainly matters. Without basic technical competence, you simply can't take on this kind of work at all. But in real projects, technology increasingly becomes just a baseline skill. What truly sets people apart is a combination of communication, management, coordination, requirements analysis, and business understanding.

Because what an FDE faces has never been just the model itself—behind it there are clients, managers, frontline staff, partners, budgets, processes, stakeholder interests, and internal organizational decision-making mechanisms.

What an FDE is really building is a bridge between business and technology. Technology is only one end of the bridge; the other end is business problems, organizational relationships, and real value. Only when both ends are truly connected has AI completed the final step from "technical capability" to "business capability."

<a id="no03"></a>

From Desk Work to Intelligent Collaboration: How an FDE Uses AI to Enhance Litigation Lawyers' Case Handling

Q1: As an FDE, what is the specific scenario where you apply AI? What do the concrete problems in this scenario look like?

We serve litigation lawyer teams, mainly handling complex cases such as commercial contract disputes and corporate equity disputes.

Once a lawyer takes on a case, they go through a complete, lengthy process: understanding the client's needs, reading large volumes of case materials, sorting out factual relationships, finding legal grounds, designing litigation strategy, and ultimately producing various legal documents.

On the surface, this is a knowledge-intensive industry. But after observing closely, I found that lawyers spend a huge amount of time on desk work every day.

First, case materials are massive and highly unstructured. A typical commercial litigation case may contain dozens of material types—contracts, chat records, financial vouchers, evidence documents—with total page counts often running into the thousands. Lawyers need to read, annotate, and categorize each one; material organization alone can take 3 to 5 working days. For complex cases involving a dozen or more parties, just sorting out the relationships between people can take two or three days.

Second, the barrier to translating legal language is high. The parties' original descriptions are often everyday colloquial speech, and lawyers need to distill them into legally meaningful elements of fact, then match them to the corresponding legal basis for claims. This translation process depends entirely on the individual lawyer's legal foundation—the efficiency gap between junior and senior lawyers can be 3 to 5 times.

Third, case information requires continuous maintenance. Litigation cycles typically last months or even over a year, during which new evidence and disputed points keep emerging. Lawyers must continuously maintain a complete understanding of the case, and every time they re-enter a case, they spend significant time restoring their memory and reviewing previous lines of analysis.

I gradually realized that the bottleneck in lawyers' productivity lies not in professional judgment, but in the efficiency of information processing. They are both decision-makers and executors trapped by desk work. To improve lawyers' overall case-handling capability, you can't just have AI answer isolated legal questions—you need to let AI enter the lawyer's complete workflow and become a continuously collaborating partner.

Q2: Before you got involved, how was this problem solved in the past?

The legal industry already had some tools.

Legal databases (such as PKULaw and Wolters Kluwer) can be used to look up statutes and precedents; document management systems help lawyers archive files; and there were also some early legal Q&A tools attempting to assist with generating simple text.

But these tools only solved two isolated actions: "lookup" and "generation." Real cases are constantly changing, and lawyers need to return to the same case repeatedly to supplement analysis and update judgments. Traditional legal databases are designed around one-off queries, which is completely disconnected from lawyers' actual working rhythm.

The standard way of working in the past was like this: after receiving case materials, the lawyer would read and organize them manually; convert natural language descriptions into professional legal language; search legal databases for relevant grounds; form judgments based on their own experience; and finally produce reports, litigation materials, or strategy recommendations. The entire process relied heavily on the individual lawyer's brain and experience.

Over the past decade, law firms also tried introducing more digital tools, but the results of implementation were generally disappointing.

There were two reasons: first, each tool solved only a single point problem, so lawyers had to switch between five or six systems, the case context was fragmented, and no coherent workflow could form; second, there was a disconnect between these tools' usage barriers and lawyers' natural way of working—lawyers had to learn specific search syntax or operational logic, adding extra burden.

In the end, most tools degenerated into aids for looking up statutes, never truly integrating into the complete case-handling process.

The fundamental flaw of traditional solutions was the lack of a role that could understand both technology and the business front line simultaneously, translating what lawyers actually need into implementable systems.

Q3: What was your overall approach and key steps in using AI to solve this problem?

Step one: enter the business front line to understand users.

After the project started, I didn't design features right away; instead, I first entered the lawyers' real working environment. Our observation of the law firm's litigation team was continuous, because litigation is a very complex matter, and we would bring back various types of anonymized materials from the field to study. We also conducted in-depth interviews with partner lawyers—this kind of research happened at a very high frequency. Through this research, we learned what they wanted, where they wanted to save time, and where they wouldn't feel at ease even if time were saved. This was highly instructive for our system design: which parts to leave for human decision-making and which to let AI handle and deliver directly—all centered around real needs.

Starting from nine in the morning when lawyers turned on their computers, we observed how they received client emails, how they flipped through paper case files, and how they switched between multiple systems to find information. I sat in on their case discussion meetings and recorded how partners broke down a seemingly simple contract dispute—their focus of discussion was not just the statutes themselves, but how to judge the parties' true expression of intent from WeChat chat records.

I would have in-depth conversations with lawyers, asking exactly what steps a case goes through from start to finish, what deliverables each step requires, who these deliverables are ultimately shown to, and what kind of result would be truly usable.

Throughout this, I held on to one principle: "deliverable value." What AI needs to generate is a result that a lawyer can use directly and deliver to clients, courts, or other professionals.

Step two: re-decompose the case workflow.

We didn't change lawyers' original way of working; instead, we looked for places within the existing process where AI could be embedded. Take early case preparation as an example: previously, lawyers had to manually read through thousands of pages of material and compile a case summary by hand—AI can now assist with this step; previously, lawyers had to manually convert the parties' colloquial descriptions into legal language before searching—AI can now assist with this step; previously, lawyers had to manually sort out evidence relationships, personal relationships, and legal relationships—AI can now assist with this as well. Through this fairly detailed decomposition, we ultimately formed 7 standard modules with high-quality legal reasoning, allowing repetitive but high-value work to be automated.

Step three: design the collaboration between AI and humans.

On the technical side, we adopted an architecture where large models and specialized systems divide and collaborate. The large model handles natural language understanding, text summarization, and preliminary legal reasoning—it excels at extracting key information from unstructured materials and understanding the complex needs lawyers express in natural language. The specialized system manages the case knowledge graph, structured retrieval of legal provisions, and precise matching of precedents, ensuring the accuracy and traceability of legal citations. The two are integrated through a unified case workspace, so what lawyers perceive is a seamless collaborative experience.

In our design, AI handles large amounts of information processing, analysis and organization, and repetitive work; the specialized system carries the case context and knowledge workflow; and the lawyer is responsible for final judgment, strategy selection, and professional accountability.

The state we hope to achieve is that lawyers don't need to learn complex AI techniques or prompt engineering—they only need to express their needs in their own professional language. For example: "Based on these case materials, help me analyze the next step in litigation strategy," "Help me prepare an evidence list," "Help me produce a report for the client"—and AI handles the work behind the scenes.

Step four: continuously adjust based on field feedback.

The entry point we originally designed was an intelligent dialog box—after logging in, lawyers could ask the AI questions directly. But after observing in the field for a while, a key problem emerged: before every question, lawyers had to re-describe the case background to the AI.

The amount of information in a single case is enormous, and lawyers can't possibly recapitulate it fully in every conversation. Conversational interaction actually increased lawyers' burden.

So we adjusted the design: changing the product entry point from a chat window to a case workbench. Lawyers first upload case materials, the system automatically builds a case knowledge graph, and the AI interacts with the lawyer on the basis of fully understanding the case context. Lawyers no longer need to explain the background each time—they only need to state specific needs in professional language. This adjustment significantly lowered the barrier to use for lawyers and helped them accept AI's involvement faster.

Q4: Compared to traditional methods, what were the actual results after using AI?

The changes brought by AI first showed up in efficiency metrics.

One case involved 14 defendants. Under the old approach, analyzing the legal basis of claims for a single defendant took 2 to 3 hours, and organizing everything took 2 to 3 days. With AI assistance, the lawyer handed the case materials to the system, and in one evening it completed work that would normally have taken days.

Another case left a deep impression on me. A lawyer took on a case at short notice, with only 3 days until the court hearing, but the case materials exceeded 1 million characters. Relying entirely on manual reading, it would likely have been impossible to fully understand the whole picture of the case before the hearing. With AI assistance, he completed a full review of the case in one day—including relationships between people, legal relationships, and the case's overall thread—and went on to formulate a hearing strategy. Material organization efficiency improved by roughly 70% compared to a purely manual approach.

But efficiency metrics are only the surface-level result. The more important change happened at the process level.

In the past, lawyers spent enormous amounts of time on execution work: reading materials, organizing information, searching statutes. Now, AI helps lawyers complete these foundational tasks, freeing lawyers to focus their energy on higher-value work: in-depth communication with clients, judging the direction of the case, formulating strategy, and making final professional decisions. The lawyer's role shifts from executor to decision-maker.

In the long run, the deeper value lies in making professional expertise replicable. In the past, an outstanding lawyer's personal experience was hard to transfer to the team, and differences in experience across lawyers led to inconsistent delivery quality. Now, through AI systems, the professional methods of top lawyers can be engineered and codified, giving more lawyers stable supporting capabilities. This is the real meaning of FDE work: it improves the efficiency of individual projects while making professional expertise reusable and scalable.

Q5: Did you encounter new problems or challenges during AI deployment? How did you solve them?

The first challenge was structuring tacit knowledge.

The difficulty of the legal industry goes beyond knowledge itself. Much of the time, what matters is how lawyers think: which facts deserve attention? How do you convert a layperson's description into legal language? Which legal bases genuinely match? How do different pieces of evidence form logical relationships? All of this is tacit knowledge formed through years of legal practice.

Our approach was to invest substantial time working alongside excellent lawyers, observing their thought processes and breaking down the decision logic behind their judgments. Specifically, we mapped out the thinking frameworks lawyers commonly use in case analysis—such as the "three layers, four steps" method for analyzing the legal basis of claims and the logical rules for building chains of evidence—and converted these frameworks into process nodes the system could execute. This allows the AI to organize information the way a lawyer professionally thinks, going beyond mere information output.

The second challenge was defining the product form.

Many AI products take the form of a chat window, but that form doesn't fit legal case scenarios. A case is more like a long-term project that needs to continuously hold large volumes of materials, process records, and changing information—a single conversation simply can't contain it.

As mentioned earlier, we changed the product entry point from a chat box to a case workspace, guided by a key design principle: let users create the case first, then interact. All analysis results, strategy recommendations, and document drafts are deposited in the case space, forming a traceable work record. Lawyers don't need to re-explain the background every time, and the AI doesn't need to repeatedly rebuild its understanding. This design turned the AI from a one-off tool into a collaborative system that accompanies the case through its entire lifecycle.

The last one was the shift in user habits.

At first, many lawyers entering the product would instinctively look for an input box, wondering "where do I type my question?"—because everyone was already used to chat-style AI. But after actually using it, they found: if the AI already understands the case background, you don't need to keep describing the problem, and efficiency is actually higher.

Our response was to not force users to change their habits. On first use, we guide them to upload materials first, letting the AI demonstrate the value it can provide once it understands the case background. When lawyers see the AI-generated case summary and the automatically organized relationship diagrams, they naturally understand the logic of "create the case first, then interact." In this process, we found that letting users see the value with their own eyes is more effective than any explanation.

Q6: Based on your experience, how can we better deploy AI into real business operations?

First, start from the business problem and define requirements in business language.

When many teams start doing AI, they first ask "what models do we have" and "what capabilities can we call." But the questions that really should be asked are: "Who will use it?" "Why do they need it?" "What is their actual workflow?" Without understanding the business, you can't judge which problems are worth solving. Without understanding the technology, you can't find the right approach. In this project, if we had started from model capabilities, we might have built a legal knowledge Q&A tool—but that only solves a tiny sliver of a lawyer's work and wouldn't truly change how lawyers work.

Second, go to the field and define problems together with industry experts.

FDEs must go to the field. You cannot understand users through imagination; you must genuinely observe how they work. During the period when we worked in deep collaboration with lawyers and observed their working state, we discovered that what we had imagined was not what was actually needed. More importantly, you must work with industry experts and find people who truly understand the business. When you don't understand an industry, you have no standing to define its problems on its behalf. In this project, the thinking frameworks of excellent lawyers were the core input for the AI system's design—without their deep involvement, the system could never be truly useful.

Third, focus on implementation details more than on model capabilities.

The keys to an AI project's success go beyond technical performance—there are many more dimensions. Are users willing to use it? Is the process natural? Is the cost acceptable? Can the results actually be delivered? These questions matter more than model capability itself.

The value of an FDE lies in connecting business, technology, and users, making AI truly enter enterprise processes and generate value. AI is only the means; changing the way work is done is the goal.

I believe an FDE cannot re-customize from scratch for every project. A truly valuable FDE needs to abstract experience into reusable methods, modules, and capabilities through each business deployment, making the next project more efficient. This is also the key to FDEs being able to scale in the AI era.

<a id="no04"></a>

From Manual Analysis to Intelligent Dispatch: An FDE Uses AI to Rebuild Urban Planning Analysis Workflows

Q1: As an FDE, what is the specific scenario where you apply AI? What did the specific problems in this scenario look like?

The urban planning industry is quite special in itself. Planning and design is not as simple as getting a table, running a few analyses, and generating a report—behind it lies a very complex professional division of labor.

For example, to plan a mobile cabin hospital, first the overall planning department determines roughly which district it should be located in; going further down, you need to look at what planning constraints and rules apply to that location; and when it actually lands on a specific plot, you must further consider a whole series of factors: roads, water, municipal infrastructure, public services, industry, and so on.

So the people we really need to deal with span roughly 10 departments.

What makes it more complex is that this project involves not only ordinary business data, but also spatial data.

In the past, when we did many government, e-commerce, or other enterprise projects, we mainly handled two-dimensional business data—what something is called, what its attributes are, what its parameters are. But urban planning adds a layer of spatial relationships. For a plot of industrial land, you not only need to know its business attributes, but also exactly which coordinates it occupies on the map and which surrounding roads or facilities it relates to.

On top of that, each department has its own professional tools, business semantics, data rules, and workflows.

So I later concluded that the real difficulty of this scenario is connecting four things: business, data, space, and tools.

And there is a fifth thing at the end: people.

Because the people in those 10 departments work in different ways, and their understanding of the same metric may also differ. You must truly understand the business language, calculation rules, and workflows they actually use—otherwise, what the AI generates may look professional, but a real planner will see at a glance that it's wrong.

Why is this problem worth solving?

Because urban planning itself is changing. In the past, when cities were rapidly expanding, much planning involved making choices in incremental space; now, it is more about finding optimal solutions within existing urban space and existing plots. Planning is becoming ever more refined, and the constraints involved in decisions keep increasing.

Meanwhile, planners' original workflow was very heavy.

A leader might say just one sentence: "Help me identify the potential land parcels in the XX area." Then the people below have to start digging up materials, pulling data, doing spatial analysis, running tools, and holding discussions before finally producing a report.

So the opportunity we saw at the very beginning was: could we first take over the part of planners' work that they repeat every day, where the rules are relatively clear and the data is traceable, freeing people's time for the things that truly require judgment and innovation.

This later became my basic standard for judging whether a scenario is worth applying AI to: Does it happen repeatedly? Is the cost of repetition high enough? Can the workflow be defined? Can the underlying facts and data be traced? Can the specialized tools involved be invoked?

If none of these conditions exist, and you're just forcing a scenario to justify being "AI First," I don't think it's necessary.

Q2 Before you got involved, how was this problem solved in the past?

Actually, the planning and design institute's level of digitalization was not low to begin with. They weren't short of software—the specialized software they used was in fact very complex. Planners themselves are also a typical group with high digital literacy.

In the past, after receiving a planning task, a planner would usually first look through a large amount of reference material, then move into specialized GIS tools, layer different layers on top of each other, run scripts, perform spatial calculations and annotations, and then form their department's judgment based on the results.

If the final output was a comprehensive planning report, the analyses from multiple departments also needed to be consolidated.

A single-person, single-item analysis might take about an hour in the past; a complete cross-departmental report would typically take professionals 3–5 days, sometimes close to a week.

This time doesn't mean they were inefficient—the real reason is that urban planning demands extremely high precision.

Where a road is drawn, whether a plot touches a historical and cultural protection line, whether a district's sewage capacity is sufficient—none of these can be answered casually. Once a plan goes wrong, it may affect actual construction downstream, so many results must be repeatedly checked, revised, and discussed.

Take site selection, for example. The system might first screen out 20 candidate plots, but picking the 10 truly suitable ones out of those 20 often required several rounds of meetings across different departments, with continued judgment based on various professional indicators.

So the traditional approach actually had its rationale: professionals mastered the rules, specialized tools ensured computational precision, and human experience was responsible for the final judgment.

The problem is that as the data, rules, and departments to be considered kept growing, this process became increasingly heavy. Large amounts of professionals' time were consumed on looking up materials, finding rules, switching between tools, repeating calculations, and organizing reports.

This also shows that the planning institute's digital tools were always there—it's just that they solved the computational precision of individual steps. There was no role that truly connected the business, data, spatial information, and tools, so cross-departmental, cross-tool workflows still had to be stitched together by people.

Therefore, when we did the AI transformation, we had no intention of overturning the traditional process. My thinking was actually the opposite: keep what was correct as much as possible, and take over the parts that machines are better at.

Q3 What was your overall approach and the key steps in using AI to solve this problem?

One thing about this project that influenced me deeply was that it gradually made me figure something out: an FDE must first go into the field, and only then decide what tools to actually use.

Step one: force yourself to become "half a planner."

Urban planning is a highly specialized industry. When I first went in, they had many professional handbooks, very thick ones. If you don't know many of the terms, you simply can't keep talking with the business people.

For example, if they ask you "what does candidate plot mean" or "what does potential land analysis mean," and you can't even answer these basic business concepts, it becomes very hard to build trust afterward.

So my requirement for myself at the time was to first become one of them. I didn't need to actually reach a planner's level of expertise, but I at least needed to know what they do every day, why they do it, what an indicator actually represents, and why a spatial calculation is done that way.

We would go to different departments to talk with them, gradually figuring out the meaning of their numbers, their spatial calculation methods, their business indicators, and their workflows.

This step doesn't look like "doing AI," but I think it is precisely the core work of an FDE. Because only by understanding the business do you know what should be handed to the model, what should be handed to specialized tools, and what must be left to humans.

Step two: don't start with the whole city; first shrink the problem to be small enough.

If you tried to bring in all the city's data, all departments, all third-party systems, and all business rules from the start, the project would easily fall into an endless data engineering effort.

So we later deliberately narrowed the scope. From the entire city, down to one district, then down to a specific unit like Mishixiang, and then picked only two clear business flows to validate.

I later felt this decision was extremely important: only when the scenario is small enough can the data possibly be cleaned up; only when the data is clean can the results possibly be precise enough; only when the results are precise enough will business people be willing to trust them.

So in phase one, we didn't bring in all third-party systems and the data platform. We only had the departments participating in the pilot first screen out the data they truly needed, and governed the data for this small slice of the scenario.

Step three: first build the three foundations of "data, knowledge, and reports" solidly.

Why did we dare to say at the time that a report generated in 20 minutes was "scrutinizable"? It mainly relied on three things underneath.

First is data. The key data in the reports came as much as possible from real data provided by the planning institute and was obtained through professional calculations—we didn't let the model guess on its own.

Second is knowledge. We organized the relevant planning rules, professional documents, and other knowledge, and used retrieval-augmented methods so the AI could find its basis. For example, why an office building can't be built in a certain location might be because it touches a historical and cultural protection line. In the past, planners had to search through piles of PDFs for the relevant regulations; now the corresponding rule can be located much faster.

Third is report templates. Different departments originally had their own reporting habits. We took the departments' templates as well as industry templates and eventually distilled a relatively general output structure.

So in the end, the AI was working within real data, professional rules, and a fixed report structure—it was no longer writing out of thin air.

Step four: let the AI orchestrate specialized tools, leaving computation to the tools.

This was also a very important judgment we made later. Many planning calculations actually have clear rules. Since specialized GIS tools can compute precisely, there's no need to let the large model do the math itself.

So our division of labor gradually became clear: the model is responsible for understanding and analysis, specialized tools are responsible for facts and computation, and humans are responsible for the final decision.

The AI is more like an orchestrator. For example, after a planner raises a site selection task, the AI understands the intent, then invokes the corresponding data and specialized tools to complete the analysis, and returns the computation results.

For high-frequency tasks with clear rules, we preferred to solidify them into workflows; for long-tail, more open-ended questions like urban assessment and potential land analysis, we handed those to an agent.

Step five: the product should grow out of the original work habits.

We didn't turn everything into a chat box. Because the true center of a planner's work is the map.

So the final interaction retained the way they were familiar with: filter conditions and specialized tools on the left, the map in the middle, and the Copilot on the right. After the AI invokes a tool or completes an analysis, the results are displayed directly back on the map.

I later felt this was very important. It's easy to fall into a trap when building AI products: since you have an agent, stuff all the features into a single input box. But what an FDE must consider is how the user originally worked.

The map is the planner's true workbench, so the AI should serve around the map, letting planners continue working the way they always have, without having to learn a new way of working just for the AI.

Q4 Compared with the traditional approach, what were the actual results after using AI?

The change first showed up in time.

In the past, a complete planning report spanning multiple departments typically took 3–5 days, sometimes close to a week. Now, in the pilot workflows that have been run through, a report that can be further scrutinized and delivered can be produced in about 10–20 minutes.

Looking at a single department only, some analyses and tables that used to take about an hour can now be completed in about 5–10 minutes.

Phase one involved about 10 departments, and currently roughly 20–30 specialists are using it.

But I gradually came to realize that the project's true value goes far beyond "turning 3–5 days into 20 minutes." Two other changes are more important.

The first is that planners have begun to break free from large amounts of repetitive operations. Previously, a lot of time was spent looking up materials, finding rules, operating tools, and organizing results. Now that this work has been compressed, people can devote more energy to things that truly require professional judgment.

Moreover, the AI sometimes suggests potential analysis factors that were outside the original workflow. For example, when judging a district's economic vitality, one might previously look at traditional indicators like transactions and traffic flow, but the AI might suggest also observing other signals such as parking gate frequency, housing vacancy rates, or population profiles. These suggestions aren't necessarily the answer themselves, but they can offer planners new research perspectives.

The second change was that the organization itself began to change. In the first phase, we worked alongside different departments to map out their workflows. Later, some departments had already started to consolidate processes like "identify, calculate, process, and output candidate plots" into Skills on their own.

In other words, they were already learning how to build AI workflows themselves.

To me, this is what makes FDE fundamentally different from traditional outsourcing. A good FDE project is one where, after the delivery ends, the customer starts growing their own AI capabilities.

Q5: During the AI deployment, did you encounter new problems or challenges? How did you solve them?

Of course, and many of the truly hard problems weren't in the model at all.

The first challenge was that departments aren't necessarily willing to give you data and rules.

Among the 10 departments, some naturally supported AI, while others had reservations, worried that once this system went live it would affect their roles and value. So when we went to ask about business rules and request data, some people responded very slowly, or even said outright: "All of this is available online, look it up yourselves."

But in reality, many rules are only known by the people who actually do the business. At times like this, an FDE can't rely on technology alone.

I gradually figured out a pattern: in complex organizations like this, finding the "execution lead" who can truly drive the project is critical. The project sponsor might be a vice president, but the person who can actually coordinate 10 departments, knows who is hardest to move and who holds what data, is often the person below them responsible for overall coordination. We had to talk things through with this person first.

At the same time, I also built fault tolerance into the solution. If a department temporarily wouldn't provide data, I wouldn't let the entire project stall because of it. One department fewer, then one scenario fewer for now; one type of data missing, then that part simply doesn't participate in the calculation for now. But in the end, the overall pipeline had to run end to end.

I set myself a very simple delivery principle at the time: "one document, one diagram, one table" had to be produced. Even with a node missing, the core deliverable form still held. This made me realize that when an FDE designs a solution, they can't make every component "indispensable," otherwise one uncooperative department can drag the whole project to a halt.

The second challenge was the tension between model capability and data security.

At the time, due to data security requirements, foreign models couldn't be used freely in the production environment. But the locally available models at that stage didn't perform well enough on some complex tasks to meet our desired state. And to make matters worse, leadership would demand demos at any moment.

This is when you realize that doing a real project is completely different from doing a demo. A demo only needs to "run beautifully this one time"; a production system must consider security, stability, accuracy, and traceability.

So we later compensated for model capability through more explicit system prompts, tool encapsulation, and engineering rules, while handing anything that truly required precise computation to specialized tools as much as possible, reducing reliance on the model's free-form generation. Technically, we adopted a hybrid deployment: for complex inference scenarios we used cloud models, while fixed workflows ran on locally deployed models, such as Qwen 7B.

This is also a lesson that hit home for me later: model capability is only one part of the whole system. What really determines whether something can go live also includes data, tools, evals, and fallbacks.

The third challenge was that the "AI effect" the customer wanted wasn't necessarily the best solution.

Initially, the customer wanted "one sentence to generate a report." It sounded natural, but once we dug deeper, we found that if you simply interpreted it as intent clarification followed by converting the question into SQL to query the database, it was very hard to satisfy the complexity of planning business. So we suggested setting aside the "universal data Q&A" for now, and instead letting the AI understand the task and then call the real specialized tools to complete the processing.

In later stages, similar issues came up again. For example, people would expect "multi-agent deliberation": legal experts, economics experts, and livelihood experts sitting together discussing a planning issue. It sounded very advanced.

But when we actually analyzed the business, we found that some site-selection problems ultimately depend on explicit rules and metric calculations. In those cases, forcing multi-agent architectures not only made the architecture more complex, but passing context between multiple agents could also introduce ambiguity, loss, and contamination, and the results were actually less convergent.

So our approach gradually evolved: on the surface, different professional perspectives could be represented, but underneath, multiple agents chatting with each other wasn't necessarily needed. We could encapsulate different professional capabilities as tools, orchestrated by a single core agent. And for certain problems of finding optimal solutions, a large model shouldn't necessarily be used at all—traditional optimization algorithms might be more precise.

This process made me increasingly convinced that an FDE's job is to help customers judge where AI should truly be used, and where it shouldn't.

Q6: Based on your experience, how can we better deploy AI into real business?

After finishing this project, my biggest shift in understanding of the FDE role was that I no longer saw the FDE as, first and foremost, "someone who understands models."

First, get into the business first.

If you're working on legal business, actually shadow lawyers through their work; if you're working on urban planning, find a way to become "half a planner." Many of the problems enterprises state on the surface aren't the real problems. Only by actually running through their workflows with them will you discover which things are repeated every day, where the truly expensive costs lie, and which steps look insignificant but determine the final outcome.

Second, don't start big.

Our project could have told a big story from the start: the entire city, all data, all planning scenarios fully intelligentized. But what actually got the project moving was continuous narrowing. From a whole city down to a district, then down to a specific unit, then picking two workflows. First find a scenario that is small enough, real enough, and can form a closed loop; get it running end to end, then expand.

Third, don't worship technical sophistication.

Customers want problems solved, not technical frameworks. If hardcoding can solve it, hardcode it; if a fixed workflow suits the current task, use a workflow; if the current task is more flexible and an agent suits open-ended tasks, use an agent; if the current task requires fine granularity and traditional algorithms are more precise than large models, use traditional algorithms.

What I value more now is how models, data, tools, people, and evals combine to form a truly deliverable system. Especially evals and fallbacks. Demos are easy to make; what's truly hard is: who discovers it when the data is wrong? What happens when the model gives bad advice? Can calculation results be traced back? Who is ultimately accountable for decisions? If these questions can't be answered, even the coolest demo won't make it into real business.

Fourth, understand that the FDE's own role also changes.

In this project, I actually went through three stages. At the very beginning, I was like a newcomer and assistant, first learning their industry and making myself one of them. Once I understood the business, I began helping them redefine problems, design processes, and judge where AI was a good fit. Later on, when they themselves already knew how to build Skills, do VibeCoding, and try building their own AI applications, my role changed again. At that point, I didn't necessarily need to write every feature for them; I could stand at a slightly higher level and tell them what pitfalls lie ahead, how to choose an architecture, and which directions are worth investing in.

So now I'm more certain that what an FDE ultimately does is accompany the enterprise through a fresh examination of its own business, find the real problems, turn business knowledge into executable processes, and then place AI where it fits best. We need to dig in like bamboo roots—and when one day the customer starts understanding AI, transforming their workflows, and even building new Skills on their own, that's when the project truly transforms from a one-time technical delivery into a continuously growing AI capability inside the enterprise.

<a id="no05"></a>

From Needle in a Haystack to Full-Pipeline Efficiency: An FDE Uses AI to Rebuild TikTok Creator Outreach and Fulfillment

Q1: As an FDE, what is the specific scenario where you applied AI? What did the specific problems in this scenario look like?

The business scenario of this project was the creator outreach business of a leading domestic e-commerce company within the overseas TikTok ecosystem.

If you understand it through the lens of domestic e-commerce experience, a TAP is somewhat like a "group leader."

When merchants have new products or marketing events and want to find a large number of creators to help sell their products in a short time, they first go to a TAP; the TAP then selects suitable people from its creator resources, pushing them to take on products, receive samples, and create content, ultimately listing the products on the creators' accounts. This role itself solves a very real problem: there are too many products on TikTok, creators can't possibly browse the product marketplace one by one, and it's hard to judge what's worth selling based on product information alone—so the TAP needs to organize merchants and creators together.

When we first engaged with this client, they hadn't actually defined the problem clearly at the outset. When they first approached me, they asked a very broad question: "How can our team use AI for empowerment?" So instead of answering directly, I turned the question back to them: How does your business actually run today? Which part of the process is slowest? Who is the most exhausted every day?

Where are things most likely to go wrong?

Later, we went on-site at the company and interviewed nearly everyone—from the boss to department heads to team leads. Through these interviews, I found that they were already aware their efficiency was low, but their previous so-called digitalization had mostly amounted to "advanced teams using Feishu first." At the actual business level, a large amount of work was still done manually. When I looked at the entire business as a whole, I found the problem ran through several stages.

First is creator outreach—finding people is hard.

Operations staff need to search for and screen creators on TikTok, then proactively message them. It used to be like "finding a needle in a haystack": operations had to find people themselves, review creator profiles, judge whether they were suitable for collaboration, and then reach out.

Second is product matching—matching is hard.

The client's own product pool contains tens of thousands of products, while creators have different content tags. Some are fitness creators, some are lifestyle creators, and some create history or philosophy content. Which products should be pushed to which creators is essentially a matching problem.

Third is fulfillment—the cycle is long.

After a creator agrees to collaborate, there are still multiple stages: shipping samples, receiving samples, communicating about filming, creating the video, and submitting it to TikTok.

The original average fulfillment cycle was about a month. Operations staff spent a huge amount of time "chasing": Has your sample arrived? When will you film? When will you submit? Isn't the deadline coming up?

Fourth is data management—too scattered.

This is actually a more fundamental problem. Some data lives on TikTok, some in Excel, and some in the finance system. Creator BD (Business Development), fulfillment staff, and finance each maintain their own data. When the boss wants to know what a creator went through from initial contact to ultimately generating GMV (Gross Merchandise Volume), it's not easy to find out.

So my final judgment was that the entire business pipeline had reached the stage where it needed to be restructured.

Q2 Before you got involved, how was this problem being solved in the past?

When the business was still small, this process relied mainly on people. One operations person would manage dozens of creators a day, keeping track in their own head of who was at which stage of conversation, who had received samples, and who hadn't filmed yet. Combined with Feishu and Excel, the business could run normally.

Creator outreach itself also relied heavily on person-to-person communication. Especially for creators with large followings—even those approaching celebrity status—business communication involves many subtle dynamics, which in the past mainly depended on experienced BD staff to judge and handle.

The real problem was that once business complexity increased, this approach hit a bottleneck. For example, when the product pool grew from a few hundred products to tens of thousands, operations could no longer rely on experience to match them one by one; as creators multiplied, it became impossible to manually go through Excel every day to find who needed chasing; and once data was scattered across different systems, managers could hardly see the entire business funnel in a timely manner.

My understanding is that the old approach solved the problem of "can the business run," while AI solves the problem of "can the business still run efficiently once it scales."

Q3 What was your overall approach and the key steps in using AI to solve this problem?

The first thing I did was map out the business process. From creator onboarding, to creator outreach, to product matching, then to sampling, content creation, and fulfillment, and finally to data review, I broke down the entire pipeline: Who does each step? What are the inputs? What are the outputs? What judgments are required? Which work must be done by humans? Which work can actually be handed to machines?

After breaking it down, I found that not every stage is suitable for AI, so our approach was to redraw the division of labor between AI and humans.

Step 1: Let AI first do the "finding the right people"

Creator outreach is a typical example. Using data such as product information, creator tags, and content attributes, we can first screen out a batch of creators most worth the operations team's attention.

For example, what are a product's main selling points, and what audience does it suit; what type of content does a creator make, and who is their audience. The system first screens out high-match candidates and gives the BD team a more precise list, so operations no longer have to "find a needle in a haystack" across all of TikTok.

But the final messaging, communication, and relationship building remain human, because creators are the client's most core asset.

So AI's role here is to shift the BD team from searching for targets to communicating directly with them.

Step 2: Use AI to solve the matching problem of "which product goes to which creator"

Previously, operations had to rely on creator tags and their own experience to decide which products to push. Now we extract the selling points of the products themselves and match them against creators' content attributes.

For example, a coffee product's selling points might include flavor, carbonation, brand, and co-branding; if a creator focuses on career or lifestyle content, then this product may match their content attributes well. AI can complete this initial screening first, followed by human confirmation—turning what was previously a heavily experience-based manual screening process into "AI screens first, humans judge after."

Step 3: Use AI to help creators complete content creation, solving the fulfillment motivation problem

This is the part I find most interesting. In many cases, creators aren't unwilling to sell products—their real sticking point is that after receiving the product, they don't know "how to film it." A product-selling video isn't just a simple product introduction; it needs to account for the creator's own style of expression, the product's selling points, and what kind of video content currently tends to attract attention.

So we combine these factors: creator characteristics \+ product selling points \+ references from viral content. After analysis, the system provides the creator with several optional shooting scripts. This essentially helps creators complete part of the creative work—it's an "altruistic" capability for creators, not just TAP improving its own efficiency. In interviews, the client reported that creators currently have a fairly high level of acceptance for this capability.

On this basis, we can further explore AI video generation in the future, giving creators an additional content production method beyond appearing on camera themselves. However, for creators built around a personal IP, we still believe that the real person and real content are the core.

Step 4: Turn "manually chasing people every day" into proactive system reminders

This is the area of the project where efficiency gains are most visible. In the past, operations staff had to open Excel every day to see which creators had reached their deadlines, then chase them one by one.

Now the system automatically judges based on fulfillment status: which creators have received samples, who hasn't completed their work, which tasks are approaching their deadlines, and which have passed system reminders without any action.

The system sends automatic reminders first; if a creator still hasn't fulfilled their obligation, the task is then handed to human operations. This way, people no longer have to dig through several spreadsheets every day for work—the system tells you directly: "Here's what you actually need to handle today." This is also, in my understanding, an important difference between AI implementation and ordinary automation: AI implementation is about reorganizing the way people work.

Step 5: Reconnect the scattered data

We also gradually brought creator outreach, fulfillment, product, and GMV data into a unified business view.

What managers really need to see is: how many new creators were added today, how many were contacted, how many entered fulfillment, how much GMV was generated, how much sample cost was invested in a creator, and how much value they ultimately brought to the company—only then can you truly judge whether a creator is worth a long-term partnership.

So from start to finish, I prefer to understand this project as: AI embedded into the entire business process.

Q4 Compared with the traditional approach, what were the actual results after using AI?

The most direct change was a shortened fulfillment cycle. Previously, from confirming collaboration to the creator receiving samples, completing creation, and submitting the video took about a month on average; after the project's pilot run, the average fulfillment time for collaborating creators is now about 18 days. But to me, this number is not the project's greatest value.

More importantly, the way the entire team works has changed. Previously, operations staff spent a large amount of time finding people, finding products, and finding tasks; now AI screens creators for them first, the system matches products for them first, AI assists creators in completing content creation, the system automatically reminds about fulfillment, and the system proactively surfaces tasks that need human intervention.

As a result, operations staff can spend more time where humans are truly needed: communicating with influencers, building relationships, and handling complex business issues. This change is especially noticeable with high-value influencers. In the past, operations staff may have spent a great deal of energy on searching and screening; now they can focus their energy on the business relationships that truly matter.

Another change is that managers can now truly see the business. Previously, it was hard for a boss to see what happened at every step from establishing contact with an influencer to GMV; now, at the very least, a more complete business view can be formed around "influencer—fulfillment—GMV."

So if I had to summarize the value of this project, I would say: previously the team was managing a pile of spreadsheets; now it is managing a business pipeline.

Q5: Did you encounter new problems or challenges when deploying AI? How did you solve them?

Of course, and I think these problems are precisely the part of the FDE case most worth sharing.

The first challenge was data permissions.

Much of this project's data came from TikTok, and it involved cross-border business, so there were fairly strict requirements around data permissions, user privacy, data retention, and server deployment.

We spent nearly a month on the data alone: data requests would be rejected and resubmitted, permission accounts had to be reconfirmed, server deployment needed to be confirmed, and even whether data could leave the country it was in, and where it should be stored, all had to be clarified in advance.

So if you are doing overseas business, I would especially recommend that FDEs research data compliance and data flows thoroughly in advance. Don't wait until the system is built to discover you can't get the data.

The second challenge was deciding which things should be handed to AI and which should not.

This was a question we discussed repeatedly in this project. For example, influencer matching can be handed to AI, contact lists can be pre-screened by AI, and fulfillment reminders can be automated; but real communication with important influencers we kept human.

The reason is simple: AI can still make some very basic mistakes. In ordinary work, a small error might just mean revising some content, but in business relationships, if the counterpart is an influencer with millions of followers, one wrong sentence could cause losses far exceeding the labor costs saved by automation. That's also why we ultimately did not build "fully automated influencer outreach."

The third challenge was the people inside the enterprise.

When many companies hear "AI," their first reaction is "is this going to replace people?" We were very mindful of this in this project. When driving the project forward, I made a point of positioning AI as "helping everyone solve problems and improve efficiency," so that people understood the system was there to help, not to replace anyone. At the same time, in our interviews we didn't only talk to the boss, because while the boss sets strategy, it's frontline employees who actually use the system.

So I communicated with all levels—top, middle, and frontline: the boss told us the business goals, frontline employees told us where they got stuck day to day, and only by piecing together information from both sides could the system truly land. This is also why I keep emphasizing a core FDE capability: getting the system to genuinely become part of how the enterprise works.

Q6: Based on your experience, how can we better deploy AI into real business?

After doing this project, one very clear takeaway for me is: what's truly hard about being an FDE is often not the models. Many AI capabilities are already quite mature now, and for small and mid-sized enterprises, technology selection is actually less difficult than before. What we focus on more is cost, stability, and ROI (Return on Investment)—using mature frameworks and appropriate models to solve problems, and avoiding pursuing technical sophistication for its own sake.

What's truly hard are the following things.

First, understand the business before talking about AI.

Don't start by asking the client "what AI product do you want to build?" Instead ask: How does your business run? Who runs it? Where is the most time wasted? Where are errors most likely to occur? Which metric most affects business outcomes? Only after clarifying these questions can you know where AI should be applied.

At the start of this project, the client only said they "hoped AI could empower the team," but if we had stopped at that level, we might have ended up just building them a chatbot. Only after truly going into the enterprise did we discover that what was most worth solving were a few specific links in the business pipeline. So the first FDE capability is actually the ability to identify value.

Second, redistribute the work between people and AI.

I increasingly tend to understand AI as a new kind of productivity. It is suited to taking over high-frequency, repetitive tasks with clear rules, but work that relies heavily on trust, relationships, and judgment should still be left to humans. In the end, this project meant BD staff no longer wasted time searching for people and flipping through spreadsheets—AI freed people from low-value work so they could do genuinely high-value things.

Third, an FDE must understand both technical and business language.

I come from a technical background—I wrote code for ten years and later went through different roles in projects and products. I used to make the mistake of thinking that as long as I explained the technology clearly, the client should be able to understand it. But I later found that's not the case.

Many bosses don't have time to understand models, agents, RAG (Retrieval-Augmented Generation), and the like. What they truly care about is: "Can you solve this problem for me?" So what an FDE must do is translate technical language into business language, and translate business problems back into implementable technical solutions.

This is also why I believe that if technical people want to become FDEs, beyond technical ability they must also build skills in business communication, scenario identification, and value articulation.

Fourth, a true FDE takes ongoing responsibility for business outcomes.

I believe one of the biggest differences between FDEs and traditional software outsourcing is whether you take ongoing responsibility for business outcomes. A traditional project might be: requirements come in → build the system → acceptance → delivery; but FDE is more like: enter the business → understand the problem → build

the first version → get the business using it → keep improving based on feedback → find new business problems → iterate again.

This project was exactly like that. After phase one was completed, the client naturally developed phase-two requirements, because once the first problem is solved, the enterprise discovers the next layer of problems. So what an FDE must do is continuously accompany the enterprise in pushing AI capabilities deeper into the business.

Finally, I believe FDEs must go deep into vertical scenarios.

In the future, the technical barriers to AI will keep getting lower, and many basic capabilities will become standard capabilities. What is truly valuable is whether I understand a particular industry well enough—knowing where its problems lie and how AI should enter its business processes.

So our team is also considering that in the future we won't take on every project, but will go deeper into one or two vertical scenarios. Because once you understand an industry well enough, the first time you do that scenario might cost 100%, the second time 80%, the third time 60%. Only by continuously accumulating experience, workflows, skills, and business understanding can you truly build your own moat.

The way I understand it, an FDE is ultimately someone who stands on the business frontline, finds the place where AI can truly create value, and keeps pushing it forward. That's also what I find most valuable about this project: we didn't try to prove that AI can do everything. What we did was, through one real business implementation, redraw the line of "which things go to AI and which things stay with humans." Only when that boundary is drawn correctly does AI truly start to become business productivity.

<a id="no06"></a>

From Experience-Based Loading to Intelligent Planning: FDE Uses AI to Optimize Cross-Border Logistics Loading Efficiency

Q1: As an FDE, what is the specific scenario where you applied AI? What did the specific problems in this scenario look like?

The application scenario of this case is truck loading optimization in China–Russia cross-border trade in the Heihe Free Trade Zone.

Many local companies export electromechanical products to Russia via road transportation. In cross-border logistics, transportation cost is a major concern for companies, and every truck trip out of the country is essentially a fixed cost investment.

Many local companies export electromechanical products to Russia via road transportation. Cross-border shipping fees are charged by cubic meter ("方"), meaning this is essentially a business about "truck compartment volume."

There is a very hard economic line here: a truck of about 110 cubic meters, loaded manually by an experienced loader, usually takes 5 hours and can be filled to 95–98 cubic meters; and 98 cubic meters is the break-even line. More crucially, every cubic meter above the break-even line generates an extra $100 in shipping revenue. So loading rate is not a technical metric—it's a profit switch: below 98 cubic meters you lose money; the fuller the load and the further past the break-even line, the more you earn.

Simply put, a truck pays the same transportation cost no matter how much cargo it carries, including driver costs, fuel costs, border crossing fees, and so on. If a truck is dispatched with only part of its space filled, the remaining space is wasted, but the transportation cost does not go down.

Therefore, for companies, increasing the load per truck and making full use of the cargo space means that the same trip can carry more goods, reducing the logistics cost per item and improving overall profit.

But in actual operations, "filling the truck" is far more complicated than simply stuffing more things into it—it is essentially a complex space optimization problem.

When I first got involved in this project, many people thought it was just a simple bin-packing problem—that you only needed to calculate how to arrange the goods to improve the loading rate. But once I actually went on-site, I found things were far more complicated than expected.

In the past, companies relied mainly on experienced veteran workers to load trucks. Based on cargo dimensions, quantities, and past experience, they would judge: which goods should go where; which spaces could still be used; and how to arrange things to fit more.

But as cross-border trade scaled up, this approach gradually exposed problems.

First, inaccurate judgment of vehicle space.

Much of the vehicle information provided by the Russian side refers to the exterior dimensions of the cargo compartment, but the usable interior space is affected by factors such as wall thickness and insulation layers. The actual usable space is often 5%–8% less than the theoretical figures.

Second, low space utilization.

In the past, there was no standardized 3D planning solution, and loading relied mainly on human experience. With the same batch of goods, different loaders could produce different results, and overall space utilization was typically only around 60%–65%, leaving a large amount of space unused.

Third, in complex scenarios, it is hard for humans to find the optimal solution.

For example, when a company faces different vehicle types, goods of different sizes, and multiple trucks being scheduled for transport simultaneously, it needs to consider multiple factors at once—space, weight, transport efficiency, and more. This already exceeds what human experience can handle.

However, during my research, I found that the most critical problem was actually that even when a solution could be computed, it could not be implemented on-site: being able to compute the optimal solution does not mean it can be executed in the field.

Many algorithmic solutions can tell a company the theoretically optimal arrangement, but when workers on-site actually try to execute it, they run into many problems: Where should loading start? Is the loading sequence reasonable? Does it require working inside the cargo compartment? Does the plan meet on-site safety requirements?

So this problem is essentially a comprehensive one that connects the business front line, algorithmic capability, and execution processes—it goes far beyond algorithm optimization itself.

Solving the technical problem is only the first step; what really needs to be done is to get AI into the business process and generate actual value.

Q2 Before you got involved, how was this problem solved in the past?

Before I got involved, the company relied mainly on experienced loaders for planning, but it took more time.

Typically, loading one truck took 5–6 hours and did not achieve an optimal loading result. Loaders essentially earn their income through physical labor and time, so optimizing this process could improve loading efficiency.

Typically, the veteran workers would rely on accumulated experience to judge: which goods should go on the bottom; which goods could be combined; which spaces could be utilized.

This approach worked when the business scale was small, but as cross-border trade grew, the problems became increasingly apparent.

First, experience cannot be replicated.

An excellent loader's experience takes years to accumulate, and newcomers find it hard to master quickly.

Second, humans cannot solve complex combination problems.

With only a few dozen items, humans can still make judgments. But as vehicle types, cargo varieties, and quantities keep increasing, it becomes very difficult for humans to quickly find the optimal solution.

In addition, there is another easily overlooked problem: in the past, many companies tried digital tools, but the results were not good.

The reason is that these tools usually only solved the computation problem without considering actual execution.

For example, the system would generate a complex 3D plan, but the on-site workers couldn't understand it, and in the end everything went back to human experience.

So the algorithm itself is not hard to obtain; what is truly lacking is a role that connects technology and the front line.

Q3 What was your overall approach and the key steps in using AI to solve this problem?

The starting point of the entire solution process was to first re-understand the business—technical development comes later.

As an FDE, the first step is always to go on-site.

I needed to figure out first: How do the workers actually load? Why do they load that way? Which steps affect efficiency? Which tasks can machines replace? Which things must conform to human habits?

Through on-site observation, I found that the loading process can actually be broken down into several steps: obtaining the truck's true dimensions, organizing cargo information, computing the loading plan, optimizing multi-truck scheduling, generating loading instructions, on-site execution, and result feedback.

Among these, the earlier planning and computation steps are suitable for AI involvement, but in the end it must come back to human execution.

For the solution design, we adopted an approach of "the large model handles orchestration, specialized algorithms handle computation."

Many people mistakenly assume that a large model can directly solve all problems, but in reality, 3D bin packing involves complex spatial computation, which large models are not well suited for.

So our design approach was to let the large model understand human needs and be responsible for calling different tools, while specialized algorithms perform the deterministic computations.

Specifically, the large model is responsible for: understanding the questions raised by business personnel; parsing task requirements; calling the bin-packing algorithm; and explaining the final results.

The actual 3D spatial computation is done by Python algorithms, including height-map-based 3D space tracking, greedy placement,

multi-strategy sorting, and genetic algorithms.

In addition, during actual implementation, we made a very important adjustment.

Initially, we hoped to let workers view the plans through a 3D visualization system.

But after on-site research, we found that workers in a loading environment are not well suited to frequently operating phones or computers.

So in the end, we converted the algorithm's output into a simpler form: a loading instruction sheet that workers can use directly. It includes cargo item numbers, placement orientation, cross-section diagrams, and loading sequence.

Turning the algorithm's output into actions that can actually be executed on-site.

Q4 Compared with the traditional approach, what were the actual results after using AI?

The project has currently completed prototype validation. During testing, we simulated loading on a real transport vehicle measuring 16.4 meters long, 2.47 meters wide, and 2.67 meters high (approximately 108 cubic meters of net interior space), combined with a catalog of 11 different specifications of electric vehicles.

The results show that, without relying on veteran workers, the AI system stably achieved about 99 cubic meters in actual tests, approaching the upper limit of the cargo compartment's capacity. More importantly, it compressed a process that originally required 5 hours of a veteran's experiential judgment and produced variable results into a minute-level, reusable standard plan—turning "every truck stably exceeding the 98-cubic-meter break-even line" from something dependent on people into something dependent on the system.

At the on-site execution level, the value is even more evident: manually loading one truck typically takes about 5 hours; with AI planning and guidance, this is expected to be compressed to about 2 hours, improving loading efficiency by roughly 100%—the number of trucks loaded within the same working hours nearly doubles. After finishing one truck, workers no longer have to wait or burn time; they can immediately move on to loading the next one.

Once this timeline is fully connected, the benefits stack up in three layers: first, workers can load more trucks in the same working hours, directly increasing their per-truck income; second, logistics companies improve overall turnover efficiency and maximize per-truck loading, raising operational efficiency; third, shippers stably exceed the 98-cubic-meter break-even line on every truck and approach the capacity limit—under the billing structure of "+$100 per cubic meter over," every extra cubic meter is real, tangible additional revenue.

So the significance of this project is not about who saves money in a zero-sum game, but about creating incremental value. Compressing 5 hours into 2 hours, the extra truck trips and extra cubic meters are shared among workers, logistics companies, and shippers—a three-way win-win built on the incremental gains.

But for me, the greatest value of this project is not just the loading numbers themselves. More importantly, it validated a replicable way of deploying AI: in the past, much of a company's experience existed only in people's heads; now AI can convert it into data and algorithms, and ultimately into executable plans. Work that only veteran workers could do before can now be replicated through standardized processes.

Q5 During the AI deployment process, did you encounter new problems or challenges? How did you solve them?

The biggest challenges actually came from the business side; technical problems were relatively more controllable.

The first challenge was the gap between the algorithm's output and on-site execution.

Initially, the algorithm prioritized maximizing space utilization. But on-site personnel told me that some plans, while theoretically better, were very difficult to execute in practice—for example, requiring workers to carry goods inside the cargo compartment, or requiring frequent repositioning of items.

So we readjusted the objective, shifting from pursuing the mathematically absolute optimum to finding a balance among efficiency, safety, and ease of operation.

Later, we designed the "cross-section method." Simply put, it means planning the loading sequence from the inside out based on the truck's cross-section. This way, workers only need to stand at the door to operate, without stepping on the cargo to enter the truck.

The second challenge was data acquisition.

The truck's actual interior dimensions are the foundation of calculation accuracy.

Relying on professional scanning equipment would be costly, with limited acceptance among enterprises. So we adopted an iPad Pro LiDAR combined with laser distance measurement, keeping the hardware cost at around 8,500 RMB while ensuring accuracy.

The third challenge was getting frontline staff to accept the new approach.

Technical solutions ultimately need to be used by people. So we kept adjusting the interaction design, converting complex algorithm outputs into simple numbered cards, cross-section diagrams, and printable loading guides.

This is where the value of an FDE lies: delivering the technology is only the starting point; ensuring the technology truly integrates into business processes is what matters.

Q6 Based on your experience, how can we better deploy AI into real business?

From this project, I believe the most important thing for AI implementation is to start from the business problem and the real needs of the multiple groups behind it, treating technology as the means of solving the problem, not the starting point.

When many companies do AI projects, they first think: "Can we plug in a large model?"

But the real question to ask is: "Which problem in the business is most worth solving?"

An FDE first needs business understanding. Only by going into the field can you know what the real problem is.

Often, business people express it as: "We can't fill the truck."

But technical people need to break it down further: Is the spatial data inaccurate? Is the planning inefficient? Is there a problem with the execution process?

Second, you need to be a good translator between technology and business.

Large models are powerful, but they need to be used in the right places. In this case, we had the large model handle understanding and orchestration, while specialized computations were delegated to specialized algorithms, leveraging each one's strengths.

Third, you need to pay attention to the details of implementation.

Whether an AI project ultimately succeeds often depends on these small issues: Are workers willing to use it? Does the process change too much? Is the cost acceptable to the enterprise?

So the FDE's role goes far beyond AI development; its core value lies in connecting business, technology, and users.

Fourth—and something I value more and more in this line of work: AI implementation requires doing the "economic math." Freight charged by cubic meter, 98 cubic meters to break even, an extra 100 USD per cubic meter—these commercial mechanisms directly determine where the value of loading optimization lands. Only an FDE who understands both algorithms and business economics can truly translate technical improvements into cost savings that customers can perceive. This is itself a scarce capability.

Fifth, good AI implementation is not a zero-sum game; it's about creating incremental value. The underlying business logic of this project is that it lets workers, logistics companies, and cargo owners all benefit from the "extra trips, extra cubic meters." Growing the pie is more valuable than fighting for shares of the old pie, and it goes further.

I was fortunate, in a border town like Heihe, to encounter business scenarios as real as they come—cross-border logistics, free trade zones; fortunate to meet a group of partners who don't just talk, and were willing to work with me to move AI out of the screen, into the workshop, to the truck door, into the hands of frontline workers. So I've always believed one thing: the AI that truly matters in the future will grow inside enterprises' real processes, not stay stuck at the demo stage. This is also what being an FDE means most to me—taking AI from the computer into the real world.

<a id="no07"></a>

From Personal Efficiency to Organizational Capability: FDEs Use AI to Drive Enterprise R&D Transformation

Q1 As an FDE, what specific scenarios do you apply AI in? What do the specific problems in this scenario look like?

This case took place at a fund company. It is an enterprise focused on fund investment research, conducting fund management business across different areas such as stocks and automobiles. What we faced was an internal R&D team whose requirements changed very rapidly—very different from the traditional team that spends months on a single large software project.

One of their characteristics was that requirements were extremely fragmented and fast-moving. Internal product managers or business departments might raise several requirements in a single day. For them, the value AI brought was increasing the number of features developers could complete each day from three to ten—quite different from the traditional notion of "a project that used to take a year now takes half a year."

So, before I got involved in this project, they were already using AI, and some people were using it quite deeply. Some used Codex, some used Claude Code, and others used other AI coding tools. The problem was precisely here: everyone knew how to use these tools, but the enterprise found it hard to get everyone to use them together.

Everyone thought their own tool was the best. "I'm efficient with this tool; if you make me switch to another, I actually can't work." Once individual habits matured, if the company wanted to standardize on tools, it would face new resistance.

From management's perspective, what the enterprise needed was clearly not just a few employees becoming individually more efficient. The boss wanted to see the entire R&D team transform, hoping AI could become an organizational capability rather than just personal tools scattered across employees' computers.

So the core problem I faced went beyond "how to teach everyone to use AI coding"—it involved three levels of issues.

First, there was no unified understanding. Everyone was using AI, but there was no shared standard for what AI coding could actually achieve or where their own skill levels stood.

Second, tools and methods were not unified. Different people used different tools with different work habits, and the original R&D collaboration practices hadn't changed with the emergence of AI coding.

Third, new changes were beginning to appear in how the organization operated. After management saw some new R&D philosophies, they wanted to further adjust R&D roles and processes, but there was no ready-made answer for how to actually implement these ideas within their own team.

This is also, in my understanding, the biggest difference between an FDE and ordinary technical training: when facing these problems, you can't just answer "how to use this tool"—you must first determine what the enterprise is really trying to solve.

Q2 Before you got involved, how was this problem handled in the past?

Previously, product managers wrote PRDs the old way, developers built according to the documents, and different roles proceeded with their original division of labor. Later, AI coding tools appeared, and developers began experimenting with various tools on their own. What emerged first was a very natural form of "personal efficiency gains."

When someone found a tool useful, they used it themselves; when someone mastered a new method, they practiced it on their own. There was really no problem at this stage, because individuals only needed to be responsible for their own efficiency.

But when the company wanted to move from "personal efficiency" further toward "team efficiency," the old ways started to show their limits.

For example, everyone used to write PRDs in Feishu documents. Later, as AI coding changed the way of working, much of the content shifted to Markdown, TXT, and other files. One person maintaining one document wasn't much of a problem, but when the whole team started collaborating around these files, new issues immediately arose: how should a dozen or so documents be split up?

What does the product manager write? What does the frontend write? What does the backend write? What are testing and operations each responsible for? If everyone edits the Markdown simultaneously, how do you avoid conflicts? Can the original role boundaries still apply?

None of these are problems you naturally solve just by learning an AI tool.

So I didn't define the old methods as "wrong." Quite the opposite—they were a mature set of methods suited to the original R&D model. It's just that once AI coding changed the way R&D was done, the original processes, documents, and role divisions also needed to be re-adjusted.

This is also a feeling that became increasingly clear to me over time: when AI truly enters an enterprise, what changes is often not just the tools, but the ways of working behind the tools.

Q3 What was your overall approach and the key steps in using AI to solve this problem?

At the very beginning of this project, the client had already decided to adopt Alibaba's related capabilities, but there was actually no particularly clear answer to "what exactly to do after purchasing."

So my first step was to re-examine the requirements before thinking about preparing the course.

I first broke down the needs of the different roles. The boss cared about whether the enterprise-wide transformation could actually happen; developers cared about whether the tools could genuinely improve their own efficiency; product managers cared about how the original R&D process would change; and HR needed to know what could be gained each day during the training.

So although the final deliverable was a five-and-a-half-day in-person training, I designed it from start to finish as a complete enterprise AI transformation practice.

I did several things at the time.

The first thing was to get clear on the boundaries of the problem.

Before officially starting, I had prepared a large amount of material, because at the time I wasn't sure what level everyone was actually at.

But there's a very real problem here: the capability level a company describes about itself often doesn't match its actual on-site capability level.

So later on, I paid more and more attention to one thing: don't fully trust the preliminary research—always try to verify things as much as possible through real hands-on work, rapid prototyping, and on-site conversations.

The second thing was turning the training into a complete business storyline.

Five and a half days and half a day are completely different concepts.

If you're just teaching tools, it might be over in a day. But if you want the company to truly change, you need to design a complete path from start to finish: why the company needs to transform, why R&D staff should use these tools, how the tools should fit into existing processes, how roles change, and how it all eventually settles into the company's own methodology.

So during those five and a half days, I was both teaching and observing; both training and consulting.

Problems discovered on-site would inform my adjustments going forward.

The third thing was customizing for the real R&D process.

This is the part of the whole case that I think best embodies the FDE characteristics.

For example, the original R&D collaboration revolved around a single PRD; now it shifted to collaborating across multiple documents, and the existing division of roles couldn't necessarily be applied directly anymore.

So we began redesigning the Spec documents. At the time, there wasn't actually a particularly mature, unified industry standard to copy, and I didn't know whether what I designed was the optimal solution.

So I didn't throw it at the client as the "standard answer" from the start. Instead, I chose to keep breaking it down, presenting it piece by piece, confirming with the client, and continuing to adjust based on feedback.

In the end, I built a set of Spec documents from 0 to 1. The client initially even thought these were documents already refined internally at Alibaba, but in fact, this set of materials was something I gradually built up during the project based on the client's actual situation.

The fourth thing was continuously adjusting on-site, letting the solution follow real-time feedback.

We did three phases with this fund company.

One of the most important values of the first phase was that it let me truly see what the company's on-site reality looked like. Starting from the second phase, I could keep adjusting based on the experience accumulated in the first phase. In later stages, the client's business staff and product managers gradually came on board too, and the whole project evolved from pure R&D training into a more complete organizational transformation.

This is also a way of working as an FDE that I now endorse: get the whole chain running first, then keep iterating based on real feedback—there's no need to aim for 100 points the first time.

Q4 Compared with traditional methods, what were the actual results of using AI?

The results of this project can't simply be understood as "how much more money the company made after using AI."

This fund company didn't open up complete ROI data that could be disclosed externally. But in terms of organizational change, the results were fairly clear.

In the past, AI was more of an individual capability—everyone had their own methods and tools.

Later, the company began unifying tools, and further unifying R&D collaboration practices. AI was no longer just a question of "whether a particular developer knows how to use it"—it started to enter the team's shared R&D process.

More importantly, we consolidated the Spec documents and related methods developed during the process. They no longer depended on any one person's live demonstrations and could continue to be reused within the company.

Later, in practice with another manufacturing client, some fairly clear short-term data also emerged: after three teams used this Spec Coding methodology and templates, statistics showed that coding time was reduced by about 1/3, documentation time was cut by more than half, and testing time remained roughly the same.

This data came from the client's internal statistics over just a few days, so I consider it genuine feedback, but it shouldn't be understood as a long-term, complete ROI conclusion. A truly valuable effectiveness evaluation requires two weeks, a month, or even longer.

So for me, the most important outcome of this kind of project is completing a shift: from "everyone using AI on their own" to "the company starting to form a shared methodology for using AI."

Q5 During the AI deployment process, did you encounter new problems or challenges? How did you solve them?

The first challenge was that AI is developing too fast, while industry standards haven't caught up.

At the time, everyone was discussing Specs, AI Coding, and R&D organizational transformation, but many methods hadn't yet been validated at scale over a sufficiently long period.

I worried about this myself: what if the methodology I put together doesn't fit the on-site reality? What if it gets rejected by the client as soon as I present it?

My solution was to expose the uncertainty, then reduce risk through small-step validation, without pretending I already knew the answer.

I would do a portion first, then confirm with the client; then continue adjusting based on external information and information available internally at Alibaba. If something was wrong, I'd fix it.

This is actually an important FDE capability in my view: in a field without standard answers, you can't refuse to act just because there's no standard, and you can't assume you must be right just because you're a technical person.

The second challenge was that preliminary research was often inaccurate.

Once, we learned in advance that the client team was quite advanced in using AI Coding, so we prepared a lot of advanced content. But when we actually got on-site, we found they hadn't even solved some basic problems.

So what to do? The only option was to downgrade on the spot and start from the basics.

The reverse is also true. If I had judged in advance that the team's capability was average, but on-site found they were already very proficient, I would bring out the "best material" I had saved in reserve.

So looking back now, I think on-site capability itself is an important part of being an FDE.

The third challenge was that companies often want to make a "heavy investment" right from the start.

For example, buying model all-in-one machines, doing model fine-tuning right away, or forcibly overturning the entire existing workflow. I actually think these approaches are rather risky.

If the business can be quickly validated with lightweight approaches—such as APIs, SaaS, or agents getting things running first—I lean toward validating business value first. Unless the company has explicit compliance, security, or similar requirements, there's no need to make the investment especially heavy from the start.

Investment should go from light to heavy: validate the business value first, then gradually deepen.

Q6 Based on your experience, how can we better deploy AI into actual business?

I increasingly feel that the most common mistake companies make when deploying AI is treating it as a standalone technical project. In reality, when it comes to actual implementation, technology is only one part of it.

First, understand what problem the business actually wants to solve.

Many companies say: "I want to do AI transformation." But this statement alone can't guide implementation. Is it individual efficiency improvement, team efficiency improvement, or R&D process restructuring? Different goals call for completely different solutions.

Second, don't over-rely on preliminary research—build prototypes quickly and run the real process.

Because AI proficiency is hard to accurately assess through questionnaires, I now prefer to build prototypes quickly and run through the real process quickly. Even if the first attempt only scores 70 or 80 out of 100, it's more valuable than sitting there discussing the plan until it's 100 before starting.

Because once things are actually running, the background, pain points, solutions, and constraints all become clearer. Optimizing on the second pass gives you a chance to go from 70–80 points to 80–90 points.

Third, accept that AI implementation is a continuous iterative process.

Especially in fields where AI is developing extremely fast, no one can guarantee that the solution they design the first time is the best one.

Rather than trying to solve all problems in one go, it's better to get the first round running, then keep correcting.

Finally—and this is what I consider the most important thing about being an FDE: don't look at problems only from the technical person's own perspective. An FDE needs to understand technology, business, and the client simultaneously.

When talking to the boss, the boss cares about organizational efficiency and return on investment; when talking to R&D staff, they care about whether the tools are easy to use; when talking to product managers, they care about how the R&D process will change; when talking to HR, procurement, or operations, it's a completely different discourse system again.

So I think an FDE is more like a "translator": converting standardized AI capabilities into something that a specific company and a specific team can truly use.

I summarize the value of an FDE in one sentence: translating AI's capabilities into working methods that the company can truly use, run, and consolidate matters more than simply bringing an AI tool into the company.

<a id="no08"></a>

From Hard-to-Find Materials to Precise Positioning: How an FDE Uses AI to Reduce Procurement Waste in Industrial Companies

Q1 As an FDE, what is the specific scenario where you apply AI? What do the specific problems you encounter in this scenario look like?

The client in this case came from overseas. To be honest, before our first visit to the client's site, we didn't know what we would end up doing. Although there had been several rounds of communication beforehand, at that point there was no preset answer—whether the client needed a large language model, an AI agent, or some other AI capability, nobody was sure.

So we didn't go in with a ready-made product. Instead, we first did something that seemed very "slow": interviews. The initial mapping of the client's entire business took a long time. We talked with different departments, understood the organizational structure and business processes, and observed how different business staff felt about AI. After we truly entered this specific case, we then conducted in-depth interviews lasting several months with the ERP team and its upstream and downstream teams.

This company operates in an industrial setting and needs to manage a large number of machines, equipment, materials, and assets. From a pair of gloves, a screw, or a pair of earplugs, to a truck or a robotic arm, everything needs to be entered into the ERP database. Around 15 teams interact with this database—some are responsible for data entry, some for procurement, some for contracts, and some for warehousing.

We interviewed these teams one by one and discovered a very interesting phenomenon: almost every department was complaining about the same thing—ERP is hard to use. But "ERP is hard to use" is not yet a problem that can be handed directly to engineers. So we kept probing: exactly what is hard to use, how do you operate it day to day, at which step does the problem occur?

Sometimes I would sit right next to a business user and watch how they actually work. Because many problems simply cannot be surfaced if you only ask about them in a meeting room. After the interviews ended, we continued to research and break things down on our own, doing root-cause diagnosis.

Through this process, we eventually identified about 15 functional points that could be addressed further, two of which were very typical. The first was dirty data. The second was very weak search capability.

The client was using a fairly old piece of industrial software. Today, people are accustomed to the search experience of Taobao, JD.com, or Amazon—type in what you're looking for and naturally get results. But in this industrial ERP, search was not that smooth.

Business users often ran into this situation: "I know this part is in the database—I used it last time—but I just can't find it now." That sentence later became a crucial entry point for our understanding of the whole problem.

Because "can't find it" itself is not the final business loss; the real problem happens afterward. When an employee can't find a certain material, they may assume it's not in the database and re-enter a new record—even though the material already exists. This creates a loop: can't find the material → re-enter it → duplicate data appears → data gets dirtier → it becomes even harder to find the right material → buying the wrong item, buying duplicates, or getting the units wrong.

When it reaches industrial procurement, real money is at stake. If a consumer buys the wrong thing, they can get a refund. Industrial procurement often can't do that—once something is bought by mistake, it usually won't be returned; you can only buy the correct one as well. The wrongly purchased items stay in the warehouse, sometimes for years.

A warehouse can't store things indefinitely. Years later, when clearing out inventory, these items are found to have sat unused for a long time and can only be disposed of according to the rules. The money the enterprise truly loses is hidden right here.

So we later defined the real problem to be solved as: whether we could reduce erroneous and duplicate purchases that should never have happened in the first place, by improving data quality and material search capability.

Once this problem was clearly defined, the value of AI also shifted from "making the system smarter" to a problem that could genuinely affect the company's business outcomes.

Q2 Before you got involved, how was this problem solved in the past?

The client's ERP had long carried the company's inventory management processes, and each team had developed its own way of working around it. Data entry, procurement, contracts, warehousing—each step had clear responsibilities, and the company had always run on this set of processes.

The problem was that as data kept accumulating, the limitations of the original system became increasingly apparent. Industrial material data in particular is very complex. The same item may exist under different names, different descriptions, different units, or different data-entry habits. And since the system's search relied mainly on traditional fields and keywords, business users found it hard to quickly confirm whether the material they wanted actually existed in the database.

In the past, when encountering this situation, business users relied on experience. If they knew the code, they could search by code; if they knew the exact name, they could search by name; and if they really couldn't find it, they would re-enter it following the original process.

When the data volume wasn't that large and the business chains weren't that complex, this approach worked. But as historical data piled up, relying on experience as a fallback became increasingly strained, and the same process began to fail.

So this can't be blamed on frontline employees—the first thing that couldn't hold up was that search system. The company had actually put its processes into the ERP long ago; the digitalization step was taken long ago. What was truly stuck was that the system's keyword retrieval and field matching couldn't handle the many names, descriptions, and units of industrial materials, so the digital tool itself became the new bottleneck.

At this point, simply asking employees to enter data more carefully and search more thoroughly would not solve the problem at its root. So we concluded that AI should step in here.

Q3 What was your overall approach and the key steps in using AI to solve this problem?

If you only look at the final features, this case is not "sexy" at all. It boils down to two things: cleaning and standardizing the existing data, and adding semantic search capability. Some might even say, isn't this just RAG or smart search?

I think saying that is technically fine, but if you stop there, you miss the most important part of this case. Because the truly difficult things have always been "why semantic search needed to be done, and what business outcomes it actually changed afterward." Our whole process went through roughly several stages.

Step one: go on-site and start with problem discovery.

We spent months communicating with the business departments, focusing on their actual work processes and listening to what they hoped AI could help with. Business users will tell you a lot of needs, but an FDE can't simply turn a list of requests into a list of features. We needed to keep judging: does this problem really exist, where is the root cause, can AI solve it, and how much business value would solving it create?

It was through this process that we gradually broke "ERP is hard to use" down into specific problems, and further identified data quality and search as the two issues worth prioritizing.

Step two: put the problem back into the complete business chain.

This is where I think an FDE differs greatly from simply building AI features. We didn't stop at "search is bad, so let's build a better search." We kept digging deeper into why bad search leads to business losses. Only then did we arrive at this chain: difficult search → duplicate data entry → data pollution → erroneous/duplicate purchases → inventory buildup → eventual disposal → real financial losses. Only when this chain holds do we know how much this AI application is actually worth.

Step three: determine priorities together with all stakeholders.

This case involved more than a dozen departments, so it was impossible for the FDE to decide on its own what to do first. We organized the diagnosed functional points into a list, then brought together the heads and representatives of the different business departments to confirm, item by item, what problem each feature solved, whether it was a genuine business need, and which should come first and which later—and we also had the business departments vote.

At the same time, within the FDE team, we evaluated each use case along seven or eight dimensions, such as whether the data was accessible, whether processed data could be written back to the business systems, whether AI could actually solve it, how technically difficult it was, and whether business users would ultimately be willing to adopt it.

Because a feature being technically feasible doesn't mean it can actually land. Sometimes the data simply doesn't exist; sometimes the legacy system doesn't allow you to write results back; sometimes it's technically achievable, but the business department doesn't want its system touched; and sometimes business users simply don't trust the AI's output. All of these issues need to be figured out as much as possible before you actually start building.

Step four: define the division of technical labor clearly, and let AI do only what it should.

We didn't stuff everything into the large language model. Semantic search was responsible for understanding the meaning behind the business user's statement of "what I'm looking for" and matching different names for the same material; data cleaning and standardization were responsible for handling duplicates and inconsistencies in the historical data before retrieval, giving semantic search a clean foundation. Whether to purchase, and how much, was still decided by the business users.

Step five: start with scenarios that can prove value quickly, and allow iteration along the way.

I don't recommend starting with the hardest, coolest things. If a project goes on for months without results, the customer's patience and confidence will drop quickly. We prefer to first find scenarios where results come easily—ideally within a few weeks, or even around two weeks, so the business department can see an initial result.

Once business people see that "this thing actually works," confidence is established, and they become more willing to actively participate in subsequent actions. And this path is never perfectly straight.

There are often setbacks along the way. Sometimes halfway through, we find the problem was defined incorrectly, and we go back to the problem-discovery step; sometimes we find the scope is too broad, and we pull it back in. What an FDE really does is continuously validate the relationship among "problem, solution, and business value," so that every step builds on the validated results of the previous step.

In the end, we made it easier for business people to find materials that already existed. The purpose was to reduce duplicate data entry at the source, and further reduce erroneous purchases and duplicate purchases—search was only the means.

Q4: Compared to traditional methods, what were the actual results of using AI?

Our method for measuring results is actually very clear. In the end, what matters is whether the customer bought fewer wrong things and made fewer duplicate purchases. Model accuracy and how much faster employees feel the search is are only process metrics; the real business result is whether purchasing behavior changed.

Before this project, the customer actually knew that erroneous purchases and inventory waste existed, but the problem wasn't visible to them. No one had actually pulled the records from the historical database and carefully analyzed how much loss these errors caused each year. So part of our work was turning a previously invisible problem into a quantifiable one.

We establish a baseline from historical data, then gradually expand the scope through small-scale experiments. At each stage we validate several questions: Has AI reduced duplicate data? Has the cleanliness of the database improved? Have erroneous purchases caused by data problems declined? And ultimately, has the corresponding purchasing waste been avoided?

More importantly, this value cannot be declared by us alone. In the end, we need to arrive at the result through rigorous calculation, and the calculated business value also needs to be confirmed by the customer's own business people. Only when the customer says, "Yes, this money really was saved because of this application," do we consider the value truly established.

So compared to the past, the biggest change in this case was transforming a situation where "everyone knew there was a problem, but no one knew how much the problem was worth" into a business problem that could be discovered, intervened in, and continuously measured. That, as I understand it, is the biggest difference between AI implementation and AI demos.

Q5: Did you encounter new problems or challenges during AI deployment? How did you solve them?

What was truly difficult about this project mostly wasn't the model itself.

The first challenge: finding the real problem takes a long time.

We spent months understanding an ERP business process that seemed to have little to do with AI. For many engineers, this may be the hardest part to accept—people are more used to customers giving requirements and themselves writing code. But FDEs are different: often the customers themselves don't know where the problem truly worth solving with AI lies. You have to sit down and understand how procurement is done, how warehousing works, how data is entered, and how different departments collaborate. Without doing this "dirty work," the AI that follows may well just be doing a more beautiful job on the wrong problem.

Diagnosis needs to be deep, yet customers expect value quickly. If a lot of time has already been spent on business analysis, and then months pass after implementation begins with no results to show, the organization can easily lose patience. So we deliberately start with scenarios where value is easy to prove—first let the business department see that it works, then gradually expand.

The second challenge: cross-department coordination is hard.

This case involved more than a dozen teams, each with different responsibilities and different demands. Some AI applications even change the existing workflows between departments, so conflicts can naturally arise—and many of these conflicts won't be voiced directly in meetings. So we hold multiple rounds of discussions: not only large meetings, but also one-on-one communication with different stakeholders in advance, defusing these unspoken concerns ahead of time.

The third challenge: technically feasible, but hard to implement.

For example: Can the data be extracted? Will the legacy ERP let us write the processed data back? Will the business department allow us to touch existing systems? Will end users trust the AI's results? If any one of these problems can't be solved, the use case may fail. So before formal construction, we score different scenarios across multiple dimensions—whether AI can implement it is only one of them.

After going live, the work is likewise not over. The project must ultimately be handed over to the business department, who decide whether to truly adopt it. After launch, we keep monitoring: after running for a while, are the results still there? Compared with the goals defined at project kickoff, have things changed? If performance has declined, what's the reason, and does it need further optimization?

An FDE cannot be "finish the thing, get paid, and leave." If the business department ultimately doesn't use it, or the results disappear after three months, the application cannot be considered truly deployed. The whole delivery therefore repeatedly loops back to problem diagnosis, scope selection, and validation—it's hard to go in a straight line from start to finish.

Q6: Based on your experience, how can we better deploy AI into actual business?

After finishing this case, I'm even more convinced that an FDE's most important capability is finding the problem truly worth solving; quickly building an AI application actually comes second. I would summarize it into a few principles.

First, don't go looking for problems with AI in hand; first go into the business field to find problems.

Many people approach AI applications by holding an agent, a RAG, or a workflow product, and then asking the customer, "Do you have any scenarios where this could be used?" This easily becomes looking for nails while holding a hammer. We prefer the reverse.

First engage with the customer over the long term, understand the business, do problem discovery, and then judge whether the problem should be solved with generative AI, traditional machine learning, or no AI at all. AI technology is only a means.

Second, don't stop at the surface-level needs users raise; keep digging down to the root cause.

When business people say "the ERP is hard to use," that's not a problem definition. When they say "search doesn't work well," that's not either. Keep digging, and you'll find that "search doesn't work well," traced all the way down, ultimately lands on real financial losses.

An FDE needs to keep asking: why, and then what, and what did this ultimately affect—until finding a root cause that can be connected to business outcomes.

Third, prioritize use cases that can prove value.

Whether an AI scenario is worth doing, I consider simultaneously: the difficulty of data acquisition, the difficulty of system integration, AI feasibility, business complexity, user acceptance, and potential value. The coolest ones often get set aside for later. Especially at the beginning, choose scenarios that can produce results quickly, because early results are not only technical validation but also the process of building organizational confidence.

Fourth, define the ROI at the start of the project.

Many AI projects only start asking after launch, "How much value did this actually create?"—and by then it's often too late.

We ask clearly from the very beginning: if this problem is solved, how much loss can the company reduce in a year? How is that number calculated? Where does the data come from? And who confirms it in the end? That way, at the end of the project, we prove ourselves with business results the customer recognizes; model metrics are only a process reference.

Fifth, what should be standardized first is the methodology; the product can wait.

I'm not against standardized products, but at this stage AI technology is changing too fast. If you start out thinking about turning a certain feature into a standard product and then take it to find the next batch of customers, you can easily fall back into the old rut.

By contrast, I value reusable methodology more: how to do problem discovery, how to do root cause analysis, how to judge use cases, how to define ROI, how to run small-scale experiments, how to validate together with the business department, how to measure continuously.

These things are worth consolidating more than any specific AI feature. Because the next customer's ERP may be completely different, and the business processes may be completely different too—but the way of thinking about solving problems is reusable.

So if I had to summarize this case in one sentence, I would say: an FDE's real work is to first go deep into the business and restore a vague complaint into a problem that can be solved, validated, and quantified in value, and only then decide where AI should appear.

What was ultimately deployed in this case was data cleansing and semantic search, but what truly created value was that we spent enough time tracing "why a material can't be found" all the way to "why the company wastes procurement budget because of it."

Only after this chain was found did AI truly transform from a technical capability into business value.

<a id="no09"></a>

From "Cousins and Aunts" to Intelligent Execution: How an FDE Uses AI to Restructure Financial Process Efficiency in State-Owned Enterprises

Q1: As an FDE, what specific scenario did you apply AI to? What did the specific problems in that scenario look like?

What I built was an AI application for financial processes at a research institution under a central state-owned enterprise.

This scenario is actually very typical. Financial work at central and state-owned enterprises involves a huge number of rules and processes, and much of the business goes far beyond the scope of "scan an invoice and you're done."

For example, an employee comes back from a business trip and needs to reimburse an invoice. In the past, he would first submit the reimbursement, and then a finance staff member would determine the nature of the expense—was it travel expenses, entertainment expenses, or something else? If it involved a project, they would also need to determine which project it should be booked under. At the same time, they would have to track down the person's travel application, approval records, department, and other information.

This information is actually scattered across different business processes. What really takes time is the judgment process before filling out the forms.

Moreover, the financial account structure at central and state-owned enterprises is inherently complex, with many rules and deep hierarchies. On top of that, the payment recipient may not just be an employee—it could be a supplier, or involve deposits and various other external financial flows. So as business volume grows, finance staff spend a huge amount of time on repetitive judgment and data entry.

For a research-oriented central enterprise, this problem has an extra layer. Many of the enterprises we serve have large numbers of researchers, even PhDs, whose time should really be devoted to research work, but instead large amounts of it are consumed by reimbursement processes.

So when I looked at this problem, what I saw was a very obvious value mismatch: having high-value people do low-value, repetitive process work is itself a waste.

This is also something I pay particular attention to as an FDE. I first look at: where does this business hurt the most? Which parts are truly worth changing? Once I've thought that through, I then go back and match the corresponding capabilities to solve it.

Q2: Before you got involved, how was this problem solved in the past?

The old way of doing things actually worked perfectly well.

Finance staff had their own professional experience and mature business rules. They knew which account an expense should be booked to, which business needed to be linked to which approval information, and how to fill out the group's systems. When business scale and complexity weren't so high, it was a reliable approach.

The problem is that many things had to depend on manual labor.

Someone had to make judgments up front. For example, when an invoice came in, the finance staff member needed to combine the employee's travel application, department, project, and other information to determine how the money should be recorded.

Someone also had to execute afterward. After the judgment was made, the finance staff member still needed to open the group's website, create a document, fill in the information line by line, and then submit it.

So the whole process actually involved two obvious time sinks: judgment time and execution time.

In the past, relying on professionals to do this wasn't a problem, but as business volume grew, this approach was hard to scale linearly. If business volume doubled, you'd need to double the number of finance staff—that path is hard to sustain.

So what we really needed to solve was freeing finance staff from large amounts of repetitive judgment and operations, letting machines take on the things that machines are better suited to do.

Q3: What was your overall approach and the key steps in using AI to solve this problem?

When I work on projects like this, I have an important habit: go directly to the business site and shadow the work.

You can't expect business people to explain their entire business logic to you completely. Often, after doing the same job for a decade or more, many of their judgments have become second nature. So we work alongside the business people, watching how they actually handle a transaction each day, and then break the whole process down piece by piece. That's how this project was done too.

Step one: truly map out the business logic.

Take employee reimbursement as an example. The employee no longer needs to care about the complex process behind it—they just tell the bot in DingTalk "I want to submit a reimbursement" and send over the invoice. From that point on, the rest of the process is handed to AI.

The AI first recognizes the invoice, then links it to the employee's existing business information—for example, whether this person previously submitted a travel application, what the approval comments were, which department they belong to, and which project they're assigned to. Once this information is pulled together, the AI then applies financial rules to make a judgment: which account should this expense be booked to, which project, and under what rules should it be processed.

An important change happens here: in the past, a person would go into the system to find information and make judgments; now, the AI proactively organizes the information and then assists in completing the judgment.

Step two: let AI handle the "judgment," with a supervision mechanism as a safety net.

Finance is serious business. No matter how well the AI judges, you can't simply interpret it as "whatever the AI says goes." So we designed a supervision mechanism into the system—you can think of it as several AI roles working together: one handles the judgment, one supervises, and one detects risks.

For business that is already fairly certain, it proceeds directly; if uncertainty remains after several models have judged, it enters risk monitoring and gets special attention from the relevant personnel.

This changes the role of people too. In the past, people handled everything and machines weren't involved; now, AI handles most of the deterministic work, and people only handle the risks and anomalies that truly need attention.

Step three: let RPA be the actual "hands."

AI solves "what should be done," but there's still another question: who actually completes the action? So we brought in RPA.

After the AI finishes its judgment, the RPA bot starts executing. It can automatically open a browser, go to the corresponding group website, create the document, fill in the relevant information, and submit it.

So this solution actually breaks the whole process into several parts: business information retrieval → AI judgment → AI supervision → risk identification → RPA execution.

This is also, in my understanding, the biggest difference between an FDE and someone who just builds technical solutions: we think about how to truly embed AI into the existing business process.

Step four: start with an "icebreaker project," then gradually expand the scope.

This is something I value highly in project implementation. I usually call the first project the "icebreaker project."

Why? Because when a company encounters AI for the first time, it usually needs to see real value before it's willing to invest significant resources—especially for central and state-owned enterprises, where data security, infrastructure, and budget issues also come into play later.

So I first look for the scenario that is closest to the business, hurts the most, and generates ROI most easily. It's like picking peaches: pick the one closest to you and sweetest first.

Let the business people actually use it once and discover that AI really can save them a lot of time. Only after the business team has tasted the benefits themselves will they be willing to stand with you and take on bigger things.

Q4: Compared to the traditional approach, what were the actual results after using AI?

The most visible change is time.

In the past, handling these financial scenarios could take staff half a month, or even a month. Now, with AI plus RPA running a complete process, it can be done in about one or two days.

And this covers more than just one reimbursement scenario. In this project, we ultimately deployed 10 AI-related application scenarios, gradually covering different parts of the finance function.

But I think what makes this project truly valuable is that it changed the way people work.

In the past, researchers might have had to participate in many processes unrelated to research itself. Now, they just hand the invoice to the bot in DingTalk, and everything else—information linking, rule-based judgment, system entry—is hidden in the background. The human's actions are compressed into a very short step.

For the enterprise, the value AI brings also goes far beyond saving a few staff members. It is actually transforming a process that relied on extensive manual experience and repetitive operations into a business capability that can run continuously.

Q5: During the AI deployment, did you encounter new problems or challenges? How did you solve them?

One of my deepest takeaways from this project is: the hardest part of an AI project is often outside the technology.

In the AI era, I'd even say that if a project can be implemented purely from a technical standpoint, it's already 80% successful. What really kills projects is the business, the people, and the organization.

The first challenge is the business department's acceptance and pace of adoption.

The AI program itself doesn't create value—it's the business departments that create value. For example, AI saves them time, but the ones who ultimately enjoy that efficiency gain are the business staff, so we have to find ways to get the business departments to stand with us.

I'm particularly opposed to one approach: letting the AI project team sit there and design something on their own, then having the business departments come over to use it. Business staff are already busy every day, and if you suddenly add a new system and a new process to their workload, their first reaction is likely to be "Why are you adding another burden to me?" That's why our approach is business shadowing: I spend a few days working alongside the business staff, observing their real workflows, and proactively mapping out the business logic, so that the business staff don't have to compile a particularly complete requirements document and hand it to us.

Similarly, you can't make drastic changes to processes on a first collaboration. If I tell the business department, "Forget your entire existing process—we'll design a brand-new AI process," the project will most likely face resistance, because business staff already have their own work habits, and the existing process exists for its own reasons.

So I prefer to start from a very small, very painful scenario, get one point done well first, and let the business staff see real ROI. Once they discover that this thing genuinely saves them time, they'll start proactively discussing with you, "Could we do this part too?" At that point, the AI project shifts from "you have to make me use it" to "I hope you'll keep helping me build it."

The second challenge is data security and infrastructure.

State-owned and central enterprises, especially research institutions, have extremely high requirements for data security. Much financial data is sensitive and can't simply be thrown into public models for processing, so we have to solve the problem starting from the underlying infrastructure, including compute, model deployment, and the data environment.

I've previously helped an enterprise procure a large all-in-one AI compute appliance, with an investment on the order of over two million yuan, giving the enterprise the foundational environment to run large models. For sensitive financial data, a private deployment approach that keeps data within its domain is also required.

But here a very practical problem arises: if you tell the client right away, "Let's first spend two to three million yuan on a machine," they'll very likely ask, "Why? I haven't seen what value AI can bring me yet." So this circles back to the earlier logic: first prove value with a small scenario, then push forward infrastructure construction—not the other way around.

The third challenge is that different scenarios can't be forced to use the same model.

When I design solutions, I don't insist on any single model provider either. Financial scenarios demand rigor, research scenarios may require professional computing capabilities, and some content generation scenarios call for more openness. So my principle is to choose capabilities based on the scenario:

Some scenarios may use Alibaba Cloud's models, some use models from other vendors, and some state-owned and central enterprise scenarios use local private deployments.

I think of this approach as "teaching according to the student's aptitude": first determine what the business needs, then assemble the underlying capabilities accordingly.

Q6 Based on your experience, how can we better deploy AI into real business operations?

After working on these projects, I increasingly feel that the real value of an FDE lies in whether they can truly connect technology, business, and the organization—and that matters more than "how much AI technology you know." If I were to summarize, I would especially emphasize several points.

First, enter the business before entering the technology.

One of the most important actions for an FDE is business shadowing. Don't sit in a meeting room waiting for business staff to tell you their requirements; what you really need to do is follow them as they work and see how they actually do things. Many business rules are hard for the business staff themselves to explain clearly in one go, but if you follow them through the work once, you'll discover a huge amount of judgment and experience hidden in the process.

Second, pick the "nearest, sweetest" peach first.

Don't start with a grand AI transformation project—find a small scenario first. Ideally, that scenario satisfies three conditions at once: the business genuinely hurts there, implementation is relatively manageable, and ROI can be seen quickly.

Make the first project an "icebreaker project," so the business department gets results, receives recognition, and even becomes a benchmark within the group. Once you have that benchmark, securing resources, budget, and organizational support later becomes much easier.

Third, truly bind the business side to the outcome.

AI projects need to break out of the positioning of "the tech team's own project." If, in the end, all that happens is the AI team saying "we built the system," it's meaningless. What should really be asked is: Did the business save time? Did per-person efficiency improve? Did business outcomes change?

So I look for ways to have the business team share responsibility for the outcome with us, and when conditions allow, even tie the AI transformation to the business department's KPIs and OKRs, so the business department itself has the motivation to push the project forward.

Fourth, an FDE needs to jump from "technical implementation" to "business outcomes."

I used to be an architect myself, but over time I've come to feel that in the AI era you can't stay stuck at "how do we implement this technology." Much of the underlying implementation work will very likely be done by AI itself in the future.

What really requires humans is: Why am I doing this? How should this problem be defined? What value does it bring to the enterprise? How do I design an architecture that can support the enterprise for the next 3 to 5 years? How do I actually drive the project to implementation?

So I believe a mature FDE must possess, at minimum, communication skills, architectural thinking, and project management thinking all at once.

Fifth, proactively "break out of your circle" and "reach higher."

I personally value two phrases: breaking out of your circle and reaching higher.

Breaking out of your circle means going out to talk with company CEOs, business leaders, and people from different industries. What they truly care about is:

Can revenue increase? Can costs come down? Can organizational management become more transparent? Can business control improve?

Reaching higher means proactively engaging with people whose understanding is a level above yours, and learning how they see problems. Once your own understanding changes, the way you solve problems changes too.

Finally, I want to say that FDE itself is an "intermediate state."

I increasingly understand the FDE role as an "intermediate state": at first, one person may do everything, surviving by solving different customers' problems; gradually, you discover which industry and which scenario you truly have an advantage in, and you begin to focus; when you can independently understand the business, design the architecture, and drive projects to implementation, you become an FDE in that field.

But if you stay at "I personally deliver every project," your personal bandwidth is limited. The next step is to consolidate the delivery experience, business methods, and SOPs you've accumulated, so more people can deliver following this methodology; and after that, distill the recurring common problems into standard products.

From individual capability, to team capability, to replicable product capability—that is the process by which FDE capability is truly amplified.

So if I were to redefine this finance case, it actually goes beyond the scope of an "AI + finance" project—it's more like a complete FDE practice: first enter the business scene and find the real pain points; then break down the business processes and place AI where judgment is genuinely needed; let RPA execute the repetitive actions; use oversight mechanisms to control risk; and finally prove value through one small scenario, then gradually expand AI's application across the enterprise.

This is also my understanding of what an FDE is: truly taking responsibility for a business problem, until the technology becomes a business outcome.

<a id="no10"></a>

From Manual Reconciliation to Intelligent Account Matching: How an FDE Uses AI to Make Offline Retail Reconciliation Fast and Accurate

Q1 As an FDE, what is the specific scenario where you apply AI? What did the specific problems in this scenario look like?

I've always felt that where an FDE is truly valuable is in finding a problem that is close enough to the enterprise's business goals. Whether you can use AI to build something is secondary.

This case is exactly that. The client is a consumer goods company focused primarily on offline retail, with annual revenue in the billions of yuan, and stores mainly located in department stores and commercial complexes. Its funds settlement chain is rather special: the store's own POS system generates one set of data, the mall has another set of settlement data, and ultimately funds are settled to the company through the mall, so for every settlement cycle, the data and documents from both sides need to be re-verified against each other.

When the client first came to us, what they raised was actually a very plain problem: reconciliation takes too much manual effort.

This sounds very standard—almost "not worth using AI." But I later found that it's precisely this kind of thing that deserves a close look.

In the past, store clerks or store managers had to take paper documents, or scans/images converted from documents, pull data out of different systems, and verify it item by item. The whole process was basically done manually, by eye. If a discrepancy was found, both sides had to re-verify, and after corrections, new discrepancies might appear again, leading to endless back-and-forth. A single cycle could take one or two person-days.

Behind this, there are actually three layers of problems.

The first layer is a business problem. Incomplete reconciliation means that some money that should have been collected may have been missed.

The second layer is a process problem. The people who actually do this work are usually store clerks or store managers, who are also carrying sales targets. The more time reconciliation takes, the less time they can devote to sales and store operations.

The third layer is an information problem. The data on both sides is not naturally connected, and paper documents add the cost of manual verification, so people have to keep cross-checking between different pieces of information.

What really made me feel this problem was worth doing was what we later discovered: beyond saving labor, it could also directly affect revenue.

In the past, headquarters would even set a "tolerance range" for stores, because everyone knew manual reconciliation was too much of a hassle—if the discrepancy was within a certain percentage, they simply stopped chasing it. But now, if a machine can surface those discrepancies, the money that was previously overlooked has a chance to be identified again. The value shifts from "saving a few person-days" to tangible revenue gains.

So from an FDE's perspective, what I ultimately prioritized was the scenario where business value is easiest to validate, and pushed "the coolest AI scenarios" to the back.

Q2: Before you got involved, how was this problem solved in the past?

The original solution logic was very straightforward: pull data from multiple systems, look at totals, look at line items, and investigate the causes of discrepancies.

For a single store or a small number of stores, a person could fully handle it.

But the problem is that as the business scales up, the marginal cost of the manual approach keeps rising.

One store might tolerate one or two hours, or even a full day, of verification, but once the number of stores grows, the same work has to be repeated every cycle. What's worse, beyond being "slow," the manual process creates continuous rework: find a discrepancy, re-confirm, revise, verify again; and if employees feel certain discrepancies aren't worth chasing, they may simply give up.

So the old method itself wasn't wrong—the problem was that business complexity exceeded what a manual approach could handle.

This is also why I increasingly feel that when FDEs deploy AI, they can't start by saying "the old process is too outdated, let's replace it with AI." The real questions to ask are: why did the old way work in the first place? At what point did it start losing efficiency? Which part exactly should AI take over?

In this case, we didn't try to make the entire reconciliation process AI-driven. Instead, we first took over the most standardized, most repetitive round of verification—the one best suited to automation—freeing people from a large amount of mechanical comparison work.

That's also why employees ultimately had a fairly high level of acceptance of this solution. From their perspective, it felt more like "someone has already done the first round of reconciliation for me; I just need to review the results and handle the real discrepancies," and it was rarely seen as "yet another system I have to relearn."

Q3: What was your overall approach and the key steps in using AI to solve this problem?

What I found truly valuable in this case was how we selected the problem and controlled the delivery scope—OCR or vision itself actually came second.

Step one was prioritizing among the multiple needs the client raised.

The client didn't just have the reconciliation need at the time; they also proposed directions like automated customer service and competitor comparison.

Purely from the standpoint of "what can AI do," all of these were feasible. But from an FDE's perspective, I would first ask: which one can generate positive business feedback the fastest?

Customer service involves both efficiency and new business opportunities, and requires a fairly long data cycle to prove how much new business was actually generated; competitor analysis involves various downstream operational strategies, and the final business results are hard to validate in a short time.

By comparison, the value of reconciliation is very direct: how much labor is saved can be seen quickly, and how much money is no longer missed can be calculated directly.

So the first judgment was focused on which task was most likely to produce positive feedback fastest; whether the technology was the most cutting-edge was secondary.

Step two was putting AI where it truly fits.

We ultimately used OCR plus vision to recognize and compare paper/image documents and related information, then ran it on a scheduled cycle through an automated workflow. Simply put, AI handles the bulk of the repetitive first-round verification, filters out the results that can already be confirmed, and leaves people to handle the parts that genuinely require judgment.

There was nothing particularly "flashy" about this solution technically.

But I actually think that's typical: what an FDE needs to do is find a solution that is simple enough, cheap enough, and genuinely solves the business problem—not necessarily the most complex technology.

Step three was designing for scale from the very beginning, not stopping at a demo.

At the time we only deployed to a few stores in Shanghai—single digits. But the client's overall store footprint was fairly large, so I had already considered future expansion when designing the solution.

A few stores running once per cycle versus hundreds or thousands of stores running simultaneously within a similar time window place completely different demands on system stability and redundancy when AI makes errors.

So from the start we split it into two phases.

Phase one was kept as lightweight as possible—it could even be done with Cherry Studio plus a local computer; in phase two, if it truly scaled to a much larger size, more capabilities would be needed on the backend data and redundancy side.

This is something I value: lightweight doesn't mean no planning. You can validate value at minimal cost first, but from day one you should already know what the next step is if validation succeeds.

Step four was avoiding adding extra burden on frontline employees as much as possible.

This is something technical teams easily overlook. With a new AI tool, if employees have to enter extra data, relearn processes, or add steps to their workflow, the first thing they see is "now I have one more thing to do."

So we tried to embed AI into the existing process rather than making employees build a new one. In the end, what employees received were results that had already gone through the first round of processing—they didn't need to maintain a system of their own.

I think this is an important detail when AI is truly deployed: don't make users see their own investment first and wait for future gains; let them feel the benefit right away.

Q4: Compared with the traditional approach, what were the actual results after using AI?

The most direct change was that time went from "person-days" to "hours."

In the past, a cycle might take one or two person-days, or even stretch longer due to repeated verification. Now the whole process is compressed to a few hours, and employees only handle the parts that genuinely require human judgment.

But if you summarize it merely as "saving labor," I think that underestimates the project.

What really surprised me was that AI exposed problems that had been masked by the manual process. In the actual data, some stores had discrepancies of one or two percentage points, and some reached two or three percentage points. This includes both under-collection and over-collection, so ultimately you have to look at the net discrepancy. But for an offline retail business, even one or two percentage points, when it falls to the net profit level, is already a very large number.

So a big insight this project gave me is: sometimes the value of AI lies in finally giving a company the ability to redo things it gave up on in the past because the cost was too high. Now that the cost of verification has come down, that abandoned value has a chance to be recovered.

Currently we've only deployed to some stores in Shanghai, and there's room to expand further in the future.

Q5: Did you encounter new problems or challenges during the AI deployment? How did you solve them?

This case itself went fairly smoothly, but we've stepped in quite a few pitfalls along the way. Looking back, I think there were three main challenges.

The first challenge was overestimating AI's capabilities and underestimating the difficulty of the real industry.

We previously did a case on horizontal price comparison for domestic e-commerce in China.

I knew at the time it wouldn't be easy, because there were already companies specializing in e-commerce price comparison, with data, APIs, various data sources, and industry know-how behind them. But we still made a judgment: we thought AI should be able to solve seventy to eighty percent of the problem.

Once we actually started, we found reality was far more complicated than imagined.

Domestic e-commerce platforms are constantly locked in a game of risk control and counter-risk-control, and the platforms themselves place strong restrictions on rapid price queries, simulated human operations, and similar behaviors. Even if you find a workaround, it can quickly be blocked by platform policies. This ended up stretching the delivery timeline and shrinking the range of scenarios we could cover.

This taught me that AI capabilities must be matched against the real difficulties of the business. You can't assume that just because models and agents are powerful now, every real-world problem can be solved.

At its core, it was still a lack of industry knowledge.

If there are already companies in an industry that survive specifically on a certain problem, you should first study it seriously: what difficulty exactly have they solved? What information asymmetry do they hold? Why is this problem worth a company's long-term investment?

The second challenge was insufficient requirements research, leading to constant rework later.

Another case was automated homework grading and intelligent question recommendation for schools.

This requirement sounds very smooth: first grade, then score, then analyze, then recommend questions based on the student's situation; and the questions come from the school's own question bank.

But once you actually break it down, the problem becomes extremely complex.

For example: what accuracy level is actually required? What are the turnaround time requirements for grading? Which subjects? How often does grading happen? To what degree does the question bank need to be structured? What are the rules for question recommendation? After a student gets a difficult question wrong, should the difficulty be lowered, or should they keep getting harder questions around the same knowledge point? At which points exactly do humans intervene?

If these questions aren't clarified upfront, requirements will keep changing later on.

In the old days of software engineering, this was called "the product manager didn't define requirements clearly, so R&D kept reworking." In the AI era, the essence hasn't changed—except that the "cost of rework" downstream may now show up directly as massive token consumption and delivery costs.

So when we do FDE work now, we're more cautious than before. Technical research must be done seriously, solution research must be done seriously, and business research must be done seriously too.

The third challenge is that organizational alignment and boundaries of responsibility weren't aligned in advance.

AI projects are easily understood as "the boss wants it, the FDE builds it, and frontline employees use it." But in reality, the boss, middle managers, and frontline employees care about completely different things. If you don't clarify each level's goals, expectations, capability boundaries, and responsibilities upfront, it's very easy to end up with "if it doesn't work well, it's the FDE's fault."

So nowadays I increasingly emphasize one thing: you must not only align with the boss, but also align separately with each level of the organization involved in the project.

Who is responsible for what, who invests what, what counts as success, and who judges and handles issues when the AI goes wrong—all of this should be made as clear as possible upfront.

Q6: Based on your experience, how can we better deploy AI into real business operations?

If I were to distill this experience into a few fundamental principles, I actually wouldn't start with models, agents, or workflows. I would start with value, priorities, and trust.

First, you must choose the right first deal.

A company may hand you ten requirements at once, but the first project can't just be about picking whichever seems most interesting. You need to weigh things comprehensively: Is the business value sufficiently visible? Does positive feedback come fast enough? Are few enough people involved? Is the business process clear enough? How much do users need to invest? Is the technical cost controllable? Can the final value be quantified?

There's no such thing as a "perfect hexagonal task"—in the end, it's always a trade-off.

The reconciliation case was suitable as a first step precisely because it was fairly balanced across these dimensions: few people involved, a relatively clear business process, calculable value, low AI cost, and easy for employees to accept.

Second, don't aim for perfection in version one; get a positive loop running first.

My advice to FDEs is that version one should solve a problem with clear boundaries. Get the customer's approval, get people actually using it, make the value visible.

Once the first positive loop is running, trust is established. Tolerance for the second requirement will be higher, then you expand further, and further, until you form a sustained positive loop.

This is far healthier than promising an "fully automated, full-coverage, solves-everything-in-one-go" solution from the start.

Third, think through the delivery boundaries on Day One.

Especially with mid-sized and large enterprises, you can't wait until you're halfway through to tell the client: "This also requires you to buy servers," "This also requires adding headcount," "This also requires changing a whole process."

The client's resources and trust are real and finite. So on day one, when designing the solution, you should clarify the technical approach, resource investment, future expansion path, and possible boundaries as much as possible.

Fourth, don't simplistically understand AI deployment as "replacing people."

This is something I personally feel strongly about. If AI takes over 70–80% of the tasks in a role, it's easy for a company to get the impulse: since efficiency has improved, why not just lay people off?

But I believe this easily turns the AI project into a confrontation between the company and its employees. A better approach is to redirect the saved human bandwidth toward higher-value work.

For example, customer service staff don't necessarily have to keep doing only customer service—they can move into user research, sales, or other customer-facing work; a paid-traffic team shouldn't just aim for "fewer people," but should value a lower per-capita error rate and higher per-capita ROI.

This way, what AI brings is an upgrade to the organization's business goals, with cost reduction becoming secondary.

Fifth, the FDE's most core capability ultimately comes back to "understanding the business."

What AI can truly scale quickly is backend delivery capability; but what's hardest to replicate is still front-end industry knowledge, insight into requirements, and understanding of organizations.

So in the future, FDEs may become stratified: a small group of people who deeply understand the industry, the organization, and consulting, as well as AI delivery; while more people can achieve stable delivery on standardized, agent-friendly tasks using mature tools.

But no matter which layer, the most fundamental questions never change.

I require my team to keep answering these questions: What does the customer truly care about? How did they do things before? After we've finished, how do they do things now? What value have we actually created for them? Compared with the original solution, what are our strengths and weaknesses?

I think this is essentially the FDE's basic "Business 101."

You either know how to do it or you don't; you either understand the industry or you don't. Don't inflate your capability boundaries just because AI and FDE are hot right now.

A truly good FDE knows what's worth doing, what can be done now, and how to do what's doable in a way that lets the customer genuinely see the value.

Only when the first small victory is won—the customer sees the value, employees are willing to use it, and the business is willing to keep investing—does AI truly transform from a technical capability into part of the company's business.

<a id="no11"></a>

From Scattered Files to On-Demand Access: How an FDE Used AI to Turn a Foreign Trade Company's Documents into Usable Assets

Q1: As an FDE, what is the specific scenario where you applied AI? What did the specific problems in this scenario look like?

When I first engaged with this company, my immediate reaction was that their requirements weren't "fancy" at all.

This is a foreign trade gift company whose products include small items like bottle openers, with annual sales of several hundred million RMB, but the entire team is only a dozen or so people. The business has been running for many years, and the problem is that there's too much data, too scattered—and a considerable portion of it is images, which are harder to organize than well-structured text and tables.

Their computers contain sample images, design graphics, reference images, client delivery images, and various product templates, scattered across different computers and different folders.

So the boss's initial request to me was very specific: could it be that in the future, he could just say one sentence to the AI, like "help me find a certain template a certain client used before," and the AI would directly find it?

Besides file search, he had several other requirements. For example, he wanted the AI to be able to see the data from Alibaba International Station and tell him how today's keywords were performing and whether to swap them; he wanted the AI to continuously publish articles on the company's website; and for product posters, which previously required handing product images to a person for processing, he wanted to just give the AI a product and have it automatically placed into an existing template.

None of these things seem complicated individually. But the real problem is actually hidden beneath these "small requirements."

First, the company's digital assets haven't truly been organized. The files are all on the computers, but the AI doesn't know the relationships between these files—and the people themselves may not know either.

Second, the company lacks an environment where AI can actually run. You can't buy a large model account today and expect the company to be "AI-enabled" tomorrow. The network, computer environment, permissions, file structure, and workflows all affect whether AI can truly enter the business.

The third problem is actually the most important one: trust.

Many bosses have already heard plenty of AI concepts and may even know what an agent is, but they don't know what these things have to do with the problems they face every day. So when an FDE comes in, I think the first thing to do is find a problem the boss genuinely cares about, and then tell them: can AI solve this problem better than your current approach?

That's the starting point.

Q2: Before you got involved, how was this problem solved in the past?

This company had already spent money on digitalization and AI-related services before.

For example, the boss spent about 50,000 RMB on a related service that could pull some data based on the International Station, and they had also built a foreign trade website. The product itself had some value, but it was closer to a standardized product. Once the company ran into personalized problems, no one continued to accompany them going forward, and no one told them how to integrate the tool with the way their company works.

I kept thinking afterwards: why did traditional software and outsourcing approaches work in the past?

Because in the past, enterprise problems were relatively clear-cut. If I want a website, I find someone to build a website; if I want an ERP, I buy an ERP; if I want a design draft, I hand it to a designer. One problem corresponds to one tool or one person.

There was nothing wrong with this approach itself. But as businesses grew more complex, bosses started to find that their companies had dozens or even hundreds of fragmented small needs at the same time. If every single need required hiring an outsourcing team to develop, the cost would simply be unaffordable.

What's more critical is that many problems aren't even clear enough to be written directly into a requirements document. The boss knows "something isn't quite smooth here," but even he doesn't know what should be developed.

What left a deep impression on me was that this foreign trade boss encountered a customer need at the time. The customer gave him a product resembling a set square, with a row of irregular markings on it. They had hired designers and even done 3D prototyping, but never figured out what that row of markings actually meant. They were even prepared to copy it by hand, but couldn't copy it accurately.

Under the old way of working, this would have meant finding people, searching for materials, and going back and forth with confirmations.

I didn't develop any software for him at the time. I simply threw the photo to AI and asked it to identify what the product was; if it didn't know, to keep searching for related materials, manufacturers, and attached documents, and then analyze what information would be needed to actually make this product.

In about 10 minutes, AI found the product and also figured out that the so-called "irregular markings" actually represented angles.

The boss was quite surprised at the time. Because by his original way of thinking, this would have taken a day or two of research.

That moment was actually very important. For the first time, he realized that AI doesn't need to be treated as a new piece of software that requires separate learning—it is itself a completely different way of solving problems.

Q3 What was your overall approach and the key steps in using AI to solve this problem?

Once we actually started, I didn't rush to develop features.

Step one: deal with the on-site environment first.

We decided to use the most cutting-edge large models directly, but only after arriving on-site did we discover that their internal network environment, adjusted continuously by themselves over the years, was extremely complicated: 4 routers, 2 optical modems, 1 switch, plus a soft router—the whole network was wired together in a messy way and was often unstable. So, in order to give the agent more stable and flexible intranet access and tools, I spent my first day almost working as a network engineer.

This beginning also shows that the first thing in enterprise AI deployment is often to solve the infrastructure problems left over from the past. If the company intranet doesn't work and device environments are inconsistent, no matter how good the agent is, it won't run.

Step two: reorganize the enterprise's files.

After the network was fixed, my second step was to organize the enterprise's files.

This step was far more complicated than simply stuffing files into a so-called "knowledge base." Our approach was to reorganize the materials scattered across various computers, establish relationships between files, and let AI know which files belong to which customer, which product, which project, and how the different materials relate to each other.

But here we immediately ran into a practical problem: these materials could not be handed directly to us.

For the boss, the contracts, customer information, and product files on his computer may themselves be the company's most core assets. Some things he wouldn't even show to other employees in his own company, let alone package everything up and send it to an external FDE.

Step three: keep the data inside the enterprise, and send the development capability in.

Under the traditional approach, we would package the data and take it back for development, but once on-site we found this path wouldn't work.

So we adjusted our thinking: first, we organized a Harness into a task package, deployed the framework, principles, specifications, and Demo together into the customer's own Codex, and then let the customer's local Codex continue the development on his own computer and file environment according to our specifications.

We spent dozens of hours upfront building the framework, then let the customer-side Codex run for about 40 hours. After it finished running, the boss started testing.

The logs, issues, and records produced by testing were then organized by the customer-side AI and sent to us. Based on this feedback, we continued to revise the specifications and tasks, and then had the customer-side AI complete the adaptation.

This process was very important to me. Because it changed the old working model where "the on-site engineer must always stay next to the customer's computer." The data doesn't need to leave the enterprise, yet development and adaptation can still continue.

Step four: turn the delivery into the enterprise's own capability.

More importantly, we don't want to handle these needs for the enterprise forever.

My goal is to turn files into documentation, sort out the relationships between materials, consolidate the knowledge, and then build workflows, Skills, and agents. Once these things gradually accumulate, the enterprise itself will be able to solve more and more problems on its own.

What I'd rather deliver in the end is the enterprise's own capability to solve its next batch of problems, so that the company doesn't have to come to me every time it encounters a problem.

Q4 Compared to traditional methods, what were the actual results of using AI?

If we look at it purely as a software project, it's actually still hard to draw a conclusion like "efficiency improved by X percent" for this case, because the project is still in its first phase and delivery is not yet complete.

However, several very obvious changes have already taken place in this project.

The first change: the enterprise began to truly understand what AI can do.

With that set-square problem, the boss originally thought it would take a day or two of research, but we used AI on-site and found the product's source and the meaning of the markings in about 10 minutes. Later, when he felt the vector graphics were hard to make, we simply asked AI what tool to use and produced the vector graphics on the spot.

What's truly important about this result is that the boss began to realize that many problems he previously thought required hiring professionals and following fixed procedures can now be solved in a different way.

The second change: once trust was established, the enterprise began proactively releasing more needs.

At the beginning, the boss was only willing to give us one very small, very specific problem with a low cost of trial and error. But after we made some deliveries, he quickly came up with a dozen or twenty new needs.

This change says more than any efficiency metric alone. Because it means the enterprise has shifted from "Should I try AI?" to "What other problems in my company can be solved this way?"

The third change: the boss's view of AI began to shift from "buying a tool" to "rethinking how the company works."

I gradually became convinced later that for this type of enterprise, the greatest value of an FDE may not be helping them hire one or two fewer people.

What's truly valuable is that, through a few concrete projects, the boss sees a new way of working, which then changes his subsequent strategic judgments.

In particular, many of the enterprises we work with are at a stage of rapid business growth where manpower can't keep up. At times like this, if the boss realizes that future new business doesn't necessarily have to be solved by adding headcount, the value brought by this shift in mindset may far exceed the cost saved by any single tool.

Q5 During the AI deployment process, did you encounter new problems or challenges? How did you solve them?

During this project, three challenges left the deepest impression on me.

The first challenge was inconsistent on-site environments.

Our own programs ran perfectly on our local machines, but produced all kinds of errors on the customer's computers. The reason is simple: every computer's environment is different.

At the beginning, this often happened: I sent an installation package, they said it errored; they sent me a screenshot, I fixed it and sent another one; then a new error appeared.

These might be very basic problems in standard software engineering, but in a real enterprise environment, they genuinely slow down the whole project.

So later we treated the environment as a first-priority on-site problem. After arriving, we first spent time getting a clear picture of each computer's network, permissions, and runtime environment, and tried to standardize them in advance. That's why there was much less back-and-forth rework later on.

The second challenge was data and privacy.

For AI to truly work, it must access the enterprise's most valuable materials. But these are precisely the materials the boss is most reluctant to hand over.

So we took a different approach: we sent the development capability and task specifications into his environment, letting the customer's own AI complete the work locally, with the data never leaving the enterprise.

The third challenge was the boss's and employees' time and cooperation.

The boss has to handle business; after the product is built, it needs his testing, but he might be out of the office for days; employees need to work during the day, yet we need to debug their computers.

But a customized product can only reveal where it fails to meet requirements if someone actually uses it. For a while, we even kept urging the boss: "Find some time to use it—at least leave us some records."

Later, we developed a remote channel ourselves, allowing our AI to connect to the AI on the customer's computer in the background and complete certain tasks without disrupting employees' normal work. Many long-running tasks were scheduled to run overnight, saving both sides a great deal of communication and waiting time.

Looking back, none of these three challenges was directly about the model, yet each one could determine whether the project could actually get off the ground. This is exactly why FDEs must get into the field of the business itself.

Q6 Based on your experience, how can we better deploy AI into real business operations?

After completing these projects, I gradually came to see one thing clearly: an FDE must not think of themselves as an "AI outsourcing provider."

If we merely help a client develop a small piece of software, we will inevitably get dragged into price comparisons with traditional outsourcing firms—and professional software outsourcing companies would likely do it more maturely than we could.

What an FDE should really solve is a different problem: how to bring AI, as a general-purpose capability, into a specific enterprise and make it ultimately stay.

First, start with a very small, very specific problem.

Don't open by talking to the boss about multi-agent collaboration, Harness, or enterprise agents. What the boss truly cares about is:

"Can you solve this problem I have right now?"

And ideally, it should be a problem they are currently spending time and money on, or one that is even affecting the business. Once that problem is solved, trust naturally follows.

That's exactly what we've seen in practice: many bosses are initially only willing to try with a single pain point, and only after seeing results will they hand over the next dozen or dozens of problems.

Second, don't just talk about AI—solve problems on the spot.

Many business owners today have already heard far too many AI concepts. What really works is taking the problem they care about right in front of them and letting them see your thinking process with their own eyes. Concepts are easily forgotten once heard, but when a real problem is solved on the spot, the boss immediately understands what AI has to do with them.

Third, shift the delivery goal from "building a tool" to "building lasting enterprise capability."

I hope that in the future, enterprises won't need to come to me every time they hit a problem. After completing a project, what the enterprise takes away should be a methodology for continuing to solve problems on its own—the specific tool itself is not the point. After a few deliveries like this, when the enterprise encounters a new problem, its first instinct will shift from "finding someone" to "trying it ourselves first."

Fourth, FDEs must accept a fact: a large amount of the work is not "AI."

You may need to fix the network, deal with Windows environments, sort out file naming conventions, resolve permissions, wait for the boss to come back from a meeting, and push employees to run tests. None of this looks like AI technology, but it determines whether AI can actually enter the real business.

The scarcest capability of an FDE is the ability to stand in front of a real business problem and dismantle, one by one, all the obstacles preventing AI from working. "How many models you know" is actually secondary.

Finally, I believe the ideal FDE makes the client increasingly independent.

One day, the enterprise will realize: previously, when a need arose, I had to find a software company, an outsourcing firm, or a consultant; now, when a need arises, my own data, workflows, and AI capabilities are already in place, and I can try to solve it myself first.

Only at that point does AI truly become the enterprise's own capability, rather than just another line item on a procurement list.

<a id="no12"></a>

From Manually Supervising Images to Company-Level Production: An FDE Reshapes the Footwear and Apparel E-commerce Content Workflow with AI

Q1 As an FDE, what is the specific scenario where you applied AI? What did the specific problems in this scenario look like?

The scenario I entered this time was content production for e-commerce products.

My client is a traditional footwear, apparel, and headwear e-commerce company with its own factories and designers, mainly selling products on platforms like Taobao and Tmall. It is already a leading player in the industry, with annual revenue of roughly 1 billion RMB.

One characteristic of this kind of company is that it has a huge number of SKUs, and new products launch very quickly.

For a single product, photography and uploading are just the beginning. Every new product launch requires main product images and detail page assets; and now that video e-commerce has taken off, shoppable video content is also required. As the number of SKUs grows, the volume of content production multiplies accordingly. The client has massive daily demands for image and video production, so they have long maintained a sizable in-house design and operations team.

Faced with such a large demand, it was easy for me at first to oversimplify the problem: if designers produce images too slowly, just use AI to help them produce images. But once I actually got into the field, I found things weren't that simple.

First, there's the cost issue. Under the traditional model, the company needs a large number of design and operations staff continuously processing assets, so labor costs are already very high.

Second, even if a company has already started using AI, it doesn't mean efficiency problems are automatically solved.

Their original usage was quite fragmented—everyone opened their own AI accounts and wrote their own prompts. It looked like everyone was "using AI," but in reality they had merely stuffed a new tool into