分支查看插件已经在你本地跑通了，接下来自然是把它发出去，让别人也能用。
但这会引出两个现实问题：
- 别人怎么安装？总不能把源码压缩包拷过去，再教他跑一遍编译命令。
- 发布之后怎么维护？有人报 bug 要修，DSH 升级要跟进，这些后续工作大概率还要交给 AI。
代码几百行时，AI 改了什么你还能一行行审；等代码长到几千行，肉眼根本盯不过来。AI 悄悄写坏一处，很可能得等到用户找上门才发现。
dsh-ccgui 也是借助 AI 写出来的，源码超过一万五千行。它之所以没被写散架，靠的就是一套给 AI 设立的硬规矩。
这一篇来看 dsh-ccgui 的防翻车策略，给你的分支查看插件加上最要紧的一道防线，并把它发布到社区。
读完这一篇，你能搞明白三件事：
- 说清 dsh-ccgui 管住 AI 的三层防线；
- 为自己的插件配置自动化架构检查；
- 把插件打包发布到 npm，让别人一条命令就能安装。
一、说明书管不住 AI
做分支查看插件时，最后一步是把 AI 犯过的错记进 AGENTS.md。说明书越写越详细，AI 也会越来越听话。
但这种方式有个前提：
- AI 每次都能完全遵守规则；
- 或者 AI 违规的时候，你能一眼看穿。
工程规模小的时候这套没问题，一旦体量变大就容易失控。
拿说明书里的第一条核心原则举例：“前端界面的代码绝对不能导入后端文件”。AI 在重构一个大功能时改动了十几个文件，其中一个前端组件顺手引入了后端工具函数。
此时 TypeScript 类型检查通过，打包构建也正常通过，你抽查的关键逻辑都没问题，这行违规导入就被悄悄带进了生产环境。
根源很简单：只写在说明书里的规矩，完全依赖 AI 的自觉和人类的肉眼盯防。
dsh-ccgui 的解法非常干脆：凡是能用脚本自动化验证的规矩，绝不留给人肉检查。
二、三层质量防线
它的约束机制一共三层，层层递进。
1. 第一层：说明书约束
dsh-ccgui 的 AGENTS.md 有九十多行。与我之前给分支插件写的那份相比，多了一组防投机策略：明确禁止 AI 用哪些手段逃避检查。
以下摘自 dsh-ccgui 的 AGENTS.md：
## 检查不通过时
改代码，不改规则。
- 不要为了让检查通过去修改 `eslint.config.js`、`tsconfig*.json`、`.dependency-cruiser.cjs`、`knip.json`、`vitest.config.ts` 里的阈值、`lefthook.yml`、`.github/workflows/`。确实觉得规则不对，停下来说明理由，等用户决定。
- 不要用 `git commit --no-verify` 或 `git push --no-verify` 绕过钩子。
- 不要用 `any`、`as unknown as X`、非空断言 `!`、`@ts-ignore`、`@ts-expect-error` 来消除类型错误。
- 不要删测试，不要加 `.skip` / `.only`，不要靠降低覆盖率门槛过关。AI 的目标是“让检查全绿”，而让检查变绿有两条路：
- 把代码改对；
- 把检查规则改松。
修改配置无疑省时省力，AI 极易倾向于后者。因此必须在前面把漏洞封死：只准改代码，不准动规则。
它的验收准则里还有一句话同样值得借鉴：
跑不了就明确说出来，不要声称已验证。AI 无法完成某项验证时，最危险的不是它无法执行，而是它没跑却汇报说已经通过。
2. 第二层：单命令全量检查
能让工具检验的规矩，dsh-ccgui 全部收敛到了一条命令：pnpm check。
在 dsh-ccgui 的 package.json 中配置如下：
"check": "pnpm format:check && pnpm typecheck && pnpm lint && pnpm arch && pnpm knip && pnpm type-coverage && pnpm coverage",使用 && 连接意味着任意一项检查失败，后续任务立即中断：