Hermans Wei.

产品不是模型，而是包裹模型的那套系统：工具、护栏、反馈、可观测性、编排。我在研究的问题是：怎样让每一次评审发现都变成机器持续盯着的约束，而不是报告里的一行字。

• 禁止只写报告。每条发现必须归入三类之一：直接修掉、编码成检查器、或写明「为什么暂时无法自动化」。三样都没做，等于没有评审。
• 熵增定律适用于 Agent。它会复制现有模式，好的坏的都复制。不固化标准，每次「改好」之后下一轮又会漂回去。每发现一次漂移，就加一个检查，让它不可能再无声发生。
• 完整评审是找新约束的工具，不是日常。找到了就编进检查器，之后靠检查器维持。如果每次人工评审都发现同类问题，说明这类问题早该被机械化了。
• 生成者不能评估自己。共用同一上下文时，评估会系统性偏宽。评估要独立的提示词、独立的样例，最好独立的模型。
• 检查器本身也要维护。阈值太严就变成噪音，太松就形同虚设。定期回看哪些警告最终被证明是真问题。

没想清楚的一条约束什么时候该从提示词层升级到代码层？我现在的经验法则是：同一条建议连续几轮都没生效，就该升级。但「几轮」还没有好答案。

The product isn't the model; it's the system wrapped around it: tools, guardrails, feedback, observability, orchestration. The question I keep working on: how does every review finding become a constraint a machine watches continuously, instead of a line in a report?

• No report-only findings. Every finding must land in one of three bins: fix it now, encode it as a checker, or write down why it can't be automated yet. If none of the three happened, the review didn't happen.
• Entropy applies to agents. They copy existing patterns, good and bad. Without hardened standards, every "fix" drifts back by the next run. Each drift found becomes a check, so it can never happen silently again.
• Full reviews find new constraints; they aren't routine. Once found, a constraint goes into a checker and the checker maintains it. If every human review finds the same class of problem, that class should already have been mechanized.
• Generators must not grade themselves. Sharing context makes evaluation systematically lenient. Evaluation needs its own prompt, its own examples, ideally its own model.
• Checkers need maintenance too. Too strict and they become noise; too loose and they're decoration. Periodically ask which warnings turned out to be real.

Still open When should a constraint move from the prompt layer to the code layer? My rule of thumb: when the same recommendation fails to take effect for several rounds in a row. I don't yet have a good answer for how many.

一个会自我改进的系统需要一条完整的闭环：运行时诊断，可逆的修复，把结论写进长期记忆，下一轮自动继承，再由一本账追踪「这条建议到底生效了没有」。难的不是让它改，是让它只在边界内改。

• 规则进记忆之前先裁决。「改完就写、不验证、不可回滚」是缺陷。有些东西永不允许被自动修改，比如评分标准和数字口径，这是红线。
• 规则要自带测试上岗。每条规则携带应拒和不应拒的样例，加载时自检，不通过就自动停用。
• 账本闭环。系统每一轮都能正确报出该修什么，但如果没有东西定期去读这些账本，等于没报。给每项自检打状态，长期不愈的那种意味着修复建议无效，需要换层解决。
• 记忆需要垃圾回收。低置信度的规则、只出现过一次的模式、过时的洞察，会持续稀释有用信号。不维护的记忆是干扰源，不是助力。
• 产物盖指纹。每条对外产物记录当时的代码、提示词和规则版本，事后能还原它是在哪套约束下生成的。
• 两个尺度，同一个形状。前沿实验室在讨论「扩展速度要受安全信心约束、让人留在改进闭环里」；我在一个行业运营系统里做的红线、裁决、账本，是同一个问题在小尺度上的样子。尺度不同，答案的结构相同。

没想清楚的规则之间会互相矛盾，而且往往是在几轮之后才显现。怎样在写入之前就发现两条约束不可能同时满足？

A self-improving system needs a complete loop: diagnose at runtime, repair reversibly, write the conclusion into long-term memory, inherit it automatically next round, and keep a ledger of whether each recommendation actually took effect. The hard part isn't making it change; it's making it change only inside the bounds.

• Adjudicate before a rule enters memory. "Change it, write it down, never verify, can't roll back" is a defect. Some things must never be auto-modified, such as scoring criteria and numeric definitions. That's the red line.
• Rules arrive with their own tests. Every rule carries should-reject and should-not-reject examples, self-checks on load, and disables itself if it fails.
• Close the ledger loop. The system correctly reports what to fix every round, but if nothing reads those ledgers, nothing was reported. Give each self-check a status; the chronic ones mean the recommendation doesn't work and the problem needs a different layer.
• Memory needs garbage collection. Low-confidence rules, one-off patterns and stale insights dilute the signal. Unmaintained memory is interference, not help.
• Two scales, one shape. Frontier labs now argue that scaling must be constrained by confidence in safety, and that people must stay inside the improvement loop. The red lines, adjudication and ledgers I run inside one industry's operations system are the same problem at a small scale. The scale differs; the structure of the answer doesn't.
• Fingerprint every artifact. Each published output records the code, prompt and rule versions it was produced under, so it can be traced back afterwards.

Still open Rules contradict each other, and usually only a few rounds later. How do you detect, before writing, that two constraints can't both be satisfied?

把模型输出放到有人看的地方之前，要过多少道门、门怎么设、失败了怎么办。这是我这两年被实测教育得最多的一块。

• 确定性规则在前，模型评委在后。能写成代码的目标线和失败线一律写死，作为评测版本的一部分。模型评委只做分层筛查，不做最终裁决。
• 多评委面板。同一提示词让多个不同模型独立打分：数值取中位数抗离群，布尔项多数表决，意见分歧的标出来进人工复核。
• 看分布，不拍阈值。存活值贴着窗口边缘堆积，就是门设错了：文案并没变短，付出的只是重试和降级。两个约束互相矛盾时，门会系统性判废。模型数句子比数词准，句级约束比词数约束可靠。
• 门分两侧。生成侧失败放行，发布侧失败拒发，因为发布没有撤销。改门之前先想清楚自己在哪一侧。
• 诊断、修复、裁决三分离。评测只诊断不修复；修复后强制二次评测；逐条比较前后分，变差就回滚；重试有上限，防止死循环。
• 反幸存者偏差。已发布产物里零越界不是证据，越界的都被门杀掉了。要看被杀掉的那部分。
• 验证手段比技术本身更重要。没有一套泛化理论能告诉你模型会不会在新情境里守规矩，所以能不能验证，比用了什么技术更决定系统能走多远。门、评委、回滚都是验证手段，不是能力。

没想清楚的自查型约束不可靠，模型会无视提示词里的配额，只能生成后用代码兜住。那提示词层到底还能承担哪些约束？还有一个更大的：当监控本身成了瓶颈，该停下的是发布、生成，还是升级模型？

Before model output reaches anyone, how many gates should it pass, how are they set, and what happens on failure? This is where real systems have corrected me most often in the past two years.

• Deterministic rules first, model judges second. Anything that can be written as code, target lines and failure lines, is hard-coded as part of the evaluation version. Model judges only do tiered screening, never the final call.
• A panel of judges. Several different models score independently with the same prompt: medians for numbers to resist outliers, majority vote for booleans, disagreements flagged for human review.
• Read the distribution, don't guess thresholds. Survivors piling up against the window edge means the gate is wrong: the text didn't get shorter, you only paid in retries and degradation. When two constraints contradict, the gate rejects systematically. Models count sentences better than words, so sentence-level rules beat word counts.
• Gates have two sides. Fail-open on the generation side, fail-closed on the publishing side, because publishing has no undo. Know which side you're on before changing a gate.
• Separate diagnosis, repair and adjudication. Evaluation diagnoses but never fixes; every repair is re-evaluated; scores are compared item by item and anything worse is rolled back; retries are capped.
• Beware survivorship bias. Zero violations in published output proves nothing; the gate killed the violators. Look at what was killed.
• Verification matters more than the technique. No theory of generalization tells you whether a model will keep the rules in a new situation, so whether you can verify decides how far a system can go, more than which technique you used. Gates, judges and rollbacks are verification, not capability.

Still open Self-policing constraints are unreliable: models ignore quotas written in the prompt, so code has to catch it after generation. Which constraints, then, can the prompt layer still be trusted with? And a bigger one: when monitoring itself becomes the bottleneck, what do you stop first: publishing, generating, or upgrading the model?

把「人找 AI」倒过来：每天系统自己生成值得追的问题，查私有数据、知识图谱和公开信息求证，筛出高价值的发现。做起来才知道，生成不难，难的是让它别每天说同一件事。

• 生成系统天然收敛。没有约束时它会反复回到少数热门话题。要用跨天去重、话题疲劳窗口、饱和实体降权、地域和事件轮转，把注意力重新摊开。
• 注意力要有预算。一部分深度追踪近期发现，一部分常规基线监控，一部分留给探索。比例写进系统，不靠模型自觉。
• 正向偏见是系统性的。模型天然把发现描述成机会，风险类内容会悄悄消失。这类分布必须在生成规则和后处理两层都硬性约束。
• 人的输入是一等公民。人类不定期放进来的指导意见和报告，直接进入提问流程，并带有效期，过期自动归档。
• 凑数比空缺更糟。产出不够时不能用克隆凑数，凑数卡对外可见，且把门槛架空。宁可少。

没想清楚的「值得追」的判断标准怎样随时间演化而不被自己的历史产出锁死？

Invert "people find AI": every day the system generates questions worth chasing, verifies them against private data, a knowledge graph and public sources, and filters for high-value findings. Only in practice did it become clear that generation is easy; the hard part is stopping it from saying the same thing every day.

• Generative systems converge by default. Unconstrained, they return to a handful of hot topics. Cross-day dedup, topic fatigue windows, saturation decay for over-covered entities, and rotation across regions and events spread attention back out.
• Attention needs a budget. A share for deep follow-up on recent findings, a share for baseline monitoring, a share reserved for exploration. The ratio lives in the system, not in the model's goodwill.
• Positive bias is systematic. Models naturally frame findings as opportunities, and risk content quietly disappears. That distribution has to be enforced in both the generation rules and post-processing.
• Human input is a first-class citizen. Guidance and reports people drop in feed straight into question generation, carry an expiry date, and archive themselves.
• Padding is worse than gaps. When output falls short, never clone to fill the quota: padded items are visible to readers and hollow out the bar. Fewer is fine.

Still open How does the standard for "worth chasing" evolve over time without being locked in by the system's own past output?

把大模型从「会聊天」做成「能交付」，大部分工作在模型之外：请求怎么路由、记忆怎么增量、工具怎么发布、实体怎么对齐、模型怎么分层选。

• 双模路由。用一次首轮调用同时完成「直接回答还是转 agent」的判断和过渡话术，省掉独立分类器；流式转发时要处理标记被切片泄漏的问题。
• 跨会话记忆只做增量。以会话摘要加附件清单为单位，只用本轮消息、本轮回答和既有摘要合并；每条摘要有硬上限，超限先让模型再压一次，仍超就本地截断；更新异步，不阻塞流式输出。
• 同一套工具双形态发布。内部 agent 循环用一种接口，对外用 MCP 协议，schema 由类型定义自动生成，数据层与模型层严格解耦。
• 实体先对齐。自然语言里的地名、机型、代码、别名和错拼，用精确别名、分块模糊检索、结构化证据三级 rerank 解析到规范实体，每类实体独立置信阈值。这是页面、AI 和工具共享同一份真相的前提。
• 按任务分层选模型。路由、规划、工具解析、最终回答、长文压缩各用不同档位，并把配置审计和用量埋点做成基础设施。

没想清楚的记忆该由谁来遗忘？用户、系统、还是时间？

Turning a model that can chat into one that can deliver is mostly work outside the model: how requests are routed, how memory accumulates, how tools are published, how entities are aligned, how models are chosen per task.

• Dual-mode routing. One first-turn call decides "answer directly or hand off to an agent" and produces the bridging text at the same time, removing a separate classifier; streaming has to guard against the marker leaking across chunks.
• Cross-session memory is increment-only. The unit is a conversation summary plus its attachment list, merged from this turn's messages, this turn's answer and the existing summary; each summary has a hard cap, gets re-compressed by the model if over, then truncated locally; updates run asynchronously and never block the stream.
• One toolset, two publications. One interface for the internal agent loop, MCP for the outside world, schemas generated from type definitions, data layer strictly separated from the model layer.
• Align entities first. Place names, aircraft types, codes, aliases and misspellings in natural language resolve to canonical entities through exact aliases, chunked fuzzy retrieval and structured evidence, with a confidence threshold per entity type. That's the precondition for pages, AI and tools sharing one truth.
• Choose models per task. Routing, planning, tool parsing, final answers and long-text compression each get their own tier, with configuration audits and usage telemetry treated as infrastructure.

Still open Who should do the forgetting: the user, the system, or time?

检索型 AI 爬虫拿到的只是 HTML 骨架。如果你的内容靠客户端渲染，它对模型来说不存在。我在研究怎样让同一份数据同时对人和模型可读、可引用、可核对。

• 服务端可读页。同一份数据渲染成无 JS 也能读全文的页面，加结构化标注，对所有访客一致可见，不是给爬虫开小灶。
• 数值要冻结。滚动口径的数字每天都变，模型今天引的数一周后核对不上就像引错。每天冻结一份快照，给模型一个定值可核对的引用目标。
• 区分两种失败。「取过页面却没引用」和「从未取过」的处置方向完全相反，必须用爬虫命中数据把它们分开。
• 不推近重复页，不推薄页。与滚动版内容相同的最新快照不一起宣告，取不到数据的切片页整个不宣告。

没想清楚的怎样衡量「被模型引用」本身？目前只能看到取没取，看不到引没引。

Retrieval crawlers get the HTML skeleton only. If your content depends on client-side rendering, it doesn't exist for the model. I'm working on making one dataset readable, citable and verifiable for people and models alike.

• Server-readable pages. Render the same data as full-text pages that need no JavaScript, add structured markup, and show the same thing to every visitor. This is not cloaking.
• Freeze the numbers. Rolling figures change daily, and a number a model cites today won't reconcile a week later, which reads as an error. Freeze a daily snapshot so the model has a fixed, checkable target to cite.
• Distinguish two failures. "Fetched but never cited" and "never fetched" call for opposite responses, so crawler-hit data has to separate them.
• Don't push near-duplicates or thin pages. The newest snapshot, identical to the rolling version, isn't announced alongside it; slices with no data aren't announced at all.

Still open How do you measure being cited by a model at all? Right now I can see fetched or not, never cited or not.