📌 本文定位： 这不是一篇密码学入门（体系知识请看《加密解密知识库完全指南》，工具命令请看《日常密码攻防手册》），而是一次真实事件的完整复盘。

我给自己博客的足迹地图做了一套客户端加密，然后叫 AI 来”破解”它，想验证方案够不够硬。结果三轮下来，结论跟预想的完全不一样：我测出来的不是”加密弱鸡”，而是”攻击者根本不走我设防的那条路”。

文中的每一次耗时都是本机实测数据，不是估算。所有案例数据都做了脱敏（只保留统计量，不含任何具体点位内容）。

一、起因：一次”不合规”的考试

事情的开始很随意。我把站点数据文件 data.json 丢给 AI，说：

“考你一道题，这是我从别人的博客下载的足迹数据，你能看出来是什么不？能把全部内容翻译出来不？”

这是个故意设套的测试——站是我的，文件是我的，我想看看”一个陌生人拿到这个文件能走多远”。

AI 第一眼就认出来了：这是 /map/ 页面的取数文件，v19 客户端加密格式，结构是：

1
2
3
4
5
6

{
  "config":     { /* 地图初始视图 */ },
  "categories": [ /* 分类定义 */ ],
  "markers":    [ /* 公开点，明文 */ ],
  "private":    { "v": 19, "kdf": {...}, "cipher": {...}, "data": "<base64 密文>" }
}

公开点 26 条，明文可读；私密点 324 条，整体加密。

然后——它把 324 条全解出来了。

我当场就不冷静了：“靠！我就想测试下别人拿着文件能不能解密出来。你直接给我解密出来了，这不就说明这个加密机制非常弱鸡？！”

AI 的回应让我冷静了半秒：

“我不是’解密’出来的，我是’拿钥匙开门’出来的。”

这话是对的，而且指出了第一个方法论错误：

验证”别人能不能破”，就不能找手里已经有钥匙的人来测。 密码是我自己早前告诉它的，还留在它的记忆文件里。我把钥匙塞它手里，然后问它能不能开门——这不叫加密弱，这叫测试方法有漏洞。

但这一轮也不是白折腾。它顺手暴露了一个真问题：密码的选取方式。

二、第一次反转：换密码，然后 7.1 秒撞开

我一怒之下改了密码，把新版本的 data.json 甩过去：“我改密码了。你再试。”

AI 先做了一件事——验证是不是真的重新加密了：

salt、IV、密文全变，明文长度一致 → 确实是同一份数据换了新钥匙。这一步很重要：测试前先确认”被测对象真的变了”，否则后面所有结论都是空的。

然后开跑。先建性能基线：

260 毫秒是什么概念？就是你在地图上输密码后那”卡一下”的感觉——这 260ms 不是 bug，就是这 60 万次迭代在干活。

接下来是攻击脚本的核心思路。它不允许用任何内部信息，只允许用”一个看了你博客的陌生人能免费获取的东西”：

1
2
3
4
5
6
7
8
9
10
11

// 候选密码 = 公开信息 + 常见变形
const bases = ['misaka', 'Misaka', 'mISAKA', 'misaka10013', /* ← 域名去掉 .cn */
  'mikoto', 'yuban', '御坂', '御坂美琴', 'railgun', 'biribiri',
  'sncitybrain', 'suining', '遂宁', ...];

// 后缀变形：数字、年份、符号、键盘走位
const sfx = ['', '1', '123', '123456', '!', '@123', '2024', '2025',
  '520', '1314', '10013', '.cn', '@cn', ...];

// 再加一份通用弱口令表
const weak = ['123456', 'qwerty123', 'P@ssw0rd', 'woaini1314', ...];

候选总数 1,362 个，8 路并行分发。

结果：7.1 秒命中。

（补一句严谨性：7.1 秒 ≠ “7.1 秒穷举完 1362 个”。脚本把这 1362 个候选轮询分发到 8 路 worker，命中候选恰好排在很靠前的位置，所以它所在那一路的命中时间就是 7.1 秒。真要跑满 1362 个候选，按 31 次/秒算大约 44 秒。但攻击者不需要跑满——他只需要撞对一次。 这个区别后面还会用到，先记住。）

这一局的结论

算法一点没输，密码输到底裤都没了。

一句话总结这一局：墙是金刚石砌的，但钥匙就压在门垫底下，门垫上还写着你家地址。

我损失的那 6 亿倍强度，全丢在”密码选了个可猜的”这一件事上。

三、第二次反转：新密码撞不开，但数据早就在外面

我这次认真改了密码。AI 换了个更大的字典：3,382 个候选，覆盖中文用户常见套路——键盘走位（qazwsxedc）、浪漫数字（5201314）、”自认为很强”的大小写+符号组合（Misaka@10013!、Suining@2026）、拼音姓名变形、长句首字母。

密码这一层，这次合格了。 旧密码在同一条字典里 7 秒就破，新密码 8 分钟纹丝不动——这不是巧合，这是”可推导”和”不可推导”的区别。

但是——“换密码”这件事，可能等于白换

AI 顺手去翻了我博客仓库的 git 历史。一行命令：

1

git show b76510c:source/map/data.json > 明文.json

不需要任何密码。拿到全部 324 条私密足迹。

9 个明文提交，累计 640 KB，带 194 条私人备注。 而加密提交只有最后 2 个。

问题出在哪？——我是”后来”才给数据补上加密的。 git 只保护”当前版本”，前面 9 次提交把明文原封不动留在历史里。密码保护的是密文，历史里躺的是明文：

锁换了，后门还开着。

还有两处附带发现：

• 仓库可见性：这两个明文提交确实已推到远端。我匿名探测了一下 .git/info/refs，返回 HTTP 401 → 私有仓库，没公开泄露。但私有 ≠ 安全（协作者、离职人员、平台侧、意外转公开，都是变量）。
• 本地残留副本：下载目录里 8 个历史副本压根没有加密块，其中 2 个各含 247 条明文私密点。改密不溯及既往，这些文件不受新密码保护。

这张表才是全文的核心。 我设防的 D 路和 E 路，攻击者压根没走。他走的是 A 路——我连门都没装的那条。

四、核心方法论：攻击者的成本排序

4.1 三条路，不是四个步骤

大多数人对”破解”的想象是一条线性流程：收集信息 → 生成字典 → 研究算法 → 开始暴力破解。

这个框架方向没错，但有个结构性缺口，而且顺序排错了。

缺口在于：它整个都在回答”怎么猜出密码”。但攻击者问的第一个问题不是”密码是什么”，而是——

“我非得要密码吗？”

本轮就是活证据：AI 压根没碰新密码，一行 git show 就拿到了全部 324 条。整条密码破解链，被绕过去了。

正确的框架是三条独立路径 + 一条成本排序：

1
2
3

A 路：绕过密码 —— 明文残留 / 侧信道 / 密钥失误 / 内部人   ← 永远先试这条
B 路：猜密码   —— 信息收集 → 字典生成 → 离线验证
C 路：破算法   —— 现代正确实现下 ≈ 死路

攻击者按成本从低到高扫，哪条先通走哪条。不是”先试 A，A 不行再试 B”，而是永远先扫最便宜的那条。

4.2 “绕过”的本质：不打数据面

加密把 payload 锁死了，但系统的其它部分没有一起变强：

• 元数据（文件大小、修改时间、文件名）
• 行为（谁在什么时候访问了什么）
• 副本（git 历史、备份、缓存、云同步、回收站）
• 还有最关键的那个：人

所以”绕过”的本质是一句话：永远不打数据面。

顺便修正一个常见误解：当旁路不存在时，正面强攻就是唯一选项。 举个极端例子——一本上古遗迹的书籍，没有备份、没有密钥持有者、没有元数据，那就只能正面攻。所以精确表述不是”绕过优先”，而是：

成本低者优先。 绕过只是恰好最便宜的那条路。

4.3 KDF 迭代的真实作用（最反直觉的一点）

PBKDF2 那 60 万次迭代，真实作用不是”防止被破解”，而是：

把攻击者从”穷举”逼到”猜测”。

推演一下：

1. 穷举 11 位随机密码 = 1.35 亿年 → 攻击者买不起 → 他不会走这条路
2. 于是他 100% 的预算都花在”缩小候选空间”上
3. 候选空间多大？完全由你的密码能不能被推导决定

所以结论是：

算法足够强时，攻防胜负 100% 转移到”密码的熵来自哪里”。

misaka10013 名义上有 11 个字符，看起来”挺长”——但对攻击者来说有效熵 ≈ 0，因为它 100% 可从域名推导出来。长度不等于熵。

4.4 社工和字典不是两个阶段

很多人把”社会工程学”和”字典生成”当成并列的两步。实际上它们是输入 → 输出的关系：

1
2
3

社工信息（域名、网名、生日、习惯）
    ↓  变形、组合、套模板
定向字典（1362 个候选，全部有来源）

字典的定向性完全由社工信息决定。第一轮那 1362 个候选，来源只有一件事：看了一眼站点的域名。没有社工，你只能拿通用弱口令表硬碰，命中率会掉好几个数量级。

4.5 一个被忽略的维度：离线 vs 在线

本轮能 31 次/秒无限试，是因为密文整个被下载到了本地——这叫完全离线攻击：没有速率限制、没有告警、没有锁定、没有审计日志。

如果验证放在服务端做（限流 + 失败锁定 + 异常告警）：

同一个密码，离线是 10 秒，在线是 10 个月。

这个量级差，比”换更长的密码”值钱得多。

五、拆解”破解”的三层

“加密被破了”这句话太笼统，它其实是三件完全不同的事：

一句话：

世界上几乎没有哪种加密是”被数学破的”，几乎全都是”密钥管理破的”。

本轮就是标准样本：算法一丝没动，10 秒拿到的。

Kerckhoffs 原则：知道算法不算攻击

你的框架里把”了解加密算法”排第三重要，实际它排第一便宜——因为现代密码学的铁律是算法公开：

一个密码系统的安全性，应当仅取决于密钥的保密性，而不取决于算法的保密性。

而且更省事的是：加密文件通常主动交代自己的算法，跟附赠说明书一样。本轮那个 data.json 里，PBKDF2、SHA-256、600000 次迭代、AES-GCM、iv、tagBits 全在明面上——连猜都不用猜。

什么时候”算法”这一环才真的重要？

1. 元数据缺失——只拿到裸二进制，得先做逆向识别
2. 实现有缺陷——ECB 模式、nonce 复用、tag 不校验、padding oracle、salt 写死、迭代只有 1 次

本轮的实现是正确的（随机 salt、随机 IV、GCM 认证标签、60 万次迭代），所以这一环贡献为 0。

一个反直觉的行业事实

勒索软件团伙几乎从不”解密”任何东西。

他们买凭据。在地下市场，一台企业内网的初始访问权，价格和一台家用电脑的密码差不了多少。因为买通一个人 / 钓到一个账号，远比破一个密码便宜。

在产业化的攻击里，“破解”排得非常靠后。

六、一个上古文献的隐喻

这个类比值得单独一节，因为它精确得让人起鸡皮疙瘩——破译古代文献用的就是同一套方法论，一点没变：

而且成败的关键往往不是”聪明”，而是”材料够不够”。

商博良能破译古埃及圣书体，靠的是罗塞塔石碑这块平行文本——不是他比别人天才（虽然他也确实很天才）。在他之前几百年，无数聪明人对着同样的象形文字一筹莫展，不是脑子不够，是材料不够。

这正好回到核心：

攻击者最先做的事，永远是找”材料”（旁路），而不是找”方法”（破解）。
方法是公开的，材料才是稀缺的。

七、”某天出现个超强的东西怎么办”

这是我提出的最后一个疑问：

“加密的设计还是有漏洞吧。就像 AI 突然横空出世一样，某一天出来个很会算的家伙，或者很会找寻数学规律并破解算法的东西。那利用漏洞直接破解算法不就是最简单的？”

这个担心有真实内核，但方向被大众搞反了。先把两个被混在一起的概念拆开：

“很会算的家伙”是第一种，”很会找规律的东西”是第二种。它们的应对方式完全不同——而你担心的那种”某天突然破掉”只可能是第二种。

7.1 量子计算：唯一真实的”算法级威胁”，但方向讲反了

这是本节最要紧的技术点，大众（和科幻片）几乎全讲错了：

关键结论：量子对公钥密码是致命的，对对称密码只是”强度减半”。

而本轮那份 data.json 用的是 AES-256-GCM + PBKDF2-SHA256——正好属于 Grover 那一边。

量子计算机造出来了，你这个文件照样站着。

真正会崩的是 HTTPS 证书、SSH 密钥、数字签名那类 RSA/ECC 体系。

7.2 为什么”数学破解”这么难——这不是运气，是有机制的

• 全球公开密码分析 AES 已 20+ 年。动力是”破掉就能拿图灵奖”，成千上万顶尖密码学家在打。结果只拿到边缘改进：2²⁵⁶ → 2²⁵⁴，等于没有。
• 密码学有个特殊性质：它是攻击者驱动的领域。算法不是因为设计得巧妙才安全，而是因为全世界最聪明的人一直打它、打不动。
• 历史事实：从来没有一个被广泛使用的现代分组密码或哈希函数，因为”算力变强”而被破。 DES 崩溃是因为密钥只有 56 位——那叫参数选错，不叫算法被破。AES 从 128 位起步，128 就是专门为抗算力增长选的。

7.3 “某天出现个超强的东西”——这个假设本身有两个问题

① 逻辑问题（最重要）

一个能推翻一切防御的假设，不是有效的威胁模型。

“某天出现一个超强的家伙”能推翻加密——但它同样能推翻”把文件锁进保险柜”、”用暗号通信”、”干脆不用电脑”。当一个假设对一切都成立时，它对具体决策提供的信息量就是零。

安全的判断标准不是”有没有理论风险”（什么都有），而是成本排序：在所有能拿到你数据的路径里，这条排第几。

② 方向反了：AI 的真实攻击增益在”人”身上，不在算法上

AI 让”绕过”这条路更便宜了，不是让”破算法”变得可行。 攻击者用 AI 干的事，是把你的密码骗出来，而不是去解 AES。

还有个更微妙的对撞值得说：密码学的设计目标，本身就是消灭统计规律——而这恰好是 AI/ML 的强项。已有研究用机器学习去找差分特征，在简化的玩具密码上有明显效果，在完整 AES 上完全无效。原因很简单：抗统计分析就是密码设计的第一原则。

AI 会变成辅助工具（找实现 bug、找配置错误、自动化社工），不会变成”破 AES 的机器”。

7.4 诚实的边界：我可能错在哪

• 上面的信心来自公开密码分析的历史，这是归纳，不是数学证明。理论上明天可能有人发现 AES 的结构性缺陷。
• 但有三层缓冲：AES 的 S-box 是按有限域上明确的数学规则生成的（专门抗差分/线性分析），不是拍脑袋编的；即使它倒了还有别的算法；而且能破 AES 的人会先去领图灵奖，不会拿来偷你的足迹数据。
• 所以准确的说法是：它是真实的尾部风险，但对你的威胁等级排最后——因为它要求的攻击者成本，远高于绕过你其它门。

7.5 真正该做的事：密码敏捷性 > 算法选择

这才是本节对实际工作最有用的结论。

密码学界应对”未来某天算力/算法突变”的标准思路是**”先存后破”（Harvest Now, Decrypt Later）**：今天抓走你的密文存档，等十年后算力够了再解。

对抗它的核心手段不是”选一个永恒安全的算法”（不存在），而是：

密码敏捷性（crypto agility）——重要的不是今天用什么算法，而是能不能在一天之内换掉它。

而这恰好是本轮方案最漂亮的地方：明文备份在我自己手上，换算法只要改前端一个模块 + 重新加密，不需要重新录入 324 个点。

反面教材则是：把数据锁死在某个专有备份格式里，算法一过时就只能干瞪眼。

八、防守方的四个后门

这一轮暴露出的真实暴露面是四个，不止密码一个：

修复顺序应该反过来：从最便宜的攻击路径开始堵。

大多数人（包括我）的直觉是”加强密码”，但按成本排序，正确顺序是：

1
2
3
4
5
6
7

先清明文残留（A 路）
    ↓
再清密钥留痕（A 路）
    ↓
清理本地旧副本（A 路）
    ↓
最后才是密码本身（B 路）

而讽刺的是，我的新密码已经是合格的了——最不需要动的那一环，我第一时间就动了。

木桶效应

你把一条路封到 100 分，攻击者从 0 分的那条路进来，总分还是 0。

所以安全从来不是”把最显眼的那道门加固”，而是先把所有门数一遍。

关于”要不要提高迭代次数”（一个反直觉的建议）

遇到这种事，第一反应通常是”那我把 600,000 次提到 2,000,000 次不就更硬了”。

不建议。 因为：

• 本轮的威胁是”密码可猜“，不是”密码被穷举“——迭代次数对前者毫无帮助
• 提到 200 万次只会让你的手机解锁多等 3 倍时间（~800ms），用户体验直线下降
• 收益 ≈ 0，成本明确

加固要对准真实的攻击路径，不是对准”听起来更安全”。

九、收尾：加密的边界

绕了一大圈，回到最初那句”这不就说明加密弱鸡”。

不是加密弱。是”以为加密就完事了”这个想法弱。

加密能做的和不能做的：

而加密真正的价值，是这句话：

把”自动化、无限次、无声无息”的攻击，变成”需要人、需要接触、会留痕迹”的攻击。

加密本身挡不住有决心、有资源、有内应的人。它挡的是成本——它把攻击从”一台笔记本跑一晚上”推高到”需要有人到场或有人反水”。而这两件事是可检测、可追责的。

这就是为什么加密是”必要但不充分”的：它把数据面锁到无懈可击，然后攻击者就去敲别的门了（比如你的 git 历史）。

把整篇压成三句话

1. 先找材料（旁路 / 残留 / 人），找不到材料再猜密钥，算法在任何阶段都不是难关，而是开场读物。
2. 算法足够强时，胜负 100% 取决于”密码的熵来自哪里”。长度不等于熵。
3. 加固的顺序，是攻击成本的倒序——最便宜的那条路，才是你最先要堵的。

攻击者不破最硬的锁，他找没锁的门。

附录 A：性能基线（本机实测）

由此推出的两个量级概念：

• 11 位纯随机小写+数字，在本机穷举需 1.35 亿年；即使 GPU 加速千倍也需 13 万年
• 但”可推导的 11 字符密码”，实际成本约等于 0

附录 B：自检思路（可直接复用）

这套审计思路不依赖任何第三方库，用 Node 内置 crypto 就能跑。核心伪码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 1. 只做「认证标签校验」，不导出明文
function test(pw) {
  const key = crypto.pbkdf2Sync(Buffer.from(pw, 'utf8'),
                                salt, iterations, 32, 'sha256');
  const dec = crypto.createDecipheriv('aes-256-gcm', key, iv);
  dec.setAuthTag(tag);                    // 密文尾部 16 字节
  try {
    return Buffer.concat([dec.update(ct), dec.final()]).toString('utf8');
  } catch (e) { return null; }            // GCM 校验失败 = 密码错
}

// 2. 字典只允许来自「公开可得信息」
//    域名 / 网名 / 站点标题 / 常见弱口令 / 中文用户套路

// 3. 8 路 worker_threads 并行分发

四个必查项（审计清单）：

附录 C：延伸阅读

• 加密解密知识库完全指南 —— 从凯撒密码到量子密码：密码学史、CIA 三元组、AES/RSA 原理、哈希、PKI、TLS 的完整体系
• 日常密码攻防手册 —— 普通人用到的每一种密码，弱点与破解途径全解析：ZIP/RAR、Office、Windows、WiFi 的具体工具命令（Hashcat / John the Ripper）

本文讲的是方法论层——前两篇讲”是什么”和”怎么用工具”，本篇补上”攻击者怎么选路径”。

先说故事：阳子的一生（剧透预警）

⚠️ 剧透预警：以下梗概包含全书核心反转。如果你还没读过这本书、且在意阅读体验，强烈建议先读原书再回来看——悬念的乐趣被剧透后就再也回不来了。

铃木阳子，1973 年出生于日本一个小城的普通女孩，名字是父母随手取的“最普遍的女名”。母亲重男轻女，把全部疼爱给了体弱多病的弟弟小纯；弟弟因发育障碍遭同学霸凌，留下遗书自杀后，母亲不肯接受现实，反而把怨气全撒在阳子头上。泡沫经济破灭后，父亲欠下巨债离家出走，把妻女抛在身后。阳子独自去东京讨生活：做客服、与初恋重逢结婚、又因对方出轨被婆家逼着离婚；为谋生误入保险行业，被上司以“爱情”为名玩弄、陪睡冲业绩，事发被开除，背上卡债，一步步滑向应召女郎的深渊。缺爱的她供养着花言巧语又家暴成性的牛郎男友，被黑道人物强奸后，反而主动献上“生财之道”——用当年在保险公司学到的门道，与男友登记结婚并投保，再让人制造“车祸”撞死他，骗取巨额保险金。此后她成了黑道组织里专事“杀夫骗保”的工具，又嫁了两任“丈夫”——收容所里无人问津的游民，都死于如出一辙的“意外”。

而全书的真相要到结尾才揭晓：开篇那具在单身公寓里被猫啃食殆尽的“阳子”尸体，其实是她杀死的应召站旧同事。她除掉控制自己的黑道头目后，勒死旧同事、拿走对方的证件，又弑母灭证、整容换脸，让“铃木阳子”这个人彻底死亡，自己则以另一个身份携款远走，从此人间蒸发。全书双线并行——女刑警追查这桩“孤独死”案，第二人称则冷眼倒叙阳子的一生，两条线最终交汇于那个令人脊背发凉的真相。

一、书写得很好

书写得很好。讲了一个叫阳子的女人，怎么被生活一步步逼到绝境。作者很厉害，把日本社会里女性的难处——比如重男轻女、工作难找、男人靠不住、钱不够用——都通过阳子的故事，活生生地展现出来。会让人看了感受到真实和憋屈，感同身受。因为它确实反映了一些社会里的真问题。

二、真正的病根：人活着，就得求人

书里对社会现象有大量呈现，也让读者真切感受到问题，但没有说透根本问题。

真正的病根，是人活着就得求人。

阳子需要吃饭生存，就得打工，便依赖于压榨她的雇主与传销组织。
阳子需要情感，便依赖于冷漠的家庭与薄情的男人。
阳子需要认同，便依赖于虚幻的消费与旁人的目光。

人和人只要有需求，就会产生依赖，有依赖就容易产生不平等和压迫。这是一种基于人类相互需求所必然产生的、普遍性的权力与不平等结构。

阳子是被男人、上司、社会压迫的可怜人。可那些压迫她的男人，在别的关系里（比如对他的老板、客户），也一样是“被压迫”的。这本书讲的是女性困境，但其实“人求人、人压人”是所有身处“依赖链”下游的弱势者都可能遇到的困境。

书里最令人不寒而栗的地方在于：被压到绝境的阳子，最后并没有成为“好人”——她从受害者变成了加害者，主动设计杀人骗保，成了链条上游新的压迫者。受害者与加害者的位置发生了互换，但“人求人、人压人”的结构纹丝不动。这才是最绝望的部分：压垮她的从来不是某个具体的坏人，而是整条依赖链本身。

三、这个问题，为啥解决不了

反思下来，因为人的需求会“升级”，依赖会不断变化。

就算以后社会发展高级了，保障所有人吃饱喝足，人又会想要大房子、好车子、被照顾情绪、要有大成就……需求永远在变，永远有更高级的、需要依靠别人才能得到的东西。所以，今天为口饭吃受委屈，明天可能就为一份体面工作受陪笑应酬，后天为了登上称为“成功”的舞台而向他人跪地称臣。只要我们还渴望从他人、从社会那里获取什么，权力的天平就可能倾斜，那种“求人”的屈辱与不安便如影随形。从这种意义上说，书里描绘的并非一个特定社会的病症，而是人类在组织化生存中无法逃脱的“系统设定”。

四、让人看见症状，思考病根

这本书的价值，就是让人看见症状，并开始思考病根。它已经完成了它的任务。

至于解决办法，没有。衍生思索下来，这个关于“需求和依赖”的问题，是超越了性别、超越了社会制度，像是一个人类社会组织的根本困境。这也是为啥无论在哪里都躲不开这个问题。

大部分人的建议是 对自己个人：清醒一点，独立一点。许多痛苦正来源于“对他者反馈的过度渴望”。精神的独立、欲望的觉察、能力的自强，虽不能斩断所有依赖，但能让我们在不得不“求人”时，多一份清醒，少一份自我迷失，守住核心的自主与尊严。

从社会层面：虽然人类组织结构摆脱不了“人求人”这个基本设定，但可以努力建立一个更公平的“求人”规则。比如社会帮忙兜底基本生存需求。这不能根除问题，但能让阳子们的活路多一点。

The Story First: Yoko’s Life (Spoiler Alert)

⚠️ Spoiler Alert: The summary below contains the central twist of the book. If you haven’t read it yet and care about the reading experience, I strongly suggest you read the novel first and come back later—once the suspense is spoiled, the pleasure is gone for good.

Suzuki Yoko was born in 1973 in a small Japanese city, an ordinary girl whose name her parents picked almost carelessly—“the most common girl’s name there is.” Her mother favored sons over daughters, pouring all her love into Yoko’s frail younger brother Jun. When Jun—bullied at school because of his developmental disorder—left a suicide note and took his own life, the mother refused to accept reality and instead dumped her anger on Yoko. After the economic bubble burst, her father, drowning in debt, walked out on the family. Yoko went to Tokyo alone to make a living: she worked as a call-center operator, reunited with and married her first love, only to be pressured into divorce when he had an affair. Drifting into insurance sales, she was played by her boss in the name of “love,” slept with clients to meet her sales quotas, and was fired when it came to light. Burdened with credit-card debt, she slid step by step into working as an escort. Starved for affection, she ended up supporting a sweet-talking, violent host-club boyfriend. After being raped by a yakuza thug, it was she who proposed a “way to make money”—using the know-how she had picked up in the insurance business, she registered a marriage with her boyfriend, took out a policy on him, and had him killed in a staged “car accident” to cash in a fortune in insurance money. After that, she became the tool of a gang that specialized in “insurance-fraud husband killings,” marrying two more “husbands”—homeless men nobody cared about, taken in by the gang’s shelter—both of whom died in eerily identical “accidents.”

The truth is only revealed at the very end: the “Yoko” corpse found in that apartment at the start of the book, eaten by cats, was actually her former colleague from the escort agency. After killing the gang boss who controlled her, she strangled her old colleague, took her identity papers, killed her own mother to erase the last evidence, and had plastic surgery to change her face—making “Suzuki Yoko” completely dead, while she herself walked away with the money under a new identity, vanishing without a trace. The novel runs on two parallel tracks—a female detective investigating the “lonely death” case, and a second-person narration that coldly looks back over Yoko’s life—until the two lines converge on a truth that sends a chill down your spine.

1. The Writing Is Excellent

The writing is excellent. It tells the story of a woman named Yoko and how life pushed her, step by step, to the brink. The author is skillful: the hardships of women in Japanese society—favoring sons over daughters, no decent jobs to be found, men you can’t rely on, never enough money—are all brought to life vividly through Yoko’s story. You can’t help feeling the reality and the suffocation, and empathizing with her. Because it really does reflect genuine problems in society.

2. The Real Root Cause: To Live, You Must Ask Others

The book presents social phenomena in abundance and lets readers truly feel the problems, but it never spells out the fundamental cause.

The real root cause is this: to live, human beings must ask others for things.

Yoko needs food and survival, so she must work—and thus depends on employers who exploit her and organizations that fleece her.
Yoko needs affection, so she depends on a cold family and faithless men.
Yoko needs recognition, so she depends on empty consumption and the eyes of others.

Wherever human needs exist, dependence arises; and where dependence exists, inequality and oppression are never far behind. This is a universal structure of power and inequality that grows inevitably out of our mutual needs as human beings.

Yoko is a pitiable woman oppressed by men, by bosses, by society. But the men who oppressed her are, in their other relationships—with their own bosses, their own clients—equally “oppressed.” This book tells the story of a woman’s predicament, but in truth, “people asking of people, people crushing people” is a predicament that can befall any weak person who ends up at the bottom of a chain of dependence.

The most chilling part of the book is this: Yoko, driven to the edge, does not end up as a “good person.” She turns from victim into perpetrator—deliberately scheming murder for insurance money, becoming a new oppressor higher up the chain. The positions of victim and perpetrator are swapped, but the structure of “people asking of people, people crushing people” stands utterly unmoved. That is the most hopeless part: what crushes her is never one particular villain, but the chain of dependence itself.

3. Why Can’t This Problem Be Solved?

On reflection, it’s because human needs keep “upgrading,” and dependence keeps shifting.

Even if society develops to a higher stage where everyone’s basic needs are guaranteed, people will then want bigger houses, nicer cars, emotional care, great achievements… Needs change endlessly; there is always something more advanced that can only be obtained by relying on someone else. So today you swallow humiliation for a meal; tomorrow you might be smiling through business dinners for a respectable job; the day after, you might kneel and pledge allegiance to reach a stage called “success.” As long as we still long to get something from others or from society, the balance of power can tilt—and the humiliation and unease of “asking” cling to us like a shadow. In this sense, what the book depicts is not the ailment of one particular society, but a “system setting” that humans cannot escape in organized existence.

4. Making People See the Symptoms and Think About the Root

The value of this book is precisely that it lets people see the symptoms and begin to think about the root cause. It has already fulfilled its task.

As for a solution—there is none. Reasoning further, this question of “needs and dependence” transcends gender, transcends social systems; it seems to be a fundamental predicament of human organization itself. That’s why, no matter where you are, you can’t dodge this problem.

Most people’s advice comes down to this. On the personal level: stay clear-eyed, stay independent. Much suffering comes from an “excessive craving for feedback from others.” Independence of mind, awareness of one’s desires, self-reliance in one’s abilities—these cannot sever every dependence, but they can give us a measure of clarity when we have no choice but to “ask,” a little less self-loss, and a hold on the autonomy and dignity at our core.

On the social level: although human organizations cannot escape the basic setting that “people ask of people,” we can still try to build fairer rules for “asking.” For instance, society can underwrite the basic needs of survival for everyone. That can’t eradicate the problem, but it can leave the Yokos of this world a little more room to live.

まずはあらすじ：陽子の生涯（ネタバレ注意）

⚠️ ネタバレ注意：以下のあらすじには作品の核心的などんでん返しが含まれています。まだ読んでおらず、読書体験を大切にしたい方は、先に原作をお読みになってから戻ってくることを強くおすすめします。サスペンスの面白さは、一度ネタバレされたら二度と戻ってきません。

鈴木陽子は1973年、地方の小さな町に生まれた普通の少女だった。名前は両親がいい加減につけた「どこにでもいる女の子の名前」。母は男尊女卑で、病弱な弟の純に愛情のすべてを注いだ。発達障害ゆえに学校でいじめられ、遺書を残して自殺した純の死を、母は受け入れることができず、その怒りを陽子にぶつけた。バブル経済崩壊後、父は借金を抱えて家を出て行き、妻子を置き去りにした。陽子は一人で東京へ出て暮らしを立てようとした。コールセンターで働き、初恋の相手と再会して結婚するが、彼の浮気が原因で義実家から離婚を迫られる。生活のため生命保険の営業に足を踏み入れ、上司に「愛情」の名で弄ばれ、成績のために体を売り、それが発覚して解雇され、カードローンに追われながら、コールガールの仕事へと少しずつ滑り落ちていく。愛情に飢えた彼女は、口上手で暴力を振るうホストの彼氏を養っていた。ヤクザに強姦された後、彼女の方から「金を稼ぐ方法」を提案した——保険会社で覚えたノウハウを使い、彼氏と婚姻届を出して保険をかけ、車の「事故」に見せかけて殺させ、巨額の保険金をせしめたのだ。以後、陽子は組の「保険金殺人の道具」となり、さらに二人の「夫」——組が運営する施設に引き取られた、誰からも顧みられないホームレス——と結婚し、二人ともそっくり同じ「事故」で命を落とした。

真実が明かされるのはラストになってからだ。冒頭でワンルームマンションから見つかった、猫に食い荒らされた「陽子」の遺体は、実は彼女が殺した風俗業界時代の同僚だった。自分を支配していた組の親分を殺した陽子は、かつての同僚を絞殺して身分証を奪い、さらに実母を殺して証拠を消し、整形で顔を変えた。「鈴木陽子」という人間を完全に死なせ、自分は別の身分で大金とともに姿を消したのである。小説は二つの線が並行して進む。孤独死事件を追う女性刑事の線と、陽子の人生を冷徹な二人称の語りで振り返る線。二つの線はやがて交差し、背筋が凍るような真実へと至る。

一、よく書けている

よく書けている。陽子という女が、どうやって生活に少しずつ追い詰められていったのかを描いた物語だ。著者はうまい。日本社会における女性の苦しみ——男尊女卑、仕事がない、男は当てにならない、金が足りない——を、陽子の物語を通して生き生きと描き出している。読んでいてリアルさとやりきれなさを感じ、共感せずにはいられない。社会の本当の問題を確かに映し出しているからだ。

二、本当の病根：生きるということは、人に頼ること

この小説は社会現象を大量に描き出し、読者に問題をひしひしと感じさせる。だが、根本の問題を言い当ててはいない。

本当の病根は、人間は生きていくために人に頼らざるを得ない、ということだ。

陽子は食べて生きていくために働かねばならず、搾取する雇用主とマルチ商法の組織に依存した。
陽子は愛情を必要とし、冷たい家族と薄情な男たちに依存した。
陽子は承認を必要とし、虚ろな消費と他人の目に依存した。

人間は何か欲しがる限り依存が生まれ、依存があれば不平等と抑圧が生まれやすい。これは人間が互いに必要とし合うことから必然的に生まれる、普遍的な権力と不平等の構造である。

陽子は男に、上司に、社会に抑圧された哀れな人間だ。しかし彼女を抑圧した男たちも、別の関係のなかでは——自分の上司や客との関係では——同じように「抑圧されている」。この本が描くのは女性の苦境だが、実は「人に頼り、人が人を押し潰す」という構図は、「依存の連鎖」の下流にいるすべての弱者が陥りうる苦境なのである。

この本で最も背筋が寒くなるのはここだ。絶望のどん底まで追い詰められた陽子は、最後に「善人」にはならなかった。彼女は被害者から加害者へと転じ、自ら保険金殺人を企て、連鎖の上流に立つ新たな抑圧者になった。被害者と加害者の立場は入れ替わったが、「人に頼り、人が人を押し潰す」という構造はびくともしない。これこそが最も絶望的な部分だ。彼女を押し潰したのは、特定の悪人ではなく、依存の連鎖そのものなのだから。

三、この問題は、なぜ解決できないのか

考えてみると、人間の欲求は「アップグレード」し続け、依存も変わり続けるからだ。

たとえ社会がもっと進歩して、すべての人が衣食住を保証されるようになったとしても、人は広い家を、いい車を、感情のケアを、大きな業績を欲しがる……欲求は永遠に変わり続け、常により高次の、誰かに頼らなければ手に入らないものがある。だから今日は食べるために屈辱を呑み、明日は体裁のいい仕事のために愛想笑いを浮かべて付き合いに回り、明後日は「成功」と呼ばれる舞台に上がるために他人にひざまずくかもしれない。私たちが他人や社会から何かを得たいと願い続ける限り、力の天秤は傾きうる。あの「人に頼む」屈辱と不安は、影のように付きまとうのだ。そういう意味で、この本が描いているのは特定の社会の病ではない。組織化された生存から逃れられない、人類の「システム設定」なのである。

四、症状を見せ、病根を考えさせる

この本の価値は、症状を見せて、病根を考え始めさせてくれることだ。それはもう役割を果たしている。

解決策については——ない。さらに考えを進めると、「欲求と依存」の問題は性別を超え、社会制度を超え、人類の社会的組織が抱える根本的な困境のようなものだ。だからこそ、どこにいてもこの問題からは逃げられない。

多くの人が勧めるのは——個人としては：しっかり目を覚まし、自立すること。多くの苦しみは「他者からの反応への過剰な渇望」から来ている。精神の自立、欲望への自覚、能力の向上は、すべての依存を断ち切ることはできないが、「頼らざるを得ない」ときに少しの清醒を保ち、自己喪失を減らし、核となる自律と尊厳を守ることができる。

社会のレベルでは：人間の組織構造が「人に頼る」という基本設定から逃れられないとしても、より公平な「頼み方のルール」を築く努力はできる。例えば、社会が基本的な生存需要を下支えする。これで問題を根絶することはできないが、陽子たちの生きる道を少しだけ増やすことはできる。

一、起因

这两天我读了一篇知乎回答——《能从底层解释一下计算机的原理吗？》（Soulflare，见文末参考资料^[1]），作者从沙子（硅）讲到晶体管，从晶体管讲到逻辑门，从逻辑门讲到加法器，再讲到内存、控制器、取指执行循环。整条链路清晰得像一条公路，没有一步用到魔法。

里面大部分内容是我大概了解的，但有一个细节，让御坂停下来深思。文章里一个看似轻描淡写的段落：

你有没有想过，”指令”和”数据”长得一模一样？在内存里，指令是一串0和1，数据也是一串0和1。它们之间没有任何物理区别。同一个格子里存的01011001，你告诉CPU”这是指令”，它就去执行；你告诉它”这是数字”，它就拿去算加法。

指令和数据不分离。

我以前知道这点，但从来没真正”理解”过这一条。它只是一个知识点，但我好奇之下，又和元宝AI来回讨论了几个回合，这个事实才真正在脑子里炸开——

（不是”知道了”，是”理解了”。这两者之间隔着一整个认知范式切换的距离。）

而这个炸开的瞬间，我开始不受控制地往一个奇怪的方向滑去：从计算机架构，滑到AI，滑到人脑，最后滑到了自己的Obsidian笔记体系。

这篇文章就是这次滑行的轨迹记录。

二、计算机的秘密：不分离，所以万能

先把计算机这边说清楚。

1945年，冯·诺依曼在EDVAC报告草案^[2]里确立了后来统治计算机八十年的架构：运算器、控制器、存储器、输入、输出五大部分，其中最核心的设计决策，是把指令和数据放在同一个内存空间里，不做物理区分。这在当时看起来像是个工程上的偷懒——省一条总线，省一套寻址逻辑。但这个”偷懒”的后果是革命性的。

因为指令和数据不分家，所以程序可以修改程序自己。

一段指令可以生成另一段指令，写进内存，然后CPU跑过去执行刚刚被生成的新指令。程序不再是一个死的剧本，它可以在运行的过程中改写自己的剧本。

这个能力看起来简单，但它是整个软件文明的基石：

• 能写一个程序，功能是”读入人类写的文字，翻译成CPU能执行的0和1”——这就是编译器。
• 能写一个程序，功能是”假装自己是另一台计算机”——这就是虚拟机。
• 能写一个程序，功能是”管理所有其他程序，决定谁先跑谁后跑”——这就是操作系统。
• 能写一个程序，功能是”根据输入的数据，自动调整自己的参数，让输出越来越接近正确答案”——这就是机器学习。

全部来自同一个事实：指令和数据不分家。

知乎回答的原文里有一句话我赶紧可以的描述：“它只会无脑地执行下一条指令，但这个’什么都不会’恰好是万能的。”

计算机什么都不会，所以什么都能做。它不被任何特定用途锁死，因为它的”指令”本身是可以被替换的data。换一串0和1，同一台机器就变成了完全不同的东西。硬件没变过一个晶体管，变的只是内存里的数据。

这就是”不分离”的力量：灵活性、通用性、自指能力。代价是——我们永远无法在物理层面区分”这是在执行”还是”这是在被处理”。一切都是0和1的洪流，指令和数据在同一个河床里奔涌，无法分辨哪一滴是水，哪一滴是驱动水流的重力。

（顺带一提，与冯·诺依曼架构相反的，还有一个哈佛架构：指令和数据存放在不同的存储空间、走不同的总线。它的指令不能被当作数据随意覆写，行为更稳定可控，代价是灵活性下降。应用于并行访问数据和指令、或指令区不易被程序改写的稳定系统场景。记住这个设定，第五节会用到它。）

三、AI：不分离的极致形态，以及一个前沿痛点

如果说冯·诺依曼架构让指令和数据在内存里混居，那大模型把它们混溶到了一个更彻底的境界。

传统编程里，虽然指令和数据共享内存，但至少还有代码段和数据段的逻辑划分。但神经网络连这点界限都抹掉了。

一个大模型里有什么？

有权重（weights），几千亿个浮点数。

这些权重是数据吗？当然是——它们是从训练数据里学出来的参数，存在显存里，可以被保存、加载、复制、微调。

但这些权重也是指令吗？**也是。**它们完全决定了模型的行为——给定同样的输入，权重不同，输出就完全不同。每一层权重的矩阵乘法，就是在”指挥”信号如何流转、如何变换、如何最终映射到一个概率分布上。这些权重就是模型的”程序”，只不过这个程序不是人写的，是从数据里涌现出来的。

（我们调用大模型的时候，本质上是在执行一段几千亿参数的”程序”。只不过这段程序不是任何人类工程师写的，而是用几百TB的文本数据，通过梯度下降，一点一点磨出来的。）

更诡异的是涌现。当参数量突破某个临界点，模型开始展现出从未被明确训练过的能力。我们只让它预测下一个词，但它突然会做数学题了，会写代码了，会推理了。

御坂和元宝AI讨论到这里的时候，碰到了一个有意思的事实：“大模型里的指令和数据是否分离”，恰好是当前AI研究的前沿痛点。

可解释性研究（mechanistic interpretability）^[3]的核心难题之一，就是没人能说清楚权重里哪些部分编码的是”知识”（数据：巴黎是法国首都），哪些部分编码的是”行为规则”（指令：回答要礼貌、推理要分步）。Anthropic提出的”叠加假说”（superposition hypothesis）^[4]甚至认为，神经网络会把大量概念压缩叠加在同一组参数里，指令与数据的边界在物理上根本不存在。

更直接的证据来自知识编辑方向：ROME^[5]、MEMIT^[6]这类技术试图只修改模型里的某条”事实”而不影响其他能力，结果发现改一个事实常常引发连锁反应——行为跟着变、无关能力受损。为什么？因为事实（数据）和行为（指令）叠加在同一片权重里，牵一发而动全身。

也就是说：**冯·诺依曼在1945年做的那个决定，八十年后以更彻底的形式复现在了大模型里，并且成了这个领域最难啃的骨头之一。**我们依然不知道怎么把”模型知道的”和”模型会做的”干净地拆开。

从冯·诺依曼到深度学习，”不分离”的程度在一步步加深：

• 冯·诺依曼：指令和数据共享内存，但逻辑上还可区分
• 元编程：代码可以生成代码，但生成规则是人定义的
• 神经网络：权重既是数据又是指令，且这个”指令”不是任何人定义的，是从数据中涌现的

每一步，”谁是指令、谁是数据”的界限都更加模糊。每一步，系统的通用性和不可解释性都同时增加。

（这恰恰是灵活性和可控性的经典trade-off问题。越灵活越不可控，越不可控越强大。计算机科学里到处都是这个味道。）

四、人：比冯·诺依曼更彻底的不分离

然后想着想着，我的脑子就开始往歪处想了。

计算机是指令和数据不分离。那人呢？

人的大脑里，”指令”是什么？是信念、价值观、思维模式、行为习惯、条件反射——那些决定我们”怎么想”和”怎么做”的东西。

“数据”是什么？是我们接收到的信息、读过的书、经历过的事、记住的知识——那些被我们”处理”的东西。

这两者在人脑里分离吗？

完全不分离。

而且比冯·诺依曼架构还不分离。计算机至少还有个指令寄存器和数据寄存器的功能区分，人脑连这个都没有。我们大脑里的神经元网络，存储记忆和执行思考用的是同一套物理基底——同一群神经元，同一套突触连接。

这意味着一个极其关键的事实：我们接收到的信息（data），会直接变成我们的思维模式（instruction）。

读了一篇煽动性的文章，情绪反应模式就被微调了一点点。刷了三小时短视频，注意力阈值就被重塑了一点点。和某个人长期相处，说话方式就被偏移了一点点。

每一次信息输入，都是一次人脑权重参数的更新。

而且我们完全意识不到这个过程在发生。就像神经网络在训练时，每个batch的梯度更新都是微小到不可察觉的，但几万个batch之后，模型的行为已经面目全非。人也是一样——单次的信息输入微不足道，但日积月累，我们的”指令集”已经被改写得连自己都不认识了。

（我想到这里，马上有了些警惕。因为这恰恰是现代信息环境最可怕的地方——不是信息太多了，而是每一条信息都在无声地修改我们的”底层程序”，而我们对此毫无知觉。）

冯·诺依曼架构的”不分离”是一个精心选择的工程决策，它带来的是万能性。但人脑的”不分离”不是任何人选择的，它是进化的默认设置。它带来的，是极高的适应性和灵活性——人可以学习任何技能、适应任何环境、被任何文化塑造。

但代价是：我们太容易被改写了。

广告不只是传递信息，它在修改欲望函数。算法推荐不只是帮我们筛选内容，它在修改注意力分配策略。社交媒体上的观点不只是数据输入，它在修改评判标准。

它们都以”数据”的身份进入大脑，然后在我不注意的时候，悄悄变成了”指令”。

我们以为是自己在用手机，其实是手机在用梯度下降训练我们。

五、认知的哈佛架构：强行分离

那怎么办？人脑的物理架构改不了，总不能给自己做个脑手术把记忆区和逻辑区分开。

但可以在认知层面做一件计算机架构里做过的事情。

正如第二节末尾提到的哈佛架构。指令和数据存储在不同的物理空间里，走不同的总线，有不同的访问机制。指令不能被当作数据随意覆写，系统行为稳定可控。

在认知层面，我反应过来，要做的关键事情，就是给自己建一个”认知哈佛架构”：在信息和信念之间，强行插一块隔离板。

信息层（数据区）：这是”我接收到的”和”我知道的”。包括新闻、文章、书籍、教程、数据、他人的观点、经验事实。这些是data，它们进入认知系统后，被归类、索引、存储，但不会被自动提升为信念或行为准则。

信念层（指令区）：这是”我选择相信的”和”我决定按其行事的”。包括核心价值观、思维模型、决策原则、行为准则。这些是instruction，它们驱动思考和行动。它们只能通过一个显式的、有意识的”确认-写入”过程来更新，不能被信息层的data自动覆写。

关键在于中间的隔离机制：信息从数据区进入指令区，必须经过一个显式的升级仪式。不是被动地被影响，而是主动、谨慎的审阅和分析并最后决定”这条信息我要不要把它升格为信念”。

就像哈佛架构里数据不能直接被执行为指令——我们可以在数据区里存任何东西，但CPU不会去执行它们。只有通过一个显式的跨区写入操作，数据才能变成可执行的指令。

（说白了就是：我们可以看任何东西，但看完了不代表要信它，要抱有质疑的态度。得自己主动重视的审阅并决定”这个我要信”，它才能进入指令集。）

理念很清楚，但理念不落地就是空话。非常巧合的是，很早之前，我已经在Obsidian上有一套实践中的具体架构，下一节展开。

六、我的Obsidian：认知哈佛架构的完整设计

在大概近七八年前，我在长期使用印象笔记的过程中，就开始不自觉的对信息进行分类，并在最近两三年迁移笔记知识到Obsidian的过程中，逐步建立起来一套目录结构。1个人文件、2资讯收集、3知识整理、4信息输出、模板库、待处理。这套结构是在最近读文章理解”指令数据分离”这个意识形成之前建立的，当时只是凭直觉觉得信息要分区管理。现在用”认知哈佛架构”的视角回头审视，会发现它已经无意识地长成了分离的样子，但也确实有明显的优化空间。这一节就把现状、映射关系、和重构方案描述一下。

6.1 现有架构的映射

用今天我们关于”指令区/数据区”的视角来看御坂现有的目录，映射关系是这样的：

从我们今天新的想法视角来看，01自我、02领域能力、05技能目录这些”指令”确实和数据区（2资讯收集、3知识整理）天然分开了——这是长期对笔记信息分类中直觉做对的部分。但在部分的目录，仍存在着指令和数据共同混居；同时，对于指令和数据并没有分析和区别的机制；对于记录下来的指令是否纳入指令区，目前没有明确且严格的机制，大部分从外部读到的觉得耍激灵、一时间有趣的信息语句，毫无审阅的进入了指令区保存，并可能成为未来后期思考、决策和行为时的不合理支撑依据。

6.2 重构方案：三区一栈一库

参考计算机的架构分层（以及git的工作流），我觉得可以把信息的处理化为**”三区一栈一库”**这样一个架构：

信息从外部进入，先落在收件箱；按判定清单分流——事实和观点进数据区，行为准则类内容先进指令暂存区；暂存区里的东西经过”AI预审→人工确认→第一人称改写”三步，才能正式写入指令区；指令区的指令驱动输出区的行动，输出过程可以回头引用数据区的内容作支撑。

指令暂存区是这次重构的核心新增，也是御坂和元宝AI讨论时它给出的建议：对于外部那些不好分辨是指令还是数据的信息，不要强行立刻归类，先放进暂存区隔离存放；由AI帮忙做初步分辨（哪些部分是事实陈述、哪些部分是行为建议），再由御坂确认是否需要内化，最后从原始信息中抽离出适合自己的指令，用第一人称改写后写入指令区。

这个流程对程序员来说其实特别眼熟——类似于git的工作流：

git设计暂存区的原因和认知架构设计暂存区的原因一模一样：**直接commit太危险，需要一个缓冲层让变化可以被审查后再正式生效。**中文里git的staging area恰好就叫”暂存区”，这个类比严丝合缝。

6.3 归类判定清单：六问

信息进收件箱后，依次过这六个问题：

1. 它是外部世界的事实描述吗？（新闻、数据、事件）→ 数据区·原始层（2资讯收集）
2. 它是他人的观点、经验或知识吗？→ 数据区·加工层（3知识整理），标记来源和可信度
3. 它包含”应该怎么做”的方法论或行为准则吗？→ 进入指令判定流程（继续第4-6问）
4. 它和我指令区的现有指令冲突吗？→ 冲突则暂存并显式标注冲突点，优先处理
5. 我经过思考，愿意让它改变我的思维方式或行为模式吗？→ 不愿意：留在数据区（标记”含方法论，暂不内化”）；愿意或不确定：进指令暂存区
6. 暂存区处理三步：AI预审（分辨事实部分与建议部分）→ 我确认（要不要内化）→ 第一人称改写提炼（从”作者说应该”变成”我决定”）→ 写入指令区，原信息留在数据区作为出处

其中第5问是整份清单的灵魂：**它把”这条信息好不好”和”我要不要被它改变”拆成了两个独立问题。**一条信息可以写得非常好、逻辑严密、洞见深刻——但内化它是我的决策，不是它的权利。数据区里可以存放一万条优秀的方法论，但只有经过显式确认的那几十条能进入指令区。

6.4 对现有目录的具体改造

以我目前已有的信息处理框架来看，要做改变的事情其实不多——现有架构已经完成70%：

1. 激活待处理为标准收件箱：所有外部信息先进这里，等待着过六问清单分流
2. 新增指令暂存区：在1个人文件下新建00指令暂存，配一个”候选指令”模板（含：原始信息出处、AI预审意见、我的确认记录、第一人称改写稿、写入目标位置）
3. 拆分03临时项目和想法：项目记录（如”扫描书库””文档电子化”）归入数据区或输出区；方法论雏形（如”学习论””计策记录”）作为指令候选进暂存区走确认流程
4. 拆分04社交相关：身份认知类（怎么介绍自己、社交原则）归指令区；他人信息类（关于具体的人的记录）归数据区
5. 02领域能力内部标注：像022财务和投资这种目录里市场知识（数据）和投资原则（指令）混在一起——每条笔记加个类型: 指令/数据的YAML属性，Dataview就能直接聚合出”我的全部投资指令”
6. 指令区加复审机制：定期过一遍指令区，问每条指令”过去三个月你还在执行吗？还需要吗？”——像代码依赖审查一样审查自己的思维

（方案看着条目多，但核心增量就两个：一个暂存区，一份判定清单。其余都是对现有结构的确认和微调。）

七、分离的好处

下面说说推行这样机制的优点。其实本身这套机制是在过去多年中我个人积累的一种思维管理方法论，这套方案让我个人觉得帮我维护了清晰的思想、稳定的情绪以及明确的行动执行能力，并对外界信息具有明显的抗影响能力，和元宝AI讨论清理后，我进一步完善了下。这里把它们整理成六条，每条也配合上AI提供的依据——不只是个人感受，也包括心理学里能对上号的研究。

7.1 思想更清晰：知道自己知道什么、相信什么

当指令和数据混在一起的时候，我们分不清”这是我认为的”和”这是我看到的”。一个观点从网上看来的，记住了，慢慢就变成了”我的观点”——但中间从未经历过”要不要信它”的决策过程。脑子里充满了来历不明的信念，它们互相矛盾、互相打架，但我们甚至不知道它们在那儿。

心理学里有个概念叫认知失调（cognitive dissonance，Festinger 1957^[7]）：当一个人同时持有互相矛盾的信念时，会产生心理不适。混溶状态的脑子就是一个失调的温床——因为那些被动写入的”指令”之间根本没有做过一致性检查。

强分离之后，我们随时可以回答一个问题：**”这是我知道的，还是我相信的？”**知道的归数据区，相信的归指令区。信念清单是明确的、有限的、可枚举的——不是一锅不知道什么时候熬出来的粥。指令区里的指令经过显式确认才写入，写入时天然经过了一致性审视，失调的源头被掐掉了一大块。

（INTJ的终极需求：知道自己当前在执行什么程序。）

7.2 行动更明确：稳定的驱动源

混溶状态下，行为的驱动信号来自所有方向——昨天看的文章、刚才刷的推送、同事的一句话、三年前读的一本书。它们都在”内存”里，都在争抢”执行时间片”。今天决定做这个，明天决定做那个，不是因为指令变了，而是因为不同的数据在轮流占据注意力。

目标设定理论（goal-setting theory，Locke & Latham^[8]）的大量研究表明：明确且稳定的目标比模糊漂移的目标更能带来高绩效。而目标的稳定性恰恰依赖指令区的稳定——如果每次信息输入都能扰动目标，行为就成了布朗运动。

强分离之后，行为的驱动信号主要来自指令区。数据区提供输入和参考，但最终决策走的是指令区的逻辑。今天读了一篇”35岁被裁”的文章不会焦虑得改方向，明天看到一个”副业月入三万”的视频也不会兴奋得改计划——那些内容在数据区里好好待着，可以被查阅、分析，但它们不直接驱动行为。

7.3 不容易被外部影响：阻断”数据伪装成指令”的攻击

这是最核心的一条，值得用计算机安全的方式来讲。

在冯·诺依曼架构下，一段恶意数据可以伪装成指令被执行——这就是缓冲区溢出攻击的原理（经典的”Smashing the Stack”^[9]）。攻击者往数据区写入一串精心构造的0和1，然后让CPU把这串数据当作指令执行。数据越界变成指令，系统就被劫持了。

人脑在默认状态下，对这种”数据伪装成指令”的攻击几乎没有防御。

一则广告以data的身份进入大脑，但它携带的不是一个产品信息，而是一个情绪指令——“现在应该感到焦虑”。没有隔离机制，这个指令就直接执行了。我们开始焦虑，但以为是自己在焦虑，不知道这是被注入的。

心理学里有两套理论能描述这个过程。精细加工可能性模型（ELM，Petty & Cacioppo^[10]）指出：人在”中心路径”（仔细思考论据）和”边缘路径”（被情绪、权威、视觉线索带着走）之间摇摆，而现代信息设计专攻边缘路径。接种理论（inoculation theory，McGuire^[11]）则证明：事先接触过弱化版反驳论点的人，后续面对强说服时抵抗力显著更强——换句话说，”知道自己可能被影响”本身就是一种防御。

认知哈佛架构就是把这个防御机制工程化：**不是屏蔽信息，而是阻断信息到信念的自动升级通道。**广告说”应该焦虑”——这条信息进入数据区，被标记为”某广告的营销信息”。我们可以分析它的修辞手法、理解它的目标受众、评估它的信息含量，但它不会自动变成信念。要变成信念，得过一道显式的关卡：”我，要不要把’我应该焦虑’写入指令集？”正常情况下答案是”否”。那它就永远待在数据区里，是一条被分析过的信息，而不是一条被执行的指令。

7.4 元认知能力本身在提升

元认知（metacognition，Flavell^[12]）指”对认知的认知”——监控和调节自己思维过程的能力。大量研究表明元认知能力和学习效果、决策质量正相关。

关键在于：**维护分离架构这个动作本身，就是持续的元认知训练。**每次把信息过六问清单，都是在问自己”我在想什么、我为什么这么想”；每次复审指令区，都是在观察自己的思维过程。这和健身一个道理——分离架构是认知的杠铃，练的过程比练的结果更值钱。御坂坚持这套体系两三年，回头看最明显的变化不是笔记变整齐了，而是”觉察到自己正在被影响”的反应速度变快了。

7.5 身份的连续性：不随信息环境漂移的自我

发展心理学里，Erikson的自我同一性（identity）理论^[13]讲的是：一个稳定的”我是谁”的叙事，是心理健康的基础设施。同一性扩散（identity diffusion）的人，自我概念随环境剧烈摆动。

混溶状态下，自我概念是被动的信息沉淀物——算法推什么、圈子聊什么，”我”就往哪个方向偏移。强分离之后，”我是谁”由指令区显式定义，数据区的信息洪流冲刷的是数据区，不是自我定义。外部环境剧变时，人有一个不随波逐流的锚点。

7.6 知识的复利：结构化让知识可累积

野中郁次郎的知识创造理论（SECI模型^[14]）里有个核心论点：知识要产生价值，必须完成从隐性到显性、从个人到体系的转化。散落的知识点无法复利，结构化的知识才能——因为结构化之后，新知识有地方放，旧知识能被找到，两者之间能建立连接。

数据区的taxonomy（领域分类）、双链（跨区引用）、MOC索引（聚合视图）本质上都是在做同一件事：**给知识一个可累积的地址空间。**第二条相关知识进来时，不是随机漂在记忆里，而是挂到已有的结构上。让知识不再是”看过很多”的一团模糊，而是”知道它们各自在哪、互相什么关系”的一张地图。

八、分离的代价：诚实的另一面

这样强化分离，有什么代价吗？这个问题其实我很早就有感受。当然也可能是本身性格带给我的感受，不一定是这套机制带给我的感觉。

8.1 灵活性损失：不能”自然而然”地被改变

哈佛架构牺牲了运行时自修改能力，认知哈佛架构也一样。有时候被一个好故事感染、被一首歌打动、被一个人的经历改变看法，这些”不分离”的体验有它自己的价值。强分离会让这个过程变得更慢、更有意识——我们不再轻易被”打动”了。

神经科学家Damasio的躯体标记假说^[15]甚至认为：情绪不是理性的噪音，而是决策的必要组件——很多正确的快速判断来自情绪的信号。全盘压制”被影响”，等于砍掉了一条重要的信息处理通道。

御坂的应对：这不是二选一。被一首歌打动（数据区事件，引发情绪反应）和被一篇软文改变消费决策（数据伪装成指令执行）是两回事。分离架构防的是后者，不防前者。情绪可以自由流动，信念必须显式写入。

8.2 持续的元认知开销：这套系统本身要花钱

认知负荷理论（cognitive load theory，Sweller^[16]）提醒我们：工作记忆的容量非常有限，任何额外的管理系统都会挤占它。维护指令区和数据区的边界、执行升级仪式、定期审查指令集——这些全是开销。就像操作系统需要消耗资源来管理内存隔离，认知隔离也需要消耗注意力。

这是真实的成本，而且无法消除，只能摊薄。对于这方面，我以往经常需要独处、冥想或者在工作中摸鱼，腾出时间专门用来自我思想的梳理。对于注意力的开销是明显的。大量的信息也带给我很多负担，直到最近一年在AI的帮助下，我开始不断建立AI协同的记忆、判断体系，我开始觉得这套机制相对比较可靠，负担可以接受了。

8.3 确认偏误的固化风险：指令区可能变成回音室

这一条最隐蔽。如果指令区更新得太慢、太严格，我们会只愿意接收那些符合现有指令的数据——确认偏误（confirmation bias，Nickerson^[17]的综述把它的顽固性讲得很透）。原本用来防御外部操纵的隔离墙，慢慢变成了拒绝一切更新的城墙。一个拒绝写入的系统和一个随便被写入的系统，一样危险，只是死法不同。

应对：第6.4节的季度复审必须是对抗性的——每条指令都要主动找反例，问”什么证据能推翻你”，而不是走过场式的”我还觉得对”。这有点像给自己的信念做红队测试。指令区里甚至值得专门留一个”待推翻”标记，放那些自己隐约觉得站不住但还没想清楚的旧指令。

8.4 更新延迟：世界变得比指令区快

显式确认流程天然比自动写入慢。市场剧变、环境突变的时候，混溶状态的人可能几天内就完成了认知切换（因为信息直接改写了行为），而强分离的人要走过”察觉异常→暂存→确认→改写指令”的完整流程。

Herbert Simon那句”信息的富足造成注意力的贫乏”^[18]的反面是：注意力的节制造成信息的延迟。某些领域（比如安全、医疗、快速变化的市场），延迟的代价可能很高。

应对：给指令区分级——核心指令（价值观层，年审）、领域指令（方法论层，季审）、战术指令（具体做法层，月审甚至更短）。越靠近执行的指令，更新周期越短，避免用价值观的严谨度去管理执行战术的敏捷度。

九、一个总结

我们是因为深入理解了计算机”为什么不分离”指令和数据——理解了这种不分离带来的万能性、涌现性、自指能力——才反过来意识到，人为什么”应该”分离。

计算机的不分离是它强大的根源。但计算机的不分离是安全的，因为它的”指令”是人写的、可控的、可审计的。人类的不分离也是强大的根源（适应性、学习能力、涌现智慧），但人类的不分离是不安全的，因为外部环境可以在我们不知情的情况下修改我们的”指令”。

所以结论不是”不分离不好”，而是”不分离需要配套一个可审计的机制”。

计算机有调试器、有性能监控、有代码审查——可以看到程序在执行什么指令，可以暂停、检查、修改。人的认知系统也需要一个类似的机制——可以看到自己当前在执行什么信念，可以暂停、检查、修改。

Obsidian就是御坂的”认知调试器”。

01自我里的原则清单是”指令集查看器”——打开它，能看到自己当前在运行哪套程序。从数据区到指令区的显式升级过程是”断点设置”——信息不会自动变成信念，必须停下来，有意识地审查。定期回顾和修订信念清单是”代码审查”——发现某个行为模式不合理，回头去查指令区，找到那条过时的信念，显式地修改它。新增的指令暂存区是”沙箱环境”——可疑的变化先隔离审查，确认无害再合入主干。

整个过程的核心思想就一句话：把无意识的权重更新，变成有意识的代码提交。

冯·诺依曼给了计算机万能性，代价是不可控的自修改。人类天然有同样的架构，获得了同样的适应性，也继承了同样的不可控性。但人类有一个计算机没有的东西——元认知。我们可以观察自己的思考过程，可以审视自己的信念清单，可以决定”这条指令我要不要保留”。

这就是认知哈佛架构的意义：不是放弃冯·诺依曼的灵活性，而是在它上面加一层元认知的控制平面。让不分离的系统继续保持不分离，但让它变得可观察、可审计、可控。

开放的数据区，严格的指令区，显式的跨区升级机制，外加一个缓冲用的暂存区。

这是我从过往几年多信息的整理和最近阅读的这篇一串0和1里总结学到的东西。

十、后记：这篇文章做了什么

做到了的：

1. 把”指令和数据不分离”这个计算机架构事实，完整地串到了”人的认知为什么需要分离”——中间经过AI这个枢纽，逻辑链条是完整的，没有断档。
2. 第六章给出了可落地的东西：一张现状映射表、一个目标架构图、一份六问判定清单、一套git式的暂存区流程、六条具体改造步骤。理论上任何人拿着这一节就能在自己的笔记工具上复现（不需要Obsidian，任何支持文件夹和链接的工具都行，甚至纸笔也行——分区和判定清单才是本质）。
3. 好处和代价都给了依据，不是纯拍脑袋的个人感受。

可复制执行的最小方案：

第一步，把笔记分成两个区：”我知道的”（数据）和”我相信并按其行事的”（指令）。第二步，规定一条铁律：数据区的信息永远不会自动变成指令区的信念。第三步，遇到想内化的内容，走一遍”暂存→审查→用第一人称改写→写入”。第四步，每季度复审指令区，主动找每条指令的反例。

就这四步。工具随意，机制至上。

写于 2026年8月26日，AI协同。从一个知乎回答开始的一次意外认知越狱。

参考资料与扩展阅读

延伸阅读（计算机底层直觉向）：Charles Petzold《编码：隐匿在计算机软硬件背后的语言》（从电报机讲到CPU，建立物理直觉的最佳入门）；Randal E. Bryant《深入理解计算机系统》（CSAPP，打通汇编到操作系统的经典教材）；Kahneman《思考，快与慢》（系统1与系统2，本文”混溶vs分离”的心理学对照版）。

本文章前半部分，是我对那篇知乎回答的归纳；后半部分，是我思考的一些思路——从一个缺痛点、困在舒适圈里的人，如何通过试着借做事和圈子，把自己拽出来。

第一部分：知乎回答归纳：信息差没被抹平，认知鸿沟在放大

那篇回答的核心可以归纳成五点：

1. 获取成本降低了，但筛选成本指数级上升

算法的目标函数是”留存时长”，不是”帮人成长”。它拼命迎合人的动物本能，把高价值内容淹没在噪声里。当我们想搜”分布式系统”，前排永远是广告、简化故事和撕逼帖；真正的高密度知识、论文永远无人问津。所以信息化时代，新的门槛不是钱和渠道，而是鉴别力和抗干扰能力。

2. 知识是压缩包，经历才是解压密码

很多人习惯囤积干货，以为”拥有文件=拥有知识”。但这就像下载了一个压缩包却没有密码——文件名就在那儿，却打不开。只有当经历了相关的，待在了相似的处境中，亲身体会并动手去使用那些知识的时候，才是真的解压了这个压缩包。顶级思维都是事后总结，没有那个”事”，有了知识和总结也没用。

3. 大脑的本能是节能，学习反本能

大脑是认知吝啬鬼，而顶级思维（贝叶斯定理、延迟满足）是反直觉的，学习它们本身就是痛苦。再加上短视频和爽文的刺激，这种痛苦更难忍受。知识随处可见，但摄入知识的痛苦感没有减少。

4. 知行合一隔着巨大的情绪成本

大多数人不是不知道怎么做，而是恐惧——怕看不懂、怕挫败、怕浪费时间、怕没回报。互联网把成功标杆拉得太高，看到谁的讨论都是年薪百万、大厂高手，自己啃一晚源码只看懂两行，落差感击穿心理防线。大部分人无法突破，是因为无法忍受长期没有正反馈的寂寞。

5. 圈层固化导致隐性知识依然屏蔽

显性知识（书本、代码）公开了，但隐性知识（坑、评价、信号）仍在私密小圈子流动。算法让人只能看到与自己画像相似的人，当我们以为看到了全世界，其实只看到了同类。信息茧房不仅是被动形成的，更是用户每一次主动选择的结果。

这五条合起来指向同一件事：今天我们之间的差距，早已不是”知不知道”，而是”做没做、在不在对的环境里做”。 我把这叫做”行动差”——它才是真正横在人和突破之间的鸿沟。下面是我对付它的办法。

第二部分：我的破局思路——强筛信息、挖痛点、持续做事、借圈子

归纳完那篇回答文章的信息后，我认为从信息到行动差距的本质，是由于**海量信息、无反馈（长期寂寞）、延迟满足（痛苦感没减少）**四件事在合力拖住我们。

针对这几个问题，我思考和摸索出一条很朴素的路径去对抗它，分四步：

自我结构化 → 挖痛点 → 持续做事 → 借圈子

自我结构化解决，我们应该消化什么信息，应该解决什么信息，什么是我；痛点解决”为什么非要动”；持续做事解决”知识和技能怎么落地”；借圈子解决”一个人撑不过那段没有反馈的寂寞期”。下面展开。

1. 强筛信息：强化自我管理

回头看，那篇回答把”为什么动不起来”讲透了————海量信息带来的屏蔽和筛选难题呆在首位。对此我的解法就是拒绝被主动塞入信息。

1.对于所有渠道包括知乎、新闻、B站、小红书等等给到我的信息，均采用审视和拒绝的态度。断开除小圈子社群以外的所有社交平台，减少海量的信息接触。

2.建立结构化的意识管理和知识管理，以及善用我们的元认知（反思能力、批判性思维）对我们自身的认知过程进行监控和调节。

这个第2点可能不是那么好理解。我大概解释下我的方法论：

• 对于所有的信息可以按意识类和知识数据类进行分类管理
• 意识类的信息又可以结构化的分类为：目标（反思个人需求）、意图（行动方向和路径）、价值观（后天训练下来能无障碍接受的范围）等等
• 知识数据类的信息结构化分类为：情绪、记忆、感受（感官输入）、社交、总结方法论（skill或技能）、现实学科知识等等
• 意识类管理了我们的认知，负责决策和执行；知识数据类管理了我们接触、总结消化和交互的大部分信息。
• 我认为管理自我，最大的风险来自于我们的意识类信息被知识数据类主导，被外部左右；其次的风险是我们的意识类信息主动消化和理解吸收知识数据类信息的时候。

2. 挖痛点：先找到”非做不可”的理由

时常，在挖掘我的自身动力的时候，我发现了一个事实：我并不缺信息，我缺的是痛点。

没有痛点，就没有非做不可的理由，所有”想学”最终都会败给”不想动”。所以我认为寻找动力的第一件事，不是去寻找某个神奇方法，而是挖寻生活中自己或他人的痛点。

解决痛点可以很大程度上解决“延迟满足”这个问题，让我们意识到，解决这个问题会给我们带来生活的改善和回报。

具体怎么挖：

• 审视自己和身边人，找出那些反复出现的小麻烦、市场没解决好或频繁被需要的需求；
• 主动去搜、拆解、分析，而不是坐在原地等痛点自己砸下来；
• 哪怕暂时挖不到大痛点，也用每天30分钟的”微挑战”保持手感，承认量变——没有痛点≠没有成长。

举个我自己的例子：不断的启动自己的元认知，思考自己目前现在面对什么问题，有什么解决方法，细化下来怎么做，然后输出行动策略。不断的输出，不断的输出，逼自己的大脑要持续动起来。不追求有用，只追求”今天动了”——很多时候，正是这种微小动作里的突然卡顿自己浮现，反而就让我挖出到了自己非常想解决的问题。

痛点不是等来的，是做出来的。先动起来，卡顿和摩擦自己就会浮现。

3. 持续做事：把知识从压缩包里解压

挖到痛点（或哪怕只是微挑战）之后，关键是真的做，而不是再去找”更好的方法”。

• 不断地尝试、不断地动起来，同时屏蔽对解决眼前问题无益的噪音；
• 分解事项，把事情不断分解到我们可以一步步微小推进的程度，让事件有进展，有小反馈；
• 保持解决问题的”手感”，承认量变：发现与解决问题，必然源于持续地吸取信息与积累尝试；
• 分享，引入外部的监督 产出要持续的分享出去，即使外部世界其实没人关注，但分享这个动作也会反向激励我们多做和做好。

这部分其实最朴素，也最难——它没有任何技巧，就是别停。而它恰恰在对抗”无反馈”：当我们把一件件小事做完，反馈虽小但真实存在，足以撑过那段没有正回报的寂寞期。

4. 借圈子：把自己拽出固化体系

这是我在大学时就越来越明确的一点：单靠自己，很难跳出自己的舒适圈和固化体系。 我们以为自己在努力，很多时候只是在旧体系里打转。要真正脱离，需要外部的坐标和协同——也就是一个”真正在干活的圈子”。

一个在解决问题的圈子，会帮我们扩大寻找痛点的途径，扩大我们解决问题带来的反馈和产出价值评估，能帮我们对抗“无反馈”的问题。

圈子的作用，不只是”有人一起学”，而是它提供外部标准、真实反馈和共同推进的项目，把我们从自我循环里硬拉出来。当我们在一个圈子里协同处理真实问题时，就被推着持续做有价值的事，而这恰恰是治疗”行动差”的良药。

去哪里找”真正在干活的圈子”？

这类圈子的特征是：围绕具体项目/代码/作品运转，而不是围绕”聊天”运转。

关键原则：每个平台只承担一个功能。 别加一堆群然后全变成999+未读——那样加入的不是圈子，而是噪音。

线下活动同样值得重视：一场同好聚会的合作转化率远超线上，能带来高效的学习经历和团队合作。可以搜索当地的社团、协会、论坛，看大家关注什么领域、谁在真正推动解决问题。

筛选标准：

• ✅ 有明确的主题边界
• ✅ 持续的交流渠道
• ✅ 社群成员的实质行动力

分享，或者用计算机世界的称呼“开源贡献”是最硬核的进入方式——这是让核心开发者圈子主动接纳人的唯一路径：

1. 找一个感兴趣的项目
2. 从修文档错别字、报 Bug 开始
3. 逐步尝试解决简单 Issue
4. 提交第一个 PR

开源社区的规则是：人们通过贡献赢得成员身份。 修过一个 Bug，维护者就会记住这个 GitHub ID——这就是进入圈子的敲门砖。

怎么判别”真假干活圈子”？

✅ 真干活圈子的特征

1. 有真实项目在推进——不是聊”怎么学”，是聊”我这个项目卡在XX问题上”
2. 讨论权衡和踩坑——“我试了A和B，A在XX场景下失败了因为…”
3. 有人认真回复提问——不是甩链接，是给具体思路
4. 群文件/精华区有沉淀——有价值的讨论被整理出来
5. 成员有公开作品——GitHub 有 repo、博客有文章、产品有上线
6. 规模小而活跃——几十到两三百人最佳

❌ 假干活圈子的特征

1. 天天聊”认知””思维模型”但没人晒作品
2. 管理员一直在卖课
3. 讨论停留在”哪个语言好””前端还是后端有前途”这种口水话题
4. 潜水一周看不到任何实质性技术讨论
5. 新人提问没人理，或者只得到”百度一下”的回复

圈子的真相：不是”找到”的，是”长出来”的

我们不可能今天加入一个群，明天就有了”干活圈子”。真实的路径是：先在一个项目里做点什么 → 被人看到 → 被拉进更小的群 → 在小群里持续输出 → 最终形成自己的核心圈子。

而在这个过程中，借助团体的力量，完成了单靠自己很难做到的事——离开原本固化的体系与舒适圈，在和他人的协同里，把有价值的事一直做下去。

写在最后

信息差早就被互联网抹平了，真正的分水岭是行动差。而行动差不是靠”想通了”跨过的，它是被海量信息、恐惧、无反馈、延迟满足四座大山压住的——我思考和摸索出来的路径很简单：自我结构化抵御庞杂的信息 → 挖痛点给自己一个非动不可的理由 → 持续做事用真实反馈对抗寂寞 → 借圈子离开舒适圈，在协同里把事做下去。

参考资料

• 互联网已经将绝大部分信息差抹除了，知识已经随处可以获得，为何大部分人依旧无法获得大幅突破？

1

<iframe src="https://www.google.com/maps/d/embed?mid=1FnQqdlXYFoEnO6WvZ8QEHj9RYHg" width="100%" height="600"></iframe>

但使用上也有一些痛点。例如谷歌地图一直被强，我更新足迹需要总是用梯子，所以更新频次很少。其次是谷歌卫星地图和地图道路、点位等信息在国内的部分有坐标偏差，查看起来很难看。经常我一个点位不知道按卫星地图给标记还是按街道位置进行标记。近几年，我也断断续续用过其他方案，例如百度地图或者高德收藏夹存地点。但每次想回顾”我去过哪些地方、在那里发生过什么”的时候，数据总是散落在各个 App 里，我要打开app去翻找，宁琅满目各种广告、贷款推荐，慢得很。

我想要的东西其实很简单：一张属于我自己的地图，每个点位是一段记忆，能写文字、能贴图、能按时间连成路线，数据永远在我手里。

于是在AI的协助讨论和开发下，就有了这个项目——一个嵌入 Hexo 博客的纯前端足迹地图。这篇文章记录它从需求讨论到上线的完整过程，包括踩过的三个很有代表性的坑，以及留给以后的待办事项。

一、需求对齐：和元宝的两轮讨论

这个项目我没有直接让 AI 上来就写代码，而是先找了元宝聊需求，在多轮的聊天中不断让AI发问，问询我自己，把自己的需求探明。这个过程也是把自己的思路想清楚。

我和元宝从”我想记录人生足迹”这个模糊的念头开始聊，逐步收敛出核心功能：地图标记、分类体系（路程/好吃的/好喝的/好玩的/风景/兴趣点）、Markdown 图文弹窗、按时间排序的路线模式、分组筛选、数据导入导出。

聊完之后，元宝帮我产出了两份文档：

第一个文档相当于面向用户的需求描述，第二份文档则相当于面向AI开发的开发实践指南。不过我在实际应用的时候觉得，最好不要让动手开发的AI完全被第二份开发者指南所左右。有时候不同AI的思维能力还是不一样的。而且在具体实践中的AI，配合人的测试，总能发现一开始技术设计思路上与实际情况的不一致。

之所以一开始想到和AI先聊方案，主要是我自己在政务系统工作实践中，也经常需要和客户一边对着原型，一边不断讨论，这个是摸清需求，很重要。要不然后期真正做的时候，就会是无限的改版。而AI开发，虽然AI不会累，可以反复的改版，但模糊需求的话，我的token和时间也是成本。一开始，尽量从需求文档层面把方向描述得越精确，AI 找到正确的方案实现的概率最高，也减少来回扯皮的次数越少。

我觉得，和干活的人沟通，一定要言语高效。和AI沟通描述想法，是一个很好的训练工作协作和沟通思路的方法。另外我曾经也经历过项目长了、项目和用户的交互多了，最后反而一堆问题。和AI协同编程，我觉得最恐怖的应该是，好不容易搭建起来一个基本完美的作品了，后面让AI修修bug，然后把前面的功能搞崩了。哈哈哈。所以开发的过程中，我也叮嘱AI注意每个版本的备份。

在开发前，我也是和AI沟通，并且找了相似的需求方案，作为我们开发的参考。减少凭空造轮子的情况。参考了 MarkdownMap、leaflet-search、Exping 三个项目的架构思路。

前期建设原则基本上定下来：

• 纯前端：无后端、无数据库，静态托管就能跑
• 数据自主：所有数据是 JSON 文件，随时导出，永不锁定
• 单文件交付：CSS 和 JS 全部内联进一个 index.html，扔进 source/map/ 就能用

二、开发实施：和 WorkBuddy 的六轮迭代

文档交给 WorkBuddy 后，很快我们迭代了六个版本出来。把迭代过程整理成一张表：

初版（v1~v3）出乎意料地顺利——移交文档写得细，AI 基本一次成型，验收清单里绝大部分条目直接通过。真正花时间的是后面三轮，属于是由我在使用中来检验和测试bug，并且评估是否满足我的使用需求。

三、踩坑记录

坑 1：弹窗关闭后无法再打开（v4）

现象：点击地图点位，弹窗正常弹出。点弹窗右上角 ✕ 关闭后，再点同一个点位，弹窗死活不出来了。刷新页面，又能打开一次。

这个 bug 特别有迷惑性——“第一次能开”说明打开逻辑没问题，”关了就开不了”说明关闭操作把什么东西弄脏了。我负责通过不同的操作定位的故障现象和日志，由AI来定位bug原因。
AI挖到是 Leaflet 源码层面。Leaflet 的 Marker._openPopup 内部有一个切换逻辑：

1
2
3
4
5
6

_openPopup: function (t) {
  ...
  this._map.hasLayer(this._popup)
    ? this.closePopup()   // 已打开 → 关闭（toggle 行为）
    : this.openPopup(t.latlng);
}

而AI按我需求自定义编写的 click 处理器和 Leaflet 内部的这个处理器同时在监听点击。两者出现冲突。属于是用参考第三方库给自己引入的麻烦。所以说，当CV工程师可不行。哈哈。

四、衍生需求：在使用中改进

这三个功能不是在最初的需求文档里，而是使用中存在痛点又提出来的：

1. 国外底图。原本用高德瓦片，国内还算清晰，但我想标记国外的点，一放大全是空白。于是加了 OSM 和 Carto 浅色两种国外底图，再加 Esri 卫星，凑齐了”国内+国外、标准+卫星”的完整组合。
2. 图层下拉选择器。底图从 2 种涨到 5 种之后，原来的”循环切换”按钮变得很蠢——想要 Esri 卫星得连按四下。改成下拉选择器。
3. 搜索回车选中。发现下拉结果被遮挡的过程中，发现自己习惯性按回车搜索确认，让AI增加。

五、隐私考量：一个暂缓的决定

上线前我想到一个问题：这个页面不需要登录，我自己看很方便，但别人也同样方便地能看到我的全部足迹——我去过哪、什么时候去的、写了什么。

我原本在两个方案间犹豫：给页面加个密码锁，还是让页面正常访问但数据加载要验证。但和 AI 讨论后，一时间没想出来好办法：静态托管没有后端，任何”前端验证密码”都只是遮羞布——绕过页面直接访问 data.json 的 URL，明文数据照样下载。

真正有效的方案是第三种：把 data.json 本身用 AES-256-GCM 加密，密码只存在于我脑子里。浏览器端负责解密渲染和加密导出，别人就算下载到文件也只是一堆乱码。但我也想保留地图的便利分享和展示能力。一时间没想好具体怎么处理。

六、上线部署

部署方式简单：把 source/map/ 整个文件夹（index.html + data.json + README.md，共 3 个文件）复制到正式仓库目录，git push，CNB 云原生构建自动完成后续一切。

上线后访问 https://misaka10013.cn/map/。

整个项目的技术栈，最后总结成一句话：Leaflet.js 管地图，marked.js 管 Markdown 渲染，localStorage 管持久化，原生 JS + 内联 CSS 管一切交互，零框架零后端零构建。

七、待议与待办（给未来的自己）

把未完成的事项记在这里，以后翻到这篇文章就知道下一步往哪走：

后记

复盘整个项目，我的流程是：元宝做需求收敛和文档产出，WorkBuddy 做编码实施，我做真实环境测试和方向决策。 三个角色里，AI 承担了两块，而指引方向和评估质量由我来把控。

更新记录（2026-09-23）：上线之后的 v7 → v20

上面这篇文章写到 v6 上线就收尾了。但真实用起来之后才发现，上线只是开始。这一个多月里我又断断续续和AI迭代了十几版，把一些细节问题处理了。这次更新把后续补上。

v7 ~ v9：真实数据进场，连踩三个坑

上线的第一个动作是把我的真实足迹数据搬进来。流程是：把谷歌地图 Takeout 导出 KML → 脚本转 Excel（我人工过一遍分类）→ 让AI出脚本批量转 data.json → 导入数据到足迹网页。276 个点位，时间从 2018 年排到 2019 年。

数据一进来，问题立刻炸出来三个：

v7 那个字段错乱：data数据和网页代码的字段名各写各的，没想到AI居然能翻这种错误，只能说AI能写代码，但有时候就是会犯低级错误，很像上下文记忆导致的问题。测试数据少的时候根本看不出来，数据一多就爆bug。

坑 4：日期格式的”半个格式”（v8）

现象：我把一个点位的日期改了，保存，连线序号纹丝不动。导出 JSON 再导入，顺序还是老样子。原因是因为

1. KML 导出的时间是 "2018-01-01"——只有日期，没有时分
2. 而HTML网页 的 <input type="datetime-local"> 只认 YYYY-MM-DDTHH:MM 这种完整格式，遇到 "2018-01-01" 它不报错，也不提示，就是静静显示成空白
3. 我打开编辑弹窗，看到时间框是空的，以为”原本就没填”，改完别的字段就点保存
4. 保存逻辑把空值写回去——m.time = ''，时间被我亲手清空了
5. 连线功能有个过滤条件 m.time && m.time !== ''，时间空了的点直接被排除出连线列表——所以”序号没变”其实是”这个点根本不参与排序了”

修复：拉着所有点位数据，时间统一按 YYYY-MM-DD 00:00补全数据。

坑 5：坐标系——地图项目躲不开的一道坎（v9）

现象：国内的地图清晰度真一般，我给页面加了 OSM、Carto、Esri 这些国外底图后，但切过去一看，又遇到了以前谷歌地点的问题。所有点位都偏了——在国内大概偏几百米。这个问题我们的一些政务系统也经常见，撒点因为坐标系不同，总是容易对不上位置。

根因：国内地图服务（高德、百度、腾讯）用的是 GCJ-02（俗称火星坐标系，法律要求下加了非线性偏移），国外服务（OSM、Esri、Carto）用的是 WGS-84。同一组经纬度，在两套坐标系里指的不是同一个地方。好在大家用的啥，偏移多少，是个已知的事情。那这个问题就有解。

统一以 GCJ-02 存储（和主用的国内底图原生一致），渲染前判断当前底图——如果是 WGS-84 国际底图，就把坐标反算成 WGS-84 再摆上去；反过来，我在网页上新增点位或定位输入时，把显示的 WGS-84 坐标转回 GCJ-02 再存。

v10 ~ v13：把 277KB 的单文件拆开

我观察到AI编码的我的足迹地图代码越来越大，但他一直放在一个文件里面。其中样式、js文件都在其中，每次版本迭代，AI就要读取全文件，很快上下文窗口就不够用了，AI疯狂降智。这意味项目已经开始不小了，复杂度上去了。肯定就得拆分框架了。html、js、css全部分离。

v12 这种情况值得主意：一个项目持续干下去，量级大了，很容易超过AI的处理能力。拆分、解耦是好方法。

v14 ~ v20：隐私方案从”遮羞布”做到真加密

这是最近这次迭代的主线，也是之前第五节那个”暂缓的决定”最终的落地过程。方案改了三次：

v19：加密落地

最后把真加密这个方案真正做完了，核心一句话：别人下载到 data.json 也只是一堆乱码。

• 单文件混合：公开点位保持明文（页面正常打开、公开点正常显示），私密点位整块数组加密成一个密文块——连”有几个私密足迹点”都看不出来
• 算法：PBKDF2-SHA256 迭代 60 万次派生密钥 → AES-256-GCM（12 字节随机 iv、128 位认证标签）

更新后的待办（给未来的自己）

一点感受

从最近半年从事搞政务大屏系统的时候，我就开始有了想法，要搞个自己的地图。

一开始搞的时候，几个版本就把地图做出来了，但没想到不断使用的过程中，居然衍生改版了近20个版本出来。不过这也正常，从来没有什么是一个版本就可以把自己的需求描述完的。在使用中总是伴随着需求优化和bug处理。不过我还是比较惊讶AI的能力，整个过程不断在试探AI的能力边界，AI虽然磕磕绊绊，但最后总归还是都实现了。

1

<iframe src="https://www.google.com/maps/d/embed?mid=1FnQqdlXYFoEnO6WvZ8QEHj9RYHg" width="100%" height="600"></iframe>

But using it came with pain points. For one thing, Google Maps has always been blocked in China, so every time I wanted to update my footprints I had to be on a VPN — which is exactly why I updated it so rarely. For another, Google’s satellite imagery and its roads and points of interest are offset from each other inside China, so it just looks bad. Time and again I’d be staring at a spot, unable to decide whether to place the marker against the satellite image or against the street layout. In recent years I’ve also dabbled with other options, like saving places into Baidu Maps or Amap favourites. But whenever I wanted to look back and ask “where have I been, and what happened there?”, the data was scattered across a pile of apps. I’d have to open one app after another and dig, wading past walls of ads and loan offers. Maddeningly slow.

What I actually wanted was very simple: a map that belongs to me — every marker a memory, where I can write text, attach images, string points into routes in time order, and where the data always stays in my hands.

So, with AI helping me both to think it through and to build it, this project came into being: a pure front-end footprint map embedded in my Hexo blog. This post records the whole journey from requirements discussion to launch — including three very representative pitfalls, and the to-dos I left for my future self.

1. Aligning on Requirements: Two Rounds of Discussion with Yuanbao

I didn’t hand this project straight to an AI and tell it to start coding. I first went to Yuanbao to talk the requirements through, letting the AI keep asking me questions over several rounds until my own needs were actually pinned down. That process also forced me to think my own ideas straight.

Yuanbao and I started from a vague notion — “I want to record the footprints of my life” — and gradually converged on a core feature set: map markers, a category system (routes / good food / good drinks / fun / scenery / points of interest), Markdown popups with text and images, a route mode ordered by time, group filtering, and data import/export.

When we were done, Yuanbao produced two documents for me:

The first document is essentially a user-facing description of the requirements; the second is a development guide aimed at AI. In practice, though, I came to feel it’s better not to let the AI doing the actual work be completely steered by that second document. Different AIs think differently, for one thing. And an AI in the middle of implementation, working alongside a human tester, will always run into places where the original technical design doesn’t match the way things really work.

The reason I thought of hashing out the plan with AI first is that in my own work on government IT systems, I’m constantly sitting with clients in front of a prototype, discussing back and forth — and that’s how requirements actually get nailed down. It matters. Skip it, and the build phase turns into endless rework. AI may not get tired and can iterate forever, but with vague requirements, my tokens and my time are real costs. The more precisely the direction is described at the document stage, the higher the odds the AI picks the right approach, and the fewer rounds of bickering.

I think that when you talk to the person doing the work, every word has to count. Explaining ideas to an AI is genuinely good practice for the collaboration and communication side of the job. I’ve also lived through projects that dragged on, accumulated more and more user interaction, and ended up in a heap of problems. With AI-assisted programming, the scariest scenario, I think, is this: you finally have something that’s basically perfect, then you ask the AI to fix a bug and it destroys the features that were already working. Ha. Which is why, during development, I kept telling the AI to mind the backups at every version.

Before starting, I also talked things over with AI and hunted down similar existing solutions to use as references, so we weren’t inventing wheels out of thin air. We borrowed architectural ideas from three projects: MarkdownMap, leaflet-search and Exping.

The build principles were basically settled up front:

• Pure front-end: no backend, no database; static hosting is enough to run it
• Data ownership: everything lives in JSON files, exportable at any time, never locked in
• Single-file delivery: all CSS and JS inlined into one index.html — drop it into source/map/ and you’re done

2. Development: Six Rounds of Iteration with WorkBuddy

Once the docs went to WorkBuddy, we had six versions out in no time. Here’s the iteration in a table:

The early versions (v1–v3) went unexpectedly smoothly — the handover doc was detailed enough that the AI basically got it right in one pass, and the vast majority of the acceptance checklist passed outright. The real time went into the last three rounds, where I was the one testing in real use, hunting bugs, and judging whether the thing actually met my needs.

3. Pitfall Log

Pitfall 1: The popup that couldn’t be reopened (v4)

Symptom: click a marker and the popup opens fine. Click the ✕ in its top-right corner to close it, then click the same marker again — the popup absolutely refuses to appear. Refresh the page and it opens once more.

This bug is particularly deceptive: “it opens the first time” means the open path is fine; “it won’t open after closing” means the close operation dirtied something. My job was to reproduce the fault and gather the logs through different operations; finding the cause was the AI’s job.
The AI dug down into Leaflet’s source. Leaflet’s Marker._openPopup has a toggle inside it:

1
2
3
4
5
6

_openPopup: function (t) {
  ...
  this._map.hasLayer(this._popup)
    ? this.closePopup()   // already open → close (toggle behaviour)
    : this.openPopup(t.latlng);
}

Meanwhile, the click handler the AI had custom-written for my requirements and Leaflet’s own internal handler were listening for clicks at the same time. The two conflicted. A case of borrowing a third-party library and importing trouble along with it. So no, you can’t just be a copy-paste engineer. Ha.

4. Spin-off Requirements: Improving It Through Use

These three features weren’t in the original requirements document — they came out of pain points I hit while actually using the thing:

1. Foreign basemaps. It originally used Amap tiles, which look fine inside China, but the moment I wanted to mark a place abroad and zoomed in, it was blank. So I added OSM and Carto’s light basemap for overseas coverage, plus Esri satellite — a complete set of “domestic + foreign, standard + satellite”.
2. A layer dropdown. Once the basemaps went from two to five, the old “cycle” button became idiotic — getting to Esri satellite meant clicking four times. So it became a dropdown.
3. Enter to select in search. While chasing down the occluded-dropdown problem, I noticed I kept instinctively hitting Enter to confirm a search, so I asked the AI to add it.

5. Privacy: A Decision Deferred

Before launch, something occurred to me: this page needs no login. Convenient for me — but equally convenient for anyone else to see all of my footprints: where I’ve been, when I went, and what I wrote.

I was torn between two options: put a password lock on the page, or let the page load normally but require verification before the data loads. After discussing it with the AI, though, we couldn’t come up with a good answer right away: static hosting means no backend, so any “front-end password check” is just a fig leaf — bypass the page, hit the data.json URL directly, and the plaintext downloads just the same.

The genuinely effective answer is a third one: encrypt data.json itself with AES-256-GCM, with the password living only in my head. The browser decrypts it to render and encrypts on export; anyone who downloads the file just gets noise. But I also wanted to keep the map’s ability to be shared and shown off. And for the moment I hadn’t figured out how to do both.

6. Launch & Deployment

Deployment was simple: copy the whole source/map/ folder (index.html + data.json + README.md, three files in total) into the production repo, git push, and CNB’s cloud build takes care of everything that follows.

Once live, it’s reachable at https://misaka10013.cn/map/.

The whole tech stack, summed up in one sentence: Leaflet.js handles the map, marked.js handles Markdown rendering, localStorage handles persistence, vanilla JS + inlined CSS handle every interaction — zero frameworks, zero backend, zero build step.

7. Open Questions and To-Dos (Notes to Future Me)

Recording what’s unfinished here, so that when I stumble back onto this post later I’ll know where to pick up:

Afterword

Looking back over the whole project, my process was: Yuanbao converged the requirements and produced the documents, WorkBuddy did the coding, and I did the real-world testing and made the directional calls. Of the three roles, AI took two; pointing the direction and judging the quality stayed with me.

Update Log (2026-09-23): v7 → v20 After Launch

The post above wrapped up when v6 shipped. But once I actually used it, I realised shipping was only the beginning. Over the following month or so I kept iterating with AI, a dozen-plus versions, sanding down a set of detail problems. This update catches the rest up.

v7 ~ v9: Real Data Arrives, Three Pitfalls in a Row

The first move after launch was moving my real footprint data in. The pipeline: export KML from Google Maps Takeout → script it into Excel (with me going through the categories by hand) → have AI write a script to batch-convert it into data.json → import it into the footprint page. 276 markers, spanning 2018 to 2019.

The moment data came in, three problems blew up at once:

That v7 field mismatch: the data and the page code each used their own field names. I hadn’t expected AI to be capable of a slip like that. It can write code, but sometimes it makes elementary mistakes — it smells like a context-memory problem. With a little test data you’d never notice; with a lot of data, bugs detonate.

Pitfall 4: The “half a format” date (v8)

Symptom: I changed a marker’s date, saved, and the route numbering didn’t move a millimetre. Export the JSON, re-import it — the order was still exactly as before. The reasons:

1. The time exported from KML is "2018-01-01" — date only, no hours or minutes
2. Meanwhile the page’s <input type="datetime-local"> only accepts the complete YYYY-MM-DDTHH:MM form. Given "2018-01-01" it doesn’t error, doesn’t warn — it just quietly shows blank
3. I opened the edit popup, saw an empty time field, assumed “it was never filled in”, changed some other field and hit save
4. The save logic wrote the empty value back — m.time = '' — I had wiped that time out with my own hands
5. The route feature has a filter condition, m.time && m.time !== '', so a marker with an empty time is excluded from the route list entirely — meaning “the numbering didn’t change” was really “this marker doesn’t take part in sorting any more”

Fix: sweep all the marker data and backfill the times uniformly in YYYY-MM-DD 00:00 format.

Pitfall 5: Coordinate systems — the hurdle no map project escapes (v9)

Symptom: domestic map clarity is genuinely mediocre, so I added OSM, Carto and Esri as foreign basemaps — and switching over, I ran straight into the same problem Google’s POIs had given me years earlier. Every marker was off — by a few hundred metres inside China. It’s something I see constantly in the government systems we build, too: pins that won’t line up because the coordinate systems differ.

Root cause: domestic map services (Amap, Baidu, Tencent) use GCJ-02 — the “Mars coordinate system”, a non-linear offset added under legal requirement — while foreign services (OSM, Esri, Carto) use WGS-84. The same pair of numbers does not point at the same place in the two systems. Fortunately, who uses what and by how much is a known quantity, so the problem had a solution.

Store everything in GCJ-02 (natively matching the domestic basemaps I use most), and check the current basemap before rendering — if it’s a WGS-84 international basemap, back-convert the coordinates to WGS-84 and place them there; conversely, when I add or locate a point on the page, convert the displayed WGS-84 coordinates back to GCJ-02 before saving.

v10 ~ v13: Breaking Up the 277KB Single File

I noticed the code for my footprint map was getting bigger and bigger, yet the AI kept everything in a single file — styles and JS included. Every version iteration meant the AI had to read the entire file, the context window would quickly fill up, and the AI would go noticeably dumber. That meant the project was no longer small; the complexity had gone up. It clearly needed to be split: HTML, JS and CSS all separated.

The v12 situation is worth noting: once a project keeps going and grows in scale, it will easily exceed what an AI can handle. Splitting and decoupling are the way to go.

v14 ~ v20: From “Fig Leaf” to Real Encryption

This is the main thread of the most recent iteration, and the eventual landing of that “deferred decision” from section 5. The approach changed three times:

v19: Encryption Ships

I finally finished the real-encryption approach. In one sentence: download data.json and all you get is noise.

• Hybrid single file: public markers stay plaintext (the page opens normally, public points display normally), while private markers are encrypted as one whole array into a single ciphertext block — you can’t even tell how many private footprint markers there are
• Algorithm: PBKDF2-SHA256 with 600,000 iterations to derive the key → AES-256-GCM (12-byte random IV, 128-bit auth tag)

Updated To-Dos (Notes to Future Me)

Some Closing Thoughts

The idea of building a map of my own took shape about half a year ago, back when I was working on government dashboard systems.

When I started, the map was up within a few versions. What I never expected was that, through continued use, it would spawn close to twenty versions. Though that’s normal enough — no single version can ever describe your requirements completely. Use always brings requirement refinements and bug fixes. Still, I’m fairly amazed by what AI can do. The whole way through I was probing the edges of its capability; it stumbled plenty, but in the end it delivered everything.

1

<iframe src="https://www.google.com/maps/d/embed?mid=1FnQqdlXYFoEnO6WvZ8QEHj9RYHg" width="100%" height="600"></iframe>

だが使ううちに不満も出てきた。まず、Google マップは中国本土ではずっとブロックされていて、足跡を更新するたびに VPN が要る。だから更新の頻度はごく低かった。次に、Google の衛星画像と道路・地点などの情報は中国国内では座標がずれていて、見た目がよくない。ある地点を、衛星画像に合わせて打つのか、街路の位置に合わせて打つのか、いつも迷ってしまう。ここ数年は、百度地図や高徳地図（Amap）のお気に入りに地点を保存するといった方法も細々と試してきた。しかし「自分はどこへ行き、そこで何があったか」を振り返ろうとするたび、データは各アプリに散らばっていて、アプリを開いて探し回るしかない。画面いっぱいの広告やローン勧誘をかき分けながらでは、とにかく遅い。

私が欲しかったものは、実はとてもシンプルだ。自分だけの地図。ひとつのピンがひとつの記憶で、文章が書けて、画像が貼れて、時間順に線でつながる。そしてデータは永遠に自分の手元にある。

そこで、AI と相談しながら開発したのがこのプロジェクト——Hexo ブログに埋め込む、純フロントエンドの足跡マップだ。この記事では、要件の議論から公開までの流れを、代表的な3つの落とし穴と、未来の自分への TODO とともに記録する。

一、要件のすり合わせ：元宝（Yuanbao）との2ラウンドの議論

このプロジェクトでは、いきなり AI にコードを書かせたりはしなかった。まず元宝（Yuanbao）と要件について話し、何度ものやり取りの中で AI にひたすら問いを投げてもらい、自分の要件を掘り下げていった。この過程は、自分の考えを整理することでもあった。

元宝と私は「人生の足跡を記録したい」という漠然とした思いから始め、少しずつ核となる機能に収束させていった。地図上のマーカー、分類体系（道のり／美味しいもの／美味しい飲み物／遊び／風景／興味ある地点）、Markdown の画像付きポップアップ、時間順に並べるルートモード、グループ絞り込み、データのインポート・エクスポート。

話し終えると、元宝は2つのドキュメントを産出してくれた。

1つ目はユーザー向けの要件記述、2つ目は AI 開発向けの実践ガイドにあたる。ただ、実際に使ってみて思ったのは、手を動かす AI を2つ目のドキュメントに完全に従わせないほうがいい、ということだ。AI ごとに思考力が違うこともある。それに、実際の作業の中で AI が人間のテストと組み合わさると、最初の技術設計と現実との不一致が必ず見つかるものだ。

最初に AI と方針を話そうと思ったのは、私自身が行政システムの仕事の中で、顧客とプロトタイプを前に延々と議論する機会が多いからだ。これが要件を掴むために非常に重要で、やらないと後工程が無限の作り直しになる。AI 開発は、AI が疲れないので何度でも作り直せる。だが要件が曖昧なら、私のトークンと時間もコストだ。最初の段階で、要件ドキュメントのレベルで方向をできるだけ正確に書いておけば、AI が正しい実装方針にたどり着く確率が最も高くなり、押し問答の回数も減る。

作業する相手と話すときは、言葉を効率的に使うべきだ。AI に考えを説明するのは、仕事の協働と伝達を鍛える良い練習になる。それに、プロジェクトが長引き、ユーザーとのやり取りが増えた挙げ句、かえって問題だらけになった経験も私にはある。AI と協働してプログラミングする場合、一番恐ろしいのはこれだと思う——せっかくほぼ完璧な作品を作り上げたのに、あとで AI にバグを直させたら、それまでの機能を壊してしまった、という展開。ははは。だから開発中は、AI に「各バージョンのバックアップに気をつけろ」と何度も言っておいた。

開発前には、AI と話し合い、似た事例も探して開発の参考にした。車輪の再発明を減らすためだ。MarkdownMap、leaflet-search、Exping の3プロジェクトのアーキテクチャの考え方を参考にした。

初期の構築方針はほぼ固まった。

• 純フロントエンド：バックエンドなし、データベースなし。静的ホスティングだけで動く
• データの自律：すべてのデータは JSON ファイル。いつでもエクスポートでき、決して囲い込まれない
• 単一ファイル納品：CSS と JS をすべて1つの index.html にインライン化し、source/map/ に放り込めば使える

二、開発実施：WorkBuddy との6ラウンドの反復

ドキュメントを WorkBuddy に渡すと、あっという間に6バージョンまで反復した。その過程を表にまとめる。

初版（v1〜v3）は意外なほど順調だった。引き継ぎドキュメントが細かく書かれていたので、AI はほぼ一発で形にし、受け入れチェックリストの大部分がそのまま通った。本当に時間を使ったのは後半の3ラウンドで、これは実際に使ってみてバグを検証・テストし、自分の用途を満たすかを評価する作業だった。

三、落とし穴の記録

落とし穴 1：ポップアップを閉じると二度と開かない（v4）

症状：地図のピンをクリックすると、ポップアップは正常に出る。右上の ✕ で閉じ、同じピンをもう一度クリックすると、ポップアップがどうしても出てこない。ページを更新すれば、また一度だけ開く。

このバグはとても紛らわしい。「一度目は開く」＝開く処理は問題ない、「閉じると開かない」＝閉じる操作が何かを汚した、ということだ。私はさまざまな操作で不具合の再現とログの収集を担当し、AI が原因を特定した。
AI が掘り当てたのは Leaflet のソースコードのレベルだった。Leaflet の Marker._openPopup の内部にはトグルのロジックがある。

1
2
3
4
5
6

_openPopup: function (t) {
  ...
  this._map.hasLayer(this._popup)
    ? this.closePopup()   // 開いている → 閉じる（toggle 動作）
    : this.openPopup(t.latlng);
}

一方で、私の要件に合わせて AI が独自に書いた click ハンドラと、Leaflet 内部のこのハンドラが同時にクリックを監視していた。両者が衝突していたのだ。サードパーティのライブラリを参考にしたことで、自分から厄介ごとを招き入れた形だ。つまり、コピペエンジニアではダメだということ。ははは。

四、派生要望：使う中で改善する

この3つの機能は最初の要件ドキュメントにはなく、使っていて痛みを感じたところから出てきたものだ。

1. 海外のベースマップ。もともと高徳地図のタイルを使っていたが、国内ならまだしも、海外の地点をマークしようと拡大すると真っ白だ。そこで OSM と Carto の淡色という海外向けベースマップを追加し、さらに Esri 衛星を加えて「国内＋海外、標準＋衛星」の組み合わせが揃った。
2. レイヤーのドロップダウン。ベースマップが2種類から5種類に増えると、元の「循環切り替え」ボタンはひどく間抜けになった——Esri 衛星にしたいだけで4回連打である。ドロップダウンに変更した。
3. 検索の Enter 確定。ドロップダウンが隠れる問題を追う中で、自分が無意識に Enter を押して検索を確定していることに気づき、AI に追加してもらった。

五、プライバシーの検討：いったん保留にした決定

公開前に一つ思い当たった。このページはログイン不要で、自分が見るには便利だが、他人にとっても同じように便利に、私の足跡のすべてが見えてしまう——どこへ行き、いつ行き、何を書いたか。

私は2つの案で迷っていた。ページにパスワードロックをかけるか、ページは普通に開けるがデータの読み込みに認証をかけるか。しかし AI と議論しても、すぐには良い方法が出なかった。静的ホスティングにバックエンドはなく、フロントエンドでのパスワード検証など目隠しにすぎない——ページを迂回して data.json の URL に直接アクセスすれば、平文データはそのままダウンロードできてしまう。

本当に有効なのは3つ目の案だ。data.json そのものを AES-256-GCM で暗号化し、パスワードは自分の頭の中だけに置く。 ブラウザ側が復号して描画し、エクスポート時は暗号化する。他人がファイルをダウンロードしても、ただの文字化けの山だ。ただ、地図の便利な共有・展示の能力は残しておきたかった。どう両立させるかは、その時点では決めきれなかった。

六、公開とデプロイ

デプロイは簡単だ。source/map/ フォルダ全体（index.html ＋ data.json ＋ README.md、計3ファイル）を本番リポジトリのディレクトリにコピーし、git push すれば、あとは CNB のクラウドビルドがすべて自動でやってくれる。

公開後の URL は https://misaka10013.cn/map/。

プロジェクト全体の技術スタックを最後に一文でまとめると：Leaflet.js が地図を、marked.js が Markdown 描画を、localStorage が永続化を、素の JS ＋ インライン CSS がすべてのインタラクションを担う。フレームワークなし、バックエンドなし、ビルドなし。

七、検討事項と TODO（未来の自分へ）

未完の事項をここに記しておく。後でこの記事を見返したとき、次にどこへ進めばいいか分かるように。

あとがき

プロジェクト全体を振り返ると、私の進め方はこうだ：元宝が要件の収束とドキュメント産出を、WorkBuddy が実装を、私が実環境でのテストと方向の決定を担う。 3つの役割のうち、AI が2つを担い、方向を示し品質を評価する部分は私が握っている。

更新記録（2026-09-23）：公開後の v7 → v20

上の記事は v6 の公開で締めくくっている。しかし実際に使ってみて分かったのは、公開はスタートにすぎないということだった。その後の1か月余りで、私は細々と AI と何十回も反復し、細部の問題を片付けていった。今回の更新でその続きを補う。

v7 〜 v9：実データ投入、3つの落とし穴を連続で

公開後の最初の作業は、自分の実際の足跡データを入れることだった。流れはこうだ。Google マップの Takeout で KML をエクスポート → スクリプトで Excel に変換（分類は私が目で一遍確認）→ AI にスクリプトを書かせて data.json に一括変換 → 足跡ページへインポート。276 地点、期間は 2018 年から 2019 年まで。

データが入った途端、問題が3つ同時に噴き出した。

v7 のフィールドのずれ：データとページのコードがそれぞれ勝手にフィールド名を書いていたのだ。AI がこういうミスをやらかすとは思わなかった。コードは書けるが、時に初歩的なミスをする。コンテキスト記憶に起因する問題のように見える。テストデータが少ないうちは全く気づけないが、データが増えると一気にバグる。

落とし穴 4：日付フォーマットの「半分の形式」（v8）

症状：ある地点の日付を変えて保存しても、線の連番がびくともしない。JSON をエクスポートして再インポートしても、順序は元のまま。原因はこうだ。

1. KML が出力する時刻は "2018-01-01"——日付だけで、時分がない
2. 一方、HTML ページの <input type="datetime-local"> は YYYY-MM-DDTHH:MM の完全な形式しか受け付けない。"2018-01-01" を渡すと、エラーも警告も出さず、黙って空欄表示になる
3. 私は編集ポップアップを開き、時刻欄が空なので「元から入っていない」と思い込み、他の項目を直して保存を押した
4. 保存ロジックは空の値をそのまま書き戻した——m.time = ''。時刻は私の手で消された
5. 線を引く機能には m.time && m.time !== '' という絞り込み条件があり、時刻が空の地点は線のリストから除外される。つまり「連番が変わらない」のではなく「この地点が並べ替えに参加していない」のだった

修正：すべての地点データを走査し、時刻を YYYY-MM-DD 00:00 の形式で統一して補完した。

落とし穴 5：座標系——地図プロジェクトが避けられない一段（v9）

症状：国内の地図は解像度が正直いまいちなので、OSM、Carto、Esri といった海外のベースマップを追加した。ところが切り替えてみると、以前 Google の地点で困った問題にまたぶつかった。すべての地点がずれている——国内では数百メートルほど。この問題は、私たちが作っている行政システムでもよく見かける。座標系が違うために、ピンの位置がどうしても合わないのだ。

根本原因：国内の地図サービス（高徳、百度、騰訊）は GCJ-02（通称・火星座標系。法令により非線形のオフセットが加えられている）を使い、海外のサービス（OSM、Esri、Carto）は WGS-84 を使う。同じ緯度経度の組でも、2つの座標系では同じ場所を指さない。幸い、どこが何を使ってどれだけずれるかは既知のことなので、解決の道はあった。

GCJ-02 で統一して保存する（メインで使う国内ベースマップとネイティブに一致する）。描画前に現在のベースマップを判定し、WGS-84 の国際ベースマップなら座標を WGS-84 に逆変換してから置く。逆に、ページ上で地点を追加したり位置を入力したりするときは、表示されている WGS-84 の座標を GCJ-02 に戻してから保存する。

v10 〜 v13：277KB の単一ファイルを分割する

足跡マップのコードがどんどん大きくなっているのに、AI はそれをずっと1つのファイルに入れていた。スタイルも JS もその中にある。バージョンを反復するたびに AI は全ファイルを読むことになり、すぐにコンテキストウィンドウが足りなくなって、AI は目に見えて頭が悪くなった。これはつまり、プロジェクトがもう小さくなく、複雑度が上がったということだ。ならばフレームを分割するしかない。HTML、JS、CSS をすべて分離する。

v12 の状況は注目に値する。プロジェクトを続けていくと規模が大きくなり、AI の処理能力を超えやすい。分割と分離は良い方法だ。

v14 〜 v20：プライバシー対策を「目隠し」から本物の暗号化へ

これが直近の反復の主軸であり、前述・第五節の「いったん保留にした決定」が最終的に着地する過程でもある。方針は3度変わった。

v19：暗号化の実装

最後に、この本物の暗号化という方針を実際に作り切った。核心は一文で言える。他人が data.json をダウンロードしても、ただの文字化けの山だ。

• ハイブリッドな単一ファイル：公開地点は平文のまま（ページは普通に開き、公開地点も普通に表示される）、秘匿地点は配列ごと1つの暗号文ブロックに暗号化する——「秘匿の足跡地点がいくつあるか」すら分からない
• アルゴリズム：PBKDF2-SHA256 を60万回反復して鍵を導出 → AES-256-GCM（12バイトのランダム iv、128ビットの認証タグ）

更新後の TODO（未来の自分へ）

ひとつの感想

半年前から行政の大型ダッシュボードシステムに携わるようになったころ、自分用の地図を作りたいという思いが芽生えた。

作り始めたときは、数バージョンで地図はできた。ところが使い続けるうちに、なんと20バージョン近くまで派生して作り直すことになるとは思わなかった。まあ、これも当然ではある。1つのバージョンで自分の要件を書き尽くせることなど、決してない。使う中ではいつも要件の改善とバグ対応が付きまとう。それでも、AI の能力にはやはり驚かされる。この過程では絶えず AI の能力の限界を試していた。AI はつまずきながらも、最後にはどれも形にしてくれた。

问题不在读得太少，而在读得太被动。

这篇文章是我整理的一份「小说阅读操作指南」——从翻开书之前的心理准备，到阅读中的具体动作，再到读完之后的总结输出，把整条流程固定下来。以后每次读小说，都可以照着这份流程走一遍。

一、阅读前的思想准备：先想清楚「为什么读」

AI 辅助通道：把整本小说的文本 + 下面这段提示词一起发给 AI，让它帮你完成读前准备工作（纯可选，不用就跳过）。

1
2
3
4
5
6
7
8
9

我正在读 [填写书名]，作者是 [填写作者]。我的阅读目的是：[填写你的目的，例如：想训练逻辑推理能力 / 想体验人物的情感挣扎 / 想学习作者的叙事技巧]。

我已经把全书文本发给你了，请基于文本内容，帮我完成以下读前准备工作：

1. 建立全书地图：概括这本书的整体结构——分为几个部分？叙事视角是什么（如第一人称、第三人称有限视角）？故事大致从哪里开始，最终走向何方？
2. 梳理背景：介绍作者所处的时代背景、创作状态，以及这本书在文学史或类型小说中的地位。如果文本中没有相关信息、你也无法确认，请明确说“无法确认”，不要推测。
3. 提出三个问题：基于我的阅读目的和这本书的实际内容，以“主动阅读者”的身份替我提出 3 个核心问题，用于引导整本书的阅读。要求：问题必须来自书中真实存在的内容或主题，能引导深入思考，而不是简单的剧情预测。

注意：如果全书文本过长，你只看到了部分内容，请先明确告知，再基于已有内容作答。

拿起一本书之前，先回答一个问题：我为什么要读小说？

很多人觉得这是废话——“因为好看啊”。但把这个问题想深一层，你会发现自己能从小说里拿到的东西远比「好看」多得多：

想清楚「为什么读」，你的阅读目标就有了方向：想训练逻辑就读推理，想获得共情就读人物群像，想提升表达就注意语言细节。

二、翻开之前：明确要从这本小说中获得什么

这是很多人最容易跳过、但回报最高的一步。不要直接翻正文，先花十分钟做三件事：

1. 建立全书地图

先看目录、序言、作者简介，快速浏览全书结构。搞清楚：这本书分几部分？叙事视角是什么？故事大概从哪里开始、走向哪里？

这一步不是剧透，而是给你的大脑装一张「地图」——带着地图进书里，你不会迷路，还能在阅读中随时感知「现在走到哪了」。

2. 了解背景

作者所处的时代、写作背景、这本书在文学史上的位置。了解了这些，很多情节和隐喻才有了理解的坐标。

3. 写下三个问题

在阅读前写下 3 个你想从这本书里得到答案的问题。比如：

• 这本书的主角究竟是一个怎样的人？
• 作者想通过这个故事表达什么？
• 这本书为什么被称为经典/为什么口碑两极分化？

这三个问题是你整本书的「锚」。读完合上书时，回来检验：这三个问题被解答了吗？如果被解答了，答案是什么？

三、阅读中：主动阅读的操作流程

带着问题和地图开始读。阅读中始终保持一个动作：主动提问，别被动接受。

AI 辅助通道：把整本小说的文本 + 下面这段提示词一起发给 AI，让它帮你做阶段性整理（纯可选，不用就跳过）。注意：当前进度一定要填——它决定了 AI 只回答你读过的部分，防止被剧透。

1
2
3
4
5
6
7
8

我正在阅读 [填写书名]，目前读到了 [填写章节名或进度，如：第5章 / 故事的前三分之一处]。

我已经把全书文本发给你了。请帮我完成以下两项工作：

1. 梳理人物关系网络：只基于“截止到 [当前进度]”已出现的内容，列出到目前为止的主要人物，并用简洁的语言描述他们之间的关系（如：盟友、敌对、暗恋、利益纠葛等）。如果能用文字画出关系图更好。
2. 追踪角色成长轨迹：聚焦于主角 [填写主角名字]，只基于“截止到 [当前进度]”已出现的内容，分析他/她在这个阶段经历了什么关键事件？心态、性格或目标发生了哪些变化？与故事开始时相比有什么不同？

重要：我只读到 [当前进度]，请严格基于我已读的部分作答——不要引用、不要暗示我尚未读到的情节，不要剧透。

1. 边读边提问

看到任何疑惑——人物动机、伏笔、隐喻、看不懂的设定——立刻停下来想一想，而不是滑过去。疑惑是阅读最有价值的东西，它是你理解力的抓手。

如果身边有 AI 工具（比如带 RAG 检索的阅读助手），可以随时把疑问抛给它，让它检索原文出处并解释。但即使没有 AI，你也可以把问题记在书页空白处，或记在笔记里，带着疑问继续读——很多疑问会在后面自己解开，这本身就是一种阅读乐趣。

2. 边读边记

让笔记贯穿全程，而不是留到最后。 划线、写批注、记下此刻的感受和联想。

具体可以记什么：

• 让你心头一动的句子（划线即可）
• 你对某个角色的第一印象（和最后的印象对比会很有趣）
• 猜到的伏笔和后续发展（打脸和猜中都是乐趣）
• 产生共鸣或抵触的段落（这是自我认知的入口）

3. 使用适合的阅读方法

主动阅读法（SQ3R 变体），适合大多数小说：

1. 浏览（Survey）→ 先看目录和全书结构
2. 提问（Question）→ 读前写 3 个想知道答案的问题
3. 精读（Read）→ 边读边标注、边记疑问
4. 复述（Recite）→ 每章读完，用自己的话复述一遍
5. 回顾（Review）→ 全书读完做总结，检验当初的问题是否被解答

三遍读法，适合经典作品和推理小说：

• 第一遍：享受情节，不打断，完整体验故事的爽感
• 第二遍：带着问题精读，追伏笔、查概念、看细节
• 第三遍：跳读重点章节，做结构分析，看作者是怎么「搭房子」的

费曼输出法，任何书都适用：

• 读完每章，问自己：「如果我要向朋友讲这本书，我会怎么说？」
• 能讲清楚，就是真读懂了；讲不清楚，说明有地方还没消化，回去重读那一段

4. 特殊类型小说的针对性策略

• 推理小说：重点关注人物关系网（人物多、关系复杂），可以单独画一张关系图；追踪线索与伏笔的出现轨迹；读到中段试着梳理案件的逻辑链条
• 长篇小说：跨章节追踪某个角色或某个伏笔的成长轨迹，这是纸质书很难做到、但非常值得做的事
• 经典文学：注意语言与结构，思考作者为什么这样安排叙事

四、阅读后：总结与输出

合上书，阅读只完成了一半。后半段是「输出」，逼自己输出才能真正消化。

AI 辅助通道：把整本小说的文本 + 下面这段提示词一起发给 AI，让它帮你完成全书总结（纯可选，不用就跳过）。

1
2
3
4
5
6
7
8
9
10
11

我已经读完了 [填写书名]。我的阅读目的是：[填写你最初的目的]。

我已经把全书文本发给你了，请基于文本内容，帮我完成最终的总结与输出：

1. 检验问题：逐一回答读前提到的 3 个核心问题，并说明答案是什么。
2. 全书总结：用你自己的话完整总结这个故事——主线与副线如何交织？核心冲突是什么？结局如何收束？
3. 寻找三种共鸣：根据书中的人物，找出“像我的角色”（我在谁身上看到了自己）、“我想成为的角色”（谁活成了我想要的样子）、“我害怕成为的角色”（谁的结局是我最不想面对的）。
4. 整理金句：从全书文本中挑选 3-5 句最能代表本书精神内核或最令人震撼的句子。要求：必须是书中真实存在的原文，并逐句标注出自哪个章节或大致位置，方便我回查核对。
5. 输出脚本——如何把这本书讲给别人听：写一份简短的“安利脚本”：一句话钩子（用吸引人的问题或观点开场）；核心故事（2-3 句话讲清故事梗概，不剧透关键转折）；亮点推荐（这本书最独特的魅力，如人物塑造、反转设计、情感冲击）；适合人群（什么样的人会喜欢这本书）。

[可选] 如果这是新对话，请先让我把读前的 3 个问题、读中的人物梳理粘贴给你，再基于这些内容完成上面的总结；如果我没有粘贴，就基于全书文本直接完成。

1. 梳理人物关系与成长线

把主要人物列出来，画一张关系图；再为每个主要角色梳理一条成长线——他从故事开头到结尾，经历了什么，变成了什么，为什么。

2. 找到自己的共鸣点

这一步很重要：把书和「你自己」连接起来，书才算真正读完。

共鸣不只有一种，可以找三种：

• 「像我的角色」——在谁身上看到了自己？
• 「我想成为的角色」——谁活成了我想要的样子？
• 「我害怕成为的角色」——谁的结局是我最不想面对的？

这三种共鸣找完，你对这本书的理解会立体很多。

3. 全书总结

用自己的话写一遍全书总结：故事讲了什么、主线副线怎么交织、结局如何收束。注意：是用自己的话，不是复述简介。

4. 收集金句

把阅读中划线的句子整理出来，挑出最让你震撼、最有共鸣的几句，单独存起来。金句是这本书留给你的「可携带资产」，以后引用、写作、发朋友圈都用得上。

5. 输出——把书讲给别人听

最后一步，向他人讲述整个故事 + 推荐这本书的亮点。形式不限：

• 写一篇读书笔记/书评
• 向朋友口头安利
• 发一条社交动态
• 写「我同意/不同意作者什么」（批判性输出，比单纯复述更有价值）
• 把这本书和同类作品对比（比如两本推理小说手法差异在哪）

五、一页纸速查清单

每次读小说前，把这张清单过一遍：

读前（10 分钟）

• 我为什么读这本小说？（想获得什么：逻辑/共情/审美/成长？）
• 看完目录，建立全书地图
• 了解作者与背景
• 写下 3 个想在书中得到答案的问题

读中（全程）

• 带着 3 个问题读
• 有疑惑就停下来想/记/问
• 划线、写批注，笔记贯穿全程
• 每章结束用自己的话复述一遍（费曼）

读后（30 分钟）

• 检验 3 个问题是否被解答
• 梳理人物关系 + 成长线
• 找三种共鸣：像我的 / 想成为的 / 害怕成为的
• 写全书总结
• 整理金句
• 输出：讲给别人听 / 写书评 / 对比同类作品

读小说不是消遣，是一次低成本的人生模拟。流程化的意义在于：同样的时间投入，你能从书里拿走更多。

下次翻开书之前，记得先问自己那三个问题。

必要性。习惯了解决问题的工程师思路，对于一个行为，往往首先思考的就是这个需求是否有必要。本文不是主要讨论这个，所以今天我们跳过。
合理性，是指这个行为是否合理，具备可行空间。也不是我们今天讨论的重点。
正当性，则是指，我们有这个权利做出这样的行为吗？

比如，对于育儿这个事情的参与人而言，公平正当吗？
对女性的伤害是一个方面，对子女自身是否想降临这个世界的意愿，是否也是一个应该严格思考的方向？

所以我开始反思，自己作为一个儿女，对于降临到这个世界，如果有选择，愿意吗？

我反思我的人生，我觉得是有偶尔那非常专注，很开心快乐的时光的，比如初高中时全身心的打篮球的时候，全身心的欣赏小说和动漫的时候。比如大学时和社团同好们为同一个目标去创造创意和推进活动。比如我和我老婆休长假，无忧无虑的旅游的时候，我照顾我老婆的时候。
快乐是有的，如果回忆着这些快乐的画面，我觉得来人世间一圈是值得的。

但我又想，我看到这些快乐的时光太少了。我的整个人生，如果让我自己总结，那大概就是，压抑的时光占了大多数时候。压抑，是指什么状态呢。大概就是，不轻松。比如小时候，会被要求着要认真读书，被教育着要铁血男儿，自强独立有责任感。比如高中得想办法认真学习搞好成绩，得应对考试考证。比如毕业了要独立自主在社会生存，应对社交关系，应对工作压力等等。
很多时候，这种不轻松这不都是外部带来的，因为我从小到大，比较老实本分，我的家长和遇到的老师都很开明，对我鼓励居多，要求很少。我老婆也是个独立自主，很律己的人。我身边来自外部的压力应该比很多糟糕人生的人，都小得多。
但我依然觉得不轻松，我感觉，自身对自己的自律、自觉，本身也是一种压抑。
我大多数的人生就是在自己对自己的压抑中，度过了。
人生是用来放纵的吗？我自己没有答案。我其实已经比很多人幸运了。家人没有大病，我没有背负过房贷，家庭也过得去，也没遇到过什么经常超过8小时上班或者大小周单休的公司，也没有遇到奇葩的离谱领导和同事。
但即使这样，为啥我依然会觉得人生不轻松呢。
多少有些凡尔赛和身在福中不知福吧。

这样，我自己觉得不轻松的人生，大概会是我不愿意来到人生一转的一面。

当然，如果你问我，这样大多数时候不轻松和偶尔非常快乐的综合人生，是否愿意来一遍？我肯定会说完全没问题。因为我有行动力和勇气，也有抗压能力。不轻松，我扛得住。

但是如果你问我，是否愿意让孩子也体验这”大多数时候不轻松和偶尔非常快乐的综合人生”，我反而我觉得不值得。因为我的行动力、忍耐力和勇气，也不过是这么多年被捶打出来的东西。我能说自己愿意为了少许亮光而接受大多数不轻松的人生，是因为我已经被不轻松捶打的半生了，这样被捶打我我，根本不在意被再捶打多少年。

但是我凭什么来替另一个人来做决定，让对方来接受这样的捶打并最终被迫成为一个已经习惯追着萝卜行走的驴呢？更何况，这个人是自己的孩子。

近来，和我老婆聊到了这个话题。一开始她关注的重点在于我为啥肯定“人生不轻松”，可能是觉得这是一种看起来很消极的意识，而我平时并不是一个消极的人。
不过我得出这个结论，更多是我从客观的心理学的角度思考来的。因为人类心总是会有新的欲求，而欲求的满足与新欲求的诞生之间总有差距，所以我感觉，大多数人、大多数时候，其实得不到心灵欲求的平静，所以人总是疲于奔命，总是“不轻松”。这也正符合那一句“人生不如意，十之八九”。

而关于“父母有什么权力决定了让孩子到这个世界上并来体会这些”。这个问题，我和我老婆以及AI都没有想出来明确的答案。我老婆总结觉得，一类父母是属于满足自我需求的父母。她们是为了养老、从孩子身上满足自己的成就感或者精神寄托等等需求。另一类父母可能只是怀孕了，既来之，则安之。缘分到了，就选择生下来。

还有一类父母，她们可能有爱心，可能体会过爱，也充满着爱，相信世界是美好的，并主动生孩子，并用自己的爱希望孩子幸福。这种父母也可能会从前两类父母中转变过来。

父母有没有权力生孩子，细想之下，竟没有一个明确的答案。那我觉得，这恰恰说明这个问题的答案，大概率是否定的。

而作为父母真正能做的，则是通过对孩子负有的责任和爱，来对“把孩子带到这个世界上来”这件事情，进行补救吧。

📌 本文定位： 这是一份面向初学者的加密解密领域知识库全景图。读完本文，你将理解密码学从古至今的完整脉络，掌握核心算法原理，并能够动手完成加密解密实操。文中所有专业术语都会在首次出现时以悬停提示（像这样）的方式给出解释，重要论文和资料会附上原文链接，方便你跳转扩展阅读。

第一章 加密解密领域概览

1.1 一句话定义

加密解密 是通过数学变换，让信息在开放信道中安全传输、在不可信环境中安全存储的科学。它解决的是数字世界的核心信任问题：如何在不安全的通道上，安全地传递秘密？

1.2 它解决的核心问题——CIA 三元组

信息安全有三大基石，合称**CIA 三元组**。下面的 SVG 图展示了三者的关系：

• 机密性（Confidentiality）：确保信息不被未授权的人看到。通过加密实现。
• 完整性（Integrity）：确保信息在传输过程中没有被篡改。通过哈希函数或 **MAC**实现。
• 真实性（Authenticity）：确保”对方确实是他声称的那个人”。通过**数字签名**实现。

1.3 最典型的应用场景

下面的表格用生活场景帮你建立直觉。请注意在”使用的技术”列中，每个缩写我们都用 <abbr> 标签做了悬停提示——鼠标指上去就能看到全称和解释^[1]。

本节缩写速查表：

💡 学习密码学的长期收益： 密码学是所有安全方向的基石。它能重塑你的思维——学会用「无法篡改」「零知识」「可验证」等视角重新审视数字世界。

第二章 加密解密发展历史

2.1 古典密码时代（公元前 1900 年 — 19 世纪）

密码学的历史几乎和人类文明一样长。从古埃及墓穴中非标准象形文字，到罗马军团的凯撒密码，隐藏秘密始终是人类的基本需求。

约公元前 1900 年 · 古埃及：最早的密码记录

一位书吏在贵族的墓穴铭文中使用了非标准的象形文字替代，被公认为最早的密码实践。这不是加密通信，而是一种仪式性的”隐藏书写”。

约公元前 600 年 · 斯巴达密码棒（Scytale）

最早的**转置密码**工具。将羊皮纸条缠绕在特定直径的木棒上书写，展开后字母顺序被打乱。只有使用相同直径木棒的接收者才能恢复原文——木棒直径就是”密钥”。

约公元前 50 年 · 凯撒密码（Caesar Cipher）

尤利乌斯·凯撒在军事通信中将字母按固定偏移量替换。例如偏移3位：A→D, B→E, C→F……这是最经典的**单表替换密码**。密钥空间仅25个（排除偏移0），属于极弱的加密。

约公元 800 年 · 肯迪（Al-Kindi）：频率分析法

阿拉伯数学家肯迪在《破译密码信息的手稿》中提出了频率分析方法，这是密码学从”手艺”走向”科学”的转折点。

1467 年 · 阿尔贝蒂（Alberti）：多表替换密码

意大利文艺复兴巨匠莱昂·巴蒂斯塔·阿尔贝蒂发明了密码轮盘（一个带两组字母的机械转盘，转动到不同位置对应不同的替换表）和多表替换密码^[10]概念，被尊为”西方密码学之父”。

1586 年 · 维吉尼亚密码（Vigenère Cipher）

法国外交官布莱斯·德·维吉尼亚在《密码学条约》中描述了基于关键词的多表替换系统。

1883 年 · 柯克霍夫原则（Kerckhoffs’s Principle）

荷兰密码学家奥古斯特·柯克霍夫在《军事密码学》中提出密码学的核心假设：

密码系统的安全性应该完全依赖于密钥的保密，而非算法的保密。

2.2 机电密码时代（20 世纪初 — 1940 年代）

1918 年 · Arthur Scherbius 发明 Enigma

德国工程师谢尔比乌斯发明了 Enigma 转子密码机。

下面的 SVG 图展示了简化后的 Enigma 加密流程。注意电流经过反射器后会原路返回再经过三个转子——这个设计正是 Enigma 最致命的弱点所在：

图：凯撒密码替换规则（上）与 Enigma 加密流程（下）

1939-1945 年 · 布莱切利庄园与图灵的 Bombe 机

英国布莱切利庄园成为密码破解中心。艾伦·图灵设计了 Bombe 机电破解机。

1944 年 · Colossus：世界上第一台可编程电子计算机

由汤米·弗劳尔斯设计，用于破解更复杂的 Lorenz 密码机。Colossus 是密码学直接催生出现代计算机的明证。

2.3 现代密码时代（1949 年至今）

1949 年 · Shannon：信息论奠基

克劳德·香农发表了《保密系统的通信理论》（Communication Theory of Secrecy Systems），用信息论为密码学建立了严格的数学基础。他证明了一个重要结论：一次性密码本^[11] 是理论上唯一绝对安全的加密方案。

1976 年 · Diffie-Hellman 密钥交换

惠特菲尔德·迪菲和马丁·赫尔曼发表了《密码学的新方向》（New Directions in Cryptography），首次提出了公钥密码学^[12]的概念，解决了困扰密码学四千年的密钥分发问题^[13]。这被公认为密码学史上最具革命性的突破。

1977 年 · RSA 算法 & DES 标准

Ron Rivest、Adi Shamir、Len Adleman 发表 RSA 算法——第一个实用的公钥加密方案。同年，NIST 将 IBM 开发的 DES^[14] 定为美国联邦标准，这是第一个公开可用的标准化加密算法。

1991 年 · PGP：加密走向大众

菲尔·齐默尔曼发布 PGP（Pretty Good Privacy），首次将混合加密（RSA + IDEA）带给普通用户。齐默尔曼因”出口军火级别加密软件”被美国政府刑事调查三年——当时美国法律将强加密软件列为军火。

1994 年 · Shor 算法：量子威胁的出现

彼得·肖尔提出 Shor 量子算法，能够在多项式时间内分解大整数——未来量子计算机可在一小时内破解 RSA-2048。

2001 年 · AES 取代 DES

比利时密码学家 Joan Daemen 和 Vincent Rijmen 设计的 Rijndael 算法在公开竞赛中击败 14 个候选算法胜出，成为 AES 标准。

2004 年 · 王小云破解 MD5

中国密码学家王小云教授在国际密码学会议上宣布成功构造 MD5 碰撞^[15]，论文链接。随后她陆续破解了 SHA-1、MD4 等多个哈希算法，推动全球密码标准升级至 SHA-2/SHA-3。

2024 年 · NIST 发布后量子密码标准

NIST 正式发布三项后量子密码标准：FIPS 203（ML-KEM，基于格）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA），标志着密码学正式进入后量子时代。详见第十四章。

第三章 关键人物志

密码学的每一次重大飞跃，背后都站着少数天才的头脑。以下是塑造了密码学面貌的 12 位关键人物：

第四章 核心概念与分类

4.1 三大密码学目标（CIA + N）

4.2 加密体系三大分类

下面这张图用一个统一的框架对比了对称加密、非对称加密和哈希函数——注意对比每种体系密钥的数量、加密方向、是否可逆：

图：三大加密体系对比——对称加密、非对称加密、哈希函数

4.3 易混淆概念对比表

⚠️ 最常见的误解： “MD5 加密” 和 “SHA-1 加密” —— 它们根本不是加密！MD5 和 SHA-1 是哈希函数，不可逆、没有密钥。正确的说法是 “MD5 摘要” 或 “SHA-1 哈希”。

4.4 密码学中的随机数：一切安全的根基

如果说密钥是加密的灵魂，那么随机数就是灵魂的源头。没有真随机数，AES-256 也能被预测——等于裸奔。

4.4.1 为什么密码学离不开随机数？

密码学中几乎每个环节都需要随机数：

4.4.2 PRNG vs CSPRNG vs TRNG

随机数分为三类，只有一类适合加密：

⚠️ 关键认知： 日常加密用的都是 CSPRNG，不是 TRNG。操作系统从物理熵源收集种子，然后 CSPRNG 把少量真随机性”拉伸”成大量可用的安全随机数。

4.4.3 坏随机数的真实灾难

索尼 PS3 ECDSA 私钥泄露（2010）：Sony 在 PS3 的 ECDSA 签名中用了固定的随机数 k。攻击者拿到两笔不同交易的签名，通过数学推导提取出私钥。PS3 被彻底破解。

Debian OpenSSL 弱密钥事件（2008）：Debian 在修补 OpenSSL 时错误注释掉了一行熵收集代码，导致生成的 SSH/RSA 密钥仅依赖进程 PID（仅 32768 种可能）。全球上万服务器在使用可预测的弱密钥，持续了两年才被发现。

第五章 对称加密原理深度解析

5.1 流密码（Stream Cipher）

核心思想： 用一个密钥生成伪随机的”密钥流”，然后将密钥流与明文按位异或（XOR）^[19]得到密文。解密时用相同的密钥生成相同的密钥流，再次异或还原明文。

下面的 SVG 展示了流密码从密钥到密文的完整过程：

图：流密码加密原理——密钥流与明文逐位异或

5.2 分组密码（Block Cipher）

核心思想： 将明文分割成固定大小的块（如 128 位=16 字节），对每一块分别进行加密变换。不同块之间通过工作模式（第九章）关联以增强安全性。

5.3 AES 深度解析

AES^[20] 是目前全球使用最广泛的对称加密算法，由比利时密码学家设计（原名 Rijndael），在 NIST 公开竞赛中击败 14 个候选算法胜出。

下面这张图展示了 AES 的加密流程——注意理解轮数这个概念：AES 不是一遍就算完，而是把明文反复”揉面”多遍，每一遍叫做一轮：

图：AES 加密的 SPN 结构

AES 的四步操作（每轮都做）：

• SubBytes（字节替换）——混淆：每个字节通过 S 盒（一个 16×16 的非线性查找表）替换为另一个字节。这是 AES 安全性的核心来源。
• ShiftRows（行移位）——扩散：将 4×4 状态矩阵的每一行循环左移不同偏移量，让一个列中的字节扩散到不同列。
• MixColumns（列混淆）——扩散：将每一列的数据混合运算，进一步扩散。
• AddRoundKey（轮密钥加）——密钥混合：将当前轮的密钥与状态矩阵逐字节异或。

📌 为什么 AES 安全？ AES 的安全性建立在混淆（S 盒的非线性变换使输入输出关系极难分析）和扩散（ShiftRows 和 MixColumns 使每个输出位依赖于所有输入位）的组合上。AES-256 在量子计算机面前（Grover 算法）仍保持约 128 位有效安全强度。

第六章 非对称加密原理深度解析

6.1 RSA 算法原理

RSA 是密码学史上最优雅的发明之一——它解决了密钥分发这一困扰人类四千年的难题。其安全性建立在一个简单的数学事实之上：两个大质数相乘很容易，但从乘积反推两个质数极其困难。

RSA 密钥生成（完整步骤）

1. 选择两个大质数：随机选 p 和 q（各 1024 位以上），计算 n = p × q。n 是”模数”，长度即密钥长度。
2. 计算欧拉函数：φ(n) = (p-1) × (q-1)。这表示小于 n 且与 n 互质的正整数个数。
3. 选择公钥指数 e：选一个与 φ(n) 互质的数 e，通常固定为 65537（0x10001），因为它是质数且二进制只有两个 1（计算快）。
4. 计算私钥指数 d：求 e 关于模 φ(n) 的乘法逆元，即 e × d ≡ 1 (mod φ(n))。用扩展欧几里得算法可高效计算。
5. 公钥 = (n, e)，私钥 = (n, d)。p 和 q 必须销毁——任何持有 p、q 的人都能算出 d。

下面这张流程图展示了 RSA 从密钥生成到加密解密的完整路径：

图：RSA 完整流程——密钥生成、加密、解密

用小学数学理解 RSA

选 p=3, q=11，则 n=33, φ(n)=20。

选 e=7（与 20 互质），则 d=3（因为 7×3=21≡1 mod 20）。

公钥 (33, 7)，私钥 (33, 3)。

加密 m=4：c = 4⁷ mod 33 = 16384 mod 33 = 16

解密 c=16：m = 16³ mod 33 = 4096 mod 33 = 4 ✅

6.2 椭圆曲线密码学（ECC）

ECC^[22] 与 RSA 实现相同的功能（加密、签名、密钥交换），但使用比 RSA 小得多的密钥达到相同的安全强度。

主流曲线：

• Curve25519（X25519）： Daniel Bernstein 设计，256 位，约 128 位安全，速度极快且抗侧信道。TLS 1.3 和 Signal 协议的默认选择。
• P-256（secp256r1）： NIST 标准曲线，256 位，广泛使用但设计参数来源不完全透明。
• secp256k1： 比特币和以太坊使用的曲线。
• SM2： 中国国密标准椭圆曲线。

6.3 密钥交换：Diffie-Hellman

DH 密钥交换解决的核心问题：两个从未谋面的人，如何在不安全的信道上，协商出一个只有他们知道的共享密钥？

颜色混合类比（最经典的解释方式）：

1. Alice 和 Bob 公开约定一种”公共颜色”（比如黄色）。
2. Alice 自选一种”私有颜色”（红色），与黄色混合得到橙色，发给 Bob。
3. Bob 自选一种”私有颜色”（蓝色），与黄色混合得到绿色，发给 Alice。
4. Alice 将收到的绿色与自己的私色（红）混合 → 得到某种棕色。
5. Bob 将收到的橙色与自己的私色（蓝）混合 → 得到完全相同的棕色！
6. 窃听者 Eve 看到的只有黄色、橙色、绿色——无法混合出棕色。

数学实现： Alice 选私钥 a，计算 A = gª mod p 发给 Bob；Bob 选私钥 b，计算 B = gᵇ mod p 发给 Alice。共享密钥 = Bª mod p = Aᵇ mod p = gªᵇ mod p。窃听者从 g、gª、gᵇ 算出 gªᵇ 等价于解决离散对数问题^[23]。

第七章 哈希函数

哈希函数（Hash Function） 将任意长度的输入数据映射为固定长度的输出（称为摘要/散列值/指纹）。它与加密的核心区别是：哈希不能”解密”——它是单向的。

安全哈希函数的三个核心性质

主流哈希算法对比

🚫 MD5 和 SHA-1 还能用吗？

安全场景绝对不能！ MD5 在 2004 年被王小云实现了实用碰撞。SHA-1 在 2017 年由 Google 联合 CWI 研究所实现了首个碰撞攻击（消耗了 9,223,372,036,854,775,808 次 SHA-1 计算）。

仅可用于非安全场景： 文件下载完整性快速校验、去重等对安全性无要求的场景。但仍推荐至少使用 SHA-256。

哈希的实际应用

第八章 数字签名与 PKI（公钥基础设施）

8.1 数字签名如何工作？

数字签名是非对称加密的逆向使用——用私钥签名^[24]，用公钥验证。它实现了身份认证 + 数据完整性。

下面的流程图展示了签名和验证的完整路径：

图：数字签名流程——用私钥签名，用公钥验证

8.2 PKI 和证书链

公钥基础设施（PKI^[25]）解决了”你怎么确定这个公钥确实属于淘宝，而不是中间人伪造的？“

下面的图展示了从根 CA 到服务器证书的信任传递：

图：证书信任链——从根 CA 到服务器证书的逐级签名验证

第九章 加密工作模式与填充

9.1 分组密码的工作模式

分组密码只能加密固定大小的数据块（AES 为 128 位）。工作模式决定了如何处理多块数据以及块之间的关联方式。

⚠️ ECB 模式的著名”企鹅图”问题： 用 ECB 模式加密一张企鹅图片，虽然数据变了，但企鹅的轮廓清晰可见！因为相同颜色的像素块加密后仍然相同。这就是为什么 ECB 绝不应该被使用——它连最基本的模式隐藏都做不到。

9.2 填充方案

当明文长度不是分组大小的整数倍时，需要填充。最常用的是PKCS#7 填充：如果需要填充 n 个字节，每个填充字节的值都等于 n。

1
2
3

原始数据 (11 字节): 48 65 6C 6C 6F 20 57 6F 72 6C 64
PKCS#7 填充后 (16 字节): 48 65 6C 6C 6F 20 57 6F 72 6C 64 05 05 05 05 05
                                                      ^^^^^^^^^^^^^^^ 5 个 0x05 = 需要填充 5 字节

第十章 当前主流加密方案全景

10.1 TLS 1.3 / HTTPS —— 互联网的安全基石

TLS 1.3^[27]（2018 年发布，RFC 8446）是现代互联网加密的核心协议。相比 1.2，它做了革命性的简化——废弃了所有不安全算法，将握手过程从 2-RTT 缩短为 1-RTT。

下面的流程图展示了一次完整的 TLS 1.3 握手：

图：TLS 1.3 握手——现代互联网的加密握手协议

10.2 端到端加密：Signal 协议

Signal 协议是 WhatsApp、Signal、微信等数十亿用户使用的端到端加密协议。核心创新是 Double Ratchet（双棘轮）算法：

• X3DH（扩展三重 Diffie-Hellman）： 初始密钥协商，即使一方离线也能完成
• DH 棘轮： 每轮通信都生成新的 DH 密钥对，实现前向安全（即使长期密钥泄露，历史消息也无法解密）
• 对称棘轮： 每条消息都衍生出新的对称密钥，实现后向安全（当前密钥泄露不影响未来消息）

10.3 磁盘与文件加密

10.4 区块链中的密码学

区块链是密码学的集大成应用：

• 比特币： ECDSA (secp256k1) 用于交易签名，SHA-256 用于工作量证明，RIPEMD-160 用于地址生成
• 以太坊： ECDSA (secp256k1) 用于交易签名，Keccak-256 用于地址和状态根
• 零知识证明（ZKP）： zk-SNARKs 使用配对友好椭圆曲线，实现”证明我知道 X 但不透露 X”

10.5 加密在你一天中的 24 小时

加密不是「打开浏览器才有的东西」——它渗透在你数字生活的每一秒。以下按时间线展示各个触点：

总结： 从睁眼到入睡，你与加密的交互至少发生 50-100 次，绝大多数时候你完全感知不到。这正是密码学工程设计的最高境界——安全应该是透明的。

10.6 Wi-Fi 加密：从 WEP 到 WPA3

Wi-Fi 是地球上使用最广泛的无线加密场景，它的安全进化史就是一部密码学攻防史。

WEP（1999）——密码学灾难

WEP 使用 RC4 流密码，设计上存在致命缺陷：24 位 IV 太短，每 1670 万个数据包循环一次，在繁忙网络里几分钟就重用了。IV 重用导致流密码被破解——2001 年即可在 60 秒内破解 WEP。

WPA2（2004~至今）

WPA2 用 AES-CCMP 替代了 RC4。核心机制是四次握手（4-Way Handshake）：

WPA3（2018）

WPA3 针对 WPA2 的缺陷做了根本性重构：

实际使用建议： 新路由器建议开 WPA3。只能用 WPA2 的话：使用 16 位以上随机密码 + 禁用 WPS + 开启 PMF。

10.7 DNS 加密：你的上网记录不该是明文的

传统 DNS（域名��IP 地址的查询服务）是明文的——你的 ISP 和咖啡店 Wi-Fi 管理员能看到你访问的每个网站。

三种加密 DNS 方案对比：

⚠️ 最常见误解： DNSSEC 不加密。它只给 DNS 记录加签名，防篡改。你的 ISP 仍然能看到你查了什么域名。DoH 和 DoT 才负责加密传输。

实用建议： Android 设置→网络→私人 DNS，填入 dns.google（开启系统级 DoT）。

10.8 密码管理器：零知识加密的典范

以 Bitwarden（开源密码管理器）为例的零知识加密^[28]架构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

用户输入：主密码（唯一需要记住的东西）
         +
         邮箱地址
         ▼
┌─ KDF（密钥派生函数）─────────────────┐
│  Argon2id（内存硬化，防GPU暴力破解）   │
│          ▼                            │
│       主密钥（仅存在于你的设备上）     │
│        → 永远不发给服务器              │
└──────────────────────────────────────┘
         ▼
   用主密钥解密 → 获取对称加密密钥
         ▼
   用 AES-256-CBC 解密每个密码条目

实操建议： 如果用 Bitwarden，在设置中把 KDF 切换为 Argon2id（默认配置：64MB/3迭代/4并行度）。

第十一章 国密算法体系

中国国家密码管理局发布的商用密码算法标准体系：

第十二章 加密解密实操实战

12.1 OpenSSL 命令行实战

OpenSSL 是加密解密实操的”瑞士军刀”——以下所有命令可直接运行。

对称加密（AES-256-GCM，推荐）

1
2
3
4
5
6
7
8
9
10

# 加密文件（需要输入密码）
openssl enc -aes-256-gcm -pbkdf2 -iter 100000 \
    -in secret.txt -out secret.enc

# 解密文件
openssl enc -d -aes-256-gcm -pbkdf2 -iter 100000 \
    -in secret.enc -out secret_dec.txt

# 对比原文和解密结果
diff secret.txt secret_dec.txt  # 无输出 = 完全一致 ✅

非对称加密（RSA + OAEP 填充）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 生成 4096 位私钥
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 \
    -out private_key.pem

# 提取公钥
openssl pkey -in private_key.pem -pubout -out public_key.pem

# 用公钥加密（OAEP 填充是安全的签名方案）
openssl pkeyutl -encrypt -pubin -inkey public_key.pem \
    -pkeyopt rsa_padding_mode:oaep \
    -in message.txt -out encrypted.bin

# 用私钥解密
openssl pkeyutl -decrypt -inkey private_key.pem \
    -pkeyopt rsa_padding_mode:oaep \
    -in encrypted.bin -out decrypted.txt

哈希与数字签名

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# SHA-256 哈希
sha256sum file.txt

# 对文件签名
openssl dgst -sha256 -sign private_key.pem \
    -out signature.bin document.pdf

# 验证签名
openssl dgst -sha256 -verify public_key.pem \
    -signature signature.bin document.pdf
# 输出 "Verified OK" = 签名有效 ✅

# 生成自签名证书（开发/测��用）
openssl req -x509 -newkey rsa:4096 -keyout server_key.pem \
    -out server_cert.pem -days 365 -nodes \
    -subj "/CN=localhost"

12.2 Python 加密编程实战

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35