Nimi Coding 白皮书

Nimi Coding 将 AI 辅助实现视为一项承载权威的工作。核心主张是：复杂 AI 编码要成功，必须在接受产出之前明确权威来源、影响范围、执行 packet、审计关口和收尾标准。

本页论证这条主张，并说明这套方法论处理哪些失败模式。

传统 AI 编程模式的局限性

小规模代码修改时，AI 助手可以读取少量文件、修改代码、运行测试并完成任务。但面对复杂项目时，这种模式往往会失效。AI 助手可能会：

在 AI 的单次执行中，这些问题难以察觉。当时每个步骤看起来都是正确的。

Nimi Coding 将开发过程分离为五个独立的关注点：

关注点	核心解决的问题
权威	事实的真相位于何处？
packet	执行者被允许读取什么、修改什么以及声明什么？
wave	当前正在闭合哪一个所有权领域？
审计	存在哪些证据可以证明工作没有发生漂移？
收尾	为什么该任务在权威、语义、消费方和抗漂移这四个维度上均已彻底完成？

这个模型不消灭迭代。它让每一次迭代都能被审计。

每个 wave 必须同时满足以下四个维度，才算真正闭合：

大多数“看似完成实则不然”的失败，都来自某个维度通过、另一个维度失败。例如，文档重写可能在权威上闭合（未偏离规范），语义上也闭合（声明准确），但消费方维度失败，因为最终文档不像公开文档，读者无法建立清晰模型。

我们当前正在处理的公共文档修复任务，是一个极佳的案例说明：

正是这种四维闭合模型，捕捉到了那些单纯依靠“构建通过”规则所无法发现的深层缺陷。

topic 的流程和结构要求在初期可能显得较重。但这种投入是必要的，因为 AI 极其擅长生成“看似合理实则错误”的输出。在传统的代码库中，代码审查和测试是主要防线。而在 AI 辅助的环境下，AI 生成的产物可以轻易通过这两道防线，却在架构权威、作用范围或消费方适用性上出错。

Nimi Coding 不取代传统代码审查。它增加一道结构化审计关卡，用来拦截代码审查单独防不住的失败模式。

之所以存在上述关于“修复人类可读文档”的 topic，正是因为之前的文档重写虽然通过了所有机器审查，却未能满足人类消费者的实际需求。这正是 Nimi Coding 要暴露的典型问题：一项任务即便拥有权威依据、Lint 检查通过、构建成功，依然可能无法满足最终消费者的预期。

当发生此类情况时，正确的应对策略是保持该 topic 的挂起状态，并准入一个后续 wave 专门解决这个缺口，而非勉强宣布任务完成。