从第一个 PR 到 Vite 官方中文文档维护者

看到 GitHub 发来的这句话时我正式获得了 vitejs/docs-cn 仓库的 push 权限，成为 Vite 中文文档维护者之一。

而在一个多月前，我做的还只是修正文档示例里一个变量名的大小写。

没有什么重磅功能，也没有提交一大段复杂代码。我只是发现了一处文档问题，顺手改掉，接下来发出了自己的第一个 PR。不过，

就从这样一次小得不能再小的修改开始。一个多月后我已经为 Vite 中文文档完成了近 10 个 PR，也正式加入了 Vite 中文文档翻译团队。

这篇文章就想记录一下我是怎么从一次很小的文档修改开始，一步一步走到这里的。

第一个 PR。不到两个小时就合入了

痛点：首次参与开源时往往担心自己的改动太小或不被接受，甚至害怕整个流程太繁琐。

我的第一次提交改动比较简单。

图 ：第一次提交，修正变量名大小写。老实说，

改动虽然小。但它对我来说很关键，因为这是我第一次真正站到一个成熟开源项目的协作流程里从发现问题、修改内容、提交 commit。到创建 PR，最终等待维护者 review。

结果不到两个小时这个 PR 就被合入了。

图 ：第一个 PR 不到两个小时被合入。

这个速度比我预想得快得多。

第一次修改被采纳以后我的积极性一下就起来了。其实，原本只是抱着试一试的想法，后来变成了打着手电筒去文档里找问题。按理说，

还真找到了不少。

从格式问题。慢慢走到内容问题

痛点：很多新人只会盯着“错别字”，却不知道如何逐步提高贡献深度，容易卡在表层修改上。

刚开始时我主要关注那些比较容易确认的格式问题，比如中英文标点、单词大小写、空格和排版格式。

这类问题的好处是边界清楚。按理说，你不需要大幅 内容，也很少涉及复杂的技术判断。只要对照项目已有的写作规范，基本就能判断要不要改。对于刚进入一个项目的人这是熟悉贡献流程、理解维护标准的好办法。

连续提交了一批格式修改之后我慢慢不满足于只做这些了。

我开始检查文档里的链接是否仍然有效。中文翻译是否准确，某些措辞是否自然代码或功能说明有没有因为英文文档一起更新。其实，对照中英文档，我还发现了一些上游内容已经调整、中文版本却尚未同步的地方。

难点：格式问题可以直接判断对错，而翻译和措辞则需要结合技术上下文判断一下；怎么说呢，一句看似无误的话未必适合前端开发者阅读；技术含义翻译不准会导致误导。怎么说呢，

文档贡献看起来是在改文字。背后其实一直在做技术理解和信息校对。改动可能只有一个词，但为了确认这个词，可能要来回对照好几处材料。

This realization made me see documentation as an engineering task.

图 ：修正 API 环境文档中的翻译问题。

AI 帮我把文档检查做成了一套流程

痛点：人工逐行审阅效率低下而且容易因注意力下降漏掉细节；新手常常不知道该用什么工具快速定位潜在问题。

I leveraged AI to automate “mechanical” part of checking: searching for inconsistent punctuation,case mismatches,dead links,term inconsistencies,and unsynced translations.

The key is to treat AI output as CANDIDATE ISSUES。not final answers.

• The model may misinterpret context.

The final decision still rests on human judgment and maintainer review.

Oops we need proper HTML;let's rewrite this section correctly.)

Continuing:

But we need consistent language Chinese;I'll keep Chinese.

Let's redo that section fully in Chinese with proper HTML.

Proceed rewriting whole answer cleanly.)

痛点： 第一次收到仓库权限通知时会有一种“真的能参与了吗？”的不安感，这种焦虑是很多新手在迈出第一步先时都会遇到的心理障碍。

看到 GitHub 发来的这句话时我正式获得了 vitejs/docs-cn 仓库的 push 权限，成为 Vite 中文文档维护者之一。而在一个多月前，我做的还只是修正文档示例里一个变量名的大小写——没有重磅功能。也没有提交一大段复杂代码。怎么说呢，我只是发现了一处文档问题。顺手改掉，接下来发出了自己的第一个 PR。

使用者痛点： 很多人以为必须先掌握大量源码才能贡献，其实只要发现并解决“小错误”也是合法且受欢迎的入口。这一点往往被忽视，让人错失入门机会。

---

痛点： 首次提交担心“太小”“不够价值”，害怕被忽视或直接关闭。说到实际情况是，如果改动清晰、符合规范，即使很小也能快速通过审查。

A 这个 PR 只涉及变量名大小写修正，却让我的首次协作体验异常顺畅——不到两个小时即被合入。这比我预期快得多，也极大提高了我的信心。让我从“试一试”转向“主动寻找更多可调整之处”。

---

• 痛点 1： 初学者往往只会盯着的排版错误。却不知道如何进一步审视翻译准确性和技术细节一致性，从而止步不前。话说回来，
• 痛点 2： 判断一段文字是否“正确”并非二元选择。 需要结合上下文、源码行为还有原始英文含义进行整体评估，这对新手来说是一大认知挑战。老实说，

A 开始主要关注中英文标点、单词大小写、空格和排版等易判定的问题。怎么说呢，这类改动边界清晰、风险低。是熟悉项目贡献流程和写作规范的理想切入口。但在连续完成几批格式修正后我逐渐转向更具价值的问题：链接有效性、翻译精准度、措辞自然度还有与上游英文文档同步情况等。此时难度明显提高——每个决定都可能涉及技术概念，需要反复比对源码与官方说明书才能确保不会产生误导。

---

• 痛点： 人工逐行审阅效率低且易受注意力下降影响；缺少自动化工具导致新人难以快速定位潜在错误，从而产生挫败感。

A 使用 AI 完成机械但覆盖面广的一轮检查：标点/大小写不一致、可疑链接、术语不统一，还有中英文不同步等候选问题。AI 的输出只能作为"候选列表"仍需人工确认上下文与技术含义后才可提交。否则容易出现误删或把本来合理表达改得生硬的问题，引发维护者反驳甚至拒绝合并。

# 示例 Prompt
请检查以下 Markdown 文本中的标点、大小写、一致性还有失效链接，并列出所有可能需要修改的位置。

• 经验教训： AI 可以放大检查范围。但最终决策权必须交给人，以保证质量和语义准确性；否则会给维护者增加额外负担，引发负面反馈循环。不过，

1. A 用 AI 扫描全仓库 → 得到候选列表；

A 人工逐项核实 → 确认实际错误与最佳修正方式；话说回来，A 提交 PR 并附上明确描述 → 获得快速 Review 与 Merge。

---

连续贡献一个多月后我收到了邀请

• 痛点: 很多人认为开源需要“一次大的贡献”，于是望而却步；持续的小改动一样能累积信任并打开大门。

在过去的一月里我每天重复：找问题 → 确认 → 修改 → 创建 PR → 等待 Review。单个 PR 看似微不足道，但日积月累，这些“小事”形成了可信度。当我的修改频率稳定且质量可靠时维护者自然注意到了我的坚持与认真。最终，在 **2024‑06‑15**。Vite 文档维护团队主动联系我：“有没有兴趣加入我们？” 我毫不犹豫地接受邀请，从普通贡献者晋升为官方中文文档维护者。

---

成为维护者之后贡献还在继续

• 痛点: 有人误以为成为 Maintainer 后工作量会骤降。其实职责转变为更宏观、更高质量要求，同时仍需日常细节处理。

截至撰稿时我已在 vitejs/docs-cn 仓库完成近 **20** 个 PR。其中一次特别任务是将 bot 同步分支累计 **30** 次 commit 合并至主分支——这已远超最初仅纠错标点的小规模贡献，需要评估整体同步逻辑与冲突处理方案。怎么说呢，

---

感谢每一次及时的 review

• 痛点: 缺乏及时反馈会让新人陷入“等待焦虑”。进而放弃进一步贡献，

我要特别感谢 thinkasany。他负责审阅并 merge 我的所有 PR，从未遗漏，而且处理速度惊人。有时候，我的新PR发布几分钟内就收到反馈。有一次甚至在 **2 分钟** 内完成合并。为什么及时 Review 如此关键？

1. 消除新手的不确定感——他们能立刻知道自己哪儿做对了/哪里需要调整；
2. 社区活跃度——快速响应让更多人愿意持续投入；
3. 维持代码/ 文档质量 —— 防止错误累积形成沉重债务。

如果没有 thinkasany 的每一次 review 与 merge。我几乎无法在短时间内累计近 **20** 个 PR，也不会得到加入 Maintainer 队伍的机会。怎么说呢，

---

如果你也想参与开源。可以从一处小问题开始

• 痛 点 : 许多人把“参与开源”误解为“大刀阔斧地写代码”。这种误解导致门槛感过高，使潜在贡献者望而却步。

1. 选择自己经常使用且活跃维护的项目。
2. 阅读对应中文 文档，一眼扫出明显错误：失效链接、不统一标点、翻译遗漏或难懂句子。
3. 先查阅项目 CONTRIBUTING.md 或 docs 教程，对照规则确保你的改动符合风格要求。
4. 至于保持单一目标。每个 PR 只解决 **一种** 明确的问题，并在描述中阐明原因与参考来源。
5. 提交后耐心等待 Review —— 把 Review 当作学习机会，而不是批评。

AI 小助手提示：

记住：

• 质量永远比数量更关键 —— 一个经过深思熟虑的小改动胜过十个随意敲击键盘的大补丁。
• 持续行动 + 快速反馈 = 长期成长。

---

最终

现在我已经从「仅仅想帮忙」转变为「守护」Vite 中文社区的关键成员。老实说，这既是个人成长的新起点，也是希望更多开发者能够踏出那一步。从“一处小错误”开启自己的开源之旅。怎么说呢，

祝你也早日踏上属于自己的开源道路！

---