AI 翻译小记

事情开始得没那么正式：我只是想把 Lampson 那篇 Hints for Computer System Design 读顺一点。

过去几天，我用 Codex 翻译了 11 篇计算机经典论文和文章。

这里的“翻译”不是把英文丢进一个输入框，再复制一份中文出来。

我最后得到的是一组可以放进博客 /paper/ 里长期维护的中文 Markdown：有页面元数据，有段落结构，有代码块，有表格，有引用锚点，有术语第一次出现时的英文注释，也能通过 Hugo 构建和浏览器检查。

这 11 篇按完成顺序是：

1. 计算机系统设计箴言：Hints for Computer System Design，Butler W. Lampson
2. “越差越好”的兴起：The Rise of “Worse Is Better”，Richard P. Gabriel
3. 没有银弹：No Silver Bullet: Essence and Accidents of Software Engineering，Frederick P. Brooks, Jr.
4. 计算机程序设计作为一种艺术：Computer Programming as an Art，Donald E. Knuth
5. 对信任“信任”的反思：Reflections on Trusting Trust，Ken Thompson
6. 编程即理论建构：Programming as Theory Building，Peter Naur
7. 苦涩的教训：The Bitter Lesson，Rich Sutton
8. 数据不可思议的有效性：The Unreasonable Effectiveness of Data，Alon Halevy、Peter Norvig、Fernando Pereira
9. 你和你的研究：You and Your Research，Richard W. Hamming
10. 计算机程序设计的公理基础：An Axiomatic Basis for Computer Programming，C. A. R. Hoare
11. UNIX 分时系统：The UNIX Time-Sharing System，Dennis M. Ritchie、Ken Thompson

现在回头看，“AI 会翻译”反而是最没意思的部分。这个说法太粗，只能说明模型会把英文句子换成中文句子。

更值得写下来的，是每篇文章都有不同的麻烦。Codex 不是靠同一个提示词把它们碾过去，而是在文件系统里一步步处理输入、清理结构、翻译、修术语、修引用、重建表格、跑检查、进博客预览。

下面按时间顺序讲。

1. Hints for Computer System Design：从一次实验变成一条流水线

第一篇是 Butler Lampson 的 计算机系统设计箴言。

它把 Lampson 做系统的经验压缩成一组提示，讨论接口、完整性、性能和容错。很多句子看起来像常识，真正做系统时才知道多难。

它是整批翻译的原型。

最开始的问题很朴素：我想读这篇系统设计经典，但 PDF 读起来累。27 页，约 13,000 个英文词，里面有大量系统设计术语、参考文献和一张把全文提示语串起来的图。

难点不是“英文很难”。难点是 PDF。

PDF 保存的是页面上的字和位置，不是文章结构。抽出来以后会有页眉、页脚、断行、页码、被拆散的段落，以及很容易坏掉的图表。直接翻译这种东西，只会把坏结构包装成一份看起来更顺的坏译文。

第一轮抽出来的 Markdown 基本不能读。我最后让它先停下来清源文：页眉页脚删掉，段落接回去，再翻译。

图 1 本质是一张文本矩阵，于是它被重建成 Markdown 表格，而不是被当图片扔掉。参考文献保留英文，正文里的引用改成能跳转的锚点。

更重要的是，Codex 开始显露出“翻译工具”之外的能力：它不只是输出中文，而是在目录里维护一组中间文件。source.md 是清理后的原文，translated.zh-CN.md 是译文，terms-candidates.tmp.md 是术语候选，terms-annotation-report.tmp.md 是术语标注报告。

这一篇之后，流程雏形出来了：

1. 先修源文，不急着翻译。
2. 参考文献默认不翻。
3. 技术术语单独过一遍。
4. 引用必须能点击。
5. 最后用脚本检查，而不是靠“看起来不错”。

这篇最重要的结果不是计算机系统设计箴言本身，而是它证明这件事可以工程化。

2. The Rise of “Worse Is Better”：短文章也有格式噪音

第二篇是 Richard P. Gabriel 的 “越差越好”的兴起。

它解释了“越差越好”为什么会在现实世界胜过“正确之物”：简单、可移植、能传播的系统，常常压过更完美但更重的设计。

我一开始以为它会很快。它比计算机系统设计箴言短得多，看起来应该很轻松。

结果第一件事还是清理格式噪音。

源文件里混进了 PDF 或网页导航文字，比如 Previous、Up、Next。还有硬换行、页内 break、PDF 风格的 ``…’’ 引号，以及一些抽取错误：the-right-thing、must sacrificed、Unix-namely。

这类问题很不起眼，但如果不处理，AI 会认真地把导航按钮翻译进正文。读者看到“上一页、上级、下一页”时，不会觉得这是论文风格，只会觉得译文混进了网页残留。

处理方式很直接：先清理源文，再翻译，再抽取术语。

短文也不能跳过源文清理。越短的文章，残留噪音越显眼。

3. No Silver Bullet: Essence and Accidents of Software Engineering：脚注不是脚注，是参考文献

到 Frederick P. Brooks, Jr. 的 没有银弹，麻烦换了个形状。

这篇论文区分软件工程里的本质困难和偶然困难。几十年后行业每一轮“新银弹”热潮，最后都要回到 Brooks 的问题上。

它的麻烦不是 PDF 双栏，而是引用结构。

原文没有一个标准的参考文献章节。引用信息散落在正文脚注里。初看这只是排版差异，但对网页阅读很要命：正文有脚注，底部有脚注定义，Hugo 有自己的脚注处理方式，读者也期待论文式参考文献能统一跳转。

Codex 先做常规清理：去掉重复页眉、分页标记、页码；修复明显文字识别错误，比如 pipes and filters、bug-type frequencies、data flow；把图 1 从固定宽度文本转成 Markdown 表格。

然后它做了一个更像编辑的动作：把嵌在脚注里的参考文献信息移到底部 ## References，把正文里的 [^n] 改成 [n](#ref-n)，再给每条参考文献加锚点。

这一步不做，网页里的引用就会变成一堆看似存在、实际没法顺手跳转的脚注。如果只是“翻译”，脚注可以原样留下。但如果目标是博客里的论文译文，就要让引用变成可导航的结构。Codex 在这里做的不是语言转换，而是文档规范化。

最后机械检查给出：12 个参考文献锚点，12 个正文引用链接，0 个错误，0 个警告。

这是我开始信任这条路的时刻之一。不是因为模型很聪明，而是因为它能把“脚注散落在正文里”这种坏结构，整理成可检查的结构。

4. Computer Programming as an Art：两栏、希腊文和坏掉的参考文献

Knuth 的 计算机程序设计作为一种艺术 开始让我意识到，老 PDF 不只是丑。

这是 Knuth 的图灵奖演讲，讨论程序设计为什么既是科学也是艺术。它保留了一个今天容易被工具链、指标和绩效表格压扁的判断：程序不是只要能跑就完事。

这篇开始进入真正麻烦的老论文格式。

PDF 有可抽取文本层，所以不需要文字识别。但直接抽取出来的 source.raw.md 不能用：两栏文字会在同一行交错，第一页和第七页尤其明显。还有页脚、夹在段落中间的版权块、断词、希腊词 τέχνη，以及被文字识别搞坏的参考文献标题，例如 Tile / Tire / Ratioehlative。

这篇文章本身还很微妙。Knuth 反复讨论 art 和 science 两个英文词的含义。如果机械地全部翻成“艺术”和“科学”，有些句子会丢掉它在讨论英语词源和用法这件事。

处理分成几步：先用 PDF 和外部转写做交叉校验，修掉明显的双栏抽取错误和参考文献损坏。再翻译正文，但在讨论英文词本身时保留 art 和 science。术语处理也不是无脑标注，比如报告里明确说：art 和 science 的英文注释要保持稀疏，否则整篇文章会被重复标注打断。

这一篇让我看到术语管理不是“越多越好”。

技术翻译里保留英文，是为了消歧，不是为了让页面看起来更专业。该标的词要标；反复讨论的基础词，反而要克制。

5. Reflections on Trusting Trust：代码图必须当代码处理

Ken Thompson 的 对信任“信任”的反思 不长，但不能随便翻。

它用自复制程序和编译器后门说明：即使源码干净，也不能简单推出工具链可信。

这篇的难点是代码。

PDF 的嵌入文字识别结果可以抽出来，但双栏布局会把段落交错，所有代码图都坏了。对这篇文章来说，代码不是装饰。自复制程序、编译器转义、特洛伊木马编译器，全靠代码片段讲故事。

如果代码坏了，整篇就坏了。

Codex 不能只翻译文字识别文本。它必须对照扫描页图片，把 C 代码重建成 c 代码块。图 1 的 C 代码转写说明，则被改成表格。中文译文里把这些 figure 标成“代码”，因为它们本质上不是普通插图。

还有一个细节很有意思：扫描版里图 2.1 和图 2.2 的图注看起来和正文逻辑是反的。Codex 在审校笔记里没有偷偷改掉当没事发生，而是记录了这个源文不一致：最终按正文逻辑使用一致的顺序，2.1 是基础 \n 转义，2.2 添加 \v，2.3 用十进制 11 引导编译器。

这时它已经不像翻译器了，更像一个会被我叫去修文档的人。普通翻译工具会把坏代码翻成中文旁白，然后安静退场。Codex 可以把代码当代码，把图注当结构，把疑似原文错误记进审校笔记。

技术翻译不是把英语抹成中文。技术翻译首先要保护技术对象。

6. Programming as Theory Building：扫描件、旁边页渗透和哲学词

Peter Naur 的 编程即理论建构 又换了一种麻烦。

Naur 认为，编程的核心不是产出程序文本，而是程序员围绕问题和解法建立一种可解释、可延续、可修改的理论。真正丢失的往往不是文本，而是活在人脑里的理论。

这篇的输入更麻烦：PDF 只有图像，没有可抽取文字，普通提取器只能产出几处分页标记。扫描件是双栏，还有邻页或背面文字渗透出来。页面边缘甚至有不属于正文的可见文字。

这时 Codex 的策略不是硬做文字识别到底。

它把 14 页渲染成图片，同时找到 Flylib 的网页转写作为正文基础，再用页面图像抽查标题、第 7 页、参考文献和最后一页。扫描边缘的干扰文字被明确忽略。明显抽取错误也被修复，比如 modifi-ability、参考文献页码范围 207213 / 248274，以及最后粘成一团的 cannotand so need notsay。

真正麻烦的是术语。

Naur 这篇不是普通工程论文，它在谈 Ryle、Popper、默会知识、程序理论。program death / program revival 不是进程退出和重启，而是一个团队持有的程序理论消失，以及后来的人试图重建它。World 3 不是“第三世界”，而是 Popper 的世界 3。

Codex 在术语报告里把这些选择写清楚：

• Programming as Theory Building 译成“编程即理论建构”，不是更硬的“编程作为理论建构”。
• program death / program revival 保留生命隐喻，译成“程序死亡”和“程序复活”。
• tacit knowledge 用“默会知识”，不是更泛的“隐性知识”。
• World 3 用“世界 3”，避免误读成地缘政治里的“第三世界”。

这一篇说明，Codex 能解决的不只是文字识别。

它还可以把术语选择变成可讨论对象。以前这类判断藏在译者脑子里；现在它会落到一个 report 文件里，供人检查、反驳、修改。

7. The Bitter Lesson：短文的价值在术语密度

第七篇换成 Rich Sutton 的 苦涩的教训。

Sutton 总结 AI 研究几十年的反复教训：长期胜出的往往不是人类手工塞进去的领域知识，而是能随计算规模增长的搜索和学习方法。

这篇很短，几乎像一篇博客。

难度也确实低很多：清理标题、作者、日期，移除分页标记，修复被拆开的短语，恢复 search 和 learning 的斜体强调。

但它的术语密度不低。

general methods、leverage computation、human-knowledge approach、deep search、self play、value function、hidden Markov models、scaling computation，这些词如果不统一，文章会变成 AI 史散文。读者看着很顺，但不知道每个概念到底对应哪个英文。

Codex 的处理重点转到术语标注：保留第一次出现的英文，后面用中文跑完。报告里确认没有遗漏。

当输入干净、结构简单时，整条流水线应该很快通过。它确实通过了。流程不能只服务最复杂的论文，也要能低成本处理短文，否则工具本身就会变成新的负担。

8. The Unreasonable Effectiveness of Data：多栏 PDF 和重复拉出式引文

到 Alon Halevy、Peter Norvig、Fernando Pereira 的 数据不可思议的有效性，问题回到 PDF 本身。

这篇文章讨论为什么在自然语言和 Web 问题上，海量真实数据加简单可扩展模型，常常比精巧但小规模的理论更有效。

这篇来自打印版、多栏 IEEE PDF，有很多视觉装饰。

难点是阅读顺序。

多栏 PDF 抽取最容易出的问题，是把正文、页眉、页脚、装饰性引文、栏目标题混在一起。尤其是拉出式引文：它们在页面上看起来像设计元素，但内容往往只是正文里一句话的重复。如果把它们保留在源文里，翻译后读者会觉得作者怎么突然开始自我引用，而且引用的还是刚说过的话。

Codex 用页面图像验证分栏阅读顺序，删除重复页眉、页脚、页码和装饰性栏目元素。四条拉出式引文被明确省略，因为它们重复正文并打断阅读顺序。

还有两个小风险被记录下来：Dublin Core Metadata Initiative point-encoding scheme 按 PDF 抽取保留；示例一节有一个疑似多出来的右括号，中文翻译里把它当标点噪音去掉。

这篇的经验是：忠实不是保留所有视觉噪音。

翻译的是文章，不是 PDF 版式事故现场。拉出式引文如果只是重复正文，就应该从可读版源文里拿掉。否则所谓“忠实原文”，最后忠实的是排版软件。

9. You and Your Research：长演讲稿和分块缝合

Richard W. Hamming 的 你和你的研究 没有公式、代码、表格，也没有参考文献。

这是 Hamming 关于如何做重要研究的演讲，谈选题、勇气、工作习惯、表达、环境和自我欺骗。它不是科研成功学，里面最刺人的地方是那个问题：你到底想不想做一流工作。

听起来容易，但它长，而且是演讲稿。

长演讲稿的难点不在结构，而在语气和一致性。Hamming 的文本有很多口语推进、转折、例子和劝诫。如果一次性翻译，容易前后风格漂移；如果分块翻译，又容易在分块边界留下缝合线。

Codex 把翻译拆成六个可审计的小块，再合并成 translated.zh-CN.md。之后它检查并修复了两个分块边界造成的句子问题。术语报告保留了不少带语境的译法，比如 attack 译成“攻击途径”，drive 译成“驱动力”，appearance of conforming 译成“顺应的表象”，orientation 译成“定向”。

还有一个很工程化的小动作：分块翻译后，Markdown 容易留下硬换行和相邻的单行段落。Codex 做了一次机械重排，并把重排前的版本保留为 translated.zh-CN.before-reflow.tmp.md。

这篇的价值在于说明：即使没有 PDF 折磨，长文本也需要流水线。

人类写作里最讨厌的一类问题，就是每段都没大错，但合起来不像同一个人说的话。AI 翻译也一样。分块能解决上下文长度问题，但合并和重排必须跟上。

10. An Axiomatic Basis for Computer Programming：图像 OCR、数学公式和 HTML 表格

C. A. R. Hoare 的 计算机程序设计的公理基础 是整批里最硬的一篇。

Hoare 在这篇论文里提出用公理和推理规则证明程序性质的框架，也就是后来 Hoare logic 的源头。

PDF 只有图像。PyMuPDF 报告 6 页，0 个嵌入文本。也就是说，正常文本抽取没有东西可抽。

看到 0 个嵌入文本时，我基本知道要进坑。做法是渲染整页图片，再裁出左右栏，用 Apple Vision 做文字识别，把原始识别结果存下来。但我没有相信识别结果。公式、定理记号、表格，全都要对照页面图像重建。

这篇最麻烦的是数学和表格。

Hoare 的正文里有断言、推理规则、赋值公理、证明步骤，还有几张小表。普通 Markdown 表格对这种内容很脆弱，尤其当单元格里有数学符号、换行、公式、证明编号时。最后译文里表 I、表 II、表 III 都重建成结构化 HTML 表格，而不是硬塞 Markdown。

公式一开始并没有被 AI 顺利处理好。我后来做了一个很笨但有效的反馈环：先把公式改成 LaTeX Markdown 语法，再接上 Chrome browser MCP 看实际渲染效果，然后拿浏览器里的公式和原论文截图对照，不对就继续改。直到页面上看到的东西和原论文里的公式基本对齐，才算过关。

这里还踩了一个 Hugo/Goldmark 的坑：原始 HTML 块里，如果嵌套标签缩进，Goldmark 可能把它解析成 Markdown 代码块，导致表格坏掉。Codex 在 review notes 里记录了这个坑，并把嵌套 HTML 左对齐。

引用也要特殊处理。因为页面启用了数学渲染，引用链接不能写成容易被数学渲染器误伤的形式。最后统一成 <a href="#ref-8">[8]</a> 这种普通锚点，并让数学渲染器忽略 <a> 标签。

这一篇几乎已经不像翻译，更像一次小型文档工程。

文字识别、LaTeX、HTML 表格、Hugo、Goldmark、引用、术语，全部挤在 6 页旧论文里。旧论文不长，但密度很高。

11. The UNIX Time-Sharing System：双栏抽取和统计表重建

最后一篇是 Dennis M. Ritchie 和 Ken Thompson 的 UNIX 分时系统。

这篇论文介绍早期 UNIX 的文件系统、进程模型、Shell、I/O 抽象和系统规模。现代操作系统、工具链文化和“万物皆文件”这类设计趣味，都能在这里看到早期形态。

这篇又回到老 CACM 双栏 PDF。

抽取出来的第一页很典型：标题、作者、摘要、第一节正文互相穿插；The UNIX Time-Sharing System 被拆成奇怪位置；moredescribesmodernonlyandthe 这种词粘连直接出现；[l] 要修成 [1]；tile password file 要修成 the password file。

后面还有第 9 节统计数据。原文是论文里的统计表，如果简单保留成纯文本代码块，博客里不够好读；如果直接用 Markdown 表格，又和 paper section 里其他论文的表格风格不一致。

Codex 先清理双栏抽取问题，再翻译操作系统术语。image 译成“映像”，trap 译成“陷阱”，mount、link、Shell 这些历史 UNIX 词保留英文或半保留英文，避免把原文的系统语境翻软。

统计数据先在翻译工作区重建成表格。后来进博客时，又进一步改成和 Hoare 那篇一致的 HTML 表格样式，并在浏览器里检查移动端横向溢出和控制台错误。这其实已经不是翻译问题，只是我不想让它在博客里显得比 Hoare 那篇潦草。

这一篇是一个很好的收尾。

因为它把整条链路都跑了一遍：PDF 清理、术语、引用、统计表、Hugo 构建、浏览器 MCP、移动端溢出检查。到这里，AI 已经不是在“翻译一篇文章”，而是在维护一个发布系统里的内容。

AI 到底解决了什么

按这 11 篇看，AI 解决的不是一个问题，而是一堆互相缠在一起的小问题。这里我用的是 Codex，但同类的代码代理工具，比如 Claude Code，只要能读写文件、调用工具、保留中间产物，也可以执行类似流程。

有些问题在输入端：PDF、HTML、扫描件、双栏、多栏、导航残留、页眉页脚、坏文字识别、断词和重复拉出式引文。有些问题在结构里：标题、章节、脚注、参考文献、引用锚点、代码块、表格、公式和 Hugo 页面元数据。还有一些问题更烦，肉眼看不出来，但读起来会一直硌着：术语第一次出现时要不要保留英文，某个链接是不是真的能跳转，数学公式在浏览器里是不是被渲染坏了。

这些都不是一句“翻译一下”能覆盖的事。

但 AI 没有解决最终责任问题。

什么词该怎么译，哪里该忠实，哪里该为了网页阅读重排，哪个文字识别结果是错的，哪个原文图注可能本来就有问题，这些仍然要人判断。

变化在于，以前人要亲手处理每一步；现在人更多是在检查机器交付的中间产物有没有偏掉。

如果按传统方式做，这 11 篇不会只是“翻译 18 万字符”。你还要手工清 PDF、校对 OCR、重建表格、统一术语、修引用、搬进博客、检查移动端。熟悉计算机论文的人全职做，两三个月不一定能做完；如果还要边读边查背景、边排版边审校，时间只会更难看。我这次实际花了两天里零散的五六个小时，而且很多时间是在写公司项目的间隙顺手推进。

时间和 token

下面的数字是从 Codex session 记录里粗略汇总出来的。它们不是实验室里擦干净的 benchmark，而是实际工作现场的账本：会话会挂着，人会切走做别的事，早期原型流程和后续正式流程也混在一起。有的 session 是我切去写公司代码前开的，回来时才继续看。

中文译文产物加起来大约是：

指标	数字
译文文件	11 个
Markdown 行数	2,812 行
wc -m 字符数	180,333
记录到的唯一会话	11 个
会话日志跨度合计	约 26.8 小时
记录到的总 token	约 61.3M
其中缓存输入 token	约 56.1M
非缓存输入 token	约 4.75M
输出 token	约 500k
推理输出 token	约 117k

这里最容易误读的是时间和 token。

26.8 小时不是“我连续干了 26.8 小时”，也不是“机器纯跑了 26.8 小时”。它是会话从开始到最后一次 token 统计之间的日志跨度，里面包括离线、切换任务，以及某些会话长时间挂着。

更接近体感的说法是：第一篇计算机系统设计箴言花得最长，因为那时流程还没成型；后面进入稳定流程后，短文章可以十几分钟，长 PDF 和复杂表格可能一小时以上。真正花在键盘前盯着它推进的时间，大约是两天里零散的五六个小时。

61.3M 总 token 看起来很吓人，但其中 56.1M 是缓存输入 token。长会话会不断携带上下文、文件片段、工具结果和历史指令，缓存输入会滚得很大。这个数字适合描述“模型处理过多长的上下文”，不适合直接当成 API 账单。

更有参考价值的是：非缓存输入约 4.75M，输出约 500k，推理输出约 117k。即使如此，这也不是一个小任务。它更像一个小型编辑项目，被压缩进了 agent 工作流。

AI 没有让这些工作消失。它只是把大块人工劳动变成了机器执行、人类审查。

成本没有消失，只是从逐句劳动转移到了流程设计和最终审校。

复盘

这批翻译做完后，我最确定的一点是：工作流比提示词重要。

如果只靠一个提示词，“帮我翻译这篇论文”，大概率会得到一篇看起来还行、但结构不可审计的中文。真正能复用的是那些不太像“AI 魔法”的东西：源文先清理，参考文献单独处理，术语候选拉出来人工裁剪，公式和表格在浏览器里看一遍。

这也是为什么这条流程看起来直接，但不懂编程的人未必容易照着做。它不要求你写复杂系统，却默认你会把任务拆成阶段，会保留中间产物，会看 diff，会相信脚本胜过感觉。source.md 可以对照原文，translated.zh-CN.md 可以查看差异，review-notes.tmp.md 可以记录不确定和原文问题。Hugo 构建和浏览器检查可以证明它至少没有在发布层面坏掉。

AI 翻译冲击最大的也许不是“懂英文的人”，而是“把英文逐句搬成中文”这类可计件劳动。初译、格式清理、术语替换、引用修复都可以被 agent 扛走以后，人剩下的工作会变得更不讨好：选文、定标准、判断术语、处理歧义、审校关键段落、承担最终责任。

AI 不能替我读经典，但可以减少阅读前的摩擦。

我翻这些文章，不是为了收藏一堆中文文件。真正的目标是读。英文原文当然可以读，但读经典论文经常有额外摩擦：PDF 难看、引用不方便、术语要反复查、段落又长又硬。

AI 做的是把这些摩擦削掉。

它不替我理解 Brooks 为什么说没有银弹，也不替我判断 Hoare 的形式化理想在今天还剩多少光泽。但它能把原文整理成一份我愿意读、愿意改、愿意链接给别人的版本。

读研的时候，我其实有过一个很不自量力的愿望：把一批经典计算机科学论文翻译出来，整理成一个中文集子。后来这个愿望长期停在那里，因为它太像那种年轻时写在笔记本上的宏大计划，听起来很对，也很容易无限期搁置。

这次它终于没有停在 TODO 里。

不是因为 AI 比我更懂这些论文，而是因为它把最消耗人的那部分工作压低了：整理 PDF、修格式、搬引用、补术语、重建表格、检查链接。以前翻译一篇经典论文，是一个独立项目。现在它更像一次构建任务：准备输入，跑流水线，看差异，修错误，构建，预览，发布。

当年这个愿望迟迟没有动手，不是因为翻译本身神圣，而是因为前置工作太多：找版本、清 PDF、修 OCR、对引用、统一术语、排版发布。每一步都不大，但加起来足够让人把它放进“以后再说”的抽屉。

AI 没有替我完成那个愿望。它只是把这些前置工作压到了可以承受的范围。

剩下的部分，终于轮到阅读本身。