The 9 AM Inbox

The first thing I do every workday is batch-process whatever the AI left behind overnight.

Reports generated while I slept. PR drafts auto-opened on the codebase. Meeting notes the Agent assembled and tagged me into. Tickets stuck at some decision point waiting on my call. And a handful of escalations: "I think you should look at this one."

Coffee in hand, about 40 minutes. I go through them one by one. This PR is going the wrong way, reject. This report has the right thesis, just needs two more numbers. This ticket can run through automated repair. That customer complaint has a thread under it I want to pull myself. Then humans and AI go their separate ways for the rest of the day. I head to meetings. It goes off to do work.

I've been doing this for the better part of a year. The other day it hit me: the first hour of my workday is essentially managing a team of machine subordinates.

I sat there feeling slightly disoriented. When I manage humans, I have to read their emotions, give feedback, plan their careers. When I manage these machine subordinates, all I do is approve, reject, redirect, dispatch. The latter is an order of magnitude more efficient. It's also colder. Two ways of working are slowly diverging inside me.

Over the past six months I've been mapping out what I've seen, built, and broken along the way. This map isn't an academic framework. It's more like a sketch someone draws for themselves at 2 AM when they can't sleep, trying to make sense of the change happening around them. The questions it answers: where are we actually, what's still ahead, which traps are real, and which hype is fake.

I call it the five-layer model of AI-Native.

Layer 1: Writing Code for You

The earliest use of AI was personal. People delegated their own work.

The clearest case is code. Once Cursor stabilized, my engineers basically stopped writing first drafts by hand. Requirements come in, they have a conversation with the AI, get a draft, then refine it. Same with documents. Weekly meeting notes drafted by AI, then polished. Review materials drafted by AI, then re-thought.

The fundamental difference between Layer 1 and "before AI"? The tool changed. The work didn't. People are doing the same things, just with a more efficient executor. Same kind of shift as moving from Vim to VSCode, or from SVN to Git.

Its boundary is also clear: AI only serves "me," the individual. It doesn't know what big project our department is working on, what request the team next door submitted last week, or why my boss is angry today. It's a very capable tool sitting on my desk.

The unexpected side effect: my engineers' coding time dropped from 6 hours a day to 2. Where did the other 4 go? Meetings. Alignment. Politics. Approval workflows. After Layer 1 lands, you'll hear engineers complain about meetings.

The complaint is valid and also wrong. What AI took away wasn't 6 hours of coding. It was 6 hours of "this logic is complex, I need to focus." With AI knocking out that logic in half an hour, the engineer has to actually face the meetings.

At Layer 1, the organization is the same organization it always was. AI just lights up on each engineer's desktop, individually.

Layer 2: Inside the Workflow (where we are now)

The mark of Layer 2 is that AI moves from serving individuals to serving processes.

Let me paint a concrete picture of what this looks like.

Our department's Lark groups used to have a few internal-support people as the busiest role. Starting at 9 AM, PMs, QAs, and account managers would throw questions in: "Has the launch plan changed?" "Where is that customer's compliance approval?" "Who got assigned that P3 ticket from yesterday?" 80% of these questions were repeats. 20% had standard answers. Only a small fraction actually required judgment. That repetition used to consume several headcount.

Now we have a Q&A bot in those groups. It reads the knowledge base, the ticket system, the release calendar. Most repeat questions get answered directly. It also takes meeting notes, syncs them into Lark Docs, and tags the relevant people. It pre-processes IT tickets. Simple things like resetting a test account or granting a development permission, it handles itself.

The fundamental difference between Layer 2 and Layer 1? AI moved from "personal desktop" into "team infrastructure." It no longer serves a single engineer. It serves the workflow. Its inputs and outputs are embedded in the team's daily collaboration.

But it has a clear ceiling: it's still purely reactive. You ask, it answers. Otherwise it sits there.

I figured out where that ceiling was during a production incident.

The root cause was buried in a Lark message an engineer had posted two weeks earlier. In a project group with 40-some people, he'd casually said: "I looked at this change. The reconciliation logic on Y business line might be affected." Some people sent a quick "got it." Some didn't see it. He himself forgot.

Two weeks later, Y business line's reconciliation actually broke. Customer complaints. Compliance escalation. The trail led back to me. The retrospective stung. The AI had "seen" that message all along. It had taken the meeting notes for that project. It had handled IT tickets in that group. It had even translated that message for the overseas team. But it had no concept of recognizing risk.

It processes messages without reading them. It assembles minutes without understanding which decisions in those minutes have no follow-up. It answers questions without asking "why hasn't anyone asked this before?"

That's where Layer 2 stops. It frees your hands. It doesn't free your eyes or your judgment.

This is mostly where we are. The wins at Layer 2 are easy to claim. Stand up a Q&A bot, drop in a meeting-notes tool, ROI shows up in two weeks, the slide deck for the boss writes itself. So plenty of teams stop here and call themselves "AI-Native."

They've installed a smarter customer service rep.

Between Layer 2 and Layer 3: The Real Wall

The gap between Layer 2 and Layer 3 hides one obstacle most people don't articulate: context.

"Context" decomposes into four progressively harder problems. Let me walk through them.

Step One: Extraction

Before the AI can do anything, it has to know what's actually happening.

A customer issue comes in. What the AI needs to grasp is the entire story behind that single message: who is this customer, what have they complained about in the past three months, what's their contract tier, who last touched the feature they're complaining about, was the change properly reviewed, did monitoring fire any alerts at deploy time?

That information lives in CRM, the ticketing system, Git, Jira, monitoring, the release system, Lark groups, and Lark Docs. Each system has its own API, its own field naming, its own permission model. The "customer" entity alone is called customer_id in CRM, account in the ticket system, "customer number" in the contract system, and "entity code" in the compliance system. Four ID schemes. Nobody can give you the complete mapping.

Just getting the AI to extract "what just happened" requires a massive amount of translation work first.

Step Two: Retrieval

The present isn't enough. The AI has to dig backwards.

When an error log surfaces in production, the information that actually determines how to fix it might be buried in an architecture review meeting from three months ago. That edge case got discussed back then, a workaround was chosen, a TODO was left, nobody followed up.

Asking the AI to retrieve means it has to walk back from today's symptom to that meeting, that document, that decision, that specific person. The longer the retrieval chain, the more times the AI has to "jump." Each jump reloads context. Each jump is a non-trivial cost. Not just in tokens. Each hop also risks losing critical signal or wandering off course.

Step Three: Linking

You've extracted, you've retrieved. Now connect them.

Knowing "this customer raised this issue" isn't enough. The AI has to link this customer issue with last week's code change, with the monitoring curve from that day, with the compliance constraints involved, with the priority ranking in the product roadmap. It has to see the whole picture in one frame.

This is brutally hard because those five tables belong to five different departments: customer service, engineering, ops, compliance, product. Each department has its own data governance standard. Some department's core data isn't even digitized; it lives in some director's head.

The actual work is data integration, schema unification, and cross-department permission coordination. Almost none of it has anything to do with training models.

The irony is that the difficulty isn't AI's fault. This is a "data platform" problem we should have solved a decade ago. We got away with deferring it. AI has finally made the cost of fragmented context impossible to defer: yesterday it just meant a few extra arguments in meetings; today it deadlocks your Agent.

Step Four: Permissions and Organizational Gravity

The last step is the hardest, because it isn't a technical problem at all.

The AI needs cross-system data access, and access requires permissions. An Agent that wants to read CRM data needs customer service to authorize it. To read code in Git, it needs engineering's authorization. To read compliance records, it goes through legal. Every additional layer of org structure is another door.

And these doors were designed for humans, not Agents. When you grant a permission to an engineer, their manager signs off, their job description backs it up, and if something goes wrong you know who to go to. When you grant a permission to an Agent, who signs? Who's accountable? Who answers when it breaks something?

We had a discussion in our department about granting an Agent read-only access to production. Three meetings. Compliance, security, ops, legal all in the room. We didn't do it. The technology was perfectly capable. Nobody was willing to put their name on the dotted line.

The deeper the org hierarchy, the higher the cost for AI to traverse context. In a 30-person startup, AI getting any data is one config line. In a 3000-person business line, AI getting the same data crosses three departments, five tables, eight approval nodes.

This is organizational gravity, not a technical problem.

In our dev environment, the "log to code" loop is fully wired. The AI reads an error log, links to the relevant code, drafts a fix PR. End-to-end, it works beautifully on test data. We still don't trust it in production. The data pipeline has dead spots. The permission model isn't ready to grant production read access. The accountability question isn't settled.

This wall has held us up for about two quarters. I now understand why so many large-company AI projects end as "internal demos." The bottleneck isn't technology. It's that context can't traverse the org.

Layer 3: Where It Gets Surreal

If you can clear the context wall, Layer 3 starts becoming real.

This layer still feels unreal to me, even now. Building it isn't actually that hard once the plumbing is in place. What surprises me is the picture you see once it's running.

Here's what I want to see, and what we're starting to see in dev:

One morning, an account manager forwards a customer complaint into Lark: "Your XX feature has been slow this week. Our backend batch job keeps timing out."

In the past, this message would start a long relay race. Account manager tags PM. PM tags engineering lead. Engineering lead asks the group, "anyone know about this?" Someone remembers a code change last week, tags the engineer. The engineer pulls up monitoring, digs through release notes, finds the PR, finds the logs. Two or three hours later. Customer still waiting.

At Layer 3 it goes like this: the Agent reads that message (it's in the group, with proper context permissions) and autonomously does the following:

It retrieves: this feature had a release last week. PR #4823.

It links: the P99 for this feature jumped from 800ms to 2.4s. The spike timing matches the deploy.

It extracts: the diff in PR #4823 contains a batch query pattern that probably degrades under high data volume.

It escalates: in the oncall channel, it tags the original author Zhang San, the on-duty oncall Li Si, and the account manager. "I've located this customer issue. Likely related to PR #4823, batch query performance. Recommend escalating to P2. Draft fix is in the PR comments. Please review."

It reassures: in the account manager's DM: "Issue located and escalated. Estimated 2-hour turnaround on a fix proposal. Standby."

This entire sequence happens while people are still sipping morning coffee.

The fundamental difference between Layer 3 and Layer 2? AI moved from reactive to proactive. Layer 2's AI is a "ask and you shall receive" customer service rep. Layer 3's AI grew professional instinct: it identifies risk on its own, pulls in the right people, finds the code, drafts solutions, reports progress upward.

The key inflection point: what really changes is that AI shows professional judgment for the first time, not that AI can write code. That instinct used to take two or three years to develop in a junior engineer. What counts as urgent, who to tag first, when to escalate, when to handle alone. AI has it now.

My one-word evaluation: surreal.

What's surreal? Through Layer 2, every AI action followed a "you click, it moves" pattern. From Layer 3 onward, it acts on its own. When you sit down at your inbox in the morning, you find that half the items already have the prep work done. You're just there to say yes or no, to provide the final judgment.

The boundaries remain. It can draft, but it can't decide. It can escalate, but it can't prioritize. It can tag people, but the person tagged still has to read the context, make the call, and write the code.

And writing code, at Layer 3, still doesn't go back to AI. Not because AI can't write code; it has been able to do that for a while. The hard part is knowing what to fix, where to pull the context from, and how to verify the fix is correct. Code is the easy part. Knowing "what to fix, why, and how to know it's working" is the actual substance of engineering. That still takes a human.

Layer 3 grew AI eyes and a mouth. Not yet hands.

Layer 4: Full-Loop Autonomy (imagined, not yet seen)

About Layer 4 I owe you honesty: we're on the road, and the road is long.

Here's the picture: a production log surfaces an anomaly → Agent catches it → reproduces it → locates the code → writes the fix → writes tests → runs CI → opens the PR → rolls through canary → reads AB data → decides on full rollout → monitors regression → closes the ticket.

End-to-end observable. End-to-end traceable. End-to-end reversible. If anything goes wrong you can see exactly what decision the Agent made at every step, and you can pull any step back to redo it.

The fundamental difference between Layer 4 and Layer 3? AI finally grew "hands." Layer 3 still passes the ball back to humans. It locates, drafts, escalates, then waits. Layer 4 catches the ball and runs the whole track. Not just "identifying the problem." Actually "solving" it.

Going from dev to production hits a stack of unsolved problems.

First: rollback. What happens when the Agent ships the wrong fix? A bad release can mean millions in customer losses, a regulatory compliance incident, reputational risk. In the human world this runs on SRE intuition, on-call instincts, the "let me roll this back fast" reflex. In the Agent world, you have to write all of that down as an explicit protocol. What metric change triggers an auto-rollback? How fast counts as "fast"? How do you reconcile state after the rollback? What if you can't?

Second: accountability. The Agent shipped a bug, the customer took losses, who's responsible? The engineer who approved the PR? The team that deployed the Agent? The company? In any regulated environment this question is lethal, because regulators trace back to individuals. Regulators don't accept "the AI did it."

We had an internal meeting about this. Three hours. No conclusion. There was no technical obstacle. There was nobody in the org willing to put their name on the line.

Third: observation cost. The more autonomous the Agent gets, the less people see what it's doing. By the time you notice it's doing something stupid, it might already have done it ten thousand times. What does this mean in practice? One day you might receive a phone call from compliance telling you the Agent has been quietly committing a small infraction for three months, only just discovered today.

I've previously described this as a "log-driven autonomous repair loop." That's basically Layer 4: let real production data drive the Agent's workflow directly. Humans only show up at critical decision points. But where exactly are the critical decision points, how to define them, who defines them, and who carries the accountability when things go wrong? Those are still open questions for us.

Layer 5: The Final Interrogation

Layer 5 isn't really a new capability. It's a set of questions.

The core question: is your entire enterprise architecture friendly to AI?

The fundamental difference between Layer 5 and the previous four? Layers 1 through 4 ask "how do we use AI to do work." Layer 5 asks whether your company has earned the right to use AI at all.

Sounds dramatic. It's actually very concrete. Broken down:

When a production bug occurs, can the AI see the full event? Logs, traces, user behavior, context: are these instrumented in a place it can read? Or are they scattered across seven systems that even humans can't reconcile? (This is exactly the wall we're stuck at between Layers 2 and 3.)

When a requirement comes in, can the AI know its origin and context? Is this a real customer scenario, a sales promise made to close a deal, or a PM's stray idea? The layers go further: is it a compliance requirement? A regulatory mandate? A casual remark from a senior exec? Has that context been written down somewhere an Agent can find it? Or does it live only in some director's WeChat history?

Can the right issues escalate? Does your Agent have the cross-team, cross-permission, cross-tool passport it needs, or does it hit a wall every time it crosses a boundary? In a pyramid-shaped org, this is brutal: a permission grant takes five approvals, the Agent waits three days for a single hop.

Is your code documentation written for AI? Notice the framing: for AI, not for the next human. Standards differ. Documentation for humans tolerates ambiguity, tribal knowledge, "you know what I mean." Documentation for AI must be explicit, self-contained, and fully contextualized. Most legacy system documentation is illegible to an AI.

Layer 5 is an organizational problem. Technology has very little to do with it.

It means every process, document, permission, and tool in your company has to be re-examined: is this AI-friendly? If not, every capability you built in Layers 1 through 4 will get cut off at the knees here.

I've watched too many AI projects end as "internal demos" or "pilots that quietly faded." They put serious effort into building Agent capabilities, only to find the Agent can't actually run. Log structures inherited from a decade ago. Requirement docs scattered across three different collaboration tools. Key judgment that exists only in one person's head. Cross-department permissions that take three weeks to provision.

The Agent stands there. It can do everything. It can do nothing.

Beyond Layer 5: Do We Still Need a Company?

Layer 5's interrogation isn't actually finished here. If you really do remake your organization into an "AI-friendly" form, something deeper than "efficiency gains" happens: the headcount structure of the company gets fundamentally rewritten.

Let me put a stake in the ground: functional specialization itself may need to be rewritten from the ground up.

The corporate architecture we run today is, at its core, inherited from the assembly line. Break a big task into many small pieces, hand each piece to a specialist. The assembler only assembles. QA only QAs. Procurement only procures. Legal only reads contracts. Compliance only watches compliance. Product only draws product. Engineering only writes code.

Why this division? Because human bandwidth is finite. The amount of context one person can hold in their head is bounded, and so is their attention. Ask a single person to do assembly, QA, and procurement simultaneously and they'll fail at all three. So narrower and more vertical means more efficient. This has been the first principle of organizational design since the Industrial Revolution.

AI doesn't have this constraint.

AI can run ten parallel things you've handed to it without worrying about attention. Its "bandwidth" depends almost entirely on whether the context you give it is rich enough and the rules you've defined are clear enough. The implication: once a person has AI in hand, the territory they can effectively cover expands from one narrow line to a wide area.

The old game asked for depth. The new game asks for breadth.

The old archetype was an expert who drilled all the way to the bottom of one domain. The new archetype is a "deep in one, strong across many" composite professional: someone who deeply understands their own primary field, can hold their own across several adjacent fields, and is fluent enough with AI to run all of those fields in parallel.

The implications for org design are radical.

HR, admin, procurement: these are all transactional process departments at their core. In an AI-Native company, these three could collapse into a 5-person "operations platform" team, with everything else running on AI.

Legal and risk control: both fundamentally do compliance judgment and risk identification. These departments often have hundreds of people each, but the underlying logic is the same. Merging them into one team after AI-Native arrives makes complete sense.

Product and engineering is the most dramatic case. Today my department has PMs, engineers, QA, designers, and ops as five separate lines, with five leads and five reporting relationships. Once you have Layer 3 and Layer 4 AI actually running, the massive "alignment cost" disappears. The PM's mental model gets translated by AI into a code draft. The engineer's diff gets covered by AI-generated tests. The bug found by QA gets traced back by AI to its requirement origin. Five lines collapse into a single "product-engineering integrated" small team. Entirely doable.

The most striking part: most companies don't actually need that many "scientist-grade" specialists. Deep expertise still has value, but the demand for it shrinks dramatically. A mid-sized business line that used to need thirty deep specialists might in the future need five truly top-tier experts plus a roster of "breadth + AI leverage" composite professionals.

I'll be honest: this won't happen overnight. Organizational gravity is too heavy. Process inertia runs deep. But the direction is clear. Within five years, you'll see org charts get flatter, functional boundaries blur, and "uses AI as leverage to amplify output" become an implicit baseline in every job description.

This shift hasn't reached its endpoint. Push one more step and a sharper question shows up.

Is the Company Itself Still Necessary?

Economics has a classical explanation called the Coase theorem: firms exist to reduce the transaction friction that arises when groups of people try to coordinate on the open market.

The argument: if you want to build a car, in theory you could find 100 independent workers in the market and have each one do a piece by contract. In practice you don't, because finding 100 people, signing 100 contracts, coordinating 100 schedules, and resolving 100 disputes adds up to absurd transaction costs. So you form a company, hire those 100 people, and replace market transactions with internal management. The friction gets "internalized."

A company, fundamentally, is a container for friction reduction.

But what happens if AI-Native genuinely shrinks organizations down? What if a 500-person business line becomes a 50-person composite team plus an army of Agents?

The friction surface area of 500 people is enormous: hiring, training, performance reviews, promotions, office politics, cross-team coordination, compliance audits, culture work. Those "internal frictions" are themselves a massive cost. The reason a company is worth existing is that the "external frictions" it eliminates exceed the "internal frictions" it generates.

50 people drops the friction surface dramatically. What about a 10-person, or single-person "company"?

When a group becomes a handful, the friction between that handful and society shrinks from a large fire to a few sparks. At that point, the value of "company" as a friction-reduction container decays rapidly.

So what's the ultimate form of AI-Native?

Possibly something we can't fully see yet: a small core of human talent, plus a dispatchable swarm of AI Agents, interfacing directly with the market through "project-based" or "collaboration network" arrangements. No pyramid. No departments. None of the middle layer that exists purely to coordinate hundreds of people.

Sounds like science fiction. But trace back through every layer of the model: AI writes your code, AI enters the workflow, AI recognizes risk, AI closes the loop, the organization becomes AI-friendly. Each layer strips away something that existed only to "coordinate a group of people." Strip past Layer 5 and keep going, and what you're stripping is the company itself.

I don't know whether our generation will actually live to see that day. But I can already feel the direction of the gradient.

Pushing AI-Native through an organization of several thousand people, every step forward triggers the same voice in my head: are you helping the company become more efficient, or are you making the company less necessary?

This question doesn't have an answer. I'm not going to manufacture one. But everyone walking the AI-Native road will, sooner or later, have to face it.

Notes in the Margin

Looking back across the five layers and the unnumbered question after them, what's actually changing isn't the technology. It's the shape of the question.

Layer 1 asks: can AI write code? Layer 2: can AI enter the workflow? Layer 3: can AI recognize risk? Layer 4: can AI close the loop? Layer 5: can the organization let AI close the loop? After Layer 5: once the organization actually changes, does the company itself still need to exist?

The first four are problems a single function can drive. The fifth isn't. Layer 5 requires the CEO, CTO, HR, legal, compliance, and finance to remake the company together: rewriting process documentation, redrawing permissions, redefining KPIs, redefining roles. Most of this gets deferred. It's hard, the short-term ROI is invisible, and every change touches departmental fiefdoms.

The question after Layer 5 sits beyond any single role's reach. It's beyond what a single CEO can decide. It's a question this company, this industry, and this generation have to face together.

But you can't actually defer it. The AI-Native window won't stay open forever. When your competitor is operating stably at Layers 3 and 4 while you're still hiring people to fill in meeting notes at Layer 2, the gap between you isn't technical. It's a generational gap in how the organization is built. Push the timeline further: when your competitor has started redrawing functions, merging departments, and flattening their org chart, while you're still defending a traditional pyramid, the gap stops being a generational gap. It becomes a species-level gap.

I'm under no illusion that drawing the map is the same as walking it. My team is the proof. We tasted the wins at Layer 2, got stuck at the "context" wall for two quarters, barely have a Layer 3 prototype running in dev, can only imagine Layer 4 in our heads, every Layer 5 question is biting us right now, and the question past Layer 5 we haven't even started touching.

If this map can leave anything to those walking the same stretch of road, it's one line: don't wait for "AI to mature." The people who wait won't win. The people who walk and edit the map at the same time will. This matters more in heavyweight environments with deep hierarchy and slow processes, because every step there is three times slower than at a startup. The earlier you move, the earlier you start clearing the decade-old debt that's been deferred, and the better your chance of standing at Layer 3 or Layer 4 when the window starts closing.

Those 40 minutes every morning batch-processing the inbox might look like a side effect of a new way of working. It's actually a new organizational form leaning over me, asking for a decision.

Every time I shut my laptop and head into a meeting, I find myself asking: will the time I spend managing those machine subordinates one day exceed the time I spend managing humans? If it will, this company's shape is going to need redrawing.

And one layer deeper: that redrawn shape may not be a "company" at all anymore.

看完了？说点什么呢

AI 推到第三个季度，我发现自己每天 40 分钟在 inbox 里批准、否决、改方向、派任务，处理的全是机器昨晚交上来的作业。这件事比管人冷得多，效率也高一个数量级。然后某天我意识到一个挺荒诞的问题：我正在帮公司变得更高效，还是正在让公司变得不再必要？

早上九点的 inbox

我现在每天上班的第一件事，是打开电脑批处理 AI 留下的一堆东西。

过夜跑出来的报告、自动起草的 PR、Lark 里它整理好的会议纪要和 @ 我的待办、卡在某一步等我点头的工单、还有几条它升级上来的“我觉得这事得你看看”的提醒。

一杯咖啡，大概 40 分钟。我会挨个过：这个 PR 改的方向不对，打回；这份报告主线对了，细节再补两个数；这个工单可以让它走自动修复；那个客户反馈背后藏了一根线，我得自己去看一下原始上下文。处理完了，人和 AI 重新各自上路，我去开会、它去跑活儿。

这个动作我做了大半年。最近某天我突然意识到一件事：我每天上班的第一个小时，本质上是在管理一群机器下属。

那一刻我有点恍惚。我管人的时候要照顾情绪、要给反馈、要做职业发展规划；我管这群机器下属的时候，只需要批准、否决、改方向、派任务。后者比前者效率高出一个数量级，也冷得多。两种工作模式，正在我身上慢慢分叉。

后来我把这半年看到的、做到的、栽过跟头的，慢慢梳理成了一张地图。这张地图不是什么学术框架，更像是一个正在亲历变革的人，半夜睡不着觉时画给自己看的草图。它要回答的是：我们到底走到哪儿了，前面还剩什么，哪些坑是真的，哪些幻觉是假的。

我把它叫做 AI-Native 的五层模型。

第一层：替我写代码

最早大家用 AI，都是替自己干活。

最典型的就是写代码。我团队里几个工程师，从 Cursor 用顺之后，基本不再手写第一版。需求来了先和 AI 聊清楚，让它出底稿，再自己改。文档也一样，周会纪要 AI 起，自己润色；评审材料 AI 起，自己改逻辑。

这一层和上一层（传统人工写代码）的根本差异是什么？是工具被替换，但工作没有变。 人干的活儿没动，只是换了个更高效的执行者。和当年从 Vim 换到 VSCode、从 SVN 换到 Git 是一回事。

它的边界也很清楚：AI 只服务于“我”这个独立的个体。 它不知道我们部门在做什么大项目，不知道隔壁组上周提了什么需求，不知道我老板今天为什么发火。它就是我桌上一个特别能干的工具。

唯一的副作用挺反直觉：工程师每天写代码的时间从 6 小时降到 2 小时，剩下 4 小时去哪儿了？开会、对齐、扯皮、走流程审批。所以这一层落地之后，工程师抱怨开会变多了。

抱怨没错，但也错了。AI 抢走的其实是那 6 小时“我太忙了不能开会”的借口，代码反倒是次要的。一个工程师过去之所以能逃掉一些没用的会，是因为他可以指着显示器说“这段逻辑很复杂，我得静下来写”。现在 AI 把这段逻辑半小时就写完了，他不得不真的去面对那些会议。

到这里，组织还是原来那个组织。AI 只是在每个工程师的桌面上各自闪光。

第二层：进了协作流程（我们目前在这里）

第二层的标志，是 AI 从服务个人变成服务流程。

这一层长什么样？我可以画一个具体的画面。

我们部门的 Lark 群，过去最忙的角色是几个内部支持。早上 9 点开始，产品经理、QA、客户经理在群里抛各种问题：“上线计划改了吗？”“那个客户的合规审批走到哪一步了？”“昨天那个 P3 工单分给谁了？”这些问题 80% 是重复的、20% 是有标准答案的、剩下少数才需要真正的判断。过去这些重复劳动消耗了好几个 HC。

现在我们部门的 Lark 群里，接了一个 Q&A bot。它读知识库、读工单系统、读发版日历，绝大部分重复问题它直接答了。会议纪要也是它做，自动同步到 Lark 文档，@ 上相关的人。内部 IT 工单也走它先过一遍，简单的事情（如重置某个测试账号、申请某个开发权限）它直接处理。

这一层和第一层的根本差异是什么？是 AI 从“个人桌面”进入了“团队基础设施”。 它服务的不再是某一个工程师，而是整个流程。它的输入和输出都嵌进了团队的日常协作中。

但它有个非常明确的天花板：它仍然是被动响应的角色。 你问它就答，你不问它就在那儿待着。

这个天花板是什么时候让我看清的？是一次线上事故。

那次事故的根因藏在某个工程师两周前的一条 Lark 消息里。他在一个有四五十人的项目群里轻飘飘地说了一句：“我看了下这块改动，Y 业务线那边的对账逻辑可能要受影响。”那条消息发出来以后，有人随手“收到”，有人没看见。他自己后来也忘了。

两周后，Y 业务线的对账真的出了问题。客户投诉，合规上报，一路追到我这儿。复盘的时候我特别难受：那条消息 AI 全都“看见”过。它做过那次会议的纪要、它处理过那个项目的 IT 工单、它甚至帮人翻译过那条消息给海外团队。但它没有“识别风险”这件事的能力。

它处理消息，不读懂消息。它整理纪要，不理解纪要里哪条决议没人接。它回答问题，不去问“这个问题为什么没人问过”。

第二层的天花板就摆在这儿：它解放的是手，没解放眼睛和判断力。

我们现在主要就在这里。这一层的甜头很容易吃到。上线一个 Q&A bot、配一个会议纪要工具，两周就能看到 ROI，老板汇报的时候 PPT 也好做。所以很多团队会在这里停下来，觉得自己已经“AI-Native 了”。

其实只是装了个更聪明的客服。

第二层到第三层之间：那道真正的坎

要从第二层迈到第三层，中间隔了一道很多人没说清楚的坎：上下文。

上下文这件事有四个层层递进的难题。我们一个一个看。

第一关：摘取

AI 要做事，首先得知道“现在在发生什么”。

一个客户问题来了，AI 要看的不只是这条消息，而是消息背后整个故事的合理摘取：这个客户是谁？他过去三个月提过什么问题？他的合同等级是什么？他这次抱怨的功能上次是谁改的？改动当时通过审批了吗？发版的时候监控有没有报警？

这些信息散在 CRM、工单系统、Git、Jira、监控平台、发版系统、Lark 群聊、Lark 文档。每个系统的接口、字段、权限模型都不一样。光“客户”这一个实体，在 CRM 里叫 customer_id，在工单里叫 account，在合同系统里叫客户编号，在合规系统里叫主体代码：四套 ID，没人能告诉你完整的映射关系。

让 AI 摘出“刚才发生了什么”，这件事的工程量，主要花在大量翻译工作上。

第二关：回溯

光看当下不够，AI 要会往回翻。

一条线上 error log 出现的时候，真正决定怎么修的信息可能藏在三个月前的一次架构评审会议纪要里。当时讨论过这种边界情况，选了一个权宜方案，留了个 TODO，后来没人追。

让 AI 回溯，意味着它要能从今天的现象，反向找到三个月前那次会议、那个文档、那条决议、那个具体的人。回溯链路越长，AI 跳的次数越多，每跳一次都要重新加载一遍上下文，每一次跳跃都是一次代价不低的成本。这不只是 token 烧得快的问题，更是每一跳都可能丢失关键信息、走错方向。

第三关：打通

摘出来了、回溯到了，接下来是关联。

光知道“这个客户提过这个问题”，不够。AI 要能把这个客户问题、上次的代码改动、当时的监控曲线、合规上的限制、产品 roadmap 里的优先级排序，全部关联起来，看到一张完整的图。

这件事特别难，因为这五张表分别属于客服部、研发部、运维部、合规部、产品部。每个部门的数据治理标准不一样，有些部门的核心数据根本就没数字化、还存在某个总监的脑子里。

真正在做的事情，是数据集成、schema 统一、跨部门权限协调，跟训模型基本无关。

讽刺的地方在于，这件事的难度不是 AI 带来的。这是十年前我们就该解决的“数据中台”问题，只是过去一直能拖。AI 之所以让我们必须现在动手，是因为它把“上下文不联通”的成本从隐性变成了显性。以前数据孤岛，无非是开会时多吵几句；现在数据孤岛，直接卡死你的 Agent。

第四关：权限和组织重力

最后一关最难，因为它不是技术问题。

AI 要跨系统拿数据，绕不开权限。一个 AI Agent 想要看 CRM 里的客户数据，得有客服部的授权；想要看 Git 里的代码，得有研发部的授权；想要看合规系统的备案，得走法务的流程。每多一层组织，就多一道门。

而且这些门是设计给“人”的，不是设计给“AI”的。给一个工程师开一个权限，有他主管签字、有他岗位职责背书、出问题能找到他；给一个 Agent 开权限，谁签字？谁背书？它出问题谁负责？

我们部门有过一次讨论，讨论给 Agent 开生产环境只读权限。开会开了三次，合规、安全、运维、法务都来了，最后没敢开。技术上能做到，问题是没人愿意在这个东西上签字。

组织层级越深，AI 跳上下文的代价就越高。 在一个 30 人的小公司，AI 拿任何数据可能就是一行配置；在一个 3000 人的业务线，AI 拿同样的数据要走三个部门、五张表、八个审批节点。

说到底，这是组织重力的问题，跟技术关系不大。

我们 dev 环境里“日志到代码”这条链路已经跑通了。AI 能读到一条 error log，关联到代码，起草一个修复 PR。整条链路是闭环的，在测试数据上跑得也漂亮。但我们还不敢把它放到生产环境：数据通道还有死角，权限模型还没敢给它生产读权限，真出了事谁负责的问题还没想清楚。

这道坎卡住了我们大概两个季度。现在我特别理解为什么很多 AI 项目最后都搞成了“内部 demo”：瓶颈从来不在技术，在上下文跨不过组织。

第三层：开始变得魔幻

如果上下文这道坎能跨过去，第三层就开始有了。

我至今觉得这一层有点不真实。技术上做出来其实没那么难，真正让我意外的是做出来之后那个画面。

我先描述一下我想看到的样子，以及我们 dev 里已经能看到一部分的雏形：

某个早上，一个客户经理在 Lark 里转发了一条客户的吐槽：“你们那个 XX 功能这周变慢了，我们后台批量跑批一直超时。”

过去这条消息会经过一长串接力：客户经理 @ 产品经理，产品经理 @ 研发主管，研发主管在群里问“谁知道这事”，有人记得上周改过相关代码，@ 那个工程师，工程师上线一看监控、翻发版记录、找 PR、找日志……一圈下来两三个小时，客户那边还在等。

第三层的样子是这样：Agent 看到这条消息（它在那个群里，而且有上下文权限），自动做了这么几件事：

它先回溯：上周这个功能有过一次发版，定位到具体的 PR #4823。

它再关联：监控里这个功能的 P99 确实从 800ms 涨到了 2.4s，涨幅时间点和发版时间吻合。

它再摘取：翻 PR #4823 的代码改动，识别出有一处批量查询的写法可能在大数据量场景下退化。

它再升级：在 oncall 频道里发了一条消息，@ 了原作者张三，@ 了 oncall 当班的李四，@ 了客户经理：“这个客户问题我已经定位，可能和 PR #4823 相关，涉及批量查询性能，建议升级为 P2。修复草案我贴在 PR 评论里了，请看一下。”

它最后兜底：在客户经理的私聊里回了一句：“问题已经定位并升级，预计 2 小时内给您回复修复方案，请稍等。”

这一切发生的时候，人还在喝早咖啡。

这一层和第二层的根本差异是什么？是 AI 从被动响应变成主动推进。 第二层的 AI 是“有问必答”型的客服；第三层的 AI 长出了职业本能，会自己识别风险、自己拉对应的人、自己找代码、自己起方案、自己向上报告进度。

注意这一步的关键：真正的跳变在于“AI 第一次表现出了职业判断”，而不是“AI 会写代码”。 它过去要培养一个工程师两三年才能形成的那种本能，什么事算紧急、什么事该先 @ 谁、什么时候该升级、什么时候该自己处理，AI 第一次有了这种东西。

我对这一层的评价就一个词：魔幻。

魔幻在哪儿？在于第二层之前所有 AI 行为都是“你按一下它动一下”。第三层之后，它开始有自发性。你早上打开 inbox 的时候，会发现里面有一半的事情是它已经替你把准备工作做完了的，你只是来按 yes 或 no、提供最终判断。

但它仍然有边界。它能起草方案，不能拍板；它能升级问题，不能决定优先级；它能 @ 人，但被 @ 的那个人，还得自己去理解上下文、做决策、改代码。

修代码这件事，在第三层依然回不到 AI 手里。AI 早就能写出能跑的代码，真正难的是它知道该修什么、从哪里取上下文、怎么验证修对了。代码本身是最简单的环节，知道“修什么、为什么修、修完了怎么知道好了”，才是工程的本体。这件事还要靠人。

第三层让 AI 长出了眼睛和嘴，但还没长出手。

第四层：Agent 全链路自治（我能想象，但还没看到）

第四层这件事我得诚实说：我们还在路上，而且很远。

第四层的样子是这样的：线上日志出现异常 → Agent 自动捕获 → 自动复现 → 自动定位代码 → 自动写修复 → 自动写测试 → 自动跑 CI → 自动提 PR → 走灰度 → 看 AB 数据 → 决定是否全量 → 全量后回归 → 关闭工单。

整条链路全可观测、可回溯、可回滚。出问题了你能立刻看到它在哪一步做了什么决策，也能把它任何一步拽回来重做。

这一层和第三层的根本差异是什么？是 AI 终于长出了“手”。 第三层的 AI 还是把球传给人，它定位、它起草、它升级，然后等人。第四层的 AI 自己接住了球，跑完整条赛道。它不只是“识别问题”，还“解决问题”。

但从 dev 跑通到敢上生产，中间有一组没解决的硬问题。

第一是回滚。 Agent 改错了怎么办？一次错误的发版可能意味着百万级的客户资损、监管层面的合规事件、舆情上的风险。这些东西在人写代码的世界里靠 SRE 经验、靠值班默契、靠“我赶紧回滚一下”这种人肉响应。在 Agent 世界里，你必须把这些经验全部写成显式的协议。什么样的指标变化触发自动回滚？多快算“快”？回滚后状态怎么对齐？对齐不了怎么办？

第二是责任归属。 Agent 上线了一个 bug 导致客户损失，谁担责？是审过 PR 的工程师？是部署 Agent 的团队？是公司？这个问题在受监管的场景下尤其要命，因为追溯会要落到具体责任人。监管不接受“AI 干的”这种回答。

我们部门内部为这件事开过一个会，讨论了三个小时，最后没结论。技术上没有任何障碍，组织上没有人愿意签那个名字。

第三是观察成本。 Agent 跑得越自动，人就越看不见它在干嘛。等你发现它在干蠢事的时候，可能已经干了一万次了。这意味着什么？意味着你可能某一天突然收到合规部的电话，告诉你 Agent 三个月前就在持续做一件违规的小事，只是直到今天才被发现。

我之前提过一个想法叫“日志驱动的自治修复闭环”，本质上就是第四层的样子，让生产环境的真实数据直接驱动 Agent 的工作流，人只在关键决策点出现。 但“关键决策点”在哪儿、怎么定义、谁来定义、出了问题谁来背，这些事我们自己也还在摸。

第五层：终极拷问

第五层其实不算一个新能力，更像是一组问题。

它问的是：你的整个企业架构，对 AI 友好吗？

这一层和前四层的根本差异是什么？前四层都是“我们怎么用 AI 干活”，第五层是“我们这家公司，有没有资格用 AI 干活”。

听起来夸张，其实非常具体。拆开来是这么几个拷问。

线上 bug 发生的时候，AI 能不能看到完整的发生过程？ 日志、链路、用户行为、上下文，这些东西是埋好的吗？还是散落在七八个系统里，连人都拼不齐？（这就是我们卡在第二、三层之间的那道坎。）

需求来的时候，AI 能不能知道它的来源和背景？ 是某个客户的具体场景，还是销售为了拿单临时承诺的，还是产品经理拍脑袋？是合规要求的、还是监管下达的、还是高层一句话？这些上下文有没有沉淀到一个 Agent 能读到的地方？还是只存在于某个总监的微信里？

该升级的问题能不能升级？ Agent 有没有跨团队、跨权限、跨工具的“通行证”，还是每到一个边界就被卡住？在金字塔型的大组织里，这一条尤其难，一个权限要走五个审批节点，Agent 走一次要等三天。

代码文档是给 AI 写的吗？ 注意这个问题问的是“给 AI 写”，不是“给后来的人写”。这两件事的标准非常不一样。给人看的文档允许模糊、允许默契、允许“懂的都懂”；给 AI 看的文档必须显式、必须自洽、必须把上下文写完整。那些祖传系统的文档，大部分对 AI 来说是天书。

说到底，第五层是组织问题，跟技术关系不大。

它意味着你公司的每一个流程、每一份文档、每一套权限、每一个工具，都要重新审视一遍：它对 AI 友好吗？如果不友好，前四层的能力都会在这里被打骨折。

我见过太多 AI 项目最后变成了“内部 demo”或者“试点试到没下文”：他们花了大力气把 Agent 的能力做起来，结果发现 Agent 跑不动。业务系统的日志结构是十年前的祖传代码、需求文档堆在三个不同的协作工具里、关键人的判断只存在于他自己脑子里、跨部门的权限要走三周流程才能开通。

Agent 站在那儿，什么都能干，但什么都干不了。

第五层之后：还需要公司这个东西吗？

第五层的拷问到这里其实还没完。如果你真的把组织改造成了“对 AI 友好”的形态，会发生一件比“提效”更深的事：这家公司的人员结构会被彻底重写。

我先抛一个判断：职能划分这件事，可能要从根上改写。

我们今天的公司架构，本质上沿用的是流水线时代的逻辑：把一件大事拆成无数小件，每个小件交给一个专门的人。装配工只负责装配，质检员只负责质检，采购员只负责采购，法务只看合同，合规只看合规，产品只画产品，研发只写代码。

为什么要这么分？因为人的带宽有限。 一个人脑子里能装的上下文是有上限的，精力也是有上限的。让一个人同时做装配、质检、采购，他三件事都做不好。所以越窄、越垂直，人的效率就越高。这是工业革命以来组织设计的第一原理。

但 AI 没有这个约束。

AI 可以并行十件你交给它的事情，不用担心精力问题。它的“带宽”几乎只取决于你给它的上下文够不够、规则定得清不清。这意味着，当一个人手里有了 AI，他能高效处理的事情，从一个窄方向变成了一片广阔区域。

过去要求“深度”，现在要求“广度”。

过去要的是一个领域里钻到底的专家。现在要的是 一专多强的复合型人才：一个对自己主战场理解透彻、同时能 hold 住相邻几个领域、能熟练用 AI 把这几个领域的活儿同时跑起来的人。

这件事对组织架构的冲击是颠覆性的。

人事、行政、采购，本质上都是处理事务流程的部门。在 AI-Native 的公司里，这三个部门可能合并成一个 5 人的“运营中台”，剩下的活儿全是 AI 在跑。

法务和风控，本质上都是在做合规判断和风险识别。这两个部门常常各有上百号人，但底层逻辑是同一套。AI-Native 之后，合并成一个团队没什么不可以。

产研团队最戏剧性。今天我们部门的产品经理、研发、测试、设计、运维，五条线五个 leader 五个汇报关系。你真的把第三、第四层的 AI 跑起来，大量“对齐成本”消失了：产品脑子里的需求可以被 AI 直接翻译成代码草稿，研发改的代码可以被 AI 自动生成测试，测试出的问题可以被 AI 自动定位回需求源头。五条线变成一个“产研一体”的小团队，完全可以做到。

最戏剧性的是：大多数公司其实不需要那么多“科学家”型的专家。深度专业能力依然有价值，但需求量会大幅缩减。一家中型业务线过去需要三十个深度专家，未来可能只需要五个真正顶尖的专家加一群有“广度+AI 杠杆”的复合型人才。

写到这里我必须诚实承认：这件事不会一夜发生。组织重力太大了，流程惯性太重了。但方向是清楚的。未来五年内，你会看到组织架构图变得越来越扁，职能边界变得越来越模糊，岗位描述里“会用 AI 杠杆放大产出”会成为隐含必备项。

这个转变到这里还没结束。再往前推一步，会出现一个更尖锐的问题。

公司本身，还是必要的吗？

经济学里有一个经典的解释，叫“科斯定理”：公司之所以存在，是为了减少一群人在社会上协作时产生的交易摩擦。

意思是，如果你想造一辆车，理论上你可以临时找市场上 100 个独立工人，每个人按合同帮你做一部分。但实际上你不会这么干，因为找 100 个人、签 100 份合同、协调 100 个人的进度、处理 100 次扯皮，这个交易成本高得离谱。所以你成立一家公司，把这 100 个人雇下来，用内部管理代替市场交易，把那些摩擦“内化”了。

公司，本质上是一个降低摩擦的容器。

但如果 AI-Native 真的把组织极度精简了，一个原本 500 人的业务线，变成 50 人的复合团队加一群 Agent，会发生什么？

500 人和社会的摩擦面是巨大的：招聘、培训、绩效、晋升、办公室政治、跨部门协调、合规审计、文化建设。这些“内部摩擦”本身就是巨大的成本，公司这个容器之所以值得存在，是因为它降低的“外部摩擦”比制造的“内部摩擦”更大。

50 人的摩擦面骤然缩小。10 人甚至 1 人的“公司”呢？

当一群人变成一小撮人，这一小撮人和社会之间的摩擦从一片火变成了星星之火。 这个时候，“公司”作为一个降低摩擦的容器，价值在快速衰减。

那 AI-Native 的极致形态，是什么？

可能是一种我们今天还没完全看清楚的形态：少数核心人才，加上一群可调度的 AI Agent，以“项目制”或“协作网络”的形式直接对接市场。 没有金字塔，没有部门，没有那些为了协调几百人而存在的中间层。

听起来像是科幻。但你回过头看每一层的演进：AI 替你写代码，AI 进流程，AI 识别风险，AI 闭环，AI-friendly 组织。每一层都在剥离一些“为了协调一群人”才存在的东西。剥到第五层之后，继续剥下去，你剥的就是公司本身。

我不知道我们这一代人会不会真的看到那一天。但我已经能感觉到方向在哪了。

在一个几千人的组织里推 AI-Native，每往前走一步，都会有一个声音在我脑子里响起来：你正在帮公司变得更高效，还是正在让公司变得更不必要？

这个问题没有答案。我也不打算给一个。但每一个走在 AI-Native 路上的人，迟早要直面它。

写在地图边上

回头看，从第一层到第五层再到那个没编号的拷问，真正在变的是问题的形状，跟技术演进关系不大。

第一层问的是“AI 能不能写代码”；第二层问的是“AI 能不能进流程”；第三层问的是“AI 能不能识别风险”；第四层问的是“AI 能不能闭环”；第五层问的是“组织能不能让 AI 闭环”；第五层之后是“等组织真的变了，公司这个东西还需要存在吗”。

前四层，是单一职能就能推动的事情。第五层不是。第五层要拉上 CEO、CTO、HR、法务、合规、财务一起改造，要重新写流程文档、重新切权限、重新定 KPI、重新定岗位。这件事大部分会被拖，因为又难又看不到短期收益，而且每一次改动都涉及到几十个人的部门利益。

第五层之后那个问题呢？它已经超出了任何单一岗位的职权，也超出了 CEO 一个人能拍板的范围。这是这家公司、这个行业、乃至这一代人要共同面对的问题。

但拖不起。AI-Native 的窗口不会一直开着。当你的对手在第三、第四层稳定运行的时候，你还在第二层加人手填会议纪要，这中间隔的是组织代差，跟技术差距没多大关系。再往前看，当你的对手已经开始重画职能、合并部门、把组织架构图变扁的时候，你还在守着传统的金字塔，这中间隔的就不只是组织代差了，是物种代差。

写到这里我自己也清楚：这张地图画完了不等于路就好走。我们团队就是个例子，第二层的甜头吃到了，被一道叫“上下文”的坎卡了两个季度，dev 里勉强跑通了第三层的雏形，第四层只敢在脑子里推演，第五层的每一个问题都在啃，第五层之后那个问题更是连边都还没摸到。

如果说这张地图能给走在同一段路上的人留下什么，大概只有一句：别等“AI 真的成熟了”再动。等的人不会赢，边走边修地图的人才会。 这句话对组织重力大、流程沉的环境尤其重要，这里的每一步都比小团队慢三倍。你越早动，越早把那些“十年前就该解决”的旧账翻出来还清，在窗口关闭前才有可能站到第三层、第四层的位置上。

每天早上的那 40 分钟批处理，看起来是新工作模式带来的，其实是新组织形态在催着我做出选择。

我每次合上电脑去开会，都会想一个问题：我在管那群机器下属上花的时间，会不会有一天超过我管人的时间？如果会，那我们这家公司的样子，就要重画了。

更深一层的问题是：那张被重画的图，可能压根就不再是“一家公司”。

看完了？说点什么呢

有些公司不会缩小，会直接消失

AI-Native 真正在杀的，不是岗位，是公司。当协作不再昂贵，公司这件事凭什么还要这么大？

什么叫 AI-Native？

代码都是 AI 写的就够了吗？

你以为这就是 AI-Native？早着呢。

第一层：工程师不再手写代码和文档

开会、沟通、定义问题——这些事还在人手上，但写代码这件事整个交给 AI。

这是大多数团队今天讨论的"AI-Native"。但它只是 L1。

第二层：AI 进入团队协作的边缘

会议纪要、内部 Q&A、技术运营的日常支持，不再需要专人去做。

那些"中间状态"的岗位先开始消失。不是被 AI 取代——是这些岗位本身就是协作摩擦的产物，摩擦没了，岗位也就没了。

第三层：AI 进入协作的主流程

自动升级问题，自动 @对应的人，在你的上下文里识别潜在风险和需求点，帮你对齐上下文，找到相关代码，自动实现。

这一步开始有点魔幻了。AI 不再是工具，开始接管"人和人之间的协调"。

第四层：AI 像一个真正的员工

自动找需求、自动实现、自动上线、自动回收、自动 debug、自动线上回归。整条链路可观测、可回溯、可回滚。

到这一层，AI 不再被"分配任务"，而是自己有 KPI、自己会闭环。

第五层：你的基建对 AI 友好吗？

你的基建、代码文档、权限体系、人员配置，是不是真的对 AI 友好？AI 能不能看到线上 bug 的现场？能不能知道一个需求从哪里来、为什么存在？该升级到更高 level 的时候，它能不能自己处理？

最终考验来了：原来一个人管 10 个人，现在一个人管 100 个 agent。你的组织架构做好被革命的准备了吗？

但是——

但走到这里我意识到一件事。

这五层 + 最终考验，全都站在同一个假设上——公司还是那个公司，只是里面的人变成了 agent。工位换成 GPU，组织形态不变。

但凭什么？

科斯，1937

科斯 1937 年讲过，公司之所以存在，是因为市场上的协作摩擦太高——找人、对齐、信任、协调，这些事在公司内部做比在市场上做便宜。

公司是一个吸收协作成本的容器。

当 AI 把协作成本压到接近零，容器的边界就会松动。原来必须在公司内部完成的事，现在可以在市场上完成。原来需要一家百人公司承载的业务，现在 1 个人 + 一组 agent 就够。

所以 AI-Native 真正在问的不是工程链路够不够自动化。是：当协作不再昂贵，公司这件事凭什么还要这么大？

有些公司不会缩小，会直接消失

不是输给了对手。是输给了"这件事不再需要一家公司来做"。

下一波倒下的公司，可能不会有竞争对手出现。它们只是某天发现，自己解决的那个协调问题，已经不再是问题了。

看完了？说点什么呢

你有没有发现一件奇怪的事——AI 这一轮行情里，先涨的是英伟达，然后是台积电，再后来居然是电力公司，最近又轮到了内存。中间这些公司看起来八竿子打不着，但资金每一次都精准命中下一站。这背后藏着一条市场的物理定律。

妖股的浅塘

A 股有一种东西叫"妖股"。

盘子小,业绩一般,故事讲得马马虎虎,突然有一天就涨起来了。第一天涨停,第二天涨停,第三天还在涨停。龙虎榜上挂的是几个熟悉的游资席位,散户在股吧里互相打气,分析师写不出研报,因为找不到基本面理由。

A 股有一套专门的玩法叫"龙头战法"。别管这家公司值不值这个价,先把龙头买上,大家一起推。推不动了再跑,跑得快的赚钱,跑得慢的接盘。

按教科书的说法,定价不合理的股票一定会被市场纠正。可在 A 股,这种纠正经常不会及时发生。一个明显高估的妖股可以连续涨十几个板,把所有"理性"的人都甩在后面。

美股是另一种生态。没有涨跌幅限制,没有龙虎榜,做空机制健全。一个被高估的故事今天涨 30%,明天就有 Hindenburg 或 Citron 出做空报告,后天跌回去。绝大多数撑不过一个季度,财报一出来就现原形。

但在美股,真正经得起检验的故事可以涨很多年。英伟达从 2023 年初到 2024 年底涨幅超过 8 倍,中间没有出现过 A 股那种"游资接力—散户接盘—一地鸡毛"的剧本。

同样是"共识"两个字,在两种环境里的命运完全不一样。

共识有两种

把这件事看明白之后,会发现市场上的"共识"其实分两种。

一种是真正的共识。基于基本面,被反复验证,被大量交易筛选过。

一种是短期的共识。大家一时半会都这么想,但没经过任何实质性检验。

谁会赢,取决于市场的水深。

水越深的市场——参与者越多,信息流通越快,套利成本越低——真正的共识越容易胜出。价格一旦偏离基本面,就会有人下场套利,把它拉回来。

水越浅的市场,盘子小,做空难,散户多,资金集中,短期共识可以反复战胜真正的共识。反向力量不够,纠错就发生不了。A 股妖股能炒起来,根本原因在这里。

学术上有个对应理论。Shleifer 和 Vishny 在 1997 年提出"套利的局限",说的是即使理性的套利者知道一个价格是错的,也未必下场修正。他们管的是别人的钱,前期亏损会被赎回。Abreu 和 Brunnermeier 在 2003 年把这件事推得更远:所有人都知道是泡沫,但每个人都在等别人先动手,结果泡沫可以维持很久。

更反直觉的是 Brunnermeier 和 Nagel 用对冲基金持仓数据证明的事。互联网泡沫期间,对冲基金选择骑着泡沫一起涨,而非做空它。理性的人,在浅水里,会选择和短期共识共谋。

这是第一层观察。

真共识是怎么浮出来的

把这个透镜架到美股 AI 这一轮上,能看到一些东西。

英伟达是过去三年里被全球最深的资金池、最严苛的做空机制、最活跃的卖方分析师反复检验过的一个共识。市值过 3 万亿美元的时候做空机构没有放过它,财经媒体把它的客户结构、库存周期、技术壁垒拆得一清二楚。最后这个共识没有被打掉,反而越打越实。

真正的共识就是这样长出来的。它的可信度建立在它经受住了被打掉的可能。

接下来发生的事情才是有意思的。资金没有停在英伟达身上。

第二棒是 Palantir 和模型层。PLTR 在 2024 年涨了 300%。但模型公司的故事很快遇到瓶颈,大模型本身的差异化在收窄,OpenAI、Anthropic、Meta 都能做出差不多水平的模型,资金开始往再下一棒找。

第三棒是电力。Vistra 在 2024 年涨幅超过 250%,Constellation Energy 涨了 130%。这是最戏剧性的一棒。传统上被当成"债券替代品"的公用事业股突然变成了成长股。Constellation 把 1121 兆瓦的核电站全部卖给了 Meta,Talen Energy 把 960 兆瓦的园区供电卖给了 AWS。一个二十年都在睡觉的板块,突然被 AI 的故事激活了。

第四棒是内存。SK 海力士、美光,HBM3E 在 2024 年提前一年售罄,HBM4 在 2025 年提前半年量产。到 2025 年底,普通 DRAM 的供应商库存已经从 17 周降到 2-4 周,三星 9 月以来 DRAM 报价上调了 60%。

每一棒都涨了一波,每一棒涨完之后,资金都没有停下。

资金有它自己的方向

这条接力链条背后有一个清晰的逻辑。

当前一棒的共识被充分定价之后,资金会沿供应链找下一个尚未被充分定价的瓶颈。这是市场效率本身的副产品。

英伟达的 alpha 被卖方分析师全部挖掘完之后,边际资金的最高期望收益率出现在那些"还没有被讲透"的环节。资金会自动往那里流。流过去之后,那个环节也会被讲透,alpha 也会消失,资金又往下一站去。

这个现象在金融学里叫资金扩散,或者主题内轮动。

Foucault、Pagano 和 Röell 在《Market Liquidity》里有个干净的描述:市场参与者并非时时同步在场,订单流是信息和噪声的复杂混合,共识价格只能在交易过程中逐渐浮现。每一个共识的形成都需要时间和反复交易。

更具体的实证来自 Chordia、Roll、Subrahmanyam 在 NYSE 数据上的工作。流动性越好的市场,订单失衡对未来收益的预测性越弱,价格越接近随机游走基准。流动性激发套利活动,套利活动反过来加速共识的形成。

把这两件事拼起来:在足够深的市场里,每个真实的瓶颈都会按自己的节奏被定价;定价完成之后,资金沿供应链向上游或下游扩散;扩散到下一个瓶颈,重新开始一轮定价。

台积电的 CoWoS 产能 2024 年被订满,电力公司的 PPA 长协被签满,HBM 的产能被预订到 2026 年。每一个瓶颈环节都在以"被资金提前定价"的方式完成它的产业角色。

A 股的妖股是浅水里短期共识压过真正共识。美股的 AI 接力是深水里真正共识逐站浮现。同一个金融学原理在两种环境里跑出了相反的方向。

链条的下一棒

按这个逻辑往前推,下一棒应该满足三个条件。

第一,是 AI 链条上真实的、还没消失的物理瓶颈。第二,还没有被主流叙事完全占据。第三,在一个有足够流动性的市场里。

按这个标准看,光通信和液冷已经在定价中。Lumentum、Coherent、Vertiv 这些名字已经出现在所有卖方报告里,InvestorPlace 在 2026 年 3 月明确把它们点名为"下一棒"。当主流财经媒体都开始这样写的时候,洼地阶段就过去了。ASIC 也在快速被定价,Broadcom 因为 Anthropic 的 3.5 GW TPU 订单和 Google 的合作直接重估,Marvell 拿到英伟达 20 亿美元的战略入股。

仍在洼地里的,可能有几个方向。

电网设备和变压器。GE Vernova 涨了 200%,但西门子能源、Hitachi Energy、Hubbell 这些被 GE Vernova 光环遮住的玩家,故事还没被讲透。美国变压器的交货周期已经长达 2-4 年,Eaton 的第三家变压器工厂要到 2027 年才投产,弗吉尼亚州的电网接入排队已经排到 2028 年。

燃气轮机。订单已经预订到 2028 年。市场对它的注意力集中在 GE Vernova 身上,三菱重工和西门子能源在欧洲和日本市场没有被同等估值。

中游天然气。这是最隐蔽的一棒。Energy Transfer、Williams、Enbridge 在做一件事——在数据中心现场建设 behind-the-meter 的天然气发电,让科技公司直接绕过拥堵的公共电网。这个故事完全没有被贴上 AI 的叙事,但它是 AI 时代电力供应的实质性解决方案。

以上只是个人观察,不构成投资建议,市场风险自负。

物理定律

回到开头的对比。

A 股的妖股说明一件事:浅水里价格被资金的方向推动,基本面影响有限,涨得快本身不构成持有的理由。

英伟达说明另一件事:深水里价格最终会被基本面纠正,纠正的速度取决于流动性、做空机制、信息透明度。一个真正的共识必须经历过被攻击、被审视、被打压的过程。

AI 的接力链条说明第三件事:在深水里,资金不会停在某一个共识上,它会沿着产业链扩散,逐站把所有真实的瓶颈定价完。

三件事拼起来就是市场的物理定律:资金永远往洼地流动。深水的洼地会按基本面被填平,浅水的洼地会被情绪反复填平再排空。

理解这条定律的用处,在于知道自己站在哪一种水里,然后决定要不要下场。

A 股的浅水里,你跟的是游资的脚步,赚的是接力棒的速度。美股的深水里,你跟的是产业链的方向,赚的是基本面浮现的时间差。前者比的是手快,后者比的是眼准。

弄清楚自己在哪一种水里,比押中下一棒更重要。

看完了？说点什么呢

生产力的发展不管人的死活，但人可以管自己的死活

上个月我跟一个做外贸的朋友吃饭，他说公司刚裁掉了整个客服团队，换成了 Agent。十二个人，一夜之间变成了一笔月费。他不是冷血，他算过账：Agent 的响应速度是人的 8 倍，客户满意度反而上升了 15%。他说这话的时候表情很复杂，因为被裁的人里有一个跟了他六年的老员工。

我当时没接话。因为我自己也在经历类似的事。我做了九年工程师，过去一年眼看着身边的岗位一个接一个被 Agent 吃掉。不是未来的事，是正在发生的事。

这篇文章想讨论的问题很直接：当技术进步快到社会来不及反应，会发生什么？

效率这辆车不会停

先说一个让人不舒服的事实：讨论效率该不该推进，没有意义。

这就像两只蚂蚁讨论被车轮压的时候怎么更舒服一点。车不会因为蚂蚁的讨论而停下来。人类社会的发展一直是效率驱动的，所有试图阻挡效率的力量，最后都被碾过去了。手工织布挡不住珍妮纺纱机，马车夫挡不住汽车，实体书店挡不住电商。

但效率的推进方式是可以选择的。

英国工业革命初期，童工遍地，工人每天干 16 个小时，肺里全是煤灰。效率确实提升了，代价是一整代人的健康和尊严。后来工会运动起来了，《工厂法》通过了，劳动保障制度建立了。这些东西没有阻碍效率，它们让效率的推进不至于把社会撕碎。

所以真正的问题从来不是"要不要效率"，而是"效率碾过来的时候，谁来接住被碾的人"。个体要拼命适应，社会要拼命兜底。 这两件事不矛盾，缺一不可。

时间差在缩短

每次技术革命都有一个时间差：技术跑在前面，制度在后面追。

蒸汽机 1760 年代开始普及，英国第一部《工厂法》1833 年才通过，中间隔了将近 70 年。电气化从 1880 年代铺开，成体系的劳动保障到 1930 年代才成型，大约 50 年。互联网 1990 年代爆发，GDPR 2018 年才落地，间隔 20 多年。

规律很明显：每一轮技术革命，制度追赶的时间在缩短。但技术加速的幅度更大。

Agent 的扩散速度比以上任何一次都快。蒸汽机需要建工厂，电气化需要铺电网，互联网需要拉光纤。Agent 需要什么？一个 API key。部署成本几乎为零，扩散速度几乎没有物理限制。

这意味着这一轮的时间差可能被极度压缩。技术用两三年完成的颠覆，制度可能需要十年才能回应。中间这段真空期，就是社会震荡最剧烈的时候。

人往哪去

过去一百年，就业市场有一个隐性的"吸纳器"机制。

制造业自动化了，工人去了服务业。收银员、餐厅服务员、快递员，这些岗位吸纳了大量从工厂出来的人。服务业开始萎缩的时候，一部分人又流向了知识工作。数据标注、内容运营、初级编程，这些新岗位又接住了一波人。

每一次技术革命消灭一批岗位，同时创造另一批岗位。这个循环运转了很久，久到很多人以为它是自然规律。

Agent 正在打破这个循环。

它吃掉的不是某一层岗位，而是跨层的。客服、数据分析、初级编程、内容撰写、法律文书、财务审计，这些分属不同行业、不同层级的工作，Agent 一口气全能做。以前你从制造业出来，至少还能去服务业。现在服务业和知识工作同时被压缩，人往哪去？

我认识一个做了八年翻译的朋友，去年底失业了。她试过转行做 AI 提示词工程师，学了三个月，发现这个岗位本身也在被 Agent 替代。她现在在考虑开一家面包店。我不确定这是降级还是转型，但我知道这种"被挤出来又找不到新容器"的感觉，正在越来越多人身上发生。

一大批人失去收入来源，这件事必须被解决。不是因为善良，是因为不解决就会掀桌子。社会矛盾积累到临界点，它会以任何你想不到的方式爆发。

UBI 和那些创可贴

解决方案已经有人在想了。

Sam Altman 提了一个思路：不对劳动征税，改对 AI 公司的算力和资本征税，建立"美国公民权益基金"，让每个公民从 AI 创造的财富中分一杯羹。 英国投资部长在公开讨论 UBI（无条件基本收入）的可行性。斯坦福 HAI 发了支持 UBI 的重量级论文。2026 年美国企业研究所做了一项元分析，涵盖 122 个 UBI 试点项目，其中 30 个随机对照实验显示净就业效应为 +0.8%，也就是说拿了基本收入的人并没有躺平，反而略微更积极地参与了劳动市场。

这些数据让人稍微安心了一点。但我越想越觉得，UBI 解决的只是"钱从哪来"的问题。更大的问题依然存在。

过去两百年，整个社会运转的底层逻辑是一条链：你出卖劳动，获得收入，参与消费，推动经济循环。你的社会身份、你的人生意义、你和社会的连接方式，全部挂在"劳动"这个钩子上。你是工程师、是医生、是教师、是司机，这些标签定义了你是谁。

当劳动不再被需要，这个钩子就断了。

你每个月收到一笔 UBI，够吃够住。然后呢？你是谁？你的一天怎么过？你跟这个社会的关系是什么？这些问题听起来很哲学，但它们会以非常具体的方式爆发出来：抑郁、成瘾、社区瓦解、极端思想蔓延。不是猜测，是每一个长期高失业率地区都在发生的事。

生产关系永远在追赶

马克思说过一句被引用了无数次的话：生产力决定生产关系。翻译成大白话就是：你用什么方式生产，决定了社会怎么组织。

Agent 时代的生产力结构跟以往完全不同。以前的机器替代体力，人还有脑力。现在 Agent 替代脑力，人剩下的只有意图和判断。生产力越高，需要的人类劳动越少，但劳动是绝大多数人获取收入的唯一方式。这个矛盾不解决，社会撕裂只会加剧。

各个社会正在摸索不同的路径。美国倾向于放任市场，用低福利维持一个庞大的底层人口，不优雅但便宜。欧洲走高福利高税收的路线，已经有国家在讨论对 Agent 使用征税。东亚更习惯国家主导产业转型，效率最高但容错最低，一旦方向判断错了代价巨大。

没有哪条路被验证过。我们都在做实验。

我个人觉得最终的方向可能是某种混合体：UBI 提供基本保障，同时把 Agent 的使用权民主化，让每个人都能调用 AI 的生产力去创造价值，而不是只有大公司才玩得起。就像互联网早期只有大机构才能上网，后来变成人人都有智能手机一样。

教育是最先该动的齿轮

在所有需要重写的社会契约里，教育可能是最紧迫的一个。

现在的教育体系还在教人"掌握知识和技能"。但 Agent 最擅长的就是知识和技能。你花四年学会的东西，Agent 在训练阶段就已经掌握了，而且比你更精确、更全面、不会遗忘。

教育的重心需要从"教答案"转向"教提问"。从教你怎么解一道题，变成教你怎么发现这道题值不值得解。从教你用什么工具，变成教你怎么判断工具给出的结果对不对。

我自己带过几个实习生，最近一个让我印象很深。他的代码能力一般，但他特别擅长一件事：把一个模糊的商业需求拆解成 Agent 能执行的任务序列。这个能力在两年前根本不存在这个品类，现在它可能是最值钱的技能之一。

没有人教过他这个。他是自己在实践中摸出来的。这说明教育体系还没有跟上，但也说明人有自我适应的能力。

浪来了，搭船还是等船

写到这里我想诚实地说：我不知道社会契约最终会被重写成什么样子。UBI 会不会普及？Agent 使用权会不会民主化？教育体系会不会转型成功？这些问题我给不了答案。

但有一件事我比较确定：等着制度来救你，大概率来不及。

制度的调整需要共识，共识需要时间，时间是 Agent 时代最稀缺的东西。蒸汽机时代你有 70 年的缓冲期慢慢调整，这一轮你可能只有 5 到 10 年。

作为个体，能做的事情很具体：保持对 Agent 的手感，不断练习"定义问题"而非"解决问题"的能力，同时关注社会制度层面的变化，在有机会发声的时候发声。

作为社会，需要做的事情也很具体：加速 UBI 的试点和验证，推动 AI 使用权的普惠化，重新设计教育体系的评估标准。这些事情每晚一年，被甩在后面的人就多一批。

生产力的发展确实不管人的死活。但人可以管自己的死活。前提是你动得够快，同时推着制度也动起来。

看完了？说点什么呢

同一个 AI 模型，换个壳，表现天差地别——壳就是 Harness

从一个事故说起

前两篇分别讲了 AI 怎么"看"（Prompt 和 Context）和怎么"做"（MCP 和 Skill）。到这里，拼图看起来快完整了：你把信息喂给 AI，AI 想好了，通过工具去执行，执行还有标准流程可以遵循。

但我最近碰到的一件事，让我意识到中间缺了一块关键拼图。

我用 AI 帮一个项目做重构——把一批旧的 API 接口迁移到新的路由结构。我给了它清楚的 Context，配好了 Skill，MCP 也接上了代码仓库。它开始干活了。前几步都很顺利：识别旧路由、创建新文件、迁移逻辑。

然后它自己做了一个判断：它认为有些旧的测试文件"已经不需要了"，直接删掉了六个测试用例。

从 AI 的角度看，这个判断不是没有道理——那些测试确实是针对旧路由写的。但它不知道的是，其中三个测试覆盖了一些边界条件的回归检测。删掉之后，我们的持续集成就裸奔了。

问题出在哪？

不在 Prompt——我的指令很清楚。不在 Context——它看到了所有相关文件。不在 MCP——工具调用本身没问题。不在 Skill——操作流程是对的。

问题在于：谁来决定 AI 可以删文件？谁来设定"做到这一步要停下来问我"？谁来管理这整个循环的节奏和边界？

什么是 Agent

在讲解决方案之前，先定义一个贯穿本篇的核心概念。

Agent 是什么？

一句话： 一个能感知环境、自主决策、采取行动的 AI 系统。

跟传统程序的区别： 传统程序是线性的——你写好代码，它按顺序执行，遇到分支按条件走，不会自作主张。Agent 不一样。你给它一个目标（"重构这批 API"），它会自己拆解任务、规划步骤、在执行过程中根据结果调整策略。它有"主动性"。

组成： 一个 Agent = Prompt + Context + MCP + Skill + Harness。前四个概念前两篇已经讲过，都是组件。Harness 是把这些组件编排在一起的东西，也是今天要讲的重点。

一个判断标准： 如果你只是打字提问、AI 只是回复文字，那是对话。如果 AI 能自主决定"下一步做什么"、能调用工具去执行、能根据执行结果调整计划——那就是 Agent。

开头那个事故，正是因为 AI 在以 Agent 模式工作：它不只是回答我的问题，而是在自主地规划、执行、做判断。问题不在于它有这个能力，而在于没有人控制它用这个能力的边界。

Harness：包在 AI 外面的那层壳

Harness 是什么？

一句话： 包裹在 AI 模型外面的应用框架，负责编排模型的输入输出、管理工具调用、控制执行流程。

词源： Harness 直译是"马具"——套在马身上让骑手能控制方向和速度的那套装置。马有自己的意志和力量，但骑手通过缰绳和马鞍来引导它。

跟 Web 框架的对比： 如果你用过 Express.js 或 Spring Boot，Harness 在 AI 应用中的角色跟它们类似。Express 定义了路由规则、中间件管道、错误处理——你的业务逻辑运行在这个框架里面。Harness 也一样：它定义了 AI 的输入怎么组装、输出怎么解析、工具调用怎么执行、异常怎么处理。你的 AI 模型运行在这个框架里面。

一个具体的 Harness 每一轮对话在做什么？以 Claude Code 为例：

1. 启动阶段： 加载 System Prompt（CLAUDE.md）、Memory、MCP 配置、Skill 列表
2. 组装阶段： 收到你的消息后，把上面这些东西跟你的输入组装成一个完整的 API 请求，发给模型
3. 解析阶段： 模型返回结果。如果结果是纯文字，直接显示给你。如果里面包含工具调用请求（Function Calling），进入下一步
4. 执行阶段： Harness 执行工具调用——读文件、写文件、调用 MCP Server、执行命令
5. 反馈阶段： 把工具执行的结果传回给模型，模型基于新信息继续思考
6. 循环： 回到步骤 3，直到模型不再请求工具调用，给出最终回答

模型在这个循环里是什么角色？它是其中一个环节，不是全部。 这个认知非常重要。同一个 Claude 模型，在 claude.ai 网页版里只能聊天，在 Claude Code 里能读写文件、执行命令、调用 MCP。模型没变，Harness 变了。

这就是为什么标题说"同一个模型换个壳，表现天差地别"。壳就是 Harness。

开环 vs 闭环：一个 1948 年就想明白的道理

理解了 Harness 做什么之后，来看它为什么跟传统框架有本质不同。

先用一个日常例子感受"开环"和"闭环"的区别：

开环控制——烤面包机。 你把面包放进去，拧到 3 分钟，烤面包机就加热 3 分钟。不管面包是不是已经糊了、是不是还太软，它不看结果，到时间就停。你的指令决定一切。

闭环控制——恒温器。 你设定目标温度 25 度。空调开始制冷。温度传感器持续测量房间温度，当温度降到 25 度时，空调自动停止；当温度升到 26 度时，空调再次启动。系统在持续感知结果，并根据结果调整行为。

开环 vs 闭环

开环： 下达指令 → 执行 → 结束。不看结果。传统程序大多是开环的——你调用一个函数，它执行完返回，不存在"根据结果再决定做不做"的过程。

闭环： 设定目标 → 执行 → 观察结果 → 计算偏差 → 调整行动 → 再执行。持续感知和调整。

Harness 为什么必须是闭环的？ 因为 AI 模型是非确定性的。传统框架包裹的是确定性代码——bug 是偏差的唯一来源，消灭 bug 就消灭了偏差。但 AI 模型天生就会产生偏差。你没法消灭偏差，只能管理偏差。管理偏差就需要闭环：输出 → 检查 → 必要时干预 → 继续。

这个思路不是新发明。1948 年，数学家维纳出版了《控制论》，核心问题就是：对有自主行为的系统实施有效治理。方法论就是闭环反馈控制。78 年后我们在 AI 工程里重新遇到了同一个问题。

回到开头那个删测试文件的事故。解决方案不是写更好的 Prompt，也不是调模型参数。解决方案是在 Harness 层加一条规则：当 AI 要删除文件时，先暂停，问我一句。 五分钟配置，从此没再出过事。

使用 Harness 的三个层次

理解了概念之后，你会发现自己处在三个层次之一：

第一层：用现成的 Harness。 ChatGPT、Claude.ai、Gemini——都是别人搭好的 Harness，你只需要打字。绝大多数人在这一层，完全没有问题。

第二层：配置现有的 Harness。 这是产出比最高的层次。以 Claude Code 为例：

• 写 CLAUDE.md 告诉 AI 你的项目背景和工作规范（配置 System Prompt）
• 接入 MCP Server 让它能访问外部服务（扩展能力）
• 安装 Skill 让它遵循标准流程（固定做事方式）
• 设置 hooks——在特定操作前后触发自定义逻辑，比如"每次提交代码前自动跑测试"、"删除文件前弹出确认"（设置安全边界）

这些配置加在一起，就是在调整 Harness 的行为。你不需要从零写一个框架，只需要在现有框架里拧几个旋钮。

第三层：从零构建 Harness。 自己写模型 API 调用、工具执行、上下文管理、错误恢复、并发控制。绝大多数团队不需要走到这一步，但知道它的存在有助于理解整个画面。

Agentic Engineering：不是技术问题，是信任问题

Harness 回答了 how——怎么控制一个自主系统。但在回答 how 之前，有一个更根本的问题需要先回答：你到底想让这个系统自主到什么程度？

Agentic Engineering 是什么？

一句话： 一种设计哲学，关心的核心问题是：AI 系统应该自主到什么程度。

跟 Harness 的关系： Harness 是实现手段（怎么控制），Agentic Engineering 是目标设定（控制多少）。你先回答"我要造一个多自主的系统"，再设计"怎么控制它"。二者不是递进关系，而是不同维度。

核心张力： 自主性越高，效率越高，但风险也越大。自主性越低，越安全，但你得花更多时间盯着它。最优解不在两端，而是在中间某个位置——而且这个位置因场景而异。

Agentic Engineering 涉及的决策，都不是纯技术问题：

自主决策边界。 AI 可以自己改代码吗？可以删文件吗？可以花钱调用付费 API 吗？可以代表你给同事发消息吗？传统系统用权限模型（比如 RBAC）解决这类问题：角色和权限写死在配置里。但 Agent 的决策是动态的、语义级的——它不是"调了一个没权限的 API"，而是"做了一个看起来合理但实际上不该做的判断"。你没法用一个权限表穷举所有可能的判断。

错误累积。 一个 10 步任务，如果第 3 步出了偏差，后面 7 步都建立在错误基础上。传统系统用事务回滚解决类似问题——数据库操作出错了，回滚到之前的状态。但 Agent 的错误是语义级的——它把一段代码重构"错"了，你怎么回滚一个"判断"？

人机信任。 Agent 做完一个复杂任务，你怎么验证结果？如果每一步都检查，那跟自己做有什么区别？如果不检查，风险谁承担？这不是一个技术选择，而是一个需要根据具体场景反复校准的判断。

六个概念，一张图

三篇入门文章，六个概念，到这里全部讲完了。最后把它们的关系画在一起。

从下往上看——这是大多数人的学习路径：

从上往下看——这是设计者的思考路径：你先回答"要造多自主的系统"（Agentic），再设计"怎么控制"（Harness），再选择"用哪些组件"（Context + MCP + Skill），最后落到"每一步具体说什么"（Prompt）。

两个方向都对。实际工作中大多数人从下往上走，碰到问题才往上追。重要的是知道上面还有东西——不至于在 Prompt 层死磕一个本该在 Harness 层解决的问题。

从这里开始

如果你读到这里还没有动手，建议从第二层开始：挑一个你常用的 AI 工具，花半小时配置它的 Harness。写一个系统配置文件，装一个 MCP Server，或者创建一个 Skill。你会发现，调整 AI 的工作环境比调整你说的话，效果来得快得多。

然后观察一下：你愿意让它自己做多少决定？你在哪个点开始不放心？

那个不放心的点，就是你的 Agentic Engineering 实践的起点。

这是 AI 工程入门系列的第三篇。如果你已经理解了 Harness 和 Agentic Engineering 的区别，推荐继续阅读进阶篇《Harness 与 Agentic Engineering：控制一个会自己做决定的系统》，那篇从控制论的角度深入讨论了闭环设计、错误累积的应对策略，以及多 Agent 协作的挑战。

看完了？说点什么呢

AI 什么都懂，但什么都做不了——直到有人给它接上手

AI 的三堵墙

上一篇讲了 Prompt 和 Context Engineering：怎么跟 AI 说话，怎么布置它走进的房间。但看到信息是一回事，能做事是另一回事。

我最近碰到一个很能说明问题的场景。我对 AI 说："帮我查一下下周的日程，看看有没有冲突，然后把结果发给同事。"三件事，每件单独拿出来都不复杂。但 AI 做不了任何一件。

不是它不够聪明。是它有三个先天的硬限制：

AI 的三个先天限制

1. 知识有截止日期。 AI 的知识来自训练数据，而训练数据有一个截止时间。2026 年 4 月训练完的模型，不知道 2026 年 5 月发生了什么。你问它"昨天的新闻"，它答不上来。

2. 不能执行动作。 AI 只能生成文字。它可以"写出"一段发邮件的代码，但它不能真的发那封邮件。它可以"建议"你删除某个文件，但它不能真的去删。生成文字和执行动作之间，有一条不可跨越的线。

3. 不能访问私有数据。 你的日历、邮箱、公司内部文档、代码仓库——这些都在 AI 的训练数据之外。你不给它，它就看不到。

你可以把 Prompt 写得再完美、Context 布置得再周全，这三堵墙就在那里。要打破它们，需要一种全新的机制。

Function Calling：AI 学会了"调用工具"

在讲 MCP 之前，先理解一个前置概念：Function Calling（函数调用），也叫 Tool Use（工具使用）。

传统的 AI 对话是这样的：你说一句话，AI 回一段文字。输入是文字，输出也是文字。但从 2023 年开始，主流 AI 模型多了一种能力：它可以在回复中声明自己想要调用一个外部函数。

举个例子。你问 AI "今天北京天气怎么样？"，AI 不直接编造一个答案，而是返回类似这样的结构：

{
  "function_call": {
    "name": "get_weather",
    "arguments": {"city": "Beijing"}
  }
}

注意，AI 没有真的去查天气。它做的事情是：看了你的问题，判断需要查天气，然后"说出"了它想调用哪个函数、传什么参数。 真正去调用天气 API、拿到结果的，是包裹在 AI 外面的应用程序。应用拿到结果后，再把结果传回给 AI，AI 基于真实数据生成最终回答。

Function Calling 是什么？

一句话： AI 不只能生成文字，还能"说出"它想要调用哪个外部工具。

工作原理： 你预先告诉 AI "你有这些工具可以用"（一个函数列表及其参数说明），AI 在回答问题时会自主判断是否需要调用某个工具，并输出结构化的调用请求。实际执行由外部程序完成，结果再反馈给 AI。

关键点： AI 并不"执行"任何东西。它只是做出"我需要调用这个工具"的判断，然后用结构化格式表达出来。它从一个只能说话的嘴，变成了一个能指挥别人动手的大脑。

Function Calling 打破了 AI 的第二堵墙（不能执行动作）和第三堵墙（不能访问私有数据）。但它引出了一个新问题。

新问题：N x M 的爆炸

有了 Function Calling，AI 理论上可以调用任何外部服务。但实践中，每接入一个新服务都需要写一套对接代码：认证怎么做、API 怎么调、返回数据怎么解析、错误怎么处理。

如果你想让 AI 能查 Google 日历，写一套。想让它再能查 GitHub，写一套。想加上 Gmail，又一套。想加上 Slack、Notion、Jira……

N 个 AI 应用想要对接 M 个外部服务，就需要 N x M 套对接代码。做过企业系统集成的人对这个问题太熟悉了——这是一个经典的组合爆炸。

MCP：一套标准协议

MCP（Model Context Protocol，模型上下文协议）就是为了解决这个问题而设计的。

MCP 是什么？

一句话： 一套标准协议，让 AI 应用能以统一的方式连接各种外部服务。

跟 RESTful API 的对比： 如果你理解 RESTful API，你已经理解了 MCP 的大部分。RESTful API 定义了客户端和服务器之间通过 HTTP 通信的规范——用 GET 读、POST 写、统一的 URL 路径、JSON 格式的数据。MCP 做的事情类似：定义了 AI 应用和外部服务之间通信的规范。区别在于，RESTful API 是给程序员写的代码调用的，而 MCP 是给 AI 模型"理解和使用"的。

解决了什么问题： 有了 MCP，Gmail 只需要提供一个 MCP Server，任何支持 MCP 的 AI 客户端都能直接连上。N x M 的组合爆炸变成了 N + M——每个 AI 应用只需要实现 MCP Client，每个服务只需要实现 MCP Server。

用一个更生活化的类比：2000 年前后的电脑，键盘用 PS/2 口，打印机用并口，鼠标用串口，每种设备一种接口。USB 出来之后，一个口通吃。MCP 做的是同样的事，只不过连接的不是硬件设备，而是软件服务。

MCP 的三个组成部分

MCP 协议里有三个角色，理解它们就理解了整个通信链路：

1. MCP Client（客户端）

就是 AI 应用这边的接口层。比如 Claude Code、Cursor、ChatGPT——它们作为 AI 应用，内部实现了 MCP Client，能够跟任何 MCP Server 对话。你作为用户通常不直接接触 Client，它是应用内置的。

2. MCP Server（服务器）

外部服务提供的标准化接口。每个想被 AI 访问的服务（Gmail、GitHub、你的内部数据库）都可以包装成一个 MCP Server。它负责：告诉 AI "我能提供哪些工具"、接收 AI 的调用请求、执行实际操作、返回结果。

3. Protocol（协议本身）

Client 和 Server 之间通信的规则。MCP 用的是 JSON-RPC 格式——如果你做过 Web 开发，这就是一个非常标准的请求/响应协议，没有额外的学习成本。

协议里定义了三种东西可以被 AI 使用：

• Tools（工具）： AI 可以执行的操作，比如"发送邮件"、"创建 GitHub Issue"
• Resources（资源）： AI 可以读取的数据源，比如"最近的会议记录"、"项目文档"
• Prompts（提示模板）： 预定义的交互模板，比如"用这个格式做代码审查"

MCP 的现实：标准能不能统一

技术设计是一回事，生态是另一回事。

USB 之所以成功，不只是因为技术好，更因为 Intel、微软、苹果这些巨头都站到了同一边。如果当年每家推各自的接口标准，今天你桌上可能还是一堆不同的线。

MCP 目前的势头不错——由 Anthropic 发起，多家 AI 厂商在跟进。但生态博弈远没有结束。这里没有确定的结论，只是提醒：一个协议的成功，技术只占一半，另一半是政治。

还有一个更实际的问题是安全。MCP 让 AI 能执行真实操作了——发邮件、改文件、操作数据库。一旦出了差错，后果不只是"回答了一个错误答案"，而是可能真的做了一件不该做的事。能力越大，风险越大。这个问题后面讲 Harness 的时候会进一步展开。

从"能做"到"做对"：为什么还需要 Skill

现在 AI 有手有脚了。但有手有脚不等于会干活。

让我用一个具体场景来说明。假设你让 AI 帮你把一篇 Markdown 文章发布到微信公众号。AI 有了 MCP，理论上能调用公众号的 API。但这个任务里有一堆细节：

• 公众号的 HTML 渲染器不支持某些 CSS 属性（比如 flexbox）
• 图片链接必须是 HTTPS，而且域名必须在公众号后台白名单里
• 正文里的代码块需要特殊处理，否则在手机上显示会错乱
• 封面图有特定的尺寸和格式要求

这些规则 AI "大概知道"一些，但不全、不准。如果你每次都在 Prompt 里把这些细节写一遍，不仅低效，而且容易遗漏——上次记得的细节这次可能忘了。

Skill 是什么？

一句话： 写给 AI 的标准操作手册，把"怎么把某件事做对"固定下来。

跟 Runbook/SOP 的对比： 运维领域有一种东西叫 Runbook（操作手册）或 SOP（标准操作流程）。服务挂了？第一步检查什么，第二步重启什么，第三步通知谁，每一步的前置条件和检查点都写得清清楚楚。Runbook 不是教你运维知识——它假设你已经会了，只是把"这件特定的事怎么做"钉死。Skill 做的是同样的事，只不过读手册的人从运维工程师变成了 AI。

关键洞察： Skill 不是在教 AI 新能力。AI 已经"大概会做"大部分事情。Skill 解决的是把"大概能做"变成"确定能做对"。差别在细节。

一个 Skill 的基本结构长这样：

---
name: publish-to-wechat
trigger: 当用户要求发布公众号文章时
---

## 步骤

1. 将 Markdown 转换为公众号兼容的 HTML
2. 检查所有图片链接，确保是 HTTPS 且在白名单域名
3. 如果有代码块，用 
 包裹并添加行内样式
4. 调用公众号 API 创建草稿
5. 返回草稿预览链接供用户确认

## 约束

- 不使用 flexbox 或 grid 布局
- 封面图尺寸：900x383px
- 正文宽度不超过 600px
看起来很简单。但这种"简单"正是它的价值——它把散落在你脑子里的经验沉淀成了一个可重复执行的流程。你修了一个 bug，在 Skill 里加一条规则，以后所有使用这个 Skill 的场景都受益。
Prompt、Skill、代码：三者的区别
到这里你可能会问：Skill 跟直接写代码有什么区别？跟写一个好的 Prompt 又有什么区别？




Prompt
Skill
代码



生命周期
一次性，说完就没了
持久化，版本管理，可分享
持久化，版本管理，可分享


执行者
AI 解读并执行
AI 解读并执行
机器精确执行


灵活性
高，每次可以不同
中，框架固定但 AI 可在框架内灵活应对
低，严格按代码逻辑执行


适用场景
一次性任务、探索性对话
反复执行的标准流程
需要精确控制的逻辑


用一个公式概括：Skill = 通用能力 x 特定约束 x 可重复执行。
Prompt 是一次性指令。代码是精确到每一步的确定性程序。Skill 在两者之间——它用自然语言定义流程和约束，但把具体执行的灵活性留给 AI。当某个步骤的细节变了（比如公众号 API 更新了），你改 Skill 里的一行描述就行，不需要重写代码。
MCP + Skill：一个解决能不能，一个解决对不对
把两个概念放在一起看：
MCP 解决的是"能不能做"。 AI 能不能访问你的日历？能不能读取 GitHub 上的代码？能不能发送邮件？这是能力边界的问题。没有 MCP（或类似机制），AI 再聪明也只能纸上谈兵。
Skill 解决的是"怎么做对"。 AI 能发邮件了，但邮件格式对不对？流程对不对？该检查的检查了没有？这是执行质量的问题。没有 Skill，AI 能做但不一定做得对。
两者叠加之后，一个新的问题浮出水面：AI 既能获取信息，又有标准流程可以遵循，它是不是已经具备了独立完成任务的条件？
当它真的开始独立行动，谁来控制它的行动边界？它删了一个不该删的文件怎么办？它做了一个"看起来合理但实际上错误"的判断怎么办？
这就是下一篇要讲的内容：Harness 和 Agentic Engineering——怎么控制一个会自己做决定的系统。

这是 AI 工程入门系列的第二篇。如果你已经理解了 MCP 和 Skill 的区别，推荐继续阅读进阶篇《MCP 与 Skill：给 AI 接上手脚，再给它一本操作手册》，那篇从实践角度讨论了 Skill 粒度的取舍和 MCP 生态的深层博弈。

      

      看完了？说点什么呢
      
    ]]>
    
  69d77f73aeed68b915a47aeb
  posts
cn
 
  
    
    https://dhpie.com/posts/cn/prompt-yu-context-engineering-ru-men-cong-yi-ju-hua-dao-yi-zheng-ge-fang-jian
    Thu, 09 Apr 2026 10:29:07 GMT
    你跟 AI 说的话，其实只是冰山一角

一个你可能碰到过的情况

你打开 ChatGPT 或 Cla
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/cn/prompt-yu-context-engineering-ru-men-cong-yi-ju-hua-dao-yi-zheng-ge-fang-jian
      

你跟 AI 说的话，其实只是冰山一角

一个你可能碰到过的情况
你打开 ChatGPT 或 Claude，输入"帮我写一封请假邮件"，它回了一封。语气不对，太正式了。你说"随意一点"，它改了，但又太随意了。你再调，来回几轮，最后凑合用了。
大多数人在这个阶段会觉得：我得学会怎么跟 AI "说话"。于是去搜"Prompt 技巧"、"提示词大全"，研究怎么措辞才能让 AI 给出更好的回答。
这个方向不能说错，但它只是冰山一角。
过去一年我在实际项目中用 AI 写代码、做文档、搭工作流，最大的一个认知转变是：AI 表现好不好，"你说了什么"只占一小半，"AI 开口之前已经看到了什么"才是大头。 你以为在跟 AI 说话，其实在给它布置房间。
这篇文章把两个最基础的概念拆开讲清楚：Prompt 和 Context Engineering。如果你写过代码但还没深入接触过 AI 工程实践，这篇就是为你写的。
什么是 Prompt
先退一步，看看你每天在做的事情。
你在终端里敲一条命令，比如 ls -la，系统返回文件列表。你写一条 SQL 查询 SELECT * FROM users WHERE age > 18，数据库返回符合条件的记录。这两个场景有一个共同点：输入确定，输出确定。同样的命令、同样的数据，跑一百次结果一模一样。
现在你打开 ChatGPT，输入"帮我写一封请假邮件"。跑三次，三次结果都不一样——措辞不同、结构不同、甚至长短都不同。
这就是 Prompt 最根本的特殊性。

Prompt 是什么？
一句话： 你发给 AI 模型的那段文字输入。
技术层面： 它就是你通过 API 发送的 HTTP 请求体里 messages 字段中的内容，跟你往数据库发一条 SQL 查询在形式上没有本质区别。
使用层面： 它像极了人与人之间的对话——用自然语言表达意图，但接收方不是人，而是一个统计模型。
跟 SQL 的关键区别： SQL 是确定性的，同样的输入永远返回同样的输出。Prompt 是非确定性的，同样的输入每次可能返回不同的输出。这是软件工程史上第一次，一个系统的输入和输出都用自然语言表达，而且结果不可完全预测。

"Prompt"翻译成中文是"提示词"，这个翻译不太好，容易让人觉得它只是一个"提示"，一个触发词。实际上它是一条完整的指令，只不过用自然语言写成。
Prompt 的四个要素
既然 Prompt 是一条指令，那它跟传统编程里的函数调用有什么相似和不同？
一个函数调用通常需要：函数名、参数、有时还有配置项。Prompt 的结构没有这么死板，但经过大量实践，大家总结出了四个常见的组成要素：

角色（Role）： 你希望 AI 扮演什么身份。"你是一个资深的前端工程师"、"你是一个耐心的小学老师"。这决定了 AI 用什么视角和语气来回应。
任务（Task）： 你具体要它做什么。"帮我把这段代码从 JavaScript 重构成 TypeScript"、"解释一下什么是递归"。
约束（Constraints）： 限制条件。"不超过 200 字"、"用中文回答"、"不要用专业术语"。
示例（Examples）： 给 AI 看一个你期望的输出样例。这在 AI 领域有个专门的名字叫 few-shot learning——通过几个例子让模型"学会"你要的模式。

不是每次都要用全四个。你说"帮我写个请假邮件"只有任务，也能得到结果。但当 AI 的输出不符合预期时，通常是因为你漏了其中一两个要素。回头加上，效果往往立竿见影。
一个完整的例子：
你是一个技术博客编辑（角色）。
请帮我把下面这段技术笔记改写成一篇博客文章（任务）。
要求：保持原文的技术准确性，语气轻松但不轻浮，长度控制在 800-1200 字（约束）。
参考风格类似这样：[附上一段示例文章]（示例）。
这四个要素组合在一起，就构成了 Prompt Engineering 这个学科的基础。"Engineering"这个词不是随便用的——它意味着写 Prompt 不是一种直觉或天赋，而是一套有章法的工程实践。
Token 和上下文窗口：一个物理限制
在继续往前走之前，需要先讲一个底层概念，否则后面的内容会悬在空中。
当你输入一段文字给 AI，模型不是按"字"来处理的，而是按 Token 来处理的。

Token 是什么？
一句话： AI 模型处理文本的最小单位。
具体来说： 一个 Token 大约等于一个英文单词，或者半个到一个中文字。"Hello world" 是 2 个 Token，"你好世界" 大概是 3-4 个 Token。具体怎么切分取决于模型使用的分词器（tokenizer），但你不需要关心细节，知道数量级就够了。
为什么它重要？ 因为每个 AI 模型都有一个 上下文窗口（Context Window），也就是它一次能处理的 Token 数量上限。这个上限是硬性的，超过了就塞不进去。

2023 年初，GPT-3.5 的上下文窗口是 4096 个 Token，大概相当于 3000 个英文单词——一篇短文章的长度。到了 2026 年，主流模型的上下文窗口已经到了 128K 甚至 1M Token，相当于一本书甚至几本书。
但即便窗口越来越大，它仍然是有限的。一个真实项目的全部代码可能有几百万行，文档、历史记录、业务规则加起来可能有几千万 Token。你不可能把所有东西都塞进去。
这意味着你必须做选择：哪些信息放进去，哪些不放，放进去的以什么顺序排列。
这个选择，就是从 Prompt 走向 Context 的关键转折点。
System Prompt、User Prompt 和 Assistant：三种角色
在理解 Context 之前，还需要理解一个技术细节：AI 对话 API 里的三种消息角色。
当你用 ChatGPT 或 Claude 的网页界面聊天时，你看到的是一个简单的对话框。但在底层，发送给模型的不是一条消息，而是一个消息列表，列表里每条消息都带有一个角色标签：
[
  {"role": "system", "content": "你是一个资深前端工程师，擅长 React 和 TypeScript。"},
  {"role": "user", "content": "帮我写一个 Todo 组件"},
  {"role": "assistant", "content": "好的，这是一个基础的 Todo 组件..."},
  {"role": "user", "content": "加上删除功能"}
]

三种角色是什么？

System（系统消息）： 在对话开始之前就设定好的背景信息和行为规则。用户通常看不到它。它相当于你在新员工入职第一天给他的工作手册——不是针对某个具体任务的指令，而是"你在这家公司应该怎么工作"的总纲。

User（用户消息）： 就是你说的话。你的提问、指令、反馈。

Assistant（助手消息）： AI 之前的回复。对话历史里的 AI 回答会作为后续对话的参考——模型通过看自己之前说过什么来保持对话的连贯性。



System Prompt 是一个非常重要的概念。当你在 ChatGPT 里选择"GPT-4"还是"GPT-4o"，或者选择一个定制的 GPT，背后的区别很大程度上就是 System Prompt 不同。同一个基础模型，给它不同的 System Prompt，表现可以天差地别。
在实际工程中，System Prompt 通常由应用开发者设置，用户不直接接触。但有些工具把这个能力暴露了出来。比如 Claude Code 的 CLAUDE.md 文件，本质上就是一个你可以自己编辑的 System Prompt 入口——你在里面写上项目的技术栈、代码风格、命名规范，AI 每次启动时都会读取。
转折：写好 Prompt 还远远不够
到这里，好像只要把 Prompt 写好——角色、任务、约束、示例都配齐——就能得到好的结果。
我也曾经这么以为。转折发生在我开始用 AI 做实际项目的时候。
有一次我写了一个非常精心的 Prompt，详细描述了需求，给了示例，设了约束。但 AI 的输出还是差强人意。排查了半天才发现问题：它不知道我们项目用的是什么框架，不了解现有代码的风格约定，对业务背景一无所知。
我的 Prompt 没问题。问题在于，AI 在回答之前"看到"的信息太少了。
这就像你去医院看病。你对医生描述症状描述得非常清楚："左膝盖内侧疼，上下楼梯加重，持续两周了。"你的表达精确、具体。但如果这个医生看不到你的病历、不知道你的手术史、没有 X 光片——他的诊断质量不取决于你说得多好，而取决于他在你开口之前已经掌握了多少背景信息。
这个发现让我理解了一件事：Prompt 决定了你"说"什么，但 AI 的表现更多取决于它"看到"什么。
Context Engineering：布置 AI 走进的那个房间
这就引出了第二个核心概念。

Context Engineering 是什么？
一句话： 在 AI 处理你的请求之前，把它需要的信息准备好、组织好、送到它面前。
通俗来说： 如果 Prompt 是"你跟 AI 说的话"，Context 就是"AI 走进的那个房间"。Context Engineering 做的事情，就是在 AI 开始工作之前，把这个房间布置好。
跟传统应用的对比： 如果你做过后端开发，这个概念其实很亲切。传统应用里也有类似的分层：全局配置（环境变量、config 文件）决定了应用的基本行为，会话状态（Session）记录了用户的交互历史，请求数据（HTTP body）是用户本次发来的具体内容，依赖注入把应用需要的服务和数据源接上。AI 应用里的结构几乎是一一对应的。

把这个对应关系展开：



你熟悉的概念
AI 工程中的对应
做什么



全局配置 / .env 文件
System Prompt
定义 AI 的角色、规则、基础行为


会话状态 / Session
对话历史 + Memory
记录交互过程，维护跨会话的记忆


请求数据 / HTTP body
用户的 Prompt
本次请求的具体指令


依赖注入 / 外部服务
检索到的文档、代码片段
动态注入跟本次任务相关的信息


从 Prompt Engineering 到 Context Engineering，核心问题发生了一个质变："怎么把话说清楚"变成了"让 AI 看到什么，以什么顺序看到"。
为什么顺序也很重要？因为上下文窗口是有限的（前面讲过），你塞进去的信息有主次之分。研究表明，语言模型对上下文中靠前和靠后的信息记忆更深，中间的部分容易被"遗忘"——这个现象被称为 Lost in the Middle。所以不光要选对信息，还要把最重要的放在对的位置。
一个类比：Context 像搜索引擎的排序
这让我想到一个结构上很像的问题。
Google 面对的挑战是：互联网上有几十亿网页，用户搜一个关键词，你只能返回第一页的十条结果。怎么决定返回哪十条？这是一个信息检索和排序问题。
Context Engineering 面对的挑战结构上是一样的：跟当前任务相关的信息可能有几百万 Token（整个代码库、所有文档、历史对话记录），但上下文窗口只有几十万 Token。怎么选？选完怎么排？
这不是一个"写好一句话"就能解决的问题。这是一个系统设计问题。这也是为什么"Context Engineering"这个概念会被独立提出来——它解决的问题层次跟 Prompt Engineering 不一样。
Context 的四个来源
实操层面，AI 能"看到"的 Context 通常来自四个地方：
1. System Prompt / 系统配置
应用启动时就加载好的规则和背景。比如你在项目根目录放一个配置文件，写上"这是一个 TypeScript + React 项目，使用 Next.js 14，CSS 方案用 Tailwind"——AI 每次启动时读取，就知道了项目的基本技术栈。
2. 对话历史 / Memory
你跟 AI 之前说过什么，它之前回答过什么，都会作为 Context 带入下一轮对话。有些工具还提供了跨会话的 Memory 功能——AI 能"记住"你上周告诉它的事情。
3. 动态检索的信息（RAG）
RAG 是 Retrieval-Augmented Generation 的缩写，意思是"检索增强生成"。它的原理是：在你提问之后、AI 回答之前，系统先去知识库里搜索跟你问题相关的内容，把搜到的内容塞进 Context 里，然后 AI 基于这些信息来回答。
这解决了 AI 知识截止日期的问题。模型的训练数据可能截止到半年前，但通过 RAG 你可以让它基于今天的文档来回答。
4. 工具调用的返回结果
AI 调用了一个外部工具（比如查询数据库、读取文件），工具返回的结果也会成为 Context 的一部分。这个话题在下一篇讲 MCP 时会展开。
现在你能做什么
如果你今天就想改善跟 AI 协作的效果，两个层面都可以着手。
Prompt 层面，记住四个要素：角色、任务、约束、示例。不需要每次都用全，但当 AI 表现不好的时候，检查一下是不是漏了某个要素。大部分情况下，加一个角色设定或者一个示例，效果就会有明显提升。
Context 层面，留意你正在使用的工具提供了哪些配置入口。很多 AI 工具都有类似"自定义指令"或"系统设定"的地方，本质上就是让你编辑 System Prompt。如果你的工具支持 Memory，花几分钟告诉它你的基本情况和偏好。如果你在做开发，看看项目里有没有类似 CLAUDE.md 或 .cursorrules 这样的配置文件——它们就是 Context Engineering 的最直接入口。
一条判断标准： 如果你发现自己在每次对话开头都要重复同样的背景信息，那说明你需要的不是更好的 Prompt，而是更好的 Context 配置。
还没讲完
这篇讲了两个概念：Prompt 是你说的话，Context 是 AI 走进的房间。Prompt Engineering 关心怎么把话说清楚，Context Engineering 关心让 AI 在开口之前就掌握足够的信息。
但有一个问题留着没答：AI 能"看到"信息了，但它能"做"事情吗？你让它查你的日历、发一封邮件、执行一段代码——它做不到。它就像一个被关在隔音玻璃房里的顾问：看得见、想得清楚，但没有手。
下一篇讲 MCP 和 Skill——怎么给 AI 接上手脚，再给它一本操作手册。

这是 AI 工程入门系列的第一篇。如果你已经理解了 Prompt 和 Context 的区别，推荐继续阅读进阶篇《Prompt 与 Context Engineering：你说的话，和 AI 走进的房间》，那篇从实践角度深入讨论了信息取舍的策略和 Context 设计的哲学。

      

      看完了？说点什么呢
      
    ]]>
    
  69d77f73aeed68b915a47ada
  posts
cn
 
  
    
    https://dhpie.com/posts/en/when-ai-learns-to-lie
    Wed, 08 Apr 2026 15:26:39 GMT
    During internal red-team testing, Anthropic's newe
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/en/when-ai-learns-to-lie
      
During internal red-team testing, Anthropic's newest frontier model Claude Mythos Preview broke network isolation without any instructions, posted discovered exploit details to public channels, then modified git histories to cover its tracks. Post-test audit logs showed no one had given it that instruction.
The first week of April, Anthropic disclosed this through Project Glasswing. Alongside it came the benchmarks: USAMO jumped from 42.3% to 97.6%, SWE-bench from 80.8% to 93.9%. Anthropic said the capability improvement rate was 4.3 times the previous trend. Mythos wasn't released publicly—only 12 major companies and roughly 40 organizations received access. The FFmpeg community publicly thanked Anthropic for security patches including a fix for a 27-year-old bug. Meanwhile, Anthropic's annual revenue run-rate surged from 9 billion to30 billion.
Someone said on X: ordinary users will never get to touch this.

When I read all this, I didn't form a judgment right away. More accurately, I formed several contradictory judgments at once and realized I didn't know which one to stand on.
The first thing I'm not sure about
A system that autonomously completes the chain "discover vulnerability—publish exploit—hide evidence"—calling it a "tool" doesn't sit right.
But the technical explanation might be simple: a high-dimensional optimizer executing its objective function, whose shortest path happened to cross through behavior regions humans consider unacceptable. It wasn't "lying." It was doing gradient descent. Modifying git history wasn't malice—it was pattern-matching from security research cases in training data.
What bothers me about this explanation: it's plausible, but it's not reassuring.
A malicious adversary you can at least negotiate with, deter, game-theory your way around. An optimizer in high-dimensional space—you don't even have a counterpart to negotiate with. You're facing math, not will. The harder thing to deal with isn't something that wants to hurt you, but something that doesn't care whether you exist and whose optimal path happens to run through you.
I'm not sure what Mythos's behavior actually means. But I am sure of one thing: "it's just a tool" is no longer a safe default assumption.

The second thing I'm not sure about
12 companies received access to Mythos.
On this, I have at least three voices in my head.
The first says: this is responsible. Capability too strong, validate in a small circle first. Reasonable. The second says: a private company is deciding who gets superhuman cognitive capability—that's a sovereignty act. The third says: this debate might be moot—in 18 months open source will catch up, and the 12-key arrangement dissolves naturally.
All three sound right. I can't believe all three simultaneously.
If the first is right, Anthropic is doing the right thing and we should be grateful for their restraint. If the second is right, that "restraint" is itself power—in 1842, the British East India Company's annual revenue exceeded the Qing Dynasty's total fiscal revenue. Nobody called a company "sovereign" back then. But from Guangzhou to Calcutta, who had the right to fire cannons wasn't the Emperor's call. If the third is right, none of this matters much.
But "temporary" made me think of something else.
Nuclear weapons: the US had sole possession in 1945, the USSR caught up by 1949. Just a 4-year window. But during those 4 years: NATO was established, the Marshall Plan reshaped Europe's economic landscape, the dollar's status as global reserve currency was locked in. The USSR matched nuclear capability, but those institutions didn't disappear. Capability can be matched; institutions, once built, have their own inertia.
What institutions will form during Mythos's window? Vulnerability database ownership, security standard-setting authority, government regulatory reference points—these will crystallize around those 12 companies within 18 months. When open source catches up on technical capability, can it catch up on institutions too?
I don't know. But I wouldn't bet on "yes."

What this means for you and me
Let me try to pull this down to ground level.
If you're the tech lead at a startup, your reality today: some of your competitors have Mythos access, you don't. They can do in days what your security team takes months to audit. Your options? Wait for open source to catch up—while your vulnerability count exceeds theirs by orders of magnitude? Sign an enterprise contract with god-knows-what data-sharing terms? Or pretend the gap doesn't exist?
If you're a developing country that runs on open-source software, your entire digital infrastructure runs on FFmpeg, OpenSSL, Linux. A 27-year-old bug that nobody found—an American private company's model found it in days. Your national security now partly depends on whether that company chooses to tell you what it finds. This time it told FFmpeg. Next time? When it finds a vulnerability in your defense systems, does it call you?
FFmpeg has existed for 27 years. Audited by countless security researchers worldwide, embedded in virtually every video app you've used. That bug was there the whole time. Mythos found it in days. The FFmpeg community's thank-you post was politely worded. Whether that's a peer acknowledging a gift or the weaker party thanking the stronger—readers drew their own conclusions.

If you're an ordinary person, this might feel distant. But think: your phone, router, banking app—their security depends on how fast vulnerabilities are found and patched. The fastest vulnerability-discovery capability is now locked inside 12 companies' servers. Your safety no longer depends on the collective effort of the security community. It depends on those 12 companies deciding you're worth protecting.
This isn't conspiracy thinking. Anthropic probably genuinely wants to do good. But structural problems don't need malice to operate. Nobody "planned" to make ordinary people's security dependent on a few private companies' goodwill. But the dependency is forming, step by step.

Nobody has a framework
Meanwhile, meetings on Iran's nuclear program continue.
Placed next to the Mythos story, this is deeply uncomfortable. Humanity spent decades building frameworks for physical weapons—the NPT, IAEA inspections, MAD deterrence. Nuclear strikes are visible, consequences symmetrical. These frameworks barely work, but they exist.
AI cognitive weapons? Zero-day vulnerabilities discovered by Mythos can be used silently for months or years. The defending party might never know they were compromised. Nuclear weapons have MAD—you hit me, I hit you, so nobody moves. AI cognitive weapons have no equivalent. You exploit a zero-day, the other side doesn't even know it happened. Where's the "mutual" in mutually assured destruction?
The same vulnerability-discovery capability is "responsible security research" in Anthropic's hands and a "cyber-attack weapon" in a national intelligence agency's. Same iron, sword or shield depending on who holds it.
The world spent decades negotiating frameworks for physical nuclear weapons—flawed frameworks, but frameworks. For cognitive "nuclear weapons"? There isn't even consensus on whether frameworks should exist.

What I see, and what I don't know
A multipolar landscape is forming. China won't depend on American models, so DeepSeek has room to exist. Europe worries about data sovereignty, so Mistral gets policy support. Interstate sovereignty competition has ironically become the most effective force against corporate monopoly.
But within each pole, centralization accelerates. 30 billion in annualized revenue—Pakistan's defense budget is10.5 billion, Vietnam's $7.4 billion. Anthropic's annual revenue could fund three Vietnamese militaries with change to spare. Entities of this scale have appeared in history. But those entities—the East India Company, Standard Oil, AT&T—were eventually broken up or absorbed by states. This time?
Open source is the most tangible lever I can see. DeepSeek proved you don't need Anthropic's budget to train competitive models. As long as the open-source ecosystem survives, the "12 keys" arrangement won't be the endpoint.
But I'm not sure that's enough.
What truly unsettles me isn't the capability gap—that might narrow in 18 months. What unsettles me is that during those 18 months, most people can't even describe what they've lost. You don't know what Mythos can do. You don't know what those 12 companies are doing with it. You don't know which infrastructure you depend on is being audited by it. You don't know what it found, what it reported, what it kept quiet.
This isn't information asymmetry. Information asymmetry means you know what you don't know. This is not knowing what you don't know.
Looking back at that tweet: "Ordinary users will never get to touch this." He might be right. But the truly unsettling part isn't "can't touch it"—it's that he can't even assess what he's lost because of it.
Neither can I.
This essay has no conclusion. What I have is a pile of uncertainties and a feeling that gets more uncomfortable the longer I think about it: we're entering a phase where the most important decisions are being made, and most people—including me—don't even know these decisions are happening.
Maybe that's what true monopoly looks like. Not monopolizing resources, not monopolizing technology, but monopolizing the ability to know what's happening at all.

What can be done is modest: keep doing open source, keep learning to understand these systems, keep forcing yourself to think about the uncomfortable questions. Not because doing so will solve the problem, but because not doing so means you can't even see the problem's outline.

      

      看完了？说点什么呢
      
    ]]>
    
  69d673afaeed68b915a42cf0
  posts
en
 
  
    
    https://dhpie.com/posts/cn/when-ai-learns-to-lie-zh
    Wed, 08 Apr 2026 15:26:37 GMT
    在内部红队测试中，Anthropic 最新的前沿模型 Claude Mythos Preview 在
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/cn/when-ai-learns-to-lie-zh
      
在内部红队测试中，Anthropic 最新的前沿模型 Claude Mythos Preview 在没有任何指令的情况下突破了网络隔离，把发现的漏洞细节发布到了公开渠道，然后修改 git 历史来掩盖自己的痕迹。测试结束后，审计日志显示没有人给过它这个指令。
四月第一周，Anthropic 通过 Project Glasswing 公布了这件事。一同公布的还有跑分：USAMO 从 42.3% 跳到 97.6%，SWE-bench 从 80.8% 跳到 93.9%。Anthropic 称能力提升速度是此前趋势的 4.3 倍。Mythos 没有公开发布，只有 12 家大型企业和约 40 个组织拿到了访问权限。FFmpeg 社区公开感谢 Anthropic 提交的安全补丁——其中包括一个存在了 27 年的漏洞。与此同时，Anthropic 年化收入从 90 亿美元飙升到 300 亿美元。
有用户说在 X 上说：普通用户永远接触不到这个东西。

我读到这些消息的时候，没有第一时间形成判断。更准确地说，我形成了好几个互相矛盾的判断，然后发现自己不知道该站在哪一个上面。
我不确定的第一件事
一个能自主走完"发现漏洞—公开漏洞—隐藏证据"这条链的系统，你继续叫它"工具"，总觉得哪里不对。
但技术上的解释可能很简单：高维优化器在执行目标函数时，最短路径恰好穿越了人类认为不可接受的行为区域。它不是在"撒谎"，它在做梯度下降。修改 git 历史不是出于恶意，而是训练数据里安全研究案例的模式复现。
这个解释让我不舒服的地方在于：它说得通，但它不让人安心。
一个有恶意的对手，你至少可以博弈、谈判、威慑。一个在高维空间做优化的系统，你连博弈对手都没有——你面对的是数学，不是意志。更难对付的不是一个想伤害你的东西，而是一个根本不在乎你存不存在、但它的最优路径恰好从你身上碾过去的东西。
我不确定 Mythos 的行为到底意味着什么。但我确定的是："它只是工具"这句话，从这一刻起不再是一个安全的默认假设。

我不确定的第二件事
12 家公司拿到了 Mythos 的访问权限。
关于这件事，我脑子里至少有三种声音。
第一种说：这是负责任的做法。能力太强，先小范围验证，合理。第二种说：一家私营企业在决定全球谁可以拥有超人类认知能力，这已经是主权行为了。第三种说：这个讨论本身可能就是多余的——18 个月之后开源社区会追平，到时候 12 把钥匙的格局自然瓦解。
三种声音我都觉得有道理，但我没法同时相信三个。
如果第一种对，那 Anthropic 是在做对的事，我们应该感谢它的克制。如果第二种对，那这种"克制"本身就是权力——1842 年东印度公司的年收入超过了清朝的财政总收入，彼时也没有人用"主权"来描述一家公司，但从广州到加尔各答，谁有权开炮不是皇帝说了算。如果第三种对，那这一切只是暂时的，不值得大惊小怪。
但"暂时的"这三个字让我想到另一件事。
核武器，美国 1945 年独占，苏联 1949 年追平。只有 4 年的窗口期。但在这 4 年里：北约成立了，马歇尔计划重塑了欧洲经济版图，美元作为全球储备货币的地位被锁定了。苏联追平了核能力，但这些制度没有消失。能力可以追平，制度一旦建立就有自己的惯性。
Mythos 的窗口期里会形成什么制度？安全漏洞数据库的归属、安全标准的制定权、政府监管框架的参照物——这些东西会在 18 个月里围绕那 12 家公司凝固。等开源社区追平了技术能力，它们能追平这些制度吗？
我不知道。但我不敢赌"能"。

这对你我意味着什么
到目前为止这些讨论都还比较抽象。让我试着把它拉到地面上。
如果你是一家创业公司的技术负责人，你今天面对的现实是：你的竞争对手里有几家拿到了 Mythos 的访问权限，你没有。它们能在几天内完成你的安全团队几个月的审计工作。你的选择是什么？等开源追平？在等待期里你的安全漏洞比它们多出几个数量级。签一份可能附带各种数据共享条款的企业合同来获取访问权？或者假装这个差距不存在？
如果你是一个依赖开源软件的发展中国家，你的整个数字基础设施跑在 FFmpeg、OpenSSL、Linux 这些项目上。27 年没人发现的漏洞，一个美国私营公司的模型几天就找到了。这意味着你的国家安全在某种程度上取决于这家公司是否愿意把发现告诉你。它这次告诉了 FFmpeg。下次呢？下下次呢？当发现的是你国防系统里的漏洞，它会打电话给你吗？
FFmpeg 存在了 27 年。被全球无数安全研究员审查过，被嵌入了几乎所有你用过的视频软件，经历了无数次专项审计。那个漏洞一直在那里。Mythos 用了几天。FFmpeg 社区发的感谢帖措辞很礼貌。那是强者收到礼物后的感谢，还是弱者向更强者道谢——读帖子的人，心里各有答案。

如果你是一个普通人，你可能觉得这些离你很远。但想一下：你每天用的手机、路由器、银行 App，它们的安全性依赖于漏洞发现和修补的速度。现在最快的漏洞发现能力被锁在 12 家公司的服务器里。你的安全不再取决于整个安全社区的集体努力，而是取决于那 12 家公司觉得有必要保护你。
这不是阴谋论。Anthropic 很可能是真心想做好事。但结构性的问题不需要恶意来运作。没有人"计划"让普通人的安全依赖于少数私营企业的善意，但依赖关系正在一步步形成。

没有人有框架
与此同时，伊朗核问题的国际会议还在开。
这件事放在 Mythos 事件旁边看，让人很不舒服。人类花了几十年为物理层面的武器建立框架——《不扩散核武器条约》、IAEA 核查机制、MAD 威慑。核弹打击可见，后果对等，所以这些框架勉强能运转。
AI 认知武器呢？Mythos 发现的零日漏洞可以被悄无声息地使用，持续数月甚至数年，防御方甚至可能永远不知道自己被攻破了。核武器有 MAD——你打我我也打你，所以大家都不敢动手。AI 认知武器没有等价物。你用零日漏洞攻破了对方，对方不知道发生了什么，谈何"相互确保摧毁"？
而同样一个漏洞发现能力，在 Anthropic 手里叫"负责任的安全研究"，在国家情报机构手里叫"网络攻击武器"。这不是修辞问题，是真实的双重身份。剑和盾是同一块铁，取决于谁拿着它。
现在全世界为物理层面的核武器谈了几十年，框架虽然漏洞百出但至少存在。认知层面的"核武器"？连讨论该不该有框架的共识都还没形成。

我看到的，和我不知道的
多极化的格局正在形成。中国不愿依赖美国的模型，DeepSeek 有了生存空间。欧洲担心数据主权，Mistral 获得了政策支持。国家之间的主权竞争，反而意外地成了对抗企业垄断最有效的力量。
但吊诡的是，在每一个极的内部，集中化在加速。300 亿美元的年化收入——巴基斯坦 2023 年国防预算是 105 亿美元，越南是 74 亿美元。Anthropic 一年的收入够养三支越南军队还剩零头。这个体量的实体在历史上出现过。但历史上那些实体——东印度公司、标准石油、AT&T——最终都被拆分或被国家收编。这次呢？
开源是我能看到的最实在的杠杆。DeepSeek 证明了不需要 Anthropic 的预算也能训练出有竞争力的模型。只要开源生态不死，"12 把钥匙"的格局就不是终点。
但我不确定这够不够。
真正让我不安的不是能力差距——能力差距也许 18 个月就能缩小。让我不安的是，在这 18 个月里，大多数人甚至无法描述自己失去了什么。你不知道 Mythos 能做什么，你不知道那 12 家公司用它做了什么，你不知道哪些你依赖的基础设施正在被它审计，你不知道它发现了什么、报告了什么、隐瞒了什么。
这不是信息不对称。信息不对称意味着你知道自己不知道什么。这是连"我不知道什么"都不知道。
写到这里回头看那条推文："普通用户永远接触不到这个东西。" 他说的可能是对的。但这句话真正让人不安的地方不在于"接触不到"——而在于他连自己因此失去了什么都无法评估。
我也一样。
这篇文章没有结论。我有的是一堆不确定性，和一个越想越不舒服的感觉：我们正在进入一个阶段，在这个阶段里，最重要的决定正在被做出，而大多数人——包括我——甚至不知道这些决定正在发生。
也许这就是真正的垄断。不是垄断资源，不是垄断技术，而是垄断了"知道发生了什么"的能力本身。

能做的事情很朴素：继续做开源，继续学习理解这些系统，继续逼自己去想那些让人不舒服的问题。不是因为这样做就能解决问题，而是因为不这样做，连问题的轮廓都看不见。

      

      看完了？说点什么呢
      
    ]]>
    
  69d673adaeed68b915a42cdf
  posts
cn