从第一个 PR 到 Vite 官方中文文档维护者
You now have push access to the vitejs/docs-cn repository.
看到 GitHub 发来的这句话时，我正式获得了 vitejs/docs-cn 仓库的 push 权限，成为 Vite 中文文档维护者之一。
而在一个多月前，我做的还只是修正文档示例里一个变量名的大小写。
没有什么重磅功能，也没有提交一大段复杂代码。我只是发现了一处文档问题，顺手改掉，然后发出了自己的第一个 PR。
就从这样一次小得不能再小的修改开始，一个多月后，我已经为 Vite 中文文档完成了近 40 个 PR，也正式加入了 Vite 中文文档翻译团队。
这篇文章就想记录一下，我是怎么从一次很小的文档修改开始，一步一步走到这里的。
第一个 PR，不到两个小时就合入了
我的 第一次提交 改动非常简单。
图 1：第一次提交，修正变量名大小写。
改动虽然小，但它对我来说很重要。因为这是我第一次真正站到一个成熟开源项目的协作流程里，从发现问题、修改内容、提交 commit，到创建 PR，最后等待维护者 review。
结果不到两个小时，这个 PR 就被合入了。
图 2：第一个 PR 不到两个小时被合入。
这个速度比我预想得快得多。
第一次修改被采纳以后，我的积极性一下就起来了。原本只是抱着试一试的想法，后来变成了打着手电筒去文档里找问题。
还真找到了不少。
从格式问题，慢慢走到内容问题
刚开始时，我主要关注那些比较容易确认的格式问题，比如中英文标点、单词大小写、空格和排版格式。
这类问题的好处是边界清楚。你不需要大幅改写内容，也很少涉及复杂的技术判断，只要对照项目已有的写作规范，基本就能判断要不要改。对于刚进入一个项目的人来说，这是熟悉贡献流程、理解维护标准的好办法。
不过，连续提交了一批格式修改之后，我慢慢不满足于只做这些了。
我开始检查文档里的链接是否仍然有效，中文翻译是否准确，某些措辞是否自然，代码或功能说明有没有随着英文文档一起更新。对照中英文档，我还发现了一些上游内容已经调整、中文版本却尚未同步的地方。
这里的难度就明显提高了。
格式问题往往可以直接判断对错，翻译和措辞却不一样。一个句子字面上没有错，不代表它适合前端开发者阅读；英文原文中的技术含义翻译过来了，也不代表中文表达足够准确、顺畅。有时还要结合前后段落、具体功能，甚至源码行为来确认。
所以，文档贡献看起来是在改文字，背后其实一直在做技术理解和信息校对。改动可能只有一个词，但为了确认这个词，可能要来回对照好几处材料。
这件事越做，我越能理解为什么文档也是工程的一部分。
图 3：修正 API 环境文档中的翻译问题。
AI 帮我把文档检查做成了一套流程
我能在一个多月里持续找到这么多问题，AI 确实帮了很大的忙。
如果完全靠人工逐行阅读，当然也能发现问题，但速度会慢很多，而且很容易因为注意力下降漏掉细节。AI 很适合先做一轮机械但覆盖面广的检查，比如寻找标点和大小写不一致、可疑链接、前后术语不统一，或者对照中英文档找出可能没有同步的内容。
但这里有一个容易被忽略的前提，AI 找出来的是「候选问题」，不是可以直接提交的答案。
它可能误解上下文，也可能把原本合理的表达改得更生硬。涉及技术含义时，表面上更通顺的句子甚至可能偏离原文。最终哪些问题成立、应该怎样修改，仍然需要人来判断，也需要通过维护者的 review。
我的做法是让 AI 负责扩大检查范围，我自己负责确认上下文和修改质量。这样既能利用 AI 的效率，又不会把未经验证的结果直接丢给项目维护者。
后来，我把这套寻找文档问题的方法整理成了一个 docs-proofread Skill。它不只是一个提示词，更像是我在不断贡献过程中沉淀下来的一份检查清单，把原本零散的经验固定成可以重复执行的流程。
图 4：docs-proofread Skill 一次修复 26 组文档问题。
这也是这段经历里一个挺有意思的循环。我先用 AI 帮助自己参与开源，又把参与开源时积累的方法做成工具，继续帮助自己和其他人检查文档。
工具不是替代判断，而是把精力留给更需要判断的地方。
连续贡献一个多月后，我收到了邀请
就这样，我每天重复着找问题、确认问题、修改、提交和创建 PR 的过程。
单看其中任何一个 PR，改动可能都不算大。但当这件事连续做上一个多月，小修改也会逐渐积累起来。
我以前会觉得，参与开源需要先准备得足够充分，最好已经熟悉源码，最好一出手就是有分量的贡献。
但这一个多月的经历让我发现，很多信任并不是靠一次大提交建立起来的，而是在一次次小而可靠的修改里慢慢积累的。
你发现的问题是真的，给出的修改是经过确认的，收到 review 后愿意继续调整，下一次提交依然保持认真。时间久了，维护者自然会知道，你不是来仓库里刷一下存在感，而是真的愿意把这件事做好。
就这样到了 7 月 15 日，文档维护者问我，是否有兴趣加入文档维护。
图 5：收到加入文档维护的邀请。
我可太愿意了!!
在维护者的引荐下，我收到了加入 Vite 中文文档翻译团队的邀请，正式成为官方文档维护者之一。
图 6：正式加入 Vite 中文文档翻译团队。
从贡献者变成维护者，身份上的变化只是一行很短的信息，但对我来说，它更像是一份来自社区的信任。
以前我主要考虑的是，自己的这个修改对不对、能不能被合入。成为维护者以后，还要开始站在项目整体的角度思考，文档风格是否一致，翻译是否忠于原意，新的改动会不会和已有内容冲突，其他贡献者的 PR 应该怎样 review。
成为维护者不是这段经历的终点，而是开始承担更多责任的起点。
我自己也还在学习，Vite 文档的内容很多，背后的技术细节也很深，真正要做好维护，靠的不会只是发现几个错别字，而是持续理解项目、熟悉规范，并且认真对待每一次协作。
成为维护者之后，贡献还在继续
加入翻译团队并不代表这段贡献经历已经结束。身份发生了变化，但每天要做的事情仍然是发现问题、确认问题，然后认真完成修改。
截至写这篇文章时，我已经在 Vite 中文文档仓库 完成了近 40 个 PR。其中还有一次比较特别的工作，我将 bot 同步分支累计的 41 个 commit 合入了主分支。
这次修改和最初调整标点相比，已经不是同一个量级了。它需要关注的内容更多，也让我第一次更具体地感受到，文档同步不是简单地把英文逐句翻译成中文，而是要确认一批变化能不能完整、准确地进入现有文档。
图 7：我在 Vite 中文文档仓库的部分 PR 记录。
从第一次修改标点，到后来处理一批同步内容，我能看到自己的贡献范围在一点点扩大。但比数量更重要的是，这件事直到现在仍然在继续。
特别感谢每一次及时的 review
写到这里，我很想特别感谢 thinkasany。
我为 Vite 中文文档提交的贡献，都是他完成 review 和 merge，没有一次落下，而且处理速度经常快得惊人。
快到啥程度？
有时 PR 刚发出去没多久，反馈就已经来了。前面提到第一个 PR 不到两个小时被合入，后面我还遇到过几分钟内就处理完成的情况，而且不是偶然一次。
图 8：一次在2分钟内完成的 PR 合入。
这种及时不只是让一个 PR 更快变成绿色。
对刚开始参与开源的人来说，等待反馈时多少会有些忐忑。自己的修改是不是太小了，会不会不符合项目要求，描述有没有写清楚？维护者快速而明确的反馈，会让贡献者知道下一步该怎么做，也会让人更愿意继续参与。
如果没有他的每一次 review 和 merge，我很难在这么短的时间里积累近 40 个 PR；如果没有他的引荐，我也不会在 7 月 15 日之后成为 Vite 中文文档维护者。
开源项目是由代码和文档组成的，但一个社区能够持续运转，最终靠的还是人与人之间的回应和信任。
如果你也想参与开源，可以从一处小问题开始
成为 Vite 官方中文文档维护者当然让我很开心，但我更想记录的，是这件事从哪里开始。
它不是从一个宏大的计划开始的，也不是等我掌握了所有知识之后才开始的。它就是从一处很小的文档问题开始。
很多人提到参与开源，第一反应往往是给项目修 Bug、加功能，或者读懂一大堆源码后再寻找贡献机会。这些当然都是参与开源的方式，但对刚开始的人来说，门槛确实不低。你需要熟悉项目结构，搭好本地环境，理解代码上下文，还得确认自己的修改不会影响其他功能。很多时候，光是把项目跑起来，就足以消耗掉刚冒出来的那点积极性。
所以，如果你也想参与开源，却一直不知道该怎么迈出第一步，我很推荐从文档开始。
文档同样是项目的一部分，也真实影响着使用者的体验，但你通常不需要先读懂整个代码库。一个标点、一处表达不准确的翻译、一个已经失效的链接，都是明确而具体的问题。发现它，确认它，修正它，再把修改提交出去，一次完整的开源协作就跑通了。
你可以先找一个自己平时就在使用的项目，读一遍它的中文文档，看看有没有失效链接、格式不一致、翻译遗漏，或者让你反复读了几遍仍然不容易理解的句子。
选项目时，我还建议关注一下项目和文档是否仍在活跃维护。我当时选择 Vite 中文文档，一方面是因为 Vite 本身足够活跃，作为前端开发者，它几乎是绕不开的工具，维护好中文内容能真正帮助到使用它的人；另一方面，Vite 中文文档的维护也很及时，我提交 PR 后能够较快得到 review 和反馈。
对第一次参与开源的人来说，这种反馈很重要。它能让你尽快知道自己的修改是否合理，也能帮助你熟悉项目的协作方式。第一次贡献最需要的，未必是一上来就做多大的改动，而是先跑通一次完整的正反馈。
找到问题后，先对照贡献指南和英文原文确认一下。改动尽量保持聚焦，一个 PR 解决一个明确问题，把修改原因写清楚。收到 review 后，也别把修改意见当成否定，那恰恰是理解项目规范最快的方式。
AI 也可以成为很好的助手，你可以让它帮助检查和比较，但提交前一定要自己复核。开源项目需要的不是更多看起来正确的修改，而是更多经过认真确认、能够让人放心合入的贡献。
门槛确实比以前低了，但质量标准并没有降低。
这反而是一件好事。AI 让我们更容易迈出第一步，而真正让一个人留在社区里的，仍然是耐心、判断和持续行动。
最后
从第一个不到两个小时就被合入的 PR，到一个多月后的近 40 个 PR，再到收到维护邀请，这条路比我最初想象得快，也比我想象得自然。
没有什么突然发生的奇迹，就是每天多找一个问题，多确认一处内容，多提交一次修改。回头看的时候，那些很小的动作已经连成了一条完整的路。
现在，我从 Vite 中文文档的贡献者，变成了需要一起守好这份文档的维护者。
这只是一个新的开始。
也希望以后会有更多人，从自己发现的那一处小问题出发，真正走进开源社区。