从Git到AI：我的技术写作工具进化史

一个版本管理员的“暴论”

十年前，我坚信技术文档的终极形态是纯文本——直到我在一个深夜重构了200个Markdown文件，却发现团队没人能看懂我的“模块化”设计。那一刻我明白：工具的本质不是效率，而是协作共识。今天，我想用一条时间线，聊聊工具如何定义我们思考问题的方式。

2015年：GitHub Pages + Jekyll 的“静态之美”

那是个“做博客就像搭积木”的年代。我用Jekyll生成了第一个技术博客，每次`git push`后等3分钟看到页面更新，会有种“控制感”。但痛点很快暴露：写一篇带代码块的教程，需要手动处理语法高亮和响应式表格。当时解决思路是“用约定代替配置”，结果团队内部诞生了8种不同的代码缩进风格——直到一位前辈丢来一个冷知识：“Git blame能查出每个空格的作者”。这种“查户口”式的协作，反而倒逼我们统一了规范。

2018年：从Gradle到Asciidoc的”迁移噩梦”

这是一个典型的“为了性能牺牲易用性”的案例。当时项目文档从Gradle迁移到Maven时，我们尝试用Asciidoc替代Markdown。结果呢？一个跨页面引用的表格，需要学三种语法才能对齐。最离谱的是，某个历史版本里藏着一段“幽灵锚点”——除非用`asciidoctor --trace`，否则永远找不到链接失效的原因。这次经历让我意识到：“可读性优先”不是理念，而是无数个深夜后得出的血泪教训。

2023年：AI工具的“反常识”体验

转折发生在Cursor出现的第三个月。当时我正写一篇关于Claude Code自动生成API文档的评测，却意外发现：AI不仅能补全函数说明，甚至主动检测出我设计模式中的范式冲突——这打破了“工具只是辅助”的认知。更反常识的案例来自Trae：我在一个Go项目中用它的“重构建议”功能，结果它把三个模块的依赖关系重组成了一张有向无环图——而人类同事花了三天才确认这图是对的。这不是效率提升，这是认知维度的跃迁。

2024年：Opus、GLM与“协作的终点”

如今，我的工具链里混用着Opus写论证框架、GLM处理中式排比，甚至用文心一言的“文档审查”功能检查技术歧义。但最让我震撼的是Claude Code的“自我修复”机制：当它发现生成的YAML配置存在潜在循环依赖时，会自动创建一条`fix-ci.yml`的分支并提交PR——整个过程不到40秒。这让我开始认真思考一个问题：当工具能主动发现并修复自身缺陷，我们还需要“文档规范”吗？

结语：工具终将消失，但故事不会

回望这条时间线，每一次工具更迭都伴随着“把人类从重复劳动中解放”的叙事。但真正让我兴奋的，是那些工具带来的意外视角：Git blame教会我代码诗人的署名，AI补全让我重新审视设计模式，而Claude Code的分支实践更像一面镜子，照出我们如何被工具定义又反过来定义工具。技术分享的意义，或许不在于传递最佳实践，而在于展示那些“工具未曾承诺但真正发生”的瞬间。