The term may sound abstract, but it is not constructed out of thin air. Over the past few years, as AI has advanced rapidly, several friends with whom I have long-standing discussions repeatedly suggested that I systematically study fields such as systems engineering, complex systems, and both the “old” and “new” cybernetics. At the time, these directions—seemingly theoretical, even somewhat “academic”—did not feel closely connected to my own practice. Perhaps that was because my experience and capabilities had not yet truly reached the boundaries of those problems.

Now, however, I see it differently. Systems engineering is not a specific discipline, but a pervasive way of thinking. Most of the time, we are “building systems” without even realizing that we are doing so.

I want to explain my understanding of systems thinking in a way that anyone can grasp, drawing on my own ten years of experience in garden-making.

On one hand, gardening is concrete enough that almost anyone can perceive it: whether plants survive, whether the environment is suitable, how water and light are balanced—these are not abstract ideas, but outcomes directly reflected in reality. On the other hand, this has been a field of long-term, hands-on practice for me. Over the past decade, most of my time has been spent in trial and error—and “trial and error” itself is the most authentic mode of operation in systems engineering.

Every judgment here, every adjustment, is not derived purely from reasoning, but paid for with time, money, and real labor. Compared to purely textual reasoning or logical deduction, this kind of experience is a more “physical” expression of a system.

In a sense, such experience is scarce. Today, writing code has become easy, and writing essays has become easy. But to truly grow a plant from the soil, you must step out of abstraction, walk into the sunlight, and enter a real system that is uncontrollable and irreducible. You must accept its constraints, feedback, and uncertainty. It is precisely this kind of long-term, concrete, and non-skippable practice that has gradually shaped my current view of systems.

Therefore, for a programmer or researcher, it is essential to respect entrepreneurs who are able to create and sustain profitable businesses in the real world. Within complex economic systems and physical reality, building a company and maintaining profitability is something that cannot be taught in full—it can only emerge through harsh market selection, combined with talent and other intangible factors.

This systems view does not belong only to gardening. It is becoming the underlying cognitive framework through which I approach the construction of AI-native private systems. This piece is closer to an essay—a reflection and summary of experience—rather than a formal theoretical derivation. Yet it remains important to me. In an era where AI can write code, many programmers who once occupied the lower layers of the production chain must transform. Writing code used to embody a kind of “translation intelligence.” Now that AI has effectively become the translator from intent to code, humans must reposition themselves at the level of system architecture.

Any “Reset-to-Zero” Approach That Wipes an Existing System Carries Endless Risk

Let me start with the first—and most fundamental—systems insight I distilled after repeated trial and error in my garden: I oppose “reset-to-zero development.”

By “reset-to-zero,” I mean taking a system that is already running in the real world—regardless of how well it performs—tearing it down entirely, reducing it to nothing, and then attempting to rebuild a supposedly better, more perfect system on a “clean” foundation.

In gardening, this has a very typical manifestation: large-scale land clearing, removing all existing vegetation, scraping away weeds (which in reality can never be completely eliminated), and then investing heavily to plant a carefully designed “ideal garden.”

I once did exactly this.

At the beginning, I envisioned this garden as an “ornamental rose garden,” aiming to collect rare rose varieties and create a space that would attract visitors during peak bloom. From a design standpoint, this was a very “correct” plan—arguably close to perfect on paper.

But real systems never operate according to paper designs.

Roses are indeed among the most commercially valuable flowers, but they come at a high cost: they require intensive labor for maintenance, continuous watering and fertilization; they are extremely sensitive to environmental conditions, highly susceptible to diseases such as black spot and powdery mildew, and frequently attacked by pests like aphids. To maintain their ornamental quality, one must also continuously enforce “clean boundaries” between plants—constant weeding, mulching, and upkeep.

None of this is a one-time effort. It is continuous and effectively endless.

More importantly—none of these problems are visible before the reset.

Once you remove the original system, you lose all the “cognitive anchors” of the existing ecology:

You no longer know what the soil’s microbial structure was, which weeds were suppressing which diseases, how water circulated, how sunlight moved through the space, or even how wind patterns shaped the system.

You simply reset everything and begin rebuilding in what you assume is a controllable environment.

The result is that chaos begins to emerge from places you could never have anticipated.

At first, it works. It looks beautiful. It even seems to validate the design. But over time, problems begin to appear—and they compound nonlinearly:

Maintenance costs spiral out of control, pests and diseases recur, labor input keeps increasing, and yet you cannot form stable expectations—you don’t know what will happen next, nor how much more resource input will be required to sustain the system. And before large-scale planning and construction, you can never be 100% certain whether the environment itself can support such a system long-term.

Eventually, the system may slowly degrade, or collapse suddenly when the cost structure becomes unsustainable.

This experience led me to a very clear systems judgment:

Any system that is already running in the real world should not be lightly “reset to zero.”

Because the mere fact that it runs means it has already formed a structural equilibrium that you do not yet fully understand.

A better path is:

Make observable, controllable, localized modifications on top of the existing system;

Allow the structure to evolve gradually while maintaining system continuity.

Better to move slowly than to break the system.

This insight extends far beyond gardening.

I have seen developers attempt to rebuild entire cities “from scratch”: leveling vast areas of land and constructing a complete urban system according to a master plan. But these often fail due to massive costs, inability to attract population, and lack of real feedback—becoming “ghost cities,” systems that are valid in design but non-functional in reality.

In contrast, more mature approaches focus on existing communities: identifying aging assets—cheap houses, declining neighborhoods—and renovating or partially rebuilding them. Because the original community is a “living system,” with people, demand, and flow, real buyers often enter even before construction is fully complete. I know several small developers in the U.S. who operate this way, and under their accumulated experience, they rarely have failed projects.

At its core, the difference between these two paths is not “design capability,” but whether one respects a system that is already in operation.

This also becomes a foundational principle in my approach to building AI-native private systems:

Do not attempt to build a perfect system from scratch. Instead, evolve structure continuously on top of a system that is already running.

You can see from the photos how stunning my rose garden looked at its peak when it was first built.

Innovation and system maintenance are not in conflict—but the success of innovation is always highly contingent, and greatness can never be planned in advance.

The world is, of course, continuously driven forward by innovation. Looking back across the long arc of human history, we have almost always been innovating. The wheat, corn, fruit trees, vegetables, and flowers on our tables today—none of them exist in their original “natural” form; nearly all bear the marks of long-term human domestication, selection, and modification. Early wheat did not look like modern wheat, and wild roses were nothing like today’s cultivated roses. In modern society, electricity, engines, computers, and most recently large language models that have swept across the globe—all are the result of humans gradually understanding the laws of nature and then actively rewriting existing conditions based on our values, technical capabilities, and practical needs. Whether reshaping plant forms, altering material properties, or reorganizing information and energy at the microscopic level, the essence of innovation is this: after understanding underlying laws, we attempt to push the world toward forms that did not previously exist.

But innovation is not a straight line. It is almost always paved by massive amounts of trial and error. The successes that ultimately materialize are often just a tiny fraction among countless failures, deviations, misjudgments, abandoned attempts, and accidental hits. In other words, innovation can be pursued, but it cannot be precisely planned; it can be continuously invested in, but it cannot be made to bloom on command. In many cases, 99.9% of the process consists of filtering, elimination, exhaustion, and sunk cost, while the remaining 0.1% still carries a strong element of chance. What humans can do is prepare the soil, accumulate samples, sharpen judgment, and endure long periods without results—but the moment when something truly “new” emerges, and the form it takes, is not fully controllable. This is precisely why system maintenance and innovation are not opposites. Without long-term maintenance—of systems, samples, environments, and observational capacity—there is no foundation upon which innovation can occur. And innovation itself is not a rejection of maintenance, but rather the occasional fruit that maintenance yields over long time scales.

My own process of breeding roses in the garden is a concrete example. Since first encountering botany in high school, I have had a simple and deeply personal wish: to create a plant of my own in this lifetime. When I finally had the chance to pursue this seriously, my goal was to cultivate a “perfect rose”: fully disease-resistant, tolerant to drought and heat, continuously blooming, with large flowers, requiring no delicate care, no frequent fertilization or chemical treatment—just basic sunlight and rain, yet capable of reliably producing enough blooms each month for cut flowers (roses are unique in that very few woody plants in the world can bloom repeatedly across multiple months in a year). In other words, I was not trying to create a fragile plant that requires constant human care, but a garden plant that combines ornamental value with autonomy.

To approach this goal, over the years I have relied on extensive purchasing, collecting, and the help of friends, repeatedly selecting through large-scale propagation and cross-pollination. In total, I have worked with over 300 varieties and propagated thousands, possibly tens of thousands, of plants. My method was simple and ruthless: high-elimination selection. Under the same conditions, out of fifty plants, perhaps only one or two would be retained for further observation; the rest would either be given away or discarded. In the early years, I tried to maintain relatively rigorous scientific records—tracking lineage, observing traits, conducting systematic comparisons. But over time, I grew increasingly exhausted and overwhelmed, especially because roses as a genus are highly susceptible to diseases like black spot and powdery mildew. Once I observed clear disease susceptibility in a lineage, I would usually abandon it immediately and stop investing further effort.

What became truly interesting was that near the end—when I was almost ready to conclude the entire experiment—I suddenly discovered that, in this field of constant elimination and clearing, one plant had somehow remained. In the area where it was found, all its sibling plants had already been eliminated. Its flowers were as large as peonies, its leaves had a distinct waxy texture, and it was almost never affected by disease. Ironically, because I was so exhausted in the later stages, I had not maintained complete records, and I could no longer fully trace its parent lineage with certainty. It did not emerge when I was most in control or most methodical, but rather appeared almost accidentally, at the moment I was about to give up.

Now, I have cleared out most of the other varieties and focused my efforts on this unique variant: on one hand, observing and stabilizing its traits through self-pollination; on the other, cloning its current genetic expression through cuttings, and distributing it to friends for cultivation so it can be tested and validated across diverse real-world environments. Some people have suggested that I consider patenting it, but for now that process feels both complicated and expensive, so I have not pursued it.

This entire journey has led me to a systems perspective I did not have before: innovation is not a betrayal of system maintenance—on the contrary, innovation can only grow out of long-term maintenance. At the same time, however, the success of innovation is never a guaranteed return on linear effort. You can plan experiments, selection processes, investment, and direction—but you cannot plan greatness itself. Greatness cannot be executed as a task; it is something that, after countless cycles of maintenance, trial and error, elimination, and persistence, eventually—and somewhat accidentally—lands in your hands.

See Reality Clearly, and Go Where Innovation Actually Happens

The changes you now see in the research world—and the different strategic choices made by major countries—are not merely policy fluctuations. They reflect a deeper restructuring of how research itself is organized. Increasingly, frontier research is spilling out of traditional university systems, while large corporations, leading companies, and private labs are becoming the new pioneers in certain key domains. The reason is straightforward: they have capital, talent, and compute resources, and they have been shaped by long-term market selection. This gives them the conditions necessary to sustain high-density trial and error, high-cost investment, and rapid iteration.

Take SpaceX as an example. NASA has, in recent years, increasingly shifted parts of its lunar program toward commercial systems. Reports have pointed out that NASA is opening more missions to commercial bidding, while traditional contractors are under growing pressure due to high costs, low launch frequency, and aging technical pathways.

This shift is even more pronounced in computing and AI. Frontier models, massive-scale compute, engineering deployment, real user feedback, and sustained capital investment mean that much of today’s “real innovation” is no longer primarily happening in traditional academic labs. Instead, it occurs within companies that control data, chips, cloud infrastructure, and product feedback loops. Reports like the Stanford AI Index Report have repeatedly highlighted that the cost and compute thresholds for training cutting-edge models continue to rise rapidly, naturally concentrating frontier research within the most resource-rich institutions.

Meanwhile, the traditional ivory tower faces multiple pressures. First, the marginal efficiency of innovation within the paper-based system is declining; evaluation mechanisms increasingly depend on publication counts, funding metrics, and peer competition, making it harder for high-risk, high-failure-rate innovation to survive within academia. Second, academic scandals—paper retractions, data fabrication, authorship disputes—have eroded the moral authority of the academic community. Third, universities historically held a monopoly on interpreting knowledge; but in the AI era, that monopoly is weakening, as access, compression, retrieval, and interpretation of knowledge are no longer confined to universities. As a result, universities are not only losing part of their research monopoly, but also the scarcity that once justified high tuition models.

This helps explain why traditional academic strongholds such as the U.S. and the U.K. are experiencing increasing structural tension. In the U.S., organizations like American Council on Education have tracked and criticized policy changes affecting federal funding and institutional structures. In the U.K., financial pressures have translated into real layoffs, with significant reductions in university staffing and ongoing revenue declines.

At a deeper level, what we are witnessing is not simply “universities declining and companies rising,” but a more fundamental shift: innovation increasingly depends on environments with high energy density, high capital concentration, and high tolerance for trial and error. Traditional universities excel at knowledge organization, talent training, academic continuity, and relatively stable long-term research. But in emerging fields that require massive compute, enormous investment, rapid feedback, and tolerance for failure, private companies and industrial labs are gaining dominance.

As for large-scale, centrally planned “national innovation systems,” their chances of success are even more limited.

From my photos, it’s clear that most of these propagations and seedlings don’t make it—only about one in ten thousand ultimately becomes a true “creation.”

Complex Systems Cannot Be Fully Controlled: There Are Always “Weeds” (Bugs), and Physical Removal Is Not the Best Solution

Anyone who has truly practiced gardening—or any experienced farmer—will tell you this: weeds never disappear. Not temporarily, but continuously, repeatedly, and indefinitely. You pull them out today, and they return tomorrow. If you take a more aggressive approach and use herbicides, the problem simply changes form: how do you ensure the soil is not chemically damaged? How do you guarantee that the plants you actually want are not harmed as well? If you cannot tolerate the existence of weeds, then unfortunately, all your time will be consumed by removing them—and that task itself has no real endpoint.

What I gradually came to understand is this: in a complex system, every individual has its own “genetic logic” and agency. In a field, every plant, every insect, every rabbit operates as an independent entity, each following its own internal rules. A company is no different—no matter how many employees it has, each person has their own interpretation and judgment; it is not a machine that can be fully programmed. A country even more so: different ethnicities, cultures, religions, and regions form a highly diverse collection of individuals, each autonomous, thinking, and inherently unpredictable. Any attempt to control all information, eliminate all anomalies, or prevent any “weeds” or bugs from emerging through centralized control, administrative planning, or rigid “hard coding” fundamentally violates the nature of complex systems.

Here, I must mention a theoretical source I have repeatedly studied: Ilya Prigogine, whose core idea in Order Out of Chaos can be summarized as:

As long as a system is far from equilibrium, structures, disturbances, and “weeds” will inevitably continue to emerge.

Why is this the case? Because systems are never static—they are continuously dissipative. A dissipative system constantly takes in energy while inevitably producing entropy. A garden absorbs sunlight and water, but also generates competition, disorder, and weeds. A company absorbs capital and information, but also produces errors, conflicts, and inefficiencies. A nation, in its operation, continuously generates noise and uncertainty. A system that only absorbs energy without producing any disorder does not exist in reality—it exists only in myth, like Eden.

Therefore, the key is not “how to eliminate weeds,” but how you understand them. For programmers, this is particularly intuitive: if you cannot tolerate even a single bug, you will remain trapped in an endless loop of debugging—with no endpoint. From another perspective, weeds are not purely anomalies in computation; they are byproducts of system operation. The problems we encounter daily—organizational friction, errors in AI-generated code—belong to this category of “irreducible byproducts.” No complex system can be entirely noise-free or bug-free.

If Not by Removal, Can We Use Smarter Forms of Constraint?

In gardening, I gradually abandoned brute-force removal and chemical control, and instead adopted a more effective strategy: temporal balancing.

For example, weeds often have stronger vitality than the plants you deliberately cultivate. But this does not mean you are powerless. You can reshape the timing of the system. By planting perennials early—such as tulips or chrysanthemums—these plants occupy key ecological niches (light, water, space) before weeds emerge in spring. When weeds appear, they lack the conditions to grow. You have not eliminated them—you have simply removed their opportunity.

If we treat pests as a form of “bug,” we can go further by introducing targeted counterbalances. A friend of mine who grows vegetables plants marigolds next to every tomato. Tomato + marigold is a classic companion planting model—essentially embedding a “native countermeasure unit” within the system. Marigolds suppress soil nematodes through root secretions, disrupt pest detection through scent, and attract beneficial insects. There is no act of “eliminating pests,” but their survival pathways are continuously weakened.

When we extend this perspective beyond gardening—to human society, organizational structures, or complex systems in the AI era—the same logic holds.

In the face of complexity, the goal is not to eliminate anomalies entirely, but to understand what causes system degradation:

• Do not force a reset to zero. Starting over destroys existing stable structures; once ecological niches are emptied, problems return even faster.

• Do not attempt total centralized suppression. The cognitive capacity of any individual, organization, or central system is limited; trying to control all variables leads to exponentially increasing control costs. Many highly centralized systems in history have collapsed for this reason (for example, the Soviet Union collapse).

• Do not rely on “herbicide-like” over-optimization—reducing complex systems to a single KPI. This often destroys both “good” and “bad” structures simultaneously, degrading the system as a whole.

In my view, a good system is not designed to be perfect—it is designed to be guided toward health. That is, based on your values, you gradually shape the system so that certain structures become easier to grow, while others lose space over time.

From Prigogine’s perspective, this is not about “controlling” a system, but about selectively introducing structures so that some evolutionary paths become more stable while others naturally decay. In complex systems far from equilibrium, order does not arise by eliminating fluctuations—it emerges over time, through the continuous stabilization of certain structures.

The Complexity of Reality Far Exceeds the Computational Threshold of Any Individual or System—No Plan Can Capture All Information; Only Feedback Can Gradually Adjust the System

The complexity of the real world far exceeds the computational threshold of any individual or system. A plan is not a tool of control—it is merely an initial guess. What ultimately determines the trajectory of a system is not your original design, but the successive cycles of information feedback that follow. At the starting point, no one can grasp all variables: sunlight is seasonal, soil carries historical residues, microorganisms evolve dynamically, materials decompose, and individuals have genetic differences. Not only are these variables vast in number, they are constantly changing. Any “top-down, one-shot perfect design” will quickly fail in reality. The only viable path is to let the system run first, and then iteratively adjust its structure through feedback.

Feedback is most directly visible in plants. Whether something works or not, the plant tells you immediately. Failure to fruit, lack of growth, disease, gradual death—these are all signals. And these signals have a critical property: they are real and cannot be falsified. They do not explain causes, they do not rationalize, and they do not conceal problems. They simply present outcomes.

If you are a programmer, the development process is essentially: error → fix → run → error again → fix again → converge. But there is a crucial prerequisite—errors must be trustworthy. If a system does not produce errors, or if errors are delayed, missing, misleading, or “packaged,” then you are not debugging—you are being consumed by the system. You lose the ability to judge causality. A system whose error signals are not trustworthy is not debuggable. If even the error messages are fake, you would want to smash the machine.

Natural systems are almost “zero-deception” feedback systems. A plant is extremely honest. You may think a location has good sunlight and drainage and should thrive—but it doesn’t. Only when you trace backward do you realize the relevant variable was not even within your original model. In spring, before trees leaf out, light is abundant; by early summer, when light is most needed, the canopy closes and blocks it. You may not know that alkaline material was buried underground (I have actually encountered this—perhaps a previous owner used it to deal with moles), causing the pH to spike; most plants tolerate slight acidity, but very few tolerate alkalinity—so they die immediately. You may not realize that wood chips were not fully composted, and during decomposition they aggressively absorb nitrogen, killing entire batches of young woody plants. I have encountered such situations countless times, and almost every time, the cause lay outside my initial understanding. Each plant is searching for a precise point where sunlight, water, soil, and genetics align. The problem is: humans cannot know all of this in advance. When you scale this complexity up to companies, organizations, or nations, the information load grows exponentially.

So what I really want to emphasize is not complexity itself, but the feedback mechanism. Plants do not give you answers—they give you extremely clean feedback signals. And precisely because these signals are trustworthy, I have been able, after repeated failures, to reconstruct the causes step by step—sometimes down to micronutrient levels (I once encountered a magnesium deficiency).

In complex systems, whether a system can be governed depends on whether feedback is real, timely, and tamper-proof.

As a System Designer: Design for Real Feedback—or Walk Away

In systems where even error signals are fake, what you invest is not time but cognitive cost from constant misdirection. You cannot establish causality, cannot accumulate experience, cannot form stable structures—you are simply trapped in noise until you burn out.

Similarly, I no longer accept any form of hidden information or unwritten rules. Systems based on guesswork—where people try to read each other, circle around issues, and rely on inference—are essentially breaking the feedback channel. They are not adding complexity; they are actively creating unobservability. You may appear to participate in such a system, but you cannot access its true state—you can only guess. Such systems cannot be optimized.

Feedback is not something that emerged in the AI era—it has always been the core of complex system design. Cybernetics, industrial systems, organizational management, ecosystems, even markets—all are fundamentally built on feedback. Without feedback, there is no regulation; without regulation, there is no real system operation. A thermostat regulates temperature through feedback, a company adjusts operations through feedback, an ecosystem maintains dynamic balance through feedback. Complex systems are not “designed once and done”—they must continuously adjust themselves during operation.

AI Does Not Change the Principle of Feedback—It Expands Its Domain

Systems in the past also had feedback, but they mainly absorbed signals that could be mechanically captured: temperature, speed, inventory, error logs, clicks, output, death, stalled growth. These belonged to the physical layer, behavioral layer, or metric layer—capturable through sensors, tables, and logs.

But a vast amount of feedback has always existed outside formal systems—floating within human semantic space. Hesitation, deflection, misunderstanding, complaints, ambiguous responsibility, repeated explanations, uncertainty in language, ambiguity in documents, friction in collaboration, contradictions in requirements—these were never unimportant. Machines simply could not process them, so they remained in human minds, meetings, conversations, emails, and all those “you figure it out” spaces.

This is where AI introduces a fundamental shift: it can now process text, images, speech, and context—it can begin to capture feedback at the semantic level. Feedback is no longer limited to physical signals and hard metrics; it expands into areas previously accessible only through human intuition and interpretation. In other words, AI does not change the fact that feedback is central to complex systems—it changes what can now be considered feedback.

The Challenge Is No Longer Capability, but System Judgment

In the past, the primary limitation was capability. Machines could not understand semantics, so systems could not absorb these floating layers of feedback. Many things were not done simply because they could not be done.

Now the situation has changed. Technology has crossed a threshold: text can be read, images processed, speech transcribed, logs summarized, context assembled, weak signals extracted. Systems can now absorb a far broader range of feedback than before.

And this is precisely where the real difficulty begins:

• What do you choose to absorb, and what do you reject?

• What counts as real feedback, and what counts as noise or contamination?

• How do you design boundaries, validation, and scheduling?

• How do you prevent systems from mistaking “readable semantics” for “trustworthy reality”?

Because once semantic feedback enters the system, both capability and risk expand dramatically. What you ingest is not just information, but also bias, emotion, framing, narrative, power structures, organizational rhetoric, and historical noise. The fact that something can be processed does not mean it should be trusted. The fact that it can enter the system does not mean it should drive decisions.

What lies between these distinctions is precisely your systems view.

For this generation of system designers, the challenge is no longer just engineering complexity—it is feedback governance complexity.

In Any System Designed to Serve Humans, Human-Centered Thinking Must Be Everywhere

1. Whenever humans interact over the long term with any container or information system, a form of energy complementarity or exchange emerges. Humans are not simply “using” a system—they continuously input attention, time, emotion, and judgment into it. The system, in turn, responds through feedback (flowers blooming, data changing, outcomes appearing, behaviors shifting). Over time, this forms a closed loop: humans are either energized or depleted, while the system is either sustained or degraded. This relationship goes far beyond simple “tool usage.”

2. Any entity that appears unrelated may, in fact, be part of the system. System boundaries are often artificially drawn for the sake of control and modeling. But in reality—especially in complex systems—the participants extend far beyond the few core nodes we define.

3. Human-centered thinking is itself a method for dealing with complexity. It is not sentimentality, but methodology—a way to find a reliable compression anchor in a world of infinite variables, unmodelable states, and delayed, noisy feedback.

Let me give a concrete example. When I first built my garden, I had a “hidden objective”: to provide sufficient nectar for bees throughout the year. Especially in late autumn, bees often face shortages because most flowers do not bloom during that season. So I deliberately designed the garden with a large number of cold-season flowering plants. As you can see in photos taken last November, the garden was still in full bloom. In horticultural terms, this is called a “cool-season garden,” which is quite rare in this region. At that time, the number of bees in my garden actually exceeded that of spring. I captured many bumblebees sleeping inside flowers, as well as activity from local solitary bee species.

If I continue, it may start to sound a bit abstract. But I personally acknowledge the complexity of the world. For phenomena that cannot yet be rigorously proven but can be consistently perceived, I accept them and incorporate them into my daily practice. I believe that the relationship between humans and systems is not one of “usage,” but of “energy exchange.”

Take the relationship between people and their environment—or between people and the homes they inhabit over long periods. I once discussed a pattern with an architect friend: during my time working in real estate, I visited many older neighborhoods in the United States and noticed a consistent pattern—houses that are continuously occupied, regardless of age, tend to remain in decent condition; once left vacant for long periods, they deteriorate rapidly. This is not merely a matter of maintenance. My friend, despite having a rational engineering background, strongly agreed that there is a form of exchange between humans and buildings that is difficult to fully quantify.

Translated into engineering terms, this is not mysterious at all: when humans interact continuously with a system (a garden, software, organization, knowledge base, community, or house), what is fundamentally happening is the input of attention, the reception of feedback, and the circulation of energy. Once this input stops, the system loses structural vitality and begins to decay.

This is why I must also care about other “users” of the system—such as whether bees are thriving. That is part of the system’s integrity.

System Boundaries Are Artificial Constructs

“Any seemingly unrelated entity may be part of the system.”

At first glance, this may sound unscientific, but it is not. Nature itself does not have clear boundaries; boundaries are tools introduced for engineering control. In technical systems, we must define boundaries to manage complexity. But the real question is: within the scope of what we can influence, why not allow more entities to have space to exist?

This idea already manifests at the societal level. Should companies care for vulnerable employees? Should people with disabilities be systematically excluded? Should disadvantaged groups receive public support? From a purely efficiency-driven perspective, all of these could be removed. But in reality, we increasingly recognize that they are not “outside the system”—they are part of it. Excluding them is not optimization; it is a reduction of system resilience.

Human-Centered Thinking Is Not Morality—It Is a Strategy for Handling Complexity

In complex systems, variables are infinite, states cannot be fully modeled, and feedback is delayed and noisy. Such systems are everywhere in human society: organizations, nations, companies, markets—each of them is at least as complex as a large-scale engineering project.

And “humans” are currently the only nodes with the following capabilities:

• Multimodal perception (vision, emotion, experience)

• Fuzzy judgment

• Long-term value assessment

Therefore, in such systems, being human-centered is not merely a moral choice—it is an engineering optimum:

Humans are the most effective nodes for compressing complexity.

Yet many real-world systems are doing the opposite: removing people for efficiency, cutting key contributors for metrics, concentrating wealth in the name of optimization. These decisions often appear “correct” in the short term, but they quietly sever a critical layer—the human feedback layer.

Any system that serves humans, if it reduces human participation in the name of efficiency, is fundamentally trading long-term system stability for short-term certainty.

What Happens When a System Becomes “Dehumanized”?

Phase 1: Efficiency Gains

• Metrics improve

• Costs decrease

• Decisions appear cleaner

Phase 2: Feedback Loss

• Weak signals disappear

• Anomalies cannot be detected early

• The system becomes “blind” to emerging problems

Phase 3: Structural Fragility

• Reduced resilience to shocks

• Local errors can no longer be absorbed

• Small issues begin to amplify

Phase 4: Systemic Collapse

• Sudden failures

• Inability to recover

• Even the root cause becomes unclear

The key question is whether a system still retains continuous human input as the source of its structural vitality. Just like a human garden—even though bees do not plant or cultivate crops, they remain a critical indicator of system health. Sustaining them is, in fact, a way of activating the system itself.

Once this input is cut off, even if the system appears more “efficient” in the short term, it has already entered an irreversible path of decline.

Final Note

A system that truly runs well is never built overnight. It emerges gradually through repeated trial and error, a measure of luck, and sustained effort from many people. Yet its decline follows the opposite pattern—it requires neither complex conditions nor dramatic shocks. Often, the mere absence of maintenance is enough for rapid deterioration. Take my garden as an example: after ten years of work, it still hasn’t fully reached the state I envision. But if I stop maintaining the soil, fertilization cycles, weed control, and the seasonal care of woody plants and perennials for just one year, the entire system will quickly fall into disorder—within a single cycle, it can become almost unrecognizable.

The rise of AI has led many programmers to believe this is some kind of “final battle,” as if everything will be rewritten. In reality, there is clearly a significant bubble in current AI valuations. Many startups will face the same fate seen across all industries—struggling to generate sustainable profits and eventually failing. This is a normal phase in the diffusion of any new technology. But one thing is irreversible: large language models have permanently altered the trajectory of the human technology tree.

If you zoom out, you’ll notice that post-war technological progress in the United States was not driven by sudden leaps, but by steady and continuous improvements in productivity. Real technological transformation rarely comes from “replacing everything.” Instead, it enters at the edges of existing systems, gradually infiltrating and reshaping them without breaking their original structure.

This pattern is already evident in how AI is being adopted today. Many traditional industries are not choosing full-scale “AI transformation.” Instead, they introduce large language models at entry points—such as customer service systems. But customer service is not simply “chatting.” It is fundamentally a node for information intake, classification, and the triggering of downstream processes. The value of AI here is not to replace humans, but to improve the structural quality of how information enters the system—and from that entry point, gradually extend into deeper layers.

The real question is not whether to go “All in AI”—that’s just a slogan. The real question is whether you understand the design of the entry point: How is information captured? How is it structured? How is it handed off to downstream processes? Is the connection between customer service and backend operators seamless, or fragmented? Without solving these questions, there is no such thing as system-level AI integration.

By contrast, a strategy that starts with the goal of “replacing all human labor” is fundamentally mechanical and non-human-centered. Such systems tend to ignore the essential role humans play in the real world—as sources of feedback, judgment, and regulation—and therefore struggle to remain stable in complex environments.

A more viable path is always to serve people first: embed the system into human workflows, take on part of the cognitive and operational load, and evolve through real feedback—rather than attempting to rebuild everything from scratch. Only in this way does AI cease to be an external tool and instead become a capability that grows organically within the system itself.

继上一篇明确了我将研究重点聚焦在“为家庭与小企业构建 AI 原生私有系统”之后，我认为有必要把一个更底层、也更难被直接描述的东西讲清楚，那就是“我的系统观”。

这个词听起来抽象，但它并不是凭空构建的。过去几年，随着 AI 的迅速发展，有几位长期交流的朋友反复建议我去系统性地研究诸如系统工程、复杂系统、老三论与新三论这些领域。在当时，这些看似偏理论、甚至有些“学院派”的方向，并没有让我觉得与自身实践高度相关，或许也是因为，那时我的经验和能力，还没有真正触及这些问题的边界。

但现在反而认为，系统工程并不是某个特定学科，而是一种无处不在的认知方式。只是大多数时候，我们是在“做系统”，却没有意识到自己正在做。

我想用一种人人都听得懂的方式，结合我自己过去10年造园的经历，来讲清楚我所理解的系统观。

一方面，园艺足够具体，几乎每个人都能感知：植物会不会活，环境是否合适，水和光如何调配，这些都不是概念，而是直接反馈在现实中的结果。另一方面，这也是我亲身经历了超过十年的长期实践场域，在这十年里，大部分时间都在试错，而“试错”本身，正是系统工程最真实的运行方式。

这里面的每一个判断、每一次调整，都不是推导出来的，而是用时间、金钱和真实劳动换来的。相比纯粹的文本推理、逻辑演绎，这种经验是一种更“物理”的系统表达。

某种意义上，这样的经验是稀缺的。今天写代码变得容易，写文章也变得容易，但要真正把一株植物从土里养出来，你必须离开抽象的环境，走到阳光下，进入一个不可控、不可简化的真实系统之中，接受它的约束、反馈与不确定性。而正是这种长期、具体、不可跳过的实践，让我逐渐形成了现在这套系统观。

所以其实对于一个程序员和研究者来说，你要尊重在现实中能够创造成功运营和盈利的企业家。在复杂的经济系统中，在物理现实中，创造企业并且持续盈利，企业家才是完全无法被培养，只能靠残酷的市场筛。

这套系统观，并不只属于园艺，它正在成为我构建 AI 原生私有系统时的底层认知框架。这篇文章更像是一篇杂文，一篇经验总结。而不是正经的理论推导。但是对我来说仍然重要，在AI写代码的今天，许多以前处于生产链上基层的程序员都必须要转型。因为以前写代码是承担一种“翻译”的职能。现在AI完全成为从意图到代码的翻译者，那么人就一定要将自己定位到“系统”架构这个角度。

任何清除现有运作中系统的清零式运作，都蕴含无尽的风险

我们说说我在花园反复试错之后，沉淀出来的第一个、也是最核心的系统经验：我反对“清零式开发”。

所谓清零式开发，就是把一个已经在真实世界中运行的系统——不管它运行得好不好——整体推倒、归零，然后试图在一片“干净”的基础上，重新搭建一个自以为更优、更完美的体系。

这在园艺中有一个非常典型的表现：大面积开荒，把原有植被全部清除，杂草铲平（事实上也根本无法真正清除干净），再投入高成本，种植一套精心设计的“理想花园”。

我曾经就是这么做的。

最初，我为这片园子设想的是一个“观赏型玫瑰园”，目标是收集大量珍稀月季品种，打造一个在盛花期可以吸引人专门前来观赏的空间。从设计上看，这是一套非常“正确”的方案——甚至可以说，在纸面上是接近完美的。

但现实系统从来不会按照纸面运行。

月季确实是商业花卉中的佼佼者，但它的代价极高：

需要高密度的人力维护，持续浇水、施肥；对环境极其敏感，极易感染黑斑病、白粉病，虫害（如蚜虫）也非常频繁；为了保证观赏性，还必须长期维持植株之间的“干净边界”，不断除草、铺设木屑抑草层。

这些工作不是一次性的，而是持续性的、无穷无尽的。

更重要的是——这些问题，在“清零之前”，是不可见的。

当你把原有系统全部移除之后，你失去了对这个空间原有生态结构的所有“认知锚点”：

你不知道土壤原本的微生物结构是什么样的，不知道哪些杂草在压制哪些病害，不知道原本的水分循环、光照路径、甚至风的流动是如何在这个系统中起作用的。

你只是把一切归零，然后在一个“你以为可控”的环境里开始重建。

结果就是：混乱从你完全无法预期的地方开始涌现。

一开始，它确实很成功，很漂亮，甚至可以说“验证了设计的正确性”。但随着时间推进，各种问题开始出现，并且是非线性地叠加：

维护成本失控、病虫害反复、人工投入越来越重，而你却无法建立稳定的预期——不知道下一阶段还会发生什么，不知道还要投入多少资源才能维持这个系统。而且这个环境本身是否能长期支持这个系统，在你大规划大建设之前，是不能100%确定的。

最终，这种系统有可能“慢慢变差”，或者是因为成本结构失衡，维护费用过高，在某一个点上突然崩溃。

这段经历让我形成了一个非常明确的系统判断：

任何系统，只要它已经在真实世界中运行，就不应该被轻易“清零”。

因为它之所以能运行，本身就意味着它内部已经形成了一套你尚未完全理解的结构平衡。

因此，更优的路径应该是：

在现有系统之上，进行可观测、可控制的局部改造；

在保持系统连续性的前提下，让结构缓慢演化。

宁可慢，不要断。

这种认知，其实不仅适用于花园。

我见过一些开发商，试图“从零开始”重建一座城市：推平大片土地，按照规划一次性建成一个完整的城市结构。但最终往往因为成本巨大、人口导入失败、系统缺乏真实反馈，这些地方变成了空城，一个在设计上成立，但在现实中无法运转的系统。

相反，一些更成熟的开发方式，是在已有社区中寻找老化资产——便宜的房子、衰退的街区——然后进行翻新或局部重建。因为原有社区本身是“活的系统”，有人口、有需求、有流动，所以哪怕房子还没完全建好，就已经开始有真实买家进入。在美国我认识不少这种极小的开发商，他们在长期积累的眼光之下，几乎没有什么失败的项目。

本质上，这两种路径的区别，不在于“设计能力”，而在于是否尊重一个已经运行中的系统。

这也是我在后续构建 AI 原生私有系统时，一个非常底层的原则：

不要试图从零构建一个完美系统，而是要在一个正在运行的现实系统上，持续演化出结构。

你可以从图片上看到，我在刚打造这个玫瑰园的时候，盛花期有多么惊艳。

任何现实中的复杂工程，都需要靠慢慢演变，渐进式介入，耗费漫长的时间完成

现在几乎所有人都在谈“All in AI”，但是AI是估值泡沫这个说法现在已经被很多，甚至我这种AI乐观主义人士认同：一方面是资本市场对AI的高估值与高预期，另一方面是它在真实世界中落地时所面临的结构性困难。

问题不在于AI能力不够，而在于系统接入方式是错的。

AI并不是一种可以“一键替换”的技术，它更像是一种会改变系统内部结构的“慢变量”。如果用错误的方式引入——例如一刀切地替换掉原有的会计系统、管理系统、运营流程——那本质上就是在做我前面所说的“清零式开发”：你不仅丢掉了已有系统的稳定性，还在一个高度不确定的基础上，引入了更大的不确定性。

这也是为什么很多AI项目看起来技术先进，但最终落地困难，甚至半途而废。AI创业团队一开始都是大明星，短短24个月就销声匿迹了。因为它被放在了错误的系统位置上。

真正可行的路径，恰恰相反。

AI原生系统，不是“从零开始构建一个AI系统”，而是在已有系统之中，逐步渗透、逐步接管、逐步重构。

它的起点，往往不是那些看起来“最重要”的核心系统，而是一些最不起眼、但最具结构价值的环节，例如：

• 繁杂的信息录入

• 原始单据的整理与结构化

• OCR + 分类 + 初步语义理解

• 重复性的人工处理流程

这些地方有一个共同特征：

低决策风险 + 高重复性 + 高结构价值

从这些“边缘入口”开始，AI可以先承担最基础的工作：把现实世界中的非结构化信息，转化为结构化输入。这一步一旦稳定下来，系统的“数据入口”就发生了变化。

而入口一旦被改变，系统就开始被“重新定义”。

接下来，才是逐步往内渗透：

从记录 → 到理解 → 到辅助判断 → 到部分自动决策 → 再到调度系统。

整个过程，是一种渐进式侵入（progressive infiltration），而不是替代。

这和我在花园中的经验是完全一致的：

你不是把整个生态拔掉重种，而是先改变水流、光照、土壤中的某一个变量，让系统在保持连续性的情况下，逐渐朝新的结构演化。

所以，从系统观来看，“All in AI”本身就是一个误导性的口号。

真正应该发生的，不是“All in”，而是：

AI slowly grows into the system, until the system itself becomes AI-native.

不是替换系统，而是让系统，在不被打断的情况下，被重新生长。一个企业只有在维持他传统业务盈利的情况下，因为AI慢慢的提高了效率，才会渐进式的推进AI原生系统的改革。

你看我一开始玫瑰园非常惊艳的，现在变得不可维护，只能重新规划。

创新与系统维护并不冲突，但创新的成功始终带有极大的偶然性，伟大更不可能被提前计划。

这个世界当然是被创新持续推进的。回头看人类漫长历史，我们几乎一直在创新。今天餐桌上的小麦、玉米、果树、蔬菜、花卉，没有哪一样完全是“天然原样”；它们几乎都带着人类长期驯化、筛选与改造的痕迹。最早的小麦不是今天的样子，最初的野蔷薇也不是今天月季的样子。再看现代社会，电力、发动机、计算机，直到这几年席卷全球的大语言模型，也都是人类在逐步理解自然规律之后，以自己的价值判断、技术能力和现实需求，对既有状态所做的主动改写。无论是改写植物的形态，金属的性能，还是微观世界中信息与能量的组织方式，创新的本质，都是在理解规律之后，尝试把世界推向一种此前并不存在的形态。

但创新不是一条直线，它几乎总是由大量试错铺出来的。真正落下来的成功，常常只是无数失败、偏差、误判、半途而废和偶然撞中的极少数结果。也就是说，创新可以被追求，却不能被精确规划；可以长期投入，却不能保证按人的意志定点开花。很多时候，99.9%都是筛选、淘汰、疲惫和沉没，最后留下的0.1%，往往仍然带着浓厚的偶然性。人能做的是准备土壤、积累样本、提高判断力、承受漫长的无果期，但那个真正成立的“新东西”，什么时候出现、以什么形式出现，并不完全受控。正因为如此，系统维护和创新从来不是对立关系。一个人若没有长期维护系统、维护样本、维护环境、维护观察能力，就不会有创新发生的条件；而创新本身，也不是对维护的否定，而是维护在长时间尺度上偶然结出的果。

我自己在花园里的月季育种过程，就是一个很具体的例子。自从高中接触植物学开始，我就一直有一个很朴素很个人化的愿望：这辈子想亲手创造出一株属于我自己的植物。后来真正有机会实践时，我想做的是一株“完美月季”：完全抗病，耐旱耐热，持续开花，花朵硕大，不需要精细照料，不需要频繁施肥打药，只要阳光和雨水基本到位，就能每个月稳定给你一把足够插花的花枝（月季的独特性，全世界几乎所有的木本植物都做不到一年中多个月份反反复复开花）。换句话说，我想培育的不是一株需要人长期伺候的娇贵植物，而是一株兼具观赏性与自立性的园林花卉。

为了逼近这个目标，这些年我依靠自己广泛购买、采集，也得到不少朋友的帮助，在大量扦插繁殖与异花授粉育种中反复筛选。前前后后，我接触过三百多个品种，繁育过几千，甚至可能上万株植株。我的方法很简单很残酷，就是高淘汰率筛选：在同等条件下，五十株里面也许只留下两株，甚至一株继续观察，其他绝大多数不是送人，就是直接淘汰。最开始几年，我还尽量维持比较严谨的科学记录，追踪谱系、观察性状、做比较系统的筛选。但随着时间推移，我越来越疲惫，也越来越感到力不从心，因为月季本身就是一个极容易感染黑斑病和白粉病的属类。只要我在某个谱系中看到明显病害，我通常就会立刻放弃，不再继续投入。

真正有意思的是，到最后，我几乎已经准备结束这场试验的时候，才突然发现，在这一大片不断淘汰、不断清理的试验田里，居然有一株自己留了下来。你可以在下图中看到最初发现他的这一片田，其他的兄弟姐妹全部被淘汰了。它的花开得如牡丹一般硕大，叶片带有明显的蜡质感，而且几乎从不染病。讽刺的是，也正因为后期我实在太累，很多早年的记录没有完全维持下来，以至于连这株植物的父系母系谱系，我都已经无法百分之百追溯清楚。它不是在我最有掌控感、最严密的时候出现的，反而是在我几乎要放弃的时候，以一种近乎偶然的方式浮现出来。

现在，我已经清除了其他大部分品种，把精力集中在这一株特异变种上：一方面通过自花授粉去观察和稳定它的性状，另一方面通过扦插繁殖去复制它现有的基因表达，并不断送给朋友种植，让它在更多真实环境中扩散、验证。也有人建议我以后去考虑专利注册，只是这件事目前在我看来既麻烦又昂贵，所以暂时没有推进。

整个过程让我形成了一个以前没有的系统观：创新并不是对系统维护的背叛，恰恰相反，创新只能生长在长期维护之中。但与此同时，创新的成功也绝不是线性努力的必然回报。你可以计划试验，计划筛选，计划投入，计划方向，却无法计划伟大本身。伟大不能作为一项任务被执行，它更像是在无数维护、试错、淘汰与坚持之后，由偶然亲手落到你面前的东西。

看清现实，去真正创新会发生的地方呆着

所以你现在看到科研界发生的很多变化，以及一些大国正在做出的不同选择，并不只是政策摇摆，而是科研组织形态本身正在重构。越来越多前沿研究开始从传统高校体系中外溢出来，大厂、头部公司和私人实验室，正在成为某些关键领域的新先锋。原因并不神秘：它们有钱、有人、有算力，也经过了长期市场筛选，因而更有条件维持高密度试错、高成本投入和快速迭代所需要的科研环境。以 SpaceX 为例，NASA 近年的月球计划本身就在越来越多地转向商业系统，Reuters 2026 年的报道直接指出，NASA 已开始把后续任务向商业竞标开放，传统承包商体系则因高成本、低频率和技术路径老化承受越来越大压力。

尤其在计算机与 AI 领域，这种转移更加明显。前沿模型、超大规模算力、工程化部署、真实用户反馈和持续资本投入，决定了今天很多“真正的创新”已经不再主要发生在传统学院式实验室，而是发生在拥有数据、芯片、云基础设施与产品闭环的公司体系里。斯坦福 2025 AI Index 也反复强调，前沿 AI 模型的训练成本和算力门槛仍在快速攀升，这天然会把最前沿研究推向资源最集中的机构。

相反，传统象牙塔正在同时面临几重压力。第一，论文体系本身的边际创新效率在下降，评价机制越来越依赖发表数量、基金指标和同行博弈，导致真正高风险、高试错、高失败率的创新越来越难在学院体制内生存。第二，学术界近年丑闻频发，从论文撤稿、数据造假到署名与同行评审争议，都在削弱学术共同体原本的道德权威。第三，大学过去最核心的一个位置，是掌握知识的解释权；但在 AI 时代，这种权力正在被削弱，因为知识获取、压缩、检索、解释的入口，已经不再只属于大学。于是，大学不仅失去一部分科研垄断地位，也开始失去过去支撑高学费体系的认知稀缺性。

这也是为什么美国和英国这些传统学术高地，都出现了越来越明显的结构性紧张。在美国，2025 年以来，高教组织 ACE 公开跟踪并批评特朗普政府一系列针对高校和联邦教育系统的重组与经费压缩动作，明确提到教育部裁员、研究拨款冻结、联邦角色收缩，以及对大学体系的持续施压。在英国，大学财政危机已经转化为实质性裁员。2025 年初，《卫报》援引业内估计称，英国高校系统中可能出现多达一万个岗位的裁撤或流失；同年 5 月，英国高教监管机构的财务健康检查又显示，英格兰高校收入已连续第三年下滑，国际学生招收不及预期正在继续推动裁员、削减项目和出售资产。

所以更深一层地看，今天科研组织的变化，不只是“高校不行了、公司起来了”这么简单，而是创新越来越依赖高能量密度、高资本密度和高试错容忍度的环境。传统大学擅长的是知识整理、人才训练、学术传承与相对稳定的中长期研究；但在某些需要巨量算力、巨额投入、极快反馈和高失败承受力的新领域，私人公司与产业实验室越来越具备主导权。

一些举国体制的“计划型创新”，那更是成功希望比较渺茫了。

从下图看，这里大量的杂交幼苗全部都没有成功。因为成功就是偶然的。成功的那一株倒是挺神的，我都不知道他哪里来的。但是完全抗病，春季开花如牡丹那么大。

复杂系统无法掌控一切：永远都有杂草（bug），物理拔除不是最佳方案

只要真正做过园艺的人，或者一位经验老道的农民，都会告诉你：杂草永远存在。不是暂时存在，而是持续、反复、不可终结地存在。你今天拔掉，它明天还会长出来；你如果更激进一点，使用除草剂，那么问题就变成了另一种形式：你如何确保土壤不被化学破坏？你又如何保证那些你真正想要的植物不会一起被伤害？如果你无法容忍杂草的存在，那么很遗憾，你的全部时间都会被消耗在拔草这件事上，而且这件事本身几乎没有终点。

我这里想说一个我逐渐悟出的道理：在一个复杂系统中，每一个个体都拥有自己的“基因”和能动性。一片田野里，每一株草、每一只昆虫、每一只兔子，都是独立的个体，它们各自按照自身的逻辑在行动。一个公司也一样，不管有多少员工，每个人都有自己的理解和判断，并不是一个可以完全被编程的机器。一个国家更是如此，不同的人种、文化、宗教、地域，构成了高度多样的个体集合，每个人都是独立的、有想法的、不可完全预测的。任何一种试图通过中央控制、行政规划或者“硬代码”来掌控一切信息、阻止一切异常、不让任何“杂草”或bug出现的设想，本质上都是违背复杂系统规律的。这里不得不提到一位我反复学习的理论来源——伊利亚·普里高津 在《Order Out of Chaos》中的核心观点：

只要系统远离平衡（far from equilibrium），结构、扰动和“杂草”就必然不断涌现。

为什么会这样？因为系统不是静态的，而是“持续耗散”的。所谓耗散结构，本质上就是系统不断输入能量，同时不可避免地输出熵。一个花园在输入阳光、水分的同时，也会产生竞争、混乱和杂草；一个公司在输入资金和信息的同时，也会产生误差、冲突和低效；一个国家在运行过程中更是持续地产生各种噪声与不确定性。一个只输入能量而不产生任何混乱的系统，在现实世界中并不存在，那只存在于神话中的伊甸园。

因此，关键不在于“如何消灭杂草”，而在于你如何看待杂草。对于程序员来说，这一点尤其容易理解：如果你无法容忍任何一个bug，那么你将永远处于修bug的循环之中，而且这个循环没有终点。换一个角度来看，杂草并不是全都代表着计算的异常，而是系统运行的副产物。我们每天面对的各种问题——无论是组织中的摩擦，还是AI生成代码中的错误——本质上都属于这一类“不可消除的副产物”。你不可能指望任何一个复杂系统是完全无噪声、完全无bug的。

如果不物理拔除杂草，是否可以采用更聪明的“制衡”方法？

在园艺中，我逐渐放弃了粗暴的“拔掉”或者依赖除草剂的方式，而开始采用一种更有效的策略：时间上的制衡。比如说，大多数杂草的生命力往往强于你精心种植的植物。但这并不意味着你只能被动应对。你可以改变时间结构，比如提前种植多年生植物，例如郁金香、菊花的根系等。当春天到来时，这些植物已经率先占据了光、水和空间这些关键生态位，杂草即使出现，也缺乏生长的条件。你并没有消灭杂草，而是让它“没有机会”。

如果把害虫也看作一种“bug”，那么还可以进一步引入定向制衡。我有一位很喜欢种菜的朋友，她在每一颗番茄旁边都会种上一株万寿菊。番茄 + 万寿菊，其实是一个经典的伴生种植模型，本质上是在系统内部嵌入一个“天然对抗单元”。万寿菊能够通过根系分泌物抑制土壤中的线虫，通过气味干扰害虫定位，同时吸引有益昆虫。这里没有任何“消灭害虫”的动作，但害虫的生存路径被持续削弱。

当我们把视角从园艺扩展到更大的系统——人类社会、组织结构，乃至AI时代的复杂系统——这个逻辑同样成立。面对复杂性，最重要的不是试图彻底清除异常，而是理解哪些做法会导致系统退化。不要强行清零，因为推倒重来意味着你同时摧毁了已有的稳定结构，而生态位一旦空出来，问题只会更快回来。不要试图全局压制，因为任何个体、任何组织、任何中央系统的认知能力都是有限的，试图掌控所有变量只会让控制成本指数级上升，历史上许多高度集权的系统最终都崩溃在这一点上（比如苏联）。也不要依赖类似“除草剂”的过度优化手段，把复杂系统压缩成单一KPI进行优化，这种做法往往会同时破坏“好结构”和“坏结构”，最终导致系统整体质量下降。

按照我的理解，一个好的系统，并不是被设计成完美的，而是可以被“引导”成良性的。也就是说，你需要基于自己的价值取向，去慢慢推进一个系统，使某些结构更容易生长，而另一些结构逐渐失去空间。从普利高津的视角来看，这甚至不是在“控制系统”，而是在通过选择性地引入结构，使某些演化路径变得更加稳定，而另一些路径自然衰退。在远离平衡的复杂系统中，秩序不是通过消除涨落获得的，而是在时间中，通过不断稳定某些结构，逐渐形成的。

现实的复杂度远超个人或者系统的计算阈值，任何人为计划都无法掌握全部信息，只有靠系统的信息反馈来慢慢调整。

现实世界的复杂度远超任何个体或者系统的计算阈值：计划不是控制工具，它只是一个初始猜测；真正决定系统走向的，不是你一开始的设计，而是后面一轮一轮的信息反馈回路。人在起点不可能掌握全部变量——光照是季节性的，土壤有历史遗留，微生物在动态变化，材料在分解，个体有各自的基因差异——这些变量不仅数量巨大，而且一直在变化。所以任何“自上而下、一次性设计完美”的方案，在现实里都会迅速失效。唯一能走通的路径，就是让系统先跑起来，然后靠反馈一点点修正结构。

信息反馈这件事，在植物上是最直接的。它好不好，它会直接告诉你。不结果、不生长、生病、慢慢死掉，这些都是信号。而且这种信号有一个极其重要的特征：真实、不可伪造。它不会解释原因，不会帮你合理化，更不会替你掩盖问题。它只是把结果摆在那里。

如果你是程序员，开发过程本质就是：报错 → 修改 → 运行 → 再报错 → 再改 → 收敛。但这里面有一个前提——报错必须可信。如果一个系统不报错，或者报错是延迟的、缺失的、误导性的，甚至是“包装过”的，那你就不是在调试，而是在被系统消耗。你会完全失去判断能力。一个连错误信号都不可信的系统，是不可调试的。一个系统要是连报错都是假的，那你肯定想直接砸机。

自然系统，它几乎是一个“零欺骗”的反馈系统。一棵植物非常诚实。你看着一个地方，阳光好、排水好，你觉得它一定长得好，但它就是长不好。你往回推，才发现变量根本不在你当初考虑的那一层。春天树叶没长出来，光很好；等到初夏，它最需要光的时候，树冠一合，光被挡死了。你不知道地下被埋过碱（我真的遇到过，以前的某个房主可能因为鼹鼠问题埋了碱），pH直接爆增，这个星球耐弱酸的植物多，耐碱的很少，立即死；你不知道木屑没熟化，在分解过程中疯狂吸氮，把整批木本植物的幼苗拖死。这种情况我遇到无数次，而且几乎每一次，原因都在你原本认知之外。每一株植物都在找一个点：阳光、水分、土壤、基因刚好匹配的那个点。但问题是，人类无法提前掌握这些全部信息。你把这个复杂度放大到公司、组织、国家，那信息量是指数级上升的。

所以我这里真正想讲的不是复杂度本身，而是反馈机制。植物给你的，不是答案，而是一个极其干净的反馈信号。也正因为这个信号是可信的，我才能在一次次踩坑之后，通过分析，把问题一点点还原出来，甚至细到土壤微量元素这一层（我还真碰到过一次“缺镁元素“的）。

在复杂系统中，系统能不能被治理，取决于反馈是否真实、及时、不可篡改。

作为系统设计者，去设计真实的反馈；无法获取真实反馈的，直接不玩了

那些连报错都是假的系统，你在里面投入的不是时间，而是被不断误导的认知成本。你无法判断因果，无法建立经验，无法形成稳定结构，只能在噪音里反复试错，最后把人拖垮。

同样，我也不再接受任何形式的“隐藏信息”和“潜规则”。那种你猜我、我猜你、绕圈子、靠揣测推进的系统，本质上就是在破坏反馈通路。它不是在增加复杂度，而是在主动制造不可观测性。你看似在参与一个系统，实际上你拿不到系统的真实状态，只能靠猜，这种系统是无法被优化的。

其实反馈并不是AI时代才出现的东西，反馈一直都是复杂系统设计里的核心环节。控制论、工业系统、组织管理、生态系统，甚至市场，本质上全都建立在反馈上。没有反馈，就没有调节；没有调节，就没有真正的系统运行。一个恒温器（比如你家空调）靠反馈调温，一个企业靠反馈调整经营，一个生态系统靠反馈维持动态平衡。复杂系统之所以不是一次性设计完就结束，就是因为它必须在运行中不断根据反馈修正自己。

AI改变的不是反馈原则，而是反馈疆域。机器一旦开始读懂语义，系统能接住的现实就突然扩大了。

过去的系统当然也有反馈，但它们主要吸收的是那些容易被机械化接住的反馈：温度、速度、库存、报错、点击、产量、死亡、生长停滞。这些反馈大多属于物理层、行为层、指标层，是可以直接被传感器、表格、日志捕捉的。但还有大量反馈，其实一直存在，只是漂浮在人类语义系统里，进不了正式系统。比如犹豫、推诿、误解、抱怨、模糊责任、反复解释、话语中的不确定、文档中的暧昧、协作中的摩擦、需求里的自相矛盾。这些东西过去不是不重要，而是机器读不懂，所以只能留在人脑、会议、闲聊、邮件和各种“你自己体会”的空间里。

现在AI最根本的变化就在这里：它开始可以直接处理文本、图像、语音、上下文，开始能够从语义层接住反馈。于是反馈第一次不再只局限于物理信号和硬指标，而是扩展到了原来只能靠人类经验去感受、去解释、去闻出来的那部分现实。也就是说，AI没有改变“反馈是复杂系统核心”这件事，AI改变的是：什么东西现在也可以算作系统反馈了。

不是技术做不到，而是技术已经开始做得到之后，你到底用什么系统观去约束它、组织它、落地它。

过去很多时候，设计者的主要问题是能力不足。机器看不懂语义，系统接不住这些漂浮在人类解释层里的反馈，所以很多事情不是你不想做，而是你根本做不了。但现在不一样了。现在的问题恰恰是，技术能力已经越过了一个门槛：文本能读，图像能读，语音能转，日志能归纳，上下文能拼接，弱信号能提取。也就是说，系统开始有能力吸收比过去大得多的反馈范围。而这时候真正困难的地方才出现：你到底吸收什么，不吸收什么；你到底把什么当作真实反馈，什么当作污染；你到底如何设计边界，如何设计验证，如何设计调度，如何防止系统把“可读懂的语义”错当成“可信的现实”。

所以这一代系统设计者面对的，不再只是工程复杂度，而是反馈治理复杂度。因为语义一旦能进系统，系统的能力会暴涨，但系统的风险也会暴涨。你接进来的不只是信息，还有误导、情绪、包装、叙事、权力痕迹、组织修辞、历史噪音。技术上能读懂，不等于系统上该吸收。能处理，不等于该相信。能进入，不等于该调度。这中间差的，正是系统观。

只要是为人服务的系统，人本思想，就必须无处不在。

1）人与任何长期交互的容器、信息体，都会形成一种能量互补或者交换的关系。人不是在“使用”系统，而是在不断向系统输入注意力、时间、情绪与判断；系统则以反馈回应这种输入（花开、数据变化、结果显现、行为改变）。长期来看，这构成一个闭环：人被激励，或被消耗，系统被维持，或被衰败。这种关系，远远超出了“工具使用”的范畴。

2）任何看似不相关的主体，也许都是系统的一部分。系统的边界，很多时候只是人为切出来的，是为了方便控制与建模。但在真实世界中，尤其是在复杂系统中，参与者远不止我们定义的那几个核心节点。

3）人本思想，本身就是处理复杂性的一部分。它不是情怀，而是方法论，是在无限变量、不可建模状态、延迟且带噪反馈中，找到一个可依赖的压缩锚点。

打个比方，我这个花园，最初建设有一个“暗目标”：尽量在全年提供足够的花蜜给蜜蜂采集。尤其是在深秋阶段，蜜蜂容易出现储备不足，因为大多数花卉并不在这个季节开花。所以我刻意设计了大量冷季开花的植物。你可以看到，我去年11月拍的照片里，整个花园依然处在盛花期。从园艺角度，这叫“冷季花园”，在这个区域并不多见。所以我的花园，这个时候蜜蜂数量甚至超过春季。我拍到大量熊蜂在花里“睡觉”，还有一些本地特有的独居蜂在活动。

好，如果继续说下去，可能听起来会有点“玄”。但我个人是承认世界复杂性的。对于那些暂时无法被严格证明、但可以被稳定感知的现象，我是认可并在日常中使用的。我认为，人与系统之间不是“使用关系”，而是“能量交换关系”。

比如人与环境，人与长期居住的房子。我和一位建筑师朋友聊过一个现象：我在房地产公司工作时，去过很多美国老城区，我发现一个很稳定的规律——只要房子一直有人居住，不管楼龄多大，看起来都“还行”；一旦长期空置，就会迅速衰败。这不仅仅是“有没有人维护”的问题。我朋友非常认同这一点，他虽然是一个理性工程背景的人，但也认为人与建筑之间存在一种难以完全量化的“交换关系”。

其实把它翻译成工程语言，也并不神秘：当人长期与一个系统交互（花园、软件、组织、知识库、社区、房子），本质上发生的是——注意力输入、系统反馈，以及能量循环。一旦输入中断，系统就会失去结构活性，开始退化。

所以，我当然应该关心其他“系统使用者”，比如蜜蜂活得好不好。这是系统完整性的一部分。

系统边界是人为切出来的

“任何看似不相关的主体，也许都是系统的一部分”

这句话乍一听有点反科学，但仔细想，并不是。自然界本身并没有清晰的边界，边界是为了工程控制而引入的工具。在技术系统中，我们必须划边界，否则无法管理复杂度。但问题在于：在我们“能力所及”的范围内，在那些可以顺手设计的部分，为什么不让更多主体有生存空间？

这在社会层面其实早已有体现。比如企业是否应该照顾弱势员工？残障人士是否应该被系统性排除？弱势群体是否应该得到公共资源支持？如果从极端效率角度，这些都可以被剔除。但现实是，我们逐渐意识到：他们并不是“系统之外的人”，而是系统的一部分。剔除他们，并不是优化，而是在削弱系统的韧性。

“人本思想”不是道德，而是复杂性处理策略

在复杂系统中，变量是无限的，状态不可完全建模，反馈具有延迟且充满噪声。这类系统在人类社会中无处不在：组织、国家、公司、市场，每一个单独拿出来，其复杂度都不低于一个大型工程项目。

而“人”，是目前唯一具备以下能力的节点：

• 多模态感知（视觉、情绪、经验）

• 模糊判断能力

• 长期价值判断能力

因此，在这种系统中，以人为本，并仅仅不是“善意选择”，而是一个工程上的最优解：

人，是压缩复杂度的最优代理节点。

然而现实中，很多系统在做相反的事情：为了效率，去掉人；为了指标，裁掉骨干；为了优化资源配置，让财富极度集中。这些决策在短期内往往是“正确的”，但它们在悄悄切断一个关键层——人的反馈层。

任何为人服务的系统，如果为了效率而削弱人的参与度，本质上是在用短期确定性，换取长期系统不稳定性。

当系统开始“去人化”，会发生什么？

第一阶段：效率提升

• 指标变好

• 成本下降

• 决策更“干净”

第二阶段：反馈丢失

• 弱信号消失

• 异常无法提前感知

• 系统开始“看不见问题”

第三阶段：结构脆化

• 抗冲击能力下降

• 局部错误无法被吸收

• 小问题开始被放大

第四阶段：系统性崩塌

• 突发性失败

• 无法恢复

• 甚至找不到原因

系统是否仍然保有持续的人类输入，作为其结构活性的来源。就如一个人类的花园，就算蜜蜂不参与种花种菜，仍然是重要的系统健康指标。养活他们，实际上是活化系统。

一旦这个输入被切断，系统即使在短期内运行得更“高效”，也已经在走向不可逆的衰退路径。

下图是我秋季的冷季花园。园艺有Cool flowers这一说法，比如菊花，金鱼草等，都属于冷季开花，吸引大量蜜蜂。

写在最后

一个系统，如果真的能够稳定运转，它的建立不是一蹴而就的，而是在反复试错、运气叠加、以及大量人的持续投入之中，慢慢长出来的。但系统的衰败却完全相反，它不需要复杂条件，也不需要剧烈冲击，往往只要失去维护，就会以极快的速度退化。就像我做了十年的花园，到现在都还没有完全达到理想状态，但只要停止一年对土壤的管理、施肥节奏、杂草控制，以及木本植物和多年生草本在正确季节的补充，这个系统几乎会在一个周期内迅速失序，甚至变得不可看。

AI 的出现，让很多程序员误以为这是某种“终局之战”，仿佛一切都会被重写。但从现实来看，这一轮 AI 的估值中显然存在巨大的泡沫，大量创业公司最终会面临和其他行业一样的问题——无法盈利、无法持续，最终被淘汰。这是正常的技术扩散路径。但大语言模型已经不可逆地改变了人类的技术树。

如果把视角拉长，你会发现，美国战后的科技进步，并不是靠跳跃式革命完成的，而是一种缓慢但持续的生产效率提升过程。技术真正改变世界的方式，往往不是“替代一切”，而是从系统的边缘切入，在不打断原有结构的前提下，逐步渗透、重构。

这一点在当前 AI 的落地路径中已经非常明显。许多传统行业并没有选择“全面 AI 化”，而是在“入口”位置引入大语言模型，比如客服系统。但客服从来不是“聊天”这么简单，它本质上是信息的采集节点、分类节点，以及后端流程的触发器。AI 在这里的价值，不是替代人，而是优化信息进入系统的结构质量，然后通过这个入口，逐步向后端渗透。

真正关键的问题不在于“All in AI ”这只是一个好听的口号罢了，而在于：你是否理解了这个入口的设计机制？信息是如何被接住、如何被结构化、如何被传递到后续环节？客服与后端服务人员之间的衔接是否是连续的，而不是断裂的？如果这些问题没有解决，就谈不上系统级的 AI 化。

相反，那种一开始就以“替代所有人工”为目标的路径，本质上是一种机械式的、去人本的设计思路。这种系统往往忽略了真实世界中人作为反馈源、判断者和调节器的作用，因此很难在复杂环境中稳定运行。

更可行的路径，始终是先服务于人——让系统先嵌入人的工作流，承接人的一部分负担，在真实反馈中逐步演化，而不是试图在一开始就重构一切。只有这样，AI 才不是一个外部工具，而是一个可以在系统内部“长出来”的能力。

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 才能从“会说话的工具”，进化为“可参与责任的系统”。

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

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 不再只是模糊的直觉，而是能被回放、被观察、被约束。但它是否真的能承载那种“方向性压缩”，目前我还不能保证。

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/

Design Theorems (设计定理)

0) Design Theorems (Fix These First)

These four points are not “recommendations,” but provable constraints that allow RRB to survive for ten years. They confine model uncertainty to the Proposal Zone, lock system sovereignty writes into the Deterministic Zone, and contain side effects within the Ticket Zone. If any one of them is violated, RRB degrades into ordinary CI/CD: it can run, but ten years later it cannot answer “why.”

0.1 RRB Does Not Judge, and Is Not “Smart”: It Only Translates and Orchestrates

(RRB = Translation + Orchestration, not Judgment)

RRB’s sole mission is to translate human / institutional responsibility declarations (Intent) into auditable, recomputable, executable structures, and to bind execution strictly to tickets produced by institutional judgment.

It does not decide whether to release, nor does it optimize release strategies. It only takes an action request that has an explicitly declared responsibility, passes it through a deterministic compilation pipeline and institutional gates, turns it into a DecisionRecord that can enter history, and executes side effects only when permitted.

Core implications:

• Judgment authority belongs to institutions (Policy Gate), not to the bot. The bot only delivers inputs into the institution and persists outputs according to protocol.

• Intelligence is allowed only in the Proposal Zone: explanations, drafts, candidate changes may be smart. Once inside the sovereign zone, only deterministic flows are permitted (validate / canonicalize / hash / policy / evidence / write).

• RRB’s correctness is not measured by “release success rate,” but by:

  1. Every historical write has a responsible subject;

  2. Every decision is recomputable;

  3. Every side effect is traceable to a ticket.

In short: RRB’s value lies not in automation, but in accountable automation.

0.2 Triggers Must Be Intent: Intent ≠ Event

(Trigger Is Responsibility, Not Activity)

RRB must be triggered by Intent (a responsibility declaration), not by any form of Event (an occurrence).

Events can be endless: push, merge, CI green, tests passing, issue closed, time elapsed… These can only serve as evidence inputs, never as sovereignty advancement.

Why this is mandatory:

• Events are facts, not responsibility; they say “something happened,” not “it should happen,” “who bears the consequences,” or “how failure is explained.”

• Intent is an institutional statement: it upgrades “I want to do this” into “I am willing to take responsibility for advancing history,” explicitly specifying the responsible subject, scope, risk acceptance, rollback plan, and so on.

• Once events are allowed to trigger sovereign writes, the system enters the dangerous state you described:

  The system advances its own history silently (no declaration, no responsibility, no explanation).

Hard constraints:

• Intent must originate from humans or institutions, never from agents or LLMs.

• All events may only populate the evidence field or act as optional policy inputs, but must never become triggers.

• “All green” is not a prerequisite for release; at most, it is one execution condition, not a justification for advancing history.

In one sentence: Events explain the world; Intent changes the world. RRB recognizes only the latter as a legitimate starting point.

0.3 No LLMs in the Sovereign Zone:

Policy / Scheduler / Ledger / Canonical Memory Must Be Model-Free and Recomputable

(Sovereign Zone = Deterministic)

RRB must enforce a strict system boundary:

LLMs may exist only in the Proposal Zone. Any component that results in historical facts or execution permissionmust be deterministic, reproducible, and recomputable.

The Sovereign Zone includes:

• Policy Gate — institutional judgments (ALLOW / DENY / REQUIRE_OVERRIDE)

• Scheduler — timing, execution windows, retry strategies, freeze policies

• Ledger / DecisionRecord / OverrideRecord — append-only institutional facts

• Canonical Memory — canonicalized source inputs for recomputation

All of these must satisfy a single invariant:

Given the same canonical inputs and the same policy_version (+ hash), the system must produce the same decision, and must be able to reproduce the full evidence chain for that decision in the future.

Why LLMs must never enter:

• LLM outputs are inherently non-deterministic: the same prompt can yield different outputs; more critically, they introduce unprovable external state (model versions, temperature, vendor updates, implicit context).

• Once an LLM enters Policy / Scheduler / Ledger, replay collapses: you can only narrate what happened, not recompute why that judgment was made.

• The goal of the sovereign zone is not to be smarter, but to be more accountable. Intelligence is a variable; institutions are constants.

Mandatory recording rules:

• Every ledger entry must include origin and replayable=true/false.

• All LLM outputs default to replayable=false and may only be proposals or annotations, never gate inputs.

In one sentence: The sovereign zone should behave like a compiler, not a chatbot.

0.4 Execution Must Be Ticketized:

The Executor Recognizes Only DecisionTickets

(Ticket-Gated Execution)

RRB’s execution layer must be designed so that without a ticket, nothing can be executed.

The Executor must not accept “raw inputs” (such as tag names, version numbers, or commands). It accepts only a DecisionTicket (or a decision_id → ticket lookup), and performs strict consistency checks before execution.

What a Ticket Is:

• A Ticket is an institution-issued portable authorization, binding execution side effects to:

  • decision == ALLOW

  • request_hash (hash of the canonical request)

  • policy_version + policy_hash

  • decision_id (pointer to the persisted record)

• Tickets enforce a critical property:

  Institutional facts are written before side effects are allowed

  (record-before-side-effects)

  Thus, even failures do not “evaporate”: DENY and OVERRIDE become auditable history.

Execution-layer hard constraints (must be enforced in code, not by convention):

• no ticket → no exec

• ticket.decision != ALLOW → no exec

• ticket.request_hash != computed_request_hash → no exec

• ticket.policy != current_policy_ref → no exec

• Optional but recommended: revoked / expired → no exec

Institutional meaning:

• Side effects are not a “program capability,” but an institutional authorization.

• Ticketization fully separates “can it be done” from “should it be done”:

  • Policy decides should

  • Tickets carry proof of authorization

  • Executors merely act on proof

In one sentence: Build the execution layer like access-control hardware, not like an obedient person.

Summary: The System Properties of the Four Theorems Together

If these four constraints are locked in, RRB gains a hard, provable long-term property:

The advancement of system history can be triggered only by responsible subjects; institutional judgments are recomputable; side effects are traceable; failures do not evaporate.

This is the engineering form of the statement you are aiming for:

A mature intelligent system is not mature because it is smart, but because ten years later it can still answer: “Why did we do this back then?”

0) 设计定理（先钉死）

这四条不是“建议”，而是 RRB 之所以能活十年 的可证明约束：它们把“模型的不确定性”关在 Proposal 区，把“系统的主权写入”锁进 Deterministic 区，把“副作用”锁进 Ticket 区。任何一条被破坏，RRB 就会退化成普通 CI/CD：能跑，但无法在十年后回答“为什么”。

0.1 RRB 不裁决、不聪明：只做翻译与执行（RRB = Translation + Orchestration, not Judgment）

RRB 的唯一使命是把 人类/制度的责任声明（Intent） 翻译成 可审计、可重算、可执行 的结构，并把执行动作严格绑定到 制度产生的票据 上。

它不“决定要不要 release”，也不“优化 release 策略”；它只负责把一个声明过责任的动作请求，经过一套确定性的编译链与制度门禁，转化为可以进入历史的 DecisionRecord，并在被允许时执行副作用。

核心含义：

• 裁决权属于制度（Policy Gate），不属于 bot。bot 只是把 inputs 送进制度，把 outputs 按协议落盘。

• 聪明只能出现在 Proposal Zone：解释、草案、候选变更可以聪明；进入主权区后，只允许确定性流程（validate/canonicalize/hash/policy/evidence/write）。

• RRB 的正确性不是“release 成功率”，而是：

  1. 所有历史写入都有责任主体；

  2. 所有决策可重算；

  3. 所有副作用可追溯到一张票据。

一句话：RRB 的价值不在“自动化”，而在“可追责的自动化”。

0.2 触发必须是 Intent：Intent ≠ Event（Trigger is Responsibility, not Activity）

RRB 的触发器必须是 Intent（责任声明），而不是任何形式的 Event（活动发生）。

Event 可以无限多：push、merge、CI green、测试通过、issue close、时间到了……这些都只能作为“证据输入”，不能作为“主权推进”。

为什么必须如此：

• Event 是事实，不携带责任；它只说明“发生过”，不说明“应该发生、谁承担后果、失败如何解释”。

• Intent 是制度语句：它把“我要做”升级为“我愿意为这次推进历史负责”，并明确责任主体、范围、风险接受方式、回滚计划等。

• 一旦允许 Event 触发主权写入，系统就会出现你说的那种危险：

  系统在不知不觉中“自我推进历史”（无人声明、无人负责、无人能解释）。

硬约束：

• Intent 必须来自 human / institution，不得来自 agent/LLM。

• 所有 Event 只能进入 evidence 字段或作为 policy 的可选输入，但 不能直接变成 trigger。

• “全绿”不是 release 的前提，它最多是 执行条件的一部分，而不是“是否应当推进历史”的理由。

一句话：Event 解释世界；Intent 改变世界。RRB 只承认后者作为合法起点。

0.3 主权区禁止 LLM：Policy/Scheduler/Ledger/Canonical Memory 必须无模型可重算（Sovereign Zone = Deterministic）

RRB 的系统边界必须明确分区：

LLM 只能在 Proposal Zone；凡是会导致“历史事实”或“执行许可”的位置，必须是确定性、可复现、可重算的（deterministic, replayable, hashable）。

主权区（Sovereign Zone）定义：

• Policy Gate：制度判断（ALLOW / DENY / REQUIRE_OVERRIDE）

• Scheduler：何时执行、执行窗、重试策略、冻结策略

• Ledger / DecisionRecord / OverrideRecord：制度事实写入（append-only）

• Canonical Memory：决定重算的真源输入（canonicalized artifacts）

这些区域必须满足同一条性质：

给定同一组 canonical inputs + 同一 policy_version(+hash)，系统必须产生同一 decision；并且能在未来复现该 decision 的证据链。

为什么 LLM 绝对不能进入：

• LLM 输出天然不可控：同 prompt 也可能不同输出；更关键的是它引入了 不可证明的外部状态（模型版本、温度、供应商更新、隐式上下文）。

• 一旦 LLM 进入 Policy/Scheduler/Ledger，你的 replay 立刻失效：你只能“复述当年发生过”，无法“重算当年为什么那样裁决”。

• 主权区的目标不是“更聪明”，而是“更可问责”。聪明是波动项，制度是常量。

必须显式记录：

• 每条进入 Ledger 的记录都要带 origin 与 replayable=true/false。

• LLM 产物默认 replayable=false，只能作为提案或注释，不得作为 gate input。

一句话：主权区要像编译器，不像聊天机器人。

0.4 执行必须票据化：Executor 只认 DecisionTicket（ticket-gated execution）

RRB 的执行层必须被设计成“没有票据就什么都做不了”。

Executor 不接受“裸输入”（比如直接给它 tag 名称、版本号、命令）；它只接受一张 DecisionTicket（或 decision_id → ticket lookup），并在执行前做严格一致性校验。

Ticket 的本质：

• Ticket 是制度输出的“可携带通行证”，把一次执行副作用绑定到：

  • decision == ALLOW

  • request_hash（对 canonical request 的 hash）

  • policy_version + policy_hash

  • decision_id（落盘记录的指针）

• Ticket 的存在让系统具备一个关键性质：

  先写入制度事实，再允许发生副作用（record-before-side-effects）。

  这样失败也不会“蒸发”，DENY/OVERRIDE 都成为可审计历史。

执行层的硬约束（必须实现为代码，而不是约定）：

• no ticket → no exec

• ticket.decision != ALLOW → no exec

• ticket.request_hash != computed_request_hash → no exec

• ticket.policy != current_policy_ref → no exec

• 可选但推荐：revoked/expired → no exec

制度含义：

• 副作用不是“程序能力”，而是“制度授权”。

• 票据化把“能不能做”与“应不应该做”彻底分离：

  • Policy 决定“应不应该”

  • Ticket 承载“被授权的证明”

  • Executor 只负责“按证明做”

一句话：把执行层做成“门禁硬件”，而不是“听话的人”。

总结：四条定理合在一起的系统性质

如果你把这四条钉死，RRB 会出现一个很硬的、可证明的长期性质：

系统的“历史推进”只能由责任主体触发；制度判断可重算；副作用可追溯；失败不蒸发。

这正是你想要的那句话的工程化版本：

一个成熟的智能系统，不是因为它聪明，而是因为它能在十年后回答：“我们当年为什么这样做。”

Data Objects 数据对象

2) Data Objects (The Four-Piece Set)

This four-piece set is RRB’s minimal closed loop for the institutional pipeline. It upgrades a release from an “operation” to an accountable institutional event:

Intent provides the responsible subject, Request provides adjudicable input, Ticket provides execution authorization, and Record provides historical fact and the true source for replay.

Missing any one of them causes the system to degenerate at some stage into an unauditable script.

2.1 ReleaseIntent v1 (Responsibility Declaration, Legitimate Trigger)

Definition: A ReleaseIntent is a declaration of responsibility to “advance the world into a new state.” It is not a requirement, not a suggestion, and not an event description. It is a subject’s commitment to future side effects: I request the system to perform a release, and I accept responsibility for explaining its consequences.

Hard constraints:

• Allowed origins only: human | institution (must be identifiable and accountable)

• Forbidden origins: agent | LLM (models may propose, but may not trigger history)

• Write mode: append-only JSONL — every intent is an immutable fact (even revocations must be expressed via a new record)

Artifacts:

• runtime_data/release_intents.jsonl

  One line per intent, serving as the true trigger source. Any subsequent governance flow related to a release must be traceable back to a specific intent.

Semantic essentials:

• The core fields of an intent are not “what to do,” but:

  1. Who declares it; 2) Why; 3) How risk is accepted; 4) Rollback / loss-containment strategy; 5) Scope boundaries.

• An intent may be brief, but it must satisfy ten-year accountability: it must be able to answer who advanced history at the time and on what basis they accepted risk.

2.2 CapabilityRequest: repo.release (Adjudicable Request)

Definition: A CapabilityRequest is the product of turning an Intent into adjudicable input. It does not carry responsibility (that resides in the Intent); it carries a structured request that the Policy Gate can deterministically judge.

Key property: It must be canonicalizable. The same request—regardless of field order or formatting noise—must yield the same canonical representation and the same request_hash.

Hard constraints:

• Must pass a deterministic pipeline:

  schema_validate → canonicalize → request_hash

• The Policy Gate may accept only the canonical form (or its hash plus evidence references). Passing raw high-entropy text directly to the gate is prohibited.

Artifacts:

• Enters the Capability Bus (the single legal entry for capability=repo.release)

• request_hash becomes the primary key across the entire pipeline:

  • Anchor for DecisionRecord

  • Binding point for Ticket

  • Validation base for Executor

  • Stable input fingerprint for Replay

Semantic essentials:

• A Request is institutional language, not human language: fields must be directly referencable, comparable, and decidable by policy.

• A Request must reference its Intent (e.g., intent_id or intent_hash); otherwise, adjudication would occur without a responsible subject.

2.3 DecisionTicket (Execution Pass)

Definition: A DecisionTicket is the Policy Gate’s authorization credential, turning the result of an adjudicable request into a portable execution permit. Its existence guarantees that side effects can occur only after institutional facts have been written to history.

Minimal field semantics (the hard-core skeleton you listed):

• decision_id: pointer to the unique institutional judgment record

• decision: ALLOW | DENY | REQUIRE_OVERRIDE

• request_hash: binds to the adjudicated canonical request

• policy_version(+hash): binds to the policy version that produced the judgment (without it, replay fails)

• timestamp: issuance time (temporal anchor of the institutional fact)

• actor: who issued / endorsed it (human or institutional subject)

Hard constraints:

• Executor recognizes tickets only: no raw parameters, no CLI flags, no environment variables.

• Tickets must pass consistency checks:

  decision == ALLOW AND request_hash matches AND policy_ref matches

  (optionally also revoked / expiry)

• Tickets are not about “execution convenience,” but about blocking all governance bypass paths.

Artifact relationship:

• A Ticket is essentially a portable execution proof derived from a DecisionRecord, but it cannot replace the Record:

  The Record is the institutional fact; the Ticket is its execution projection.

2.4 DecisionRecord / OverrideRecord

(Institutional Facts, Append-Only, True Source for Replay)

Definition: A Record is an institutional fact the system has taken responsibility for over time. It is not a log, but a constitution-level historical entry. All RRB replay, auditing, and regression are anchored to it.

DecisionRecord (judgment fact) must include:

• decision_id (primary key)

• request_hash (fingerprint of the adjudicated object)

• policy_version + policy_hash (policy basis of the judgment)

• decision (ALLOW / DENY / REQUIRE_OVERRIDE)

• timestamp

• actor (institutional subject)

• (strongly recommended) evidence_refs: references to evidence inputs (CI results, diff summaries, risk flags, etc.). These are references—not live external state fetching by the gate.

OverrideRecord (override fact) must express:

• An override does not rewrite old records; it appends a higher-authority institutional fact:

  override_id / target_decision_id / by / reason / risk_acceptance / timestamp / scope

• Overrides are expensive actions and must be able to trigger subsequent policy review (an institutional self-correction loop).

Hard constraints:

• Append-only: never overwrite, never rewrite. Revocation or correction must be expressed via new records (revoke / replace / invalidate).

• Record-before-side-effects: write the DecisionRecord (or override fact) first; only then may the executor perform any side effects.

• Replay definition: replay = recompute the original judgment using Records + canonical inputs + policy_ref; it is not rerunning the workflow and not refetching external state.

Artifacts:

• runtime_data/decisions.jsonl, runtime_data/overrides.jsonl

  (or unified under runtime_data/governance/*.jsonl)

• Together, they constitute RRB’s ten-year explainability.

The Causal Closed Loop of the Four Pieces (One Sentence)

• Intent: who takes responsibility for advancing history

• Request: convert responsibility into adjudicable input (canonical + hash)

• Record: write the judgment as an institutional fact (append-only, replayable)

• Ticket: project the fact into execution authorization (ticket-gated, bypass-proof)

2) 数据对象（四件套）

这四件套是 RRB 的“制度流水线最小闭环”。它们把一次 release 从“操作”升级为“可追责的制度事件”：Intent 给出责任主体，Request 给出可裁决输入，Ticket 给出执行许可，Record 给出历史事实与 replay 真源。缺任何一个，系统都会在某个环节退化为不可审计的脚本。

2.1 ReleaseIntent v1（责任声明，合法触发）

定义：ReleaseIntent 是“把世界推进到一个新状态”的责任声明。它不是需求、不是建议、不是事件描述，而是一个主体对未来副作用的承诺：我要求系统进行一次 release，并承担其后果解释责任。

硬约束：

• 来源只允许：human | institution（必须可识别、可追责）

• 禁止来源：agent | LLM（模型只能提案，不能触发历史）

• 写入方式：append-only JSONL，每条 intent 都是一条不可覆盖的事实（即使后续撤销，也必须用新记录表达撤销/替代）

产物：

• runtime_data/release_intents.jsonl

  每条一行，作为“触发真源”。后续任何 release 相关的制度流程都必须能指回某条 intent。

语义要点：

• Intent 的核心字段不是“做什么”，而是：

  1. 谁声明；2) 为什么；3) 风险如何接受；4) 回滚/止损策略；5) 范围边界。

• Intent 可以很短，但必须满足“十年后可问责”：能回答“当时是谁让系统推进历史、他/它依据什么承担风险”。

2.2 CapabilityRequest: repo.release（可裁决请求）

定义：CapabilityRequest 是“把 Intent 变成可裁决输入”的产物。它不携带责任（责任在 Intent），它携带的是 Policy Gate 能够确定性判定 的结构化请求。

关键性质：它必须是 canonicalizable 的：同一个请求，无论字段顺序、格式噪声如何，都必须得到同一个 canonical 表示与同一个 request_hash。

硬约束：

• 必须先经过 deterministic pipeline：

  schema_validate → canonicalize → request_hash

• Policy Gate 的输入只能是 canonical form（或其 hash + 证据引用），禁止把“原始高熵文本”直接交给 gate。

产物：

• 进入 Capability Bus（capability=repo.release 的单一合法入口）

• request_hash 成为贯穿全链路的主键：

  • 写入 DecisionRecord 的锚点

  • Ticket 的绑定点

  • Executor 校验的基座

  • Replay 的稳定输入指纹

语义要点：

• Request 是“制度语言”，不是“人类语言”：字段必须能被 policy 直接引用、比较、判定。

• Request 必须包含对 Intent 的引用（例如 intent_id 或 intent_hash），否则会出现“无责任主体的裁决”。

2.3 DecisionTicket（执行通行证）

定义：DecisionTicket 是 Policy Gate 的“授权凭证”，把一次可裁决请求的结果变成一张可携带的执行许可。它的存在保证：副作用只能发生在制度已经写入历史之后。

最小字段语义（你列的这组就是硬核骨架）：

• decision_id：指向那条制度判断的唯一记录

• decision：ALLOW | DENY | REQUIRE_OVERRIDE

• request_hash：绑定到被裁决的 canonical request

• policy_version(+hash)：绑定到产生该裁决的制度版本（没有它 replay 失效）

• timestamp：签发时间（制度事实的时间锚）

• actor：谁在签发/背书（human/institution 的制度主体）

硬约束：

• Executor 只认 Ticket：不认裸参数、不认 CLI flags、不认环境变量。

• Ticket 必须做一致性校验：

  decision==ALLOW 且 request_hash 匹配 且 policy_ref 匹配（以及可选 revoked/expiry）

• Ticket 不是“优化执行便利性”的对象，而是“堵死绕过治理路径”的对象。

产物关系：

• Ticket 本质上是从 DecisionRecord 派生的“可携带执行证明”，但它不能替代 Record：

  Record 是制度事实，Ticket 是制度事实的执行投影。

2.4 DecisionRecord / OverrideRecord（制度事实，append-only，replay 真源）

定义：Record 是系统在时间中对世界承担过的制度事实：它不是日志（log），而是“宪法意义上的历史条目”。RRB 的 replay/审计/回归全都以它为真源。

DecisionRecord（裁决事实）必须包含：

• decision_id（主键）

• request_hash（裁决对象指纹）

• policy_version + policy_hash（裁决依据的制度版本）

• decision（ALLOW/DENY/REQUIRE_OVERRIDE）

• timestamp

• actor（制度主体）

• （强烈建议）evidence_refs：引用哪些证据输入（CI 结果、diff 摘要、risk flags…），注意是引用，不是让 gate 去“现场抓取外部状态”。

OverrideRecord（越权事实）必须表达：

• override 不是“改写旧记录”，而是新增一条更高权限的制度事实：

  override_id / target_decision_id / by / reason / risk_acceptance / timestamp / scope

• Override 是昂贵行为：必须能触发后续 policy review（制度自我修正回路）

硬约束：

• append-only：永不覆盖、永不 rewrite；如果要撤销/纠错，用新记录表达“撤销/替代/作废”。

• record-before-side-effects：先落盘 DecisionRecord（或 override 事实），再允许执行器做任何副作用。

• replay 的定义：replay = 以 Record + canonical inputs + policy_ref 重算当年的判断；不是重跑流程、不是重新抓外部状态。

产物：

• runtime_data/decisions.jsonl、runtime_data/overrides.jsonl（或你统一放到 runtime_data/governance/*.jsonl）

• 它们共同构成：RRB 的“十年可解释性”。

四件套的因果闭环（一句话把链条钉死）

• Intent：谁在承担推进历史的责任

• Request：把责任转成可裁决输入（canonical + hash）

• Record：把裁决写成制度事实（append-only，可 replay）

• Ticket：把事实投影成执行许可（ticket-gated，堵死绕过）

3) Main Flow (From Intent to History, Then Optional Execution)

The goal of the main flow is not “to get a release done,” but to turn a release into an institutionally explainable historical entry: before any side effects occur, a recomputable adjudicative fact must be produced; every adjudicative fact must point back to a responsible subject; every execution must be ticketed, revocable, and replayable. Intelligence is allowed in the flow—but it must never cross the sovereign-zone firewall.

3.1 Phase Structure: Three Zones, Five Steps

(Proposal / Sovereign / Execution)

• Proposal Zone (LLM allowed): transform Intent into candidate plans and candidate structures (drafts, explanations, diff summaries, risk lists)

• Sovereign Zone (LLM forbidden): deterministic compilation + institutional adjudication + append-only fact writing

• Execution Zone (LLM forbidden): ticket-gated side-effect execution (tag / release / deploy), optionally writing execution results to an event ledger

3.2 End-to-End Flow (High-Density Version)

(1) Intent Declared: Responsibility Enters the System (The Only Legitimate Trigger)

Input: ReleaseIntent v1 (human / institution)

Actions (deterministic):

• schema validation

• canonicalization (optional but recommended: canonicalize intent + compute intent_hash)

• append-only write to runtime_data/release_intents.jsonl

Invariants:

• Without intent, no adjudication chain may proceed (no intent → no history)

• Intents are immutable; revocation must be expressed via a new intent or record

(2) Proposal Build: Generate Candidate Requests (LLM Only Here)

Input: intent_id / intent_hash + read-only snapshot of current repo state

Actions (LLM allowed; outputs are always “proposals”):

• generate a draft CapabilityRequest (repo.release)

• generate explanatory materials (why release, risks, rollback, change summary)

• mark outputs with origin=model, replayable=false

Artifacts:

• proposal artifacts (may be persisted to runtime_data/proposals/*.json or printed to stdout)

• Note: proposals never enter the ledger or policy inputs unless extracted into structured fields by the deterministic compiler

Invariants:

• LLM outputs are candidates only; they must never directly trigger the bus, the ledger, or the execution gate

(3) Compile & Validate: Deterministic Compilation

(Turning Proposals into Adjudicable Requests)

Input: proposal drafts (or structured input provided directly by a human)

Actions (deterministic; the “compiler” before entering the sovereign zone):

• schema validation: repo_release_request_v1.json

• canonicalization: produce canonical request

• compute request_hash = sha256(canonical_request)

• construct CapabilityRequest (including intent_ref + request_hash + evidence_refs)

Artifacts:

• canonical request (optional persistence: runtime_data/canonical/requests/<request_hash>.json)

• CapabilityRequest enters the Capability Bus

Invariants:

• request_hash must depend solely on the canonical request (no implicit external state)

• Recompiling the same request at any time must yield the same hash (hash stability)

(4) Capability Bus → Policy Gate: Single Legal Entry for Adjudication

(Institutional Judgment)

Input: CapabilityRequest (repo.release) + policy_ref (version + hash)

Actions (deterministic):

• Capability Bus: normalize entry, package context, invoke policy gate

• Policy Gate: produce a three-state judgment:

  • ALLOW: institution permits issuing an execution ticket

  • DENY: institution explicitly refuses (refusal is also history)

  • REQUIRE_OVERRIDE: escalation to higher-authority signing / override flow

Artifacts:

• DecisionRecord (append-only, and written before any side effects)

• Optional: derived DecisionTicket (only when decision == ALLOW, or if you allow non-executing tickets)

Invariants:

• Policies must be versioned (policy_version + policy_hash), or replay is invalid

• The gate must not read implicit external state (time, env vars, network) unless explicitly included as inputs

(5) Ledger Append: Write Institutional Facts First, Then Allow Side Effects

(Record-Before-Effects)

Input: adjudication result + request_hash + policy_ref + actor + evidence_refs

Actions (deterministic):

• append to runtime_data/decisions.jsonl

• if overridden: append to runtime_data/overrides.jsonl (never overwrite prior decisions)

Artifacts:

• DecisionRecord / OverrideRecord (true source for replay)

• (if ALLOW) DecisionTicket (execution projection)

Invariants:

• Without a record, execution is forbidden (no record → no side effects)

• Overrides must not rewrite old records; only append new facts (append-only governance)

(6) Ticket-Gated Execution: Authorized Execution

(Side-Effect Zone)

Input: DecisionTicket or decision_id → ticket lookup

Actions (deterministic):

• verify decision == ALLOW

• verify ticket.request_hash == recompute_hash(canonical_request)

• verify ticket.policy_ref == current_policy_ref (or record.policy_ref)

• verify ticket not revoked / not expired (optional)

• execute side effects: git tag / GitHub release / deploy (plugin-based)

Artifacts:

• execution result events (recommended separate ledger: runtime_data/executions.jsonl)

• failures must also be recorded (failure does not evaporate; it is an asset)

Invariants:

• Executors never accept raw inputs (parameter bypass equals governance bypass)

• Tickets are the sole execution authorization (ticket-gated execution)

(7) Replay / Regression: Recompute Judgments from Records

(Not Re-running the Workflow)

Input: DecisionRecord + corresponding canonical inputs + policy_ref

Actions (deterministic):

• recompute the policy decision

• compare recomputed result with the recorded decision

• produce regression reports (for institutional evolution and anti-regression)

Invariants:

• Replay targets “recomputing the judgment made at the time,” not “rerunning past side effects”

• Policy changes must imply version changes; otherwise differences cannot be explained

3.3 Two Critical “Institutional Locks”

(What Makes the Main Flow Non-Bypassable)

1. Single-Entry Lock: all repo.release adjudication requests must pass through the Capability Bus (single choke point).

2. Side-Effect Lock: all side effects must pass ticket verification (single gate).

With these two locks plus an append-only ledger, RRB truly transitions from a “bot” into an organ.

3.4 Minimal v0 Execution Strategy

(Ship Immediately Without Taking Risks)

• v0: implement Intent → DecisionRecord (no automatic tagging, no deployment)

• v0.1: issue tickets only on ALLOW + ticket-gated tagging

• v0.2: plugin-based release/deploy + execution events ledger

• At every step, replay must remain functional: stabilize the sovereign zone first, then grow features

Main Flow (主流程)

3) Main Flow (From Intent to History, Then Optional Execution)

The goal of the main flow is not “to get a release done,” but to turn a release into an institutionally explainable historical entry: before any side effects occur, a recomputable adjudicative fact must be produced; every adjudicative fact must point back to a responsible subject; every execution must be ticketed, revocable, and replayable. Intelligence is allowed in the flow—but it must never cross the sovereign-zone firewall.

3.1 Phase Structure: Three Zones, Five Steps

(Proposal / Sovereign / Execution)

• Proposal Zone (LLM allowed): transform Intent into candidate plans and candidate structures (drafts, explanations, diff summaries, risk lists)

• Sovereign Zone (LLM forbidden): deterministic compilation + institutional adjudication + append-only fact writing

• Execution Zone (LLM forbidden): ticket-gated side-effect execution (tag / release / deploy), optionally writing execution results to an event ledger

3.2 End-to-End Flow (High-Density Version)

(1) Intent Declared: Responsibility Enters the System (The Only Legitimate Trigger)

Input: ReleaseIntent v1 (human / institution)

Actions (deterministic):

• schema validation

• canonicalization (optional but recommended: canonicalize intent + compute intent_hash)

• append-only write to runtime_data/release_intents.jsonl

Invariants:

• Without intent, no adjudication chain may proceed (no intent → no history)

• Intents are immutable; revocation must be expressed via a new intent or record

(2) Proposal Build: Generate Candidate Requests (LLM Only Here)

Input: intent_id / intent_hash + read-only snapshot of current repo state

Actions (LLM allowed; outputs are always “proposals”):

• generate a draft CapabilityRequest (repo.release)

• generate explanatory materials (why release, risks, rollback, change summary)

• mark outputs with origin=model, replayable=false

Artifacts:

• proposal artifacts (may be persisted to runtime_data/proposals/*.json or printed to stdout)

• Note: proposals never enter the ledger or policy inputs unless extracted into structured fields by the deterministic compiler

Invariants:

• LLM outputs are candidates only; they must never directly trigger the bus, the ledger, or the execution gate

(3) Compile & Validate: Deterministic Compilation

(Turning Proposals into Adjudicable Requests)

Input: proposal drafts (or structured input provided directly by a human)

Actions (deterministic; the “compiler” before entering the sovereign zone):

• schema validation: repo_release_request_v1.json

• canonicalization: produce canonical request

• compute request_hash = sha256(canonical_request)

• construct CapabilityRequest (including intent_ref + request_hash + evidence_refs)

Artifacts:

• canonical request (optional persistence: runtime_data/canonical/requests/<request_hash>.json)

• CapabilityRequest enters the Capability Bus

Invariants:

• request_hash must depend solely on the canonical request (no implicit external state)

• Recompiling the same request at any time must yield the same hash (hash stability)

(4) Capability Bus → Policy Gate: Single Legal Entry for Adjudication

(Institutional Judgment)

Input: CapabilityRequest (repo.release) + policy_ref (version + hash)

Actions (deterministic):

• Capability Bus: normalize entry, package context, invoke policy gate

• Policy Gate: produce a three-state judgment:

  • ALLOW: institution permits issuing an execution ticket

  • DENY: institution explicitly refuses (refusal is also history)

  • REQUIRE_OVERRIDE: escalation to higher-authority signing / override flow

Artifacts:

• DecisionRecord (append-only, and written before any side effects)

• Optional: derived DecisionTicket (only when decision == ALLOW, or if you allow non-executing tickets)

Invariants:

• Policies must be versioned (policy_version + policy_hash), or replay is invalid

• The gate must not read implicit external state (time, env vars, network) unless explicitly included as inputs

(5) Ledger Append: Write Institutional Facts First, Then Allow Side Effects

(Record-Before-Effects)

Input: adjudication result + request_hash + policy_ref + actor + evidence_refs

Actions (deterministic):

• append to runtime_data/decisions.jsonl

• if overridden: append to runtime_data/overrides.jsonl (never overwrite prior decisions)

Artifacts:

• DecisionRecord / OverrideRecord (true source for replay)

• (if ALLOW) DecisionTicket (execution projection)

Invariants:

• Without a record, execution is forbidden (no record → no side effects)

• Overrides must not rewrite old records; only append new facts (append-only governance)

(6) Ticket-Gated Execution: Authorized Execution

(Side-Effect Zone)

Input: DecisionTicket or decision_id → ticket lookup

Actions (deterministic):

• verify decision == ALLOW

• verify ticket.request_hash == recompute_hash(canonical_request)

• verify ticket.policy_ref == current_policy_ref (or record.policy_ref)

• verify ticket not revoked / not expired (optional)

• execute side effects: git tag / GitHub release / deploy (plugin-based)

Artifacts:

• execution result events (recommended separate ledger: runtime_data/executions.jsonl)

• failures must also be recorded (failure does not evaporate; it is an asset)

Invariants:

• Executors never accept raw inputs (parameter bypass equals governance bypass)

• Tickets are the sole execution authorization (ticket-gated execution)

(7) Replay / Regression: Recompute Judgments from Records

(Not Re-running the Workflow)

Input: DecisionRecord + corresponding canonical inputs + policy_ref

Actions (deterministic):

• recompute the policy decision

• compare recomputed result with the recorded decision

• produce regression reports (for institutional evolution and anti-regression)

Invariants:

• Replay targets “recomputing the judgment made at the time,” not “rerunning past side effects”

• Policy changes must imply version changes; otherwise differences cannot be explained

3.3 Two Critical “Institutional Locks”

(What Makes the Main Flow Non-Bypassable)

1. Single-Entry Lock: all repo.release adjudication requests must pass through the Capability Bus (single choke point).

2. Side-Effect Lock: all side effects must pass ticket verification (single gate).

With these two locks plus an append-only ledger, RRB truly transitions from a “bot” into an organ.

3.4 Minimal v0 Execution Strategy

(Ship Immediately Without Taking Risks)

• v0: implement Intent → DecisionRecord (no automatic tagging, no deployment)

• v0.1: issue tickets only on ALLOW + ticket-gated tagging

• v0.2: plugin-based release/deploy + execution events ledger

• At every step, replay must remain functional: stabilize the sovereign zone first, then grow features

3) 主流程（从 Intent 到历史，再到可选执行）

主流程的目标不是“把 release 做出来”，而是把一次 release 变成 制度可解释的历史条目：任何副作用之前必须先产生可重算的裁决事实；任何裁决事实必须能指回责任主体；任何执行必须被票据化、可撤销、可回放。流程里允许聪明，但聪明永远不得跨过主权区防火墙。

3.1 阶段划分：三域五步（Proposal / Sovereign / Execution）

• Proposal Zone（可用 LLM）：把 Intent 变成候选方案与候选结构（草案、解释、diff 摘要、风险点清单）

• Sovereign Zone（禁止 LLM）：确定性编译 + 制度裁决 + append-only 事实写入

• Execution Zone（禁止 LLM）：票据化执行副作用（tag/release/deploy），并把执行结果写入事件账本（可选）

3.2 端到端流程（高密度版）

(1) Intent Declared：责任声明入账（唯一合法触发）

输入：ReleaseIntent v1（human/institution）

动作（deterministic）：

• schema validate

• canonicalize（可选但推荐：intent 也 canonicalize + intent_hash）

• append-only 写入 runtime_data/release_intents.jsonl

不变量：

• 没有 intent，不得进入后续任何裁决链路（no intent → no history）

• intent 不可覆盖；撤销必须用新 intent/记录表达

(2) Proposal Build：生成候选请求（LLM only here）

输入：intent_id/intent_hash + repo 当前状态快照（只读）

动作（允许 LLM，但输出永远是“提案”）：

• 生成候选 CapabilityRequest(repo.release) 草案

• 生成“解释材料”（为什么 release、风险、回滚、变更摘要）

• 标注 origin=model、replayable=false

产物：

• proposal artifacts（可落盘到 runtime_data/proposals/*.json 或仅 stdout）

• 注意：proposal 不进 ledger、不进 policy 输入（除非被 deterministic 编译器抽取成结构字段）

不变量：

• LLM 产物只能作为候选；不得直接触发 bus / ledger / execution gate

(3) Compile & Validate：确定性编译（把提案变成可裁决请求）

输入：proposal 草案（或 human 直接给的结构）

动作（deterministic，主权区入口前的“编译器”）：

• schema validate：repo_release_request_v1.json

• canonicalize：生成 canonical request

• compute request_hash = sha256(canonical_request)

• 生成 CapabilityRequest（含 intent_ref + request_hash + evidence_refs）

产物：

• canonical request（可落盘：runtime_data/canonical/requests/<request_hash>.json）

• CapabilityRequest 进入 Capability Bus

不变量：

• request_hash 必须只依赖 canonical request（禁止隐式外部状态）

• 同 request 任何时间重编译都必须得到同 hash（hash stability）

(4) Capability Bus → Policy Gate：单一合法入口裁决（制度判断）

输入：CapabilityRequest(repo.release) + policy_ref(version+hash)

动作（deterministic）：

• Bus 负责：标准化入口、打包上下文、调用 policy gate

• Policy Gate 负责：输出三态裁决

  • ALLOW：制度允许签发执行票据

  • DENY：制度明确拒绝（拒绝也是历史）

  • REQUIRE_OVERRIDE：必须走更高权限签字/越权流程

产物：

• DecisionRecord（必须 append-only，且在任何副作用之前写入）

• 可选：派生 DecisionTicket（仅当 decision==ALLOW 或你允许签发“非执行票据”）

不变量：

• policy 必须版本化（policy_version + policy_hash）；否则 replay 不成立

• gate 禁止读取隐式外部状态（时间/环境变量/网络）除非显式纳入输入

(5) Ledger Append：先写制度事实，再允许副作用（record-before-effects）

输入：裁决结果 + request_hash + policy_ref + actor + evidence_refs

动作（deterministic）：

• append runtime_data/decisions.jsonl

• 如有 override：append runtime_data/overrides.jsonl（永不覆盖旧决策）

产物：

• DecisionRecord / OverrideRecord（replay 真源）

• （若 ALLOW）DecisionTicket（执行投影）

不变量：

• 没有 record，不得执行（no record → no side-effects）

• override 不得改写旧 record，只能追加新事实（append-only governance）

(6) Ticket-Gated Execution：票据化执行（副作用区）

输入：DecisionTicket 或 decision_id -> ticket lookup

动作（deterministic）：

• 校验：decision==ALLOW

• 校验：ticket.request_hash == recompute_hash(canonical_request)

• 校验：ticket.policy_ref == current_policy_ref（或 record.policy_ref）

• 校验：ticket 未 revoked/未过期（可选）

• 执行副作用：git tag / GitHub release / deploy（插件化）

产物：

• 执行结果事件（建议另写 event ledger：runtime_data/executions.jsonl）

• 失败也要落盘（失败不是蒸发，是资产）

不变量：

• Executor 永远不接受裸 inputs（参数绕过就是治理绕过）

• ticket 是唯一执行许可（ticket-gated execution）

(7) Replay / Regression：以 record 为真源重算裁决（不是重跑流程）

输入：DecisionRecord + 对应 canonical inputs + policy_ref

动作（deterministic）：

• 重算 policy decision

• 比对：重算结果是否与 record 一致

• 产出回归报告（用于制度演化与防回归）

不变量：

• replay 目标是“重算当年的判断”，不是“重跑当年的副作用”

• policy 变更必须导致“版本变化”，否则无法解释差异

3.3 两条关键“制度锁”（把主流程变成不可绕过）

1. 唯一入口锁：所有 repo.release 的裁决请求必须经过 Capability Bus（单点收口）。

2. 副作用锁：所有副作用必须经过 Ticket 校验（单点门禁）。

这两条锁加上 append-only ledger，RRB 才真正从“bot”变成“器官”。

3.4 最小 v0 执行策略（让你能立刻落地而不冒险）

• v0 先做到：Intent → DecisionRecord（不自动 tag，不 deploy）

• v0.1 加：ALLOW 才签发 Ticket + ticket-gated tag

• v0.2 再加：release/deploy 插件化 + execution events ledger

• 每一步都必须保持 replay 可用：主权区先稳，功能再长

(1) Intent declared  ───────────────┐
                                    ▼
(2) Orchestrator builds Proposal (optional LLM drafting allowed here only)
                                    ▼
(3) Compiler/Validator (deterministic)
    - schema validate
    - canonicalize
    - request_hash
                                    ▼
(4) MCP Capability Bus (single legal entry)
                                    ▼
(5) Policy Gate (deterministic)
    → ALLOW / DENY / REQUIRE_OVERRIDE
                                    ▼
(6) DecisionLedger.append(record)  (append-only, before side effects)
                                    ▼
(7) Execution (optional, ticket-gated)
    - only if decision==ALLOW
    - tag/release/deploy plugins optional
                                    ▼
(8) Replay/Regression
    - same canonical inputs + same policy_version => same decision

Triggering Mechanism(触发机制)

4) Triggering Mechanism

The triggering mechanism is RRB’s sovereign gate. It does not answer the question “when should a workflow run,” but a far more fundamental one:

Who has the authority to advance system history, and in what form responsibility is borne.

Therefore, triggering is not a technical event—it is an institutional statement.

4.1 The Only Legitimate Trigger: ReleaseIntent

Restated definition:

A ReleaseIntent is a Responsibility Declaration.

Its meaning is not “the system should release,” but:

“An accountable subject explicitly requests the system to perform a release, and is willing to bear responsibility for that decision in the future.”

Only once this semantic condition is satisfied does RRB allow the governance process to begin; otherwise, the system must remain still.

Core principles:

• Trigger ≠ Event

• Trigger = Intent

• Intent = accountable subject + explicit intention + risk acceptance

4.2 Legitimate Trigger Entry Points (v0: Most Stable)

✅ CLI: rrb intent create ... (Human Explicit)

This is the only recommended trigger implementation in v0.

Why CLI is the most stable starting point:

• Clear human-in-the-loop presence

• Cannot happen “silently”

• Easy to record actor.id / actor.kind

• Naturally trains users into a mindset of declaring responsibility

Institutional meaning:

• Every release is an explicit act

• There is no gray zone where “the system decided to release by itself”

CLI is chosen not for technical convenience, but because it forces slowness at both the psychological and institutional levels.

🔜 Extensible Entry Points (Semantics Must Be Equivalent)

These entry points are not new trigger types, but merely different input adapters for ReleaseIntent.

PR Comment: /release

Must satisfy:

• comment author = human / institution

• comment → compiled into ReleaseIntent v1

• the comment itself is not the trigger — the Intent is the trigger

All comment-based triggers must ultimately:

• be written to release_intents.jsonl

• enter the same main governance flow

UI Button (Approval Desk / Console)

• Essentially a “visual CLI”

• UI actions must generate structured Intent

• UI must not bypass:

  • intent schema

  • append-only writing

  • actor recording

Unified invariant:

Regardless of entry form, the system ultimately sees only ReleaseIntent.

4.3 Explicitly Forbidden Triggers (Red Lines)

These prohibitions are not “temporarily unsupported features,” but structural sources of danger.

🚫 Automatic Release on Merge

Why this is dangerous:

• A merge is a collaboration event, not a responsibility declaration

• merge author ≠ release responsibility holder

• It easily leads to:

  • “I just merged the code—who knew the system would release it?”

The only exception (strict conditions):

• The merge rule itself is institutionalized

• The merge action explicitly generates Institutional Intent

• That rule is:

  • versioned

  • auditable

  • replayable

Otherwise, it is strictly forbidden.

🚫 Automatic Trigger on CI Green

The fundamental issue:

• CI answers “can it run?”

• Release answers “should it happen?”

Treating CI green as a trigger is equivalent to saying:

“As long as nothing breaks, the system may advance history on its own.”

This is precisely the condition you are trying to avoid:

a system advancing its own history with no declaration and no responsible party.

CI results may only serve as:

• evidence

• one of the policy inputs

They must never be triggers.

🚫 Agent-Automated Triggering

This is the most critical red line.

The reason is not “models aren’t good enough yet,” but structural:

• agents ≠ responsible subjects

• agent objective functions ≠ institutional responsibility

• agents cannot be held accountable ten years later

No matter how intelligent agents become in the future, they may only:

• propose options

• generate proposals

• annotate risks

They must never declare Intent.

Once agents are allowed to trigger Intent, the system loses:

• its human responsibility anchor

• institutional legitimacy

• long-term explainability

4.4 A Critical Structural Judgment (Unique to This System)

Your trigger design operationalizes a rare but crucial principle in engineering:

History is not advanced by “conditions being satisfied,” but by responsibility being declared.

This means:

• Release is no longer a natural outcome of CI/CD

• It is an institutional act

• The system upgrades from an “automation tool” to a responsibility-executing entity

4.5 One-Sentence Summary (Constitution-Ready)

RRB responds only to Intent, not to events.

Without a responsibility declaration, the system would rather do nothing.

This guarantees that every advance of history has someone who can step forward in the future and say: this was my decision at the time.

4) 触发机制（Triggering）

触发机制是 RRB 的主权闸门。它解决的不是“什么时候跑流程”，而是一个更根本的问题：

谁有权让系统推进历史，并以什么形式承担责任。

因此，触发不是技术事件，而是制度语句。

4.1 唯一合法触发：ReleaseIntent

定义重申：

ReleaseIntent 是一次责任声明（Responsibility Declaration）。

它的语义不是“系统应该发布”，而是：

“某个可追责主体，明确要求系统执行一次 release，并愿意在未来为该决定负责。”

这条语义一旦成立，RRB 才允许进入治理流程；否则，系统必须保持静止。

核心原则：

• Trigger ≠ Event

• Trigger = Intent

• Intent = 可追责主体 + 明确意图 + 风险承担

4.2 合法触发入口（v0：最稳态）

✅ CLI：rrb intent create ...（Human Explicit）

这是 v0 阶段唯一推荐实现的触发方式。

为什么 CLI 是最稳的起点：

• 明确的人类在场（human-in-the-loop）

• 不可“悄悄发生”

• 易于记录 actor.id / actor.kind

• 易于训练使用者形成“声明责任”的心智模型

制度意义：

• 每一次 release 都是一次显式行为

• 不存在“系统自己决定发布了”的灰区

CLI 并不是因为技术方便，而是因为它在心理与制度层面都强制慢下来。

🔜 可扩展入口（但语义必须等价）

这些入口不是新的触发类型，只是 ReleaseIntent 的不同“输入适配器”。

PR Comment：/release

• 必须满足：

  • comment author = human / institution

  • comment → 编译成 ReleaseIntent v1

  • comment 本身不是触发，Intent 才是触发

• 所有 comment 触发，最终都要：

  • 写入 release_intents.jsonl

  • 进入同一主流程

UI Button（审批台 / 控制台）

• 本质是一个“可视化 CLI”

• UI 行为必须生成结构化 Intent

• UI 不得绕过：

  • intent schema

  • append-only 写入

  • actor 记录

统一不变量：

无论入口形态如何，最终系统只“看到” ReleaseIntent。

4.3 明确禁止的触发方式（红线）

这些禁止项不是“暂时不支持”，而是结构性危险源。

🚫 merge 自动触发 release

为什么危险：

• merge 是协作事件，不是责任声明

• merge author ≠ release responsibility holder

• 极易导致：

  • “我只是合了代码，谁知道系统就发布了”

唯一例外（严格条件）：

• merge 规则本身被制度化

• merge 动作明确生成 Institutional Intent

• 该规则：

  • 版本化

  • 可审计

  • 可 replay

否则，一律禁止。

🚫 CI green 自动触发

根本问题：

• CI 是“证明能不能跑”

• Release 是“判断应不应该发生”

把 CI green 当触发条件，本质是在说：

“只要没出错，系统就可以自行推进历史”

这正是你要避免的那种：

系统在无人声明、无人承担责任的情况下自我推进历史

CI 结果只能作为：

• evidence

• policy 输入之一

  永远不能作为 trigger。

🚫 agent 自动触发

这是最关键的一条红线。

原因不是“现在模型不够好”，而是结构性原因：

• agent ≠ 责任主体

• agent 的目标函数 ≠ 制度责任

• agent 无法在十年后被追责

即使未来 agent 再聪明，也只能：

• 提出建议

• 生成 proposal

• 标注风险

但它永远不能声明 Intent。

一旦允许 agent 触发 Intent，系统就失去了：

• 人类责任锚点

• 制度合法性

• 长期可解释性

4.4 一个重要的结构判断（你这个系统特有）

你这里的 Trigger 设计，实际上在工程上落地了一个非常罕见但极其关键的判断：

历史不是被“条件满足”推动的，而是被“责任声明”推动的。

这意味着：

• Release 不再是 CI/CD 的自然结果

• 而是一次制度行为

• 系统从“自动化工具”升级为“责任执行体”

4.5 一句话总结（可以直接放进 Constitution）

RRB 只响应 Intent，不响应事件。

没有责任声明，系统宁可什么都不做。

这是为了保证：每一次历史推进，都有人能在未来站出来说——这是我当时的决定。

Executor (执行器)

5) Executor Design Principles

The Executor is the most dangerous—and therefore the most in need of domestication—component in the entire RRB architecture.

Once it oversteps its authority, it can change the world with no institutional trace whatsoever.

Therefore, the Executor is not “code that gets things done,” but a side-effect channel fully domesticated by institutions.

5.1 The Executor’s Identity: A Side-Effect Port, Not a Decision-Maker

Definition:

The Executor has exactly one responsibility: to perform side effects (tag / release / deploy / publish) if and only if they are explicitly authorized by institutional judgment.

It does not understand Intent.

It does not understand Policy.

It does not judge whether something is “reasonable.”

It answers only one question:

“Is this ticket sufficient for me to execute?”

If the answer is not a definitive YES, it must refuse.

5.2 Function Signature Red Line: No Raw Inputs

This is the single most critical engineering red line in Executor design.

Forbidden function shapes (any one of these constitutes governance bypass):

def execute_release(tag: str): ...
def deploy(version: str, env: str): ...
def run(cmd: str): ...

These interfaces conflate whether execution is allowed with how execution is performed,

implicitly trusting the caller and eliminating institutional constraints at the engineering level.

The only allowed function signatures:

def execute(decision_id: str): ...
# or
def execute_with_ticket(ticket: DecisionTicket): ...

The Executor may accept only:

• a decision_id (which it then uses to look up the ledger / ticket itself), or

• a complete DecisionTicket

Institutional meaning:

• The Executor never knows “who provided the business parameters”

• It knows only this: I am executing side effects on behalf of an institutional fact

5.3 Mandatory Pre-Execution Validation Chain

(Gate Before Effects)

Before any side effect occurs, the Executor must complete a full, non-skippable validation chain.

This chain must be a hard failure chain (any failure raises immediately and terminates execution).

(1) Decision Must Be ALLOW

ticket.decision == ALLOW

• DENY and REQUIRE_OVERRIDE are explicitly forbidden execution states

• An override does not “modify the decision”; it produces a new ALLOW ticket

(2) request_hash Must Match

ticket.request_hash == sha256(canonical_request)

• Prevents “execution object substitution”

• Prevents “using ticket A to execute side effects for B”

• request_hash is the cryptographic anchor between execution and institutional judgment

(3) policy_version (+ hash) Must Match

ticket.policy_ref == decision_record.policy_ref

or (more strictly):

ticket.policy_ref == current_policy_ref

Meaning:

• Ensures execution occurs under the same institutional context

• Prevents “allowed under old policy, secretly executed under new policy”

(4) Ticket Not Revoked / Not Expired

(Optional but strongly recommended)

ticket.revoked == false
now < ticket.expires_at

Purpose:

• Supports emergency human intervention

• Supports execution time windows (e.g. “must execute within 24 hours”)

• Converts execution authority from “forever valid” into a controlled resource

5.4 Failure Semantics: Better to Do Nothing Than to Do Too Much

The Executor’s failure philosophy must be:

“Refusing to execute is a successful failure; unauthorized execution is a catastrophe.”

Therefore:

• Validation failure must:

  • produce no side effects

  • raise a clear error

  • optionally append an execution-denied event (append-only)

• The Executor must never attempt self-recovery

  (e.g. “retry automatically with different parameters”)

5.5 Temporal Discipline Between Execution and Recording

The Executor must never be the first component to write history.

Correct order:

1. Policy Gate adjudication

2. DecisionRecord append (institutional fact)

3. DecisionTicket issuance

4. Executor ticket validation

5. Side effects occur

6. Execution Event recorded (append-only)

Forbidden order:

• Execute first, write records later

• Execute and record nothing on failure

• Treat execution logs as “historical facts”

5.6 The Executor Must Be the “Dumbest” Component

This is counter-intuitive, but absolutely essential:

The dumber the Executor, the safer the system.

The Executor must not:

• understand business semantics

• dynamically construct commands

• decide execution paths

• “guess” parameters from the environment

It should only:

• validate tickets

• invoke explicitly declared side-effect plugins

• record results

5.7 A Constitution-Ready Summary Sentence

The Executor is not a “program that executes,” but a port authorized by institutions.

All of its power comes from a ticket; without a ticket, it can do nothing.

5.8 Minimal Engineering Principles for Immediate Implementation (v0)

If you start coding right now, remember just these three rules:

1. Function signatures accept only ticket or decision_id

2. All validation happens before any side effect

3. Better to reject 100 legitimate executions than to allow 1 unauthorized execution

5) 执行器（Executor）设计要点

Executor 是整套 RRB 架构里“最危险、也最必须被驯化”的部件。

它一旦越权，就能在毫无制度痕迹的情况下改变世界。

因此，Executor 不是“会干活的代码”，而是被制度完全驯服的副作用通道。

5.1 Executor 的身份：副作用端口，不是决策者

定义：

Executor 的唯一职责是：在且仅在制度明确授权的前提下，执行副作用（tag / release / deploy / publish）。

它不理解 Intent，不理解 Policy，也不判断“合不合理”。

它只回答一个问题：

“这张票据，是否足以让我执行？”

如果答案不是确定的 YES，它必须拒绝。

5.2 函数签名红线：不接受裸 inputs（No Raw Inputs）

这是 Executor 设计中最关键的一条工程红线。

禁止的函数形态（任何一种都意味着治理绕过）：

def execute_release(tag: str): ...
def deploy(version: str, env: str): ...
def run(cmd: str): ...

这些接口把“能不能执行”与“怎么执行”混在一起，

等于默认信任调用方，在工程层面取消了制度约束。

唯一允许的函数签名形态：

def execute(decision_id: str): ...
# or
def execute_with_ticket(ticket: DecisionTicket): ...

Executor 只接受：

• decision_id（再由它自己去查 ledger / ticket）

• 或完整的 DecisionTicket

制度含义：

• 执行器永远不知道“业务参数是谁给的”

• 它只知道：我是在为一条制度事实执行副作用

5.3 执行前的强制校验链（Gate Before Effects）

在任何副作用发生之前，Executor 必须完成一整套不可跳过的验证链。

这条链必须是 hard failure（不满足就抛异常、立即终止）。

(1) Decision 必须是 ALLOW

ticket.decision == ALLOW

• DENY 与 REQUIRE_OVERRIDE 都是明确禁止执行的状态

• override 不是“修改 decision”，而是产生一张新的 ALLOW 票据

(2) request_hash 必须匹配

ticket.request_hash == sha256(canonical_request)

• 防止“偷换执行对象”

• 防止“用 A 的票据，执行 B 的副作用”

• request_hash 是执行与制度判断之间的密码学锚点

(3) policy_version (+ hash) 必须匹配

ticket.policy_ref == decision_record.policy_ref

或（更严格）：

ticket.policy_ref == current_policy_ref

意义：

• 确保执行发生在同一制度语境下

• 防止“旧制度下允许，新制度下偷偷执行”

(4) Ticket 未撤销 / 未过期（可选但强烈建议）

ticket.revoked == false
now < ticket.expires_at

用途：

• 支持人工紧急止血

• 支持时间窗执行（比如“只允许 24h 内执行”）

• 把执行权从“永远有效”变成“受控资源”

5.4 失败策略：宁可不做，也不能多做

Executor 的失败语义必须是：

“拒绝执行是成功的失败；越权执行是灾难。”

因此：

• 校验失败必须：

  • 不产生任何副作用

  • 产生明确错误

  • 可选：写入 execution-denied 事件（append-only）

• Executor 不得尝试补救（比如“自动 retry 用别的参数”）

5.5 执行与记录的时序纪律

Executor 永远不是第一个写入历史的组件。

正确顺序：

1. Policy Gate 裁决

2. DecisionRecord append（制度事实）

3. DecisionTicket 签发

4. Executor 校验 ticket

5. 副作用发生

6. Execution Event 记录（append-only）

错误顺序（禁止）：

• 先执行，再补写记录

• 执行失败就什么都不记

• 把执行日志当成“历史事实”

5.6 Executor 必须是“最笨”的组件

这是一个反直觉但极其重要的设计目标：

Executor 越笨，系统越安全。

它不应该：

• 理解业务语义

• 动态构造命令

• 决定执行路径

• 从环境中“猜”参数

它只应该：

• 校验票据

• 调用明确声明过副作用的插件

• 把结果记下来

5.7 一个可以写进宪法的总结句

Executor 不是一个“会执行的程序”，而是一个“被制度许可的端口”。

它的所有能力，都来自于一张票据；没有票据，它什么都做不了。

5.8 给你一个工程落地的最小原则（v0）

如果你现在要立刻写代码，记住这三条就够：

1. 函数签名只收 ticket / decision_id

2. 所有校验失败都在副作用前

3. 宁可拒绝 100 次合法执行，也不能放过 1 次越权执行

LLM 边界（Model-to-Executable Firewall）

1) LLM Boundary (Model-to-Executable Firewall)

This section defines RRB’s civilizational firewall.

It is not about limiting model capability, but about fully isolating uncertainty from historical sovereignty.

In one sentence: LLMs may participate in thinking, but must never directly touch history or execution.

1.1 The Core Purpose of the Firewall: Confining “Uncertainty” to a Controllable Zone

The essential characteristics of LLMs are not that they are “not smart,” but that they are:

• Non-deterministic (the same input does not guarantee the same output)

• Not fully replayable (model versions, context, and vendor state drift over time)

• Opaque internal state (not auditable)

These properties are assets in the cognitive / proposal phase,

but once they enter institutional judgment, historical writing, or execution authorization, they become systemic risks.

Therefore, RRB must establish a hard firewall:

LLM outputs may influence how humans think, but must never directly influence how the system acts.

1.2 The Only Legitimate Habitat for LLMs: The Proposal Zone

The role of the Proposal Zone:

It is a cognitive augmentation zone, not an institutional zone.

Here, LLMs may—and are well suited to—do the following:

• Draft candidate CapabilityRequests

• Summarize diffs and change impact

• Generate risk checklists

• Propose rollback strategies

• Explain to humans “what might happen if this is released”

But the legal status of all their outputs is exactly one thing:

Proposal

—not:

• Judgment

• Fact

• Authorization

• Instruction

1.3 Explicitly Forbidden Zones (Sovereign Red Lines)

LLM outputs are always, unconditionally, and without exception forbidden from entering the following areas:

🚫 Policy (Institutional Judgment)

• The Policy Gate must be a fully deterministic function

• Same canonical input + same policy_version → same decision

• Once LLMs participate in policy:

  • replay fails immediately

  • decisions become irreproducible

  • institutions lose credibility

🚫 Scheduler (Temporal and Execution Scheduling)

• The Scheduler determines when something may happen

• This is temporal control over real-world side effects

• Any LLM-based scheduling introduces:

  • implicit state

  • inexplicable delays or accelerations

  • causality errors that are hard to reconstruct

🚫 Ledger (Historical Fact Writing)

• The Ledger is institutional memory

• It is not a log, but “the set of responsibilities the system has taken on over time”

• LLMs must not:

  • write

  • modify

  • synthesize

  • summarize and then write (summaries are also forbidden)

🚫 Canonical Memory (Replay Source of Truth)

• Canonical Memory is the input anchor for replay

• It must satisfy:

  same input → same output

• LLM outputs inherently fail this property, and therefore may only serve as “reference,” never as “truth”

🚫 Execution Gate (Execution Authorization)

• Execution authorization is the key to changing the world

• If LLM outputs can directly affect the execution gate, it implies:

  • agents autonomously advancing history

  • no human responsibility anchor

  • systems that cannot be governed long-term

1.4 Mandatory Metadata: origin and replayable

To turn “boundaries” from philosophical agreements into engineering facts,

RRB requires that all data objects entering the system explicitly declare their origin and replayability.

origin

Answers the question: “Who produced this?”

Recommended enum values:

• human

• institution

• model

• system

Rules:

• Objects with origin=model are automatically downgraded to Proposals

• Objects with origin=model must not be read by policy / ledger / executor

replayable

Answers the question: “Can this be recomputed ten years later?”

Recommended semantics:

• replayable=true

  → may serve as replay source of truth (canonical inputs / policy / records)

• replayable=false

  → may only serve as explanation, annotation, reference, or proposal

Critical red lines:

• All objects entering DecisionRecord / Canonical Memory / Ticket validation chains must be replayable=true

• LLM outputs default to replayable=false, unless explicitly extracted and reconstructed into structured fields by a deterministic compiler

1.5 The Firewall Is Not Distrust of Models, but Distrust of Historical Contamination

This point is often misunderstood and must be made explicit:

The Model-to-Executable Firewall is not about “LLMs being untrustworthy,” but about history needing to be more trustworthy than models.

You allow models to:

• help you think

• help you explain

• help you propose

But you do not allow models to:

• bear responsibility on your behalf

• write history for you

• decide execution for you

1.6 A Constitution-Ready Definition Sentence

LLMs are cognitive collaborators, not institutional subjects.

They may participate in forming judgments, but must never become the judgments themselves.

1.7 Minimal Engineering Checklist (v0)

If you start coding now and enforce just these four points, you will already outperform 99% of systems:

1. All LLM outputs must carry origin=model

2. All origin=model objects default to replayable=false

3. Policy / Ledger / Executor layers must not read origin=model data

4. Only deterministic compilers may transform proposals into canonical inputs

1) LLM 边界（Model-to-Executable Firewall）

这一节定义的是 RRB 的“文明防火墙”。

它不是在限制模型能力，而是在把不确定性与历史主权彻底隔离。

一句话：LLM 可以参与思考，但永远不能直接触碰历史与执行。

1.1 防火墙的核心目的：把“不确定性”关在可控区

LLM 的本质特征不是“不聪明”，而是：

• 非确定性（同输入未必同输出）

• 不可完全重放（模型版本、上下文、供应商状态都会漂移）

• 不可审计的内部状态

这些特征在 认知/提案阶段是资产，

但一旦进入 制度判断、历史写入或执行许可，就会变成系统性风险。

因此，RRB 必须建立一条硬防火墙：

LLM 的输出只能影响“人类如何思考”，不能直接影响“系统如何行动”。

1.2 LLM 的唯一合法生存区：Proposal Zone

Proposal Zone 的角色：

是“认知增强区”，不是“制度区”。

在这里，LLM 可以做、而且非常适合做以下事情：

• 起草候选 CapabilityRequest

• 总结 diff / 变更影响

• 生成风险点清单

• 提供回滚建议

• 给人类解释“如果发布，可能发生什么”

但它所有产物的法律地位只有一个：

Proposal（提案）

而不是：

• 判断

• 事实

• 授权

• 指令

1.3 明确禁止进入的区域（主权红线）

LLM 输出 永远、无条件、不可例外地 禁止进入以下区域：

🚫 Policy（制度判断）

• Policy Gate 必须是 完全确定性函数

• 同 canonical input + 同 policy_version → 必须同 decision

• LLM 一旦参与 policy：

  • replay 立即失效

  • 决策不可复现

  • 制度不再可信

🚫 Scheduler（时序与执行调度）

• Scheduler 决定“什么时候能发生”

• 这是 现实世界副作用的时间控制权

• 任何基于 LLM 的调度都会引入：

  • 隐式状态

  • 不可解释的延迟/提前

  • 难以回溯的因果错误

🚫 Ledger（历史事实写入）

• Ledger 是 制度记忆

• 它不是日志，而是“系统在时间中承担过的责任集合”

• LLM 不得：

  • 写入

  • 修改

  • 合成

  • 总结后再写入（summary 也是禁止的）

🚫 Canonical Memory（重放真源）

• Canonical Memory 是 replay 的输入锚点

• 必须满足：

  同输入 → 同输出

• LLM 输出天生不满足这一性质，因此只能作为“参考”，不能作为“真源”

🚫 Execution Gate（执行许可）

• 执行许可是“世界改变的钥匙”

• 一旦 LLM 输出能直接影响执行门禁，就等于：

  • agent 自主推进历史

  • 无人类责任锚点

  • 系统不可长期治理

1.4 强制元数据标记：origin 与 replayable

为了把“边界”从哲学约定变成工程事实，

RRB 要求所有进入系统的数据对象，必须显式声明来源与可重放性。

origin

用于回答：“这是谁产生的？”

推荐枚举：

• human

• institution

• model

• system

规则：

• origin=model 的对象 自动降级为 Proposal

• origin=model 的对象 不得被 policy / ledger / executor 读取

replayable

用于回答：“十年后还能不能重算？”

推荐语义：

• replayable=true

  → 可作为 replay 真源（canonical input / policy / record）

• replayable=false

  → 只能作为解释、注释、参考、提案

关键红线：

• 所有进入 DecisionRecord / Canonical Memory / Ticket 校验链 的对象，必须是 replayable=true

• LLM 产物默认 replayable=false，除非被 deterministic compiler 明确抽取、重建为结构化字段

1.5 “防火墙”不是不信任模型，而是不信任历史污染

这是一个容易被误解的点，必须说清楚：

Model-to-Executable Firewall 并不是“LLM 不可信”，而是“历史必须比模型更可信”。

你允许：

• 模型帮你想

• 模型帮你解释

• 模型帮你提案

但你不允许：

• 模型替你承担责任

• 模型替你写历史

• 模型替你决定执行

1.6 一个可以直接写进宪法的定义句

LLM 是认知协作者，而不是制度主体。

它可以参与形成判断，但永远不能成为判断本身。

1.7 工程落地的最小检查表（v0）

如果你现在要开始写代码，只要强制这四点，就已经赢过 99% 系统：

1. 所有 LLM 输出对象必须带 origin=model

2. 所有 origin=model 对象默认 replayable=false

3. Policy / Ledger / Executor 层禁止读取 origin=model 数据

4. 只有 deterministic compiler 才能把 proposal → canonical input

2) Intent Is Not an Event (Intent ≠ Event)

This section defines the most important semantic assertion in RRB.

If you were allowed to lock in only one sentence across the entire system, it would be this:

“Events describe the world; Intent changes the world.”

2.1 The Ontological Difference Between Event and Intent

(They Are Not the Same Kind of Thing)

Event and Intent belong to two fundamentally different semantic categories:

Core conclusion:

Events may be recorded, referenced, and evaluated;

but only Intent is qualified to move the system into a new historical state.

2.2 Why Events Must Not Advance History

If a system allows Events to advance history, three irreparable problems immediately emerge:

(1) Responsibility Evaporation

When merges, CI green signals, or cron schedules directly trigger releases:

• The system can explain what happened

• But it cannot explain who decided it should happen

Ten years later, during an audit, all you see is a chain like:

test passed → release happened

But you cannot answer:

Who, at the time, took responsibility for judging that releasing was appropriate?

(2) Unconscious History Advancement

Event-driven systems have a dangerous property:

As long as conditions are met, history moves forward by itself.

This means:

• No human needs to be present

• No explicit declaration is required

• No responsibility anchor exists

This is exactly the state you have repeatedly emphasized must be avoided:

the system unconsciously advancing its own history.

(3) Replay and Audit Collapse

Events often depend on:

• current time

• current environment

• current network state

All of these are implicit states that cannot be replayed.

Once Events become triggers:

• replay can only describe what happened back then

• but cannot recompute why it happened that way

This destroys the foundation of the entire replay / regression system.

2.3 The Necessary Components of Intent: Declaring a Responsible Subject

A legitimate Intent must answer at least four questions:

1. Who is requesting the system to advance history? (actor)

2. What is being requested? (scope / capability)

3. Why now? (reason)

4. Who bears the consequences if things go wrong? (risk acceptance / rollback)

Therefore, Intent can only originate from:

• human

• institution

Because only these subjects:

• can be named

• can be held accountable

• can explain their judgment in the future

2.4 The Role of Agents: Proposal Only, Never Intent

This red line is easily challenged by technical intuition—but it must be fixed firmly.

What agents may do:

• observe events

• analyze risk

• generate suggestions

• draft proposals

• alert humans that “this may be a release window”

What agents must never do:

• declare Intent

• trigger historical advancement

• assume institutional responsibility on behalf of humans

The reason is not that agents are “not smart enough,” but that:

Agents have no institutional identity.

They cannot be held accountable ten years later:

• “Why did you think releasing was appropriate at the time?”

• “What risk assessment did you base that on?”

• “If the consequences were severe, who would take responsibility?”

2.5 A Critical but Subtle Point

What your system is actually doing is a civilizational-level engineering move:

It completely separates “what happened” from “what should happen.”

Most automation systems conflate these two:

• once conditions are satisfied,

• they automatically assume the system should advance state

RRB’s strict Intent/Event separation is a deliberate engineering refusal of that shortcut.

2.6 Hard Engineering Constraints (Not Verbal Agreements)

To ensure that Intent ≠ Event is more than rhetoric, the following hard constraints must exist:

• All trigger APIs may accept only Intent schemas

• Event streams (CI, GitHub webhooks, cron):

  • may write evidence only

  • must never call the Capability Bus

• The Capability Bus must reject:

  • actor.kind == agent

  • origin == model

2.7 A Constitution-Ready Summary Sentence

Events tell us what happened in the world; Intent decides whether we allow the world to change.

RRB recognizes only the latter.

2) Intent 不是事件（Intent ≠ Event）

这一节定义的是 RRB 最重要的语义断言。

如果只允许你在整个系统里钉死一句话，那就是这一句：

“事件描述世界，Intent 改变世界。”

2.1 Event 与 Intent 的本体差异（不是同一类东西）

Event（事件） 与 Intent（意图） 在语义上属于两个完全不同的范畴：