S20-X01 · 规则资产与杂项登记（附录）

适用读者：核对"那 13 篇 Vibe 规则与杂项文去哪了"的读者；本系列维护者。
性质：登记表。24 篇尾部旧文中，11 篇已吸收进 J05/A04，其余 13 篇在此登记处置。
覆盖旧文：4639、4640、4641、4642、4643、4644、4645、4646、4647、4650（Vibe 规则系列 10 篇）、4616（成本优化五层）、3417（ChatGLM 部署）、3418（手机 + agent）、3147（153 字符一句话）→ 13 篇。

1. 逐篇登记

旧文	标题	字符数	处置	去向与理由
`4639`	为什么要给 AI 立规矩：四类典型事故与规则注入原理	1,527	`duplicate_ref`	S24-J05 §2/§6：规则注入的分层与"写了等于没写"三种后果
`4640`	把需求确认搬进人机协作：复述、PRD、许可三步闸门	1,506	`duplicate_ref`	S24-J04 §4：需求→Prompt 六段法（目标/现状/边界/验收）即同一闸门
`4641`	前端组件治理两件套：PlayGround 与样式收敛	1,859	`appendix`	AI 驱动前端治理的做法，与 S14-A03（AI 时代 UI 生成方法论）互补；本系列保留要点
`4642`	注释三要素与代码保护：让 AI 写跨时间的注释	1,253	`appendix`	注释规范（是什么/为什么/边界），并入本文 §3
`4644`	不接受分期交付：完整实现才是对技术债的唯一回应	1,174	`duplicate_ref`	S24-J04 §3：小步提交与"可验证"原则的另一种表述（原文偏口号，按判据重写）
`4645`	四份文档各管一个维度：功能生命周期、改动细节、用户视角与产品品味	1,999	`appendix`	文档四分法，并入本文 §4
`4646`	把环境事实写进 Rule：模型配置、技术栈锁定与必踩的坑	1,638	`duplicate_ref`	S24-J05 §3 规则骨架的"技术栈与版本"段
`4647`	破坏性操作的三道闸：备份、回退方案与发版 diff 审查	1,557	`duplicate_ref`	S24-A01（权限沙箱与审批）+ S18-A05 §6（回滚）
`4650`	规则的价值：14 章全景图、三步装进项目与适配四步	1,999	`appendix`	规则集合的组织方式，并入本文 §2
`4616`	LLM 成本优化与选型全指南：KV Cache、五层策略	4,146	`duplicate_ref`	S20-A01（性能与成本）+ S23（KV Cache 底层机制）
`3417`	【部署教程】ChatGLM-6B 开源双语对话模型	1,994	`needs_verification`	部署步骤与依赖版本已过时（2023 年模型），待核；机制层由 S23 覆盖
`3418`	手机 + agent，这是要掀桌子！	3,881	`needs_verification`	前瞻性判断，无技术结论；待核时效
`3147`	搭个 ChatGPT 算法模型，离 Java 程序员有多远？	153	`non_knowledge`	153 字符标题式内容，无正文

2. 规则集合的组织方式（`4650` 保留结论）

14 章 → 不是 14 个文件，是 4 类：
① 环境事实（技术栈/版本/命令）—— 最稳定，写一次用一年
② 硬约束（不可违反的红线）—— 稳定，需每条可判定
③ 工作流（评审/发布/迁移的步骤）—— 中频，适合 Skills
④ 品味（命名、注释、表达风格）—— 低频，靠示例而非形容词

三步装进项目：

① 先只写「环境事实 + 硬约束」两段（20~30 行），跑一周看有没有违反
② 违反过的约束，补上"为什么"（模型对带原因的约束遵循更好）
③ 高频多步流程单独抽成 Skills，别塞进静态文件（判据见 S24-J05 §2）

适配四步（换工具/换团队时）：

① 抽公共段（环境事实、硬约束）→ 一份源
② 生成三份工具配置（AGENTS.md / CLAUDE.md / .cursor/rules）→ 软链或脚本
③ 工具特有段（模式、命令入口）留在各自文件，不进公共源
④ 每次改公共源后，跑一次"复述检查"确认三处都生效

3. 注释三要素与文档四分法（E-S20-028，`4642`/`4645` 保留结论）

/**
 * 计算订单的可退款金额。
 *
 * 为什么：优惠券与运费险的抵扣顺序在业务上必须固定（先券后险），
 *         顺序写错会导致用户多退或少退，历史上出过一次资损。
 *
 * 边界：仅处理已支付订单；未支付/已取消返回 0，不抛异常。
 *       金额单位为「分」，不接受负值输入。
 */
long refundableAmount(Order order) { … }

要素	写法	反例
是什么	一句话说清输入输出	重复方法名
为什么	业务约束/历史事故	"实现该功能"
边界	适用条件、异常语义、单位	不写单位导致元/分混用

判据：能跨时间的注释写"为什么"和"边界"，不写"怎么做"——怎么做会随实现变化，为什么不会。

4. 文档四分法

文档	回答	更新时机	读者
功能生命周期	这个功能现在处于什么阶段（实验/GA/弃用）	阶段变化	全员
改动细节	这次改了什么、为什么、影响面	每次变更	评审者/后来者
用户视角	用户怎么用、看到什么	功能上线/文案变更	产品/客服/用户
产品品味	我们偏好什么样的解法	长期演进	设计与架构

判据：四类文档混在一份里，必然有一类永不更新——分开后各自的更新责任人清晰。

5. 前端组件治理两件套（`4641` 保留结论）

① PlayGround（试衣间）：组件在隔离环境里可调参预览 → 评审时看真实渲染，不看截图
② 样式收敛：把散落的内联样式/魔法值收敛到 token（颜色、间距、字号）
判据：AI 生成 UI 的速度远快于人工评审 → 必须先用「token + 隔离预览」把可变空间收窄，
      否则生成越多、不一致越多。

6. 缺口与待核

项	状态
`3417` ChatGLM-6B 部署步骤	待核：模型与依赖版本过时（2023），未复现
`3418` 手机 + agent 的判断	待核：前瞻性内容，无技术结论
`4616` 成本五层的具体倍数	原文数字无口径，本系列不引用；机制见 S20-A01/S23
Vibe 规则系列原始 14 章完整清单	仅有 10 篇留存，其余章节未在恢复语料中，待核

7. 下一篇

S20 系列验收（v2） —— 14 篇 / 10,722 点位 / 24 篇尾部旧文 100% 登记 / 下一系列（P14：S27 22 篇）前置依赖。

上一篇：S20-A04 · 训练与微调机制：预训练、Chat Template、SFT 与幻觉治理

本篇属于系列《S20 · AI 应用与工程》。旧文来源：A-4639–4650（Vibe 规则 10 篇）、A-4616、A-3417、A-3418、A-3147；扩展点 E-S20-027（规则四分类）、E-S20-028（注释与文档规范）。