Skip to content

四闭合

四闭合是一种思考方式,不是一份收尾清单。当某次 AI 输出没有报错却又总觉得不对,你用四闭合去定位问题在哪一维。

一次 wave 必须四个维度都显式过关才算闭合。过三个不算。

四个维度

维度它问的问题
权威这一面的真相归在哪里?内部是否一致?
语义契约的必填字段、失败模式、复杂分支是否都已写明?
消费方真正使用这条接缝的系统或读者是否在正确使用它?
抗漂移下一位实施者会不会轻易把这次设计退回去?

权威闭合

这一面的真相归在哪里?内部是否一致?

权威闭合问的是:改动之后,是否仍只有一个权威所有者?任何并行的真相面(影子缓存、应用本地的"方便状态"、双读路径)是否被消除,或者被显式准入?

闭合时失败时
权威所有者唯一两条面同时声称权威
没有遗留并行真相非正式缓存悄悄变成权威
已准入的修改是显式的出现未声明的所有权重开

常见权威失败:AI 加了一段帮助函数,实际重新实现了另一个包负责的行为,从而生出影子真相。

语义闭合

契约的必填字段、失败模式、复杂分支是否都已写明?

语义闭合问的是:两位独立实施者按这份契约写出来的行为是否等价?MIME 类型、错误原因、重试策略、边界行为,到底已经规定,还是"留给实现"?

闭合时失败时
必填字段已规定必填字段缺失
失败模式已钉死只覆盖了 happy path
复杂分支没有作为隐含假设"边角情况"被悄悄搁置

常见语义失败:只写 happy path——AI 实现了成功长什么样,把失败处理留作隐含。

消费方闭合

真正使用这条接缝的系统或读者是否在正确使用它?快捷方式会不会悄悄变成主路?

消费方闭合问的是:实际的消费方(应用、文档读者、运维人员)是否感到这次工作真正解决了他们的问题?还是契约干净落地,消费方那边却仍然没有改善?

闭合时失败时
正常消费方使用正确的接缝消费方仍走旧接缝
快捷方式不会悄悄变成主路"临时"快捷方式变成事实主路

常见消费方失败:build 通过、消费方不通过。先前那个公开文档议题就是范本:所有机器侧关卡都通过,真实读者却把文档读成"审计余渣文体"。

抗漂移闭合

下一位实施者会不会轻易把这次设计退回去?

抗漂移闭合问的是:禁用快捷方式是否被命名?重开条件是否显式?防止退化的边界是结构性的,还是只靠社交压力维持?

闭合时失败时
禁用快捷方式已显式列出快捷方式没名字,下次又会被重新发现
后来人不容易把设计稀释回去没有显式准入也能再稀释一遍

常见抗漂移失败:今天的收尾过得去,但没有任何机制阻止下一季在上下文消失之后,同样的快捷方式再次被引入。

为什么四个维度独立

**"过三缺一"是 AI 工作中最常见的假闭合形态。**每一种"三过一缺"的组合,都对应一种可识别的病理:

权威语义消费方抗漂移结果
通过通过通过不通过当下能跑,半年后腐烂
通过通过不通过通过技术正确,无人能用
通过不通过通过通过体验不错,契约不全
不通过通过通过通过隐藏的并行权威

方法论要求四维都显式过关。收尾时少写一维不是软信号,而是 schema 违规。

读者场景:用四闭合判定一次 wave

你是这次 wave 收尾的管理者。worker 报告完成。你按四闭合走一遍:

  1. **权威。**权威真相是否仍在 .nimi/spec/** 里?没有产生影子路径?所有权是否清晰?
  2. **语义。**kernel 规则是否仍然钉住必填字段、失败模式、schema?复杂分支是否显式?
  3. **消费方。**真实的应用、文档读者、运维人员是否感到问题被解决?跑一次渲染后的站点,读一遍文案,调一次 API。
  4. **抗漂移。**禁用快捷方式目录是否更新?重开条件是否命名?日后一次匆忙改动会不会把错误模式再带回来?

三过一缺,消费方不通过。这次 wave 没有闭合。要么打回修订,要么准入一次后续 wave 专门补消费方那一维。

读者场景:一次真实的"过三缺一"

先前那次公开文档修复,机器审计层面是闭合的:权威闭合(无规范漂移)、语义闭合(声明对得上规范)、抗漂移闭合(不主张未取得证据的姿态保住了)。消费方不通过——用户把渲染后的文档读作"审计余渣"。

方法论的反应:保持议题在 pending,不标记 closed;准入一次后续 wave,专门处理消费方缺口。不要回头修改已闭合 wave 的记录。

四闭合存在的意义,正在于此。没有它,"build 通过"就会被当成完成。

来源依据

Nimi AI open world platform documentation.