采纳路径
谁会采纳 Nimi Coding，又是为什么？这一页列出目标用户画像，并说明每一类人能从中得到什么。
目标用户画像
| 用户画像 | 他们得到的 |
|---|---|
| 重度依赖 AI 的单人创业者 | 没有团队，也能拿到团队规模的复核纪律 |
| 引入 AI 的 2–5 人小团队 | 不靠扩编也能扩展的复核冗余 |
| 接受 AI 撰写 PR 的开源维护者 | 可证明的贡献纪律 |
| 面临 AI 编码合规压力的研发组织 | 审计链路与结构化验收 |
| 研究 AI 工程实践的研究者 | 可观察的方法论语料 |
来自 Nimi 自身的实地证据
Nimi Coding 最强的证据不是某项基准跑分，而是 Nimi 在自己身上使用了这套方法论。
在 Nimi 仓库里，Nimi Coding 用于：
- 重建并校验权威
.nimi/spec/**树； - 用议题驱动的设计与修复，替代无界的自由式 AI 会话；
- 把长审计拆成 sweep audit 分块，证据逐块记录；
- 把审计 finding 转成 sweep design worksets 与候选议题 wave；
- 让大型跨域修复在 Runtime、SDK、桌面端、文档以及 Nimi Coding 自身之间保持可审视。
这并不能证明方法论在任何地方都是对的。它的作用是让宣称变得可证伪——如果工件出现漂移、如果议题在没有证据的情况下被 close、如果规范审计被破坏、或者消费方接受度缺位，失败会出现在它要求别的项目采用的同一套机器证据里。
重度依赖 AI 的单人创业者
最难的情形。一位单人创业者要构建有野心的系统，必须以团队规模的速度推进，却没有团队的复核冗余。
痛点：
- 自我代码评审不可靠。
- 测试能抓行为 bug，抓不到权威漂移。
- AI 那种"看似合理实则错误"的输出，能从单回路复核里活下来。
Nimi Coding 提供：
- 审计员角色可以路由到另一个 AI 会话或另一个厂商，模拟一个团队本应提供的结构性分离。
- 四闭合让"这件事算完成了吗？"有证据可以回答，而不是凭感觉。
- 禁用快捷方式目录帮你抵御那些自己尚未察觉的反模式。
这正是 Nimi 项目自身的处境。Nimi 由一位单人创业者重度借助 AI 在构建，而 Nimi Coding 正是让这些工作在聊天上下文消散之后仍可复核的机制。
引入 AI 的 2–5 人小团队
小团队最早撞上 AI 的失败模式，因为他们的复核冗余不如 20 人团队。五双眼睛能看到三双眼睛漏掉的形态。
痛点：
- AI 让产出加速；复核能力并不线性扩展。
- 权威漂移在 PR 这一层不可见，几周时间里慢慢累积。
- 复核员被拉得太开时，"我看着没问题"会变成默认通过。
Nimi Coding 提供：
- 审计与评审在结构上分离。团队的 PR 走常规评审；针对四闭合的审计是另一个回路。
- 即便复核员疲劳，禁用快捷方式目录也能抓到模式。
- 议题 / wave 纪律让团队在同一时间内只盯着一条主迭代线。
对小团队而言，价值是不靠扩编也能扩展的复核冗余。
接受 AI 撰写 PR 的开源维护者
维护者要审看 AI 撰写的贡献，需要的是：AI 的边界是什么、它声称满足了哪些闭合条件、权威住在哪里——这些都要有证据。
痛点：
- AI 撰写的 PR 看起来很光鲜，仍可能从项目规范漂移开。
- 审看者很难分辨 AI 推理里哪些是有证据支撑的，哪些是幻觉。
- "信任贡献者"这套逻辑，在贡献者是无持久利益的模型时不成立。
Nimi Coding 提供：
- 一份冻结 packet，命名贡献者所受的边界。
- 审计血缘，维护者可以直接读，不用从 PR 描述里反推。
- 四闭合收尾，维护者在合并前可逐项核验。
对开源维护者而言，价值是贡献纪律的结构性证据。
面临 AI 编码合规压力的研发组织
更大的机构需要审计 AI 协作工作如何被治理——出于合规、安全审查、跨团队交接需要——他们要的是工件链路。
痛点：
- "这次工作是 AI 协作的吗？"事后很难回答。
- "AI 当时被限定在什么范围？"从 PR 里很难看出。
- 审计与合规团队读不了自由格式的 Slack 串和聊天记录作为证据。
Nimi Coding 提供：
.nimi/topics/**是结构化的工件链路。topic.yaml是生命周期证据。- 收尾维度是结构化的验收标准。
- 审计血缘把建议 → 裁决 → 批准 → 行动串起来。
对研发组织而言，价值是可审计追溯的 AI 协作工作。
研究 AI 工程实践的研究者
研究 AI 编码如何成功或失败的研究者，需要一份结构化的工件语料用于分析。
痛点：
- 多数 AI 编码的证据散在聊天记录里，转瞬即逝。
- "AI 失败模式 X 长什么样？"很难从轶事里回答。
- 方法论非正式时，跨团队复现性差。
Nimi Coding 提供：
- 一份强类型方法论语料，其他团队接入后能产出可比对的工件。
- 假闭合类型，命名了反复出现的失败形态。
- 审计 / packet / 收尾工件，构成可观察的实践数据。
对研究者而言，价值是可观察的 AI 工程实践数据。
不适合采纳的情形
方法论对适用范围明确：
| 情形 | 是否使用 Nimi Coding？ |
|---|---|
| 高风险或承载权威的工作 | 是 |
| 复杂修复 | 是 |
| 多 wave 迭代 | 是 |
| 跨模块重构 | 是 |
| 极小的局部修复 | 否（开销超过价值） |
| 一次性脚本 | 否 |
| 抛弃式原型 | 否 |
把方法论强加到小改动上，只增加成本而不带来闭合价值。小改动的默认姿态是"常规工程卫生，不走议题纪律"。
读者场景：单人创业者首次采纳 Nimi Coding
一位单人创业者重度借助 AI 在构建一个有野心的系统。
- **取包。**从 npm 安装
@nimiplatform/nimi-coding；详见 Installation。 - **运行
nimicoding start。**完成 bootstrap 准入。 - 重建规范。
nimicoding handoff --skill spec_reconstruction --json，发送给已准入宿主。 - **下一项高风险改动采纳方法论。**写议题；准入 wave；冻结 packet。
- **路由审计。**审计员角色用另一个 AI 会话承担。
- **闭合 wave。**走完四个维度。
- **继续。**后续高风险改动按同一套纪律推进。
半年之后，每一次实质性改动都留下了结构化的工件证据。权威漂移可被察觉。在主回路里漏掉的错误，会在审计回路里被抓到。
读者场景：维护者把 Nimi Coding 用于 PR 评审
一位有中等流量项目的开源维护者，决定把 Nimi Coding 用在 AI 撰写的 PR 上。
- **作为 dev 依赖加入。**把 Nimi Coding 加到项目里。
- **在主分支 bootstrap
.nimi/**。**方法论与规范结构成为项目的一部分。 - **更新贡献者指南。**AI 撰写的 PR 必须附带议题 / wave / packet 工件。
- **评审者读工件。**冻结 packet + 审计 + 收尾，构成 PR 评审的一部分。
- **闭合后合并。**wave 收尾通过，PR 即可合并。
这次变化只针对 AI 贡献是结构性的；常规的人类贡献不受影响。