# HA7CH — Full Corpus

> HA7CH is an AI-native Builder Lab born at Stanford, the world's first FDE Accelerator. Founded by lawted (https://x.com/lawted2). This file bundles every essay published at https://ha7ch.com/writing for LLM ingestion. Each essay is also available individually at /writing/{slug}/md.

# The Ultimate Business Model for FDE / FDE 的终极商业模式

> Published 2026-08-11 · By lawted · Canonical: https://ha7ch.com/writing/fde-ultimate-business-model

## English

I want to talk about a business model we have been developing. It may still sound abstract to many people, so let me start with a concrete example.

Suppose we are serving a traditional company valued at RMB 400 million. After an AI-native transformation, we believe its valuation has the potential to grow to RMB 800 million.

During that process, the FDE still charges the normal delivery fee: RMB 100,000 when the work is worth RMB 100,000, or RMB 200,000 when it is worth RMB 200,000. Ha7ch already does not take a cut from the work between the FDE and the company. What we really want to do is go beyond the service engagement, invest another RMB 3 million for a corresponding equity stake, and bet alongside the company on its future after the AI-native transformation.

If the company truly grows from a valuation of RMB 400 million to RMB 800 million, the equity acquired through our initial RMB 3 million investment could become worth RMB 6 million.

At the same time, we would allocate RMB 300,000 worth of that equity as a staged incentive for the FDE deployed on site. A portion would vest each time the FDE completes a transformation milestone. If the company reaches a valuation of RMB 800 million, that original RMB 300,000 equity incentive could become worth RMB 600,000.

This is what we currently see as the ultimate business model for FDE.

Once an FDE truly enters a company, they develop an unusually deep understanding of it: whether senior leadership has vision, whether middle management can manage and execute, and how efficiently frontline teams operate; where the business sits in its ecosystem and whether it has room to grow; which workflows AI can actually transform and how much real value that transformation can create.

None of this can be seen clearly from a conventional due-diligence process conducted in a meeting room. An FDE uncovers it gradually by solving real problems and working alongside the company over time.

That is why I believe that if we genuinely serve ten or twenty companies, we will have a chance to identify three or five that deserve long-term investment. At that point, Ha7ch will no longer be only a community connecting FDEs and enterprises. It will become a true AI-native investor.

We do not make money by taking a cut from an FDE's outsourcing income. We share with the FDE and the company in the long-term value that AI transformation actually creates.

In the future, Ha7ch will select not only exceptional FDEs, but also exceptional traditional companies. Strong FDEs will earn Ha7ch's recognition, and strong companies will earn both our recognition and our investment.

Just as a startup might say that it received investment from YC, an exceptional traditional company may one day be able to say:

We received investment from Ha7ch.

That would mean it is not merely a well-run traditional company. It is a company willing to embrace AI, capable of thinking in AI-native terms, and positioned to grow into an AI Native Company.

## 中文

跟大家聊一下我们最近想出来的这个商业模式。可能很多人听起来还是有点抽象，那我直接举个例子。

假设我们现在服务一家估值 4 亿元的传统企业。经过 AI Native 改造以后，我们判断它的估值有机会增长到 8 亿元。

在这个过程中，FDE 该收 10 万元服务费就收 10 万元，该收 20 万元就收 20 万元，正常的交付费用不变。Ha7ch 本来就不会从 FDE 和企业的合作中抽成，我们真正想做的是在服务之外，再投入 300 万元，拿到这家企业相应的股权，与企业一起押注 AI Native 改造后的未来。

如果企业的估值真的从 4 亿元增长到 8 亿元，那么我们最初投入 300 万元获得的股权，就可能价值 600 万元。

同时，我们还会拿出其中价值 30 万元的股权，分批激励给驻场的 FDE。FDE 每完成一个阶段的改造目标，就归属一部分股权。当企业估值增长到 8 亿元时，他原本价值 30 万元的股权，也可能增长到 60 万元。

这就是我们现在设想的 FDE 终极商业模式。

因为 FDE 真正进入企业以后，对这家企业的了解会非常深入：高层有没有远见，中层有没有管理和执行能力，基层的工作效率怎么样；这家企业的业务处于什么生态位，未来有没有增长空间；AI 到底能够改造哪些流程，又能带来多大的真实价值。

这些都不是坐在会议室里做一次普通尽调能够看清楚的。FDE 是在真实解决问题、与企业长期共事的过程中，把这些事情一点点摸清楚。

所以我认为，只要我们真正服务十家、二十家企业，就有机会从中发现三家、五家值得长期投资的企业。这个时候，Ha7ch 就不再只是连接 FDE 和企业的社区，而会成为一个真正的 AI Native 投资人。

我们不靠 FDE 的外包收入赚钱，而是和 FDE、企业一起分享 AI 改造真正创造出来的长期价值。

未来，Ha7ch 不仅会筛选优秀的 FDE，也会筛选优秀的传统企业。优秀的 FDE 会得到 Ha7ch 的认可，优秀的企业同样会得到 Ha7ch 的认可和投资。

就像一家创业公司会说自己拿到了 YC 的投资一样，未来一家优秀的传统企业也可以说：

我们拿到了 Ha7ch 的投资。

这意味着它不仅是一家经营不错的传统企业，更是一家真正愿意拥抱 AI、具备 AI 思维，并且有机会成长为 AI Native Company 的企业。


---

# The Enterprise AlphaGo Moment / 企业的 AlphaGo Moment

> Published 2026-08-10 · By lawted · Canonical: https://ha7ch.com/writing/enterprise-alphago-moment

## English

After running two FDE hackathons, I have a more precise understanding of what “48 hours” means.

In Lawted’s 48 Theory, 48 hours has never been a delivery promise to the outside world, nor a demand that a team finish an enterprise AI transformation in two days. It is only the first decomposition: enter the company within a deliberately short window, understand a workflow, and find one piece of real evidence worth investing in.

Ideally, that evidence creates an AlphaGo Moment inside the company.

An enterprise AlphaGo Moment is the first time AI produces a specific, verifiable result inside the company’s own work—one strong enough to change the next decision.

AI does not have to defeat a person, and the system does not have to be complicated. It might catch one error in a human record, compress several hours of work into minutes, or link a result back to the original file for the first time.

The size of the result is not the point. The point is whether the company can verify it with its own hands.

Compressed into one line: the value of a demo is evidence, not performance.

1. Map one surface, then break through one point

When we entered the second FDE hackathon, we did not start building from a single sentence spoken by the boss. We first completed two sets of interviews.

The boss described the problem he could see. Managers described checks and accountability. Frontline workers described what actually happened every day. Only by combining those roles could we see the full workflow.

That is the “surface.”

The surface must clarify at least five things: where real inputs come from, which people they pass through, who makes the judgment, who handles exceptions, and where the final result goes.

But workflow mapping alone turns into consulting. The company gets a picture of the future without knowing whether the team can build any of it.

So we also need to break through one point.

The point should not be 20 percent of every module in the grand plan. It should be one narrow, real chain completed end to end.

We chose one kind of real material, one concrete task, and one result that could be checked on site. When the demo returned an OCR result, it also preserved the original image and exact location. It did not cover the company’s entire knowledge base or try to solve every workflow. It completed one crucial judgment loop.

So “one surface plus one point” is not a slogan.

The surface proves that the FDE understands the company. The point proves that the FDE can change it.

A surface without a point becomes a slide deck. A point without a surface becomes an isolated feature.

2. The real shock comes from the evidence chain

During that demo, the AI result disagreed with a human record.

The first reaction in the room was that the AI had made a recognition error. But after reopening the original image through the demo’s source link and locating the exact evidence, everyone confirmed that the AI record was correct and the human spreadsheet was wrong.

What changed the company’s judgment was not a beautifully generated answer or a sophisticated interface.

When the human and the AI disagreed, the system did not ask the company to “trust the model.” It took everyone back to the original evidence.

The result met four conditions:

- It used real business material;

- It was specific enough to judge right or wrong;

- Every conclusion could be traced to the original source;

- After verification, the company wanted to discuss the next step.

That is an enterprise AlphaGo Moment.

AlphaGo was shocking not because it could describe its capabilities, but because it made a move on a board everyone understood—a move humans had not imagined.

Enterprise AI is the same. The shock does not come from a model explaining itself. It comes from an evidence chain the company can independently verify.

We therefore made the standard for an on-site demo very hard: if a result cannot be traced to the original source, it does not count as evidence.

A chatbot that can answer questions is not enough. A prearranged successful demo is not enough. The system must consume real inputs, preserve sources, record human corrections, and make failures visible.

3. Architecture must be decided after entering the site

The second hackathon also overturned many of our technical assumptions.

The materials were not clean Markdown files. They were large collections of PDFs, images, and heavy project files. Upload time, network speed, remote retrieval, and source traceability quickly became more immediate constraints than model capability.

Architecture, we learned, cannot be chosen by personal preference. It must be shaped by the form of the company’s Context.

If the company mainly has Markdown, small files, and low data volume, a Light mode in which individual Agents read directly may be enough.

If the company has large volumes of images, PDFs, and multi-gigabyte project files, keeping files and execution close to the company through hosted or local deployment is more reliable. Otherwise, half of the 48-hour window can disappear into uploads.

The same logic applies to RAG.

When a single business object can be covered by direct files, structured summaries, and deterministic retrieval, there is no reason to build a second index just to appear technically complete. Reconsider RAG only when cross-project similarity search becomes necessary, one object consistently overflows context, or glossaries and summaries still cannot bridge the semantic gap.

Connecting to the company’s existing IM only solves the entry point.

Employees can start tasks from Feishu, DingTalk, or another IM, but the IM is a Gateway, not the company’s brain. Context, files, Skills, permissions, and feedback records still require a clear source of truth and execution environment.

The technical judgment from that hackathon fits in one sentence: absorb the Context first, then let the Context decide the architecture.

4. Count the people at the workflow entrance first

At another manufacturing site, we corrected another assumption.

Faced with paper forms, our initial instinct was to preserve employee habits and add OCR to structure the contents.

That looked reasonable, but further investigation showed that the people actually filling in the forms were not the whole factory. They were roughly 30 workshop supervisors.

If the real entrance consists of only 30 people, a small training session and direct submission through Feishu may be cheaper than building, maintaining, and correcting OCR over the long term.

But if the entrance includes more than 700 factory workers, asking everyone to register for a new tool, learn a new process, and change habits creates a much larger adoption cost. Preserving the paper form and adding an OCR adapter can then be the better design.

An FDE should therefore neither mechanically insist on “never changing user habits” nor demand a new workflow for everyone whenever AI appears.

The correct judgment compares total costs: the cost of changing habits versus the cost of building and maintaining an automation adapter.

That comparison is impossible until the team enters the site and counts the people who truly operate the workflow.

Thirty supervisors and seven hundred workers require entirely different product designs.

5. A hackathon is not a feature-count competition

After several field projects, we no longer judge an FDE hackathon by how many pages, models, or features appear within 48 hours.

The first stage should leave behind five things:

1. A workflow map validated through interviews with multiple roles;

2. A demo narrow enough to finish but complete enough to close the chain;

3. Real inputs and the original evidence behind every result;

4. A record of successes, failures, and human corrections;

5. One clearly defined question for the next stage.

Evaluation cannot look only at accuracy.

We also record the original task time, AI task time, usable-field rate, task completion, human correction items, traceability, and whether failure is explicitly visible.

The test set must include normal, boundary, and exceptional cases.

Normal cases validate the main path. Boundary cases test missing fields, ambiguous inputs, and oversized material. Exceptional cases test conflicting sources, permission violations, prompt injection, and tool failure.

If every test case was preselected to succeed, the demo proves only that the team can perform—not that the system can enter the company.

The most important signal is not “finished.” It is whether the company will continue to open real materials, assign real users, and enter another round of validation.

6. Forty-eight hours is only the first cut

In Lawted’s 48 Theory, 48 hours is only the first cut in an enterprise AI transformation.

In 48 hours, find one surface and one point, then establish the first verifiable piece of value evidence with real material.

In 48 days, put the demo into real use and distill employee acceptance, edits, rejection, and exceptions into enterprise Context, Skills, workflows, permissions, and Evals.

In 48 weeks, let validated Agents take on end-to-end tasks and redraw responsibilities, permissions, and risk between humans and AI, ultimately changing the organization itself.

So 48 hours is not delivery, and it does not necessarily mean a formal project has begun.

It is closer to a high-density joint investigation: the company observes whether the FDE deserves trust, while the FDE judges whether the company’s problem, materials, people, and organization deserve further investment.

The two sides are not looking for a grand blueprint. They are looking for one fact small enough to verify, real enough to matter, and strong enough to move the next step.

A company does not begin its AI transformation when the boss first understands AI or when the company first buys model accounts.

It begins when the company verifies an AI result inside its own work and is willing to act on it.

That is the enterprise AlphaGo Moment.

## 中文

做完两期 FDE 黑客松以后，我对「48 小时」有了一个更准确的理解。

在劳泰德 48 理论里，48 小时从来不是一个对外承诺的交付周期，也不是要求团队两天做完一家企业的 AI 改造。它只是第一层拆解：用一个足够短的时间窗口进入企业、理解工作流，并找到一个值得继续投入的真实证据。

这个证据最好能够制造一次企业的 AlphaGo Moment。

所谓企业的 AlphaGo Moment，是 AI 第一次在企业自己的业务里产生一个具体、可核验，而且足以改变下一步决策的结果。

它不一定是 AI 战胜了人，也不一定需要一个复杂系统。它可以只是发现一条人工记录错误，把几个小时的工作压缩到几分钟，或者第一次把结果准确地回链到原始文件。

关键不在于结果有多大，而在于企业能不能亲手验证它。

压到最短就是：Demo 的价值是证据，不是表演。

一、先做一个面，再打穿一个点

第二期 FDE 黑客松进场以后，我们没有拿着老板的一句话直接开工，而是先完成了两组访谈。

老板描述的是他看到的问题，管理者描述的是检查和责任，一线人员描述的才是每天真正发生的操作。只有把不同角色拼起来，才能看见完整工作流。

这就是「一个面」。

这个面至少要把五件事说清楚：真实输入从哪里来，中间经过哪些人，谁负责判断，出现异常时谁来处理，最终结果进入哪里。

但只做工作流梳理，会退化成咨询。企业得到一张未来蓝图，却不知道团队能不能真正做出来。

所以还需要打穿「一个点」。

这个点不能是把完整方案里的每个模块都做 20%，而应该选择一条足够窄的真实链路，把它 100% 跑通。

我们最终选择的是一种真实材料、一个具体任务和一个能够现场回查的结果。Demo 返回 OCR 结果时，同时保留原始图片和对应位置。它没有覆盖整个企业知识库，也没有试图一次解决全部业务，只是把一个最关键的判断闭环做完整。

所以「一个面＋一个点」不是一句口号。

面负责证明 FDE 理解了企业，点负责证明 FDE 能够改变企业。

只有面，会变成 PPT；只有点，会变成孤立功能。

二、真正的震撼来自证据链

那次演示里，AI 给出的结果与人工记录出现了分歧。

现场第一反应是 AI 识别错了。但沿着 Demo 返回的来源重新打开原始图片、找到对应位置以后，大家确认这一次是 AI 记录正确，人工表格反而出现了错误。

那一刻真正改变企业判断的，不是模型生成了一段漂亮答案，也不是我们做了一个多复杂的界面。

而是人和 AI 发生分歧时，系统没有要求企业「相信模型」，而是把所有人带回了原始证据。

这个结果同时满足了四个条件：

- 使用的是真实业务材料；

- 结果具体到可以判断对错；

- 每个结论能够回查原件；

- 核验以后，企业愿意继续讨论下一步。

这才是企业里的 AlphaGo Moment。

AlphaGo 让人震撼，不是因为它会介绍自己的能力，而是因为它在一个所有人都看得懂的棋盘上，走出了一步人类没有想到的棋。

企业 AI 也是一样。震撼不来自模型的自我解释，而来自一条企业能够独立复核的证据链。

所以我们后来把现场 Demo 的标准改得非常硬：结果不能回查原件，就不能算作证据。

一个能回答问题的聊天框不算，一个提前准备好的成功演示也不算。系统必须吃进真实输入，保留来源，记录人工修改，并允许失败被看见。

三、架构必须在现场以后决定

第二期黑客松还推翻了我们很多进场前的技术假设。

现场资料不是整理好的 Markdown，而是大量 PDF、图片和体积很大的项目文件。文件上传、网络速度、远程检索和原件溯源，迅速成为比模型能力更现实的问题。

这时我们才发现，架构不能靠个人偏好决定，而要由企业 Context 的形状决定。

如果企业主要是 Markdown、小文件和低数据量资料，可以先使用 Light 模式，让个人 Agent 直接读取。

如果企业有大量图片、PDF 和多 GB 项目资料，把文件和执行放在企业附近，采用托管或本地模式会更稳定。否则 48 小时可能有一半都耗在上传文件上。

是否使用 RAG 也是同样的逻辑。

当单个业务对象可以被直接文件、结构化摘要和确定性检索覆盖时，不需要为了显得技术完整，提前建设第二套索引。只有出现跨项目相似案例检索、单个对象持续溢出上下文，或者术语表和摘要仍然无法解决的语义鸿沟时，才重新评估 RAG。

现场接入企业已有 IM，也只能解决入口问题。

员工可以从飞书、钉钉或其他 IM 发起任务，但 IM 只是 Gateway，不是公司的大脑。真正的 Context、文件、Skills、权限和反馈记录，仍然需要一个清晰的真相源和执行环境。

这场黑客松留下的技术判断可以压成一句话：先吸收 Context，再让 Context 决定架构。

四、先数清流程入口有多少人

另一次制造业现场里，我们又修正了一个原来的判断。

最开始面对纸质单据，我们倾向于不改变员工习惯，保留原来的填单方式，再通过 OCR 把内容结构化。

这个方案看起来合理，但现场进一步梳理后发现，真正填写单据的人并不是全厂员工，而是大约 30 名车间主管。

如果实际入口只有 30 人，组织一次小规模培训，让这些主管直接通过飞书提交信息，可能比长期建设、维护和纠正 OCR 更便宜。

但如果入口是全厂 700 多名工人，让所有人注册新工具、学习新流程并改变工作习惯，推广成本就会非常高。这种情况下保留原单据，再增加 OCR 适配层反而更合理。

所以 FDE 不能机械地坚持「绝不改变用户习惯」，也不能看到 AI 就要求所有人换一种工作方式。

正确的判断是比较两边的总成本：改变习惯的成本，与维护自动化适配层的成本，哪一个更低。

而这个问题只有进入现场、数清真正的流程入口人数以后才能回答。

30 名主管和 700 名工人，面对的是完全不同的产品设计。

五、黑客松不是比谁做的功能多

经过几次现场以后，我们判断一次 FDE 黑客松，不再看 48 小时内做出了多少页面、接入了多少模型或者堆了多少功能。

第一阶段真正需要留下的是五样东西：

1. 一张经过多角色访谈验证的工作流图；

2. 一个范围足够窄、但链路完整的 Demo；

3. 一套真实输入，以及结果对应的原件证据；

4. 一份成功、失败和人工修正记录；

5. 一个明确的下一阶段问题。

评测也不能只看准确率。

我们会同时记录原任务需要多长时间、AI 需要多长时间、字段可用率、任务完成率、人工修正项、依据是否可追溯，以及系统失败时是否明确暴露。

测试数据至少要包含典型、边界和异常三类。

典型用例验证主流程；边界用例检查缺字段、模糊输入和超长材料；异常用例检查资料冲突、权限越界、提示注入和工具失败。

如果测试集里全部是提前挑选的成功案例，Demo 只能证明团队会演示，不能证明系统可以进入企业。

最重要的指标也不是「做完了」，而是企业是否愿意继续开放真实材料、安排真实使用者，并进入下一轮验证。

六、48 小时只是第一刀

因此，在劳泰德 48 理论里，48 小时只是企业 AI 改造的第一刀。

48 小时，找到一个面和一个点，用真实材料建立第一条可核验的价值证据。

48 天，让 Demo 进入真实使用，从员工的接受、修改、拒绝和异常处理中，沉淀企业 Context、Skills、工作流、权限和 Evals。

48 周，让经过验证的 Agent 开始承担端到端任务，重新划分人和 AI 的责任、权限与风险，最终改变企业的组织方式。

所以 48 小时不是交付，甚至不一定代表一个项目正式成立。

它更像一次高密度的共同调查：企业在观察 FDE 是否值得信任，FDE 也在判断企业的问题、资料、人员和组织是否值得继续投入。

双方最终要找到的，不是一张宏大蓝图，而是一个足够小、足够真实、足以推动下一步的事实。

一家企业真正开始 AI 改造，并不是老板第一次听懂 AI，也不是公司第一次购买大模型账号。

而是它第一次在自己的业务里验证一个 AI 结果，并愿意根据这个结果采取行动。

这就是企业的 AlphaGo Moment。


---

# The Zero-Middle-Management Company / 0 中层公司：AI Native Company 的下一种组织形态

> Published 2026-08-03 · By lawted · Canonical: https://ha7ch.com/writing/zero-middle-management

## English

An AI Native Company can be defined one step further: a "zero-middle-management company." Zero middle management does not mean no managers, and it does not mean everyone reports directly to the boss. It means the company no longer keeps a permanent layer of people whose main job is aggregating information, passing down instructions, coordinating resources, and supervising process. The coordination work that middle managers used to do gets decomposed into company Context, Skills, Agents, Evals, a permission system, and dynamic DRIs. Managing people still exists — but management no longer automatically comes with a permanent position.

Compressed to one line: traditional companies route information through people; an ANC routes information through systems. Traditional companies bind power to positions; an ANC binds power to outcomes.

Two clarifications up front.

First, zero middle management is not zero management. A company still needs strategy, delegation, arbitration, talent development, conflict resolution, and risk governance. What disappears is the management layer whose main value is moving information around. What stays are the people accountable for outcomes.

Second, zero middle management is not a layoff plan. It is what a mature organization looks like after its capabilities have grown. If a company has no Context, Skills, Agents, Evals, permissions, or audit, firing the middle layer will not produce an AI Native Company — just a company that has lost the ability to coordinate itself.

1. Org charts were always an information technology

Why does every company, past a certain size, inevitably grow a middle layer?

The root cause is not that bosses love bureaucracy. It is that human bandwidth is finite.

A founder can directly understand what five people are doing, but cannot continuously understand what five hundred people do every day. As the organization grows, the company has no choice but to split people into teams, give each team a lead, and hand several leads to a manager one level up.

Employees report to team leads, team leads report to department managers, managers report to directors, and the director finally compresses everything into a slide deck for the boss. Once the boss decides, instructions travel back down the same chain.

So a traditional org chart looks like a division of power, but is really an information system made of people. Every middle layer performs three functions: compress information, relay instructions, coordinate resources.

Middle management is not accidental redundancy. It was the industrial era's infrastructure for scaling organizations. But the system has one unavoidable flaw: information loses fidelity every time it passes through a layer.

A customer says ten things on site. The frontline employee remembers eight, reports five to the manager, three make it into the weekly report, and what reaches the boss's slide might be a single line: "The customer has some concerns about the system experience."

It works the same way downward. The boss asks for "higher customer renewal rates." A few layers of decomposition later, it becomes daily call quotas, forms to fill, and process metrics that have nothing to do with customer value.

So traditional companies live inside a contradiction: the bigger the company, the more it depends on middle layers; the more middle layers, the further the company drifts from real work and real customers.

There used to be no better option, because organizational information could only be understood, summarized, and relayed by humans. That premise has now changed for the first time.

2. The first thing AI replaces may not be employees, but the information routing layer

Today, most so-called AI transformation means buying every employee a large-model subscription.

Employees use AI to write documents, managers use AI to summarize them, directors use AI to turn summaries into briefings, and the boss uses AI to read the briefing. Everyone looks more efficient, but the company's information structure has not changed at all.

A weekly report that took two hours now takes ten minutes; consolidating reports that took half a day now takes half an hour. The result is not that the company got closer to its customers — it is that the old pyramid can now produce more weekly reports.

That is not an AI Native Company.

An AI Native Company does not install a copilot at every node of the traditional org chart. It asks a different question: do these nodes still need to exist?

If customer feedback, project records, meeting notes, contracts, code, orders, quotes, and financial data are already digital, an Agent can read that raw Context directly and continuously work out what is happening in the company: which project is slipping, what the customer actually asked for, where work is being redone, which decisions have already been made, and who should act next.

The boss no longer waits through three layers of reporting to learn what happened on the front line. Employees no longer need three layers of approval to get the background, methods, and resources a task requires.

So AI's biggest impact on organizations may not be one employee doing the work of two. It is the company no longer needing layer after layer of people to move information around.

Once organizational Context can be understood directly by AI, the middle layer's most important function — information routing — starts losing its reason to exist.

3. Zero middle management does not mean nobody is accountable

The easiest misreading of the "zero-middle-management company" is imagining a company with no management and no boss, where hundreds of people fully self-organize.

That is not realistic.

An AI Native Company still needs clearly accountable owners. What changes is not whether responsibility exists, but how responsibility is produced.

In a traditional company, power comes from position. Because you are the department manager, the department's budget, hiring, projects, and information all flow through you. Whatever the company's most important problem is right now, you permanently occupy that layer of the organization.

In an ANC, power comes from outcomes. Because you are responsible for "deploying the quoting Agent to the front line at 80% adoption within the next 48 days," you temporarily hold the power to mobilize the relevant people, data, and systems. When the task ends, the mandate can end too, or move to another problem.

That is the DRI — the Directly Responsible Individual.

A DRI does not need permanent reports, and does not need to own a department before they can solve a problem. They simply carry final responsibility for a specific outcome over a specific period of time.

So a zero-middle-management company is not everyone reporting to the CEO. It is most work no longer being organized through reporting lines, but through tasks, outcomes, and dynamic mandates.

Traditional companies create positions first and pour tasks into them; an ANC lets problems appear first, then organizes people and Agents around the problem.

4. The middle layer is not replaced by one Agent, but decomposed by a system

"Replace all middle managers with one AI manager" is another oversimplification.

The middle layer's work breaks down into at least five categories:

| Traditional middle-management function | What takes it over in an ANC |

| --- | --- |

| Collecting status, consolidating progress | Company Context and a continuously updated organizational state |

| Relaying policies and working methods | Skills and standardized workflows |

| Assigning tasks, coordinating resources | Agent orchestration and dynamic DRIs |

| Checking quality, catching anomalies | Evals, monitoring, and audit trails |

| Growing people, resolving conflict | Human player-coaches |

The first four are mostly information processing, process execution, and outcome verification — they can be handed to systems step by step. The last one involves trust, emotion, value judgment, and long-term human growth. It still needs people.

So an ANC does not swap one Agent in for one manager. It builds a new kind of organizational infrastructure.

Company Context replaces layered reporting. Skills replace methods that lived in veterans' oral tradition. Agents replace repetitive task dispatch, information lookup, and process execution. Evals replace "show it to the boss when you're done." Permissions and audit replace the fuzzy control hidden inside personal positions.

The people who genuinely handle human growth, professional judgment, and conflict become player-coaches: participating in real work while helping others grow.

In an ANC, pure managers detached from the front line become rarer and rarer. People who can both create results and help others create results become more and more important.

5. The four kinds of people in a zero-middle-management company

A mature zero-middle-management company keeps roughly four core roles.

First, the Owner. The Owner decides why the company exists, which outcomes matter most, which boundaries must not be crossed, and who makes the final call in a major conflict. AI can help an Owner see more facts, but cannot replace the attribution of responsibility.

Second, the DRI. A DRI receives a scoped mandate around a concrete problem. They might own a 48-hour sprint or a customer outcome that runs for half a year. As long as the task exists, they hold the power to mobilize the relevant resources; when it ends, the mandate is reassigned.

Third, the Builder. Most people in an ANC should be Builders. Engineers, salespeople, consultants, operators, designers, lawyers, and finance can all be Builders. What matters is not the job title but whether they directly create results. With Agents, one person can lead a fleet of Agents and own a larger, more complete slice of outcome.

Fourth, the player-coach. Still on the field playing, while owning professional standards, talent development, and the hard judgment calls. Their influence comes from expertise and earned trust — not from headcount.

So a zero-middle-management company does not demote all managers into individual contributors. It asks managers to become creators again.

6. Block is publicly trying to remove the permanent middle layer

In the public record, the company closest to this organizational form is not Anthropic, and not OpenAI. It is Block, Square's parent company.

In 2026, Jack Dorsey and Sequoia partner Roelof Botha published "From Hierarchy to Intelligence." Their argument: corporate hierarchy fundamentally exists to solve an information-flow problem. Managers need to know what their teams are doing, then aggregate that upward and relay decisions downward along the org chart.

But Block is a remote-first company. Its discussions, decisions, plans, code, issues, and project progress already live in digital systems. Those records can become the raw material for a company world model.

That world model can continuously understand what is being built, which project is stuck, where resources went, which methods are working, and which results are drifting off target.

If AI can continuously maintain that map of the company, the organization no longer needs managers running recurring meetings, chasing updates, and producing briefings just so the company can know what it is doing.

Block proposes three core roles for this: Individual Contributors who directly create results, DRIs who own specific problems and customer outcomes, and player-coaches who work while developing others.

Its public essay contains one very direct line: There is no need for a permanent middle management layer.

That line should not be misread as "Block is already a fully mature zero-middle-management company." Block itself openly admits the transition is early, and that some mechanisms may break before they mature.

The accurate statement is: Block has not finished zero middle management — it is among the first large tech companies to publicly and systematically move toward zero permanent middle management.

Source: Block, "From Hierarchy to Intelligence" (block.xyz/inside/from-hierarchy-to-intelligence)

7. Claude is turning this from theory into infrastructure

Block did not just publish an organizational theory essay.

Internally it has deployed Goose, an open-source Agent built on Claude, connecting the model to the company's data, tools, and workflows.

According to Anthropic's published case study, 75% of Block engineers save 8–10+ hours per week; thousands of employees across roles now use Goose; non-technical staff can generate SQL, query data, and automate workflows directly, instead of filing a request with the data team and waiting in the queue.

The most important meaning of those numbers is not "engineers got more efficient."

The real organizational change is this: employees started calling the company's data and tools directly, without needing a manager to coordinate with another department first.

A product manager who wanted usage data on a feature used to contact the data team, explain the request, wait for scheduling, align on definitions, and then receive a report. Now they can have an Agent query the data, generate the SQL, explain the results, and turn the analysis into the next action.

What got removed is not just one data analyst's work — it is the communication, scheduling, approvals, and management that used to surround that work.

Source: Claude × Block case study (claude.com/customers/block)

An even more direct case is LaunchNotes. It hands project data from GitHub, Jira, and Linear to Claude for analysis — auto-generating personalized progress updates, catching anomalies, and understanding engineering context. Incident identification became 5x faster, and meeting time dropped by 50%.

Collecting progress, spotting blockers, running syncs, nudging owners — that is the most common work of engineering middle management. Claude is not "playing the role of a manager," but it has taken over much of the information-gathering and synchronization work managers used to do.

Source: LaunchNotes × Claude case study (claude.com/customers/graph)

Anthropic's internal survey of 132 engineers and researchers shows respondents already use Claude in about 59% of their work, self-reporting roughly 50% productivity gains. The average number of consecutive actions Claude Code executes has grown from about 10 half a year ago to about 20.

Which means Agents are moving from "helping a person with one step" toward "independently owning a stretch of work."

Source: Anthropic, "How AI Is Transforming Work at Anthropic" (anthropic.com/research/how-ai-is-transforming-work-at-anthropic)

8. Neither Anthropic nor OpenAI is a zero-middle-management company

A factual clarification is needed here.

Anthropic uses Claude deeply and emphasizes high trust, small teams, and individual agency — but it is not a zero-middle-management company. Anthropic still publicly hires Research Managers and Engineering Managers, with responsibilities covering team execution, performance, career development, hiring, and cross-team communication.

OpenAI is not one either. Its public job postings still show multiple layers of managers, regional leads, and global leads. An APAC sales development leader manages frontline SDR managers and sales teams across markets; HRBP roles explicitly coach managers and participate in org design and talent planning.

Square cannot be called a zero-middle-management company on its own either. Square is now a business brand under Block; the org transformation was proposed by the parent company.

So the accurate judgment today is: Anthropic is a deeply AI-powered company, but not a zero-middle-management company. OpenAI is a company that produces AI, but is not one either. Block is one of the most aggressive large companies publicly moving toward zero permanent middle management — and the experiment is not finished.

Which also shows: building the most advanced AI and using AI to rebuild your own organization are two different things.

9. Zero middle management starts from company Context, not from the org chart

Many bosses reading this far will have a first reaction: should I start cutting management layers?

No.

If your company's real information still lives in personal WeChat threads, paper documents, Excel files, employees' heads, and disconnected software, the middle layer is still your most important information connector.

Cut it in that state, and the organization's information will not flow into AI. It will walk out the door with the people.

So an ANC transformation cannot start by redrawing the org chart. It starts by punching through real business.

Pick one business point specific enough to prove value. Send an FDE into the field to understand the real process, connect the necessary data and tools, and ship the first usable system.

Only after employees start using it can the system collect real feedback. Which rules need adding, which permissions must stay closed, which exceptions need a human, which judgments depend on veterans' experience — you only learn these inside the business.

That feedback gets distilled into Context, Skills, and Evals, and only then can Agents gradually take on more complete tasks.

When more and more information no longer depends on reporting, more and more methods no longer depend on oral tradition, and more and more tasks no longer depend on a coordinator, the org structure earns the conditions to flatten naturally.

Do not cut the middle layer first and then build the ANC. Build organizational intelligence first, and let part of the middle layer's functions naturally lose their reason to exist.

10. 48 hours, 48 days, 48 weeks — the road from middle layers to zero

The zero-middle-management company fits inside Lawted's 48 theory.

In 48 hours, an FDE proposes a surface and punches through one point — bypassing traditional project approval, reporting, and cross-department coordination — so the boss directly sees business value. This stage does not change the organization. It proves that some things can be done fast without the original seven or eight roles and layers of collaboration.

In 48 days, the system is deployed to employees. Real usage collects company Context, and the experience scattered across brains, chat logs, and files gets distilled into a knowledge base, Skills, workflows, and Evals. This stage starts distilling the middle layer: the rules, experience, and judgment managers used to hold become capabilities the organization can call repeatedly.

In 48 weeks, validated Agents start owning end-to-end tasks. The company redraws the division of work, responsibility, permissions, and risk between humans and AI, and some permanent departments are replaced by dynamic DRIs and task-based teams. Only this stage truly rebuilds the middle layer.

So the three stages compress into: bypass the middle layer in 48 hours, distill it in 48 days, rebuild it in 48 weeks.

Zero middle management is not a 48-hour slogan. It is an organizational outcome that may appear after 48 weeks.

11. Five questions that tell you whether a company is an ANC

In the future, judging whether a company is an AI Native Company should not depend on how many model subscriptions it bought or how many prompts its employees write per day. Ask five questions.

One: can the boss understand what is really happening on the front line without waiting for three layers of reporting?

Two: can employees get the Context, Skills, data, and tools a task requires without a leader coordinating for them?

Three: do the company's key capabilities live in a few veterans' heads, or have they become organizational assets every employee and Agent can call?

Four: is work judged acceptable because "the boss took a look," or because clear, executable, traceable Evals exist?

Five: does a person get resources and decision rights because they permanently occupy a position, or because they are currently responsible for a concrete outcome?

If these questions still resolve through hierarchy, the company is at best using AI.

Only when information no longer depends on middle-layer relay, methods no longer depend on personal monopoly, tasks can be executed by Agents, quality can be verified by Evals, and responsibility can dynamically reorganize around outcomes — only then does it truly start becoming an AI Native Company.

Coda: management stays, the management layer goes

A traditional company is a pyramid.

Information climbs level by level from the bottom; power descends level by level from the top. Middle managers stand at every node, compressing information, relaying orders, coordinating resources, keeping process alive.

An AI Native Company looks more like a continuously learning organizational intelligence.

Company Context remembers. Skills accumulate methods. Agents execute. Evals judge. The permission system controls risk. DRIs own concrete outcomes. Player-coaches own human growth.

So what zero middle management removes is not management, and not responsibility.

It removes one default assumption of the industrial age: that a person can permanently occupy a layer of the company by collecting information, holding meetings, relaying instructions, and managing others.

Future companies will still have founders, still have owners, still have people with deeper experience and better judgment. But their value will no longer come from standing on the path information must pass through. It will come from setting direction, carrying responsibility, making judgment calls, and growing people.

In an AI Native Company, everyone must ultimately stay close to one of two things: real work, or real customers.

Leave the information hauling to the Agents.

## 中文

AI Native Company 可以被进一步定义为一家「0 中层公司」。这里的「0 中层」，不是没有管理者，也不是所有员工都直接向老板汇报，而是不再保留一层以汇总信息、传达指令、协调资源和监督流程为主要工作的永久中层。过去由中层承担的组织协调功能，被拆解给企业 Context、Skills、Agent、Evals、权限系统和动态 DRI；人与人的管理仍然存在，但管理不再天然对应一个永久职位。

压到最短就是：传统公司让信息沿着人流动，ANC 让信息沿着系统流动；传统公司把权力绑定在职位上，ANC 把权力绑定在结果上。

有两点先说清楚。

第一，0 中层不等于 0 管理。公司依然需要战略、授权、裁决、人才培养、冲突处理和风险治理。消失的是以信息搬运为主要价值的管理层，保留下来的是对结果负责的人。

第二，0 中层不是裁员方案，而是组织能力成熟后的结果。如果企业没有 Context、Skills、Agent、Evals、权限和审计，直接把中层裁掉，不会得到一家 AI Native Company，只会得到一家失去协调能力的公司。

一、组织架构本来就是一种信息技术

为什么公司发展到一定规模以后，一定会出现中层？

根本原因不是老板喜欢官僚主义，而是人的带宽有限。

一个创始人可以直接理解五个人在做什么，却不可能持续理解五百个人每天在做什么。随着组织扩大，公司只能把人分成小组，每个组设置负责人，再把几个负责人交给更高一层管理者。

员工向组长汇报，组长向部门经理汇报，部门经理向总监汇报，总监最后把信息整理成一份 PPT 交给老板。老板作出决定以后，指令再沿着同样的链条逐级向下传递。

所以传统组织架构表面上是在划分权力，本质上却是一套由人组成的信息系统。每一层中层都承担三种作用：压缩信息、传递指令、协调资源。

中层不是偶然出现的冗余，而是工业时代解决组织规模问题的基础设施。但这套系统有一个无法避免的问题：信息每经过一层，就会损失一次。

客户在现场说了十句话，一线员工记住八句，汇报给经理时剩下五句，经理写进周报时剩下三句，最后出现在老板 PPT 上的可能只剩一句：「客户对系统体验存在一定意见。」

反过来也一样。老板提出的是「提高客户续约率」，经过几层拆解以后，可能变成要求员工每天打多少个电话、填写多少张表、完成多少个与客户价值无关的过程指标。

于是传统公司形成了一个矛盾：公司越大，越依赖中层；中层越多，公司距离真实工作和真实客户越远。

过去没有更好的办法，因为组织中的信息只能由人理解、归纳和传递。但现在，这个前提第一次发生了变化。

二、AI 首先替代的可能不是员工，而是信息路由层

今天，大部分企业所谓的 AI 转型，是给每个员工购买一个大模型账号。

员工用 AI 写材料，经理用 AI 总结材料，总监用 AI 把几份总结变成汇报，老板再用 AI 阅读这份汇报。看起来每个人都提高了效率，但公司的信息结构没有发生任何变化。

以前员工花两个小时写周报，现在只需要十分钟；以前经理花半天汇总周报，现在只需要半小时。结果不是公司更接近客户了，而是旧金字塔能够生产更多周报了。

这不是 AI Native Company。

AI Native Company 不是给传统组织的每一个节点安装一个 Copilot，而是重新追问：这些节点还有没有存在的必要？

如果企业里的客户反馈、项目记录、会议纪要、合同、代码、订单、报价和财务数据都已经数字化，Agent 就可以直接读取这些原始 Context，持续判断公司现在发生了什么、哪个项目正在延期、客户真正提出了什么问题、哪个环节正在重复返工、哪些决策已经作出，以及下一步应该由谁行动。

老板不再需要等待三层汇报才能知道一线发生了什么，员工也不必通过三层审批才能获得完成任务需要的背景、方法和资源。

所以 AI 对组织最大的影响，可能不是让一个员工完成两个人的工作，而是让公司不再需要依靠一层又一层的人来搬运信息。

当组织的 Context 可以被 AI 直接理解，中层最重要的信息路由功能就开始失去存在的基础。

三、0 中层，不是没有负责人

「0 中层公司」最容易引起的误解，是大家会以为公司以后没有管理，也没有老板，几百个人完全自我组织。

这不现实。

AI Native Company 依然需要明确的最终责任人。它改变的不是责任是否存在，而是责任如何产生。

传统公司的权力来自职位。因为你是部门经理，所以这个部门的预算、招聘、项目和信息都要经过你。无论公司此刻最重要的问题是什么，你都永久占据组织中的这一层。

ANC 的权力来自结果。因为你在未来 48 天里对「把报价 Agent 部署到一线并达到 80% 使用率」负责，所以你暂时拥有调动相关人员、数据和系统的权力。任务完成以后，这份授权可以结束，也可以转移到另一个问题上。

这就是 DRI，Directly Responsible Individual。

DRI 不一定拥有永久下属，也不需要先拥有一个部门，才能解决一个问题。他只是在一段明确时间里，对一个明确结果承担最终责任。

因此，0 中层公司不是所有人直接向 CEO 汇报，而是大部分工作不再通过汇报关系被组织，而是通过任务、结果和动态授权被组织。

传统公司是职位先存在，再把任务放进职位里；ANC 是问题先出现，再围绕问题组织人和 Agent。

四、中层不会被一个 Agent 替代，而是被一套系统拆解

「用一个 AI 经理替代所有中层」同样是一种过度简化。

中层承担的工作至少可以被拆成五类：

| 中层的传统职能 | ANC 中的承接机制 |

| --- | --- |

| 收集情况、汇总进度 | 企业 Context 与持续更新的组织状态 |

| 传达制度和工作方法 | Skills 与标准化工作流 |

| 分配任务、协调资源 | Agent 编排与动态 DRI |

| 检查质量、发现异常 | Evals、监控与审计记录 |

| 培养员工、处理冲突 | 人类 player-coach |

前四类工作主要涉及信息处理、流程执行和结果验证，可以逐步交给系统。最后一类涉及信任、情绪、价值判断和人的长期成长，依然需要人。

因此，ANC 不是拿一个 Agent 替换一个经理，而是建立一套新的组织基础设施。

企业 Context 替代层层汇报；Skills 替代依靠老员工口头传授的方法；Agent 替代重复的任务分发、信息查询和流程执行；Evals 替代「做好以后给领导看一下」；权限与审计替代隐藏在个人职位里的模糊控制。

真正需要处理人的成长、专业判断和冲突的人，会变成 player-coach：一边参与真实工作，一边帮助其他人成长。

在 ANC 里，脱离一线工作的纯管理者会越来越少；既能够创造结果，又能够帮助他人创造结果的人会越来越重要。

五、0 中层公司的四类人

一家成熟的 0 中层公司，大致会保留四种核心角色。

第一类是 Owner。Owner 决定公司为什么存在、什么结果最重要、哪些边界不能突破，以及出现重大冲突时由谁作出最终裁决。AI 可以帮助 Owner 看见更多事实，但不能替代责任归属。

第二类是 DRI。DRI 围绕一个具体问题获得阶段性授权。他可能负责一次 48 小时 Sprint，也可能负责一个持续半年的客户结果。只要任务还存在，他就拥有调动相关资源的权力；任务结束，授权就重新分配。

第三类是 Builder。ANC 中的大多数人都应该是 Builder。工程师、销售、顾问、运营、设计师、律师和财务都可以是 Builder。关键不在岗位名称，而在于他是否直接创造结果。在 Agent 的帮助下，一个人可以带着一组 Agent，对一段更完整的结果负责。

第四类是 player-coach。他自己仍然在场上比赛，同时负责专业标准、人才培养和复杂判断。他不是靠拥有下属证明价值，而是靠专业能力和他人信任产生影响。

因此，0 中层公司不是把管理者全部变成普通员工，而是要求管理者重新成为创造者。

六、Block 正在公开尝试取消永久中层

目前公开资料中，最接近这种组织形态的，不是 Anthropic，也不是 OpenAI，而是 Square 的母公司 Block。

2026 年，Jack Dorsey 和红杉合伙人 Roelof Botha 发表了《From Hierarchy to Intelligence》。他们提出，传统公司的层级结构本质上是为了解决信息流动问题。管理者需要掌握团队正在发生什么，再将这些信息沿着组织结构向上汇总、向下传达。

但 Block 是一家 remote-first 公司。公司的讨论、决策、计划、代码、问题和项目进展，本来就大量存在于数字系统中。这些记录可以成为 company world model 的原材料。

这个 world model 可以持续理解什么正在被开发、哪个项目被卡住、资源被分配到了哪里、什么方法正在奏效，以及哪些结果正在偏离预期。

如果 AI 能够持续维护这张公司地图，组织就不再需要依靠管理者反复开会、询问和制作汇报，才能知道自己正在发生什么。

Block 为此提出了三种核心角色：直接创造结果的 Individual Contributor、对具体问题和客户结果负责的 DRI，以及一边工作、一边培养他人的 player-coach。

它的公开文章里有一句非常直接的话：There is no need for a permanent middle management layer.

不过，这句话不能被误读成「Block 已经是完全成熟的 0 中层公司」。Block 自己也明确承认，这项转型仍处于早期阶段，部分机制可能会先出问题，再逐步成熟。

准确的表述应该是：Block 不是已经完成了 0 中层，而是第一批公开、系统地向 0 永久中层转型的大型科技公司。

来源：Block《From Hierarchy to Intelligence》（block.xyz/inside/from-hierarchy-to-intelligence）

七、Claude 正在把这件事从理论变成基础设施

Block 并不是只写了一篇组织理论文章。

它内部已经部署了基于 Claude 的开源 Agent Goose，把模型与公司的数据、工具和工作流连接起来。

根据 Anthropic 公布的案例，75% 的 Block 工程师每周因此节省 8—10 小时以上；数千名不同岗位的员工已经开始使用 Goose；非技术员工可以直接生成 SQL、查询数据和自动化流程，不再必须把问题提交给数据团队，再等待排期。

这些数字最重要的意义不是「工程师效率提高了」。

真正的组织变化是：员工开始直接调用公司的数据和工具，不再需要通过管理者协调另一个部门的人，才能完成任务。

过去，一个产品经理想知道某项功能的客户使用情况，需要先联系数据团队、解释需求、等待排期、确认口径，再拿到报表。现在，他可以直接让 Agent 查询数据、生成 SQL、解释结果，并把分析转化为下一步行动。

这减少的不只是一名数据分析师的工作，也减少了围绕这项工作产生的沟通、排期、审批和管理。

来源：Claude × Block 案例（claude.com/customers/block）

另一个更直接的案例是 LaunchNotes。它将 GitHub、Jira、Linear 等系统里的项目数据交给 Claude 分析，自动生成个性化进展更新、识别异常并理解工程上下文。使用以后，团队识别事故的速度提升到原来的 5 倍，会议时间减少了 50%。

收集进度、发现阻塞、组织同步、提醒负责人，本来就是工程中层最常见的工作。Claude 并没有「扮演一名经理」，但它接走了经理大量用于收集信息和维持同步的工作。

来源：LaunchNotes × Claude 案例（claude.com/customers/graph）

Anthropic 对内部 132 名工程师和研究人员的调查也显示，受访者平均已经在约 59% 的工作中使用 Claude，并自报获得约 50% 的生产力提升。Claude Code 平均连续执行的动作数量，也从半年前大约 10 个增长到了约 20 个。

这说明 Agent 正在从「帮助人完成一个步骤」，逐渐进入「独立承担一段工作」的阶段。

来源：Anthropic《How AI Is Transforming Work at Anthropic》（anthropic.com/research/how-ai-is-transforming-work-at-anthropic）

八、Anthropic 和 OpenAI 都不是 0 中层公司

这里需要做一个事实澄清。

Anthropic 虽然深度使用 Claude，也强调高信任、小团队和个人主动性，但它并不是 0 中层公司。Anthropic 仍在公开招聘 Research Manager 和 Engineering Manager，职责包括管理团队执行、员工绩效、职业发展、招聘和跨团队沟通。

OpenAI 同样不是。OpenAI 的公开招聘信息中，仍然存在经理、区域负责人和全球负责人的多层结构。例如，APAC 销售发展负责人需要管理各个市场的前线 SDR 经理和销售团队；HRBP 岗位也明确需要辅导经理、参与组织设计和人才规划。

Square 也不能被单独称为 0 中层公司。Square 现在是 Block 旗下的业务品牌，提出这套组织变革的是母公司 Block。

因此，目前更准确的判断是：Anthropic 是一家高度 AI 化的公司，但不是 0 中层公司；OpenAI 是一家生产 AI 的公司，但也不是 0 中层公司；Block 是目前公开向 0 永久中层转型最激进的大公司之一，但这场实验尚未完成。

这也说明，「做出最先进的 AI」和「用 AI 重构自己的组织」是两件不同的事。

九、0 中层不是从组织架构开始，而是从企业 Context 开始

很多老板看到这里，第一反应可能是：那我是不是应该开始削减管理层？

不是。

如果企业的真实信息还散落在个人微信、纸质文件、Excel、员工大脑和互不连通的软件中，中层依然是公司最重要的信息连接器。

在这种情况下裁掉中层，组织的信息不会自动进入 AI，只会跟着人一起离开。

所以 ANC 改造不能从修改组织架构开始，而应该从打穿真实业务开始。

先选择一个足够具体、能够验证价值的业务点，让 FDE 进入现场，理解真实流程，连接必要的数据和工具，做出第一个可用系统。

员工开始使用以后，系统才能收集真实反馈。哪些规则需要增加，哪些权限不能开放，哪些异常必须人工处理，哪些判断依赖老员工经验，只有进入业务以后才能知道。

这些反馈再被沉淀成 Context、Skills 和 Evals，Agent 才能逐渐承担更完整的任务。

当越来越多的信息不再依赖中层汇报，越来越多的方法不再依赖中层口头传授，越来越多的任务不再依赖中层协调，组织结构才有条件自然变平。

不是先裁掉中层，再建设 ANC；而是先建设组织智能，让一部分中层职能自然失去存在的必要。

十、48 小时、48 天、48 周，也是从有中层走向 0 中层

「0 中层公司」可以被放进劳泰德 48 理论中理解。

48 小时，FDE 提出一个面、打穿一个点，绕过传统立项、汇报和部门协调，让老板直接看见业务价值。这一阶段不是改变组织，而是证明：有些事情不需要经过原来的七八个工种和多层协作，也可以快速完成。

48 天，系统部署给员工使用。通过真实使用收集企业 Context，把散落在人脑、聊天记录和文件中的经验，逐渐沉淀为知识库、Skills、工作流和 Evals。这一阶段开始蒸馏中层。原来中层掌握的规则、经验和判断，开始变成组织可以重复调用的能力。

48 周，经过验证的 Agent 开始承担端到端任务。企业重新划分人和 AI 的工作、责任、权限与风险，一部分永久部门被动态 DRI 和任务型团队取代。这一阶段才真正开始重构中层。

所以可以把三个阶段进一步压缩成：48 小时绕过中层，48 天蒸馏中层，48 周重构中层。

0 中层不是 48 小时的口号，而是 48 周以后可能出现的组织结果。

十一、判断一家公司是不是 ANC，看五个问题

未来判断一家公司是不是 AI Native Company，不应该看它买了多少大模型账号，也不应该看员工每天写多少 Prompt，而应该问五个问题。

第一，老板能不能不等待三层汇报，直接理解一线真实发生的事情？

第二，员工能不能不依赖领导协调，直接获得完成任务需要的 Context、Skills、数据和工具？

第三，公司的关键能力是掌握在几个老员工脑中，还是已经成为所有员工和 Agent 都能调用的组织资产？

第四，一项工作是否合格，依赖「领导看一眼」，还是已经存在明确、可执行、可追溯的 Evals？

第五，一个人获得资源和决策权，是因为他永久占据某个职位，还是因为他正在对一个明确结果负责？

如果这些问题仍然依赖组织层级，那么这家公司最多是在使用 AI。

只有当信息不再依赖中层搬运，方法不再依赖个人垄断，任务可以由 Agent 执行，质量可以由 Evals 验证，责任可以围绕结果动态重组，它才真正开始成为 AI Native Company。

结语：管理不会消失，管理层会消失

传统公司是一座金字塔。

信息从底层逐级向上，权力从顶层逐级向下。中层站在每个节点上，负责压缩信息、传达命令、协调资源和维持流程。

AI Native Company 更像一个持续学习的组织智能。

企业 Context 负责记忆，Skills 负责沉淀方法，Agent 负责执行，Evals 负责判断，权限系统负责控制风险，DRI 对具体结果负责，player-coach 负责人的成长。

所以，0 中层真正取消的不是管理，也不是责任。

它取消的是工业时代的一种组织默认：一个人可以只靠收集信息、召开会议、传达指令和管理别人，永久占据公司的一层。

未来的公司依然会有创始人，依然会有负责人，依然会有经验更丰富、判断力更强的人。但他们的价值不再是站在信息必经之路上，而是定义方向、承担责任、作出判断和培养他人。

在 AI Native Company 里，每个人最终都必须靠近两样东西：要么靠近真实工作，要么靠近真实客户。

剩下的信息搬运，交给 Agent。


---

# A Six-Cell Strategy for Working with AI: From the Four Quadrants to a 3×2 for Vibe Coding / 与 AI 协作的六格策略：从提问四象限到 Vibe Coding 3×2

> Published 2026-07-12 · By lawted · Canonical: https://ha7ch.com/writing/six-cell-ai-collaboration

## English

This article started with a short video by Dr. Xiaohui on Xiaohongshu: The Four Quadrants of Working Effectively with AI. The video sorts prompts to AI into four kinds: known knowns (Express), known unknowns (Ask), unknown knowns (Iterate), and unknown unknowns (Explore). It also makes a key observation: most people only work on Express, while the real ceiling of the collaboration is set by the other three. Those three cannot be reached by writing one perfect prompt; they can only be drawn out inside a collaboration loop.

The quadrants themselves have an upstream source. The video's author mentions they come from a talk by an Anthropic researcher. That researcher is Thariq Shihipar, a member of Anthropic's technical staff, and the original piece is A Field Guide to Claude Fable 5: Finding your unknowns, published on Anthropic's official blog on 2026-07-06. I will come back to this primary source below.

Inspired by this, I wanted to move the framework from the prompt level to the project level: what information is missing in one collaboration session is one question; what model, what harness, and what verification method a project should be equipped with is another. That is how the 3×2, six-cell framework below came about.

---

From four quadrants to 3×2: adding a capability dimension

First, a point that is easy to confuse: the dimensions in this article are not the same pair of axes as the original quadrants. The relationship is inspiration, not mapping. Shihipar's two axes are whether you are aware × whether you possess, and what they classify is the information inside a prompt: an epistemic state. My axes are goal clarity, method clarity, and capability, and what they classify are properties of the project task itself.

For example, the entire cell “goal clear but method unclear” is, in his framework, just one known unknown: you are aware that you do not know the method. So the 3×2 below is not an upgraded version of the quadrants; it swaps the lens from your epistemic state about the information to the resource state of the task.

In real vibe-coding projects, one more layer needs to be split apart: knowing the method and being able to execute the method are two different things.

An example: a senior database expert and a novice who has only briefly touched databases both know they need to build a database. The expert can complete it end to end without AI; the novice can barely move without AI. Facing AI, the two of them have completely different prompt states and need completely different collaboration styles.

So the framework becomes three dimensions and six cells. First: is the goal clear? That determines what you iterate on. With a clear goal you iterate on implementation; with a vague goal you iterate on the goal itself. Second: is the method clear? That determines who decides the technical approach: you decide, or AI proposes and you choose at the level of consequences. Third: is your capability sufficient? That determines your means of verification. With sufficient capability you can verify by reading code; without it you can only verify by observing behavior, such as tests, previews, and run results.

The third point matters most. Insufficient capability does not change what the AI should do; what it changes is that your quality control must drop from the code level to the behavior level. The whole harness has to be configured around making behavior observable.

The six-cell matrix reads like this:

| | Method clear + capability sufficient | Method clear + capability insufficient | Method unclear |

|---|---|---|---|

| Goal clear | ① Efficiency mode | ② Apprentice mode | ③ Client mode |

| Goal unclear | ④ Do not start here → go to ⑥ | ⑤ Do not start here → go to ⑥ | ⑥ Goal-clarification loop |

Note that the two rows differ in kind: the top row contains working modes; the bottom row contains states and routing. Only ⑥ is a place where real work can start. ④ and ⑤ are states you discover yourself in, and the only action there is to merge into ⑥. Once ⑥ finishes and the goal converges, you land back in ①②③ for delivery according to your method and capability at that moment.

---

The six cells in detail

① Efficiency mode: you could do it yourself; AI saves labor.

In efficiency mode, model choice can prioritize cost-effectiveness because you can backstop and correct mistakes. The harness can have high autonomy: auto-accept edits, run multiple tasks in parallel, use tests and lint as automatic gates, and write a detailed CLAUDE.md to lock in your code style.

The prompt style is to hand over a detailed requirements document and acceptance criteria in one shot, then delegate in batches. Your role is reviewer. The biggest trap is over-reviewing: the time you saved flows right back out. Learn to review only interfaces and critical paths.

② Apprentice mode: you know how it should be done, but cannot write it fluently.

In apprentice mode, use a strong model. The logic is the opposite of ①: you cannot catch its mistakes, so you must lower the probability that it makes them. The harness should be low-autonomy. Turn on Plan mode to see the plan first, and confirm edits step by step. Ask the AI to attach a why-it-is-written-this-way explanation to every change. This can be locked into settings or CLAUDE.md.

Verification also changes: since you cannot fully read the code, move your judgment onto observable behavior. Run every small step and look at the result. The extra output is a learning note maintained by the AI along the way. This is the core difference between ② and ③: you are buying capability, not just results.

This connects directly to a technique in Thariq Shihipar's original piece: the structured interview. Let Claude interrogate the ambiguities in your requirements one by one, prioritizing questions whose answers would change the architecture. For someone in apprentice mode, the value runs both ways: the AI clarifies the requirements, and being interrogated fills knowledge gaps you had not noticed in yourself.

One fork to decide in advance: is this capability worth learning? For a stack you will keep using, take apprentice mode: slow but compounding. For a one-off task, downgrade it to ③: fast but non-compounding. Many people stuck in the pain of ② simply have not realized that choosing not to learn is an option.

③ Client mode: you know what you want, not how to build it.

In client mode, the model choice is strong model plus Plan mode. Have the AI propose two or three technical approaches first. You do not choose at the technical level; you choose at the level of consequences: maintenance cost, deployment difficulty, and compatibility with your existing tools.

The harness should focus on short feedback loops: a preview server, browser tools, screenshot comparison. Your acceptance surface is the rendered result, not the code. The prompt should use user language, not technical language. Give reference sites, screenshots, or hand-drawn sketches. One reference image often saves several rounds of text back-and-forth. That is the key workflow saving.

Write the acceptance criteria in advance, in a form you can check yourself: “opens on a phone without horizontal scrolling,” not “responsive layout.”

Shihipar's structured interview is a core technique in this cell too. The biggest risk of client mode is the unknown knowns: implicit standards so obvious to you that you would never write them into the requirements, such as taste, layout preferences, or an interaction that must never appear. Rather than hoping to write them all down in one pass, let the AI actively ask them out of you. Combine that with another of his suggestions, collecting reference code and reference works, and the implicit standards surface at minimal cost.

---

The rule for the bottom row: no construction in ④⑤; always route through ⑥ first

The three bottom cells share one fact: the goal is unclear. Writing code toward delivery while the goal is unclear mostly produces waste. So here is a hard rule: ④ and ⑤ are for state recognition only, not construction. When you find yourself in these cells, the only action is to explicitly switch into ⑥'s goal-clarification loop.

The most dangerous thing about ④⑤ is precisely that they look ready to start. The person in ④ is holding a hammer and easily starts swinging, building something nobody wants. The person in ⑤ tends to end up with a half-learned stack and a product nobody wants, losing on both ends. Differences in method and capability do not change the ⑥-first routing; they only change the cost of running ⑥.

④, method clear and capability sufficient: you can prototype quickly yourself, so the clarification loop runs fast and cheap. Focus the prompt on describing your assets and boundaries, such as what data, skills, and audience you have. Let the AI propose a candidate list of goals those assets could unlock, then test them one by one with throwaway prototypes.

⑤, method clear and capability insufficient: let AI do all the prototyping, and freeze learning. Until the goal stabilizes, do not invest in learning any stack. Learning is currently the only cost AI has not deflated. Do not spend it on a direction that may be falsified.

---

⑥ The goal-clarification loop: the only working mode in the bottom row

⑥'s deliverable is not a product; it is a clarified goal. Starting to build here is legitimate, because after the collapse of construction costs, building has turned from a means of execution into a means of cognition. You cannot meditate your way to knowing what you want, but given a few clickable prototypes, you know within ten seconds which one is wrong.

Judgment is the only thing that cannot be outsourced. Before entering the loop, write down what counts as good as an explicit standard, however rough. Even “I would want to share this with someone” works. Without a yardstick, the loop will not converge.

The harness setup is: use a strong model to generate multiple variants in parallel, then you rank and eliminate, then synthesize. You act only as selection pressure. Note that ①'s cost-effectiveness logic does not apply here. In the exploration phase the bottleneck is the heuristic quality of each prototype, not the quantity. The diversity a weak model offers is diversity within a low-quality region, and this is exactly the moment when your own input is weakest and you most need model quality to raise the ceiling. The extra tokens spent exploring are negligible against the cost of heading in the wrong direction.

This loop has a ceiling: the ceiling of your input sets the ceiling of the output. The model explores around the context you provide; it can hardly reach the frontier of a domain entirely unknown to you. It illuminates the range your judgment can recognize. The mitigation is to expand the input from just yourself to the outside world: have the model bring in domain benchmarks, competing products, and real user feedback as reference points, instead of only making variants within your description.

All code is disposable by default. What deserves keeping is the conclusion notes: which directions were falsified, and why.

The exit condition is: when you can write the goal as a requirement you can accept yourself, even at the behavior level, such as “opens on a phone without horizontal scrolling,” the loop ends, and you land back in ①②③ for delivery according to your method and capability at that moment.

This cell corresponds to the Unknown Unknowns quadrant in Shihipar's piece. His advice is to run a blind-spot pass before starting: have Claude generate a few drastically different directions, for example as HTML artifacts. You are not picking an answer; you are using your own reactions to probe the boundary of the problem space.

---

Two observations across cells

First, cells are dynamic. Projects migrate, and the migration has a fixed route. The typical path is: ④/⑤, recognizing that the goal is unclear; then ⑥, the clarification loop converges on a goal; then ③ or ②, the method becomes clear during delivery; then ①, capability catches up after doing the same kind of thing repeatedly. Strategy is not set once at project start. At every stage you re-ask: which cell am I in now? Be especially wary of unknowingly starting construction in ④⑤. That self-check question deserves a place in your workflow.

Second, the two frameworks govern different levels and complement each other. Shihipar's quadrants, and Dr. Xiaohui's Express / Ask / Iterate / Explore version, govern information clarification within a single collaboration. This article's 3×2 governs project-level strategy selection. First use the six cells to fix the model, harness, and verification method; then, in each concrete collaboration, use the quadrants to check for information gaps.

---

Sources

Primary source: Thariq Shihipar (Anthropic), A Field Guide to Claude Fable 5: Finding your unknowns, 2026-07-06. Core claim: in the Fable 5 era, the bottleneck on output quality is your ability to clarify your own unknowns; the prompt is the map, the codebase is the territory, and the gap between them is the unknowns.

Secondary source: Dr. Xiaohui, The Four Quadrants of Working Effectively with AI, Xiaohongshu.

## 中文

这篇文章的起点，是小红书上「晓辉博士」的一条视频：《跟AI高效协作的四个象限》。视频把给 AI 提 prompt 分成四类：已知的已知（表达 / Express）、已知的未知（求助 / Ask）、未知的已知（迭代 / Iterate）、未知的未知（探索 / Explore）。它还点出一个关键观察：大多数人只在「表达」上下功夫，而真正决定协作上限的是后三类。后三类无法靠一次写出完美 prompt 达成，只能在协作循环中被激发出来。

这个四象限本身也有一个上游。视频作者提到它源自一位 Anthropic 研究员的分享。这位研究员是 Thariq Shihipar（Anthropic 技术团队成员），原文是他发表在 Anthropic 官方博客的 A Field Guide to Claude Fable 5: Finding your unknowns（2026-07-06）。关于这篇一手来源，后文会详细展开。

受此启发，我想把这个框架从 prompt 层面换到项目层面：一次协作里缺什么信息是一回事，一个项目该配什么模型、什么 harness、什么验证方式是另一回事。于是有了下面这个 3×2 的六格框架。

---

从四象限到 3×2：加入「能力」维度

先澄清一个容易混淆的点：本文的维度和原版四象限不是同一对轴，两者的关系是启发，不是映射。Shihipar 四象限的两条轴是「你是否觉知 × 你是否拥有」，分类的对象是 prompt 里的信息，属于认识论状态。本文的轴是目标清晰度、方法明确度、能力，分类的对象是项目任务本身的属性。

举例来说，「目标清晰但方法不明」这整个格子，在他的框架里只是一个 known unknown：你意识到自己不知道方法。所以下文的 3×2 不是四象限的升维版，而是把「对信息的认识状态」这个视角，换成了「对任务的资源状态」这个视角。

在真实的 Vibe Coding 项目里，还有一层需要拆开：知道方法和有能力执行方法是两回事。

举个例子：一个数据库资深专家和一个只接触过数据库的新手，都「知道」要建一个数据库。专家没有 AI 也能从头到尾独立完成；新手没有 AI 则寸步难行。两个人面对 AI 时，输入的 prompt 状态、需要的协作方式，完全不同。

所以框架变成三个维度、六个格子。第一，目标是否清晰，决定你迭代的对象：目标清晰时你在迭代实现，目标模糊时你在迭代目标本身。第二，方法是否明确，决定技术方案由谁拍板：你拍板，还是 AI 提案、你从后果层面选择。第三，能力是否足够，决定你的验证手段：能力足够时你能读代码验证；能力不足时你只能看行为验证，比如测试、预览、运行结果。

第三点最关键。能力不足并不改变 AI 该做什么，它改变的是你的质检手段必须从代码层降级到行为层：整套 harness 都要围绕「让行为可观察」来配置。

六格矩阵可以这样读：

| | 方法明确 + 能力足够 | 方法明确 + 能力不足 | 方法不明确 |

|---|---|---|---|

| 目标清晰 | ① 提效模式 | ② 学徒模式 | ③ 甲方模式 |

| 目标不明确 | ④ 不在此开工 → 先走 ⑥ | ⑤ 不在此开工 → 先走 ⑥ | ⑥ 目标澄清循环 |

注意上下两行性质不同：上半行是工作模式，下半行是状态与路由。只有 ⑥ 是可以真正动手的地方。④⑤是「你发现自己所处的状态」，动作只有一个：并入 ⑥。⑥ 完成、目标收敛之后，按当时的方法和能力状态落回 ①②③ 交付。

---

六格策略详解

① 提效模式：你自己也能做，AI 省人力。

在提效模式里，模型选择可以性价比优先，因为你能兜底纠错。Harness 可以给高自主度：auto-accept 编辑、并行跑多个任务，用测试和 lint 做自动关卡，再写一份详细的 CLAUDE.md 固化你的代码风格。

Prompt 的写法是一次性给足细节化需求文档和验收标准，然后批量委派。你的角色是审查者。最大的坑是审查过度，省下的时间又花回去了。要学会只审接口和关键路径。

② 学徒模式：知道该怎么做，但写不熟练。

在学徒模式里，要用强模型。逻辑与 ① 相反：你抓不住它的错误，所以要降低它犯错的概率。Harness 应该低自主度。开 Plan mode 先看计划，逐步确认编辑。要求 AI 每次改动附带「为什么这样写」的解释，这条可以固化在 settings 或 CLAUDE.md 里。

验证方式也要变：既然读不透代码，就把判断转移到可观察行为上，每一小步都跑起来看效果。附加产出是让 AI 顺手维护一份学习笔记。这是 ② 区别于 ③ 的核心：你在买能力，不只是买结果。

这里正好接得上 Thariq Shihipar 原文里的一个技巧：结构化采访。让 Claude 逐条追问你需求中的歧义，并且优先问「答案会改变架构」的问题。对学徒模式的人来说，这个手段的价值是双向的：AI 澄清了需求，你也在被追问的过程中补上了自己没意识到的知识缺口。

一个要提前决定的分岔是：这个能力值不值得学？以后常用的技术栈，走学徒模式，慢但增值；一次性任务，直接降级当 ③ 处理，快但不增值。很多人卡在 ② 的痛苦里，其实是没意识到自己可以选择不学。

③ 甲方模式：知道要什么，不知道怎么做。

在甲方模式里，模型选择是强模型 + Plan mode。先让 AI 给 2 到 3 个技术方案，你不从技术层面选，而是从后果层面选：维护成本、部署难度、和现有工具的兼容性。

Harness 的重点是建短反馈回路，比如 preview 服务器、浏览器工具、截图对比。你的验收界面是渲染结果，不是代码。Prompt 用用户语言，不用技术语言。给参考网站、截图、手绘草图。一张参考图往往能省掉好几轮文字往返，这是节省工作流的关键。

验收标准要提前写成你自己能检查的形式，比如「手机上打开不横向滚动」，而不是「响应式布局」。

Shihipar 的结构化采访在这一格同样是核心手段。甲方模式最大的风险是未知的已知：那些对你太显然、你根本不会写进需求里的隐性标准，比如品味、排版偏好、某个绝不能出现的交互。与其指望自己一次写全，不如让 AI 主动把它们问出来。再配合他建议的另一招，收集参考代码和参考作品，隐性标准就会以最低的成本浮出水面。

---

下半行的通行规则：④⑤禁止开工，一律先走 ⑥

下半行三格共享同一个事实：目标不明确。目标不明确时朝着交付写代码，产出大概率是废品。所以这里立一条硬规则：④ 和 ⑤ 只做状态识别，不做施工。发现自己在这两格时，唯一的动作是显式切换到 ⑥ 的目标澄清循环。

④⑤最危险的地方恰恰在于「看起来可以开工」。④ 的人手里有锤子，很容易直接抡起来，造一个没人要的东西。⑤ 的人则容易既学了半吊子技术、又做了没人要的东西，两头落空。方法和能力上的差异不改变「先走 ⑥」这个路由，只改变你跑 ⑥ 的成本。

④（方法明确、能力足够）：你自己能快速搭原型，澄清循环跑得又快又便宜。Prompt 重点是描述你的资产和边界，比如我有什么数据、什么技能、什么受众，让 AI 提出「这些资产能撬动什么目标」的候选清单，再用一次性原型逐个检验。

⑤（方法明确、能力不足）：原型全部让 AI 代劳，并且冻结学习。在目标稳定之前，不要投入学任何技术栈。学习是当前唯一没被 AI 通缩的成本，别把它花在可能被证伪的方向上。

---

⑥ 目标澄清循环：下半行唯一的工作模式

⑥ 的交付物不是产品，是一个清晰化的目标。这里「开工」是合法的，因为构建成本坍塌之后，「做」已经从执行手段变成了认知手段：你无法通过冥想知道自己要什么，但给你几个能点的原型，你十秒钟就知道哪个不对。

判断尺度是唯一不能外包的东西。进入循环前，先把「什么算好」写成显式标准，哪怕很粗糙，比如「我看到会想分享给别人」也行。没有尺度，循环就不会收敛。

Harness 的设置是：用强模型并行生成多个变体，然后你排序淘汰，再综合。你只当选择压力。注意这里不适用 ① 的性价比逻辑：探索期的瓶颈是每个原型的启发质量，不是数量。弱模型给出的多样性，只是低质量区域内的多样性。而此刻正是你自己输入最弱、最需要模型质量来抬升上限的时候。探索多花的 token，相对走错方向的代价可以忽略。

这个循环有一个天花板：你的输入上限决定输出上限。模型的探索围绕你给出的语境展开，它很难替你触到一个你完全未知领域的上限。它照亮的是你判断力能识别的范围。缓解办法是把输入从你一个人扩展到外部世界：让模型引入领域标杆案例、竞品、真实用户反馈作为参照物，而不是只在你的描述里做变体。

一切代码默认可抛弃。真正要留存的是结论笔记：什么方向被证伪了、为什么。

出口条件是：当你能把目标写成一份自己能验收的需求，哪怕是行为层面的验收，比如「手机上打开不横向滚动」，循环就结束，按此刻的方法和能力状态落回 ①②③ 交付。

这一格对应 Shihipar 原文里的 Unknown Unknowns 象限。他的建议是动手前做一轮「盲点 pass」：让 Claude 生成几个截然不同的方向，比如以 HTML artifact 的形式。你不是在挑答案，而是在用自己的反应探测问题空间的边界。

---

两个跨格子的观察

第一，格子是动态的，项目会迁移，且迁移有固定路由。典型路径是：④/⑤（识别出目标不明）→ ⑥（澄清循环收敛出目标）→ ③ 或 ②（交付中方法逐渐明确）→ ①（反复做同类事之后能力补齐）。策略不是项目开始时定一次，而是每个阶段重新问一遍「我现在在哪个格子」。尤其要警惕在 ④⑤ 不自知地开工。这个自检问题本身值得写进工作流。

第二，两个框架管的层次不同，可以互补着用。Shihipar 的四象限，以及晓辉博士的表达 / 求助 / 迭代 / 探索版本，管的是一次协作内的信息澄清；本文的 3×2 管的是项目级的策略选型。先用六格定下模型、harness 和验证方式，再在每次具体协作中用四象限检查信息缺口。

---

来源

一手来源：Thariq Shihipar（Anthropic），A Field Guide to Claude Fable 5: Finding your unknowns，2026-07-06。核心论点：Fable 5 时代产出质量的瓶颈是「你澄清自己 unknowns 的能力」；prompt 是地图，代码库是领地，两者的差距就是 unknowns。

二手来源：晓辉博士，《跟AI高效协作的四个象限》，小红书。


---

# Zero Token Design, After ChatGPT Work / ChatGPT Work 之后，再谈零 Token 设计

> Published 2026-07-11 · By lawted · Canonical: https://ha7ch.com/writing/zero-token-after-chatgpt-work

## English

Two months ago I wrote a piece called Zero Token Design.

The core claim was this: an AI product doesn't always need to burn its own tokens at runtime. The old logic, where every click fires another model call and burns another token, works differently once the user already has their own agent workspace.

The better way is to let the user finish the reasoning inside their own agent workspace, and then push the structured result back into the product. The product owns the schema, the database, the versions, the rendering, and the distribution. Basically: let the agent do the work, and let the product catch the result.

But that piece quietly rested on one assumption I never said out loud.

---

It Only Worked for a Few People

Not everyone has an agent workspace.

A developer might already have Codex, Claude Code, or OpenCode installed. They know how to open a terminal, they know what npx is, and they know where to paste a quick-start prompt.

But for most ordinary users, that's still too much of a leap. They're not going to install a coding agent just to use some small product, and they're not going to set up a new working environment on their laptop.

So Zero Token Design held up as an architecture, but it really only belonged to developers. It was a developer's design.

---

ChatGPT Work Is That Agent Workspace

After ChatGPT Work shipped, I realized that missing piece was now in place.

ChatGPT Work is no longer the old chat box. It can read files, connect to external services, run multi-step workflows, and keep working for much longer stretches. It's an agent workspace in its own right.

What matters more is that it runs in the cloud, and it is on the phone. The agent workspace that used to live only on a developer's laptop now sits in everyone's pocket.

You don't need the phone itself to run an npx command. The real execution environment already lives in the cloud workspace behind ChatGPT.

But the role of npx has flipped completely. Before, npx was how a user launched a product's capability. Now, npx is just how a developer packages that capability into the product. The user doesn't even need to know it exists. They just have to ask.

So for the first time, Zero Token Design goes from an architecture for developers to an architecture for everyone.

---

That Screenshot Importer? Don't Build It

I once built a high-speed rail app called Raily.

Someone gave me a very reasonable suggestion at the time: why not add a screenshot import feature? A user buys a ticket on 12306, drops the order screenshot into Raily, and Raily automatically reads the date, train number, departure and arrival stations, time, and seat, then creates a trip.

By the old product logic, of course you should build this. I would have to build image upload inside Raily, request photo library permissions, wire up OCR, parse the fields, handle recognition errors, add a confirmation step, and finally write the data to the server.

But looking at it now, that feature does not need to live inside Raily at all.

The user buys the ticket and sends the screenshot straight to ChatGPT: add this train to my Raily.

ChatGPT reads the screenshot. The Raily Skill turns the train number, time, stations, and seat into the data structure Raily needs, then calls Raily's API to write it to the server. The Raily Skill and the Raily app share the same account, the same database, and the same server.

The next time the user opens Raily, the trip is already on the timeline. They never had to open Raily to make it happen, never hunted for an import button, never re-uploaded the screenshot, and never learned what formats Raily supports.

---

But Raily Doesn't Disappear

This doesn't mean ChatGPT replaces Raily.

Because a chat box isn't necessarily the best interface for looking at rail trips. Users still want a clean timeline, transfers between cities, departure and arrival reminders, station details, trip history, maybe even a map of where they have traveled by rail. A dedicated vertical app can probably do these better than a chat box.

What actually changes is that Raily no longer has to carry everything at once. ChatGPT handles understanding what the user wants and pulling in real-world input. Raily handles showing the rail trip beautifully.

They're not two competing products. They're two interfaces of the same system. One handles input, one handles display, and they share the same data underneath.

This logic is not limited to a rail app. A spending tracker is the same: the user no longer has to download an app, sign up, photograph a receipt, wait for OCR, fix errors, and pick a category just to reach a report page. They can snap a receipt inside ChatGPT and say log this expense, then open a website to see the full monthly chart. Both sides read the same data.

---

ChatGPT Work Becomes the Entry Point for Every Small Product

So the real change this time is not that screenshot import got more convenient.

It's that ChatGPT Work might become the entry point for every small product from now on.

In the past, every product had to build its own entry: sign up, login, upload, search, forms, a help center, plus a new AI chat box and its own inference service. Every founder was rebuilding the same things.

But what users actually need is usually not these entries. It's the small bit of capability behind the product: a set of domain rules, a data structure, a stable execution flow, and the state that accumulates over time.

The point of ChatGPT Work is that it strips this generic shell out of every product.

So the small product of the future may only need four things: a clear data structure, a reliable server, a Skill or Plugin that agents can call, and a display surface that genuinely deserves to exist on its own. The first batch of users might use your product entirely through ChatGPT.

---

Design the API Before the Pages

At that point, the structure of a product shifts.

It used to be: the user opens the app, the app understands the user, the app calls the AI, the app writes the data, the app displays the result. Now it might be: the user opens ChatGPT Work, ChatGPT understands the user, the Skill calls the product's capability, the product server holds the state, and the app displays the result.

So the first question a founder asks may no longer be how many pages do I need to build. It becomes: can my product be called by an agent? Can it reliably accept a structured result? Can identity and permissions carry over between ChatGPT and my product? Can the Skill and the app read and write the same data? When the user never opens my product, does it still create value?

This also changes the logic of distribution. We used to ask how to get the user to open our product one more time. Now we may have to ask how to get ChatGPT to call our product at the right moment.

SEO is about getting a search engine to find your page. There may be a new kind of optimization ahead: getting an agent to understand your capability, trust your interface, and call you in the right situation.

---

Back to Zero Token

This is also why I wanted to write about Zero Token Design one more time.

The first time, I cared about the token cost, about not making every product carry the same inference over and over. But looking at it now, what really matters about Zero Token Design may not be how much money it saves. It is that it redefines where a product is allowed to happen.

In the past, a product had to happen inside its own website and app. Now, a product can happen inside the user's agent workspace. And ChatGPT Work moved that agent workspace from a developer's terminal into everyone's phone. This time, the user doesn't need to install Codex, doesn't need to understand npx, and only needs to open ChatGPT.

And once a product starts happening inside the agent workspace, the place where users enter it moves there too. Where a product happens and where the user enters it become the same place, for the first time.

So from now on, don't rush to stuff another chatbot into every product, or rebuild a page for every kind of input. Hand the agent what belongs to the agent, and keep a good app only for the places that genuinely need a dedicated display.

In the past, we designed an entry point for each product. In the future, all products may share the same entry point. And that entry point is ChatGPT Work.

## 中文

两个月前，我写了一篇《零 Token 设计》。

那篇文章的核心判断是：一个 AI 产品，不一定要在自己的 runtime 里烧 token。用户点一下就调一次模型、烧一次 token 的老逻辑，在用户已经有了自己的 agent workspace 之后，其实可以换一种做法。

更好的方式是，让用户在自己的 agent workspace 里完成推理，把结构化的结果写回产品。产品负责 schema、数据库、版本、展示和分发。说白了就是，让 agent 去干活，让产品把结果接住。

但那篇文章其实藏着一个我当时没说破的前提。

---

这套设计原来只属于少数人

不是每个人都有 agent workspace。

一个开发者可能已经装了 Codex、Claude Code 或者 OpenCode。他知道怎么开终端，知道 npx 是什么，也知道该把一段 quick start prompt 粘到哪里。

但对绝大多数普通用户来说，这件事太远了。他不会为了用一个小产品，先去装一个 coding agent，也不会在自己电脑上配一套新的工作环境。

所以零 Token 设计当时在架构上是成立的，但它其实只属于开发者。它是一个开发者的设计。

---

ChatGPT Work 本身就是那个 agent workspace

ChatGPT Work 出来之后，我意识到这个前提被填上了。

ChatGPT Work 已经不是原来那个聊天框。它可以读文件、连外部服务、跑多步骤的工作流，并且能持续工作更长时间。它本身就是一个 agent workspace。

更关键的是，它跑在云端，而且进了手机。过去只有开发者的电脑里才有 agent workspace，现在它出现在每一个人的手机里。

所以你不需要让手机自己去执行一条 npx 命令。真正的执行环境已经在 ChatGPT 背后的云端工作台里。

而 npx 的角色，其实彻底反了过来。以前，npx 是用户启动某项产品能力的入口；以后，npx 只是开发者把能力打包进去的一种方式，用户甚至不需要知道它存在。他只需要说一句话。

于是零 Token 设计，从一个面向开发者的架构，第一次变成了一个面向所有人的架构。

---

Raily 那个截图导入功能，不用做了

我之前做过一个高铁行程 App，叫 Raily。

当时有人给过我一个很合理的建议：为什么不加一个截图导入功能？用户在 12306 买完票，把订单截图传进 Raily，Raily 自动识别日期、车次、出发到达站、时间和座位，生成一条行程。

按以前的产品逻辑，这功能当然该做。我得在 Raily 里做图片上传、申请相册权限、接 OCR、解析字段、处理识别错误、加一个二次确认页，最后再把数据写进服务器。

但现在再看，这个功能根本不需要存在于 Raily 里。

用户买完票，直接把截图发给 ChatGPT：把这趟高铁加进我的 Raily。

ChatGPT 看懂截图。Raily Skill 把车次、时间、车站和座位转成 Raily 需要的数据结构，再调用 Raily 的接口写进服务器。Raily Skill 和 Raily App 共用同一套账户、同一个数据库、同一台服务器。

用户下一次打开 Raily，这趟行程已经在时间线上了。他没有打开 Raily，没有找导入按钮，没有重新上传一次截图，也没有去学 Raily 支持什么格式。

---

但 Raily 不会消失

这不代表 Raily 会被 ChatGPT 取代。

因为对话框不一定是查看铁路行程的最佳界面。用户还是需要一条清晰的时间线、不同城市之间的换乘、出发和到达提醒、车站信息、历史行程，甚至一张铁路旅行地图。这些体验，一个专门的垂直 App 可能比对话框做得更好。

真正变化的是，Raily 不再需要同时承担所有事情。ChatGPT 负责理解用户想干什么、负责把真实世界的输入接进来；Raily 负责把铁路行程展示到最好。

它们不是两个互相竞争的产品，而是同一个系统的两个界面。一个负责输入，一个负责展示，背后共用同一份数据。

这个逻辑不只适用于高铁 App。一个消费分析产品也一样：用户不用再下载 App、注册、拍小票、等 OCR、改错误、选类别，才能进到报表页。他可以直接在 ChatGPT 里拍一张小票说帮我记一笔，再打开网站看完整的月度图表，两边读的是同一份数据。

---

ChatGPT Work 会成为所有小产品的入口

所以这次真正的变化，不是截图导入变得更方便了。

而是 ChatGPT Work 可能成为以后所有小产品的入口。

过去，每一个产品都要自己建一套入口：注册、登录、上传、搜索、表单、帮助中心，再加一个新的 AI 聊天框，和一套自己的推理服务。每一个创业者，都在重复造这些几乎一样的东西。

但用户真正需要的，往往不是这些入口，而是产品背后的那点能力：一段行业规则、一套数据结构、一个稳定的执行流程，以及长期沉淀下来的状态。

ChatGPT Work 的意义，就是把这层通用的壳，从每一个产品里抽走。

于是未来的小产品，可能只需要四样东西：一套清晰的数据结构，一台可靠的服务器，一个能被 agent 调用的 Skill 或 Plugin，以及一个真正值得独立存在的展示界面。第一批用户，甚至可以完全通过 ChatGPT 来用你的产品。

---

先设计接口，再设计页面

到这一步，产品的结构会变。

以前是：用户打开 App，App 理解用户，App 调用 AI，App 写数据，App 展示结果。以后可能是：用户打开 ChatGPT Work，ChatGPT 理解用户，Skill 调用产品能力，产品服务器保存状态，App 展示结果。

所以创业者第一件要问的事，可能不再是我要做几个页面，而是：我的产品能不能被 agent 调用？能不能稳定地接收结构化结果？身份和权限能不能在 ChatGPT 和产品之间打通？Skill 和 App 能不能读写同一份数据？用户不打开我的产品时，它还能不能产生价值？

这也会改变产品分发的逻辑。过去我们问的是，怎么让用户多打开一次我的产品；以后我们要问的，可能是怎么让 ChatGPT 在正确的时候调用我的产品。

SEO 是让搜索引擎找到你的页面。未来可能会有另一种优化：让 agent 理解你的能力、信任你的接口，并在正确的场景里调用你。

---

再说回零 Token

这也是我想再写一次零 Token 设计的原因。

第一次写它的时候，我关心的是 token 成本，别让每个产品都重复承担一遍推理。但今天再看，零 Token 设计真正重要的，可能不是省了多少钱，而是它重新定义了一个产品应该在哪里发生。

过去，一个产品必须发生在自己的网站和 App 里。现在，一个产品可以发生在用户的 agent workspace 里。而 ChatGPT Work，把这个 agent workspace 从开发者的终端，搬到了所有人的手机。这一次，用户不需要装 Codex，不需要懂 npx，只需要打开 ChatGPT。

而当一个产品开始发生在 agent workspace 里，用户进入它的地方，也跟着搬了过去。产品在哪里发生，用户就在哪里进入，这两件事第一次重合了。

所以以后，别急着给每个产品再塞一个 chatbot，也别急着为每一种输入重做一个页面。该交给 agent 的就交出去，只把真正需要专业呈现的地方，留给一个好的 App。

以前，我们为每一个产品设计一个入口。以后，所有产品可能共用同一个入口。这个入口，就是 ChatGPT Work。


---

# FDE in Four Cities / 中国四城 FDE 行业观察

> Published 2026-07-09 · By lawted · Canonical: https://ha7ch.com/writing/four-cities-fde-report

## English

From June 6 to July 4, 2026, HA7CH ran four closed-door FDE meetups in Shenzhen, Shanghai, Hangzhou, and Beijing, one Saturday afternoon each, 129 builders in total. This report is compiled from the live discussions at all four sessions. It is among the earliest firsthand testimony we know of on China's FDE ecosystem.

Two things up front. First, attendance figures come from our registration system (31 in Shenzhen, 31 in Shanghai, 32 in Hangzhou, 35 in Beijing), and every price, revenue, and timeline figure quoted in this report comes verbatim from what was shared in the room, with no extrapolation. Second, everything has been anonymized: all views are attributed uniformly to ha7ch guild members, with only industry and background descriptions retained. No real names, company names, or school names appear, with the exception of public industry facts about OpenAI and Anthropic.

---

1. Why Now: Real Business, No Industry Yet

FDE, Forward Deployed Engineer. A job title that until recently existed only on Silicon Valley careers pages was discussed, debated, and priced, intensively, across four afternoons in four Chinese cities. It still has no settled definition in China: there is no standard rate card, no established path into the work, not even a Chinese name everyone agrees on.

But it already has real contracts: a 20,000-yuan all-inclusive textile outsourcing job, a roughly 200-million-yuan domestic-stack IT (xinchuang) deal, an ERP subscription taking a 5 percent cut pegged to headcount reduction, and e-commerce gigs starting at 500 yuan apiece. What this report wants to record is precisely this moment: real business, no industry yet.

The backdrop is a set of mismatches. At the Shenzhen session, a guild member with a cloud-vendor background offered his read: since the new generation of models shipped late last year, coding agents' capabilities have exploded, but user-facing applications have not followed. Compute consumption is concentrated in a small number of users, product and engineering teams face layoffs precisely because of AI, and nearly every startup in Silicon Valley is crowding toward FDE. Capability in surplus, deployment in deficit, investment and returns badly mismatched. Standing in the gap of that mismatch is the FDE.

A member at the Hangzhou session who watches the industry from a big-tech vantage point pushed the judgment further: the last generation of software was a tools business, while this generation of AI business delivers "revenue growth" or "cost cuts and layoffs" as the product itself. Big tech has already started cutting staff as coding gets penetrated, and more than 90 percent of industries have not been penetrated at all. His exact words were logged on the spot as a quotable line: "These two years are the biggest blue ocean there is. You have to grab it."

What the four sessions produced is not secondhand trend commentary but firsthand testimony from the people doing the delivery, carrying payment receipts, failure postmortems, and layoff guilt. What follows is a city-by-city walk-through.

---

2. Shenzhen #001: On the Industrial Belt, Build First, Talk Money Later

June 6, a Saturday afternoon, 31 people.

Shenzhen was a classic industrial-belt scene, with the highest case density of the four cities, and every case came wrapped in words with body heat: on-site postings, commissions, headcount efficiency, layoffs. The opening introductions alone showed the spectrum: someone using large models to crack RGB-to-CMYK color conversion for the textile industry, someone doing marketing for a companion-robot company, someone doing RAG research, someone in cloud pre-sales, someone who had moved from sales into FDE. The ratio of traditional-industry people to AI practitioners was far more balanced than you would expect.

Start with the small cases. A member with an indie-developer streak hand-built a photo auto-classification tool in a few days, solving a friend's real pain point: a traditional retail sales rep who had to manually sort two to three thousand photos a month. The tool pairs a vision model with local algorithms, and the friend just plugs in his own API key. A pricing debate broke out on the spot: what should this thing cost, priced by the sales rep's hourly wage, or by some other anchor entirely? No conclusion, but everyone in the room realized that pricing is this industry's biggest blank space right now. Another member had done a wilder job: automating invoice issuance for an accounting firm, using an agent to drive the browser through the entire flow, and the project is live. A third member, formerly in financial analysis, used AI to write code that made his own job so efficient he simply quit, then built a website and food-delivery system for relatives running restaurants overseas, solving unstable delivery fees with fixed delivery zones and prepaid pricing, and built a Telegram bot for staff to self-select shifts with automatic payroll settlement. Not one of these jobs appears on any job board, but they are real FDE business.

Now the big cases. A member with deep roots in petrochemical IT shared three projects: using RAG to relieve in-house technical experts drowning in repeated Q&A, later extended to external pre-sales; a foreign-trade order-tracking system stalled at half-finished because email formats were too unstable; and AI-assisted decision-making layered onto an existing equipment management system, which landed smoothly. A member who spent years on core trading systems at a foreign bank drove the AI transformation of the trading stack, building a prediction system and a trade-flow agent. After launch it processed a heavy daily volume of trades, the bank subsequently cut staff, and he called himself "the guilty one," half in jest. A member from cross-border e-commerce turned product-selection logic and customs paperwork into formulas plugged into an ERP: shipping workflows for over a hundred SKUs a week used to consume enormous labor, automation cut labor needs by about 60 percent, some staff were laid off, some moved to operating the system, and the transition took about two months. A tech-company CTO put it most bluntly: after going AI-native, they can finish in three or four days what used to take more than half a year, their internal workflows are automated, and efficiency gains and layoff anxiety are two sides of the same coin.

One unresolved deal shows the boundary conditions of this market: a highly digitized manufacturing plant with in-house systems wants to bring in AI, an edge-deployment project with expected returns of 3 to over 5 million yuan. But the terms are harsh: no data goes to the cloud, deployment must be on-device, and the technology vendor must hand over the intellectual property. The original team passed; another member in the room said on the spot that he wanted it. Same clause, some see risk, others see a ticket in.

What made Shenzhen distinctive was industry, academia, and research at the same table, a rare sight. The associate dean of an engineering school at a university in South China launched a project-based FDE training program on the spot: recruit students across majors, bring in FDEs with real delivery experience to teach, form teams to work on real corporate projects, students get jobs, companies get hands, and he solicited instructors then and there. The supply side was just as lively: a fresh master's graduate from a Singapore university, short on internships, built three B2B POCs on his own and brought them to the room job-hunting; big-tech people who had quit cold because of the agent explosion were looking for direction; a member born after 2000 with a game-engine background had already built an AI avatar of his mother for foreign-trade lead generation. A member doing engineering-survey digitization inside his company voiced the common plight of the internal reformer: he has built plenty of tools, but efficiency gains inside the company carry limited economic value and little bargaining power, and he is wavering on going independent. The room's advice was one line: get out and make money.

Business models got their most direct and most unruly airing here: revenue shares pegged to layoffs or growth, technology for equity, AI roll-ups (raise capital to acquire traditional businesses, retrofit them with AI to lift margins, then keep rolling up more; startups in the US are already running this play), and splitting a project into training, coaching, and vision-selling as three separately billed phases. Pricing anxiety ran under the whole session, from "too embarrassed to charge" to "price by the client's anxiety level." The room also logged its expectations for the competition ahead: a price war may come, and the industry will move toward consolidation and standardization.

---

3. Shanghai #002: The Craft of Getting Paid

June 13, a Saturday afternoon, 31 people.

Shanghai was an intensely pragmatic business session, centered not on technology but on collections. The finance concentration was markedly higher than elsewhere: an asset-allocation product manager from a foreign bank, an undergraduate with nine finance internships, and students with brokerage backgrounds shared the room, putting constraints on the table you rarely hear elsewhere: heavy regulation, traceability and auditability, on-premise deployment, policy review for robo-advisory.

Start with the definition. A member with an organizer's background drew a line for FDE: an FDE is not an outsourcer who standardizes data, builds databases, or deploys chatbots, but a role that shortens a company's decision loop. His example was an airline: can we fly in this rain, how do we handle an emergency. Once AI is deployed, what shrinks is the decision chain, not document-processing time. Another member's project made the definition concrete: he is building an agent for a professional racing team, handling PR and logistics, making advance decisions on crew lodging and cargo transport. His summary stuck with the room: AI efficiency does not necessarily mean making the car faster; it means faster decisions and better-rested drivers.

The hardest-won material came from traditional-industry veterans. A member with over a decade in intelligent retrofits did a postmortem on smart-mine projects: hardware-inclusive projects carry heavy upfront work, errors and costs slip out of control easily, acceptance criteria are vague, and the client's leadership can seize on any problem as a reason to delay payment. His most extreme sample: a mining project in western China dragged on for years without completion, over client-side execution and budget problems, and the hardware warranty expired in the meantime. His countermeasure is not technical but relational: build communication with every level of the client organization, and screen out unsuitable industries and business types from the start. An operator at a state-owned IT company used a domestic-stack IT (xinchuang) deal worth hundreds of millions of yuan as his example and delivered a more structural judgment: FDE does not fit state-owned institutions. Pitching cost savings and efficiency to them goes nowhere; settlement requires layer upon layer of approval, and the logic never closes. State-owned enterprises (SOEs) answer upward, not downward, so the acceptance criterion is whether the people above are satisfied. If you must do it, get alignment with the very top first and push top-down.

A member selling integrated solutions shared two ledgers, one about profit, one about cost. The profit ledger: an integrated solution bundling high-end life-support equipment with a prediction system, negotiated at 1 to 1.5 million yuan per case, with clear delivery boundaries and fat margins. But at 60 to 70 percent completion, the project died quietly, tangled in the cadence of official red-header documents, school resources, and annual budgets. The cost ledger: he converted a data-annotation line to agents, and error handling genuinely got faster, but model consumption ran 30,000 dollars that month, more than the original small-scale cloud bill, and every workflow still needed human review at the end. Uncontrollable cost directly killed his ability to quote future deployments.

Organizational problems were put squarely on the table here. A member automating the full sales pipeline said his system targets industrial firms' bidding and tender workflows and achieves essentially zero employee input, but the moment employees learned the agent would replace their work, friction appeared instantly. The room's solution was surprisingly mature: partner with firms specializing in labor arbitration and workforce transition, and settle compensation, redeployment, and non-compete questions with the CEO and HRBP during the organizational diagnosis phase; transfer whoever can move to other business units, retrain whoever can be retrained. Another member shared a lesson from logistics: from efficiency pitch to delivery, blocked at every turn, and the final landing was to extract the features as plugins grafted onto the client's existing ERP. Anything that touches core systems, like finance-business integration, do not touch if you can avoid it.

On playbooks, an AI tooling company that got into FDE work early laid out its path: enter the enterprise with generic needs first, help the client bank quick wins and build trust, then capture high-margin work through deep needs. A member with a consulting background doing enterprise diagnosis added a feature of China's toB ecosystem: the product is sold to the decision-maker, not the user. Data security came up again and again: one team doing AI work for a leading consumer brand runs all client-document redaction on local models; another member mentioned a regional SOE's AI transformation project with budget in hand but little grasp of agent technology, so market education happens one training session at a time.

Two details explain why non-technical factors matter. One member dissected why Microsoft Copilot sells well despite not being great: SLA breaches come with compensation, and the brand itself is a procurement rationale. You cannot build looking only at the technology; companies of different sizes are buying service and certainty. Another member cited a choice from the aerospace world: for the reliability and stability of long-cycle projects, they would rather stick with old software versions and forgo the latest technology. Put the two together and you have the real procurement logic of toB.

Supply and demand closed the loop inside the room itself: an energy-storage materials company came looking for an algorithm partner, wanting to start at the mine with ore-sorting and process optimization; a doctoral student from a traditional engineering background, who had only touched vibe coding in April or May, was picked up on the spot by a team hiring interns. What lingered after the session was a genuine appetite for organization: one member proposed founding an FDE industry association to unify understanding and set standards.

---

4. Hangzhou #003: A Grassroots Blue Ocean, AI Landing in the Capillaries

June 27, a Saturday afternoon, 32 people.

Hangzhou was the most grassroots, most e-commerce-flavored session of the four, with the widest price spectrum. At one end, fast small jobs at 500 to 5,000 yuan apiece: a member who taught himself coding out of cross-border e-commerce operations now works as an FDE at an e-commerce company. His business lines are content replication (cloning viral product videos), RPA automation (simulating manual web operations), and data dashboards (as he put it, the thing scrappy small-town bosses welcome most). He prices by the client's budget, installation and training included, gets clients through short-video platforms and job boards, and screens them with almost disarming bluntness: use dressed-up open-source projects and demos to filter out the non-payers first. At the other end, a member with real nerve landed a CRM-plus-B2B-inquiry customer-profiling project through connections just two weeks after arriving in Hangzhou: 50,000 yuan for phase one, roughly 100,000 in total, a team of two or three.

The cases in between were all over the map. A fresh graduate joined an enterprise-services firm as an FDE and was dispatched shortly after joining to a temple posting, teaching the monks to use AI and configuring systems. His field report: the masters are easygoing and highly receptive, but everything is hand-holding. A solutions engineer covering general industry did a postmortem on why a steel-mill project would not move: not because the technology fell short, but because the client had no confidence in its own data quality and the veteran operators feared being replaced by AI. The project died before the technology got a chance. An engineer doing high-performance computing at a major tech company had used agents to automate the long pipeline of algorithm deployment, but inside the big company he cannot use the latest models, budgets are tight, and there is little room to adjust internal processes. His self-assessment: close to the technology, far from the market, here to hear stories of FDEs dealing with clients on the front line.

Career changers set the tone of this session. A financial accountant at a chain business, keeping books for hundreds of stores, first squeezed efficiency out of software, then used an AI coding assistant to automate 60 percent of his work, then built small websites and browser extensions. His colleagues' fear of AI is exactly what showed him the FDE direction; his worry is his non-technical background. A Java developer with five years' experience wants to move into FDE, gets leads by posting in content communities, and has already built a dashboard for a friend's factory; a retail stock trader also came to him asking for quantitative trading code. A member with over five years of AI algorithm deployment in chip manufacturing wants to run a one-person company and admitted he understands neither client acquisition nor business. A member on a large-model team at an SOE software unit, working on efficiency for new-energy-vehicle software development, is stuck on requirements comprehension and test quality evaluation, and walked away with a usable testing idea from the room: traffic replay plus verification. Everyone was asking the same question: I have this half of the skill set, how do I get the other half?

The supply-demand mismatch was most visible in this session. A founder whose main business is cloud computing said his channels have accumulated a large client base, the AI deployment demand is real and well-budgeted, but his team is strong on business development and short on delivery confidence. A member selling inside the ecosystem of a leading foreign-trade B2B platform was the exact inverse: the platform is pushing AI products hard this year, he has started selling, his clients have a rough grasp of AI but no deployment guidance, and he has client resources but no technology, weighing whether to close the technical gap himself or find a technical co-founder. One side has work and no hands; the other has hands and no work. What separates them is the trust and pricing machinery this industry has not yet grown.

Hangzhou contributed several judgments that reached room-wide consensus. First, engineering is no longer the moat: agents will readily help you, and engineers on generic stacks are easy to find, but people who understand a specific business domain are hard to find. The FDE's core moat is domain business knowledge. Second, business data matters more than business logic: most corporate data cannot be fed to agents as-is, and data infrastructure is itself the opportunity. Third, clients pay for exactly two things: ROI they can compute, or making the boss happy. SOE deals that come with detailed PRDs are easy to execute and easy money, but they barely differ from traditional outsourcing and command no premium. Fourth, AI transformation must be driven by the boss in the top seat; bottom-up pushes rarely move, and before signing, check your counterpart's authority. The acquisition and screening playbook was equally blunt: for clients with no budget and no understanding, charging a consulting fee first is the best filter.

One overseas reference kept being cited: OpenAI and Anthropic have each formed joint ventures with PE firms to lift portfolio-company margins, in essence using capital relationships to remove transaction friction and accelerate AI penetration. Silicon Valley startups have the last generation's toB muscle and VC backing, which makes FDE comparatively easy; Chinese VCs care more about grand trends, the FDE ramp is long, and the toB narrative is systematically undervalued in China. On billing, a member who serves as COO of a Shenzhen hardware company while running an FDE practice offered his three-part kit: train management and staff separately, start billing the moment the diagnostic phase begins on-site, then switch to project-based fees. The team formula also converged in this session: a domain expert plus an engineer with project experience.

---

5. Beijing #004: Systems, Organizations, and Client Psychology

July 4, a Saturday afternoon, roughly 30 people.

Beijing had the highest resource density and the widest spectrum. The first speaker of the day was a data annotator: he automated his job of copy-pasting evaluation sets from spreadsheets into chat windows with a Python script, packaged it as an EXE, spotted the FDE direction and decided to pivot. He dressed up his resume, sent it out, and found real market demand, but every time someone asks "how do you charge," he has no answer. At the other end of the same afternoon: the founder of an AI brand-marketing company with tens of millions of yuan in annual revenue, there to recruit a technical co-founder; a medical information-services company with deep roots in hospital invoicing, looking to go deeper into hospital economic-operations management platforms; and a veteran with nearly 20 years in hotel franchising, carrying a product concept billed annually at 10,000 to 40,000 yuan per property, looking for a development team, with a goal stated at full volume: ride this to an IPO together.

Two young people's stories deserve their own note. One fresh graduate rebuilt a content-platform business with AI from scratch at an agency-side marketing firm, one person going head-to-head against what used to be a 30-person team. Batch generation of posts and data dashboards is already iterating, some of the numbers hold up, and the next step is taking on FDE contracts. A graduate student built an AI agent that helps foreign tourists hail rides, find restaurants, and plan itineraries, and is exploring overseas client acquisition. What they share is that neither waited for anyone's permission: build it first, then come to the room looking for an amplifier.

The discussion in this session leaned distinctly toward systems and organizations. A government-and-enterprise digitization vendor is building an FDE curriculum and co-developing standards and certification; they use telecom-carrier client relationships as a wedge to serve heavy-industry and energy companies in the north, and their stated ask was matching strong FDEs to large B-side orders. One member wants to build an FDE talent platform: sourcing, training, matching to enterprises, with personal-brand incubation on the side. A carmaker is pushing AI-native reform through org-structure changes, building a structured AI coding knowledge base. A large consumer-goods company is rolling out AI across every department, pulling staff from business lines while hiring outside. A business-analysis role at a big tech firm offered a quantified internal sample: over 50 percent efficiency gains across business-analysis workflows, though external tools were ultimately dropped over problems with the tools themselves. The shift in hiring criteria was named outright by a partner at a Series A AI hardware company: from engineer-leaning to product-manager-leaning, favoring young people with a hybrid background of big tech plus startup plus SE service experience. Another member in the room added a field observation: students from top universities really do learn faster and adapt across more surfaces. His scaling sample was an FDE company in a vertical hardware niche with roughly 20 million yuan in annual revenue, growing its client base through investor referrals; another acquisition reference was a content creator serving private equity and investment banking, where same-industry case studies carry far more trust than cross-industry ones.

The dissection of client psychology was the sharpest of the four cities. A member running multiple AI products (including an AI academic-writing product with steady revenue in the 100,000-yuan range) called it: some companies hire an FDE not for ROI but because the boss wants a person sitting there for peace of mind. So step one is figuring out whether the boss wants ROI or reassurance. A member who moved from vertical agents to B-side work testified with his own detour: a contract-review project stalled, and only when he pivoted to financial and business data analysis did things click. His summary: the boss cares about exactly three things, results, cost, and whether it can be replicated across other lines of business, and cares not at all how you built it. A member with a legal background added the other side: clients' expectations about where AI's capabilities end are generally fuzzy, so boundary management is itself part of the delivery.

Methodological convergence was clearest in this session. Step one of enterprise AI adoption is datafication: small companies start with a database or knowledge base; only at large companies do business-process and org redesign come into play. The knowledge base is the main event: heterogeneous data and expert knowledge must be consolidated into a form agents can call, and what bosses care about most is whether the knowledge base can evolve with the business. That currently has no general solution, and traditional RAG accuracy is degrading. One reusable sample was a knowledge base built for a professional racing team: tires, cars, and logistics all structured, wired into a collaboration platform for agentic search. The room's verdict: a knowledge base plus data skills can solve 80 percent of FDE project problems. Acquisition advice circled back to basics: run your first deal through channels where trust already exists, accumulate data and case studies, and spin up the flywheel. Picking the industry matters more than picking the client: sectors like home services, low-margin and thin on talent, were named as having limited ability to pay. And AI startups should head for incremental markets like overseas expansion and foreign trade, steering clear of the tangled interests that cost-cutting plays stir up in saturated markets.

---

6. Cross-City Comparison: Pricing, Acquisition, Pain Points, Talent

Start by laying the four cities' price points side by side. This may be the densest public sample of Chinese FDE pricing to date:

Shenzhen. Manufacturing plant edge-AI project: expected returns of 3 to over 5 million yuan, with harsh terms including no cloud for data and surrender of IP.

Shenzhen. Cross-border e-commerce supply-chain automation: roughly 60 percent labor reduction, a transition of about two months, over a hundred SKUs a week.

Shenzhen. AI content for lead generation: 50,000 views in 4 days, converting directly into business inquiries.

Shanghai. Integrated high-end life-support equipment plus prediction system: 1 to 1.5 million yuan per case.

Shanghai. Domestic-stack IT (xinchuang) deal: contract around 200 million yuan.

Shanghai. Data annotation converted to agents: 30,000 dollars of model consumption in a single month, above the original cloud cost.

Shanghai. Long-term advisory retainers: on the order of a million yuan per year depending on company size, contracts typically signed for three years.

Hangzhou. Small e-commerce FDE jobs: 500 to 5,000 yuan apiece, installation and training included.

Hangzhou. CRM plus customer-profiling project: 50,000 yuan for phase one, roughly 100,000 in total, a team of two to three.

Beijing. Textile inkjet-positioning outsourcing: 20,000 yuan all-in, replicable and resellable to other textile mills.

Beijing. Yiwu manufacturing AI plus ERP: a subscription taking a 5 percent cut pegged to headcount reduction, 50,000 yuan a year.

Beijing. Hotel AI product concept: annual billing, 10,000 to 40,000 yuan per property.

Beijing. FDE company in a vertical hardware niche: roughly 20 million yuan in annual revenue.

Beijing. AI brand-marketing company: tens of millions of yuan in annual revenue.

Beijing. Consumer AI academic-writing product: steady revenue in the 100,000-yuan range.

On models, each city leaned differently, but together they form a complete map: project-based (person-days, feature points, all-inclusive), subscription (cost-savings cuts, annual billing), consulting-first (charge a consulting fee to screen clients, bill from the moment on-site diagnosis begins), lock-in (technology for equity, the overseas reference of PE joint ventures), and reuse (templatize solutions for resale, then charge for tokens once the work is banked). Two pricing anchors won recognition across cities: the digital employee's annual salary (proposed in Shanghai: price AI services at the salary of the role they replace, which bosses accept more readily), and back-calculating from cost savings (Shenzhen's layoff-ratio revenue share, Beijing's 5 percent subscription cut). The problems Shenzhen exposed (too embarrassed to charge, no standard for quotes) had structured answers by the time of Beijing, such as three-phase billing: corporate training, paid on-site diagnosis, then development, delivery, and maintenance. The first two phases can be bought separately, and for long-term maintenance the advice is to teach the client's internal IT to take over. But the question of how to convert workflow improvement into money went unanswered in all four cities.

On acquisition, the four cities' playbooks overlap heavily: content-based acquisition (short video, content communities; Shenzhen had the sample of 50,000 views in 4 days converting straight into inquiries), first deals through trusted personal networks (Beijing framed it as the starting point of the flywheel), channel reuse by industry veterans (20 years of hotel contacts, industrial-belt resources in Foshan and Yiwu), on-site entry followed by lateral expansion, and referrals backed by same-industry case studies. The difference is in client segments: Shanghai stressed SOE relationship management and the top-down play, Beijing added the route of entering government-and-enterprise accounts through carrier relationships, and Hangzhou was bluntest: charge a consulting fee first and keep the budgetless out.

The pain points sort into four layers, and every city named all four, just in different words. The demand layer: clients cannot articulate their pain, offering only broad notions like AI marketing or AI lead generation, with no acceptance criteria, so vendors dare not promise outcomes. The data layer: corporate data cannot be handed to agents as-is, sensitive data is hard to connect, and clients do not even trust their own data quality. The organizational layer: employee resistance, veteran obstruction, department walls; efficiency gains directly trigger layoff anxiety, and management and staff need two separate narratives. The technical-commercial layer: however high single-task success rates get, chaining tasks collapses the success rate of the full business scenario; model costs are uncontrollable; payment cycles slip; internal reformers have no bargaining power; and AI consulting resists scale.

The talent and transition signals escalated city by city. Shenzhen produced university project-based FDE training and fresh graduates job-hunting with self-built POCs. Shanghai is testing an "expert plus FDE plus intern" placement model across industry and academia, and a doctoral student who patched up his algorithm skills with vibe coding got snapped up in the room. Hangzhou proved the non-technical route works: a financial accountant who automated 60 percent of his job, e-commerce operators, and Java developers each found their own conversion. Beijing supplied the demand-side shift in standards: hiring is moving from engineer-leaning to product-manager-leaning, senior FDEs can go straight to co-founder seats, and curriculum and certification co-building is underway. The consensus running through all four cities: initiative first, domain knowledge is the scarce input, and pure engineering skill is being flattened by agents.

---

7. Trend Calls: The Next 6 to 12 Months

Call one: pricing will converge on anchors and then head into the eve of a price war. Shenzhen named the pricing problems born of being too embarrassed to charge, and the notes logged expectations of a price war and consolidation; Shanghai contributed the digital-employee-salary anchor and million-yuan-a-year retainers; Beijing produced the replicable 5-percent-of-layoffs subscription formula. Anchors will spread faster than practitioners expect, and the low end (the 500-to-5,000-yuan jobs) will be the first to turn cutthroat.

Call two: data infrastructure will displace agent development as the FDE's main battlefield. Hangzhou judged business data more important than business logic; Beijing concluded that a knowledge base plus data skills can solve 80 percent of project problems and that datafication is step one of enterprise AI adoption; Shenzhen argued that proprietary data is the entry point. Three cities converging independently on the same conclusion means the first line item on an FDE quote over the next six months will most likely be data governance, not agents.

Call three: client segmentation will become the line between life and death. Shanghai delivered the structural verdict that the cost-savings pitch goes nowhere in state-owned institutions; Hangzhou noted that SOE deals with detailed PRDs are easy money but barely differ from traditional outsourcing and command no premium; Beijing named low-margin sectors like home services as unable to afford FDEs and argued for incremental overseas markets. Teams that pick the wrong segment will be bled dry at collections (the mining project that dragged on for years without completion is the cautionary tale), and industry-screening ability will separate winners from losers before delivery ability does.

Call four: the efficiency-layoff paradox will move from a moral topic to a step in the delivery process. Shenzhen's bank engineer jokingly called himself the guilty one; Hangzhou's steel-mill project died on veteran resistance; Shanghai has already produced the mature practice of partnering with labor-arbitration and workforce-transition firms and settling compensation and redeployment with the CEO and HRBP during organizational diagnosis. Workforce-transition plans will enter the FDE's standard list of deliverables.

Call five: FDE talent supply will systematize within 6 to 12 months. Shenzhen's university project-based training, Shanghai's industry-academia placements, and Beijing's curriculum-and-certification co-building and talent-platform ventures are three stages of the same thing. Add the talent spillover from big-tech layoffs in coding roles and the demand-side shift from engineers to product managers, and the first cohort of formally trained FDEs will hit the market in the first half of next year.

Call six: the fight over paths to scale will decide whether capital shows up. Beijing's VCs admitted most are still in the getting-acquainted phase with no clear process; the worry that FDE looks like outsourcing and resists scale was relayed by founders in the room as the industry's standing question about FDE. Three answers have already surfaced: bank solutions for reuse and then charge for tokens, technology for equity, and the reference model of overseas model companies forming joint ventures with PE. Whichever produces a replicable sample first will decide whether China's undervalued toB narrative can flip within a year.

---

8. Closing

Four cities, 129 builders, four afternoons, assembling the earliest terrain map of China's FDE ecosystem: Shenzhen's industrial-belt street fight, Shanghai's collections sobriety, Hangzhou's grassroots blue ocean, Beijing's systemic ambition. The industry has no consensus even on its name, and meeting transcription tools cannot spell out the acronym, but it already has a real contract spectrum running from 500 yuan to 200 million.

ha7ch guild's next move is to turn this terrain map into infrastructure: keep running periodic closed-door sessions city by city, so supply and demand keep closing the loop in the same room; make hackathons and sprints the channel through which young people enter real enterprise sites; and bank the pricing anchors, client-screening methods, and delivery lessons that recurred across the four cities, so the next person converting to FDE does not have to start over from "too embarrassed to charge."

"These two years are the biggest blue ocean there is. You have to grab it." That line came from the Hangzhou session. We leave it here exactly as spoken, and we will come back in a year to check the answer.

## 中文

2026 年 6 月 6 日到 7 月 4 日，HA7CH 在深圳、上海、杭州、北京连办了四场闭门 FDE Meetup，每场一个周六下午，四场合计129 位 builder。这份报告基于四场的现场讨论整理而成，是我们能找到的、关于中国 FDE 生态最早的一批一手证词。

先说清楚两件事。第一，到场人数来自报名系统统计（深圳 31、上海 31、杭州 32、北京 35），报告里引用的价格、流水、周期等数字全部来自现场分享原话，未做外推。第二，全部内容已匿名化：观点归属统一表述为 ha7ch guild 成员，只保留行业与背景描述；OpenAI 与 Anthropic 这类公开行业事实除外。

---

一、为什么是现在：有生意，没行业

FDE，Forward Deployed Engineer，前向部署工程师。这个此前只存在于硅谷招聘页上的岗位名称，在中国四座城市的四个下午被密集地讨论、争辩、定价。它在国内还没有统一定义，没有标准报价，没有成熟的入行通道，甚至没有一个所有人都认的中文名字。

但它已经有了真实的合同：2 万包圆的纺织外包单，约 2 亿的信创大单，按裁员比例抽 5% 的 ERP 订阅，单笔 500 元起步的电商小单。这份报告想记录的，正是这个「有生意、没行业」的时刻。

背景是一组错配。深圳场一位云厂商背景的 guild 成员给出了他的观察：自去年底新一代模型发布后，coding agent 的能力爆发，但用户端应用没有跟着爆发，算力消耗集中在少数用户手里，产研团队反而因为 AI 面临裁员，硅谷的 startup 几乎都在往 FDE 方向挤。能力过剩，落地不足。错配的缝隙里，站着的就是 FDE。

杭州场一位从大厂视角观察行业的成员把这个判断推得更远：上一代软件生意是卖工具，这一代 AI 生意的交付物是「增收入」或者「降本裁员」本身；大厂因为 coding 场景渗透已经开始裁员，而 90% 以上的行业还没有被渗透。他的原话被当场记进了金句：「这两年就是最大的蓝海市场，一定要抢。」

四场会呈现的不是二手转述，而是一线交付者带着回款单、失败复盘和裁员愧疚感的一手证词。下面按城市走一遍。

---

二、深圳 #001：产业带现场，先干出来再谈收钱

6 月 6 日，周六下午，31 位。

深圳场是典型的产业带现场，案例密度四城最高，而且全是带体温的词：驻场、提成、人效、裁员。开场自我介绍就能看出光谱：有人用大模型解决纺织行业 RGB 转 CMYK 的难题，有人在陪伴机器人公司做营销，有人在云厂商做售前，有人从销售转做 FDE。

案例先说小的。一位独立开发者气质的成员，几天手搓出一个照片自动分类工具，解决的是朋友的真实痛点：一位传统零售业务员，每月要手动整理两三千张照片。工具用视觉模型加本地算法。现场随即展开定价讨论：这个东西该收多少钱，按业务员的时薪算，还是别的锚点。没有结论，但所有人都意识到，定价是这个行业眼下最大的空白。另一位成员的单子更「野」：帮财务公司做自动开发票，用 agent 操作浏览器跑通整个流程，已经上线。还有一位原本做财务分析的成员，用 AI 提效自己的工作之后干脆辞了职，帮在海外开餐馆的亲戚做了网站和外卖系统，用划定配送区域、预先收费解决外卖费用不稳定，又用 Telegram bot 做了员工自助选班和自动算工资。这类单子不会出现在任何招聘网站上，但它们是真实发生的 FDE 业务。

案例再说大的。一位深耕石油化工信息化的成员分享了三个项目：用 RAG 解决企业内部技术专家被频繁答疑的困扰，后来拓展到外部售前；外贸订单追踪系统因为邮件格式不稳定，停在半成品；在既有设备管理系统上加 AI 辅助决策，落地顺利。一位在某外资银行做核心交易系统多年的成员，推动交易系统 AI 化，上线后日处理大量交易，行内随后缩减人员，他自嘲是「罪人」。一位跨境电商出身的成员把选货单逻辑和出关单据整理成算式套进 ERP，每周上百个 SKU 的运输流程自动化后降低约 60% 人效，一部分员工被裁，一部分转去操控系统，转型周期约两个月。一位科技公司 CTO 说得更直接：AI 化之后能用三四天完成以前半年以上的开发任务，效率提升和裁员焦虑是同一枚硬币的两面。

一个悬而未决的单子能看出市场的边界条件：某数字化程度很高的制造工厂，自研系统，想接入 AI，端侧项目预期收益 300 至 500 多万。但条件苛刻：数据不上云、端侧部署、供应商交出知识产权。原团队没接，现场另有成员当场表示想接。同一个条款，有人看到的是风险，有人看到的是门票。

深圳场的独特性在于产学研罕见地同桌。华南某高校一位工科学院副院长现场发起 FDE 项目制培训：跨专业招学生，请实战 FDE 授课，组队做真实企业项目，当场征集授课者。供给侧同样活跃：从新加坡高校毕业的应届硕士自己搭了三个 B2B 的 POC 带着来求职，裸辞的大厂人在找方向，一位 00 后游戏引擎技术出身的成员，已经给母亲做了一个 AI 分身用于外贸获客。一位做工程勘察数字化的成员说出内部改造者的普遍处境：工具做了不少，但在公司内部提效议价权低，正在犹豫要不要出来单干。现场给他的建议只有一句：出来赚钱。

商业模式在这一场聊得最直接也最野：按裁员或增长比例分成，技术换股权，AI roll-up（融资收购传统企业、用 AI 改造提升利润率再滚动收购），以及把项目拆成培训、陪跑、画饼三段分开收费。定价焦虑是全场暗线，从「抹不开脸收钱」到「按客户焦虑程度报价」。现场也留下了对市场竞争的预期：价格战可能出现，行业会走向整合与规范化。

---

三、上海 #002：把钱收回来的学问

6 月 13 日，周六下午，31 位。

上海场是一场极其务实的商务局，讨论重心不在技术，而在回款。金融浓度显著高于其他城市：外资银行的资产配置产品经理、做过 9 段金融实习的本科生、券商背景的学生同场，把强监管、可追溯可审计、私有化部署、智能投顾政策评估这些别处少见的约束条件摆上了桌面。

先从定义讲起。一位组织者背景的成员给 FDE 划了线：不是数据标准化、搭数据库、部署聊天机器人的外包，而是让企业决策流程变短的角色。他举的例子是航空公司：下雨能不能飞、紧急情况怎么处理，AI 缩短的是决策链路，不是文档处理时间。另一位成员的项目把定义具象化了：他为某职业车队做 agent，负责公关、后勤，提前决策人员住宿和货物运输。他的总结被现场记住：AI 提效不一定是让赛车开得更快，而是让决策更快、车手休息更好。

最硬的干货来自传统行业老兵。一位做了十多年智能化改造的成员复盘智慧矿山项目：含硬件的项目前置工作多，误差和成本容易失控，验收标准不明确，甲方领导随时可以拿问题当理由推迟付款。最极端的样本是西部某矿业项目，因甲方现场落实和预算问题拖了数年没有完成，硬件质保期都过了。他的对策不是技术，是客情：跟企业每个层级建立沟通，从一开始就筛掉不适合进的行业。一位国有信息化企业的操盘者用一个亿元级的信创大单做例子，给出更结构性的判断：FDE 在国有单位不适合落地，谈省钱提效结算要层层审批，逻辑走不通；国央企只对上负责，验收标准就是让上面的人满意，要做就先跟最高层达成共识，自上而下推。

一位做整体方案销售的成员算了两笔账。利润那笔：含高端生命支持设备与预测系统的整体方案，单案例谈到 100 至 150 万，交付边界明确，利润空间大，但项目做到 60% 至 70% 时，因为红头文件有周期、学校资源和年度预算的问题，无疾而终。成本那笔：一条数据标注业务线 agent 化后效率确实提高，但当月模型消耗花掉 3 万美元，比原来的小规模云成本还高，且流程跑完仍需人工审核。成本不可控，直接卡死了他后续报价的能力。

组织问题在这一场被摆到了台面上。一位做销售全流程自动化的成员说，他的系统针对工业企业的标书和招投标流程，基本做到零员工输入，但员工知道智能体要替代自己的工作后，沟通阻力立刻出现。现场给出的解法成熟得让人意外：与专业人员安置公司合作，在组织诊断阶段就跟 CEO 和 HRBP 谈清补偿、转岗和竞业；能转岗的转岗，能培训的培训。物流行业的教训类似：提效方案处处受阻，最后把功能抽成插件嫁接到企业原有 ERP 上；业财一体这种动核心系统的事，能不碰就不碰。

打法层面，一家较早做 FDE 业务的 AI 工具公司给出路径：先用通用需求进入企业、快速建立信任，再用深度需求获取高毛利。一位有咨询背景、在做企业诊断的成员补充了中国 toB 生态的特点：产品是卖给决策者的，不是卖给使用者的。数据安全被反复提及：有团队给头部消费品牌做 AI 项目，客户文档脱敏全部用本地模型处理；某地国企的 AI 转型项目有预算，但对 agent 技术了解不足，市场教育只能靠培训一点点做。

还有两个细节解释了为什么非技术因素重要：微软 Copilot 不好用还卖得好，因为 SLA 出问题有补偿，品牌本身就是采购理由；航天系统为了长周期项目的稳定性，宁可坚持用旧版本软件。把这两条放在一起，就是 toB 的真实采购逻辑。

供需闭环在房间内直接发生：一家储能新材料企业现场找算法合作方，想从矿端开始做选矿和工艺优化；一位传统工科背景的博士生，四五月份才接触 vibe coding，现场就被在招实习生的团队接住了。散场时留下的是对行业组织化的真实诉求：有成员提议成立 FDE 行业协会，统一认知、制定准则。

---

四、杭州 #003：草根蓝海，毛细血管里的 AI 落地

6 月 27 日，周六下午，32 位。

杭州场是四城里最草根、最电商味的一场，价格光谱极宽。一头是单笔 500 到 5000 元的小单快跑：一位从跨境电商运营自学 coding 转型的成员，在电商公司做 FDE，业务是内容裂变（复刻爆款带货视频）、RPA 自动化（模拟人工操作网页）和数据仪表盘（用他的说法，土老板最欢迎这类东西），收费看客户预算，含软件安装和培训，获客靠短视频平台和招聘平台，筛客户的办法直白：用包装过的开源项目和 demo 先把不付费的滤掉。另一头是一位敢想敢做的成员，到杭州才两周就靠关系签下 CRM 加 B 端询盘客户画像的项目：一期 5 万，整体约 10 万，团队 2 到 3 人。

中间夹着的案例五花八门。刚毕业的成员入职一家企业服务商做 FDE，入职不久就被派到寺庙驻场，教师傅用 AI、配置系统，他的现场报告是：大师们好说话、接受度高，但要手把手教。一位泛工业方向解决方案工程师复盘了钢厂项目为什么推不动：不是技术不行，是客户对自己的数据质量没自信，老师傅担忧被 AI 取代，项目死在了技术之前。有大厂里做高性能计算的工程师，把算法部署的长链路用 agent 自动化了，但在大厂内部用不了最新模型、预算受限，内部流程调整空间也小，他的自我评价是：离技术近，离市场远，来这里想听 FDE 在一线跟客户打交道的故事。

转型者浓度是这一场的底色。一位连锁企业的财务会计，管着上百家门店的账，用 AI 编程助手自动化了 60% 的工作，同事对 AI 的恐惧反而让他看到了 FDE 这个方向，担心的是自己非技术出身。一位有 5 年经验的 Java 开发想转 FDE，靠在内容社区发帖获客，已经帮朋友的工厂搭了大屏，还有炒股散户找上门让他写量化交易代码。一位在芯片制造行业做了 5 年多 AI 算法落地的成员想做一人公司，坦承不懂获客和商业。一位在国企大模型小组为汽车软件开发提效的成员，卡在需求理解和测试质量评估上，现场直接收到可用的测试思路：流量回放加验证。各路人马问的是同一个问题：我这半边能力，怎么补上另外半边。

供给和需求的错位在这一场看得最清楚。一位主业做云计算的创业者说，他靠渠道积累了大量客户，AI 落地需求真实存在而且预算充足，但他的团队商务有余、交付信心不足。一位在头部外贸 B2B 平台生态里做销售的成员正好相反：平台今年力推 AI 产品，他已经开始售卖，客户对 AI 有初步认知但缺落地指导，他有客户资源缺技术，正在考虑补技术短板还是找技术合伙人。一边是有活没人干，一边是有人没活干，中间隔着的就是这个行业还没长出来的信任和定价机制。

杭州场贡献了几条全场共识级的判断。其一，工程不再是门槛：很容易有 agent 帮你，也很容易找到通用技术栈的工程师，但很难找到懂某个业务领域的人，FDE 的核心壁垒是领域业务知识。其二，业务数据比业务逻辑更重要：企业数据大多无法直接供 agent 使用，数据基建本身就是机会。其三，客户付费考量只有两类：按 ROI 算账的，和让老板开心的；国央企出详细 PRD 的单好做、易赚钱，但和传统外包流程差别不大，难收溢价。其四，AI 转型必须老板一号位推动，从下往上基本推不动；商务签单前先看对接人的权限。获客与筛客的打法也直白到底：对没预算没认知的客户，先收咨询费是最好的筛选器。

还有一条海外参照被现场反复引用：OpenAI 与 Anthropic 分别与 PE 成立合资公司，改造投资组合公司的利润率，本质是用资本关系解决交易摩擦、加速 AI 渗透。硅谷的 startup 有上一代 toB 的积累和 VC 支持，做 FDE 相对容易；而国内 VC 更关注宏大趋势，FDE 爬坡周期长，toB 叙事在中国被系统性低估。计费方法上，一位同时做 FDE 业务的硬件公司 COO 给出三件套：管理层与员工分开培训，诊断层入驻即计费，之后走项目费用制。团队配置公式也在这一场收敛：行业专家，加上有项目经验的工程师。

---

五、北京 #004：体系、组织与甲方心理学

7 月 4 日，周六下午，35 位。

北京场资源密度最高，光谱最宽。开场第一位发言者是一位数据标注员：他把评测集从表格复制粘贴到对话框的工作用 Python 脚本自动化，打包成了 EXE，看到 FDE 方向后想转型，包装简历投出去发现市场需求真不少，但每次被问到「你怎么收费」就答不上来。同一个下午的另一端，是一家年营收数千万的 AI 品牌营销公司创始人，来招技术型联合创始人；一家深耕医院发票服务的医疗信息服务公司，想深入做医院经济运行管理平台；还有一位近 20 年酒店招商加盟经验的老兵，拿着按年付费、单店 1 万到 4 万的产品设想找研发团队，目标说得很大：一起冲击上市。

两个年轻人的故事值得单独记下。一位刚毕业的成员在乙方广告营销公司从零到一用 AI 重构内容平台业务，一个人对着原来 30 人的团队 PK，批量生成图文和数据看板已经迭代出来，下一步想接 FDE 商单。一位在读研究生做了帮外国游客打车、找餐厅、安排行程的 AI agent，正在探索出海获客。他们的共同点是没有等任何人给许可：先做出来，再来现场找放大器。

这一场的讨论明显偏体系和组织。一家政企数字化服务商在打造 FDE 课程体系、参与标准和认证共建，以运营商客情为切口服务北方重工业和能源企业，现场发布的需求是找优秀 FDE 匹配大 B 订单。有成员想做 FDE 人才平台：找人、培训、对接企业，附带个人 IP 孵化。某车企在通过组织架构变革推动 AI native 改革，构建结构化的 AI coding 知识库。一家大型消费品企业全部门推 AI 化，从业务线抽调员工，同时对外招人。某大厂的经营分析岗给出了内部提效的量化样本：商业分析各环节提效超过 50%，外部工具则因工具本身的问题用了又停。招聘标准的转向由一位 A 轮 AI 硬件公司合伙人说破：从偏工程师转向偏产品经理，偏好年轻、有大厂加创业公司加 SE 服务经验的复合背景；现场另有成员补充观察：顶尖高校的学生学习能力和多端适应力确实强。他分享的规模化样本是一家垂直硬件领域的 FDE 公司，年营收约 2000 万，靠投资人关系转介绍扩客；另一个获客参照是一位服务私募投行的自媒体博主，同业案例的信任背书比跨行案例强得多。

对甲方心理的拆解是四城最犀利的。一位运营多个 AI 产品的成员（其中 AI 论文产品稳定有 10 万级流水）点破：有的公司招 FDE 不是要 ROI，是老板想要一个人放在那里心安。所以第一步要分清楚，老板要的是 ROI 还是心理安抚。一位从垂类智能体转 B 端的成员用自己的弯路作证：合同审核项目遇阻，转做财务和业务数据分析才跑通，他的总结是老板只关注三件事，效果、成本、能不能复制到其他业务，完全不在乎你怎么实现。一位法律背景的成员补充了另一面：客户对 AI 能力边界的期待普遍不明确，边界管理本身就是交付的一部分。

方法论层面的收敛在这一场最清晰。企业 AI 化的第一步是数据化：小公司先做数据库或知识库，大公司才谈业务流程和组织架构重构。知识库是重头戏：要把异构数据和专家知识整合成 agent 能调用的形态，老板最关心的是知识库能不能随业务自进化，这一点目前没有通解，传统 RAG 的准确度在下降。一个可复用的样本是给某职业车队搭的知识库：轮胎、赛车、后勤信息全部结构化，接上协同办公平台做 agentic search，现场的判断是知识库加 data skills 能解决 80% 的 FDE 项目问题。获客建议回到朴素：从身边有信任关系的渠道跑出第一单，形成正向飞轮；选行业比选客户重要，家政这类低毛利、低人才密度的行业被点名支付能力有限；AI 创业应该走出海、外贸这样的增量市场，避开存量市场里降本增效的利益纠葛。

---

六、横向对比：定价、获客、痛点、人才

先把四城的价格数据点摆在一起。这可能是目前关于中国 FDE 定价最密集的一份公开样本：

深圳 · 制造工厂端侧 AI 项目：预期收益 300 至 500 多万，附数据不上云、交出知识产权等苛刻条件。

深圳 · 跨境电商供应链自动化：降约 60% 人效，转型周期约两个月，每周上百个 SKU。

深圳 · AI 内容获客：4 天 5 万播放量，直接带来企业询单。

上海 · 高端生命支持设备加预测系统整体方案：单案例 100 至 150 万。

上海 · 信创大单：合同约 2 亿。

上海 · 数据标注 agent 化：单月模型消耗 3 万美元，高于原云成本。

上海 · 长期陪跑咨询：按企业规模每年百万量级，合同多签三年。

杭州 · 电商 FDE 小单：单笔 500 至 5000 元，含安装加培训。

杭州 · CRM 加客户画像项目：一期 5 万，整体约 10 万，2 至 3 人团队。

北京 · 纺织喷墨定位外包：2 万包圆，可复制转卖给其他纺织厂。

北京 · 义乌制造业 AI 加 ERP：按裁员比例抽 5% 订阅费，一年 5 万。

北京 · 酒店 AI 产品设想：按年付费，单店 1 万至 4 万。

北京 · 垂直硬件领域 FDE 公司：年营收约 2000 万。

北京 · AI 品牌营销公司：年营收数千万。

北京 · C 端 AI 论文产品：稳定 10 万级流水。

模式上，四城各有偏重，但拼起来是一张完整图谱：项目制（人天、功能点、包圆），订阅制（降本抽成、按年付费），咨询先行（先收咨询费筛客、诊断入驻即计费），绑定制（技术换股权、与 PE 合资的海外参照），复用制（方案模板化转卖、沉淀后收 token 钱）。定价锚点有两个被多城认可：数字员工年薪（按替代岗位的年薪给 AI 服务定价，老板更容易接受），和按降本增效倒算（深圳的按裁员比例分成，北京的抽 5% 订阅）。深圳暴露的问题（抹不开脸收钱、报价没标准），到北京已经有了三阶段计费这类结构化答案：企业内训、驻场诊断收费、开发交付加运维，前两段可以单独买，长期运维建议教会企业内部 IT 自己接手。但「工作流程改善的价值怎么折算成钱」这个问题，在四城都没有解。

获客上，四城打法高度重叠：内容获客（短视频、内容社区，深圳有 4 天 5 万播放带来询单的样本），熟人信任关系跑首单（北京总结为正向飞轮的起点），行业老兵渠道复用（酒店 20 年人脉、佛山义乌产业带资源），驻场切入后横向扩展，转介绍加同业案例背书。差异在客群：上海强调国央企的客情关系和自上而下打法，北京补充了以运营商客情切入政企的路径，杭州最直白，先收咨询费把没预算的挡在门外。

痛点可以归成四层，四城都在说，只是说法不同。需求层：客户说不清痛点，只提 AI 营销、AI 获客等宽泛概念，没有验收标准，乙方不敢承诺效果。数据层：企业数据无法直接给 agent 用，敏感数据难打通，客户甚至对自己的数据质量没自信。组织层：员工抵制、老师傅阻挠、部门墙，提效直接触发裁员焦虑，管理层与员工需要两套叙事。技术与商业层：单个任务成功率再高，多任务串联后整个业务场景的成功率会大幅下降；模型消耗成本不可控；回款周期失控；企业内部改造者议价权低；AI 咨询难规模化。

人才与转型路径的信号在四城逐场升级。深圳出现高校 FDE 项目制培训和应届生自建 POC 求职；上海在摸索「专家加 FDE 加实习生」的产学研派驻模式，博士生靠 vibe coding 补齐算法能力后现场被抢；杭州证明非技术出身可行，财务会计自动化 60% 工作、电商运营、Java 开发各有转法；北京给出了需求侧的标准变化，招人从偏工程师转向偏产品经理，高阶 FDE 可以直通联合创始人席位，课程体系与认证共建已经启动。贯穿四城的共识：主观能动性优先，领域知识是稀缺项，纯工程能力正在被 agent 拉平。

---

七、趋势判断：未来 6 至 12 个月

判断一：定价将从锚点收敛走向价格战前夜。深圳场已点名「抹不开脸收钱」带来的定价问题，纪要同时记下了价格战与行业整合的预期；上海给出数字员工年薪和陪跑年费百万量级的锚点；北京出现按裁员比例抽 5% 的可复制订阅公式。锚点扩散的速度会快于从业者预期，低端市场（500 至 5000 元的小单）最先卷。

判断二：数据基建将取代 agent 开发成为 FDE 的主战场。杭州场判断业务数据比业务逻辑更重要，北京场总结知识库加 data skills 可解决 80% 的项目问题、企业 AI 化第一步是数据化，深圳场提出独家数据就是切入位点。三城独立收敛到同一结论，意味着未来半年 FDE 项目的第一张报价单大概率是数据治理，而不是 agent。

判断三：客户分层将成为生死线。上海场对国有单位给出「省钱提效叙事走不通」的结构性否定，杭州场指出国央企出详细 PRD 的单好做易赚钱、但和传统外包流程差别不大且难收溢价，北京场点名家政这类低毛利行业付不起 FDE，并主张走出海增量市场。选错客群的团队会在回款环节被拖死（拖了数年没有完成的矿业项目是前车之鉴），行业筛选能力将比交付能力更早分出胜负。

判断四：提效裁员悖论将从道德话题变成交付流程的一部分。深圳的银行工程师自嘲罪人，杭州的钢厂项目死于老师傅抵触，上海已经出现与安置公司合作、在组织诊断阶段谈清补偿与转岗的成熟做法。人员安置方案会进入 FDE 的标准交付物清单。

判断五：FDE 人才供给将在 6 至 12 个月内体系化。深圳的高校项目制培训、上海的产学研派驻、北京的课程体系与认证共建和人才平台创业方向，是同一件事的三个阶段。叠加大厂裁员带来的人才溢出和招人标准转向产品经理的变化，第一批「科班 FDE」会在明年上半年进入市场。

判断六：规模化路径之争将决定资本是否入场。北京场的 VC 坦言大多还在接触阶段、流程尚不明确；「像外包、难规模化」则被现场创业者转述为业界的普遍顾虑。现场已出现三条回应路径：方案沉淀复用后收 token 钱，技术换股权，以及海外模型公司与 PE 合资的参照模式。哪条先跑出可复制样本，决定国内 toB 叙事被低估的局面能否在一年内翻转。

---

八、结语

四座城市，129 位 builder，四个下午，拼出的是中国 FDE 生态最早的一张地形图：深圳的产业带肉搏，上海的回款清醒，杭州的草根蓝海，北京的体系野心。这个行业还没有名字上的共识，连会议转写工具都拼不对它的全称，但已经有了从 500 元到 2 亿的真实合同谱系。

ha7ch guild 的下一步方向，是把这张地形图变成基础设施：按城市持续办周期性闭门会，让供需两端继续在同一个房间完成闭环；把黑客松和 Sprint 做成年轻人进入真实企业现场的通道；沉淀四城反复出现的定价锚点、筛客方法和交付教训，让下一个转型 FDE 的人不必从「抹不开脸收钱」重新走一遍。

「这两年就是最大的蓝海市场，一定要抢。」这句话出自杭州场。我们把它原样放在这里，一年后回来对答案。


---

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

> Published 2026-07-07 · By lawted · 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 最终不是靠说服证明自己的，而是靠在很短时间内做出可见结果证明自己的。


---

# A Pair of Scissors in the Gap / 缝隙里有一把剪刀

> Published 2026-06-04 · By lawted · Canonical: https://ha7ch.com/writing/scissors-in-the-gap

## English

A while back I wrote The Ignored Continent. I said the biggest market isn't inside the big tech companies. It's on every industrial belt you can't see. In Shenzhen alone there are 8,000-plus companies doing ocean freight forwarding, and their workflows are roughly the same — orders come in over WeChat, the paperwork gets done in Excel, files get passed around as PDFs, everything reconciled by hand, keyed in by hand, chased for payment by hand. I said big tech can't get in, VCs won't touch it, outsourcing does it badly, and the bosses can't do it themselves. That's the gap. And HA7CH was going to crawl into it.

So I actually crawled in. Headfirst into freight forwarding — a real company, real shipments, real operators.

Now I'm going to be honest with you about what I hit in that gap.

I hit a pair of scissors.

---

Let me spell out what these scissors look like.

A freight forwarder with thirty or forty people spends maybe twenty thousand RMB a year on software. I can help him. I can take the work he's been doing by piling up human labor and rewrite it with AI, and genuinely cut headcount. That part I've verified — the boss grabbed my hand and said you have to come help us cut costs and boost efficiency.

But I can't collect the money. Because his price ceiling is welded to a line below twenty thousand. The labor I pour in costs more than that twenty thousand. Low-ACV customers: I can do the work, but I can't make money.

So I go upmarket. Bigger customers, higher ACV.

And here's the problem. The moment the ACV is high enough to be worth my time, the customer is big enough and complex enough that one guy with a MacBook simply can't carry it. He wants security, compliance, SLAs, someone who picks up the phone at 3 a.m. when something breaks, a whole delivery org and a chain of accountability.

And that is exactly what big-tech FDE has and I don't. What I have is individual capability. What he wants is organizational capability.

---

So you see it, right? ACV and a builder's capability point in opposite directions.

The higher the ACV, the bigger and more complex the customer, the more org they need. The lower the ACV, the more I can actually do it, but the less money there is. The two blades of these scissors are joined together. I try to save my margin by raising the price, and the instant I raise it, the customer starts demanding the one thing I can't give.

That narrow band in the middle — ACV high enough to make money, simple enough for one person to deliver — is so thin it barely exists.

---

What sent a chill down my back wasn't "freight forwarding doesn't work." It was something else.

In The Ignored Continent I said big tech can't get in, because they'd never send a team for a thirty-person logistics company. I treated that as the opportunity.

But now I get it: the reason it isn't worth a team for big tech is the same reason it isn't worth my people either — this company can't afford FDE labor.

That gap is empty not because everyone else is stupid. It's empty because "delivery by humans" doesn't close the math at either end. I saw the gold. I just never put a price on the scissors that were locking it up.

---

I sat with it for a long time and almost gave up. But one thing saves this — and only one.

These scissors only cut when delivery runs on people.

The moment what I distill out of a company turns into software that runs on its own, without me — both blades open at once.

Low ACV becomes profitable: marginal cost approaches zero, and I can carry an entire long tail.

High ACV becomes serviceable: what carries the complexity is the product, not my body sitting in a chair.

Software is the only thing that can touch both blades of the scissors at the same time.

---

I used to hold up Palantir as the model FDE. But Palantir never made its money from FDE. It made it from Foundry.

FDE is the land — the act of walking in. The product is the business. The FDE labor is subsidized by the product's margin, and in the end it gets replaced by the product.

My mistake was treating "walking in" as the business itself. The scissors are the punishment for that confusion.

---

Honestly, these past few weeks I argued with myself round after round.

I said, AI parsing of shipping instructions — that's a moat, right? No. Anyone who wires up a model can copy it in a week.

Okay, the two-sided parsing of a whole reconciliation email? Also copyable. And right now it still gets things wrong all the time.

Fine, then I just take over the work entirely and run it for the customer (OPC)? The trust won't hold. When something breaks, who pays for it.

Then volume? The ACV is twenty thousand. Capped.

Then replicate to competitor number two, number three? Every single one makes you re-learn the whole workflow from scratch. It doesn't save you anything.

And now, another pair of scissors.

Five different angles, all slamming into the same wall. And the wall is one sentence: can the knowledge I distill out of a company become software that delivers itself — and gets more accurate the more it's used.

---

And then I have to admit the most embarrassing thing.

In HA7CH Is a FDE Accelerator I wrote the sexiest line of all: every traditional company can be distilled exactly once, and after that all the knowledge lives inside this AI system, so it's very hard for anyone to re-distill, and the boss won't want to switch.

That line — I've never verified it. Not once.

The product I built does quietly record every human correction: what the AI filled in, what the human changed it to in the end, stored in the database pair by pair. That's the hardest half of distillation, and I built it.

But the other half — feeding those corrections back so it gets better next time, so it actually gets thicker the more it's used — I haven't written a single line of. That table only takes in. Nothing comes out.

The load-bearing brick of my whole theory — I laid half of it, and I've never once put weight on it to see if it holds.

---

So I've decided to stop.

Stop writing theory. Stop finding new reasons it won't work — I've already found five, and every one of them ends at the same wall I've never pressed on.

No argument, however clever, will pry those scissors open. Only one thing will: build the other half of that wall, and put weight on it once.

This takes a week to settle. I feed back those "AI got it wrong, human got it right" pairs, and I watch whether — for the same customer, the same overseas agent's invoices — the human correction rate stays flat, or bends down.

If it stays flat — then I'll accept it. This is a service business capped by the scissors. It can earn a few people their first bucket of gold, but it isn't the thing I wanted. Accepting it early is worth more than accepting it late.

If it bends down — then the scissors are pried open. And the ignored continent is real again.

---

When I wrote MVP as Research, I said: drop the food on the ground first and see if anyone eats it. If someone eats it, then you give them a plate.

Freight forwarding is the food I dropped on the ground. Someone took a bite. The research has come back now — it's not that no one's hungry. It's that there's a pair of scissors on this patch of ground.

I'm not going to argue my way onto that continent with my mouth anymore. I'm going to walk over, put weight on that wall, and find out whether it holds.

That's it.

## 中文

前段时间我写了《被忽略的大陆》。我说,最大的市场不在大厂里,在每一条你看不见的产业带上。光深圳做船单物流的就有 8000 多家,工作流大同小异——微信接单,Excel 做单,PDF 传文件,人工核对,人工录入,人工催款。我说,大厂进不来,VC 不投,外包做不好,老板自己搞不定。这就是那个缝隙,HA7CH 要钻进去。

然后我真的钻进去了。一头扎进货代,扎进一家真实的公司、真实的单子、真实的跟单员。

现在我要诚实地告诉你,我在那个缝隙里撞到了什么。

我撞到了一把剪刀。

---

先说清楚这把剪刀长什么样。

一家三四十个人的货代公司,一年在系统上花两万块。我能帮他。我能把他那套靠人肉堆出来的活,用 AI 重写一遍,真的能省人。这一点我验证了——老板握着我的手,说你一定要过来帮我降本增效。

但是我收不到钱。因为他的价格天花板,就焊死在两万块那条线下面。我投进去的人力,比这两万块贵。低客单的客户,我做得动,但不赚钱。

那我往上走,找大一点的、ACV 高一点的客户。

问题就来了。ACV 一旦高到值得我做,这个客户就大到、复杂到一个背着 MacBook 的人根本扛不住。他要安全,要合规,要 SLA,要出了事凌晨三点有人接电话,要一整套交付体系和问责。

而这套东西,恰恰是大厂 FDE 有、我没有的。我有的是个体能力,他要的是组织能力。

---

所以你发现没有:ACV 和一个 builder 的能力,是反着走的。

ACV 越高,客户越大越复杂,越需要组织;ACV 越低,我越做得动,但越不赚钱。这把剪刀的两片是连在一起的。我想用涨价去救毛利,可涨上去的那一刻,客户就开始要我恰好给不了的东西。

中间那条「ACV 高到能赚钱、又简单到一个人能交付」的窄带,薄得几乎不存在。

---

这一刀下去,让我后背发凉的不是「货代不行」。是另一件事。

我在《被忽略的大陆》里说,大厂进不来,因为不可能为了一个三四十人的物流公司专门派一个团队。当时我把这当成机会。

但现在我明白了:让大厂派团队不划算的原因,和让我派人也不划算的原因,是同一个——这家公司付不起 FDE 的人力。

那个缝隙之所以空着,不是因为别人都蠢。是因为「靠人交付」这件事,在两头都不闭合。我看到了金子,却从来没给那把锁住金子的剪刀定过价。

---

我想了很久,差点就放弃了。但有一个东西救了这件事——而且只有这一个。

这把剪刀,只在「交付靠人」的时候才剪得动。

如果我从一家公司蒸馏出来的东西,变成了一个不靠我、自己会跑起来的软件——那两片刀刃,同时松开了。

低客单变得能赚钱:边际成本趋近于零,我可以铺一整条长尾。

高客单变得能接:扛复杂度的是产品,不是我那副坐在椅子上的身体。

软件,是唯一能同时碰到剪刀两片的东西。

---

我以前一直把 Palantir 当 FDE 的样板。可 Palantir 从来不靠 FDE 赚钱,它靠 Foundry。

FDE 是 land,是走进去的那一下;产品,才是生意。FDE 那点人力是被产品的毛利补贴的,而且最终会被产品替代。

我犯的错,是把「走进去」这个动作,当成了生意本身。剪刀差,就是对这个混淆的惩罚。

---

其实这几个星期,我一个人跟自己吵了好几轮。

我说,AI 解析托书是护城河吧?不是,谁接个模型一周都能抄。

那整封对账邮件的双侧解析呢?也会被抄,而且现在还老出错。

那我干脆把活全接过来、替客户跑(OPC)呢?信任扛不住,出了事谁赔。

那靠走量呢?客单两万,封顶。

那同行第二家、第三家复制呢?每家都得重新摸一遍业务流,根本不省力。

现在,又来一把剪刀。

五个不同的角度,全撞在同一面墙上。这面墙,是同一句话:我从一家公司蒸馏出来的知识,到底能不能变成一个「自己会交付、而且越用越准」的软件。

---

然后我得承认一件最难堪的事。

我在《HA7CH 是一个 FDE 加速器》里写过最性感的一句话:每个传统公司有且只能被蒸馏一次,蒸馏完,所有知识都进入这个 AI 系统,别人再想蒸馏就非常难,老板也不会想切换。

这句话,我从来没验证过。一次都没有。

我做的产品,确实在偷偷地把人工的每一次修正都记下来:AI 当时填了什么,人最后改成了什么,一对一对地存进库里。这是蒸馏里最难的一半,我把它建好了。

但另一半——把这些修正喂回去,让它下一次更准、让它真的越用越厚——我一行都没写。那张表,只进不出。

我理论里最承重的那块砖,我盖了一半,从来没压过它到底承不承重。

---

所以我决定停下来。

停止写理论。停止给「它为什么不行」找新的理由——我已经找到五个了,而每一个的终点,都是同一面没被压过的墙。

再聪明的论证也撑不开那把剪刀。只有一个东西能:把那面墙的另一半盖上,然后压一次。

这件事,一个星期就能见分晓。我把那些「AI 填错、人改对」的配对喂回去,看同一个客户、同一个海外代理的账单,人工修正率是平的,还是往下走的。

如果是平的——那我认。这就是一门被剪刀封了顶的服务生意,能让几个人赚到第一桶金,但不是我想要的那个东西。早点认,比晚点认值钱。

如果它往下走——那把剪刀,就被撑开了。被忽略的大陆,重新成立。

---

我写《MVP as Research》的时候说过:先把食物丢在地上,看有没有人吃;有人吃,再给他安排一个盘子。

货代,就是我丢在地上的那块食物。有人啃了一口。研究结论现在回来了——不是没人饿,是这块地上,有一把剪刀。

我不会再用嘴把自己 argue 上那片大陆。我要走过去,把那面墙压一次,看它到底承不承重。

That's it。


---

# Deep Notes from Using Databricks AI Products / Databricks AI 产品深度体验心得

> Published 2026-06-14 · By lawted · Canonical: https://ha7ch.com/writing/databricks-ai-product-experience

## English

There are not many Databricks product write-ups on the Chinese internet. Since my company's databases and data-processing workloads are being migrated onto Databricks, I have had a fairly deep experience with Databricks' current AI product line. I have some thoughts, and I need to get them out.

---

Genie Space

Genie Space is a data agent that lets users interact in natural language, use SQL to retrieve data from databases, and generate simple visualizations. The concept itself looks good and is genuinely attractive, but the accuracy and stability of AI-driven data retrieval are still worrying, especially when the request is complex or spans multiple databases.

Genie Space provides customization features for instructions and patterns. But this is essentially building patterns on top of a technical black box. The opaque underlying instructions can conflict with the custom instructions you build on top, turning a setting that should strengthen the system into a source of friction.

For example, if you ask for sales from the past month, the phrase can mean many things: last calendar month, the past 30 days, or month-to-date. Even if the custom instructions define past month as last calendar month, the model may still randomly choose another definition if that conflicts with the hidden base instructions.

Of course, this kind of issue can be found and adjusted through testing. But because you never fully control the instructions, later testing and tuning become very difficult. When multiple ambiguous conditions are combined with cross-table queries, it becomes an engineering disaster.

This leads to two other problems.

First, Databricks' Git support is very limited. Much of it can only be operated through the Web UI, and Genie Space customization does not even support Git sync. Users can only use scripts to save the entire customization as JSON, sync that through Git, and then manually load and overwrite it. This is a disaster for team collaboration. CI/CD is basically nonexistent.

Second, Genie Space does not let you choose the base model or modify the interaction style. When the natural-language instruction is ambiguous, the simplest thing to do is ask the user to clarify. At the very least, it should point out the ambiguity. But because the underlying black box is constrained, this is hard to achieve.

---

Genie Code

Another Databricks AI product is Genie Code, an AI coding agent focused on data governance. You cannot choose the model, and you cannot see the context window. It feels like driving on a highway without a speedometer and without knowing how much horsepower the pedal gives you.

Here is one case from my own experience. Genie Code spent five minutes, through multiple rounds of edits and tests, before finally solving a very simple error: a ! pip install XXX cell had been set in a SQL environment instead of a Python environment.

To put it more seriously, Genie Code barely reaches the passing line in complex engineering environments. At one Databricks event I attended, I saw Databricks staff use Claude Code to build an MVP and run it on their own platform. To me, that detail highlighted the gap between Genie Code and mature AI coding tools.

There is no doubt that Genie Code is useful for building some MVPs, and its access to Databricks' internal knowledge base is very smooth. But given its stated target of becoming a coding agent for data governance and data analysis, its basic capabilities are still weaker than the best AI tools today, such as Claude Code and Codex. That is before we even talk about harness engineering and tool use in complex situations.

---

Outlook

For people who have not been exposed to AI-native workflows, Databricks' Genie Space and Genie Code are very attractive. But in genuinely deep AI-native workflows, they still feel a bit toy-like.

If Oracle plus Codex or Claude Code can fully replace Databricks' current AI products, and even work better, then where exactly is Databricks' moat in AI?

My personal view is that Databricks should heavily strengthen Genie Code until it reaches the level of GitHub Copilot, combine it with Databricks' database platform, and make it an AI tool that amplifies super individuals. That would narrow the gap with today's T0-class AI tools. It should keep Genie Code's cloud-side advantage while giving users some freedom to modify the tool itself.

At the platform level, Databricks could design a communication and coordination architecture specifically for Genie Code instances inside organizations. It could use its cloud advantage to manage and sync session history, sync project-progress information, and redesign a super-team architecture for AI-agent coordination. Reducing the friction of communication and coordination may become the real highlight of the tool.

## 中文

在中文互联网上少见 Databricks 的产品体验，恰逢公司数据库、数据处理计算正在迁移到 Databricks 上，也算是深度体验了一下 Databricks 当前的 AI 产品线，有一些自己的感想，不吐不快。

---

Genie Space

Genie Space 是一个通过自然语言交互、使用 SQL 从数据库获取对应数据，并做简单可视化展示的 Data Agent。这个概念本身看起来很好，很吸引人，但是 AI 获取数据的准确性和稳定性堪忧。尤其是在复杂要求和多数据库联合时有待加强。

Genie Space 提供客制化修改指令和范式的功能。这是在一个底层的技术黑盒上搭建范式，不透明的底层指令和构建的客制化指令相冲突，让本应该加强能力的设置反而成为了阻碍。

例如：当询问「过去一个月的销售额」，语义可以有很多种解释，是上个月，还是过去 30 天，抑或是月初到今天。尽管在客制化的指令中定义了「过去一个月」是指上个月，但是如果和底层黑盒中的设置指令相冲突，模型会随机根据一种定义选择回答。

当然这种情况可以通过测试发现并调整。但是对于指令的不完全掌控使得后续的测试和调整十分困难。尤其是当多个有歧义的条件结合在一起再加上跨表格查询，这在工程学上简直是灾难。

这也引出了其他两个问题。

一，Databricks 对于 Git 的支持很有限，只能通过 Web UI 交互，Genie Space 的客制化甚至不支持 Git 同步。用户只能通过 script 将整个客制化保存成 JSON，再通过 Git 同步，再手动加载覆盖。这简直是团队协作的灾难，CI/CD 基本没有。

二，Genie Space 无法选择基座模型，也无法修改交互方式。当自然语言输入的指令存在歧义的时候，最简单的是反问用户明晰需求，最不济也要指出问题。然而这些都因为底层黑盒被限制了，很难做到。

---

Genie Code

Databricks AI 的另一个产品是 Genie Code，这是一个专注于数据治理的 AI Coding Agent。你无法选择模型，看不到上下文窗口。这就像在高速上没有时速表，也不知道油门对应车子的马力。

举一个我本人的案例：Genie Code 花了 5 分钟，经过多轮修改和测试，最终才解决了一个十分简单的 error：! pip install XXX 的 cell 被设置在了 SQL 环境而非 Python 环境中。

严肃一点来说，Genie Code 在复杂工程环境中艰难达到及格线。在我参加的一场 Databricks 活动上，我看到 Databricks 工作人员使用 Claude Code 搭建 MVP，并让它运行在自家平台上。这个细节在我看来，反而凸显了 Genie Code 和成熟 AI coding 工具之间的差距。

毋庸置疑 Genie Code 在做一些 MVP 时十分有用，对于 Databricks 内部的知识库调用也十分顺畅。但是其设定的目标是数据治理和数据分析场景里的 coding agent，从基础功能上就比 Claude Code、Codex 这类目前最好用的 AI 工具要弱，更不用说复杂情况下的 harness engineering 以及工具调用了。

---

展望

Databricks 的 Genie Space、Genie Code，对于没有接触 AI 原生的人来说十分有吸引力。但是用在真正深度 AI 原生的工作流中有点玩具性质。

如果 Oracle + Codex/Claude Code 可以完全替代 Databricks 当前的 AI 产品，甚至更好用，那 Databricks 这个平台在 AI 方向的护城河到底在哪里？

以我个人的愚见，大力加强 Genie Code，使其达到和 GitHub Copilot 同样的水准，结合 Databricks 的数据库，成为一款为超级个体提供放大能力的 AI 工具，缩小和现阶段 T0 级别 AI 工具的差距。保持 Genie Code 的云端优势，同时给用户一定的自由度来修改工具本身。

在平台上，为组织专门设计 Genie Code 和 Genie Code 之间的通信协调架构。发挥云端优势，对于 session 历史进行管理和同步，以及项目进度信息的同步，重新设计一个 AI agent 协调协作同步的超级团队架构，减少沟通协调的阻力。这可能成为工具的亮点。


---

# My Best Resume Material Was Hidden in 700 Conversations, But I Was Too Lazy to Dig / 700 条对话记录里藏着我最好的简历素材，但我懒得翻

> Published 2026-05-22 · By lawted · Canonical: https://ha7ch.com/writing/resume-material-from-700-conversations

## English

Here is what happened.

I was preparing an internship resume for an AI Coding product manager role. My daily development depends almost entirely on AI. I switch between Claude Code and Codex, and in three months I burned through 3.95 billion tokens. If these experiences went into my resume, they would be very solid material.

The problem was that all this material was scattered across hundreds of chat windows.

700 sessions, 96 projects. What I said to AI in each project, how I collaborated with it, what traps I stepped into, all buried inside jsonl files and git commits. Go through them one by one? Just thinking about it made me want to die.

So I did the most natural thing: I let AI go dig through it itself.

I sent out 7 subagents at the same time. One scanned my token usage data. One went through Codex conversations to find how I built my electronic diary. One reconstructed the real bug-fixing timeline from git log. One read my global config files to understand why I chose one model over another. Every agent had a clear search scope and a clear task target.

A few minutes later, 19 research reports came back.

Let me give you a few examples so you can feel what I mean by "accurate."

Report R10 told me that Codex accounted for 60% of my total token consumption, while Claude Opus 4.6 accounted for 78% of my total conversations. The former handled code, the latter handled writing. I knew I had this habit, but I had never quantified it. The agent went straight into data.json, broke it down by model, and calculated it.

Report R4 reconstructed a bug story. My cross-device file transfer tool Folip had a problem where uploads succeeded but Android could not download the file. AI kept circling around the client code and could not find the cause. At the time, I did one thing: I asked AI to read the Alibaba Cloud OSS access logs itself. It found the issue instantly. The pre-signed URL had missed Content-Type in the calculation. The agent reconstructed that entire timeline clearly from git commits.

Report R8 dug up a detail from my electronic diary project. When Codex helped me proofread handwritten diary entries, it would "take initiative" and polish them, expanding "但她很 normal" into "但是她也很 normal." Because of that, I wrote 7 "do not" rules and folded them into the prompt. The agent found the exact jsonl file path and timestamp.

If I had gone through all this myself, it might have taken a whole day, and I probably would have remembered the details wrong. Letting AI dig through its own memory was both fast and accurate.

But that was not the most interesting part.

The most interesting part was the correction process between me and AI. In the drafts the agents brought back, several places were reversed or overstated. For example, one agent got my logic for using Codex and Claude backwards, and I immediately corrected it. Another wrote about a technical detail called "15% context optimization," and I said, "I don't really understand this myself," then deleted it directly. Another described my bug discovery process as "manually checking logs," and I said no, that was wrong. I had asked AI to read the logs.

Every round of correction moved the resume closer to reality. In the final version, every number, every story, and every judgment was something I had actually done, actually thought through, and could actually explain clearly in an interview.

Honestly, I think this is what an AI-native resume-writing process should look like. It is not asking AI to invent a polished resume for you. It is asking AI to dig the best material out of your own real data, then having you judge what is truly you and what is not.

AI has a better memory than you do, but only you know which memories are yours.

## 中文

事情是这样的。

我在准备一份实习简历，方向是 AI Coding 产品经理。我日常开发全靠 AI，Claude Code 和 Codex 两个工具换着用，三个月烧了 39.5 亿 tokens。这些经历如果写进简历，是非常硬的素材。

问题来了，这些素材散落在几百个对话框里。

700 个 sessions，96 个项目，每个项目里我跟 AI 说了什么、怎么协作的、踩了什么坑，全部埋在 jsonl 文件和 git commit 里面。一个个翻？我光想想就觉得要死。

然后我做了一件很自然的事，让 AI 自己去翻。

我同时派了 7 个子代理出去。一个去扫我的 token 用量数据，一个去翻 Codex 的对话记录找我怎么开发电子日记的，一个去 git log 里还原我修 bug 的真实时间线，一个去读我的全局配置文件看我为什么选这个模型不选那个。每个代理都有明确的搜索范围和任务目标。

几分钟后，19 份调研报告回来了。

我举几个例子你们感受一下这个「准确」是什么意思。

R10 报告告诉我，我的 Codex 用量占 token 总消耗的 60%，Claude Opus 4.6 占总对话的 78%。前者跑代码，后者跑文字。我自己是知道这个习惯的，但我从来没量化过。代理直接去 data.json 里按模型拆分算出来的。

R4 报告还原了一个 bug 故事。我的跨设备文件传输工具 Folip 出了个「上传成功但 Android 下载不到」的问题，AI 在客户端代码里反复打转找不到原因。我当时做了一件事，让 AI 自己去读阿里云 OSS 的访问日志。秒定位，预签名 URL 漏算了 Content-Type。代理从 git commit 里把这整条时间线还原得清清楚楚。

R8 报告挖出了我做电子日记项目时的一个细节，Codex 帮我校对手写日记的时候会「自作主张」润色，把「但她很 normal」扩写成「但是她也很 normal」。我因此写了 7 条「不要」规则，沉淀进 prompt 里。代理找到了对应的 jsonl 文件路径和时间戳。

这些东西我自己去翻可能要一整天，而且大概率会记错细节。AI 去翻自己的记忆，又快又准。

但这不是最有意思的部分。

最有意思的是我跟 AI 之间的纠错过程。代理跑回来的初稿里有好几个地方写反了或者写过了。比如有个代理把我用 Codex 和 Claude 的逻辑写反了，我立刻纠正。有个代理写了一个「15% context 优化」的技术细节，我说「我自己都不太懂这个」，直接删掉。还有一个把我发现 bug 的过程写成了「手动查看日志」，我说不对，是我让 AI 去读的。

每一轮纠正都让简历离真实更近一步。最后定稿的简历里，每一个数字、每一个故事、每一个判断都是我真的做过、真的想过、真的能在面试里讲清楚的。

说真的，我觉得这才是 AI native 写简历应该有的样子。不是让 AI 帮你编一份华丽的简历，是让 AI 帮你从自己的真实数据里把最好的素材挖出来，然后你来把关哪些是真的你、哪些不是。

AI 的记忆比你好，但只有你知道哪些记忆是你的。


---

# Why You Should Come to Hatch / 你为什么该来 HA7CH

> Published 2026-05-21 · By lawted · Canonical: https://ha7ch.com/writing/why-you-should-come-to-hatch

## English

Let's just assume you are an AI-native person. Let me ask you a question.

What's the coolest thing you have ever built?

Maybe it's a final project for some stupid course. Maybe it's a project at a hackathon. Or maybe one weekend you used Claude Code to throw together a small demo, took a screenshot, sent it to LinkedIn, and a lot of people liked it.

And then what?

A lot of things just stop there.

So in the summer or winter, you still go look for an internship. Maybe 40 RMB an hour, doing some dog shit job. You know it's not what you want. You just don't know where else you can go.

---

So let me tell you something.

There are people out there willing to pay for your ability, and pay you a lot of money. But they are not in the world you are familiar with.

They are the bosses you would never get a chance to touch if you stay in school. They run a traditional company, maybe 30 people. ARR maybe a million.

Their daily job is this: people are using Excel, PDF, WeChat, some internal system, just copy and paste. They know something is wrong. They want to use AI. But they don't know how to prompt, they don't know how to find these AI-native people, and they don't trust that the consulting or the IT company will give them what they actually want.

But you. You can use Claude Code, you know how to build a frontend, you know some shit about backend, and you can build a small system in a week.

I gotta say, these two worlds have no intersection.

So what HA7CH wants to do is send you there.

It's quite hard for you to find this boss. Getting them to trust you is much harder. But this path, you don't need to walk through by yourself. We're going to lead you there. You just need to deliver and ship. That's the most familiar thing for you, right?

---

Okay, now let's talk more specifically.

A summer. You go to a company like this. Not remote. Literally on site. You follow their employees for a couple of days, maybe a couple of weeks, and see how they do their job. How they match a ticket. How they follow a customer. How they put the same number in four different places.

Then you go back. Or you just sit on the ground, on the floor, and give them something they can try in maybe two days. Iterate within a couple of hours.

And in the end, the boss pays you by how many people I cut. Not by what tech stack you are using.

This ticket, this shit, is much higher than finding an internship at Amazon.

---

What's more, you get another thing.

You get to know what the real customer is thinking. You get to know the cool feature they're not going to use. You get to know what they are willing to pay for. You get to know after you build it, whether people use it or not.

There is not a single thing about this you can learn from class.

And if this process is shared across the industry, then it's not just a single business. You use this case to knock the second door, to knock the third door. Maybe it's the start point of a SaaS. Maybe it's the entry point for your startup journey.

---

One more thing.

We did FDE before, and we know what it looks like. So we have a Hatch House. A place where people live, eat, code, talk shit, and drink together.

Even if you did nothing in those two months, you got to know a bunch of people just like you. Which is pretty insane. Pretty interesting, to be frank.

---

HA7CH is not a school. We don't teach you how to prompt. We don't need to teach you how to fine-tune. That's easy for you, right?

And we are not an outsourcing company. We are not going to pay you by function, by feature, by PRD.

HA7CH is just a path.

A summer. You go from your course homework into a real industry, finish a real delivery, get a real fucking check.

Adding one more line on your resume is so different from running a real business of your own. Those are two different things. You choose it yourself.

---

If you think you are this kind of person, just come to ha7ch.com.

Our first batch is running right now.

See you soon.

## 中文

我们就假设你是一个 AI native 的人。我问你一个问题。

你做过的最酷的东西，是什么？

可能是某门傻逼课的期末大作业。可能是某次 hackathon 上的一个项目。或者就是某个周末，你用 Claude Code 拼了一个小 demo 出来，截图发了朋友圈，一堆人点赞。

然后呢？

很多事情就停在那儿了。

寒暑假到了，你还是去找一份实习。一个小时 40 块钱，干一些 dog shit 的活儿。你心里清楚这不是你想要的。但你不知道还能去哪儿。

---

我跟你说件事。

外面真的有人，愿意为你已经会的能力付钱，付一笔你想象不到的钱。

但他们不在你熟悉的那个世界里。

他们是一群你只要待在学校，就基本不可能接触到的老板。开着一家三十来人的传统公司。一年营收几千万。

他们每天的工作是：员工在 Excel、PDF、微信、几个内部系统之间复制粘贴。他们知道这件事不对劲。他们也想用 AI。但他们不会 prompt，他们不知道去哪儿找你们这种 AI native 的人，他们也不相信外包公司、软件公司能给他们做出他们真正想要的东西。

但你不一样。你会 Claude Code，你能写前端，后端也懂个大概，你一个人一周能跑出一个能用的小系统。

我得说，这两个世界基本没有交集。

HA7CH 要做的，就是把你送过去。

你自己去找这种老板很难。让他们信你，更难。这段路你不用自己走，我们带你过去。你只管交付，只管 ship。这本来就是你最熟悉的事，对吧？

---

OK，再具体说说。

一个暑假。你进到一家这样的公司。不是远程，是真的进现场。你跟着他们的员工看几天，或者一两个礼拜，看他们到底怎么干活。怎么对一张单。怎么跟一个客户。怎么把同一个数字在四个地方填四遍。

你就直接蹲在他们公司里，两天就给他们一个能跑的东西，再过几个小时就迭代一版。

最后，老板按「我省了几个人」付你钱。不是按「你用了什么 tech stack」付你钱。

这一单，比你去大厂找一份实习，钱多得多。

---

你拿到的还不止是钱。

你会知道真实客户脑子里到底在想什么。你会知道你自以为很酷的那个功能，他根本不用。你会知道他真正愿意为什么东西掏钱。你会知道东西交付以后，到底有没有人在用。

这些没有一件，是你能在课上学到的。

而且如果你做的这个流程，恰好是行业里很多公司都有的，那它就不只是一单生意。你拿着第一家的案例去敲第二家、第三家的门。这可能就是一个 SaaS 的起点。可能就是你创业的起点。

---

还有一件事。

我们自己做过 FDE，知道前期手头紧是什么感觉。所以我们办了一个 Hatch House。一个让大家住到一起、一起吃饭、一起写代码、一起扯淡、一起喝酒的地方。

就算这两个月你最后什么都没做成，你也认识了一群跟你一样的人。这件事本身就够爽了。说真的，挺有意思。

---

HA7CH 不是学校。我们不教你怎么 prompt，也不用教你怎么 fine-tune。这些对你来说太简单了，对吧？

HA7CH 也不是外包公司。我们不会让你照着 PRD 一条一条按功能报价。

HA7CH 就是一条路。

一个暑假。从课程作业的世界里走出来，走进一个真实的行业，完成一次真实的交付，拿到一笔 real fucking money。

简历上多一行，跟你自己第一次做成一单生意，是完全两件事。你自己选。

---

如果你觉得你就是这种人，来 ha7ch.com。

我们第一批已经在跑了。

下次再见。


---

# Three Hundred Strangers / 三百个陌生人

> Published 2026-05-20 · By lawted · Canonical: https://ha7ch.com/writing/three-hundred-strangers

## English

I was at a supermarket when Lawted texted me: 'bro check out this groupchat on 小红书.'

He'd released a prototype of Raily a few hours earlier. By the time I opened the link, three hundred people were already in the chat. Feature requests. Bug reports. Screenshots. Someone asking when the Android version was coming.

Nobody in that chat was introduced by anyone's dad. Nobody owed anyone a favor. None of them would have been in the same room a decade ago. The entry fee was that the thing existed and was worth being around.

The fact that the room exists means the end of an era most people haven't noticed is ending.

---

For a hundred years, 人脉 was the operating system. Your dad knew someone's dad. The dinner was the interview. The red envelope was the contract. You couldn't verify a stranger from outside their network, so the network was the verification. Information was scarce. Capital was scarce. Trust was scarce. All three flowed through the same pipes, and those pipes had names on them.

This system built fortunes. It built industries. It built most of the wealth your parents are proud of.

It's over.

Information isn't scarce anymore. You can verify a stranger in thirty seconds. The work is the signal now, and the signal is public. A twenty-two-year-old shipping from a dorm room is more legible to the people who matter than someone's nephew with a polished résumé and a recommendation letter from a vice president.

Capital isn't scarce anymore. Raily cost Lawted a few sleepless nights. That's the whole budget. When building was expensive you needed money, and money moved through networks, which is why the networks mattered. The son of a billionaire used to have a moat ten miles wide. Today he has nothing a hungry working-class kid with a laptop can't match by Friday.

And the rooms that matter have new bouncers. The bouncer isn't a person anymore. The bouncer is a filter: can you ship, can you see, are you worth three hours of someone's evening. You can't bribe that filter. You can't get your dad to call it. The work is the only password, and there are no backdoors.

Every advantage the old system sold you — access, introductions, the family name, the right school, the right firm — is collapsing in real time. Most of the people holding those advantages haven't realized they're holding nothing but a piece of paper.

---

The cliché says you're the average of the five people you surround yourself with. So everyone optimizes for access. How do I get into the room. How do I meet the right people. How do I get the introduction.

That's the loser's game now.

---

The old system isn't fully dead. There are industries and cities where 关系 still runs everything and will for another generation. Fine. Let the people who inherited that game keep playing it. It's a shrinking board.

Every year more verification moves online. Every year more building gets cheaper. Every year more rooms form around the work instead of around the bloodline. The direction is one-way and the slope is steepening.

If you're betting on this, you're betting early. Early is the only time the bet pays.

Stop trying to climb into rooms.

Build something loud enough that the room comes to you.

## 中文

我在超市的时候，Lawted 给我发消息：'哥你看看这个小红书的群聊。'

他几个小时前刚放出了 Raily 的原型。等我点开链接的时候，群里已经三百人了。功能建议。Bug 反馈。截图。有人在问安卓版什么时候出。

这群里没有一个人是被谁的爸爸介绍进来的。没有谁欠谁人情。十年前他们根本不可能聚在同一个房间。入场费就是——这个东西存在，而且值得围观。

这个房间能存在本身，就意味着一个时代的终结。大多数人还没意识到它正在终结。

---

一百年来，人脉一直是这套系统的底层操作系统。你爸认识谁的爸。饭局就是面试。红包就是合同。你没办法从网络外部去验证一个陌生人，所以网络本身就是验证。信息稀缺。资本稀缺。信任稀缺。这三样东西都通过同一套管道流动，而那些管道上都写着名字。

这套系统造就了财富。造就了行业。造就了你父母引以为傲的大部分家底。

它结束了。

信息不再稀缺。验证一个陌生人只要三十秒。作品就是信号，而且这个信号是公开的。一个在宿舍里发版本的二十二岁年轻人，在真正重要的人眼里，比某某副总裁推荐信里那个简历光鲜的侄子要清晰得多。

资本不再稀缺。Raily 的全部成本就是 Lawted 几个失眠的晚上。仅此而已。建造昂贵的时代，你需要钱；钱在网络里流动，所以网络才那么重要。亿万富翁的儿子曾经有十英里宽的护城河。今天，一个饥渴的、有台笔记本电脑的工薪阶层小孩，周五之前就能追平。

而真正重要的房间，有了新的门卫。门卫不再是人了。门卫是一个过滤器：你能不能交付，你能不能看见，你值不值得别人花三个小时的晚上。你贿赂不了这个过滤器。你爸打电话也没用。作品是唯一的密码，而且没有后门。

旧系统卖给你的所有优势——人脉、引荐、家族名号、对的学校、对的公司——都在实时崩塌。大多数还握着这些优势的人，还没意识到他们手里握的只是一张废纸。

---

那句老话说，你是你身边五个人的平均值。所以大家都在优化'进入'——怎么进那个房间。怎么认识对的人。怎么搞到那个引荐。

这是输家的游戏了。

---

旧系统没有完全死。有些行业、有些城市，关系还在主导一切，而且还会再主导一代人的时间。行。让那些继承了那套游戏的人继续玩吧。棋盘在缩小。

每一年，更多的验证搬到线上。每一年，建造的成本继续下降。每一年，更多的房间是围绕作品形成的，而不是围绕血统。方向是单向的，坡度还在变陡。

如果你押注在这个转向上，你是在早期下注。早期是唯一押对的时机。

别再想着挤进哪个房间了。

做点声音够大的东西，让房间自己来找你。


---

# The Ignored Continent / 被忽略的大陆

> Published 2026-05-20 · By lawted · Canonical: https://ha7ch.com/writing/the-ignored-continent

## English

Here is what happened.

A while ago, my friend Lawted met a boss who runs a traditional manufacturing and transportation business. After they talked through the business, Lawted casually helped him install DouBao on his phone.

The boss opened it and tried a few things. Face reading, fortune telling, chatting.

Then he said one sentence: “Holy shit, this is fucking insane.”

This boss runs a company with annual revenue in the tens of millions and dozens of people under him. But he had never used any AI product before. He did not know what ChatGPT was, did not know what Claude was, did not know what a prompt was. His entire business runs on WeChat groups, Excel handoffs, and people brute-forcing the workflow.

What did he use DouBao for?

Face reading and fortune telling.

And it was not the kind of thing where he tried it once and put it down. He was using it every day. Completely hooked. Almost possessed. It was honestly wild.

When I heard this story, I sat there stunned for a while.

Not because I thought it was funny. Because I suddenly realized something: those of us soaking in the AI world every day and the bosses actually running businesses on human labor live in two completely different worlds.

We are discussing Harness Engineering, multi-agent orchestration, whether Codex or Claude Code is stronger. Codex ships on mobile and some people think it is convenient while others complain it is slow. Our feeds are full of this stuff every day.

But outside our field of vision, there is an entire continent we cannot see.

On that continent, a boss making tens of millions a year sees AI for the first time through a face-reading app and is stunned speechless.

Just picture that scene.

This is not a joke. It is a signal. A huge signal that almost everyone has ignored.

---

Honestly, I used to think the market for AI was inside internet companies, inside big tech, inside teams that already understand technology. I thought AI deployment meant making better tools, stronger agents, and smoother workflows for people who already knew how to use AI.

But ever since we started doing HA7CH and actually began touching traditional industries, my view has been completely changed.

The largest market is not there at all.

The largest market is on every industrial belt in China that you cannot see.

Take the shipping-doc logistics business that boss is in. In Shenzhen alone, there are more than 8,000 companies doing this line of work.

More than 8,000.

And across these companies, the workflows are almost the same. Orders come in through WeChat, documents are made in Excel, PDFs get passed around, people manually check, manually enter, manually chase payments, manually track progress. A company may have twenty or thirty people whose daily work is basically moving something from one system to another, from one spreadsheet to another, from a sentence in a WeChat group into a cell in Excel.

What the boss says is one thing. What the employees do is another. What is written in the system is one thing. How it actually works is another. Many of the key rules are not in any document. They live inside the head of one old employee who has been there for more than a decade. A lot of the information is not structured data. It is a voice message in a WeChat group, a tiny line in a PDF, an abbreviation in the notes column of an Excel sheet.

And this is just one industry in one city.

Multiply that number across the whole country and across every traditional industry: logistics, education, manufacturing, trade, freight forwarding, building materials, restaurant supply chains. You get a number that makes your scalp go numb.

Most of these bosses do not use Jike, do not follow AI news, do not know the difference between ChatGPT and DouBao. The only thing they know is: I spend a huge amount on labor every month, it gives me a headache, I want to cut costs and boost efficiency, but I do not know who to call.

This is the real PMF for AI.

Not helping people who already know how to use AI use it better. Helping people who have never seen AI see it for the first time and feel their heads explode.

---

Some people may wonder: if the market is this large, why are the big companies not doing it? Why has nobody eaten it?

To be blunt, it is not that they do not want to. It is that they cannot.

When big companies do FDE, companies like Palantir, OpenAI, and Anthropic have mature platforms behind them: Foundry, Claude Enterprise, entire delivery systems. They face Fortune 500 companies and clients with budgets in the millions or tens of millions. They cannot send a dedicated team to deeply customize software for a logistics company with thirty or forty people, a local education business, or a small traditional factory.

Domestic companies like MiniMax and Zhipu follow a similar logic. Enterprise customers do not want “I chat with AI for a bit.” Enterprises want models that can enter the intranet, connect to existing systems, and handle concrete business scenarios. Delivery costs are high, so the FDE teams at model companies can only prioritize large clients.

VCs do not fund this kind of business either. It is too scattered, too dirty, too non-standardized. It does not tell a clean exponential-growth story.

But the problem is, the opportunity is exactly hidden in these places.

The more local, messy, and labor-heavy something is, the more room there is for AI to transform it.

Traditional outsourcing companies do not do this well either. Communication costs are high, delivery cycles are long, pricing is not cheap, and the final product often does not work well. Outsourcing also charges by feature: you tell me what you want, I build it. But these traditional companies do not have the problem “I need a feature.” Their problem is “my entire workflow is chaotic, and I cannot even explain what I need.”

This is the gap. Big companies cannot enter, outsourcing cannot do it well, and the boss cannot figure it out alone.

And what HA7CH wants to do is get inside this gap.

---

Back to the DouBao story. That boss was blown away by a face-reading app, but what he actually needs is not fortune telling. What he needs is someone to help him rewrite all those repetitive, labor-stacked workflows with AI.

What he needs is a young person with a MacBook and a $200 Claude Code plan to walk into his company, sit beside his employees, and watch how they actually work every day. Then, over two or three months, turn the most painful workflows into a system that actually runs.

That person is the FDE: Forward Deployed Engineer.

But our kind of FDE is different from big-company FDE.

Behind a big-company FDE is a massive model platform. Behind our kind of FDE there may just be a MacBook, a $200 Claude Code plan, a few APIs, a WeChat group, and one person brave enough to walk into the company on-site.

It sounds very local.

But precisely because it is local, it can enter places the big companies cannot enter.

And why does this work now? Because AI coding tools have amplified the delivery ability of an individual by too much. In the past, a small enterprise system needed a small team working for two or three months. Now, a sufficiently strong builder using Claude Code, Cursor, Codex, and tools like these may be able to ship an MVP in two weeks. In the past, juggling five or six projects at once was basically impossible. Now, if the method is right, it really can be done.

This turns “enterprise solutions” from an organizational capability into a strong-individual capability.

---

This is also why we say HA7CH is not an outsourcing company, not a bootcamp, and not a startup community.

HA7CH is an FDE accelerator.

We send AI-native builders into traditional companies on-site. During the day, they interview operations people and watch how they work, how they fill forms, how they reconcile orders, how they copy and paste, how they move back and forth between WeChat and Excel. At night, they go back and code what they saw into a system. The next day, they bring it back on-site and let the employees try it.

If it is wrong, they change it. If it is right, they keep pushing forward.

The boss pays based on “how many people did this save,” not based on “what technology did you use.”

This logic is very simple and very real. If a company has 10 operators, each making 8,000 RMB a month, that is nearly 1 million RMB in labor cost a year. If your system can turn the work of 10 people into something 3 to 5 people can handle, charging 10% to 20% of the saved cost, 100,000 or 200,000 RMB is not exaggerated at all.

And the more important point is: this system is not something you can only sell to one company. In the same industry, workflows are largely similar. After you finish the first company, you take the case study to its peers. You do not need to preach the future of AI again. You just say, this company is already using it. This workflow used to take this many people, now it saves this many people. They used to process this many orders per day, now they can process this many.

The first company is the show apartment. The ones after that can become a repeatable industry product.

If the first boss is smart enough, he may even become your angel investor. Because he understands very clearly that if this system works, there is no way you will only sell it to him. You will definitely sell it to his competitors. So he will think: can I get a seat first?

That is the part of FDE that is genuinely sexy.

At the beginning, it may look like you are working for free, like you are doing outsourcing. But if you pick the right industry, the right first customer, and the right repeatable workflow, what comes after is not outsourcing at all. It becomes SaaS. It may even become an industry-level AI system.

---

At this point, some people may ask: what kind of people are you actually looking for?

I will say it directly. Two traits. You need both.

Ability and time.

First, ability. You need to be able to build. You do not have to be the strongest engineer, but you must be able to make something from zero. You know how to use Claude Code, Cursor, Codex, and tools like these; how to quickly set up a system; how to connect APIs; how to build a page; how to deploy. If you are already using vibe coding to make small projects in daily life, you probably already have the basic ability.

Then, time. This is extremely important. FDE is not remote coding work. You have to actually go on-site, to the company, the office, maybe even the warehouse, and stand beside front-line employees watching how they work. You need to be able to talk to the boss and also to the operations people. You need to understand the very local industry language they use. This takes at least several continuous weeks, and sometimes two or three months.

So I genuinely think college students are a very suitable group.

Not only college students. If you are a freelancer, a developer who has left a job, or someone on a gap year, as long as you meet the two conditions above, you can do it. But college students have several natural advantages that are hard for other groups to match.

They have time. A winter or summer break of two or three months is just enough to go on-site and complete one project.

They have momentum. They have not yet been trained by big-company process. They are willing to try, willing to run, willing to throw themselves into an unfamiliar industry.

And most importantly, this generation of students already naturally knows how to use AI tools. They know how to use Claude Code, how to use Cursor, how to open issues, how to send PRs, how to quickly fork something and modify it.

Think about it: a sophomore spends two months in the summer helping a logistics company build a system. That system later sells to the second and third companies in the same industry. Every month, he can still receive some revenue share from it. That money might cover living expenses, buy equipment, fund the next project.

That feeling is completely different from having a job. It lets you feel, for the first time, that something you built can actually make money in the real world.

Not salary. Cash flow you created yourself.

This experience cannot be taught by school, and big-company internships may not teach it either. Taking ten classes in school is not as good as actually going on-site to a company, watching how a boss makes money, how an operations person works, how a system goes from zero to one and starts running. You learn product, engineering, sales, delivery, business, industry, and human nature all at once.

This is the best kind of learning.

---

Of course, I do not want to make this sound too beautiful. To be blunt, doing FDE is hard.

You do not have a proper desk. You do not have a proper work environment. Everyone in the office may be smoking. The boss may pour tea for you, or he may ask you to drink with him. Your first project will probably only be paid after delivery, maybe with not even one yuan of deposit. You may put your own time into it, go on-site every day, and write code until midnight.

And what you face is not standardized requirements. Real business is not written in a PRD. The boss will not write user stories for you. Employees will not tell you the full workflow either. You have to watch, ask, break it down, and judge by yourself. You will run into a mess of fields, historical baggage, and endless cases of “this customer is special.”

This is not something everyone can do.

But if you can do it, and you dare to do it, the return is also very real.

Because in traditional industries, you suddenly become a very scarce person. When you tell them AI can help reconcile orders, organize spreadsheets, automatically generate files, analyze customer data, and take over the daily copy-paste work, they will really think: holy shit, this person has something.

Inside a big company, you may just be an ordinary engineer. At Stanford, you may just be an ordinary research assistant. But when you arrive in a traditional industry that truly lacks AI, automation, and technical understanding, you suddenly become a key person.

Technology has completely different value depending on where you put it.

---

I am not sure where HA7CH will ultimately go. Maybe a few months from now we find out some assumptions were wrong. Maybe Hatch House is a false premise. Maybe the business model needs a major adjustment. All of that is possible.

But there is one thing we are certain about.

That ignored continent is real.

Those bosses who have never seen AI truly need someone to walk in.

Those workflows stacked on human labor are truly waiting to be rewritten.

And every company can only be AI-ified once. Whoever gets in first owns that workflow. Distilling it later becomes extremely difficult.

This window will not stay open forever. Big companies will enter within 12 months, but they will start with large clients. The market of small and mid-sized “local bosses” may still have a 12-month window.

So, back to the opening story.

A boss making tens of millions a year uses DouBao for face reading and fortune telling, and thinks it is incredible.

He does not know what else AI can help him do. He does not know that half of the labor cost he spends every day can be taken over by a system. He does not know that his company is waiting to be distilled.

But we know.

And what we need to do is find those young builders who have ability, have time, and dare to walk into the field, then send them to the side of these bosses.

Let them become the first person to walk into these companies.

HA7CH, BUILD IN THE FIELD. HATCH INTO IMPACT.

If you feel like you are this kind of person, or you want to learn more, come to ha7ch.com. Our first batch is already running.

See you next time.

## 中文

事情是这样的。

我的朋友 Lawted 前段时间见了一个做传统制造运输的老板。聊完业务以后，他随手帮老板在手机上装了一个豆包。

老板打开，试了试。看脸，算命，聊天。

然后老板说了一句，「卧槽，这他妈太屌了。」

这个老板，公司年营收过千万，手底下几十号人。但他从来没用过任何 AI 产品。他不知道什么是 ChatGPT，不知道什么是 Claude，不知道什么是 prompt。他的全部业务靠微信群协调、Excel 流转、人力堆砌。

他用豆包干什么呢？

看脸算命。

而且不是试一次就放下了。是每天都在用。完全上瘾了，跟着了魔似的，真的很夸张。

我当时听完这个事儿，愣了好一会儿。

不是觉得好笑。是突然意识到一件事，我们这些天天泡在 AI 圈子里的人，和这些真正在用人力堆业务的老板，真的活在两个完全不同的世界里。

我们在讨论 Harness Engineering，在讨论多 Agent 编排，在讨论 Codex 和 Claude Code 到底谁更能打。Codex 上了移动端有人觉得方便有人嫌它慢。我们每天的信息流里全是这些东西。

但在我们视线之外，有一整片我们根本看不见的大陆。

那片大陆上，一个年入千万的老板，第一次见到 AI，是被一个看脸算命的 APP 震撼到说不出话。

你想想这个画面。

这不是一个段子。这是一个信号。一个巨大的、几乎所有人都忽视了的信号。

---

说真的，我之前一直以为 AI 的市场在互联网公司里，在大厂里，在那些已经很懂技术的团队里。我觉得 AI 落地嘛，就是给已经会用 AI 的人做更好的工具，做更强的 agent，做更丝滑的工作流。

但自从我们开始做 HA7CH，真的去接触传统行业以后，我的想法被彻底改变了。

最大的市场根本不在那里。

最大的市场，在中国每一条你看不见的产业带上。

就拿那个老板做的船单物流来说。光深圳一个城市，做这行的公司就有 8000 多家。

8000 多家。

而且这些公司之间，工作流几乎大同小异。都是微信接单，Excel 做单，PDF 传文件，人工核对，人工录入，人工催款，人工跟踪。一个公司里面可能有二三十个人，每天在做的事情就是从一个系统搬到另一个系统，从一个表格搬到另一个表格，从微信群里的一句话搬到 Excel 里的一个格子。

老板说的是一套，员工做的是另一套。系统里写的是一套，真实操作又是一套。很多关键的规则不在任何文档里，而是在某个干了十几年的老员工脑子里。很多信息不是结构化数据，而是微信群里的一句语音、PDF 里的一行小字、Excel 备注栏里的一个缩写。

这还只是一个行业，一个城市。

你把这个数字乘以全国，乘以所有传统行业。物流、教育、制造、贸易、货代、建材、餐饮供应链。你会得到一个让人头皮发麻的数字。

而这些公司的老板，绝大多数都不刷即刻，不关注 AI 新闻，不知道 ChatGPT 和豆包有什么区别。他们唯一知道的事情是，我每个月在人力上花一大笔钱，我很头疼，我想降本增效，但我不知道该找谁。

这才是 AI 真正的 PMF。

不是让已经会用 AI 的人用得更好。而是让从没见过 AI 的人，第一次见到就炸裂。

---

可能有小伙伴纳闷，这么大的市场，为什么大厂不做？为什么没有人去吃？

坦率的讲，不是不想做，是做不了。

大厂做 FDE，比如 Palantir、OpenAI、Anthropic，背后是成熟的平台产品，是 Foundry、是 Claude 企业版、是整套交付体系。他们面对的是世界 500 强，是动不动几百万几千万预算的大客户。他们不可能为了一个三四十人的物流公司、一个本地教育机构、一个传统小工厂，专门派一个团队去做深度定制。

国内的 MiniMax、智谱也是类似的逻辑。企业客户要的不是「我跟 AI 聊两句」，企业要的是模型能进内网、能接现有系统、能处理具体业务场景。这些事情的交付成本很高，大模型公司的 FDE 只能优先服务大客户。

VC 也不投这种生意。太散了，太脏了，太不标准化了，讲不出什么指数增长的故事。

但问题是，机会恰恰就藏在这种地方。

越土、越乱、越靠人堆，才越有 AI 改造的空间。

传统外包公司也不好做这个事儿。外包沟通成本高、交付周期长、报价也不低，最后做出来还经常不好用。而且外包是按功能收费的，你要什么我做什么。但这些传统企业的问题不是「我要一个功能」，而是「我整个流程都是乱的，我自己都说不清我需要什么」。

这就是那个缝隙。大厂进不来，外包做不好，老板自己搞不定。

而 HA7CH 要做的，就是钻进这个缝隙里。

---

回到那个装豆包的故事。那个老板被一个看脸算命的 APP 震撼到不行，但他真正需要的不是算命。他需要的是有人帮他把那些每天重复的、靠人堆出来的流程，用 AI 重新写一遍。

他需要的是，一个带着 MacBook 和 Claude Code 200 刀套餐的年轻人，走进他的公司，坐在他员工旁边，看他们每天到底怎么干活。然后用两三个月时间，把那些最痛的流程做成一个能跑的系统。

这个人，就是 FDE。Forward Deployed Engineer，前沿部署工程师。

但我们这种 FDE，跟大厂的不一样。

大厂 FDE 背后是一个巨大的模型平台。我们这种 FDE 背后可能就是一个 MacBook、一个 Claude Code 200 刀套餐、几个 API、一个微信群，和一个敢走进企业现场的人。

听起来很土。

但也正因为土，所以它能进入那些大厂进不去的地方。

而且现在为什么这事能成立？因为 AI coding 工具真的把个体的交付能力放大了太多。以前一个企业小系统，需要一个小团队做两三个月。现在一个足够强的 builder，用 Claude Code、Cursor、Codex 这些工具，可能两周就能跑出一个 MVP。以前你要同时 handle 五六个项目基本不可能，现在如果方法对，真的可以做到。

这件事把「企业解决方案」从一个组织能力，变成了一个强个体能力。

---

这也是为什么我们说 HA7CH 不是外包公司，不是培训班，也不是创业社群。

HA7CH 是一个 FDE 加速器。

我们把 AI-native 的 builder 送到传统企业现场。白天去访谈业务员，看他们怎么工作，怎么填表，怎么对单，怎么复制粘贴，怎么在微信和 Excel 之间来回切。晚上回去 coding，把今天看到的东西写成系统。第二天再拿回现场，让业务员试。

不对就改。对了就继续往下推。

老板按「省了多少人」付钱，不按「用了什么技术」付钱。

这个逻辑非常简单，也非常真实。一个公司如果有 10 个运营，每人月薪 8000，一年就是接近 100 万的人力成本。如果你的系统能帮他把 10 个人的活变成 3 到 5 个人就能做，收他节省成本的 10% 到 20%，收个 10 万、20 万，一点都不夸张。

而且更关键的一点是，这个系统不是只能卖给一家。同一个行业里，工作流大同小异。做完第一家，你拿着案例去找同行，不用再重新讲什么 AI 未来。你直接说，某某公司已经用了，原来多少人做这个流程，现在省了多少人，原来一天处理多少单，现在一天能处理多少单。

第一家是样板间。后面的，是可以复制的行业产品。

如果第一个老板够聪明，他甚至可能直接变成你的天使投资人。因为他很清楚，你这个系统只要好用，不可能只卖给他一家。你一定会卖给他的同行。那他就会想，我能不能先占一个坑。

这才是 FDE 真正性感的地方。

你一开始看起来像是在免费干活，像是在做外包。但如果你选对行业，选对第一个客户，选对那个可以复制的工作流，它后面就完全不是外包。它会变成一个 SaaS。甚至变成一个行业级的 AI 系统。

---

说到这个，可能有人会问，你们到底想找什么样的人。

我直说了。两个特征，缺一不可。

有能力，有时间。

先说能力。你要会 build。你不一定是最强的工程师，但你一定要能把东西从 0 做出来。你知道怎么用 Claude Code、Cursor、Codex 这些工具，怎么快速搭系统，怎么接 API，怎么做页面，怎么部署。如果你平时就在用 vibe coding 做各种小项目，那你大概率已经具备基础能力了。

再说时间。这一点非常关键。FDE 不是远程写代码的活儿。你要真的去现场，去公司，去办公室，甚至去仓库，站在一线员工旁边看他们怎么干活。你要能跟老板聊，也要能跟业务员聊。你要能听懂他们讲的那些很土的行话。这需要至少连续几周到两三个月的投入。

所以我是真的觉得，大学生是一个非常适合的群体。

不是说只要大学生。如果你是自由职业者、离职程序员、gap year 的人，只要满足上面两个条件，都可以。但大学生有几个天然的优势，是其他群体很难具备的。

有时间。寒暑假两三个月，刚好可以驻场做一单。

有冲劲。还没有被大厂流程驯化，愿意试、愿意跑、愿意把自己扔到一个陌生的行业里。

而且最关键的是，这一代学生已经天然会用 AI 工具了。他们知道怎么用 Claude Code，怎么用 Cursor，怎么提 issue，怎么发 PR，怎么快速 fork 一个东西再改出来。

你想想看，一个大二的学生，暑假两个月，帮一家物流公司做了一套系统。这套系统后来卖给了同行的第二家、第三家公司。他每个月还能从里面拿到一些分成。这些钱可能帮他 cover 生活费，帮他买设备，帮他做下一个项目。

这个感觉和打工是完全不一样的。它会让你第一次感受到，我做出来的东西，真的可以在真实世界里赚钱。

不是工资。是你自己创造出来的现金流。

这种体验，学校教不了，大厂实习也不一定教你。你在学校里学十门课，都不如你真的去一个公司现场，看一个老板怎么赚钱，看一个业务员怎么干活，看一个系统怎么从 0 到 1 跑起来。你会同时学到产品、工程、销售、交付、商业、行业、人性。

这才是最好的学习。

---

当然，我也不想把这件事说得太美好。坦率的讲，做 FDE 很苦。

你没有工位，没有正经的工作环境，办公室里可能所有人都在抽烟。老板可能给你端茶倒水，也可能要你陪酒。你做的第一单大概率是交付以后才给钱，甚至一分钱定金都没有。你可能贴时间进去，可能天天去现场，可能晚上写代码写到 12 点。

而且你面对的不是标准化的需求。真实业务不是 PRD 里写好的。老板不会给你写 user story。员工也不会告诉你完整流程。你要自己看，自己问，自己拆，自己判断。你会遇到一堆乱七八糟的字段，一堆历史包袱，一堆「这个客户比较特殊」的情况。

这不是每个人都能干的事。

但如果你能干，而且你敢干，回报也是很真实的。

因为在传统行业里，你会突然变成一个很稀缺的人。你跟他们说 AI 可以帮他们对单、整理表格、自动生成文件、分析客户数据、把每天复制粘贴的活儿接走，他们真的会觉得，我操，这个人有点东西。

在大厂里你可能只是一个普通工程师。在 Stanford 你可能只是一个普通研究助理。但你到了一个真正缺 AI、缺自动化、缺技术理解的传统行业里，你突然就会变成一个很关键的人。

技术这东西，放在不同的地方，价值完全不一样。

---

我自己也不确定 HA7CH 这件事最后能走到哪里。也许几个月后发现某些假设是错的，也许 Hatch House 是个伪命题，也许商业模式需要大调整。这些都有可能。

但有一件事我们是确定的。

那片被忽略的大陆，是真实存在的。

那些从没见过 AI 的老板，是真的需要有人走进去的。

那些靠人力堆出来的工作流，是真的在等着被重写一遍的。

而每一个公司，有且只能被 AI 化一次。先进去的人，就拥有了那个工作流。后面再想蒸馏，就非常困难了。

这个窗口期不会永远存在。大厂 12 个月内会进场，但他们会从大客户做起。中小「土老板」市场，可能还有 12 个月的窗口。

所以回到开头那个故事。

一个年入千万的老板，用豆包看脸算命，觉得太牛逼了。

他不知道 AI 还能帮他做什么。他不知道他每天花在人力上的成本，有一半可以被系统接走。他不知道他的公司正等着被蒸馏。

但我们知道。

而我们要做的，就是找到那些有能力、有时间、敢走进现场的年轻 builder，把他们送到这些老板身边去。

让他们成为走进这些公司的第一个人。

HA7CH，BUILD IN THE FIELD. HATCH INTO IMPACT.

如果你觉得自己就是这种人，或者你想了解更多，来 ha7ch.com 看看。我们第一批 batch 已经在跑了。

我们，下次再见。


---

# Harvard Isn't Harvard, YC Isn't YC / 哈佛不是哈佛，YC 也不是 YC

> Published 2026-05-19 · By lawted · Canonical: https://ha7ch.com/writing/harvard-is-not-harvard

## English

Lately we've been chewing on one question: what exactly is ha7ch?

Not a business-model question. Not a fundraising-story question. Just very plainly: what are we actually building?

---

China has a massive number of mid-sized companies. Dozens of people, hundreds, sometimes several hundred. The operations are already too complex for Excel, but they can't afford a traditional software vendor.

Before, they had two options: drop several million on a custom platform, or keep grinding it out by hand. So entire industries got stuck in a “semi-digitalized” limbo.

Then AI native coding showed up. Claude Code, Cursor, vibe coding... they crushed the cost of writing software to a level no one would have dared to imagine. Suddenly a lot of needs that “weren't worth doing” were worth doing.

That was the opportunity we saw first. But later we realized it might only be the surface.

---

We suddenly clicked on something: the core of ha7ch might not be software at all. It's filtering people.

Today's college students aren't short on tutorials, courses, or Hackathons. What they're short on is the first real entry into the real world. The first time they realize:

“Wait, what I built is actually being used.”

“Wait, a system I made actually saved a company money.”

“Wait, I can make my first real money off my own skill.”

After a Hackathon ends, the project never gets opened again. A real company is different. A real company yells at you every day, chases you every day, says there's a bug here every day, says the flow is wrong every day. And precisely because of that, you actually enter the real world.

So ha7ch isn't a bootcamp. It's a funnel for AI native builders. We keep filtering: who can actually communicate, who can actually walk into a company, who can actually understand the business, who can actually deliver, who can actually finish.

A real builder isn't just someone who can write code. A real builder is someone who can turn the mess of the world into a system.

---

A lot of people ask: “Are you guys handing money to top college students?”

No. Handing out money has no meaning. What matters is letting them earn money for the first time. That feeling is completely different.

The moment someone realizes “holy shit, I actually made money doing this,” their worldview shifts. And the shift is irreversible.

A lot of people never get into that state in their whole life. They only live inside the GPA, grad-school, internship, offer, ranking game. The real world has another game. Some people are wired for research, some for enterprise, some for starting things, some for 0-to-1, some for 1-to-100.

Jack Ma wasn't Tsinghua's top student. Not everyone has to become the top of the academic ladder. What matters is: have you found your own battlefield?

---

Then we figured out one more thing: why do some organizations end up so strong?

Not the courses. Not the office. Not the logo. It's the people inside.

Why is PayPal Mafia strong? Because that group later scattered across the Valley and built Tesla, LinkedIn, YouTube, Palantir. Why is YC strong? Because it keeps filtering founders, and the alumni network keeps compounding. Why is Harvard, Harvard? Because inside Harvard is that group of people.

Without those people, Harvard isn't Harvard.

So we increasingly think: the truly valuable thing isn't code. It's who you pulled all-nighters with, who you shipped projects with, who you failed with, who you raced a deadline with in a rented Shenzhen apartment. These relationships stay with you for years and years.

---

Honestly, we haven't figured out what ha7ch finally turns into. But one thing is getting clearer: it doesn't necessarily need to be commercial, at least not at the start.

The moment you stare at monetization from day one, you start unconsciously doing “things that make money” instead of “the right things.” What we want is to gather people first, let things happen first, let young people enter the real world and get results first.

It's more like a hybrid: a community of AI native builders, a filter, a real-world training ground, a resource network for young people.

If we have to analogize, it's closer to early YC. Not a commercial product but a mechanism. Its value isn't in a revenue report. It's in the people who walk out of it.

“I came out of ha7ch.” We hope one day that sentence carries weight.

---

A lot of people like to argue these days about whether AI will replace programmers.

But we increasingly think the truly hard-to-replace ability is a different one: can you talk to the boss, can you read a business workflow, can you walk into an unfamiliar industry, can you take the chaos, can you marshal resources, push things forward, land a vague requirement into something real.

AI has a hard time replacing these. And this might be the most important ability for the next generation of builders.

What ha7ch wants to do is actually simple: use the real world to filter out the next generation of AI native builders.

Monetization, later.

## 中文

我们最近一直在聊一件事：ha7ch 到底是什么？

不是商业模式的问题，也不是融资故事的问题。就是很纯粹地在想：我们到底在做一个什么东西？

---

中国有大量中型企业。几十人，上百人，甚至几百人。业务已经复杂到 Excel 顶不住了，但又请不起传统软件公司。

以前他们只有两个选择：花几百万上千万搞中台，或者继续人工硬撑。于是大量行业永远卡在“半数字化”的状态里。

然后 AI native coding 出现了。Claude Code、Cursor、vibe coding……把软件开发成本压到了一个以前不敢想的程度。突然之间，很多原本“不值得做”的需求，现在居然值得做了。

这是我们最早看到的机会。但后来发现，这可能只是表层。

---

后来我们突然意识到：ha7ch 最核心的东西，可能根本不是软件。而是筛人。

现在的大学生不缺教程，不缺课程，不缺 Hackathon。他们缺的是第一次真正进入真实世界。第一次知道：

“原来我写的东西真的有人在用。”

“原来一个系统真的能帮企业省钱。”

“原来我可以靠自己的能力赚到第一桶金。”

Hackathon 做完以后，项目一辈子没人打开第二次。但真实企业不是。企业会天天骂你，天天催你，天天说这里有 bug，天天说流程不对。但也正因为这样，你才真正进入了现实世界。

所以 ha7ch 的本质不是培训班，而是一个 AI native builder 的漏斗。我们在不断筛选：谁真的能沟通，谁真的能进企业，谁真的能理解业务，谁真的能交付，谁真的能把事情做完。

真正的 builder，不是只会写代码的人，而是能把混乱世界变成系统的人。

---

很多人会问：“你们是不是给优秀大学生发钱？”

不是。直接给钱没有意义。真正重要的是，让他第一次赚到钱。那个感觉完全不一样。

一旦一个人发现“卧槽，我靠这个东西真的赚到钱了”，他的世界观会变。而且这种改变是不可逆的。

很多人一辈子都没进入过这种状态。他们只活在 GPA、保研、实习、offer、ranking 的那套游戏里。但真实世界还有另一套游戏。有人适合做 research，有人适合做企业，有人适合创业，有人适合做 0 到 1，有人适合做 1 到 100。

马云也不是清华第一名。不是所有人都要成为学术最顶尖的人。真正重要的是：你有没有找到自己的战场。

---

后来我们想明白了一件事：为什么有些组织最后会变得那么强？

不是因为课程。不是因为 office。不是因为 logo。而是因为那群人。

PayPal Mafia 为什么强？因为那群人后来散落到了整个硅谷，创了 Tesla、LinkedIn、YouTube、Palantir。YC 为什么强？因为它持续在筛选创业者，校友网络越滚越大。哈佛为什么是哈佛？因为哈佛里面是那群人。

如果没有那群人，哈佛也不是哈佛。

所以我们越来越觉得，未来真正值钱的东西不是代码，而是：你和谁一起熬过夜，你和谁一起做过项目，你和谁一起失败过，你和谁一起在深圳的出租屋里赶过 deadline。这些关系会跟着你很多很多年。

---

说实话，我们现在也没想清楚 ha7ch 最终会长成什么样。但有一件事越来越确定：它不一定需要商业化，至少前期不需要。

如果一开始就盯着变现，你会不自觉地去做“能赚钱的事”，而不是“对的事”。我们现在更想做的是，先把人聚起来，先让事情发生，先让年轻人进入真实世界拿到结果。

它更像一个混合体：一个 AI native builder 的社区，一个筛选系统，一个现实世界训练场，一个年轻人的资源网络。

如果非要类比的话，可能更接近早期的 YC。不是一个商业产品，而是一种机制。它的价值不在营收报表里，而在于从里面走出来的那群人。

“我是从 ha7ch 出来的。”我们希望有一天，这句话是有分量的。

---

现在很多人喜欢讨论 AI 会不会替代程序员。

但我们越来越觉得，真正难替代的是另一种能力：你能不能和老板聊天，能不能看懂业务流程，能不能进入一个陌生行业，能不能扛住混乱，能不能组织资源、推动事情、把模糊需求真正落地。

这些东西，AI 很难替代。而这也可能是下一代 builder 最重要的能力。

ha7ch 想做的事情其实很简单：用真实世界，筛出下一代 AI native builder。

商业化的事，以后再说。


---

# Stop Saying "Jiushi" / 不要再说“就是”

> Published 2026-05-17 · By lawted · Canonical: https://ha7ch.com/writing/stop-saying-jiushi

## English

This is not exactly a "practical tips" essay. It is more like a small language alarm, and also a bit of life thinking from the AI era. Lately I have felt more and more strongly that there is one word we should probably say less. Ideally, we should consciously try to quit it. That word is "jiushi."

Of course, "jiushi" in Chinese is not some original sin. It has many normal uses. Sometimes it is just an ordinary copula. Sometimes it is just a spoken connector. Sometimes it is even just a filler sound people reach for while thinking. The problem is not the word itself. The problem is that we often use it to skip ahead. A lot of the time, once a "jiushi" comes out, the thinking that should follow has already been sealed off in advance.

The most common scene is not explanation, but rhetorical questioning. For example: "Isn't that what you mean?" "Isn't this just avoidance?" "Doesn't that just show you do not really want it?" On the surface, this sounds like discussion. In reality, the conclusion has already been stuffed into the question. It is not opening understanding. It is setting the default. It is not inviting the other person to think together. It is speaking the other person's meaning to death. A lot of people feel oppressive in conversation not because their tone is especially fierce, but because this posture of "I have already summarized you" arrives too quickly.

After spending a long time with AI, this actually becomes easier to see. A reasonably tuned model usually will not rush into a rhetorical question like that, and it usually will not slap a sentence like "aren't you just..." onto someone's head right away. What it does more often is first try to understand the context, first identify ambiguity, first offer several possible interpretations, and then slowly narrow them down. A lot of the time, it is even clumsy in how much it confirms: am I understanding this correctly? Is this what you mean? That kind of caution can feel verbose, but at least it shows one thing: real understanding should not be built on defaults. It should be built on space.

The most dangerous thing about "jiushi" is not that it is rude, and not that it is too colloquial. It is that it can so easily create the illusion of "I have already figured this out." Especially in Chinese, the word is too convenient. So convenient that a lot of the time, before the mind has really turned the corner, the mouth has already defined things on its behalf. It looks fluent. In reality, it is skipping steps. A question that was still worth thinking through one more layer, a place where one more question could still be asked, a relationship that had not yet been truly clarified: once a "jiushi" covers it over, what follows often stops unfolding.

That is also why I have recently become especially sensitive to this word. Model thinking takes time. AI today is already faster and faster, and better and better at simulating the feeling of "I get it." But any reasoning that is halfway decent still needs context, still needs disambiguation, still needs to put several possibilities next to each other and compare them. People are actually the same. But in real life, many people open their mouths with "jiushi," as if within one second they have already completed understanding, judgment, summarization, and classification. But how could it be that fast? Many so-called "jiushi" moments are not expressions after thinking has finished. They are shortcuts before thinking has begun.

So lately I have been somewhat serious about quitting this word. Not because it is low-class, and not because it lacks elegance, but because once you say it a little less, you realize that many times you actually had not thought that far. The place that "jiushi" wanted to jump over is exactly the place most worth pausing. Why do I understand it this way? Is there another possibility? Am I stating a vague problem too fully? Am I sealing off something that could still be questioned further?

In a sense, quitting "jiushi" is not training diction. It is training a more honest way of thinking. It forces a person to admit: I may not understand this yet. I may still need to think about this. I cannot reach a conclusion that quickly. This sense of pause feels more and more important in this era. AI is already very clear in its contextual logic. It is good at organizing information, sorting out structure, and laying out several possibilities. If we still keep some advantage that is more decent than the machine's, it may not be speed, and it may not be being "smarter." It may be understanding.

The understanding I mean here is not just "knowing" something. It is really entering into it, admitting that it may be more complicated than your first reaction, admitting that you may not have grasped the point immediately, and being willing to leave some room in discussion between people. Understanding is not some lofty posture of empathy, either. It is a very plain ability: knowing that you have limits, being willing to ask further, being willing to let a question stay with you for a little longer instead of rushing to answer first.

I originally wanted to connect this to Andrej Karpathy, but the more accurate version is that in his public discussions in recent years, Karpathy has repeatedly pushed human taste, judgment, and understanding to the front, rather than simply offering the slogan "the only moat humans have is understanding." A steadier way to put it is: the stronger AI becomes, the more important human judgment, taste, and understanding become. I agree with that direction. Because AI can already "think for a minute before answering." It can already simulate caution, simulate reasoning, and simulate reflection. But it cannot always truly notice where it does not understand. Humans at least still have one ability: in a certain moment, to honestly admit that I may have misunderstood this, I have not thought this through, I need to ask one more question, I need to learn a little more. That action itself is already powerful.

So in the end, what I want to say is not language purism, and it is not that "jiushi" should be deleted from Chinese entirely. I just increasingly feel that the way a person uses "jiushi" reveals many things. It reveals whether they are too eager to judge, too eager to summarize other people, too eager to simplify something complex into a ready-made default. It also reveals whether they leave room for understanding, whether they leave time for thinking, and whether they realize that they may not have arrived there yet.

If the AI era still leaves humans with any decent homework, I suspect one piece of it is this: do not live yourself into a machine that only knows how to buzz in first. A little less "isn't this just," a little more "let me think again"; fewer defaults, more real understanding; less rushing to define, more willingness to ask.

Start by saying one less "jiushi." Maybe that is not a bad exercise. Not because the word is guilty, but because a lot of the time, it arrives too fast. And understanding was never supposed to be that fast.

## 中文

这不是一篇特别“干货”的文章。更像是一篇语言上的小警报，也是一点 AI 时代的生活感想。最近越来越强烈地觉得，有一个词，真的应该少说，最好能有意识地戒掉。这个词就是“就是”。

中文里的“就是”当然不是原罪。它有很多正常用法，有时候只是一个普通的系词，有时候只是口语里的连接词，有时候甚至只是人在思考时顺手垫一下的语气。问题不在这个词本身，而在于它常常被我们用来偷跑。很多时候，一个“就是”出来，后面的思考其实就已经被它提前封口了。

最常见的场景，不是解释，而是反问。比如，“你不就是这个意思吗？”“这不就是在逃避吗？”“那不就是说明你根本不想吗？”这种说法表面上像在讨论，实际上已经把结论塞进了问题里。它不是在打开理解，而是在设定默认值。它不是在邀请对方一起想，而是在替对方把话说死。很多人说话之所以让人觉得有压迫感，不是因为语气有多凶，而是因为这种“我已经替你总结完了”的姿态来得太快。

这一点，和 AI 相处久了之后，反而会看得更明显。一个正常被调教过的模型，通常不会那么急着反问，也不会上来就把一句“你不就是……”扣在人头上。它更常做的事情，是先试图理解上下文，先辨认歧义，先给出几种可能的解释，然后再慢慢收束。很多时候，它甚至笨拙得有点过头，会反复确认：我理解得对不对？是不是这个意思？虽然这种谨慎有时让人觉得啰嗦，但它至少说明了一件事：真正的理解，不该建立在默认值上，而该建立在空间上。

“就是”最危险的地方，不在于粗鲁，也不在于口语化，而在于它特别容易制造一种“我已经想清楚了”的幻觉。尤其是在中文里，这个词太顺手了。顺手到很多时候，脑子还没真正转过去，嘴已经先替自己下了定义。看上去像表达流畅，实际上是在跳步。原本还值得再想一层的问题，原本还可以再问一句的地方，原本还没有真正厘清的关系，一旦被一个“就是”盖过去，后面往往就不会再继续展开了。

这也是为什么我最近开始对这个词特别敏感。因为模型思考是需要时间的。今天的 AI 虽然已经越来越快，越来越会模拟那种“我懂了”的感觉，但真正像样一点的推理依然需要上下文，需要辨义，需要把几种可能性放在一起比一比。人其实也一样。可现实里，很多人一开口就是“就是”，好像一秒钟之内就已经完成了理解、判断、归纳和定性。可哪里有那么快。很多所谓的“就是”，不是思考完成后的表达，而是思考还没开始时的捷径。

所以我最近有一点想认真戒掉这个词。不是因为它低级，也不是因为它不够优雅，而是因为一旦少说一点，才会发现，很多时候自己其实并没有想到那个地步。那个“就是”原本想跳过去的地方，恰恰是最值得停一停的地方。为什么会这样理解？有没有别的可能？是不是把一个模糊的问题讲得太满了？是不是把一个本来还可以继续追问的东西，提前封口了？

某种意义上，戒掉“就是”，不是在训练措辞，而是在训练一种更诚实的思考方式。它逼着人承认：这里我可能还没懂，这里我还需要再想一下，这里不能那么快地下结论。这种停顿感，在现在这个时代反而显得越来越重要。因为 AI 的上下文逻辑已经很清楚了，它很擅长整理信息、梳理结构、摊开几种可能性。我们如果还保留一点比机器更像样的优势，未必是在速度上，也未必是在“更聪明”上，而更可能是在理解上。

这里说的理解，不只是“知道”一个东西，而是真实地进入它，承认它可能比自己第一反应更复杂，承认自己可能没有一下子抓到重点，也愿意给人与人之间的讨论留一点空间。理解也不是一种高高在上的共情姿态，而是一种相当朴素的能力：知道自己有局限，愿意追问，愿意让一个问题在自己这里多停留一会儿，而不是急着抢答。

我原本想把这件事和 Andrej Karpathy 联系起来，但更准确的说法应该是，Karpathy 在近年的公开讨论里，反复会把人的 taste、judgment、understanding 往前推，而不是简单给出一句“人类唯一的护城河就是理解”的口号。更稳妥地说，AI 越强，人的判断、品味和理解力就越重要。我很认同这个方向。因为 AI 当然已经能“思考一分钟再回答”，也已经能模拟谨慎、模拟推理、模拟反思，但它不总能真的意识到自己哪里没懂。人至少还有一个能力，是可以在某个瞬间认真承认：这里我可能理解错了，这里我还没想透，我得再问一句，我得再学一点。这个动作本身，就已经很厉害了。

所以到最后，我想说的其实不是语言洁癖，也不是要把“就是”从中文里彻底删掉。我只是越来越觉得，一个人怎么用“就是”，其实会暴露很多东西。暴露他是不是太急着下判断，太急着替别人总结，太急着把复杂的东西简化成一个现成的默认值。也暴露他有没有给理解留空间，有没有给思考留时间，有没有意识到自己可能还没到那个地步。

如果说 AI 时代还给人留了什么像样的功课，我猜其中一个就是这个：不要把自己活成一台只会抢答的机器。少一点“这不就是”，多一点“我再想想”；少一点默认值，多一点真的理解；少一点急着定性，多一点愿意追问。

先从少说一句“就是”开始，也许是个不坏的练习。不是因为这个词有罪，而是因为很多时候，它来得太快了。而理解这件事，本来就不该那么快。


---

# Baseball and the Blame Game / 棒球与职场甩锅

> Published 2026-05-14 · By lawted · Canonical: https://ha7ch.com/writing/baseball-and-the-blame-game

## English

I got into baseball last year and realized: baseball and the office are basically the same thing. Same rules, same playbook, no one really watching.

---

Nine of them against one of you. When it's your turn, you're alone against all of them. The office is no different — you think you have teammates, but you don't.

There's exactly one situation where a coworker actually cares about you: they've already taken a base, they need you to not strike out, they need you to move them forward. The moment your interests line up, they care. The rest of the time, nobody is catching the ball for you.

---

Every pitch is someone trying to pin something on you.

The ball flies in, you don't know if it's meant for you. If it isn't in your zone, that's a ball — don't move. The blame doesn't land, and the person who threw it just exposed themselves. The second you swing, it's yours.

The most important skill is reading whether it's coming into your zone. The mistake juniors make is panicking and swinging.

---

If it's in your zone, you have to swing. The point isn't to hit the ball back — it's to throw the blame somewhere else.

But you can't put it directly into someone's hands. That's a caught fly ball. Everyone saw it. Everyone knows it came from you.

Either knock it out of the park — home run — and the blame vanishes. Or hit it where nobody can catch it cleanly, then run like hell and get yourself on base.

Getting on base is grabbing onto a boss's leg. The blame is still floating around, but you're standing on something solid.

---

Standing on base isn't winning, though.

People keep coming for you. Three strikes and you're out. The round is over.

How does the strikeout happen so easily? Because your coworkers all know you're going to throw the blame somewhere. They've already taken up every position on the field — wherever you want to throw it, they're already standing there. The angle and force of your swing? They've predicted it.

Real home runs — the ones that actually clear the park — are rare. Most balls land inside their range. They reach out and catch.

---

The hard part of baseball isn't swinging. It's knowing when not to.

But there's a harder call than that — whether you're on the field today, or up in the stands.

It's not a difference in job. It's a difference in posture. In the same company, some people are out there grinding for every at-bat, while others sit in the stands with a beer and watch the whole thing play out.

---

But honestly, neither of those is right.

Baseball is baseball. The office shouldn't be baseball.

Nine guys on the field grinding through a game nobody's watching — that's their job. The office isn't supposed to be like that. The office is supposed to be a place where you produce value. What you ship runs or it doesn't. It saved a headcount or it didn't. A customer paid for it or they didn't. There's no blame to pass, because there's nothing to blame anyone for.

Over the next few years, there's going to be a new player on the field. More specifically: an AI player. The person who brings him onto the field is what's now being called an FDE — a Forward Deployed Engineer.

This player can pitch, catch, run, and deflect — all at once. He knows your strike zone. He knows where you want to throw the blame. He can stand at all nine positions at the same time. Hit it clean and he reaches out and catches. Even a home run — he gets to the wall first.

In the office, he's the handoff that used to take three people a week — now it takes ten minutes.

Reading this, you might be thinking: isn't this exactly the work that's going to replace mine?

Yes. Partly. But more precisely — he's not here to replace you. He's here to replace the game itself. This game nobody was watching, he can play it alone. The only real question left is whether you want to keep stepping up to bat, or stop playing this game.

You might still be thinking: even if I stop, the coach isn't going to let me have any of that saved time off.

He won't — if you're still on his team.

Here's another angle. The AI player can do everything, but he doesn't know what to do. Which process is broken. Which Excel everyone hates. Which handoff is the worst — none of that lives in the documentation. None of it lives in the data.

It lives in the break room complaints. In the 5:47 PM message someone fires into the group chat and deletes a minute later. In the 'don't tell the boss' that a coworker drops over a cigarette right before telling you anyway.

People only say this kind of thing to other people. That's the part AI can't take.

You've been on this field for years. So you know.

Take that — the things only humans tell other humans — into another company, bring the AI player with you, and you're the FDE.

Freelancing, building your own product, working solo with a craft — these count too. None of them put you on this field.

Of course, not every one of those paths will work for everyone. That's OK — this game isn't going to wrap up in a day, and you don't have to leave in one either. Knowing what AI can do, and what it still can't, is enough.

Where you go doesn't matter. Just stop playing.

People who stop playing this game come home tired and can still go watch a real one. A beer, some peanuts, friends.

## 中文

我从去年开始喜欢看棒球，意识到棒球和职场其实是一回事。一样的规则、玩法，没人在看。

---

球场上九个人对你一个。轮到你打球的时候，你一个人面对所有人。职场也是——你以为有同事，其实没有。

只有一种情况他们会真正关心你：他已经站上了某个位置，需要你别砸，需要你把他往前推。利益捆在一起的那一刻，他才在乎。剩下的时候，没人替你挡球。

---

每一次投球，是一次甩锅。

锅飞过来，你不知道它是不是冲着你来的。没飞进你的区域，那是坏球——你不动，扔锅的人自己心虚。但你只要挥棒，这口锅就是你的。

所以最重要的是看清楚有没有飞向你的区域。新人最容易犯的错，就是慌着挥。

---

飞向你了，你必须挥。挥不是为了把球打回去，是把锅甩出去。

但不能甩到别人手里——那叫接杀，所有人都看见是你甩的。

要嘛打出场外，全垒打，锅找都找不着。要嘛打到没人接得住的地方，自己冲上去安全上垒。

安全上垒，就是抱住了领导的大腿。锅还在场上，但你站稳了。

---

但是站稳不等于赢。

人会一直来找你茬。三振出局，这一轮就完了。

三振出局是怎么发生的？你的同事都知道你会甩锅。他们已经在场上每一个位置都站好了——你想往哪甩，他们就在哪等着。你挥棒的方向、力度，他们早就预判过。

真正能打出场外的全垒打，很少。大多数球，都落进他们的射程里，伸手就接住。

---

棒球的难，不在挥，在判断什么时候不挥。

但还有一个更难的判断——你今天到底是在场上，还是在看台上。

这不是工种的区别，是心态的区别。同一家公司里，有人在场上为这一棒拼命，有人在看台上嗑着瓜子把整场看完。

---

但说实话，这两种都不对。

棒球就是棒球。职场不应该是棒球。

球场上九个人玩这场没人看的硬仗，那是他们的本职工作。职场不该是。职场该是一个生产价值的地方——你交付的东西要么跑要么不跑，要么省了人要么没省，要么客户买单要么没买单。这种地方没有锅可甩，因为根本没有锅。

未来几年球场上会多一个人。准确说，是一个 AI 球员。带他上场的人，现在流行叫 FDE（前线部署工程师）。

这个球员同时会投会接、会跑会甩。你的好球带他知道，你想把锅甩到哪他也知道。他可以同时站在场上的九个位置——你打得再准他也伸手就接，全垒打也接得下来。

具体到办公室里，他就是那个每天三个人扯一星期的对接，现在十分钟自己跑完了。

看到这儿你可能想：这不就是来取代我的工作的吗？

对，部分是。但更准确地说——他不是来取代你。他是来取代这场球本身的。这场没人看的比赛，他一个人就能玩。剩下的问题只有一个：你想继续上场挥棒，还是不打这场球。

你可能还会想：就算我不打了，省下来的时间教练也不会让我休息。

对，他不会——如果你还在他的球队里。

换个角度想——AI 球员什么都会做，但他不知道该做哪件。哪个流程最烂、哪个 Excel 大家最恨、哪个对接最折磨人——这些事不在文档里，也不在系统数据里。

它们在茶水间的抱怨里，在群里 5 点 47 分发出来又秒删的那条吐槽里，在同事跟你抽烟时说的「你别跟领导说啊」后面那半句话里。

人只跟人说这种话。这是 AI 拿不走的。

你打了这么多年球。所以你知道。

把这些「只有人才会告诉人」的事，带到另一家公司，再带上 AI 球员——你就是 FDE。

自己接活、做产品、靠手艺单干，也都行。这些人都不在这个球场里。

当然，这些路不一定每条都走得通。也没关系——这场球不是一天散的，你也不必一天就走。看清楚 AI 能干什么、还干不了什么，已经够了。

去哪不要紧。不打就行。

不打的人，累完回家还能去看一场真的。一杯啤酒，一把瓜子，一群朋友。


---

# Claude Code for Everything / Claude Code，用于一切

> Published 2026-05-14 · By lawted · Canonical: https://ha7ch.com/writing/claude-code-for-everything

## English

Not long ago I wanted to ask another developer: did you write this feature?

I stopped myself. Wait — why am I asking him? When did I start doing that?

I went and asked Claude Code instead.

The answer came back faster, broader, and more complete than anything I would have gotten from the person who wrote it. I didn't need to wait. I didn't need to bother anyone. I didn't need to set up any context at all.

---

I'm not saying asking people doesn't work.

I'm saying Claude Code has a deeper understanding of the entire codebase than any single person has of their own part of it.

When you ask a person, you first check if they're free. Then you set the context. Then you wait. Then you accept that they might remember it wrong. Every single stage has friction.

Ask Claude Code, and all of that is gone.

---

And now I use Claude Code for everything.

Articles, ideas, content production, all of it. This article itself: I dictate in Chinese using WeChat voice input on Mac, drop it into Claude Code, and get a Chinese draft with an English version alongside it. The English always sounds too AI, so I don't use it directly. I take both versions, run them through Claude one more time, and that produces the final thing you're reading.

---

This is also why we're building zero-token products.

Zero-token doesn't mean zero AI. It means the reasoning happens inside your own workspace, not inside some chatbot widget embedded in a product. Claude Code is the workspace. Not the tool. Everything flows through it: coding, writing, thinking, executing.

That's the default architecture for everything we build now.

---

So my conclusion is simple: everyone needs their own Claude Code or Codex.

Not a recommendation. A must have.

This is the infrastructure of 2026.

## 中文

前不久，我想问我们另一个开发一个问题：这个功能是不是你写的？

然后我突然停住了。喂，为什么我要问他呢？

我直接去问了 Claude Code。

Claude Code 的回答比本人更快、更全、更准。不需要打扰别人，不需要等待，也不需要给他铺垫上下文。

---

不是另一个开发不行。

而是 Claude Code 对整个 codebase 的理解，比任何一个人对他自己的那块代码的理解都要深。因为我们所有人都是 Vibe Coding 的。

当你想问一个人的时候，你需要先去问他有没有空，然后要把背景说清楚，然后等他想起来，他有可能还记错了。中间全部都是摩擦点。

而问 Claude Code，这些摩擦点会全部消失。

---

我已经把 Claude Code 用于一切。改文章、整理思路、内容生产，都在这里。

就连这篇文章，工作流是这样的：用 Mac 微信的语音输入说中文，丢进 Claude Code，它先出一个中文初稿。然后我对着这个中文初稿，口说英文翻译，再把英文丢给 Claude Code，让它将两个版本结合起来。因为这样的话，中文初稿里那些 AI 腔的语言，我是不会翻译成英文的。这样一结合，就更容易出一个人类易阅读的版本。

---

这就是为什么我们一直在做零 Token 产品。关于零 Token 产品，可以看我们之前的文章。

Claude Code 是一个 workspace，不是一个工具。所有的工作都以它为中心展开：编码、写作、思考、执行。我们所有产品的默认架构，都是这样的。

---

最后我的结论很简单：每个人都应该有自己的 Claude Code 或者 Codex。

这不是一个推荐，而是一个 must have。

因为他妈的，2026 年的基础设施，就是这个。


---

# Question Every Instinct / 质疑你的每一个直觉

> Published 2026-05-13 · By lawted · Canonical: https://ha7ch.com/writing/question-every-instinct

## English

Since shipping Raily, we get a ton of suggestions every day.

They all sound reasonable. They all sound like the obvious next step. But I've noticed that most of them, if you just follow your gut and do them, are wrong.

I mean it. All wrong.

---

Example one. We have a RedNote group of about 1000 people dropping feedback all day. A bunch of people told me: you should build a RedNote agent. Have the agent read the group messages, turn them into a requirements doc, then you can build the requested features faster and you don't have to keep providing emotional value in the group.

I told them: you're dead wrong. Completely wrong. Absurdly wrong.

First, the reason we built this group is to learn how to do ops. We've been writing fucking code for five years. Why would we want to learn more code? What we need to learn right now is how to give people emotional value. That's our current bottleneck. Not code.

Second, building a RedNote scraper agent walks straight into anti-bot hell. It's a bottomless pit. Burns time, burns brain, returns close to zero.

What's the right move? You provide the emotional value yourself, in the group, and while you're at it you distill the requirements yourself. Once the requirements are clean, you hand them to Claude Code or Codex and let it write the code. That's the right way.

And the technical difficulty of that second half is zero. That's literally today's workflow. Right?

Following the gut, you were going to use the agent for the part that's most worth doing by hand, and spend your own time on the part the agent is best at. Completely flipped.

---

Example two. We started doing writing, and people said: you should add email subscriptions.

Nope.

Email is a thing on the way out. If my read is right, we're heading into a zero-token era. Everyone will have their own AI agent.

So what should we build? A CLI, or an MCP, so people can plug their agents in.

Whenever their agent wants to read our writing, it can just ask the AI. The AI summarizes, extracts, translates into whatever language. That's how the consumption is going to happen.

Or, if they want it automated, their agent crawls our site on a schedule and pulls in the new content.

So the move is not to embed a chatbot widget on the page, and not to slap on an email subscription button. The move is to make our site more agent-friendly. Easier to read, easier to parse, easier to consume.

Following the gut, you were trying to keep people on your webpage. But the future is that people aren't going to come to your webpage at all.

---

So now, every time I hear a suggestion or feel an instinct, I stop.

I ask: which era does this instinct come from? Is it a paradigm from the previous era? Is it my old comfort zone?

Most of the time, the answer is yes.

## 中文

做了 Raily 以后，每天会有非常多的人给我们提建议。

听起来都很有道理，听起来都像是顺理成章的下一步。但是我发现，大部分的建议如果你顺着直觉去做，全是错的。

我说真的，全是错的。

---

举个例子。我们小红书群里大概 1000 个人，每天嘎嘎地提需求。听了好多人跟我说：你可以做一个小红书的 agent，让 agent 去读群里面的消息，整理成需求文档，然后你就可以更方便地去做，不需要在群里面提供情绪价值了。

我说大错特错，大错特错，错到离谱。

第一，我们建这个群是因为我们要学习的是如何去运营。我们写代码他妈的已经写了五年了，我们还学什么代码？我们要学的就是如何去给别人提供情绪价值，这是我们当下的瓶颈，不是写代码。

第二，你做小红书的 agent，反爬非常严重。你掉进去就是个无底洞，烧时间、烧脑子、收益接近于零。

那正确的做法是什么？你他妈应该自己在群里一边提供情绪价值，一边把需求整理出来。把需求整完了以后，丢给 Claude Code 或者 Codex 自己去写。这才是正道。

而且这后面的技术难度是零，就是现在的工作流，对不对？

也就是说，你顺着直觉是想用 agent 去做你最值得人工做的部分，然后自己花时间去做 agent 最容易做的部分。完全反了。

---

再举个例子。我们这边开始做了 writing，然后有人说：你们应该给 writing 加上邮件订阅。

我说不对呀。

邮件是正在退场的东西。如果我的判断是对的，后面大家会进入零 token 时代，所有人都会有自己的 AI agent。

那这种情况下我们应该做什么？应该做一个 CLI，或者一个 MCP，让大家可以把他们的 agent 接进来。

他们的 agent 在任何时候，如果他想起来要读一下我们的文章，可以直接问 AI。AI 也可以帮他总结、帮他提炼、帮他翻译成各种各样的语言。

或者，如果他想自动化，应该是他的 agent 每天定时来爬一下我们的网站，把新的内容拉走。

所以我们要做的不是在网页里嵌一个聊天机器人，也不是加一个邮件订阅按钮。我们要做的是让我们的网站对 agent 更友好，更容易被读、更容易被理解、更容易被消费。

你顺着直觉想做的是把人留在你的网页上。但未来的事情是，人根本就不会来你的网页。

---

所以我现在每次听到一个建议、产生一个直觉，先停下来。

问自己：这个直觉到底来自哪个时代？是来自上一个时代的范式吗？是来自我以前的舒适区吗？

大部分的时候，答案是是的。


---

# The Frog in the Well / 井底之蛙

> Published 2026-05-13 · By lawted · Canonical: https://ha7ch.com/writing/the-frog-in-the-well

## English

I failed Computer Science in high school. I'm studying accounting in college. I am, by every reasonable measure, not the person who should be writing this.

But three internships in three industries taught me something most software engineers will never see.

---

I didn't learn what FDE meant from a blog post. I learned it from three internships where I watched smart people do stupid things, and nobody around them knew it was stupid.

Private equity firm (2023): Hundreds of interns. Powerful CRM, genuinely good leads, real money on the table. The job: copy-paste the same boilerplate outreach message to every lead. Hundreds of interns, all doing the exact same thing, by hand, every day.

I built a pipeline that replaced the work of 200 interns and personalized every message at the click of a button. They didn't want to pay me for the tool. Cited my work contract. Hell nah, I left.

Fuel company, $5B in revenue (2024). I was a tax accounting intern. I watched two CPAs (people who passed one of the most rigorous certifications in the country) manually copy-paste customer addresses, one by one, to look up tax rates. This was 50 percent of their job. This is what the company pays them to do. Mindless. Their specialization is needed elsewhere but their time is soaked up here. One week. I find my own shapefiles, build a Python pipeline (a few hundred lines of code), done. Whole company's fuel tax calculations, automated.

Civil engineering firm (2025). Engineers eyeballing 50 years of time series data, trying to pattern-match temporal sequences visually. With their eyes. Took them 10 hours per week. I built a parsing engine with dynamic time warping that surfaced mathematically high-tier matches in seconds.

---

Three internships. Three industries that have nothing to do with each other. Same story every time. I wasn't in any of these companies as a software engineer. I entered each of these companies as a business intern. A SWE intern would never have been in those rooms. The reason I saw these workflows is that I was sitting next to the people doing them.

These weren't dumb companies. PE firms aren't dumb. CPAs aren't dumb. These civil engineers were incredibly smart. And yet all of these workflows were structurally insane. Nobody on the inside saw it. Not because they were stupid. Because they were the frog at the bottom of the well.

井底之蛙. You don't know what you don't know. You can't see the sky from down there. The water you swim in is the only water there is.

---

This is what's sitting in every traditional company in the world right now. Not a few. Every single one. Some workflow that absorbs the brainpower of three people, or thirty, or three hundred, that one person with a laptop and the right instinct could collapse in a few weeks. The bottleneck is that the people who can see the workflow can't see the AI, and the people who can see the AI never walk into the room.

YC and SF are bright and flashy right now. Founders pitching wrappers that will be murdered in the next Claude release, bragging on Twitter how they're going to scam VCs out of a seed round, building the same stupid dating app for the seventh time. The bubble is real. Many of those companies will not exist for long.

Meanwhile, there's a logistics company outside Seattle doing $80M a year, running dispatch out of a spreadsheet a guy named Dave built in 2011. Dave retired in 2019. Nobody knows how half the formulas work. They hired two people last year just to babysit the file. The owner has heard of ChatGPT because his daughter showed him. He has real revenue, real margin, and a real problem that AI can solve this afternoon.

That's where the value is. Not glamorous. Not on Twitter. A back office in a strip mall, fluorescent lights, a printer that jams, a whiteboard with last quarter's numbers still on it. Just a workflow that's been running on human brainpower for thirty years, waiting for one person to walk in and see it.

---

The people who can do this are not normal software engineers. A traditional SWE wants a ticket, a spec, a code review, a staging environment. None of that exists here. You walk in with nothing. The workflow lives in someone's head. Half the time the boss can't even tell you what his employees do. You have to sit next to them and watch.

You will not understand anything going in. You have to learn fast or you're cooked. You have to be able to talk to people who are nothing like you, who think AI is magic or a scam or both. You have to have tact when the boss is wrong, and you have to know when to push anyway. You have to ship something on Tuesday that you didn't understand existed on Monday.

The things you build will have no documentation. There is no way to paste it into Claude Code and have it write itself. The schema is in someone's notebook. The business logic is in an employee's head. The edge cases live in a Teams chat from 2020. You have to dig it out, structure it, and ship.

---

This is not for everyone.

But if you can do it (and maybe that person is you) there is a window right now that we've never seen before. Every traditional company gets distilled exactly once. Whoever does it first owns that workflow. And there are millions of these companies.

I learned this by accident. Starting from an accounting degree, three internships, and a habit of figuring shit out and building the thing when I see something too stupid to be done manually. Most of the people who'll thrive at HA7CH probably learned it the same way- from somewhere they weren't supposed to be.

---

The frog at the bottom of the well doesn't know the well is a well.

Let's go build some fucking ladders

## 中文

我高中计算机课挂了科。我大学读的是会计。怎么看，我都不该是写这篇东西的人。

但三段实习，三个完全不同的行业，让我看到了大多数软件工程师一辈子都不会看到的东西。

---

我不是从哪篇博客上学会什么叫 FDE 的。我是从三段实习里学会的——在那些地方，我亲眼看着一群聪明人做着蠢事，而他们身边没有一个人意识到那有多蠢。

私募股权公司（2023年）：几百个实习生。强大的 CRM、真正优质的线索、桌面上摆着真金白银的钱。工作内容是什么？把同一段模板化的开发信复制粘贴给每一个线索。几百个实习生，每天手动重复着完全一样的动作。

我搭了一条流水线，一键替代了 200 个实习生的工作，而且每封信都做了个性化处理。他们不愿意为这个工具付我钱，搬出我的劳动合同来压我。去他妈的，我走人。

燃油公司，年营收 50 亿美元（2024年）。我是税务会计实习生。我看着两个 CPA（全美最难考的资格证之一的持证人）一个一个手动复制粘贴客户地址，去查税率。这占了他们工作量的 50%。这就是公司花钱请他们干的事。完全是脑死亡的活。他们的专业能力本该用在别的地方，时间却全耗在了这里。一个星期。我自己找到了 shapefile 数据，搭了一条 Python 流水线（几百行代码），搞定。整个公司的燃油税计算，全自动化了。

土木工程公司（2025年）。工程师们盯着 50 年的时间序列数据，试图用眼睛去识别时间模式。用他们的肉眼。每周要花 10 小时。我写了一个解析引擎，用动态时间规整（DTW）算法，几秒钟就把数学意义上的高匹配项给捞出来了。

---

三段实习。三个毫不相干的行业。每次都是同一个故事。我进这些公司都不是以软件工程师的身份。每一次我都是以商科实习生的身份进去的。SWE 实习生根本进不了那些房间。我能看到这些工作流，是因为我就坐在干这些活的人旁边。

这些都不是傻公司。私募股权公司不傻。CPA 不傻。那些土木工程师聪明得很。但所有这些工作流在结构上都是疯狂的。公司里没有一个人看得出来。不是因为他们蠢，而是因为他们是井底之蛙。

井底之蛙。你不知道自己不知道什么。从井底，你看不到天空。你游的那点水，就是你认识的全部的水。

---

这就是现在全世界每一家传统企业里都摆着的东西。不是少数几家。是每一家。某个吞噬着三个、三十个、甚至三百个人脑力的工作流，而一个带着笔记本电脑和正确直觉的人，几个星期就能把它压成一行命令。瓶颈在于：能看见工作流的人看不见 AI，能看见 AI 的人从来不会走进那个房间。

YC 和旧金山现在又亮又花。创始人们推销着下一个 Claude 版本一发布就会被秒杀的套壳产品，在 Twitter 上炫耀自己怎么把 VC 的种子轮骗到手，第七次做同一个傻逼约会软件。泡沫是真的。这些公司里很多撑不了多久。

与此同时，西雅图郊外有家物流公司，年营收 8000 万美元，整个调度系统跑在一个叫 Dave 的人 2011 年搭的 Excel 表上。Dave 2019 年退休了。没人知道那些公式里有一半是怎么算出来的。去年他们专门请了两个人来伺候这张表。老板听说过 ChatGPT，因为他女儿给他看过。他有真实的营收、真实的利润，以及一个 AI 今天下午就能解决的真实问题。

价值在那儿。不光鲜。不在 Twitter 上。在某个购物广场后面的办公室里，荧光灯，会卡纸的打印机，白板上还写着上个季度的数字。一个跑了三十年、全靠人脑撑着的工作流，等着一个人走进来看见它。

---

能干这活的人，不是普通的软件工程师。传统 SWE 想要的是工单、需求文档、code review、staging 环境。这里什么都没有。你两手空空地走进去。工作流住在某个人的脑子里。一半时间老板自己都说不清他的员工到底在干什么。你必须坐在他们旁边，看着。

刚进去的时候你什么都看不懂。你必须学得很快，不然就完蛋。你必须能跟那些跟你完全不是一类人的人说上话——那些觉得 AI 是魔法、是骗局、或者两者皆是的人。老板说错的时候你得有分寸，但该顶回去的时候你还得顶回去。你必须在星期二交付一个你星期一根本不知道它存在的东西。

你写出来的东西不会有任何文档。没法直接丢给 Claude Code 让它自己写出来。数据库结构在某人的笔记本里。业务逻辑在某个员工的脑子里。边角情况躺在 2020 年的某个 Teams 聊天记录里。你必须把它们挖出来，理清楚，然后交付。

---

这不是每个人都能干的活。

但如果你能干（也许那个人就是你），现在有一扇我们从来没见过的窗口。每一家传统公司只会被蒸馏一次。谁先把它做了，谁就拿下那个工作流。这样的公司有几百万家。

我是误打误撞学会这件事的。一个会计学位、三段实习，加上一种看见太蠢的人工活就忍不住想搞清楚、把东西造出来的习惯。能在 HA7CH 干得好的人，大概也都是这么学会的——从一个他们本不该出现的地方学会的。

---

井底之蛙不知道那口井是一口井。

我们去造他妈的梯子吧


---

# Walk on Two Legs / 两条腿走路

> Published 2026-05-12 · By lawted · Canonical: https://ha7ch.com/writing/walk-on-two-legs

## English

At dinner today a friend brought up this question: why does the US political system have an auto-repair mechanism?

It's pretty simple. Every government can publicly say the previous one was wrong. That sounds normal, but think about it. It means the system can go left, can go right, can go left-right-left-right, and it just keeps moving. Working with two legs.

Most people can't do this. Because we're always scared. Scared that when we publish our ideas, someone will say you're fucking stupid. Scared that something we told a friend last week gets screenshotted and thrown back at us: look how much you've changed. So we either say nothing, or we hold a position we already know is wrong.

---

But you can treat every period of yourself as a different person.

Next week, you can say: what I wrote last week was wrong. I wasn't clever enough then. After that I saw something, I experienced something, so my judgment changed. That's a good update.

Everything you write today, you don't need to protect it with your whole life. It's just today's version. Look at the date on this article. May 12. This is a snapshot of May 12. It might change tomorrow, next week, next month. Or it might be right forever. Both are fine.

---

Your mind only has before and after. There is no high and low.

Because it's dynamic. Yesterday is right and today may be wrong. And even worse, you don't know you're wrong today. But that's very possible.

Every day is different. Who you meet, what you read, what you talk about at dinner — it all has a huge impact on your judgment. That's pretty normal.

So don't chase a straight upward mind curve. That curve doesn't exist. If you pursue it, you're just going to end up saying nothing.

Walk on two legs. Left right, left right. That's how we work.

## 中文

今天和朋友吃饭，聊到一个观点：为什么美国的政权有一种自动修复机制？

很简单。每一届政府都可以公开说，上一届是错的。这件事听起来很普通，但你仔细想，这其实非常牛逼。它意味着整个系统可以左，可以右，可以左右左右地走，但它一直在走。两条腿走路。

我们很多人做不到这件事。不是因为认知不够，而是因为怕。怕发出来以后别人觉得你蠢，怕上周说了一件事这周被打脸，怕被人截图说你前后矛盾。所以大多数人就干脆不说，少做少错，不做不错。

---

但其实你完全可以把每一个时期的自己当成不同的人。

下周的你，完全可以站出来说：上周那些话是错的。我那时候认知不够。后来我看到了什么，经历了什么，所以我今天的判断变了。这不是打脸，这是更新。

你今天写下来的东西，不是一份需要你用余生去捍卫的声明。它只是你今天这个版本的快照。

---

认知只有先后，没有高低。

而且它是动态的。昨天是对的，今天可能是错的。更麻烦的是，你今天意识不到自己今天是错的。这也完全有可能。

每天都会不一样。你今天遇见了什么人，读了什么，吃饭的时候聊了什么，都会影响你的判断。这不是软弱，这是正常的。

所以，不要去追求一条永远笔直向上的认知曲线。那种曲线不存在，追求它只会让你越来越不敢开口。

两条腿走路，左右左右，一直往前走。这才是真的在走路。


---

# HA7CH Is a FDE Accelerator / HA7CH 是一个 FDE 加速器

> Published 2026-05-11 · By lawted · Canonical: https://ha7ch.com/writing/ha7ch-is-a-fde-accelerator

## English

Over the last couple of days a lot of people have been asking us what HA7CH actually does. The answer is simple: HA7CH is a FDE accelerator.

---

YC helps founders become companies. HA7CH helps people become founders.

YC takes people who already stand out and gives them resources. HA7CH finds people before they stand out, on campuses and in build in public, and puts them in front of real problems, real users, and real deliveries.

YC asks: "Who is worth investing in?" HA7CH asks: "Who can be ha7ch'd?"

In a world where products are easy to copy, the moat is no longer the product itself. The moat is the people you can gather, ignite, and move forward together.

---

So what are we actually doing right now?

On one side, we're running a RedNote group of around 1000 people who really love Raily, which, to be fair, has turned out pretty well. They drop feedback in there all day long.

On the other side, we're running a WeChat builder group, made up of people who like vibe coding, with their heads on right. People who want to build things together, and who align with some of what HA7CH thinks.

---

Let's start with Raily. A lot of people want us to charge. We don't want to. We'll ship it, list it on the store, and at peak popularity we'll just open source the whole thing.

Raily didn't cost us much. A few sleepless nights and some dev. But what did we get? A user base. Feedback. Affection. These matter way more than the few bucks of subscription money we could have collected.

What we're after is momentum, pulling more users and more attention onto our products. There's a second use too: when we want to break out and push the next product, if someone in the builder group has an idea, they don't have to cold start. We drop what they build straight into the user group and let real users react. If they like it, we keep going. If they don't, we drop it and start the next one.

So Raily is really our first branding move. Lawted's branding, HA7CH's branding. Which is fucking important.

This is how we attract a certain kind of builder: people with serious AI and coding skill, with belief, with ideas, with execution.

What are these people good for? They're good for FDE.

---

FDE is Forward Deployed Engineer. You walk straight into a traditional-industry company and rewrite their workflow with AI.

Why Shenzhen? Because Shenzhen is crawling with bosses of old-school industries, and every one of them sits on a workflow built up over decades of human labor. Employees who've been there for decades have all the implicit knowledge in their heads: how to talk to clients, how to price, how the flow goes, who to call when shit breaks, what each field means, what each piece of jargon decodes to. None of it is documented. None of it lives in a system. It's all in heads, or in Excel. Their systems are mostly Excel, PDF, and Word.

AI can obviously replace this. We all believe a lot of people in these companies will be laid off in two years.

So why do those people get laid off? Because the boss suddenly learned to vibe code and built a system himself? I don't think so.

It's because one fucking person walked into the company, came in every day with a Mac, and over two or three months distilled them, sorted them out, raised efficiency, and replaced a chunk of headcount.

This is how we let this group of people earn their first real fucking money. A first bucket of gold. Not a salary. Something they made themselves.

---

So how do our people get to Shenzhen to do FDE?

We want to set up a Hatch House in Shenzhen. You'd be surprised how much office space is sitting around. Sponsors, borrowed rooms, or just renting somewhere for parties, any of it works. Pull these builders into one place, then connect them to companies. Every day they head out from the house to wherever they're embedded.

A summer might be enough.

These builders were probably students, or programmers at big tech. I believe that if they can come through and survive our 2C filter, they can do this.

If you haven't been through that filter, I don't think you can be a real FDE. The FDE working environment can be brutal: the boss might pour you tea, might want you out drinking with him, no workstation, no proper workspace, the office might be full of smoke. But that's where you have to find your first bucket of gold.

---

What these builders are actually doing is distilling the first workflow out of a company.

And we have a bold claim: this is going to be a massive wave. Because every traditional company can be distilled exactly once. After that, all the knowledge lives inside that AI system. Even if the industry keeps evolving, all the thinking, all the business knowledge ends up inside the same system. Trying to re-distill later becomes very hard.

And the bosses won't want to switch vendors. On the labor cost question, what's cheaper than a builder walking in barefoot?

Once you've done the first company, you can almost always keep going in that industry. Workflows in a given industry are roughly the same.

So HA7CH helps these bosses sell the same AI system to competitor #2 and #3. With those workflows in hand, the boss can turn his company into an AI company. Costs drop hard, competitors can't survive.

It's the same play as Raily: we can be free because we used AI to write the code, far more powerful than the older apps, so we can just give it away.

---

We're aiming for the first FDE delivery in May–June, then start pushing people through Hatch House, then horizontal replication and operations and so on.

We might pull it off. We might not. Maybe in June I realize the path doesn't work. Maybe Hatch House is a false premise. All of it might be wrong.

But what HA7CH is, we know. HA7CH is a FDE accelerator.

---

P.S. The term 'old-school bosses' in this piece doesn't refer to any specific person and isn't pejorative. Huge thanks for the opportunities Reform and Opening Up created.

## 中文

这两天好多人来问我们 HA7CH 到底是干什么的。答案很简单：HA7CH 是一个 FDE 加速器。

---

YC 帮助创始人成为公司。HA7CH 帮助人成为创始人。

YC 挑选的是已经冒尖的人，然后给他们资源。HA7CH 找的是还没冒尖的人，在校园里找，在 build in public 里找，让他们去解决真实的问题，了解真实的用户，完成真实的交付。

YC 会问：谁值得投资？HA7CH 会问：谁可以嗨起（ha7ch）？

在产品极易被复制的世界里，护城河不再是产品本身。护城河是你能聚集、ignite、一起向前走的人。

---

所以我们现在在做什么？

我们一边在运营小红书的群，群里有大概 1000 个人，非常喜欢我们 Raily 这个产品，确实做得也不错，他们每天在那里嘎嘎地提反馈。

另一方面，我们在运营一个微信的 builder 群，群里有一些喜欢 vibe coding、认知比较高的人。大家想一起做一些事情，也认同 HA7CH 的某些观点。

---

先说 Raily。很多人说希望我们收费，但我们其实并不希望收费。我们决定很快就会上线上架，然后在它最火爆的时候直接开源。

因为 Raily 其实没有多少成本，成本就是熬一些夜、一些开发。但是我们得到了什么？得到了一个用户群，得到了反馈，得到了大家的喜爱。这些东西都很重要，比那几十块钱的订阅费重要太多。

我们希望的是造势，拉更多的用户、更多的注意力到我们的产品上。这件事还有另外一个好处：如果我们想出圈、想推下一个产品，builder 群里有人有 idea，他就不用冷启动，我们可以直接把它丢到用户群里去，让真实的用户做反馈。如果喜欢，我们继续做；如果不喜欢，就丢掉，做下一个。

所以 Raily 其实就是我们的第一次 branding，Lawted 的 branding，HA7CH 的 branding。Which is fucking important.

就这样，我们希望吸引到一些志同道合的 builder。这些 builder 会有非常高超的 AI、coding 能力，他们有信念、有想法、有执行力。

这样的人适合做什么呢？适合来做 FDE。

---

FDE 其实就是 Forward Deployed Engineer，直接驻进一家传统行业公司，用 AI 把他们的工作流重写一遍。

为什么是深圳？因为深圳一抓一大把传统行业的土老板，每个老板手里都有一套跑了几十年、用人肉堆出来的工作流。员工在这里干了几十年，脑子里全是隐性的知识：客户怎么谈、价格怎么算、流程怎么走、出问题找谁、每个字段该怎么填、这是什么东西、那是什么黑话。这些东西没文档、没系统，全部都在人的脑子里，或者在 Excel 里。他们的系统大部分都是 Excel、PDF、Word 组成的。

AI 当然可以代替这些东西。我们现在所有人都相信，两年后这些公司将会裁掉很多人。

那为什么这些人会被裁掉？是因为这些土老板突然学会了 vibe coding，自己做了一个系统吗？我并不这么觉得。

我觉得是他妈的有一个人走进这家公司，每天带着一个 Mac，两三个月，帮他们蒸馏、帮他们梳理，最后提高效率，裁掉一波人。

就这样，我们可以让这批人赚到他们自己的第一笔 real fucking money。这是第一桶金，不是工资，是他自己的创造。

---

那我们的人怎么来到深圳做 FDE 呢？

我们希望在深圳搞一个 Hatch House。你知道深圳的办公室多得一批，赞助、借场地都行，我们也可以直接租一个开 party。把这些 builder 全部聚集在这里，然后帮他们去链接公司。他们每天从 house 出发，去那些公司驻场做事。

我觉得一个暑假可能就够了。

这群 builder 可能之前是学生，可能是大厂里的程序员。我相信，如果他们能进入并通过我们 2C 这一关的验证和考验，他们应该能做到。

如果你没有经过这个考验，我觉得你很难成为一个真正的 FDE。因为 FDE 的工作环境可能非常恶劣：老板可能给你倒茶，也可能要你陪酒，没有工位，没有正经的工作环境，甚至办公室里大家都在抽烟。但你就要在这里找到你的第一桶金。

---

这些 builder 真正做的事，就是把第一个工作流蒸馏出来。

我们有一个大胆的断言：这件事会是一个巨大的风口。因为每一个传统公司有且只能被蒸馏一次。再往后，所有的知识都会进入这个 AI 系统。即使这个传统行业还在迭代，所有的思考、所有的业务知识也都会进入这个 AI 系统。这样即使别人想蒸馏，也会变得非常困难。

而且土老板们也不会想切换方案。关于人力成本，还有什么比一个光脚走进来的 builder 更便宜的东西呢？

做完第一家以后，你肯定还能继续做这个行业。因为工作流在一个行业里其实大同小异。

所以 HA7CH 会帮他们把这些 AI 系统卖给同行业的第二家、第三家。有了这些工作流，土老板可以把自己的公司变成 AI 公司，成本大大降低，让竞品无法生存。

就像我们做 Raily 一样：我们能免费，是因为我们用 AI 去写代码，比之前其他的 APP 强大太多，所以我们就可以直接做到免费。

---

我们希望在 5-6 月跑出第一笔 FDE 交付，然后开始往 Hatch House 输送人，接着是后面的横向复制、运营等等。

这件事我们可能跑得出来，也可能跑不出来。也许 6 月我就发现走不通，也许 Hatch House 是个伪命题。可能都是错的。

但是 HA7CH 是什么，我们知道了。HA7CH 是 FDE 加速器。

---

P.S. 本文中「土老板」并不针对任何具体的人，也并非贬义。感谢改革开放创造的巨大机会。


---

# FDE Is The Future / FDE 才是未来

> Published 2026-05-11 · By lawted · Canonical: https://ha7ch.com/writing/fde-is-the-future

## English

A lot of people have already noticed something happening abroad. OpenAI, Anthropic, these companies aren't just selling models or APIs anymore. They started sending people into enterprises, sitting right next to the client, asking how they work each day, how their systems run, what their industry jargon means, and then using AI to rebuild those workflows from the ground up. That's FDE: Forward Deployed Engineer.

Inside China, I think there's a better name for the role: AI BP, AI Business Partner.

They're not traditional consultants. They don't hand you a PPT or a proposal. They sure as hell don't hand you some shitty SaaS account. It's one person with a laptop, on-site at the company, working through the workflow line by line with the boss and the employees, and then turning it into an AI-based solution that actually runs.

---

We live in a bubble most of the time. We assume everyone is already using AI. We assume everyone uses Claude Code, vibe codes, has AI write code, build spreadsheets, organize documents, run automations.

Walk through traditional industries in Shenzhen for a day and you'll see it's nothing like that.

A lot of bosses haven't even used DouBao. A while back I set up DouBao for a boss and he was overjoyed. To us this is a completely ordinary thing. To him it was like a door to a new world opened up, and he wanted to take us out for Moutai. The skills that are completely mundane inside the AI bubble are still rare and valuable in traditional industries.

Another time I was talking to a boss and showing him a product I'd built. He said, you can use AI to write code? I said of course, obviously, everyone uses AI to write code now. But it suddenly hit me: in his entire circle, there might not be a single person who knows how to use AI to write code. He immediately grabbed my hand and said, you have to come help us cut costs and boost efficiency.

---

Over the next two years, everyone knows a huge chunk of jobs will be replaced by AI. But how does that replacement actually happen?

Is it the bosses who haven't even touched DouBao suddenly learning to vibe code, then organizing their entire company's workflow themselves, setting up their own agents, plugging in their own APIs, deploying themselves? No way.

What actually happens is this: a young person walks into a traditional company with a MacBook Air, sits in the office, maybe sits on the floor, and one by one asks the employees. What's the first thing you do every day? Who does this Excel get sent to? What does this field mean? What does that industry term mean? Why do you copy-paste this every time? Which step of this process is the most tedious? Which is the most error-prone? Which is the hardest to handle?

They write it all down and turn it into tools using AI. Maybe it's an internal system, maybe a Chrome extension, maybe a small utility, maybe an agent, maybe an I-don't-know-what-the-fuck-is-this.

But here's the result. AI stops being a cool thing. The boss realizes that what three people used to do, one person can do now. What used to take a day takes ten minutes. What used to require a senior employee mentoring you to ramp up, a new hire can just do with AI. Stuff that used to need someone constantly nagging, AI now proactively messages on its own. That's it.

So that's what FDE actually is.

---

I think this is a huge opportunity for ordinary people. Because what traditional industries are short on isn't a stronger foundation model.

A lot of people building startups are fighting against the model itself. Every week they worry: is Claude Code going to ship some update next week that kills my whole product? But think about it. When you're doing FDE, the stronger the model gets, the stronger you get. The cheaper the model gets, the more powerful you become.

---

FDE asks a lot of you. You have to be willing to meet these bosses. You have to be willing to go on-site. You have to understand what they're saying. You can't mind the dirt, the mess, or the annoyance. Every day starts with Excel files, WeChat screenshots, emails, handwritten receipts, and you turn all of it into an AI workflow.

And you have to be fast. You just had tea with the boss this morning, you need to ship a prototype this afternoon. You just understood something today, this weekend you go heads-down and turn it into system logic.

You don't have to come from the industry. You can know absolutely nothing about it. But you have to be proactive enough to dive in and turn AI into productivity. That's FDE. That's AI BP.

---

Over the next two years, the last mile of AI deployment is going to depend on this kind of person. Carry your laptop into the room. Let companies actually spend less, make fewer mistakes, hire fewer people. That's it.

## 中文

很多人已经看到，在国外，OpenAI、Anthropic 这些公司已经不再是单纯卖模型、卖 API。他们开始派一批人到企业里面，直接坐在客户旁边，问他每天怎么工作，问他们系统怎么跑，问他们的行业黑话是什么，然后用 AI 把这些流程重新搭一遍、重构一遍，把 AI 完全地植入进去。这就是 FDE，Forward Deployed Engineer。

如果放到中国，我觉得它有一个更好的名字：AI BP，AI Business Partner。

他不是那种传统的咨询，他不给你 PPT，不给你方案。他更不是把一些什么傻逼的 SaaS 账号给你，而就是一个人带着电脑，直接到企业现场，帮老板和员工一条一条地把工作流拆出来，然后用 AI 做成能够真正跑起来的 solution。

---

其实我们经常活在一个错觉里面。我们以为所有人都已经在用 AI 了，以为所有人都会用 Claude Code、都会 vibe coding、都会让 AI 写代码、做表格、整理文档、跑自动化。

但是你只要去深圳的传统行业转一圈，你就会发现完全不是这样。

很多老板连豆包都没有用过。我前段时间给一个老板装了一个豆包，他都高兴得不行。对我们来说这可能是一个再普通不过的东西，但对他来说，直接就像打开了新世界的大门，高兴得要请我们喝茅台。所以在 AI 圈里非常稀疏平常的东西，在传统行业里依然是非常稀缺的技能。

还有一次我跟一个老板谈话，给他介绍我写的产品。他说，你会用 AI 写代码？我说当然啦，废话，现在所有人都在用 AI 写代码。但是突然我也意识到一件事：在他身边，也许连一个会用 AI 写代码的人都没有。于是他立马就握着我的手说，你一定要过来帮我们降本增效。

---

未来两年，所有人都知道有大量工作会被 AI 替代。但是这些岗位到底是怎么被替代的？

是那些连豆包都不会用的老板突然开始学习 vibe coding，然后自己把公司的工作流全部整理出来，自己搭 Agent、自己接 API、自己部署吗？不可能。

真正发生的事情一定是这样：一个年轻人背着 MacBook Air 走进一家传统公司，他坐在办公室里，可能就坐在地上，一个一个地问员工：你每天第一件事干什么？Excel 发给谁？这个字段什么意思？行业术语代表了什么？为什么你每次都要复制粘贴？这些流程里哪一个最繁杂、哪个最容易出错、哪一个最难搞？

然后他把这些东西记下来，用 AI 做成工具。可能是个内部系统，可能是一个 Chrome 插件，可能是一个小工具，可能是一个 Agent，可能是一个 I don't know what the fuck is this。

但是结果是什么？结果就是 AI 不再是一个很酷的东西。老板会发现原来三个人做的事情，现在一个人就可以做。以前一天做不完的，现在 10 分钟就可以做完。以前需要老员工手把手带着才能上手做项目的，现在新员工直接用 AI 开始做。原来需要人一直去盯着、去催的东西，现在 AI 都可以主动去发消息。That's it。

所以这就是 FDE 的本质。

---

我觉得对于普通人来说，这里有非常大的机会。因为传统行业缺的并不是一个更强的大模型。

很多人创业都在跟模型对着干，每天都要担心：下一周 Claude Code 是不是又更新一个东西把我干掉了？但是你仔细想，我们做 FDE，就是模型越强我越强，模型越便宜我越牛逼。

---

当然 FDE 的要求也很高。你要愿意认识这些老板，你要愿意走到现场，你要听得懂他们的话，你要不嫌脏、不嫌乱、不嫌烦，每天从 Excel、微信截图、邮件、手写的单据开始，然后把这些东西全部变成 AI workflow。

而且你要做得非常的快。你上午刚刚跟老板喝完茶，下午就必须要跑出一个 prototype。你今天刚刚理解了一个东西，周末就要开始狂干，然后把它写进系统的逻辑里。

你可以不是这个行业出身，甚至你可以对这个行业一无所知。但是你必须要足够主动，能够钻进去，把 AI 变成生产力。这就是 FDE，这就是 AI BP。

---

未来两年，AI 落地的最后一公里，靠的就是这种人。背着电脑走进现场，让企业真的少花钱、少犯错、少用人。That's it。


---

# Code Agent and Token Cost / Code Agent 和 Token Cost

> Published 2026-05-11 · By lawted · Canonical: https://ha7ch.com/writing/code-agent-and-token-efficiency

## English

This one runs a bit long — about ten minutes. If you're a heavy VibeCoding user or curious about how LLM billing actually works under the hood, it's worth finishing.

VibeCoding is becoming infrastructure for a lot of engineers. When you hit a rate limit or context ceiling in the middle of a long task, the quickest fix is obvious: throw $200 at a GPT Pro subscription, throw another $200 at Claude Max — problem gone.

But if we don't just buy our way around this, and instead ask the real question — where the hell do all the tokens go — aren't you curious? I sure am.

---

Let's start with billing. Most mainstream LLM APIs, including Claude and OpenAI, charge by token count, with separate rates for input and output. Input is cheaper; output costs more. In the specific context of Code Agents, input tokens are the overwhelming majority — often over 80% of total consumption.

Some providers offer a KV Cache Discount: when the server detects that the input prefix of a new request heavily overlaps with a previous one, the overlapping portion hits the cache and gets a significant discount. The mechanism makes physical sense — it avoids redundant attention computation.

This will become a plot point. We'll come back to it.

---

Most Code Agents today, including Claude Code, still run on the classic ReAct framework. The original ReAct paper is over three years old. Its core loop: the model produces a Tool Call, receives an Observation, reasons through a CoT, then produces the next Tool Call.

It was an elegant design when it was proposed. But over the past three years, the agent research community has produced a lot of optimization paradigms — Plan Before Act, Hierarchical Planning, Task Decomposition with Memory… Code Agents have adopted basically none of them.

The arrogance isn't entirely unjustified — engineering stability will always outrank academic novelty at the product level. But that doesn't mean we can't look at the cost.

The cost lands on token consumption, and ultimately on the user. The worst offender is context management. The only way to describe it is: A Piece of SHIT.

Each loop iteration, the Agent appends the full user Query, the current Tool Call, the Observation, and the model's own CoT into the Context — then feeds the entire thing back unchanged on the next round. Under this model, Context grows quadratically, and most of it becomes historical noise that's nearly useless for whatever the model is actually trying to do right now.

When Context approaches the model's limit, Claude Code triggers Auto Compact — an interesting mechanism in itself. It's not a semantic summarization pass; it's a rule-based structural pruning at the linguistic level. Codex takes a blunter approach and just terminates the session.

Claude's context window is around 200K tokens. That sounds large until you've done a few dozen tool calls on any reasonably-sized codebase — then it's gone fast.

---

Solutions to this problem fall into two camps: Harness Level and Model Level.

Harness Level means engineering the Agent's runtime framework without touching the model itself. Two main approaches:

First, fine-grained Context management — actively filtering and compressing historical information, keeping only what's genuinely relevant to the current task. Compressing Observations is the primary lever.

Second, introducing a Plan Before Code paradigm — having the Agent complete an explicit planning pass before execution, reducing aimless exploratory Tool Calls and cutting token consumption by reducing loop iterations.

Papers along these lines have been coming out for about a year. The arrogant CC has shown zero interest. From an engineering standpoint, adding structural complexity always introduces potential side effects.

The standard academic benchmark for validating these methods is SWE-Bench. Hit good numbers there and you can publish. But SWE-Bench is fundamentally a closed evaluation with deterministic answers. Most real Code Agent usage is open-ended exploration — unfamiliar codebases, undefined requirements — far beyond what SWE-Bench covers. Academic proof doesn't translate cleanly to actual user experience.

Model Level is an entirely different angle: keep the Agent code unchanged, but use a better model. If it can solve your problem in 3 loops instead of 15, token consumption drops on its own.

The most striking news on this front came from DeepSeek. DeepSeek V4's API pricing is near-disruptive — after two rounds of discounts, it lands at roughly one-tenth of the baseline price. At that level, almost no token compression technique can match the savings, because you can't algorithmically optimize your way to a 1000% efficiency gain.

What's even more counterintuitive: because of KV Cache Discounts, some optimization approaches that reduce raw token count actually end up costing more — because restructuring the input breaks the cache hit pattern. Counterintuitive, but completely logical once you understand the billing mechanics.

---

Worth noting: some Claude Code developers are pretty dismissive of Harness Level approaches. They don't want to introduce complex context management at the harness layer. Their position is that whatever CC can't solve today, the next model will handle.

Maybe that's principled engineering conservatism. Maybe it's passing the buck.

There's another take: on a long enough timeline, obsessing over token counts is just a phase. A mentor of mine compared tokens to mobile data — we might be in the 3G era right now. When 5G arrives, nobody cares how much data a single request burns.

That analogy has some weight. Compute costs will keep falling. Context windows will keep growing — a 1M context window isn't unthinkable. What feels like a bottleneck today might genuinely be a historical footnote in the transition period.

---

My own take: I'm open on this field, but I lean Model Level right now. Partly hindsight — Harness Level approaches have been around for a year and none of them have made it into production at scale, which tells you something. Partly distribution — if Model Level solves the problem, it'll spread like DeepSeek did. People running low on tokens will find the better API on their own.

And from a vendor's perspective: token cost is temporary. Time and compute are forever.

If you have a take or a solution, reach out — happy to talk.

## 中文

这篇文章略长，大概需要十分钟。如果你是 VibeCoding 的重度用户，或者对 LLM 的计费机制感兴趣，值得读完。

VibeCoding 正在成为很多工程师日常开发的基础设施。当你在某次长任务中撞上了 rate limit 或者 context 上限的时候，最直接的解决办法当然是给 GPT 充一个 200 刀的 Pro、给 Claude 充一个 200 刀 Max——问题立刻消失。

但如果我们不从财力上绕开这个问题，而是从原理上真正问一句「token 到底去哪了」，你难道不好奇吗？反正我是很好奇。

---

先说计费机制。目前主流的 LLM API，包括 Claude 和 OpenAI，都按 token 数量计费，区分输入和输出。输入会便宜一点，输出会贵一些。在 Code Agent 这个具体的情景之下，Input 的 token 消耗占绝对大头，甚至达到 80% 以上。

部分厂家的 API 会提供一种 KV Cache Discount：当 Server 端检测到本次请求的输入前缀与历史请求高度重叠时，重叠部分的计算可以命中缓存，因此给出相当幅度的折扣。这个机制设计得很合理，背后的物理含义是避免了重复的注意力计算。

这个机制会成为伏笔，我们接下来会讲到。

---

当前绝大多数 Code Agent，包括 Claude Code，依旧运行在经典的 ReAct 框架上。ReAct 最早的论文距今已有三年多，其核心循环是：模型产生一个 Tool Call，收到 Observation，结合 CoT 思考下一步，再产生下一个 Tool Call。

这个框架在它提出的年代是相当优雅的设计。但三年以来，Agent 领域涌现出了大量优化范式——Plan Before Act、Hierarchical Planning、Task Decomposition with Memory……Code Agent 几乎一个都没有采用。

傲慢并非没有理由，毕竟工程稳定性的优先级在产品层面永远高于学术新颖性，但这不妨碍我们审视其代价。

代价落在 token 消耗上，最终落在消费者身上。Token 消耗的重灾区是上下文管理，这里只能用「A Piece of SHIT」来形容。

每一轮循环，Agent 会把当前的用户 Query、本轮的 Tool Call、Observation、以及模型自身的 CoT 全量追加进 Context，然后在下一轮把整个 Context 原封不动地喂回给模型。这种模式下，Context 以二次方速度膨胀，且大量内容是对模型当前任务几乎不再有用的历史噪声。

当 Context 逼近模型的上限时，Claude Code 会触发 Auto Compact——这个机制本身也颇有意思，它并非调用一次模型做语义层面的摘要压缩，而是从语言学结构角度做规则性的删减；Codex 则更为简单粗暴，直接终止本次对话。

Claude 的 Context 窗口大约在 200K token 量级，这个数字听起来很大，但在一个稍有规模的代码库上执行几十轮工具调用之后，很快就会见底。

---

目前针对这个问题的解决思路大致分两派：Harness Level 和 Model Level。

Harness Level 的核心是在不修改模型本身的前提下，对 Agent 的运行框架做工程改造。核心思路有两条：

一是精细化管理 Context，主动过滤和压缩历史信息，只保留对当前任务真正有价值的内容，以压缩 Observation 的思路为主力军；

二是引入 Plan Before Code 的范式，让 Agent 在实际执行之前先完成一次显式的任务规划，从而减少无效的探索性 Tool Call，从减少循环次数来减少 token。

这类论文已经陆续发表了约一年，傲慢的 CC 依旧没有任何反应。因为从工程实践角度来说，让结构变复杂必然带来潜在的 Side Effect。

学界验证这类方法的标准工具是 SWE-Bench，跑下来指标漂亮的话足以发表，但 SWE-Bench 本质上是一个有确定性答案的封闭评测。大多数人使用 Code Agent 的场景是开放性探索——面对一个陌生的代码库、一个未定义的需求——这类场景的复杂度远超 SWE-Bench 所能覆盖的边界，学界的证明因此很难直接转化为对用户实际体验的保证。

Model Level 则是一个视角完全不同的方向：构建 Agent 的代码保持不变，调用的模型更牛逼了，3 轮循环就能把你问题解决了，token 消耗自然下来了。

这个方向最牛逼的新闻来源于 DeepSeek。DeepSeek V4 的 API 定价策略是近乎颠覆性的——两轮打折后折扣力度达到了基准价格的一折。在这个价格体系下，几乎没有任何一种 token 压缩方法能够产生与之匹配的效益，因为你无法通过算法优化做到 1000% 的效率提升。

更吊诡的是，由于 KV Cache Discount 的存在，某些优化方案在减少了 token 消耗的同时，却因为改变了输入结构导致缓存命中率下降，实际扣费不减反增。这是一个反直觉的结果，但从计费机制的逻辑来看完全合理。

---

值得一提的是，Claude Code 的部分开发者对 Harness Level 的改造方案持相对消极的态度，不太倾向于在 Harness Level 引入复杂的上下文管理逻辑。他们的观点认为，现在 CC 解决不了的问题，等新模型出来之后就能解决了。

这或许是出于工程保守主义的考量，但也可能是在为自己的工作甩锅。

还有一种观点认为，从更长的时间轴来看，现在对 token 斤斤计较这件事本身就是阶段性的。我的一位导师曾把 token 比作流量：我们现在可能处于 3G 时代，当 5G 到来的时候，无人在意一次请求消耗了多少流量。

这个比喻有它的说服力。计算成本的下降是可以预期的，模型的 Context Window 也在持续提升（比如可能会实现的 1M 上下文），今天被视为瓶颈的问题，未来或许真的只是一个过渡期的历史注脚。

---

本人对这个 Field 持开放态度，目前来说站 Model Level。一个是马后炮唯结果论的原因，Harness Level 的方法现在工业界一个都没有用上，那总有它的原因在。还有一个是推广度上的看法，如果从 Model Level 解决了问题那么就会像这次 DeepSeek 一样，无需过多推广，缺 token 的人自然会使用你的 API。

更何况从厂商的角度来说，token 的减耗是暂时的，时间和算力的减耗是永远的。

任何观点和方法都可以联系我们进行探讨。


---

# Attention is All You Need

> Published 2026-05-11 · By lawted · Canonical: https://ha7ch.com/writing/attention-is-all-you-need

## English

I think the era of programming we-media has arrived.

In the past, when we wanted to do a project, it would take a lot of time. Design, develop, test, publish — the whole process needed a few months, or even a fucking year. But right now, you can do it in a real quick vibe-coding session, and ship an MVP within a couple hours.

It's like writing a book. In the past, when you wanted to publish an idea, you had to choose the topic, do the editing, proofread, print, distribute. It took a long time. But right now you can publish in a real quick. Just post your idea on Twitter. A couple seconds.

And at this moment, the most important thing changes. Just like I said — we are entering the we-media era.

Attention is all you need.

Imagine you make a great movie. You go through all the processes, you spend a lot of time, and finally people can see it in the cinema. But there is fucking no one. Meanwhile some random livestream is on, and a bunch of people are watching, dropping comments, even sending gifts.

But a lot of people, when they're starting a business, are still thinking: I don't need to find users first. Promotion is not that important. I just need to build the stuff, build the workflow, and use that to find a VC, get the money. Then I'll use that pile of money to do promotion afterwards.

Honestly, I was trapped in this exact idea last year. But I figured out it's fucking wrong. Because this era has already passed.

You could do this two years ago. You can't do it now.

Why? Because two years ago everybody was caring about the concept. AI was pretty new. So you'd say, "Okay, we'll do an AI browser. We'll do AI plus fucking medicine, AI plus fucking health." AI plus this, AI plus that — you'd quickly raise a seed round. Then the seed-stage guy would tell you how to wrap this fucking idea to help you raise a Series A, so he could exit and make money.

That was the old logic. Right now this logic has been turned upside down.

Investors right now are very grounded. If you don't have ARR, no traction, they won't give you any fucking money.

What you need to do now — if you're going toC, it has to be something genuinely useful. Otherwise, you might as well come back to toB.

By the way, I really like the FDE role. In China it's called AIBP, in the US it's called FDE. I'm doing FDE in Shenzhen right now. I'll talk about this with everyone in the next post.

Now back to normal people. I've talked a lot in previous essays about how you should just build an MVP and throw it on social media to test if anyone is interested. If you get a user, keep going. Don't build a fucking heavy code shit on day one.

For normal people — code is pretty cheap right now. You can just vibe-code something. Don't go build some workflow or some complicated system on day one.

First, it might not be what people want.

Second, it's gonna make you start really fucking slow. You'll spend a lot of time thinking about how the workflow should be built. You might even be afraid of building something that big.

For normal people, the most important thing is how fast you can start. Can you ship it this afternoon? Can you ship it before you go to sleep tonight? That's what determines how fast your product can land in front of users, and how fast it can catch their attention.

## 中文

我觉得编程自媒体时代已经到来了。

原来我们做一个项目，需要花很长时间。设计、开发、测试、再发布，整个流程跑下来动辄几个月，甚至几年。但是现在，你可以做得非常快。Vibe coding 一下，几个小时就是一个 MVP。

这有点像写书。原来你写一本书，需要发版、需要选题、约稿、编辑、校对、印刷、发行，一两年是一个常态。但是现在你可以发布得非常的快，公众号、博客、推特，写完就发，几秒钟就完事了。

在这种时候，最重要的事情就变了。它就像自媒体一样，最重要的是要找到你的用户。

Attention is all you need.

就像你拍了一个很好的电影，走过了所有流程，花了很长时间，终于他妈的大家可以在电影院里面看到了。结果你发现，没有人看你的电影。反而小杨哥的直播间非常的土，但却有一群人在看。

但是很多人创业的时候还是会想：我先不需要找用户，推广不重要。我先把东西搭出来，先把工作流搭出来，然后再通过这套东西去找投资人，找完投资人拿到钱，拿了钱以后再去做推广。

我去年其实也是这个想法。后来发现，这个想法大错特错。因为这个时代已经过去了。

两年前你可以这么做，但是现在你不能。

为什么？因为前两年大家都在炒概念，AI 很新。你可以先说，「哎，我要做一个 AI browser，我要做一个 AI 加他妈的医疗，AI 加什么健康」，AI 加什么、AI 加什么，你都能很快融到种子轮。然后种子轮的人会告诉你如何继续包装这个概念，帮他融到 A 轮，让种子轮的人能从中赚钱退出。

这是原来的逻辑。但是现在，逻辑已经发生了翻天覆地的变化。

现在的投资人已经非常务实了。你没有 ARR、没有 traction，他基本上不会给你一分钱。

现在大家需要做的，如果是 toC，那就要做一些真正有用的东西。不然的话，不如回到 toB 上面来。

By the way，我现在一直很看好 FDE 这个角色。在中国叫 AIBP，在美国叫 FDE。我自己在深圳就在做 FDE。下一篇文章有机会再和大家讲一讲这个内容。

那回到普通人。我前面几篇文章其实已经说过了，你应该先把东西做一个 MVP，然后丢到社交媒体上，看有没有人感兴趣。有用户用了，你再继续做。而不是一上来就背一堆代码债。

对于普通人而言，现在 code 这么便宜，你自己 vibe coding 写一些东西就好，不要一上来就搭什么工作流、什么复杂的系统。

第一，它不一定是大家想要的。

第二，这样会让你启动得非常慢。你会花一堆时间去想这个工作流应该怎么搭，甚至你会害怕做一个那么大的东西。

对一个普通人而言，最重要的就是你能多快启动。今天下午能不能 ship 出去？睡觉之前能不能 ship 出去？这件事情决定了你的产品能多快到用户面前，多快抓住他们的注意力。


---

# Two Pairs of Eyes / 两双眼睛

> Published 2026-05-10 · By lawted · Canonical: https://ha7ch.com/writing/poetry-and-the-plaza

## English

I've been thinking a lot about San Francisco and Silicon Valley lately.

More specifically, I've been thinking about why these two places, only forty minutes apart by car, feel like two different countries.

Silicon Valley is not a city. It's a suburb. Plaza after plaza, neighborhood after neighborhood, corporate park after corporate park. Every town has a so-called downtown, but compared to SF, those downtowns are basically just one block.

But geography is just the surface. The real difference is the gaze.

When you live in Silicon Valley, you can always feel someone watching you.

But honestly, those people aren't actually watching you. The truth of American life is that you spend more time alone than you think. The gaze you can feel — almost all the time — is yourself watching yourself.

It's just that the eyes you're watching yourself with were installed by the place you live. Once they're installed, you can't take them off. Even in an empty room, on an empty highway, at 2am with nobody around, those eyes are still open.

Silicon Valley installs a pair of eyes with very clear markings on them. They keep asking you: did you get the promotion? What's your company's valuation? Which school district did your kid get into? These questions all have clear answers. You can answer them at any moment, and at any moment you know exactly where you stand.

These markings are double-edged. On one hand, they slowly grind you into the shape they measure. You end up becoming a person mostly defined by these numbers.

On the other hand, a person without any markings also has a hard time pushing anything to its limit. I know this take isn't popular, but I think it's correct.

Caring about whether those eyes are scoring you and caring about whether you've actually done a good job are the same internal structure. A person who genuinely doesn't care what anyone thinks usually doesn't write code with tests, doesn't ship a product polished enough for a thousand strangers to use, doesn't sustain a thirty-year career arc. Patience, rigor, finishing — these are qualities that come more naturally to people who have an audience. Even if the audience is only imagined.

Silicon Valley is Silicon Valley because those eyes have, over decades, produced the world's best engineers, the most ruthless product standards, the longest patience. They kill creativity. But they also feed excellence. It's the same thing turning into different things at different stages of your life. Invention needs those eyes closed. Building needs them open.

I think this is similar to what happens in Asia. Asia installs the same kind of eyes — invisible, internalized, always there. They eat freedom, but they also build the kind of order that lets generations live stable lives. It's not a question of good or bad. It's a question of whether you need them right now.

San Francisco has its own gaze too. I don't want to write SF as a city without a gaze, because it isn't.

But the eyes SF installs are different.

The Silicon Valley eyes ask you: do they see you?

The SF eyes ask you: do you see yourself?

The first question has an answer. The second one doesn't.

The answer to the first is on your paycheck, your LinkedIn, your kid's acceptance letter. The answer to the second is something only you can faintly feel at 3am, alone, and very often you can't feel it at all.

So SF isn't actually a lighter city. It just changes the direction of the work. It swaps the work of being seen for the work of seeing yourself. The first has KPIs. The second doesn't. The first you can perform. The second you can't. When you do the first one right, people clap. When you do the second one right, nobody knows.

A lot of people think moving to SF lets them escape the gaze. It doesn't. They just move from one gaze to another. And many of them quietly bring the SV ruler with them — they live an SF life but score themselves with an SV scorecard, and end up paying both costs.

That said, the SF gaze is genuinely thinner, because from the very beginning this city was a refuge for weird people. Gold rushers, missionaries, drifters, poets, coders, people who didn't want to get married, people who didn't want kids, people who didn't want to wear normal clothes, people who didn't want to do normal jobs. They all found their corner here.

The architecture says the same thing. It's not telling you the city is beautiful. It's telling you: you don't need to be normal to live well.

Silicon Valley's architecture speaks a different language. Low, flat, clean, white, beige, lawns always trimmed, Teslas always parked. These buildings don't tell you anything. They just wait for you to fit them. That kind of fitting isn't romantic, but it has an underrated kind of good. A house that doesn't demand anything of you is, for someone who has been demanded of all day, its own kind of rest. It doesn't ask you to be interesting. It doesn't ask you to be edgy. It doesn't ask you to prove anything. You can be tired. You can be bored. You can stare into space. You can spend three hours being nobody at all. The beige and the lawn don't ask you whether you spent the day living meaningfully enough.

AI brought the young people back to SoMa, to Hayes Valley, to the Mission. Twenty-somethings, not married, no kids, no Tesla, renting a studio, or sleeping on a friend's air mattress, writing code in a cafe until 2am. They're building things that might change the world, or might pivot in two weeks.

Silicon Valley is mostly houses. SF is mostly apartments, condos, townhouses. I think there's something interesting hiding behind that.

When you live in a house, your connections point inward. You have a family, a backyard, a dinner time. The relationships that matter most to you are already inside these walls. You don't need to go looking. And your thoughts stop changing that easily.

When you live in a studio, your connections point outward. The apartment is too small to want to stay inside, so you go out — to cafes, to coworking, to random meetups, to meet people you've never met. You don't know where your next idea will come from, but you know it won't come from inside your 120 square feet.

Both are connection, just in different directions. One tends to what's already there. The other keeps reaching outward. That's probably also why people in SF change their minds more easily.

And eventually I figured it out: these two places really represent two states a person can be in at different stages of life.

Silicon Valley is for people who already know where they're going. Their lives are meant to be optimized.

SF is for people who haven't figured out where they're going. Their lives are not meant to be optimized. They're meant to be invented.

That's the difference between poetry and the grind. But the grind isn't bad. The grind is taking the ruler somebody else wrote and being as good as possible on that ruler. Poetry is throwing that ruler away and trying to find one nobody has made yet.

Most people will probably need both at some point. First use someone else's ruler to lay a foundation, then throw it away and look for your own. Or the other way around — wander around with your own ruler for a while, then accept the more mainstream one and grind it into your own. The question isn't which one is higher. The question is which stage you're in right now, and whether you're being honest with yourself about it.

Honestly, every time I drive north out of Silicon Valley, past Daly City, and the SF skyline emerges from the fog, I feel myself exhale.

## 中文

我最近一直在想旧金山和硅谷的事。

更准确地说，我在想为什么这两个地方开车只要四十分钟，但它们给人的感觉差得像两个国家。

硅谷其实根本不是一座城市。它是一片郊区。一个又一个 plaza，一个又一个住宅区，一个又一个公司园区。每个城市都有一个所谓的 downtown，但是放到旧金山来看，那个 downtown 也就只能算一个街区。

但地理只是表面。真正不一样的是凝视。

你住在硅谷的时候，你总是能感到有人在看你。

但说实话，那些人其实并没有真的在看你。美国生活的真相是，你独处的时间比你以为的多。你能感觉到的那种凝视，绝大多数时候是你自己在凝视你自己。

只是这双眼睛是你住的这个地方装上去的。它装好以后，就再也卸不下来了。哪怕在没有人的房间里、没有人的高速上、没有人的凌晨两点，那双眼睛也还是开着的。

硅谷给你装的，是一双有非常清晰刻度的眼睛。它会一直问你：你 title 升了吗？你公司估值多少？你小孩进了哪个学区？这些问题都有清楚的答案。你随时可以回答，也随时知道自己在哪一档。

这种刻度是双刃的。一方面，它会慢慢把一个人磨成它所测量的形状。你最后变成了一个主要由这些指标定义的人。

但另一方面，一个永远没有刻度的人，也很难把一件事做到极致。我知道这个观点不讨喜，但我越来越觉得它是对的。

在意自己有没有被这双眼睛打分，和在意自己有没有把事情做好，其实是同一种内在结构。一个完全不在意外界目光的人，往往也写不出有 test 的代码、做不出能给一千个陌生人用的产品、坚持不了一个三十年的事业曲线。耐心、严谨、收尾——这些都是有「观众」的人才容易具备的品质。哪怕那个观众只是想象中的。

硅谷之所以是硅谷，正是因为这双眼睛在过去几十年里逼出了世界上最厉害的一批工程师、最严格的产品标准、最长期的耐心。它杀创造力，但它也喂养卓越。这是同一个东西在你不同阶段会变成不同的东西。发明需要这双眼睛闭上，建造需要这双眼睛睁开。

我觉得这其实和亚洲很像。亚洲装上的也是这样一双眼睛，无形的、内化的、永远在那里。它消耗自由，但它也建造了让一代一代人能稳定生活的秩序。这不是一个好坏的问题，是一个你现在需不需要它的问题。

旧金山也有自己的凝视。我不想把旧金山写成一座没有凝视的城市，因为它不是。

但旧金山给你装的眼睛不一样。

硅谷的眼睛问的是：他们看见你了吗？

旧金山的眼睛问的是：你看见你自己了吗？

第一个问题有答案。第二个问题没有。

第一个问题的答案在你的工资条上、你的 LinkedIn 上、你小孩的录取通知书上。第二个问题的答案，只有你一个人在凌晨三点的时候能隐约感觉到，而且经常感觉不到。

所以旧金山其实并不是一座更轻松的城市，它只是把工作的方向换了。它把「被世界看见」的工作，换成了「看见自己」的工作。前者有 KPI，后者没有。前者可以表演，后者表演不了。前者你做对了别人会鼓掌，后者你做对了没人知道。

很多人以为搬来旧金山就能从凝视里逃出来。其实不能。他们只是从一种凝视搬到了另一种凝视。而且很多人最后会偷偷把硅谷那把尺子带过来——他们用旧金山的方式过日子，但用硅谷的标准给自己打分，结果是两边的代价都付了。

但即便如此，旧金山的凝视确实更稀薄一些，因为这座城市从一开始就是各种奇怪的人的避难所。淘金的、传教的、流浪的、写诗的、写代码的、不想结婚的、不想要小孩的、不想穿正常衣服的、不想做正常工作的人，都在这里找到了他们的角落。

旧金山的建筑也是这样。它不是在告诉你这座城市多漂亮，它是在告诉你：你不需要正常才能过得好。

而硅谷的建筑说的是另一种语言。低矮的、平的、整洁的、白的、米色的、永远在修剪的草坪，永远停着的 Tesla。这些建筑不会告诉你任何事情，它们只是在等你去配合它们。这种配合不浪漫，但它有一种被低估的好。一栋不要求你的房子，对一个白天一直被要求的人来说，本身就是一种喘息。它不要求你 interesting，不要求你 edgy，不要求你证明什么。你可以疲惫，可以无聊，可以发呆，可以一连好几个小时什么都不是。米色和草坪不会问你今天有没有更有意义地活着。

AI 又把年轻人带回了 SoMa，带回了 Hayes Valley，带回了 Mission。他们二十几岁，没结婚，没小孩，不开 Tesla，租一个 studio，或者睡在朋友的 air mattress 上，每天在 cafe 里写代码到凌晨。他们在做一些可能会改变世界，也可能两个礼拜就 pivot 掉的产品。

硅谷大部分是 house，旧金山大部分是 apartment、condo、townhouse。我觉得这背后藏着一件挺有意思的事。

住在 house 里，你的连接是向内的。你有一个家庭，一个院子，一个晚饭时间。你最重要的关系都已经在这堵墙里面了，你不太需要往外找。你的想法也就不那么容易被改变。

住在 studio 里，你的连接是向外的。你的房子小到你不愿意一直待在里面，所以你会出门，去 cafe，去 coworking，去随便一个 meetup，去认识完全不认识的人。你不知道你下一个想法会从谁那里来，但你知道它一定不会从你这一百二十平方英尺的墙里冒出来。

两种都是连接，但方向不一样。一种是在养护已经有的关系，一种是在不断地往外伸触手。这大概也是为什么旧金山的人想法更容易变。

我后来想明白了，这两个地方其实代表了一个人在不同阶段的两种状态。

硅谷是已经知道自己要去哪儿的人住的。他们的人生是要被持续优化的。

旧金山是还没想好自己要去哪儿的人住的。他们的人生不是要被优化的，是要被发明的。

诗和苟且其实就这一点区别。但苟且不是不好。苟且是你拿着别人写好的尺子，然后在那把尺子上把日子过到最好。诗是你扔掉那把尺子，自己去找一把还没人造出来的。

一个人这一辈子，大概率两种都需要。先用别人的尺子把基础打牢，再扔掉它去找自己的。或者反过来，先用自己的尺子瞎走一段，最后接受那把更主流的尺子，把它打磨成自己的。问题不是哪个更高级，问题是你现在在哪个阶段，以及你有没有诚实地知道自己在哪个阶段。

说到底，每次开车从硅谷北上，过了 Daly City，旧金山的天际线在雾里浮出来的那一瞬间，我都会松一口气。


---

# MVP as Research

> Published 2026-05-09 · By lawted · Canonical: https://ha7ch.com/writing/mvp-as-research

## English

In the AI era, how should we ship a product?

Traditionally, when we want to build something, we start with user research. Then we write the requirements, draft the idea, do the design, develop it, test it, and finally release it. That was how big tech worked. And it made sense at that time, because the cost of development was high. If a product direction was wrong, the cost was serious. You couldn't really afford to be wrong.

But now I increasingly feel that for normal people, especially people who can use Claude Code and do vibe coding, this process is just too slow. At least fifty times too slow.

So what is the better way? I think it is: MVP as research.

Don't think too much at the beginning. Just build the thing you want to build. Build the ugliest version. Or build a version where you can at least look at it and say, "Okay, I understand what this thing is."

Because if you want to build it, that already means it is attractive to you. You want to use it, or you believe it might be useful. That is enough. Just build it.

Some of my friends always say, "What if I build this thing and someone has already done it?" Or, "What if I build this and someone comes after me? What if I get into legal trouble?"

And I usually say: after you build it, if someone really comes after you, then hire the best lawyer and fight the case. But if you don't even have the money to hire the best lawyer, why would they come after you in the first place?

A lot of the time, we are not blocked by reality. We are blocked by tiny-probability events inside our own head.

For example, I built Raily Friend in maybe two hours. I built CV.PRO in three or four hours. Raily took a little longer because it is an app, maybe a few days. But even so, compared with the traditional product development process, this speed is fucking insane.

I saw one data point before: Flighty spent about two years in beta, from 2019 to 2021. And I basically replicated the core feeling of it in around twenty days. This is AI coding. This is the AI era.

So I think the new process should not be: research first, then development. It should be: develop first, then use the launch itself as research. That is MVP as research.

You build the thing first, then post it on WeChat Moments. Because people in your Moments know you. They have some relationship with you. Many of them live in a similar environment, share similar interests, or have a similar mindset. So when you publish it, someone will jump out.

Some people will say, "This is wrong." Some people will say, "This is pretty good." Some people will give you suggestions. Some people will directly say, "Fuck it, I want to use this." Anyway, all of these are signals.

And the most important thing is: if you do user research first, you don't even know who you should research with. You don't know which motherfucker in your Moments is actually interested in your thing. But when you drop a real product out there, the interested people naturally come out.

At that moment, you can pull them in. Let them become your early users. Let them give you advice. Let them analyze it. Let them talk shit about it. Let them tell you why it sucks. That is much better than sitting there and imagining user needs by yourself.

And another thing I think is very important: don't make the product too perfect at the beginning. I know a lot of people talk about this, but I mean it in a very practical way.

You can build the product to 40 points, then package it like it is 60 points. If someone uses it, if someone complains about it, then you can hire another person, or hire an agent, or invest more time and money to push it to 80 points.

I once built a tool that could import my school timetable into iCloud Calendar. At the beginning, it was extremely simple. You had to run it with Python. That means if you didn't know Python, you basically couldn't use it. It was just a CLI.

But somehow, a few people were actually using it. And even more surprisingly, someone submitted a PR. That was the signal.

So I kept going. I reverse-engineered the school login system so students could log in directly with their student account and password. Then I posted it on the school forum. After that, hundreds, even thousands of students started using it.

So my understanding is simple: you should first drop the food on the ground and see if anyone eats it. If someone is willing to eat it even when it is on the ground, then you can give them a plate.

## 中文

在 AI 的时代，我们到底应该怎么去 ship 一个 product？

传统来说，我们做一个产品，可能会先做用户调研，然后写需求，做设计，开发，测试，最后再发布。以前大厂里面都是这么干的。因为当时开发成本很高，一个产品如果做错了，代价会很严重。

但是我现在越来越觉得，对于普通人来说，尤其是对于会用 Claude Code、会 vibe coding 的人来说，这套流程实在是太慢了。至少慢了五十倍。

现在更好的方式是什么？我觉得是：MVP as research。

你不要一开始想太多。你直接先把你想做的东西做出来。做一个最简陋的版本，或者说，做一个你自己觉得「OK，我能看懂这是什么」的版本。

因为只要你想做这个东西，就至少说明它对你自己是有吸引力的。你想用，或者你觉得它可能有用。那就够了。先把它做出来。

我有些朋友经常会说，哎，那如果我做了这个东西，别人是不是已经做过了？如果我做了这个东西，会不会有什么影响？会不会有人过来找我麻烦？

我一般就说，你等你做出来以后，他真的过来找你麻烦了，你再请最好的律师去跟他打官司不就完了吗？那如果你连请最好的律师的钱都没有，人家为什么要过来找你麻烦呢？

很多时候，我们根本不是被现实拦住了，而是被脑子里那些极小概率的事情拦住了。

比如我之前做 Raily Friend，可能就花了两个小时。做 CV.PRO，也就三四个小时。Raily 时间稍微长一点，因为它是一个 App，可能花了几天。但即使这样，这个速度跟传统产品开发比起来，还是快得离谱。

我之前还看到一个数据，Flighty 的 beta 阶段做了两年，从 2019 年做到 2021 年。

所以我现在觉得，新的流程不应该是：先调研，再开发。而应该是：先开发，再用发布本身来做调研。也就是 MVP as research。

你先把东西做出来，然后发朋友圈。朋友圈里面的人是认识你的，跟你有关系，很多人的生活环境、兴趣、认知结构也跟你比较接近。这个时候你发出来，就会有人跳出来。

有的人会说，你这个做得不对。有的人会说，你这个挺好。有的人会给你提建议。有的人会直接说，我想用。Anyway，这些都是信号。

而且很关键的一点是，如果你一开始就去做用户调研，你根本不知道应该调研谁。你也不知道你朋友圈里面到底谁会对这个东西感兴趣。但是当你把一个真实的产品丢出去以后，感兴趣的人自然会冒出来。

这个时候你就可以把他们拉进来，让他们成为你的早期用户，让他们帮你提意见，帮你分析，帮你骂你。这比你自己坐在那里幻想用户需求啥都不做要好。

还有一点我觉得挺重要的：一开始千万不要把产品做得太完美。

有的时候，你需要先把产品做到 40 分，然后把它包装成 60 分。如果真的有人用，有人骂，有人给你提 PR，那你再去招一个人，或者拉一个 agent 进来，把它做到 80 分。

比如我之前做过一个学校课表导入 iCloud 日历的工具。一开始那个东西非常简陋，甚至必须要用 Python 跑。也就是说，如果你不懂 Python，你根本用不了，因为它就是一个 CLI。

但这玩意儿还真的有几个人在用，而且竟然还有人给我提 PR。

所以我就开始继续往下做。我去逆向了学校的登录系统，让大家可以直接用账号密码登录，然后再把它发到学校论坛里面去宣传。后来，几百个人，甚至上千个人都开始用这个东西。

所以我现在的理解是：你应该先把食物丢在地上，看有没有人吃。如果丢在地上都有人吃，那你再给他安排一个盘子。


---

# Powerball Effect

> Published 2026-05-08 · By lawted · Canonical: https://ha7ch.com/writing/powerball-effect

## English

Recently, I found this new thing. Maybe just tonight. I'm planning to call it the Powerball Effect. Yeah, fuck it. I named it.

It's not that Powerball really makes you a fucking rich person. It means that before you get the result, you briefly live in a totally different world.

I first felt this last Christmas, when I was on the way to Sequoia Park with my friend Jin. That day, the Powerball jackpot was something like $1.7 billion. So when we passed by a gas station, we just bought two tickets. And after buying those tickets, the world was fucking different.

We started seriously talking about what if we actually won. At that time, I was visiting the U.S. with my B1/B2 visa, so I started thinking, if I really won this thing, how am I gonna take the money? Would the IRS tax me? Do I need a lawyer? Do I need to set up a trust? Should I not go back to China first?

And my friend Jin was even more insane. He said, if you really win, maybe you won't be able to walk out of the hotel alive. I said, what? And he said, because if the winning ticket is yours, he might just take the ticket, drive the car away, and I will never see him again in my whole life. That was fucking crazy. We were laughing so hard in the car.

Then later, when we got back to the hotel, I said I was going to take a shower. Jin said, don't you need to wait until 9? Because the result was coming out at 9. What he meant was, if the result came out while I was showering, and the winning ticket was mine, then maybe by the time I came back from the bathroom, the ticket would already be gone. And maybe he would be gone too. That was fucking stupid, but we were really high.

And the craziest thing is, in the end, my ticket actually got three numbers right. Of course, I didn't win the $1.7 billion. But during those few hours, we had already lived a $1.7 billion life.

That's what I mean by the Powerball Effect. It's not about actually winning. It's about holding a ticket that might change your life, and before the result comes out, you start seriously imagining another version of your life.

And I found that startups are kind of the same thing. Recently, I've been building Raily, an app that feels like Flighty for rail. I posted something on RedNote and did some small promotions. At first, I didn't really think it would become anything.

But then tonight, around 1 or 2 a.m., I suddenly found that some people actually liked this thing. Maybe just four or five people. But my feeling was: Oh my God, that's fucking a lot. Finally, someone saw me.

So I posted another video. A couple hours later, about 70 people had joined the group. They wanted to try the app. The video had around 2,000 views, which means every 10 or 20 people, someone wanted to join the group and try this thing. And at that moment, I entered the Powerball Effect.

I started thinking: What if this really works? What if Raily really becomes the Flighty for rail? Flighty is for airplanes, and it can do millions in ARR. What about rail? There are so fucking many people taking trains every day. China, Europe, Japan, the UK, Amtrak, commuters, students, business travelers, rail fans. So if Flighty can do $6M ARR, why can't Raily do $20M? Fuck that. Maybe even bigger.

Anyway, this is the Powerball Effect.

## 中文

我最近发现一个东西，我暂时叫它 Powerball Effect。不是 Powerball 真的会让你发财，而是，在开奖之前，你会短暂地活在一个完全不同的世界里。

我第一次很强烈地感受到这个东西，是去年圣诞节，和我朋友金哥一起去 Sequoia Park 的路上。那天 Powerball 的奖池好像有 1.7 billion，我们两个在路上就顺手买了两张票。然后从买完票开始，整个世界就变了。

我们开始认真讨论，如果真的中了怎么办。我当时还是旅游签去美国，我就在想，如果我真的中了这个钱，我要怎么把它拿走？IRS 会不会扣很多税？我是不是要请律师？是不是要成立 trust？我要不要先别回国？

金哥更离谱。他说，如果你真的中了，你可能不一定能从旅馆里活着走出来。我说什么意思？他说，因为如果开奖之后发现是你的票，他可能直接拿着票跑了，这辈子我就再也见不到他了。然后我们两个人在车上笑疯了。

那天晚上好像九点开奖。到了酒店之后，我说我要先去洗澡。金哥说，你不等九点开奖以后再洗吗？意思就是，如果我洗澡的时候开奖了，然后真的中了，那我出来以后可能票已经没了，人也没了。很傻逼，但真的很嗨。

最离谱的是，我那张票最后还真的中了三个数字。当然，没有中 1.7 billion。但那几个小时里，我们已经把 1.7 billion 的人生过了一遍。

这就是我说的 Powerball Effect。它不是中奖本身，它是你手里拿着一张可能改变命运的彩票，然后在开奖之前，你开始认真幻想另一个版本的人生。

我发现，创业也是这样的。这几天我在做 Raily，一个有点像高铁版 Flighty 的 app，然后我发了一些小红书，做了一些推广。一开始也没觉得会怎么样。

结果今天凌晨一两点的时候，我突然发现，有几个人开始真的喜欢这个东西。可能也就四五个人。但我当时的感觉是：Oh my God, that's fucking a lot. 终于有人看到我了。

于是我又发了一个视频。几个小时之后，有七十多个人加了群，视频两千多 views，大概十几二十个人里就有一个人愿意进群。我当时整个人就开始进入 Powerball Effect。

我开始想，what if this really works? What if Raily really becomes the Flighty for rail? Flighty 做飞机，可以做到几百万 ARR，那铁路呢？中国高铁每年那么多人坐，欧洲铁路也很多，日本、英国、Amtrak、跨城通勤、留学生、商务差旅、铁路爱好者，全世界坐铁路的人并不比坐飞机的人少，甚至很多地方铁路比飞机更高频。那如果 Flighty 可以做 $6M ARR，Raily 为什么不能做 $20M ARR？Fuck that, maybe even bigger.

Anyway, 这就是 Powerball Effect.


---

# Zero Token Design / 零 Token 设计

> Published 2026-05-07 · By lawted · Canonical: https://ha7ch.com/writing/zero-token-design

## English

I'm not saying the product doesn't need AI. What I mean is: an AI product doesn't always need to burn its own tokens at runtime.

Think about how we built AI SaaS products in the past. The logic was simple: every time a user clicks, the product calls the model. Another click, another request. Another request, another token burned.

That made sense in 2023, because back then, most users didn't really have their own AI workspace.

But now it's different.

Codex, Claude Code, OpenCode, Cursor, and other local agent workspaces are getting more and more mature. They are no longer just chatboxes. They can read your directory, read your documents, run bash commands, edit code, run npx or uvx, and handle a whole workflow inside the user's own environment.

So I think the next generation of AI products can be designed differently.

Not every product needs to put a chatbot inside the webpage and pay for all the reasoning costs by itself. A better way might be: let users finish the reasoning inside their own agent workspace, and then push the result back into your product.

And this is different from Bring Your Own Key.

BYOK still asks users to apply for an API key, configure the key, understand billing, and put that key into your product. Honestly, that's just transferring the bill to the customer, but the UX is still heavy.

Zero-token design is not about asking users to configure a key inside my product.

It is about letting my product work with the tools they already use, like Codex, Claude Code, OpenCode, or Cursor.

CV.pro is a zero-token AI product in my understanding.

It is definitely an AI product, because resume parsing, JD tailoring, and content rewriting all need AI. But these things don't have to happen on CV.pro's server.

The more natural way is: the user copies a quick-start prompt, and maybe there is an npx command inside that prompt. Then they paste it into their own agent workspace. The agent runs the command, parses the file, handles the errors, generates the structured schema, and pushes that schema back to CV.pro.

So CV.pro is responsible for the schema, database, URL views, versions, rendering, and distribution.

Basically: Let the user's agent do the work. Let the product handle the result.

And I think every founder building AI products should think about this carefully.

Should your product do all the reasoning by itself?

Or should it become a system that can be operated by agents, capture the result, and distribute it beautifully?

That's the difference.

## 中文

它不是说产品不用 AI，而是说：AI 产品不一定要在自己的 runtime 里烧 token。

以前做 AI 产品，默认逻辑是用户点一下，产品调用一次模型；用户再点一下，产品再烧一次 token。这个在 2023 年可能合理，因为用户没有自己的 AI 工作台。但现在不一样了。

Codex、Claude Code、OpenCode、Cursor 这种本地 agent workspace 已经越来越成熟。它们不只是聊天框，而是可以在用户自己的项目目录里读文件、跑命令、改代码、执行脚手架的工作台。

所以我觉得，下一代 AI 产品的默认架构应该变了。

不是每个产品都自己包一个 chatbot，然后自己承担推理成本。更好的方式是：让用户在自己的 agent workspace 里完成推理，把结果写回产品。

这和 Bring Your Own Key 不一样。BYOK 还是让用户去申请 API key、配置 key、理解 billing，本质上只是把账单转嫁给用户，体验很重。零 Token 设计不是让用户把 key 塞进我的产品，而是让我的产品进入用户已经在用的 Codex / Claude Code / OpenCode 工作台。

CV.pro 就是我理解里的零 Token AI 产品。它当然是 AI 产品，因为简历解析、JD tailoring、内容重写都需要 AI。但这些动作不应该都发生在 CV.pro 的服务器里。更自然的方式是，用户复制一段 quick start prompt，丢进自己的 agent，agent 自己去跑 npx、解析文件、处理错误、生成结构化数据，然后写回 CV.pro。

CV.pro 负责的是 schema、数据库、URL view、版本、展示和分发。

说白了就是，让 agent 去干活，让产品把结果接住。

这可能也是我现在对下一代 AI 产品的一个判断：不要急着在网页里塞一个聊天框。先想清楚，你的产品到底应该自己推理，还是应该变成一个能被 agent 操作、能沉淀结果的系统。


---

# So WTF is HA7CH

> Published 2026-04-30 · By lawted · Canonical: https://ha7ch.com/writing/so-wtf-is-ha7ch

## English

3 a.m. on my side. I was chatting with my American friend on WeChat, morning for him. Mid-conversation, he tossed out an idea: what if we build Raily Friends, a high-speed rail travel buddy?

I said, let's fucking go.

Two hours later, my frontend was done. I went to sleep. He picked up the relay on the U.S. side, building out the chat backend. By noon China time, the thing was actually usable. We posted it on WeChat Moments right on schedule.

It got a wave of attention and feedback the moment it went live.

That was the moment we realized something. We really can ship in 48 hours.

So, WTF is HA7CH? It's a tiny little club.

Anyone here can speak up with an idea, we build it fast, or build it together with you. The moment it ships, we throw it on WeChat Moments and RedNote for people to use.

If people use it, we keep maintaining it. If nobody does, we drop it and move to the next one.

The reason this works is because vibe coding is fucking fast right now. As long as you have a decent idea, you don't need to wait for requirement docs, you don't need to wait for design mocks, you don't need to wait for anything. Just build it.

And because we ship fast, we don't get too attached to any single product. We don't cling. Maybe this week it's this product, next week it's the next one.

Before ByteDance hit it big, Zhang Yiming had built 5 products. He failed 5 times. Back then there was no AI, and shipping anything took forever. One or two years per product was the norm.

In the AI era, failing 500 times before you hit it is fine. After all, our shipping speed is 100 times faster.

## 中文

凌晨三点，我跟我美国的朋友在微信上聊天。他那边是早上。聊着聊着，他突然冒出一个想法：要不我们做一个 Raily Friends，高铁搭子？

我说，let's fucking go。

两个小时后，我这边前端就做完了。做完我就去睡了。他在美国那边接力，把后端的聊天功能都补齐。等中国中午十二点的时候，东西已经能用了。准时发朋友圈。

一上线就收获了一波关注和反馈。

那一刻，我们意识到一件事。We really can ship in 48 hours.

So, WTF is HA7CH? 它就是一个小小的 club。

在这里，谁有 idea 就直接说出来，我们快速把它做出来，或者拉上大家一起做。做完立马丢到朋友圈、小红书，给大家用。

有人用，我们就继续维护下去。没人用，立马放掉，去做下一个。

之所以能这样，是因为 vibe coding 现在快到这种程度。你只要有一个不错的想法，不需要等需求文档、不需要等设计稿、不需要等任何东西，直接做就行。

而且因为做得快，我们对单个产品的期待反而没那么高了。我们不会死守。也许这一周做这个产品，下一周就开始做下一个了。

字节跳动成功之前，张一鸣做了 5 个产品，失败了 5 次。那个时候没有 AI，做东西很慢，一个产品做一两年是常态。

在 AI 时代，我们成功之前失败 500 次也没什么。毕竟，我们的开发速度提升了 100 倍。