我眼中技术文档的演进图谱：从windows开发手册到 AI 智能体的知识传承-海口c网

-----一位25年的技术亲历者的时代观察

序

2000 年毕业进入科研所时，我未曾想过 CRT 显示器与泛黄的《Windows 宝典》会成为技术启蒙的坐标。从调试 MFC 控件的桌面开发起步，到 Web1.0 时代与 IE6 兼容性博弈的战术文档，再到 Kubernetes 部署手册成为跨部门协作的 "作战沙盘"——25 年职业历程中，技术文档始终是解码时代难题的钥匙。

这四分之一个世纪里，我从码农一路成长为创业者，亲历了从 Visual C++ 到 ChatGPT 的技术跃迁，也扮演过 IT 行业从开发到管理的全角色。当 Web2.0 的 AJAX 手册进化为 AI 时代的智能文档系统，那些被反复修订的技术记录早已超越工具属性：应急响应文档曾在系统崩溃时凝聚团队共识，云端协作文档见证过 AI 客服系统的迭代生长，每一页文字都刻着技术演进的年轮。

如今案头泛黄的《Windows 程序设计》与屏幕上实时更新的 AI 文档形成奇妙呼应。从软盘时代的纸质手册到 AI 大模型的智能文档，六个技术阶段的范式转移重塑着文档的载体、工具与编写逻辑，而这恰恰印证了技术传播的核心命题 —— 用最适配的媒介传递最精准的技术语义。

这份带着实践温度的观察手记，凝结着从桌面到 AI 每个时代的真实困境与突破智慧。愿后来者能在技术迷宫中，借这些文字点亮前行的灯。、

注：文章中素材均是自己亲历工作的见证

桌面时代（1995-2000）：文档的机械复刻

在我的大学期间，见证了DOS系统朝win3.1系统的转变，然而Windows 95 掀起的图形界面革命，让技术文档首次承担 "软件镜像" 的使命。在我大学生涯的尾声到2000年毕业，有一段时间我从事的都是基于winform桌面系统的开发，主要用的C++,Delphi后来衍生到C/S（Client/Server）系统，后来迭代到了MIDAS三层系统，但这个期间很短暂。因为web浪潮很快就来了我们不得不转型，当然这是后话。

桌面时代的技术文档特点：

1、技术文档高度聚焦在应用开发的场景

技术文档主要围绕 Windows 操作系统平台，详细阐述如何利用 Winform 框架开发各种桌面应用程序。文档会具体讲解桌面应用的界面设计、用户交互逻辑实现等内容，例如如何在 Windows 窗体上添加按钮、文本框等控件，以及如何处理这些控件的事件响应，以满足用户在桌面环境下的操作需求。

2、注重点在win API和控件的使用详解

当时的开发工具无论是C++,Vb,Delphi还是PB开发工具，都提供了丰富的控件库，技术文档对这些控件的使用进行了详尽说明。从基础控件如标签（Label）、文本框（TextBox）到复杂控件如数据网格视图（DataGridView）等，文档会介绍每个控件的属性、方法和事件。以按钮控件为例，文档会说明其 Text 属性用于设置显示文本，Click 事件用于处理用户点击操作，还会讲解如何通过代码动态设置控件的属性和行为，帮助开发者熟练掌握控件的使用方法，构建功能丰富的用户界面。

3、代码示例

那个年代没有网络，不像现在百度一下基本上什么问题就可以解决。那个年代的开发，技术文档凸显了很重要的一面，技术文档中的代码示例采用开发的语言。我们通过会通过大量的代码示例展示 Winform 开发的具体实现方式，还有语法格式，那时候的winfom就已经用了很多技巧，诸如，将每个界面都DLL编辑，然后主程序通过数据库的的配置动态的加载，如何在窗体加载时初始化数据，如何处理数据库连接和数据操作等。这些代码示例具有很强的实用性，开发者可以直接参考或复制使用，快速实现相应的功能。那个年代的程序员就是通过前辈们编写的技术文档，了解到整个系统的开发框架。

4、事件驱动模型

Winform 开发都基于事件驱动编程模型，所以技术文档对此进行了重点强调。文档会详细介绍事件驱动编程的概念和原理，以及在 Winform 中如何应用这一模型。

图：Delphi工具的事件编辑框

这张图还是我从DELPHi工具上截出来的图，例如，当用户点击按钮、输入文本或关闭窗体时，会触发相应的事件，开发者需要编写事件处理程序来响应这些事件。文档会通过具体的例子说明如何注册事件处理程序，如何在事件处理程序中实现业务逻辑，帮助开发者理解和掌握事件驱动编程的核心思想。

5、涉及 Windows API 交互

在一些复杂的 Winform 开发场景中，需要与 Windows API 进行交互，技术文档也会涉及这方面的内容。文档会介绍如何通过 P/Invoke（平台调用）技术调用 Windows API 函数，以实现一些 Winform 框架本身没有提供的功能，如获取系统信息、操作 Windows 注册表等。同时，文档会提醒开发者注意 Windows API 调用的安全性和兼容性问题，确保应用程序在不同的 Windows 版本上能够正常运行。在没有互联网的时代，程序员如果拥有一本windows API的开发宝典，那是一件很幸运的事情，因为会为你的开发带来很多宾利。

6、包含部署与安装指南

那时候的技术文档不仅关注开发过程，还包含应用程序的部署与安装指南。文档会详细说明如何将开发好的 Winform 应用程序打包成安装包，如何设置安装包的属性，如应用程序名称、版本号、安装路径等。此外，文档还会介绍安装过程中可能出现的问题及解决方法，帮助开发者将应用程序顺利部署到用户的计算机上。

图：桌面时代技术文档的模版

小结

Winform 开发年代的技术文档结构相对固定，通常包括引言、开发环境搭建、控件参考、编程模型、实战案例、部署指南等部分。这种固定的结构便于开发者查阅和学习，也可以根据自己的需求快速定位到相应的章节。例如，新手开发者可以先从开发环境搭建和基础控件使用开始学习，而有经验的开发者则可以直接参考复杂控件的使用和高级编程技巧。。

Web1.0 时代（2001-2005）：HTML 文档与 API 手册

我应该是02年开始转型成为JAVA程序员，当时前端和后端还没有严格区分，最初接触到的web项目就是JSP+JAVA BEAN。当时特别注重Servlet的技术开发。记得早起的项目都是以 “信息展示” 为核心，技术文档主要服务于 HTML 静态页面开发。系统很多都是企业内部的系统，当时的互联网还是以拨号上网为主，所以文档重点讲解如何用 HTML 标签构建页面结构，如<table>布局、<font>字体控制等，当然也有不少涉及动态交互逻辑。开始JS也用得很少，都是整页刷新，现在看来简直无法忍受，不过当年的客户表示可以接受。典型场景如就是许多企业内部管理系统、或是新闻门户的系统，这样的系统给客户带来了新鲜感，他们头一次感受到了免安装桌面程序，用浏览器就可以登录并操作系统了。

图：web1.0时代对应的技术文档

我把这个阶段称作为web1.0时代，这个阶段的技术文档的特点：

1、注重内容结构

记得这个阶段对于要使用的HTML标签尤为看中，在web1.0阶段还是比较重标记语言而轻编程逻辑的。一般需要编写项目需要用到的HTML标签化手册，里面都是项目可能涉及到的标签：如基础结构标签：详解<html>``<head>``<body>的嵌套规则，强调 DOCTYPE 声明对浏览器解析的影响；还有文本格式化标签：对比<b>与<strong>的语义差异，说明<blockquote>的缩进实现方式；多媒体标签：标注<embed>与<object>在 Flash 插件调用中的参数区别；当然也会带着CSS的说明，而这些是项目初期的项目美工也就是后来UI设计师角色提供的内容。考虑限于浏览器兼容性（IE bug 频发），文档通常附带 “浏览器 hack” 方案，如用*html前缀针对 IE浏览器做样式适配。

2、开发工具

对于winform程序转型最大的痛苦，莫过于就是通过记事本来编辑HTML代码了。当时前端的开发工具都局限于后端，如：当时用的jbuild工具都是后端javabean的开发。对于前端开发而言，会详细说明：如何用记事本创建 HTML 文件并保存为.htm格式；快捷键组合（如 Ctrl+F 查找标签）的效率技巧；手动校验 HTML 语法的方法（如检查标签闭合）。

3、网络优化开发

当时受限于网络带宽，所以网络优化开发是一件很重要的事情。技术文档就有个章节就会单独提炼出来说说优化图片的事情，如：GIF 与 JPEG 的压缩策略对比和使用的问题;如何用 ImageReady 切割图片并生成 HTML 表格拼接代码；在低分辨率屏幕（800×600）的布局适配技巧；而这些章节也是根据项目的情况而定。

当然还有一部分涉及到代码的开发，主要有精简规划的内容。如：移除 HTML 标签冗余属性（如<table border="1">需简化为<table border>）；用 CSS 替代 HTML 样式属性（如用.red {color:red}替代<font color="red">）；注释仅保留关键逻辑说明（避免多余注释增加文件体积）等；这部分优化也是集思广益，也会将很多程序员的建议采纳后转成文字添加在其中。

4、交互逻辑说明

这个阶段交互逻辑都以表单验证为主；一般都能实现简单的动态效果，也要考虑涉及实现，图片轮换效果（通过定时器切换<img src>属性）；下拉菜单（用 CSS+JavaScript 控制<div>显示 / 隐藏）；页面载入动画（简单的 gif 动画 + JavaScript 加载提示）的实现技巧。

5、文档形态多重性

跟winform时代一样，在web1.0时代相关的HTML权威指南是程序的红宝书，所以技术文档上有相当一部分内容都是完整的标签属性表格（带浏览器支持度标记）；印刷版代码示例（需手动逐行输入）；附录收录 ASCII 字符编码表；还有一些就是开发web系统的代码风格标签类的说明。那时候为了方便，已经用 FrontPage 制作 HTML 格式的 API 文档，通过锚点链接实现类库之间的关联查询。随后流行的 Javadoc 工具通过代码注解自动生成文档的时代还没到来。但在web项目开发"代码即文档" 的早期实践，为以后项目的文档埋下了伏笔。

小结

这个阶段的技术文档，专业术语密集。其中包含了计算机网络基础知识其中主要就是Http协议为主，文本编辑能力，还有基础的美工常识的内容。该引入 "技术白皮书 + API 参考" 的双层结构。白皮书用 HTML 表格呈现系统架构，API 文档则采用 "方法签名 + 参数枚举 + 返回值示例" 的标准格式。值得一提的是 XML 格式的 DOCBOOK 尝试，虽然因解析复杂未能普及，但其定义的标签首次实现代码片段的语义化标注，为后来的文档测试奠定基础。总而言之，这个阶段的文档也反映了web1.0时代的信息发布的核心定位。

Web2.0 时代（2006-2010）：Wiki 协作与 Markdown

这个阶段我是深刻体会到了web2.0时代的特点：以 "用户生成内容" 和 "交互体验" 为核心。AJAX技术兴起，很多框架如潮水一般而来,exttjs，jquery,dwr等；这个阶段宽带也逐步普及，技术文档也从静态从静态页面开发转向动态应用构建。文档重点从 HTML 标签使用转向：异步数据交互：XMLHttpRequest 对象的应用；动态 DOM 操作：JavaScript 操作页面元素。

图：接口文档范例

1、框架手册

这个阶段的技术文档形成了以AJAX为核心来组建技术知识体系。

一般都以AXAX请求为例，处理各类请求的方式及方法

还有DOM操作规范：详细说明getElementById、createElement等 API 的跨浏览器兼容写法

当然最为主要的还是JSON数据处理规范:对比 XML 与 JSON 的解析效率，推荐eval()与原生 JSON.parse 的使用场景

框架的说明：介绍当年流行的JQuery等框架，重点介绍$()选择的实现原理。以及插件开发的框架，最为重要的还是针对浏览器的解决方案。

2、开发工具使用手册

这个阶段，已经有集成的开发环境IDE的出现，如Eclipse，Viusual studio.net，前端开发比较流行Dreamweaver。所以有专门的章节要介绍IDE工具怎么安装，以及如何安装相应的插件的一些说明。

3、测试说明

web2.0时代，随着前端复杂度提升，测试已经是非常重要的一个环节。而测试方法和技巧不单单是测试用例这么简单，还要告知怎么结合浏览器或者工具，查看DOM结构和HTTP请求，以及如何在JS中断点调试和性能分析，也有高级的用法如使用一些抓包工具。

4、接口文档

这个阶段作为技术文档最为重要的环节，因为确定了前后端数据协议的规范。主要体现在三个方面：RESTful API 设计：GET/PUT/POST/DELETE 方法的资源操作语义；跨域解决方案：JSONP 的原理与安全风险（如：callback=?参数注入）；数据格式约定：XML 与 JSON 的字段命名规范等；

另外web交互最为重要的就是状态设计，通常会有几种常用的方案如：客户端缓存策略：使用localStorage（HTML5 早期草案）与 Cookie 的容量对比；无刷新分页实现：history.pushState()与锚点 (#) 结合的 URL 管理；以及离线应用：AppCache manifest 的配置方法；

5、交互模式和性能

这块也是重点，主要是有模态对话框的处理：遮罩层与焦点锁定的跨浏览器实现；相关事件流的的处理过程等；其次最为重要的就是针对AJAX调用时的性能要求，通常围绕三个方面：减少 HTTP 请求：合并 CSS/JS 文件，使用 CSS Sprites；延迟加载技术：图片懒加载（onload事件与滚动事件结合）；合理使用客户端模板引擎：

小结

这个阶段开始形成 "代码 + 文档" 的双生关系。Swagger 通过 YAML 定义接口规范，能同时生成开发文档和客户端代码；都可以表格化的方式展示API接口，并且可以确认哪些浏览器可支持的接口方式。以用户参与、以数据驱动的核心特征，技术文档从单纯的技术说明转变为包含交互设计、性能优化、用户体验的综合知识体系，加上前端技术的革新，前端也出现了模块化开发的事项，还有相应的构建工具的出现，为后续 Web3.0 时代的框架化开发（如 React、Vue）奠定了基础。

移动互联网时代（2011-2015）：响应式文档与多端适配

这阶段的初期，让程序员就分成了两种角色：一类是安卓程序员另一位是IOS程序员。这也是早期要从事移动互联网应用开发公司的标配。这一阶段的技术文档比起web2.0时代更为复杂，因为技术的适配要满足如下情况：

设备多样性：iPhone、Android 手机、iPad 等多尺寸屏幕的适配需求

网络环境复杂化：2G/3G/4G 与 Wi-Fi 的混合网络场景

移动原生开发：Objective-C/Swift（iOS）、Java/Kotlin（Android）的技术栈崛起

跨平台方案：PhoneGap、React Native 等一次编写多端运行的框架出现

所有的开放如果涉及到支付或者是用户，都离不开微信、支付宝的场景，而这些大咖公司也会提供一系列的超级技术文档，都围绕移动设备特性（摄像头、GPS、重力感应）展开的开发指南。自己编写的业务场景还要与其融合在一起。这个阶段技术文档的特点：

1、多端融合

早期的技术文档是需要与移动原生开发融合一体的系统，并且会形成双平台并行的技术知识体系架构，简单说同样的一个开发场景，你需要编写出两套方案：一套安卓一套IOS。这种双生态崛起也给带来文档呈现的新难题。可能你在在开发跨平台 SDK 时，需要同时维护 PDF 格式的开发者指南、HTML5 的移动端帮助中心，以及嵌入 APP 的上下文提示。Pandoc 工具的出现解决了多格式转换难题，通过一份 Markdown 源文件可生成 EPUB、PDF、HTML 等多种输出，而 Read the Docs 平台则实现文档的版本化管理，所以作为版本管理，你不同 APP 版本都需要对应独立的文档分支。

2、跨平台开发框架

这个阶段的中期，这个阶段许多框架也开始兴起如：React Native，我们技术人员可以在一个平台开发一套程序就可以满足andriod/IOS 的需求。但在跨平台这块就需要围绕三个方面展开：围绕JS与原生Api 通信机制通常就是所说的桥接技术、UI组件适配、还有最为重要的就是平台差异化处理：通过Platform.OS判断 iOS/Android 并渲染不同组件。

3、开发工具说明

这个阶段开发工具层出不穷，已经从单一IDE发展到对应的系列。已经有移动开发专业的工具：Xcode：iOS 开发的界面设计器 (Storyboard) 与调试工具;Android Studio：Gradle 构建脚本配置与 Lint 代码检查;Charles：移动应用的 HTTP 请求抓包与弱网测试.同时针对跨平台开发，针对混合场景需要打包、更新、代码热重载等技术，而这些技术也会有对应的一些工具如：PhoneGap CLI、RN热更新、FLuter重载等。

4、开发规范

要满足程序多端适配，尤其是从响应式到原生体验，确实要遵循相应移动web开发的规范。这里有不少内容如：viewport的配置、触摸交互式设计、移动性能优化等；尤其是设备特性开发这块针对摄像头的调用、地理位置、手势识别等相关内容。

如果从开发层次展开那么内容更多：如首屏加载优化：关键 CSS 内联，非关键 CSS 异步加载；图片使用 WebP 格式（2010 年 WebP 推出）；路由懒加载（React Native 的 React.lazy），还有网络优化：二进制协议 (Protobuf) 替代 JSON；长连接 (WebSocket) 替代轮询；断点续传与增量更新。

另外还有许多关于移动交互模式库的说明，如：侧滑菜单：DrawerLayout 的实现与手势响应；下拉刷新：Pull to Refresh 的事件处理流程；底部导航：TabBar 的选中状态管理与动画效果。

5、标准化体系

这个阶段后期逐步形成统一的标准：如W3C 移动 Web 标准：Web App Manifest、Service Worker 等规范；Open Mobile Alliance：移动应用分发与权限管理标准；Flutter 跨平台框架：自绘 UI 实现真正的一次编写多端运行。

同时关于移动工程也形成了相应的标准化：持续集成 / 部署 (CI/CD)：Jenkins 配置移动应用的自动化构建流程；版本管理：SemVer 语义化版本规范在移动 SDK 中的应用；测试框架：Appium、Espresso 的自动化测试用例编写。

小结

这个阶段最大的特色就是云文档的崛起，也诞生了许多云文档平台。编写技术文档可以允许同时多人编写，形成了交互式的编写方式。这些特点反映了移动互联网时代 "多端协同、体验优先" 的核心特征，创造 "核心文档 + 平台特化" 的分层策略。

技术文档从单一平台开发指南演变为包含原生开发、跨平台框架、性能优化、用户体验的综合知识体系，用 AsciiDoc 编写跨平台的核心逻辑，通过 ifdef 宏指令区分 iOS/Android 特有的 API 说明。在编写移动支付 SDK 文档时，我们引入 "场景化示例" 概念 —— 每个 API 说明都附带 iOS Swift/Android Kotlin / 小程序 JavaScript 三种实现代码，并用 CodePen 在线运行环境让开发者直接测试片段，这种 "可执行文档" 模式大幅降低了集成门槛。为后续小程序、Flutter 等跨端技术的发展奠定了基础。

云计算与 DevOps 时代（2016-2020）：基础设施即文档

这个阶段，容器化技术推动文档进入 "可执行化" 阶段。当 Kubernetes 成为云原生标配，Helm Chart 的 values.yaml 文件本身就成了最佳配置文档。其特点非常鲜明，以 "弹性伸缩" 和 "持续交付" 为核心，技术文档从传统本地化开发转向云原生体系：基础设施即代码 (IaC)：AWS CloudFormation、Terraform 等工具的普及；容器化部署：Docker、Kubernetes 成为标准部署方式；微服务架构深化：服务网格 (Service Mesh) 如 Istio 的应用；DevOps 文化渗透：开发、测试、运维的全流程协作需求。最为典型场景如基于 Kubernetes 的电商平台架构文档，需涵盖容器编排、服务发现、自动扩缩容等云原生特性的开发运维指南。这个阶段的技术文档特点：

图：云原生时代利用消息队列提供云服务的文档

1、云原生技术栈体系化文档

以云原生技术的特点逐步形成公有云API、Terraform配置、Kubernetes(也就是我们常说的K8S)、服务网格配置（Istio）、DevOps的流水线配置、监控配置测试等内容；

2、开发工具生态系说明

这是开发工具生态分为多种，主要分为：

集成开发环境 (IDE)：VS Code Remote Development：远程连接云服务器开发；IntelliJ IDEA Kubernetes 插件：YAML 文件智能提示；
容器开发工具：Docker Desktop：本地容器环境搭建；Minikube：本地 Kubernetes 集群部署
云开发平台：AWS Cloud9：浏览器内 IDE；Google Cloud Shell：云端命令行环境

3、部署工具说明

针对全流程自动化，文档包含：

版本控制：Git 分支管理策略（如 Git Flow）

容器镜像管理：Harbor 仓库权限配置与镜像扫描

基础设施自动化：Ansible 剧本编写规范

4、分布式系统设计文档

分布式设计主要强调，云原生原则：主要包含弹性设计、容错机制、分布式事务；多云/混合云适配指南：针对复杂云环境，文档包含：跨云资源编排：Terraform 多云配置；服务网格跨集群：Istio 多集群部署方案；数据跨云迁移：MongoDB Sharding 跨云配置。

5、性能链路检测

这块主要是针对性的优化方案如：容器性能调优、网络优化：service Mesch策略；成本优化：AWS Cost Explorer；还有配套的全链路检测监控的搭建：

日志收集：Fluentd+Elasticsearch+Kibana (EFK) 架构

指标监控：Prometheus+Grafana 配置

分布式追踪：Jaeger 全链路追踪集成

你会发现通过 GitOps 流程维护的README.MD，比专门编写的运维手册更具时效性 —— 每次文档更新都伴随 CI/CD 流水线验证，这种 "文档即代码" 的理念催生出 MkDocs、Docusaurus 等静态站点生成器，让文档具备与代码同等的版本控制能力。

小结

这个阶段技术文档从静态文档衍生到了动态协作。我们把基础设施可以生成文档，如代码化文档的概念：文档与基础设施配置同步维护；也有文档即代码：因为可以方便使用markdown+ci生成可执行文档；还有交互式文档：在web2.0时代也开始运用的如:Swagger UI wendang 。技术文档的生成也可以实现自动化：如从代码注释自动生成API文档，同时如果企业引进了飞书等工具也可以实现实时协作的文档编写方式。

AI 大模型纪元（2021 - 至今）：智能交互的革命

AI 大模型时代的大幕才刚刚拉开，技术文档领域的革新之路才迈出初始步伐。当下我们初步洞察到的智能生成趋势，诸如从代码和注释自动化产出多语言文档，以及多模态内容生成促使代码、图表、解释实现有机融合，这仅仅是这场技术变革的开篇。在交互层面，尽管已经出现交互式代码沙箱、智能问答系统等创新形式，但随着大模型对自然语言理解与生成能力的持续精进，未来技术文档有望实现与开发者更深度、更自然的交互，例如依据开发者的实时反馈，动态调整内容呈现方式与讲解深度。

从个性化角度而言，目前基于角色、技能水平的内容推荐与难度适配尚在发展初期，后续借助大模型对用户行为数据的深度挖掘与精准分析，将能够为每位开发者打造完全贴合其需求与习惯的专属文档体验。质量保障方面，虽然现有的 AI 验证手段可对文档正确性、知识一致性进行检查，但随着技术的演进，未来将构建起更为完善的质量保障体系，确保文档在快速更新的同时，始终维持高质量水准。

在生态协作领域，众包知识平台与跨语言协作当前仅是崭露头角，后续借助大模型的翻译、审核、智能推荐等能力，全球开发者将能更顺畅地参与到文档的共建与完善中，形成一个真正意义上的全球技术知识生态共同体。至于预测性文档与自主文档系统，当下仅是理论设想与初步探索，随着大模型认知能力的全方位提升，未来技术文档极有可能演变成一种能够自主学习新知识、主动感知开发者需求并实时更新完善自身的智能存在，彻底重塑技术知识的传播与应用模式。而这一系列充满无限可能的演进方向，正亟待后续的技术实践去逐步探索、细化并实现。

最后小结

二十五年技术变迁印证了一个真理：优秀文档的核心要素从未改变。从桌面时代 "用鼠标轨迹思考" 的用户视角，到 Web2.0 时期 "协作即创造" 的共享精神，再到云原生阶段 "测试即验证" 的工程思维，直至 AI 时代 "智能即进化" 的交互哲学，最终凝结成三条永恒法则：

形态适配法则要求文档载体必须与技术栈同构 —— 就像桌面时代的纸质手册匹配单机程序逻辑，云原生时代的 Markdown 文档契合 Git 工作流，AI 时代的智能文档自然要成为大模型的知识接口。这种同构性在我用 DOS 字符绘制流程图时已初现端倪，那时 ASCII 线条里藏着最早的 "形态适配" 意识。

双向追溯法则强调任何技术描述都应能锚定实现代码，任何代码变更都必须同步更新文档。记得调试 MFC 控件时，我在纸质手册空白处标注的每处 API 调用细节，恰是这种 "文档 - 代码" 原子级关联的早期实践，它构成了知识传承最坚实的基石。

持续进化法则让文档从静态产物蜕变为动态系统。当我在 Web1.0 时代用表格记录浏览器兼容性时，未曾想过如今的文档能接入 API 调用频次、错误日志等开发流程数据实现自动优化。这种进化基因，早在 DOS 手册被反复批注的纸页间就已埋下。