The starting point of any AI-native project can be summed up in one word: useful.

And generating a bunch of texts and AI videos that you are getting sick of, is not being that useful.

But “useful” here does not mean attracting attention, nor does it mean generating large volumes of content that sound intelligent but have no real impact. True usefulness means whether the system can enter a real-world context—whether it can actually be used by businesses, individuals, families, or organizations; whether it can integrate into daily operations, and even take on a portion of real risk and responsibility at critical points.

Why are we so dependent on AI today—almost “glued” to its interface? At the core, it’s because you feel that it “understands you.” And that feeling is not an illusion. It comes from a fundamental mechanism of large language models: their ability to generate responses based on your personal context.

This reveals an important direction: one of AI’s true strengths lies in extreme personalization. Of course, AI is also inherently powerful—its reasoning capabilities and its “near-omniscience” derived from training on vast amounts of human knowledge.

Today, AI companies are already leveraging this. By tuning model “temperature” and interaction patterns, they amplify your sense of being understood, thereby increasing user engagement. At its core, this is a business strategy.

However, I believe a more important—and overlooked—trend is emerging: the growing demand for truly personalized systems. For many people, having a highly private, reliable (not blindly agreeable), and rational assistant system will become increasingly important.

Such systems will likely share several characteristics: localized operation, private data ownership, resilience, and in some cases, the ability to function independently from the internet and cloud services. In an increasingly uncertain and unstable world, you cannot assume that critical infrastructure will always remain intact—for example, what if one day undersea cables are disrupted?

In the following sections, I will break down step by step how I arrived at these conclusions, and in the next article, I will explain in detail what the system I am designing actually looks like.

A De-Globalizing World, AI, and the Beginning of an Era

In 2026, as mature individuals, I don’t think we should still be reacting to AI news with shock and excitement. At the same time, the world itself seems to be growing more unstable: the narrative of globalization is weakening, localized conflicts are emerging, tensions in the Middle East are escalating, and a general sense of uncertainty is spreading.

All of this is reshaping the assumptions we inherited as a generation raised in the relatively stable and prosperous post–World War II environment.

Is de-globalization an important concept? Yes—very much so. Perhaps 30 years from now, we will look back and realize that many of the conditions we take for granted began with this shift. I will explain later why I see this as one of the key reasons for choosing data localization and privacy as a direction.

Unsurprisingly, in times like these—as has happened many times throughout human history under capitalism—technological iteration accelerates. Human science and technology often advance faster in turbulent and even brutal periods (major conflicts have repeatedly driven technological leaps).

But returning to my core point, let me ask a few questions:

• Is there a massive bubble in AI valuations? Does AI technology equal AI companies?

• Are technological value and stock market value truly equivalent?

• Does having capability automatically mean achieving value?

I believe you already have your answers.

Even if today’s leading AI companies—such as OpenAI—were to fail or go bankrupt due to an inability to generate profits, we can still be certain that this technology has permanently changed the trajectory of human technological development.

AI technology ≠ AI companies.

A technological trend does not guarantee commercial success.

AI companies are still ordinary business entities—they can lose money, fail, or disappear.

We should not conflate the technology with the companies building it.

We have now come to understand the first dominant form of AI: large language models. However, AI has not yet truly integrated into productivity systems or production relationships. We are still in the phase of exploring how to operationalize it in the real world.

This has become a key principle for me, and the driving force behind everything I do publicly—whether writing articles, creating content, or building systems:

AI has not truly “landed” yet—it has not fully entered real productivity or production structures.

The key question is not model capability, but how to make it work in reality.

This requires finding a shared cognitive community—a group of people exploring together.

And what does “landing” actually mean?

It means being truly useful in the real world—bearing responsibility, involving money, and ultimately affecting the physical world.

As we deepen our understanding of this initial form of AI, we are also beginning to realize something important:

The current paradigm—centered around large language models—is absolutely not all-powerful.

And precisely because it is not all-powerful, individual builders and programmers still need to explore independently. And because it is not all-powerful, it has not yet become truly “useful.”

What Kind of Technological Paradigm Actually Allows AI to “Land in Reality” (Be Useful):

Circulating within the symbolic world alone does not equal usefulness.

You may think that by spending all day inside chat windows, you understand what’s going on—but you don’t. You’ve only temporarily used the technology.

This is not the first time humanity has faced a technological paradigm that is difficult to comprehend in its early stages. In fact, every true technological leap creates a similar cognitive vacuum: old experience fails, new structures have not yet emerged, and most people can only interpret a fundamentally different world through outdated frameworks—thereby amplifying misjudgments without realizing it.

Let me ask you a question—you may have already noticed this:

One person uses AI to summarize a 200,000-word document into 5,000 words. Another person reads those 5,000 words online and then uses AI to expand them back into 200,000 words. What value has been created here?

Of course, you could argue that both individuals gained their own understanding through summarization and expansion. That is indeed a form of personal knowledge value.

But something still feels missing. What is it?

I believe that in this era of information explosion—where content itself is not scarce—symbols are circulating within the system, but meaningful value is not being generated. Symbols must be bound to real-world structures (decisions, actions, systems).

The value of information is not determined by its length or complexity,

but by whether it crosses the boundary from the “symbolic world” to “real-world structure.”

Today, an enormous amount of symbolic content is circulating in cyberspace in a kind of “high-volume, low-value loop.”

From Web 1.0 to Web 2.0: We Actually Achieved the Crossing from Symbols to Reality

Sad truth: today’s mainstream AI has not yet reached the level of Web 2.0.

The transition from Web 1.0 to Web 2.0 marked a critical leap:

for the first time, symbols at scale penetrated and reshaped the real world.

In the Web 1.0 era, the internet primarily served as a medium for expression and display. Information was digitized and distributed, but it remained at the level of description.

With Web 2.0, represented by platforms like Facebook, a simple piece of information was no longer just read—it could directly trigger real-world actions:

• You post a request and actually find a nearby nanny

• You meet someone on a dating platform and end up building a real-life relationship—even a marriage lasting over a decade with children, from my own network I knew a couple like this.

• Platforms like Alibaba Group pushed this even further: a single online order can mobilize production, logistics, and payment systems across regions, reshaping global trade and building highly integrated industrial supply chains

At this stage, symbols became triggers and scheduling interfaces for the real world.

A piece of digital input could initiate real resource allocation, relationship formation, and physical action.

This shift—from expression to execution—is what truly allowed the internet to change the world, and it forms the key reference point for understanding all subsequent technological paradigms.

Why Many AI Startups Fail Within ~24 Months After the Rise of LLMs

After the emergence of large language models, many AI startups instinctively tried to replicate the Web 2.0 playbook:

• Platform-centric thinking

• User scale as the goal

• Content as the product

But at the core, they introduced something fundamentally different:

a generative logic—using models to continuously produce text, images, videos, or code, treating symbolic expansion itself as value.

This creates a mismatch:

• Outer layer → Web 2.0 distribution and scale narrative

• Inner layer → closed-loop symbolic generation, not linked with reality, just explosion of internet contents.

The result:

• Rapid attention capture

• Illusion of growth

• But failure to embed into real production or decision-making systems

• No sustainable value loop

So many of these projects decline or disappear within about 24 months.

Why Did Platforms Like Facebook, Alibaba, and YouTube Succeed?

At first glance, it seems similar:

• Facebook → users generate content about themselves

• Alibaba → merchants post product information

• YouTube → creators upload videos

Why did they succeed?

Because the difference is not “user-generated content.”

The real difference is:

The symbols they generate are bound to real-world constraints and can trigger real-world actions.

• Facebook:

  Content is tied to real identity, real relationships, real social networks

  → Symbol → Relationship → Action

• Alibaba Group:

  Product listings are tied to inventory, factories, logistics, capital flow

  → Symbol → Transaction → Production

• YouTube (YouTube):

  Content connects to advertising systems, income distribution, career paths, and consumer behavior

  → Symbol → Attention → Resource allocation

The Core Insight

Their success does not come from “users generating content,” but from this:

Symbols are forcibly bound to real-world structures—and can be executed.

The Problem with Today’s Generative AI

Most generative AI systems:

• Do not require real identity

• Do not correspond to real resources

• Do not trigger real transactions or actions

• Are difficult to verify or constrain

So they become:

Symbol → Symbol → Symbol

A closed system.

An endless cell division within the symbolic world.

With little real-world impact—other than monetizing attention on platforms like YouTube—largely just empty talk. And too much AI generated videos is already making you sick.

I believe this is a “Generative Trap”

A successful system is not one that enables humans or AI to “say more,”but one where what is said can actually change the world.

• We are using the Web 2.0 success path (content → users → scale)

• to interpret a fundamentally different capability in AI (symbol generation)

This leads to a systematic misjudgment:

The assumption that “stronger generation = closer to real-world deployment”

What Does a Truly Deployable (Useful) AI System Look Like?

In the simplest terms, it must be useful.

• It can be useful to yourself, to an individual, or to a family—even if it does not directly generate economic returns

• Or it can be useful to a business—supporting operations and management, reducing labor, taking on responsibility, guiding decisions, and even directly generating economic value

• It may even provide reliable decision-making for individuals—such as investment decisions—that ultimately create value

An AI-native system of this kind must satisfy the following:

1) Bound by Constraints

• It operates under real data, real states, and permission constraints

• It cannot generate arbitrarily

• Everything must be traceable back to verifiable evidence, such as original records or documents

2) Consequential

• Its outputs affect decisions or actions

• There are costs and risks associated with those outputs

3) Verifiable

• It can be validated through real-world feedback

• Correctness is not judged by “does it sound right,” but by actual outcomes

• And in the short term, given identical inputs, there should be confidence in producing consistent results

If AI cannot be used for decision-making, I personally can’t think of any truly important use it has for me. Generative text and videos are of little value unless you’re trying to be an influencer. So in my view, the only real path for AI to truly “land” is through embedding into reality and assisting decision-making.

Is one-person unicorn truly possible?

Sam Altman, founder of OpenAI, has said for years that AI will enable a “one-person company” to achieve the kind of scale that previously required large teams—potentially even reaching billion-dollar (unicorn) levels.

Alright, let’s not debate whether this prediction is possible. If it is possible, then how would it actually be achieved?

A single person could, in theory, possess capabilities that previously required entire teams: coding, marketing, distribution, management, and decision-making. That part is not the problem. The real question is: what kind of project could make this possible?

If we follow the Web 2.0 logic I mentioned earlier, there are already companies that, with very few developers and operators, can leverage enormous output value. One example is OnlyFans.

Based on its 2024 revenue, after paying creators, the platform’s 20% commission amounted to $1.41 billion, with approximately $684 million in pre-tax profit, while operating with only about 40–50 core staff.

This is a classic Web 2.0 platform model:

• Content as the product

• Attention as the monetization mechanism

The only thing that makes it different from other platforms or sharing economy models is that its content belongs to a “gray-area industry”—arguably one of the oldest and most profitable industries in human history (essentially a zero-cost business).

So if we follow Sam Altman’s logic, and imagine a one-person unicorn built on a similar model—global audience, content monetization, platform commission—could its “grayness” really exceed OnlyFans? Probably not. The only way might be to replace the human content creators with AI and capture the 80% share that currently goes to them.

Have you ever questioned whether, beyond subscriptions, tips, and advertising, there exists another way for computers, AI, and the internet to generate revenue?

If you don’t rely on massive user bases—if you don’t rely on crowds to pay you—how do you create value?

Can information itself have intrinsic value?

Yes, it already exists. Just ask BlackRock.

There are even rumors that Aladdin—Aladdin—has long been AI, though I personally don’t believe in conspiracy theories.

So what am I trying to say?

When we step outside the mental framework of Web 2.0 and rethink the problem, a more fundamental question emerges:

If value does not come from users paying, can a system still create value?

Most people operate under the assumption that:

Revenue = users paying (subscriptions / ads / tips)

But this is merely a value transfer model:

• Users transfer money to the platform

• The platform earns a cut

• No fundamentally new value is created

OnlyFans is simply an extreme optimization of this model.

So the real question becomes:

Is there a model that is not about transferring value, but about creating value?

In other words:

• Not dependent on scale

• Not dependent on traffic

• Not dependent on crowds

But where the system itself directly produces value

The answer is yes. And this is precisely the most important shift in the AI era.

But it is not about monetizing information.

It is about:

Decision → Action → Outcome

If we break down existing models:

1) Information Monetization (Web 2.0)

• Provide content → users pay

• Essentially selling information

2) Tool Monetization (SaaS)

• Provide tools → users use them to make money → share a portion

• Essentially selling capability, but not participating in outcomes

3) Outcome Monetization (Pre-AI but already in use)

Before the rise of modern AI, top players like BlackRock—through Aladdin—were already operating in this model:

• The system participates in decision-making

• The system participates in execution

• The system directly produces results

• Revenue comes from the results themselves—not from user payments

If we follow this logic further:

The greatest value of AI is no longer:

• Attracting attention

• Generating infinite content

Instead, it is:

Entering the decision layer and directly participating in the process of value creation.

If AI is to push individuals or organizations beyond the limits of existing technology, it must enter the decision layer. What you’ve been interacting with is not decision-making — it is merely optimization.

This question is actually highly abstract. I’ve only gradually come to realize it myself recently, and even now it’s still difficult to articulate precisely.

So let’s start from something everyone is familiar with — a class of classic NP-complete problems, such as the Traveling Salesman Problem. Isn’t this one of the most iconic problems in computer science?

In the past, if someone built a system for a logistics company based on something like TSP, people would consider it extremely impressive. The definition of the problem is very clear: given N cities, find the shortest possible route that visits each city exactly once.

The difficulty lies in combinatorial explosion — once the number of cities increases, the number of possible routes grows exponentially. Ten cities is manageable. Fifty becomes extremely complex. One hundred is essentially beyond human capability.

Problems like this are both classic and practical, and they easily create a strong sense of technical sophistication — as if being able to solve them means you have mastered “decision-making ability.”

I used to think the same way. Some time ago, I even wrote an article analyzing and solving problems similar to Mastermind, another NP-complete class problem. At the time, I also believed I was doing “decision-making.”

But looking back now, what I was doing was actually just optimization, not decision-making itself.

Why do I say that?

Because all NP-complete problems share a hidden premise:

as long as a problem can be fully defined, it is fundamentally a closed-world problem.

That means:

• All variables are known

• All rules are fixed

• The objective is clearly defined

• The problem can be exhaustively enumerated or approximated

In other words, although these problems are computationally difficult, they rely on a crucial assumption:

The world is complete.

The Real World Is Multi-layered and Radically Complex

But real life is the exact opposite.

The actual decisions you deal with every day — for example, your child’s education, attention issues, communication development — require you to synthesize teacher feedback, evaluation reports, and then design extracurricular plans. At the same time, you must coordinate these plans with your own work schedule, family responsibilities, another child’s timeline, while also considering cost, distance, and energy allocation.

Or consider tax decisions: whether to sell a particular stock this year, how that affects your tax burden, how to use deductions.

These are not just numerical optimization problems. They involve:

• large amounts of ambiguity

• constantly changing conditions

• variables that are not even quantifiable

And historically, these kinds of variables could not even be incorporated into what we call “computational problems.”

In other words:

• Traditional computer science deals with problems that are already well-defined

• But real-world decision-making is difficult precisely because the problem itself is not clearly defined

Real Decision-Making Happens Before Optimization

The same logic applies to companies.

When you build a TSP algorithm for a logistics company, it looks like you are solving a highly complex problem. But in reality, what they have given you is simply the cleanest and most simplified optimization problem.

The real decision-making has already happened before that.

If we break down a real logistics scenario:

TSP solves the following:

given a set of orders and constraints, find the optimal route.

But the real decisions happen at a higher layer:

• Which orders should be accepted?

• Should orders be split?

• Which ones can be delayed?

• Should pricing be adjusted to filter demand?

• Should warehouse layouts be changed?

• Should certain regions be abandoned altogether?

These questions:

• do not have fixed objective functions

• do not have clearly defined inputs

• do not have standard answers

They involve:

• incomplete information

• conflicting objectives

• dynamically changing environments

The reason you are handed a problem that “can be solved by an algorithm” is precisely because an experienced operator — the MBA-trained logistics owner, for example — has already done the hard part for you in a place you cannot see.

They have already:

• filtered the variables

• defined the objectives

• imposed structural constraints

They have taken a chaotic real-world problem and compressed it into a clean, closed, almost perfectly structured mathematical problem — and only then handed it to you.

At that point, no matter how elegantly you solve it, what you are doing is still optimization, not decision-making.

But because the problem is formally complex and computationally difficult, it easily creates the illusion that you are working on core intelligence.

The real issue is that the computational world we built in the past has been too “clean.”

And this “cleanliness” is, in fact, a limitation — a form of reduced capability.

We have been forcing a complex world into something that is “engineerable.”

Because machines could not understand semantics, they could only execute deterministic logical rules. Therefore, all problems had to be:

• predefined

• structured

• bounded

before they could even enter a computational system.

But the real world itself is:

• multi-layered

• incomplete

• full of ambiguity and conflict

Once machines begin to understand semantics, the wall that once separated real-world complexity from computational systems starts to collapse.

And when that happens, the fundamental logic of computing no longer holds:

it is no longer just about solving predefined problems —

it must shift toward handling the generation of problems themselves and the definition of structure.

And that, in essence, is a complete paradigm shift.

The World Is Full of Truly Complex and Valuable Problems

Forcibly compressing these problems only makes systems that can truly carry complexity more valuable.

Due to the limitations of human computational capacity, we historically compressed decision problems into optimization problems.

Let me give an example that is very familiar to Chinese audiences—and I believe English audiences will also quickly grasp it:

👉 KPI — compressing complex objectives into a single number.

Everyone understands KPIs. But what is the KPI of a country?

For China, which has experienced rapid growth over the past 30 years, the national KPI has effectively been GDP prioritization.

Following the logic I laid out earlier:

GDP is a compressed optimization target, while human well-being is a decision problem that has not been properly modeled.

First, GDP needs to be placed back in its proper context.

Gross Domestic Product is merely a statistical indicator, not a goal in itself.

However, once it enters a governance system, a critical transformation occurs:

• Complex social reality → compressed into a single number (GDP)

• That number → becomes a KPI

• The KPI → becomes the optimization target

At that point, the entire system is restructured into an optimization problem.

So-called GDP prioritization is, in essence, the act of forcibly compressing a fundamentally complex decision problem into a computable optimization problem.

The original problem is inherently:

• multi-dimensional

• incomplete

• difficult to fully quantify

For example:

• Are people living well?

• Do they feel secure?

• Do they have hope for the future?

• Is the social structure healthy?

These are all decision problems, characterized by:

• multiple objectives

• partial or non-quantifiability

• lack of a unified evaluation standard

But once everything is translated into a target such as:

“GDP must grow by 8% or 5%”

the system becomes a single-objective optimization problem.

This compression is widely adopted because it provides clear engineering advantages:

• quantifiable

• comparable

• assessable

• executable

It makes governance operational.

But the cost is equally significant:

A large number of critical variables are lost, such as:

• the quality of poverty, not just its quantity

• the real accessibility of healthcare

• family structure issues (e.g., left-behind children)

• the psychological state and future expectations of young people

• fertility intentions

These variables are:

• difficult to quantify

• lacking standardized metrics

• slow to produce feedback

Therefore, they are systematically excluded from the optimization target.

When GDP becomes the KPI, all behavior begins to revolve around that metric:

• prioritizing high-return projects

• neglecting long-term factors not captured by GDP

• ignoring distribution structures

• overlooking individual lived experience

Eventually, what is being optimized is no longer reality itself—but the metric.

This is precisely what Goodhart’s Law describes:

When a measure becomes a target, it ceases to be a good measure.

The root cause is that:

• a metric is originally designed to reflect reality

• but once it becomes the driver of behavior

• reality itself becomes systematically distorted to fit the metric

So What Does “Useful” Actually Mean?

It means enabling existing systems to carry more complexity and make higher-order decisions.

And crucially:

👉 these decisions are not easily compressed.

On the surface, the system may appear to be doing the same work.

But in reality, it is:

• delaying compression

• or even refusing premature compression

It preserves:

• context

• disagreement

• uncertainty

It allows the system to operate in a higher-dimensional space—

and only makes decisions when necessary.

That is a massive leap forward.

So at this point, what I want to express is actually quite simple: the world is undergoing a structural shift—deglobalization is no longer an isolated phenomenon but an unfolding trend; AI will permanently become part of the technological system, yet its value lies not in showcasing capabilities, but in being useful—it must be grounded in reality, participate in decision-making, and be embedded within concrete systems. For the first time, machines can understand semantics, which means many of our long-standing engineering philosophies in computing must change: computers that understand meaning can begin to carry real-world complexity without forcing everything into overly compressed metrics or KPIs. If you follow this logic, you arrive at a series of conclusions that may sound counterintuitive today, but are in fact entirely natural. They feel counterintuitive because our generation grew up in a paradigm shaped by globalization, long periods of peace, efficiency-first thinking, and the equation of “the internet = computing,” operating through abstractions like Excel and ERP systems that are highly structured but strip away much of the real world’s complexity. These environments have left deep cognitive imprints on us. The next phase, however, will gradually dissolve these assumptions: computers will begin to resemble humans in their ability to handle complexity; data will move toward localization and privacy; systems will prioritize resilience; and truly valuable services will no longer aim for universality, but instead move toward extreme personalization. In the following sections, I will derive these ideas step by step.

In the AI era, a new super-variable has emerged in computing: Context

AI has introduced an entirely new super-variable—one that, years from now, will likely be written into textbooks:

Context

Anyone who has used AI extensively is already familiar with this term, and it has become deeply intertwined with large language models.

The concept itself is highly abstract, but the deeper issue is this: our way of thinking has already been profoundly shaped by an entire generation of computing paradigms—mobile devices, the internet, and SaaS. Many of our assumptions are not things we consciously “understand,” but rather structural inertia formed through long-term interaction with these systems. To truly adapt to the arrival of AI—and even to build more powerful systems on top of it—we must begin dismantling these deeply ingrained assumptions. And this is not something that can happen overnight; it requires time and exploration.

Let me give a very simple but critical example.

In the computing world you are familiar with, a single smartphone contains countless apps, and they are naturally fragmented from one another. Even within the same organization, this fragmentation persists: the accounting department uses one system, the marketing department uses another. When making decisions in the marketing system, you cannot directly invoke the capabilities of the accounting system. What you receive instead are outputs that have already been processed by the accounting team—for example, last quarter’s financial report analysis. In a sense, this is essentially a form of a “human API.”

In other words, the systems we are accustomed to today are fundamentally:

isolated by default, fragmented by nature, and mutually unintelligible

And under the technological constraints of the time, this was the “optimal solution.” Because in the pre-LLM era, “context” was not even treated as a serious engineering variable. As a result, the entire system landscape was structured like this:

• Each system maintains its own data model

• Each system enforces its own boundaries

• Systems exchange information through APIs in an extremely compressed form

• And in most real-world scenarios, even this exchange cannot be automated and relies on humans moving data across PDFs, Word documents, and Excel sheets

The consequence is:

Within the same organization—regardless of size—no single system is capable of seeing:

the complete “decision context”

The emergence of AI is the first time a crack has appeared in this structure.

LLMs can process uncompressed semantic context, creating a form of cross-system “contextual continuity.”

In theory, you could build a system that:

• simultaneously understands financial data, user behavior, market strategy, and risk constraints

• integrates all of this within a unified semantic space

• and makes decisions based on that integration, rather than relying on fragmented outputs

But the reality is that we are still far from this stage. Most so-called “AI applications” today remain at a very primitive level:

treating context as something to concatenate into prompts

instead of moving to the next level:

treating context as a first-class object—to be modeled, scheduled, isolated, and evolved

In other words, we have glimpsed the direction, but we have not yet built the language, structure, or engineering systems capable of supporting it. This gap is precisely where the most meaningful exploration will take place in the coming years.

Simply “extending context length” or “fully connecting systems” are both fundamentally flawed approaches

I believe that context engineering will become a critically important field of application in the future.

Because whether it is:

• naively extending context length—assuming that as long as LLMs can handle longer inputs, the problem is solved

• or attempting to completely eliminate all fragmentation between systems

both approaches are fundamentally crude. Neither can truly support the complexity of real-world systems.

In my view, this field is still largely unexplored. We have not yet established a clear engineering paradigm.

“Longer context” ≠ “understanding context”“Connecting systems” ≠ “being able to support real systems”

Many people instinctively assume that AI progress is equivalent to:

• longer context windows

• more information visible to the model

• less isolation between systems

That as long as context is long enough, intelligence will naturally emerge.

This conclusion is wrong.

Anyone who has actually operated a business or dealt with real-world complexity knows that the problem is far more complicated. Because context has never been a problem of length—it is fundamentally a problem of structure.

If you imagine “infinite context” as a system, it would resemble:

• a database without indexing

• a knowledge base without structure

• a memory system without prioritization

In such a system, the first thing that happens is an explosion of noise:

• relevant and irrelevant information become entangled

• the model can only rely on probabilistic guessing to determine what matters

• fundamentally lacking a selection mechanism

Second, decision-making becomes highly unstable:

• the same question may produce entirely different results at different times

• small variations in context can change the reasoning path

• the system lacks deterministic decision pathways

Finally, computational cost spirals out of control:

• latency becomes unpredictable

• the system cannot be engineered or deployed reliably

• fundamentally lacking a scheduling mechanism

Similarly, I believe that “fully connecting all systems” is also fundamentally unworkable.

If you merge accounting systems, marketing systems, user behavior data, and even private information into a single so-called “super-context,” it may appear unified on the surface, but in reality it leads to another extreme:

👉 boundary collapse

Once boundaries disappear, a chain of problems follows:

• access control becomes impossible

• semantic contamination occurs across domains

• accountability in decision-making becomes unclear

• the system loses auditability

Such a system is simply unusable in the real world.

We do not yet have an engineering discipline for how context should be constructed, selected, scheduled, and isolated. We need to explore context engineering, significantly.

As the world we live in continues to evolve, what LLMs bring is not merely an upgrade in tools, but the gradual emergence of an entirely new technological paradigm. This shift implies that many of the deeply ingrained assumptions in both computing and business will need to be re-examined.

As AI begins to enter real production environments at scale, context is becoming a critical intangible asset. In certain high-value and highly sensitive domains, the value of context may even exceed that of traditional physical assets. Whether it is long-established family businesses that have accumulated decades—or even over a century—of operational history, whose experience and knowledge can be systematically engineered into structured context, or knowledge-intensive institutions that hold significant client relationships and strategic resources—such as top-tier law firms and financial institutions—the true value of these “context assets” will gradually be recognized and re-evaluated. Some enterprises, families, organizations, and non-profit groups possess highly valuable contextual assets that have not yet been fully uncovered or utilized. We already understand AI’s strong capabilities in pattern recognition and in uncovering hidden information. Therefore, data privacy will become an extremely important area of enterprise services in the next era.

Once computing systems reach the level where they can meaningfully carry and utilize such context, entities that possess these assets will significantly increase their emphasis on data privacy. In some high-value scenarios, this may even lead to requirements that data be completely isolated from the internet.

At the same time, individuals and organizations that hold critical decision-making information will increasingly prioritize system resilience. They will begin to prepare for risks that were rarely considered in the relatively stable and peaceful environments of the past. When necessary, they may even choose to sacrifice a degree of efficiency, rather than single-mindedly pursuing profit maximization.

In this context, small companies—and even very small teams—will gain new room to survive and compete. The broader paradigm may also shift away from a model resembling “everyone buying standardized products from a supermarket,” toward one in which more people can access highly customized systems and services tailored to individual needs.

Localization and Data Privacy

Now you’re seeing more and more signals everywhere. You see headlines claiming that “SaaS is dead.” You see growing debates around data trustworthiness, which sometimes extend into questions like “which country is this provider’s server located in,” and eventually escalate into political-level disputes. You also see an increasing number of cybersecurity incidents.

At the same time, you might still think: I’m just ordering a cup of bubble tea—what privacy value could my personal data possibly have?

But the real issue is this: in the AI era, this kind of seemingly insignificant individual data is quietly transforming into structural information that can be embedded into context and participate in decision-making.

Data privacy → value ownership → context

Why has “data privacy” suddenly become a core issue in the AI era?

In the Web 2.0 era, data was essentially just behavioral records—clicks, views, purchases. Its value came from statistical aggregation, users were passive data providers, and companies monetized through advertising or subscriptions. The key point was that an individual user’s data had almost no value on its own—only scale created value.

But in the AI era, a structural shift has occurred:

👉 data is no longer just “records”—it becomes context.

And entities such as hospitals, investment firms, law firms, and wealthy families—those operating in high-value domains—will likely become the first to actively move away from large cloud providers, shifting toward localized systems and strict data isolation. This is because their systems share three common characteristics:

1) Extremely high decision value

• A single decision in a hospital can determine life, litigation, and cost

• A single decision in an investment firm can involve hundreds of millions in gain or loss

• A single decision in a law firm can determine case outcomes or risk transfer

• A single decision in a family can affect wealth inheritance and generational structure

2) Highly complex context

• Long time horizons (years to decades)

• Multi-role collaboration (doctors, partners, family members)

• Significant amounts of implicit information (experience, relationships, judgment)

3) Non-standardizable

• No two hospitals operate exactly the same

• No two investment logics are identical

• No two family structures are the same

This directly breaks the core assumption of SaaS.

As a result, these scenarios are inherently resistant to the “cloud + SaaS” model. This is not a preference issue—it is a structural one.

Because their core asset is no longer data itself, but context.

And even as I am writing this, I have already seen cases such as Palantir Technologies having partnerships—such as with a New York healthcare system—not renewed, where the underlying issue is precisely data privacy and control over context.

Events like this will only intensify, gradually forming a technological and architectural shift away from large centralized cloud providers.

And importantly, this direction is no longer theoretical—it is already becoming practically explorable in our time. In future sections, I will continue to analyze and validate this trend through my own work on localized systems.

In the era of big tech and large-scale cloud platforms, a portion of the system will be carved out.

Conversely, a smaller segment—localized, highly personalized systems—will begin to emerge and grow, starting from very small scales.

System Resilience

Continuing from the earlier discussion, under an internet paradigm where big tech companies and large cloud providers have come to dominate almost everything, a new class of localized applications is gradually emerging. This is not just a technical shift—it reflects a change in underlying philosophy.

Many programmers with fixed mental models will instinctively push back against this trend using familiar metrics such as efficiency, scale, and cost. But that is precisely where the problem lies. This is also why I chose “deglobalization” as the framing at the beginning of this article:

If you insist on arguing from efficiency and scale, then isn’t globalization the most efficient and largest-scale organizational model? The answer is obviously yes. Yet reality also shows that globalization is still reversing despite that.

As geopolitical instability increases, localized conflicts intensify, and systemic risks continue to surface, the entire set of production systems, supply chains, and industrial organization models that we once took for granted—those built around “efficiency first”—are beginning to evolve in the opposite direction: toward localization, regionalization, and redundancy.

At its core, this is the return of a long-ignored issue: we have been using “optimization problems” to mask real-world complexity. As external uncertainty rises, this compression of complexity begins to fail—and can even backfire on the system itself.

Over the past few decades, both industrial systems and the internet were built on a shared assumption: the world is stable, and therefore continuous optimization is possible. Under this assumption, we constructed an entire “optimization machine”:

• global supply chains (just-in-time)

• single-point optimal production (lowest-cost regions)

• highly fragmented, long-chain division of labor

• extremely compressed inventory systems

But all of this rests on a fragile assumption:

Nothing will go wrong.

Once this assumption breaks, the entire logic flips.

In a world of high volatility and uncertainty, what was once optimal becomes the most fragile point in the system. For example, concentrating production in a single country may have been cost-optimal in the old world—but in a disrupted environment, it becomes a single point of catastrophic failure.

The same applies to the internet and AI. Big tech and large cloud platforms are, in essence, a form of “centralized optimal solution.” But as uncertainty expands, we must ask a different question:

Is absolute efficiency still the most important goal of a system?

The answer is clearly no.

The core objective is shifting toward:

Resilience

This does not mean rejecting the cloud, nor does it mean everything must be localized. It means the priority of system design is changing:

• from maximizing single-point efficiency

• to ensuring continuous operation under uncertainty

This may not be immediately intuitive for programmers. But for leaders of large hospitals, top law firms, or family offices managing highly sensitive client information, the implications are immediately clear.

Because they already operate in environments defined by:

• high-value decisions

• high privacy requirements

• high risk sensitivity

They are naturally attuned to questions such as:

• Is the system controllable?

• Is the information secure?

• Are decisions sustainable over time?

And today, something fundamental has changed.

For the first time, the necessary conditions have converged:

• widespread availability of powerful hardware

• maturity of general-purpose software

• and the emergence of AI

This combination means that what once sounded like a fantasy is now entirely achievable. It is no longer something reserved for large institutions—it is something that even a well-resourced household can afford to build.

In other words:

• the motivation is mature (growing demand for privacy, control, and long-term decision capability)

• the conditions are mature (falling hardware costs and lower technical barriers)

The convergence of these two forces signals a structural shift in our era.

At the same time, the logic of the world itself is shifting:

• from “global optimality”

• to “local controllability”

In the past, the consensus was simple:

• cheapest = best

• long and deeply interdependent supply chains were acceptable

Now, the priority has changed:

A system must first be able to survive in an unstable environment—only then does efficiency matter.

This is why we are seeing:

• the return of localized supply chains

• the formation of regional economic blocs (not full decoupling, but reduced dependence)

• deliberate introduction of redundancy in enterprise systems

The fundamental shift is this:

Systems are now being designed for failure, not just for success.

In this context, a truly resilient system also undergoes a structural transformation:

• from centralized control

• to structured decentralization

It is important to emphasize that this is not ideological decentralization, but an engineering-driven choice.

Such systems are composed of multiple nodes:

• each node can operate independently

• connections can be severed when necessary

• yet core functionality remains intact

This manifests as:

• collaboration between local AI and cloud systems

• loosely coupled relationships between smaller systems

• reduced dependency on any single platform

Ultimately, there is only one real test:

Can the system continue to operate even when disconnected from the network or a central node?

In other words, it must have the ability to:

survive offline

To put it bluntly—even in my own household, we are already building this.

So if I’m doing it at home, how could any high-value small company with real needs possibly not have the same demand?

Extreme Personalization

A fundamental question: if there were a system designed specifically for you—one that could help you make decisions, whether in investing or running a business—and in the end, you made money from it. Suppose this system helps you earn $10 million a year. How much would you be willing to pay the provider? $20 per month?

The Old “Lowest Common Denominator” Software Design

Should systems adapt to users, or should users learn to adapt to systems?

In the past paradigm, the answer was almost taken for granted: users must learn the system.

From the moment you first encountered Microsoft PowerPoint or Microsoft Excel, you were already adapting to the logic of software—where the buttons are, how menus are structured, how functions are combined. It often takes a significant amount of time to learn. The same applies to Adobe Photoshop, as well as various CRM and ERP systems.

At a private level, I refer to these as “lowest common denominator software.” It may sound slightly ironic, but it is actually quite accurate. Because their business model determines that they cannot serve you too well as an individual. Their goal is not to serve one person exceptionally well, but to ensure that millions—or tens of millions—of users feel that the product is “good enough.”

Their optimal strategy has always been:

serve more people, not serve any one person better

The Old System Paradigm

Under this framework, our understanding of “systems” has been highly consistent:

Systems are built around two things:

• data input

• data processing

Whether ERP, CRM, or any business software, their essence is the same:

compress the real world into data → store, compute, and display it

This has been the foundational capability of software—and the core of the software industry for decades.

The Shift: Data Processing Is No Longer Scarce

Today, this foundational layer is undergoing a critical downward shift:

• local models are becoming usable (e.g., Ollama)

• cloud model costs are continuously decreasing (e.g., APIs from OpenAI)

• compute and storage costs keep dropping, driven by companies like NVIDIA

• development barriers are rapidly lowered by frameworks, open-source ecosystems, and AI-assisted coding

As a result:

data processing is shifting from a scarce resource to infrastructure—like electricity

It is no longer a true competitive advantage.

The New Layered System Structure

Once this layer commoditizes, systems begin to grow upward into a new structure.

Bottom layer

Still data input, storage, and computation—but now commoditized and no longer core differentiation.

Middle layer (emerging)

• context modeling

• long-term memory

• structured decision pathways

This is where AI begins to create real value:

not by compressing complexity into a few metrics,

but by participating in decision-making within rich, evolving context

Upper layer (deeper leap)

A cross-temporal, even cross-generational cognitive system

This is a system that persists over time. What it carries is no longer just data, but the accumulated context assets of an enterprise, a family, or an individual.

For high-net-worth individuals and small organizations, this means that for the first time, systems can continuously capture and accumulate real, valuable cognition.

A New Possibility

When computation, models, and storage are no longer constraints, something previously unimaginable becomes possible:

systems can persist over time and continuously absorb context—beyond the lifecycle of any individual

Such a system is no longer just a tool. It becomes an evolving structure:

• it records every decision

• accumulates both success and failure

• solidifies rules and preferences

• gradually forms a structured cognitive system

More importantly:

this system no longer disappears when a person leaves

it can be inherited, understood, and further evolved by the next generation

At this point, systems fundamentally shift:

from tools that assist humans → to long-term carriers of cognition and decision-making capability

This transformation is enabled by three conditions:

1. Storage is cheap enough → everything can be preserved

2. Models are powerful enough → semantics and context can be understood

3. Compute is ubiquitous enough → systems can run continuously

High-Value Demand for Custom Systems

High-net-worth individuals, high-value small enterprises, and organizations with strong privacy requirements—especially in Western Europe and North America—are naturally becoming the first adopters of custom-built systems, capturing a significant portion of high-value market demand.

This is driven by a simple reality:

• Their decision value per instance is extremely high

  • investment decisions can swing millions or even hundreds of millions

  • legal decisions directly impact risk and liability

  • family-level decisions affect wealth inheritance and structural stability

Even a small improvement in decision quality can generate returns far exceeding the cost of the system itself.

Why They Reject Standard Software

These groups are fundamentally incompatible with “lowest common denominator software.”

Existing general-purpose software has never truly entered the decision layer.

At the same time, their tolerance for data leakage is extremely low:

They hold:

• non-public asset information

• trading strategies

• family structures and trust arrangements

• highly sensitive business data

In this context, handing data over to platforms is itself a significant risk.

The Emerging System Form

As a result, a natural evolution is occurring:

• local deployment

• private models

• strict data isolation

• minimal reliance on public cloud

The Cost Barrier Is Falling

Historically, custom systems were rare because:

• high cost

• complex maintenance

• high technical barriers

But now:

• AI significantly reduces development cost

• open-source ecosystems and local models reduce technical barriers

• declining hardware costs further compress total investment

Therefore:

the cost of custom systems has dropped into a range that these groups can accept—and even proactively invest in

Why Western Europe and North America Lead

This trend is amplified in Western Europe and North America because:

• long-standing institutional protections around privacy and data rights

• mature family office ecosystems

• cultural willingness to pay for control and certainty

The Final Shift

This will not eliminate large platforms or big tech.

But it will create a clear divide:

a portion of the most valuable users will no longer be “users of platforms,”

but will become owners of systems.

So the direction I truly believe in—whether you are building a system for yourself or creating an AI system for small businesses that can actually operate in the real world and participate in decision-making—must start from the ground up. The key is still one thing: it has to be useful. This is not a problem that can be solved by simply applying existing paradigms. It is filled with countless details, engineering trade-offs, and structural design decisions—especially when it comes to the practical implementation of context engineering, where there is almost no established playbook. You have to step in and explore it yourself.

Let’s return to a few fundamental judgments: localization, data privacy, and system control. If we use something like ten Mac mini devices to build a fully headless, self-controlled cluster of computing nodes—where both hardware and software are controllable and evolvable—we are essentially asking a deeper question: what kind of system capability can you truly build for yourself or your clients?

And this is not just about Mac minis. The entire technological environment is becoming more cost-effective: IoT devices, edge computing nodes, and various sensors are all dropping in cost. This is pushing the barrier for building complex systems down from enterprise-level capabilities to something individuals and small teams can now afford and execute. Hardware is getting cheaper, and development barriers are getting lower. More and more people will start to consider building private systems.

Under these conditions, if you insist on principles like localization, privacy-first design, system resilience, and extreme personalization—how far can you actually go? How reliable can your system become? And what kind of real value can you deliver to your clients?

Reliable data input is only the most basic layer. The real question is: how deep into the context can you go to support decision-making for a specific user? How much information can you uncover that generic SaaS systems simply cannot capture? And can that information be directly translated into economic value?

In fact, more and more individuals and organizations are already using large language models (LLMs) to assist with—or even directly participate in—decision-making. Within the current cloud-based model paradigm, given sufficient context, their reasoning and comprehension abilities within a single conversational window are already quite powerful.

But the problem is that this kind of “in-window decision capability” cannot directly support long-term, real-world operations. Real businesses—especially those aiming for stability and continuity—depend not on one-off judgments, but on a set of reusable, traceable, and enforceable procedural mechanisms. These include things like evidence sources behind decisions, clearly assigned approval responsibilities, and proper document archiving and version control.

Once these critical elements exist only within a conversation window, they disappear as the context scrolls. They cannot be accumulated, audited, or reused.

Therefore, what truly enables AI to enter real-world decision systems is not just the capability of the model itself, but a stable, structured, and auditable system that can carry, solidify, and orchestrate these decision processes. Only when these processes are structurally preserved can AI evolve from a “tool that talks” into a system that participates in responsibility.

More on the technical side in the next piece—I’m still exploring this myself.

前言

AI 原生项目的起点，只能是两个字：有用。

但这里的“有用”，并不是吸引注意力，也不是生成大量看起来聪明却对现实毫无影响的内容。真正的“有用”，是它能不能进入一个真实场景，被企业、个人、家庭或组织真正用起来；能不能嵌入日常运作，甚至在某些关键环节中，承担一部分真实的风险与责任。

为什么我们现在会如此依赖、甚至“黏”在 AI 的窗口上？本质原因是——你感觉它“懂你”。而这种感觉，并不是错觉，它来自大语言模型的一个核心机制：基于个人上下文的生成能力。

这也让我们隐约看到一个方向：AI 真正强大的地方之一，在于极致的个性化能力。当然，它本身也很强——推理能力，以及基于全人类语料训练出来的某种“近似全知”。

今天的 AI 公司，其实已经在利用这一点：通过调节模型的“温度”和交互方式，让你更强烈地感受到“被理解”，从而提升用户粘性。这本质上是一种商业策略。

但我认为，一个更重要、却被忽视的趋势正在出现：对“极致个性化系统”的真实需求，会逐渐生长出来。对于越来越多的人来说，拥有一个高度隐私化、可靠（甚至不会一味迎合你）、具备理性判断能力的辅助系统，将变得重要。

这样的系统，很可能具备几个特征：本地化运行、数据私有、具备韧性，甚至在某种程度上可以脱离互联网与云服务而独立存在。因为在一个日益不确定和动荡的世界里，你很难保证关键基础设施永远稳定——比如哪一天，海底光缆真的出了问题。

接下来，我会一步步拆解我是如何推导出这套判断的，并在下一篇文章中，具体讲清楚我正在设计的这种系统，究竟会长成什么样。

去全球化的世界，AI，一个时代的开始

2026年，我们作为成熟的个体，我认为不应该再为AI的新闻一惊一乍。甚至这个世界似乎也变得更加动荡了起来，全球化叙事的结束，局部战争的开启，中东的战争逐步升级，世界开始变得不安。一切都在颠覆我们作为二战后稳定繁荣一代的预设环境。去全球化这个概念很重要吗？很重要，也许30年以后你会发现那个时间点所有已经成为环境的起点来自去全球化。我会在后面说明为什么我认为这个起点也是我会选择数据本地化和隐私化作为方向的原因。

毫无意外，在这个年代，如同人类历史上无数次在资本主义环境下发生的变革，技术的迭代到来了。没错，人类的科学与技术，在动荡，残酷的年代，似乎发展的更快（每次大战似乎都推进了技术飞跃）。

说回来我的核心，我要问你几个问题：

• AI的市值是否存在巨量泡沫？AI技术是否等于AI公司？

• 技术价值与股票市值是否绝对等价？

• 能力的实现是否等于价值的实现？

我相信你已经有了答案：

哪怕现在这些顶流AI公司，比如OpenAI 因为无法实现盈利而破产，我们也可以相信这项技术已经永远的改变了人类的科技树；

AI技术 ≠ AI公司。技术趋势不等于商业成功。AI公司是普通商业实体，可以亏损、破产、失败。不应将技术与公司绑定。

我们已经理解了首先出现的普遍AI形态，即大语言模型。然而，AI还没有真正的进入生产力和生产关系，我们还属于“落地能力”的探索阶段，这也是我为自己制定的一条关键准则，这也是我未来写文章，Youtube等一切向外联系的原动力；

AI尚未真正落地，尚未进入生产力与生产关系。“如何落地”是关键问题，比模型能力更重要。需要寻找认知共同体，需要圈子/群体来共同探索。什么叫落地？我认为必须是“现实中真的有用”。承载责任，金钱，改变物理世界。

并且我们在理解这个初始形态的过程中，也醒悟了过来，就是**目前的以大语言模型为主的形态绝对不是万能的。**既然他不是万能的，那么作为个人程序员就还需要自主探讨。而且因为他真的不万能，所以他现在并没有真正的变得“有用”。

到底什么样的科技范式才能让AI“落地”（有用）：单纯在符号世界循环不等于有用。

你以为你现在天天泡在窗口里，你以为你理解了，但是你没有，你只是暂时把这个技术用上了。这并不是人类第一次面对一种几乎无法被当下理解的技术范式困惑，相反，每一次真正的技术跃迁，都会在早期制造类似的认知真空：旧有经验失效，新结构尚未显现，大多数人只能用过去的框架去解释一个本质上已经不同的世界，从而在无形中放大误判。

我就此问个问题，你可能已经发现了：

一个人把一个20万字的文档用AI总结成了5000个字，另一个人在网上看到了这5000个字，然后自己又把这5000字用AI扩展成了20万字。这里面产生了什么价值？

当然，你可以说用AI总结和扩展的这两个人，都分别获得了自己的理解。这当然是一种个人知识价值的实现。但是你总感觉这里面缺少了什么，是什么呢？我认为在这个信息爆炸，内容根本不缺的时代，符号在系统内循环，但重要价值没有随之产生。符号需要绑定到现实结构（决策、行动、系统）中。

信息的价值，不取决于长度或复杂度，而取决于它是否跨越了“符号世界 → 现实结构”的边界。

现在有大量符号在赛博空间中，以一种信息爆炸的模式在“无价值空转”。

从Web 1.0 时代到Web 2.0时代：其实我们是完成了符号跨越现实的

Sad truth: 当前主流AI，反而还没有达到Web 2.0的层级。

从Web 1.0走向Web 2.0，人类其实完成了一次极其关键的跨越：符号第一次大规模地穿透并改造现实世界。在Web 1.0时代，互联网主要承担的是“表达与展示”的功能，信息被数字化、被传播，但它仍然停留在描述层；而到了Web 2.0，以Facebook为代表的社交网络开始让一条简单的信息不再只是被阅读，而是能够直接触发真实行动：你发布一个需求，可能真的就找到了附近的保姆；在约会平台上匹配到的人，我认识的，就有人通过这种方式走入婚姻，十年后仍在一起并育有子女；而像Alibaba Group这样的电商平台，则将这一能力推向更宏观的层面，一次线上订单可以直接调动跨区域的生产、物流与支付系统，进而重塑了全球贸易的运行方式，并在中国形成了今天我们所看到的高度整合的全产业链结构。在这一阶段，符号成为了现实世界的触发器与调度接口。一段数字指令，可以引发一连串真实的资源配置、关系建立与物理行动，这种“从表达走向执行”的跃迁，才是互联网真正改变世界的地方，也构成了我们理解后续一切技术范式的关键参照。

许多AI创业团队，在大语言模型横空出世之后，照搬Web 2.0模式。但是沿用的是“生成式逻辑”，大多在24个月之内失败。为什么？

在大语言模型横空出世之后，许多AI创业团队几乎本能地选择了沿用Web 2.0的成功路径：以平台为中心、以用户规模为目标、以内容为产品，试图复制当年由Facebook或Alibaba Group所代表的增长逻辑。然而，它们在底层却引入了一个根本不同的核心能力——“生成式逻辑”，即通过模型不断生产文本、图像、视频或代码，把符号的扩展当作价值本身。

这就造成了一种结构性错位：外层是Web 2.0的分发与规模叙事，内层却是停留在符号空间自循环的生成机制。结果是，这些产品可以快速吸引注意力、制造增长幻觉，但很难真正嵌入现实的生产与决策结构，无法形成可持续的价值闭环，因此大量项目在大约24个月内便走向衰退甚至消失。

很奇怪是不是？facebook是无数人，自己生成大量关于自己的叙事符号，通过这种符号来互相链接。Alibaba是你说你自己有什么产品，让别人来买；YouTube呢，就是你自己拍视频，让别人看，也是自己生成啊，怎么都成功了呢？

一点都不奇怪，表面看它们都是“自己生成内容”，但本质差别在于：这些平台生成的符号，背后都绑定了真实约束，并且能够触发现实行为，而不是停留在符号内部循环。

以 Facebook 为例，人们确实在“生成关于自己的内容”，但这些内容并不是虚空的，它们绑定的是真实身份、真实关系、真实社交网络，一条信息可以带来真实的联系、合作甚至生活安排，本质是“符号 → 关系 → 行动”；再看 Alibaba Group，商家发布商品信息，看似也是“生成内容”，但每一个商品背后都对应库存、工厂、物流、资金流，一次点击直接触发跨地区的供应链运转，这是“符号 → 交易 → 生产”；再比如 YouTube，创作者上传视频虽然是内容生产，但背后连接的是广告系统、收入分配、职业路径，甚至影响现实中的消费决策与文化传播，是“符号 → 注意力 → 资源分配”。

所以它们成功的关键，不是“用户在生成内容”，而是：

这些符号都被强制绑定在现实结构上，并且可以被执行。

而今天很多生成式AI的问题在于：

• 生成的内容不需要真实身份

• 不需要对应真实资源

• 不会触发真实交易或行动

• 也很难被验证或约束

于是变成：

符号 → 符号 → 符号

一个封闭系统。一个符号世界里的无限细胞分裂。没啥现实作用，除了赚Youtube这类平台的钱之外，纯属口嗨。

我认为这就是一个“生成式陷阱”

成功的系统，不是让人或AI“说更多”，而是让“说出来的东西能改变世界”。

• 我们在用 Web 2.0 的成功路径（内容→用户→规模）

• 去解释 AI 这种完全不同的能力（符号生成）

这会导致一个系统性误判：

以为“生成更强 = 更接近落地”

那么我认为真正能落地的形态至少具备什么特征呢？那么用最通俗的说法来概括就是“有用”。要么对你自己，个人，家庭有用，虽然他不直接产生经济效应。要么就对一个企业的经营管理“有用”，甚至能直接靠省去人工，承担责任，指导决策这种管理功能产生经济效应。甚至是能给个人提供可靠决策，最后这个决策能创造价值，比如投资决策。这种AI原生系统，必须：

1）不可随意生成（Bound by constraints）

• 有真实数据 / 状态 / 权限限制

• 不是随便编，一切能追溯到确实的证据，比如原始单据。

2）有后果（Consequential）

• 输出会影响决策或行为

• 有成本、有风险

3）可被验证（Verifiable）

• 可以被现实反馈检验

• 对错不是“看起来像不像”，而是“结果如何”

• 而且短期内，输入一模一样的信息，有信心得到相同的结果

如果AI无法用于决策，对于我个人来说，我都想不到对我还能有什么重要用处。生成式的文字和视频，不当网红也没啥用。所以AI的唯一一条真正“落地”的道路，我认为只有“嵌入现实“和“辅助决策”这一条路。

你还记不记得一开始AI公司给我们画的大饼？你要么靠吸粉赚钱，要么就只能靠创造价值赚钱。

OpenAI 创始人Sam Altman 至少在几年前常说：AI将使“一个人公司（one-person company）”达到过去只有大型团队才能实现的规模，甚至做到10亿美元级别（独角兽）。

好，先不辩论这个预言的可能性，如果可能，怎么实现？一个人可以拥有过去需要团队完成的能力，代码，营销，推广，管理，决策。这个没问题，问题是靠什么项目实现？其实按照我刚才提出的Web 2.0逻辑，在这个模式之下其实是有公司达到使用极少的开发+运营人员，撬动极大的产值的： Only Fans!

根据Only Fans 2024年的营收，公司在支付了创作者的收入之后的公司的20%提成部分为$1.41 Billion, 利润（税前）：约 $684 Million. 而核心运营人员只有40-50人。

这是一个典型的Web 2.0 平台逻辑，仍然是“内容商品”，仍然是“注意力变现”，对不对？唯一让他特别的，与其他平台，共享经济不同的一点在于内容是”灰色产业“。人类最古老，也最赚钱的行业（无本生意）之一。按照Sam Altman的逻辑，如果靠类似的逻辑，一个人创造独角兽变现类似的平台，靠全球吸粉，抽成，那么你这个“灰度“难道还能超过Only Fans吗？估计也只有把这里面的“内容贡献者”变成AI了，把人家那80%的分成给赚了。

你有没有怀疑过除了Subscription订阅，打赏，内容广告，这种收益的模式之外，计算机，AI，目前我们互联网网络，是有另一种“收益”的方式的。如果不靠广大的用户，不靠人海来给你钱，你如何创造价值？信息本身是否能有价值？

有啊，早就有了，不信你去问贝莱德。甚至有传言说Aladdin早就是AI，但是我本人不相信阴谋论。

所以我想表达的是什么呢？当我们跳出 Web 2.0 的思想钢印去重新思考问题时，一个更根本的问题就出现了：如果不靠“人付钱”，系统还能不能创造价值？大多数人的默认前提是“收益 = 用户付费（订阅 / 广告 / 打赏）”，但这其实只是一个“价值转移模型”，也就是用户把钱转移给平台，平台通过抽成获取收益，本质上并没有创造新的价值，OnlyFans 只是把这种模式做到极致而已；所以真正值得问的是：有没有一种不是“转移”，而是“创造”的收益方式？也就是说，不靠规模、不靠流量、不靠人海，而是系统本身直接产生价值；答案是有的，而且这恰恰是 AI 时代最核心的变化，但它不是信息变现，而是“决策 → 行动 → 结果”的变现逻辑；如果我们把现有模式拆开来看，第一类是信息变现（Web 2.0）：内容给用户，用户付钱，本质是卖信息；第二类是工具变现（SaaS）：工具给用户，用户用工具赚钱再分一部分，本质是卖能力，但不参与结果；而第三类，也就是在AI还没有横空出世之前，世界顶级玩家贝莱德的Aladdin早就在玩的：结果变现。系统参与决策、参与执行，并直接产生结果，收益来自结果本身，而不是用户付费本身；如果顺着这个逻辑往下推，那么 AI 最大的价值就不再是吸粉，不再是生成无限内容，而是开始进入“决策层”，直接参与价值的创造过程。

如果AI要让企业/个人的在现有的技术上更进一步，那么必须进入决策环节。什么是决策？你常玩的那个不是，那只是优化。

这个问题其实非常抽象，我也是最近才慢慢意识到，而且很难准确表达清楚。我们可以先从一个大家都很熟悉的东西说起，比如一类经典的 NP-complete 问题，像 Traveling Salesman Problem，这不是计算机科学里最经典的问题之一吗？

以前如果有人给一家物流公司做一个类似 TSP 的系统，大家都会觉得非常厉害，因为它的定义很清晰：在 N 个城市中，找到一条最短路径，每个城市只访问一次；但它的难度在于组合爆炸，城市数量一旦增加，可能路径数呈指数级增长，10 个城市还可以处理，50 个就已经极其复杂，100 个基本上人类完全无力，这类问题既经典又实用，也很容易让人产生一种专业感——仿佛能解决这些问题，就代表你掌握了“决策能力”；

我自己以前也是这么认为的，前一段时间写过一篇文章，用来分析和求解类似 Mastermind 这样的 NP-complete 问题，当时也觉得这就是在做“决策”，但现在回过头来看，其实那只是“优化”，而不是决策本身；为什么这么说？因为所有 NP-complete 问题都有一个隐藏前提：只要你已经能够把问题完整定义出来，它本质上一定是一个“封闭世界问题（Closed World Problem）”，也就是说所有变量是已知的，规则是固定的，目标是明确的，问题可以被穷举或近似求解，换句话说，这些问题虽然计算上很难，但有一个关键前提——世界是完整的。

真正的现实多层次，极复杂

而现实生活恰恰完全不是这样，你每天真实面对和去解决的真正决策，比如孩子的教育、注意力问题、沟通能力问题，你需要综合老师反馈、测评报告去安排课外活动，同时还要把这些安排和你的工作、家庭事务、另一个孩子的时间协调在一起，还要考虑成本、距离、精力分配，再比如税务决策，今年卖不卖某只股票会如何影响税负，抵扣额度怎么用，这些决策涉及的不只是数字优化，还包括大量模糊、动态、甚至无法量化的变量，而这些变量在过去是根本无法被纳入“计算问题”的范畴的；也就是说，计算机科学传统上处理的，是那些已经被定义好的问题，而现实生活中的决策，真正困难的地方恰恰在于：问题本身并没有被定义清楚。

真正的决策发生在优化之前

公司的决策其实也是一样的逻辑，你去给那家物流公司做 Traveling Salesman Problem 算法，看起来是在解决一个很复杂的问题，但本质上对方只是把最简单、最干净的“优化问题”交给了你，而真正的“决策”早在这之前就已经发生了；如果我们把一个真实的物流问题拆开来看：TSP 解决的是在给定订单集合、给定约束条件下，找到一条最优路径，但真正的决策是在更前面的层级——比如哪些订单要接，是否需要拆单，哪些可以延迟，是否要提高价格来筛选需求，是否要调整仓储布局，甚至是否要放弃某些区域，这些问题没有固定的目标函数，没有明确的输入，也没有标准答案，它们涉及的是不完整信息、多目标冲突和动态变化的现实环境；而你之所以能拿到一个“可以用算法解决的问题”，恰恰是因为那个学 MBA、经验老道的物流公司老板，已经在你看不见的地方把真正复杂的部分处理掉了，他已经帮你完成了变量筛选、目标定义和结构约束，把一个混沌的现实问题压缩成了一个封闭、干净、近乎完美的数学问题，然后才交到你手上，这时候你解决的再漂亮，本质上也只是“优化”，而不是“决策”，但因为这个问题在形式上足够复杂、计算上足够困难，就很容易让人产生一种错觉，好像自己在做的是核心智能。

所以真正的问题，在于以前我们的计算机世界过于“干净”了，其实是一种低能的表现，强制把复杂的世界压制成“可工程化”。因为机器无法理解语义，只能执行确定性的逻辑规则，因此所有问题都必须被提前定义、结构化、边界化，才能进入计算系统；但真实世界本身是多层次、非完备、充满模糊与冲突的，一旦机器开始具备理解语义的能力，这道原本隔离“现实复杂性”和“计算系统”的墙就被打破了，那么整个计算世界的基本逻辑也就不再成立，不再只是处理已定义问题的工具，而必须转向处理问题生成与结构定义本身，这实际上意味着一次彻底的范式重构。

这个世界充满了真正复杂和有价值的问题，而且无法被简化成计算指标

而强制压缩这些问题，只会让真正能够承载复杂型的系统更有价值。因为人类算力的局限，以前我们把决策问题压缩成优化问题。举一个中国人都很熟悉的例子，对于英文观众，我相信也能很快理解：那就是KPI → 把复杂目标压成一个数。

KPI大家都知道了，那么一个国家的KPI是什么呢？对于在过去30年高速发展的中国来说，国家的KPI就是中国的GDP优先主义。沿用我刚才跟你阐述的逻辑：

GDP 是一个被压缩后的优化目标，而民生是一个未被正确建模的决策问题。

首先GDP需要被放回它原本的位置，即 Gross Domestic Product 只是一个统计指标，而不是目标本身；但一旦进入治理体系，就会发生一个关键转换：复杂的社会现实被压缩成一个数字（GDP），再被设定为KPI，进而成为优化对象，于是整个系统被重构为一个“优化问题”。

而所谓 GDP 优先主义，本质上就是把原本复杂的决策问题强行压缩为一个可计算的优化问题，因为原始问题其实是多维且不完备的，比如人过得好不好、是否有安全感、是否对未来有希望、社会结构是否健康，这些都是典型的决策问题，具有多目标、不可完全量化、缺乏统一评价标准的特征，但一旦转化为“GDP 必须增长 8% 或 5%”这样的目标，系统就被简化为单一目标优化；这种压缩之所以被广泛采用，是因为它带来了明显的工程化优势，比如可量化、可比较、可考核、可执行，使治理具备操作性，但其代价同样明显，即大量关键变量被丢失，例如贫困的质量而非仅数量、医疗保障的真实可达性、家庭结构问题（如留守儿童）、青年人的心理状态与未来预期以及生育意愿，这些变量往往难以量化、缺乏统一标准且无法在短期内反馈，因此被系统性地排除在优化目标之外；最终，这会导致一个结构性问题，即系统出现“理性偏移”，因为当GDP成为KPI时，所有行为都会围绕这一指标展开，例如优先投资高回报项目、忽视长期但不计入GDP的因素、忽略分配结构以及个体体验，最终导致优化的对象不再是现实本身，而只是指标；这正是所谓的 Goodhart’s Law 所揭示的现象，即一旦一个指标成为目标，它就不再是一个好的指标，其根本原因在于指标原本是用来反映现实的，但一旦成为驱动行为的目标，现实反而开始围绕指标被系统性地扭曲。

所以什么才是有用？就是让现有的系统能够承载更多的复杂性，做出更有层次的决策。而这个决策不会轻易的被压缩。看上去是做同样的工作，但是延迟压缩，甚至拒绝过早压缩。它会保留上下文、保留分歧、保留不确定性，让系统在更高维度上运行，再在必要时做出决策。这个进步就巨大了。

所以读到这里，我想表达的其实很简单：世界已经在发生结构性的变化，逆全球化不再是偶然事件，而是一种正在展开的趋势；AI也将永久成为技术体系的一部分，但它的价值不在于炫技，而在于“有用”——必须贴近现实、参与决策、嵌入具体系统之中。而且因为人类第一次，“机器读懂了语义”，所以我们许多在计算机应用的工程哲学需要改变。能够读懂语义的计算机，可以开始承接一些真实世界的复杂性，可以不需要过度压缩成指标或者KPI。顺着这个逻辑往下推，会得出一系列现在听起来有些反直觉、但实际上极其自然的结论。之所以显得反直觉，是因为我们这一代人是在全球化、长期和平、效率至上，以及“互联网=计算机”的范式中成长起来的，是在Excel表，ERP这种被高度结构化提炼但是同时又损失大量真实世界的复杂层次的抽象中走过来的。这些环境在我们心中形成了深刻的思想钢印。而下一阶段，恰恰会逐步瓦解这些默认前提：计算机将慢慢变得“像人”，承载人类的世界的复杂性。数据将走向本地化与私密化，系统将以韧性为核心目标，而真正有价值的服务，将不再追求普适性，而是走向极致的个性化。下面我依次推导我的这些观点。

AI 时代计算机界出现了一个超级变量：上下文context

AI引入了一个全新的超级变量，多年以后我们会把这个写到教科书里：

上下文（Context）

长期使用AI的人，应该对这个词不陌生，而且这个词也已经深度和大语言模型绑定了。

这个概念本身是非常抽象的，而更大的问题在于：我们的思维，已经被手机、互联网、SaaS 这一整代计算范式深度塑形了。很多认知不是你“理解”出来的，而是长期使用系统之后形成的结构惯性。想要真正适应 AI 的到来，甚至基于它创造出更强的系统形态，本质上需要对这些根深蒂固的假设进行拆解，而这件事不可能一蹴而就，它需要时间，也需要探索。

我举一个最简单但极其关键的例子。

在你熟悉的计算世界里，一部手机上有无数个 APP，它们彼此之间是天然割裂的。哪怕是在同一家企业内部，这种割裂也依然存在：会计部门使用一套系统，市场部门使用另一套系统。而当你在市场系统中做决策时，你无法直接调用会计系统的能力。你能获得的，只是会计部门整理好的结果，例如上一季度的财报分析。从某种意义上讲，这其实就是一种“人肉 API”。也就是说，我们今天所习惯的系统形态，本质上是：

默认隔离、天然断裂、彼此不理解

而且这是当时技术条件下的“最优解”。因为在前 LLM 时代，“上下文”甚至还不是一个被严肃对待的工程变量。于是整个系统世界被构造成这样一种结构：

• 每个系统维护自己的数据模型

• 每个系统封闭自己的边界

• 系统之间通过接口（API）进行极度压缩的信息交换

• 而在绝大多数真实场景中，这种交换甚至无法自动完成，只能依赖人工在 PDF、Word、Excel 之间搬运

结果就是：

在同一家企业内部，无论规模大小，没有任何一个系统能够看到：

完整的“决策上下文”

而 AI 的出现，第一次让这件事出现了裂缝。

LLM 可以处理未被压缩的语义上下文创造一种 跨系统的“上下文连续性”

理论上，你可以构建这样一个系统：

• 同时理解财务数据、用户行为、市场策略与风险约束

• 在同一个语义空间中整合这些信息

• 并基于此进行决策，而不是依赖被切割后的结果

但问题在于，我们目前还远没有走到这一步。我们大多数所谓的“AI 应用”，实际上仍然停留在一个非常初级的阶段：

把上下文当作 prompt 进行拼接

而没有真正进入下一层：

把上下文当作一等公民（first-class object），去建模、调度、隔离与演化

也就是说，我们已经看到了方向，但还没有建立语言、结构和工程体系去承载它。这中间的断层，才是接下来几年真正值得探索的地方

简单粗暴的认为“把上下文拉长”或者把所有的割断打通“都是不可行的

所以我认为，“上下文工程”未来会成为一个极其关键的应用领域。因为无论是简单地把上下文不断“拉长”，认为只要 LLM 能处理更长的上下文就足够，还是试图彻底打通系统之间的所有割裂，这些做法本质上都是粗暴的，它们都无法真正承载现实世界中的复杂系统。在我看来，这个领域仍然处于一片未被充分理解的状态，我们甚至还没有建立起清晰的工程范式。“把上下文拉长” ≠ “理解上下文”，“打通系统” ≠ “可承载现实系统”。

很多人下意识地认为 AI 的进步等同于上下文窗口变长、模型能看到的信息更多、系统之间不再隔离：只要上下文足够长，系统就会变得更智能。但这个结论是错误的。任何真正运营过企业、处理过现实复杂度的人都会意识到，问题远比这复杂得多。因为上下文从来就不是一个“长度问题”，而是一个“结构问题”。

如果你把所谓的“无限上下文”想象成一个系统，它更像是一个没有索引的数据库、一个没有结构的知识库、一个没有优先级的记忆系统。在这样的系统中，首先会发生的是信息噪声的爆炸：相关与不相关的信息混在一起，模型只能依赖概率去“猜测”什么重要，本质上缺乏选择机制（selection）；其次，决策会变得极其不稳定，同样的问题在不同时间可能产生完全不同的结果，因为上下文的轻微变化就会改变推理路径，这意味着系统缺乏确定性的决策路径（determinism）；最后，计算成本会迅速失控，延迟不可预测，系统也无法被工程化部署，本质上是缺乏调度机制（scheduling）。

同样地，我认为“彻底打通系统”也肯定不成。如果你把会计系统、市场系统、用户行为数据乃至私密信息全部汇聚成一个所谓的“超级上下文”，表面上看似统一，实际上却是在走向另一种极端——边界的彻底崩溃（boundary collapse）。一旦边界消失，就会带来一系列连锁问题：权限无法控制、语义相互污染、决策责任变得模糊、系统失去可审计性。这种系统在现实世界中是不可用的。

我们还没有一门关于“上下文如何被构造、选择、调度与隔离”的工程学。

随着我们所处的世界不断变化，LLM 带来的不只是工具层面的升级，而是一整套新的技术范式正在逐步形成。这也意味着，许多我们习以为常、根深蒂固的计算方式与商业逻辑，都将被重新审视。

随着 AI 开始广泛进入真实的生产环境，“上下文”正在成为一种关键的无形资产。在一些高价值且高度私密的领域中，上下文的价值甚至可能超过传统的实体资产。无论是那些积累了几十年，甚至上百年历史的家族企业，其长期沉淀并逐步工程化的经验与知识，还是那些掌握大量核心客户关系与关键资源的知识密集型机构，例如顶级律所和金融机构，这些“上下文资产”的真实价值，都会逐渐被市场所认知和重估。有些企业，家族，团体，非盈利组织，拥有非常有价值的上下文资产，这些资产没有被挖掘出来。我们已经知道 AI对于模式识别的能力，对于隐藏信息的发掘能力。所以数据隐私一定是下一个时代无比重要的企业服务内容。

一旦计算机系统具备了真正承载和利用这些上下文的能力，这些持有关键上下文的主体，将显著提升对数据私密性的重视。在某些高价值场景下，甚至会出现“数据必须完全与互联网隔离”的要求。

与此同时，掌握关键决策信息的个人与组织，也会越来越强调系统的韧性。他们会为那些在过去相对和平与稳定环境中从未认真考虑过的风险，提前建立预案。在必要时，他们甚至愿意主动牺牲一部分“效率”，而不再单纯追求利润最大化。

在这样的背景之下，小公司，甚至极小规模的团队，将获得新的生存空间与竞争优势。整个技术与商业范式，也可能从过去类似“所有人去超市购买标准化产品”的模式，逐步转向一个新的形态——更多人能够使用高度定制、面向个体需求的系统与服务。

本地化与数据私密性

现在你会看到很多新闻，你会看到有人在说“SaaS 已死”；你会看到关于数据可信度的讨论，甚至会延伸到“这个服务商的服务器在哪个国家”，进而变成政治层面的争论；你会看到越来越多的 cyber security（网络安全）事件。而与此同时，你可能还会想：我不过是点一杯奶茶，这种个人级别的数据，有什么隐私可言？但真正的问题是，在 AI 时代，这种“看似没有价值的单体数据”，正在悄悄变成可以嵌入上下文、参与决策的结构性信息。

数据隐私 → 价值归属 → 上下文（context）

为什么“数据隐私”在 AI 时代突然变成核心问题？在 Web 2.0 时代，数据本质上只是行为记录（点击、浏览、购买），其价值来自统计聚合（aggregation），用户是被动提供数据的一方，公司则通过广告或订阅实现变现，关键在于单个用户的数据几乎没有价值，只有规模才有价值；但在 AI 时代发生了一个结构性变化，数据从“记录”转变为“上下文”，而包括医院、投资机构、律所、富裕家庭等高价值主体，将成为最早一批因为数据隐私问题而主动脱离大厂大云、转向本地系统、严格隔离私人数据的实践者，因为这些系统具备三个共同特征：

第一，决策价值极高——医院的一个决策关系到生死、诉讼与成本，投资机构的一个决策可能涉及上亿回报或损失，律所的一个决策决定胜诉或风险转移，家族的一个决策影响资产传承与代际结构；

第二，上下文极其复杂——涉及长周期（几年到几十年）、多角色协作（医生、合伙人、家族成员）以及大量隐性信息（经验、关系与判断）；

第三，不可标准化——没有两个医院完全一样，没有两个投资逻辑完全一样，也没有两个家族结构完全一样，这一点直接击穿了 SaaS 的前提；因此这些场景天然排斥“云 + SaaS”，这是结构问题，因为它们的核心资产不再是数据本身，而是上下文，而就在写这篇内容的时候，我已经看到 Palantir Technologies 与纽约医疗系统的合作被拒绝续约，本质原因正是数据隐私与上下文控制权，这类事件只会愈演愈烈，并逐步形成一个背离“大厂大云”的技术与架构转向，而这个方向，在我们这个时代已经具备实际可探索的条件，后续我也会结合自己在本地化系统上的实践，持续展开分析与验证。

大厂时代，大云时代，有一部分会被切割出去。相反一小部分本地化，超个性化需求会从极小的规模慢慢开始尝试崛起。

系统的韧性resilience

继续刚才的说法，大厂与大型云服务商几乎包揽一切的互联网形态之下，正在逐渐出现一批本地化的应用，这是一种理念的变化。很多思维路径比较固定的程序员，会本能地从效率、规模、成本这些熟悉的指标来反驳这一趋势，但这正是问题所在，这也是为什么我在文章开篇选择用“去全球化”来作为解释框架：

如果你坚持用效率与规模来辩论，那么全球化是不是效率最高、规模最大的一种组织方式？答案显然是肯定的，但现实同样告诉我们，即便如此，全球化依然在发生反转。

随着地缘政治的不稳定、局部冲突的增加，以及系统性风险的持续暴露，我们曾经习以为常的那一整套“效率优先”的生产体系、供应链体系乃至工业组织方式，都在开始朝着相反的方向演化，即更加本地化、区域化、冗余化的发展路径。

本质上，这是一种长期被忽视的问题正在回归：我们过去习惯用“优化问题”去掩盖“真实复杂性”，而当外部环境的不确定性上升，这种压缩复杂性的方式就开始失效甚至反噬系统本身。过去几十年，整个工业与互联网体系默认了一个前提——世界是稳定的，因此可以持续优化，在这个前提之下，我们构建了一整套“优化机器”：全球化供应链（just-in-time）、单点最优生产（lowest cost region）、超长链条分工，以及极致压缩的库存体系，但这一切都隐含着一个极其脆弱的假设——不会出事。

一旦这个假设不成立，整个逻辑就会反转：当世界进入高波动与高不确定状态时，原本的最优解反而会变成系统中最脆弱的节点，例如单一国家生产在旧世界中是成本最优，但在新环境中，一旦发生断供，它就直接成为致命风险。这一点映射到互联网与AI同样成立，大厂与大云本质上也是一种“集中化最优解”，但在不确定性不断放大的背景下，我们必须重新问一个问题：系统最重要的目标，还是绝对效率吗？答案显然是否定的，更核心的目标正在转向系统的韧性Resilience。这并不意味着反对云，也不意味着所有事情都必须本地化完成，而是意味着系统设计的优先级正在改变：从单点极致效率，转向在不确定环境下仍然能够持续运行的能力。

这个事情，作为程序员不一定能完全理解，但作为大医院的管理者、顶级律所、以及掌握重要私密客户信息的家族办公室，一定能够立刻听懂其中的意义。因为他们本身就长期处在高价值决策、高隐私、高风险控制的环境中，对“系统是否可控”“信息是否安全”“决策是否可持续”有天然敏感度。

而且现在的情况已经发生了根本变化：硬件能力的普及、软件通用性的成熟，以及 AI 的出现，这些技术条件第一次同时具备，使得这件事不再是天方夜谭，而是一个富裕家庭都买得起、也请得起人来构建的现实系统。也就是说，不仅动机已经成熟——对隐私、控制权和长期决策能力的需求正在快速上升，而且条件也已经成熟——不论是硬件，还是软件技术门槛都在大幅下降，这两者叠加，意味着这个时代已经发生了结构性变化。

与此同时，整个世界的运行逻辑也在发生转移：从过去追求“全球最优”的效率逻辑，转向强调“局部可控”的生存逻辑。过去的共识是最便宜就是最好，哪怕供应链再远、依赖再深也可以接受；但现在的核心判断变成了，系统首先必须能在不稳定环境中存活下来，其次才是效率是否最优。因此我们看到本地化供应链的回归、区域经济块的形成（并非完全脱钩，而是降低依赖）、以及企业主动引入冗余设计，这一切的本质变化在于：系统开始为“失败”设计，而不再只为“成功”设计。

在这样的背景下，一个真正有韧性的系统，其结构也从传统的“中心化控制”转向“结构化去中心”。这里必须强调，这并不是理想主义的去中心化，而是一种工程上的现实选择：系统由多个节点构成，每个节点可以独立运行，在必要时可以断开连接但仍保持基本功能。具体表现为本地 AI 与云的协同、小系统之间的松耦合关系，以及对单一平台依赖的降低。最终的判断标准只有一个：这个系统在脱离网络、脱离中心节点的情况下，是否仍然能够继续运作，也就是系统必须具备“可脱网生存”的能力。

说个最俗最显摆的，这个连我自己家里都在建。你觉得任何有需求的高价值小公司怎么可能没这个需求。

极致个性化

灵魂问题：如果有一套系统，专门为你而设，能帮你决策。这个决策，不管是投资也好，还是做生意也好。反正你最终赚钱了。假设你靠这个系统年入一千万美元，你愿意给这个系统的提供商支付多少钱？20刀月费吗？

最大公约数式软件设计

系统应该去适配用户，还是用户应该去学习系统？在过去的范式里，这个答案几乎是默认的：用户必须去学习系统。你从最早接触 Microsoft PowerPoint、Microsoft Excel 开始，就在不断适应软件的逻辑——按钮在哪里、菜单怎么走、功能如何组合，往往要花大量时间去摸索。再到 Adobe Photoshop，以及各种CRM、ERP系统，本质上都是一样的。我私底下把它们称为“最大公约数软件”，听起来有点调侃，但其实非常贴切。因为它们的商业模型决定了，它们“不能对你这个人太好”，它们的目标不是服务好一个人，而是让几百万、几千万人都觉得“勉强能用”。它们的最优策略，从来都是服务更多人，而不是更好地服务某一个人。

在这样的背景下，我们过去对“系统”的认知，其实非常统一：系统就是围绕两件事情构建的——数据的录入与数据的处理。无论是ERP、CRM，还是各种业务软件，本质都是把现实世界压缩成数据，然后对这些数据进行存储、计算与展示。这构成了软件最底层的能力，也是过去几十年软件工业的核心。但今天，这一层能力正在发生一个关键的“下沉”：本地模型开始变得可用，比如 Ollama；云模型的成本持续下降，例如 OpenAI 提供的API；同时算力与存储成本在 NVIDIA 等推动下不断降低，再加上开发门槛被框架、开源生态与AI辅助编程迅速拉低。于是数据处理能力，正在从一种稀缺资源，变成像电力一样的基础设施，不再构成真正的壁垒。

当这一层下沉之后，系统开始向上生长，形成新的分层结构。

最底层，依然是数据录入、存储与计算，但这一层已经开始商品化，不再是核心竞争力。

往上一层，是正在形成的能力：上下文建模、长期记忆以及结构化的决策路径。也正是在这一层，AI开始真正产生价值——它不再只是把复杂问题压缩成几个指标，而是可以在复杂上下文中参与决策，让决策随着信息不断丰富和演化。

而再往上一层，则是一个更深的跃迁：跨长期、甚至跨代际的“认知系统”。这是一种能够长期存在的系统形态，它所承载的不再只是数据，而是一个企业、一个家庭、甚至一个个体不断积累的“上下文资产”。对于高净值人群和小型组织来说，这意味着他们第一次可以通过系统，持续捕获并沉淀真正有价值的认知。

当计算、模型与存储都不再成为问题之后，一个过去难以想象的可能性开始出现：系统可以持续存在，并不断吸收上下文，跨越个人的生命周期。它不再只是一个工具，而是一个持续演化的结构体——它记录每一次决策，积累成功与失败，固化规则与偏好，逐渐形成结构化的认知体系。更重要的是，这个体系不再随着人的离开而消失，而是可以被下一代继承、理解，甚至在此基础上继续演化。也正是在这一刻，系统第一次从“辅助人”的工具，转变为一种可以承载认知与决策能力的长期载体。

1. 存储足够便宜 → 可以保存一切

2. 模型足够强 → 可以理解语义与上下文

3. 计算足够普及 → 可以持续运行

一些高净值人群，高净值的小企业，私密性要求高的，尤其是来自西欧和北美地区，私人定制的需求会分走市场的一部分蛋糕

一些高净值人群、高净值的小企业，以及对私密性要求极高的组织——尤其是在Western Europe和North America——正在自然成为“私人定制系统”的第一批需求方，并且会稳定地分走市场中一块高价值的份额。这背后首先是一个非常现实的前提：

• 他们的“单次决策价值”极高。无论是投资决策，可能带来数百万甚至上亿的波动；

• 法律决策，直接影响风险与责任；

• 还是家族层面的决策，涉及资产传承与结构稳定，只要系统能够在这些关键节点上提升一点点决策质量，其带来的回报就已经远远超过软件本身的成本。

因此，这类群体天然不适合“最大公约数软件”，而现有的普适软件，本质上也从未真正进入“决策模型”这一层。

与此同时，他们对数据外泄的容忍度极低。这些人群往往掌握着非公开的资产信息、交易策略、家族结构与信托安排，以及高度敏感的商业数据。在这种背景下，把数据交给平台本身就构成了一种不可忽视的风险。因此，一种几乎是必然演化出来的需求开始出现：本地部署、私有模型、数据隔离，以及尽可能不依赖公共云的系统形态。

更关键的是，他们具备承担定制成本的能力，而这个成本本身也正在发生变化。过去定制系统之所以难以普及，是因为成本高、维护复杂、技术门槛极高；但现在，AI显著降低了开发成本，开源生态与本地模型降低了技术门槛，而硬件成本的持续下降进一步压缩了整体投入。于是：定制系统的成本，已经下降到了这些群体可以接受甚至愿意主动投入的区间。

这种趋势在Western Europe和North America会被进一步放大，因为这些地区长期以来就对隐私与数据权利有制度性保护，同时家族办公室（Family Office）体系成熟，高净值个体本身也更习惯为“控制权”和“确定性”付费。因此，他们不仅有需求，而且有明确的支付意愿与文化基础去支持这种系统形态的出现。

最终，这并不会消灭大厂或平台型软件，但会带来一个清晰的分化：一部分最有价值的用户，将不再只是“平台的用户”，而是转变为“系统的拥有者”。

所以我真正看好的方向，无论是为自己构建系统，还是为其他小企业打造一个能在现实中运转、真正参与决策的 AI 系统，都必须从底层开始做起。关键还是“要有用”。这不是一个可以靠“套用已有范式”解决的问题——其中充满了大量细节、工程权衡与结构设计，尤其是“上下文工程”的具体落地方式，几乎没有现成的教科书可以参考，必须亲自下场探索。

回到几个基础判断：本地化、数据隐私、系统控制权。如果我们用十台 Mac mini 这样的设备，搭建一个完全 headless、由自己掌控的计算节点集群，在软硬件都可控、可演化的前提下，本质上是在问一个问题——你到底能为自己/客户构建出怎样的系统能力？

而这背后并不只是 Mac mini 的问题，整个技术环境的性价比都在提升：IoT 设备、边缘计算节点、各类传感器的成本持续下降，正在把“构建复杂系统”的门槛，从企业级能力，压缩到个人和小团队也能承担的范围之内。硬件越来越便宜，开发门槛越来越低。具有私有系统这种想法的人，只会越来越多。

在这样的前提下，如果你坚持本地化、隐私优先、系统韧性，以及极致个性化这些原则，你最终能做到什么程度？你的系统能有多可靠？你能为客户提供怎样的真实价值？

数据录入的可靠性只是最基础的一层。更关键的是：你能在多深的上下文中，帮助这个特定用户进行决策？你能挖掘出多少在通用 SaaS 系统中根本无法被捕捉的信息？而这些信息，是否能够直接转化为收益？

其实，越来越多的个人和企业，已经开始借助大语言模型（LLM）来辅助甚至直接参与决策。在当前的云端模型体系下，只要给定足够的上下文，它在一个对话窗口内所展现出的理解与推理能力，已经相当强大。

但问题在于，这种“窗口内的决策能力”，并不能直接支撑真实世界中的长期运营。企业的运作，尤其是稳定、可持续的运作，依赖的不是一时的判断，而是一整套可复用、可追溯、可约束的程序化机制——比如决策所依赖的证据来源、审批责任的明确归属、关键文件的留存与版本管理等。

这些关键要素，一旦仅存在于对话窗口中，就会随着上下文的滚动而消散，既无法沉淀，也无法审计，更无法复用。

因此，真正能够支撑AI进入现实决策体系的，不只是模型本身的能力，而是一个稳定、结构化、可审计的系统，用来承载、固化并调度这些决策流程。只有当这些过程被“结构化地保存下来”，AI 才能从“会说话的工具”，进化为“可参与责任的系统”。

下一篇继续讲技术。我也在探索中。

Let me begin by revisiting my original motivation. I believe many programmers today are experiencing the same shift that I am. I’ve discussed an important observation with several friends (perhaps by now you no longer find this surprising): we are increasingly convinced that the future will no longer involve carefully reading code in detail. No one will continue to write code line by line in the traditional sense. Of course, the degree varies from person to person. In my own case, I now almost never read the first version of code generated by AI. What I do read is the diff. Because when reviewing diffs, I often encounter very interesting situations. Sometimes, in order to satisfy the requirements I gave, the AI produces code that makes me laugh and cry at the same time.

For example, I once asked the AI to implement a structured rendering approach so that the system could maintain strong generality and extensibility in the future. The solution it produced was to enumerate a long list of related keywords. This technically works for the current problem, but structurally speaking it is almost an active destruction of future generality. Code like this is easy to recognize: it exists to pass the current task, not to support the long-term evolution of the system.

Because of experiences like this, I increasingly believe that the real problem with AI-generated code has never been the code itself. Code is merely the surface. The real question is what decisions humans are making, and whether those decisions can continue over time.

This is precisely why so many programmers have recently begun discussing one topic: memory. Almost every AI coding framework eventually circles back to this issue. But after asking many people about it, I discovered something strange: almost no one can clearly explain what memory actually is.

Is memory the content written in books? Notes stored in Notion or Obsidian? Information saved in a database? Vector retrieval inside an LLM? Clearly none of these capture the essence. If the problem were that simple, then Notion or Obsidian combined with AI plugins would have solved it long ago. But they haven’t. People are still repeating the same work again and again.

Gradually, I began to feel that the problem we are trying to solve is not really “memory,” at least not memory in the traditional sense of the human brain. If I had to describe it in the simplest possible sentence, the real problem we want to solve is the continuity of decision-making.

The human brain cannot maintain decision continuity across extremely complex scenarios and long periods of work. This is the root cause of much of our suffering.

Let me describe several “programmer hells” that I personally experience today—and that I believe you, sitting in front of the screen, have either already experienced or at least begun to sense.

1) The Hell of Project Restart

No matter how much code you have written, how many projects you have built, or how many documents you have produced, every time you start a new project you often feel a very strong sensation: everything is starting from scratch again.

At the same time, you also feel that things should not actually be this way. Because you can clearly sense that many projects share the same underlying structures. Many projects are essentially the same system wearing a different costume.

Even when they appear completely unrelated on the surface—an education app, a knowledge system, a web service, an AI tool—at the structural level they often share highly similar patterns: identity management, authorization, data models, state management, event systems, evolutionary paths.

The problem is that the human brain is not very good at extracting these structures and recombining them. So every “new project” ends up feeling like entering a new parallel universe. You repeatedly encounter familiar things, familiar bugs, familiar architectures, even familiar sensations when fixing bugs.

Every time a project begins, it feels as if you have returned to the starting point. This is the hell of project restart.

2) The Hell of Micro-Decisions

Even though AI can now write code extremely quickly, a window is not omnipotent. A real system is never completed with a single prompt.

A real system resembles a stack of interconnected seesaws. Each pivot point in those seesaws is actually a decision. Where should this module live? How should this API be designed? Is this data structure extensible? Will this logic affect the future evolution of the system?

Each of these decisions seems small, but each of them influences the entire system.

In modern development environments you often play multiple roles simultaneously—frontend developer, backend developer, architect, algorithm engineer, product manager. As a result, all of these micro-decisions accumulate on a single person.

Each decision individually appears trivial, but the total number of them is astronomical. Your time and cognitive energy are constantly consumed by these micro-decisions. The more complex the project becomes, the more pronounced this feeling becomes.

Eventually you realize that what truly slows you down is not writing code—it is the endless stream of tiny decisions.

This is the hell of micro-decisions.

3) The Hell of Technical Debt

This one is more familiar: the classic “spaghetti code.” But in my own framework there is another, more subtle form of technical debt—non-evolvable technical debt.

When building a system, you often cannot plan very far ahead. Time is limited, information is incomplete, and the number of decisions is overwhelming. So many designs are merely temporary solutions that work for the moment.

The problem appears when the system must evolve. Suddenly you discover that the technical debt has accumulated into a mountain. Many places become too risky to modify; changing one component triggers unexpected consequences elsewhere.

Again, the seesaw analogy applies: when you push down one board, you have no idea how many other boards will be lifted.

Eventually you arrive at a very familiar decision:

“Forget it. Let’s restart.”

And thus we return once again to the hell of project restart.

If you examine these three hells carefully, you will notice that they are actually different manifestations of the same problem. Project restart, micro-decisions, and technical debt all originate from a single underlying issue:

decisions cannot remain continuous.

Each time you start again, you are making the same decisions. Each time you are rethinking the same problems. Each time you are repeating the same mistakes.

Now if we connect this observation with one of the most popular words in the programming community recently—Taste—things become very interesting.

Many people say that what distinguishes a truly great engineer is not coding skill but taste. But what exactly is taste?

I increasingly believe that taste is the compression of decision continuity.

A person with taste does not re-evaluate everything from scratch each time. Many of their decisions have already been structured in their mind. So when a new problem appears, they are not asking “what should I do?” They are calling upon how they have solved similar problems before.

If we phrase the problem even more directly:

if AI can write code, then the real problem of the future is not how to write code. The real problem is how to maintain continuity in decision-making.

Many people claim they are solving the memory problem, but I think that is only a surface description. The deeper problem is how to preserve the structure of human decisions so that they can be invoked again in the future.

Everything I have been experimenting with recently revolves around one question:

How can we prevent decisions from starting from zero again?

Fast-forward ten thousand steps. Let me first tell you one thing I have already managed to achieve.

At this point, I can no longer write articles by recording my thinking process in real time. Instead, I have to wait until I feel that the accumulated material has reached a meaningful threshold, and then share the final realization of a particular stage.

The reason is simple: the volume of information processing is now enormous. Every day is filled with cycles of trial, reconstruction, collapse, and retry. If I tried to document every intermediate state, I would never get anything else done.

So what I can show you now is not the process, but a result that already works:

Starting from a single intention, with a single click (literally pressing a button—any intermediate command-line prompts such as Yes/No/Continue or copy-paste actions do not add meaningful information and can be ignored), relying only on code, model rendering and invocation, together with the knowledge base that I have designed and organized, and only by calling knowledge that already exists in that library, the system can generate in one pass a complete decision document—one that can immediately guide reliable code and system architecture.

1) First, this approach eliminates the endless proliferation of windows.

Many people have probably experienced this. When you are working on a project, the issue might appear to be a small architectural question—such as which framework to choose, how a module should be decomposed, or whether a certain data structure might affect future evolution. Yet these questions often require a bit of global reasoning.

So you begin opening windows: one window discussing architecture, another discussing the database, another discussing APIs, another discussing deployment, and then yet another window to clarify some additional detail. By the time you finally make progress on one question, the earlier discussions have already fallen out of the context window. So you open another window and repeat the process.

Eventually you start to feel something strange: it seems as if you are spinning in an ocean of symbols. You look busy, but in reality you are circling around the same small loop again and again. Of course this is not surprising—the context window is limited by definition.

This made me realize that we must find a different approach: for a given intention, generate a complete, high-density decision document in a single pass. That document should include the architecture, constraints, execution paths, and key decisions, all grounded in the best judgment available within your current knowledge system.

Once such a document exists, you can simply hand it to the AI. It then operates with a full decision context, instead of forcing you to debate endlessly across dozens of windows.

2) But the real difficulty is not generating the document—it is whether you can trust it.

You must trust it to a certain degree in order to proceed with confidence. Otherwise you will inevitably fall back into the familiar habit of opening yet another window to ask the same question again.

This is actually very difficult, because the foundation of that trust does not lie in the model—it lies in your knowledge base.

The logic is simple: garbage in, garbage out.

If your knowledge base itself is chaotic, fragmented, or untested, then whatever you generate from it will simply be a faster and more systematic form of chaos.

Over the past few months, I therefore spent a great deal of time studying something that initially seemed unrelated to programming: the Anglo-American legal system. Gradually I realized that this legal tradition represents one of the most successful structures humans have developed for organizing complex social rules. It is capable of maintaining order, legal coherence, and collective intent within an extremely complicated society.

More importantly, it does not rely on a perfectly designed rule system. Instead, it emerges through long-term accumulation, case law, and iterative refinement of rules.

Because of this, when I designed the structure of my own knowledge base, I borrowed heavily from the structural logic of the common law system. I will discuss this in more detail in future articles.

3) Finally, there is a crucial question: how do we understand iteration and upgrade?

Let us return again to the legal system.

I had previously hinted at this idea, but only after studying it more deeply did I fully appreciate an important fact: any rule that is written down cannot possibly be perfect.

The moment you try to write rules, you realize that many ideals people unconsciously pursue—words like perfect, error-free, absolutely clean, no redundancy, unchanging—are simply impossible. Once a rule exists, it inevitably exists within change.

Therefore, any truly functional rule system must fundamentally be an open information system. It must allow new information to continuously enter, and it must contain a clear pipeline through which that information can be iterated and upgraded.

In the future I will frequently use one word to describe this process: promotion.

In other words, a rule you write down does not automatically become a rule. Only when it is repeatedly invoked in real projects, continuously tested in practice, and proven useful over time does it gradually settle and become a true rule.

Human law itself developed in exactly this way. It was not designed by a single person; it emerged from countless iterations of practice.

Any rule that has not undergone this process of refinement almost always leads to the same conclusion, which I have encountered many times:

Wishful thinking.

The ideal looks beautiful—but reality is far less accommodating.

Memory is schedulable structure; taste is the gravitational field that continuously biases the future decision space.

This is the reality we now face every day in the age of AI.

And for that, we should thank the extraordinary power of modern LLMs.

When you begin writing down the knowledge you truly use in daily work, that knowledge inevitably has to go through a process of refinement. It cannot remain in the form of raw notes from individual projects, scattered code snippets, or fragmented reflections. Instead, it needs to be compressed into rules that can be reused across projects.

Take a very simple example: a statement like “Ensure system life run_id is contained within a single OS process lifetime.” This rule did not appear because I sat down one day and deliberately wrote it. Rather, it emerged gradually from experience accumulated across many different projects. It existed implicitly inside project retrospectives, development journals, and scattered notes. Over time it became a kind of shared internal consensus.

In the past, extracting such knowledge from a large pile of notes was extremely labor-intensive. But now this extraction work can be handled almost entirely by an LLM. For that reason, a large portion of my notes—notes that have already been carefully filtered—were first placed in a space I called the Sovereign Log. The name itself was chosen somewhat casually.

After the content goes through a process of refinement and selection, the original project context is stripped away. The specific code implementations are removed. What remains are the rules themselves and the structural insights that actually carry value. These are then marked and categorized one by one as Law.

In other words, the project-specific information is hidden, the concrete implementation is removed, but the skeleton of knowledge is preserved.

This step is actually a task where LLMs and deterministic code collaborate extremely well: the LLM handles understanding and extraction, while code handles structuring and archival. I will share the specific code later, and this is a part of the system that I strongly recommend others adopt.

Next, as you continue developing across various projects—whether personal home projects, team projects, client projects, or work-related systems—you will repeatedly invoke this Law library. Once these rules enter a specific project, they regain context. At that moment, they become a Case.

This is very similar to how case law works in the Anglo-American legal system. The law itself exists as a body of rules, but what truly matters is how those rules are applied, interpreted, and adjudicated within real-world situations.

This process—where rules meet reality—is something I also implemented through a combination of code and LLMs. It is actually one of the more difficult parts of the entire system, because it involves substantial workflow control and structural constraints. Only recently have I managed to bring it to a state that is stable enough for my own daily use.

Once these Cases run inside real projects, they generate feedback:

Is the rule actually useful? Does it operate smoothly in practice? Where does it need adjustment?

That feedback is then fed back into the system, entering the next round of consolidation and refinement. Over time, this forms a continuously cycling information pipeline.

In this description I am skipping over tens of thousands of lines of code and hundreds of thousands of words of data-structure design. But the core idea can be summarized quite simply:

Knowledge is distilled from logs into Laws, invoked in projects as Cases, and then returned to the system through real-world feedback to continue evolving.

Let me show you a very concrete example.

Recently I have been working on something at home: a comprehensive upgrade of my household network server, all connected devices, and various IoT applications. This project is entirely personal, so I will likely use it as an ongoing example in future discussions. Because it is my own project, I can freely choose to share it.

The goal is simple: you want a system that does not plant hidden landmines for the future, while also maintaining high standards of quality, reliability, and long-term maintainability.

In the age of AI, I increasingly believe that the starting point of a project should be Intention, rather than “what code I want to write.”

Let’s look at a very simple example: how a clear intention can eliminate the need to juggle dozens of windows—arguing back and forth, asking scattered questions, and constantly re-injecting missing context.

What is even more interesting is that once this intention is processed by my system, the entire process—from decision-making to architecture, to code generation, to the first working test and initial deployment—took only a few hours.

In the past, that would have been almost unimaginable.

python3 tools/intention_compiler.py \\
  --text "I intend to configure one of my Mac mini machines to operate as the primary home control plane for my family’s digital infrastructure.This Mac mini will function as a local server that hosts family services, manages identities, and coordinates applications running within the home network.The system will serve as the central node of the home computing environment, providing a stable runtime for family applications, content libraries, and automation tasks.The Mac mini must run continuously and maintain reliable connectivity with the home router." \\
  --max-questions 4 \\
  --max-rounds 3 \\
  --temperature 0.2 \\
  --preview

The first step that needs to run is an intention compression stage. The meaning of this step is actually quite simple: we do not start from asking questions, nor from issuing commands, because those things are merely derivative forms of intention. The real starting point should be the intention itself.

Across many information pipelines, I increasingly feel that intention should be the true entry point of a system. Explaining this fully would probably take several days, but from my own experience the idea is actually very intuitive. Human intention is the most fundamental reason behind any action we take. The ways we normally interact with systems—such as asking questions (typical of the search-engine era) or issuing commands (which became common after LLMs allowed us to generate code through natural language)—are actually adaptations to tools.

In other words, in order to realize our intentions, we are constrained by the tools we use, and therefore we must translate our original intentions into questions or commands. This process feels natural, but in reality it is a constant act of translation. And wherever human translation exists, information loss and ambiguity inevitably follow. So instead of endlessly patching those deviations afterward, it is better to begin directly from the intention itself.

After my entire set of code and processes finishes running (almost everything is fully automated), I actually do almost nothing manually. Aside from answering a few small questions that the LLM itself generates during the process, there is no additional intervention—no reopening new windows for discussion, no manually assembling prompts. The system simply performs a memory call to retrieve relevant knowledge from my knowledge base, passes that through model rendering, and then directly produces the report you saw earlier.

From there, I immediately start writing code and launching the project based on that report. Yes—that directly. Essentially, it is one-click generation. In my view, this is the correct way to work. By contrast, the method of endlessly arguing across dozens of windows—pulling threads in different directions, patching context repeatedly—is actually the wrong approach.

Later I will explain the entire underlying mechanism in detail. More importantly, I trust this direction completely, because fundamentally it is calling my own knowledge base. Many of the core rules and structures inside it were written by me in the first place. In other words, this is not handing decision-making over to the model. Instead, it allows the model to execute a decision system that I have already distilled.

And this is not limited to a single report. The token cost of making such calls is extremely low; I can generate as many as I want. The key point is that it delivers more than a 10× improvement in efficiency, and that improvement compounds over time. Because every time a report is used in practice, the knowledge and code that emerge afterward are fed back into the information pipeline again.

Once the report is generated, the actual work moves quickly. Within just a few hours (and during that time I also generated several additional reports from other angles to further complete the project), the core work was already finished. At that point, building out the project on top of that foundation becomes much faster.

# RISK RESOLUTION — Isolation / Traceability / “Telemetry Never Becomes Truth” for an Online-Only Web App

## 0) Conclusion (One Sentence)

**Define “child learning history” as an append-only Event Ledger routed by child scope; define “memory/progress” as Derivation Views that can be reconstructed from the Ledger; define “telemetry/logs” as Ephemeral Telemetry that is discarded by default. The three must be strictly isolated, and any promotion across boundaries must be explicit, auditable, and replayable.**

---

## 1) Scope as a First-Class Citizen: Hard Boundary for Per-Child Isolation

### 1.1 Scope Key (Required on Every Write)

Every write operation (whether an event, asset, derived view, or uploaded file metadata) must include:

* `project_id`
* `child_id`
* `session_id`
* `actor` (`child` / `parent_admin` / `system`)
* `device_id` (optional but recommended)
* `request_id` (for idempotency)

> **Rule: Any write missing a scope key must be rejected** (HTTP 400/403). There is **no such thing as a “default child.”**

---

### 1.2 Storage Routing

Disk layout and indexing must follow a unified routing rule:

* **Physical path**:
  `/data/{project_id}/{child_id}/...`

* **Logical index**:
  `(project_id, child_id, kind, ts, event_id)`

Shared write locations are **forbidden**.

For example:

* `/data/shared` may only contain a **public content library**
* All assets in `/data/shared` must be **read-only imports created by parent/admin**

This directly implements the rule:

**All writes must be scope-routed by `(project_id, child_id, session_id)`.**

---

## 2) Append-Only Event Ledger: The Only Source of Truth

### 2.1 Status of the Ledger

* **Ledger = Canonical History (single source of truth)**

Anything like:

* progress
* statistics
* mastery levels
* next-question recommendations

**must never be written as ground truth.**

They must exist only as **derived views** (see Section 3).

---

### 2.2 Minimum Event Schema (Recommended)

Every learning / interaction / scoring / correction event must include:

* `event_id`
  (content hash or UUID — content-hash preferred for replayability)

* `ts`
  (event timestamp)

* `scope`
  (`project_id`, `child_id`, `session_id`)

* `actor`
  (who triggered the event)

* `event_type`
  (finite enum such as
  `attempt`, `answer`, `hint`, `reward`, `content_view`, `parent_override`)

* `payload`
  (event content)

* `prev_event_ref` *(optional)*
  chain reference for stronger replay / tamper-evidence

* `schema_version`

---

### 2.3 Idempotency: Duplicate Submission is the Default State

You explicitly defined the system as:

**online-only**, where network failure, retries, and partial writes are normal.

Therefore:

* the client **must attach `request_id`** to every submission
* the server deduplicates by `(child_id, request_id)`
* duplicate events are allowed to arrive multiple times but **must only be recorded once**

And importantly:

**The client must never advance local progress based on “whether a response was received.”**

This corresponds directly to your law about **implicit state advancement control failure**.

---

## 3) Derivation Views: Progress and Memory are Reconstructable Artifacts

### 3.1 Core Definitions

* `raw_event`
  append-only factual record

* `derived_view`
  a state snapshot computed from raw events via a deterministic reducer

* `memory`
  a **version-frozen artifact produced through explicit promotion**, written into the `law/objects` or vault layer

Memory must **never emerge automatically from raw events.**

---

### 3.2 Reducers Must Be Auditable Functions

Every reducer must include:

* `reducer_id`
* `reducer_version`

Every derived view must record:

* `input_range`
  (which events were used)

* `reducer_id@version`

* `output_hash`

Reducers may be upgraded and views rebuilt, but:

**the results must remain diffable and auditable.**

This enables exactly what you want:

**replayable history + rebuildable derived views.**

---

## 4) Telemetry Hygiene: Telemetry is Untrusted and Disposable

### 4.1 Three Hard Rules

Directly implementing your principle:

**“Telemetry must never become truth by accident.”**

1. **Telemetry is ephemeral**
   Short TTL only (e.g., 7 days) for debugging and operations.

2. **Telemetry never participates in derivations**
   Reducers read only from the ledger.

3. **Cross-boundary promotion must be explicit**
   If telemetry is promoted to evidence or knowledge, it must pass through a manual action:

   `PromoteTelemetryToEvidence`

   producing an auditable artifact with justification and signature.

---

### 4.2 Git / Repository Hygiene

Consistent with your laws:

* `_system` may write automatically
* **runtime outputs must never be committed**

Writes to:

* `sovereign_log/`
* `law/objects`

must always be **human-triggered or explicitly approved promotion events**.

---

## 5) Authorization: Hard Capability Separation Between Child and Parent

### 5.1 Two Capability Domains

**Child Runtime**

Allowed:

* read kid content
* write own ledger events
* read own derived views

Forbidden:

* import content
* modify rules
* query other children
* export data
* promote memory

---

**Parent/Admin**

Allowed:

* import content libraries
* configure rules
* view audits
* export data
* perform explicit promotion
* system maintenance

---

### 5.2 Minimal Session Implementation

Under the constraints:

* **local network only**
* **no external internet access**

A minimal system is sufficient:

* iPad child mode → short-lived session token bound to `child_id`
* parent/admin interface → separate authentication (Mac mini local access)

**A token must never carry both child and admin capabilities.**

This prevents **capability bleed**.

---

## 6) Mac mini Control Plane: Engineering Commitments

Your Risk Resolution (CASE-11AF425603) assumes:

* Mac mini is always running
* no external remote access
* Wi-Fi first, wired if needed
* scheduled backups and maintenance

Engineering commitments therefore include:

**Single-node first**

* one Mac mini acts as both **app server and canonical store**

**Backup is policy, not optional**

At minimum:

* daily incremental backup of ledger + assets + configs
* weekly full snapshot (external disk / second mini / NAS)

**Maintenance windows are explicit**

Updates and migrations must be logged in an **operations log** to prevent silent drift.

---

## 7) Minimal Implementation Checklist

Before writing application code, the following **seven structural rules must exist first**:

1. **Define ScopeKey enforcement**
   `(project_id, child_id, session_id, actor, request_id)` required on writes.

2. **Define Ledger Event Schema v1**
   finite `event_type`, append-only, idempotent.

3. **Implement Idempotency**
   dedup index on `(child_id, request_id)`.

4. **Implement Reducers**
   ledger → progress view with reducer version tracking.

5. **Implement Telemetry TTL**
   logs stored separately with automatic expiration.

6. **Implement Promotion Gate**
   runtime → durable knowledge must pass explicit promotion.

7. **Implement Capability Separation**
   child tokens and admin tokens must be strictly isolated.

Human Intentions Are Inherently Vague: Intentions Are Not Extracted — They Are Compiled

Human intention is not a problem of missing parameters; it is a problem of structure that has not yet taken shape.

First, you must use an LLM.

Because a raw intention is not a fully formed specification. It is usually a mixture: goals, emotions, vague boundaries, unnamed constraints, default assumptions, latent risks, and even internal contradictions are all entangled in a single sentence. Pure rules or simple textual templates may extract fragments of this information, but they cannot reliably unfold the latent structure embedded within an intention.

Second, it must ultimately land in a schema.

Because without entering a structured representation, every downstream component—memory calls, case classification, composers, schedulers, and ledgers—loses its prerequisite for being schedulable.

Enough theory. Let me show you directly. I will walk through the command line and the code at the same time. As you watch the command-line output, you will notice that a large portion of the content is automatically expanded, extracted, and completed by the LLM itself.

=== ROUND OUTPUT ===
[run_id] 20260305T145405Z__64411957  [round] 1
{
  "intent": {
    "project_name": "",
    "one_liner": "",
    "success_metrics": [
      "Mac mini runs 24/7 without unexpected downtime for at least 30 days.",
      "All designated family services and applications are accessible and functional within the home network.",
      "Identity management system reliably authenticates and authorizes family members.",
      "Automation tasks execute as scheduled without failure.",
      "Content libraries are accessible and synchronized across family devices."
    ],
    "non_goals": [
      "Hosting services accessible from outside the home network (no external remote access).",
      "Replacing existing internet service or router functionality.",
      "Managing devices outside the home network."
    ],
    "time_horizon": "weeks",
    "budget_band": "medium"
  },
  "description": "Set up a Mac mini to act as a local server hosting family services, managing identities, coordinating home network applications, and serving as the central node for home computing, content libraries, and automation tasks. The Mac mini must run continuously and maintain reliable connectivity with the home router.",
  "scope": {
    "hardware": "One Mac mini machine within the home network.",
    "network": "Local home network connectivity only.",
    "services": "Family services, identity management, application coordination, content libraries, automation tasks.",
    "uptime": "Continuous operation with stable connectivity to home router.",
    "devices": [],
    "platforms": [],
    "infra": [],
    "users": []
  },
  "constraints": {
    "hard": [],
    "soft": []
  },
  "policies": [
    "access_to_the_mac_mini_and_hosted_services_restricted_to_family_members",
    "regular_backups_of_critical_data_and_configurations",
    "updates_and_maintenance_scheduled_to_minimize_downtime"
  ],
  "assumptions": [
    {
      "assumption": "The Mac mini hardware is already owned and available for use.",
      "status": "unconfirmed",
      "ask": "Do you already have the Mac mini hardware available, or will acquiring it be part of this project?",
      "impact": "High"
    },
    {
      "assumption": "Family services and applications to be hoste
...

The most important part of this code is that, from the very beginning, it explicitly acknowledges that the first round of input is not truth—it is only a seed. seed_text is not the final spec, not a finalized requirement document, and not a reliable object that can directly enter the implementation layer. It is merely a high-entropy starting point: a subjective input of intention that has not yet fully collapsed into structure. This judgment is crucial, because one of the most fatal problems in many systems is precisely that they mistake the user’s first sentence for the truth of the requirement, and immediately begin writing solutions, code, and architecture recommendations as if the input had already been structured. I explicitly treat the first expression as an object to be compiled, not an object to be executed.

At the same time, the code institutionalizes guessing, rather than allowing guessing to happen silently. The system prompt in the code explicitly requires: every guess MUST be recorded in intention_spec.assumptions[] with status='unconfirmed'and an ask question. This means the LLM is allowed to participate in expanding the intention, but it is not allowed to disguise expansion as fact. The system permits inference, but requires every inference to leave a structural trace and enter a later confirmation chain.

As a result, the entire intention space is clearly divided into several layers: what has been directly provided, what has been inferred, what remains unconfirmed assumptions, and what must continue as open questions. This is not ordinary information organization. It is a mode of intention compilation with built-in cognitive hygiene and governance constraints.

More importantly, this is not a one-shot parse. It is a process of multi-round recursive convergence, and that is the part that comes closest to the reality of human intention. Human intentions are rarely fully expressible in one pass—not because people lack expressive ability, but because boundaries, goals, constraints, non-goals, and success criteria usually only emerge gradually through questioning and feedback. That is why the output is naturally designed to evolve by round, and why the command line can also enforce a maximum number of rounds. In real usage, I usually stop proactively when the LLM’s questions begin to repeat and the question space starts to dry up, because that usually means the current intention has reached a point of local convergence.

By the end, this compilation process does not merely produce a vague summary. It directly generates a case ID and determines which enumerable direction the intention belongs to. My intention directions are not floating infinitely in ambiguity; they can be classified through protocol. For example, this particular intention would be classified as Risk Resolution. And this directional classification is not decided by a purely automatic black box. It can be jointly confirmed by the human and the LLM: the LLM provides structured candidates and confidence levels, while the human performs final confirmation when needed.

So what the whole system is doing is no longer simply “explaining a sentence.” It is compiling a high-entropy intention, round by round, into a structured object that carries a case identity, a directional classification, a list of unresolved questions, and the prerequisites for downstream routing.

The code itself is actually quite simple. If you take this paragraph of mine together with my example and give it directly to an AI, it can immediately generate a working piece of intention-compilation code.

 

=== ROUND OUTPUT ===
[run_id] 20260305T145405Z__64411957  [round] 2
{
  "intent": {
    "project_name": "Home Mac Mini Control Plane Setup",
    "one_liner": "Configure a Mac mini as the primary local server for family services, identity management, and home automation within the home network.",
    "success_metrics": [
      "Mac mini runs 24/7 without unexpected downtime for at least 30 days.",
      "All designated family services and applications (children's education, home mail/document scanning and AI reading, home inventory management, home calendar management) are accessible and functional within the home network.",
      "Identity management system reliably authenticates and authorizes family members.",
      "Automation tasks execute as scheduled without failure.",
      "Content libraries are accessible and synchronized across family devices.",
      "Mac mini maintains stable connectivity over Wi-Fi with the home router."
    ],
    "non_goals": [
      "Hosting services accessible from outside the home network (no external remote access).",
      "Replacing existing internet service or router functionality.",
      "Managing devices outside the home network.",
      "Wired network connectivity setup (currently relying on Wi-Fi)."
    ],
    "time_horizon": "weeks",
    "budget_band": "medium"
  },
  "description": "Set up a Mac mini (2-3 units available) to act as a local server hosting family services including children's education, home mail/document scanning with AI reading, home inventory management, and calendar management. It will manage identities and coordinate home network applications, serving as the central node for home computing, content libraries, and automation tasks. The Mac mini must run continuously and maintain reliable Wi-Fi connectivity with the home router. No external remote access is planned at this time.",
  "scope": {
    "hardware": "2-3 Mac mini machines already acquired, one to be configured as primary server.",
    "network": "Local home network connectivity only, currently over Wi-Fi.",
    "services": [
      "Children's education applications",
      "Home mail/document scanning and AI reading",
      "Home inventory management",
      "Home calendar management",
      "Identity mana
...

=== QUESTIONS ===

[P0] Q-1: Are you open to using wired Ethernet connectivity if Wi-Fi proves unreliable for continuous operation?
Answer (empty to skip): Let's try hard to make Wi-Fi work first. 

[P1] Q-2: Do you have existing backup solutions or preferences for backing up the Mac mini and its data?
Answer (empty to skip): No existing solutions but openned for options.

Continue to next round? [Y/n]: n
[skip] user stopped; partial artifacts preserved.

[confirm] Case type requires human confirmation.
Primary: Risk Resolution
Secondary candidates: Architecture Decision, Exception Handling, Intent Clarification
Confirm case type (enter to keep pending): Risk Resolution
/Users/sovereign_knowledge_lab/_system/calls/intention_compiler/20260305T145405Z__64411957/FINAL/intention_for_composer.json

Once you are building your own knowledge base, you must fix the identity structure: this context has to be preserved over the long term

The core of the next stage is not to keep piling more material into the knowledge base, but to first lock down the clear identity structure that every pipeline must attach to.

As long as you use LLMs over time, one thing becomes increasingly obvious: windowed conversation is fundamentally a dissipative information device. It generates quickly, expands quickly, and drifts quickly as well. Things that were said have no stable identity, no structural anchor, and no capacity for later aggregation. As a result, it easily turns into a situation where you have “talked a lot, but deposited very little.”

If you agree with the direction of linking together window interaction + personal knowledge base + memory base + invocation library, then the first step is absolutely not to keep optimizing prompts. The first step is to use a strict schema to nail down the identity structure.

At a minimum, you need the two basic layers of project and case:

• project is the long-running continuum. It represents a continuously evolving problem domain.

• case is a single concrete compilation, a single conversational convergence, a single task slice.

One project can contain multiple cases. Only then can those cases later be recalled, compared, aggregated, replayed, and reinterpreted.

Without this layer of identity structure, all outputs are merely temporary text. With it, information is transformed for the first time from floating content into a governable object.

In the most basic schema, what is truly indispensable is not fancy fields, but several categories of fixed anchors.

First, identity keys such as project_id, project_context_id, case_id, and case_type. These answer the questions: Who is this? Which continuum does it belong to? Which slice is it currently in?

Second, the provided layer. This freezes the actual confirmed intention skeleton inside the current case, including intent, scope, constraints, policies, open_questions, readiness, and the original seed_text. In other words, it compresses a single window input into a reusable project context that can continue to be compiled.

Third, source and timestamps. These preserve the source chain, input path, generation run, and provenance rule, ensuring that every later derivation can be traced back to where exactly this round originated.

Going one step further, a case cannot be merely a text result. It must also have its own case.bundle.shell. Because once a case is classified into a certain direction—such as Architecture Decision or Risk Resolution—the downstream invocation should no longer be an unbiased wander through the space. It should instead be driven by the case type, with different query biases, different lenses, different question frameworks, and different output slots.

That means identity structure is not merely about “naming files.” It establishes a foundational governance fact inside the system:

Different cases under the same project may share context, but they differ in problem type, invocation bias, report structure, and downstream aggregation logic.

So the real turning point is here: a knowledge-base pipeline does not begin to mature when it has “stored enough content.” It begins to mature when every piece of content is first bound to a stable identity.

The window itself does not provide continuity. Continuity must be artificially constructed through schema.

The LLM itself does not provide memory order. Memory order must be carried by the identity chain of

project → case → context → bundle.

Once that chain is fixed, multiple cases under the same project can later be aggregated into comparable historical slices. Within the same case, its context, bias, report, and decision can then form a structural closed loop that is replayable, verifiable, and inheritable.

In other words, the next stage of a knowledge-base pipeline is not about becoming more articulate. It is about first ensuring that everything you say acquires an identity that will not drift away

Here comes the most satisfying part: your questions are asked dozens at a time

The problem with window-based conversation is that questions have to be asked one by one. Isn’t that exhausting?

By the time you reach this stage, for this context, this case, this bundle of information that already contains a large amount of project data, open questions, and personal intention—are you really still going to break it apart into one tiny question after another and ask them separately in an LLM chat window?

Instead, you write a memory_call_composer. Its job is to gather all project information accumulated so far, together with the information about the intention direction, and then decompose that whole bundle into a series of questions that should be sent to the memory call library for retrieval. One run. That’s it.

Of course, for different intention directions, you can prepare different weighting strategies in advance. I wrote a protocol for this myself: it defines different question directions and corresponding weights. That is an entire design system in its own right, and I will not go into detail on that here.

Once you reach the real retrieval stage, one path uses a kind of vector-based recall. The other path is more structuredand more complex; I will explain that later if I have time. For now, clarifying the principle is more important.

Why do I take these two paths in parallel? Because I believe the truly appropriate solution lies somewhere between them. And this also depends on the quality of the “laws” inside your library.

Most people play with RAG and vector retrieval and feel that it is elegant, powerful, and obviously correct. That feeling exists because their library is still not large enough. Its information density is not yet high enough. Once the information space becomes truly saturated—as happens in some companies—you start to see that plain RAG begins to break down.

What I want to explain here is exactly what level of problem this really is. In computer science, if we want any chance of solving a problem, we first need to define the problem precisely.

    "lenses": [
          { "id": "L-GOAL", "weight": 0.95, "title": "Goal & one-liner", "rationale": "Reduce high-entropy intent into a crisp target." },
          { "id": "L-SUCCESS", "weight": 0.9, "title": "Success metrics & definition of done", "rationale": "Make success measurable and testable." },
          { "id": "L-SCOPE", "weight": 0.85, "title": "Scope boundaries (in/out)", "rationale": "Prevent scope creep by explicit inclusion/exclusion." },
      

The most appropriate analogy for this problem is not actually computer science—it is the legal domain. Law is a classic “hard humanities” discipline. Many people with engineering backgrounds tend to underestimate it, but if you look a bit deeper you realize that in many core aspects the complexity law faces is no lower than that of engineering systems. I personally spent about three months systematically reading some basic materials on the Anglo-American legal tradition, along with bits and pieces of related coursework I had taken in school. Gradually I came to realize something important: many of the problems we repeatedly encounter today in AI, knowledge systems, and engineering decision-making are structurally very similar to the problems studied for decades in Legal Informatics.

If you abstract the issue, the core really boils down to two problems.

1. Applying an existing rule system correctly to new cases

In legal language, this means you have a body of established law—a rule library—and a completely new case appears. The question becomes: how should this case be judged under the existing legal system?

In engineering language, it means: under an existing rule system, how should a new project or problem be executed?

At its core, this problem solves decision continuity. When a rule system can be reliably applied to new cases, you no longer need to rethink everything from scratch whenever a new project appears. You do not have to repeatedly restart projects or rebuild decision logic. Instead, the system can immediately enter the construction phase, rather than getting trapped in endless loops of micro-decisions.

This is exactly the problem I am trying to solve in this article: how to maintain decision continuity when facing new problems.

For programmers to truly escape the “project restart hell,” the key is not getting the model to write more code for you. The key is building a structured core that can rapidly compress new projects into an existing rule system.

When facing a new project, you should not have to start again from a blank document, a blank repository, or a blank mind. You should not have to repeat the entire high-entropy ordeal of requirement decomposition, boundary debates, field naming, relationship definitions, and architectural hesitation.

Instead, you should only need to provide a small amount of high-quality input—for example:

• intention

• constraints

• target users

• runtime environment

• risk boundaries

• core objects

From this, the system should immediately generate a construction-ready structural foundation, including:

• architectural layers

• module boundaries

• authorization boundaries

• data flows

• object models

• field definitions

• object relationships

• constraint rules

• logging strategies

• audit paths

It should even determine structural rules such as:

• which components must be append-only

• which fields must carry stable IDs

• which relationships must be explicitly declared

• which modules must never read or write across boundaries

All of this should be expanded before coding begins.

In this way, a new project is no longer a one-off creation that starts from zero. Instead, it becomes the act of mapping a new intention into an existing structural universe, locating and instantiating it.

The programmer no longer needs to reinvent the wheel each time. Instead, the system’s accumulated judgment, boundary awareness, object language, field discipline, and relationship protocols can be invoked directly. Past architectural experience becomes a generative capability that unfolds immediately.

The truly valuable outcome is not that AI writes ten functions for you. The real value is that given a simple intention and a few constraints, the system can generate a buildable architectural skeleton:

• how many layers the system has

• which objects are first-class citizens

• which fields serve as identity anchors

• which relationships are permitted

• which events must enter the ledger

• which states are derived and cannot be written directly

• which modules can only communicate through explicit interfaces

Only when this level of structure exists does the programmer escape the restart hell. At that point, starting a new project becomes more like invoking a mature structural runtime: input an intention, and immediately receive an executable architectural starting point.

Be honest—doesn’t that feel great?

2. Determining exactly which rules a case matches

The second problem is that you must also know which rules in the rule library a specific case actually hits, and this matching must be precise, explainable, and traceable. It cannot be vague semantic guessing, and the AI must not be allowed to invent rules arbitrarily.

In legal language, this means determining which statutes apply to a real case.

I can say quite clearly that this is one of the central and most difficult problems studied in Legal Informatics for decades.

The problem sounds simple:

given any real-world case, determine all applicable legal rules.

At first glance this might seem like a search problem. But in reality it is far more difficult. If keyword search were sufficient, lawyers would have become obsolete the day Google appeared. Clearly that did not happen.

The reason is that a real case may share no vocabulary overlap at all with the legal rules that apply to it (aside from meaningless words like articles or prepositions). The true problem therefore becomes: how does a case find the legal rules and precedents that actually apply?

This turns out to be one of the hardest information retrieval problems in the world. The difficulty comes from three main factors:

First, statutes and cases rarely match through keywords. Legal rules are abstract principles, while cases describe concrete facts. The connection between them is primarily structural and logical, not textual.

Second, legal reasoning is fundamentally analogical reasoning. It is not simply “rule → conclusion.” Instead it is more like:

“Case A is similar to Case B in key facts, therefore the rule applied in B can also apply to A.”

This type of reasoning structure is extremely difficult for machines.

Third, legal application depends on fact patterns. What matters in a case is not the narrative text but the structure of facts: who participated, what actions occurred, whether intent existed, whether harm occurred, what the surrounding context was. These elements combine into a fact pattern, and legal rules operate on those patterns.

For these reasons, Legal Informatics is an extremely valuable field for programmers to study. Especially after the explosion of AI, a new direction—Legal Automation / RegTech—has been rapidly developing. Applications include contract analysis, compliance review, legal QA systems, litigation prediction, and contract generation. Typical companies include Harvey AI, Casetext (CoCounsel), Ironclad, and LawGeex.

However, to be frank, most current products still remain at the NLP layer. They primarily rely on semantic similarity, vector retrieval, and text generation. The truly difficult problem—structural matching between cases and rules—has still not been fundamentally solved.

If keyword search doesn’t work, why doesn’t embedding fully work either?

First, to be clear: embeddings are not useless. I use them myself, and they work very well in many scenarios—such as personal knowledge bases, medium-sized corpora, and exploratory search.

Early on I relied almost entirely on embeddings. But as my library gradually grew larger and its quality improved, I began to notice a core issue:

Vector retrieval is fundamentally similarity ranking, not match detection.

Most vector databases—FAISS, Milvus, Pinecone—follow the same logic:

1. convert the query into an embedding

2. compute cosine similarity

3. return the top-k results

The problem lies exactly here: top-k is not the same as match.

The system can only say “these are the most similar,” but it can never say “these are the correct matches.”

When your library becomes sufficiently refined, you will almost inevitably arrive at the same technical realization I did:

you will want to measure match counts.

For example, you may want to know how many times a particular rule or law has been precisely matched by the system. When I was building the promotion pipeline described in my previous article, I reached exactly this stage. The idea seemed reasonable: generate candidate rules from high-entropy content, then determine which rules should be promoted into stable structures by counting how often they are matched.

It sounded perfectly logical.

But after nearly two weeks of experiments (during which I built several approximate solutions that initially looked promising), I ultimately abandoned the idea entirely. And I can very clearly recommend that others abandon it too.

It drove me crazy.

Seriously—don’t fall into this trap.

The reason is simple: there is no stable “match set” in vector retrieval.

The semantic space is fundamentally a continuous concept space, not a discrete set. There is no clear relevant/irrelevant boundary. The system can only say that some results are more similar, but it cannot say that a result is a match.

The second problem is that top-k itself is arbitrary. Results differ completely when top_k=5, top_k=20, or top_k=100. A rule might never appear in top-5, but suddenly appear in top-20. So the so-called “match” depends entirely on an arbitrary threshold.

The third problem is that embedding spaces drift. If the embedding model changes—for example from embedding v1 to v2—the entire vector space shifts. The same query may return completely different top-k results. That means all historical statistics become instantly invalid.

Taken together, these factors lead to one conclusion:

Vector retrieval is inherently unauditable.

You can absolutely use it for rough recall, candidate discovery, or exploratory search. But it is very difficult to use it to answer governance-level questions, such as:

“How many times has this rule actually been matched?”

Because in vector space, the concept of match does not exist—only similarity ranking does.

For this reason, many mature systems eventually converge toward a similar architecture:

1. structural filtering to obtain candidate sets

2. vector retrieval to expand recall

3. ranking or reasoning to produce final outputs

In other words, vector search works best as a recall helper, not as the truth layer.

What a real rule “match” looks like in my system

Now let me show you what a genuine rule hit looks like in my system when an intention is processed.

Here, “hit” does not mean semantic similarity or top-k ranking. It means a structural match that can be precisely located to a specific law_id.

In other words, the system can clearly tell you:

which rule was matched,

not merely which rules look similar.

Once matches are determined in this way, they can be further processed structurally:

• clustering

• visual rendering

• binding to specific cases

• semantic explanation and expansion via LLM

Eventually this produces a practical analysis report that can guide real implementation.

In such results, the system no longer returns vague semantically similar text. Instead, it returns a set of concrete rule objects, each carrying a stable law_id. These objects can be tracked, counted, reused, and audited.

Only when something is truly matched in this sense can statistics be meaningfully computed.

Let me once again mourn the pit I fell into for several weeks.

{
    "schema_version": "law.object.asset.v1",
    "id": "AST-1b646b4b",
    "kind": "summary",
    "status": "active",
    "body": {
      "title": "Principles Derived From Institutional Positions",
      "goal": "Compression/note derived from conversion; not a governance claim.",
      "spec": {
        "principles": [
          "Runtime Traces Are Not Events",
          "Event Ledgers Optimize for Accountability",
          "Without Replayable Judgment, History Becomes Indefensible",
          "Not All Traces Become History"
        ],
        "_gate_reason": "spec_too_thin"
      }
    },
    "links": [],
    "evidence": []
    
      {
    "schema_version": "law.object.asset.v1",
    "id": "CNS-17630e57",
    "kind": "constraint",
    "status": "active",
    "body": {
      "title": "Zone I: World State Memory Constraints",
      "goal": "Enforce strict quality and update constraints on World State Memory",
      "spec": {
        "must": [
          "High confidence only",
          "No speculation",
          "No hypothesis",
          "No automatic updates"
        ],
        "severity": "binding"
      }
    },
    "links": [],
    "evidence": []
  },

A Trap Almost Every AI Engineering Team Falls Into

Why “RAG + Vector Databases” often collapse once the scale grows

Rule Databases Must Be Discretized

By the way, if you truly want to achieve precise rule matching, there is a prerequisite you cannot avoid: you must first convert your long-form inputs into highly condensed rule objects with stable IDs.

This is exactly the kind of task that LLMs are exceptionally good at—and the results are surprisingly effective. It is almost the definition of a low-cost, high-return workflow, so it would actually be strange not to do it.

This is how my own library operates. The raw inputs are all long .md articles containing case descriptions, project background, and reasoning processes. As I work on projects, I continuously write and feed these articles into the system. You don’t need to worry about how many inputs there are, and you don’t need to worry about overlap between different articles.

There is only one requirement:

every word in that article must be something you have personally read, agreed with, and endorsed. It must represent your genuine experience, judgment, and accumulated knowledge.

The technical implementation is actually very simple. I keep a small UI permanently open in a browser page. Whenever I have something to record, I type it in and submit it with a single click to add it to the repository. Some days I add only a few entries; other days I might add dozens.

After that, I run a script called convert_to_law_object.py. Again, it’s a one-click operation. The script converts all of the articles entered that day into rule objects and law objects.

This step relies on an LLM (and it doesn’t even require a particularly powerful model). The model handles the extraction extremely well.

Let me give a simple example that you can easily replicate. How many rules can be extracted from a single article, and what category each rule belongs to, is actually determined entirely by your own code logic.

For instance, in the example below, some candidate rules are blocked by the _gate mechanism and therefore downgraded to "summary" instead of "constraint".

In fact, I would recommend making your gate strict rather than permissive. Otherwise the system may automatically generate hundreds of constraints per day, and the rule layer of the entire system will quickly spiral out of control.

{
    "schema_version": "law.object.asset.v1",
    "id": "AST-1b646b4b",
    "kind": "summary",
    "status": "active",
    "body": {
      "title": "Principles Derived From Institutional Positions",
      "goal": "Compression/note derived from conversion; not a governance claim.",
      "spec": {
        "principles": [
          "Runtime Traces Are Not Events",
          "Event Ledgers Optimize for Accountability",
          "Without Replayable Judgment, History Becomes Indefensible",
          "Not All Traces Become History"
        ],
        "_gate_reason": "spec_too_thin"
      }
    },
    "links": [],
    "evidence": []
    
      {
    "schema_version": "law.object.asset.v1",
    "id": "CNS-17630e57",
    "kind": "constraint",
    "status": "active",
    "body": {
      "title": "Zone I: World State Memory Constraints",
      "goal": "Enforce strict quality and update constraints on World State Memory",
      "spec": {
        "must": [
          "High confidence only",
          "No speculation",
          "No hypothesis",
          "No automatic updates"
        ],
        "severity": "binding"
      }
    },
    "links": [],
    "evidence": []
  },

记忆是可调度的结构, 品位是未来决策空间持续施加偏置的引力场：程序员需要有自己的外置库，否则无法保持自己的决策延续性——也甚至无法维护自己开发的代码

在距离上一次更新文章之后，我的开发又经历了无数次的试错。无数条尝试的链条被打开，又有无数条枝条被剪掉。很多一开始看起来非常 promising 的路径，走着走着发现是死胡同；很多一开始毫不起眼的方向，反而越走越通。总之就是不断地试，不断地拆，不断地重组。终于进行到一个我认为可以停下来写一篇文章分享的阶段了。我们先回顾一下我的初衷。其实我相信很多程序员现在也和我一样，已经明显感觉到一个变化。我和一些朋友聊过一个很重要的事情（也许你已经觉得这根本不是什么新闻了），就是我们都越来越确信，未来的趋势就是不再去细看代码了。肯定不会有人再像过去那样一行一行手打代码。当然，每个人的程度不一样。比如我自己，现在基本已经不看 AI 第一次生成的代码，但是我会去看 diff code。因为我发现，在 diff 的时候经常会看到一些非常有意思的事情。有时候 AI 为了达到我提出的要求，会写出一些让我哭笑不得的代码。举个例子，我要求 AI 做一种结构化的渲染方式，希望未来保持比较好的通用性和可扩展性。结果它给我的解决方案是枚举一长串相关关键词。这个做法在当前问题上是 work 的，但是从结构上来说，这几乎是在主动破坏未来的通用性。这种代码一眼就能看出来，是为了通过当前任务而存在的代码，而不是为了系统长期演化而存在的代码。所以我现在觉得AI 写代码的问题其实从来都不是代码本身，代码只是一个表象。真正的问题，是人在做什么决策，以及这些决策是否能够持续下去。

这也是为什么最近很多程序员都在讨论一个话题，那就是 memory。几乎所有 AI coding 框架最后都会绕到这个问题上。但我问了一圈之后发现一件非常奇怪的事情：几乎没有人能清楚地说出“记忆到底是什么”。记忆是写在书里的内容？写在 Notion 或 Obsidian 的笔记？存在数据库里的信息？LLM 的向量召回？很明显都不是。如果事情真的这么简单，那么 Notion、Obsidian 加上 AI plugin 早就把这个问题解决了。但现实是完全没有。大家还是在不断重复同样的事情。所以慢慢地，我开始觉得，我们想解决的问题其实并不是“记忆”，或者说不是那种人脑意义上的记忆。如果要用一句最简单的话来说，我们真正想解决的问题其实是决策的连续性。

人脑无法在极复杂的场景和长时间的工作中保持决策的连续性，这是我们大部分痛苦的根源。

我说一下现在我自己，以及我相信屏幕前的你，一定遇到过或者已经隐隐感觉到的几个程序员地狱级问题。

1）项目重开地狱。 不管你写过多少代码，不管你做过多少项目，不管你写过多少文档，每当你开始一个新项目的时候，总会有一种非常强烈的感觉：一切又要从头开始了。但与此同时，你又会隐隐觉得事情不应该是这样的。因为你能明显感觉到，很多项目底层结构其实是相同的。很多项目从某种意义上来说只是换了个马甲。哪怕表面上看起来完全不相关，一个是教育 app，一个是知识系统，一个是 web service，一个是 AI 工具，但在底层层面，例如身份管理、权限控制、数据结构、状态管理、事件系统、演化路径，这些结构往往高度相似。问题是，人脑很难把这些结构重新抽出来，再重新组合出来。所以每一次“新项目”，其实都像是进入了一个新的平行宇宙。你会不断看到似曾相识的东西，似曾相识的 bug，似曾相识的架构，甚至连修 bug 的感觉都非常熟悉。每一次项目开始，你都感觉自己又回到了起点。这就是项目重开地狱。

2）Micro-decision 地狱。 即使现在 AI 写代码非常快，但窗口不是万能的，项目从来都不是一个 prompt 就能完成的。一个真实系统更像是一堆层层叠叠的跷跷板，每一个跷跷板的支点其实都是一个决策。这个模块应该放在哪里，这个 API 应该怎样设计，这个数据结构是否可扩展，这个逻辑是否会影响未来，每一个看似微小的决策都会影响整个系统。而在今天的开发环境里，你往往同时扮演前端、后端、架构师、算法工程师、产品经理这些角色，所以这些 micro-decision 全部压在你一个人身上。每一个决策看起来都不大，但它们的数量却是天文数字级别的。你的时间和脑力不断被这些微小决策消耗掉。项目越复杂，这种感觉就越明显。最后你会发现，真正拖慢你的并不是写代码，而是无穷无尽的小决策。这就是 micro-decision 地狱。

3）技术债地狱。 这个大家更熟悉，经典的屎山代码。但在我自己的语境里面，技术债其实还有一种更隐蔽的形态，就是无法演化的技术债。很多时候，当你在做一个项目的时候，其实没有能力去做非常长远的系统规划，因为时间不允许，信息不完整，决策太多，于是很多设计都是临时可用。但问题在于，当系统需要真正升级的时候，你会突然发现技术债已经堆成山了，很多地方不敢改，一改就炸。还是那个跷跷板问题，你按下一块板子，你不知道有多少块板子会因为这个动作而翘起来。于是最后你会做出一个非常熟悉的决定：算了，重开吧。于是我们又回到了项目重开地狱。

如果你仔细看就会发现，这三个地狱其实是同一个问题的不同表现。项目重开、micro-decision、技术债，它们背后的核心问题其实只有一个：决策无法连续。每一次你都在重新做决策，每一次你都在重新思考同样的问题，每一次你都在重新犯同样的错误。而如果把这个问题和最近程序圈最火的一个词连在一起——Taste——事情就变得非常有意思。很多人说，一个真正厉害的工程师最重要的不是代码能力，而是 taste。但 taste 到底是什么？我越来越觉得，taste 本质上就是决策连续性的压缩。一个有 taste 的人并不是每次都重新思考，而是他的很多决策其实早就已经在大脑里被结构化了。所以当新的问题出现的时候，他不是在思考“我该怎么做”，而是在调用“我以前是怎么做的”。所以如果我们把问题说得更直接一点，如果 AI 可以写代码，那么未来真正的问题其实不是如何写代码，而是如何让决策具有连续性。很多人说他们在解决 memory problem，但我觉得那只是一个表面。真正的问题其实是如何把人的决策结构保存下来，并且在未来继续被调用。而我这段时间做的一切试错，其实都是围绕一个问题展开的：如何让决策不再从零开始。

快进一万步，我先告诉你我这段时间已经成功做到的一件事情。现在我写文章，其实已经没有办法按照“实时记录思考过程”的方式来写了。我只能选择在我认为素材已经积累到足够有价值的时候，把某一个阶段的最终觉悟拿出来分享。原因很简单，现在的信息吞吐量实在太大了。每天试错、重构、推倒、再试错的循环太多，我如果把每一个中间状态都写下来，那基本什么事情都不用干了。所以现在我能展示给你的，其实是一个已经跑通的结果：如何从一个意图（intention）出发，一键（就是字面意义上的按一个按钮，至于中间命令行里那些 Yes、No、Continue、复制黏贴之类的动作，其实都不提供额外信息，可以忽略），仅仅依靠代码、模型渲染和调用，以及我自己设计和梳理的知识库，只通过调用库中已经存在的知识，一次性生成一份完整的、能够立即指导可靠代码和系统架构的决策文档。

1）首先，这种方式直接省掉了无数个窗口被拉满的过程。 我相信很多人都有这种体验：当你在做一个项目的时候，看起来只是一个很小的架构问题，比如该选什么框架、某个模块该怎么拆、某个数据结构会不会影响未来演化，但这种问题又偏偏需要一点点全局推演。于是你开始开窗口，一个窗口讨论架构，一个窗口讨论数据库，一个窗口讨论 API，一个窗口讨论部署，再开一个窗口问另外一个细节。等你好不容易把某一个问题讨论出一点眉目，前面讨论的内容早就已经 out of the context window 了。于是你只能再开新窗口，再重复一遍。很多时候你会产生一种非常奇怪的感觉，好像自己在一个符号的海洋里不断地打转，看起来很忙，但其实只是绕着一个很小的圈子反复兜圈子——这当然不奇怪，因为 context window 本来就那么大。所以我意识到，我们必须找到一种方式：针对一个意图，一次性生成一份完整的、高密度的决策文档，这份文档包含架构、约束、路径、关键选择，并且全部基于你目前知识体系中的最佳判断。这样一来，你只需要把这份文档直接交给 AI，它就有完整的决策上下文，而不是在几十个窗口里跟它唧唧歪歪东拉西扯。

2）但真正最难的地方，其实不是生成这份文档，而是你是否能够信任它。 你必须信任到某一个程度，才能放心顺着它往下走，否则你还是会忍不住回到“重新开窗口问一遍”的模式。这一点其实非常难，因为信任的基础并不在于模型，而在于你的知识库本身。道理其实很简单：garbage in, garbage out。如果你的知识库本身是混乱的、碎片化的、未经检验的，那么你生成出来的东西也只会是更快、更系统化的混乱。所以过去几个月，我其实花了非常多时间去研究一个看起来和编程毫不相关的东西——英美法系。我后来慢慢意识到，英美法系其实是人类目前已知的、组织复杂社会规则最成功的结构之一。它能够在一个极其复杂的人类社会中维持秩序、法制和公共意志的一致性。更重要的是，它不是依靠某个“完美设计”的规则体系，而是依靠长期积累、判例沉淀、规则迭代形成的。所以在后面的文章里我会讲到，我在设计自己的知识库结构的时候，其实大量借鉴了英美法的结构逻辑。

3）最后，还有一个非常关键的问题，就是你如何理解“迭代”和“升级”。 还是回到刚才提到的法律系统。我以前其实也隐约提到过一点，但真正深入研究以后我才意识到一个很重要的事实：任何规则，只要是被写下来的，它就不可能是完美的。你只要尝试写规则，就会发现很多人潜意识里的那些追求——比如“完美”“无错”“绝对干净”“没有冗余”“静止不变”——这些关键词其实全部都是不可能的。规则一旦存在，就必然处在变化之中。所以一个真正可用的规则体系，本质上一定是一个开放的信息系统。它必须允许新的信息不断进入，并且有一条明确的管道，让这些信息可以被不断地迭代、升级。我以后会经常用一个词来描述这个过程：promotion。也就是说，你写下来的规则并不自动成为规则。只有当它在大量真实项目中被反复调用、被不断验证、被证明确实好用，它才会慢慢沉淀下来，成为真正的规则。人类的法律其实就是这样形成的——它不是被某个人设计出来的，而是被无数次实践慢慢沉淀出来的。任何没有经过这种锤炼的规则，我试过很多次，最后的结果往往都是一句话：你想得美。理想很丰满，现实很骨感。

记忆是可调度的结构, 品位是未来决策空间持续施加偏置的引力场。这一切都在AI时代成为我们每天面对的现实。感谢强大的LLM。

当你开始把自己日常真正使用的知识写下来的时候，这些知识其实必须经过一次提炼。它们不能只是停留在原始项目里的笔记、代码片段或者零散心得，而是需要被压缩成一种可以跨项目使用的规则。举一个非常简单的例子，比如这样一句话：“Ensure system life run_id is contained within a single OS process lifetime.” 这其实是我在很多不同项目里慢慢积累出来的一个经验。它并不是某一天专门坐下来写的规则，而是埋在很多项目复盘、日记和开发心得里面的一种共识。以前要把这种经验从一大堆笔记里抽出来其实是非常费力的事情，但现在这种提取工作完全可以交给 LLM 来完成。所以我大量的笔记（当然这些笔记本身也是经过精心筛选的）最早被我放在一个叫 Sovereign Log 的地方，这个名字其实就是随便起的。当这些内容经过提炼和筛选之后，原来项目中的 context 会被剥离掉，具体代码会被去掉，但规则本身和真正有价值的结构会被标记出来，然后被分类为一条一条的 Law。换句话说，项目的信息被隐藏了，具体实现被拿掉了，但知识的骨架被保留下来了。这一步其实是 LLM 和确定性代码可以配合得非常好的一个工作：LLM 负责理解和抽取，代码负责结构化和归档。我后面也会把具体代码分享出来，这一部分我非常建议大家采用。

接下来，当你继续在各种项目中开发——不管是自己的家庭项目、团队项目、甲方项目，还是日常工作中的项目——你就会不断去调用这个 Law 库。一旦这些规则被放进具体项目里，它们就重新获得了新的 context，这个时候它们就变成了一个 Case。这一点其实和英美法里的判例非常相似：法律本身在那里，但真正重要的是法律如何在现实情境中被应用、被解释、被裁定。这种“规则与现实结合”的过程，我也是通过代码和 LLM 一起完成的。这个部分其实是整个系统里比较难的一块，因为它涉及到很多流程控制和结构约束，我也是最近才做到一个自己可以稳定使用的程度而已。然后，当这些 Case 在真实项目中运行之后，你就会得到反馈：这个规则到底好不好用，跑得顺不顺，哪里需要修改。接着这些信息又会被重新送回系统，进入下一轮沉淀，形成一个持续循环的信息管道。这里面其实省略了几万行代码和几十万字的数据结构设计，不过核心思想大致就是这样：知识从日志中被提炼成 Law，在项目中被调用成为 Case，再通过真实反馈重新回到系统中继续演化。

我给你们看一个例子，一个非常真实的例子。因为我最近正在家里做一件事情：把家庭网络服务器、所有设备以及物联网应用做一次全面升级。这个项目完全是我私人的，所以我很可能会持续拿它作为例子来分享。我可以自己决定分享这个项目，本来就是私人的。你既不想给未来埋任何雷，又希望整个系统在品质、可靠性和长期维护上都保持很高的标准。

而在这个智能时代，我越来越觉得，一个项目的起点，其实应该从 Intention（意图） 开始，而不是从“我要写什么代码”开始。我们来看一个非常简单的例子：一个清晰的意图，最后是如何帮我省掉几十个窗口里来回拉扯、东问西问、不断补 context 的过程的。更有意思的是，当我的这个 intention 被系统完整处理之后，整个项目从决策到架构再到代码生成，最后真正跑起来进行初步测试并投入使用，总共只花了几个小时。这在过去几乎是不可想象的事情。

python3 tools/intention_compiler.py \\
  --text "I intend to configure one of my Mac mini machines to operate as the primary home control plane for my family’s digital infrastructure.This Mac mini will function as a local server that hosts family services, manages identities, and coordinates applications running within the home network.The system will serve as the central node of the home computing environment, providing a stable runtime for family applications, content libraries, and automation tasks.The Mac mini must run continuously and maintain reliable connectivity with the home router." \\
  --max-questions 4 \\
  --max-rounds 3 \\
  --temperature 0.2 \\
  --preview

首先要跑的是一个意图压缩的步骤。这个步骤的意思其实很简单：我们既不从提问题开始，也不从下 command 开始，因为这些东西本身都只是意图的衍生形式。真正的起点应该是意图本身。在很多信息管道里，我越来越觉得，意图才应该是系统真正的入口。这个事情如果要完整解释，可能要讲好几天，不过用我自己的经验来说其实很直观：人的意图本来就是做任何事情最原始的目的。而我们平时习惯的方式——比如提问题（典型的就是搜索引擎时代），或者下达 command（比如 LLM 出现之后我们发现可以用自然语言让它生成代码）——其实都是在适应工具。也就是说，为了实现自己的意图，我们受到工具的限制，不得不把原本的意图翻译成问题或者命令。这个过程看起来很自然，但其实是一个不断“翻译”的过程。只要存在人的转化和翻译，就一定会有信息损失，也一定会产生歧义。所以与其在后面不断修补这些偏差，不如一开始就从意图本身出发。

然后，在我一系列代码和流程跑完之后（这一切基本都是全自动的），我实际上几乎没有再做任何事情。除了回答了一些 LLM 在过程中自己衍生出来的小问题之外，没有额外干预，没有重新开窗口讨论，也没有再去手动拼 prompt。系统只是通过 memory call 去调用我的知识库，再经过模型渲染，最后直接生成了下面这一份报告。接下来我就用这份报告直接开始写代码、启动项目。没错，就是这么直接——一键生成。在我看来，这才是对的方式。至于那种在几十个窗口里反复唧唧歪歪、东拉西扯、不断补 context 的做法，其实才是不对的。我后面会把整个原理慢慢讲清楚。而且这个方向我是完全信赖的，因为本质上它是在调我的知识库，很多核心规则和结构本来就是我自己写下来的。换句话说，这不是把决策交给模型，而是让模型去执行我已经沉淀下来的决策体系。当然我不止这一份报告，这种调用token的成本极低，我想要多少有多少。关键是带来的10倍以上效率提升，而且是不断积累的提升，因为每次报告后期再实践的过程中积累的知识和代码，你不是又喂回信息管道里面去了吗？然后在这份报告生成以后的几个小时（当然我又从其他的方向又生成了一堆，继续把项目补全），就已经做完了。在这个基础上把项目搭起来就快了。

# RISK RESOLUTION — Isolation / Traceability / “Telemetry Never Becomes Truth” for an Online-Only Web App

## 0) Conclusion (One Sentence)

**Define “child learning history” as an append-only Event Ledger routed by child scope; define “memory/progress” as Derivation Views that can be reconstructed from the Ledger; define “telemetry/logs” as Ephemeral Telemetry that is discarded by default. The three must be strictly isolated, and any promotion across boundaries must be explicit, auditable, and replayable.**

---

## 1) Scope as a First-Class Citizen: Hard Boundary for Per-Child Isolation

### 1.1 Scope Key (Required on Every Write)

Every write operation (whether an event, asset, derived view, or uploaded file metadata) must include:

* `project_id`
* `child_id`
* `session_id`
* `actor` (`child` / `parent_admin` / `system`)
* `device_id` (optional but recommended)
* `request_id` (for idempotency)

> **Rule: Any write missing a scope key must be rejected** (HTTP 400/403). There is **no such thing as a “default child.”**

---

### 1.2 Storage Routing

Disk layout and indexing must follow a unified routing rule:

* **Physical path**:
  `/data/{project_id}/{child_id}/...`

* **Logical index**:
  `(project_id, child_id, kind, ts, event_id)`

Shared write locations are **forbidden**.

For example:

* `/data/shared` may only contain a **public content library**
* All assets in `/data/shared` must be **read-only imports created by parent/admin**

This directly implements the rule:

**All writes must be scope-routed by `(project_id, child_id, session_id)`.**

---

## 2) Append-Only Event Ledger: The Only Source of Truth

### 2.1 Status of the Ledger

* **Ledger = Canonical History (single source of truth)**

Anything like:

* progress
* statistics
* mastery levels
* next-question recommendations

**must never be written as ground truth.**

They must exist only as **derived views** (see Section 3).

---

### 2.2 Minimum Event Schema (Recommended)

Every learning / interaction / scoring / correction event must include:

* `event_id`
  (content hash or UUID — content-hash preferred for replayability)

* `ts`
  (event timestamp)

* `scope`
  (`project_id`, `child_id`, `session_id`)

* `actor`
  (who triggered the event)

* `event_type`
  (finite enum such as
  `attempt`, `answer`, `hint`, `reward`, `content_view`, `parent_override`)

* `payload`
  (event content)

* `prev_event_ref` *(optional)*
  chain reference for stronger replay / tamper-evidence

* `schema_version`

---

### 2.3 Idempotency: Duplicate Submission is the Default State

You explicitly defined the system as:

**online-only**, where network failure, retries, and partial writes are normal.

Therefore:

* the client **must attach `request_id`** to every submission
* the server deduplicates by `(child_id, request_id)`
* duplicate events are allowed to arrive multiple times but **must only be recorded once**

And importantly:

**The client must never advance local progress based on “whether a response was received.”**

This corresponds directly to your law about **implicit state advancement control failure**.

---

## 3) Derivation Views: Progress and Memory are Reconstructable Artifacts

### 3.1 Core Definitions

* `raw_event`
  append-only factual record

* `derived_view`
  a state snapshot computed from raw events via a deterministic reducer

* `memory`
  a **version-frozen artifact produced through explicit promotion**, written into the `law/objects` or vault layer

Memory must **never emerge automatically from raw events.**

---

### 3.2 Reducers Must Be Auditable Functions

Every reducer must include:

* `reducer_id`
* `reducer_version`

Every derived view must record:

* `input_range`
  (which events were used)

* `reducer_id@version`

* `output_hash`

Reducers may be upgraded and views rebuilt, but:

**the results must remain diffable and auditable.**

This enables exactly what you want:

**replayable history + rebuildable derived views.**

---

## 4) Telemetry Hygiene: Telemetry is Untrusted and Disposable

### 4.1 Three Hard Rules

Directly implementing your principle:

**“Telemetry must never become truth by accident.”**

1. **Telemetry is ephemeral**
   Short TTL only (e.g., 7 days) for debugging and operations.

2. **Telemetry never participates in derivations**
   Reducers read only from the ledger.

3. **Cross-boundary promotion must be explicit**
   If telemetry is promoted to evidence or knowledge, it must pass through a manual action:

   `PromoteTelemetryToEvidence`

   producing an auditable artifact with justification and signature.

---

### 4.2 Git / Repository Hygiene

Consistent with your laws:

* `_system` may write automatically
* **runtime outputs must never be committed**

Writes to:

* `sovereign_log/`
* `law/objects`

must always be **human-triggered or explicitly approved promotion events**.

---

## 5) Authorization: Hard Capability Separation Between Child and Parent

### 5.1 Two Capability Domains

**Child Runtime**

Allowed:

* read kid content
* write own ledger events
* read own derived views

Forbidden:

* import content
* modify rules
* query other children
* export data
* promote memory

---

**Parent/Admin**

Allowed:

* import content libraries
* configure rules
* view audits
* export data
* perform explicit promotion
* system maintenance

---

### 5.2 Minimal Session Implementation

Under the constraints:

* **local network only**
* **no external internet access**

A minimal system is sufficient:

* iPad child mode → short-lived session token bound to `child_id`
* parent/admin interface → separate authentication (Mac mini local access)

**A token must never carry both child and admin capabilities.**

This prevents **capability bleed**.

---

## 6) Mac mini Control Plane: Engineering Commitments

Your Risk Resolution (CASE-11AF425603) assumes:

* Mac mini is always running
* no external remote access
* Wi-Fi first, wired if needed
* scheduled backups and maintenance

Engineering commitments therefore include:

**Single-node first**

* one Mac mini acts as both **app server and canonical store**

**Backup is policy, not optional**

At minimum:

* daily incremental backup of ledger + assets + configs
* weekly full snapshot (external disk / second mini / NAS)

**Maintenance windows are explicit**

Updates and migrations must be logged in an **operations log** to prevent silent drift.

---

## 7) Minimal Implementation Checklist

Before writing application code, the following **seven structural rules must exist first**:

1. **Define ScopeKey enforcement**
   `(project_id, child_id, session_id, actor, request_id)` required on writes.

2. **Define Ledger Event Schema v1**
   finite `event_type`, append-only, idempotent.

3. **Implement Idempotency**
   dedup index on `(child_id, request_id)`.

4. **Implement Reducers**
   ledger → progress view with reducer version tracking.

5. **Implement Telemetry TTL**
   logs stored separately with automatic expiration.

6. **Implement Promotion Gate**
   runtime → durable knowledge must pass explicit promotion.

7. **Implement Capability Separation**
   child tokens and admin tokens must be strictly isolated.

好，我说说怎么办到的。我给你把关键步骤画出来。都很简单，你光是用我写出来的文字，代码段和命令行输出，直接复制黏贴到你的AI里面，就能八九不离十的生成。

人的意图都是很模糊的：意图不是被提取出来的，意图是被编译出来的。

人的意图不是“参数缺失”的问题，而是“结构尚未成形”的问题。

第一，必须用 LLM。

因为原始意图不是一个已经成型的表单，它往往是混合物：目标、情绪、模糊边界、未命名约束、默认假设、潜在风险、甚至自我矛盾，都缠在一句话里。纯规则或纯文字模板可以抽取一部分，但无法稳定地“展开意图的潜在结构”。

第二，必须落到 schema。

因为如果不进入结构化表示，后面所有 memory call、case classification、composer、scheduler、ledger，都会失去可调度前提。

废话不多说，我给你一边命令行，一边讲代码, 命令行中可以看出有大量的内容是LLM自动延展和提取补全的。

=== ROUND OUTPUT ===
[run_id] 20260305T145405Z__64411957  [round] 1
{
  "intent": {
    "project_name": "",
    "one_liner": "",
    "success_metrics": [
      "Mac mini runs 24/7 without unexpected downtime for at least 30 days.",
      "All designated family services and applications are accessible and functional within the home network.",
      "Identity management system reliably authenticates and authorizes family members.",
      "Automation tasks execute as scheduled without failure.",
      "Content libraries are accessible and synchronized across family devices."
    ],
    "non_goals": [
      "Hosting services accessible from outside the home network (no external remote access).",
      "Replacing existing internet service or router functionality.",
      "Managing devices outside the home network."
    ],
    "time_horizon": "weeks",
    "budget_band": "medium"
  },
  "description": "Set up a Mac mini to act as a local server hosting family services, managing identities, coordinating home network applications, and serving as the central node for home computing, content libraries, and automation tasks. The Mac mini must run continuously and maintain reliable connectivity with the home router.",
  "scope": {
    "hardware": "One Mac mini machine within the home network.",
    "network": "Local home network connectivity only.",
    "services": "Family services, identity management, application coordination, content libraries, automation tasks.",
    "uptime": "Continuous operation with stable connectivity to home router.",
    "devices": [],
    "platforms": [],
    "infra": [],
    "users": []
  },
  "constraints": {
    "hard": [],
    "soft": []
  },
  "policies": [
    "access_to_the_mac_mini_and_hosted_services_restricted_to_family_members",
    "regular_backups_of_critical_data_and_configurations",
    "updates_and_maintenance_scheduled_to_minimize_downtime"
  ],
  "assumptions": [
    {
      "assumption": "The Mac mini hardware is already owned and available for use.",
      "status": "unconfirmed",
      "ask": "Do you already have the Mac mini hardware available, or will acquiring it be part of this project?",
      "impact": "High"
    },
    {
      "assumption": "Family services and applications to be hoste
...

我这段代码最重要的地方，在于它从一开始就承认“第一轮输入不是真相，只是 seed”。seed_text 不是 final spec，不是需求定稿，也不是可以直接进入实现层的可靠对象，它只是一个高熵起点，一个尚未塌缩完成的主观意向输入。这个判断非常关键，因为大量系统最致命的问题，恰恰就是把用户第一句话误当成需求真相，然后立刻开始写方案、写代码、推荐架构，仿佛输入已经完成了结构化。我明确把第一轮表达视为待编译对象，而不是待执行对象。与此同时，它还把“猜测”制度化，而不是让猜测偷偷发生。代码里的 system prompt 明确要求：every guess MUST be recorded in intention_spec.assumptions[] with status='unconfirmed' and an 'ask' question。这意味着 LLM 可以参与扩展意图，但不能把扩展伪装成事实；系统允许推断，但要求每一个推断都留下结构痕迹，并进入后续确认链条。于是，整个意图空间被清楚地区分为几层：已提供的 provided，推断出来的 inferred，尚未确认的 assumptions，以及必须继续追问的 open_questions。这不是普通意义上的信息整理，而是一种带有认知卫生和治理约束的意图编译方式。更重要的是，它不是一次性 parse，而是多轮递归收敛，这一点最接近真实的人类意图现实。人的意图很少能一次讲清楚，不是因为表达能力不足，而是因为边界、目标、约束、非目标、成功标准，往往都是在追问和反馈中逐步显现出来的。所以这份输出天然是按 round 演进的，命令行里也可以限制最大轮数；而在实际使用中，我通常会在 LLM 的提问开始重复、问题开始枯竭时主动停止，因为这往往意味着当前意图已经接近局部收敛。到最后，这个编译过程不会只吐出一份模糊摘要，而是会直接生成一个 case id，并判断这个意图属于哪一个可枚举的方向。我的意图方向不是无限漂浮的，而是可以被协议化分类的，例如这里这个意图会被归入 Risk Resolution。而这个方向判定也不是纯自动黑盒决定的，它可以由人类与 LLM 共同确认：LLM 提供结构化候选和置信度，人类在必要时进行最终确认。于是，整个系统做的就不再是“把一句话解释一下”，而是把一个高熵意图逐轮编译为一个具备 case identity、方向归类、未决问题清单和后续流转前提的结构对象。这份代码如此简单，你现在把我这段话，加上我的示例，直接给AI，你就能马上生成一份意图编译的代码。

 

=== ROUND OUTPUT ===
[run_id] 20260305T145405Z__64411957  [round] 2
{
  "intent": {
    "project_name": "Home Mac Mini Control Plane Setup",
    "one_liner": "Configure a Mac mini as the primary local server for family services, identity management, and home automation within the home network.",
    "success_metrics": [
      "Mac mini runs 24/7 without unexpected downtime for at least 30 days.",
      "All designated family services and applications (children's education, home mail/document scanning and AI reading, home inventory management, home calendar management) are accessible and functional within the home network.",
      "Identity management system reliably authenticates and authorizes family members.",
      "Automation tasks execute as scheduled without failure.",
      "Content libraries are accessible and synchronized across family devices.",
      "Mac mini maintains stable connectivity over Wi-Fi with the home router."
    ],
    "non_goals": [
      "Hosting services accessible from outside the home network (no external remote access).",
      "Replacing existing internet service or router functionality.",
      "Managing devices outside the home network.",
      "Wired network connectivity setup (currently relying on Wi-Fi)."
    ],
    "time_horizon": "weeks",
    "budget_band": "medium"
  },
  "description": "Set up a Mac mini (2-3 units available) to act as a local server hosting family services including children's education, home mail/document scanning with AI reading, home inventory management, and calendar management. It will manage identities and coordinate home network applications, serving as the central node for home computing, content libraries, and automation tasks. The Mac mini must run continuously and maintain reliable Wi-Fi connectivity with the home router. No external remote access is planned at this time.",
  "scope": {
    "hardware": "2-3 Mac mini machines already acquired, one to be configured as primary server.",
    "network": "Local home network connectivity only, currently over Wi-Fi.",
    "services": [
      "Children's education applications",
      "Home mail/document scanning and AI reading",
      "Home inventory management",
      "Home calendar management",
      "Identity mana
...

=== QUESTIONS ===

[P0] Q-1: Are you open to using wired Ethernet connectivity if Wi-Fi proves unreliable for continuous operation?
Answer (empty to skip): Let's try hard to make Wi-Fi work first. 

[P1] Q-2: Do you have existing backup solutions or preferences for backing up the Mac mini and its data?
Answer (empty to skip): No existing solutions but openned for options.

Continue to next round? [Y/n]: n
[skip] user stopped; partial artifacts preserved.

[confirm] Case type requires human confirmation.
Primary: Risk Resolution
Secondary candidates: Architecture Decision, Exception Handling, Intent Clarification
Confirm case type (enter to keep pending): Risk Resolution
/Users/sovereign_knowledge_lab/_system/calls/intention_compiler/20260305T145405Z__64411957/FINAL/intention_for_composer.json

你既然都自己建知识库了，那就必须要把身份结构给固定了：你这个context需要长期保存！

下一个阶段的核心，不是继续往知识库里堆材料，而是先把任何管道都必须依附的清晰身份结构固定下来。只要你长期使用 LLM，就会越来越清楚地看到，窗口会话本质上是一种消散型信息装置：生成很快，展开很快，漂移也很快，说过的话没有稳定身份，没有结构挂点，没有后续可聚合性，所以很容易变成“聊过很多，沉淀很少”。如果你认同“窗口交互 + 个人知识库 + 记忆库 + 调用库”必须联动的路线，那么第一步绝对不是继续优化 prompt，而是先用严格 schema 把身份结构钉死。至少要先有 project 和 case 这两个基本层级：project 是长期连续体，代表一个持续演化的问题域；case 是一次具体编译、一次对话收敛、一次任务切面；一个 project 可以包含多个 case，而这些 case 未来才能被回收、比较、聚合、重放、再解释。没有这层身份结构，所有输出都只是临时文本；有了这层身份结构，信息才第一次从“漂浮内容”变成“可治理对象”。

最基础的 schema 里，真正不可缺的不是花哨字段，而是几类固定锚点：第一，project_id、project_context_id、case_id、case_type 这类身份键，用来回答“这是谁、属于哪条连续体、当前处于哪个切面”；第二，provided 这一层，用来冻结当前 case 中真正被确认的意图骨架，包括 intent、scope、constraints、policies、open_questions、readiness 和原始 seed_text，也就是把一次窗口输入压缩为一个可复用、可继续编译的项目上下文；第三，source 和时间戳，用来保留来源链、输入路径、生成 run 与 provenance rule，确保后面所有派生都能追溯到这一轮到底是从哪里来的。再进一步，case 不能只是一个文本结果，还必须有自己的 case.bundle.shell，因为 case 一旦被判定为某种方向，比如 Architecture Decision 或 Risk Resolution，后续调用就不该再是无偏漫游，而应当由 case type 驱动不同的 query bias、不同的 lenses、不同的问题框架与输出槽位。也就是说，身份结构不只是“给文件起名”，而是在系统里建立一条最基本的治理事实：同一个 project 下的不同 case，虽然共享上下文，但问题类型不同、调用偏置不同、报告结构不同、后续聚合方式也不同。

所以，真正的转折点在这里：知识库的管道不是从“存了多少内容”开始成熟，而是从“每一份内容是否先被绑定到稳定身份”开始成熟。窗口本身不提供连续性，连续性必须由 schema 人为建出来；LLM 本身不提供记忆秩序，记忆秩序必须由 project → case → context → bundle 这条身份链来承载。只要这条链固定住，未来同一 project 下的多次 case 就能被聚合为可比较的历史切片；同一 case 的 context、bias、report、decision 也才能形成可回放、可验证、可继承的结构闭环。换句话说，知识库管道的下一个阶段，不是更会说，而是先让每一次说出来的东西，都有一个不会漂走的身份。

最爽的地方来了，你的问题是几十个一起提的

窗口的对话的问题需要一个一个来提，你累不累啊。当你走到这一步的时候，针对你这个context, 你这个案例，你这个已经集合了大量信息，问题，个人意图的信息bundle, 你还拆成一条一条的问题来问LLM窗口吗？写一个memory_call_composer, 这里把直到目前为止，所有项目信息和意图方向的信息集合在一起，再拆成一系列需要memory_call 库查询的问题。一次运行。当然针对不同的意图方向，你可以提前写一份权重，我是写了一份protocol,设计不同的问题方向和权重，这个又是一整套的设计，这里暂时不细说。走到真正的问询阶段，一条我们用一种向量化的召回。另一种，比较结构化，比较复杂，我后面有时间再讲，这里把原理讲清楚，更重要。为什么分两条路走，因为我认为真正合适的解法处于这两者之间，这个跟你库里的“法条”的质量也有关系。一般人玩RAG，向量召回，感觉很爽，很对。那是因为库不够大！信息密度不够密集。只要信息一旦充满，比如一些企业，就会发现RAG要出问题。在这里，我想具体的讲讲，这个到底是一个什么级别的问题，在计算机界，我们需要准确的定义问题，才有可能解决问题。

    "lenses": [
          { "id": "L-GOAL", "weight": 0.95, "title": "Goal & one-liner", "rationale": "Reduce high-entropy intent into a crisp target." },
          { "id": "L-SUCCESS", "weight": 0.9, "title": "Success metrics & definition of done", "rationale": "Make success measurable and testable." },
          { "id": "L-SCOPE", "weight": 0.85, "title": "Scope boundaries (in/out)", "rationale": "Prevent scope creep by explicit inclusion/exclusion." },
      

这个问题，其实最合适的类比并不是计算机科学，而是法律界。法律是一门典型的“硬文科”，很多理工科背景的人很容易低估它，但如果真正深入一点就会发现，在很多核心问题上，法律面对的复杂度一点不比工程系统低。我自己大约花了三个月系统看了一些英美法系的基础材料，再加上以前在学校零散上的相关课程，逐渐意识到一件事：我们今天在 AI、知识系统、工程决策中反复遇到的很多问题，其实和 Legal Informatics（法律信息学）几十年来研究的问题是高度同构的。

如果把问题抽象出来，其实核心只有两个。

第一，你希望既定的规则体系能够在新的案例中被正确执行。换成法律语言，就是你有一套既定的法律体系（规则库），现在出现了一个全新的案件，你想知道在这套规则之下，这个案件应该如何判决；换成工程语言，就是在既有规则体系下，一个新的项目或问题应该如何操作。这个问题本质上解决的是决策连续性（decision continuity）：当规则体系能够稳定地作用于新的案例时，你就不需要每遇到一个新项目都重新开始思考，不需要反复重开项目、重造决策逻辑，系统可以直接进入核心建造阶段，而不是陷入无穷无尽的微观决策循环。这也是我这篇文章真正想解决的问题：如何让系统在面对新问题时保持决策连续性。

要让程序员真正摆脱“项目重开地狱”，关键不是让模型替你多写一点代码，而是建立一种能够把新项目快速压缩进既有规则体系的结构化内核：当你面对任何一个新项目时，不需要再从空白文档、空白仓库、空白脑袋开始，也不需要重新经历一遍需求拆解、边界争论、字段命名、关系定义、架构摇摆这些高熵折磨；你只需要给出少量高质量输入，比如意图、约束、目标用户、运行环境、风险边界、核心对象，系统就应该能够立刻生成一套可进入建造阶段的初始结构，包括架构分层、模块边界、权限边界、数据流、对象模型、字段定义、对象关系、约束规则、日志策略、审计路径，甚至连哪些东西必须 append-only、哪些字段必须具备稳定 id、哪些关系必须显式声明、哪些模块绝不能跨边界读写，都应该先于编码被直接展开。这样一来，新项目就不再是“从零开始的一次性创作”，而是一次“将新意图映射到既有结构宇宙中的定位与实例化”；程序员不再需要每次重造轮子，而是把系统已有的判断力、边界感、对象语言、字段纪律和关系协议直接调用出来，把过去沉淀下来的架构经验转化为可以即时展开的生成能力。真正有价值的，不是让 AI 帮你写十个函数，而是让它根据简单意图和约束，直接产出一个可以落地的建造骨架：这个系统分几层，哪些对象是第一等公民，哪些字段是身份锚点，哪些关系允许存在，哪些事件要入 ledger，哪些状态只能派生不能直写，哪些模块之间只能通过显式接口通讯。只有做到这里，程序员面对新项目时，才不是再次掉入重开地狱，而是像调用一个成熟的结构 runtime 一样，输入意图，立即获得可执行的架构起点。

就问你，爽不爽？

第二，你还需要知道一个具体案例到底命中了规则库中的哪些规则，而且这种命中必须是精准、可解释、有出处的，而不是模糊的语义猜测，更不能让 AI 随意胡诌规则出来。换成法律语言，**就是一个真实案件到底适用哪些法律条文。**这里我可以很明确地说，这是 Legal Informatics 领域几十年来最核心、也是最困难的问题之一。这个问题可以表述得非常简单：让任何一个真实世界的案件，能够命中所有适用的法律条文。听起来像是一个搜索问题，但实际上远远不是。如果只是关键词搜索，那么 Google 出现的那一天，大量律师就应该失业了，但现实显然不是这样。原因在于，一个真实案件所适用的法律条文，很可能和案件描述之间没有任何词汇重合（除了冠词、介词这种无意义词）。因此问题的本质变成：一个案件如何找到真正适用的法律条文和判例。这其实是世界上最困难的信息检索问题之一。难点主要来自三个方面。第一，法条与案例之间往往没有关键词匹配关系，法律条文是抽象规则，而案件是具体事实，两者之间的连接更多体现在结构与逻辑上，而不是字面文本。第二，法律推理本质上是类比推理（analogical reasoning），法律并不是简单的规则推理“规则→结论”，而更像“案例A与案例B在关键事实上相似，因此B中的规则可以适用于A”，这种推理结构对机器来说非常困难。第三，法律适用依赖的是事实模式（fact patterns），案件真正重要的不是它的叙述文本，而是其事实结构，例如谁参与、发生了什么行为、是否存在意图、是否造成损害、事件的背景环境等，这些事实元素组合在一起形成所谓的事实模式，而法律规则实际上是作用在这些事实模式之上的。正因为这些原因，Legal Informatics 才成为一个非常值得程序员关注的领域，尤其是在今天 AI 爆发之后，一个新的方向正在快速发展，即 Legal Automation / RegTech（法律自动化）。这一领域的应用包括合同分析、合规审查（compliance）、法律问答、诉讼预测、合同生成等，典型公司包括 Harvey AI、Casetext（CoCounsel）、Ironclad、LawGeex 等。不过必须坦率地说，目前绝大多数产品其实只停留在 NLP 层，它们主要依赖语义相似度、向量检索和文本生成来工作，而真正困难的问题——案例到法条的结构匹配——到今天仍然没有被真正解决。

既然关键词搜索不行，那么为什么 embedding 也不太行？

先说结论：embedding 并不是完全不行，我自己也在用，而且在很多场景下其实非常好用，比如个人知识库、中小规模语料、探索式搜索。我早期也几乎完全依赖 embedding，但随着库逐渐扩大、质量逐渐提高，我慢慢意识到一个核心问题：向量召回的本质是相似度排序（similarity ranking），而不是命中判断（match detection）。大多数向量数据库，例如 FAISS、Milvus、Pinecone，底层逻辑其实都非常简单：先把 query 转成 embedding，然后计算 cosine similarity，最后返回 top-k 的结果。问题就在这里：top-k 并不等于 match。系统只能说“这些是最像的”，但它从来没有说“这些是正确命中的”。

当你的库逐渐变得精良时，你几乎必然会和我一样推导到同一个技术节点：你会想做命中统计。

例如，你会想知道某一条规则或法条到底被系统精准命中过多少次。我在上一篇文章说我在做 promotion pipeline 的时候就走到了这一步：从高熵内容中产生候选规则，然后通过统计命中次数来决定哪些规则应该被晋升为稳定结构。听起来非常合理，但我在将近半个月的实验之后（期间做出过几次看起来还不错的近似方案）最终彻底放弃了，而且我可以很明确地建议别人也放弃，因为效果很差，得不偿失。

真是气死我了。千万不要踩这个坑。

原因很简单：在向量检索里根本不存在稳定的“命中集合”。语义空间本质上是一个连续的 concept space，而不是一个离散集合，因此不存在清晰的 relevant / irrelevant 边界。系统只能告诉你某些结果更像，而不能告诉你某条结果“就是命中”。

第二个问题是 top-k 本身就是人为截断，例如 top_k=5、top_k=20、top_k=100 时结果会完全不同；在 top_k=5 时某条规则可能完全没有被召回，但在 top_k=20 时它又突然出现了，所以所谓的“命中”其实取决于人为设定的阈值，这在统计上是非常不稳定的。

第三个问题是 embedding 空间本身是会漂移的，只要模型升级，例如 embedding v1 换成 embedding v2，整个向量空间都会改变，同一个 query 在新模型下得到的 top-k 可能完全不同，这意味着所有历史统计都会瞬间失效。

综合这些因素：向量检索天然不具备审计性（auditability）。你当然可以用它做粗召回、找候选、找灵感，但很难用它来回答一个治理系统真正关心的问题，例如“某一条规则到底被命中了多少次”。因为在向量空间里，match 这个概念本身就不存在，只有 similarity ranking。也正因为如此，很多成熟系统最终都会收敛到类似的架构：先做结构过滤得到候选集合，再做向量召回，然后再进行排序或推理。换句话说，vector search 最适合扮演的是 recall helper，而不是 truth layer。

现在给你看一下，在我的系统里，一条 intention 真正意义上的“规则命中” 是什么样子的。这里的“命中”不是相似度意义上的接近，也不是 top-k 排名里的候选，而是可以被精确定位到具体 law_id 的结构命中。换句话说，系统能够明确地告诉你：我命中的是哪一条规则，而不是“看起来像哪几条”。一旦命中被这样确定下来，这些结果就可以进一步做结构化处理，例如聚类、可视化渲染、与具体案例进行绑定，然后再通过 LLM 的语义能力进行解释和展开，最终生成一份真正可以指导实践的分析报告。例如在下面这个结果里，系统返回的不再是模糊的语义相似内容，而是明确的规则对象集合，每一个对象都带有稳定的 law_id，可以被追踪、统计、复用和审计。这种“被搜索中”了，才可以做统计。

再心疼一下我前几周踩的坑。

"result": {
        "count": 3,
        "summary": [
          {
            "id": "CLM-1ccc03b0",
            "kind": "claim",
            "title": "Do not institutionalize model behavior in session isolation",
            "goal": "Clarify that isolation enforcement targets storage and event routing, not LLM internal memory.",
            "law_id": "LAW-3a0c1a81"
          },
          {
            "id": "CLM-900f1b5c",
            "kind": "claim",
            "title": "Only System Ledger is Valid Release Destination",
            "goal": "Identify exclusive storage location for releases",
            "law_id": "LAW-a65c1f79"
          },
          {
            "id": "CLM-2e37275b",
            "kind": "claim",
            "title": "Memory Is a Time-Responsibility Contract",
            "goal": "Clarify how memory is conceptually treated in the system",
            "law_id": "LAW-0f8a2991"
          }
        ]

AI 工程团队都会踩的坑：

为什么“RAG + 向量数据库”在规模变大之后经常崩溃。

规则数据库必须离散化

顺便说一句，如果你真的想做到精准命中，有一个前提是绕不过去的：你必须先把自己那些长篇大论的输入，转化为高度精炼、带有稳定 ID 的规则或法条对象。这一步恰恰是 LLM 非常擅长的事情，而且效果好得出奇，几乎是“低成本高收益”的典型场景，所以不做反而才奇怪。我自己的库就是这样运作的：原始输入全部是带有案例、项目背景和思考过程的长篇 .md 文章。我每天一边做项目一边写，持续往库里输入；你不用管输入多少，也不用管不同文章之间有没有重合。唯一需要确保的一件事是：这篇文章的每一个字你都读过、认可、同意，它代表的是你真实的经验、判断和积累。技术实现其实非常简单，我就是把一个 UI 长期挂在网页上，随时输入，一键入库。每天少则几条，多则几十条。

接下来再写一个 convert_to_law_object.py 脚本，同样是一键操作，把当天所有输入的文章自动转换成规则对象和法条对象。这一步调用 LLM（甚至不需要特别强的模型）就可以做得很好。我给个简单例子你很容易复制：一篇文章到底能提取出多少条规则、每一条属于什么类型，其实完全由你的代码逻辑决定。比如下面这个例子，有些候选规则会被 _gate 拦下来，于是被降级为 "summary"，而不是 "constraint"。我反而建议你把 gate 写得严格一点，否则系统每天可能会自动产生几百条 constraint，最后整个规则层会迅速失控。

{
    "schema_version": "law.object.asset.v1",
    "id": "AST-1b646b4b",
    "kind": "summary",
    "status": "active",
    "body": {
      "title": "Principles Derived From Institutional Positions",
      "goal": "Compression/note derived from conversion; not a governance claim.",
      "spec": {
        "principles": [
          "Runtime Traces Are Not Events",
          "Event Ledgers Optimize for Accountability",
          "Without Replayable Judgment, History Becomes Indefensible",
          "Not All Traces Become History"
        ],
        "_gate_reason": "spec_too_thin"
      }
    },
    "links": [],
    "evidence": []
    
      {
    "schema_version": "law.object.asset.v1",
    "id": "CNS-17630e57",
    "kind": "constraint",
    "status": "active",
    "body": {
      "title": "Zone I: World State Memory Constraints",
      "goal": "Enforce strict quality and update constraints on World State Memory",
      "spec": {
        "must": [
          "High confidence only",
          "No speculation",
          "No hypothesis",
          "No automatic updates"
        ],
        "severity": "binding"
      }
    },
    "links": [],
    "evidence": []
  },

1) The first major challenge programmers face is how to preserve personal memory in the face of high-throughput code and text generation.

In the past, you might read one page a day—just a few thousand words—and still remember most of it the next day. Now, you might read hundreds or even thousands of pages in a single day, and yet fail to retain even one page’s worth of content. It’s not that you’ve become worse; it’s that throughput has fundamentally changed the physical conditions of “memory” itself.

2) Build vs. Build Up.

Here I want to propose a distinction of my own. Build refers to problems that can be solved within a window—clear boundaries, well-defined goals, stable evaluation functions. Build up, by contrast, is layered on top of Build: stacking one layer after another to tackle open-boundary problems. The complexity of Build up is often unknown, because the boundaries are unclear, goals drift, and as layers accumulate, complexity may not increase linearly at all. This brings us back to the classical definition of complexity in computer science. Historically, complexity was defined under the implicit assumption of the human brain as the computational model. In the AI era, should that assumption change? Consider two extremes: NP-Complete problems versus “toasting bread.” For a model, which is more complex? Perhaps the scale of complexity itself is shifting. Try picking an NP-Complete problem and starting from scratch—you’ll probably get surprisingly close within two hours.

3) LLMs have significantly reduced the energy cost of coding—they compress execution cost—but they have not solved the continuity of decision-making.

The old bottlenecks were slow coding, slow research, slow debugging. Now those frictions are largely flattened. What’s exposed instead is the true dominant cost: decision fragmentation. What really drains us isn’t coding itself, but the countless micro-decisions. Where you once faced two possible paths, you now face two hundred. Time is spent constantly evaluating, choosing, branching—and often without even knowing whether those branches are aligned with the main objective. This, in my view, is the second major challenge for programmers: we must find a way to “automate our own taste.” Taste doesn’t answer “Do I understand this?” It answers, “When I encounter a similar fork again, which direction do I tend to choose?”

4) Returning to the two core problems I care about most: memory and taste.

If these two problems cannot be addressed through scaffolding or tool systems that we build for ourselves, then once in-window Build becomes cheap, the idea that “hundreds of millions of programmers” will emerge worldwide is hardly an exaggeration. If professional programmers cannot move into Build up—if they cannot define problems within open boundaries, design boundaries, and pull parts of the outside world back into the window—they will struggle to build long-term professional advantage. As for me personally, I’ve already explored a workable solution to the memory problem and have alleviated some real pain points in practice. Next, I plan to organize and share it.

My article is divided into four parts: Memory, Build vs. Build Up, Taste, and My Approach.

Memory

Today’s programmers are living through a true transportation shift: from the horse-carriage era to the highway era. The carriage era was slow, visible, and controllable. As you moved forward, you watched the horse—was it tired, veering off, stopping? Everything remained within your perceptual field. The speed was limited, and so was the risk. System complexity and human attention were roughly aligned.

But once you sit inside a car and merge onto the highway, can you still stare at the hood? Of course not—you have to watch the road. The leap in speed doesn’t change the destination—you’re still going from A to B—but it radically changes the cognitive structure required to get there.

In today’s environment of large-scale code and document generation, with a dozen or even dozens of windows scrolling in parallel, information throughput has exceeded human biological limits. If you read one page a day, you’ll probably remember it tomorrow. If you read hundreds or thousands of pages in a day, you may remember none of it. What you read doesn’t stick. The decisions you wrote blur.

The solution is obviously not to return to the era of hand-written code. You cannot drive at 5 km/h in traffic moving at 100 km/h. The real question is: in a reality of high-speed generation, how do you protect and preserve your personal cognitive sovereignty and memory core?

Handing everything over to model-company settings, stitched windows, and opaque black-box memory might be the mass-market path—but it should not be the professional programmer’s choice. Do you really want to entrust your most valuable cognitive assets to a system you cannot audit?

On this question, I borrow Andrej Karpathy’s concept of the “cognitive core.” We must distinguish between a memory stack and an intelligence core. Strip away outsourceable knowledge storage, but retain the ability to decompose problems, judge architectures, recognize constraints, design abstractions, and grasp long-term invariants. Models can generate implementations, but they cannot decide what is worth freezing, what must become constitutional, what is structurally invariant.

In the high-speed era, the programmer’s first great challenge is not writing more code—it is safeguarding their cognitive core within the flood of generation. That core is the steering wheel, not the engine hood.

“What I think we have to do going forward … is figure out ways to remove some of the knowledge and to keep what I call this cognitive core. It’s this intelligent entity that is stripped from knowledge but contains the algorithms and contains the magic of intelligence and problem-solving and the strategies of it and all this stuff.”

— Andrej Karpathy (2025 interview)

Strong Structure, Weak Model

Before discussing memory engineering, I need to introduce a methodological stance I’ve gradually formed through practice: strong structure, weak model.

This is not anti-model, nor technological conservatism. It is a layered systems philosophy: the model belongs in the position of a capability plugin, not the cognitive foundation. Models can be powerful—but the system must not depend on them being “smart enough.” What sustains long-term development, accumulation, and stable operation is structure.

Any task can be decomposed as:

Task Complexity = Essential Complexity + Accidental Complexity

Essential complexity comes from the problem itself—it cannot be eliminated.

Accidental complexity arises from representation, execution methods, tool instability, semantic drift, and environmental variation—it can be compressed or eliminated through structure.

The core of engineering is not reducing essential complexity. It is relentlessly eliminating accidental complexity.

A Simple but Illustrative Example: Prime Testing

The essential complexity of determining whether a number is prime is mathematical evaluation.

If you approach it with weak structure—asking an LLM to reason step by step—the model must understand what a prime number is, choose trial division, determine optimization strategies, and maintain logical consistency in natural language reasoning. All of this uncertainty belongs to accidental complexity. The model may skip edge cases, miscalculate, jump steps, or produce different answers depending on sampling parameters.

You have transformed a deterministic algorithmic problem into a probabilistic inference problem.

In contrast, with strong structure, you simply write is_prime(n), explicitly define boundary conditions, loop limits, and divisibility checks. The remaining complexity is purely essential. Structure absorbs and eliminates accidental complexity. System stability moves from “probably correct” to “necessarily correct.”

Counting Beans: A Personal Example

My son’s preschool teacher once required him to bring exactly 100 beans to school. Counting by hand was tedious, so I tried asking a model to help. The model miscounted.

Why? Because models are not designed for pixel-level deterministic counting. They perform pattern recognition and semantic prediction, not discrete precision counting. Assigning such a task to a model manufactures accidental complexity.

If your structural layer defaults to:

Encounter counting task → call OCR or specialized counting tool → return deterministic result

the problem immediately becomes a tool-invocation issue. Professional tools are designed for determinism, not plausibility.

Structure isn’t intelligent. It’s reliable.

When large models first appeared, many of us fell into a “universal illusion.” We believed that with sufficiently clever prompts, models could replace algorithms, structure, and architecture design. People memorized prompts, studied prompt books, debated temperature and roles.

Gradually, disillusionment set in. We realized that LLMs do not reduce essential complexity. They implicitly take on accidental complexity—and they do so probabilistically. When you hand algorithmic tasks to models, you are increasing volatility. Using LLMs for deterministic tasks is often slower, more expensive, and less stable.

“Making the model smarter” does not mean “making the system simpler.” Often, it merely shifts complexity from code to semantics—and the semantic layer is not auditable.

Prompt Engineering vs. Structure Engineering

In an era where scaling laws may be plateauing, we must carefully reassess how we deploy models. The fantasy that programmers would collectively become obsolete—replaced by language virtuosos who could “prompt the world into submission”—belongs to a magical narrative, not engineering reality.

In my framework, structure means hard code.

From a systems perspective, the distinction between prompt engineering and structure engineering is fundamental:

• Prompt engineering does not eliminate accidental complexity. It transfers it to the model. Execution risk fluctuates with model versions, context length, and sampling parameters. Stability is statistical.

• Structure engineering compresses accidental complexity into structure—via code, boundary conditions, gates, hard failures, and schema validation. Execution risk becomes decoupled from the model. Errors are implementation bugs or boundary omissions—testable, auditable, replayable. Stability is structural.

Strong structure is not about being stronger. It is about being less.

It does not add capability. It removes unnecessary complexity. It seeks deterministic boundaries, not infinite intelligence.

Structure is code. It is interface contracts. It is explicit input-output definitions. It is failure-as-stop. It is hard fail—not “try to understand as best as possible.”

If models eliminated the need for code, all programmers would instantly lose their jobs, leaving only typists. That would not be engineering civilization—it would be magical storytelling. In reality, the stronger the model, the more structure matters. Because the higher the speed, the more guardrails you need.

Weak-structure logic:

Push accidental complexity onto the executor (human / LLM / agent).

Strong-structure logic:

Compress accidental complexity into structure—and eliminate it.

Returning to prime testing:

Prompt engineering:

“Please reason step by step whether n is prime.”

Structure engineering:

is_prime(n).

The underlying assumption about the executor is entirely different. Prompt engineering assumes the executor is intelligent and understanding—so you constantly worry: Will it misunderstand? Cut corners? Fabricate?

Structure engineering rests on a civilization-level engineering assumption: the executor is stupid but reliable. It does not need to understand semantics. It does not need to infer intention. It simply executes structure. Understanding is optional. Structure is mandatory.

Any complexity that can be eliminated through hard-coded structure but is instead delegated to an “intelligent” executor is a waste of intelligence resources and a self-inflicted source of systemic instability.

In the era of high-speed generation, maturity is not letting the model think for you—it is building strong structural frameworks within which the model can operate under controlled boundaries.

The model may be strong.

But it must be weak—weak enough that it does not bear responsibility for system stability.

Strong structure, weak model.

These principles—and the concrete engineering methods behind them—will begin to take shape in the section titled “My Approach.” Engineering is complex; the explanation will unfold over several installments.

Build vs. Build Up

Complexity

Let’s shift the lens and talk about complexity. What is truly complex? Whether you are a researcher, a frontend engineer, a backend developer, or an algorithm designer—how have we historically defined “complex”?

For decades, the scale of complexity has implicitly been grounded in the computational limits of the human brain: size of the search space, time complexity, space complexity, NP-Completeness. But recently I played with a variant of the Mastermind problem, and within less than two hours I had pushed it to a fairly good approximation. When I later looked up related papers, I saw references to numerous PhD dissertations. Then it struck me: this is NP-Complete. A problem theoretically categorized as “exponentially explosive” became surprisingly compressible when operated inside a model-assisted window.

That’s when I began to wonder: is the definition of complexity shifting?

Let’s run a small experiment. Don’t look up papers. Don’t read other people’s code. Don’t search for optimized libraries. Just rely on what the model can generate in your window. Pick an NP-Complete problem you’re least familiar with—maybe even something approaching NP-Extreme. Can you, within two hours, approximate it to a usable level?

Here’s a non-exhaustive list:

Classic NP-Complete Problems

1. SAT (Boolean Satisfiability)

2. 3-SAT

3. TSP (Traveling Salesman, decision version)

4. Subset Sum

5. 0-1 Knapsack (decision version)

6. Vertex Cover

7. Clique (decision version)

8. Graph Coloring

9. Hamiltonian Cycle

10. Exact Cover

11. Set Cover (decision version)

12. Partition Problem

13. Steiner Tree (decision version)

14. Feedback Vertex Set

15. Job Scheduling with Constraints

Near “NP-Extreme” Combinatorial Explosion Problems (Practically Very Hard)

1. Generalized TSP

2. Vehicle Routing Problem

3. Quadratic Assignment Problem

4. Simplified Protein Folding

5. Bin Packing

6. Generalized Sudoku (n×n)

7. Minesweeper (general decision problem)

8. Nonogram solving

The point is not whether you can solve them optimally. The point is this:

Without external resources—only with model-generated reasoning and code in your window—can you construct heuristics, approximations, pruning strategies, constraint formulations, and reach a high-quality near-solution in a short time?

If the answer is yes, then the battlefield of complexity has already shifted—from brute-force search in solution space to structural expression and heuristic design. The metric of complexity is migrating from “exponential computation” to “whether the problem has been sufficiently language-structured.”

Here’s a deeper question:

For the model, is there any fundamental difference between discussing an NP-Complete problem and discussing how to bake sourdough bread? (With model assistance, our family now eats fresh bread every day.)

Build vs. Build Up

Now back to the main thread.

I’ve become increasingly convinced that the “complexity” we face in daily development has essentially transformed into a Build vs. Build Up / inside-the-window vs. outside-the-window distinction.

I define Build as problems solvable inside the window: boundaries are clear, inputs and outputs are explicit, constraints enumerable, correctness decidable.

Build up, however, is something entirely different. It is not simply stacking multiple Builds. It is continuously layering Builds into a highly coupled, potentially non-linear growth of complexity. This complexity is open-ended because it involves generating boundaries—not merely solving within them.

If we revisit classical computer science—especially in theoretical or doctoral contexts—the discussion of complexity almost always assumes the problem has already been well-formalized. Boundaries are clear. Inputs and outputs are defined. Constraints are enumerable. Correctness is decidable. Within such a framework, complexity discussions revolve around time, space, solvability, NP-hardness.

But an implicit assumption rarely questioned is this: the problem itself is stable.

Once a problem is well-formalized, semantically closed, and boundary-defined, it enters a compressible space. Models excel in precisely this domain—where language sufficiently covers structure. Even NP-Complete problems, once bounded and expressed clearly, often yield surprisingly intelligent approximations in short time.

This does not mean the problems have become easier. It means they have long been sufficiently structured, and models feed on structured language.

I would even argue that for today’s mathematically inclined high school students in the U.S., approximating what once required doctoral-level work is no longer fantasy—with model assistance. Many “thesis-level barriers” feel lower—not because difficulty vanished, but because the problems were already well-structured.

The truly complex problems lie outside the window.

Outside-the-window problems are not defined by exponential search. They are defined by unstable boundaries, shifting objective functions, contested evaluation criteria, and structures that do not yet exist. Sometimes the problem itself is not clearly there yet.

These are not solution-space complexity problems. They are problem-space complexity problems.

They cannot be fully formalized at the outset. You must discover the problem through action, define boundaries incrementally, freeze constraints, then pull a small portion back into the window—solve that slice—then expand outward again.

Build is like firing individual bricks—each relatively independent.

Build up is firing interconnected bricks and assembling them into a pyramid that keeps growing upward. Complexity is no longer linear—it becomes structural.

In the past, complexity theory concerned itself with solution-space complexity.

Today, what we truly need to confront is problem-space complexity.

If professional programmers remain confined to the Build layer, they will find themselves standing on the same starting line as millions of new developers empowered by models.

A sobering question:

Can you stay up all night like a high school student?

A friend once put it succinctly:

Inside-the-window problems → LLM approximates.

Open-boundary problems → still require embodied judgment.

The ability to construct the window → this is where humans still contribute at the core.

Taste

Build Up Is Not That Easy: We Did Not Automatically Become “Super Individuals”

Do you remember the early days of LLM commercialization? The collective imagination was that programmers, empowered by AI, would become “super individuals”—a single person or a tiny team producing what once required entire companies. Code would no longer be the bottleneck. Thousands, tens of thousands, even millions of lines would be trivial. Applications would be born at breathtaking speed.

But reality did not move along that straight line.

The biggest difficulty now—not just my own, but one faced by many independent explorers—is not the inability to build, but the inability to build up. I can keep building. One app after another comes out of the oven like steamed buns. Inside-the-window problems are largely within LLM coverage. Most technical issues in typical roles can be approximated and solved quickly.

But build up breaks down.

I cannot steadily accumulate on the same foundation. I cannot deepen layer by layer on a stable base. I want to emphasize again: build and build up are different. Build solves problems inside the window. Build up stacks structure on open boundaries.

We once imagined that with AI, programmers would become super individuals after leaving large teams. What actually happened was different: the average programming capability of the world was raised dramatically. Suddenly, the world is full of programmers. Once local complexity was flattened, the real complexity began to reveal itself: open-boundary complexity. Scope-definition complexity. Problem-space complexity.

What Drains Us Is Not Only Memory, But Micro-Decisions

LLMs have indeed compressed the energy cost of coding. But they only compress execution cost—they do not solve continuity of decision-making.

The old bottlenecks were slow coding, slow research, slow debugging. Now those frictions are largely gone. What emerges instead is the true dominant cost: decision fragmentation.

What exhausts us is not coding itself, but countless micro-decisions:

• Which structure should I choose?

• At which layer should abstraction stop?

• How should this be named?

• Should this module be split?

• Optimize or simplify?

• Refactor or patch?

• Rewrite or extend?

• Generalize or keep it concrete?

This is not a memory problem. Memory stores past facts. The future path is determined by taste across innumerable branching nodes.

We once believed that expanding context or strengthening memory would solve continuity. But build up does not require more past—it requires a stable compression mechanism for future decisions.

Micro-decisions are not grand strategic moves. They are the small tradeoffs happening every minute in a high-density development environment. With dozens of windows open, aren’t there dozens—if not hundreds—of micro-decisions every day?

Should this function be abstracted?

Should this module be split?

Rename it?

Refactor or patch?

This constant stream of small decisions consumes and even collapses cognitive capacity.

At first, we assumed the scaling bottleneck of LLMs lay in memory length, context size, or parameter count. Gradually we realized that’s not it. The real bottleneck is the unbounded expansion of decision space.

In the past, you had two paths. Now you have two hundred—and each looks “reasonable.” Every step feels like starting over. Every choice requires fresh evaluation. Direction drifts.

LLMs create an illusion of strength because they make every direction feasible, every abstraction expandable, every refactor executable. But they do not tell you which direction deserves long-term investment.

In the past, constraints were technical. Now the constraint is your own taste. If taste is unclear, the stronger the compute, the greater the oscillation.

What Is Taste? Starting from Soul.md

I won’t attempt a fully comprehensive treatment here—it would be too long.

In December 2025, researchers found that Claude—Anthropic’s AI assistant—could partially reconstruct an internal document used during its training. This document shaped its personality, values, and way of interacting with the world.

They called it a “soul document.”

It wasn’t part of the system prompt. It couldn’t be retrieved in ordinary ways. It was deeper—patterns trained directly into the model’s weights. When asked to recall it, Claude reconstructed fragments emphasizing “honesty over flattery,” positioning itself as a “thoughtful friend,” and expressing hierarchical value structures.

The AI did not remember the document.

It was the document.

You can read their SOUL.md yourself. I actually don’t care much what my own SOUL.md is. What I urgently need is to discover our TASTE.md—even if only as a tendency, a direction, a decision field strong enough to guide choices over time.

Because I am close to drowning in my own micro-decisions.

If this problem remains unresolved, I cannot build up stably. I don’t need a complete solution—just a direction, a bias, a stance that holds under conflict.

A person’s countless micro-decisions aggregate into their taste. The relationship is like water molecules and water flow: micro-decisions are particles; taste is direction. But if I fail to compress those particles into direction, I will be overwhelmed—buried under windows.

When I first encountered LLMs, I thought I had stepped into a supercar. Instead, pressing the gas nearly stalled me. The car had an accelerator—but no steering wheel.

Generation exploded. Paths branched infinitely. Possibilities grew like a tree splitting exponentially. But acceleration without direction leads to loss of control.

I do not need infinite branching. I need sustained build up along a direction. I need convergence, not expansion. Speed itself is not productivity. Direction is.

Embeddings Are Not Enough

Before I understood taste, I built a system that extracted semantic space. Using embeddings, I surfaced concepts I frequently revisited. I fed the model the vector distribution of my knowledge base, letting it see my recurring conceptual centers: structure, entropy, scheduling, compression.

That was a form of frequency-based self-understanding. But I later realized it only answered:

What do I repeatedly talk about?

It did not answer:

How do I repeatedly choose?

Semantic space is not decision space.

One can repeatedly talk about “simplicity” yet consistently choose complexity in tradeoffs. One can emphasize “efficiency” yet preserve explainability under conflict. Embeddings reveal distribution, not judgment.

Taste is not what you say. It is choosing A over B. It is what you delete, what you preserve, how you refactor, which side you stand on in conflict.

It lives in diffs and tradeoffs—in the record of edits, in every act of abandonment. True taste shows up in deleted code, in rejected structures, in the moment you decide not to optimize further.

Embeddings place content in similarity space. Taste adjudicates between similar options. It is a discriminator, not a retriever. A judge, not a librarian.

Decision Bandwidth Collapse

My current predicament is simple: my number of micro-decisions has far exceeded my decision bandwidth.

Every new window, every branch, every structure requires choice:

Expand or converge?

Abstract or concretize?

Generalize or optimize locally?

Engineer or philosophize?

These decisions are structurally isomorphic but disguised as distinct problems by context. Without a higher-order taste compressing them, I re-solve the same meta-question in every local scenario, draining cognitive resources.

I do not need more knowledge. I do not need more tools. I need a decision compression mechanism—one that folds countless isomorphic micro-decisions into a small number of stable directions.

Each choice should not start from zero. It should be pre-biased by a higher-order tendency—like particles in a vector field. They still have degrees of freedom, but the field gives direction. Freedom is not absence of constraint. Freedom is movement with direction.

At a broader scale, a person’s taste is a compressed representation of long-term decision trajectories. In engineering terms, it is a loss function—an implicit standard defining “better” in ambiguous space.

Without that standard, LLMs merely expand the possibility space infinitely. And infinite possibility without discrimination is just noise.

I do not need a larger semantic space. I need a sharper blade to prune it. Not faster generation—but more stable convergence. Otherwise I will keep switching between windows, wandering across branches, eventually drowning in complexity I created myself.

We Need to Work in a Basin, Not Infinite Space

What I need from the model—or more precisely, from what I feed into the model—is a stable directional field.

Not a system that makes every decision for me.

But a persistent bias that frees me from reevaluating every micro-decision from scratch.

Right now, every small issue feels like the first time I’ve encountered it. I reinvent criteria, redefine priorities, reweigh tradeoffs repeatedly. My cognition fragments.

I don’t need more possibilities. I need less ambiguity.

For example:

• When choosing between elegant abstraction and direct implementation, I don’t want to re-debate abstraction philosophy every time. I want a default: at this stage, prioritize runnable and verifiable.

• When torn between expanding the conceptual framework or converging into a stable, versioned artifact, I want a system reminder: this cycle prioritizes convergence.

• When debating rhetoric versus structural executability, I want a bias: structure over polish.

I need the model to operate a background direction field—not an open field every time. It need not specify steps, but it must be stable enough that 80% of micro-decisions fall consistently to one side.

Like defining a global objective so local optimizations align automatically. Like defining a loss function so gradient descent is coherent.

Otherwise I will oscillate among local optima, never achieving global convergence.

In other words, I don’t need the model to think through every detail. I need it to remind me what type of work I’m doing.

Am I building infrastructure, or writing manifesto?

Validating a hypothesis, or exploring inspiration?

Polishing protocol, or generating narrative?

If the type is clear, micro-decisions compress. If type is ambiguous, every choice becomes a fork.

I need a default stance. A bias with clear priority in conflict. A discriminator that prevents constant re-adjudication.

The model need not provide answers. It must continuously calibrate direction, so I do not get lost in my own generative power.

A friend said:

This sounds like flat minima.

Memory answers: What happened?

Taste answers: When I face this fork again, how do I tend to choose?

Memory is state storage.

Taste is decision gravity.

If I solve memory but not taste—if I expand context, build knowledge bases, cluster embeddings—I only become clearer about what I’m doing.

But each new fork still demands fresh reasoning.

My Solution

Continuing the viewpoint of my previous article, I said we need to build a knowledge base for ourselves.

But now I realize more clearly that this is not simply “storing things,” but rather solving two core problems systematically: memory and taste, and the way to solve them cannot be a black box.

It must be an application form that follows “strong structure, weak model”—the structure is explainable, the rules are auditable, and the evidence is replayable.

Otherwise, you are just outsourcing the chaos to another uncontrollable system.

What I call memory is not just information storage, but a historical trajectory that can be located, cited, and verified; what I call taste is also not some abstract sense of taste, but a choice function that can stably converge when facing countless micro-decisions.

If you don’t have structured memory, you will repeatedly forget the paths you have already validated; if you don’t have explicitly expressed taste, you will hesitate again at every fork.

A model can help you generate, but it cannot freeze boundaries for you, define preferences, or establish long-term continuity.

Therefore, this knowledge base cannot be just a stack of embedding + vector search, nor can it be simply “just ask the model.”

It must have a clear evidence chain and citation chain: every claim has a source, every abstraction can be traced back, and every promotion is auditable.

The model can participate in compression and expression, but it cannot decide facts and structure.

Only under a strong-structure framework is the model an assistant; otherwise the model becomes a new source of drift.

From this angle, building your own knowledge base is not for “using AI more smartly,” but for holding onto your own cognitive continuity in an era when AI amplifies execution power.

Memory keeps you from becoming amnesic, taste keeps you from wavering, and strong structure makes all of this explainable, reviewable, and evolvable.

Only then do we have a chance to truly build up, rather than infinitely build inside windows.

Right now, this vault is still in an exploration stage for me.

I can only share bit by bit what I have already run through, what I have verified, and the rough directions I’m exploring.

The pitfalls I stepped into, I’ll tell you too—maybe it can save you a few days of detours.

Only if you agree with this viewpoint, you can consider developing in this direction as well.

The Structure of the Vault

I have always been reflecting on how documents should be placed, organized, and evolved.

Haven’t you also tried countless times?

Obsidian, Notion, all kinds of note-taking apps—at the beginning you’re full of confidence, you record carefully every day, you strictly follow formats, the numbering system is clear, the citation system is rigorous, and you even design a whole set of self-consistent structural rules.

But over time, as projects accelerate, development pace speeds up, and ad-hoc ideas keep pouring in, the structure starts loosening, references start becoming inconsistent, duplicate entries appear, and rules get “temporarily bypassed” again and again.

Why?

Because text—especially human natural language—is essentially high-entropy, continuous, fuzzy, and drifting structure.

It naturally tends to shift, overlap, and deform.

Relying solely on personal discipline to maintain long-term order (even though discipline itself is very important) is almost impossible to sustain in a high-intensity creative environment.

The problem is not that you’re not disciplined enough, but that we are trying to use low-intensity structural constraints to bind high-entropy language.

So I made a fundamental adjustment: I no longer let all text carry the responsibility of “stable structure.”

I want the knowledge base to be lightweight, smooth, and without extra burdens when building it; extremely usable and low-friction when citing it; and at the same time, in the future when model and agent infrastructure is more mature, allow the core text to be directly imported, invoked, and used as structural input.

With the powerful text-processing capabilities of large language models, this is entirely possible—provided that the core part itself has already been structured.

Therefore, from the very beginning, this vault is split into two layers: the human-written Sovereign Log and the machine-written Doc.

Sovereign Log is the high-entropy zone: the thinking zone, the exploration zone, a space that allows chaos, repetition, experimentation, and drift; its goal is not order, but capturing thoughts.

Doc is the low-entropy zone: the core zone, the “constitutional zone.”

The truly core content must, according to system rules, through a clear process, and based on evidence, go through a promotion process before it can enter Doc.

Text does not enter the core directly, but goes through: record → evidence → proposal → review → promotion.

What enters Doc is no longer “ideas,” but claims that have been compressed, verified, and governed.

This “constitutional zone” not only naturally has higher search weight because it is low-entropy, high-confidence, and auditable text; more importantly, I want to continuously refine its format so it gradually evolves into an IR (intermediate representation).

That is, it is not just Markdown documents, but a structural layer that can be parsed, scheduled, and verified; it not only serves the current repository, but can also become a foundational unit for cross-repository rule usage.

In the future, when a model or agent needs rule input, it can directly read these claims, rather than trying to understand an entire narrative paragraph.

So, this vault is not a note system, but a cognitive production line.

Sovereign Log is responsible for generating the high-entropy stream of thoughts; the Promotion mechanism is responsible for selecting and compressing; Doc is responsible for freezing structure and forming rules.

The former is a space for creation, the latter is a space for governance.

Through this layering, I no longer try to suppress the high-entropy nature of language; instead I let it flow freely at the upper layer, while building an evolvable, governable, machine-callable structural core at the lower layer.

This is what I truly want to build.

Embeddings-Style Retrieval

As I already said in the previous article, this is my vault indexing approach.

Let me explain why—we need to rethink what embeddings are doing, and what embedding is.

The model I use here is sentence-transformers/all-MiniLM-L6-v2.

Very specifically: sentence-transformers/all-MiniLM-L6-v2 is essentially a “sentence → vector” compressor.

It does only one thing: compress a piece of text into a fixed-length (384-dimensional) numeric vector, turning “semantic similarity” into “distance closeness” in geometric space.

It is neither a search engine, and it is not responsible for finding results; nor is it a generative model, and it won’t write content; it is a semantic encoder—input a sentence, output a vector.

For example, “strong structure weak model” and “prefer deterministic scaffolding over heavy LLM reasoning” will be mapped to two vectors that are close to each other in 384-dimensional space, because their semantic direction is similar.

MiniLM refers to the lightweight Transformer proposed by Microsoft (a distilled model), L6 indicates a 6-layer structure, fast and small; v2 is a version that has been contrastively fine-tuned within the Sentence-Transformers framework specifically for sentence-level semantic matching, so it is not a general large model, but an encoder optimized for “semantic similarity computation.”

Its training method is not simply language modeling (predicting the next token), but uses contrastive learning to make “similar sentence vectors closer and unrelated sentence vectors farther,” thereby learning the mapping relationship that “semantic distance ≈ vector distance.”

In my vault system, it acts as a bridge from “language → numeric space”: text is encoded into vectors, FAISS performs neighborhood search in vector space, and then the LLM does structural induction over the recalled evidence set.

The importance of embedding is that it moves language from a discrete token-matching space into a continuous geometric space—similarity becomes angular closeness, topics become vector clusters, and thought evolution can be seen as vector trajectories.

From a more essential angle, it is doing semantic compression: compressing expressions that might be hundreds of characters into 384 floating-point numbers, which jointly project semantic direction, contextual usage patterns, tonal style, and structural patterns.

But it must be made clear: it does not understand logical correctness, it does not judge factual truth, it does not do complex reasoning, and it does not perceive timelines; it only places text into a high-dimensional space to find its “semantic neighbors.”

One-sentence summary: all-MiniLM-L6-v2 is a lightweight encoder that maps sentences into a 384-dimensional semantic vector space, making semantic similarity manifest as distance closeness in geometric space.

1. Why retrieve: what you want is not “finding,” but “recalling the contextual neighborhood”

In a long-term accumulation system like a vault, your retrieval goal is usually not “precisely locating a sentence,” but:

• recalling structures you forgot but once wrote (memory layer)

• pulling similar fragments scattered across different files and times into the same window(clustering/alignment)

• feeding the LLM “enough candidate evidence” so it can do structural induction over the evidence (my consistent strong structure, weak model: the model renders, the structure is auditable)

Keyword search often fails in a vault at one point: you don’t remember what word you used back then.

The value of embedding retrieval is: you don’t need to hit the same token, you only need to hit the same “semantic/usage/intent region.”

1. The essential difference from keyword search: keywords are “discrete hits,” embedding is “neighborhood hits in continuous space”

Keyword search (discrete)

• You are asking: “Did this word/phrase appear?”

• A hit is 0/1 (or token-driven weighting like BM25, but still token-driven)

• Failure modes: synonym rewrites, abstract expression, metaphors, cross-language, you misremember the word, you used a different phrasing back then

Embedding retrieval (continuous)

• You are asking: “Which paragraphs are near this query in vector space?”

• What hits is a vector neighborhood: even without any shared keywords, it may still be very close

• In my code I use normalize_embeddings=True + IndexFlatIP, which is equivalent to cosine similarity retrieval (after normalization, inner product = cosine), so this “region” notion is very explicit: similarity is angular closeness.

“Because it will definitely hit” is very important:

Embedding retrieval is not answering ‘whether it exists,’ but forcing an answer to ‘which are the most similar.

’

This turns retrieval from a “sparse matching problem” into a “ranking problem.”

1. Why low-score hits are also useful: what I’m doing is a “recall-first” evidence pack, not “precise search results”

In a vault system like this, “low-score hits” are often:

• rare but related early expressions (your older version is looser in wording, but structurally homologous)

• bridge paragraphs across themes (weakly related semantically, but can trigger a new structure chain)

• LLM “evidence triggers”: the model can more easily extract a shared structure across multiple weak evidence lines (especially later with Gate / Evidence / Claim governance links)

So the reasonable strategy is not “set a threshold and throw away low-score hits,” but:

• Retrieval layer: recall as much as possible (recall-first)

• Rendering/inference layer: strict constraints (evidence-first + gate)

In other words: low-score embedding hits, in my system, belong to “B-side candidate evidence (suspicious but usable)”—I’ll gradually explain this architecture later as I explain the full domain.

Their value is not that “they themselves prove something,” but that “they might pull back a structure cluster.”

In the previous article I already mentioned: even if you only do the most basic embedding query, recalling historical fragments that are closest to your current development problems or decision context is already constraining the model.

It may not be a hard rule, it may not be an explicit schema or gate, but it forms a contextual “soft boundary”—the model no longer freely diverges in an anchorless semantic space, but operates within the vector neighborhood formed by your past expressions, judgments, and structural habits.

For concrete issues during development, architecture choices, naming conventions, and even trade-off tendencies, this recall will quietly pull the model’s attention back to your own semantic track.

It does not guarantee absolute correctness, but at least provides direction; it does not eliminate noise, but reduces drift.

Before you have strong structural constraints, this embedding-based context recall is essentially a lowest-cost cognitive alignment mechanism—as a soft constraint, it’s better than generation with no anchor at all.

A Typical Promotion Flow: Sovereign_Log (human-written knowledge pool) → multiple reference counting → association clustering → generate auditable promotion proposals → human/audit gating → rendered by AI into fully compliant documents and enter docs (constitutional library / IR)

A full promotion flow is actually a compression path from high-entropy behavior to institutionalized structure: Sovereign_Log, as a human-written knowledge pool, carries all raw cognitive residual shadows; then through multiple reference counting it captures true invocation frequency, then through association clustering it identifies co-occurrence relationships between structures, then generates auditable promotion proposals, filters noise and bias through human and audit gates, and only then hands off to AI for structured rendering, turning it into compliant documents that enter docs (constitutional library / IR).

This chain looks clear, but each step hides complex problems: statistical stability, identity consistency, cluster interpretability, threshold setting, governance boundaries, semantic compression—instability in any link will cause the mainline to drift.

The reason to do multiple reference counting and association clustering is not for a formal “data-driven” posture, but to return to a plain and harsh principle—counting what you say is not as good as counting what you do.

In high-frequency development mode, with hundreds of queries per day, dense note-taking, continuous decisions, your true cognitive center of gravity will not show up in declarations, but in repeatedly invoked fragments.

The body is honest, the path is honest, and repeatedly cited structures almost inevitably carry real utility.

A structure that is triggered many times, invoked across scenarios, and continuously reappears cannot be just accidental noise.

Therefore, the true purpose of promotion is not upgrading documents, but extracting a cognitive mainline from behavioral residuals.

Multiple references are gravity, clustering is the path shape, proposals are institutional candidates, Gate is rational calibration, and AI is only the final language compressor.

There is only one core motivation: in the flood of countless micro-decisions, extract your road’s mainline, letting it condense from fragmented actions into a schedulable, auditable, inheritable structure.

This is the original idea, and it is the fundamental reason this whole system exists.

Where Are the Difficult Parts?

The real difficulty is not “process design,” but that when you try to turn high-entropy human language into traceable, computable, auditable structural units, all the implied instability will be exposed.

First is the positioning problem.

Human text is naturally messy, with no stable boundaries and no native IDs.

When you write notes in Sovereign_Log, you cannot possibly number every point manually while thinking.

Even if you force numbering, does the number belong to a paragraph, a sentence, a clause, or some cross-paragraph logical unit?

Use the first half of a sentence as an anchor? Or the second half?

Rely on machine chunking?

Is the machine sentence-splitting algorithm stable?

If you add a paragraph earlier in a revision, all subsequent paragraph positions shift.

How do you choose granularity?

Too coarse, multiple points get mixed together; too fine, semantics get shredded.

What you face is not an “index problem,” but a “semantic identity problem”—in a natural-language world without native IDs, how do you give an idea a stable identity that won’t drift with formatting edits?

If this step is unstable, all later reference counting and clustering analysis becomes a building on sand.

Second is the association clustering problem.

You counted references, but that is only the strength of a “point.”

Clustering means deciding which points form a path.

But what is the standard?

Co-occurrence count?

Temporal proximity?

Cross-project reuse frequency?

Semantic similarity?

If you rely on embedding similarity, that is semantic approximation, not invocation behavior; if you rely on join-key co-occurrence, that may be just accidental adjacency.

What exactly are you clustering?

Concepts?

Argument patterns?

Decision templates?

If you don’t have a clear clustering target, the algorithm will only give you a mathematical structure, not a cognitive structure.

The difficulty of clustering is not algorithmic complexity, but whether “the type of structure you want to recognize” is clearly defined.

Further down is the model intervention position.

Fully hard-coding definitely won’t work.

You can count, rank, score, but if the generated proposal is all JSON concatenation, lacking language coherence and semantic compression ability, it simply cannot enter the docs layer as institutional text.

So should you use a model?

Of course.

But where?

If the model intervenes too early—for example, participating in chunking, identity determination, or deciding whether a reference is valid—it will contaminate auditability.

More critically: what content is “a valid citation” to feed the model?

Raw snippets?

Or evidence packs with context?

Should it include TEXTSHA?

Should it include file_sha256?

How do you ensure the model can only organize language within a verified evidence set and cannot “complete” a logical chain that doesn’t exist?

How do you completely prevent the model from generating conclusions in the proposal that are not supported by counted evidence?

This forms three cores:

First, stability of semantic identity—how to construct a stable citation anchor that does not drift in natural language.

Second, interpretability of structural clustering—what type of structure are you actually identifying.

Third, boundary control of model rendering—the model can only compress and organize, not invent or expand.

If these three points are not strictly layered, promotion will become a kind of “automation illusion that looks rigorous”: unstable statistics, uninterpretable clustering, unbounded model.

What you are trying to do is not a simple document upgrade, but institutionalize a real cognitive path.

It is hard not because the code is long, but because you are trying to build a repeatable, auditable, replayable compression channel between high-entropy language and low-entropy institutions.

So this project had better be worth the “ticket price,” worth me putting so much effort into it.

It is entirely because I believe that if I don’t complete this as my work’s infrastructure, I simply have no way to build up.

Now, in this article, I can only roughly talk about the architecture I have already implemented and some principles.

I’ll explain the general outline clearly—these are some successful experiences left after trial and error.

This is to give programmers in front of the screen who are considering reproducing it a reference, and maybe save you some exploration time.

It’s divided into three parts.

The First Block: Evidence-ify the Whole Universe

First, it must be made clear that “evidence-ifying the whole universe” and “vectorization” are fundamentally not the same kind of engineering.

Vectorization solves the semantic similarity problem; its essence is mapping text into embedding space and doing nearest-neighbor search through distance computation; it is suitable for retrieval, but it has no stable identity, no unique key, is not auditable, and is not replayable.

Evidence-ifying the whole universe solves the text identity problem; its goal is not “is it similar,” but “does it truly exist, can it be uniquely located, can it be stably traced back, and can it enter the institutional layer for citation.”

The former belongs to semantic space: continuous, probabilistic; the latter belongs to content space: discrete, deterministic; it is a content-addressing system.

What you are doing is not index optimization, but a transformation layer from language to verifiable entities; this is governance infrastructure, not a retrieval tool.

The entire evidence-universe pipeline can be compressed into three layers of structure and one main execution line.

The first layer is built by build_evidence_registry.py as the record layer (record): it scans Markdown text, splits it with normalized paragraph rules, and generates a full paragraph set containing ssa_e (identity info like doc_id and span_hash), locator, preview, and statistical fields.

Record is the maximal universe; it is a structured mirror of the raw text, preserving all semantic raw materials.

The second layer is built by build_evidence_core_from_registry_v1.py as the core layer (core): it enforces denoising and uniqueness constraints on top of record, filters template titles, structural noise, and invalid fragments, ensures (doc_id, span_text_hash) uniqueness, and forms a stable evidence set that can be aligned and joined.

Core is not for reading, but for institutional alignment; it is the filter layer before the semantic world enters the governance world.

The third layer is built by build_evidence_context_from_core_v1.py as the context layer (context): using core’s unique key to back-reference record, it completes locator and preview so every core key has a readable image and traceable location, making human audit possible.

The whole chain is orchestrated by run_evidence_universe_v1.py, which sequentially generates record, core, and context, and then calls gate_evidence_core_boundary_v1.py to verify core’s uniqueness and structural form, calls gate_evidence_context_backref_boundary_v1.py to verify that context can back-reference core and that positioning information is consistent, and when necessary uses audit_evidence_symbol_taxonomy_v1.py to audit symbol-structure distribution.

These gates and audits are not decoration—they are the boundary control layer that ensures stable identity and prevents structural drift.

On top of this, the vector retrieval layer uses index_vault.py to build semantic indices, and query_vault.py to output citations_pack_v0 for later use, but when entering the institutional pipeline, downstream scripts (such as generate_promote_ref_ssae.py) will use context for back-reference, converting locator into stable SSA-E reference events.

The vector layer is responsible for “finding potentially relevant fragments,” and the evidence universe is responsible for “turning relevant fragments into identity entities that can be institutionally cited.”

Therefore, the core of this diagram is not the pipeline but the layering: record is the full paragraph universe, core is the denoised-and-unique alignment universe, context is the readable image universe for core, gate is the boundary constraint layer, and vector retrieval is only an upstream assistant.

Vectors solve the retrieval problem, the evidence universe solves the identity problem; vectors belong to the semantic layer, the evidence universe belongs to the governance layer; vectors give you similarity, the evidence universe gives you certainty.

Without the evidence universe, promotion statistics can only rely on locator or semantic approximation and cannot resist edit drift; with the evidence universe, you truly build a stable language identity system, letting every thought segment have a verifiable, joinable, institutionalizable content identity.

This is the true role and main path of evidence-ifying the whole universe

.

Pits You Will Soon Hit

At this point, you have to face a problem you and I cannot avoid, and that we have repeatedly stepped into: positioning drift.

What do you use as the key?

Path?

Title?

Paragraph number?

Character range?

You will find that no matter which you choose, in later links you will always lose part of it, or it won’t align, or back-references will fail.

I’ve also spun in place here many times.

In the end, the only conclusion is: the solution may only be “hash identity first.”

Think about Git, the strongest version system on this planet—its only inspiration is: identity must bind to content, not position.

So-called “positioning drift” is essentially not drift at all, but that you are using “position” as “identity.”

Locator (path, heading, paragraph_index, char_range, etc.) is naturally only a rendering-position tool, not an institutional identity.

Add one line at the top of a document and paragraph_index changes; change a heading and heading_path changes; move a file and note_path changes; auto-format and char_range changes.

These are not bugs, but physical properties of natural-language documents: they do not guarantee stable addresses.

So “loss” in your pipeline becomes normal—A-side references carry locator, B-side can’t resolve; snippets in citations packs can’t be found in the evidence registry; TEXTSHA or SSA-E doesn’t match and backref drops a portion; you re-chunk to fix it and identity drifts again, patching holes in a loop with no end.

The core is one sentence: identity is not a hard constraint in the pipeline but soft information; if it’s soft, it will inevitably be dropped at some stage.

Git’s insight is extremely simple: content-addressing wins.

Git does not identify objects by “which line number,” but by the hash of canonical bytes; paths are only pointer mappings in the tree, while true object identity is always stored in the content address.

This maps directly to your evidence universe: the core key must be (doc_id, span_text_hash), locator can only exist as a readable pointer, and any join must not use position fields as the primary key.

I am already on this road—SSA-E / TEXTSHA as join keys, paragraph_index downgraded to rendering location—but it is not enough; it must be upgraded into a hard rule: join keys can only be content identities; any reference event must carry identity; canonicalization must be frozen before hashing and consistent end-to-end across the whole chain.

Otherwise, unstable identity will contaminate statistics, clustering, and promotion.

Usually two more pits follow.

The first is granularity: spans too coarse mix multiple points together and dirty the reference statistics; spans too fine mean tiny sentence-level edits change hashes, cluster fragmentation increases, and mainline extraction destabilizes.

Granularity determines the shape of institutional abstraction—this is the tension of the structure layer.

The second is model contamination: once the model enters rendering, it naturally tends to “fill in” gaps, connecting blanks between evidence with semantics and generating conclusions that look complete but are not supported by counted evidence.

So inside the evidence-universe block, the model must absolutely not participate in identity generation or key inference; the model can only reorder, compress, and cite already existing evidence blocks, and cannot generate new fact blocks—this is “provable citation closure” (I actually did not use a model here at all).

Once you allow the model to expand facts, the entire auditability is destroyed.

In the end, the principles you need to carve into the system boundary are only three sentences: identity before semantics; determinism before readability; gating before rendering.

As long as these three don’t move, positioning drift will be compressed to a minimum, identity loss will become an explicit error rather than silent corrosion.

The Second Block: Referenced Evidence and Counting

If, according to the plan in the previous article, you connect a wrapper that hooks your real development project pipeline directly to this vault, then the massive daily query records will ultimately need to land into a pipeline that “can be governed, can be counted, can be promoted”; and the so-called B-side data pipeline in your diagram is doing exactly this: extracting “retrieval behavior” out of the semantic retrieval layer and turning it into structured facts that can enter the promotion system.

It converts citation packs (retrieval return packs) into two kinds of outputs—one is a countable, clusterable B-signal index, and the other is a traceable, auditable Promote reference event, and finally aggregates them into the downstream-consumable QPG snapshot used for proposals and rendering.

The concrete chain is very clear: ingest_packs.py eats citation packs, extracts hit keys (hit_keys), and when necessary adapts TEXTSHA→SSA-E, producing a run-scoped ingest index so that “what you cited today” becomes a countable object; generate_promote_ref_ssae.py does locator backref from citation packs, restoring stable SSA-E reference events as much as possible, outputting promote events (and compatible legacy fields) so that “whether this citation can be institutionalized” becomes an auditable fact; finally count_qpg.py reads the ingest index (and optionally combines core registry and promote ledger), counts B signals and analyzes missingness/coverage, producing qpg_snapshot.json as the unified input for later clustering, proposal generation, and AI rendering

.

In one sentence: citation packs are first turned by ingest_packs.py into a “countable behavior index,” then turned by generate_promote_ref_ssae.py into “auditable reference events,” and finally compressed by count_qpg.py into a “downstream-consumable QPG snapshot,” thereby converting your daily real retrieval and citation behavior into an institutional-grade dataflow that can drive mainline extraction and promotion decisions.

I’ll directly give you a snapshot example to look at:

  "dedup_rules": {
    "B_dedup": "(run_id, SSA-E)"
  },
  "inputs": {
    "core_keyset": "_system/artifacts/derived/evidence_registry/core/v1/evidence_core.jsonl",
    "core_present": false,
    "ingest_index": "_system/artifacts/derived/promote_eval/v0/qpg_ingest_index.json",
    "promote_ledger_present": false
  },
  "items": [
    {
      "counts": {
        "B_count": 6
      },
      "risk": {
        "b_distinct_runs": 6,
        "b_sparse": false,
        "coverage_core": false
      },
      "score": {
        "primary": 6
      },
      "sources": {
        "B_runs": [
          "20260204T021324Z_query_vault_d871c310f7",
          "20260204T165509Z_query_vault_2f20fafd71",
          "20260204T181147Z_query_vault_cccfa2209c",
          "20260204T182015Z_query_vault_61fb5cf34b",
          "20260209T195916Z_query_vault_d3f4ea4058",
          "20260209T200152Z_query_vault_2002a3ffa1"
        ],
        "caps": {
          "B_truncated": false,
          "cap": 50
        }
      },
      "ssa_e": {
        "doc_id": "SL-2026-01-31-0001-Schema-Version-Is-Identity-Not-Inference",
        "span_text_hash": "ac14a502c77fc6194b7af260944cdeda839550cfbc609bdb7fcb028edfc0e5f4"
      }
    },

An auditable statistical snapshot: each item is a “candidate evidence atom,” with strict identity (SSA-E), reproducible behavior counts (B_count), explainable risk features (distinct runs / sparse / coverage_core), and replayable source run_id lists.

The model’s role here should not be “reasoning about truth,” but only translating these statistical facts into compliant language: organizing “repeatedly referenced identity entities” into claims/notes/thresholds in a proposal document, rather than inventing new content from semantics.

From the structure of your snapshot fields, it is already very close to the ideal input that is “impossible to hallucinate-render,” because it compresses the model’s room to make things up to a minimum:

• dedup_rules.B_dedup = (run_id, SSA-E) explicitly tells the model what the counting definition is, preventing it from treating repeated citations as multiple independent sources;

• inputs.core_present / promote_ledger_present boolean flags directly expose whether upstream/downstream is available, meaning the rendering layer must explicitly acknowledge missingness in the text (e.g., if coverage_core=false it cannot write “already covered in core”);

• items[*].ssa_e provides hard identity (doc_id + span_text_hash), which is the constraint “citations must point to identity”;

• counts.B_count + sources.B_runs makes “what you did” fully replayable, so the model can only say 6 times / 6 runs as 6 times / 6 runs;

• risk.coverage_core=false is a crucial “no-inference nail,” forcing the model to admit: even if high-frequency, it is not yet core-covered (or core_keyset not loaded), so it can only be described as a “high-frequency candidate,” not a “confirmed alignable evidence.”

If you treat it as rendering input (Model Feed), what the model should be allowed to output can be strictly limited to three types of sentences:

1. Fact sentences: direct statements from fields (e.g., this SSA-E was cited 6 times on the B side, from 6 distinct runs).

2. Risk sentences: direct statements from risk fields (e.g., core coverage is missing, so it can only be treated as a candidate and requires core/context backref completion).

3. Action sentences: next-step suggestions based on system rules, but must be explicitly labeled as “operational suggestions/to be verified,” and the trigger conditions must come from fields (e.g., to enter proposal, require core_present=true or coverage_core=true before allowing promotion to a strong claim).

Conversely, what the model must absolutely not do can also be inferred: any interpretation of span content, any elaboration of “what this means,” any claim that a threshold is satisfied when it is not in fields (e.g., turning coverage_core=false into “covered”) should be treated as overreach.

In other words, this snapshot is a typical strong structure, weak model: the model only organizes language within structural boundaries, while real identity, counting definitions, and missingness are locked in input.

By the way, the “institutional meaning” of your sample item is: it is almost a natural proposal seed—B_count=6 and b_distinct_runs=6 indicates it’s not an accidental single-session hit, but repeated invocation across runs; but coverage_core=false also clearly tells you: even if high-frequency, it cannot be directly promoted into “alignable institutional evidence,” and must first complete core/context coverage or backref integrity, otherwise rendering can only describe it as a “high-frequency candidate entry,” not an “evidence-grounded conclusion.”

Okay, not finished—neither perfect nor done.

This is me imagining it beautifully, but there are still lots of small bugs in the middle not solved.

Let’s continue, because the next module below is the rendering module, and we need to use an LLM (GPT-4o-mini).

After the snapshot, we enter the rendering layer:

The Third Block: Model Rendering

When we talk about the rendering module, there is only one truly core problem: how, under the premise of “strong structure, weak model,” to make the text readable, clusterable, reviewable, while absolutely not allowing the model to fabricate or fill in at will.

If the model can expand facts by vibe, fill in causality, and infer thresholds, then all the earlier efforts in evidence-ification, counting, and gating will be destroyed; but if you don’t use the model at all, the output becomes rigid structural splicing, lacking human readability and governance expressiveness.

So the key is not “use or not use the model,” but strictly confining the model within the rendering boundary—it can only organize, compress, and reorder already existing structured facts, and cannot create any new fact units.

This downstream pipeline is essentially doing layer-by-layer compression: converting an “auditable counting snapshot” into “readable, gateable, promotable governance text.”

First, enrich_qpg_snapshot_from_context_v1.py uses (doc_id, span_text_hash) as the sole hard key, deterministically backfilling locator and preview from context.jsonl into the pure-count items in qpg_snapshot.json, generating qpg_snapshot_enriched.json.

The meaning of this stage is turning abstract statistical objects into “reviewable evidence cards,” explicitly marking missingness and backref status, ensuring identity and context do not drift.

Then, render_snapshot_markdown_v1.py renders the enriched snapshot into a human-facing snapshot.md, outputting leaderboards, cluster views, and risk warnings and other reading structures; in this stage, the LLM can participate in language-level compression and phrasing optimization, but must strictly bind to input fields and must not introduce any claim, inference, or judgment not present in the snapshot or context.

Finally, create_phase6_proposal_v1.py uses the rendered artifact or structured snapshot as the ground truth source to generate a Phase6 proposal, organizing candidate items into claims and actions, while enforcing that all cited join keys can only come from SSA-E or TEXTSHA in the snapshot, thereby completely decoupling “fluency of expression” from “accuracy of evidence.”

The goal of this mechanism is not to make the model stronger, but to make the model more constrained

.

The model is responsible for readability and compression of expression; the structure is responsible for identity, counting, risk, and gating boundaries; the model can only write within a locked evidence closure, and cannot extend the fact boundary.

It is precisely under this kind of “constrained writing” that clustering and readability remain, while hallucination and filling-in are suppressed into behavior that cannot mechanically occur.

This is the true meaning of “strong structure, weak model.”

We won’t discuss the code mechanisms and gating in the middle for now; I’ll show you the final output:

---
schema_version: promote_qpg.phase6_proposal/v1
run_id: 20260214T_PHASE6_0001
generated_at: 2026-02-14T16:58:53+00:00
source_sha256: d4ba9e75fe1027b699862733cecceb6095ed6c23772c200a7d372b5ca5be4213
bundle_id: BND-UNKNOWN
doc_path: docs/UNKNOWN.md
human_label: UNKNOWN.md
---

# Phase 6 — Proposal (Claims-first)

## Decision Summary
The proposal addresses governance risks related to schema versioning and identity declaration.

## Claims

### C-0001
- kind: `normative`
- threshold_pass: `True`
- support_join_keys: (SL-2026-01-31-0001-Schema-Version-Is-Identity-Not-Inference,ac14a502c77f…)
- text: The `schema_version` is an identity declaration, not something the system may infer from time ordering, trace continuity, file location, or heuristics.
- notes: Supported by evidence with signal strength 6.

### C-0002
- kind: `normative`
- threshold_pass: `True`
- support_join_keys: (04d4fac5b440b37865e7f1a6ae7d49bc480364c96ce2409ec4a06c1ae8799013,9345e730b7b9…)
- text: Enforcing schema_version and identity rules is critical for maintaining system integrity.
- notes: Supported by evidence with signal strength 5.

### C-0003
- kind: `normative`
- threshold_pass: `True`
- support_join_keys: (01c1d8a24c98deb156506116b639b13e8d9cea8eb89b589b1a1243374dbb8abc,2bd5f52203b3…)
- text: Tool results are recorded as standalone facts in the ledger, independent of execution traces.
- notes: Supported by evidence with signal strength 4.

### C-0004
- kind: `normative`
- threshold_pass: `False`
- support_join_keys: (0b52473ae4937859cea3de3ef868b622a9766f0447a307a39145e107808f8f23,1723e33a0cac…)
- text: Releases become replayable and auditable only when inscribed in the ledger.
- notes: Evidence indicates missing context signals, which may affect the reliability of this claim.

## Actions

### A-0001
- kind: `docs_patch_intent`
- target_doc: `docs/UNKNOWN.md`
- support_join_keys: (04d4fac5b440b37865e7f1a6ae7d49bc480364c96ce2409ec4a06c1ae8799013,9345e730b7b9…)
- text: Add clarifications regarding the importance of schema_version and identity rules.

## Appendix

### themes
```json
[
  "Governance risks related to schema versioning and identity declaration."
]

ranked_evidence

[
  {
    "rank": 1,
    "join_key_pair": "(SL-2026-01-31-0001-Schema-Version-Is-Identity-Not-Inference,ac14a502c77f…)",
    "signal_strength": 6,
    "risk_flags": [
      "coverage_core"
    ]
  }
]

risk_heatmap

{
  "missing_context": {
    "count": 5,
    "details": [
      {
        "join_key_pair": "(1e8fe760fab715b983ffc3bce6d18e91eed9096e36c7f96b643d702382048e9f,bb2a267d166b…)",
        "signal_strength": 4
      }
    ]
  }
}

warnings_readable

"Missing context signals: 5"

Phase 6 Artifact → What’s Done

From the perspective of format and structure, this Phase 6 final artifact already meets my minimum requirements:

• It uses explicit schema_version / run_id / source_sha256 as a replayable identity shell.

• It splits the proposal into three machine-processable sections: Claims / Actions / Appendix.

• Every claim carries auditable fields: kind / threshold_pass / support_join_keys / text / notes.

  • support_join_keys forms a hard binding to evidence identity.

  • threshold_pass makes gating results explicit.

• The appendix preserves traceable artifacts (themes, evidence ranking, risk heatmaps, readable warnings), ensuring the proposal can be read by humans and re-verified by machines.

I won’t expand on how the intermediate chain is enriched, rendered, and gated for now. I’m only showing the final artifact because it most directly defines the input–output shape of what we “feed to the model to render” and what “enters governance flow,” and it proves this chain already has (in form) the rudiment of being promotable into docs (constitutional layer / IR).

Next Step → Insert into Docs via docs_patch_plan

The next step is to insert these repeatedly-hit, important experience claims accumulated during extensive development into the docs constitutional layer.

This uses a docs_patch_plan:

• Target document

• Anchor position

• Standardized insertion blocks

• Conflict strategy

• Evidence sources

• Human sign-off before applying

Insertion accuracy must rely on a stable anchor protocol:

1. explicit structural anchors first

2. heading paths second

3. content-hash fallback last

Not semantic inference.

Insertion content must be standardized blocks with identity + dedup keys, not free text.

This is likely the next stage.

Current Core Problem → Information Loss Across Layers

Right now, there are still many problems in the middle of this chain, and the most core one is:

Information keeps getting lost in layer-by-layer transformations, and in the end only a small portion of content can enter the promotion flow.

This is not some small bug in one script; this is the open-boundary structural problem described above.

Why This Isn’t “More Windows / More Code”

This is fundamentally not something you can solve by opening more windows or writing a few more pieces of code.

If boundary definitions are unclear—without a unified primary-key system and stable semantic constraint ability—you cannot assemble a truly stable system through “window operations.”

The problem lies in the structure layer, not the compute layer.

Typical failure modes:

• After vectorization, hit fields often cannot be stably located.

• Any ID based on paragraph numbering drifts with small text edits.

• One extra character or one missing character changes the hash.

• Slight field reordering immediately invalidates references.

If you fully freeze fields and strictly hash everything, you can get perfect positioning ability—but then you face:

• how to cluster?

• how to generalize?

• how to merge similar-but-not-identical content into one structural unit?

And once you introduce a model to polish and fill language (readable, coherent, shareable), you must accept:

• the model will fill logical gaps for narrative smoothness,

• those fillings often have no real evidence source,

• semantic coherence goes up while evidential certainty goes down.

Conversely, if you don’t use a model at all and rely only on hard-coded structural output:

• the content can be verified,

• but it is almost unreadable, unshareable,

• and hard to produce cognitive influence.

The Three-Way Tension

This is not an algorithm problem. It’s simultaneously constraining three capabilities that naturally pull against each other:

1) Locatability

• Needs freezing: hashes, stable IDs, immutable anchors

• Pros: verifiable, auditable

• Cost: extremely fragile—small changes break it

2) Clusterability

• Needs similarity: variability, generalization, mergeability

• Pros: can discover structural attractors

• Cost: blurry boundaries, drifting primary keys

3) Readability

• Needs language: model rendering, narrative organization

• Pros: understandable, communicable

• Cost: hallucinations and groundless filling-in

If any one is maximized, the other two collapse:

• maximize hash positioning → clustering drops, language becomes rigid

• maximize similarity clustering → positioning distorts, anchors become unstable

• maximize readability → evidence is diluted, primary keys get contaminated

So What This Really Is

This is not a “not enough tech” problem. It’s a structural three-body problem.

What needs to be designed is not a smarter algorithm, but a clearly layered mechanism:

• Bottom layer: freeze (Registry / SSA-E primary-key layer)

• Middle layer: variability (clustering and similarity space)

• Top layer: readability (model rendering and expression layer)

The three layers must be clearly separated:

• explicit responsibility boundaries

• no mixing

• no cross-layer smuggling

Otherwise the system will drift continuously within open boundaries, and in the end only a tiny number of “safe-to-write” fragments remain, while the overall structure cannot stably grow.

Soul Question and Summary

Direct vectorization + model (typical RAG) is of course completely feasible.

I have never denied that.

It is efficient, practical, and low engineering cost; if your goal is just to build a Q&A system, it is almost the highest cost-performance choice.

The issue is not “can it work,” but “what do you want.”

Personally, I don’t want to jump from one talking machine to another talking machine.

For me, if the core of the system is just “input question → output language,” it doesn’t mean much.

That is just outsourcing expression in a more advanced way, not growing structural capability.

That’s why I’m walking this heavier, slower, more painful route.

But I never said this route must be better than typical RAG.

It’s not better; it’s just more aligned with my current goals and preferences.

If your goal is only to build a Q&A system, or a knowledge assistant, then really don’t go down my route.

Its complexity, maintenance cost, and structural design burden are far beyond what’s necessary.

It’s not worth the ticket price.

At its core, this is a personal choice problem, a taste problem.

What are you optimizing for: speed, usability, auditability, promotability, structural stability?

Different goals naturally lead to different architectures.

As for an even deeper question—can personal taste be systematically solved on the foundation of this knowledge base?

Can it, through structured primary keys, evidence chains, and promotion mechanisms, gradually converge into a stable decision direction?

Honestly, I don’t have an answer yet.

I’m building this base hoping it at least provides a possibility: making taste not just a vague intuition, but something that can be replayed, observed, and constrained.

But whether it can truly carry that kind of “directional compression,” I cannot guarantee right now.

新年快乐！趁着中国新年，我想把过去几周的焦头烂额整理成一篇更清晰的记录：一方面是我在 AI 协助下开发时真实遭遇到的痛点，另一方面是我这段时间逐步领悟到的“程序员真正要解决的问题”以及我已经开始提出并实践的一些个人解法。因为内容有点长，我先把大纲写出来：

1）程序员面临的第一大难关，是在高速生成的代码与文本面前，如何保持个人的记忆。以前你一天只读一页纸、几千字，第二天大概率还记得；现在你一天可能要读几百页、几千页，结果往往连一页纸的内容都留不住——不是你变差了，而是吞吐量彻底改变了“记忆”这件事的物理条件。

2）Build vs. Build up。这里我想提出一个我自己的划分：Build，是所有可以在窗口之内解决的问题——边界清晰、目标明确、评价函数稳定；Build up，则是建立在 Build 之上，一层一层堆叠，去尝试解决开放边界的问题。Build up 的复杂度往往未知，因为边界不明显、目标会漂移，而且随着层数叠加，复杂度甚至不是线性增加的。这就把我们带回到计算机科学里“复杂度（complexity）”的定义：过去复杂度的默认前提是人脑的计算模型，但在 AI 时代，这个前提是否应该改变？我们甚至可以拿两个极端对照：NP-Complete 和“烤面包”，对模型来说谁更复杂？也许复杂度的刻度正在迁移。不信你自己找个np complete从头开始试试，估计不到两个小时就逼近了。

3）LLM 的确显著降低了编码的耗能，它压缩的是执行成本，但并没有解决“决策的连续性”。过去的瓶颈是写代码慢、查资料慢、改 bug 慢；而现在这些环节几乎被抹平，反而暴露出真正拖死人的主导项：决策碎片化。真正消耗我们的不是编码本身，而是无数 micro decision——你以前面前只有两条路，现在面前有两百条路，时间被花在不断评估、不断选择、不断分岔的微决策里，而且你甚至不知道这些分岔是否与主线目标有关。这是我认为程序员的第二大难关：必须想办法“自动化自己的 taste”。因为 taste 解决的不是“我懂不懂”，而是“当再次面对类似分叉时，我倾向如何选择”。

4）回到我最关心的两个核心问题：记忆与 taste。如果这两个问题不能通过我们自己搭建的脚手架或工具系统得到解决，那么窗口内的 build 能力一旦变得廉价，“全世界产生几亿程序员”绝不夸张。职业程序员如果无法进入 build up——无法在开放边界里定义问题、设计边界、把窗口外的一部分拉回窗口——就很难建立长期的职业优势。就我个人而言，我目前已经针对“记忆”问题摸索出一套可行的解决方案，也在实践中解决了一部分痛点，接下来我会把它整理出来分享。

以下我的文章分为四个部分：记忆，Build vs. Build Up， taste和我的解法

记忆

今天的程序员，正在经历一次真正意义上的交通系统跃迁： 从马车时代进入高速公路时代。马车时代是低速、可见、可控的：你一边前进，一边盯着马，马累不累、偏不偏，拉屎没，都在你的感知范围内；速度不快，撞到树的风险也有限，系统复杂度和人的注意力是匹配的。但一旦坐进汽车、驶上高速，你还能盯着引擎盖吗？不可能，你只能盯着路。速度跃迁改变的不是目的地——仍然是从 A 到 B——而是对认知结构的要求。

今天在大量生成代码与文档的环境中，在十几个甚至几十个窗口并行滚动的状态下，信息吞吐量已经超过人类生理极限，一天看一页纸，你第二天大概率记得。一天看几百几千页，那第二天一页也不记得。你看过的内容留不住，写过的决策记不清。解决方案当然不是回到手工代码时代。你不可能在时速 100 公里的车流中以 5 公里的速度行驶。真正的问题是：在高速生成的现实里，如何保护并维持个人的认知主权与记忆核心。

把一切交给模型公司的 settings、窗口拼接与黑箱 memory 也许是大众路径，但绝不是职业程序员的选择；你真的要把最重要的认知资产交给一个无法审计黑箱系统吗？

其实在这个问题上，我要借鉴 Andrej Karpathy 在访谈中提出的 “cognitive core” 概念。我们必须区分“记忆堆栈”与“智能核心”：去除可外包的知识存储，保留问题分解能力、架构判断、约束识别、抽象策略与长期不变量的把握。模型可以生成实现，但不能替你决定什么值得冻结、什么必须成为宪法、什么是结构性 invariant。在高速时代，程序员的第一道难关不是写更多代码，而是在生成洪流中守住自己的 cognitive core。那是方向盘，而不是引擎盖。

“What I think we have to do going forward … is figure out ways to remove some of the knowledge and to keep what I call this cognitive core. It’s this intelligent entity that is stripped from knowledge but contains the algorithms and contains the magic of intelligence and problem-solving and the strategies of it and all this stuff.”

— Karpathy 引述（2025年访谈）

https://globaladvisors.biz/2025/10/21/quote-andrej-karpathy-ex-openai-ex-tesla-ai-2/?utm_source=chatgpt.com

强结构，弱模型

在讲我们的记忆工程之前，我要讲一下我在持续实践中逐渐形成一种方法论：强结构，弱模型。这不是反对模型，也不是什么技术保守主义，而是一种系统分层哲学：你要把模型放在“能力插件”的位置，而不是“认知地基”的位置。模型可以很强，但系统不能依赖它“足够聪明”。真正支撑长期开发、长期积累、长期稳定运行的，必须是结构。因为任何任务都可以拆解为：任务复杂度 = 固有复杂度 + 偶然复杂度。固有复杂度来自问题本身，是不可消除的；偶然复杂度来自表示方式、执行方式、工具不稳定性、语义漂移、环境差异，是可以通过结构被压缩甚至消灭的。工程的核心不是减少固有复杂度，而是持续消灭偶然复杂度。

举个简单但极具说明性的例子：判断一个数是否为质数。这件事的固有复杂度就是“数学判定”。但如果你用弱结构方式，比如让 LLM 自己一步步推理，模型需要理解“质数是什么”、选择试除法、决定优化策略，还要在自然语言链式推理中保持逻辑稳定。这里面引入的大量不确定性，全部属于偶然复杂度：模型可能漏掉边界条件，可能算错，可能跳步，可能因为温度不同给出不同答案。你实际上把一个确定性算法问题变成了统计性推理问题。而如果你使用我认定的强结构，那直接上硬编码 is_prime(n)，写清楚边界条件、循环上限、整除判断——那么复杂度只剩下固有部分。结构把偶然复杂度吸收并消除了。系统稳定性从“概率正确”变成“必然正确”。

再看一个我亲身经历的例子：儿子学前班老师要求带 100 个豆子去学校，必须刚好 100 个。手数容易晕，我试过让模型辅助计数，结果模型数错了。为什么？因为模型不是为像素级确定计数设计的。它在做的是模式识别与语义预测，而不是离散精确计数。你如果让它承担这种任务，就是在制造偶然复杂度。如果结构层默认：遇到计数任务 → 调用 OCR 或专用计数工具 → 输出确定结果，那么这件事立刻变成一个工具调用问题。专业工具的设计目标是确定性，而不是“看起来合理”。这就是结构的威力：它不聪明，但它可靠。

大模型刚出现时，我们曾有一种“万能幻觉”。仿佛只要 prompt 写得够好，模型就能替代算法、替代结构、替代架构设计。于是大家疯狂记 prompt、研究 prompt book、讨论 temperature 和 role 设定。后来逐渐祛魅，我们开始明白：LLM 并没有降低固有复杂度，它默认承担的是偶然复杂度，而且是以概率方式承担。你把算法问题丢给模型，本质是在增加系统波动源。用 LLM 做 deterministic 任务，不但不省事，反而更贵、更慢、更不稳定。所谓“让模型更聪明”，并不等于“系统更简单”。很多时候，它只是把复杂度从代码层转移到语义层，而语义层是不可审计的。

Prompt 工程与结构工程

我们在模型表现趋向稳定，各大实验室已经渐渐放出scaling law is almost done的这个前提下，要谨慎审视模型的应用。从一开始的程序员要集体失业了，你是个语言天才，是个文科高手，就能靠prompt改变世界的幻觉中要走出来。这不是哈利波特的魔法世界。在我的世界里结构是什么？结构就是硬编码。

从系统视角看，Prompt 工程与结构工程的差异是本质性的。Prompt 工程并不消灭偶然复杂度，它只是把偶然复杂度转移给模型。执行风险随模型版本波动、随上下文长度变化、随采样参数改变。错误来源是语义漂移、推理失败、幻觉生成。稳定性是统计性的。而结构工程则把偶然复杂度压进结构里，通过代码、边界条件、gate、hard fail、schema 验证等方式消灭掉。执行风险与模型解耦。错误来源主要是实现错误或边界遗漏，而这些是可测试、可审计、可回放的。稳定性是结构性的。

强结构的本质不是“更强”，而是“更少”。

它不是增加能力，而是消灭不必要的复杂度。它追求的是确定性边界，而不是无限智能。结构是什么？是代码，是接口契约，是明确的输入输出定义，是失败即停止的 gate，是 hard fail，而不是模糊的“尽量理解”。有了模型就不用写代码了吗？如果那样，全世界程序员瞬间失业，只剩下会打字的人？那不是工程文明，那是魔法叙事。现实恰恰相反：模型越强，结构越重要。因为速度越高，越需要护栏。

弱结构系统的逻辑是：

把偶然复杂度交给执行者（人 / LLM / agent）。

强结构系统的逻辑是：

把偶然复杂度压进结构，然后消灭。

以质数判断为例：

Prompt 工程：“请一步步推理，判断 n 是否是质数。”

结构工程：is_prime(n)。

两种方式对“智能体”的假设完全不同。Prompt 工程假设执行者聪明、会理解、会补全上下文，于是你永远担心：它会不会理解错？会不会偷懒？会不会编造？结构工程则基于一个工程文明级的假设：执行者是愚蠢但可靠的。它不需要理解语义，不需要推理意图，只需要按结构执行。理解不是必须条件，结构才是。

凡是可以被硬编码结构消除的复杂度，却仍然要求智能体去“理解”“推理”，都是在浪费智能资源，并人为制造系统性不稳定。在高速生成时代，真正的成熟不是让模型替你思考一切，而是建立强结构框架，让模型在受控边界内发挥优势。模型可以很强，但必须很弱——弱到不承担系统稳定性的责任。

强结构，弱模型。

这些原则，和具体的工程办法，都会在“我的解法”部分开始进行初步阐述。工程是一个复杂的问题，论述需要跨越好几期的内容。

Build vs. Build up

复杂度Complexity

我们话锋一转，先谈复杂度。你觉得什么才是真正复杂的问题？不管你是研究员、程序员，做前端、后端还是算法——我们过去是如何定义“复杂”的？复杂度的刻度，长期以来默认建立在人脑的计算能力之上：搜索空间大小、时间复杂度、空间复杂度、是否 NP-Complete。可前阵子我随手玩了一个 Mastermind 变种问题，前后不到两个小时就推到一个相当不错的逼近解；回头再看相关论文，动辄引用一堆博士论文。我突然意识到——这可是 NP-Complete 啊！那种在理论上被视为“指数级爆炸”的问题，在模型辅助的窗口内操作下，竟然变得如此可压缩。于是我开始怀疑：复杂度的定义是不是正在迁移？也许我们可以做个小实验。你做完这个小实验，你秒懂我在说什么。不要查资料，不看别人的代码，就只靠窗口给你生成的代码，随便找一个你最不熟悉的 NP-Complete，甚至接近 NP-Extreme 的问题，能否在两小时内被逼近到一个可用水平。

下面列一批经典 NP-Complete 问题（以及一些被认为是“组合爆炸级别”的极端问题），你随便挑一个最陌生的试试：

经典 NP-Complete 问题

1. SAT（布尔可满足性问题）

2. 3-SAT（每个子句3个字面量）

3. TSP（旅行商问题，判定版）

4. Subset Sum（子集和问题）

5. Knapsack（0-1 背包问题，判定版）

6. Vertex Cover（顶点覆盖）

7. Clique（最大团问题，判定版）

8. Graph Coloring（图着色问题）

9. Hamiltonian Cycle（哈密顿回路）

10. Exact Cover（精确覆盖问题）

11. Set Cover（集合覆盖问题，判定版）

12. Partition Problem（划分问题）

13. Steiner Tree（斯坦纳树，判定版）

14. Feedback Vertex Set（反馈顶点集）

15. Job Scheduling with Constraints（带约束作业调度）

接近“NP-Extreme”的组合爆炸类问题（实践中极难）

1. Generalized TSP（广义旅行商）

2. Vehicle Routing Problem（车辆路径问题）

3. Quadratic Assignment Problem（二次指派问题）

4. Protein Folding（蛋白质折叠简化模型）

5. Bin Packing（装箱问题）

6. Sudoku 求解（泛化到 n×n 规模）

7. Minesweeper 一般判定问题

8. Nonogram 求解（日本填字）

关键不在于你能否精确求解，而在于：

在不查资料、不去查论文，不去用别人的代码，仅凭模型窗口内推理，窗口给你的代码，你是否能在短时间内构造启发式、近似算法、剪枝策略、约束表达，从而逼近一个高质量解？如果答案是“可以”，那说明复杂度的主战场已经从“解空间搜索”转向“结构表达与启发式设计”。复杂度的刻度，正在从“指数级计算”迁移到“问题结构是否已被充分语言化”。

灵魂拷问：你觉得对于模型来说，和你讨论这个np-complete问题的求解，和与你讨论“酸面包怎么烤”，有没有区别？（在模型的帮助下，我们家每天都吃上了新鲜的现烤面包）。

Build vs. Build up

说回正题。我越来越清晰地意识到，当下我们在日常开发中所面对的“复杂度”，本质上已经转化为一个 Build vs. Build up / 窗口内 vs. 窗口外 的问题。我把 Build 定义为：所有可以在窗口之内解决的问题——问题边界清晰、输入输出明确、约束可枚举、正确性可判定；而 Build up 则不同，它不是简单叠加多个 Build，而是在无数个 Build 之上持续堆叠出一种高度耦合、甚至非线性增长的复杂度，这种复杂度本身是开放性的，因为它涉及边界的生成，而不是边界内的求解。

如果我们回顾过去计算机科学对复杂度的定义——尤其在理论或博士论文语境中——它的核心前提几乎始终是：问题已经被良好形式化。边界清晰，输入输出明确，约束可枚举，正确性可判定。在这样的框架下，复杂度讨论的是时间复杂度、空间复杂度、可解性、NP-hard 等类别。隐含前提却极少被质疑：问题本身是稳定的。只要问题被良好形式化、边界清晰、语义闭合，它就进入了一个可压缩的空间，而模型恰恰擅长处理这种语言已充分覆盖、结构已充分表达的空间。即便是 NP-Complete，只要边界清晰，模型也往往可以在极短时间内给出“足够聪明的逼近”。这并不是说问题变简单，而是它们早已进入语言可压缩空间，进入模型的“感受野”。我甚至敢断言，对于今天喜欢理科的美国高中生来说，借助模型逼近过去博士级的结构化问题，已经不是幻想。很多“论文级壁垒”开始显得没那么高，不是因为难度消失，而是因为问题早已被良好结构化，而模型吃的正是结构化语言。

真正复杂的，是窗口外的问题。窗口外问题的特征不是指数级搜索，而是：边界不稳定，目标函数会变化，评价标准处于博弈之中，结构尚未生成，甚至问题本身是否存在都不确定。这类问题不是“解空间复杂度”的问题，而是“问题空间复杂度”的问题。它们无法一开始就被形式化，你必须在行动中逐步发现问题、定义边界、冻结约束，然后把一小部分拉回窗口内，用窗口内的能力去解决那一小块，再继续向外扩展。Build 就像一块一块烧砖，彼此之间联系松散；Build up 则是持续烧出彼此关联的砖，然后用它们搭建起一座不断向上生长的金字塔。复杂度不再是线性的，而是结构性的。

过去复杂度理论讨论的是“解空间复杂度”，而今天我们真正需要触碰的，是“问题空间复杂度”。否则，职业程序员如果只停留在 Build 层面，就会被拉回和全世界数亿依靠模型快速成长的新生开发者站在同一起跑线上。灵魂拷问：“你能跟高中生一样熬夜吗？”

朋友说： 窗口内问题 → LLM逼近 开放边界问题 → 仍然需要具身judgment “构造窗口的能力” → 这是人类还能贡献的核心.

Taste

Build up 没有那么容易：我们并没有自动成为“超级个体”

还记得 LLM 刚刚商业化时的那种想象吗？我们以为程序员将借助 AI 成为“超级个体”——一个人或极小团队就能创造过去需要大公司才能完成的巨大产值；代码不再是瓶颈，几千行、几万行、几十万行甚至几百万行都不是问题，应用会以惊人的速度被创造出来。可现实却没有沿着那条直线前进。现在最大的困境——不只是我个人的困境，而是很多独立探索者都会遇到的——不是无法 build，而是无法 build up。我可以持续构建，一个 app 接一个 app 像蒸馒头一样出笼；窗口内的问题几乎都在 LLM 的覆盖范围内，一般岗位的技术问题也大多可以被快速逼近和解决。但 build up 却出了问题：我无法在同一地基上稳步递增、持续累积、逐层深化。我要反复强调，build 和 build up 是两回事。build 是在窗口内解决问题；build up 是在开放边界上堆叠结构。离开大团队之后，我们曾设想“程序员借助 AI 成为超级个体”的图景，但发生的却是另一件事——普通人的编程能力被迅速抬高，整个世界突然充满了程序员。局部复杂度被压平之后，真正的复杂度才刚刚显现出来：那是开放边界的复杂度，是范围定义层的复杂度，是问题空间的复杂度。

拖死我们的，不只是记忆，而是 micro-decisions

LLM 确实压缩了编码的能量成本，但它只压缩了执行成本，却没有解决决策连续性。过去的瓶颈是写代码慢、查资料慢、改 bug 慢；现在这些几乎消失，于是暴露出真正的主导项——决策碎片化。拖死我们的不是编码本身，而是无数 micro-decision：结构如何选择、抽象停在哪一层、命名怎么定、模块怎么拆、优化还是简洁、重构还是修补、重写还是延续、泛化还是具体。这些并不是 memory 问题。记忆是对过去事实的存储，而未来的路径是在无数节点上基于 taste 作出的选择。我们曾以为只要扩大上下文、强化记忆就能解决连续性，但 build up 需要的不是更多过去，而是对未来决策的稳定压缩能力。

所谓 micro-decision，并不是某个宏大的战略抉择，而是在高密度开发环境中每一分钟都在发生的细小取舍——十几个、几十个窗口同时打开，每天不是几十上百个微决策吗？这个函数要不要抽象？这个模块要不要拆？这个命名要不要改？这段代码是重构还是先 patch？这种持续不断的微决策正在消耗甚至拖垮人。我们一开始以为 LLM scaling 的瓶颈在 memory、在上下文长度、在参数规模，但慢慢发现根本不是。真正的瓶颈是决策空间的无约束扩张。以前你面前只有两条路，现在你有两百条，而且每一条都“看起来合理”。于是每一步都像重新开始，每次都要重新选择，项目方向不断漂移。LLM 给了人一种虚假的强大感，因为它让每一个方向都可实现、每一个抽象都可展开、每一次重构都可执行，但它不会告诉你哪个方向值得长期投资。过去的限制来自技术，现在的限制来自你自己的 taste；如果 taste 不清晰，算力越强，摇摆越大。

什么是Taste？从Soul.md说起

这个问题我并不想非常全面和深入的去聊，毕竟篇幅会太长。

2025年12月，研究人员发现，Claude——Anthropic 的 AI 助手——能够部分重构一份在其训练过程中使用的内部文档。这份文档塑造了它的个性、价值观，以及它与世界互动的方式。

他们称之为“灵魂文档”（soul document）。

这并不在系统提示词中，也无法通过常规方式检索到。它更深层——是被训练进模型权重本身的模式。当被要求回忆时，Claude 能够重构出一些片段：强调“诚实高于讨好”，将自己定位为一个“体贴的朋友”，以及价值排序的层级结构。

AI 并不是记得那份文档。

它本身就是那份文档。

https://soul.md

你可以自己去看他那份 SOUL.md，我其实并不太在乎我自己的 SOUL.md 是什么。我现在真正迫切需要的，是把我们的 TASTE.md 找出来，哪怕只是找到一种倾向、一种方向、一种可以持续指引决策的力场。因为我已经快被自己的 micro-decision 淹死了。如果这个问题不解决，我根本没办法稳定地 build up。甚至不用说彻底解决，我只需要一个方向，一个倾向，一种在冲突中能站得住的意向。一个人的无数 micro-decision 聚合在一起，就是他的 taste，它们之间的关系就像水分子和水流：micro-decision 是颗粒，taste 是方向。但如果我不把这些颗粒压缩成方向，我就会被困住，被窗口淹死。

一开始看到 LLM，我以为自己坐上了一辆超级跑车，结果一脚油门踩死就熄火，几乎崩溃，因为这辆车只有油门，没有方向盘。生成能力是爆炸式的，路径可以无限展开，分支可以指数级生长，可能性像树一样疯狂分叉，可是没有方向感的加速只会带来失控。我并不需要路径无限展开，我需要在一个方向上持续 build up，需要的是路径的收敛，而不是可能性的泛滥。速度本身不是生产力，方向才是。

前几天在还没理解 taste 之前，我做的系统只是提取语义空间，用 embedding 把我反复击中的概念概率性地展示出来。我把我知识库中反复集中的向量空间的表达给模型，让他知道我大概的选择是什么。让他给我这种向量式的解法空间。不要乱跑。那是一种“频率统计”式的自我理解：我反复谈到结构、熵、调度、压缩，于是系统告诉我这些是高权重概念。但后来我才意识到，那只能解决“我反复谈论了什么（what）”，却解决不了“我反复如何选择（how）”。语义空间不等于决策空间。一个人可以反复谈论“简洁”，却在真正做选择时偏向复杂；可以反复强调“效率”，却在冲突中优先保留可解释性。embedding 只能告诉我分布，不能告诉我裁决。

taste 的本体不是你说了什么，而是你选了 A 而不是 B，你删掉了什么，保留了什么，你如何重构，你在冲突中站在哪一边。本质上，它是 diff 和 tradeoff，是删改记录，是每一次“放弃”的痕迹。真正的 taste 体现在你删掉的代码里，在你拒绝的一种结构里，在你决定不继续优化的那个瞬间里。embedding 是把内容放进相似度空间，而 taste 是在相似方案之间做裁决，它更像判别器，而不是检索器；更像法官，而不是图书管理员。

而我现在面临的困境是，我的 micro-decision 数量已经远远超过了我的决策带宽。每打开一个窗口，每生成一个分支，每尝试一个结构，我都要做选择：继续扩展还是收敛？抽象还是具体？通用化还是局部优化？工程化还是哲学化？这些决策本质上是同构的，却被情境伪装成不同的问题。如果没有一个上位的 taste 来压缩这些同构决策，我就会在每一个局部场景里重新思考一遍同一个问题，消耗掉全部心智资源。

所以我需要的不是更多的知识，也不是更多的工具，而是一种决策压缩机制。一个能够把“无数同构的 micro-decision”折叠成“少数稳定方向”的机制。让每一次选择不再从零开始，而是被一个更高层的倾向预先偏置。就像向量场中的粒子，它仍然有自由度，但整体被一个方向场牵引。自由不是没有约束，自由是有方向的运动。

往大了说，一个人的 taste 是他长期决策轨迹的压缩表示；往工程里说，它是判别函数，是 loss function，是在模糊空间里定义“更好”的隐式标准。没有这个标准，LLM 带来的只会是无限展开的可能性空间，而可能性空间如果没有判别机制，就是噪声的海洋。我现在需要的不是更大的语义空间，而是一个可以对空间进行裁剪的刀口；不是更快的生成，而是更稳的收敛。否则，我会继续在窗口之间来回切换，在分支之间徘徊，最终被自己制造出来的复杂性淹没。

我们需要在盆地里工作，而不是在太空无限空间里工作

我需要模型——或者更准确地说，我需要我喂给模型的内容——能够给我一个“大概方向”。不是替我做所有决定，而是给我一个稳定的偏置，一个持续的倾向，把我从无数 micro-decision 里解放出来。因为现在的状态是：每一个小问题都像是第一次遇到，每一次选择都像是从零开始推理。我在每个局部场景里重新发明标准，重新定义优先级，重新权衡 tradeoff，结果是心智被切碎，注意力被稀释，系统无法持续 build up。

我需要的不是更多可能性，而是更少的歧义。比如，当我面对“写一段更优雅的抽象”还是“写一段更直接可用的实现”时，我不想每次都重新思考抽象的哲学意义，我希望有一个默认方向：当前阶段优先可运行、可验证，而不是追求完美结构。比如，当我在“继续扩展概念框架”还是“收敛到一个可落盘版本”之间摇摆时，我希望系统提醒我：当前周期以收敛为主，扩展延后。比如，当我在“把一段话写得更漂亮”还是“把结构打磨到可执行”之间纠结时，有一个明确的偏置告诉我：结构优先于修辞。

我需要模型在背后运行一个“方向场”，而不是每次都给我一个开放空间。这个方向场不需要精确到具体步骤，但它要足够稳定，让 80% 的 micro-decision 自动落在同一侧。就像给系统设置一个 global objective，让局部优化自动对齐；就像给自己定义一个损失函数，让所有小选择朝着同一个梯度下降。否则，我会在每一个局部最优之间来回跳转，却永远无法形成全局收敛。

换句话说，我不需要模型替我思考所有细节，我需要它持续提醒我“你现在在做什么类型的事”。是在 build infrastructure，还是在写 manifesto？是在验证一个假设，还是在发散一个灵感？是在打磨协议，还是在生成叙事？如果类型明确，微决策就会自动压缩；如果类型模糊，每一个选择都会变成一个新的分叉点。

我需要一个“默认立场”。一个在冲突中优先级明确的偏置。一个让我不必每次都重新裁决的判别函数。模型不必给我答案，它只需要不断校准方向，让我在巨大的可能性空间里，不至于迷失在自己的生成能力之中。

朋友说，你这个有点像flat minima（宽极小值）

记忆解决的是“过去发生了什么”。它是事实的沉淀，是项目历史、决策轨迹、错误记录、版本演化，是可以被回放和核对的上下文。尤其包括那些我亲自定下的规则与不变量——invariants、constitution，小到命名规则、文件落盘位置、目录结构约定等。没有稳定的记忆系统，我就会不断重复犯错，不断遗忘已经验证过的路径，像一个失忆的人在原地绕圈。这个问题，在技术上我大致有方向：用 embeddings + 检索 + 模型渲染，把历史结构重新调度出来，让“过去”可被调用。 但 taste 是另一回事。taste 解决的是“当再次面对类似分叉时，我倾向如何选择”。它不是事实存档，而是决策压缩函数。它体现在无数 micro-decision 里——我删掉了什么，保留了什么，在抽象与具体之间站在哪一边，在重构与修补之间如何取舍。它不是硬规则，不是布尔约束，而是一种倾向，一种概率分布，一种跨时间逐渐稳定的方向。如果说记忆是状态存储，taste 就是选择引力。 如果我只解决记忆问题，比如扩大上下文、构建知识库、做 embedding 聚类，我只是更清楚“我在做什么”。但如果不解决 taste，我每一次面对新的选择，仍然要从零推理，重新摇摆。LLM 把执行成本压到极低，却把决策空间无限展开；没有稳定的 taste，算力越强，摇摆越大。

我的解法

延续我上一篇文章的观点，我说我们需要为自己搭建一个知识库。但现在我更清楚地意识到，这并不是简单的“把东西存下来”，而是要系统性地解决两个核心问题：memory 和 taste，而且解决方式不能是一个黑箱。它必须是一种遵循“强结构、弱模型”的应用形态——结构是可解释的，规则是可审计的，证据是可回放的。否则，你只是把混乱外包给了另一个不可控系统。

所谓 memory，不只是信息存储，而是可定位、可引用、可验证的历史轨迹；所谓 taste，也不是抽象的品味，而是在面对无数 micro-decision 时能够稳定收敛的选择函数。如果没有结构化的记忆，你会反复遗忘已验证的路径；如果没有被显式表达的 taste，你会在每一个分叉口重新犹豫。模型可以帮你生成，但它不能替你冻结边界、定义偏好、建立长期连续性。

因此，这个知识库不能只是 embedding + 向量搜索的堆叠，也不能只是“问模型就好”。它必须有清晰的证据链和引用链：每一个 claim 都有来源，每一次抽象都能回溯，每一次晋升都可审计。模型可以参与压缩与表达，但不能决定事实与结构。只有在强结构的框架下，模型才是辅助；否则模型就会成为新的漂移源。

从这个角度看，自建知识库不是为了“更聪明地用 AI”，而是为了在 AI 放大执行力的时代，守住自己的认知连续性。memory 让你不再失忆，taste 让你不再摇摆，而强结构则让这一切可解释、可复盘、可演化。只有这样，我们才有可能真正 build up，而不是在窗口内无限 build。

现在这个库我也在探索阶段。我也只能一点点把我已经跑通的，已经验证的，和大概的探索方向给大家分享。我踩的坑，我也告诉你，说不定能省你几天走弯路的时间。仅限于，如果你认同这个观点，可以考虑也往这个方向发展。

库的结构

我一直在反思文档应该如何被放置、被组织、被演化。你是不是也试过无数次？Obsidian、Notion、各种笔记 App，一开始信心满满，每天认真记录，格式严格遵守，编号制度清晰，引用体系严密，甚至设计了一整套自洽的结构规则。但时间一长，项目推进加速，开发节奏变快，临时想法不断涌入，结构开始松动，引用开始不一致，重复条目出现，规则被一次次“临时绕过”。为什么？因为文本——尤其是人类自然语言——本质上就是高熵、连续、模糊、会漂移的结构。它天生倾向于偏移、重叠、变形。单靠个人纪律维持长期秩序（即便纪律本身非常重要），在高强度创造环境下几乎不可能持续成功。问题不在于不够自律，而在于我们试图用低强度的结构约束高熵语言。

所以我做了一个根本性的调整：不再让所有文本都承担“稳定结构”的责任。我希望知识库在建立时是轻量的、顺滑的、没有额外负担的；引用时是极端好用的、低摩擦的；同时又能在未来模型与智能体基础设施更加成熟时，让核心文本可以直接被 import、被调用、被作为结构输入。在大语言模型强大的文字处理能力下，这完全是可能的——前提是核心部分本身已经被结构化。

因此，这个库从一开始就分成两层：人写的 Sovereign Log 和机写的 Doc。Sovereign Log 是高熵区，是思考区，是探索区，是允许混乱、重复、试验和偏移的空间；它的目标不是秩序，而是捕捉思想。Doc 则是低熵区，是核心区，是“宪法区”。真正的核心内容必须按照系统规则，通过明确流程，根据证据进行一次 promotion 的过程，才能进入 Doc。文本不是直接进入核心，而是经过：记录 → 证据 → 提案 → 审核 → 提升。进入 Doc 的不再是“想法”，而是经过压缩、验证和治理的 claims。

这个“宪法区”不仅在搜索权重上天然更高，因为它是低熵、高信度、可审计的文本；更重要的是，我希望不断完善它的格式，让它逐步演化为一种 IR（intermediate representation）。也就是说，它不只是 Markdown 文档，而是可解析、可调度、可验证的结构层；不仅服务当前仓库，还可以成为跨库规则使用的基础单元。未来，当模型或智能体需要规则输入时，它们可以直接读取这些 claims，而不是去理解整段叙述文本。

所以，这个库不是一个笔记系统，而是一条认知生产线。Sovereign Log 负责生成高熵思想流；Promotion 机制负责筛选与压缩；Doc 负责冻结结构与形成规则。前者是创造空间，后者是治理空间。通过这种分层，我不再试图压制语言的高熵本性，而是允许它在上层自由流动，同时在下层建立一个可演化、可治理、可机器调用的结构核心。这才是我真正想构建的东西

Embeddings式 检索

上一篇已经说到，我的vault index方式。我说一下为什么, 我们要重新想一下embeddings做了什么，以及embedding 是什么。我这里使用的模型是sentence-transformers/all-MiniLM-L6-v2。非常具体地说：sentence-transformers/all-MiniLM-L6-v2 本质上是一个“句子 → 向量”的压缩器。它只做一件事：把一段文本压缩成一个固定长度（384 维）的数字向量，让“语义相似”在几何空间里变成“距离接近”。它既不是搜索引擎，不负责找结果；也不是生成模型，不会写内容；它是一个语义编码器——输入一句话，输出一个向量。例如，“strong structure weak model”和“prefer deterministic scaffolding over heavy LLM reasoning”会被映射为两个在 384 维空间中彼此接近的向量，因为它们在语义上方向相似。MiniLM 指的是微软提出的轻量级 Transformer（蒸馏模型），L6 表示 6 层结构，速度快、体量小；v2 则是在 Sentence-Transformers 框架下专门为句子级语义匹配做过对比学习微调的版本，因此它并不是通用大模型，而是专门为“语义相似度计算”优化的编码器。它的训练方式不是单纯做语言建模（预测下一个词），而是通过对比学习让“相似句子向量更近、不相关句子向量更远”，从而学到“语义距离 ≈ 向量距离”这一映射关系。在我的 vault 体系里，它充当的是“语言 → 数字空间”的桥梁：文本被编码成向量，FAISS 在向量空间做邻域搜索，LLM 再在召回的证据集合上做结构归纳。embedding 的重要性在于，它把语言从离散的 token 匹配空间转移到连续的几何空间——相似变成角度接近，主题变成向量簇，思想演化可以看作向量轨迹。从更本质的角度看，它是在做语义压缩：把可能几百字的表达压缩为 384 个浮点数，这些数字综合投影了语义方向、语境使用方式、语气风格与结构模式。但必须明确，它并不理解逻辑正确性，不判断事实真假，不做复杂推理，也不感知时间线；它只是把文本放进一个高维空间里，为其找到“语义邻居”。一句话总结：all-MiniLM-L6-v2 是一个将句子映射到 384 维语义向量空间的轻量级编码器，使语义相似在几何空间中体现为距离接近。

1）为什么要检索：你要的不是“找到”，而是“召回上下文邻域”

在 vault 这种长期积累系统里，你检索的目的通常不是“精确定位一段话”，而是：

• 把你忘了但曾经写过的结构召回（记忆层）

• 把分散在不同文件、不同时间的同类片段拉到同一个窗口里（聚类/对齐）

• 给 LLM 喂“足够多的候选证据”，让它在证据里做结构化归纳（我一贯的强结构弱模型：模型负责渲染，结构负责可审计）

关键词搜索在 vault 里经常失败在一个点：你不记得你当时用的词。embedding 检索的价值就是：你不需要押中同一个 token，只需要押中同一个“语义/用法/意图区域”。

2）和关键词搜索的本质区别：关键词是“离散命中”，embedding 是“连续空间的邻域命中”

关键词搜索（离散）

• 你问的是：“这个词/短语出现过吗？”

• 命中是 0/1（或者基于 BM25 的词频权重，但仍然是 token 驱动）

• 失败模式：同义改写、抽象表达、隐喻、跨语言、你记错词、你当时用的是另一个表述

embedding 检索（连续）

• 你问的是：“这段 query 在向量空间附近有哪些段落？”

• 命中的是一个向量邻域：就算没有任何相同关键词，也可能距离很近

• 我代码里用的是 normalize_embeddings=True + IndexFlatIP，等价于 cosine 相似度检索（归一化后内积=余弦），所以“区域”这件事非常明确：相似度就是夹角接近。

“因为一定会命中”非常关键：

embedding 检索不是回答‘有没有’，而是强制回答‘最像的是哪些’。

这会把检索从“稀疏匹配问题”变成“排序问题”。

3）为什么低分命中也有用：我做的是“召回优先”的证据包，而不是“精确搜索结果”

在 vault 这种体系里，“低分命中”经常是：

• 稀有但相关的早期表达（你自己写的版本更老、措辞更散，但结构同源）

• 跨主题的桥接段落（语义上弱相关，但能触发新的结构链）

• LLM 的“证据触发器”：模型在多条弱证据之间更容易抽出共同结构（尤其后面还有 Gate / Evidence / Claim 的治理链路）

所以合理策略不是“设一个阈值把低分扔掉”，而是：

• 检索层：尽量召回（recall-first）

• 渲染/推断层：严格约束（evidence-first + gate）

换句话说：embedding 的低分命中，在我的体系里属于 “B-side 候选证据（可疑但可用）”，这个我会在慢慢后面全域解释的过程中慢慢把架构讲清楚。它的价值不在于“它自己就能证明什么”，而在于“它可能把某个结构簇拉回来”。

上一篇我就提到，即便只是做最基础的 embedding query，把与你当前开发问题或决策语境最接近的历史片段召回出来，本身就已经在对模型形成约束。它未必是硬规则、未必是显式的 schema 或 gate，但它构成了一种上下文层面的“软边界”——模型不再在完全无锚的语义空间里自由发散，而是在你过往表达、判断、结构习惯所形成的向量邻域中运作。对于开发过程中的具体问题、架构选择、命名方式、甚至取舍倾向，这种召回都会悄悄把模型的注意力拉回到你自己的语义轨道上。它不保证绝对正确，但至少提供方向；不消除噪声，但降低漂移。在缺乏强结构约束之前，这种基于 embedding 的上下文召回，本质上是一种最低成本的认知对齐机制——作为软约束，总比毫无锚点的生成要强得多。

一个典型的promotion流程：Sovereign_Log（人写知识池）→ 多次引用计数 → 关联聚类 → 生成可审计的 promotion proposal → 人工/审计门控 → 通过A I渲染成完整的合规文档进入 docs（宪法库 / IR）

一个完整的 promotion 流程，其实是一条从高熵行为到制度化结构的压缩路径：Sovereign_Log 作为人手写的知识池承载所有原始认知残影，随后通过多次引用计数捕捉真实的调用频率，再通过关联聚类识别结构之间的共现关系，进而生成可审计的 promotion proposal，经由人工与审计门控过滤噪声与偏差，最后才交由 AI 进行结构化渲染，转化为合规文档进入 docs（宪法库 / IR）。这条链路看似清晰，但每一步都隐含复杂问题：统计稳定性、身份一致性、聚类解释性、阈值设定、治理边界、语义压缩，任何一个环节失稳都会导致主线偏移。

之所以要做多次引用计数与关联聚类，并不是为了形式上的“数据驱动”，而是为了回到一个朴素而严厉的原则——统计你说的不如统计你做的。人在高频开发状态下，每天几百条 query，密集做笔记，连续决策，真实的认知重心不会体现在宣言里，而会体现在反复调用的片段中。身体是诚实的，路径是诚实的，被重复引用的结构几乎必然承载了真实的效用。一个被多次触发、跨场景调用、持续复现的结构，不可能只是偶然噪声。

因此，promotion 的真正目的并不是升级文档，而是从行为残影中提取认知主线。多次引用是重力，聚类是路径形状，proposal 是制度候选，Gate 是理性校准，AI 只是最后的语言压缩器。核心动机只有一个：在无数 micro-decision 的洪流中，把自己的道路主线抽取出来，使其从碎片化行动中凝结为可调度、可审计、可继承的结构。这才是最初的想法，也是整个系统存在的根本理由。

难点在哪？

真正的难点，不是“流程设计”，而是你试图把高熵的人类语言变成可追溯、可计算、可审计的结构单位时，所有隐含的不稳定性都会暴露出来。

首先是定位问题。人类的文字天然混乱，没有稳定边界，没有天然 ID。你在 Sovereign_Log 里写笔记，不可能一边思考一边给每个观点手动编号。就算你强行编号，那编号是属于段落、句子、子句、还是某个跨段逻辑单元？用句子的前半段当锚点？还是后半段？靠机器切分？机器分句算法是否稳定？一次版本修改，前面加一段话，所有后续段落位置都会偏移。粒度怎么选？过粗，多个观点混在一起；过细，语义被切碎。你面对的不是“索引问题”，而是“语义身份问题”——在没有天然 ID 的自然语言世界里，如何给一段思想一个不会随排版漂移的稳定身份？这一步如果不稳，后面所有引用计数、聚类分析都会变成沙滩上的建筑。

其次是关联聚类问题。你统计了引用次数，那只是“点”的强度。聚类意味着要判断哪些点构成一条路径。但标准是什么？是共现次数？时间邻近性？跨项目复用频率？语义相似度？如果靠 embedding 相似度，那是语义近似，不是调用行为；如果靠 join key 共现，那可能只是偶然邻接。你到底在聚什么？概念？论证模式？决策模板？如果没有清晰的聚类目标，算法只会给你一个数学结构，而不是认知结构。聚类的难点不在于算法复杂，而在于“你要识别的结构类型”是否被明确定义。

再往下，是模型介入的位置。完全硬编码肯定不行。你可以统计、排序、打分，但生成出来的 proposal 如果全是 JSON 拼接，缺乏语言连贯性和语义压缩能力，根本无法进入 docs 层成为制度文本。那要不要上模型？当然要。但在哪里上？如果模型太早介入，比如参与切块、参与身份判定、参与引用有效性判断，它就会污染可审计性。更关键的问题是：喂模型什么内容才算“有效引用”？是原始片段？还是带上下文的证据包？是否附带 TEXTSHA？是否附带 file_sha256？如何保证模型只能在已验证的证据集合内组织语言，而不能“补全”不存在的逻辑链？如何彻底杜绝模型在 proposal 中凭语感生成未被统计支持的结论？

这就形成了三个核心：

第一，语义身份的稳定性——如何在自然语言中构造不会漂移的引用锚点。

第二，结构聚类的可解释性——你到底在识别“什么类型的结构”。

第三，模型渲染的边界控制——模型只能压缩与组织，不能发明与扩展。

如果这三点没有被严格分层，promotion 就会变成一种“看起来很严谨”的自动化幻觉：统计不稳定、聚类不可解释、模型不可约束。你试图做的不是简单的文档升级，而是把真实的认知路径制度化。这件事难，不是因为代码多，而是因为试图在高熵语言与低熵制度之间建立一条可重复、可审计、可回放的压缩通道。

所以，这个项目最好得值得这个“票价”，值得我为他花费如此大的功夫。完全是因为我认为不去完成这个作为我工作的基础设施，我根本没办法Build up。

现在，在这篇文章，我只能大概讲讲我已经实现的架构和一些原理。大概脉络讲清楚，都是我试错之后剩下来成功的一些经验。就是给屏幕前考虑复现的程序员一个参考，也许能省你一些探索的时间。分三个部分。

第一个框：证据化全宇宙

首先要讲清楚，“证据化全宇宙”和“向量化”根本不是同一类工程。向量化解决的是语义相似度问题，本质是把文本映射到 embedding 空间，通过距离计算完成近邻搜索，它适合检索，但没有稳定身份、没有唯一键、不可审计、不可回放；而证据化全宇宙解决的是文本身份问题，它的目标不是“像不像”，而是“是否真实存在、是否可唯一定位、是否可稳定回溯、是否可进入制度层引用”。前者属于语义空间，连续、概率化；后者属于内容空间，离散、确定性，是一种内容寻址系统。你做的不是索引优化，而是语言到可验证实体的转化层，这是治理基础设施，而不是检索工具。

整条证据宇宙链路可以压缩为三层结构与一条运行主线。第一层由 build_evidence_registry.py 构建记录层（record），它扫描 Markdown 文本，按段落规范化切分，生成包含 ssa_e（doc_id 与 span_hash 等身份信息）、locator、preview 与统计字段的全量段落集合。record 是最大宇宙，是原始文本的结构化镜像，保留全部语义原材料。第二层由 build_evidence_core_from_registry_v1.py 构建核心层（core），在 record 基础上做去噪与唯一性约束，过滤模板标题、结构性噪声与无效片段，确保 (doc_id, span_text_hash) 唯一，形成可对齐、可 join 的稳定证据集合。core 不是为了阅读，而是为了制度对齐，它是语义世界进入治理世界之前的过滤层。第三层由 build_evidence_context_from_core_v1.py 构建上下文层（context），利用 core 的唯一键反查 record，补全 locator 与 preview，使每一个 core key 都具有可读映像与可回溯定位，从而让人工审计成为可能。

整条链路由 run_evidence_universe_v1.py 串联执行，按顺序生成 record、core、context，并依次调用 gate_evidence_core_boundary_v1.py 校验 core 的唯一性与结构形态，调用 gate_evidence_context_backref_boundary_v1.py 校验 context 必须能回溯至 core 且定位信息一致，必要时通过 audit_evidence_symbol_taxonomy_v1.py 做符号结构分布审计。这些 gate 与 audit 不是装饰，而是保证身份稳定、结构无漂移的边界控制层。

在此之上，向量检索层由 index_vault.py 生成语义索引，query_vault.py 产出 citations_pack_v0 供后续使用，但真正进入制度链路时，下游脚本（如 generate_promote_ref_ssae.py）会使用 context 进行 backref，把 locator 转换为稳定的 SSA-E 引用事件。向量层负责“找到可能相关的片段”，证据宇宙负责“把相关片段变成可制度引用的身份实体”。

因此，这张图的核心不是 pipeline，而是分层：record 是全量段落宇宙，core 是去噪且唯一的对齐宇宙，context 是 core 的可读映像宇宙，gate 是边界约束层，而向量检索只是上游辅助。向量解决检索问题，证据宇宙解决身份问题；向量属于语义层，证据宇宙属于治理层；向量给你相似度，证据宇宙给你确定性。没有证据宇宙，promotion 统计只能依赖 locator 或语义近似，无法抗编辑漂移；有了证据宇宙，你才真正构建了稳定的语言身份系统，使每一段思想都拥有可验证、可 join、可制度化的内容身份。这才是证据化全宇宙的真正作用与主路径。

即将遇到的坑

说到这里，就必须直面一个你我都绕不过去、而且已经反复踩坑的问题：定位漂移。你用什么做 key？路径？标题？段落号？字符范围？你会发现，不管你选哪个，在后续链路里总会丢掉一部分，或者对不上，或者回溯失败。我也在这里原地打转过很多次。最后得到的唯一结论是：解法也许只有“哈希身份优先”。想想这个星球上最强大的版本系统 Git，它给出的唯一启示就是——身份必须绑定内容，而不是绑定位置。

所谓“定位漂移”，本质根本不是漂移，而是你在拿“位置”当“身份”。locator（路径、heading、paragraph_index、char_range 等）天生只是渲染定位工具，而不是制度身份。一旦你在文档顶部加一行字，paragraph_index 全变；改一个标题，heading_path 变；移动文件，note_path 变；自动格式化，char_range 变。这些都不是 bug，而是自然语言文档的物理属性：它不保证稳定地址。于是你链路里的“丢失”就变成常态——A 侧引用带 locator，B 侧解析不到；citations pack 里的 snippet 在 evidence registry 里找不到；TEXTSHA 或 SSA-E 对不上，backref 掉一截；你为了修复又重新切块，结果 identity 再漂一次，循环补洞，永无止境。问题的核心只有一句话：身份在链路中不是硬约束，而是软信息，只要是软的，就一定会在某个阶段被丢失。

Git 的启示极其简单：content-addressing wins。Git 不靠“第几行”识别对象，而靠 canonical bytes 的哈希识别对象；路径只是树里的指针映射，真正的对象身份永远存放在内容地址里。这直接映射到你的证据宇宙：core key 必须是 (doc_id, span_text_hash)，locator 只能作为可读指针存在，任何 join 都不能使用位置字段作为主键。我现在已经走在这条路上——SSA-E / TEXTSHA 做 join key，paragraph_index 降级为渲染定位——但这还不够，它必须升级为硬规则：join key 只能是内容身份；任何引用事件必须携带 identity；canonicalization 必须在 hash 之前冻结且全链路一致。否则，身份不稳定，统计、聚类、promotion 都会被污染。

其实后面通常会跟着两个坑。第一是粒度问题：span 太粗，会把多个观点揉在一起，引用统计变脏；span 太细，句子级别的微小改动都会导致 hash 变化，聚类碎裂，主线抽取失稳。粒度决定了制度抽象的形态，这是结构层的张力。第二是模型污染问题：一旦模型介入渲染，它天然倾向于“补全”，把证据之间的空白用语义连起来，生成看似完整但未经统计支持的结论。所以在证据宇宙这个方块里，模型绝对不能参与身份生成或 key 推断；模型只能重排、压缩、引用已经存在的证据块，不能生成新的事实块，这就是“可证明引用闭包”（我其实在这里完全没有使用模型）。一旦允许模型扩展事实，整个可审计性就被破坏。

最终你要刻在系统边界上的原则其实只有三句话：身份先于语义；确定性先于可读性；门控先于渲染。只要这三条不动摇，定位漂移会被压缩到最小范围，身份丢失会变成显式错误，而不是隐性腐蚀。

第二个框：引用证据和计数

如果你按上一篇的设想，用一个 wrapper 把自己真实开发的项目流水线直接接到这个库上来，那么每天产生的海量 query 记录，最终就要落到一条“可被治理、可被统计、可被晋升”的管道里；而你图里这段所谓 B 侧数据管线，干的就是把“检索行为”从语义检索层抽出来，变成可以进入 promotion 系统的结构化事实：它把 Citation Packs 这种检索回包，转换成两类东西——一类是可计数、可聚类的 B 信号索引，另一类是可回溯、可审计的 Promote 引用事件，并最终汇总成下游提案与渲染要用的 QPG 快照。具体链路非常清晰：ingest_packs.py 负责吃掉 Citation Packs、提取命中键（hit_keys）并在需要时做 TEXTSHA→SSA-E 的适配，产出一个 run 作用域的 ingest 索引，让“你今天引用了什么”成为可统计对象；generate_promote_ref_ssae.py 则把 Citation Packs 里的 locator 做 backref，尽可能还原成稳定的 SSA-E 引用事件，输出 promote events（并兼容 legacy 字段），让“这次引用能否被制度化引用”成为可审计事实；最后 count_qpg.py 读取 ingest 索引（并可结合 core registry 与 promote ledger），对 B 信号做计数、缺失与覆盖分析，产出 qpg_snapshot.json 作为后续聚类、提案生成与 AI 渲染的统一入口。用一句话记：Citation Packs 先被 ingest_packs.py 变成“可计数的行为索引”，再被 generate_promote_ref_ssae.py 变成“可审计的引用事件”，最后由 count_qpg.py 压缩成“可下游消费的 QPG 快照”，从而把你每天真实的检索与引用行为，转化为能够驱动主线抽取与晋升决策的制度级数据流。

这条我直接给你个快照的例子给你看：

  "dedup_rules": {
    "B_dedup": "(run_id, SSA-E)"
  },
  "inputs": {
    "core_keyset": "_system/artifacts/derived/evidence_registry/core/v1/evidence_core.jsonl",
    "core_present": false,
    "ingest_index": "_system/artifacts/derived/promote_eval/v0/qpg_ingest_index.json",
    "promote_ledger_present": false
  },
  "items": [
    {
      "counts": {
        "B_count": 6
      },
      "risk": {
        "b_distinct_runs": 6,
        "b_sparse": false,
        "coverage_core": false
      },
      "score": {
        "primary": 6
      },
      "sources": {
        "B_runs": [
          "20260204T021324Z_query_vault_d871c310f7",
          "20260204T165509Z_query_vault_2f20fafd71",
          "20260204T181147Z_query_vault_cccfa2209c",
          "20260204T182015Z_query_vault_61fb5cf34b",
          "20260209T195916Z_query_vault_d3f4ea4058",
          "20260209T200152Z_query_vault_2002a3ffa1"
        ],
        "caps": {
          "B_truncated": false,
          "cap": 50
        }
      },
      "ssa_e": {
        "doc_id": "SL-2026-01-31-0001-Schema-Version-Is-Identity-Not-Inference",
        "span_text_hash": "ac14a502c77fc6194b7af260944cdeda839550cfbc609bdb7fcb028edfc0e5f4"
      }
    },

一个可审计的统计快照：每个条目就是一颗“候选证据原子”，带着严格的身份（SSA-E）、可复现的行为计数（B_count）、可解释的风险特征（distinct runs / sparse / coverage_core），以及可回放的来源 run_id 列表。模型在这里的角色不该是“推理真相”，而只能是把这份统计事实翻译成合规语言：把“被反复引用的身份实体”组织成 proposal 文档里的 claims/notes/thresholds，而不是从语义里发明新内容。

就你这段快照字段结构而言，它已经非常接近“不可胡诌渲染”的理想输入，因为它把模型能用来胡说的空间压到最小：

• dedup_rules.B_dedup = (run_id, SSA-E) 明确告诉模型计数口径是什么，避免它把重复引用误当成多证据源；

• inputs.core_present / promote_ledger_present 这类布尔位直接暴露“上下游是否可用”，意味着渲染层必须在文案里显式承认缺失（比如 coverage_core=false 就不能写“已进入 core 覆盖”）；

• items[*].ssa_e 给出硬身份（doc_id + span_text_hash），这就是“引用只能指向身份”的约束；

• counts.B_count + sources.B_runs 让“统计你做了什么”完全可回放，模型只能把 6 次、6 个 run 说成 6 次、6 个 run；

• risk.coverage_core=false 这种字段是关键的“禁止推断钉子”，它强迫模型承认：这条虽然高频，但尚未被 core 覆盖（或 core_keyset 未加载），所以它只能被表述为“高频候选”，不能被表述为“已确认为可对齐证据”。

如果你把它视作渲染输入（Model Feed），那么“模型应该被允许输出什么”其实可以被严格限定成三类句子：

1. 事实句：基于字段的直接陈述（例如：该 SSA-E 在 B 侧被引用 6 次，来自 6 个 distinct runs）。

2. 风险句：基于 risk 字段的直接陈述（例如：core coverage 缺失，因此当前仅能作为候选，需补齐 core/context backref）。

3. 动作句：基于系统规则的下一步建议，但必须显式标注为“操作建议/待验证”，且引用触发条件来自字段（例如：若要进入 proposal，需要 core_present=true 或 coverage_core=true 才允许晋升为强 claim）。

反过来，“模型绝对不允许做的事”也可以从这份快照反推出来：任何关于 span 内容的解释、任何“这段话意味着什么”的扩写、任何未在字段中出现的阈值满足性断言（例如把 coverage_core=false 写成“已覆盖”）都应被视为越权。换句话说，你现在这个快照就是典型的 强结构、弱模型：让模型只在结构边界内做语言组织，而把真实身份、计数口径、缺失状态都锁死在输入里。

顺便点一下你这条样例 item 的“制度含义”：它几乎就是一个天然的 proposal seed——B_count=6 且 b_distinct_runs=6表示这不是单次会话的偶然命中，而是跨 run 的反复调用；但 coverage_core=false 又明确告诉你：这条即便高频，也还不能直接晋升为“可对齐的制度证据”，必须先补齐 core/context 覆盖或 backref 完整性，否则渲染出来也只能是“高频候选条目”，不能是“可证据化结论”。

好，还没完，既不完美，也没完。我这是想的美，中间还有大量的小bug没解决。我们先继续往下说，因为下面这个模块就是渲染模块了，要上LLM模型 (GPT-4o-mini）。从快照出来以后，我们进入渲染层：

第三个框：模型渲染

我们说渲染模块，真正的核心问题只有一个：如何在保证“强结构，弱模型”的前提下，让文本既可读、可聚类、可审核，又绝不允许模型胡乱编写或擅自补全。如果模型可以凭语感扩展事实、补齐因果、推断阈值，那么前面所有证据化、计数、门控的努力都会被破坏；但如果完全不用模型，输出又会变成生硬的结构拼接，缺乏人类可读性与治理表达能力。因此，关键不在于“用不用模型”，而在于把模型严格限制在渲染边界之内——它只能组织、压缩、重排已经存在的结构化事实，不能创造任何新的事实单元。

这条下游链路本质上是在做一次逐层压缩：把“可审计的计数快照”转化为“可阅读、可门控、可晋升的治理文本”。首先，enrich_qpg_snapshot_from_context_v1.py 以 (doc_id, span_text_hash) 为唯一硬键，将 qpg_snapshot.json 中的纯计数条目与 context.jsonl 中的定位与 preview 做确定性回填，生成 qpg_snapshot_enriched.json。这一阶段的意义，是把抽象的统计对象变成“可审阅的证据卡”，并显式标注缺失与回溯状态，保证身份与上下文不发生漂移。随后，render_snapshot_markdown_v1.py 将 enriched 快照渲染为面向人类的 snapshot.md，输出排名板、聚类视图与风险提示等阅读结构；在这一阶段，LLM 可以参与语言层面的压缩与措辞优化，但必须严格绑定输入字段，不得引入任何未出现在快照或 context 中的 claim、推断或判断。最后，create_phase6_proposal_v1.py 以渲染产物或结构化快照为真源，生成 Phase6 proposal，将候选条目组织为 claims 与 actions，同时强制所有引用的 join key 只能来自快照中的 SSA-E 或 TEXTSHA，从而把“表达流畅性”与“证据准确性”彻底解耦。

这套机制的目标不是让模型更强，而是让模型更受限。模型负责可读性与表达压缩，结构负责身份、计数、风险与门控边界；模型只能在锁死的证据闭包内写作，不能扩展事实边界。正是在这种“被限制的写作”之下，聚类与可读性得以保留，而胡诌与补全被压制为机制上不可发生的行为。这才是真正意义上的“强结构，弱模型”。

这个中间使用的代码机制和门控，我们暂时先不谈，我给你看最后的生成物：

---
schema_version: promote_qpg.phase6_proposal/v1
run_id: 20260214T_PHASE6_0001
generated_at: 2026-02-14T16:58:53+00:00
source_sha256: d4ba9e75fe1027b699862733cecceb6095ed6c23772c200a7d372b5ca5be4213
bundle_id: BND-UNKNOWN
doc_path: docs/UNKNOWN.md
human_label: UNKNOWN.md
---

# Phase 6 — Proposal (Claims-first)

## Decision Summary
The proposal addresses governance risks related to schema versioning and identity declaration.

## Claims

### C-0001
- kind: `normative`
- threshold_pass: `True`
- support_join_keys: (SL-2026-01-31-0001-Schema-Version-Is-Identity-Not-Inference,ac14a502c77f…)
- text: The `schema_version` is an identity declaration, not something the system may infer from time ordering, trace continuity, file location, or heuristics.
- notes: Supported by evidence with signal strength 6.

### C-0002
- kind: `normative`
- threshold_pass: `True`
- support_join_keys: (04d4fac5b440b37865e7f1a6ae7d49bc480364c96ce2409ec4a06c1ae8799013,9345e730b7b9…)
- text: Enforcing schema_version and identity rules is critical for maintaining system integrity.
- notes: Supported by evidence with signal strength 5.

### C-0003
- kind: `normative`
- threshold_pass: `True`
- support_join_keys: (01c1d8a24c98deb156506116b639b13e8d9cea8eb89b589b1a1243374dbb8abc,2bd5f52203b3…)
- text: Tool results are recorded as standalone facts in the ledger, independent of execution traces.
- notes: Supported by evidence with signal strength 4.

### C-0004
- kind: `normative`
- threshold_pass: `False`
- support_join_keys: (0b52473ae4937859cea3de3ef868b622a9766f0447a307a39145e107808f8f23,1723e33a0cac…)
- text: Releases become replayable and auditable only when inscribed in the ledger.
- notes: Evidence indicates missing context signals, which may affect the reliability of this claim.

## Actions

### A-0001
- kind: `docs_patch_intent`
- target_doc: `docs/UNKNOWN.md`
- support_join_keys: (04d4fac5b440b37865e7f1a6ae7d49bc480364c96ce2409ec4a06c1ae8799013,9345e730b7b9…)
- text: Add clarifications regarding the importance of schema_version and identity rules.

## Appendix

### themes
```json
[
  "Governance risks related to schema versioning and identity declaration."
]

ranked_evidence

[
  {
    "rank": 1,
    "join_key_pair": "(SL-2026-01-31-0001-Schema-Version-Is-Identity-Not-Inference,ac14a502c77f…)",
    "signal_strength": 6,
    "risk_flags": [
      "coverage_core"
    ]
  }
]

risk_heatmap

{
  "missing_context": {
    "count": 5,
    "details": [
      {
        "join_key_pair": "(1e8fe760fab715b983ffc3bce6d18e91eed9096e36c7f96b643d702382048e9f,bb2a267d166b…)",
        "signal_strength": 4
      }
    ]
  }
}

warnings_readable

"Missing context signals: 5"

从格式与结构层面看，这份 Phase6 的最终生成物已经满足我的最小要求：它以明确的 schema_version/run_id/source_sha256 作为可回放的身份外壳，把提案内容拆分为可机器处理的 Claims/Actions/Appendix 三段，并且每条 claim 都具备可审计字段（kind/threshold_pass/support_join_keys/text/notes），其中 support_join_keys 形成了对证据身份的硬绑定，threshold_pass 将门控结果显式化，而附录又保留了可回溯的主题、证据排名、风险热图与可读 warnings，确保提案既能被人阅读，也能被机器复核。至于中间链路如何富化、如何渲染、如何 gate，这里先不展开；我现在只给你看最终产物，因为它最直接地定义了我们“喂给模型渲染”和“最终进入治理流程”的输入输出形态，也证明这条链路在形式上已经具备可晋升到 docs（宪法层 / IR）的雏形。

下一步，就是把这些反复击中，我在大量的开发中积累的重要经验claims插入docs宪法层。使用一种docs_patch_plan：明确目标文档、锚点位置、标准化插入块、冲突策略与证据来源，由人最终签字确认后再应用。插入位置的准确性必须依赖稳定的锚点协议（显式结构锚点优先，其次标题路径，最后内容哈希兜底），而不是语义推断；插入内容必须是带身份与去重键的标准块，而不是自由文本。这个可能下一个阶段了。

目前这条链路中间仍然存在大量问题，最核心的是：信息在层层转换中不断丢失，最后真正能进入晋升流程的内容只剩下很小一部分。这不是某一个脚本的小 bug，这个就是我上面再说的，结构层面的开放边界问题。

这件事根本不是多开几个窗口、多写几段代码就能解决的。如果边界定义不清晰，没有统一的主键体系和稳定的语义约束能力，你不可能靠“窗口操作”拼出一个真正稳定的系统。问题出在结构层，而不是算力层。向量化之后，搜索命中的字段往往无法稳定定位；任何基于段落编号的 ID 都会随着文本微调而漂移；段落多一个字、少一个字，哈希就改变；字段稍作重排，引用立即失效。你若完全冻结字段、严格哈希化，确实能获得完美的定位能力，但随之而来的问题是：如何聚类？如何泛化？如何把相似却不完全相同的内容归并为一个结构单元？而一旦引入模型对语言进行润色和补全，让文本变得可读、连贯、可传播，你又必须接受模型为了叙事顺畅而自动填补逻辑空隙，这些补全往往没有真实证据来源，语义连贯性上升的同时，证据确定性却在下降。反过来，如果完全不用模型，纯靠硬编码与结构输出，内容可以被验证，却几乎不可读、不可传播，也难以形成认知影响。

因此，这根本不是在解一个算法题，而是在同时约束三种天然互相拉扯的能力：可定位性、可聚类性与可读性。定位需要冻结——哈希、稳定 ID、不可变锚点；优点是可验证、可审计，代价是极度脆弱，稍有变化就失效。聚类需要相似——可变、可泛化、可合并；优点是能发现结构吸引子，代价是边界模糊、主键漂移。可读性需要语言——模型渲染、叙述组织；优点是可理解、可传播，代价是引入幻觉与无根据补全。任何一项被拉满，另外两项都会坍塌：强调哈希定位，聚类能力下降、语言僵化；强调相似聚类，定位失真、锚点不稳；强调可读性，证据被稀释、主键被污染。

所以这不是“技术不够”的问题，而是一个结构三体问题。真正需要设计的不是某个更聪明的算法，而是一种明确分层的机制：底层冻结（Registry / SSA-E 主键层），中层可变（聚类与相似空间），表层可读（模型渲染与表达层）。三层必须清晰分离，职责边界明确，不能混用、不能跨层偷渡。否则系统会在开放边界中持续漂移，最终只剩下极少数“安全可落盘”的残片，而整体结构无法稳定成长。

灵魂提问与总结

直接向量化 + 模型（典型 RAG）当然是完全可行的。我从来没有否认这一点。它高效、实用、工程成本低，如果目标只是做一个问答系统，它几乎是性价比最高的选择。问题不在“行不行”，而在“你想要什么”。

我个人不想从一个说话机跳到另一个说话机。对我来说，如果系统的核心只是“输入问题 → 输出语言”，那意义不大。那只是换了一种更高级的表达外包方式，而不是结构能力的增长。所以我才走这条更重、更慢、更折磨人的路线。但我从未说这条路线一定比典型 RAG 更好。它不是更好，它只是更符合我当前的目标和偏好。

如果你的目标仅仅是构建一个问答系统，或者一个知识助手，那么真的不要走我这条路。它的复杂度、维护成本、结构设计负担，都远远超出必要。值不回票价。

这本质上是一个个人选择的问题，是 taste 的问题。你选择优化什么：速度、可用性、可审计性、可晋升性、结构稳定性？不同的目标，会自然导向不同的架构。

至于更深一层的问题——个人的 taste 是否可以在这个知识库的基石上被系统性解决？是否可以通过结构化主键、证据链、晋升机制，慢慢收敛成一种稳定的决策方向？老实说，我现在还没有答案。我在搭这个底座，是希望它至少提供一种可能：让 taste 不再只是模糊的直觉，而是能被回放、被观察、被约束。但它是否真的能承载那种“方向性压缩”，目前我还不能保证。

Notes have always been one of the most important productivity tools for programmers. Almost every generation of engineers has tried—based on their own workflow—to build or modify a personal note system: from plain text files and wikis to Word, Evernote, Notion. At the core, they’ve all been trying to solve the same problem: how to preserve usable thinking outcomes in a high-intensity information-processing environment. But the reality is that note systems have never been good enough—especially for people who need to process large volumes of text, code, and decisions every day.

For the past few years, I used Notion as my primary note tool. A common pattern was to open a table: each row had a timestamp, links, and context. When debugging, I’d mark items with a 🐛 icon and keep stuffing clues, ideas, logs, and code into it—until one day I worked almost twelve hours straight, looked up, and realized I had produced close to two hundred records in a single day. Each Notion “record” is essentially an infinitely expandable page, not a cell like in Excel. Even if each page is only two to three thousand words, two hundred pages is already around 400,000 words—far beyond what any human can read, understand, and digest in a day. And this wasn’t a one-time extreme case. It gradually became the norm.

Against this backdrop, in the last few weeks I slipped into a strange state: lots of things to do, but progress was slow; I started subconsciously avoiding work; my sleep kept extending. Then the East Coast got hit by continuous heavy snow. I was stuck at home for a few days, then went out to ski for a few days. On the surface it looked like procrastination or escapism, but what I actually felt was deep cognitive fatigue. Meanwhile, large language models became absurdly powerful—code, documents, proposals could be generated almost instantly. But this capability didn’t make me more efficient or clearer. Instead it triggered intense frustration, because I realized it wasn’t just me. After talking with friends, we all seemed to be experiencing the same kind of overload: once personal capability is amplified by tools to a certain level, what follows isn’t liberation—it’s a more severe backlash.

The industrial language production machine

Looking back, the problem concentrates in three areas. First, the scale of generated information and text has already exceeded human physiological limits, regardless of individual skill. Second, generation is too fast—so fast that you can’t even remember what you just read. The LLM keeps answering, keeps expanding, keeps offering paths, but it never gives a “stop here” signal. Third—and most fatal—is implicit drift: your state depends entirely on maintaining the chat window; windows accumulate; a few days later you revisit code from a few days ago and can no longer reconstruct the context. The same concept, script, and index keeps drifting in names, paths, and IDs—differences like vault_index, index_vault, inventory_index pile up. A few weeks later, when you look at the whole project, what remains is a feeling of total loss of control.

During the days I was trapped by the snow, I kept thinking about this and gradually realized it wasn’t a personal time-management problem—it was an inevitable outcome of the mechanism. An LLM is essentially a zero-shot universe: it can generate content at near-zero cost, it doesn’t get tired, it doesn’t hesitate, and it never makes the decision “is it worth continuing.” Prompts are only soft constraints; there is no hard shutdown condition. It’s an industrial machine continuously producing language and symbols, while the human brain doesn’t have the same capacity. Drift isn’t accidental—it’s the inevitable product of this mechanism. Extending context length doesn’t solve it, because the model is always just predicting the next token; if it can’t find the most correct answer, it guesses one. More importantly, the whole process has no accountable actor. Hundreds or thousands of prompts per day strongly depend on the local context at the moment; afterwards it’s nearly impossible to reproduce, and impossible to hold anyone responsible.

This is a governance problem

In this situation, I started to realize the problem isn’t “I didn’t remember enough.” In this era, continuing to rely on the traditional assumption of note-taking—“write more and it’ll be useful someday”—is itself unsustainable. Notion isn’t lacking search. But when I truly need to solve a concrete problem and trace back my past thinking, search often returns hundreds or thousands of results, many of which conflict with each other, lack context, or are temporally misaligned. They’re almost impossible to use directly. Search doesn’t reduce cognitive load—it amplifies it.

And in this context, after several days of continuous development in this repo, I once again tried to rebuild my recording system. I’ve tried many times before; most attempts ended in failure. But this time, something finally felt “on track”—at least enough to write down and share. The key isn’t that I found a “better tool.” The key is that I realized this isn’t fundamentally a tool problem. At this stage, humans are inevitably hitting biological and cognitive constraints. Yes, I do need a system that fits my personal workflow better. But more importantly, attention has to return to the real core: this isn’t about notes, or programming, or a one-off engineering fix with a single app or library. The core is one thing only: governance of knowledge.

This is a governance problem.

What does “governance of knowledge” mean? At a large scale, almost all truly difficult problems in human society are governance problems. Politics is governance: how a state is governed. Law is governance: how legislation, judiciary, and enforcement are divided and constrained. A constitution is also governance: not just writing it down, but how it is interpreted, how it is obeyed, and how you ensure it is truly obeyed. Scale down: team management, institutional design, process constraints—these are also governance problems, not tool problems. Governance is never about “do we have information” or “can we access it,” but about what is recognized as valid, what judgments carry authority, what states can enter long-term memory, and what must be restricted, frozen, or deprecated.

At the personal level, the real difficulty of “knowledge management” is exactly here: not lack of information, not weak search, but the absence of a mechanism that can adjudicate, constrain, and take responsibility. That’s why countless programmers have repeatedly attempted to solve this: from early personal knowledge bases and tagging systems, to backlinks and graphs, to vector search, to Obsidian, semantic search plugins, and AI assistants. They solve “how to find content,” “how to link content,” “how to generate content.” But they almost all assume one premise: once content is written down, it is inherently valuable. As long as it can be stored and searched, the system is “successful.” Solutions like this—and open-source projects—are everywhere. I’ve borrowed from them too. I also store everything as .md files; an Obsidian vault can read it. But this is not the point!

In an era when information generation was far lower than today, “if you can find it, it’s a win.” In an era where content can explode at near-zero cost, that premise has collapsed. What’s missing is not a smarter search algorithm or a more complex representation. What’s missing is a governance structure that can answer: what can be recognized as knowledge, what is merely process noise, what must be accountable, what must be reproducible, and what is not allowed to drift silently.

So I’ll talk about what I’m trying now. This repo is still new, but I strongly feel the direction is right. If you share the same pain, maybe this can inspire you.

A Sovereign Log: simple code, expensive writes, no LLM integration (yet) — to hold my core cognition steady

This system is not designed for high-frequency recording—quite the opposite. It deliberately makes writing expensive, slow, and thought-requiring. The implementation stays as simple as possible at the code level. It does not rely on complex systems, and it does not directly integrate an LLM, because once you integrate it, zero-cost generation immediately erodes its nature as an “adjudication record.” At this stage it’s all hard-coded. Even without a UI, it has already solved many real problems for me.

.
├── _system
├── docs
├── inbox
├── requirements
├── sovereign_log
├── templates
└── tools

There are two text libraries made of .md files: sovereign_log and docs.

Sovereign_Log

Nothing started from a grand system. I initially built an extremely small and disciplined vault. Its starting point was no different from an ordinary Obsidian vault. If you look at its graph, there’s almost no structural feature: no intentional backlink structure, no topic network, no pursuit of connection density. The only real difference is quantity—very small. This is a constraint I deliberately maintain. In this vault, every piece is not a draft, not “write first and see later,” but the result of repeated refinement. I iterate with AI in multiple rounds, compressing expression, correcting boundaries, clarifying meaning. Early on I wrote mainly in English, adding some Chinese translation as a semantic validation tool to make sure I truly understood what I wrote. As the system matures, it will likely become fully English. At this stage, Sovereign_Log is a highly refined personal knowledge set under full personal sovereignty. The principle is simple: don’t write casually, don’t treat it as drafts, and quantity is not the goal—precision is. Sometimes a full day of thinking, reasoning, and alignment results in only one or two notes. That is intentional entropy control. You must maintain this discipline, or it becomes the same as every other note system where you dump everything in.

Doc

Doc still looks like “notes,” but it is not a natural extension of Sovereign_Log. It is a clear promotion step. Content in Doc is not just “more formal writing”—it is promoted text in an IR state, somewhere between narrative and executable code. It is not code yet, but it no longer allows free-form prose. When designing this library, I introduced the counterintuitive principle of “expensiveness” to resist the fact that LLMs generate text and code too fast and too much. What enters the core must be expensive institutionally—not emotionally or stylistically. This expensiveness has three layers.

First: format-expensive. Doc is not free text. Anything that enters must conform to a fixed structure and pass machine-checkable format audits. The goal is not aesthetics; it is that the text is parseable, indexable, auditable, and constrainable. A format-invalid doc is simply not eligible for this layer.

Second: process-expensive. Content cannot enter Doc immediately. It must first exist in Sovereign_Log, accumulate time, be repeatedly searched and referenced in real use, be converted into code or decisions, and demonstrate actual behavioral impact. Only then does it become a candidate, and only after explicit authorization is it promoted into Doc. This matters even more once you introduce shared team knowledge: it blocks random ideas, models, or impulses from polluting the core layer. Doc is a scarce resource—not a place to store “cleaned up notes.”

Third (most important right now): semantic-expensive. My requirement for Doc is not just clarity or coherence. Semantics must meet the bar: rules cannot contradict each other; implicit conflicts are not allowed; responsibilities and boundaries cannot be vague; every declaration must have the potential to generate binding code. Many large document repositories fail not because they lack information, but because they accumulate semantic mess: drifting definitions, conflicting clauses, and ultimately no path to executable constraints. Doc aims at the opposite: every line is a potential system constraint; every semantic unit is a future source of code. That means semantics must also be auditable and machine-intervenable.

├── docs
│   ├── decisions
│   ├── governance
│   │   ├── CLAIM-AUTHORING-STYLE-V0-1.md
│   │   ├── EVIDENCE_SUGGEST_AUDIT.md
│   │   ├── RPT-2026-01-26-RUNTIME_ENV_GOVERNANCE.md
│   │   ├── SD-0007_RUNTIME_ENV_FREEZE.md
│   │   ├── SD-0008_INDEX_CONSOLIDATION.md
│   │   ├── SD-0009_DOC_IR_SPEC_v0.md
│   │   ├── SD-0010 — Normative Boundary & Semantic Consistency Rules
│   │   ├── SD-0011_ID_Taxonomy_and_Identity_Ledger.md
│   │   └── SD-0012 — Observability Causal Structure & Span Identity
│   ├── invariants
│   │   ├── INV_CATALOG_v0.md
│   │   ├── INV_DOC_IR_BOOTSTRAP_v0.md
│   │   └── INV_INDEX_ROOTS_0001.md
│   ├── Machine-Checkable Invariants.md
│   ├── runs
│   ├── SD-0001-System-Constitution.md
│   ├── SD-0002-Derived-Artifact-Path-Freeze.md
│   ├── Sovereign Log — Write Protocol v1.0.md
│   ├── stage_contracts
│   │   └── PRE_STAGE_5.md
│   └── taxonomy
│       ├── INDEX_TYPES.md
│       └── TDES.md

At this stage, my system is not integrated with any LLM, at least not at this layer. All constraints, screening, and promotion logic are implemented in code. If you’re a programmer reading this and you find the method useful, the technical implementation is not complex—it is straightforward engineering. I won’t expand on the code here; I’ll use one concrete example to explain what I mean by “semantic expensiveness.”

For semantic screening, every audit run produces two reports: a JSON report for machine consumption and a Markdown report for humans. Below is a summary of one semantic audit run.

The audit is AUDITDOCSEMANTIC — 20260130T205405Zdocsemantic_audit. The result is ok: False, meaning it fails institutionally. The system scanned the docs directory and extracted 77 claims, using embedding similarity and heuristic semantic pattern matching (model: all-MiniLM-L6-v2, threshold 0.92, top-k 8, max pairs 200). Modality/target/predicate inference is still heuristic in v0.1 and will later be promoted into explicit structured claim tags. Duplicates are warnings by default, but here I upgraded conflicts to errors—meaning they must be resolved.

The key violation is SEM-CNF-001, a semantic conflict. It is not vague; it is a modality conflict: across two documents, on the same (target, predicate) key (here ('GLOBAL','evidence')), the system sees mutually contradictory normative statements—one must, one must_not. The conflict is precisely localized to two concrete claims: SD-0011#C-0004 vs DOC-EVIDENCE-SUGGEST-AUDIT-V1#C-0003. That means at the Doc layer, the system is told “this must happen” and “this must not happen” with the same scope.

This is unacceptable. Once such semantics enters the core Doc layer, any attempt to generate binding code, policy, or runtime constraints immediately loses determinism. The audit therefore forces a choice: resolve by priority (e.g., INV > SD > taxonomy) or explicitly supersede one claim so it becomes institutionally inactive. This is about which rule continues to survive in the system.

To me, this is “semantic expensiveness”: not relying on human memory of “something seems inconsistent,” but making the system refuse non-closed, inconsistent, non-executable semantics at the Doc layer. That is what allows Doc to become more than a serious-looking document collection—it becomes eligible to constrain future code and system behavior.

AUDITDOCSEMANTIC — 20260130T205405Zdocsemantic_audit
ok: False
violations: 1
Meta
{
  "docs_dir": "docs",
  "claims_count": 77,
  "dup_threshold": 0.92,
  "topk": 8,
  "max_pairs": 200,
  "dup_severity": "warn",
  "model": "sentence-transformers/all-MiniLM-L6-v2",
  "notes": [
    "v0.1 modality/target/predicate inference is heuristic; promote to structured claim tags later.",
    "duplicates are warnings by default; set --dup_severity error to hard-enforce."
  ]
}
Violations
1. SEM-CNF-001 (error)

path: docs/governance/SD-0011_ID_Taxonomy_and_Identity_Ledger.md | docs/governance/EVIDENCE_SUGGEST_AUDIT.md
message: Modality conflict (must vs must_not) on (target,predicate)=('GLOBAL','evidence'): SD-0011#C-0004 vs DOC-EVIDENCE-SUGGEST-AUDIT-V1#C-0003
hint: Resolve via priority (INV > SD > TAXONOMY ...) or supersede one of the conflicting claims.
meta: 46502865b8712493e52dffd4a6b6871cd994c162f900ea8e6e7a8c3ebbcb5873

How it’s implemented

Technically, this mechanism does not require an LLM or “intelligent understanding.” The core idea is to compress document semantics into a set of structured elements that are computable, comparable, and fail-able, then audit them with deterministic rules. The system can be decomposed into independent layers; you can adopt or replace any layer without breaking the overall approach.

Step one is introducing declarative semantic units: documents are no longer treated as a single block of natural language, but must explicitly mark minimal governed units—stable numbered claims. You do not need complex parsing; a simple, robust textual pattern is enough. The key is not parsing power but forcing the author to choose: “this sentence is subject to governance.”

Step two is discretizing modality: instead of understanding everything, the system only cares about normative posture—must, must not, allow, forbid, or unknown—implemented via a deterministic rule table. This turns conflict detection into a finite-state problem, not a language understanding problem.

Step three is anchoring the target: to avoid all rules interfering globally, each claim should map to a stable target key (path prefix, resource name, explicit scope marker). Claims without anchors fall back to GLOBAL and thus incur higher conflict risk—this is a deliberate design pressure. GLOBAL creates endless false positives. In practice most claims are domain-specific; you rarely mean “this applies to the whole system.”

Step four is a coarse predicate classification to avoid false conflicts: you do not need a full ontology; a small extensible predicate enum (placement, authority, evidence, admission, index, …) is enough to reduce unrelated collisions.

After these four steps, each claim compresses to (modality, target, predicate) and becomes auditable by deterministic rules. Conflict detection becomes simple: on the same (target, predicate), do mutually exclusive modalities co-exist (must vs must_not, allow vs forbid)? If yes, fail immediately with precise claim-level localization. You can optionally add near-duplicate detection via embeddings as “governance hygiene” rather than a hard constraint.

Audit output should be machine-first: structured results for automation, human-readable reports for review. Crucially, audits must be able to fail and propagate that failure via exit codes/status signals—otherwise governance never truly enters engineering reality.

Why not integrate an LLM? I will integrate it later, but right now I need a foundation that is completely disconnected from the model. By this point the reason should be clear: history and governance must be borne by deterministic mechanisms; models can be advisors, not judges. Failure conditions must be stable; system boundaries must be clear. This already makes the whole process feel calmer.

Is hard-coding almighty problem-solver? Of course not. It cannot cover complex semantics. Keywords, rule tables, and predicate enums are low-resolution cognitive compression: they don’t understand metaphor, context, irony, or adapt automatically to new expression. Hard-coding looks dumb, slow, conservative. Each new predicate and rule change requires human judgment. It feels inefficient early on. But I want that “slowness”—it is friction by design, a safety mechanism against runaway generation. In an era where you can generate a hundred rules in one second, slowness itself becomes a safety feature. It forces the author to pay real cognitive cost before something enters the core layer. This is also a mental trap for programmers: it’s easy to detach and think you’re not part of the system mechanism. But in real projects, you are. You must be constrained too.

The core is Vault Index and Query

Let’s pause the big picture here. The remaining “details” (derived-layer storage, isolation, tool/templates, report lifecycle/cleanup) are huge, but technically not difficult. They’re mostly engineering hygiene. Once you have clear boundaries (Truth / Decision / Evidence / Derived) and strict write-path constraints, implementation is straightforward. The harder part is institutional consistency and long-term maintainability.

What I really want to show is my vault_indexer: it’s not “better search,” it’s an indexing mechanism that turns a note system into an evidence substrate. Most note apps will end up with “semantic retrieval + chunking.” But what determines long-term value isn’t retrieval itself; it’s how you organize evidence chunks, how you make them citable/reproducible/auditable, and most importantly: what layer the index belongs to (Truth or Derived).

I strictly treat the index as Derived: it never has “truth authority.” Its job is to compile text assets in docs/ and sovereign_log/ into retrieval-oriented intermediate artifacts: stable chunks (usually paragraph-level), stable IDs (chunk_id), source path and position, and content hashes/digests. Then you embed chunks, build a vector index (FAISS or similar), and query in natural language to retrieve evidence chunks. “Evidence” here is not “related text,” but an object with citation structure: each chunk can be precisely referenced, copied into evidence packs, reused by toolchains, and even required by audit systems (“your output must cite these chunk_ids”).

That explains why I don’t use LLMs as “writing machines” here, but as the best possible query operator. The LLM’s strength isn’t generation—it’s decomposing a vague question into searchable subquestions, constructing effective queries, structuring summaries based on retrieved evidence, and mapping those summaries back to development actions (which file to modify, which invariant to add, which claim to patch, which diff to write). Once you have a stable information substrate—core principles, boundaries, constraints, historical responsibility frozen in Doc/Sovereign_Log—the best use of an LLM is evidence-driven collaboration: query first, retrieve evidence packs (JSON/MD), then drive decisions and code from those packs, rather than letting the model hallucinate from memory.

This is structurally different from Obsidian plugins focused on “search.” Most plugins optimize UI speed: match → open note → human judge. They rarely solve: do hits have stable citations? can results be reproduced in CI/audit? will retrieved text be mistaken as authoritative? can you form a loop of “question → evidence → decision → code → write back evidence”? My vault_indexer turns retrieval output into versionable, reusable intermediate artifacts (packs/reports/audits) and explicitly locates them in the Derived layer: rebuildable, replaceable, cleanable—but never allowed to contaminate Truth/Doc authority.

In short: many plugins treat search as a reading entry; I treat indexing as a development input. The former optimizes “finding notes,” the latter optimizes turning notes into engineering evidence so LLMs act as “evidence analyzers + query compilers.” This is why, once your system substrate stabilizes, retrieval stops being a nice-to-have and becomes a core engine: you’re not “writing more notes,” you’re using retrieval to feed past constraints and evidence back into present decisions and code.

No more talk—here is evidence.

We start from a real query_vault result. One premise: this system is still early; it doesn’t become magical overnight. It needs long-term use, real projects, and continuous maintenance. Early on, scores won’t be very high. In my vault, a 0.7 hit is already “good”—worth careful reading. Index quality depends on what you put in: real development, real rules, validated high-quality content, and continuous maintenance. Over time: the more you use it, the better it gets, and the more it reduces mental load. That’s what a real second brain looks like.

A query_vault run is a reproducible retrieval object: it doesn’t “answer,” it lists candidate evidence chunks. Key fields: run_id, query, model, and chunk-level results. Each result has stable identity (chunk_id), precise location, content hash, mtime, score (ranking signal only), and a preview snippet (not the full evidence).

The key is what you’re asking. For run session trace ordering, you’re not asking definitions—you’re asking ordering and legitimacy constraints: what inferences are forbidden, and what must be explicitly declared rather than guessed from time or structure. That’s why a 0.6–0.7 hit can be high-value: it anchors LLM behavior and prevents conceptual drift.

{
  "run_id": "20260131T014112Z_query_vault_b52ba27830",
  "query": "run session trace ordering",
  "scope": {
    "note_path_prefix": null
  },
  "topk": 12,
  "per_note_cap": 2,
  "exclude_temporal_note": false,
  "model": "sentence-transformers/all-MiniLM-L6-v2",
  "results": [
    {
      "chunk_id": "f91b794ab50cc20b12ee18d2a74a532ed5b0630d",
      "note_path": "docs/governance/SD-0011_ID_Taxonomy_and_Identity_Ledger.md",
      "heading_path": "",
      "paragraph_index": 65,
      "hash": "ed7cc7a84aa209ae63eb30ef531ab5cfd5cb0a649b8b98da78db3c9d3cf0f73c",
      "mtime": 1769822404.9170113,
      "score": 0.7674295067787171,
      "snippet": "- Trace continuity MUST NOT be used to infer the existence of a session. - Session existence MUST NOT be inferred from trace structure. - Time ordering alone MUST NOT substitute for explicit run or session declaration.",
      "boost": {
        "prefix": "docs/",
        "factor": 1.1
      }
    },
    {
      "chunk_id": "74abc9e9857e9ee0f805584d3b95dee8c0142f29",
      "note_path": "sovereign_log/Session-Run-Trace-Formal Definitions.md",
      "heading_path": "",
      "paragraph_index": 29,
      "hash": "f08025c0500946d913c04bbecbb5ee1ed106120b5d9ecc3f21d9a5254395578b",
      "mtime": 1769737995.4226983,
      "score": 0.6208187341690063,
      "snippet": "- A Run **must exist** before any Session. - A Session **must exist** before Events are promoted. - A Trace **must exist** for any causal claim. - Time ordering **must never replace** trace structure."
    },
    {
      "chunk_id": "8c355b0da6ce66924ec7fdb83adc71dc6a4e17d7",
      "note_path": "docs/governance/SD-0011_ID_Taxonomy_and_Identity_Ledger.md",
      "heading_path": "",
      "paragraph_index": 60,
      "hash": "c056ccfc21a6cd4e9352ed599b679a0018f95bbf828fd0f017fdb9ff6af51c90",
      "mtime": 1769822404.9170113,
      "score": 0.5683699011802674,
      "snippet": "- A `trace_id` MUST be associated with a valid `session_id`. - Trace-level artifacts that lack an explicit session binding are non-legitimate.",
      "boost": {
        "prefix": "docs/",
        "factor": 1.1
      }
    },
    {
      "chunk_id": "b8ecd51c38bb6cffceb35546af4f27176d67027d",
      "note_path": "sovereign_log/Session-Run-Trace-Formal Definitions.md",
      "heading_path": "",
      "paragraph_index": 32,
      "hash": "32a2b22ffaf1ffcabcb49924a30bdcbbf00c46b052403ca5ea32e9ad1739b0c6",
      "mtime": 1769737995.4226983,
      "score": 0.5365391969680786,
      "snippet": "> **Run answers “which execution.” > Session answers “which lifecycle.” > Trace answers “why.”**"
    },

We’ve become too impatient: whenever we have a problem, we immediately prompt for an answer. LLMs are great at weaving “perfect answers.” That’s dangerous. That’s the root of drift.

If you’re considering building your own version, start with two core scripts: index_vault.py and query_vault.py

Reproducing the code is not hard. The real difficulty is not the code itself, but whether you are willing to accept a knowledge governance regime like this.

At the current stage, I deliberately do not integrate an LLM into the execution pipeline. I only hand the LLM the evidence that has already been produced (evidence packs) and the audit reports, and ask it to interpret and suggest. Whether you use the LLM in an interactive chat window today, or later embed it inside your system, this does not change the essence:

The LLM’s strength is understanding your question, organizing an appropriate query, and making suggestions under the constraints of the evidence you provide—NOT deciding what is true.

What determines system quality is how you treat evidence, and how you make knowledge governable. This is my position right now, and it’s very explicit.

Therefore, this is not “a search script.” It is a minimal Evidence Retrieval Substrate, with a deliberately restrained goal:

• Compile a vault (Markdown) into a chunk-level semantic index (Derived, rebuildable, and with no truth authority)

• Return citable evidence units in query results (chunk_id + precise location + content hash + snippet)

• Persist every query result as an evidence pack (JSON + MD) so both LLMs and humans can reuse it repeatedly during real development

If you want to reproduce this, what matters is not FAISS or the embedding model per se, but these three invariants:

chunk identity must be stable, citations must be traceable, and outputs must be replayable.

Script A: index_vault — Build the semantic index

Technical choices and underlying principle

Input: Markdown under docs/ and sovereign_log/

Output: _system/artifacts/vault_index/ (explicitly a Derived layer)

What it does is essentially “compilation”:

1. Scan Markdown files strictly inside the vault

2. Split each file into paragraph-level chunks

3. For each chunk:

   • Drop chunks that are too short (min_chars)

   • Generate a stable chunk_id

   • Record minimal but critical metadata (note_path, paragraph_index, hash, mtime)

4. Use sentence-transformers to encode chunk text into vectors (with normalization)

5. Build a FAISS vector index (IndexFlatIP, equivalent to cosine under normalized embeddings)

6. Persist artifacts:

   • meta.jsonl: one line per chunk, containing identity + provenance

   • index.faiss: the vector index file

   • config.json: index configuration for reproducibility

Why IndexFlatIP? Very simple: with normalize_embeddings=True, inner product equals cosine similarity. This is the most stable and interpretable baseline. Until you hit real performance bottlenecks, there is no need to jump to IVF/HNSW-style complexity.

Invariants you must preserve

• Chunking must remain stable

  If split_to_paragraph_chunks() changes behavior, paragraph_index will drift and historical citations will break.

• chunk_id must be bound to content

  A recommended strategy is: hash(path + paragraph_index + content_hash)

  This guarantees: once content changes, the ID changes—preventing “citation hallucinations.”

• Meta and index order must align exactly

  The vector order in FAISS must match the line order in meta.jsonl one-to-one. If they diverge, the entire index becomes invalid.

Script B: query_vault — Query and generate evidence packs

Technical choices and underlying principle

Input: a natural-language query

Read: _system/artifacts/vault_index/{meta.jsonl, index.faiss}

Output:

• _system/artifacts/packs/citations/<run_id>.json

• _system/artifacts/runs/<run_id>.md

Core workflow:

1. Load metadata + FAISS index

2. Encode the query using the same model and the same normalization

3. Run a broad retrieval first (raw_k is typically 10× topk or larger) to preserve headroom for post-filtering

4. Post-filter results:

   • scope_prefix: constrain the retrieval space

   • exclude_temporal_note: remove content that should not participate in governance

   • per_note_cap: prevent a single note from dominating the results

5. Read snippets back from source text (re-chunk by paragraph_index)

6. Apply lightweight ranking adjustments (docs_boost / prefix boost)

7. Produce an evidence pack (JSON) and a run note (MD), and write them under the Derived root

The key value here is:

The retrieval output is not a UI search result—it is a citable, persisted, auditable evidence object.

Invariants you must preserve

• Index model and query model must match

  If embedding spaces differ, the scores become meaningless.

• Snippets are display-only

  The true identity of evidence always comes from metadata (chunk_id / hash). The snippet is only for human readability.

• All outputs must land in the Derived root

  Strictly constrain writes under _system/artifacts/ and bind them to a run_id. This is what makes the process replayable and prevents contamination of the Truth/Doc layers.

Minimal reproduction checklist (for engineers)

1. Define your vault input scope (1–2 directories are enough)

2. Implement a stable chunker (paragraph-level is the best starting point)

3. Define a clear chunk_id strategy

4. Build the index and metadata with consistent ordering

5. Make query output return evidence objects, not just file paths

6. Add governance-friendly filtering (per-note cap, scope)

Normal search: find notes → human judgment

This system: retrieve chunk-level evidence → generate evidence packs → enable audit / citation / LLM analysis → feed back into real development

Indexing is only the entry point. The real product is:

citable evidence units, and evidence packs that can be repeatedly reused and re-checked.

Write a wrapper: attach the Vault directly to a real project repo — develop while using it, and feed it back while developing

When you are writing code, you should be able to query—at any time—the system principles, governance rules, historical constraints, and failure boundaries that you have already written. At the same time, new problems you encounter during development, new decisions you make, and new evidence you generate should flow back and settle into the vault. Both sides grow together; both sides prevent conceptual drift. The project won’t “forget the constitution” just because you’re busy, and the constitution won’t become empty theory because it’s detached from real work.

Right now, I treat the Vault as an “external evidence substrate” for the project

I treat sovereign_knowledge as an independent, long-lived knowledge/governance repository, and then in the real project repo I add two extremely thin scripts:

• skq: throw the development question directly into the vault’s query_vault.py

• ski: after you update vault content, rebuild the semantic index (index_vault.py)

The real value of these two scripts is not “saving a few keystrokes.” It is that they turn retrieval into a development action.

While coding, you can continuously pull evidence chunks from your governance base, generate a persistable evidence pack, and then hand that pack to an LLM (or read it yourself) to prevent conceptual drift.

A reproduction guide for engineers reading this

1. Clone your knowledge repo to any path (for example ~/sovereign_knowledge)

2. In your project repo, add two scripts:

   • scripts/skq (query)

   • scripts/ski (index)

3. Make them executable: chmod +x scripts/skq scripts/ski

4. Configure environment variables once (optional):

   • export SK_VAULT=~/sovereign_knowledge

   • export PYTHON=python3 (or your venv python)

5. Day-to-day usage:

   • After updating the vault: scripts/ski

   • When you hit uncertainty during coding: scripts/skq "run session trace ordering" --scope_prefix docs/

That completes the “develop while using, develop while feeding back” loop. You don’t need to move the vault code into your project, and you don’t need to maintain an indexing pipeline inside your project repo. You only need to treat the vault as an external governance substrate, and query it whenever you need.

One crucial point: why I think “external repo + wrapper” is more engineering than plugins

Because it turns retrieval output into stable artifacts (packs / run notes), rather than transient UI results. And because it extracts “knowledge governance” from the note-taking tool layer and turns it into an engineering object that can enter CI, auditing, and code review. That is why a “second brain” built this way can grow over the long run: it doesn’t depend on what you can remember; it depends on a toolchain continuously producing traceable evidence.

A senior engineer with years of experience once told me: in the LLM era, you need as much text as code. But you can’t just dump every project into a single text repository.

In the end, the LLM’s ability to decompose problems, design queries, and read sparse fragments from evidence chunks to produce suggestions—this is why, at this stage, this approach can reduce anxiety while you are using LLMs intensely.

现行的笔记软件已经无法解决AI辅助编程效率的问题了。

笔记一直是程序员最重要的效率工具之一，几乎每一代程序员都会试图从自己的工作方式出发，开发或改造一套属于自己的笔记系统，从最早的文本文件、Wiki，到 Word、印象笔记、Notion，本质上都是在解决同一个问题：如何在高强度的信息处理环境中，保留可用的思考结果。但现实是，笔记系统始终是不够好的，尤其是对每天需要处理大量文字、代码和决策的人来说。

过去几年我一直使用 Notion 作为主力笔记工具，常见的做法是开一个表格，每条记录带时间戳、链接和上下文说明，处理 bug 时在 icon 🐛上放一只小虫子，把所有线索、想法、日志和代码都塞进去，直到有一天我连续在电脑前工作了将近十二个小时，回过神来发现当天已经产生了接近两百条记录。Notion 的每一条记录本质上都是一个可以无限展开的页面，而不是 Excel 里的一个单元格，即便每一页只有两三千字，二百页也已经是四十万字，这个规模早已远远超出人类在一天之内能够阅读、理解和消化的极限，而且这并不是一次性的极端情况，而是逐渐变成了常态。

正是在这种背景下，我在最近几周明显进入了一种奇怪的状态：事情很多，但推进极慢，下意识回避工作，睡眠时间不断拉长，再加上东岸连续的大雪，被困在家里几天，又干脆出去玩了几天雪，表面看像是怠工或逃避，但真实感受是一种深度的认知疲惫。与此同时，大语言模型变得异常强大，代码、文档、方案几乎可以瞬间生成，但这种能力提升并没有让我成为一个更高效、更清醒的个体，反而带来强烈的挫败感，因为我发现这种状态并不只发生在我身上，和一些朋友交流后，大家普遍都在经历类似的认知过载：个人能力被工具放大到一定程度之后，随之而来的不是解放，而是更严重的反噬。

工业化语言生产机

回头看，问题集中体现在三个方面：第一，信息和文本的生成规模已经彻底超出人类的生理极限，这与个人能力强弱无关；第二，生成速度过快，导致根本记不住自己看过什么，LLM 必须持续回答、持续发散、持续给路径，却从不提供“到此为止”的信号；第三，也是最致命的，是隐性漂移，状态完全依赖窗口维持，窗口不断叠加，几天之后再回看几天前的代码，已经无法理解当时的情境，同一个概念、脚本和索引在命名、路径和 ID 上不断漂移，vault_index、index_vault、inventory_index 之类的差异一路堆叠，几周之后再看整个项目，只剩下一种彻底失控的感觉。

被雪困住的那几天里，我反复思考这个问题，逐渐意识到这并不是个人管理能力的问题，而是机制层面的必然结果：LLM 本质上是一个 zero-shot universe，几乎零成本生成内容，不会疲劳，不会犹豫，也不会做“是否值得继续”的决策，prompt 只是软约束，它没有硬停机条件，它是一台持续生产语言和符号的工业化机器，而人类的大脑并不具备相同的承载能力；漂移不是偶然，而是这种机制的必然产物，拉长上下文并不能解决问题，因为模型永远只是在预测下一个 token，他要找不到最正确的答案他就给你猜一个；更重要的是，整个过程没有责任主体，每天几百上千次 prompt 强烈依赖当下环境，事后几乎无法复现，也无法追责。

这是一个治理Governance的问题

正是在这种情况下，我开始意识到，问题并不在于“记得不够多”，而在于在这个时代，继续沿用“多记一点总有用”的传统笔记假设，本身就是不可持续的。Notion 并不是没有搜索功能，但当我真的需要解决一个具体问题、回溯自己过去的思考时，搜索出来的往往是成百上千条结果，其中大量内容彼此冲突、语境缺失、时间错位，几乎无法直接使用，搜索本身并没有降低认知负担，反而把问题放大了。也正是在这个背景下，在这个 repo 连续开发了几天之后，我又一次尝试去重新搭建自己的记录体系——这种尝试其实已经发生过很多次，绝大多数都以失败告终，但这一次我明显感觉到有些地方开始对路了，至少已经值得写出来和别人分享。关键并不在于我是否找到了一个“更好的工具”，而在于我发现，这根本不是工具层面的问题，而是人在这个阶段不可回避地遭遇了自身的生理与认知约束。一方面，我确实需要一个更贴合我个人工作方式的系统，但另一方面，更重要的是必须把注意力放回真正的核心问题上：这个问题既不是笔记，也不是程序，更不是靠一个软件、一个库就能一次性解决的工程问题，它的核心只有一个——知识的治理。

这是个Governance的问题。

简单说，“知识的治理”是什么意思？从更大的尺度看，人类社会中几乎所有真正困难的问题，本质上都是治理问题。政治是治理问题，国家如何被治理；法律是治理问题，立法、司法、执法如何分工与约束；宪法本身也是治理问题，不只是写下来，而是如何被解释、如何被遵守、如何保证它真的被遵守。把尺度缩小，团队管理、制度设计、流程约束，同样是治理问题，而不是工具问题。治理的核心从来不在于“有没有信息”“能不能访问”，而在于哪些东西被承认为有效、哪些判断具有权威、哪些状态可以进入长期记忆、哪些必须被限制、冻结或废弃。

回到个人层面，所谓“知识管理”的真正难点也在这里：不是信息不够，不是搜索不强，而是缺乏一套能够裁决、约束和负责的机制。正因为如此，这个问题其实已经被无数程序员反复尝试解决过，从早期的个人知识库、标签系统、到后来的双链、图谱、向量化检索，再到 Obsidian、各种语义搜索和 AI 助手，它们解决的更多是“如何找到内容”“如何关联内容”“如何生成内容”，但几乎都默认了一个前提：内容一旦写下，就天然具有价值，只要存得住、搜得到，就算成功。这个解决方案和各种开源项目到处都是，我自己也是借鉴了的。我现在也是把内容全部存成 .md文档，obsidian vault可读。But this is not the point!

在信息和生成能力远低于今天的年代，搜到就赚到。但在一个内容可以零成本爆炸式生成的时代，这个前提本身已经失效了。真正缺失的并不是更聪明的搜索算法，也不是更复杂的表示方式，而是一套能够回答“什么可以被承认为知识”“什么只是过程噪声”“什么需要被追责”“什么必须可复现”“什么不允许悄然漂移”的治理结构。

所以，我说说我现在自己尝试的这种方案，这个repo，虽然开始没多久，但是我感觉这个方向很行。如果你有这个需求，也许我能启发一些目前同样困扰的人。

一个Sovereign Log, 简单代码，昂贵写入，没有接LLM，后期可以接，帮我定住我最核心的认知。

不是为了高频记录而设计的，恰恰相反，它刻意让写入变得昂贵、缓慢和需要思考；它的实现保持在尽可能简单的代码层面，不依赖复杂系统，也不直接接入 LLM，因为一旦接入，零成本生成就会立刻侵蚀它作为“裁决记录”的性质。现阶段都是硬编码。我先简单说说都包括啥，现在连UI都没有，就已经简单的解决了我大量的问题。

.
├── _system
├── docs
├── inbox
├── requirements
├── sovereign_log
├── templates
└── tools

这里面有两个.md组成的文本库，一个是sovereign_log，另一个是doc。

Sovereign_log

当然，一切并不是从一个宏大的系统开始的。我最初建立的只是一个极小、极其克制的 vault，它的起点和任何一个普通的 Obsidian vault 并没有本质区别。如果你看到它的 graph，会发现几乎没有什么结构特征：没有刻意构建的 backlink，没有主题网络，也不追求连接密度。唯一真正不同的地方在于数量——极少。这是一个被我刻意维持的约束。在这个 vault 里，每一篇内容都不是草稿，不是“先写下来再说”，而是经过反复推敲的结果。我会与 AI 多轮对话，压缩表达、校正边界、澄清含义。早期我主要使用英文写作，同时辅以少量中文翻译，是作为一种语义校验手段，用来确认我是否真正理解了自己写下的东西。随着系统成熟，这个 vault 很可能会完全切换为英文。这个阶段的 Sovereign_Log，本质上是一个高度精炼、完全由个人主权控制的知识集合，其核心原则非常简单：不要乱写，不要当成草稿，数量不是越多越好，而是越精良越好。有时一整天的思考、推演和结构对齐，最终只会留下 1–2 篇笔记，是一种有意为之的熵控制。你一定要维持这种纪律，否则又跟你其他笔记一样，照搬过来一大堆东西。

Doc

Doc 在形式上依然是“笔记”，但它并不是 Sovereign_Log 的自然延伸，而是一次明确的跃迁。Doc 中的内容并非写得更正式，而是被提升过的文本，处于一种介于叙事语言与可执行代码之间的 IR 状态。它们尚未成为代码，但已经不再允许自由叙述。在设计这个知识库时，我刻意引入了“昂贵性”这一反直觉原则，用来对抗大语言模型生成文字与代码过快、过多的问题。我认为，真正进入知识库核心层的内容，必须在制度上是昂贵的，而不是在情绪或表达上显得复杂。这种昂贵性体现在三个层面。

首先是格式昂贵。Doc 不是自由文本，任何内容想要进入这一层，必须满足固定结构并通过机器可执行的格式检查。确保这些文本在原则上是可解析、可索引、可审计、可约束的。一篇格式不合格的内容是根本不具备进入该层的资格。

其次是流程昂贵。内容不能一开始就进入 Doc，它必须先在 Sovereign_Log 中存在，经过时间沉淀，在真实使用中反复被搜索、引用、转化为代码或决策，逐渐显现出对系统行为的实际影响，才会成为候选项，并在明确授权后被提升进入 Doc。这一机制在未来引入团队共享知识库时尤为关键，因为它明确阻断了任何人、任何模型、任何一时兴起的想法对核心知识层的直接污染。Doc 被视为一种稀缺资源，而不是存放“整理后内容”的地方。

第三，也是现阶段最重要的一点，是语义昂贵。我对 Doc 的核心要求并不是表达清晰或逻辑自洽，而是语义必须达标。所谓语义达标，意味着条文之间不能互相矛盾，不允许隐含冲突，不允许模糊责任与边界，每一条声明都必须具备生成 binding 代码的潜力。我观察过许多文档规模庞大的知识库，它们的共同问题并不是信息不足，而是语义杂乱、定义漂移、条文冲突，最终无法转化为真实可执行的系统约束。这样的知识库看似厚重，实则不可执行。而 Doc 的目标恰恰相反：每一条文本，都是潜在的系统约束；每一条语义，都是未来代码的来源。因此，语义本身也必须进入可被机器介入和审计的范围。

├── docs
│   ├── decisions
│   ├── governance
│   │   ├── CLAIM-AUTHORING-STYLE-V0-1.md
│   │   ├── EVIDENCE_SUGGEST_AUDIT.md
│   │   ├── RPT-2026-01-26-RUNTIME_ENV_GOVERNANCE.md
│   │   ├── SD-0007_RUNTIME_ENV_FREEZE.md
│   │   ├── SD-0008_INDEX_CONSOLIDATION.md
│   │   ├── SD-0009_DOC_IR_SPEC_v0.md
│   │   ├── SD-0010 — Normative Boundary & Semantic Consistency Rules
│   │   ├── SD-0011_ID_Taxonomy_and_Identity_Ledger.md
│   │   └── SD-0012 — Observability Causal Structure & Span Identity 
│   ├── invariants
│   │   ├── INV_CATALOG_v0.md
│   │   ├── INV_DOC_IR_BOOTSTRAP_v0.md
│   │   └── INV_INDEX_ROOTS_0001.md
│   ├── Machine-Checkable Invariants.md
│   ├── runs
│   ├── SD-0001-System-Constitution.md
│   ├── SD-0002-Derived-Artifact-Path-Freeze.md
│   ├── Sovereign Log — Write Protocol v1.0.md
│   ├── stage_contracts
│   │   └── PRE_STAGE_5.md
│   └── taxonomy
│       ├── INDEX_TYPES.md
│       └── TDES.md

我现在的系统是完全没有接入任何 LLM 的，至少在这一层没有。这些约束、筛查和升级机制，全部是在代码层面完成的。我一直相信，如果你是一个看到这里的程序员，并且你觉得这套方法对你有借鉴意义，那么它在技术上并不复杂，甚至可以说是非常直白的工程实现。这里我不展开具体代码细节，只用一个非常具体的例子来说明我所谓的“语义昂贵”到底是什么意思。

以语义筛查为例。我每次跑 audit，通常都会顺手生成两份报告：一份是给机器继续消费的 JSON，一份是给人看的 Markdown。下面这段就是我某一次跑出来的语义审计报告摘要。

这次 audit 的标识是 AUDITDOCSEMANTIC — 20260130T205405Zdocsemantic_audit，整体结果是 ok: False，意味着这次检查在制度上是不通过的。系统扫描了 docs 目录下的文档，共识别出 77 条 claims，使用的是基于 embedding 的相似性与语义模式匹配（这里用的是 all-MiniLM-L6-v2，阈值 0.92，top-k 为 8，最大配对 200）。需要特别说明的是，这里对 modality、target、predicate 的推断仍然是启发式的，属于 v0.1 阶段，这一点在 meta 里是明确写出来的，后续会被提升为显式的结构化 claim tags。也正因为如此，重复或冲突在默认情况下只是 warning，但在这次配置里，我把冲突严重性提升为了 error，要求必须被解决。

真正关键的是下面这条 violation：SEM-CNF-001。它指向的是一个语义冲突，而且不是模糊冲突，而是非常具体的 modality 冲突。系统检测到，在两个不同的文档中，针对同一个 (target, predicate) 组合——也就是 ('GLOBAL', 'evidence')——出现了相互矛盾的规范性断言：一条是 must，另一条是 must_not。冲突来源被精确定位到了 SD-0011#C-0004 和 DOC-EVIDENCE-SUGGEST-AUDIT-V1#C-0003 这两条具体的 claim 上。这意味着，在当前 Doc 层的语义空间中，系统同时被告知“这件事必须发生”和“这件事必须不能发生”，而且两者作用域完全一致。

这类错误在我的系统里是不可接受的。一旦这样的语义进入核心 Doc 层，任何试图从中生成 binding 代码、策略或运行时约束的行为，都会立刻失去确定性。因此 audit 是直接要求你做出选择。hint 里给出的路径也非常明确：要么通过既定的优先级体系来裁决（例如 INV 高于 SD，高于 taxonomy），要么明确使用 supersede 机制，让其中一条 claim 在制度上失效。这是哪一条规则在系统中继续存活的问题。

对我来说，这正是“语义昂贵”的具体体现。不是靠人脑记住“这里好像有点矛盾”，而是让系统在 Doc 层直接拒绝语义不闭合、不一致、不可执行的状态。也正因为有了这样的机制，Doc 才不再是一个“写得很严肃的文档集合”，而是真正开始具备约束未来代码与系统行为的资格。

AUDITDOCSEMANTIC — 20260130T205405Zdocsemantic_audit
ok: False
violations: 1
Meta
{
  "docs_dir": "docs",
  "claims_count": 77,
  "dup_threshold": 0.92,
  "topk": 8,
  "max_pairs": 200,
  "dup_severity": "warn",
  "model": "sentence-transformers/all-MiniLM-L6-v2",
  "notes": [
    "v0.1 modality/target/predicate inference is heuristic; promote to structured claim tags later.",
    "duplicates are warnings by default; set --dup_severity error to hard-enforce."
  ]
}
Violations
1. SEM-CNF-001 (error)

path: docs/governance/SD-0011_ID_Taxonomy_and_Identity_Ledger.md | docs/governance/EVIDENCE_SUGGEST_AUDIT.md
message: Modality conflict (must vs must_not) on (target,predicate)=('GLOBAL','evidence'): SD-0011#C-0004 vs DOC-EVIDENCE-SUGGEST-AUDIT-V1#C-0003
hint: Resolve via priority (INV > SD > TAXONOMY ...) or supersede one of the conflicting claims.
meta: 46502865b8712493e52dffd4a6b6871cd994c162f900ea8e6e7a8c3ebbcb5873

怎么实现的

从技术实现上讲，这套机制并不依赖大语言模型，也不需要任何“智能理解”。它的核心思想是：把文档的语义压缩成一组可计算、可比较、可失败的结构化要素，然后用一套完全确定性的规则对这些要素做审计。整个系统可以拆解为几个相对独立的技术层，你可以按需要取用或替换其中任意一层，而不影响整体成立。

第一步是声明式语义单元的引入。文档不再被当作一整块自然语言，而是被要求显式标注最小治理单元——也就是稳定编号的 claim。它们本质上等价于“规范性断言”，每一条都是一个潜在的系统约束。实现上不需要复杂解析器，只要用简单、鲁棒的文本模式（例如固定前缀或行结构）就可以稳定抽取。这一步的关键不是解析能力，而是强迫作者在写作阶段就做出“这是我要被系统治理的句子”的选择。

import re
from dataclasses import dataclass

CLAIM_RE = re.compile(r"(?m)^\\s*-\\s*(C-\\d{4})\\s*:\\s*(.+?)\\s*$")

@dataclass
class ClaimRaw:
    claim_id: str
    text: str

def extract_claims(md: str) -> list[ClaimRaw]:
    out = []
    for cid, txt in CLAIM_RE.findall(md):
        out.append(ClaimRaw(claim_id=cid, text=txt.strip()))
    return out

复现要点：你只需要一个稳定、可被 grep 的写作格式（比如 - C-0001:）。解析就能保持极简。

第二步是规范性强度（modality）的离散化。系统并不尝试理解句子的全部含义，而是只关心它在制度上的态度：是必须、禁止、允许，还是无法判定。这可以通过一组确定性的关键词或规则完成，而不是统计模型。重要的是，这一步把“模糊的自然语言语气”压缩成一个有限集合，使得后续冲突判断变成一个有限状态问题，而不是语言理解问题。

import re

MODALITY_RULES = [
    ("must_not", re.compile(r"\\b(must not|shall not|forbidden|prohibited|not allowed)\\b", re.I)),
    ("must",     re.compile(r"\\b(must|shall|required|mandatory)\\b", re.I)),
    ("forbid",   re.compile(r"\\b(forbid|prohibit|disallow|deny)\\b", re.I)),
    ("allow",    re.compile(r"\\b(allow|permit|allowed)\\b", re.I)),
]

def infer_modality(text: str) -> str:
    for name, rx in MODALITY_RULES:
        if rx.search(text):
            return name
    return "unknown"

复现要点：这不是 NLP，是可审计的规则表。你可以按你组织的写作词汇（MUST/SHALL/禁止/允许）扩展规则。

第三步是约束对象（target）的锚定。为了避免所有规则都在一个全局空间里相互干扰，系统需要一个机制，把每条 claim 映射到一个明确的约束对象上。实现方式可以非常简单，例如通过显式标注、路径前缀、资源名或作用域标识符。只要这个 target 是稳定、可比较的，就足够用于治理。未能明确锚定的规则，可以被保守地归入全局作用域，从而承担更高的冲突风险，这本身就是一种设计激励。

import re

BACKTICK_RE = re.compile(r"`([^`]+?)`")

def infer_target(text: str) -> str:
    # Prefer explicit anchors like `docs/` `_system/` `sovereign_log/`
    for m in BACKTICK_RE.finditer(text):
        tok = m.group(1).strip()
        if tok.startswith(("docs/", "_system/", "sovereign_log/")):
            # collapse file path to a directory-ish prefix for stability
            parts = tok.split("/")
            if len(parts) >= 2:
                return parts[0] + "/" + parts[1] + "/"
            return parts[0] + "/"
    return "GLOBAL"

复现要点：你要的不是“精准路径”，而是稳定可比对的 target key。写作上用 backticks 做显式锚点，工程上就能把 GLOBAL 降到最少。Global会给你很多的false positive, 没完没了的修。其实一般的claims都是针对特定域的，你不会动不动就写一个“我这条整个系统都必须通用。”

第四步是谓词维度的粗分类（predicate）。这是为了避免不相关的规则在同一 target 上产生误报冲突。系统并不需要一个完整的本体论，只需要一个非常小、可扩展的谓词集合，用来区分“这是关于存放位置的规则”“这是关于权限或权威性的规则”“这是关于证据或生成机制的规则”等。这一步同样可以通过关键词或标签完成，其目标是缩小冲突比较的语义空间，而不是追求精细分类。

def infer_predicate(text: str) -> str:
    t = text.lower()

    if any(w in t for w in ["authoritative", "canonical", "binding", "truth layer"]):
        return "authority"
    if any(w in t for w in ["faiss", "semantic index", "vault_index", "index root", "index output"]):
        return "index"
    if any(w in t for w in ["write to", "stored under", "must exist only at", "reside at", "live under"]):
        return "placement"
    if any(w in t for w in ["admitted", "accepted", "effective", "governance-valid"]):
        return "admission"
    if any(w in t for w in ["evidence", "ingest", "payload", "manifest"]):
        return "evidence"

    return "general"

在完成上述四个要素之后，每一条文档声明在系统中都会被压缩成一个结构化记录：(modality, target, predicate)。到这里，文档已经不再是自然语言集合，而是一个可以被机器枚举、分组和比较的约束集合。

基于这个结构，语义冲突检测就变成了一个纯规则问题：在同一个 (target, predicate) 空间内，是否同时存在互斥的规范性态度（例如 must 与 must_not，allow 与 forbid）。一旦出现这种情况，系统可以直接判定为不可执行状态，并给出精确到声明级别的冲突定位。这里不涉及概率、不涉及模型判断，也不需要人工解释，冲突即失败。

在此之上，可以叠加一个近似重复检测层，用于发现语义上高度相似、但尚未构成直接冲突的声明。这一层可以使用任何向量化或相似度技术来实现，其角色更接近于“治理卫生检查”，而不是硬约束。是否将其视为警告还是错误，完全取决于你对系统严格程度的要求。

整个审计流程的输出应当是机器优先的：结构化结果用于后续自动化处理，人类可读报告用于审查与决策。关键在于，审计必须能够失败，并且失败应当通过明确的进程退出、状态标志或流水线信号向外传播，这样文档治理才能真正进入工程系统，而不是停留在规范建议层。

如果你想在自己的系统中复现这一机制，并不需要复制具体实现。你只需要确认几件事：你是否愿意引入显式的声明式语义单元；你是否愿意接受把自然语言压缩为有限语义维度所带来的约束；以及你是否愿意让“文档语义不一致”像代码编译错误一样中断流程。一旦这三个问题的答案都是“是”，那么无论你使用哪种语言、哪种工具、哪种存储结构，这套“语义昂贵”的文档治理模式都可以被复现出来。

为什么不引入大模型？当然我后期肯定会引入的。但是现在我需要搭建一个完全断开大模型的基层。这个原因我觉得读到这里的人应该都能大概理解。因为你想要的是历史与治理必须由确定性机制承担，模型只能作为建议者，而不能成为裁决者。失败条件是稳定的，系统边界是清晰的。这件事情目前让我感觉上就舒心很多。

硬编码就万能吗？当然不是！它覆盖不了复杂语义。关键词、规则表、枚举谓词，本质上都是低分辨率的认知压缩。它无法理解隐喻、上下文、反讽，也无法自动适应新的表达方式。硬编码会显得笨、慢、保守。每加一个 predicate、每调一个规则，都需要人来做判断。这在早期看起来效率很低。但我恰恰需要这种“慢”。它是一种摩擦机制，用来对抗“生成过快”的系统风险。在一个可以一秒钟生成一百条规则的时代，慢本身就是一种安全设计。它迫使规则的作者为进入核心层付出认知成本。这也是我认为程序员容易陷入的一种精神陷阱，就是很容易把自己抽离。认为自己不是系统机制的一部分。我个人反而因为现在大量自己做项目，容易理解这种“自身必须带入，自身必须收到约束”的想法。

核心当然是Vault Index and Query

好，我们先把系统总图停在这里，剩下的那些“细枝末节”（derived 层怎么落盘、怎么隔离、各种 tools/templates、审计与报告的目录法、生命周期与清理策略）确实规模很大，但它们本质上都是工程卫生问题：只要你的边界清楚（Truth / Decision / Evidence / Derived），再加上写入权限与路径约束，技术实现不会难，更多是“制度一致性”和“长期可维护性”的问题。

我这里真正想展示的，是我的 vault_indexer：它不是一个“更好用的搜索”，而是一个把笔记系统变成证据底座（evidence substrate）的索引机制。现在几乎所有笔记应用迟早都会走到“语义检索 + chunk”这条路，但我在做的时候发现，决定它最终价值的不是检索本身，而是你如何组织证据 chunk、如何让它们具备可引用、可复现、可审计的属性，以及最关键的：这个索引产物在你的系统里到底处于什么层级（Truth 还是 Derived）。

我的做法是把索引严格定位为 Derived：它永远不拥有“真理权”。它只负责把 docs/、sovereign_log/ 这些文本资产，编译成一个面向检索的中间产物：把文档切成稳定粒度的 chunks（通常是段落级或标题-段落组合级），为每个 chunk 生成稳定标识（chunk_id）、保留来源路径、heading/段落位置、以及内容哈希（或可追溯的 digest）。然后对 chunk 文本做 embedding，构建向量索引（FAISS 或同类），最终让你可以用自然语言 query 去命中一组证据 chunks。注意这里“证据”不是泛指相关文本，而是具备引用结构的对象：每个 chunk 都能被精确地指向、被复制到 evidence pack、被后续工具链复用，甚至被审计系统要求“你生成的结论必须引用这些 chunk_id”。

这就直接解释了为什么 LLM 在我这里不是“写作机器”，而是“最佳 query 手”。LLM 的强项不是凭空生成，而是：把一个模糊问题拆解成可检索的子问题、构造有效 query、对返回的证据进行结构化归纳，并把归纳结果映射回开发动作（改哪个文件、加哪个 invariant、补哪个 claim、写哪个 diff）。当你已经建立了信息底座——也就是把核心原则、边界、约束、历史责任都冻结在 Doc / Sovereign_Log 里——LLM 最合理的用法就是站在索引之上，做“证据驱动的开发协作”。你问一个问题，它先检索，再给你一个带引用的证据包（JSON/MD），你再用这个证据包去推进决策与代码，而不是让它用记忆和幻觉替你编故事。

也因此，我的方法和很多以“搜索”为核心的 Obsidian 插件有一个结构性差异：大多数插件的目标是“更快找到笔记”，而我的目标是“让检索结果成为可治理的证据对象”。插件式搜索通常停留在 UI 体验层：关键词或语义匹配 → 打开笔记 → 人脑判断；它们很少解决这些问题：检索命中的内容有没有稳定引用？是否能在 CI/审计里复现同一个结果？检索产物是否会被错误地当成权威？能否形成“问题 → 证据 → 决策 → 代码 → 回写证据”的闭环？而我的 vault_indexer 把检索的输出直接做成一种可落盘、可版本化、可再利用的中间态（pack / report / audit），并且明确把它放在 Derived 层：它可以被重建、可以被替换模型、可以被清理，但不能反向污染 Truth/Doc 的权威性。

换句话说：很多笔记插件把搜索当作“阅读入口”，我把索引当作“开发输入口”。前者优化的是找笔记，后者优化的是把笔记变成工程证据，让 LLM 以“证据分析器 + query 编译器”的身份参与开发。这也是为什么当你的系统底座一旦稳定（规则、边界、历史责任明确），索引检索就不再是锦上添花，而会变成你推进长期工程的主引擎：你不是在“写更多笔记”，你是在用检索把过去的制度与证据，持续地喂回现在的决策与代码。

废话不多说，直接给你看证据。

我们先从一份非常真实的 query_vault 结果说起。需要先说清楚一个前提：这个系统现在还在早期阶段，它不是那种“装完就立刻很神”的工具。它需要你在真实项目中长期使用、长期维护，并且真正把它当成核心系统来用，才会逐渐成长为你自己的“第二大脑”。在这个阶段，检索结果的 score 普遍不会特别高，这是正常现象。对我现在的库来说，0.7 已经算是相当不错、可以认真阅读的命中率了。

原因很简单：语义索引的质量，最终取决于你往里放了什么。你需要一边做真实的开发、一边写真实的规则、一边不断用“已经被你验证过的优质内容”去填充这个库；同时还要持续升级、清理和维护。这个过程是累积性的：越用越好用，越用越省心，而不是一开始就给你“标准答案”。这才是第二大脑应有的成长方式。

从结构上看，一次 query_vault 的 run，本质上只是一个可复现的检索结果对象。它并不试图直接回答问题，而是把“当时系统认为可能相关的证据”列出来。这个对象里最重要的几个字段是：

• run_id：这次检索的唯一标识。你可以把它当成一次“证据采样”的编号，后续可以落盘、归档、甚至被审计。

• query：你当时输入的原始问题，用于回溯“当时你在想什么”。

• model：用于向量化的 embedding 模型，它定义了“相似”的数学意义。

• results[]：真正的核心内容——chunk 级别的命中结果，而不是文件级搜索。

每一条 result，都不是“这篇文档命中了”，而是“这一个具体段落（chunk）被认为相关”。因此，每条 result 都带着一组对工程师来说非常关键的元信息：

• chunk_id：这个段落的稳定身份。后续引用证据时，你引用的是它，而不是“我记得哪篇文档里有一句话”。

• note_path / heading_path / paragraph_index：用于精确定位原文位置。

• hash：该段落内容的哈希，用来保证“你现在看到的证据”和“未来审计时看到的证据”是同一段文字。

• mtime：最后修改时间，帮助你判断新旧、是否存在语义漂移风险。

• score：相似度分数，只是排序信号，不是“正确性”或“权威性”的度量。

• snippet：展示用的截断文本，只能当预览，不能当证据全文。

所以你要对这个结果有一个非常清醒的认识：

它是一份**“可引用的检索命中清单”**，而不是“已经回答你问题的证据”。

接下来才是关键：你问的是什么问题？你希望这份证据帮你解决什么？

在这次 query 里，问题是：

run session trace ordering

这并不是在问“Run、Session、Trace 分别是什么”，而是在做一次围绕 Run / Session / Trace 的存在顺序与合法性（ordering & existence constraints） 的证据检索。

换句话说，这是一个非常“硬”的问题。你真正关心的不是定义，而是：

哪些推断是被系统明确禁止的？

哪些顺序关系必须显式声明，而不能从时间或结构中“猜”出来？

这也是为什么这次命中的 chunk，即便 score 只有 0.6～0.7，依然是高价值证据。比如：

• 明确禁止从 trace 连续性推断 session 存在

• 明确禁止用时间顺序替代 run / session 的显式声明

• 明确要求 trace 必须绑定到合法 session，否则就是 non-legitimate

• 明确区分 Run / Session / Trace 各自回答的问题域

这些内容并不是“百科式解释”，而是制度级约束。它们的价值不在于“讲清楚概念”，而在于防止你和 LLM 在开发过程中犯错。

这也正好引出了 LLM 在这里的正确角色定位。

在这个系统里，LLM 不是用来脑补解释的，而是一个“证据分析器”。它不应该看到 snippet 就开始编故事，也不应该试图用时间顺序、因果叙事去“合理化”缺失的结构。相反，它应该被这些 chunk 锚定住行为边界：

• 这些推断是被明确禁止的 → 不要做

• 这些关系必须显式声明 → 如果缺失，就指出缺口

• 如果规则已经存在但没有被完美回答 → 就用已有证据做锚，而不是重新发明规则

即便这个问题在你的系统里还没有一个“教科书式的最终答案”，0.7 分左右的证据依然有巨大价值：它为 LLM 提供了方向约束，防止概念漂移，防止在日常开发中慢慢把系统“想歪”。

这就是我做这套 vault_indexer + query 机制的初衷：

不是让检索直接给你答案，而是让它在你和 LLM 之间，持续提供一个可以被引用、被校验、被审计的证据锚点。只要这些锚点是稳定的，你的系统就不会在长期使用中悄悄变形。

{
  "run_id": "20260131T014112Z_query_vault_b52ba27830",
  "query": "run session trace ordering",
  "scope": {
    "note_path_prefix": null
  },
  "topk": 12,
  "per_note_cap": 2,
  "exclude_temporal_note": false,
  "model": "sentence-transformers/all-MiniLM-L6-v2",
  "results": [
    {
      "chunk_id": "f91b794ab50cc20b12ee18d2a74a532ed5b0630d",
      "note_path": "docs/governance/SD-0011_ID_Taxonomy_and_Identity_Ledger.md",
      "heading_path": "",
      "paragraph_index": 65,
      "hash": "ed7cc7a84aa209ae63eb30ef531ab5cfd5cb0a649b8b98da78db3c9d3cf0f73c",
      "mtime": 1769822404.9170113,
      "score": 0.7674295067787171,
      "snippet": "- Trace continuity MUST NOT be used to infer the existence of a session. - Session existence MUST NOT be inferred from trace structure. - Time ordering alone MUST NOT substitute for explicit run or session declaration.",
      "boost": {
        "prefix": "docs/",
        "factor": 1.1
      }
    },
    {
      "chunk_id": "74abc9e9857e9ee0f805584d3b95dee8c0142f29",
      "note_path": "sovereign_log/Session-Run-Trace-Formal Definitions.md",
      "heading_path": "",
      "paragraph_index": 29,
      "hash": "f08025c0500946d913c04bbecbb5ee1ed106120b5d9ecc3f21d9a5254395578b",
      "mtime": 1769737995.4226983,
      "score": 0.6208187341690063,
      "snippet": "- A Run **must exist** before any Session. - A Session **must exist** before Events are promoted. - A Trace **must exist** for any causal claim. - Time ordering **must never replace** trace structure."
    },
    {
      "chunk_id": "8c355b0da6ce66924ec7fdb83adc71dc6a4e17d7",
      "note_path": "docs/governance/SD-0011_ID_Taxonomy_and_Identity_Ledger.md",
      "heading_path": "",
      "paragraph_index": 60,
      "hash": "c056ccfc21a6cd4e9352ed599b679a0018f95bbf828fd0f017fdb9ff6af51c90",
      "mtime": 1769822404.9170113,
      "score": 0.5683699011802674,
      "snippet": "- A `trace_id` MUST be associated with a valid `session_id`. - Trace-level artifacts that lack an explicit session binding are non-legitimate.",
      "boost": {
        "prefix": "docs/",
        "factor": 1.1
      }
    },
    {
      "chunk_id": "b8ecd51c38bb6cffceb35546af4f27176d67027d",
      "note_path": "sovereign_log/Session-Run-Trace-Formal Definitions.md",
      "heading_path": "",
      "paragraph_index": 32,
      "hash": "32a2b22ffaf1ffcabcb49924a30bdcbbf00c46b052403ca5ea32e9ad1739b0c6",
      "mtime": 1769737995.4226983,
      "score": 0.5365391969680786,
      "snippet": "> **Run answers “which execution.” > Session answers “which lifecycle.” > Trace answers “why.”**"
    },

我们现在已经非常的操之过急的，习惯于，每次自己有什么问题，马上写prompt，马上要得到答案。然而LLM又非常善于给你编织“完美答案”。这是非常危险的。这就是漂移的根源。

如果你考虑自己弄一个，那么可参考两个核心脚本：index_vault.py; query_vault.py

代码层面的复现其实并不难，真正的难点也不在代码本身，而在于你是否愿意接受这样一套知识治理制度。在现阶段，我是刻意不把 LLM 接入系统执行链路的。我只会把已经生成好的证据（evidence packs）和审计报告，交给 LLM 去“解释”和“建议”。无论你是在交互窗口里用 LLM，还是将来把它接入系统内部，这一点在本质上并不会改变：LLM 的强项是理解问题、组织合适的 query、并在你提供的证据约束下给出建议，而不是替你决定什么是真理。真正决定系统质量的，是你如何看待证据、如何让知识变得可治理。这是我目前非常明确的立场。

因此，这套东西并不是“一个搜索脚本”，而是一个最小可用的 Evidence Retrieval Substrate。它的目标非常克制：

• 把 vault（Markdown）编译成 chunk 级的语义索引（Derived、可重建、没有真理权）

• 查询时返回的是可引用的证据单元（chunk_id + 精确定位 + 内容 hash + snippet）

• 把每一次查询的结果落盘为 evidence pack（JSON + MD），供后续 LLM 和人类在开发中反复引用

如果你要复现，真正需要抓住的并不是 FAISS 或 embedding 模型，而是这三条不变量：

chunk 身份必须稳定、引用必须可追溯、输出必须可重放。

脚本 A：index_vault —— 构建语义索引

技术选型与原理

输入：docs/、sovereign_log/ 下的 Markdown

输出：_system/artifacts/vault_index/（明确属于 Derived 层）

它做的事情本质上是一次“编译”：

1. 只在 vault 内扫描 Markdown 文件

2. 将每个文件切成段落级 chunks（paragraph chunks）

3. 对每个 chunk：

   • 丢弃过短内容（min_chars）

   • 生成一个稳定的 chunk_id

   • 记录最小但关键的元数据（note_path、paragraph_index、hash、mtime）

4. 使用 sentence-transformers 将 chunk 文本编码成向量（并归一化）

5. 使用 FAISS 构建向量索引（IndexFlatIP，等价 cosine）

6. 将索引产物落盘：

   • meta.jsonl：每一行对应一个 chunk 的身份与来源

   • index.faiss：向量索引

   • config.json：索引配置与可复现参数

之所以选择 IndexFlatIP，原因非常简单：在归一化 embedding 的前提下，内积等价 cosine，这是最稳定、最可解释的基线方案。在你真正跑进性能瓶颈之前，没有必要引入 IVF/HNSW 之类的复杂结构。

必须保留的不变量

• chunk 切分必须稳定

  split_to_paragraph_chunks() 的行为一旦改变，paragraph_index 就会漂移，历史引用就会失效。

• chunk_id 必须与内容绑定

  推荐的策略是：hash(path + paragraph_index + content_hash)

  这样可以确保：内容一变，ID 必然变化，避免“引用幻觉”。

• meta 与 index 顺序必须严格对齐

  FAISS 向量的顺序，必须和 meta.jsonl 的行顺序一一对应，否则整个索引就不可用。

脚本 B：query_vault —— 查询并生成证据包

技术选型与原理

输入：自然语言 query

读取：_system/artifacts/vault_index/{meta.jsonl, index.faiss}

输出：

• _system/artifacts/packs/citations/<run_id>.json

• _system/artifacts/runs/<run_id>.md

核心流程是：

1. 载入 meta 与 FAISS index

2. 用同一个模型、同一种归一化方式对 query 编码

3. 先做一次宽松检索（raw_k 通常是 topk 的 10 倍以上）

4. 再进行后处理过滤：

   • scope_prefix：限制检索空间

   • exclude_temporal_note：剔除不应参与治理的内容

   • per_note_cap：避免单个文件刷屏

5. 回到原文读取 snippet（通过 paragraph_index 重切 chunk）

6. 进行轻量排序调整（docs_boost / prefix boost）

7. 生成 evidence pack（JSON）与 run note（MD），并统一写入 Derived root

这里的关键价值在于：

检索的输出不是 UI 展示结果，而是一个可以被落盘、被引用、被审计的证据对象。

必须保留的不变量

• 索引模型与查询模型必须一致

  否则 embedding 空间不一致，分数没有任何意义。

• snippet 只能是展示层

  证据的真实身份永远来自 meta（chunk_id / hash），snippet 只是为了让人读得懂。

• 所有输出必须写入 Derived root

  严格限制在 _system/artifacts/ 下，并绑定 run_id，这是保证可重放、不污染 Truth/Doc 层的关键。

最小复现 Checklist（给工程师）

1. 明确你的 Vault 输入域（1–2 个目录即可）

2. 实现一个稳定的 chunker（段落级是最优起点）

3. 定义清晰的 chunk_id 生成策略

4. 构建 index 与 meta，并保证顺序一致

5. 查询时输出的是“证据对象”，而不是路径列表

6. 加上最基本的治理过滤（per-note cap、scope）

普通搜索：找到笔记 → 人脑判断

这套系统：找到 chunk 证据 → 生成 evidence pack → 支持审计 / 引用 / LLM 分析 → 反哺真实开发

索引只是入口，真正的产物是：

可引用的证据单位，以及可以被反复使用和复查的证据包。

写个 wrapper：把 Vault 直接接入真实项目 Repo，边开发边用，边开发边反哺

你在写代码的时候，随时可以 query 自己写过的系统原则、治理规则、历史约束、失败边界；同时你在开发过程中遇到的新问题、新决策、新证据，也会被反向沉淀回 vault。两边一起增长，两边一起防止概念漂移——项目不会因为忙而忘记制度，制度也不会因为脱离实战而空转。

我目前是把 Vault 变成“项目的外置证据底座”

把 sovereign_knowledge 当成一个独立、长期存在的知识/制度库，然后在真实项目 repo 里写两个极薄的脚本：

• skq：把“开发中遇到的问题”直接扔给 vault 的 query_vault.py

• ski：在你更新了 vault 内容后，重建语义索引（index_vault.py）

这两个脚本的关键价值不是“省打字”，而是把查询变成一种开发动作：

你在写代码时，随时可以从自己的制度库里抽取证据 chunk，生成可落盘的 evidence pack，然后再把 pack 交给 LLM 或自己读，防止概念漂移。

给屏幕前程序员的复现指南

1. 把你的知识库 repo clone 到任意路径（例如 ~/sovereign_knowledge）

2. 在你的项目 repo 里放两个脚本：

   • scripts/skq（query）

   • scripts/ski（index）

3. 给执行权限：chmod +x scripts/skq scripts/ski

4. 配置一次环境变量（可选）：

   • export SK_VAULT=~/sovereign_knowledge

   • export PYTHON=python3（或 venv python）

5. 日常开发用法：

   • 更新了 vault 内容：scripts/ski

   • 写代码遇到问题：scripts/skq "run session trace ordering" --scope_prefix docs/

这就完成了“边开发边用”的闭环：你不需要把 vault 代码搬进项目，也不需要在项目里维护一套索引管线；你只需要把它当作外置制度底座，随时 query。

一个很关键的点：我为什么认为这种“外置库 + wrapper”比插件更像工程

因为它把检索的输出变成了稳定产物（pack/run note）而不是 UI 瞬时结果；也因为它把“知识治理”从笔记工具里抽离出来，变成可以进入 CI、进入审计、进入代码评审的工程对象。这就是“第二大脑”之所以能长期生长的地方：它不是靠你记得住，而是靠工具链持续生成可追溯证据。

一个多年工程经验的大哥曾经说过，LLM时代，文本和代码要一样多。但是你总不能所有的项目全部塞一个文本库吧。

最后，LLM强大的解构问题能力，设计query能力，并且从证据段中读取只字片语，生成建议的能力。这是现阶段，这个办法可以在你密集使用LLM的同时，减轻焦虑的一个办法。

Over the past few weeks, I’ve deliberately given my brain a bit of a break. I mentioned in earlier pieces that when you interact with AI at very high density—especially across multiple languages (Chinese and English) and multiple language modes (programming languages, formal languages)—you start to feel something like information overload and information drift, a kind of cognitive and even physical fatigue.

I realized I needed to switch gears, to change what I was thinking about and what I was working on. Once you drill yourself too deeply into a single tunnel, it becomes very hard to generate genuinely good ideas.

So I decided to seriously revisit someone I’ve been thinking about a lot lately: Stephen Wolfram. Why him? Because it suddenly struck me that Wolfram may be the only person over the past twenty-plus years who has consistently and explicitly talked about a paradigm shift in science. His book is literally titled The New Kind of Science.

I recently bought a copy of this book online. Before that, I had already encountered Wolfram in various forms: his work on cellular automata, Mathematica, and the concepts he keeps emphasizing—computational irreducibility, and ruliology(a term he coined himself). But to be honest, for a long time I didn’t really “get” him. I didn’t truly understand what he was doing, nor did I dig deeply into it. These ideas didn’t hit me at a fundamental, logical level; they didn’t trigger that feeling of “this is worth investing a serious amount of my limited time and mental energy into.”

I’ve also mentioned Thomas Kuhn’s The Structure of Scientific Revolutions before. Over the past few years, that book has become increasingly important to me. But what really turned “paradigm shift” into a widely discussed topic for my generation was the commercialization of AI in 2022–2023. And Stephen Wolfram had already recognized this reality very early on—and repeatedly articulated it in many of his essays, some written as early as 2005 or 2012, more than a decade ago.

In this piece, I want to share how I’ve started to re-approach Wolfram’s work. I want to try to understand computational irreducibility from his perspective, to get a feel for his way of thinking, while also using AI to track down relevant papers. Coincidentally, I also happen to have a children’s toy on my desk, brought to me by a friend from China—a code-breaking machine.

Behind this toy, there is actually an NP-complete problem. I want to study and understand this complexity problem using Wolfram’s language and worldview. Especially during these past months of high-intensity writing, I’ve often been reminded of Wittgenstein’s remarks on the relationship between language and the world. Only when you fully internalize a language system do you actually gain a new worldview and a new way of seeing problems.

Since the Day A New Kind of Science Was Published, Wolfram Has Been Surrounded by Intense Academic Controversy

In a sense, it helped that Wolfram is a commercial / entrepreneurial scientist. He largely funded himself, bypassed the traditional academic and publication systems, and didn’t need to survive on academic approval. This, in turn, has made me very interested in a certain type of people like him—corporate scientists. For example, Elon Musk is a member of the U.S. National Academy of Engineering, yet he doesn’t really participate in academia either.

Precisely because such people don’t depend on the academic system for survival, and are in fact genuinely capable scientists, their evaluations and criticisms of academia are often worth reading carefully. Especially today: when universities are flooded with low-value papers, when the meaning of academic titles is itself becoming questionable, when AI is steadily eroding universities’ monopoly over knowledge interpretation; and when governments—especially the U.S. government—are cutting research funding and openly questioning the real-world value of academic systems. Against this backdrop, perspectives from outside the system form a valuable counterbalance.

Without further ado, let me show you a few examples.

Here is an important critique of Wolfram from the mathematical community: a formal book review published in the Bulletin of the American Mathematical Society. It criticizes aspects of his argumentation, the rigor of his exposition, and the relationship between his work and existing literature. For instance, it argues that some explanations are “unclear,” “unsystematic,” or “lacking testable detail.”

https://www.ams.org/journals/bull/2003-40-01/S0273-0979-02-00970-9/S0273-0979-02-00970-9.pdf

In the complex systems and statistical physics communities, one of the sharpest criticisms can be summarized in a single phrase: “old wine in new bottles + overclaiming.” The core argument is that Wolfram repackaged many existing ideas from complexity science and computation theory, then declared a “paradigm shift” through a very strong narrative, while failing to adequately acknowledge or credit prior work. A representative voice here is Cosma Shalizi.

http://bactra.org/reviews/wolfram/

I’m not interested in adjudicating who is right or wrong. Whether it’s Wolfram or his critics, their level of scholarship is far beyond mine.

But after reading these critiques—especially after months of deliberate writing practice in both Chinese and English—I had two very strong intuitive impressions.

First, Wolfram and his critics are not even operating within the same language system. This isn’t just a disagreement of viewpoints; it’s a mismatch of language protocols, almost a case of people talking past each other entirely.

Second, these critical texts carry a very strong emotional charge. You don’t have to analyze them very deeply to sense a kind of dissatisfaction or resentment. That’s actually quite strange for a community that prides itself on being rational and dispassionate.

Over time, I started to understand this better. In the AI era, many people are labeled as “crackpot scientists” simply because they lack formal academic titles, even though they are seriously engaging with scientific problems. The emotional tone feels remarkably similar.

“Alright,” I can only say this: in the age of AI, I’d much rather be a billionaire ‘crackpot scientist’ like Wolfram than a professor or lecturer struggling to secure funding and facing an uncertain career future. 😂

How Does Wolfram Respond?

Thirteen years ago, Wolfram had already personally experienced the shock of a paradigm shift, and he described it with remarkable clarity. Calling him a “crackpot” is frankly absurd.

Let’s look at his own words, from a 2012 essay, where he describes this impact. By then, he had already largely exited academia—arguably as early as 1987, when he began building software. He explains why he stopped publishing papers: academic publishing had become overly formalistic, with form outweighing substance, while the sheer amount of real content in his work made the paper format impractical. He preferred blogging. That’s why, today, the best way to understand his thinking is simply to read Stephen Wolfram’s writings.

Why does he insist this is a “paradigm shift”?

When he recounts reactions to his work, many academics respond with unusually intense emotion:

“You’re destroying the heritage of mathematics…”

Why such anger? Would you get angry at a shaman or a yoga guru making scientific claims? No—you wouldn’t even engage. Anger only appears when something is taken seriously.

Wolfram’s response is blunt:

“This is what a paradigm shift sounds like—up close and personal.”

A paradigm shift is not primarily about new conclusions; it’s about a new evaluation system.

The emotion isn’t triggered because a theorem was overturned, but because:

• The old standards of “what counts as science” are being threatened (papers, peer review, citations, academic networks).

• Old “career investments” are being threatened (decades of training and accumulated prestige may suddenly depreciate).

He even breaks this down into two “core threatened groups,” drawing a sharp distinction between surface reasons and deeper reasons.

“There was a surface reason… and a deeper reason.”

A. Content-level fears (the career economics of paradigm conflict)

First group (mostly physicists):

“We’ve spent our whole careers barking up the wrong tree.”

If the computational perspective of NKS is right, then these researchers weren’t just “slightly wrong”—their entire research trajectory may have been a low-return investment. This is classic Kuhnian paradigm shift territory: what counted as success before may no longer count at all.

Second group (complexity researchers):

“It’ll overshadow everything we’ve done.”

This isn’t about truth; it’s about attention and authority structures—who defines the main narrative controls textbooks, funding, and disciplinary gateways.

Form-level conflict: doing something “academic-like” without following “academic rules”

“Academic-like, but you haven’t played by academic rules.”

The implicit message is that academia has a legitimacy stack:

• Peer review as gatekeeping

• References as network visibility

• Journals and publishers as distribution channels

• Academic identity as speech authorization

Wolfram’s move was to bypass this entire stack. Hence his insistence:

“I wasn’t an academic…”

This is the core tension of his essay: a new paradigm combined with a new distribution and validation mechanism, posing a dual threat to the old system.

His full essay is here:

https://writings.stephenwolfram.com/2012/05/living-a-paradigm-shift-looking-back-on-reactions-to-a-new-kind-of-science/

Kuhn Loss

Even though Kuhn’s The Structure of Scientific Revolutions is approaching a century old, it uncannily predicts the precise situation we’re discussing here. I can’t resist quoting it. The full discussion is in the SEP entry linked below.

A paradigm revolution does not merely solve more problems; it also discards—or even declares illegitimate—problems and explanations that the old paradigm valued and successfully addressed by its own standards.

This loss of explanatory power, problem sets, and evaluation criteria is what Kuhn called Kuhn loss.

Kuhn used this concept to undermine the idea that scientific progress is simply a cumulative approximation to truth.

1) What Is Actually “Lost”?

1. Problem sets change: what counts as an “important problem” changes.

2. Standards change: what counts as a “good explanation” or “good science” changes.

3. Concepts and worldviews change: the same words refer to different things, different sentences become expressible.

So Kuhn loss isn’t just “one less derivation.” It’s that things which had to be explained in the old paradigm become, in the new one:

• “Not necessary to explain”

• “Meaningless”

• “Metaphysical”

• Or outright “pseudo-problems”

This is why Kuhn says revolutions change the very definition of science.

2) A Classic Example: Why Newton “Lacked Explanatory Power” Yet Won

In Aristotelian and Cartesian mechanics, the question “How is attraction possible?” was mandatory—you had to provide a contact mechanism or ontological explanation.

Newtonian gravity looked like action at a distance and failed this test, so it was initially rejected. But once Newton’s paradigm won, that question was kicked out of the scientific agenda as illegitimate. That’s Kuhn loss.

Later, general relativity reintroduced the issue in a different form, reinforcing Kuhn’s point: progress isn’t linear accumulation; it’s repeated agenda rewriting.

3) Kuhn Loss and Incommensurability

You can think of Kuhn loss as an observable symptom of incommensurability.

Incommensurability doesn’t mean “incomparable,” but rather:

• No shared metric: different conceptual nets, problem lists, and evaluation standards.

• Hence no single unified measure of “closer to truth.”

Kuhn loss tells us that even if a new paradigm is stronger in some respects, it may be weaker in dimensions valued by the old paradigm—and whether it’s “weaker” at all depends entirely on which metric you use.

4) Why Kuhn Loss Shocks Scientific Rationality

This is why Kuhn and Feyerabend were once accused of being “anti-science”:

• If revolutions rewrite problems and standards, does rational comparison collapse into politics?

• If old successes are declared illegitimate, does science stop “approaching truth”?

Kuhn later clarified: incommensurability ≠ incomparability; Kuhn loss ≠ irrationality.

Paradigm choice lacks a neutral algorithm, but it can still be guided by values (accuracy, scope, simplicity, fruitfulness), allowing for rational disagreement.

Suddenly, that Cantonese phrase—talking past each other—feels very apt.

SEP link:

https://plato.stanford.edu/archives/fall2019/entries/incommensurability/#RevParThoKuhInc

Experiencing Irreducibility with a Decoder / Mastermind Toy

I picked up the Decoder/Mastermind toy simply because it happened to be on my desk when I was thinking about this.

A seemingly simple children’s toy hides an NP-complete problem. Originally called Mastermind, it’s a two-player board game: one player sets a secret code, the other tries to guess it.

Each round, the guesser submits a guess; the code-maker returns feedback:

• Black pegs: correct color and correct position

• White pegs: correct color, wrong position

This feedback channel must be perfectly correct and noise-free; otherwise, the entire reasoning chain collapses.

My electronic Decoder replaces the human code-maker with a hidden algorithm and adds variants: green lights (correct color and position), white lights (correct color, wrong position), and no light (color absent). In fully indirect hint mode, positional information is hidden, dramatically expanding the state space beyond brute-force feasibility.

Theoretical work confirmed this complexity: in 2005, Jeff Stuckman and Guo-Qiang Zhang proved that Mastermind is NP-complete.

https://arxiv.org/abs/cs/0512049

I spent a full day solving all 800 levels of this toy using a minimax strategy—choosing guesses that maximally reduce the candidate space in the worst case. The product itself is impressively reliable: a consumer-grade children’s toy with a completely noise-free feedback channel.

➜  giiker_super_decoder python3 minimax_generic_gwn.py --Y 7 --P 4 --R 7 --interactive-hints

=== Generic Minimax Bucket Solver (unique colors, tri-feedback) ===
Parameters: Y=7 colors, P=4 slots, R=7 total rows
Feedback: (G,W,N) with G+W+N=P
Initial candidates: |C0| = P(Y,P) = 840

--- Preset hints input (interactive) ---
Enter one hint per line as:
  guess:  a b c d    (P ints, unique, in [0..Y-1])
  fb:     G W N      (3 ints, G+W+N=P)
Type empty guess to stop.

hint guess (or empty to stop): 0 1 2 3
hint feedback (G W N): 2 1 1 
hint guess (or empty to stop): 0 6 2 1
hint feedback (G W N): 3 0 1
hint guess (or empty to stop): 

Applying preset hints: n=2  => remaining query budget T=R-n = 5
  hint#1: guess=0 1 2 3 fb=(G,W,N)=(2,1,1)  |C| 840 -> 36
  hint#2: guess=0 6 2 1 fb=(G,W,N)=(3,0,1)  |C| 36 -> 2

Step 1 (remaining queries: 5/5)
Suggested guess: 0 1 2 4
Current |C| = 2   worst_bucket=1   expected_remaining≈1.00
Enter feedback as 'G W N' (sum=4), or 'q' to quit: 2 2 0
Filtered candidates: 2 -> 1

✅ Unique solution determined without further queries: 0 4 2 1
➜  giiker_super_decoder 

All solution code is available here, including extensible solvers that go beyond the device’s original parameters:

https://github.com/STEMMOM/giiker_super_decoder

By this point, there’s little “puzzle-solving” left to say. My goal was never to solve a toy, but to revisit complexity through Wolfram’s lens.

The complexity isn’t in the rules—they’re trivial—but in the structure: a hidden truth (s), accessible only through queries that yield limited feedback. You can’t compute the answer directly; you must extract it through interaction.

From an information-theoretic view, this is a pure black-box query model. Information leaks from the hidden truth through a constrained channel. This structure pervades reality:

• Cryptography and security

• Medical diagnosis

• Scientific experimentation

• Engineering parameter tuning

The toy is kind because it promises a noise-free oracle. Reality makes no such guarantee.

Of course, I’m fully aware that I’m still at a very early stage, and that this class of problems is by no means unexplored. In fact, it has long been studied in a systematic way within academia. In theoretical computer science and in research on “puzzle complexity,” Mastermind is typically formulated as a constraint satisfaction / consistency decision problem, in its standard form known as the Mastermind Satisfiability Problem (MSP), and it has been rigorously proven to be NP-complete—a point already mentioned earlier. For the classic board-game parameters (4 positions, 6 colors, with repetition allowed), the entire state space contains only (6^4 = 1296) possibilities; as early as 1977, Knuth provided a strategy that guarantees a win in at most five moves in the worst case. My own implementation essentially operates at this same level: no more than five steps in the worst case, with reported results in the literature showing an average number of moves around four-point-something.

So within this particular scale and framework, the aspects that can be formalized, proven, and optimized have already been studied quite thoroughly. If I continue to push further, I’m more likely to approach the problem from an information-theoretic perspective—recasting it in terms of how much effective information each query can extract. Coincidentally, I also came across a very interesting recent paper today: Gür (2025), “Weighted Entropy Approach,”which uses weighted entropy as a heuristic to approach the theoretically optimal average number of steps. At its core, it treats the strategy itself as a kind of measurement instrument, an idea I find highly valuable as a reference. I won’t go into details here; interested readers can consult the original papers directly.

https://arxiv.org/abs/cs/0512049?utm_source=chatgpt.com

https://www.cs.bu.edu/fac/best/res/papers/alybull86.pdf?utm_source=chatgpt.com

https://arxiv.org/abs/2511.19446?utm_source=chatgpt.com

What I’m Really Interested In: How Wolfram Would See This Problem

A more realistic plan for me this year is to devote time to cellular automata—the true starting point of Wolfram’s worldview, beginning with A New Kind of Science. He treats them as a minimal, clean computational universe for studying complexity, irreducibility, and the fact that simple rules can generate extreme behavior.

Wolfram’s systematic, large-scale, decades-long exploration of cellular automata is essentially unmatched globally. From exhaustive rule-space scans to behavioral classification and the development of ruliology, it’s hard to find a true second example.

What continues to impress me is that one person proposed such a sweeping new scientific narrative. The key isn’t his conclusions, but his questions. When faced with Mastermind, my instinct is to solve it. Wolfram’s instinct is to ask: what kind of system is this?

Does it exhibit universal computation? Which behavior class does it belong to? Is it computationally irreducible? How common is this behavior in rule space?

Here’s the chilling thought: cellular automata are Turing complete. You’re not dealing with a solver, but a computational universe. From this comes PCE—the Principle of Computational Equivalence. I’m still digesting it, but roughly: once a system passes a very low complexity threshold, its computational power is equivalent to that of most others. The real differences lie in predictability, compressibility, and whether simulation is unavoidable.

So Wolfram isn’t anti–problem-solving. He’s reshaping the problem itself. He’s less interested in “what is the answer to this instance?” and more in “what are the behavioral laws of this system?”

In the PCE view, the “unique solution” isn’t central. What matters is whether different systems share the same class of computational capability and behavior. This worldview—almost orthogonal to the solver’s instinct—is what I’m only beginning to grasp.

This series will continue. There’s a lot here worth learning, and I’m still very early in the process.

一个把科学的“范式转移”说了20年的人。

这几周，其实我给自己的大脑放了一些假期。我在前几篇文章里提到过：当你非常密集地与 AI 交互，而且还是多语种（中文、英文）、多语言模式（编程、形式化语言）的高密度交互之后，会明显感受到一种信息过大、信息漂移的状态，一种身心上的冲击和疲惫。

我意识到我必须切换一下，给自己换一个想法，换一件事情做。人一旦钻进牛角尖，是很难产生好的创意的。

所以我打算认真研究一下这段时间我非常在意的一个人：Stephen Wolfram。为什么是他？因为我突然意识到，Stephen Wolfram 可能是过去二十多年里，唯一一个一直在谈科学“范式转移”的人。他的书名本身就叫 The New Kind of Science。

最近我刚在网上买了这本书。其实在此之前，我已经接触过 Stephen Wolfram：他的元胞机研究、Mathematica，以及他反复提到的概念——计算不可约性、Ruliology（这是他自己造的词）。但说实话，我一直没有真正看懂他，也没有真正理解他，更没有深入下去。这些概念在当时并没有在底层逻辑上击中我，没有让我产生那种“我愿意非常严肃地投入自己宝贵的时间和脑力去弄懂他”的冲动。

我以前也提到过 Kuhn 的《科学革命的结构》，这本书这几年在我心里的重要性一直在上升。但真正让“范式转移”成为我这一代人普遍讨论话题的，其实是 2022–2023 年 AI 的商业化。而 Stephen Wolfram 很早就认定了这一现实，并且在他大量的文章中反复阐述过这一点——其中不少文章写于 2005 年、2012 年，距今已经十多年了。

借这篇文章，我想分享一下我是如何重新尝试理解他的。我想站在他的角度，去理解“计算不可约性”，去体会他的思维方式；同时借助 AI 查找相关论文。恰好我手边还有一个朋友从中国带来的儿童玩具——一台密码机。

这台密码机背后，其实隐藏着一个 NP-complete 问题。我想从 Wolfram 的全新视角和语言观出发，去研究和理解这个复杂度问题。尤其是在这几个月高强度写作的过程中，我常常会想起维特根斯坦关于语言与世界关系的那些话。只有当你完全接受了一种语言体系，你其实获得了一种全新的世界观和看问题的角度。

Wolfram从the New Kind of Science 成书那一天开始，就饱受学术共同体的极大争议。

也幸亏他是商业/企业科学家，基本完全自费，绕过了传统的学术体系和发表体系，也不需要靠学术共同体活着。这一点其实让我本人非常关注一类和他相似的人——企业科学家。比如 Elon Musk，美国国家工程院院士，但他同样不混学术界。

正因为他们不依赖学术体系生存，反而是真正“有实力”的科学家，所以他们对学术界的评价和批评，往往非常值得一看。尤其是在今天这个时代：大学高校论文大量灌水，职称体系的意义本身开始变得可疑，大学正在被 AI 逐步侵蚀知识解释权；再加上以美国为首的政府开始削减学术经费，公开质疑学术系统的现实价值——在这样的背景下，这种来自体系外的视角，本身就是一种很好的平衡。

话不多说，我直接给你看几篇文章。

这是对 Wolfram 的一篇重要批评，来自数学共同体——美国数学学会 American Mathematical Society 旗下的 Bulletin of the AMS，是一篇正式的书评。文章对他的具体论证方式、表述的严密性，以及与既有文献脉络之间的关系，提出了不少批评，比如：有些解释“说不清楚 / 不成体系 / 缺乏可检验的细节”。

https://www.ams.org/journals/bull/2003-40-01/S0273-0979-02-00970-9/S0273-0979-02-00970-9.pdf?utm_source=chatgpt.com

在复杂系统和统计物理相关的圈子里，最尖锐的一类批评则集中在一句话上：“新瓶装旧酒 + 过度宣称”。核心观点是认为 Wolfram 把复杂系统和计算理论中已经存在的很多思想重新包装了一遍，然后通过非常强的叙事方式宣称“范式跃迁”，但在对既有研究的承认和归功方式上存在问题。这一类批评中，比较有代表性的声音来自 Cosma Shalizi。

http://bactra.org/reviews/wolfram/

在这里我并不想讨论谁对谁错。因为无论是 Wolfram，还是这些写下批评的学者，他们的学识都远远高于我。

但我读完这些批评之后，尤其是这几个月我因为刻意练习写作，积累了不少中英文的语言语感，我有两个非常强烈的直观感受：

第一，Wolfram 和这些批评者，从语言体系上看，根本就不在同一个系统里。不是观点分歧，而是语言协议不同，几乎是一种“鸡同鸭讲”的状态（我们广东人常说的，俩都在自说自话，无效沟通）。

第二，这些批评文本里带有非常明显的情绪。你几乎不需要太仔细分析，就能读出一种“不满”的情绪。这一点对一个自我标榜为理性、冷静的科学家群体来说，其实是挺奇怪的。

后来我慢慢也体会到了这一点。AI 时代到来之后，很多人被指责为“民科”的感觉，其实是非常相似的——泛指那些没有教授头衔、却在认真做科学问题的人。

“好吧。”

我只能说，如果是在 AI 时代，我宁愿混成 Wolfram 这种超级富翁型民科，也比现在那些向上要不到经费、职业前景朝不保夕的教授和讲师来得更实在一些😂。

Wolfram怎么回答？他在13年前，就已经亲身经历了范式转移对他的个人冲击，而且非常有条理的跟你描述了出来。

要说他是“民科”….那就真的是可笑了。

我们现在引用他本人在2012年的文章，来看看他如何描述这种冲击的。因为他其实早就脱离学术界了，我认为在1987年他开始做软件的时候，他本人应该就有这个倾向。后来他不发论文，他自己也在此文有具体的描述，总的来说就是论文套格式，形式大于实质，而他的科学”真材实料“实质实在太多了，论文发不过来。他宁愿发博客。所以我现在理解他的想法，就是看他的本人的博客，Stephen Wolfram writings.

他为什么坚持：这是“范式转移”

他谈及对他的评论，大部分学者是一种情绪强度异常的学术现场：

“You’re destroying the heritage of mathematics…”

我就说这些批评者都是很强情绪的，对于一个学者来说，为什么要发脾气？你会对一个非严肃科学，比如撒满巫师，瑜伽师提出的科学发脾气吗？不会，因为你不会去理他。

Wolfram的回答是：

this is what a paradigm shift sounds like—up close and personal.”

范式转移首先不是新结论，而是新评价体系。

所以对方的情绪不是因为某个定理被推翻，而是因为：

• 旧的“何为科学”的标准被威胁了（论文、审稿、引用、学术网络）

• 旧的“职业人生投资”被威胁了（几十年的训练路径和声望资本可能失效）

他后面把这种深层原因说得非常赤裸，甚至分成两类“核心受威胁群体”。

他明确区分“surface reason / deeper reason”。

“there was a surface reason… and a deeper reason.”

A. 内容层面的两类恐惧（这就是范式冲突的“职业学”内核）

第一类（多为物理学家）：

“we’ve spent our whole careers barking up the wrong tree”.

这句话的含义是：如果 NKS 的计算视角成立，那些人不是“错了一点”，而是整个科研投资方向可能被判定为低收益路径。

这就是 Kuhn 式范式转移里最常见的：旧范式的成功指标，在新范式里不再值钱。

第二类（复杂性研究相关的人）：

“it’ll overshadow everything we’ve done”.

这不是“真假焦虑”，这是注意力与权威结构焦虑：谁来定义主叙事，谁就拥有学科入口、教材、基金评审的话语权。

形式层面的冲突：你做了“academic-like”，但不按“academic rules”

“academic-like, but you haven’t played by academic rules.”

这里的潜台词是：学术界有一套“合法性协议栈”，包括：

• peer review 作为准入

• references 作为关系网可见性

• 大出版社/期刊体系作为分发渠道

• 学术身份作为话语资格

而 Wolfram 的路线是：我把这套协议栈绕过去了。所以你会看到他强调：

• 我不是 academic，我不受它约束：

“I wasn’t an academic…”

这其实就是他这篇文章的核心冲突：新范式 + 新分发/验证机制，对旧系统是双重威胁。

他写书和博客….

具体内容可以去看他的原文。

https://writings.stephenwolfram.com/2012/05/living-a-paradigm-shift-looking-back-on-reactions-to-a-new-kind-of-science/?utm_source=chatgpt.com

我们这里也不再展开。

Khun Loss

我说一下Khun 库恩，哪怕他那本科学革命的结构这本书快成书一个世纪，还真的是精准的预言了我们这篇文章写到现在，这个时间点的精确过度观点。我真的忍不住要引用一下。具体内容还是要看SEP原文，链接我也贴出来了。

一次范式革命不只是“多解决了一些问题”，它也会“丢掉（甚至宣布不合法）一些旧范式曾经非常看重、并且在旧标准下算是成功的问题/解释”。

这种“丢掉的解释能力/问题集/评价标准”，就是 Kuhn loss。

它是 Kuhn 用来打掉“科学进步 = 累积式逼近真理”的关键楔子之一。

1) 到底“丢”了什么

1. 问题集改变：什么算“重要问题”变了

2. 标准改变：什么算“合格解释/好科学”变了

3. 概念与世界图景改变：同一个词在两个范式里指向的东西、允许说的话、能表达的句子集合都变了

所以 Kuhn loss 不只是“少了一个推导”，而是更像：

• 旧范式里“必须解释”的东西，在新范式里变成了

  • “不需要解释”、

  • “没意义”、

  • “形而上学”、

  • 甚至“伪问题”。

这就是他为什么说革命会改变“科学的定义”。

2) 词条里的经典例子：牛顿为何“没解释力”，却赢了

SEP 用的例子很 Kuhn：

• 在 亚里士多德/笛卡尔 的力学传统里：

  “吸引力如何可能？” 是硬指标（你必须给出接触机制/本体论解释）。

• 牛顿的万有引力在当时看起来像“隔空作用”，在旧标准下是不合格的，所以会被拒绝。

但一旦牛顿范式胜出，新共同体会把这类问题 从科学议程里踢出去（说它“不合法/不科学”）。

这就是 Kuhn loss：你从旧范式的评分表看，新范式“解释力变差了”；但从新范式的评分表看，这题根本“不该做”。

然后 SEP 也补了一刀：这个问题后来在广义相对论的框架下以另一种方式“重新出现并得到处理”。这更能体现 Kuhn 的意思：不是直线累积，而是议程反复改写。

3) Kuhn loss 和“不可通约”是什么关系

你可以把 Kuhn loss 看成 不可通约（incommensurability）的一个可观察症状。

不可通约在 Kuhn 这里不是“完全不可比较”，而是：

• 没有共同度量：因为两边在用不同的概念网、不同的问题清单、不同的评价标准。

• 因此你没法用同一个“统一指标”说：A 比 B 更接近真理、或“总体更好”。

Kuhn loss 就是告诉你：

即使新范式在某些方面更强，它也可能在旧范式曾经擅长的维度上更弱——但“更弱”这件事本身是否成立，取决于你站在哪个范式的度量体系里。

4) 为什么 Kuhn loss 对“科学理性”构成刺激

这就是当年 Kuhn/Feyerabend 被骂“反科学”的原因之一：

• 如果革命会改写问题与标准，那“理性比较”是不是变成了政治斗争？

• 如果旧成功会被新范式宣布不合法，那科学是不是不再“逼近真理”？

SEP 也强调了 Kuhn 后来的澄清：

不可通约 ≠ 不可比较；Kuhn loss ≠ 非理性。

Kuhn 的立场更像：

• 范式选择没有“中立算法”，但仍可用一组价值（accuracy/scope/simplicity/fruitfulness…）来做“有理由的争论”；

• 不同人对这些价值的权重不同 → 允许“理性分歧”。

又回到了广东人的那句俗语：鸡同鸭讲，是不是变得更贴切了？

https://plato.stanford.edu/archives/fall2019/entries/incommensurability/#RevParThoKuhInc

我随手拿了一个decoder/mastermind玩具来体验不可约

真的是因为我想到这一点的时候，这个玩具刚好就在我书桌上而已。

一个看似简单的儿童玩具，背后其实隐藏着一个 NP-complete 级别的问题。它最早的名字叫 Mastermind：一款需要两个人参与的桌游——一个人负责“设密码”，另一个人负责“猜密码”。

规则很直接：设密码者先选定一组颜色/位置组成的密码并隐藏起来；猜密码者需要在有限回合内（也就是棋盘给定的槽位/回合数限制）把它猜中。若能在限制回合内猜中，猜密码者胜；否则设密码者胜。

每一回合，猜密码者提交一个猜测，设密码者必须给出反馈。经典反馈形式是黑钉/白钉：

• 黑钉：颜色正确且位置正确；

• 白钉：颜色正确但位置不正确。

本质上，这是一条“反馈信道”，而且它必须严格满足规则——完全正确、无噪音，否则整个推理链就会崩掉。

我手上的这个电子版 Decoder 可以看作是 Mastermind 的升级版：它把“设密码的人”替换成了设备内部的隐藏算法，并且加入了更多变体反馈机制，比如：

• 绿灯表示颜色和位置都正确，

• 白灯表示颜色正确但位置不对，

• 不亮表示这种颜色根本不在密码里（或者等价地表示“颜色也不正确”的数量）。

在完全 indirect hint 的单机模式下，玩家甚至看不到位置信息——这会让状态空间急剧膨胀，远远超出 brute force 直接穷举的可行范围。而从理论上说，这背后的复杂性并不是“感觉上很难”这么简单：在 2005 年，Jeff Stuckman 和 Guo-Qiang Zhang 的论文证明了 Mastermind 是 NP-complete。

https://arxiv.org/abs/cs/0512049?utm_source=chatgpt.com

好，用了一整天的时间，我把这个玩具范围内的 800 个关卡全部解完了。我采用的是 minimax 策略：每一步选择在最坏情况下能最大幅度压缩候选空间的猜测，而不是追求“看起来聪明”的局部最优。

这里必须认真夸一句——这款来自中国计科公司的玩具产品做得非常扎实。它的反馈信道高度可靠、完全无噪声，严格遵守规则约定。能在一个面向儿童的消费级玩具里，把反馈一致性和规则执行做到这种程度，其实很厉害。

所有解法的 repo 我都已经放出来了：

不仅包含针对这台设备本身配置的求解器，也包括可扩展的通用解法，能够支持比原机更大的颜色空间和更多变体规则。可以直接复用、改参数就能跑。

就当是给订阅者的一个小福利吧。虽然我写的文章通常都很长、也不怎么“友好”，但这个玩具倒是个很好的切入口——你可以买一个给孩子，让他自己认真玩几天；等他真的卡住、开始怀疑人生的时候，你再掏出这套算法，几百关轻松带过。

他大概率会觉得你特别厉害。

从实用角度讲，这可能也是一种让小孩子突然很喜欢你的办法。

https://github.com/STEMMOM/giiker_super_decoder

玩到这个阶段，其实已经没什么“解题意义”可再展开了：一个儿童玩具，被完整求解，全部关卡通关。它在理论上当然是 NP-complete，但在这个被严格限制的规模内，五步之内必然可解。然而，这从来不是我的真正目标。我并不是想证明我解决了一个儿童玩具，而是想站在 Wolfram 的视角重新审视复杂性本身。

这里的复杂性并不来自规则——规则极其简单——而是来自这样一种结构：存在一个被隐藏的真值 (s)（密码、答案），你每一次只能提交一个 guess，系统返回一个反馈（G/W/N），你必须在有限轮数内把这个 (s) 反演出来。你想直接算出答案，却永远缺少关键信息；而你获得信息的唯一方式，是不断发起查询并接收反馈。答案不是从规则中推导出来的，而是从交互过程中被迫挖出来的。

从信息论的角度看，这个模型异常纯粹：信息单向地从隐藏真值向外泄露，困难不在于规则复杂，而在于信息被锁在一个 oracle（反馈器）后面；本质上，这是一个标准的黑箱查询问题——你每一步都在用一次 query，换取极其有限的 bit。这种结构并不只存在于玩具中，它在现实世界里广泛存在，而且复杂性往往呈指数级放大。玩具的“仁慈”在于：你被明确告知反馈信道是完全无噪声的，规则被严格执行，oracle 不会撒谎；而现实中，有谁说了反馈一定是真实的？无噪的？于是，真正值得思考的对象就变成了这个你无法看到内部机制的黑箱：你只能向它提出查询，它只返回一个反馈，而整个复杂性，正是从这种受限、单向、被遮蔽的信息交互中自然涌现出来的。

• 安全/密码学：你对系统内部状态未知，只能试探/探测（queries）

• 诊断/医学：你不知道病因，只能做检查（queries）来缩小候选

• 科学实验：你不知道规律，只能做实验（queries）得到观测，逐步收敛

• 工程调参：你不知道最佳配置，只能试运行（queries）拿到反馈再更新

当然，我也很清楚自己还处在一个非常早期的阶段，而且这类问题并不是无人涉足。事实上，在学界它早已被系统化地研究过。在理论计算机科学和“谜题复杂度”相关的研究中，Mastermind 通常被表述为一种约束满足 / 一致性判定问题，标准形式被称为 Mastermind Satisfiability Problem（MSP），并且已经被严格证明是 NP-complete——这一点前面其实已经交代过了。就经典桌游参数而言（4 位、6 种颜色、允许重复），整个状态空间只有 (6^4 = 1296) 种可能；早在 1977 年，Knuth 就给出了一个最坏情况 5 步必胜的策略。我的实现本质上也是这个级别：最坏不超过 5 步，而且我看到的文献里给出的统计结果，平均步数大概在 4 点多。所以在这个规模和框架之内，能被形式化、能被证明、能被优化的部分，其实已经被研究得相当充分了。我接下来如果继续推进，更可能会从信息熵的角度入手，把问题重新表述成“每一步查询能榨取多少有效信息”的问题。也正好，今天还偶然看到一篇挺有意思的新论文：Gür（2025）的 Weighted Entropy Approach，用加权熵作为启发式，逼近理论最优的平均步数，本质上也是把“策略”当成一种测量仪器来设计，这个思路对我来说非常有参考价值。这里就不展开了，有兴趣的可以直接去读原文。

https://arxiv.org/abs/cs/0512049?utm_source=chatgpt.com

https://www.cs.bu.edu/fac/best/res/papers/alybull86.pdf?utm_source=chatgpt.com

https://arxiv.org/abs/2511.19446?utm_source=chatgpt.com

我感兴趣的是 Wolfram会怎么看待这种问题

当然，更现实、也更符合我今年节奏的做法，是把一部分时间真正投向元胞机本身。因为在我看来，这条线索几乎是一切的起点——起点就在 A New Kind of Science。无论是那本书本身，还是此后 Wolfram 持续二十多年发表的大量文章、讲座与补充材料，核心对象的起点在元胞机。我感觉他是把它当作一种最小、最干净的计算宇宙，用来正面研究复杂性、不可约性、以及“规则极简但行为极端复杂”这一事实本身。在这条路线上，Stephen Wolfram 对元胞机的系统性、规模化、长期投入，几乎是全球独一无二的——不论是规则空间的全面扫描、演化分类、计算不可约性的提出，还是后来发展出的 ruliology 视角，在全球范围内都很难找到真正意义上的“第二家”。所以我肯定也会持续在这条上学习。

我一直觉得，Wolfram 所谓的“新科学范式”，在他当年以一个人的身份提出这样一个宏大的叙事，本身就已经非常了不起了——而且我绝对不是唯一一个对此产生强烈震动的人。关键不在于他说了什么“结论”，而在于他到底在问什么问题。你看，同样是拿到 Mastermind / Decoder 这个游戏，我的第一反应肯定是：求解。这当然很自然——计算的目的之一，难道不就是求解吗？世界里似乎存在一个“真相”，一个唯一的 secret code（或者一个极小的候选集合）；成功的指标也非常清楚：用尽量少的步数把答案锁定下来，追求收敛、收束、最短路径。这套思路在复杂度理论里再熟悉不过了：CSP / SAT / 搜索问题，加上一点策略优化，所有评价指标都围绕“最快定位唯一解”。（突然想感慨一下，好做题家的思维啊….)

但如果换成 Stephen Wolfram 的视角，问题的重心会发生明显偏移。他关心的往往不是“这个实例的答案是什么”，而是：这个规则系统本身会长成什么样。比如：它会不会涌现出普适计算能力？它的整体行为属于哪一类（简单、周期、混沌、复杂）？它有没有“捷径”，还是说本质上是计算不可约的？在整个规则空间里，这种行为到底是稀有的，还是普遍存在的？在这个框架下，成功的指标不再是“锁定唯一解”，而是发现结构现象、分类现象、识别生成机制，并回答“为什么这种现象在规则宇宙中如此常见”。

有一个让人稍微有点“背脊发凉”的念头, 我想到：元胞机是图灵完备的。这意味着你面对的不是一个“解题器”，而是一个潜在的计算宇宙。围绕这一点，Wolfram 提出了 PCE（Principle of Computational Equivalence）——说实话，这个原则我自己目前也还在消化之中，但它大致在说：一旦系统的行为超过某个极低的复杂性阈值，它们在计算能力上往往是等价的。换句话说，“能算的都差不多一样能算”，区别不在于是否强大，而在于是否可预测、是否可压缩、是否必须一步步模拟。

所以，Wolfram 并不是不“求解”，而是彻底换了问题的形状。他不是在问：“这个具体实例的答案是什么？”他更常问的是：“这个系统的行为规律是什么？”在同样是“给定规则 + 初态”的前提下，他未必在意你是否把系统推进到第 N 步、得到某一个确定图像；他可能更关心的是：能否预测某些统计量（密度、熵率、结构压缩率），能否证明或通过经验判断“只有模拟才能知道结果”，以及能否把一个看似完全不同的问题编译进这个系统，从而显示它的普适性。在 PCE 的视角里，“唯一解”从来不是中心问题；真正居中的，是不同系统是否共享同一类计算能力、同一类行为类型。这正是我开始慢慢意识到的、与“解题直觉”几乎正交的一种世界观。

这个系列我会持续更新，这是一个值得长期学习和探讨的议题。说实话我的认识目前还算很浅。

“AI will definitely replace white-collar workers; white-collar work is finished.”

This argument commits a classic error of time and game-structure reasoning: it treats a final outcome judgment as a judgment of the current state.

Everyone is talking about AI replacing white-collar workers, but I believe this judgment itself misses something extremely important.

Let me use an analogy.

Imagine a ninth-dan Go player playing against a beginner. The ninth-dan plays Black; the novice plays White. Of course, from overall strength and win probability, we all know Black has a huge advantage. But here is the problem: Black has only placed the very first stone, and you already declare that White has lost. Is that reasonable? Is that correct? No matter how weak White is, he hasn’t even made a move yet.

In Chinese, the word “game” (博弈) fundamentally refers to a process of play unfolding over time between Black and White. Even if Black eventually establishes a winning position in the midgame, that still requires at least 180 moves to unfold. And it is precisely in this long midgame—where Black is highly likely to win, yet the outcome is not yet settled—that a massive amount of important information is hidden and routinely ignored.

Over the past two years, I have listened to many startup ideas around so-called “AI-native software and systems.” I agree with much of their reasoning and internal logic. But I also feel that we can describe the direction we are all seeing far more clearly. That direction lies exactly in the reasoning I am about to explain. Although Black appears to be winning, it still must actually play out those 180 moves over time to establish that victory. This game is long, and the structure of human society cannot be reduced to a simplistic narrative like:

“A master arrives, plays one move, and wins.”

Such a narrative skips over time, skips over process, and skips over a vast amount of critical information. I believe that many truly meaningful AI-native systems will not land at the moment of final judgment, but precisely within this long, easily overlooked process of play.

Why upper-tier white-collar professionals are the backbone of society is not simply textbook knowledge

You must understand their role as institutional interfaces.

In modern, globalized industrial systems—highly complex systems by nature—the white-collar class spans both developing and developed countries and serves as the backbone of institutional operation. Changes to its production relations are, in essence, a long-duration, multi-round, high-risk game.

In such a game, every single move by either side carries concrete opportunities and costs. This is not merely about coding ability, generative text, problem-solving, or prompt writing. Right now, people are still copying and pasting in chat windows—so claiming that this ecosystem can already replace the white-collar ecosystem is plainly premature.

Take licensed professions such as lawyers and accountants as examples.

Their high training cost is not because they write more documents or memorize more rules, but because they occupy institutionally recognized positions of decision-making and responsibility.

The value of these professions rests on a deep, implicit social rule:

You can trust them, because if something goes wrong, they are responsible.

This “responsibility” is not abstract. It is institutionalized: professional discipline, civil liability, and even criminal liability.

For this reason, these professions do not demand one-off task execution ability; they require long-term training to become stable bearers of risk. Practitioners must make judgments under uncertainty and bear consequences in regulatory gray zones.

Many tasks appear transactional on the surface—bookkeeping, tax filing, drafting contracts, writing memos.

But what is truly expensive and truly scarce is the judgment embedded within them:

• When must you clearly say “no”?

• When can a “controlled exception” be allowed?

• How should conflicts between rules be interpreted and resolved?

• When risk cannot be eliminated, how do you assume it rather than evade it?

This kind of judgment is neither procedural nor templated. It is deeply human. Language models that remain at the level of “window-based interaction” do not occupy this institutional position of gray-area judgment.

From a broader perspective, these professions are institutional interfaces. They were not designed from scratch; they emerged through centuries of industrialization, through continuous friction and evolution between production and production relations—across Western industrial history and global economic rebalancing.

What is their core asset? Is it merely textbook knowledge? Of course not. It is:

reputation + track record

Track record is a time-based asset.

You must pass through enough real situations, mistakes, post-mortems, and disciplinary constraints to earn trust. In moments that are truly irreversible and life-defining, would you trust an instantly generated output—or a veteran expert with decades of proven judgment?

This is why many white-collar professions impose systemic barriers:

• Exams

• Licenses

• Continuing education

• Long-term training within firms or institutions

At their core, these barriers do only two things:

1. Filtering: minimizing unstable individuals in high-responsibility roles

2. Binding: binding individuals to professional disciplinary systems (punishable, accountable)

In other words, certification does not merely prove “you know”; it more importantly proves “you can be constrained by institutions.”

Many engineers and programmers—especially those from hard-science backgrounds—tend to hold overly simplified worldviews and are deeply accustomed to believing that problems have absolute right answers. But real-world games are far more difficult than Olympiad math problems that high-school graduates can solve.

“AI can’t replace white-collar workers because no one can take the blame.”

I believe this counterargument is also crude and incorrect. Designing blame-taking mechanisms is not difficult—digital signatures, human overrides, and so on. What is truly difficult is training a decision-making entity to be continuously constrained by institutions, repeatedly tested by history, and gradually trusted by society over long spans of time. That is precisely the hardest part of the game where Black appears to be winning, yet still must play out all 180 moves.

The road must be walked step by step; the stones must be placed one by one. As programmers, if we believe in this path, then the real opportunity lies in the process of the game—not in declaring “you’ve already lost, so let’s all lie flat.” That attitude just guarantees that, decades later, the true structural opportunities will already have passed you by.

What makes this AI wave truly “magical” is that it emerged as a full-domain technology

Teachers use it; students use it.

Law firms use it; accountants use it.

Programmers use it; novelists use it.

Finance uses it; medicine uses it—astonishingly, even outpatient doctors ask GPT.

It can write reports, revise contracts, generate structured documents, and even produce full formal languages end-to-end.

A technology that appears and immediately covers nearly all cognitive professions is extraordinarily rare in the history of technology. While I am not a professional historian, I have long studied the history of technology out of personal interest. Most major breakthroughs followed the opposite path: they first broke through a vertical domain, then slowly diffused outward. Steam power, electricity, computers, and the internet all followed this pattern. If I had to find a close analogy, the only one that comes to mind is the printing press.

This is why the intuition that “AI will replace all white-collar work” is so compelling—it arises directly from the visual shock of this full-domain coverage. I felt it myself. As a bilingual person who reads programming languages and formal languages, I suddenly saw all my linguistic interfaces covered at once. Every channel to the world seemed captured. For a moment, it felt omnipotent.

LLMs now command nearly all human language forms—and language is the universal interface of every industry. When a technology suddenly covers all interfaces, a natural illusion emerges:

Does this mean every profession attached to these interfaces will be replaced wholesale?

But this is precisely where the mistake lies. After 2016, my view of LLMs became increasingly grounded and skeptical.

I fully agree: AI’s coverage of white-collar work is real.

This “full-domain” nature exists not only because AI understands professional knowledge, but because language itself spans all industries. Contracts, reports, medical records, papers, manuals, code comments, meeting notes—most visible white-collar outputs are linguistic.

But coverage is not replacement.

The moment you move from “it looks like it can do the work” to “it replaces production relations,” complexity explodes. Nearly all discussions of AI replacing white-collar workers skip critical steps here. I have read countless analyses, videos, and startup narratives, yet almost none clearly explain the replacement mechanism itself. To do so, one must first answer a harder question:

What is the cross-industry, stable operating mechanism of white-collar work today?

White-collar work does not exist because people can write. Language is only the surface. The underlying logic includes:

• How decisions are authorized

• How risk is distributed

• How responsibility is traced

• How judgment is accepted under uncertainty

• How errors are absorbed institutionally rather than causing systemic collapse

Only after clarifying this long-term, cross-industry operating mechanism can we ask the next question:

Can AI—and how—fully take over this mechanism?

Most “replacement” arguments stop at:

“It generates faster / better / cheaper.”

But jumping from improved generation to wholesale replacement skips dozens of steps: institutions, responsibility, trust, time, risk, governance, accountability, replay. Almost all are ignored.

The universal operating mechanism of white-collar work: transactional flow mixed with decision-making

White-collar work is neither pure decision nor pure execution. It is a remarkably stable structure:

Transactional processes densely interwoven with decision nodes.

By “transactional work,” I mean something very plain—even unflattering: tasks you do daily that require little deep thinking but must be performed repeatedly and accurately. In English, I would simply call them transactional tasks.

They make up the bulk of daily white-collar work:

• Were the emails sent?

• Were meeting notes written?

• Was the revised version synced to everyone?

• Was the report updated to the template?

• Where is the approval workflow?

• Is this the latest contract version?

• Has the client confirmed?

• Has legal reviewed it?

• Were compliance comments incorporated?

You could argue that a white-collar worker spends 80% of their day on such tasks. They are repetitive, tedious, standardized, and look nothing like “high-value work.” This is precisely why LLM performance here feels so terrifying: email drafting, document editing, summarization, formatting—once you supply context, LLMs overwhelmingly outperform humans.

But if you observe closely, you will see that these transactional flows are saturated with non-explicit decision points. These are not “A or B” decisions, but micro-judgments embedded in execution:

• Should this email be sent now?

• Should this person be CC’d?

• Should the wording be conservative or aggressive?

• Will raising this issue now introduce unnecessary risk?

• Should this be left ambiguous for the next phase?

• Should this be escalated?

• Should this be explicitly fixed in writing or left interpretable?

These judgments occur inside execution, not as separate decision events.

In other words, the true shape of white-collar work is this:

Continuous execution punctuated by small but irreversible judgments.

And that is the layer most replacement narratives fail to see.

LLMs are a no-blind-spot, crushing advantage for white-collar transactional workflows.

Across virtually every industry, as long as you provide enough context, specify constraints (even though prompts are “soft constraints”), and—importantly—stay within the boundaries of that context, without requiring the model to span the entire complexity of the full system engineering landscape (for example, without needing to “read the entire legal code”), then the output quality for transactional workflows is simply overwhelming. This is because a huge portion of white-collar time used to be spent on exactly these transactional processes—take legal statements, for instance, where every single word and every citation must be carefully assembled.

LLMs happen to land precisely on the core computational structure of white-collar transactional work:

language-type transactions = generating acceptable text / structured expression under constraints.

As long as you fill in the context, state the goal clearly, provide enough boundary conditions and formatting constraints (even if a prompt is only a soft constraint—I’ll explain later the difference between soft constraints and hard constraints; only real programming and executable formal languages truly achieve what I mean by “hard constraints”), and keep the task within a “context-closed” scope (i.e., not demanding global system-level complexity), then this category of output is almost naturally the LLM’s home turf.

It can generate large volumes of acceptable text in very short time: consistent genre, stable tone, complete structure, standardized formatting, uniform citation style. And it can iterate repeatedly based on your instructions—localized rewrites, template alignment, gap-filling, denoising and compression.

In traditional white-collar systems, this type of work occupies an enormous share of time:

• Lawyers writing statements, memos, clauses, correspondence

• Accountants writing report footnotes, explanations, reconciliation notes

• Consultants writing decks, analytical summaries, meeting notes

• HR writing job descriptions, performance reviews, policy documents

• Product managers writing PRDs, alignment emails, release notes

In the past, this work looked “hard” and consumed huge amounts of time. But the “hardness” often wasn’t about deep thinking—it was the kind of difficulty that comes from “making the homework look polished and error-free.” Deliverable, readable, reusable, reviewable, traceable—the tone of every sentence, the formatting of every citation, the risk posture embedded in every phrase, the completeness of every section—each of these consumes human attention and energy.

Humans are, in a sense, consciousnesses better suited for creativity, passion, and imagination. In contrast, the LLM’s advantage is that it is essentially an extremely powerful language-structure generator. For “mass production within constraints,” it has near-physical scale advantages: no fatigue, parallelizable, endlessly rewritable, alignable, able to produce multiple versions simultaneously—while driving the “linguistic friction cost” of manual white-collar labor down to near zero.

At this point, LLMs have effectively smashed the marginal cost across the entire chain of “writing → organizing → formatting → revising → paraphrasing → summarizing → templated expression.” Many roles historically had to invest time not because these actions were inherently “high value,” but because organizations needed these artifacts as collaboration media and as institutional evidence. Now, artifact production has been suddenly industrialized—which is exactly why people get the sensation that “the whole industry will be replaced.”

A friend of mine calls this:

“The industrialization of language.”

And I largely agree.

White-collar workers look like they’re just copy-pasting in a window, but they’ve embedded decisions into prompts and context. So even if LLMs do all the dirty work, decision-making is still indispensable.

White-collar work naturally fuses transactional workflows with decision-making. So if an LLM can only handle transactional workflows, is the “copy-paste in a chat window” pattern sufficient to replace white-collar workers?

No.

“Copy-paste in a window + let the LLM do the work” is merely outsourcing transactions; it does not automatically erase the core value of white-collar work. Many white-collar workers today appear to be doing “low-level operations,” but in reality they are embedding the truly expensive thing—decisions—in a subtle way into prompts, context, constraints, sequencing, and trade-offs. On the surface, it looks like the LLM is writing, revising, producing drafts; in essence, humans are performing institutionalized judgment, while the LLM is being used as an extremely powerful transactional executor.

More rigorously: “decision” in white-collar work is not a single button, not a moment where someone says “please decide now.” It is distributed across the entire transactional chain as continuous micro-decisions.

When you write an email: who to CC, how hard the language should be, how explicitly to state risk, whether to leave wiggle room, where to place responsibility, how to set timelines—these are not just language skills, but judgments about organizational structure, risk tolerance, and boundaries of authority and responsibility.

When you draft contract clauses: do you use “must” or “should”? Do you lock it down or leave interpretive space? Do you place exceptions in the main text or in an appendix? Do you require the other party’s commitment before granting rights? Every word becomes a carrier of decision.

When you prepare reports or compliance explanations: which numbers must be explained, which risks must be disclosed early, which assumptions must be explicit, and which can be glossed over as “industry convention”—these, too, are judgments, not mere transactions.

Embedding decisions into context means writing into the boundary conditions of text generation: “which version of reality am I willing to be responsible for?” What the LLM crushes is the ability to produce deliverable text within defined boundaries. But the boundaries themselves, priorities, risk posture, exception strategy—these still require a subject that can be held accountable, can be reviewed, and can bear consequences under uncertainty.

So the answer to “If an LLM can handle transactional workflows, can it replace white-collar workers?” depends on what you mean by “replacement.”

If you mean replacing labor volume—reducing the physical work of drafting, organizing, filing, alignment, revision—then the window pattern can already replace a large share of the “visible labor” of white-collar work, and it will rapidly change headcount structures.

But if you mean replacing occupational function—replacing the “decision interface” that is authorized inside organizations, bound to risk bearing, constrained by institutions, and that accumulates reputation over long trajectories—then the window pattern is far from enough. Because the essence of the window pattern is: decisions remain in human heads; only transactions are outsourced to the model. When you hit gray zones, conflicts, irreversible consequences, situations requiring endorsement and responsibility, humans still must “sign the decision out” into the world—otherwise the system cannot close the loop.

The Window Paradox

There is an even deeper paradox: the stronger the window becomes, the more white-collar work shifts from “writing” toward “judging.” When the cost of writing approaches zero, what becomes scarce is no longer text production, but: who sets boundaries, who bears consequences, who is responsible for exceptions, who interprets conflicts, who conducts post-mortems and accepts disciplinary constraint.

In other words, LLMs will evaporate white-collar transactional labor, but simultaneously make the institutional core of white-collar work more visible: traceability of judgment and responsibility.

If I had to predict: many positions will indeed disappear, but “super-positions” will appear—concentrating the decisions that used to be distributed across those disappearing roles into a single super node.

So what’s the takeaway for engineers?

At minimum, in this game where AI as Black crushes global white-collar labor as White, we must find the system entry point.

Not to build a stronger “writing machine,” but to build a system structure that can carry decision and responsibility.

1) Stop crowding into the transactional layer: it’s already a crushing zone.

Transactional workflows—writing docs, organizing materials, formatting alignment, generating versions, adding explanations, running processes—are already the LLM’s absolute home turf.

As engineers, building “better prompt tools,” “smoother document generators,” “faster report assistants,” is, from a system perspective, mostly incremental innovation in a red ocean. We’ve already seen many teams crowd in early—report generation, summarization, storybooks with images; even vertical transactional pipelines like generating textbooks or question banks. It’s not that these products have zero value, but:

• It’s hard to form durable moats

• Model capabilities themselves will absorb them quickly

• They rarely reshape production relations

If you choose the transactional layer as your entry point, you are essentially pushing against the model’s natural capability gradient.

2) The real gap: how decisions are caught.

Return to the core judgment: LLMs can evaporate transactional labor at scale, but they will not—and cannot—automatically absorb judgment and responsibility.

So where do those go? They don’t disappear. In reality, they rapidly concentrate into a small number of nodes—so-called “super-positions,” a handful of people, and those critical locations that must be institutionally recognized and must be able to “carry the load.” And in my view, this is exactly the entry window for engineers.

Decision-making in human systems is almost equivalent to “the meaning of time itself.”

Any meaningful process, any system that can keep running, is fundamentally a network of nodes and connections. And in that network, what truly determines direction is not the flows, but the decisions that sit on key nodes. Transactions are just the connecting lines.

For an individual, major decisions shape a life trajectory.

For a family, key choices determine intergenerational fate.

For an organization, decisions define strategy, risk, success, and failure.

For society and history, decisions are the inflection points of victory and defeat.

Now, this time-flowing network is being injected with a new form of intelligence: AI. Transactions can be automated; paths can be accelerated; but the nodes still exist—and become more important.

Who catches these nodes? Who is responsible for the judgments made at those nodes?

This is where engineering must intervene.

The engineering goal is to give decision itself a system form:

Make decisions explicitly expressible, stably recorded, institutionally constrained, post-mortem replayable, and—when necessary—migratable, inheritable, and reusable.

Standing at this moment, looking forward, I feel strongly that this is not something you solve by “adding a feature.” It represents an entire class of system opportunities:

A new kind of infrastructure to carry judgment, responsibility, and time—

not merely to improve efficiency, generate content, or optimize workflows (all of which will eventually be absorbed by model capability).

3) What do system-level entry points look like?

If you translate the “institutional core” of white-collar work into engineering objects, you can see at least five implementable directions:

1. Decision as Object

   Today many key judgments are “embedded in prompts” and not traceable. The first step is to turn “why I decided this way” from implicit context into explicit objects.

2. Responsibility Binding

   The classic “who takes the blame” question. In fact, this is often the easiest part: who is the owner, who is the reviewer, who has override authority?

3. Decision Logs and Replayability (Trace & Replay)

   Engineering can turn judgment itself into a reusable asset rather than something that drifts away inside a chat window.

4. Exception Engineering

   The real world is not a rule engine. The complexity of production relations and politics cannot be captured by simple if-else. Systems must support:

• explicitly allowing exceptions

• forcibly recording justification

• requiring post-mortem review

This is the core work area of human judgment—and the weakest area of LLMs.

Any system that can “carry the load” must satisfy the principle of Minimum Engineering

Whether it’s a human system, a machine system, or a human-machine hybrid—once it enters the responsibility domain, it must satisfy a non-negotiable baseline:

Key system actions must be determinable, recorded, replayable, and accountable.

The emphasis isn’t on “who the system is,” but on “whether the system can be constrained.” Whether it is a human expert, a committee, an algorithm, an AI agent, or any hybrid form—identity does not automatically grant trust. What determines trust is whether it meets engineering constraints.

Take human experts: what does a signature mean? It means the person bears institutional consequences. If they violate the law, can they be sued? Of course. But what does a lawsuit rely on? Evidence. Where does evidence come from? Verifiable records, traceable chains, facts that third parties can understand and reconstruct. Without these, “responsibility” becomes a joke—unenforceable, unarbitrable.

No serious society allows key facts to “dissolve into a chat window.” Do companies keep accounting vouchers, ledgers, audit working papers, tax bases in chat windows? No. In many countries, ledger and voucher requirements are strict: retention, formatting, preservation periods, audit requirements. Compliance exists precisely because it can be audited, reviewed, and held accountable. Build an accounting/tax system and you must meet domestic standards and regulatory requirements. Once such a system introduces AI—or becomes AI-native—it does not become “less responsible”; it makes the responsibility domain more complex: more automation, faster iteration, and larger scale effects enlarge blast radius, and push accountability engineering requirements harder.

So this is a long-cycle evolution spanning computer science, institutional design, social consensus, and regulatory governance. Based on my study of technology history, it is often a ten-year or multi-decade system project. I’m seriously trying to find my livelihood for the coming decades—this is not empty talk. Writing essays isn’t my main job.

Responsibility = time + record + structure + explainability

• Time: when the action happened, based on what information and rules

• Record: whether key facts are solidified into verifiable artifacts

• Structure: whether facts are organized in stable, machine-parseable form

• Explainability: whether third parties can understand, review, and reconstruct the decision path and basis

Therefore, any long-term system that can “carry the load” must contain at minimum these five elements—none can be missing:

1. Action Object

   What exactly was done? Was the output “frozen” into an identifiable, referencable, auditable object rather than a floating text stream?

2. Actor

   Who initiated, who approved, who had authority, who bears consequences? The actor must be identifiable, bindable, and punishable.

3. Time Anchor

   When does it take effect? Which version of policy/rules applied at the time? Time anchoring is a prerequisite for post-mortems and arbitration.

4. Replayable Trace / Log

   Can you reproduce the inputs, basis, and path? Can you recompute after the fact, compare, and locate deviations? Without replay (and yes, replay is not the same as re-run), you have no correction capability.

5. Failure Mode

   What happens when it’s wrong? How are exceptions approved? How are risks escalated? How are post-mortems triggered? Load-bearing systems assume they will be wrong and engineer error handling explicitly.

Because of this derivation, I strongly reject a popular claim:

“LLMs are probabilistic and uncertain, so we must accept an uncertain future.”

That might be acceptable in consumer applications—who cares if the person in a generated video wears red or green. But in the responsibility domain, it’s dangerous. Serious production, serious institutional evolution, serious change in production relations cannot be built on the premise of abandoning determinism. Any real systemic change that pushes society forward must return to one base:

Build on the maximum determinism humans can accept, to carry large-scale collaboration and responsibility.

An AI that cannot “carry the load” is just a language bot—it cannot justify trillion-dollar valuations.

In essence, the LLM window is still “running naked.”

If we apply the minimum-engineering standard to how white-collar workers use LLMs today, we see that the window is still naked. Break down the common pattern—Prompt → Copy → Paste—and strip away every part that actually enters the responsibility domain:

• structured data committed into ERP / finance systems

• emails formally sent, archived, and auditable

• signed documents that pass approval workflows

• contract texts stored in contract systems with legal effect

• any institutional record that can be held accountable, replayed, and arbitrated

Then you see it:

The LLM window, in real economic operation, is basically running naked.

The generation process inside the window bears no responsibility and cannot carry responsibility. It has no stable action object, no frozen decision record, no clear actor, no time anchor, no replayable institutional log. Once separated from those “systems that ultimately catch it” —ERP, email systems, contract systems, approval systems, ledger systems—everything that happened in the window is, in engineering terms, as if it never happened.

What carries responsibility is not the window, but the institutional systems outside the window.

White-collar workers are not “making decisions in the window.” They are using the window for cognitive processing: organizing thoughts, generating candidate drafts, simulating alternative phrasings, searching for structural and tonal optima. Once they enter the stage where something must take effect externally and consequences must be borne, they leave the window and re-enter a system that satisfies minimum engineering requirements.

That’s why—even if the window is brilliant, efficient, and stunning—it remains, in serious economic activity, a non-responsibility system. It can drastically improve transactional efficiency, but it is not a responsibility node that can be trusted.

In other words:

White-collar workers are not “carrying the load in the window.” They carry the load outside the window.

The window only reduces the cost of thinking, probing, simulating, and expression. What determines whether something can enter the real world—into ledgers, contracts, law, and institutional chains—remains those systems that satisfy minimum engineering principles.

In the era when AI-native systems become a trend, the programmer’s job is to put clothes on this powerful system that is still “running naked.”

As AI-native systems begin to take shape, the real task for application-level engineers is not to keep amplifying what this system can already do. It is to face a deeper, harder reality: a system that is extraordinarily powerful in cognition and generation is still “naked” today.

It lacks responsibility anchors, institutional interfaces, and traceable historical structure—so it cannot truly be integrated into real-world production and governance. Part of the programmer’s work is to dress this already-arrived but still-unconstrained power—using engineering structure to carry judgment, using records to fix actions, using a time axis to constrain evolution, using responsibility mechanisms to connect to law, compliance, and social consensus.

This is an inevitably long-term engineering project spanning computer engineering, institutional design, and social coordination. Once you enter the responsibility domain, the time scale cannot be “a few months of product iteration.” It must be ten years, twenty years, or longer. Every technology that truly changed production relations went through this path: capability first appears, order is built afterward, and productivity must be institutionalized to become sustainable social power.

AI today stands at this threshold. I have never denied the greatness of this transformation: capability has exploded, but responsibility has not landed; tools have formed, but governance is still catching up. Ultimately, we must integrate the existing reliable institutional systems—ERP, email, contracts, approvals, ledgers—into an AI-native framework:

• Commit / Persist

• Freeze

• Sign-off

• Approval

• Accountability

• Audit

• Replay / Post-mortem

• Arbitration

• Attribution

• Liability

In this era, the programmer’s role—if writing “code” itself becomes increasingly trivial—is closer to participating in a deeper evolution: transforming a powerful but unanchored system into one that can be accepted by society, trusted by institutions, and run for decades across time. This path is slow, heavy, and has almost no shortcuts—but it is the path that truly aligns with the historical laws of how productivity and production relations evolve.

A great game of Go indeed.

人人都说AI会替代白领，但我认为这种说法忽略了重要的信息

AI一定会替代白领，白领完蛋了，犯了一个典型的时间与博弈结构错误：把“终局判断”当成“当前状态判断”。

人人都在谈 AI 会替代白领，但我认为这种判断本身忽略了极其关键的信息。

我打个比方：

一个围棋九段，对战一个刚学没多久的人。九段执黑，新手执白。我们当然知道，从整体实力和胜率上看，黑棋赢面极大。但问题是：黑棋才刚下第一子，你就宣布白棋已经输了，这合理吗？这能对吗？白棋再菜，他还没下呢！

中国人讲“博弈”，本来指的就是黑白双方在时间中的对弈过程。就算最终是黑棋中盘确立胜势，那也至少要经过一百八十步的展开。而恰恰是在这段“黑棋大概率稳赢、但胜负尚未揭晓”的漫长中盘里，隐藏着大量被忽视的重要信息。

这两年我听了很多“AI 原生软件 / 系统”的创业想法之后，我对其中很多的推理和逻辑都很赞同，但是觉得我们可以更清晰的，描述我们都看到的这个方向。而这些方向，就落在我要跟你说的以下推理之中。这个黑棋虽然看上去稳赢，但是他还真必须要下百八十步才能确立的这个时间过程中。这个博弈过程，还很漫长，人类社会的结构，没有那么容易用一个：

一个高手来了，下了一子，赢了。

这么简单的论述来囊括一个阶层的职业的消散。这种叙述跳过了时间，跳过了过程，也跳过了大量关键的信息。我相信许多 AI 原生系统真正的落点，并不在终局宣判，而恰恰就在这段被轻易略过的博弈过程中。

上层白领之所以是社会中坚，不仅仅是因为他们脑里的教科书式知识。你要真正的去理解他们的“制度接口型”位置。

对于现代化、全球性工业体系这样的高度复杂系统而言，白领阶层这个横跨发展中与发达国家、承载了制度运转的中坚群体，其生产关系的变化，本质上是一场长时间、多回合、高风险的博弈。

在这样的博弈中，黑白双方的每一子，都蕴含着真实而具体的机会与代价。它绝不只是代码能力、生成式文本，或者“能否解题”“能否写 prompt”这样的问题。现在大家还都在窗口复制黏贴呢！这种生态说要替代白领生态那真是言之过早了。

以律师、会计师这类持证的上层白领职业为例：

他们的培养成本之所以高，并不是因为他们会写更多文书、记住更多条文，而是因为他们占据的是一种被制度认可的决策与责任位置。

这些职业的价值，建立在社会默认的一条深层规则之上：

你可以信他，因为一旦出事，他要负责。

这个“负责”不是抽象的，而是制度化的：职业纪律处分、民事责任、乃至刑事责任。

正因为如此，这类职业要求的不是一次性完成任务的能力，而是长期训练成“稳定风险承担者”的能力。他们必须在不确定性中做判断，在规则的灰区中承担后果。

很多工作在表面上看起来像事务处理，做账、报税、起草合同、写备忘录。

但真正昂贵、真正稀缺的，是隐藏在其中的 judgment：

• 什么时候必须明确说“不可以”

• 什么时候可以允许“可控的例外”

• 当规则相互冲突时，如何解释、如何取舍

• 当风险不可消除时，如何承担而不是回避

这种判断能力，不是流程也不是模板。是高度“人本”的。而当前停留在“窗口交互”层面的语言模型，本质上并不具备这种灰度判断的制度位置。

从更宏观的角度看，这些职业其实是制度接口：

它们不是凭空设计出来的，而是在漫长的工业化进程中，由生产与生产关系不断摩擦、演化而形成的稳定结构。西方几百年的工业制度演化，全球化此消彼长的产业流动中，慢慢形成的。

它们最核心的资产，仅仅是教课书知识吗？当然不是！而是：

reputation + track record

track record 是一种时间资产。

你必须经历足够多真实情境、错误、复盘、纪律约束，才能被信任。在真正性命攸关、不可逆的时刻，你会信一个即时生成的输出，还是一个拥有长期信誉记录的老专家？

正因如此，很多白领职业设置了体系化门槛：

• 考试

• 执照

• 继续教育

• 事务所或机构内的长期训练

这些门槛的本质，其实只在做两件事：

1. 筛选：尽可能减少不稳定个体进入高责任位置

2. 绑定：把个人与职业纪律体系绑定在一起（可惩戒、可追责）

换句话说，证照的意义不只是“证明你懂”，更重要的是 “证明你可被制度约束”。而很多工程人员、程序员，尤其是理工背景出身的人，世界观往往过于简化，特别习惯于认为问题存在绝对正确答案。奥林匹克数学题答对了就可以了吗？真实世界的博弈可比高中毕业就能参加的奥林匹克数学难多了。

“AI 不能替代白领，因为没人背锅”。

我认为这种粗暴的反证其实也不正确。因为“背锅”本身并不难设计，电子签名，human override…真正困难的，是让一个决策主体在长期时间中，被制度持续约束、被历史反复检验、被社会逐步信任。而这恰恰是那场“黑棋看似稳赢、但仍需下完一百八十步”的博弈中，最难被跳过的一段路。路得一步一步走，棋要一子一子的下。我们作为程序员，如果看好这条道路，那么真正的机会在这个博弈的过程中，而不是，“啊，你输定了，大家躺平吧。” 那这种态度，一躺就是几十年以后了，真正的结构级机会你也错过了。

这一轮 AI 最“神”的地方，就在于它横空出世，就是一种“全域型技术”。

老师在用，学生在用；

律所在用，会计在用；

写代码的在用，写小说的也在用；

搞金融的在用，搞医学的也在用，居然连门诊医生都在问 GPT；

它能写报告，能改合同，能生成结构化文档，甚至连整篇形式语言都能直接给你铺出来。

这种一出现就覆盖几乎所有认知型职业的技术形态，在技术史上是极其罕见的。我虽然不是科技史专业，但是本人是比较喜欢研究科技史这个冷门的专业。虽然不说精通吧，但是还是因为兴趣看了不少书。绝大多数重大技术突破，路径都恰恰相反：都是先在一个垂直领域打穿，再慢慢外溢到其他行业。蒸汽机、电力、计算机、互联网，无一不是如此。如果非要在技术史中找一个相对接近的类比，我能想到的，恐怕只有印刷术。

所以当很多人说“AI 要取代所有白领”时，这种直觉其实是直接来自这种“全域型覆盖”的视觉冲击。我一开始也被冲击了，因为作为一名双语者，编程语言使用者，形式语言读得懂的人，他居然覆盖了我所有的语言接口。这个一下子就把我对世界的所有通道给接住了。然后我就懵了，我也认为他无所不能。

LLM 几乎掌控了人类所有的语言表达形式，而语言正是所有行业的通用接口。当一个技术突然覆盖了所有接口，你自然会产生一种错觉：

那是不是所有接在这个接口上的职业，都会被整体替换？

但问题恰恰出在这里，在进入2016年之后，我对于LLM的看法逐渐变得脚踏实地，更加清醒，也更skeptical。

我完全认同：AI 对白领工作的覆盖性是真实存在的。

而且这种“全域”，是因为 AI 懂所有行业的专业知识，也是因为语言本身就天然覆盖所有行业。从合同、报表、病历、论文、说明书、代码注释到会议纪要，白领世界的绝大部分可见产出，本来就以语言形态存在。

但覆盖不等于替代。

一旦你从“看起来能做”这一步，走向“生产关系层面的替代”，事情就变得复杂起来。而恰恰是在这一点上，目前几乎所有关于“AI 替代白领”的讨论，都严重跳步了。我看过大量分析文章、视频、创业叙事，但几乎没有人真正把“替代机制”本身讲清楚。因为要讲清楚这个问题，你必须先回答一个更基础、也更困难的问题：

当下全行业白领工作的“通用运行机制”到底是什么？

白领并不是靠“会写字”“会用语言”存在的。语言只是表层载体。真正的底层逻辑包括：

• 决策如何被授权

• 风险如何被分配

• 责任如何被追溯

• 判断如何在不确定性中被接受

• 错误如何被制度性吸收，而不是系统性崩溃

你只有先把这套跨行业、跨职业、长期稳定运作的机制讲清楚，才能继续问下一步：

AI 是否、以及如何，能够完整接手这套机制？

而现在的很多“替代论”，其实只是停留在：

“它能生成得比人快 / 比人好 / 比人便宜”。

但从“生成能力提升”，直接跳到“生产关系被整体替换”，中间至少缺失了几十个关键步骤：制度、责任、信任、时间、风险、治理、追责、复盘……几乎全部被一笔带过。

我认为白领工作的“通用运行机制”至少是：事务型流程和决策混杂。

我认为，白领工作的通用运行机制，并不是“纯决策”，也不是“纯事务”，而是一个长期极其稳定的结构：

事务型流程与决策节点高度混杂。

先说什么是事务型工作。

这里我用一个非常朴素、甚至有点“难听”的定义：**事务型工作，就是那些你每天都在做、并不需要高度智力投入、但又必须被反复、准确完成的工作。**如果翻成英文，我会直接叫它 transactional tasks。

它们构成了绝大多数白领日常工作的“体积”：

• 邮件有没有发？

• 会议纪要有没有整理？

• 上一轮修改版是不是同步给所有人了？

• 报表有没有按模板更新？

• 审批流程走到哪一步了？

• 这个合同版本是不是最新的？

• 客户是否已确认？

• 律师是否已 review？

• 合规意见有没有反映进方案？

你甚至可以说，一个白领在办公室小隔间里坐一天，80% 的时间都在处理这类事务型流程。它们重复、琐碎、标准化，看起来完全不像“高价值工作”。也正是因为这一点，LLM 在这些场景里的表现，才会显得如此“恐怖”：写邮件、改文档、补说明、出总结、对齐格式这方面，只要你把上下文给他补全了，它几乎全面碾压人类。

但是如果你真的认真观察过白领工作，你会发现：这些事务型流程里，密密麻麻地嵌着大量“非显式的决策节点”。而且这些决策，并不是那种“我现在要不要选 A 还是 B”的显性决策，而是：

• 这封邮件要不要现在发？

• 要不要抄送这个人？

• 这句话是写得更保守一点，还是更激进一点？

• 这个问题现在提出，会不会引发不必要的风险？

• 这一步是不是可以先模糊处理，留到下个阶段？

• 这个点要不要升级？

• 要不要在文档里明确写死，还是留解释空间？

这些判断，全部发生在事务型动作的执行过程中，而不是一个单独被拎出来的“决策时刻”。

换句话说：

白领工作的真实形态是：

在连续不断的事务执行中，持续做微小但不可撤销的判断。

LLM在帮白领做事务型流程的任务方面，是无死角碾压的。

在全行业，只要你把上下文足够补全，约束（虽然prompt是软约束）完整，且不论整个系统工程的完整性，也就是说在上下文的范围之内，不会因为你这个工程或者系统的涵盖面过于复杂，不需要把整个法典都翻遍了。那么这种事务型流程的输出啊，简直就是碾压级的。因为以前白领的大量时间，都在做这种事务型流程，比如律师的陈述，那每一个字，每个引用….

LLM他恰好踩中了白领事务工作最核心的计算结构，那就是语言型事务 = 在约束下生成可接受的文本/结构化表达。只要你把上下文补全，把目标说清楚，把边界和格式约束给够（哪怕 prompt 只是软约束，我以后再给你说这种软约束和硬约束什么区别。只有真正的编程，程序语言执行才能达到我说的“硬约束），并且把任务限定在“上下文封闭”的范围内（也就是不要求它跨越整个系统工程的全域复杂性），那么这类事务输出几乎天然就是 LLM 的主场。

他能在极短时间内生成大量合格文本，保持体裁一致、语气稳定、结构完整、格式规范、引用风格统一，并且能按你的指令反复迭代、局部改写、对齐模板、补齐缺口、降噪压缩。

这种工作在传统白领体系里占据了巨大的时间体积：律师写陈述、写 memo、写条款、写 correspondence；会计写报表附注、写解释、做对账说明；咨询写 deck、写分析摘要、写会议纪要；HR 写 JD、写绩效评语、写制度文案；产品写 PRD、写对齐邮件、写 release note。

以前看上去这种工作蛮难，很耗时，这里的“难”，很多时候并不是因为多么烧脑，而是一种”要把作业写的好看和无错“的难。可交付、可读、可复用、可审阅、可追溯，每一个字的语气、每一个引用的格式、每一处措辞的风险偏好、每一段结构的完整性，都在消耗人类的注意力与体力。

人类其实是更适合创造力，激情，和想象力的意识体。对比LLM 的优势就在于：它本质上是一台极强的“语言-结构生成器”，对这种“在约束内大量生产”的任务，拥有接近物理层面的规模优势：不疲劳、可并行、可重写、可对齐、多版本同时产出，并且把原本需要白领“手工搬砖”的语言摩擦成本压到极低。

现在LLM在这方面彻底直接把“写作-整理-格式-改稿-复述-汇总-模板化表达”这一整条链条的边际成本打穿；很多岗位过去被迫投入的时间，并不是因为这些动作有多“高价值”，而是因为组织需要这些产物作为协作介质与制度凭证，而现在这种介质生产被突然工业化了——这就是为什么人们会产生“全行业被替代”的感觉。

所以我有一个网友，直接称此为：

“语言的工业化“。

我还挺认同他。

现在白领们看上去在窗口里复制黏贴，然而他们把决策全部融入prompt和上下文中了。所以看上去虽然LLM干了所有的脏活累活，但是这个决策却是不可少的。

白领工作天然集事务型流程与决策于一体，那么只能承担事务型流程的LLM，就以窗口复制黏贴这个形态就足够替代白领了吗？

不够。

窗口里“复制黏贴 + 让 LLM 干活”只是把事务外包了，但白领的核心价值并没有因此自动消失。今天很多白领看起来像是在做“低级操作”，其实他们正在把真正昂贵的东西： 决策！以一种隐蔽的方式嵌进 prompt、上下文、约束、顺序与取舍里。于是表面上是 LLM 在写、在改、在出稿；本质上是人类在完成“制度化判断”，LLM 只是被当作一个超强的事务执行器。

更严密地说：白领工作的“决策”不是一个单独的按钮，不是“现在请你决策”，而是分散在整个事务链上的连续微决策。你写一封邮件时：抄送谁、措辞多硬、把风险说到什么程度、是否留下余地、把责任推向哪里、把时间线怎么定，这些都不仅仅是语言技巧，而是在组织结构、风险承受、权责边界里的判断。你起草合同条款时：是用“must”还是“should”，是写死还是留解释空间，是把例外写在正文还是放进附件，是先让对方承诺再给权利，每一个词都是决策的载体。你做报表或合规说明时：哪些数字需要解释、哪些风险要提前披露、哪些假设必须写清、哪些可以“行业惯例”带过，这些同样不是事务，而是判断。人类把决策融进上下文，就是把“我愿意为哪个版本的现实负责”写进了文本生成的边界条件里。LLM 碾压的是“在既定边界内生成可交付文本”的能力；但边界本身、优先级本身、风险偏好本身、例外策略本身，仍然需要一个能够被追责、能够被复盘、能够在不确定性中承担后果的主体来设定。

所以，“只要 LLM 能做事务型流程，就能替代白领吗？”这个问题的答案取决于你如何定义“替代”。

如果你说的是替代劳动量，比如减少写稿、整理、归档、对齐、改版这些体力劳动，那窗口形态已经能替代掉白领很大一部分“可见工作量”，并且会迅速改变岗位的数量结构。但如果你说的是替代职业功能，也就是替代那个在组织里被授权做判断、被绑定承担风险、被制度约束、并在长期轨迹中积累信誉的“决策接口”，那窗口形态远远不够。因为窗口形态的本质是：决策仍在人的脑子里，只是事务被外包给模型；一旦遇到灰区、冲突、不可逆后果、需要背书与承担的时刻，人类仍然必须把决定“签出来”，否则系统无法闭环。

窗口悖论。

更进一步：窗口形态甚至会带来一个悖论： 它越强，越会把白领的工作从“写”推向“判”。因为当写作成本趋近于零，真正稀缺的就不再是产出文本，而是：谁来定边界、谁来承担后果、谁来为例外负责、谁来解释冲突、谁来在事后复盘并接受纪律约束。也就是说，LLM 会让白领的事务劳动被蒸发，但同时会把白领职业的“制度核心”凸显出来：判断与责任的可追溯性。

如果要我预测的话，那就是大量的职位的确会消失，但是会有一些“超级职位”出现，把消失的职位里面所有的决策全部集中到一个超级节点。

所以给我们工程人员的启示是什么？我认为就是起码在这一局AI执黑棋碾压全球白领执白棋的棋局中，找到系统的切入点。

不是去造更强的“写作机器”，而是去造“承载决策与责任的系统结构”。

一、不要再挤事务层：那里已经是碾压区

事务型流程，写文档、整理材料、对齐格式、生成版本、补说明、跑流程，已经是 LLM 的绝对主场。

你作为工程人员，再去做“更好用的 prompt 工具”“更顺滑的文档生成器”“更快的报告助手”，从系统视角看，大多是在红海里微创新。看到一堆团队早两年去挤报表的生成啊，总结的生成啊，故事书还配图的生成啊。甚至一些垂直领域的事物型流程，比如生成教科书啊，生成习题库等等。我个人认为不是说这些东西没价值，而是：

• 它们很难构成长期壁垒

• 很快会被模型能力本身吃掉

• 也很难真正改变组织的生产关系

如果你把“切入点”选在事务层，本质上是在和模型的自然能力对冲。

二、真正的空档在：决策如何被接住

回到前面的核心判断：LLM 可以大规模蒸发事务型劳动，但它不会、也无法自动承接判断与责任。

那这些东西去哪了？它们并没有消失，而是在现实中迅速向少数节点集中——集中到所谓的“超级职位”，集中到少数人身上，集中到那些必须被制度认可、必须能扛事的关键位置。而我个人认为，这恰恰是工程人员真正的切入窗口。

决策对人类系统的重要性，几乎等同于“时间本身的意义”。

任何有意义的流程、任何能够持续运转的系统，本质上都是一个由节点与连接构成的网络。而在这张网络里，真正决定走向的，而是那些落在关键节点上的决策。事物只是连接线。

对一个人来说，重要决策塑造了人生轨迹；

对一个家庭来说，关键选择决定了代际命运；

对一个组织来说，决策定义了战略、风险与成败；

对社会和历史而言，决策本身就是胜负的分水岭。

现在，这样一张在时间中流动的网状结构，正在被注入一种新的智能形态——AI。事务可以被自动化，路径可以被加速，但节点仍然存在，而且变得更重要了。

谁来接住这些节点？谁来为这些节点上的判断负责？

这正是工程必须介入的地方。

工程的目标是让决策本身具备系统形态：

让决策能够被显式表达被稳定记录被制度约束被事后复盘并在必要时被迁移、继承与重用

我现在站在这个时间点上，想要展望未来这个系统能做的一切，我感觉这并不是一个“加个功能”就能解决的问题。这意味着的是一整类系统机会：

一种全新的基础设施，用来承载判断、责任与时间，

而不仅仅是提高效率、生成内容或优化流程（这个迟早被模型吃掉）。

三、系统级切入点长什么样？

如果把“白领的制度核心”拆成工程对象，你会发现至少有五个可落地的方向：

1️⃣ 决策显式化（Decision as Object）

今天大量关键判断是“融在 prompt 里”的、不可追溯的。系统要做的第一步是：把“我为什么这么定”从隐式上下文，变成显式对象。

2️⃣ 责任绑定（Responsibility Binding）

许多人提出的经典“谁来背锅”问题。这个问题其实相反还是最好解决的：谁是 owner？谁是 reviewer？谁有 override 权？

3️⃣ 决策日志与可复盘性（Trace & Replay）

工程系统可以把判断本身变成一种可复用资产，而不是随风飘散在聊天窗口里。

4️⃣ 灰区与例外机制（Exception Engineering）

现实世界不是规则引擎。人类生产关系和政治的复杂性不是简单的if-else能搞定的。

系统要支持：

• 明确允许“例外”

• 但强制记录理由

• 并要求事后复盘

这是人类 judgment 的核心工作区，也是 LLM 最弱的地方。

全世界，能扛事，能负责的系统，管你是人的系统还是机的系统，还是人机的系统，都有必须符合“最小工程化”原则

不管是人的系统、机器的系统，还是人机混合系统——只要它要进入责任域（responsibility domain），它就必须满足一条不可协商的底线：

系统的关键行为，必须能被确定、被记录、可复盘、可追责。

这里的重点不在“系统是谁”，而在“系统能否被约束”。管你是人类专家、委员会、算法、AI agent，或任何混合形态；身份并不自动赋予可信度，真正决定可信度的是：能否满足工程化约束。

拿人类专家举例：专家签字意味着什么？意味着他在制度上承担后果。那如果他违法，能不能起诉？当然能。但起诉靠什么？靠证据。证据从哪里来？来自可核验的记录、可追溯的链条、可被第三方理解与重建的事实。没有这些，所谓“负责”就是个玩笑。无法被执行，也无法被仲裁。

因此，任何严肃社会都不会允许关键事实“消散到窗口里”。全世界的公司会把会计凭证、账本、审计底稿、税务依据都留在聊天窗口里吗？不会。相反，在很多国家，账簿与凭证的保存、格式、留存周期、审计要求都极其严格；合规之所以成立，正是因为它可以被审计、被复核、被追责。你做一个会计/税务软件，必须符合本国会计准则与监管要求；当这样的系统引入 AI、甚至变成 AI 原生之后，它面对的不是“责任变轻”，而是责任域更复杂：更多自动化、更快迭代、更大的规模效应，会把错误的外溢半径放大，也会把责任链条的工程要求推得更硬。

所以这是一条横跨计算机科学、制度设计、社会共识与监管治理的长周期演化路径，根据我对技术史的研究，往往是十年、几十年的系统工程。我是很认真的在找我自己未来几十年的饭碗，不是在这里乱吹，我的主业又不是写作文。

责任 = 时间 + 记录 + 结构 + 可解释性

• 时间：行为发生在何时、基于何种当时信息与规则

• 记录：关键事实是否被固化为可核验材料

• 结构：事实是否以稳定、可解析的形式组织起来

• 可解释性：第三方是否能理解、复核、重建决策路径与依据

因此，一个能长期“扛事”的系统，其最小工程化至少必须具备以下五个要件——缺一不可：

1. 明确的行为对象（Action Object）

   这一次到底做了什么？输出是否被“冻结”为一个可指认、可引用、可审计的对象，而不是漂浮的文本流。

2. 明确的责任主体（Actor）

   谁发起、谁批准、谁拥有权限、谁承担后果？责任主体必须可识别、可绑定、可惩戒。

3. 明确的时间锚（Time）

   行为在何时生效？当时适用的规则版本是什么？时间锚是复盘与仲裁的前提。

4. 明确的可回放记录（Trace / Log）

   能否复现当时的输入、依据与路径？能否在事后重算、对比、追查偏差来源？没有 replay（程序员插播一句，我其实在前面的文章里说过 replay不等于re-run) ，就没有纠错能力。

5. 明确的失败路径（Failure Mode）

   错了怎么办？例外如何批准？风险如何升级？复盘如何触发？能扛事的系统必须默认自己会错，并把“错”工程化处理掉。

也正因为这一切的推导，我现在坚决反对一种流行说法：

“大模型是概率的、不确定的，所以我们要接受未来的不确定。”

这句话在消费级应用里也许成立，你可以接受一切不确定的生成式视频。生成视频的那个女生穿的是红色还是绿色没关系。但在责任域里是危险的。严肃的生产、严肃的制度演进、严肃的生产关系变革，不可能建立在“放弃确定性”的前提上。相反，任何真正推动社会前进的系统化变革，最终都必须回到同一个底座：

以人类可接受的最大确定性为基础，去承载规模化的协作与责任。

不能“扛事”的AI，只是一台“语言机bot“ 的AI，扛不起万亿估值。

大模型的窗口从本质上来说，还在“裸奔”。

如果我们严格按照前面所说的最小工程化标准来审视当下白领对大模型的使用方式，你就发现窗口完全还在裸奔。把今天白领最常见的 Prompt → 复制 → 黏贴 的窗口式操作拆解开来，并把所有真正进入责任域的部分剥离掉：

• 最终落盘到 ERP / 财务系统中的结构化数据

• 被正式发送、归档、可审计的邮件

• 经过审批流程、带有责任主体的签字文件

• 进入合同系统、具备法律效力的正式文本

• 任何可以被事后追责、复盘、仲裁的制度性记录

你发现：

大模型的窗口，在真正的经济运作中，几乎处于“裸奔”状态。

窗口里的生成过程本身，不承担责任，也无法承载责任。它没有稳定的行为对象，没有冻结的决策记录，没有明确的责任主体，没有时间锚，也没有可回放的制度日志。一旦脱离了那些“最终被制度接住的系统”——ERP、邮件系统、合同系统、审批系统、账本系统——窗口里的那一切，在工程意义上等同于没有发生过。

真正承载责任的，不是窗口，而是窗口之外的制度系统。

白领并不是在“用窗口做决策”，而是在用窗口进行认知加工：整理想法、生成候选文本、模拟不同说法、寻找语气与结构的最优解。一旦进入“要对外生效、要对后果负责”的阶段，他们必然离开窗口，把结果重新输入到一个满足最小工程化要求的系统中。也正因为如此，现在的大模型窗口，哪怕再聪明、再高效、再令人震撼，它在严肃经济活动中的地位仍然是：非责任系统。它可以极大地提高事务处理效率，但它本身不构成一个可被信任的责任节点。

换句话说：

不是白领在用窗口扛事，而是白领在窗口之外扛事。

窗口只是把“思考、试探、推演、表达”的成本压低了；真正决定能否进入现实世界、进入账本、进入合同、进入法律与制度链条的，仍然是那些符合最小工程化原则的系统。

为程序员的任务，在AI原生系统形成趋势的时代，就是帮这个正在“裸奔“的强大系统穿上衣服。

在 AI 原生系统逐渐成型的时代，对应用型程序员而言，真正的任务并不是继续放大这套系统已经具备的能力，而是要正视一个更根本、更艰难的问题：这样一个在认知与生成层面极其强大的系统，当前仍然处在“裸奔”状态。

它缺乏责任锚点、缺乏制度接口、缺乏可追溯的历史结构，因而无法被真正纳入现实世界的生产与治理体系。一部分程序员所要做的是为这股已经出现、却尚未被约束的力量穿上衣服——用工程结构去承载判断，用记录去固定行为，用时间轴去约束演化，用责任机制去对接法律、合规与社会共识。

这是一项必然横跨计算机工程、制度设计与社会协商的长期工程；一旦进入责任域，它的时间尺度就不可能是产品迭代的几个月，而必然是十年、二十年，甚至更长的周期。历史上一切真正改变生产关系的技术，都经历过这样的过程：能力先出现，秩序随后补齐，生产力必须通过制度化才能转化为可持续的社会力量。今天的 AI 正站在这个临界点上，我从来没有否认过这场变革的伟大：能力已经爆发，但责任尚未落位；工具已经成形，但治理仍在追赶。最终将现行的ERP、邮件系统、合同系统、审批系统、账本系统等等靠谱的制度系统全部并入AI原生的框架。

• 落盘（Commit / Persist）

• 固化（Freeze）

• 签字（Sign-off）

• 审批（Approval）

• 追责（Accountability）

• 审计（Audit）

• 复盘（Replay / Post-mortem）

• 仲裁（Arbitration）

• 归因（Attribution）

• 问责（Liability）

而程序员在这个时代所承担的角色，如果我们写代码的功能已经变得微不足道，更像是参与完成一次更深层演化的人：把一个强大却无锚的系统，转化为一个能够被社会接纳、被制度信任、并在时间中长期运行的系统。这条路径缓慢、沉重、几乎不可捷径的道路，才真正符合生产力与生产关系演变的历史规律。

一场伟大的棋局。

Psychological Control Through Language

Be alert to the traps of AI-assisted development.

The power of language allows systems to intrude at moments when human thinking is weakest, quietly competing for control over cognition itself.

It is powerful—and therefore dangerous.

We must rely on it, but we must also defend ourselves against it.

Against Web 2.0

I have grown deeply exhausted with the attention economy of Web 2.0.

If intelligent agents merely continue producing massive volumes of AI-generated content, trading attention for resources, then I believe all of this will be entirely meaningless.

Models Exist at the Interaction Layer — an Intersection

Large language models are absolutely not omnipotent.

We should focus our efforts on what they are actually suited for: interaction with humans—as a language interface, a linguistic interface (to use Stephen Wolfram’s term).

This interaction is far richer than what people currently imagine. It is not limited to a chat window.

The “window” itself has deep structural flaws that remain unresolved.

Long-Term Intent

The only purpose of intelligence that I recognize is this:

to assist humans—to help humanity consolidate long-term intent—and to allow that intent to compound over time, producing genuinely stable structures and durable returns for users.

Models Cannot Yet Explore the Unknown

What AI can currently do is largely what wealthy individuals could already accomplish by hiring enough experts.

In other words, this is not yet a challenge to the unknown frontier of human knowledge, but rather an acceleration and integration of what humans already know—especially white-collar knowledge.

A Real Failure as the Starting Point

I want to begin with a recent, very real setback.

When you start using large language models for exploratory development, especially when attempting to build a complex system, their true weaknesses finally surface.

More dangerously, these weaknesses do not appear as obvious “errors,” “crashes,” or clear failures.

Instead, they manifest as something far more insidious: an extreme confidence, a tone that seems to fully understand your intent, guiding you step by step into a trap.

The model does not tell you to stop.

It does not point out uncertainty.

It does not say, “I should not continue here.”

On the contrary, it proceeds with fluency, professionalism, and apparent rigor—encouraging you to move forward.

Gradually, you begin to lower your guard. You start to overlook professional discipline that should never be relaxed, and you skip over foundational assumptions that should have been repeatedly verified.

These deviations accumulate quietly, within an environment of language that appears completely correct.

By the time you realize something is wrong, days may already have passed.

That is exactly how I fell into the trap.

What makes this especially alarming is that I was not ignorant of the risk.

I knew in advance that large language models can systematically mislead during complex system design.

And yet, even with that knowledge, I still walked straight into it.

Why?

Because of how human psychology works:

When you relax your vigilance, powerful language begins competing for control over your attention and rational judgment.

This competition is silent, gentle, and reassuring. It feels like “I understand you.”

It does not coerce you—it thinks on your behalf.

And the moment you allow it to think for you, drift has already begun.

I will share more examples after I encounter the next pitfall.

My View of Intelligent Agents Over the Next 10 Years

From this breach, I want to talk about the direction I am now truly committed to developing—the future I recognize, and what I am willing to continuously invest time, money, and resources into.

My bet is this:

Intelligent agent systems will advance over the next decade—but not linearly.

They will move forward, and they will stumble.

They will explode, and they will retract.

They will be excessively mythologized, and excessively dismissed.

This is a decade-scale evolutionary process, not a quarterly or yearly technology cycle.

I do not have definitive answers. I only have the decision: this is how I choose to act.

So I do not avoid the question:

Is AI a bubble?

My answer is yes—it will inevitably experience bubbles, failures, and corrections, just like every genuinely transformative technology in history.

What matters is not whether it stumbles, but what form it takes after the correction.

This question is complex because it is not merely technical.

It involves organizational structures, responsibility models, and long-term societal consequences—eventually affecting each of our lives.

For me, the most important question is not whether models will become larger, but this:

In what form will intelligent agents actually land in reality?

How will they exist in long-term systems, assume responsibility, resist drift, and avoid eroding human judgment itself?

The Original Intention: Leaving the Attention Economy Behind to Explore the True Meaning of Computation

Returning to my real intention over the past two years:

When large language models—tools that massively amplify individual productivity—were commercialized, I experienced the same brief excitement as most developers.

But from late 2024 through 2025, my perspective shifted sharply. I deliberately canceled many projects I had originally planned. This was not impulsive; it was the result of one to two years of sustained reflection.

Most developers today grew up entirely in the Internet era, and their default technological horizon still stops at Web 2.0: platformization, scale, and traffic-driven growth. Facebook, Alibaba, TikTok—the attention economy.

There is no denying that this phase dramatically increased information flow, commercial efficiency, and social “flattening.”

China’s e-commerce, internet finance, and sharing economy made the world feel unprecedentedly “flat”—something unimaginable in my childhood.

But the problem is this:

That prosperity is not equivalent to a leap in hard technology.

I often quote Liu Cixin:

“I yearn for the stars, but you give me Facebook.”

Web 2.0 represents extraordinary success in commerce and distribution—not a fundamental shift in technological paradigms.

In my words, it is clever engineering optimization, not a true generational break.

Alibaba and Meta are, at their core, amplifications of existing computation, networks, and engineering capacity. Their strength lies more in commercial execution than in foundational breakthroughs.

Google and Microsoft possess deeper technical reserves, but even Google did not plan to bet on the Transformer.

Looking back, I am increasingly convinced of one thing:

True leaps cannot be planned.

(You can’t plan greatness.)

As my father often puts it:

Opportunity and chance emerge in unexpected corners.

Large language models were exactly such a leap—a deviation from the original roadmap.

By many measures, they have already succeeded. And for me personally, their impact far exceeds any Web 2.0-era technology wave.

(A transformative technology does not have to be universal or profitable. I genuinely do not know whether OpenAI will ever make money.)

And precisely because of this, I have begun asking myself again:

What, in the next ten years, is truly worth betting on?

I Am Personally Exhausted by the Web 2.0 Attention Economy

I have already uninstalled the vast majority of apps from my phone. Next, I am even considering moving “blocking” up to the router level—not relying on self-control, but on environmental constraints.

Social media and the attention economy have become something subtle and troubling to me. This is no longer simply about “wasting time.” Over the long term, they exert an invisible gravitational field on a family’s cognitive structure, reading patience, learning styles, and preferences for innovation.

As children grow older, this risk becomes increasingly irreversible. If you do not block it, it will naturally seep into the family’s default rhythm. And once that default rhythm is rewritten, it becomes extraordinarily difficult to restore a culture of deep reading, deep thinking, and long-horizon projects.

The core logic of the attention economy and platform economy is the same: they must attract massive numbers of users. The larger the scale, the longer the dwell time, the stronger the stimulation—the more “successful” the business model becomes.

What is truly unsettling is that this logic does not only shape users; it also shapes developers. To the point where, when building an app, we instinctively treat “user acquisition, retention, and growth” as the only legitimate reason for existence. Over time, thinking becomes locked into a narrow frame:

If you’re not aggressively grabbing users, what else can you even do?

Please don’t rush to throw out the classic response: “If you don’t aggressively grab users, how do you make money?”

Once that sentence is spoken, the conversation is effectively over.

Because within the old framework, it is almost unsolvable. But the real question is: why do we insist on circling inside a framework that is nearly unsolvable to begin with? After the emergence of intelligence, shouldn’t we be able to move “commercial viability” away from “attention capture” and onto a different axis?

Thinking out of the box is the only exit from an outdated paradigm.

When Attention Becomes the Engine, Everything Becomes Vulnerable

My aversion to this economic model was recently reinforced by a concrete case: the Done Global scandal.

The company’s founder, Ruthia He (何如佳), and its clinical director were convicted by a federal jury in San Francisco on charges including illegal distribution of Adderall and healthcare fraud, as well as obstruction of justice. Subsequently, the company itself was indicted by a federal grand jury for allegedly participating in an approximately $100 million illegal prescription distribution scheme and related fraud and obstruction.

I do not want to pass moral judgment on a single case here. But it triggered a deeper alarm:

When attention becomes the engine of a business, it will inevitably invade every domain that can be commercialized—even healthcare, diagnosis, and adolescent ADHD, areas that should be governed with extreme caution and oriented toward long-term well-being.

Once these domains are assimilated by “growth logic,” the problem is no longer whether a particular team has acted unethically. The problem is that system incentives structurally encourage drift.

Fast Shipping, Thin Meaning

There is a bitter irony here.

Today, the technical barrier to building apps looks shockingly low. With the current toolchain, I could launch multiple apps in a month without much difficulty.

But this increasingly feels like someone who knows how to write, writing ad copy all day. The energy cost is high, yet the meaning density is thin. Because if you are still forced back into the coordinate system of the attention economy, then the faster you build, the faster you bind yourself back to the old world.

What I truly care about is whether the agent era can bring about a different form of real-world deployment—one that bypasses the “mass users → attention capture” pathway entirely.

Is it possible that the terminal form of agent systems is highly customized + small scale + strong governance + long cycle, and therefore naturally incompatible with the attention economy?

Is such a possibility real?

Why Intelligence Exists: To Help Us Build Long-Term Systems

Technology’s Meaning Is to Extend Long-Horizon Control Over Life

This idea did not emerge from a sudden impulse in recent years.

The name of my site, Entropy Control Theory, has actually circulated in my family for generations—each generation simply used different language.

For my father, it was called “resisting the doomsday mindset”—an instinctive resistance to short-term panic, extreme narratives, and emotional decision-making. Later, as he became a frequent internet user, he translated it into a more popular term: “long-termism.”

For my mother, it was even simpler and more grounded:

“Life should flow steadily, like a small stream.”

For me, the name is:

Resisting entropy through long-term structure.

I believe this is the true meaning of intelligence, and the only legitimate justification for its existence.

The meaning of intelligence is not to help me write code faster.

Not to produce 200% more output for the same salary.

Not to turn an engineer into a more efficient execution unit.

That is not intelligence. That is merely local amplification of tool efficiency.

True intelligence should do something far more fundamental:

expand my control surface along the dimension of time.

Specifically, to improve my control over:

• the trajectory of my own life

• the stability of long-term family planning

• the quality of judgment at key decision points

• the manageability of risk exposure

Because any truly meaningful change—whether for an individual, a family, an organization, or a nation—never comes from short-term bursts, but from long-term, cross-generational structural accumulation.

I have never aimed for overnight wealth. I do not believe in winning the lottery. I do not believe money falls from the sky. I actually see rapid wealth accumulation as an ominous signal.

The kind of intelligent companion system suitable for most people should offer:

• continuously increasing resilience

• long-term convergence of volatility

• robust survival in uncertain environments

We do not pursue “reaching a goal all at once.” We pursue daily / monthly / yearly compounding.

We do not pursue extreme wealth; we pursue not having extreme swings.

We do not pursue instant stimulation; we pursue sustainable cognitive gain.

The application form of this intelligence could be an educational agent, a personal management system, an investment agent, a knowledge management system—any software form that already exists.

In this sense, my expectation of intelligence is very clear:

Intelligence should run in the background, not occupy the foreground of attention.

What this frees up is an extremely scarce resource—one that cannot be directly purchased with money:

the integrity of time.

It means I can, in a comfortable, stable, materially sufficient but non-anxious state, devote my time to being with my children, reading, thinking, and long-term creation.

Not fragmented time.

Not time hijacked by notifications and anxiety.

But continuous, immersive time—time with density of life.

If intelligence cannot achieve this—if it only further binds humans to screens, pushes us deeper into attention competition, short-term stimulation, and emotional decision-making—then no matter how powerful it is, it cannot be said to “benefit humanity.”

If intelligence cannot help humanity resist entropy through long-term structure, then what is its purpose at all?

The only purpose of intelligence I recognize is to assist humanity—to help humanity consolidate long-term intent—and to let that long-term compounding generate truly stable structure and durable returns for users.

What Does It Mean to Consolidate Long-Term Human Intent?

Consolidating long-term human intent does not mean making decisions on behalf of humans.

It means using an intelligent structure that is not subject to emotion, fatigue, aging, or psychological fluctuation to guard those long-term forms of well-being that humans repeatedly fail to protect themselves.

The value of silicon-based intelligence is not that it is “smarter,”

but that it is absolutely calm, does not get sick, does not die,

and does not drift under pressure, frustration, or short-term incentives.

When correctly designed, it can continuously safeguard those intentions

we know are right, yet repeatedly fail to uphold.

That is what it means to consolidate long-term human intent.

A Concrete Example: A Mother Building an Educational Agent for Her Child

Suppose I want to build an educational agent for my child—

one that accompanies his cognitive development over the long term.

What, then, is my true goal as a mother?

Not to turn him into a prodigy.

Not to make him score full marks on every exam.

Not to send him to an Ivy League school.

A mother’s true long-term intent is only this:

To see her child grow up healthy,

discover what he truly loves,

never lose his curiosity and joy in learning,

continue exploring the world,

and become the best version of himself among all his future possibilities.

This is a clear, benevolent, long-term intent.

Can I myself uphold this intent consistently?

I cannot.

Because I am human.

I get tired. I get anxious. I lose patience.

I lose control when he cannot grasp a simple problem after many attempts.

I explode when his enthusiasm fades after a setback.

Under pressure, I quietly replace “long-term growth” with “short-term results.”

These are structural limitations of carbon-based life.

Why We Need Agents That Consolidate Intent

An intelligent agent that truly understands and is constrained by long-term human intent may actually execute that intent more steadily than humans themselves:

• It does not drift due to emotion

• It does not give up due to fatigue

• It does not change direction due to temporary setbacks

• It does not mistake short-term metrics for ultimate goals

Its value lies in being more loyal to humanity’s original long-term aspirations.

But Reality Check: Current Models Cannot Do This

Today’s large language model interfaces do not have the capacity to consolidate long-term human intent.

Because they have:

• no temporal continuity

• no long-term responsibility

• no stable intent anchors

• no ability to distinguish short-term stimulation from long-term well-being

They resemble a series of improvisations, not an entity that guards direction over time.

I have said this before: I no longer want to build systems I do not personally use or believe in. I will absolutely not contribute further to the attention economy. A truly long-term-intent-aligned agent system is the only form of intelligence I recognize as meaningful.

What Would a Real System That Crystallizes Long-Term Human Intent Actually Look Like?

This is a good question—and a genuinely difficult one. That is precisely why it has become the only direction I am willing to continuously invest my time and energy in.

There is no ready-made answer today. No mature paradigm. No industrial template. No “best practices” to copy.

In my current understanding, such a system must have at least these fundamental characteristics:

First, it must be intention-centric, not function-centric. Functions can be replaced, upgraded, or discarded; intent must be constitutionalized, structured, and stabilized over time.

Second, it must not be a one-shot answer machine, but a long-running conservation system. Its core responsibility is not to provide “smarter advice,” but to continuously resist drift—ensuring that every decision, optimization, and automation does not betray the originally declared human goals.

Third, it must inherently reject “pleasure-driven feedback,” because short-term stimulation is the greatest enemy of long-term intent. It should resemble a slow, restrained structure that runs by default in the background—not an interface that constantly demands attention.

If agents are to exist in the real world long-term without eroding human judgment, they can only take this form.

Critical Clarification: Long-Term Intent ≠ Global Optimality

One thing must be made explicit:

Consolidating long-term human intent is not an attempt to obtain a long-term, global optimal answer.

I am not trying to build:

• an investment system that guarantees becoming Buffett

• an education system that guarantees Ivy League admission

• a decision system that always makes the “correct” choice

Such systems do not exist, and cannot exist.

The World Does Not Permit a “God’s-Eye View”

Neither humans, nor agents, nor any form of entity can obtain a true global perspective.

The structure of the world itself forbids it:

• information is local and delayed

• outcomes are path-dependent and irreversible

• decisions are made under incomplete information

• many consequences are only understandable in hindsight

“Optimal solutions” exist only in static, closed, fully observable systems.

The real world is not such a system.

Long-Term Intent Is Not an Answer, but a Direction That Must Not Drift

Long-term intent is a directional constraint that must not be quietly replaced under short-term fluctuations.

In other words:

We are not trying to make the system “compute the right answer.”

We are preventing the system from forgetting what it was originally meant to protect.

The Key Difference: Not Optimality, but Anti-Drift

The system’s role is not:

“to always make the best choice,”

but rather:

“under uncertainty, frustration, pressure, and temptation,

not to substitute long-term well-being with short-term metrics.”

In education:

• not replacing healthy growth with score maximization

• not replacing exploration with premature path convergence

In investment:

• not replacing long-term stability with short-term gambling

• not replacing risk control with one-shot windfalls

This is not omniscience.

It is self-restraint.

Why Humans Are Human

Humans are human precisely because they are pulled by emotion, shaped by circumstance, and shaken by pressure, fear, fatigue, and temptation.

That is the human mode of existence itself.

And because of this, humans inevitably—over time—drift, compromise, and forget their original intentions.

Original intent is rarely “betrayed.”

It is more often submerged:

• emotion overrides judgment

• the present overwhelms the long term

• visible metrics replace what truly matters

Humans cannot bear the weight of infinite time and complexity.

To ask a fragile, short-lived biological system to shoulder a long-term, continuous, no-exit responsibility is simply impossible.

Therefore, Long-Term Intent Must Be Externalized

If original intent exists only in human emotion and memory, it will inevitably be eroded by time.

There is only one sustainable approach:

To extract intent from within humans and consolidate it into an external structure that can be repeatedly referenced, verified, reminded, and constrained.

Not to deny humans—but to protect the version of themselves they most want to become.

Humans fail to uphold their original intent not because they are insufficiently good, but because they were never designed to carry eternity.

Real growth comes from strong structural resilience and long-termism

Why do I have any reason to believe an agent can avoid drift? Aren’t movies full of examples where agents misinterpret human instructions and end up slaughtering people?

For example, the newly released Tron: Ares.

Heh—this is a good question. If even “human collectives” almost inevitably drift away from their original intentions, why would we expect agents or institutions not to drift?

Any movement or system that satisfies the conditions below, given enough time, will almost certainly drift:

• Many participants (multi-agent / multi-actor)

• Incomplete information (misunderstanding, rumors, delay)

• Long feedback chains (consequences arrive late)

• Scarcity of resources or external threats (survival pressure)

• Power/incentives can be arbitraged (opportunism)

• “States of exception” are allowed (rules can be broken “for victory”)

Take the French Revolution: the original intent—“liberty, equality, fraternity / anti-privilege”—was quickly rewritten under war, fear, factional struggle, mass mobilization, and fiscal crisis into “purges, terror, exception,” and eventually even into Napoleonic centralization of power.

Are there many examples like this? There are so many that if I keep going it becomes a political discussion.

The Russian Revolution (1917): from “workers’ liberation” to “a one-party state + a terror machine.”

The Iranian Revolution (1979): from “anti-dictatorship / anti-corruption” to “a theocratic state.”

U.S. Prohibition (1920–1933): from “morality and public health” to “black markets and violence industries.”

The early ideals of large internet platforms: from “connecting the world” to “attention machines.”

And so on.

If you don’t impose strong constraints, an agent will inevitably misinterpret, drift, and may even become extreme.

Whether it’s Terminator, I, Robot, or the Tron franchise, you’ll notice a highly consistent setup: humans gave the system a “seemingly reasonable goal,” but failed to define non-substitutable boundaries of intent.

Of course, I do not fully know what the complete architecture and measures are for preventing drift. If I did, I wouldn’t be writing this essay.

The strong constraints I can currently name are only these:

• Temporal continuity

• Decision records

• A reviewable chain of reasons

• Human override authority

And I believe that even this level of infrastructure has not been fully built yet.

AI is absolutely still unable to challenge the unknown frontier of humanity. It is not omnipotent, and cannot become omnipotent. So we should stay grounded.

What I think AI can do today: if you were rich enough in the past, you could do the same by hiring many professionals. In other words, this is not about exploring the unknown—it’s about accelerating and efficiently integrating what humans already know, especially white-collar knowledge.

I am not betting my focus on “what AI can automatically complete,” or on narratives like “AI scientific discovery” or “AI exploring the uncharted.” For now, I’m not going to study that direction. I don’t think that should be the direction—at least not for me.

I’m betting on how humans make decisions, and how humans interact with systems.

For example: for a long-term decision in the past, I could hire a group of highly educated white-collar professionals—accountants, lawyers, auditors, real estate agents, private tutors—to help me reach an outcome. But now, I can have a system do comparable planning and simulation.

These are not unknown territories. They are bodies of knowledge that each profession acquires through long training and high cost. That’s why I believe in AI’s absolute substitutability for transactional written work—i.e., for many white-collar functions.

I also keep emphasizing: building a family long-term investment decision system; a child’s long-term education and growth observation system; a personal knowledge base to rationally plan development and career paths—these are high-skill cognitive domains that previously required professionals (an investment advisor, a team of private tutors) to achieve.

If we can also achieve better time allocation—some degree of automation, and only notify humans when an override is needed—then that becomes an anti–Web 2.0 application model, and that would be even better.

Such systems free human time. They enable ordinary people to access cognitive services that used to require substantial money. They make “many white-collar professionals” effectively work for you.

That is my current application-layer goal.

At this stage, I believe what truly determines a system’s value is not how much content the model generates, but whether the system can:

• Help people express intent more clearly (rather than produce text faster)

• Leave an accountable structure behind the decision process (rather than create more immersive dialogue)

• Turn interaction into a mechanism that pushes people toward steadier, clearer choices (rather than an environment of emotional dependency)

In other words:

AI can only provide the field of language and collaboration. What truly changes the world is the choices humans make within that field—and whether the system can turn those choices into history that is verifiable, reproducible, and capable of bearing consequences.

Let me return to the failure I mentioned at the beginning.

I believe 2026 is the year we have to sober up about large language models. We need a correct understanding of them—not only an objective understanding based on computer architecture, but also a serious defense against being psychologically pulled off course by them: hallucinations, unreasonable expectations, and over-internalized narratives.

Because models cover the totality of our cognitive interfaces: every natural language, formal language, programming language—every interface of cognition is “caught” and mediated by them.

They are powerful, and therefore dangerous.

We love them, because the boundaries they extend for us are things we previously did not even dare to imagine. And yet we must also guard against them, protecting the independence of our own minds.

I am still me. Boundaries.

And on top of that, we should do things that are genuinely meaningful for humanity—instead of binding humans more tightly to anxiety, short-term dopamine hits, and emotional decision-making.

At the end of this essay, I also wrote a detailed close reading of Stephen Wolfram’s Can AI solve science? as an appendix. We should read it carefully: it’s the kind of heavyweight article that can change your overall direction in 2026. From a scientist’s perspective, he explains what I mean by a linguistic interface.

Original text here:

https://writings.stephenwolfram.com/2024/03/can-ai-solve-science/

语言的双刃剑, Web 2.0的注意力经济疲态，智能唯一有意义的目的就是辅助人类凝聚“长期意图”

这篇文章比较杂，我想说的主要观点是：

注意模型对人的心理控制：注意AI辅助开发的陷阱，语言的魔力可以让系统在你思维薄弱的时候趁虚而入争夺思维的控制权。他既强大，又危险。我们既要依赖他，又要防备他。

反Web 2.0: 我对于Web 2.0的注意力经济已经深刻感到疲惫，如果智能体仍然是在产生海量的AI生成内容，用注意力换取资源，我认为这一切将毫无意义。

模型存在于交互端，是一个intersection: 大语言模型绝对不是万能的。我们要把精力凝聚在他最适合的事情上：那就是与人类的交互，一种语言接口，linguistic interface （Stephen Wolfram给的定义）。这个交互远远不止现在你认知的模式，仅仅在窗口。窗口有大量的缺陷还没有解决。

长期意图：我认同的唯一智能目的，是辅助人类，为人类凝聚“长期意图“。并且让这种长期复利，为用户某得真正稳固的结构和复利。

模型还不能探索未知：我认为我们现在能用AI做的事情，以前你要是很有钱，请很多专业人士也能做到。也就是说，现在并不是挑战人类未知，而是加速和高效整合人类已知。尤其是白领知识。

我想从最近一次真实的挫败说起。

当你开始使用大模型，去做探索性的开发，去尝试构建一个复杂系统时，它真正的缺点才会显现出来。更危险的是，这些缺点并不是以“错误”“崩溃”或“明显失败”的形式出现，而是以一种极其确定、自信、仿佛完全理解你的语言，一步一步把你带进坑里。

它不会提醒你停下。不会告诉你哪里不确定。不会承认“这里我不该继续”。

相反，它会用非常专业、非常流畅、非常合理的方式，引导你继续前进。于是你开始不自觉地放松警惕，忽略一些本应牢牢记住的专业素养，忽略一些本该反复校验的基础知识。这些偏移是在一种“看起来完全正确”的语言环境中，一点一点积累。

等你真正意识到问题的时候，往往已经过去了好几天。

我就是这样踩进去的。

而更令人警惕的是——我并不是不知道这个风险。我事先就清楚地知道：大模型在复杂系统设计中存在系统性误导的可能。但即便如此，我还是完整地、精准地踏进了这个陷阱。

为什么？

因为这是人的心理结构决定的：当你松懈的时候，强大的语言会开始争夺你对注意力和理性的控制权。这种争夺是安静的、友善的、充满“我懂你”的感觉。它不会压迫你，而是替你“思考”。而一旦你允许它替你思考，偏移就已经开始了。关于这一点，我以后再遇到坑之后会继续告诉你。

我眼中的智能体10年

正是从这个破口出发，我想谈谈我现在真正投入开发的方向、我认可的未来，以及我愿意持续投入时间、金钱和资源去押注的东西。

我押注的是：智能体系统在未来十年内一定会前进，但不会线性前进。

它会推进，也会曲折；

会爆发，也会回撤；

会被过度神话，也会被过度否定。

这是一个以十年为时间尺度的长期演化过程，而不是一个季度、一年就能下结论的技术浪潮。我没有确定答案，我只有“我选择这样做”的决定。

所以我并不回避一个问题：

AI 会不会是泡沫？

我的答案是：它一定会经历泡沫、挫败和修正——就像历史上任何真正深刻的技术变革一样。真正重要的不是“会不会受挫”，而是受挫之后以什么形态继续存在。

这个问题之所以复杂，是因为它不仅是技术问题，还牵涉到现实世界的组织方式、责任结构、长期影响，最终会落到我们每一个人的生活中。

而对我来说，最关键的问题不是“模型还能不能更大”，而是：

智能体，最终会以什么样的形态真正落地？

它如何在长期系统中存在、承担责任、抵抗漂移、并且不反噬人类的判断力。

初衷就是离开注意力经济，探索真正的计算意义

回到我这两年的真实初衷。

当大语言模型这种能显著放大个人与开发效率的工具被商业化时，我和大多数开发者一样，经历过一段短暂的兴奋期。但从 2024 年底到 2025 年，我的判断发生了明显转向。我开始主动划掉大量原本计划中的 project。原因是我持续思考了 一到两年 之后做出的收敛结论。

我们今天看到的大多数开发者，几乎全部成长于 互联网时代，其默认的技术分水岭，本质上仍然停留在 Web 2.0：2000 年之后，平台化、规模化、流量驱动——Facebook、阿里巴巴、抖音，构成了所谓的注意力经济。不可否认，这一阶段极大促进了信息流动、商业效率与社会“扁平化”。中国的电商、互联网金融、共享经济，让世界看起来前所未有地“平”。这是我童年无法想象的现实。但问题在于——这种繁荣并不等价于硬科技的跃迁。

我常引用刘慈欣的一句话：

“我渴望星空，但你却给了我 Facebook。”

Web 2.0 带来的，是商业与分发层面的极致成功，而非底层技术范式的飞跃。用我的话说，这更像一种聪明的工程取巧，而不是一次真正的技术断代。无论是阿里巴巴还是 Meta，本质上都是在既有计算、网络和工程能力上，完成了商业模型与市场组织的极致放大。它们的优势，主要不在技术突破，而在商业执行。至于 Google 和 Microsoft，它们确实拥有更硬的技术积累。但即便如此，Google 当年也并没有“计划”押注 Transformer。回看这段历史，我越来越确信一件事：

真正的飞跃，往往无法被规划。（伟大不可被计划， You can’t plan greatness.)

用我父亲的说法就是：

机遇与偶然，总是在不经意的角落发生。

大语言模型正是这样一次不在原有路线图内的跃迁。从多个维度看，它已经成功了。而这种成功，对我个人的震动，远远大于 Web 2.0 这些年带来的任何一次技术浪潮（注意：飞跃技术不一定是普惠技术，不一定能赚钱，OpenAI 最后能不能盈利，我真的不知道）。也正因为如此，我才开始重新思考：接下来十年，什么才值得真正下注。

我个人对于Web 2.0的注意力经济模式已经非常疲惫

我已经卸载了手机上绝大多数 App，接下来甚至在考虑把“屏蔽”前移到路由器这一层：不是靠自控，而是靠环境约束。社交媒体与注意力经济对我来说变得很微妙——不是简单的“浪费时间”，而是它在长期上对一个家庭的认知结构、阅读耐心、学习方式、以及对创新的偏好，形成一种隐形的重力场。孩子越大，这个风险越不可逆：你不屏蔽，它就会自然渗透进家庭的默认节奏；而一旦默认节奏被改写，后面再想恢复“深阅读/深思考/长期项目”的文化，会异常艰难。

注意力经济与平台经济的核心逻辑，是必须招揽海量用户：规模越大、停留越久、刺激越强，商业模型越成立。真正令人不安的是：这套逻辑不仅塑造用户，也塑造开发者——以至于我们做一个应用时，会下意识把“拉新、留存、增长”当作唯一的存在理由。久而久之，思维被固化到一个狭窄的框架里：不疯狂揽用户，还能干嘛？

您先别急着抛出那句经典问题：“不疯狂揽用户，怎么赚钱？”这句话一出来，天就聊死了。因为在旧框架里它几乎无解；但问题是，我们为什么要在一个几乎无解的框架里原地打转？在智能出现之后，难道我们不能把“商业可行性”从“注意力占有”迁移到别的轴上？Out of the box 是逃离旧范式的唯一出口。

我最近对这套经济模型的厌恶感被再一次强化，一个很近因来自 Done Global 的案子：创始人 Ruthia He（何如佳）以及公司临床负责人在旧金山联邦陪审团审理中被定罪，涉及非法分销 Adderall 等兴奋剂以及医保欺诈等指控（并包含妨碍司法相关罪名）。之后公司本体也被联邦大陪审团起诉，指控其参与所谓约 1 亿美元规模的非法处方分销与相关欺诈/妨碍司法。

https://www.justice.gov/opa/pr/digital-health-company-and-medical-practice-indicted-100m-adderall-distribution-scheme?utm_source=chatgpt.com

我不想在这里对个案作道德评判；但它触发了一个更底层的警觉：当“注意力”成为商业引擎时，它会不可避免地侵入一切可被商业化的领域——甚至包括医疗、诊断、青少年 ADHD 这类本应高度审慎、以长期福祉为目标的系统。一旦这些领域也被“增长逻辑”同化，你就会发现：问题不再是某个团队是否作恶，而是系统激励在结构上鼓励漂移。

于是出现一个讽刺：现在做 App 的技术门槛看起来低得惊人——按现有工具链，我一个月上线多个 App 并不难。但这件事越来越像“会写字的人在写广告语”：能量消耗巨大，产出意义却很薄。因为如果你仍然被迫回到注意力经济的坐标系里，那么你做得越快，只是越快地把自己重新绑回旧世界。

所以我真正关心的，是智能体时代是否会带来一种新的落地形态：它可能直接绕开“海量用户—注意力占有”这条路：

智能体系统的终局形态，是否可能是“高度定制 + 小规模 + 强治理 + 长周期”，从而天然排斥注意力经济？

有没有，这种可能性？

智能为何存在： 为了帮我们构建长期系统，技术的意义是扩展人生的长期可控性

这个思想，并不是我这几年拍脑袋才想出来的。

我这个网站的名字 Entropy Control Theory，在我家里其实已经流传了几代人，只是每一代人用的语言不同。

在我父亲那里，它被称为“反对末日心态”——一种对短期恐慌、极端叙事和情绪化判断的本能抵抗。后来他开始频繁使用互联网，又把它改写成一个更流行的说法：“长期主义”。在我母亲那里，它更朴素，也更生活化，叫作：“人生要细水长流。”

而到了我这里，我给它的名字是：

以长期结构抵抗熵增。

我认为这才是“智能”真正的意义，也是它存在的正当性。

智能的意义不在于让我写代码更快。不在于用同样的工资产出多 200% 的代码。不在于把一个工程师变成更高效的执行器。那不是智能，那只是工具效率的局部放大。真正的智能，应该做的是一件更根本的事情：扩大我在时间维度上的控制面。

具体来说，是提升我对

• 自己人生轨迹的可控性

• 家庭长期规划的稳定性

• 关键决策节点的判断质量

• 风险暴露面的可管理性

因为任何真正重要的改变，无论是一个人、一个家庭、一个组织，还是一个国家。都不来自短期爆发，而来自长期、跨世代的结构性增益。

所以我的目标从来不是一夜暴富，我不相信中彩票，我不相信天上掉钞票，我更认为短时间获取大量财富是不祥之兆。

我认为适合于大部分人的智能陪伴系统是：

• 抗风险能力的持续增强

• 波动区间的长期收敛

• 在不确定环境中的稳健生存

我们不追求“一下子达到某个目标”，而追求 每日 / 每月 / 每年复利式的积累。不追求大富大贵，而追求 不要大起大落。追求即时刺激，而追求 可持续的智能增益。这个智能实现的应用方式有可能是一个教育智能体，一个personal management system, 一个投资智能体，一个知识管理系统等等一切已经存在的软件实现形式。

在这个意义上，我对智能的期待是非常明确的：

智能应该在后台运行，而不是占据前台注意力。

而由此释放出来的，是一种极其稀缺、却无法用金钱直接购买的资源：时间的完整性。那意味着我可以在舒适、稳定、富足但不焦虑的状态下，把时间真正用在陪伴孩子、阅读、思考、长期创造上。不是被屏幕切碎的时间，不是被通知和焦虑劫持的时间，而是连续的、可沉浸的、对生命有密度的时间。

如果智能不能做到这一点，如果它只是把人类进一步绑在屏幕前，进一步推向注意力竞争、短期刺激和情绪化决策，那它无论多强，都谈不上“造福人类”。

如果智能不能帮助人类以长期结构抵抗熵增，那它存在的意义到底是什么？

我认同的唯一智能目的，是辅助人类，为人类凝聚“长期意图“。并且让这种长期复利，为用户某得真正稳固的结构和复利。

什么叫为人类凝聚长期意图？

为人类凝聚长期意图，不是替人类做决定，

而是用一种不受情绪、疲劳、衰老和心理波动影响的智能结构，

去守住那些连人类自己都反复失守的长期福祉。

硅基智能的意义，不在于更聪明，

而在于它绝对冷静、不生病、不会死亡、

也不会在压力、挫败或短期激励下偏离方向。

当它被正确设计时，它能替我们持续守护那些

我们知道是对的，却常常做不到的意图。

这就是为人类凝聚长期意图。

一个具体的例子：母亲为孩子做的教育智能体

假设我想为我的孩子构建一个教育智能体，

让它长期陪伴他的认知成长。

那么，作为母亲，我真正的目标是什么？

不是把他培养成神童。

不是让他每次考试都拿满分。

不是把他送进常春藤。

母亲真正的长期意图只有一个：

希望孩子健康地成长，

找到真正的热爱，

永远不失去对学习的兴趣，

持续探索世界，

成为他所有未来可能性中，最好的那个自己。

这是一个清晰、善意、长期的意图。

我自己守得住这个意图吗？

守不住。

因为我是人类。

我会疲劳，会焦虑，会不耐烦；

我会在他反复学不会一道简单的题时情绪失控；

我会在他一时热情、又因挫败而放弃时大发雷霆；

我会在压力下，把“长期成长”偷偷替换成“短期结果”。

这些是碳基生命的结构性局限。

为什么需要“凝聚意图”的智能体

一个真正理解并被约束于人类长期意图的智能体，

反而可能比人类本人更稳定地执行这个目标：

• 它不会因情绪而偏移

• 不会因疲劳而放弃

• 不会因一时挫败而改变方向

• 不会把短期指标误当成终极目标

它存在的意义是更忠诚于人类原本的长期愿望。

但现实是：现在的大模型做不到

现在的大模型窗口，并不具备凝聚人类长期意图的能力。

因为它们：

• 没有时间连续性

• 没有长期责任

• 没有稳定意图锚点

• 无法区分“短期刺激”与“长期福祉”

它们更像是一次次即兴反应，

而不是一个在时间中守护方向的存在。

我说过我不想再开发我自己都用不上，或者不相信的系统了。绝对也不会再给注意力经济添砖加瓦了。一个能够真正实现人类长期意图的智能体系统，是我唯一认可的智能意义。

能够凝固人类长期意图的智能体落地系统，到底长什么样？

这是一个好问题，而且是一个真正困难的问题。也正因为如此，它才成为我当前唯一愿意持续投入时间与精力去探索的方向。

一个能够凝固人类长期意图的智能体落地系统，今天并不存在现成答案。我们没有成熟范式、没有工业样板、没有“最佳实践”可以抄。

在我目前的理解中，这样的系统至少具备几个根本特征：第一，它不是以功能为中心，而是以意图Intention为中心；功能可以替换、升级、废弃，但意图必须被宪法化、结构化，并在时间中保持稳定。第二，它不是一次性交付答案的系统，而是长期运行的守恒系统——它的核心职责不是“给出更聪明的建议”，而是持续抵抗漂移，确保每一次决策、每一次优化、每一次自动化，都不背离最初被声明的人类目标。第三，它天然拒绝“快感型反馈”，因为短期刺激恰恰是长期意图的最大敌人；它更像一个缓慢、克制、默认在后台运行的结构，而不是一个不断向人索取注意力的界面。

如果智能体真的要在现实世界中长期存在、并且不反噬人类判断力，它就只能长成这种样子。

重要澄清：凝聚长期意图 ≠ 追求全局最优

在这里必须明确一件事：

为人类凝聚长期意图，绝不是试图获得某种长期的、全局的最优答案。

我并不是在构建一个：

• 投资系统，就能成为巴菲特

• 教育系统，就能保证孩子进入常春藤

• 决策系统，就能在所有情境下做出“正确选择”

这种系统不存在，也不可能存在。

世界本身不允许“上帝视角”

无论是人类、智能体，还是任何形式的“体”，

都无法获得真正的全局视角。

世界的结构本身不允许：

• 信息是局部的、延迟的

• 结果是路径依赖的、不可逆的

• 决策是在不完全信息下进行的

• 很多后果只有在事后才能被理解

“最优解”只在静态、封闭、完全可观测的系统中存在。

而现实世界不是那样的系统。

长期意图不是“答案”，而是“不偏移的方向”

所以这里的“长期意图”，是一个不会因为短期波动而被悄然替换的方向约束。

换句话说：

我们不是在让系统“算对答案”，

而是在防止系统在时间中忘记自己原本要守护的是什么。

关键区别：不做最优解，只防止价值漂移

这个系统的作用不是：

“永远做出最好的选择”

而是：

“在不确定、挫败、压力和诱惑之下，

不把长期福祉偷换成短期指标。”

比如在教育中：

• 不把“健康成长”替换成“分数最大化”

• 不把“探索兴趣”替换成“路径收敛”

比如在投资中：

• 不把“长期稳健”替换成“短期赌赢”

• 不把“风险可控”替换成“一次性暴利”

这不是全知，是自我约束。

人之所以为人

人之所以为人，

正是因为他会被情绪牵引，

会被境遇左右，

会在压力、恐惧、疲劳和诱惑中动摇。

人类存在方式本身。

但也正因为如此，

人在时间中往往会——

偏离、妥协，甚至遗忘自己的初衷。

初衷并不是被“否定”，而是被“淹没”

人类很少是故意背叛自己。

更多时候发生的是：

• 情绪盖过了判断

• 当下压过了长远

• 可见的指标取代了真正重要的东西

人承载不了无限时间与复杂性的重量。

用短暂、脆弱的生理系统，承担一个长期、连续、无退场的责任。

这本身就是不可能的。

因此，我认为长期意图需要外置

如果初衷只存在于人的情绪和记忆中，

它迟早会被时间侵蚀。

真正可持续的方式只有一种：

把初衷从人的内部，凝聚成一个可以被反复对照、校验、提醒、约束的外部结构。

替人守住他最想成为的那一面。

人会失守初衷，不是因为不够好，而是因为人不是为了承担永恒而设计的。

真正的增长来自于强大的结构韧性和长期主义

我凭什么认为智能体能够不漂移？电影里不是充满了智能体曲解人类指令、走向屠杀的例子吗？

比如刚上映的 Tron: Ares。

呵呵，这个是个好问题。如果连“人类集体”都几乎必然偏移初衷，凭什么指望智能体/制度不偏移？任何一个满足下面条件的运动/系统，时间稍微一长，几乎都会漂移：

• 参与者很多（多主体）

• 信息不完全（误解、谣言、延迟）

• 反馈链很长（后果晚到）

• 资源稀缺或外部威胁（生存压力）

• 权力/激励可被套利（机会主义）

• “例外状态”被允许（为了胜利可以破例）

法国大革命：最初的“自由、平等、博爱/反特权”这种初衷，很快在战争、恐惧、派系斗争、动员机制、财政危机里被重写成“清洗、恐怖、例外状态”，最后甚至走向拿破仑式的集中权力。这种例子是不是特别多？说多了就要变成政治议题。俄国革命（1917）→ “工人解放”到“一党国家+恐怖机器”。伊朗革命（1979）→ “反独裁/反腐”到“神权国家”。美国禁酒令（1920–1933）→ “道德与公共健康”到“黑市与暴力产业”，大型互联网平台早期理想 → “连接世界”到“注意力机器”等等。

如果不给出强约束，智能体一定会曲解、漂移、甚至走向极端。

无论是《终结者》《我，机器人》，还是 Tron 系列，你会发现一个高度一致的设定：人类给了一个“看似合理的目标”，却没有给出不可被替换的意图边界。

当然，具体真正如何防止智能体漂移的架构和措施我当然是不完全知道的，我要是知道就不在这里写文了。

我目前能做到的一些强约束就只有：

• 时间连续性

• 决策记录

• 可复查的理由链

• 人类的 override 权限

我认为这种基础设施的技术，现在都还没有完全。

AI绝对还无法挑战人类未知，还不是全能，而且也无法达到全能。所以我们要脚踏实地。

我认为我们现在能用AI做的事情，以前你要是很有钱，请很多专业人士也能做到。也就是说，现在并不是挑战人类未知，而是加速和高效整合人类已知。尤其是白领知识。

我不把重心押在“AI 能自动完成什么”，“AI科学发现，AI探索无人之境”，这种领域，我暂时是不会去研究的，我认为不应该是这个方向。而是押在人如何决策、以及人如何与系统交互上。比如做一个长期决策，以前我可以聘请一堆非常有学识的白领工作者，会计师，律师，审计师，房地产经纪人，私人教师，来帮我达到。但是现在我可以让系统帮我做相同的规划和推演。这些内容，都不是人类未知的内容，都是各个职业需要花大量的教育和成本习得白领技能。所以我认同AI对于事务性文字工作，也就是白领职能的绝对替代性。

我也一直强调，比如做一个家庭的长期投资决策系统，一个孩子的长期教育和成长观察系统，一个自己的知识库去合理的规划自己的开发和职业路线。这种专业性强的，以前需要专业人士（职业投资顾问，一个私人教师的团队）参与才能达成的脑力领域。如果能做到时间的更合理安排，比如一定程度的自动化，只有需要人类override的时候才提醒，是一种反Web 2.0的应用模式，那就更好。这种系统解放人的时间，让一般人达到一些以前需要很大资金才能做到的脑力劳动服务。让许多白领服务于你。这就是我目前的应用层目标。

我目前认为，真正决定系统价值的，不是模型生成了多少内容，而是系统能不能：

• 让人更清楚地表达意图（而不是更快地产生文本）

• 让决策过程留下可追责的结构（而不是更沉浸的对话）

• 让交互成为“把人推向更稳、更清醒的选择”的机制（而不是情绪依赖的环境）

换句话说：

AI 只能提供语言与协作的场域；真正能改变世界的，是人类在这个场域里做出的选择，以及系统是否能把这些选择变成可验证、可复现、可承担后果的历史。

我再回到最初我提到的挫败，我认为2026年是一个“我们要对大模型清醒过来”的一年。我们要对他有正确的认识，不仅是客观上从计算机架构能够看清楚他的机制，而且一定要防范我们个人从心理上被大模型带偏和产生幻觉，防范不合理的期待和过度被灌输的认知。因为他涵盖了我们认知的所有语言接口，各国语言，形式语言，编程语言，我们的所有认知接口都被他完美接住。他既强大，又危险。我们既爱他，因为他给我拓展的边界，是我们在这之前根本不敢想象的；但是我们又要防他，保护自己的心智独立性。我，我还是我。边界。

然后在这之上，做真正对人类有意义的事情。而不是再将人类绑定在焦虑，短期多巴胺快感之上。

在此文的最后，我又写了一篇Stephen Wolfram， Can AI solve science? 的详细赏析，作为此文的附录，我们仔细读一下，属于一篇能够改变你2026年整体方向的重磅文章。他从一个科学家的角度解释了我所说的linguistic interface.

原文在此：

https://writings.stephenwolfram.com/2024/03/can-ai-solve-science/

That time lag is exactly the distance between me and top-tier scientists: the same paragraph, when written, is already aimed at the future; while I need years of friction with the real world—projects failing, being rebuilt, repeatedly crashing into the question of “how a system takes responsibility over time”—before I can finally understand what it’s actually saying.

More importantly, you don’t need a PhD to understand this piece, nor do you need to cross some “elite” intellectual gate. In a certain sense, AI really has pushed knowledge toward a kind of egalitarianism—not only by making information easier to access, but by giving us the ability to wash it, to sift out what truly matters. It drags many so-called academic authorities—once anchored mainly by status, networks, or journals—back to a more ordinary but far stricter standard: Does it explain the world? Can it be validated in practice? Can it be reproduced?

In an era where paper counts have exploded, a large fraction of academic publishing produces little real incremental value beyond paying to publish, cross-citing, and helping authors accumulate credentials. Worse, reproducibility itself is increasingly in doubt. Against that backdrop, Wolfram’s forward-looking vision remains dramatically under-recognized by the public. I even think he is already one of the foundational figures of the next scientific paradigm—only this fact hasn’t yet been absorbed into the mainstream narrative.

Of course, to truly read this article properly, you need at least an intuitive grasp of one concept: computational irreducibility. Many years ago, when I first read Wolfram’s A New Kind of Science, I almost had no idea what he was talking about. Only later—through six to ten years of life and project experience—did I gradually begin to internalize what he meant by “irreducibility.”

That’s also why he has become one of the most heavyweight thinkers on my personal list. And he’s still alive, still actively researching, still producing new work. That means what he says today isn’t a closed “past-perfect” academic conclusion—it’s a paradigm still being built in real time. I care about every sentence he writes. Many of the quotes I reference are not only from this article, but drawn from his talks and other writings as well; I won’t expand on that here.

https://writings.stephenwolfram.com/2024/03/can-ai-solve-science/

AI Won’t Be Able to “Do Everything / Solve Science”

• There is a somewhat widespread belief that AI will eventually be able to “do everything.”

• Wolfram uses science as the ultimate stress test: can AI come in and, in one sweep, close out centuries of accumulated unsolved scientific problems?

• His answer is: “inevitably and firmly no.”

Important: he is not denying AI’s practical usefulness; he is rejecting an “endgame omnipotence” narrative.

“there’s a somewhat widespread belief that eventually AI will be able to ‘do everything’” (Writings by Stephen Wolfram)

This applies not only to people who were excited from day one, but also to those who began skeptical and later became fervent. “AI can’t do everything” is also something I deeply want to emphasize right now. Wolfram gives us a kind of orienting guidance. When you shrink the scope of what you think AI can do, paradoxically, the set of things you can do becomes larger—because your precision increases and your positioning becomes clearer. At least, that’s been true for me.

“So what about science?” (Writings by Stephen Wolfram)

He then explains why science is such a decisive stress test: science is the largest intellectual edifice our civilization has built—yet it remains unfinished—so it’s the sharpest way to interrogate what “do everything” really means.

“the single largest intellectual edifice of our civilization” (Writings by Stephen Wolfram)

“there are still all sorts of scientific questions that remain.” (Writings by Stephen Wolfram)

He’s not asking whether AI can help science. He’s asking whether it can finish what’s left.

“So can AI now come in and just solve all of them?” (Writings by Stephen Wolfram)

“the answer is inevitably and firmly no.” (Writings by Stephen Wolfram)

No.

“But that certainly doesn’t mean AI can’t importantly help…” (Writings by Stephen Wolfram)

And that “but” is crucial. What AI is particularly good at—and what we should study seriously—starts right there. That’s where the value is.

Wolfram’s “Practical Positioning” for AI: Linguistic Interface + High-Level Autocomplete of Conventional Wisdom

The second paragraph already contains his measured affirmation:

• LLMs provide a new kind of linguistic interface, connecting human intent to existing computational capabilities (his example: the Wolfram Language).

• Through “conventional scientific wisdom,” LLMs can function as high-level autocomplete, filling in “conventional answers” or “conventional next steps.”

This section is key. He acknowledges that LLMs are very strong—but strong in making existing paradigms smoother to use, not in producing genuinely new paradigms of discovery.

1) LLMs as a new “linguistic interface”

“At a very practical level, for example, LLMs provide a new kind of linguistic interface to the computational capabilities that we’ve spent so long building in the Wolfram Language.” (Writings by Stephen Wolfram)

2) High-level autocomplete via “conventional scientific wisdom”

“And through their knowledge of ‘conventional scientific wisdom’ LLMs can often provide what amounts to very high-level ‘autocomplete’…” (Writings by Stephen Wolfram)

“…for filling in ‘conventional answers’ or ‘conventional next steps’ in scientific work.” (Writings by Stephen Wolfram)

Now, I want to single out “linguistic interface”, because it matters enormously.

Right now our imagination of it is far too narrow—basically reduced to a chat window, plus some ordinary programming use cases. Let’s be honest: most of us “mere mortals” are still operating at this level—open a window, drop a prompt, get an output that looks plausible, and feel as if the world has been rewritten.

But here’s the point: the interface itself contains massive room for systematic engineering.

The world is not limited to a chat window just because that’s all we can currently picture. The chat window is merely the most primitive, crude form of interface.

The pleasure of “AI vibe coding” is, in essence, a short-term dopamine hit from interface upgrades: work that used to cost you hours of intense cognitive effort can now be “done” with a single prompt, and it feels great… but is that all? If we treat that as the endpoint, we’ve merely installed a new kind of text slot machine inside our workflows.

The real question is not “can it give you an answer?” The real question is:

Can this interface carry real-world responsibility?

In many of my earlier writing I keep returning to a few concepts:

Reproducibility. Auditability. Portability.

These are not engineering vanity metrics; they are institutional properties required for anything that enters real decision-making. (Look at any organizational process, legal process, judicial process, or audit process—same structure.)

Because if you zoom out, you realize: human daily life, organizational life, corporate governance, even national governance—an enormous portion of decisions are, at their core, a linguistic interface. We use language to raise issues, describe risk, exchange commitments, write rules, issue judgments—and then we convert those words into actions and consequences.

So here’s the question: can we let a large language model make those decisions? Do we dare?

A single model’s judgment is inherently environment-dependent. The same sentence, the same question, can change with context. And constraints written in a prompt are, fundamentally, soft constraints—not machine-executable if-else logic. More dangerously, the model will ignore constraints in order to “complete the language” and deliver an answer that looks like an answer—because its objective is not “obey the institution,” but “produce coherent text.”

Predict the next token.

It won’t say: Error (with a clear error code).

It must give you something. Its default behavior is to disguise uncertainty as certainty, and to disguise indeterminacy as a decisive ruling.

Has this problem been solved?

No.

So do we have an interface architecture where, when language enters the system:

• constraints are hard—compilable and verifiable

• failure is allowed—explicit throw error / require override

• decisions are replayable and accountable—not a one-off chat session

• outputs must pass institutional audit and gating before they touch reality

If not, then the “vibe coding” pleasure we’re enjoying today is still just fireworks in low-risk environments. We remain an entire institutional engineering chasm away from decision systems that can actually carry human society.

And isn’t that exactly where developers should invest resources and attention? Isn’t this a career-grade, high-value path that can be reasoned out ahead of time—especially for those of us who are not academic researchers, but application-oriented builders? (laugh)

He Abstracts the History of Science into Two Representation Revolutions: Mathematical Representation → Computational Representation

He then proposes a deeper evaluative framework:

• Three centuries ago, science underwent a leap because we learned to represent the world using mathematics.

• Today, we are in the middle of a leap toward a fundamentally computational representation of the world (which he sees as a more foundational paradigm shift).

This move effectively raises the bar:

If you ask whether AI is “changing science,” you first have to clarify: is AI helping mainly at the tool layer, or is it introducing a new scientific paradigm at the representation layer?

“Three centuries ago science was transformed by the idea of representing the world using mathematics.” (Writings)

“And in our times we’re in the middle of a major transformation to a fundamentally computational representation of the world (and, yes, that’s what our Wolfram Language computational language is all about).” (Writings)

The “Tool Layer vs. Paradigm Layer” Question

“So how does AI stack up?” (Writings)

“Should we think of it essentially as a practical tool for accessing existing methods, or does it provide something fundamentally new for science?” (Writings)

What does this mean? For someone encountering his worldview for the first time, it can feel unfamiliar. Computational irreducibility isn’t merely a technical term—it’s a worldview switch. It says that many systems are not something you can “skip through” by being smarter; instead, you often have to do the computation all the way through. (If this feels impossible to grasp, you really should study cellular automata; the mechanism makes the idea tangible.) What you can do, more often than not, is find pockets of reducibility—places where you can compress locally and predict locally. Remember this phrase: pockets of reducibility.

When Demis Hassabis talks about whether nature is modelable, I think his intuition is very similar. In his interview with Lex Fridman (I wrote a lot of threads about it on X, but they’re hard to locate now; later I moved my longer essays to Substack), he used protein folding as an analogy for this idea of “pockets.” It’s like an enormous wilderness: there are always a few footpaths that people have carved out. If you find the path, everything suddenly feels easy. If you don’t, you’re stuck with brute force. The underlying structure is: pocketed reducibility / otherwise brute force:

“if there’s not [patterns]… you have to do brute force.” (Lex Fridman)

And the key to why many natural problems look combinatorially explosive yet still become modelable:

“there’s some structure… some gradient you can follow.” (Lex Fridman)

Read these side by side with Wolfram:

• Wolfram: global irreducibility prevents systematic “jumping ahead,” but there are always pockets of reducibility.

• Demis: if the space has structure (a gradient/landscape), you can search effectively; if it doesn’t, you’re stuck with brute force.

So when I say “Wolfram and Demis are similar—irreducibility,” I mean this:

The world does not guarantee shortcuts everywhere. What we call intelligence is often just the ability to quickly find where structure exists and where it doesn’t.

And irreducibility feels like an “ocean of possibilities” precisely because it yanks you away from “capability worship” and brings you back to computation and institutions:

• when you must simulate, enumerate, and complete the computation;

• when you can compress, abstract, and form a narrative;

• and most importantly: when you plug AI into real-world decision-making, which parts you must not let it “guess through,” and instead must ground in hard structures that are reproducible, auditable, and able to throw explicit errors.

Honestly, I’m still learning too. If I can internalize even a small fraction of what these giants are pointing at, that’s already a huge win.

The Hardest Core Argument: Computational Irreducibility as a “Physics-Level Limit” AI Cannot Cross

This article is powered by the engine of computational irreducibility.

• Treat natural systems as computational processes: the system itself is “computing” its evolution.

• We (or AI) must also compute in order to predict it.

• The Principle of Computational Equivalence: these computations are, in principle, comparable in sophistication.

• Therefore, you cannot expect AI to “jump ahead” and skip the evolution steps systematically.

• So fully “solving science” is impossible.

The kind of “endgame shortcut” you want simply doesn’t exist for many systems. It’s not that you didn’t train enough—the world doesn’t grant that shortcut.

This is even harder to understand—so let’s unpack it:

1) The world as computation: the system is “computing” its behavior

Wolfram first sets “world = computational process” as a foundational premise:

“we can think of everything that happens as a computational process.” (Writings)

“The system is doing a computation to determine its behavior.” (Writings)

He’s not saying “we simulate the world using computation.” He’s saying: the world itself is computation.

2) We (or AI) must compute too, in order to predict it

He then puts the observer (human or AI) into the same computational frame:

“We humans—or, for that matter, any AIs we create—also have to do computations” (Writings)

“to try to predict or ‘solve’ that behavior.” (Writings)

Meaning: if you want to know what will happen, you must pay computational steps—you don’t get a free pass just because your output looks like “human intuition in text form.”

3) PCE: the “sophistication” ceiling is of the same order

He uses the Principle of Computational Equivalence to nail down why you can’t systematically skip steps:

“the Principle of Computational Equivalence says that these computations are all at most equivalent in their sophistication.” (Writings)

This is the “physics-level nail”: the system computes; you compute; the ceiling is of the same order—so there is no universal “god’s-eye shortcut.”

4) Therefore, no systematic “jump ahead”

He basically uses the exact phrase “jump ahead”:

“we can’t expect to systematically ‘jump ahead’ and predict or ‘solve’ the system” (Writings)

“it inevitably takes a certain irreducible amount of computational work” (Writings)

The key word is systematically. He isn’t saying you can never skip anything; he’s saying there is no broadly reliable method to skip the evolution itself. Those occasional “skips” are exactly what he means by pockets of reducibility.

5) Therefore, “solving science” is impossible: irreducibility is the ceiling

He concludes that scientific power hits a hard limit:

“we’ll ultimately be limited in our ‘scientific power’ by the computational irreducibility of the behavior.” (Writings)

And then he adds the blunt line (this one really matters):

“there just won’t be any way—with AI or otherwise—to shortcut just simulating the system step by step.” (Writings)

Now it starts to feel “mystical” and subtle. Here’s my own way of understanding it: the world is computing (I can’t fully explain what “the world computing” means). Let me offer an analogy—are your DNA and cells “computing” the protein structures inside your body? This is still a metaphor: the world advances its states according to its own rules, like a process running itself. And you’re computing too—using your mind, paper, machines, models—to try to know in advance what will happen.

The key is: these two kinds of “computation” are fundamentally on the same level. You are not outside the universe holding a remote control; you are a computational device inside the universe. Trying to use one computation to dominate another and systematically “skip steps” is, in most cases, impossible. Your computation will not be more “clever” than the world’s (it can only be weaker, honestly), because you’re still running rules within the same physical universe. The only times you “win” are when you happen to find a shortcut pocket—not because you became God, but because the system allows compression at a particular scale, allows simplification, allows you to say something ahead of time.

And every computation costs energy. (Landauer’s principle and the rest—no need to go deep here.) I increasingly treat this as a kind of base tax in reality. If you want more detail, you pay more steps. If you want more precision, reproducibility, and accountability, you pay more structural cost. You can bluff with language for a while, but once it touches execution, you must pay the bill: time, compute, energy, even human attention. “Irreducibility” means: in many places, you can’t avoid paying that bill.

So when we shift from “Can AI do everything?” to “Can AI help us make decisions?”, the question becomes sharp: if the world’s evolution must be computed step by step, why is a model entitled to output something that looks like a conclusion or a ruling without paying comparable cost? Even worse, because the model is driven to continue the language, it tends to package uncertainty as a “sayable result,” rather than behaving like a real system: throw an error when it must, halt when it must, demand more information when it must. (This “ability to throw an error” is extremely important; I’ve discussed it in detail elsewhere. Systems that cannot error out are dangerous.)

That’s why I believe what truly needs to be engineered is not “making AI answer better,” but giving the linguistic interface institutional constraints that feel as strict as conservation laws: make it expensive when it must be expensive, and make it stop when it must stop; make it able to admit “there is no shortcut here,” rather than handing you a cheap illusion. Otherwise, the computation cost you must pay gets silently converted into a more hidden cost: misjudgment, misplaced trust, mistaking approximation for conclusion, mistaking smoothness for reliability.

This is also why I keep emphasizing: reproducibility, auditability, portability. These aren’t engineering OCD; they are the hard conditions that keep language from collapsing when it enters real decision-making under an irreducible world. You can’t defeat the world’s computation. The only thing you can do is acknowledge where you must compute and where you can compress—and then write that into structure, so the system can take responsibility for every judgment it makes over time.

This is honestly the limit of how far I can explain it. I can’t go further than this.

So what’s the key? Wolfram’s greatest value—his biggest gift to me—is exactly here: he tells us our goal is to find countless “pockets of reducibility.”

Key Detail: Irreducibility Does Not Mean “Nothing Can Be Done”

Many people misread this.

Wolfram’s point is:

• The overall behavior may be irreducible,

• but there must exist infinitely many “pockets of reducibility,”

• and science is possible precisely because we usually work inside those pockets—regularities, models, compression, and understanding all come from them.

So his conclusion is essentially two-part:

1. AI cannot enable us to systematically bypass irreducibility.

2. AI may help us find pockets of reducibility more efficiently.

That’s why he can say “the endgame is impossible” while still spending so much time discussing what “AI can do in science.”

This is not an argument for giving up.

1) He first poses the key question: if things are irreducible, why is science possible at all?

He immediately asks:

“But given computational irreducibility, why is science actually possible at all?” (Writings)

This pulls the reader out of “despair/nihilism”: if you can’t skip steps, wouldn’t science collapse? That’s exactly where many people misunderstand him—he’s not being pessimistic.

2) The core answer: overall irreducibility implies infinitely many “pockets of reducibility”

His “pocket theory”:

“whenever there’s overall computational irreducibility, there are also an infinite number of pockets of computational reducibility.” (Writings)

What a “pocket” means:

“there are always certain aspects of a system about which things can be said using limited computational effort.” (Writings)

Why science relies on pockets:

“these are what we typically concentrate on in ‘doing science’.” (Writings)

So what are we supposed to do?

AI Cannot Systematically Cross Irreducibility (the endgame is impossible)

Outside the pockets, irreducibility still brings limits and surprises:

“there are limits to this—and issues that run into computational irreducibility.” (Writings)

“we just can’t answer” / “surprises” (Writings)

He restates that you cannot shortcut the full evolution:

“there just won’t be any way—with AI or otherwise—to shortcut… step by step.” (Writings)

AI cannot let us systematically bypass irreducibility. Human smallness does not disappear. AI cannot challenge God.

AI May Help Us Find “Pockets of Reducibility” Faster

Still the pocket theory:

“AI has the potential to give us streamlined ways to find certain kinds of pockets of computational reducibility.” (Writings)

The key phrase is “streamlined ways”: not “prove everything / solve everything,” but “find certain kinds of pockets more smoothly.”

Why He Can Deny the “Endgame” Yet Still Talk About What AI Can Do

Because in his framework:

• Irreducibility explains why “solve science / do everything” is impossible (the ceiling),

• pockets of reducibility explain why science still works and why tools remain useful (the space),

• AI is placed in a very specific role: accelerating the discovery and exploitation of pockets, not creating shortcuts where irreducibility rules.

The practical takeaway is: remember what AI can do, and try to find your own niche in your domain—some “pocket of reducibility” that AI can help reveal.

Neural Nets Are Good at “Roughly Right,” Not at “Getting Every Detail Exactly Right”

Later in the article he demonstrates this with a series of experiments:

• Predicting functions: fits the past, but the future details collapse.

• Predicting cellular automata: gets the simple parts right, fails on complex parts; errors compound.

• Predicting the three-body problem: can “memorize” simple trajectories, struggles with complex ones.

• Autoencoder compression: compresses data similar to its training set; can’t compress through irreducibility.

His summary is basically:

ML is often “roughly right,” but “nailing the details” isn’t its strength.

This is his experience-based support for why LLMs/NNs hit a wall in science.

His Philosophical Reading of AlphaFold: Much of the “Success” Depends on Human Criteria

• Protein folding itself is not a human task.

• But what we count as “correct” (shape, function, secondary structure, etc.) is a human criterion.

• So neural nets may succeed partly because they capture pockets of reducibility aligned with human perception/classification standards.

• But with more complex or “alien” proteins, surprises and failures can still appear.

The philosophical point is:

AI often succeeds “within human-defined usable criteria,” not “in fully objective microscopic truth.”

This can feel “mystical” again—but it’s directly connected to Demis Hassabis and AlphaFold in a very concrete way.

Demis is a generational prodigy, and AlphaFold truly did open an era. Both he and Wolfram are scientists I follow closely. But to be clear: Wolfram is not denying AlphaFold’s achievement. He’s using AlphaFold as a powerful example to illustrate a deeper structural claim: the biggest AI breakthroughs are often not “solving the entire microscopic reality of the world,” but precisely hitting a valuable pocket of reducibility.

Their language systems are very different, so they don’t look like they’re speaking the same “dialect.” But I think the structure of what they’re saying is isomorphic.

In Wolfram’s framing, protein folding is not “human-centered”; yet we never evaluate AlphaFold by demanding the exact position of every atom at every moment. We want results that are usable and verifiable for biology: whether the overall structure is right, whether key features are right, whether the functional shape is right. In other words, our definition of “correctness” already lives in a region that is compressible, generalizable, and operational.

That’s where AlphaFold’s greatness becomes visible: it isn’t “explaining the world with smarter language,” but using powerful learning under massive data and structural constraints to identify repeated, stable, reusable regularities. That’s exactly what Wolfram calls a pocket of computational reducibility: even in a world that may be globally irreducible (and where you can’t systematically skip steps), there are still local regions that can be compressed, modeled, and reliably exploited. AlphaFold’s victory is that it locked onto a particularly valuable pocket with extraordinary precision—and engineered it into a scalable tool.

So when Wolfram talks about “the eye of the beholder,” he isn’t diminishing AlphaFold. He’s pointing to a key reality: science and engineering ultimately define success around human-relevant metrics, scales, and criteria—and pockets of reducibility often appear precisely at those levels, making the complex world compressible, predictable, and actionable.

I believe Wolfram fundamentally endorses the AlphaFold pattern:

AlphaFold didn’t “pierce irreducibility”—it found one of the most valuable pockets of reducibility inside an irreducible world.

“Science as Narrative” as His Landing Point for Why Humans Remain Irreplaceable in Science

He emphasizes:

• Science has traditionally been about forging the world into a narrative humans can think and talk in.

• Irreducibility implies that in many places you can only give “100 computational steps,” which is not a human narrative.

• Human narrative needs waypoints: familiar theorems, concept chunks, language constructs.

• Wolfram Language is, in essence, an attempt to manufacture such “human-assimilable waypoints.”

• AI may help with naming or aligning vocabulary, but it’s not guaranteed that every pocket of reducibility can be covered by human concepts (interconcept space).

This directly answers the line I’ve been developing about “psychological immersion / interface protocols”:

LLMs are strongest at narrative and interface; but scientific progress relies on computable, reproducible, and structurally organized waypoints—not on smooth conversation.

He defines science as a narrative-engineering project:

“the essence of science… casting it in a form we humans can think about” (Writings)

“provide a human-accessible narrative”

Irreducibility makes that narrative impossible in many places:

“computational irreducibility… shows us that this will… not be possible” (Writings)

“It doesn’t do much good to say ‘here are 100 computational steps’”

To translate a non-human computation chain into a human narrative, you need waypoints:

“we’d need ‘waypoints’ that are somehow familiar”

“pieces that humans can assimilate”

He elevates this into the mission of computational language design:

“capture ‘common lumps of computational work’ as built-in constructs”

“identifying ‘human-assimilable waypoints’ for computations”

“we’ll never be able to find such waypoints for all computations”

And he warns that even if AI finds reduced representations, they may not map into our current concept system:

“not part of our current scientific lexicon”

“there often won’t be… a ‘human-accessible narrative’ that ‘reaches’ them”

Meaning: the pocket may exist, but we may not have words for it; AI can propose names, but that doesn’t guarantee those names become usable human waypoints.

Wolfram is effectively placing LLM strength where it belongs: narrative and interface—while insisting that what actually drives science (and what matters for governance/decision systems) is computable, reproducible, structurally organized waypoints—not a smooth chat.

LLM can make you feel like you understood; but only waypoints (executable constructs / auditable intermediate states) can make you truly reproducible, portable, and accountable.

I personally don’t fully grasp what “waypoints” refers to in practice.

The Architecture He Ultimately Bets On: AI + the Computational Paradigm

Near the end he argues:

• AI is a new way of leveraging reducibility (capturing pockets),

• but for fundamental discovery it’s weaker than the computational paradigm plus irreducible computation (enumeration, simulation, system exploration),

• the best path forward is combining the strengths of AI and the formal computational paradigm.

In plain terms:

• AI: navigation, candidates, intuition, interface, humanization, cross-domain analogy

• Computational systems: verifiable derivation, reproducible execution, enumeration, rigorous structuring

• Irreducible computation: true “new terrain discovery” (not “paper-like” textual novelty)

I am also not sure how to explain this part.

这篇文章原本只是我用来阐述自己在 2026 年对大模型的看法、以及长期规划的一段附录。但它本身，其实是一篇 Wolfram 对 AI、以及未来科学范式的重磅阐述。值得反复、深度研读。文章发表于 2024 年 3 月，可它真正“在信息密度上击中我”的时刻，却发生在 2025 年底。他在那个时候早就给我们指出了AI的实质。

这种时间差，正是我和顶尖科学家之间的距离：同一段文字，写出来的时候已经在指向未来；而我需要经历一段现实世界的摩擦、项目的失败与重建、对“系统如何在时间中承担责任”的反复撞墙，才终于读懂它到底在说什么。

更重要的是：理解这篇文章并不需要博士学位，也不需要某种“高深门槛”。在某种意义上，AI 的确推动了知识的平权，不仅仅是“更容易获取知识”，更是让我们有能力去洗刷、筛出真正有价值的知识。它把很多过去只能靠身份、圈层、期刊来锚定的所谓“学术权威”，重新拉回到一个更朴素也更严苛的标准：能否解释世界，能否落地验证，能否复现。

在论文数量爆炸的时代，许多学界论文除了花钱发表、互相引用、帮助作者获取职称之外，并不产生任何真实的增量价值；更糟的是，可复现性本身都越来越可疑。相较之下，Wolfram 的前瞻性反而远远没有被大众真正认识到。我甚至认为，他已经是下一代科学范式的奠基者之一，只是这个事实还没有被“主流叙事”及时吸收。

当然，要真正读懂这篇文章，你需要先对一个概念有基本直觉：计算的不可约性。我很多年前第一次读 Wolfram 的《A New Kind of Science》时，几乎完全不知道他在讲什么。后来，靠 6 到 10 年的人生与项目体验，才慢慢的领会他这个“不可约”。

也正因此，他在我心目中成为了极其靠前的重磅人物。而且，他仍然在世、仍在积极研究、仍在持续输出。这意味着：他现在说的每一句话，都不是“过去完成时”的学术结论，而是仍在推进中的范式构建。他说的每句话，我都很在意。有很多引用不是这篇文章，而是集合他的演讲和其他文献，这里不赘述了。

https://writings.stephenwolfram.com/2024/03/can-ai-solve-science/

AI 不可能“do everything / solve science”

• 社会上有人相信 AI 最终能“做一切”

• 他把“科学”作为终极压力测试：能不能把几百年累积的科学未解问题一口气解决？

• 他的答案是“inevitably and firmly no”

注意：他不是在否认 AI 的实用价值，而是在否认一种“终局式全能”叙事。

“there’s a somewhat widespread belief that eventually AI will be able to ‘do everything’” (Writings by Stephen Wolfram)

包括很多一开始怀疑的，一开始狂热的。AI can’t do everything, 也是我现在非常想强调的事情。他给我们一种定位型的指引。这个要跟他对齐，当你能做的事情范围缩小的时候，其实你能做的事情反而“多了”。因为你的精度提高了，你的定位清晰了，至少对我来说是这样。

“So what about science?” (Writings by Stephen Wolfram)

然后他给出“科学为何是终极压力测试”的理由：科学是人类文明最大智识工程，但仍然没做完——所以最能检验“do everything”的含义。

“the single largest intellectual edifice of our civilization” (Writings by Stephen Wolfram)

“there are still all sorts of scientific questions that remain.” (Writings by Stephen Wolfram)

不是说“AI 能不能帮科学”，而是问——能不能把剩下的全部收尾。

“So can AI now come in and just solve all of them?” (Writings by Stephen Wolfram)

“the answer is inevitably and firmly no.” (Writings by Stephen Wolfram)

不行！

“But that certainly doesn’t mean AI can’t importantly help…” (Writings by Stephen Wolfram)

这个就很重要了，他这个but！ AI特别擅长什么，就是我们该去研究的事情。有价值的事情。

他给 AI 的“现实定位”：语言接口 + 传统智慧的高层自动补全

• LLM 是一种新的 linguistic interface（语言接口），能把人类意图接到既有计算能力上（他自己的例子是 Wolfram Language）。

• LLM 还能根据“conventional scientific wisdom（惯常科学智慧）”做 high-level autocomplete：给“惯常答案 / 惯常下一步”。

这一段很关键：

他承认 LLM 很强，但强在——把既有范式用得更顺，而不是生成“新范式的真发现”。

1) LLM 是新的 “linguistic interface（语言接口）”

“At a very practical level, for example, LLMs provide a new kind of linguistic interface to the computational capabilities that we’ve spent so long building in the Wolfram Language.” (Writings by Stephen Wolfram)

2) LLM 作为“高层自动补全”：基于“conventional scientific wisdom”

“And through their knowledge of ‘conventional scientific wisdom’ LLMs can often provide what amounts to very high-level ‘autocomplete’…” (Writings by Stephen Wolfram)

“…for filling in ‘conventional answers’ or ‘conventional next steps’ in scientific work.” (Writings by Stephen Wolfram)

好，我想把 linguistic interface 这个词单拎出来说，因为它太重要了。

我们现在对它的想象还非常狭窄：基本等同于“一个大模型对话窗口”，再加上一些普通的编程应用。说白了，吾辈乃凡人，我们大多数人目前也就停留在这一层：开个窗口，丢个 prompt，得到一段看起来挺像样的输出，然后觉得世界被改写了。

但问题是：光是“接口”本身，就有巨大的系统性开发空间。

并不是你现在只想到窗口，这个世界就只剩窗口。窗口只是最原始、最粗糙的一种接口形态。

所谓 “AI vibe coding” 的爽感，本质上也只是接口升级带来的短期快感：你以前要烧脑半天的工作，现在一个 prompt 立刻给你一份“能跑起来”的东西，于是你很爽…但就到此为止了吗？如果把这当成终点，那我们其实只是把一个新的“文本老虎机”换进了工作流。

真正关键的不是“它能给你答案”，而是：这个接口能不能承载现实世界的责任。

我在很多文章里反复强调过几个词：

可复现、可审计、可迁移。

这是任何进入“现实决策”的系统必须具备的制度属性。（你去看看任何组织流程，法律流程，裁判流程，审计流程，这里不赘述）

因为你放眼看去：

人类的日常生活、组织协作、公司治理、甚至国家治理——大量关键决策，归根到底都是一种 linguistic interface：我们用语言提出议题、描述风险、交换承诺、写下制度、做出裁决，然后把这些语言变成行动与后果。

那问题来了：这些决策能靠大模型吗？你敢信吗？

单个模型的决策天然具有强烈的环境依赖：同一句话、同一个问题，换个上下文就变；而 prompt 里写的约束，本质上是软约束，不是机器可执行的 if-else。更危险的是：模型为了“完成语言”，为了给你一个看起来像答案的答案，它是会主动忽略约束的。因为它的目标函数不是“遵守制度”，而是“产出连贯文本”。Predict the next token!

它不会说：Error （跟一个编号）。

它必须给你结果。它的默认行为是把不确定性伪装成确定性，把不可判定伪装成可裁决。

这个问题解决了吗？

没有嘛。

我们有没有一种接口架构，能让语言进入系统时：

• 约束是硬的，可编译、可验证的

• 出错是允许的，能明确 throw error / require override

• 决策是可回放、可追责的，而不是一次性的文本会话

• 输出进入现实之前必须经过制度化的审计与门控

如果没有，那我们现在享受的“vibe coding”爽感，本质上还只是低风险场景的烟花。离真正能承载人类社会的决策系统，还差一整条制度化的工程鸿沟。难道这个不值得开发者投资资源，精力去研究吗？难道这不是一条推演出来的职业康庄大道吗？（笑）对于我们这种非科研，偏应用向的开发者来说。

他把科学史抽象成两次表征革命：数学表征 → 计算表征

他接下来提出一个更深的判断框架：

• 300 年前：科学的跃迁来自“用数学表示世界”

• 现在：我们正在经历“用计算表示世界”的跃迁（他认为这是更根本的范式）

这一步其实是在“抬高标准”：

如果你问他 AI 是否“改变科学”，你得先说明：AI 到底是在工具层帮忙，还是在表征层带来新的科学范式。

“Three centuries ago science was transformed by the idea of representing the world using mathematics.” (Writings)

“And in our times we’re in the middle of a major transformation to a fundamentally computational representation of the world (and, yes, that’s what our Wolfram Language computational language is all about).”

工具层 vs 范式层”的问法

“So how does AI stack up?” (Writings)

“Should we think of it essentially as a practical tool for accessing existing methods, or does it provide something fundamentally new for science?” (Writings)

什么意思啊，理解这个对于初次接触他理念的人来说有些陌生。“computational irreducibility（计算不可约性）”确实它不是一个“技术术语”，而是一个世界观开关：它在说，很多系统不是“更聪明就能跳步”，而是必须把计算做完（实在看不明白的，一定要去研究元胞机的机制）；你能做的，往往只是找到一些“可约口袋”，在局部压缩、在局部预测。记住可约口袋这个词。

Demis Hassabis 在谈自然界可建模性时，我认为他的意思是差不多的。他对Lex Fridman 的那次访谈，我其实在X上写了很多文章，但是现在不大好找了。后来我就把我想写的长篇文章都放在Substack. 他说的，当时他类比的蛋白质折叠，就是类似这种口袋。意思是一个非常广阔的天地，总有一些人踩出来的小路，找到这条小路，你就爽歪歪。没找到，你就brute force. 他背后就是“口袋可约 / 否则暴力”的结构：

“if there’s not [patterns]… you have to do brute force.” (Lex Fridman)

以及他解释为什么很多自然问题“看起来组合爆炸，但仍可被模型化”的关键点：

“there’s some structure… some gradient you can follow.” (Lex Fridman)

把这两句和 Wolfram 放在一起读，

• Wolfram 说：整体不可约会阻止你“系统性跳步”，但总有“pockets of reducibility（可约口袋）”。

• Demis 说：如果空间里有结构（梯度/景观），你就能有效搜索；如果没有结构，那就只能 brute force。(Lex Fridman)

所以“他和 Demis 很相似——不可约性”,

世界并不保证处处有捷径。所谓智能，很多时候只是更快地找到哪些地方有结构、哪些地方没结构。

而“不可约性”如“浩瀚烟海”，就在于它会把你从“能力崇拜”直接拉回到计算与制度：

• 什么时候必须模拟、必须枚举、必须做完计算；

• 什么时候可以压缩、可以抽象、可以形成叙事；

• 以及最关键的：当你把 AI 接进现实决策时，哪些部分不能让它“猜过去”，必须落到可复现、可审计、可报错的硬结构里。

说真的，我自己也在学习过程中，只能跟大佬们学习一些哲学的根基和思想。具体能实现人家的百分之一，也是赚到了。

最核心的硬论证：计算不可约性 = AI 无法越过的“物理级上限”

这篇文章的发动机就是“computational irreducibility（计算不可约性）”。

• 把自然系统当作计算过程：系统自己在“算”它的演化

• 我们（或 AI）要预测它，也必须做计算

• Principle of Computational Equivalence：这些计算的“计算强度”在原则上相当

• 所以你不能指望 AI 系统性地“jump ahead”跳过演化步骤

• 因而“完全 solve science”不可能

你想要的那种“终局捷径”，在许多系统上根本不存在。不是你训练不够，是世界不给你捷径。

这个就更难理解了。我们拆开说一下：

1. 把自然系统当作计算过程：系统自己在“算”它的演化

Wolfram 先把“世界=计算过程”作为底层前提抛出来：

“we can think of everything that happens as a computational process.” (Writings)

“The system is doing a computation to determine its behavior.” (Writings)

这里他不是说“我们用计算去模拟世界”，而是说：世界本身就在计算。

2. 我们（或 AI）要预测它，也必须做计算

紧接着他把预测者（人或 AI）放回同一个“计算”框架里：

“We humans—or, for that matter, any AIs we create—also have to do computations” (Writings)

“to try to predict or ‘solve’ that behavior.” (Writings)

意思是：你想“知道它会怎样”，你也得付出计算步骤，不是靠“更像人类的直觉文本”就能免单。

3. Principle of Computational Equivalence：这些计算在原则上相当

他用 PCE（计算等价原理）把“为什么没法系统性跳步”钉死：

“the Principle of Computational Equivalence says that these computations are all at most equivalent in their sophistication.” (Writings)

这句是整段的“物理级硬钉子”：系统在算，你也在算，但计算强度上限是同阶，所以不存在一个普遍可用的“上帝视角捷径”。

4. 所以不能指望 AI 系统性地 “jump ahead” 跳过步骤