为什么要保持简单

一篇技术文章最有价值的部分，往往是那个终于被讲清楚的细节：一个字节如何被解释，一条指令怎样访问内存，一个看似合理的方案为什么在边界条件下失效。

这个博客想留下的，就是这些细节。

从一个具体的问题开始

“理解计算机”太大了。“为什么 0.1 + 0.2 会出现误差”则是一个可以动手的问题。

先手算一个例子，再写几行代码观察结果，最后回到原理。沿着这条路径，概念就有了落脚点。读完之后，最好能自己复现一次，而不只是记住几个术语。

这里的文章也尽量遵循这个顺序：问题、实验、解释、边界。

比如讨论 RSA，先选两个小素数，把密钥和密文算出来，再问为什么能还原；讨论文件的熵，先造出一个字节频率均匀、却仍能压缩的文件，再问统计遗漏了什么。问题有了具体数字，就不容易被一句宽泛的结论带过去。

保持简单，并不意味着省略限制条件。相反，一个解释越简洁，越需要说清楚它在什么前提下成立。

讨论算法时，除了描述它如何工作，也要问它付出了什么代价；展示代码时，除了给出运行结果，也要交代输入与假设。能用一个小例子解释清楚的地方，就先把这个例子走完。

如果使用教学模型，也应该标出它与真实系统的区别：固定小数位的模型可以说明舍入，却未必能复现浮点加法的全部行为；几条汇编可以展示寻址，却不能代表所有编译器的输出。把这些界限说清楚，例子才值得信任。

简单的表达，应该让人更容易接近问题的复杂之处。

本站用 Markdown 写作，再通过 Python 和模板生成静态页面。文章和构建脚本放在一起，一次修改就能留下清晰的记录。

这套方式的好处很朴素：打开文件就能开始写；换一个编辑器，文字仍然在那里；页面样式改变，内容也能继续使用。

工具够用以后，就可以把注意力放回文章本身。发现推导少了一步，就补上；实验结果与原来的理解不一致，就回头修正解释。文章不必一次写成定稿，但应该让后来的读者看到更准确的版本。

页面需要清晰的标题、舒适的行距，以及能在手机上读下去的代码块。目录帮助读者找到想看的部分，摘要帮助读者决定是否继续。

其余的空间，留给文字，也留给思考。

如果你第一次来到这里，可以从乱码与编码开始，看看同一串字节如何变成不同的文字；想沿着计算走远一点，也可以读读RSA 的手算与逆向示例，从一把小钥匙走到验证程序的信任问题。

保持简单，保持好奇。下一篇，从另一个小问题开始。