程序员需要有自己的外置库，否则无法保持自己的决策延续性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# RISK RESOLUTION — Isolation / Traceability / “Telemetry Never Becomes Truth” for an Online-Only Web App
## 0) Conclusion (One Sentence)
**Define “child learning history” as an append-only Event Ledger routed by child scope; define “memory/progress” as Derivation Views that can be reconstructed from the Ledger; define “telemetry/logs” as Ephemeral Telemetry that is discarded by default. The three must be strictly isolated, and any promotion across boundaries must be explicit, auditable, and replayable.**

## 1) Scope as a First-Class Citizen: Hard Boundary for Per-Child Isolation
### 1.1 Scope Key (Required on Every Write)
Every write operation (whether an event, asset, derived view, or uploaded file metadata) must include:
* `project_id`
* `child_id`
* `session_id`
* `actor` (`child` / `parent_admin` / `system`)
* `device_id` (optional but recommended)
* `request_id` (for idempotency)
> **Rule: Any write missing a scope key must be rejected** (HTTP 400/403). There is **no such thing as a “default child.”**

### 1.2 Storage Routing
Disk layout and indexing must follow a unified routing rule:
* **Physical path**:
`/data/{project_id}/{child_id}/...`
* **Logical index**:
`(project_id, child_id, kind, ts, event_id)`
Shared write locations are **forbidden**.
For example:
* `/data/shared` may only contain a **public content library**
* All assets in `/data/shared` must be **read-only imports created by parent/admin**
This directly implements the rule:
**All writes must be scope-routed by `(project_id, child_id, session_id)`.**

## 2) Append-Only Event Ledger: The Only Source of Truth
### 2.1 Status of the Ledger
* **Ledger = Canonical History (single source of truth)**
Anything like:
* progress
* statistics
* mastery levels
* next-question recommendations
**must never be written as ground truth.**
They must exist only as **derived views** (see Section 3).

### 2.2 Minimum Event Schema (Recommended)
Every learning / interaction / scoring / correction event must include:
* `event_id`
(content hash or UUID — content-hash preferred for replayability)
* `ts`
(event timestamp)
* `scope`
(`project_id`, `child_id`, `session_id`)
* `actor`
(who triggered the event)
* `event_type`
(finite enum such as
`attempt`, `answer`, `hint`, `reward`, `content_view`, `parent_override`)
* `payload`
(event content)
* `prev_event_ref` *(optional)*
chain reference for stronger replay / tamper-evidence
* `schema_version`

### 2.3 Idempotency: Duplicate Submission is the Default State
You explicitly defined the system as:
**online-only**, where network failure, retries, and partial writes are normal.
Therefore:
* the client **must attach `request_id`** to every submission
* the server deduplicates by `(child_id, request_id)`
* duplicate events are allowed to arrive multiple times but **must only be recorded once**
And importantly:
**The client must never advance local progress based on “whether a response was received.”**
This corresponds directly to your law about **implicit state advancement control failure**.

## 3) Derivation Views: Progress and Memory are Reconstructable Artifacts
### 3.1 Core Definitions
* `raw_event`
append-only factual record
* `derived_view`
a state snapshot computed from raw events via a deterministic reducer
* `memory`
a **version-frozen artifact produced through explicit promotion**, written into the `law/objects` or vault layer
Memory must **never emerge automatically from raw events.**

### 3.2 Reducers Must Be Auditable Functions
Every reducer must include:
* `reducer_id`
* `reducer_version`
Every derived view must record:
* `input_range`
(which events were used)
* `reducer_id@version`
* `output_hash`
Reducers may be upgraded and views rebuilt, but:
**the results must remain diffable and auditable.**
This enables exactly what you want:
**replayable history + rebuildable derived views.**

## 4) Telemetry Hygiene: Telemetry is Untrusted and Disposable
### 4.1 Three Hard Rules
Directly implementing your principle:
**“Telemetry must never become truth by accident.”**
1. **Telemetry is ephemeral**
Short TTL only (e.g., 7 days) for debugging and operations.
2. **Telemetry never participates in derivations**
Reducers read only from the ledger.
3. **Cross-boundary promotion must be explicit**
If telemetry is promoted to evidence or knowledge, it must pass through a manual action:
`PromoteTelemetryToEvidence`
producing an auditable artifact with justification and signature.

### 4.2 Git / Repository Hygiene
Consistent with your laws:
* `_system` may write automatically
* **runtime outputs must never be committed**
Writes to:
* `sovereign_log/`
* `law/objects`
must always be **human-triggered or explicitly approved promotion events**.

## 5) Authorization: Hard Capability Separation Between Child and Parent
### 5.1 Two Capability Domains
**Child Runtime**
Allowed:
* read kid content
* write own ledger events
* read own derived views
Forbidden:
* import content
* modify rules
* query other children
* export data
* promote memory

**Parent/Admin**
Allowed:
* import content libraries
* configure rules
* view audits
* export data
* perform explicit promotion
* system maintenance

### 5.2 Minimal Session Implementation
Under the constraints:
* **local network only**
* **no external internet access**
A minimal system is sufficient:
* iPad child mode → short-lived session token bound to `child_id`
* parent/admin interface → separate authentication (Mac mini local access)
**A token must never carry both child and admin capabilities.**
This prevents **capability bleed**.

## 6) Mac mini Control Plane: Engineering Commitments
Your Risk Resolution (CASE-11AF425603) assumes:
* Mac mini is always running
* no external remote access
* Wi-Fi first, wired if needed
* scheduled backups and maintenance
Engineering commitments therefore include:
**Single-node first**
* one Mac mini acts as both **app server and canonical store**
**Backup is policy, not optional**
At minimum:
* daily incremental backup of ledger + assets + configs
* weekly full snapshot (external disk / second mini / NAS)
**Maintenance windows are explicit**
Updates and migrations must be logged in an **operations log** to prevent silent drift.

## 7) Minimal Implementation Checklist
Before writing application code, the following **seven structural rules must exist first**:
1. **Define ScopeKey enforcement**
`(project_id, child_id, session_id, actor, request_id)` required on writes.
2. **Define Ledger Event Schema v1**
finite `event_type`, append-only, idempotent.
3. **Implement Idempotency**
dedup index on `(child_id, request_id)`.
4. **Implement Reducers**
ledger → progress view with reducer version tracking.
5. **Implement Telemetry TTL**
logs stored separately with automatic expiration.
6. **Implement Promotion Gate**
runtime → durable knowledge must pass explicit promotion.
7. **Implement Capability Separation**
child tokens and admin tokens must be strictly isolated.

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

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

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

第一，必须用 LLM。

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

第二，必须落到 schema。

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

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

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

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

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

=== QUESTIONS ===
[P0] Q-1: Are you open to using wired Ethernet connectivity if Wi-Fi proves unreliable for continuous operation?
Answer (empty to skip): Let's try hard to make Wi-Fi work first.
[P1] Q-2: Do you have existing backup solutions or preferences for backing up the Mac mini and its data?
Answer (empty to skip): No existing solutions but openned for options.
Continue to next round? [Y/n]: n
[skip] user stopped; partial artifacts preserved.
[confirm] Case type requires human confirmation.
Primary: Risk Resolution
Secondary candidates: Architecture Decision, Exception Handling, Intent Clarification
Confirm case type (enter to keep pending): Risk Resolution
/Users/sovereign_knowledge_lab/_system/calls/intention_compiler/20260305T145405Z__64411957/FINAL/intention_for_composer.json

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

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

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

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

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

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

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

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

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

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

要让程序员真正摆脱“项目重开地狱”，关键不是让模型替你多写一点代码，而是建立一种能够把新项目快速压缩进既有规则体系的结构化内核：当你面对任何一个新项目时，不需要再从空白文档、空白仓库、空白脑袋开始，也不需要重新经历一遍需求拆解、边界争论、字段命名、关系定义、架构摇摆这些高熵折磨；你只需要给出少量高质量输入，比如意图、约束、目标用户、运行环境、风险边界、核心对象，系统就应该能够立刻生成一套可进入建造阶段的初始结构，包括架构分层、模块边界、权限边界、数据流、对象模型、字段定义、对象关系、约束规则、日志策略、审计路径，甚至连哪些东西必须 append-only、哪些字段必须具备稳定 id、哪些关系必须显式声明、哪些模块绝不能跨边界读写，都应该先于编码被直接展开。这样一来，新项目就不再是“从零开始的一次性创作”，而是一次“将新意图映射到既有结构宇宙中的定位与实例化”；程序员不再需要每次重造轮子，而是把系统已有的判断力、边界感、对象语言、字段纪律和关系协议直接调用出来，把过去沉淀下来的架构经验转化为可以即时展开的生成能力。真正有价值的，不是让 AI 帮你写十个函数，而是让它根据简单意图和约束，直接产出一个可以落地的建造骨架：这个系统分几层，哪些对象是第一等公民，哪些字段是身份锚点，哪些关系允许存在，哪些事件要入 ledger，哪些状态只能派生不能直写，哪些模块之间只能通过显式接口通讯。只有做到这里，程序员面对新项目时，才不是再次掉入重开地狱，而是像调用一个成熟的结构 runtime 一样，输入意图，立即获得可执行的架构起点。

就问你，爽不爽？

第二，你还需要知道一个具体案例到底命中了规则库中的哪些规则，而且这种命中必须是精准、可解释、有出处的，而不是模糊的语义猜测，更不能让 AI 随意胡诌规则出来。换成法律语言，**就是一个真实案件到底适用哪些法律条文。**这里我可以很明确地说，这是 Legal Informatics 领域几十年来最核心、也是最困难的问题之一。这个问题可以表述得非常简单：让任何一个真实世界的案件，能够命中所有适用的法律条文。听起来像是一个搜索问题，但实际上远远不是。如果只是关键词搜索，那么 Google 出现的那一天，大量律师就应该失业了，但现实显然不是这样。原因在于，一个真实案件所适用的法律条文，很可能和案件描述之间没有任何词汇重合（除了冠词、介词这种无意义词）。因此问题的本质变成：一个案件如何找到真正适用的法律条文和判例。这其实是世界上最困难的信息检索问题之一。难点主要来自三个方面。第一，法条与案例之间往往没有关键词匹配关系，法律条文是抽象规则，而案件是具体事实，两者之间的连接更多体现在结构与逻辑上，而不是字面文本。第二，法律推理本质上是类比推理（analogical reasoning），法律并不是简单的规则推理“规则→结论”，而更像“案例A与案例B在关键事实上相似，因此B中的规则可以适用于A”，这种推理结构对机器来说非常困难。第三，法律适用依赖的是事实模式（fact patterns），案件真正重要的不是它的叙述文本，而是其事实结构，例如谁参与、发生了什么行为、是否存在意图、是否造成损害、事件的背景环境等，这些事实元素组合在一起形成所谓的事实模式，而法律规则实际上是作用在这些事实模式之上的。正因为这些原因，Legal Informatics 才成为一个非常值得程序员关注的领域，尤其是在今天 AI 爆发之后，一个新的方向正在快速发展，即 Legal Automation / RegTech（法律自动化）。这一领域的应用包括合同分析、合规审查（compliance）、法律问答、诉讼预测、合同生成等，典型公司包括 Harvey AI、Casetext（CoCounsel）、Ironclad、LawGeex 等。不过必须坦率地说，目前绝大多数产品其实只停留在 NLP 层，它们主要依赖语义相似度、向量检索和文本生成来工作，而真正困难的问题——案例到法条的结构匹配——到今天仍然没有被真正解决。

既然关键词搜索不行，那么为什么 embedding 也不太行？

先说结论：embedding 并不是完全不行，我自己也在用，而且在很多场景下其实非常好用，比如个人知识库、中小规模语料、探索式搜索。我早期也几乎完全依赖 embedding，但随着库逐渐扩大、质量逐渐提高，我慢慢意识到一个核心问题：向量召回的本质是相似度排序（similarity ranking），而不是命中判断（match detection）。大多数向量数据库，例如 FAISS、Milvus、Pinecone，底层逻辑其实都非常简单：先把 query 转成 embedding，然后计算 cosine similarity，最后返回 top-k 的结果。问题就在这里：top-k 并不等于 match。系统只能说“这些是最像的”，但它从来没有说“这些是正确命中的”。

当你的库逐渐变得精良时，你几乎必然会和我一样推导到同一个技术节点：你会想做命中统计。

例如，你会想知道某一条规则或法条到底被系统精准命中过多少次。我在上一篇文章说我在做 promotion pipeline 的时候就走到了这一步：从高熵内容中产生候选规则，然后通过统计命中次数来决定哪些规则应该被晋升为稳定结构。听起来非常合理，但我在将近半个月的实验之后（期间做出过几次看起来还不错的近似方案）最终彻底放弃了，而且我可以很明确地建议别人也放弃，因为效果很差，得不偿失。

真是气死我了。千万不要踩这个坑。

原因很简单：在向量检索里根本不存在稳定的“命中集合”。语义空间本质上是一个连续的 concept space，而不是一个离散集合，因此不存在清晰的 relevant / irrelevant 边界。系统只能告诉你某些结果更像，而不能告诉你某条结果“就是命中”。

第二个问题是 top-k 本身就是人为截断，例如 top_k=5、top_k=20、top_k=100 时结果会完全不同；在 top_k=5 时某条规则可能完全没有被召回，但在 top_k=20 时它又突然出现了，所以所谓的“命中”其实取决于人为设定的阈值，这在统计上是非常不稳定的。

第三个问题是 embedding 空间本身是会漂移的，只要模型升级，例如 embedding v1 换成 embedding v2，整个向量空间都会改变，同一个 query 在新模型下得到的 top-k 可能完全不同，这意味着所有历史统计都会瞬间失效。

综合这些因素：向量检索天然不具备审计性（auditability）。你当然可以用它做粗召回、找候选、找灵感，但很难用它来回答一个治理系统真正关心的问题，例如“某一条规则到底被命中了多少次”。因为在向量空间里，match 这个概念本身就不存在，只有 similarity ranking。也正因为如此，很多成熟系统最终都会收敛到类似的架构：先做结构过滤得到候选集合，再做向量召回，然后再进行排序或推理。换句话说，vector search 最适合扮演的是 recall helper，而不是 truth layer。

现在给你看一下，在我的系统里，一条intention 真正意义上的“规则命中”是什么样子的。这里的“命中”不是相似度意义上的接近，也不是 top-k 排名里的候选，而是可以被精确定位到具体 law_id 的结构命中。换句话说，系统能够明确地告诉你：我命中的是哪一条规则，而不是“看起来像哪几条”。一旦命中被这样确定下来，这些结果就可以进一步做结构化处理，例如聚类、可视化渲染、与具体案例进行绑定，然后再通过 LLM 的语义能力进行解释和展开，最终生成一份真正可以指导实践的分析报告。例如在下面这个结果里，系统返回的不再是模糊的语义相似内容，而是明确的规则对象集合，每一个对象都带有稳定的 law_id，可以被追踪、统计、复用和审计。这种“被搜索中”了，才可以做统计。

再心疼一下我前几周踩的坑。
"result": {
"count": 3,
"summary": [
"id": "CLM-1ccc03b0",
"kind": "claim",
"title": "Do not institutionalize model behavior in session isolation",
"goal": "Clarify that isolation enforcement targets storage and event routing, not LLM internal memory.",
"law_id": "LAW-3a0c1a81"
},
"id": "CLM-900f1b5c",
"kind": "claim",
"title": "Only System Ledger is Valid Release Destination",
"goal": "Identify exclusive storage location for releases",
"law_id": "LAW-a65c1f79"
},
"id": "CLM-2e37275b",
"kind": "claim",
"title": "Memory Is a Time-Responsibility Contract",
"goal": "Clarify how memory is conceptually treated in the system",
"law_id": "LAW-0f8a2991"

AI 工程团队都会踩的坑：

为什么“RAG + 向量数据库”在规模变大之后经常崩溃。

规则数据库必须离散化

顺便说一句，如果你真的想做到精准命中，有一个前提是绕不过去的：你必须先把自己那些长篇大论的输入，转化为高度精炼、带有稳定 ID 的规则或法条对象。这一步恰恰是 LLM 非常擅长的事情，而且效果好得出奇，几乎是“低成本高收益”的典型场景，所以不做反而才奇怪。我自己的库就是这样运作的：原始输入全部是带有案例、项目背景和思考过程的长篇.md文章。我每天一边做项目一边写，持续往库里输入；你不用管输入多少，也不用管不同文章之间有没有重合。唯一需要确保的一件事是：这篇文章的每一个字你都读过、认可、同意，它代表的是你真实的经验、判断和积累。技术实现其实非常简单，我就是把一个 UI 长期挂在网页上，随时输入，一键入库。每天少则几条，多则几十条。

接下来再写一个convert_to_law_object.py脚本，同样是一键操作，把当天所有输入的文章自动转换成规则对象和法条对象。这一步调用 LLM（甚至不需要特别强的模型）就可以做得很好。我给个简单例子你很容易复制：一篇文章到底能提取出多少条规则、每一条属于什么类型，其实完全由你的代码逻辑决定。比如下面这个例子，有些候选规则会被_gate拦下来，于是被降级为"summary"，而不是"constraint"。我反而建议你把 gate 写得严格一点，否则系统每天可能会自动产生几百条 constraint，最后整个规则层会迅速失控。

"schema_version": "law.object.asset.v1",
"id": "AST-1b646b4b",
"kind": "summary",
"status": "active",
"body": {
"title": "Principles Derived From Institutional Positions",
"goal": "Compression/note derived from conversion; not a governance claim.",
"spec": {
"principles": [
"Runtime Traces Are Not Events",
"Event Ledgers Optimize for Accountability",
"Without Replayable Judgment, History Becomes Indefensible",
"Not All Traces Become History"
],
"_gate_reason": "spec_too_thin"
},
"links": [],
"evidence": []

"schema_version": "law.object.asset.v1",
"id": "CNS-17630e57",
"kind": "constraint",
"status": "active",
"body": {
"title": "Zone I: World State Memory Constraints",
"goal": "Enforce strict quality and update constraints on World State Memory",
"spec": {
"must": [
"High confidence only",
"No speculation",
"No hypothesis",
"No automatic updates"
],
"severity": "binding"
},
"links": [],
"evidence": []
},