过去的问题本来就是同步问题
在“Docs-as-Code”这个名字出现之前，文档团队已经在处理多个源文件、共享片段、版本手册，以及“哪一份才是最新”的问题。工具不同，协调问题却非常熟悉。
真正变化的是，文档现在可以更直接地进入软件交付体系。
文本源更容易自动化
纯文本格式、Git 和静态生成器让 diff、branch 和自动 build 变得普遍。文档变更可以直接触发 link check、style lint、preview 和 deployment。
这并不说明所有旧流程都错误，只是自动化和协作的成本变了。
Web 改变了阅读单元
印刷手册鼓励线性阅读。Web 文档则大量通过搜索、deep link 和支持答案进入。单个页面需要更多自足上下文，导航和 cross-link 也成为产品体验的一部分。
复用更容易，也更危险
Component、include 和 structured content 可以减少重复，也可能产生在一个上下文正确、另一个上下文困惑的 fragment。工具无法代替编辑判断。
下一个工具也不会消除责任
AI 可以以新的规模生成内容，因此来源质量、review、provenance 和信息架构会更重要。
技术持续改变 workflow，但对准确、可用信息负责这件事没有消失。
实践示例
阅读《文档工具的过去与现在：真正改变了什么》时分成两栏：哪些属于当时的技术条件，哪些属于长期存在的文档问题。用今天的工具重做一个小型历史流程，例如发布说明、术语表或离线手册，并标记哪些决策虽然媒介改变了却仍然相同。
寻找长期模式：
- 读者怎样找到信息；
- 更正怎样分发；
- 发布后谁负责准确性；
- 旧媒介的哪些限制反而带来了有用的纪律。
历史材料的价值，在于帮助我们更清楚地看见今天的问题。目标不是恢复旧工具，而是把持久的编辑原则与特定时代的媒介分开。
快速编辑检查
- 过去的问题本来就是同步问题. 在“Docs-as-Code”这个名字出现之前，文档团队已经在处理多个源文件、共享片段、版本手册，以及“哪一份才是最新”的问题。
- 文本源更容易自动化. 纯文本格式、Git 和静态生成器让 diff、branch 和自动 build 变得普遍。
- Web 改变了阅读单元. 印刷手册鼓励线性阅读。Web 文档则大量通过搜索、deep link 和支持答案进入。
- 复用更容易，也更危险. Component、include 和 structured content 可以减少重复，也可能产生在一个上下文正确、另一个上下文困惑的 fragment。
