# Thirteen Questions on FDE / 关于 FDE 的十三个问题

> Published 2026-07-07 · By lawted (https://x.com/lawted2) · Published on HA7CH (https://ha7ch.com)
> Canonical: https://ha7ch.com/writing/thirteen-questions-on-fde

## English

This is a warm-up interview held ahead of the 2026 Feifan Awards (Shanghai · AI Business Summit, July 15–16). The interviewee is Ha7ch founder Lawted (Wu Mingze). The following is organized according to the original interview's five parts and thirteen questions, with the answers kept as close to the original wording as possible.

---

I. Identity Check: From Engineer to Ha7ch Founder

Q1｜Your resume spans a lot of ground — a master's in Design Engineering from Harvard, a research assistant at Stanford HAI, a former engineer at Alibaba/Tencent/MiniMax, and now the founder of Ha7ch (an FDE community and incubator). How did this shift happen — going from an "engineer who writes code" to building an FDE community? Was there a specific trigger?

This shift happened around April this year. Back then I got to know a friend who'd spent ten years in logistics, and we often had meals together. Lobster was really hot at the time, so through "packing lobsters" he introduced me to a friend of his — the boss of a freight forwarding company.

At first we went over just under the pretext of packing lobsters and meeting friends, but as we kept talking we discovered this boss hadn't even really used an AI product like Doubao.

That hit me hard, because a lot of what I'd been exposed to before came from Silicon Valley, Stanford, or the most cutting-edge research and products in the AI industry. In that context, everyone was talking about Agents, model capabilities, workflows, and all sorts of new technical paradigms. But once I was at a real enterprise site, I suddenly realized that AI is actually still very far from huge numbers of ordinary companies and ordinary people — there's a massive gap in between.

What's even more interesting is that these bosses aren't without anxiety. He knew perfectly well that AI is happening, and he knew his company should be putting AI to use, but he didn't know where to start, didn't know what problems AI could actually solve, and didn't know who to hire to do it.

Later we went right into his business on-site and watched how the order operators work every day. A lot of the work still relies on WeChat, Excel, PDF, and manual copying — reading documents, entering fields, checking information, handling exceptions. We quickly saw that there really were plenty of steps here that AI could optimize and make more efficient.

That experience made me feel very clearly, for the first time, that AI's real opportunity might not lie only in creating more cutting-edge technology, but in bringing technology that already exists into real industries.

From then on, my perspective began to change. I no longer just focused on the most cutting-edge overseas research and products, and I no longer saw myself only as an engineer who writes code. Instead I started putting more energy into enterprise sites — understanding real workflows, judging which problems are worth solving with AI, and then quickly building systems that can be validated.

That was also the trigger point where I really started doing FDE.

Follow-up｜How does a design engineering background (which emphasizes human-computer interaction and systems thinking) shape the way you understand FDE now? And how does that differ from the perspective of a founder with a pure computer engineering background?

As for how the design engineering background shapes my understanding of FDE — first, I wouldn't claim I'm already defining the industry standard for FDE. I'm more like putting forward an observation and a classification.

For example, I divide FDE into the "big-tech, platform FDE" and the "scrappy FDE" — the scrappy, entrepreneurial FDE who goes into small and medium-sized enterprises on their own and handles both demand discovery and delivery themselves.

The reason I can see the difference between these two kinds of FDE is inseparable from my design engineering background. Design engineering demands that one person understand product, design, engineering, and human behavior all at once. You can't only understand technology, and you can't only know how to run interviews.

You have to actually get inside the enterprise, talk with the boss and the frontline employees, and understand what they really need — while also understanding the boundaries of AI's capabilities, and having personally used Agents, Claude Code, and other tools intensively across a large number of projects, so you know whether an idea can quickly turn into a demo and whether it can actually go live. Only when all of these abilities exist at the same time can you understand what FDE is really about.

The biggest difference between me and founders with a pure computer engineering background is probably that I don't worship technology all that much. For me, what matters most isn't how new the technology being used is, but understanding the boundaries of technology and then quickly delivering a solution that's genuinely useful.

Many technical founders might start from technical innovation, first asking, "I've got a new model, a new algorithm, or a new architecture — what can I do with it?" Whereas I'd rather start from human needs and workflows, first asking, "What problem is this person facing right now, and what solution can help them most effectively?"

If technology from ten years ago could already solve the problem well, I'd use ten-year-old technology too, because what enterprises actually buy isn't whether the technology is new or old — it's whether the problem gets solved.

I think the biggest influence design engineering has had on me is that it keeps me always starting from people and their needs, while retaining enough engineering ability to quickly turn that need into a system that can be validated.

---

Q2｜Ha7ch's website says it's an "AI-native Builder Lab born at Stanford, the world's first FDE Accelerator." Why "Accelerator" and not a "training program" or a "consulting firm"? What's the biggest difference between an FDE accelerator and a traditional YC-style startup accelerator?

Follow-up｜What are you actually accelerating — "people" (a Builder growing into an FDE), "projects" (a product from zero to one), or "companies" (an AI-native startup)? How do you rank those three within Ha7ch's system?

Ha7ch's earliest origin was really back when I was a research assistant at Stanford.

At the time, some friends and I were discussing one thing: whether a genuinely AI-Agent-facing product form would emerge in the future. Back then we ran a lot of experiments around Claude Code. What we wanted to build wasn't simply bolting AI onto an existing product — we wanted the product to be AI-native from the very start.

In other words, its interaction model, its workflow, and its underlying logic would be designed from the ground up for an Agent to use, to collaborate with, and to get tasks done.

Later, after I came back to China and started dealing with real companies, I found that this actually lined up perfectly with what companies needed.

Of course companies want to become more AI-native — they want to use AI to boost efficiency, cut costs, even rebuild the way they work. But the problem is: who maps out the business, who decides where AI actually fits, and who turns those needs into a product that genuinely runs?

I eventually realized that this role is the FDE. So Ha7ch gradually evolved from an AI-native Builder Lab into what we call an FDE Accelerator.

The reason we call ourselves an Accelerator rather than a training program is that an FDE fundamentally isn't something you learn by taking classes. It requires actually going into a company, being deployed on-site, talking to the boss and to frontline staff, and dealing with unclear requirements, legacy systems, internal resistance, and real business pressure.

None of that is easy to simulate with a curriculum.

In particular, a lot of people who have already worked for years and carry family responsibilities don't necessarily have enough time or room to fail to keep dropping into different company settings. So in the beginning we focus more on students and young Builders.

These people have more flexible schedules, are willing to use the latest AI tools, and are more willing to step into an unfamiliar industry and re-understand the problem from scratch.

What we want to give them isn't an FDE course but a real testing ground — a chance to go into a company and see whether they can actually understand the business, whether they can find the real problem behind the boss's surface-level ask, and whether they can build something that frontline staff genuinely accept.

At this stage, the most important thing is to let them actually try it once, and then get feedback from the company's boss and its frontline users.

Because a lot of what Builders make right now is essentially a toy demo — it looks cool, but it isn't solving a real problem. What they lack isn't one more tutorial to read; it's a chance to get into the field and actually solve the real problem.

This is also where Ha7ch resembles YC.

A big part of YC isn't just the money — it's that YC forms a kind of alumni culture, a high-density network, and a form of credentialing. When a founder gets into YC, it means they've entered a network where excellent founders connect with and help one another, and at the same time YC itself becomes a form of market trust.

Ha7ch wants to build something similar in the FDE space.

Right now anyone can call themselves a Builder, and anyone can change their title to FDE. But who actually has the ability to go into the field, who can map out a workflow, who can talk to the boss and to frontline staff, who can handle the tangled problems sitting between business, product, and engineering — the market really has a hard time telling.

In the future, if someone is one of Ha7ch's earliest FDEs who grew up inside real company settings, that fact itself should become a form of credentialing.

We've already held offline events in cities like Beijing, Shanghai, Shenzhen, and Hangzhou, connecting a large number of people doing AI implementation, Builders, industry practitioners, and enterprise resources. This network is itself continuously generating value.

For example, someone who had just arrived in Shenzhen and had almost no local friends went to a single Ha7ch offline event, and later, through the people they met there, got connected to enterprise resources and new opportunities. This kind of high-quality person-to-person connection is also something I very much want to build for the long term.

But the biggest difference between Ha7ch and YC is that YC's core starting point is giving companies capital and then helping the company grow fast; Ha7ch's core starting point is giving people real settings and then helping a Builder gain industry capability.

YC's basic unit is the company; our basic unit right now is the person. YC uses money to lower the barrier for a founder to start a company, whereas we use the company's field to lower a Builder's barrier from "can build a product" to "can solve a real problem."

YC usually accelerates a project or company after it has already appeared, whereas Ha7ch sits further upstream — we accelerate the process of a person becoming an FDE, and even the process of a person finding a problem worth building a company around.

Another difference is that an FDE can naturally generate cash flow. As long as a Builder genuinely solves a problem for a company, they can potentially earn revenue from the project, so they don't necessarily need to raise investment first to start down this path.

What we provide isn't a check but a real problem, an entry point into a company, a group of peers, and a chance to complete a first real delivery.

So among the three — people, projects, companies — what Ha7ch is most clearly accelerating right now is people.

Projects are the training ground, but they aren't the asset Ha7ch ultimately wants to own; a company may be a long-term outcome, but it isn't a goal we're forcing at this stage.

We run the Ha7ch 48-Hour FDE Sprint, dropping Builders into real companies and having them, in a very short time, map out the company's pain points, reconstruct the workflow, find the parts suited to AI-driven efficiency gains, and then build a demo strong enough to give the boss and frontline staff a visceral, tangible feel for it.

Our role is to match the right people with the right companies and to provide the method and the environment.

Afterward, if the two sides want to sign a contract and pursue commercial delivery, that can be handled by another commercial entity or driven by the Builder themselves — it doesn't have to be tied to Ha7ch. Ha7ch would rather stay in the role of a talent network and an experimental field.

So the three should be ordered like this: first accelerate the person, then validate the person through projects, and finally some of those people may, out of a string of projects, discover a genuinely recurring industry need and go on to found a company.

Over the long run, we hope the companies these Builders have served will also gradually become more AI-native.

Because the people we screen for and cultivate already think about problems in an AI-native way — they won't just think about bolting a chatbot onto a company; they'll re-examine the workflow, the way the organization is structured, and the product architecture.

Of course, what solution ultimately gets adopted still depends on the company's specific situation, rather than forcibly changing everything just to chase the AI-native label.

---

Q3｜You run a personal account on Xiaohongshu, and your content style leans toward "engineer narrative + entrepreneurial thinking." Does this account actually help Ha7ch with customer acquisition and brand? Or is it more of a personal outlet for you?

Follow-up｜Are you yourself also playing the role of a "super FDE" — going deep into the industry's front lines, then abstracting that experience into methodology?

Actually, I'm already slowly drifting away from the "engineer narrative."

In the past, people probably felt my content was more about talking about technology, engineering, and projects, but now what I want to express more is entrepreneurial judgment, the customer's front line, and FDE-related thinking.

I no longer spend a lot of time separately explaining some model, some framework, or some new technology. Instead, I pay more attention to what scenarios these technologies ultimately enter, what problems they solve, why some projects can get deployed while others just stop there once the demo is done.

For me, the more important role of this account now is not to show how much technology I understand, but to get different kinds of people to connect.

A Builder can see through the content what's actually happening inside real companies; a business owner can understand through the content what an FDE can actually do for them; and people who are already doing deployment work can exchange their respective judgments and experiences here.

This account is of course a very substantial help to Ha7ch, because at this stage the whole of Ha7ch still depends to a large degree on my personal IP.

Many people don't get to know Ha7ch first and then get to know me; instead, they first see my content, agree with my judgment, and only then enter Ha7ch's events and network.

I hope Ha7ch can gradually form its own brand and organizational capability in the future, but I also don't think it should be completely detached from the individual.

Especially since FDE work is itself something highly dependent on trust, front-line experience, and concrete judgment — if you turn Ha7ch into a fully institutionalized brand with no expression from specific people, it can easily lose that "living human" feel.

That's not a good thing for FDE, because in the end companies aren't buying an abstract concept; they're judging whether this group of people really understands the front line, whether they dare to take on responsibility, whether they have real experience.

So Ha7ch can gradually stop depending only on me, but it can't turn into an organization that's all official slogans and no specific people.

As for whether I'm playing the role of a "super FDE," I think to some extent I am.

These days I go into the front lines of many different industries — factories, logistics companies, cross-border teams, racing teams — talking directly with the top boss of a company as well as with frontline employees.

Because we want to invite these companies to join Ha7ch's hackathons or FDE Sprint, I not only need to explain FDE and AI-driven efficiency to them, but also to get them to understand what Ha7ch wants to do, why it's worth opening up their real problems, and what they can get out of it.

This process is itself part of FDE work: first build trust, then understand the business, and finally find a problem suitable to be validated.

These front-line experiences have also had a huge impact on me personally.

When I used to work at tech companies like Alibaba, Tencent, and MiniMax, even though I came into contact with a lot of complex software systems, I actually didn't have many chances to really see how the world we live in gets produced.

After going into factories, for the first time I seriously watched how an assembly line runs, how hardware gets manufactured, how workers and managers collaborate, how an order, a part, or a product comes into being through a whole series of real processes.

These experiences don't just help me understand FDE; they're also enriching my understanding of business, of industry, and even of how society as a whole operates.

But if you're asking whether I've already abstracted these experiences into a complete methodology, I don't think I've reached that stage yet. It hasn't yet reached the point where quantitative change produces qualitative change.

On the community-operations side, I've probably already accumulated some relatively clear methods, but FDE itself is too fragmented; different industries may need completely different solutions.

A logistics company might need AI plus ERP, or a document digital worker; a cross-border business might need an Agent workbench; a racing team might need Feishu agents and a knowledge base; a manufacturing company might instead care about visual inspection, patrol inspection, or the production process.

Their technical forms, organizational structures, evaluation metrics, and value logic are all different, so if I said right now that I've already formed a complete methodology applicable to all industries, I think that would be dishonest.

What I believe more now is that part of FDE ability can be trained, but it's impossible to quickly turn someone into a senior FDE through a single course, just as it's impossible to produce a senior consultant through a few months of courses.

Real industry judgment and front-line experience take time to accumulate.

But we can train a person with potential and make them an excellent junior FDE, or a "consulting intern": someone with strong learning ability and initiative, willing to go into the front lines, able to proactively probe for business problems, who knows how to interview frontline employees and dares to keep pressing on the surface-level needs a customer raises.

What Ha7ch really wants to do at this stage is exactly this: first discover and train this underlying ability, then let these people gradually grow their own industry experience and judgment through one real project after another.

---

II. Defining the FDE: Old Wine in a New Bottle, or a New Species?

Q4｜In 2025-2026 the concept of the FDE (Forward Deployed Engineer) blew up, and some people are skeptical: isn't this just the old "on-site engineer" or "outsourced delivery" with an English title slapped on? As one of the earliest people to systematically promote the FDE in China, how do you answer that?

Follow-up｜At its core, how is the FDE you define different from Palantir's original FDE, and from the FDEs that model companies are hiring now? Is there something uniquely "Chinese-style FDE" about it?

I once recorded a video specifically about a "ten-dimension comparison," putting the on-site engineer, outsourcing, consulting, the big-tech FDE, and the scrappy FDE side by side across ten different dimensions.

A lot of people ask me at first: isn't the FDE just the old on-site engineer or outsourcing with an English title slapped on?

But I think the most fundamental difference between them isn't whether you sit and work in the client's office — it's that the starting point and the ending point are completely different.

The starting point for traditional outsourcing or an on-site engineer is usually a solution that's already basically decided. The client tells you: I want to build a system, add a feature, do multilingual localization; the engineer takes the requirement and is responsible for executing it.

But the FDE's starting point is often an extremely vague problem.

Maybe it's just that you went and packed lobsters once for a logistics boss, and he suddenly says to you: "I want to use AI to boost efficiency too, but I have no idea where to even start."

That is the FDE's true starting point.

There's no PRD, no fixed solution, not even a clear sense of what the problem is.

The FDE has to go on-site, watch how the employees work, talk constantly with the boss and the frontline staff, gradually tease this extremely vague need into a clear workflow, then turn it into GitHub Issues, and only at the end into production-grade code.

The ending point is different too.

The endpoint of traditional outsourced delivery is usually the completion of the product or feature; once it passes acceptance, you get paid. Whether anyone actually uses the product in the end, whether it truly helps the client acquire customers, cut costs, or improve efficiency, is usually outside the outsourcing team's scope of responsibility.

But the FDE puts far more emphasis on delivering for outcomes.

On projects suited to being settled by results, if the system you build can't help the client generate qualified leads, lower costs, or improve processing efficiency, then the thing itself has no value — and it shouldn't earn the full fee just because the code got written.

This willingness to tie your own income to the client's outcomes is what gives the FDE its confidence, and it's one of the most important things that separates it from ordinary outsourcing or on-site development.

Of course, not every project can use pure pay-for-performance, but the FDE's judgment of value must always take the client's outcome as the endpoint, not a feature list.

Take a cross-border apparel company, for example: the boss might only say, very vaguely, "I feel like AI can help me make more money."

In the traditional outsourcing model, you'd usually wait for the boss to first put forward a clear requirement — say, "I want a multilingual version of the site with styling adapted to different regions" — and then the outsourcing company builds it to spec, charges 50,000 yuan, and the project is over.

As for whether the site, once live, actually brings in customers from Spain, Portugal, or anywhere else, that's usually no concern of the outsourcing team's.

But the FDE's work sits much further upstream.

We might first analyze his customer-acquisition methods, his site structure, his target markets, and user behavior, and then discover that right now he only has an English-language site — and one whose wording and design are still very Chinese-style, not suited to consumers in different countries.

Based on that judgment, we might then propose: use AI to rapidly build a site adapted to the languages and cultural habits of eighteen countries, and then verify the results through real traffic and the number of qualified customers.

In that case, the FDE's business model might not simply be "I'll build you eighteen sites for 30,000 yuan," but settling based on the qualified customers or leads it brings in — say, 5 or 10 yuan per qualified customer.

If all eighteen sites get built but bring in no new customers, then commercially those sites are worthless.

Outsourcing delivers eighteen websites; the FDE delivers new customers.

This example makes the difference between the two crystal clear: outsourcing starts from a fixed solution and ends with a completed feature; the FDE starts from a vague problem and ends with a business result.

Of course, the FDE isn't a brand-new species that came out of nowhere; it absorbs part of the capabilities of consulting, product, engineering, pre-sales, and implementation.

But the single biggest variable that makes this model viable today is the Coding Agents like Claude Code and Codex.

In the past, building a set of custom software for a company took a full team — frontend, backend, product, QA, and a project manager — and the cost could run into the millions.

Today, with a Coding Agent, the production cost of that same thing might drop by an order of magnitude.

In the past, small and mid-sized businesses simply couldn't afford custom solutions, but if a solution drops from two or three million to two or three hundred thousand — or even becomes an ongoing service of 40,000 to 50,000 yuan a year — it starts to enter the range that a large number of small and mid-sized businesses can accept.

A delivery that used to take a whole team can now possibly be done by one person who understands the business, the product, and engineering, plus Codex or Claude Code.

So I believe the Coding Agent isn't merely an aid to the FDE — it's the precondition for this wave of FDE to truly take off.

I personally split the FDE into two kinds: one is the big-tech, platform FDE, and the other is the scrappy FDE — that is, the entrepreneurial FDE, or FDE OPC.

The scrappy FDE faces small and mid-sized businesses directly, with no platform he's obligated to sell and no mature product backing him up.

He can freely choose his technology based on what the site needs: use GPT if GPT fits, use Codex if Codex fits; if it calls for an incremental AI-plus-ERP plugin, he builds the plugin; if it calls for a knowledge base, a workbench, or an automation flow, he builds those.

What he ultimately delivers isn't some fixed product, but the solution to the client's problem.

This is also a very big difference between the scrappy FDE and traditional software sales. The scrappy FDE doesn't first ask "what product do I have to sell," but first asks "what does this client actually need."

A lot of people also ask: with this one-person delivery model, how do you handle maintenance down the line?

Take the racing team I currently serve as an example: the client keeps raising new requirements, but the maintenance itself isn't as hard as you'd imagine.

My most important work isn't personally writing large amounts of code every day, but observing their workflow, teasing the requirements into clarity, and then turning them into GitHub Issues.

By evening, I can hand those Issues to Codex or Claude Code to finish.

The part of me that's truly irreplaceable is judging the problem, clarifying the requirements, and defining the boundaries — not mechanically writing every line of code.

As the models keep getting stronger, the implementation of more and more systems will become "get the requirements exactly right, then hand them to an Agent to execute."

So the technical implementation itself will get cheaper and cheaper, while on-site judgment and requirement definition will, on the contrary, get more and more expensive.

The logic of the big-tech, platform FDE is completely different.

Whether it's Palantir, or domestically Feishu, DingTalk, or Alibaba Cloud, they're all essentially based on a mature platform, doing a certain degree of customization for the client.

I once visited a factory in Anhui that had already bought Feishu and purchased AI credits. The Feishu team would then go on to ask whether they needed capabilities like hard-hat detection or smoke-and-fire detection, and then feed the surveillance data into Feishu Base.

Because the client had already bought the platform and the credits, the FDE service might be offered as an add-on.

The FDE sent over may have already done similar projects for twenty or thirty factories; once on-site, he confirms the camera models, the system interfaces, and the workflow, and can finish very quickly.

This is the typical big-tech FDE: on the surface it looks like customizing for one particular client, but in reality there's already a mature platform, standard components, and repeated-delivery experience behind it.

So the big-tech FDE is ultimately usually driving the sale, adoption, or renewal of some product.

Behind the Palantir FDE is Foundry; behind the Feishu FDE are Feishu and Feishu Base; behind the DingTalk FDE is DingTalk; and behind a model vendor's FDE are the models, the API, the Coding Agent, or cloud services.

Their advantages are a mature platform, stable delivery, and strong compliance capabilities, but they also have a built-in limitation: they tend to steer the client's problem toward their own product.

The scrappy FDE's advantages are technology neutrality, flexibility, and the ability to serve the small and mid-sized businesses that big tech can't yet cover, but the risk is that he easily degenerates into low-price outsourcing, and he lacks the brand, engineering, and after-sales guarantees that a big platform provides.

So I think the FDE isn't simply an on-site-engineer reskin.

If you only change the title but still write code to the client's PRD, then of course it's still traditional outsourcing.

The real change has four aspects:

First, the FDE's starting point is a vague problem, not a fixed solution;

Second, the FDE holds the right to define the problem, rather than only being responsible for execution;

Third, the FDE's endpoint is a business result, not merely a finished product;

Fourth, the Coding Agent slashes the production cost of custom software, making it possible for one person or a small team to accomplish work that used to require a full organization.

Without these changes, it's a reskin; with these changes, it's a new mode of organization and delivery.

As for the Chinese-style FDE, I think we're still exploring it.

China has a huge number of manufacturing, logistics, cross-border trade, and traditional service businesses, and inside them there are enormous amounts of order-operating, order-dispatching, reviewing, routing, data-entry, and communication processes — work that's very well suited to being partly automated by AI.

But the Chinese market also has a very real contradiction: the price businesses are willing to pay is relatively low, while the labor cost of a mature FDE right now is relatively high.

Palantir tends to serve projects worth millions, tens of millions, or even more, but a large number of small and mid-sized Chinese businesses can perhaps only accept a budget of tens of thousands to a few hundred thousand yuan.

This means the Chinese-style FDE has to be lighter, faster, and more reliant on Agents, and put more emphasis on embedding into existing systems rather than rebuilding a whole platform.

In the future, as more big-tech engineers and product talent enter the market, and as Coding Agents further raise individual productivity, the supply of FDEs and the price businesses can accept may reach a new equilibrium.

I believe the form the Chinese-style FDE is most likely to take is not a miniature Palantir, but a large number of small teams and super-individuals who understand their industry, understand communication, and can independently complete delivery with the help of Agents.

---

Q5｜The core paradox of the FDE model is this: you have to "go deep into the client's site and do custom work" (which doesn't scale), and also "abstract that experience into products/methodologies" (which does scale). Palantir solved this with the Ontology model. How do you think an FDE should handle the tension between customization and scale — one SOP per industry, or a common core plus an industry-adaptation layer?

Follow-up｜Is there any industry whose knowledge "can't be abstracted" — where you have to go on-site and figure it out from scratch every time? What industry is that?

I think the way an FDE scales doesn't necessarily start with turning every industry into a standardized product; it comes from a person's abilities being replicable and amplifiable.

A mature enough FDE, especially an FDE in the OPC form, isn't necessarily limited to a single industry.

Because a lot of enterprise scenarios belong to different industries on the surface, but the workflows that actually need solving are in fact highly similar.

Take order entry, order operating, review, breaking documents apart, field extraction, exception handling — whether these happen in selling clothes, selling shoes, logistics, or cross-border trade, the underlying structure is pretty much the same.

Of course we need to pick up a certain amount of domain knowledge, but it's not like every time you enter a new industry you have to understand all of that industry's knowledge from scratch.

The key is to distinguish between two kinds of problems.

The first kind is core professional judgment — like which clothes are worth selling, which shoes will become bestsellers, which medical device is safer, whether a given diagnosis holds up.

These problems really do depend heavily on industry experts, and they're hard for a generalist FDE to transfer into quickly.

The second kind is the repetitive workflows embedded inside an industry — data entry, splitting, organizing, checking, templating, approvals, and exception handling.

An FDE is better suited to going after the second kind first, because these processes have a lot in common across industries.

For example, when we worked on a medical-device scenario, we weren't having the AI judge which medical device is better, nor were we having the system replace doctors or professionals in making critical judgments — we were handling the huge amount of dirty, grinding, repetitive work inside it.

For instance, breaking design drawings down into parts, organizing them into templates, classifying fields, or automating processes that used to need people to handle them over and over.

That way you produce clear value without crossing the line into professional judgment.

So I don't think an FDE has to first become a ten-year expert in an industry every time they enter a new one.

What's really transferable is the ability to identify workflows, judge what's suitable for automation, quickly build thin slices, and push things into production.

From that angle, I lean toward "a common underlying capability plus the necessary industry adaptation," rather than independently developing a whole heavy methodology for every single industry.

A great FDE can work across multiple industries, but they have to know what can transfer and where they must rely on domain experts.

What transfers is workflow judgment and engineering ability; what doesn't transfer easily is the critical professional decisions.

As for Palantir using the Ontology to solve the customization-versus-scale problem, I think you first have to understand what the Ontology actually solves.

It's not just about uniformly modeling the objects, relationships, and actions inside an enterprise; more importantly, it builds a governance layer in a complex organization that is traceable, auditable, and capable of access control and data-compliance review.

Where a piece of data came from, what processing it went through, who has permission to view it, who made what decision, and whether accountability can be assigned when something goes wrong — these matter enormously for governments, large financial institutions, multinationals, or heavily regulated industries.

So Palantir's Ontology is essentially not just solving software reuse — it's also solving data governance, lines of responsibility, and compliance in complex organizations.

But I don't think every Chinese company needs to copy this path wholesale.

For large enterprises and heavily regulated industries, this Ontology layer can be extremely valuable; but for the vast number of small and medium-sized businesses in China, it's often too heavy.

What a lot of SMEs need to solve first isn't whether a decision can be fully audited, nor how to unify data permissions across departments and countries — it's that today there are still five employees entering orders by hand, one PDF has to be copied twenty times, and a single order has to be confirmed back and forth between WeChat and Excel.

At this stage, building out a full ontology, permissions, and audit system first can cost far more than the actual problem itself.

A lot of the projects we deal with aren't million- or ten-million-yuan mega-deals; they're real needs in the range of tens of thousands to hundreds of thousands of yuan.

In that situation, if you start out building a complex ontology, a unified data model, and a large platform, the client's budget may be gone before they've even seen any value.

It's like solving a simple problem — you don't need to build an extremely complex solving system first.

For SMEs, the more realistic approach is to first find a high-frequency, clearly bounded process, do it well with AI or a digital employee, and then gradually add permissions, logging, traceability, and audit capabilities according to the company's size, risk, and compliance requirements.

Not every company needs a shrunk-down Palantir; what they need more is a lightweight, fast solution that can embed into their existing systems.

So the way I understand scaling isn't cramming every client into the same platform — it's three things:

First, training up the FDE's ability to identify problems and break down workflows;

Second, accumulating the components, templates, and delivery methods that recur across industries;

Third, where it genuinely involves critical industry judgment, data governance, and compliance responsibility, bringing in domain experts and a more complete audit system — instead of pretending one general-purpose model can solve everything.

---

III. Ha7ch's Real Status

Q6｜Ha7ch has now built local networks in Beijing, Shanghai, Shenzhen, and Hangzhou. Roughly what scale is the Ha7ch community at right now? How many active Builders are there? On average, how long does it take to go from "joining the community" to "becoming an FDE who can be deployed on-site independently"?

Follow-up｜Between university students and "lateral-hire" engineers, which group is better suited to being an FDE? Are the university partnerships signed as framework agreements, or is there actual course, credit, or hands-on training embedded in them?

The Ha7ch community right now is at roughly over 2,000 people, and of those, the ones who are relatively active — who keep an eye on FDE, AI deployment, and Builder-related opportunities — number somewhere around 500 to 1,000.

This measure of "active Builder" doesn't mean all of these people can already do FDE work independently; it means they keep taking part in discussions, show up to offline events, follow real projects, or are themselves already building AI applications and doing enterprise deployment.

Our network now reaches beyond China — we've held events in Beijing, Shanghai, Shenzhen, and Hangzhou, and we're starting to build offline connections in Silicon Valley too.

The people we meet in Silicon Valley are more often big-tech, platform FDEs, or people who want to get into companies like Google, OpenAI, or Anthropic to do customer engineering, model deployment, and enterprise deployment.

In China, and especially in Shenzhen, there are a lot of people who are closer to the scrappy FDE or the FDE OPC — they deal directly with small and mid-sized businesses, and a single person or a small team handles demand discovery, product design, and delivery.

As for how long it takes on average to go from joining the community to being deployable on-site independently, we don't yet have a mature, trustworthy set of statistics.

Because what Ha7ch does right now is mainly not a training mechanism, but a screening mechanism.

The first thing we have to figure out is: what kind of person genuinely has FDE potential, what kind of person can only build a demo, and what kind of person can walk into the site, talk to both the boss and the frontline staff, and turn a fuzzy problem into a system that actually runs.

I think an FDE is very hard to mass-produce through a short course; it takes real projects, industry experience, and repeated on-site feedback.

So for now we'd rather first establish the screening criteria — for example, using Echo and Delta to judge whether someone lacks demand-discovery ability or end-to-end build ability — and then match the right people to the right enterprise scenarios.

Even if we can't yet give a single unified training timeline, as long as we can raise the accuracy with which the whole industry screens for FDEs, I think that in itself is a kind of positive infrastructure.

University students and lateral-hire talent each have their own strengths.

A student's biggest advantages are strong initiative, fast learning, more flexible time, and very high openness to new tools like Claude Code and Codex.

They're willing to step into an unfamiliar industry, and they're more willing to spend a day or two straight doing intense on-site research and prototyping.

But they usually lack experience communicating within a company, they don't understand the web of interests inside an organization, and they don't necessarily know what resistance a system will run into on the way from demo to launch.

Lateral-hire talent, on the other hand, shouldn't be understood as just engineers.

In fact, people who've worked as product managers, in operations, in solutions, in consulting, or in startups may more easily have the Echo an FDE needs than a pure engineer does.

They already have mature experience in communication, coordination, and business judgment; they know how to talk to a client, and they know how to sort out the problem from a mess of information.

A pure engineer's Delta tends to be strong, but if they're long used to waiting for a clear PRD and unwilling to meet clients, they aren't necessarily a natural fit for FDE work either.

Of course, the real problem with experienced talent is that they have less time and higher opportunity cost — a day of on-site work costs far more for them than for a student, and they find it harder to accept a stretch of exploration with no steady return.

So I don't think there's an absolute better-or-worse between students and experienced talent.

A student is more like a high-potential, low-cost Builder who needs to grow on-site; mature product, operations, or industry talent has a stronger foundation in communication and business, but needs to shore up their AI-native build ability.

The ideal team is often a combination of the two, rather than pulling people from only one kind of background.

University partnerships are still in an exploratory phase for now.

We'll try lectures, workshops, real enterprise problem sets, and FDE Sprints, but we're not yet at the point where we can claim to have built a mature curriculum, a credit system, or a mechanism for training talent at scale.

Ha7ch has really only been doing FDE content and community systematically for a little over a month — no more than sixty days — so it's still a very early stage right now.

At this point, what matters more is honestly distinguishing what has already happened, what is being validated, and what is just a long-term vision.

If any organization claims, in this short a time, that it has already fully run through multiple industries and built a mature training system, I'd look at that pretty cautiously.

We'd rather first screen the right people and do the first real project well, and then gradually answer the questions of average training time and scaled-up partnerships.

---

IV. Cognitive Reversals and Industry Judgment

Q7｜You've worked as an engineer at Alibaba, Tencent, and MiniMax, and now you're out on your own building Ha7ch. Is there anything like an FDE role inside big tech companies — solutions architect, customer success engineer, that sort of thing? How do you see the relationship between the big-tech, platform FDE and the independent FDE?

Follow-up｜If ByteDance or Tencent announced tomorrow that they were setting up an "FDE middle platform" and deploying on-site engineers to all their enterprise customers, where would the value of the independent FDE and the FDE community be?

I don't actually think of what I'm doing right now as building so-called "FDE infrastructure." A more accurate way to describe my position is that I'm building an FDE community — connecting different kinds of Builders, companies, and the people who are actually out there doing the deployment work.

Big tech companies obviously already have roles that come very close to FDE. Feishu, for example, already deploys engineers to enterprise customers to help them combine Feishu, Feishu Base, AI capabilities, and their existing workflows.

So I don't think big tech is incapable of doing FDE well, and I don't think the FDE has to exist independently, outside of big tech.

The more accurate judgment is that there's a very clear market split between the big-tech, platform FDE and the scrappy FDE, the FDE OPC.

Some large AI service companies or platform vendors can serve a big bank like HSBC, because those customers have enough budget and also have complex security, compliance, audit, and systems-integration requirements — they need a mature brand, a complete platform, and a large delivery team to support them.

But the scrappy FDE usually doesn't enter that kind of market. It serves the vast number of small and medium-sized companies — small logistics companies, cross-border trading companies, regional manufacturers, or traditional service-industry firms.

These companies may not even be willing to buy the flagship version of Feishu — not necessarily because the product is bad, but because they think their existing tools are already good enough, and they're unwilling to keep paying a relatively high fee for a large, general-purpose platform.

In this situation, the big-tech FDE and the scrappy FDE face completely different customers, budgets, sales approaches, and delivery models.

The core goal of the big-tech FDE is usually still to help the company sell, deploy, and renew an existing general-purpose product.

Feishu's FDE ultimately has to drive usage of Feishu, Feishu Base, and AI credits; Alibaba Cloud's team has to drive consumption of cloud services, models, or Tokens; and other model vendors likewise want customers to use their APIs and platforms more deeply.

The FDE here is a very important form of added value — it helps customers bring general-purpose products down into specific scenarios, and it helps big tech lower the barrier to customer adoption. But in the end it still serves the growth of the platform product.

The logic of the scrappy FDE is the opposite: there's no platform it has to sell, so it can freely choose tools based on the customer's problem.

If the customer needs Feishu, use Feishu; if they need DingTalk, use DingTalk; if they need a custom-built plugin, build a plugin; and if ten-year-old technology can solve the problem, there's no need to force the use of the latest model.

So it's not a matter of one replacing the other — they serve different tiers of the market.

If ByteDance, Tencent, Feishu, or Alibaba announced tomorrow that they were setting up an even bigger FDE middle platform, I don't think it would directly wipe out the scrappy FDE. If anything, it might further educate the market and help more companies understand what an FDE is.

Big tech will prioritize serving large customers with bigger contract sizes — the ones who can buy platforms and cloud resources. There's no way they'll pour large amounts of pre-sales and on-site resources into every small business whose annual budget is only a few tens of thousands of yuan.

And the opportunity for the scrappy FDE lies precisely in that highly fragmented, non-standardized, budget-limited, but demand-rich market of small and medium-sized companies.

Its competitive edge isn't that its technology is more advanced than big tech's, but that it's lighter, faster, more flexible, and more willing to start from a very small, concrete problem.

Of course, the scrappy FDE can't simply position itself as "cheaper outsourcing."

If it's just writing code on the cheap, big tech doesn't need to step in personally — traditional outsourcing companies can already handle that.

The scrappy FDE's real competitive edge should be technology neutrality, problem orientation, and an extremely low cost of delivery.

It can go on-site, untangle a vague problem into something clear, use Agents to quickly produce results, and not require the customer to first procure an entire platform.

In the long run, the big-tech FDE will keep serving large enterprises, making its mature platform deeper; the scrappy FDE will cover the vast number of small and medium-sized companies that big tech can't serve economically.

The two aren't in direct competition — it's more like a layered market.

---

Q8｜You used to run a Web3 project, and now you're all in on AI plus FDE. That whole Web3 ethos of "decentralization" and "community self-governance" — how does it shape how you run the Ha7ch community now? Or has that chapter already been "wiped clean" for you?

Follow-up｜Does the Ha7ch community borrow any governance mechanisms from Web3? For example, how do you quantify a Builder's contribution, and how do you incentivize it?

Oh my God, so even this chapter got dug up.

I did run a Web3 project before, called Snails Finance.

That experience does still have some influence on how I run Ha7ch now, but I'm not going to copy over the DAO, the Token, or a fully decentralized governance mechanism from Web3 as-is.

What I actually kept is the idea that a community shouldn't be run forever in one direction, top-down, by the founder alone.

A community with real life in it should let members gradually take part in building it, form a sense of identity, and grow their own local networks in different cities.

The structure we're building right now is Meetup, Guild, and GuildUp.

At the very start, someone can enter the community through a Ha7ch city Meetup.

The Meetup is more like a doorway — its job is to let new people get to know FDEs, and to get to know the local Builders, companies, and industry practitioners who are doing AI deployment.

After attending a Meetup, they can enter the Guild that corresponds to that city.

A Guild isn't a one-off event group chat — it should become the FDE network that exists for them long-term in that city.

For example, Beijing, Shanghai, Shenzhen, Hangzhou — each city can gradually form its own Guild.

Each Guild will also have relatively active leads or organizers.

They aren't necessarily "branch office heads" in the traditional sense — they're more like the conveners of the local network.

They'll regularly organize meals, coffee meetups, company visits, or small gatherings, and we call this kind of ongoing get-together a GuildUp.

The point of GuildUp is to get people who've been to a Meetup once to keep meeting up, to understand more about what each other is working on, and to deepen their understanding of FDEs, of the industry, and of how companies actually deploy.

I think GuildUp is absolutely necessary.

The problem with a lot of communities is that people meet once at an offline event, add each other on WeChat, join a group chat, and then the relationship just stalls there.

A single Meetup can generate a huge number of weak connections, but without follow-up, small-scale, high-frequency interaction, those connections rarely turn into real trust, and they rarely produce project collaboration, career opportunities, or industry knowledge exchange.

The value of GuildUp is to gradually turn one-off weak connections into long-term strong connections.

So Ha7ch's growth logic isn't to keep pulling everyone into one ever-larger WeChat group.

Overall, Ha7ch will keep hosting Meetups to connect new Builders and companies; the city Guilds take in the people who've already entered the network; and GuildUp lets existing members keep forming deeper relationships with each other.

This forms a layered structure: Meetup handles acquiring new people, Guild handles forming a city identity, and GuildUp handles increasing connection density.

That's mainly where my Web3 experience shows up.

I believe community members can jointly take part in governance and operations, and a city network shouldn't depend entirely on me personally.

But I won't treat "decentralization" as the goal.

Especially once Ha7ch moves into real corporate projects, there still has to be a clear person in charge, quality standards, and clear boundaries of responsibility.

Community activities can be co-built by members, but commercial delivery can't run on votes, and when a project fails, no one can be left unaccountable just because "everyone governs it together."

As for how to quantify and incentivize a Builder's contribution, we're still at a fairly early stage right now, and I don't want to introduce points, a Token, or a complex set of gamification mechanics too soon.

The contributions that are genuinely valuable in the future might include organizing GuildUps, connecting corporate resources, sharing real cases, helping other Builders, taking part in the FDE Sprint, and distilling project experience back into the community.

But these contributions won't all necessarily be well-suited to simply being converted into a single number.

What I'd rather Ha7ch end up forming is a reputation and identity system.

When someone consistently organizes events in a city, helps members, and completes real projects, everyone naturally knows who they are and trusts their ability.

The best incentive for them isn't necessarily points either — it might be higher-quality connections, corporate opportunities, industry influence, and the identity of being the representative figure of that city's Guild.

So that Web3 chapter hasn't been wiped clean for me — what I kept is the value of community co-building, identity, and network, and what I gave up is decentralizing for the sake of decentralization.

Ha7ch can be run by more people together, but in the end it still has to center on real connections, real contributions, and real projects.

---

Q9｜In 2026, huge numbers of companies overseas and in China are hiring FDEs, and FDE has gone from a "niche role" to a "hot title." Won't this overheating dilute the concept of FDE — say, traditional outsourcing firms rebranding their on-site engineers as FDEs, and training programs slapping the FDE label on their courses?

Follow-up｜How do you prevent "bad money driving out good"? Does Ha7ch have any certification system or quality endorsement to tell a "real FDE" from a "fake FDE"?

I think the FDE concept is genuinely starting to get muddy right now.

A lot of companies, when they hire, haven't actually figured out what an FDE should even be responsible for. They just see the title getting hot and repackage their old solutions, pre-sales, on-site development, or AI application engineer roles as FDE.

At the same time, training programs are starting to roll out FDE courses, but a lot of the content feels like it was thrown together at the last minute — stitching together some product, consulting, AI-tools, and project-management knowledge and then claiming they can quickly turn out an FDE.

I think this phenomenon is bound to happen, because any new role, once it gets hot, goes through a stage of concept diffusion, over-packaging, and messy standards.

But honestly, I'm not going to spend much energy arguing over who's a real FDE and who's a fake one.

FDE is itself a very broad role. It can lean toward product, toward engineering, toward consulting, or toward delivery, and different companies will define it differently.

If you insist that some person doesn't count as an FDE, he can just as easily say he's doing FDE work. I think this kind of fight over the title doesn't mean all that much in itself.

What actually matters isn't what he calls himself, but whether he's gone into a real site, whether he's taken a fuzzy problem and made it clear, whether he's built something that actually gets used, and whether it ultimately produced a result.

The market will end up separating these people through projects and delivery, not through a debate about definitions.

Right now Ha7ch also hasn't set up any formal certification system or quality-endorsement mechanism.

For now we mostly maintain quality through community culture, real projects, and long-term interaction between members.

Because if an organization that has just started doing FDE immediately rolls out a set of exams and certificates, then defines the standard itself, trains people itself, and hands out the certificates itself, I think it very easily turns back into a training business.

And the most crucial abilities of an FDE are hard to prove through an exam anyway — they need to be validated inside a real company.

In the future we might give a kind of identity to people who have actually taken part in an FDE Sprint, a hackathon, or a company project and have completed a real delivery — something like a Ha7ch Fellowship.

This identity shouldn't just be a "you attended the event" souvenir certificate; it should correspond to an experience that can be verified: what company he went into, what problem he faced, what system he built, whether the company used it, and what he specifically took on.

We'd rather it be a reputation formed jointly by projects and the community, rather than a certification you can get just by finishing a course.

So even if Ha7ch does quality endorsement in the future, it won't be the "pass the exam equals qualified FDE" approach.

It's more likely to be through project records, company feedback, peer evaluation, and sustained contribution that a person's ability record takes shape.

Whether it's called FDE isn't the most important thing; what matters is what this person has done, and whether his results can be verified by others.

We don't need to become title police, judging who's qualified to use the word FDE. But through real projects, we can make it easier for the market to see who genuinely has this kind of ability.

---

Q10｜If you could do it all over again, on the path from Alibaba/Tencent/MiniMax engineer to founding Ha7ch, which decision would you make differently? Building the community earlier, commercializing earlier, or defining the standard later?

Follow-up｜Is there one specific "do-over" moment? How was that decision made at the time, and looking back now, where did it go wrong?

If I could do it over, I'd probably start doing my own content much earlier.

Because I keep realizing more and more that I'm actually pretty well suited to this, and I genuinely enjoy the process.

I like sharing what I've seen, the projects I've worked on, and the judgments I'm still forming, and I like connecting with all kinds of people through content.

A lot of people tell me I have a good feel for what plays online, and I think so too — I probably do have some intuition for what content sparks discussion and what way of putting things is easiest for people to understand.

When I first started getting into FDE, I was basically learning the concept while continuously publishing content about it.

Later an investor said to me, you should try being a Growth Hacker.

I asked him, what exactly is a Growth Hacker.

He said, it's simple — I give you a target: get to 10,000 followers within a month. If you can figure out how to pull it off, you're a Growth Hacker.

And I said, OK, let me try.

Since the social media platform I personally use the most is Xiaohongshu, I started with Xiaohongshu.

But at the start I honestly had no idea that getting to 10,000 followers on Xiaohongshu isn't an easy thing at all.

Back then I was just constantly testing content, testing topics, testing ways of putting things, watching what people responded to.

I didn't quite hit the target within a month, but at the current pace I have a shot at getting close to that result in about two months.

This process made me realize that I don't just enjoy making content — I treat it as a product and growth problem to study.

So if you sent me back to the stage where I'd left Alibaba and gone to Stanford to do research, I'd probably have started documenting and publishing content consistently right from then.

There was actually a lot worth sharing in that period — going from big-tech engineer to research, switching between different cultures and ways of working, and the shifts in how I think about AI, Agents, products, and startups.

If I'd started building that up back then, I might have formed a stable channel for expression earlier, and connected earlier with the Builders, business owners, and industry practitioners I know now.

But I wouldn't frame this as simply chasing followers or traffic.

What I actually find interesting is the process of sharing knowledge and connecting people.

I really like putting out the thinking I'm still forming, and I like seeing someone start to understand FDE, join Ha7ch, or find a new project or collaboration because of one piece of content.

To me, doing my own content isn't just a promotion tool — it's also a way of thinking in public, getting fast feedback, and building a community.

So the decision I'd really change isn't necessarily commercializing earlier, and it isn't defining the standard earlier — it's starting to express myself in public earlier.

Because a lot of opportunities don't show up only after you've finished everything; they take shape gradually as you keep sharing and keep talking with people.

---

V. Looking Ahead and Recommended Actions

Q11｜If you could only go all in on one direction: keep deepening Ha7ch's "talent incubation + community network" (asset-light, slow to scale but a deep moat), go all out expanding "on-site delivery" (asset-heavy, fast cash flow but labor-intensive), or build an "FDE SaaS tool" (productize the methodology, sell software instead of headcount)? Why?

Follow-up｜If you pick "talent incubation," how do you cope with the pressure of "slow monetization"? If you pick "on-site delivery," how do you solve the "scaling bottleneck"? If you pick a "SaaS tool," won't it clash with the FDE core principle of "selling outcomes, not tools"?

If I could only go all in on one direction, I'd still choose to keep deepening talent incubation and the community network.

It really is a relatively asset-light model. Scaling up early on is fairly slow, and monetization won't be as direct as commercial delivery, but I think once it takes shape, the moat will be extremely deep.

Especially after you've built up talent density, a network of cities, and community identity in the early days, the person-to-person referral effect afterward will be very strong.

An outstanding Builder joining Ha7ch might bring in their friends, colleagues, and industry resources; a company that finds the right person through the community might also bring more real-world scenarios in.

Once this network starts growing on its own, it could move much faster than scaling purely through ads and sales.

As for commercialization and cash flow, I'm not in that much of a hurry right now.

Because once a community is genuinely valuable, it's not like there's no way to monetize at all.

Down the road it can sustain itself through corporate sponsorships, joint events, talent matching, industry partnerships, the FDE Sprint, co-created projects, and even support from a foundation or industry resources.

But that revenue should serve the community, not turn Ha7ch into a course-selling outfit, a recruiting agency, or a pure commercial-delivery company in the end.

Personally, I do genuinely prefer building community.

I like connecting people, I like watching people from different backgrounds meet each other through a Meetup, a GuildUp, or a real project, and then create new collaborations and opportunities.

The satisfaction this long-term network gives me is stronger than simply scaling up a delivery team fast.

So I'll still keep deepening Ha7ch, and try to keep it non-profit in its positioning.

If I chose on-site delivery, the biggest risk is that it's easy to fall into labor-intensive expansion: the more projects, the bigger the team, the heavier the management and after-sales, and in the end it might become a traditional project-based company.

This direction can generate cash flow and has real value, so it can be run by an independent commercial entity, but it's not the thing I personally most want to go all in on.

As for FDE SaaS, I think it also shouldn't be built too early at this stage.

Because right now we haven't accumulated enough on real enterprise scenarios, and if we productize the methodology too early, it'll probably just end up as another Agent platform or project-management tool, without actually solving the core problem of the FDE.

Tools should grow out of real projects, not start from the assumption that every FDE needs one unified piece of software.

So my choice isn't simply "give up delivery and only do community," but to make community and talent the core, while keeping a small amount of real projects as a training ground and feedback mechanism.

Talent is the main body, projects are the validation, tools are the sediment, and commercialization is the means to keep this network running long-term, not the ultimate goal.

---

Q12｜A year from now, which currently popular FDE plays or companies will have disappeared? And conversely, which things that look niche or unfashionable right now will turn out to have been right?

Follow-up｜You've talked about "letting the best Builders grow into FDEs, entrepreneurs, and the founders of the next generation of AI companies inside real industries." This funnel — talent → FDE → entrepreneur — how far along is it actually running? Has any Builder who came out of Ha7ch already started a new AI company?

My view is that a year from now, most of the FDE plays we see today won't actually disappear outright, because the supply-and-demand relationship behind them holds up.

On one side, companies have widespread AI anxiety; they need to redesign processes, boost efficiency, and upgrade their organizations. On the other side, a large number of engineers, product managers, operators, and other highly skilled people are going to be looking for a new place for themselves as AI disrupts their old roles.

So companies have the demand, and talent needs to transition — this market is going to exist for a long time.

It's a bit like the matchmaking market.

You can say a particular guy and a particular girl aren't a match, but you can't conclude from that that the whole matchmaking market doesn't exist.

FDE is the same. A large enterprise might not match with a small team; a small or mid-sized company might not be able to afford the cost of a big-tech FDE. But there will always be some portion of companies and some portion of talent that manage to match successfully.

What really needs to be solved is matching efficiency, not whether the market exists.

So what might actually gradually disappear isn't a particular organizational form — it's the models that can't prove results, that are just traditional outsourcing repackaged as FDE.

For example, ones that still just wait for a PRD, charge by headcount, or can only build a demo and never get into a real production environment.

These plays won't automatically earn long-term value just because they changed the name on the label.

In the end the market still looks at whether anyone is using the system, whether the process has actually changed, whether the company has genuinely gotten results.

Conversely, the direction that I think is relatively niche right now but may prove correct in the long run is AI-native companies.

Right now everyone is more focused on how to bolt AI features onto an existing ERP, or how to deliver a project at lower cost.

These things obviously have value, but if you stop at simple efficiency gains and never think about how a company's whole organization and systems should change once model capabilities keep getting stronger, I think that's not enough.

Because AI is going to keep getting smarter.

Today it can maybe only replace a small slice of the work — data entry, organizing, review — but in the future it may take on much more of the communication, judgment, and execution.

If a company's systems can continuously plug in AI from the very start, and record people's corrections and process changes, then as the models get stronger, the human-in-the-loop part can keep shrinking, and the company's overall operating efficiency will keep getting higher.

So what I'm more bullish on is a kind of company that can keep re-engineering itself as the models evolve — not just one that bolts an AI plug-in onto a legacy system.

Of course, building a fully AI-native company from scratch is still very hard today, especially while domestic models, local deployment, reliability, and data security aren't fully mature yet.

But we also can't wait until the models are completely mature to start.

You can already go into a company now, gradually replace the simple, repetitive, labor-intensive work, and then keep iterating as model capabilities grow stronger.

As for the path Ha7ch envisions — "Builders growing into FDEs, then becoming entrepreneurs and the founders of the next generation of AI companies" — it's still at a very early stage.

We've only been doing FDE content and community systematically for about two months. If we claimed right now that we'd already gotten the full funnel running, that would actually be not credible.

Reddit was in YC's very first batch back in 2005, and it was acquired quite early, but it still took many years to reach the scale and influence it has in the later sense.

So a project or a talent network getting recognized very early doesn't mean its long-term value has already been proven.

What Ha7ch has really validated so far is just the very front of the funnel: finding Builders through content and Meetups, judging who has FDE potential through real enterprise scenarios, and then getting some of them into a Sprint or a project.

The later stages — independent delivery, industry accumulation, discovering entrepreneurial opportunities, and actually founding companies — all need a much longer cycle.

I hope that by the end of this year we'll see the first batch of concrete cases: for example, someone who got into a real company through Ha7ch, completed their first independent delivery, and maybe even found a startup direction worth committing to for the long haul.

But whether this path ultimately holds up should be proven by the people and companies who actually walk it over the next few years — not announced in advance by us when we're two months old.

---

Q13｜If you could give the audience at the Feifan Awards — corporate decision-makers, AI founders, engineers in transition — just one piece of advice about "how to actually get AI to land in the real world," what would it be?

Follow-up｜Could you give a concrete action or checklist people can execute right away? Something like "three signals that tell you whether your team needs an FDE" or "three criteria for choosing an FDE provider"?

If I could give corporate decision-makers, AI founders, and engineers preparing to make the switch just one piece of advice about how to actually get AI to land in the real world, I think the first thing isn't to keep taking courses, and it isn't to read more industry reports — it's to use Claude Code intensely, and use it to build a large number of things you'd always wanted to make but never got around to because of time and cost.

A lot of people will say they've used Claude Code, but if the way you used to write code hasn't really changed and you're now just handing off part of the code to Claude Code, I don't think that's enough.

The real leap comes from using it frequently enough — frequently enough that you start to re-understand what an Agent is, what an Agent can take on, and just how far a single person's capabilities can be amplified.

For me, the most obvious leap came after I started using the $200/month plan.

The reason I signed up for that plan was that I was maintaining a lot of products at the same time — in one month I built roughly eight or nine relatively complete products and kicked off more than ten projects.

It was during that stage that I truly realized just how much one person plus AI can do.

In the past, if an idea came to me at three in the morning, I'd probably just jot it down, put it off for a few days, and most likely never build it.

But now I can just open my laptop, lay out the background, the users, the requirements, and the outcome I want, and let the Agent get to work.

By the next morning I might already have a running version, and then I can ship it, go find my first batch of testers, and keep iterating based on their feedback.

Only when you go from idea to product to real users at that kind of cadence, over and over, do you truly understand what an Agent can do — rather than staying at the level of "it can help me autocomplete code."

So whether you're a corporate decision-maker, an AI founder, or an engineer preparing to make the switch, my advice is to first build a large enough number of small projects back to back.

These projects can't just be demos you keep on your own machine and admire yourself — ideally they should actually be shipped, attract real users, even if only ten people use them at the start.

Because only when a product actually faces users do you run into changing requirements, deployment, feedback, bugs, and maintenance — and only then can you understand what AI has actually done for you, and where it still can't replace human judgment.

My second piece of advice is that everyone preparing to become an FDE should seriously consider doing their own media — that is, Build in Public.

Because one of the hardest problems for an FDE isn't actually writing code — it's acquiring customers and building trust.

How do you get a company to know you can solve its problems? How do you make the next client believe you're not just someone who can build a demo?

One of the most effective methods is to continuously document the problems you run into on real projects, your thought process, your failures, your results, and your methods.

For example: you walk into a factory and find some problem in their order process; you try a solution and get stuck at a certain step; how you finally redesigned the workflow; and what happened to the manual-correction rate after it went live.

All of this can become content.

Every time you finish a project, you shouldn't only deliver it to the current client — you should also distill whatever can be made public, so it keeps attracting your next client for you.

If you do no public expression at all and just keep your head down delivering one project after another, it's easy to slide back into traditional outsourcing.

Once a project ends, the experience stays only in your own head — it never becomes a brand, a methodology, or a new source of clients — so there's no compounding.

This is exactly what a lot of great independent designers do: they don't wait until the whole project is done to show the result — they keep sharing new color schemes, motion, layouts, and design decisions throughout the process.

On one hand this content attracts their next client, and on the other it helps them distill their own workflow.

FDEs should do the same.

For corporate decision-makers, I think there are three signals that tell you whether your team needs an FDE.

The first signal is very direct: you already have obvious AI anxiety.

You know your peers are starting to use AI, you know the company needs to change, but no one inside can make it concrete.

At that point, rather than keep holding meetings to discuss it, it's better to bring in an FDE to run a small-scale trial on-site, or take part in one of Ha7ch's Ha7chthons.

The reason we call it a Ha7chthon rather than just a traditional hackathon is that a traditional hackathon is usually held at a fixed venue, where everyone builds demos around a hypothetical problem; but with a Ha7chthon, wherever the company is, that's where the event happens.

Builders go straight into a real company, observe real employees and real workflows, and complete demand discovery and prototype validation on-site.

It's not a competition around a set prompt — it's work around a company's real problems.

The second signal is that your company is still constantly hiring people to take on repetitive work that your gut tells you AI can already replace.

Things like data entry, organizing, review, order operations, moving information around, and repeated back-and-forth communication.

If on one hand you feel this work is very mechanical, and on the other you keep hiring people to fill it, then it's worth letting an FDE come in and take a look, and judge which processes can be redesigned.

This doesn't necessarily mean directly cutting a certain number of people — it means first seeing whether it's even necessary to keep solving the problem by adding headcount.

The third signal isn't necessarily cost-cutting or efficiency gains — it's that you simply want the company to keep progressing.

I'd split companies' motivations for using AI into two kinds: one is clear cost-cutting and efficiency gains, and the other is company progress.

Some bosses don't have a very specific KPI — they don't necessarily require profits to jump by so much or costs to drop by so much right away — but they want to look back in five years and see that starting on AI today was the right decision.

Especially some second-generation factory owners or business operators who are taking over the family company: they may care more about whether the company will still be competitive in the future.

Because no one can fully predict what AI will look like in five years.

If you start right now to re-examine the company's processes, data, and organization from an AI-native angle — even if it's just a small trial first — it could become the foundation for the company to stay ahead in the future.

An FDE doesn't only have to be about cutting costs — they can also help a company understand what the next generation of ways of working should be.

As for how to choose an FDE or an FDE provider, I don't think you can give an absolute set of standards right now, because the whole market is still very early and there aren't many truly mature providers.

But one principle is: don't put too much faith in titles, prestigious-school backgrounds, or all kinds of packaging — the most important thing is whether they can keep making things in a very short time.

A lot of traditional business bosses might be willing to sign a deal outright because the other side is a Tsinghua or Peking University team, yet unwilling to first spend some money to actually let them give it a try.

But if it were me, I'd rather cover the travel costs first, then — at a reasonably, even somewhat high, day rate — let the team come into the company and work for seven or fourteen days.

By the end of that period, I'd look at how much of the problem they actually understood, what they built, and whether anyone is willing to use the system.

One important change in the AI era is that delivery speed can be extremely fast.

A reliable FDE shouldn't spend two weeks stuck writing proposals, giving briefings, and discussing requirements — they should keep delivering.

Day one, map out the problem; day two, produce a workflow; day three, a prototype appears; and after that, keep revising based on feedback.

Seven to fourteen days is actually already enough to judge whether a person or a team is reliable.

So my advice to companies is: don't sign a particularly large contract right at the start, and don't make your choice based only on slide decks and reputations.

First pay for one real, small-scale, high-intensity engagement, and see whether the other side can get on-site, understand the business, build fast, and keep delivering.

In the end, an FDE doesn't prove themselves by persuasion — they prove themselves by producing visible results in a very short time.

## 中文

这是 2026 非凡大赏（上海 · AI 商业峰会，7 月 15–16 日）活动前的一次预热访谈。受访人是 Ha7ch 发起人 Lawted（吴明泽）。以下按原访谈的五个部分、十三个问题整理，回答尽量保留原话。

---

一、身份校准：从工程师到 Ha7ch 发起人

Q1｜你的履历跨度很大——哈佛设计工程硕士、斯坦福HAI科研助理、前阿里/腾讯/MiniMax工程师，现在创立了Ha7ch（FDE社群与孵化器）。从“写代码的工程师”到建设FDE社群，这个转变是怎么发生的？有没有一个具体的触发点？

这个转变大概发生在今年四月。当时我认识了一位在物流行业工作了十年的朋友，我们经常一起吃饭。那段时间龙虾很火，他就通过“装龙虾”这件事，把我介绍给了他的一位朋友，也就是一家货代公司的老板。

我们最开始只是以装龙虾、认识朋友的名义过去，后来聊着聊着发现，这位老板甚至还没有真正用过豆包这样的 AI 产品。

这件事给我的冲击很大，因为我之前接触的很多东西，都来自硅谷、斯坦福或者 AI 行业最前沿的研究和产品。在那个语境里，大家讨论的是 Agent、模型能力、工作流和各种新的技术范式，但到了真实企业现场，我突然发现，AI 距离大量普通企业和普通人其实还非常远，中间存在一个巨大的 gap。

更有意思的是，这些老板并不是没有焦虑。他很清楚 AI 正在发生，也知道自己的企业应该用上 AI，但他不知道从哪里开始，不知道 AI 到底能解决什么问题，也不知道应该找谁来做。

后来我们就进入他的业务现场，看了跟单员每天是怎么工作的。很多工作仍然依赖微信、Excel、PDF 和人工复制，包括读取单据、录入字段、核对信息、处理异常。我们很快就发现，这里面确实存在大量可以被 AI 优化和提效的环节。

那次经历让我第一次非常明确地感受到，AI 真正的机会可能不只是在创造更前沿的技术，而是在把已经存在的技术带进真实产业。

从那以后，我的视角开始发生变化。我不再只关注海外最前沿的研究和产品，也不再只把自己看成一个写代码的工程师，而是开始把更多精力放在企业现场，理解真实工作流，判断什么问题值得用 AI 解决，再快速做出可以验证的系统。

这也是我真正开始做 FDE 的触发点。

追问｜设计工程背景（强调人机交互与系统思维）对你现在理解FDE有什么影响？这和纯计算机工程出身的创业者视角有什么不同？

至于设计工程背景对我理解 FDE 的影响，我首先不会说自己已经在定义 FDE 行业标准，我更像是在提出一种观察和分类。

比如我把 FDE 分成“大厂平台型 FDE”和“土 FDE”，也就是独立进入中小企业、自己完成需求发现和交付的创业型 FDE。

我之所以能看到这两类 FDE 的差异，和设计工程背景是分不开的。设计工程要求一个人同时理解产品、设计、工程和人的行为。你不能只懂技术，也不能只会做访谈。

你既要真正进入企业，和老板、一线员工沟通，理解他们到底需要什么，同时又要理解 AI 的能力边界，并且自己高强度地使用 Agent、Claude Code 等工具做过大量项目，知道一个想法能不能快速变成 Demo，能不能真正上线。只有这些能力同时存在，你才能理解 FDE 到底在做什么。

我和纯计算机工程背景创业者最大的区别，可能是我并没有那么技术崇拜。对我来说，最重要的不是使用了多新的技术，而是理解技术的边界，然后快速实现一个真正有用的方案。

很多技术型创业者可能会从技术革新出发，先问“我有了一个新的模型、新的算法或者新的架构，我能拿它做什么”，而我更愿意从人的需求和工作流出发，先问“这个人现在遇到了什么问题，什么方案能够最有效地帮助他”。

如果十年前的技术已经能够很好地解决这个问题，我也会使用十年前的技术，因为企业真正购买的不是技术的新旧，而是问题有没有被解决。

我认为设计工程给我最大的影响，就是让我始终从人和需求出发，同时又保留足够的工程能力，把这个需求快速变成一个可以被验证的系统。

---

Q2｜Ha7ch官网上写着“AI-native Builder Lab born at Stanford, the world's first FDE Accelerator”。为什么是“Accelerator”而不是“培训机构”或“咨询公司”？FDE加速器和传统YC-style创业加速器最大的区别是什么？

追问｜你们加速的到底是“人”（Builder成长为FDE）、还是“项目”（从0到1的产品）、还是“公司”（AI-native startup）？这三者在Ha7ch的体系里怎么排序？

Ha7ch 最早的起点，其实就是我在 Stanford 做科研助理的时候。

当时我和一些朋友就在讨论一件事情：未来会不会出现一种真正面向 AI Agent 的产品形态。我们那时候围绕 Claude Code 做了很多尝试，想做的不是简单地把 AI 加到原来的产品上，而是从一开始就让产品是 AI-native 的。

也就是说，它的交互方式、工作流和底层逻辑，本来就是为了让 Agent 去使用、去协作、去完成任务。

后来我回到国内，开始接触真实企业以后，我发现这件事情和企业的需求其实是不谋而合的。

企业当然希望变得更 AI-native，希望通过 AI 提效、降本，甚至重构原来的工作方式，但问题是，谁来梳理业务，谁来判断什么地方适合用 AI，谁来把这些需求做成真正能运行的产品？

我后来意识到，这个角色就是 FDE。所以 Ha7ch 从最早的 AI-native Builder Lab，逐渐变成了我们所说的 FDE Accelerator。

我们之所以把自己叫作 Accelerator，而不是培训机构，是因为 FDE 本质上不是靠上课学出来的。它需要真正进入企业，需要驻场，需要和老板、一线员工沟通，需要面对不清晰的需求、旧系统、内部阻力和真实业务压力。

这些东西很难靠一套课程模拟出来。

尤其是很多已经工作多年、承担家庭责任的人，并不一定有足够时间和试错空间去频繁进入不同企业场景，所以我们一开始会更关注学生和年轻 Builder。

这些人时间更灵活，愿意使用最新的 AI 工具，也更愿意进入一个陌生行业重新理解问题。

我们希望给他们的不是一套 FDE 课程，而是真实的试验田，让他们进入企业，看看自己能不能听懂业务，能不能发现老板表面需求背后的真问题，能不能做出真正被一线员工认可的东西。

现阶段最重要的是，让他们真正试一次，然后获得企业老板和一线用户的反馈。

因为现在很多 Builder 做出来的东西，本质上还是 toy demo，看起来很酷，但没有在解决真实问题。他们缺的不是再看一篇教程，而是一个进入现场的机会，真正去 solve the real problem。

这也是 Ha7ch 和 YC 相似的地方。

YC 很重要的一部分，并不只是那笔投资，而是它形成了一种校友文化、一个高密度网络和一种能力背书。一个创业者进入 YC，意味着他进入了一个优秀创业者彼此连接、彼此帮助的网络，同时 YC 本身也成为一种市场信任。

Ha7ch 希望在 FDE 领域形成类似的东西。

现在有很多人都可以说自己是 Builder，也可以把 title 改成 FDE，但谁真正有进入现场的能力，谁能梳理工作流，谁能和老板及一线员工沟通，谁能处理商务、产品和工程之间的复杂问题，市场其实很难判断。

未来如果一个人是 Ha7ch 最早一批在真实企业场景中成长出来的 FDE，这件事情本身应该成为一种能力背书。

我们已经在北京、上海、深圳、杭州等城市举办过线下活动，连接了大量正在做 AI 落地的人、Builder、行业从业者和企业资源。这个网络本身也在持续产生价值。

比如有人刚到深圳时几乎没有本地朋友，只参加了一次 Ha7ch 线下活动，后来就通过活动认识的人连接到了企业资源和新的机会。这种高质量的人与人之间的连接，也是我非常想长期建设的东西。

但 Ha7ch 和 YC 最大的区别是，YC 的核心起点是给公司资本，然后帮助公司快速增长；Ha7ch 的核心起点是给人真实场景，然后帮助一个 Builder 获得产业能力。

YC 的基本单位是公司，我们现在的基本单位是人。YC 用资金降低创业者启动公司的门槛，而我们用企业现场降低 Builder 从“会做产品”到“能解决真实问题”的门槛。

YC 通常是在项目和公司已经出现以后加速它，而 Ha7ch 更靠前，我们加速的是一个人成为 FDE 的过程，甚至是一个人找到值得创业的问题的过程。

另一个区别是，FDE 本身天然能够产生现金流。一个 Builder 只要真正为企业解决了问题，就有可能从项目中获得收入，所以他不一定需要先拿投资，才能开始这条路。

我们提供的不是一张支票，而是一个真实问题、一个企业入口、一群同行，以及完成第一次真实交付的机会。

所以在“人、项目、公司”这三者里，Ha7ch 当前最明确加速的是人。

项目是训练场，但不是 Ha7ch 最终要占有的资产；公司可能是长期结果，但不是我们现阶段强行推动的目标。

我们举办 Ha7ch 48 小时 FDE Sprint 的活动，把 Builder 放进真实企业，让他们在很短时间内梳理企业痛点、还原工作流、找到适合 AI 提效的环节，再做出一个足以让老板和一线员工产生直观感受的 Demo。

我们的作用是把合适的人和合适的企业匹配起来，并提供方法和环境。

后续如果双方要继续签约、商业化交付，可以由其他商业主体去完成，也可以由 Builder 自己推进，这不一定和 Ha7ch 绑定。Ha7ch 更希望保持人才网络和实验场的角色。

因此三者的排序应该是：先加速人，再通过项目验证人，最后其中一部分人可能从连续项目中发现真正重复的行业需求，进而创立公司。

从长期来看，我们希望被这些 Builder 服务过的企业，也逐渐成为更 AI-native 的公司。

因为我们筛选和培养的人，本身就是用 AI-native 的方式思考问题的，他们不会只想着给企业加一个聊天机器人，而会重新看工作流、组织方式和产品结构。

当然，最终采用什么方案，仍然要取决于企业的具体场景，而不是为了追求 AI-native 这个标签强行改变一切。

---

Q3｜你运营小红书个人账号，内容风格偏“工程师叙事+创业思考”。这个账号对Ha7ch的获客和品牌有什么实质性帮助？还是更多是你个人的表达出口？

追问｜你本人是不是也在扮演一个“超级FDE”的角色——深入产业现场，再把经验抽象成方法论？

其实我现在已经在慢慢偏离“工程师叙事”了。

过去大家可能会觉得我的内容更多是在讲技术、工程和项目，但现在我更想表达的是创业判断、客户现场和 FDE 相关的思考。

我不会再花很多时间单独解释某个模型、某个框架或者某项新技术，而是更关注这些技术最后进入了什么场景，解决了什么问题，为什么有的项目能落地，有的项目做完 Demo 以后就停在那里。

对我来说，这个账号现在更重要的作用，不是展示我懂多少技术，而是让不同的人产生连接。

Builder 可以通过内容看到真实企业里正在发生什么，企业主也可以通过内容理解 FDE 到底能为他做什么，已经在做落地的人则可以在这里交流各自的判断和经验。

这个账号对 Ha7ch 当然有非常实质性的帮助，因为现阶段整个 Ha7ch 在很大程度上仍然依附于我的个人 IP。

很多人并不是先认识 Ha7ch，再认识我，而是先看到了我的内容，认同了我的判断，之后才进入 Ha7ch 的活动和网络。

我希望 Ha7ch 未来能够逐渐形成自己的品牌和组织能力，但我也不认为它应该完全脱离个人。

尤其 FDE 本身就是一件高度依赖信任、现场经验和具体判断的事情，如果把 Ha7ch 做成一个完全机构化、没有具体人物表达的品牌，很容易失去“活人感”。

这对于 FDE 并不是一件好事，因为企业最终不是在购买一个抽象概念，而是在判断这群人到底懂不懂现场、敢不敢承担、有没有真实经验。

所以 Ha7ch 可以逐渐不再只依附于我，但不能变成一个只有官方口号、没有具体人的组织。

至于我是不是在扮演一个“超级 FDE”的角色，我觉得某种程度上是。

现在我会进入很多不同行业的现场，去工厂、物流企业、跨境团队、赛车队，直接和企业一把手以及一线员工交流。

因为我们希望邀请这些企业加入 Ha7ch 的黑客松或者 FDE Sprint，所以我不仅需要向他们解释 FDE 和 AI 提效，还要让他们理解 Ha7ch 想做什么、为什么值得开放真实问题、他们能够从中得到什么。

这个过程本身就是 FDE 工作的一部分：先建立信任，再了解业务，最后找到一个适合被验证的问题。

这些现场经历对我个人也有非常大的影响。

我以前在阿里、腾讯、MiniMax 这样的科技公司工作时，虽然接触了很多复杂的软件系统，但其实没有太多机会真正看到我们生活的世界是怎么被生产出来的。

进入工厂以后，我第一次认真看到流水线怎么运转，硬件怎么被制造，工人和管理者怎么协作，一个订单、一个零件或者一个产品是怎样经过一系列真实流程出现的。

这些经历不只是帮助我理解 FDE，也在充实我对商业、产业甚至整个社会运行方式的认识。

但如果说我已经把这些经验抽象成了一套完整的方法论，我觉得还没有到那个阶段。现在还没有达到量变引起质变的程度。

社群运营方面，我可能已经积累了一些相对清晰的方法，但 FDE 本身太零散了，不同行业需要的解法可能完全不同。

物流企业可能需要 AI 加 ERP 或者单据数字员工，跨境业务可能需要 Agent 工作台，赛车队需要的可能是飞书智能体和知识库，制造企业又可能关注视觉检测、巡检或者生产流程。

它们的技术形态、组织结构、评价指标和价值逻辑都不一样，所以现在如果说已经形成一套能够适用于所有行业的完整方法论，我觉得是不诚实的。

我现在更相信，有一部分 FDE 能力是可以训练的，但不可能通过一套课程快速把一个人培养成资深 FDE，就像不可能通过几个月课程培养出资深咨询师一样。

真正的行业判断和现场经验需要时间积累。

但我们可以训练一个有潜力的人，让他成为一个优秀的 FDE 初级选手或者“咨询实习生”：他有很强的学习能力和主动性，愿意进入现场，能够主动探寻业务问题，知道怎样访谈一线员工，也敢于继续追问客户提出的表面需求。

Ha7ch 现阶段真正想做的，就是先发现和训练这种底层能力，再让这些人在一个个真实项目里逐渐长出自己的行业经验和判断力。

---

二、FDE 定义：新瓶旧酒，还是新物种

Q4｜2025-2026年FDE（Forward Deployed Engineer）概念爆火，也有人质疑：这不就是换了英文title的“驻场工程师”或“外包交付”吗？你作为在中国较早系统性推广FDE的人，怎么回应这个质疑？

追问｜你定义的FDE和Palantir原版的FDE、以及模型公司现在招聘的FDE，核心差异是什么？有没有一个“中国式FDE”的独特之处？

我之前专门录过一个“十维度对比”的视频，把驻场工程师、外包、咨询、大厂 FDE 和土 FDE 放在十个不同维度里比较。

很多人一开始也会问我，FDE 不就是把原来的驻场工程师或者外包换了一个英文 title 吗？

但我觉得它们最根本的差异，不在于是不是坐在客户办公室工作，而在于起点和终点完全不同。

传统外包或者驻场工程师的起点，通常是方案已经基本确定。客户会告诉你，我要开发一个系统、增加一个功能、完成多语言适配，工程师接到需求后负责执行。

但 FDE 的起点往往是一个极其模糊的问题。

可能只是因为你去给一个物流老板装了一次龙虾，他突然跟你说：“我也想用 AI 提效，但我完全不知道应该从哪里开始。”

这才是 FDE 真正的起点。

它没有 PRD，没有确定方案，甚至连问题是什么都还不清楚。

FDE 需要进入现场，观察员工怎么工作，和老板、一线人员不断沟通，把这种极其模糊的需求逐渐梳理成明确的工作流，再变成 GitHub Issue，最后才变成生产级别的代码。

终点也不一样。

传统外包交付的终点往往是产品或者功能完成，验收以后就可以收款。这个产品最后有没有人使用，能不能真正帮客户获客、降本或者提高效率，通常不在外包团队的责任范围内。

但 FDE 更强调为结果交付。

在适合按效果结算的项目里，如果做出来的系统不能帮助客户产生有效线索、降低成本或者提升处理效率，那么这个东西本身就没有价值，也不应该仅仅因为代码写完了就获得全部费用。

这种愿意把自己的收入和客户结果绑定的能力，才是 FDE 的底气，也是它和普通外包、驻场开发最重要的区别之一。

当然，不是所有项目都能采用纯效果付费，但 FDE 的价值判断必须始终以客户结果为终点，而不是以功能列表为终点。

比如一家做跨境服装的企业，老板可能只会非常模糊地说：“我觉得 AI 能帮助我赚更多的钱。”

如果是传统外包模式，通常要等老板先提出一个明确需求，比如“我要给网站做多语言版本和不同地区的样式适配”，然后外包公司按照需求开发，收取五万元，项目结束。

至于网站上线以后能不能获得来自西班牙、葡萄牙或者其他地区的客户，通常和外包团队无关。

但 FDE 的工作要更靠前。

我们可能先分析他的获客方式、网站结构、目标市场和用户行为，然后发现他现在只有英文网站，而且整体还是中国式网站的表达和设计，并不适合不同国家的消费者。

基于这个判断，我们才可能提出：利用 AI 快速开发适配十八个国家语言和文化习惯的网站，再通过真实流量和有效客户数量验证结果。

在这种情况下，FDE 的商业模式也可能不是简单地说“我帮你做十八个网站，收三万元”，而是按照带来的有效客户或者线索结算，例如每个有效客户收取五元或十元。

如果十八个网站全部做完，却没有带来任何新的客户，那这些网站在商业上就是没有价值的。

外包交付的是十八个网站，FDE 交付的是新增客户。

这个例子非常清楚地说明了两者的区别：外包从确定方案开始，以功能完成结束；FDE 从模糊问题开始，以业务结果结束。

当然，FDE 也不是凭空出现的全新物种，它吸收了咨询、产品、工程、售前和实施的一部分能力。

但真正让这种模式在今天成立的最大变量，是 Claude Code、Codex 这一类 Coding Agent。

过去给一家企业做一套定制软件，需要一个完整团队，需要前端、后端、产品、测试和项目经理，成本可能达到几百万。

今天有了 Coding Agent，同样一套东西的生产成本可能下降一个数量级。

过去中小企业根本买不起定制化方案，但如果一套解决方案从两三百万降到二三十万，甚至变成一年四五万元的持续服务，它就开始进入大量中小企业可以接受的范围。

原来需要一个团队才能完成的交付，现在可能一个懂业务、懂产品、懂工程的人，加上 Codex 或 Claude Code，就可以完成。

所以我认为，Coding Agent 不是 FDE 的辅助工具，而是这一轮 FDE 真正能够爆发的前提条件。

我自己把 FDE 分成两类，一类是大厂平台型 FDE，另一类是土 FDE，也就是创业型 FDE 或 FDE OPC。

土 FDE 直接面对中小企业，没有一个必须销售的平台，也没有一个成熟产品在背后支撑。

他可以根据现场需求自由选择技术，用 GPT 就用 GPT，用 Codex 就用 Codex，需要做 AI 加 ERP 的增量插件就做插件，需要做知识库、工作台或自动化流程就做这些。

他最终交付的不是某一个固定产品，而是客户问题的解决方案。

这也是土 FDE 和传统软件销售非常大的差异。土 FDE 不先问“我手里有什么产品可以卖”，而是先问“这个客户到底需要什么”。

很多人也会问，这种一个人交付的模式，后续怎么维护。

以我现在服务的赛车队为例，客户会持续提出新的需求，但维护本身并没有想象中那么困难。

我最重要的工作不是每天亲自写大量代码，而是观察他们的工作流，把需求梳理清楚，再转成 GitHub Issue。

到了晚上，我可以让 Codex 或 Claude Code 去完成这些 Issue。

我真正不可替代的部分，是判断问题、澄清需求、定义边界，而不是机械地写每一行代码。

随着模型继续增强，越来越多系统的实现会变成“把需求整理准确，然后交给 Agent 执行”。

所以技术实现本身会越来越便宜，现场判断和需求定义反而会越来越贵。

大厂平台型 FDE 的逻辑则完全不同。

无论是 Palantir，还是国内的飞书、钉钉、阿里云，本质上都是基于一个成熟平台，为客户完成一定程度的定制化。

我之前去安徽探访一家工厂，他们已经采购了飞书，也购买了 AI 额度。飞书团队就会进一步询问，他们是否需要安全帽识别、烟火识别等能力，再把监控数据接入飞书多维表格。

因为客户已经购买了平台和额度，所以 FDE 服务可能作为附加服务提供。

派过去的 FDE 可能已经给二三十家工厂做过类似项目，他到现场以后确认摄像头型号、系统接口和流程，很快就能完成。

这就是典型的大厂 FDE：表面上看是在为某一家客户定制，实际上背后已经有成熟平台、标准组件和重复交付经验。

所以大厂 FDE 最终通常是在推动某个产品的销售、使用或续费。

Palantir FDE 背后是 Foundry，飞书 FDE 背后是飞书和多维表格，钉钉 FDE 背后是钉钉，模型厂商的 FDE 背后则是模型、API、Coding Agent 或云服务。

他们的优势是平台成熟、交付稳定、合规能力强，但也有天然限制：他们往往会把客户问题导向自己的产品。

土 FDE 的优势则是技术中立、灵活、能够服务大厂暂时覆盖不到的中小企业，但风险是容易变成低价外包，也缺少大平台提供的品牌、工程和售后保障。

因此我认为，FDE 并不是简单的驻场换皮。

只改 title，仍然按照客户 PRD 写代码，当然还是传统外包。

真正的变化有四个方面：

第一，FDE 的起点是模糊问题，而不是确定方案；

第二，FDE 拥有问题定义权，而不是只负责执行；

第三，FDE 的终点是业务结果，而不只是完成产品；

第四，Coding Agent 把定制软件的生产成本大幅降低，使一个人或小团队有可能完成过去需要完整组织才能完成的工作。

没有这些变化，它就是换皮；有了这些变化，它才是一种新的组织和交付模式。

至于中国式 FDE，我觉得现在仍然在探索中。

中国有大量制造、物流、跨境贸易和传统服务企业，内部存在非常多跟单、发单、审核、流转、录入和沟通流程，这些工作非常适合被 AI 部分自动化。

但中国市场也有一个非常现实的矛盾：企业愿意支付的价格比较低，而目前成熟 FDE 的人力成本又比较高。

Palantir 服务的往往是几百万、几千万甚至更大的项目，但中国大量中小企业可能只能接受几万到几十万元的预算。

这意味着中国式 FDE 必须更轻、更快、更依赖 Agent，也更强调嵌入现有系统，而不是重做一套平台。

未来随着更多大厂工程师和产品人才进入市场，加上 Coding Agent 进一步提高个人生产力，FDE 的供给和企业能够接受的价格可能会达到新的平衡。

我认为，中国式 FDE 最有可能形成的形态，不是缩小版 Palantir，而是大量懂行业、懂沟通、能够借助 Agent 独立完成交付的小型团队和超级个体。

---

Q5｜FDE模式的核心悖论是：既要“深入客户现场做定制”（不扩展），又要“把经验抽象成产品/方法论”（规模化）。Palantir用Ontology模型解决这个问题。你认为FDE应该如何处理定制化和规模化之间的矛盾？是“每个行业一套SOP”，还是“底层通用+行业适配层”？

追问｜有没有一个行业的知识是“无法被抽象”的——必须每次驻场重新摸索？那个行业是什么？

我觉得 FDE 的规模化，不一定首先来自把每个行业都做成一套标准产品，而是来自人的能力能够被复制和放大。

一个足够成熟的 FDE，尤其是 OPC 形态的 FDE，并不一定只能做一个行业。

因为很多企业场景表面上属于不同产业，但真正需要解决的工作流其实高度相似。

比如录单、跟单、审核、拆解文档、字段提取、异常流转，这些问题无论发生在卖衣服、卖鞋子、物流还是跨境贸易，底层结构都大差不差。

我们当然需要补充一定的 domain knowledge，但并不是每一次进入新行业，都要从零理解这个行业的全部知识。

关键是要区分两类问题。

第一类是核心专业判断，比如什么衣服值得卖、什么鞋子会成为爆款、哪种医疗器械更安全、某个诊断是否成立。

这些问题确实高度依赖行业专家，也很难由一个通用 FDE 快速迁移。

第二类则是嵌入行业内部的重复性工作流，比如录入、拆分、整理、核对、模板化、审批和异常处理。

FDE 更适合优先进入第二类问题，因为这些流程跨行业有很强的共性。

例如我们接触医疗器械场景时，并不是让 AI 去判断哪种医疗器械更好，也不是让系统代替医生或专业人员做关键判断，而是去处理其中大量脏活、累活和重复性工作。

比如把设计图纸拆解成零件，整理成模板，做字段归类，或者把原本需要人工反复处理的流程自动化。

这样既能产生明确价值，也不会越过专业判断的边界。

所以我并不认为 FDE 每进入一个新行业，就必须先成为这个行业十年的专家。

真正可以迁移的是识别工作流、判断什么适合自动化、快速做薄切片和推动落地的能力。

从这个角度看，我更认同“底层通用能力 + 必要的行业适配”，而不是每个行业都独立开发一整套重型方法论。

一个优秀 FDE 可以在多个行业中工作，但他必须知道哪些东西可以迁移，哪些地方必须依赖领域专家。

可以迁移的是工作流判断和工程能力，不能轻易迁移的是关键专业决策。

至于 Palantir 用 Ontology 解决定制化和规模化的问题，我认为首先要理解 Ontology 真正解决的是什么。

它不仅是把企业里的对象、关系和动作统一建模，更重要的是在复杂组织里建立一层可溯源、可审计、可进行权限控制和数据合规审查的治理结构。

一个数据从哪里来、经过了什么处理、谁有权限查看、谁做出了什么决策、出现问题以后能不能追责，这些对于政府、大型金融机构、跨国企业或者高度监管行业非常重要。

所以 Palantir 的 Ontology 本质上不仅在解决软件复用，也在解决复杂组织中的数据治理、责任边界和合规问题。

但我并不认为所有中国企业都需要照搬这条路径。

对于大型企业和强监管行业，Ontology 这一层可能非常有价值；但对于中国大量中小企业来说，它往往过于重。

很多中小企业首先要解决的，并不是一个决策是否可以被完整审计，也不是跨部门、跨国家的数据权限如何统一，而是今天还有五个员工在手工录单，一张 PDF 需要复制二十次，一个订单需要在微信和 Excel 之间反复确认。

在这个阶段，先搭建一套完整的本体、权限和审计体系，成本可能远高于实际问题本身。

我们接触的很多项目不是百万、千万级的大单，而是几万到几十万元的真实需求。

在这种情况下，如果一开始就建设复杂本体、统一数据模型和大型平台，客户可能还没看到价值，预算就已经消耗完了。

这就像解一道简单题，不需要先搭建一套极其复杂的求解系统。

对于中小企业，更现实的方式是先找到一个高频、边界清晰的流程，用 AI 或数字员工把它做好，再根据企业规模、风险和合规要求，逐步增加权限、日志、溯源和审计能力。

不是所有企业都需要一个缩小版 Palantir，它们更需要的是轻量、快速、能嵌入现有系统的解决方案。

所以我理解的规模化，不是把所有客户塞进同一套平台，而是三件事：

第一，把 FDE 识别问题和拆解工作流的能力训练出来；

第二，把跨行业重复出现的组件、模板和交付方式沉淀下来；

第三，在真正涉及关键行业判断、数据治理和合规责任的地方，引入领域专家和更完整的审计体系，而不是假装一个通用模型可以解决一切。

---

三、Ha7ch 的真实状态

Q6｜Ha7ch目前已在北京、上海、深圳、杭州建立本地网络。现在Ha7ch的社群规模大概是什么量级？活跃Builder有多少？从“加入社群”到“成为能独立驻场的FDE”平均周期是多长？

追问｜高校学生和“社会招聘”的工程师，哪个群体更适合做FDE？高校合作是签框架协议，还是有具体的课程、学分或实训嵌入？

Ha7ch 现在整个社群的规模大概在两千多人左右，其中相对活跃、持续关注 FDE、AI 落地和 Builder 相关机会的人，大概有五百到一千人。

这个“活跃 Builder”的口径并不是说这些人现在都已经能够独立做 FDE，而是指他们会持续参与讨论、参加线下活动、关注真实项目，或者本身就在做 AI 应用和企业落地。

我们的网络现在不只在国内，北京、上海、深圳、杭州都已经办过活动，在硅谷也开始有线下连接。

硅谷这边接触到的人，更多是大厂平台型 FDE，或者希望进入 Google、OpenAI、Anthropic 这类公司做客户工程、模型部署和企业落地的人。

国内尤其是深圳，则有很多更接近“土 FDE”或者 FDE OPC 的人，他们直接面对中小企业，用一个人或小团队完成需求发现、产品设计和交付。

至于从加入社群到能够独立驻场，平均需要多长时间，我们现在还没有一个成熟、可信的统计。

因为 Ha7ch 目前做的主要不是培训机制，而是筛选机制。

我们首先要解决的是：什么样的人真正具备 FDE 潜力，什么样的人只是会做 Demo，什么样的人能够进入现场、和老板及一线员工沟通，并且把模糊问题转成一个可以运行的系统。

我认为 FDE 很难通过一套短期课程批量培养出来，它需要真实项目、行业经验和多次现场反馈。

所以当前我们更希望先把筛选标准建立起来，例如通过 Echo 和 Delta 判断一个人是缺少需求发现能力，还是缺少端到端构建能力，再把合适的人匹配到合适的企业场景。

即使暂时还不能给出一个统一的培养周期，只要能够提高整个行业筛选 FDE 的准确度，我觉得本身就是一种正向的基础设施。

高校学生和社会招聘的人才，各有不同优势。

学生最大的优势是主动性强、学习速度快、时间更灵活，而且对 Claude Code、Codex 等新工具的接受度非常高。

他们愿意进入陌生行业，也更愿意连续花一两天做高强度的现场调研和原型。

但他们通常缺少企业沟通经验，不理解组织里的利益关系，也不一定知道一个系统从 Demo 到上线会遇到什么阻力。

社会招聘的人才则不能只理解成工程师。

事实上，做过产品经理、运营、解决方案、咨询或者创业的人，可能比纯工程师更容易具备 FDE 所需要的 Echo。

他们已经有成熟的沟通、协调和业务判断经验，知道怎么和客户交流，也知道如何从混乱信息中梳理问题。

纯工程师的 Delta 往往比较强，但如果长期习惯等待明确 PRD，不愿意见客户，也不一定天然适合 FDE。

当然，社会人才的现实问题是时间更少、机会成本更高，驻场一天的成本一定远高于学生，也更难接受一段没有稳定回报的探索周期。

所以我不认为学生和社会人才之间存在一个绝对优劣。

学生更像高潜力、低成本、需要现场成长的 Builder；成熟产品、运营或者行业人才则拥有更强的沟通和业务基础，但需要补足 AI-native 的构建能力。

理想的团队往往是把两者组合起来，而不是只从某一种背景里找人。

高校合作目前仍然处在探索阶段。

我们会尝试讲座、工作坊、企业真实课题和 FDE Sprint，但还没有到能够宣称已经建立成熟课程、学分体系或批量人才培养机制的程度。

整个 Ha7ch 开始系统性做 FDE 内容和社群，实际上也只有一个多月，不超过六十天，所以现在仍然是一个非常早期的阶段。

在这个时间点，更重要的是诚实地区分什么已经发生、什么正在验证、什么只是长期愿景。

任何组织如果在这么短时间内就宣称已经完整跑通了多个行业、建立了成熟培养体系，我都会比较谨慎地看待。

我们宁愿先把人筛对、把第一个真实项目做好，再逐渐回答平均培养周期和规模化合作的问题。

---

四、认知反转与行业判断

Q7｜你在阿里、腾讯、MiniMax都做过工程师，现在出来做Ha7ch。大厂内部有没有类似FDE的角色，比如解决方案架构师、客户成功工程师？你怎么看大厂平台型FDE与独立FDE之间的关系？

追问｜如果字节或腾讯明天宣布成立“FDE中台”，向所有企业客户派驻场工程师，独立FDE和FDE社群的价值在哪里？

我其实不认为自己现在是在做所谓的“FDE 基础设施”，我更准确的定位还是在做一个 FDE 社群，连接不同类型的 Builder、企业和正在做落地的人。

大厂内部当然已经有非常接近 FDE 的角色，像飞书现在就已经会向企业派驻相关工程师，帮助客户把飞书、多维表格、AI 能力和原有工作流结合起来。

所以我并不认为大厂做不好 FDE，也不认为 FDE 必须脱离大厂独立存在。

更准确的判断是，大厂平台型 FDE 和土 FDE、FDE OPC 之间存在非常清晰的市场分割。

像一些大型 AI 服务公司或者平台厂商，可以服务汇丰这类大型银行，因为这些客户有足够预算，也有复杂的安全、合规、审计和系统集成要求，需要成熟品牌、完整平台和大型交付团队支持。

但土 FDE 通常不会进入这样的市场，它服务的是大量中小型企业，例如小型物流公司、跨境贸易公司、区域制造企业或者传统服务业公司。

这些企业可能连飞书旗舰版都不愿意购买，不一定是因为产品不好，而是他们认为现有工具已经够用，也不愿意为一个大型通用平台持续支付较高费用。

在这种情况下，大厂 FDE 和土 FDE 面对的客户、预算、销售方式和交付模式完全不同。

大厂 FDE 的核心目标，通常还是帮助公司销售、部署和续费已有的通用产品。

飞书的 FDE 最终要推动飞书、多维表格和 AI 额度的使用，阿里云的团队要推动云服务、模型或者 Token 消耗，其他模型厂商也希望客户更深入地使用自己的 API 和平台。

FDE 在这里是一种非常重要的附加价值，它帮助客户把通用产品落到具体场景里，也帮助大厂降低客户采用门槛，但它最终仍然服务于平台产品的增长。

土 FDE 的逻辑则相反，它没有一个必须卖出去的平台，可以根据客户问题自由选择工具。

客户需要飞书就用飞书，需要钉钉就用钉钉，需要自己开发一个插件就做插件，甚至十年前的技术能够解决问题，也没有必要强行使用最新模型。

所以两者不是谁取代谁，而是服务不同层级的市场。

如果字节、腾讯、飞书或者阿里明天宣布成立更大的 FDE 中台，我觉得并不会直接消灭土 FDE，反而可能进一步教育市场，让更多企业理解 FDE 是什么。

大厂会优先服务合同规模更大、能够购买平台和云资源的大型客户，不可能为每一家年预算只有几万元的小企业投入大量售前和驻场资源。

而土 FDE 的机会，恰恰存在于这部分高度分散、非标准化、预算有限，但真实需求非常多的中小企业市场。

它的竞争力不是技术比大厂更先进，而是更轻、更快、更灵活，也更愿意从一个非常小的具体问题开始。

当然，土 FDE 也不能把自己简单定位成“更便宜的外包”。

如果只是低价写代码，大厂不需要亲自下场，传统外包公司就已经可以完成。

土 FDE 真正的竞争力应该是技术中立、问题导向和极低的交付成本。

他能够进入现场，把一个模糊问题梳理清楚，用 Agent 快速做出结果，并且不要求客户先采购一整套平台。

从长期来看，大厂 FDE 会继续服务大型企业，把成熟平台做得更深；土 FDE 则会覆盖大量大厂无法经济服务的中小企业。

两者之间不是直接竞争，而更像一套分层市场。

---

Q8｜你之前做Web3项目，现在All in AI+FDE。Web3那套“去中心化”“社区自治”的理念，对现在Ha7ch的社群运营有什么影响？还是说那段经历已经被你“清零”了？

追问｜Ha7ch的社群有没有借鉴Web3的治理机制？比如Builder的贡献度怎么量化、怎么激励？

Oh my God，这段经历居然也被挖出来了。

我之前确实做过 Web3 项目，叫 Snails Finance。

那段经历对我现在做 Ha7ch 还是有一定影响的，但我不会把 Web3 里的 DAO、Token 或者完全去中心化的治理机制原样搬过来。

我真正保留下来的，是“社区不应该永远只由创始人单向运营”这件事。

一个有生命力的社群，应该让成员逐渐参与建设、形成身份认同，并且在不同城市中长出自己的本地网络。

我们现在正在搭建的结构是 Meetup、Guild 和 GuildUp。

一个人最开始可以通过 Ha7ch 的城市 Meetup 进入社群。

Meetup 更像入口，它负责让新的人认识 FDE，认识当地正在做 AI 落地的 Builder、企业和行业从业者。

参加完 Meetup 后，他可以进入这个城市对应的 Guild。

Guild 不是一次性活动群，而应该成为他在这座城市长期存在的 FDE network。

比如北京、上海、深圳、杭州，每个城市都可以逐渐形成自己的 Guild。

每个 Guild 还会有相对积极的负责人或组织者。

他们不一定是传统意义上的“分公司负责人”，更像是当地网络的召集者。

他们会定期组织吃饭、咖啡局、企业参访或者小型交流，我们把这种持续性的聚会称为 GuildUp。

GuildUp 的作用，是让参加过一次 Meetup 的人继续见面，进一步了解彼此正在做什么，也进一步加深对 FDE、行业和企业落地的理解。

我觉得 GuildUp 非常有必要。

很多社群的问题是，大家在线下活动认识一次，加了微信、进了群，然后关系就停在那里。

一次 Meetup 可以产生大量弱连接，但如果没有后续的小规模、高频互动，这些连接很难变成真正的信任，也很难产生项目合作、职业机会或者行业知识交流。

GuildUp 的价值，就是把一次性的弱连接逐渐变成长期的强连接。

所以 Ha7ch 的增长逻辑不是不断把所有人拉进一个越来越大的微信群。

Ha7ch 总体上会持续举办 Meetup，连接新的 Builder 和企业；城市 Guild 则承接已经进入网络的人；GuildUp 让老成员之间继续形成更深的关系。

这会形成一个分层结构：Meetup 负责拓新，Guild 负责形成城市身份，GuildUp 负责提高连接密度。

Web3 经历对我的影响，主要就体现在这里。

我相信社区成员可以共同参与治理和运营，城市网络也不应该完全依赖我本人。

但我不会把“去中心化”当成目的。

尤其当 Ha7ch 进入真实企业项目时，仍然必须有清晰的负责人、质量标准和责任边界。

社区活动可以由成员共建，但商业交付不能靠投票，项目失败也不能因为“大家共同治理”就没有人负责。

至于 Builder 的贡献度如何量化和激励，我们现在还处于比较早期的阶段，我不想过早引入积分、Token 或者一套复杂的游戏化机制。

未来真正有价值的贡献，可能包括组织 GuildUp、连接企业资源、分享真实案例、帮助其他 Builder、参与 FDE Sprint，以及把项目经验沉淀回社区。

但这些贡献不一定都适合简单换算成一个数字。

我更希望 Ha7ch 最终形成的是一种声誉和身份系统。

一个人在某个城市持续组织活动、帮助成员、完成真实项目，大家自然会知道他是谁、信任他的能力。

对他最好的激励，也不一定是积分，而可能是更高质量的连接、企业机会、行业影响力，以及成为这座城市 Guild 代表人物的身份。

所以 Web3 那段经历并没有被我清零，但我留下的是社区共建、身份和网络的价值，放弃的是为了去中心化而去中心化。

Ha7ch 可以由更多人共同运营，但最终还是要以真实连接、真实贡献和真实项目为中心。

---

Q9｜2026年，海外和国内的大量公司都在招聘FDE，FDE从一个“冷门岗位”变成了“热门title”。这种过热会不会导致FDE概念的稀释——比如传统外包公司把驻场工程师改名叫FDE，培训机构的课程贴上FDE标签？

追问｜你们怎么防止“劣币驱逐良币”？Ha7ch有没有认证体系或质量背书，来区分“真FDE”和“假FDE”？

我觉得现在 FDE 这个概念确实已经开始出现鱼龙混杂的情况。

很多公司在招聘时，自己其实都还没有完全想清楚 FDE 到底应该负责什么，只是看到这个 title 变热了，就把原来的解决方案、售前、驻场开发或者 AI 应用工程师重新包装成 FDE。

与此同时，也开始有培训机构推出 FDE 课程，但很多内容更像是赶鸭子上架，把一些产品、咨询、AI 工具和项目管理知识拼在一起，就说可以快速培养一个 FDE。

我觉得这种现象一定会出现，因为任何一个新岗位变热以后，都会经历概念扩散、过度包装和标准混乱的阶段。

但我其实不会花太多精力去争论谁是真 FDE、谁是假 FDE。

FDE 本身就是一个很宽泛的岗位，它可以偏产品、偏工程、偏咨询、偏交付，不同公司对它的定义也会不一样。

你硬要说某个人不算 FDE，他也完全可以说自己在做 FDE，我觉得这种 title 之争本身意义没有那么大。

真正重要的不是他怎么称呼自己，而是他有没有进入真实现场，有没有把一个模糊问题梳理清楚，有没有做出真正被使用的东西，以及最后有没有产生结果。

市场最终会通过项目和交付把这些人区分开，而不是靠一场概念辩论区分开。

Ha7ch 目前也没有建立一套正式的认证体系或者质量背书机制。

我们现在更多还是通过社群文化、真实项目和成员之间的长期互动来维护质量。

因为如果一个组织刚刚开始做 FDE，就立刻推出一套考试和证书，然后自己定义标准、自己培训、自己发证，我觉得很容易重新变成一个培训生意。

FDE 最关键的能力又很难通过一场考试证明，它需要在真实企业中被验证。

未来我们可能会给真正参加过 FDE Sprint、黑客松或者企业项目，并且完成过真实交付的人一种身份，比如 Ha7ch Fellowship。

这个身份不应该只是“参加过活动”的纪念证书，而应该对应一段可以被验证的经历：他进入过什么企业，面对了什么问题，做出了什么系统，企业是否使用，以及他具体承担了什么。

我们更希望它是一种项目和社区共同形成的声誉，而不是一个上完课就能获得的认证。

所以 Ha7ch 未来即使做质量背书，也不会用“考试通过等于合格 FDE”这种方式。

更可能是通过项目档案、企业反馈、同行评价和持续贡献，形成一个人的能力记录。

是否叫 FDE 并不是最重要的，重要的是这个人做过什么，以及他的结果能不能被别人验证。

我们没有必要成为一个 title 警察，去判断谁有资格使用 FDE 这个词，但我们可以通过真实项目，让市场更容易看出谁真正具备这类能力。

---

Q10｜如果重来一次，从阿里/腾讯/MiniMax工程师到创立Ha7ch这条路，你会在哪个决策上做得不同？——是更早做社群、更早商业化，还是更晚定义标准？

追问｜有没有一个具体的“后悔药”时刻？那个决策当时是怎么做的，现在回头看错在哪里？

如果重新来一次，我可能会更早开始做自媒体。

因为我现在越来越发现，我其实挺适合做这件事，也真的喜欢这个过程。

我喜欢把自己看到的东西、做过的项目和形成中的判断分享出来，也喜欢通过内容和不同的人建立连接。

很多人会说我比较有网感，我自己也觉得，我对什么内容会引起讨论、什么表达方式更容易让人理解，可能确实有一些直觉。

我刚开始接触 FDE 的时候，基本上是一边理解这个概念，一边持续发布相关内容。

后来也有投资人跟我说，你可以试一下做 Growth Hacker。

我当时问他，Growth Hacker 到底是什么。

他说，很简单，我给你一个目标，你要在一个月之内做到一万粉，如果你能找到办法完成，你就是 Growth Hacker。

我当时就说，OK，let me try。

因为我自己平时用得最多的社交媒体就是小红书，所以就从小红书开始做。

但我最开始其实完全不知道，在小红书做到一万粉并不是一件特别容易的事情。

我当时只是不断试内容、试选题、试表达方式，看大家对什么有反应。

虽然没有完全在一个月内达到目标，但按照现在的进度，大概两个月左右也有机会接近这个结果。

这个过程让我发现，我不仅喜欢做内容，而且会把它当成一个产品和增长问题去研究。

所以如果让我回到从阿里离职、去 Stanford 做研究的那个阶段，我可能从那个时候就会开始持续记录和发布内容。

那段经历里其实有很多值得分享的东西，包括从大厂工程师转向研究、在不同文化和工作方式之间切换，以及我对 AI、Agent、产品和创业的一些认知变化。

如果当时就开始积累，可能会更早形成一个稳定的表达渠道，也会更早连接到现在这些 Builder、企业主和行业从业者。

但我不会把这件事理解成单纯追求粉丝或者流量。

真正让我觉得有意思的，是知识分享和人与人连接的过程。

我很喜欢把自己还在形成中的思考讲出来，也喜欢看到别人因为一条内容开始了解 FDE、加入 Ha7ch，或者找到新的项目和合作机会。

对我来说，自媒体不只是宣传工具，也是一种公开思考、快速获得反馈和建立社区的方式。

所以我真正会改变的决策，不一定是更早商业化，也不是更早定义标准，而是更早开始公开表达。

因为很多机会并不是等你把所有事情做完以后才出现，而是在你持续分享、持续和别人对话的过程中逐渐形成的。

---

五、前瞻与行动建议

Q11｜如果只能All in一个方向：继续深耕Ha7ch的“人才孵化+社群网络”（轻资产、规模化慢但壁垒深），还是全力扩张“驻场交付”（重资产、现金流快但人力密集），或者做“FDE SaaS工具”（把方法论产品化、卖软件不卖人头）？为什么？

追问｜选“人才孵化”怎么对抗“变现慢”的压力？选“驻场交付”怎么解决“规模化瓶颈”？选“SaaS工具”会不会和FDE“卖成果而非卖工具”的核心理念冲突？

如果只能 All in 一个方向，我还是会选择继续深耕人才孵化和社群网络。

它确实是一个相对轻资产的模式，前期规模化会比较慢，变现也不会像商业交付那么直接，但我觉得它一旦形成，壁垒会非常深。

尤其是在早期建立了人才密度、城市网络和社区认同以后，后面的人传人效应会非常强。

一个优秀 Builder 进入 Ha7ch，可能会再带来他的朋友、同事和行业资源；一个企业通过社群找到合适的人，也可能把更多真实场景带进来。

这个网络一旦开始自增长，速度可能会比单纯靠广告和销售扩张快得多。

至于商业化和现金流，我现在没有那么着急。

因为当一个社群真正有价值以后，它并不是完全没有变现方式。

未来可以通过企业赞助、联合活动、人才匹配、行业合作、FDE Sprint、项目共创，甚至基金会或产业资源的支持来维持运转。

但这些收入应该服务于社群，而不是让 Ha7ch 最后变成一个卖课机构、招聘中介或者纯商业交付公司。

我个人也确实更喜欢做社群。

我喜欢连接人，喜欢看到不同背景的人因为一次 Meetup、一场 GuildUp 或一个真实项目认识彼此，然后产生新的合作和机会。

这种长期网络给我的满足感，比单纯把交付团队快速做大更强。

所以我还是会继续深耕 Ha7ch，并尽量保持它的非盈利定位。

如果选择驻场交付，最大的风险是很容易陷入人力密集型扩张：项目越多，团队越大，管理和售后越重，最后可能变成一家传统项目制公司。

这个方向可以产生现金流，也有现实价值，所以可以由独立的商业主体去做，但它不是我个人最想 All in 的事情。

至于 FDE SaaS，我觉得现阶段也不应该过早去做。

因为我们现在对真实企业场景的积累还不够，如果太早把方法论产品化，很可能只是做出另一个 Agent 平台或者项目管理工具，但并没有真正解决 FDE 的核心问题。

工具应该从真实项目里长出来，而不是先假设所有 FDE 都需要一套统一软件。

所以我的选择不是单纯“放弃交付、只做社群”，而是以社群和人才为核心，保留少量真实项目作为训练场和反馈机制。

人才是主体，项目是验证，工具是沉淀，商业化是维持这套网络长期运转的手段，而不是最终目的。

---

Q12｜一年后的今天，FDE这个行业里哪些现在热门的玩法或公司会消失？反过来，哪些现在看起来冷门但会被证明是对的？

追问｜你提到“让最优秀的Builder在真实产业中成长为FDE、创业者与下一代AI公司创始人”。这个“人才→FDE→创业者”的漏斗，现在跑通到哪一步了？有没有Ha7ch出来的Builder已经创立了新的AI公司？

我觉得一年后的今天，现在看到的大多数 FDE 玩法其实都不会直接消失，因为它们背后的供需关系是成立的。

一边是企业普遍存在 AI 焦虑，需要做流程改造、效率提升和组织升级；另一边是大量工程师、产品经理、运营和其他高技能人才，会因为 AI 对原有岗位的冲击重新寻找自己的位置。

所以企业有需求，人才也需要转型，这个市场一定会长期存在。

它有点像相亲市场。

你可以说某个男生和某个女生匹配不上，但不能因此说整个相亲市场不存在。

FDE 也是一样，大型企业可能和小团队匹配不上，中小企业可能也承担不起大厂 FDE 的成本，但总会有一部分企业和一部分人才能够匹配成功。

真正需要解决的是匹配效率，而不是这个市场是否存在。

所以真正可能逐渐消失的，不一定是某一种组织形式，而是那些无法证明结果、只是把传统外包重新包装成 FDE 的模式。

比如仍然只是等待 PRD、按人头收费，或者只能做 Demo，却无法进入真实生产环境。

这些玩法不会因为改了一个名字，就自然获得长期价值。

最后市场还是会看系统有没有人用、流程有没有改变、企业有没有真正获得结果。

反过来，我觉得现在比较冷门，但长期可能被证明是正确的方向，是 AI-native 企业。

现在大家更关注的是如何给现有 ERP 增加 AI 功能，或者如何用更低的成本完成一次项目交付。

这些事情当然有价值，但如果只停留在简单提效，没有思考模型能力持续增强以后，整个企业的组织和系统应该如何变化，我觉得是不够的。

因为 AI 会越来越聪明。

今天它可能只能替代录入、整理、审核等一小部分工作，但未来它可能承担更多沟通、判断和执行。

如果企业系统从一开始就能够持续接入 AI，并记录人的修正和流程变化，那么随着模型变强，人工参与的部分就可以不断减少，公司整体的运转效率也会越来越高。

所以我更看好的，是一种能够随着模型进化而持续自我改造的企业，而不只是给传统系统加一个 AI 插件。

当然，从零开始做一家完全 AI-native 的公司，在今天仍然很困难，尤其是在国产模型、本地部署、可靠性和数据安全还没有完全成熟的情况下。

但我们也不能等到模型完全成熟再开始。

现在已经可以先进入企业，把简单、重复、劳动密集的工作逐步替换掉，然后随着模型能力增强持续迭代。

至于 Ha7ch 所设想的“Builder 成长为 FDE，再成为创业者和下一代 AI 公司创始人”这条路径，目前还处于非常早期的阶段。

我们系统性做 FDE 内容和社群只有两个月左右，如果现在就说已经跑通了完整漏斗，反而是不可信的。

Reddit 虽然是 YC 2005 年第一批项目，并且很早就被收购，但它真正形成后来意义上的规模和影响力，仍然经历了很多年。

所以一个项目或者一个人才网络，很早获得认可，并不等于它的长期价值已经被证明。

Ha7ch 现在真正验证的，只是漏斗最前面的部分：通过内容和 Meetup 找到 Builder，通过真实企业场景判断谁具备 FDE 潜力，再让一部分人进入 Sprint 或项目。

后面的独立交付、行业积累、发现创业机会和真正创立公司，都需要更长的周期。

我希望到今年年底能够出现第一批具体案例，比如有人通过 Ha7ch 进入真实企业，完成第一次独立交付，甚至发现一个值得长期投入的创业方向。

但这条路径最终是否成立，应该由未来几年真正走出来的人和公司证明，而不是由我们在成立两个月的时候提前宣布。

---

Q13｜如果只能给参加非凡大赏的观众——企业决策者、AI创业者、工程师转型者——一条关于“怎么让AI真正落地”的建议，你会说什么？

追问｜能否给出一个可以马上执行的具体动作或检查清单？比如“判断你的团队是否需要FDE的三个信号”或“选择一个FDE服务商的三个标准”？

如果只能给企业决策者、AI 创业者和准备转型的工程师一个“怎么让 AI 真正落地”的建议，我觉得第一件事不是继续听课，也不是再看更多行业报告，而是高强度地使用 Claude Code，并且用它做出大量原来想做、但因为时间和成本一直没有做出来的东西。

很多人会说自己用过 Claude Code，但如果你原来是怎么写代码的，现在只是把其中一部分代码交给 Claude Code 来写，我觉得还不够。

真正的质变来自使用频率足够高，高到你开始重新理解什么是 Agent、Agent 可以承担什么，以及一个人的能力边界到底可以被放大到什么程度。

我自己比较明显的质变，是开始使用每月 200 美元的套餐以后。

之所以会开这个套餐，是因为当时我同时维护了很多产品，一个月内大概做了八九个相对完整的产品，前后启动了十多个项目。

也是在那个阶段，我才真正意识到，一个人加上 AI 能够做的事情非常多。

以前凌晨三点想到一个想法，我可能先把它记下来，过几天再说，最后大概率不会做。

但现在我可以直接打开电脑，把背景、用户、需求和我想要的结果讲清楚，让 Agent 开始工作。

第二天早上，我可能已经能看到一个可以运行的版本，接着就可以发布、寻找第一批试用者，再根据反馈继续迭代。

只有当你以这样的频率不断从想法走到产品、再走到真实用户时，你才会真正理解 Agent 的能力，而不是停留在“它能帮我补代码”这一层。

所以，无论你是企业决策者、AI 创业者，还是准备转型的工程师，我都建议你先连续做出足够多的小项目。

这些项目不能只是放在本地自我欣赏的 Demo，最好能够被真实发布，吸引到真实用户，哪怕最开始只有十个人使用。

因为只有当产品真正面对用户，你才会遇到需求变化、部署、反馈、错误和维护问题，也才能理解 AI 到底帮助了你什么，又在哪些地方仍然无法代替人的判断。

第二个建议，是所有准备转型做 FDE 的人，都应该认真考虑做自媒体，也就是 Build in Public。

因为 FDE 最困难的问题之一，其实不是写代码，而是获客和建立信任。

你怎么让企业知道你能解决问题？怎么让下一个客户相信你不只是会做 Demo？

最有效的方法之一，就是把你在真实项目里遇到的问题、思考过程、失败、成果和方法持续记录下来。

比如你进入一家工厂，发现他们的订单流程有什么问题；你尝试了一个方案，在哪个环节卡住；你最后怎么重新设计工作流；上线之后人工修正率发生了什么变化。

这些都可以成为内容。

你每完成一个项目，不只是交付给当前客户，也应该把其中可以公开的认知沉淀下来，让它继续为你吸引下一个客户。

如果完全不做公开表达，只是埋头一个项目接一个项目地交付，那很容易重新变成传统外包。

项目结束以后，经验只留在自己脑子里，没有形成品牌、方法论和新的客户来源，也就没有复利。

很多优秀的独立设计师就是这样做的：他们并不是等到整个项目完成后才展示结果，而是在过程中持续分享新的配色、动效、版式和设计判断。

这些内容一方面吸引下一位客户，另一方面也在帮助他们沉淀自己的工作流。

FDE 也应该如此。

对于企业决策者来说，我觉得有三个信号可以判断自己的团队是否需要一个 FDE。

第一个信号很直接，就是你已经有明显的 AI 焦虑。

你知道同行开始使用 AI，也知道企业需要改变，但内部没有人能够把这件事具体化。

这个时候，与其继续开会讨论，不如找一个 FDE 进入现场做一次小规模尝试，或者参加一次 Ha7ch 的 Ha7chthon。

我们之所以把它叫 Ha7chthon，而不只是传统黑客松，是因为传统黑客松通常是在一个固定场地举办，大家围绕一个假设问题做 Demo；但 Ha7chthon 是企业在哪里，活动就在哪里。

Builder 直接进入真实企业，观察真实员工和工作流，在现场完成需求发现和原型验证。

它不是围绕一道命题比赛，而是围绕一家企业真正的问题工作。

第二个信号，是你的公司还在持续招聘人员，去承担一些你直觉上认为 AI 已经能够替代的重复工作。

比如录入、整理、审核、跟单、信息搬运和反复沟通。

如果你一边觉得这些工作很机械，一边又在不断招人填补，那么就值得让 FDE 进来看一看，判断哪些流程可以被重新设计。

这里不一定意味着直接裁掉多少人，而是要先看有没有必要继续用增加人头的方式解决问题。

第三个信号不一定是降本增效，而是你单纯希望企业继续进步。

我会把企业使用 AI 的动机分为两类，一类是明确的降本增效，另一类是企业进步。

有些老板并没有非常具体的 KPI，不一定要求利润立刻增长多少、成本立刻下降多少，但他希望五年后回头看，今天开始做 AI 是一个正确的决定。

尤其是一些厂二代或者正在接班的企业经营者，他们可能更关心公司未来是否仍然具备竞争力。

因为五年后的 AI 会发展成什么样，没有人能够完全预测。

如果现在就开始从 AI-native 的角度重新审视公司的流程、数据和组织，即使只是先做一个小尝试，也可能成为企业未来持续领先的基础。

FDE 不一定只负责砍成本，也可以帮助企业理解下一代工作方式应该是什么。

至于如何选择一个 FDE 或者 FDE 服务商，我觉得现在很难给出一套绝对标准，因为整个市场还很早，真正成熟的服务商也不多。

但有一个原则是，不要过于迷信 title、名校背景和各种包装，最重要的是看对方能不能在很短的时间内持续做出东西。

很多传统企业老板可能愿意因为对方是清华北大团队直接签单，却不愿意先花一笔钱让他们真正来试一试。

但如果是我，我反而愿意先承担差旅费用，再用一个相对合理、甚至偏高的日薪，让团队进入企业工作七天或者十四天。

到周期结束时，我再看他们到底理解了多少问题，做出了什么东西，系统是否有人愿意使用。

AI 时代的一个重要变化，就是交付速度可以非常快。

一个靠谱的 FDE 不应该两周都停留在写方案、做汇报和讨论需求，他应该不断 Deliver。

第一天梳理问题，第二天给出流程，第三天出现原型，后面持续根据反馈修改。

七天到十四天，其实已经足够判断一个人或者一个团队是否靠谱。

所以我会建议企业不要一开始就签一个特别大的合同，也不要只根据 PPT 和名头做选择。

先为一次真实、小规模、高强度的合作付费，看对方能不能进入现场、理解业务、快速构建，并持续交付。

FDE 最终不是靠说服证明自己的，而是靠在很短时间内做出可见结果证明自己的。