如果您是我的好友，可能已经听我说过这些。但我还是想把它写下来，让任何想向我管理的项目提交贡献的人都能清楚了解。

我并不反对 AI。恰恰相反——我满怀热情地关注着它的发展，并且相信 LLM 是文本和代码类工作中最有用的工具之一。但在我看来，使用 AI 有好的方式，也有有问题的方式——尤其是在开源环境下。

#沟通必须源于你，而非模型

我的第一个、也是最为强调的原则：不要让 LLM 替您说话。当您发送邮件、在 issue 中写评论、或在 pull request 中解释某件事时——我想读到的是您自己的声音，而不是经过模型润色后的输出。

我不在乎语法是否完美。我不在乎句子是否卡顿、是否有拼写错误。我在乎的是，那段文字背后是否有一个真实的人在真正思考和努力沟通。对我而言，开源贡献的核心是人与人之间的联系——而不是谁能写出最精美的文字。

#理解您所贡献的内容

使用 LLM 辅助编写或审查代码是正常且没有问题的。但在您向开源项目提交任何内容之前——无论是什么——您必须真正理解您提交的东西。

这不是形式主义。如果您贡献的代码中存在 bug，当有人问起时，您必须能够解释清楚。如果需要讨论某个设计决策，您必须有自己的、您自己确信的观点，而不仅仅是模型推荐的方案。如果您无法解释自己的代码，那么这份贡献带来的更多是负担，而不是帮助。

#氛围编程无法让任何人成长

我非常支持使用 LLM 来加速工作。但把 AI 当作辅助工具，与把项目全部控制权交给模型，这两者之间有巨大的区别。后者就是常说的“氛围编程”——坐着、输入提示词、接受输出、然后继续。

问题不在于产出结果一定很差。问题在于在这个过程中，您自身发生了什么。如果您从不参与技术决策，从不与那些在模型训练数据中找不到答案的问题搏斗，您就不会成长。而一个依赖不成长的贡献者的开源项目，就是一个停滞的项目。

#透明关乎诚信

我坚持的第四个原则是：对 AI 的使用保持开放。如果您使用 LLM 来辅助研究、撰写草稿或生成部分代码——请说出来。这不是因为这样做很丢人，而是因为这是诚实的。

在许多专业语境下，说明使用了 AI 是一种诚信的体现。这有助于阅读或审查您工作的人更好地理解上下文。而在一个建立在信任基础之上的开源社区中，这种诚实具有比看上去更大的价值。

---

在这四个原则中，我一直想知道哪一点在别人看来最重要，或者是否还有其他原则应该被列入清单。如果您对此有任何想法，欢迎在issue 页面上与我讨论。

第一条，也是我最强调的一条：不要让 LLM 替你说话。当你发邮件、在 issue 里写评论、或者在 pull request 里解释某件事时，我想看到的是你的声音，不是被模型润色过的输出。

我不在意语法是否完美，不在意句子是否流畅，不在意有没有错别字。我在意的是这段文字背后有没有一个真正在思考、在努力表达什么的人。开源贡献对我来说是人与人之间的事——不是谁能产出最精致的文本的比赛。

#搞清楚你在贡献什么

用 LLM 帮助写或审查代码是正常的，没有问题。但在你把任何东西提交到开源项目之前，你必须真正理解你提交的内容。

这不是形式上的要求。如果你贡献的代码里有 bug，有人来问，你得能解释清楚。如果有个设计决策需要讨论，你得有自己真正认同的立场，不只是模型推荐的那个。如果你解释不了自己写的代码，这个贡献带来的负担可能比它解决的问题还多。

#Vibe Coding 不会让任何人成长

我非常支持用 LLM 提高工作效率。但把 AI 作为辅助工具，和把项目的全部决策权交给模型，是完全不同的两件事。后者就是人们常说的 vibe coding——坐下来，打个提示词，接受输出，继续往下走。

问题不在于这样产出的东西质量一定很差。问题在于这个过程里你经历了什么。如果你从来不参与技术决策，从来不去面对那些训练数据里找不到答案的问题，你就没有在成长。一个依赖不成长的贡献者的开源项目，是在慢慢停滞的项目。

#透明是诚信的一部分

第四条原则：对 AI 使用情况诚实。如果你用 LLM 帮助做调研、写草稿或生成代码的一部分，说出来。不是因为这件事可耻，而是因为这是诚实的。

在很多专业场合，主动说明使用了 AI 是一种诚信的体现。它帮助阅读或审查你工作的人更好地理解背景。在建立在信任之上的开源社区里，这种诚实的分量往往比表面上看起来要重。

---

在这四条里，我一直很好奇别人觉得哪条最重要——或者有没有什么应该在列表里但还没有的。如果你有想法，欢迎在 issues 页面 讨论。