附录 C · 部署与目录清单
怎么用：你要给自己的系统“找个地方安顿”，照这份清单摆一遍。
原则只有一条：内核和项目分开放。 混在一起的系统，最后会落到“动一处、全身疼”。
你的根目录/
│
├── 内核/ ← 装一次，不轻易动
│ ├── 身份/ 它是谁（三份：它是什么、你是谁、你们什么关系）
│ ├── 规矩/ 不许做什么（边界 + 禁令）
│ ├── 常驻规则/ 永远在线的那几条
│ └── 体检/ 那把尺（指标 + 记录）
│
├── 项目/ ← 会长、会变、各关各的
│ ├── <项目A>/
│ │ ├── 它管什么.md 边界（含"它不管什么"）
│ │ ├── 记忆/ 这个项目的长期事实
│ │ ├── 产出/ 做出来的东西（落盘处）
│ │ └── 日志/ 做过什么
│ └── <项目B>/ …
│
└── 公共/ ← 谁都能用，但不属于任何人
├── 方法论/
├── 模板/
└── 归档/
三个判断标准：
| 问 | 归“内核” | 归“项目” |
|---|---|---|
| 它会不会因为某件事变了？ | 不会 | 会 |
| 改了它，别的事受影响吗？ | 受影响 | 只影响它自己 |
| 三年后它还在吗？ | 在 | 可能没了 |
⚠️ 最常犯的错：把“会长的项目”塞进“内核”，或者新建一个项目就在内核里加一条规矩。
结果：内核越改越乱，你不敢动任何东西。
规范一：序号 + 类型 + 名字。
00-卷首-<名字>.md
01-第一章-<标题>.md
90-附录A-<名字>.md
为什么带序号？因为排序稳定。不带序号的文件，换个系统打开顺序就乱了。
规范二：一件东西两份，名字完全一样。
07-第七章-手-把想清楚的事做成.md ← 源
07-第七章-手-把想清楚的事做成.docx ← 成品
只有扩展名不同。这样你（和你以后接手的任何人）一眼能配对。
规范三：改版留档，不覆盖。
_旧版v1/ ← 上一版整体移进来
_bak/ ← 改动前的备份
为什么留？因为“它曾经是这样”本身是信息（见附录 A“标作废而非删除”）。
摆好目录之后，你要维护四张清单。每张都很短，但缺一张都会出事：
| 清单 | 装什么 | 用来干什么 | 多久看一次 |
|---|---|---|---|
| 资产清单 | 你有哪些能力（技能、脚本、自动化） | 调度前先看有没有 | 变动时 |
| 接口清单 | 每样东西“吃什么、吐什么” | 串流程 | 变动时 |
| 规矩清单 | 不许做的事 + 边界 | 让人和系统都知道红线 | 每月 |
| 体检清单 | 指标 + 时间 + 不过怎么办 | 判断还行不行 | 按定好的时间 |
这四张清单，就是你这套系统的“户口本”。
它们不用长。“资产清单”写二十行也够用；关键是有人维护，而且变动时同步改。
这一节是硬红线。放进去之前先过一遍：
| 不放 | 为什么 |
|---|---|
| 账号、密钥、密码 | 放在配置文件里集中管，不写进正文 |
| 别人的个人隐私 | 不是你的东西，你没权留 |
| 未经确认的内部经营数据 | 会漂移，而且一旦进公开端收不回来 |
| “看起来合理”的估计值 | 编的数字比缺数字坏——它会被人当真的用 |
这一条对我们是死规矩，对你更是。
一个库里只要有一条编的数据被人当真引用过一次，整个库的可信度就降一级。
最后一件事，也是最笨的一件：产出必须落在两个地方。
为什么？
规矩三条：
1. 第一落点要够近——你能立刻打开它（比如桌面）。
2. 第二落点要够稳——它不跟着你手滑（比如同步盘、Git、另一块盘）。
3. 两边不一致时，以内容更全的那一份为准，然后补齐另一份。
还有一条最容易被忘的：备份要“验”。
没验过的备份，等于没有备份。——因为你不知道它是不是空的。
验法极简单：从备份里随便打开一个文件，看它是不是完整的那一份。
摆完之后，用一句话自检：
“如果我现在要把这套东西交给第二个人，他要拿哪几样、放哪儿、从哪开始？”
版本：v2.0 ｜ 对应正文：第 7、10、13、15 章