返回列表
🧠 阿头学 · 💬 讨论题

开源的本质不是代码贡献，是修改的自由——Kimi Code CLI 的克制哲学

编码代理时代，代码人力不再稀缺，开源的价值回归本质：不是"帮我写代码"，而是"给你改代码的自由"。

2026-01-31 原文链接 ↗
阅读简报
双语对照
完整翻译
原文
讨论归档

核心观点

  • 代码贡献从来不是开源最有价值的部分 在 AI 之前就是这样——没有社区信任和维护承诺的 PR 是负担不是帮助。编码代理只是让更多人能创建 PR，但没改变这个底层逻辑。
  • 编码代理让"写代码的人力"永远不再是瓶颈 这意味着开源项目的稀缺资源从"贡献者"转移到了"维护者的判断力和审美"。分拣 PR 的速度已经比维护者自己用 Agent 写还慢了。
  • 内核思维 vs 超级应用思维 Kimi CLI 刻意保持极简，不在终端里造超级应用（对标 Claude Code）。把 TUI 体验交给专家（Toad/Textual），自己聚焦 Web 界面和 VSCode 插件。这是产品审美上的选择。
  • "可改造性"是刻意的设计目标 不只是允许 fork，而是在架构上为 fork 做准备，让分叉尽可能低摩擦。这比"欢迎贡献"更诚实，也更实用。
  • 社区重于代码（Community Over Code） GitHub 越来越是"开放讨论"的地方，而不是"开放贡献"的地方。功能 PR 会被慢接收，但 bug 报告和想法讨论始终欢迎。

跟我们的关联

  • Neta 的开源/社区策略：如果 Neta 未来考虑开源任何工具或 SDK，"内核而非超级应用"的思路值得参考。意味着要想清楚开源的边界——是给社区改造的自由，还是要社区帮你写功能？两者的架构设计和社区运营完全不同。
  • ATou 的 AI 工具链选择：Kimi Code CLI 定位为可改造的内核，对比 Claude Code 的超级应用路线。接下来可以关注 Kimi CLI 的 Web 界面和 VSCode 插件发布，评估是否值得纳入工具链。

讨论引子

  • 编码代理时代，开源项目的"贡献"形态会怎么变？如果代码不再稀缺，社区的核心价值是什么？
  • Neta 如果要开源某个组件，应该走"内核+可改造"路线还是"超级应用+欢迎贡献"路线？

关于开源软件与 Kimi Code CLI 的思考

@istdrc 和我在正式开启职业生涯之前就一直在做开源项目。我们从贡献者与维护者两端都深刻理解开源的运行机制。我们知道它带来的喜悦、挫败与负担。

在编码代理（coding agents）的时代，有一种变化愈发明显，正如 @GergelyOrosz 所说：

事实上，这并不新鲜。在 AI 之前，真正的开源项目就已经是这样运作的。代码贡献从来不是最有价值的部分。除非你深度参与社区讨论、证明自己的能力并赢得信任，否则你的 PR 很容易被忽视——尤其是大功能。关键原因是：代码需要维护。除非你能证明你愿意维护自己的代码、关心整个项目与社区，或能展示你的 PR 易于维护并且对所有人（用户与维护者）都有益，否则你的 PR 往往更像负担，而不是帮助。

编码代理让更多人具备了创建 PR 的能力，因此新人可能会惊讶地发现：开源其实并不是那样运作的。

在编码代理出现之前，社区有时会形成一致的路线图，但缺少落地的人力。在这种情况下，维护者很乐意接纳新人一起建设——这些新人也可能因此对成为长期贡献者，甚至维护者本身产生兴趣。

但现在，有了编码代理，写代码的人力将永远不会再成为问题。事实上，对 PR 进行分拣与分流的速度，已经比维护者与自己的编码代理协作还慢了。

这意味着开源已死吗？完全不是。那我们为什么还要把 kimi-cli 开源出来？

修改的自由

以 MIT License 为例，我认为它抓住了开源精神的核心：

特此免费授予任何获得本软件及相关文档文件（下称“软件”）副本的人，在不受限制的情况下处理该软件的权利，包括但不限于使用、复制、修改、合并、出版、分发、再许可和/或销售该软件副本的权利，并允许向其提供该软件的人如此行事，...

最重要的是，我们希望赋予每个人按自身需求修改软件的自由。

事实上，从 kimi-cli 的第一天起，我们就一直在思考这件事。我们希望它是一块坚实的基座——一个可向上构建的内核。我们希望人们能够轻松地在 kimi-cli 的内核之上继续构建，同时也打磨出优雅而稳固的抽象，让源码更易于动手改造。

这种对可改造性的强调，呼应了开源在自由软件运动早期的起源——那时甚至还没有 GitHub。

我们完全拥抱这种自由。即使我们的愿景出现分歧，或者我们的路线图与你的需求并不一致，你仍然拥有 fork 并修改的完全自主权。我们不只是允许这种行为——我们也会在架构上为此做准备。让 kimi-cli 易于改造，是一个刻意的设计目标，确保分叉与分歧尽可能低摩擦。

内核，而非超级应用

不过，我们也没那么严格。有些项目对外部贡献的立场更强硬。最著名的例子大概是 SQLite：它是开源的，但明确不开放贡献：

开源（Open-Source），但不开放贡献（not Open-Contribution）

SQLite 是开源的，这意味着你可以不受限制地复制任意多份，并对这些副本做任何你想做的事。但 SQLite 并不开放贡献。为了让 SQLite 保持在公有领域（public domain），并确保代码不被专有或受许可内容“污染”，该项目不会接受未提交宣誓书、将其贡献献入公有领域的人所提交的补丁。

https://sqlite.org/copyright.html

我们最大的担忧，是 kimi-cli 失去其简洁性，变成一头臃肿的怪兽。

有人批评说，与 Claude Code 相比，TUI 体验很糟糕。这是刻意为之。我不觉得它“很糟”——只是极简，并且足够好用。

我们刻意不想像 Claude Code 那样在终端里打造一个超级应用（它确实是一款很棒、值得尊重的产品）。相反，我们会把精力聚焦在构建 kimi web（Kimi Code CLI Web Interface🥝）以及 Kimi Code 的 VSCode 插件上。

这也是我们把 @willmcgugan 的 Toad（因 Rich 与 Textual 而广为人知）集成为 kimi term 的原因——TUI 的卓越体验交给专家来做。

我们认同 “The Apache Way”——社区重于代码（Community Over Code）。

我们欢迎什么

对我们来说，GitHub 将越来越成为一个用于“开放讨论”的地方。Bug 报告对我们非常重要，修复 bug 的 PR 仍然欢迎。

（当然，有些 bugfix 并不像表面看起来那么显而易见，可能影响整体系统质量——因此我们对某些修复的接受速度可能会比较慢。）

然而，新功能 PR 的运作方式会很不一样。我们欢迎“功能请求”和“想法讨论”，但我们很可能会较慢地接收这类 PR。我们需要审慎评估每一次变更，并按照我们的路线图推动项目向前，维护内核的稳定性与一致性，以确保长期可持续。话虽如此，你可以把 Pull Requests 和 KLIPs（Kimi CLI Improvement Proposals，Kimi CLI 改进提案）作为社区里讨论想法的载体。如果我们看到其价值，或认识到真实的社区需求，你的提案可能会促使我们调整路线图。当然，对于需要立即关注的真实痛点，我们会优先处理。而为了让项目契合你的具体需求，我们也鼓励你在其之上继续构建——或者 fork 它——打造你自己的“个人软件”。也欢迎把你构建的内容分享给我们。

这些原则与实践未必适用于所有项目。“Move fast and fail fast” 的 OSS 也可以以自己的方式成功。但那不是我们希望 Kimi Code 成为的那类 OSS。我们追求的是更克制、更可持续——并最终对那些选择在其之上构建的人更有用。

链接: http://x.com/i/article/2017139966565085184

相关笔记

@istdrc and I have been working on open source projects since even before we began our careers. We deeply understand the dynamics of open source—both from the contributor's perspective and the maintainer's. We know the joy, the frustration, and the burden it brings.

@istdrc 和我在正式开启职业生涯之前就一直在做开源项目。我们从贡献者与维护者两端都深刻理解开源的运行机制。我们知道它带来的喜悦、挫败与负担。

In the era of coding agents, one change is becoming increasingly apparent, as stated by @GergelyOrosz:

在编码代理（coding agents）的时代，有一种变化愈发明显，正如 @GergelyOrosz 所说：

Actually, this is nothing new. Before AI, real open source projects already worked like this. Code contribution was never the most valuable part. Unless you were deeply involved in community discussions, proved your capability, and earned trust, your PR could easily be ignored—especially for large features. The key reason is that code needs maintenance. Unless you could prove you were willing to maintain your code, cared about the whole project and the community, or demonstrated that your PR was easy to maintain and beneficial to everyone (both users and maintainers), your PRs were often more of a burden than a help.

事实上，这并不新鲜。在 AI 之前，真正的开源项目就已经是这样运作的。代码贡献从来不是最有价值的部分。除非你深度参与社区讨论、证明自己的能力并赢得信任，否则你的 PR 很容易被忽视——尤其是大功能。关键原因是：代码需要维护。除非你能证明你愿意维护自己的代码、关心整个项目与社区，或能展示你的 PR 易于维护并且对所有人（用户与维护者）都有益，否则你的 PR 往往更像负担，而不是帮助。

Coding agents now give more people the ability to create PRs, so newcomers may be surprised to find that open source doesn't actually work that way.

编码代理让更多人具备了创建 PR 的能力，因此新人可能会惊讶地发现：开源其实并不是那样运作的。

Before the era of coding agents, there were cases where the community had an aligned roadmap but lacked the manpower to implement it. In such cases, maintainers were happy to accept newcomers to build together—newcomers who might develop an interest in becoming long-term contributors or even maintainers themselves.

在编码代理出现之前，社区有时会形成一致的路线图，但缺少落地的人力。在这种情况下，维护者很乐意接纳新人一起建设——这些新人也可能因此对成为长期贡献者，甚至维护者本身产生兴趣。

But now, with coding agents, the manpower for coding will never be a problem again. In fact, triaging PRs has become slower than maintainers collaborating with their own coding agents.

但现在，有了编码代理，写代码的人力将永远不会再成为问题。事实上，对 PR 进行分拣与分流的速度，已经比维护者与自己的编码代理协作还慢了。

Does that mean open source is dead? Not at all. And why are we still open sourcing kimi-cli?

这意味着开源已死吗？完全不是。那我们为什么还要把 kimi-cli 开源出来？

The Freedom to Modify

修改的自由

Consider the MIT License, which I believe captures the core spirit of open source:

以 MIT License 为例，我认为它抓住了开源精神的核心：

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, ...

特此免费授予任何获得本软件及相关文档文件（下称“软件”）副本的人，在不受限制的情况下处理该软件的权利，包括但不限于使用、复制、修改、合并、出版、分发、再许可和/或销售该软件副本的权利，并允许向其提供该软件的人如此行事，...

Most importantly, we want to grant everyone the freedom to modify the software to fit their own needs.

最重要的是，我们希望赋予每个人按自身需求修改软件的自由。

We actually thought about this from day one of kimi-cli. We want it to be a solid foundation—a kernel for building upwards. We want to make it easy for people to build on top of kimi-cli's kernel, while also crafting elegant and solid abstractions that make the source code easy to hack.

事实上，从 kimi-cli 的第一天起，我们就一直在思考这件事。我们希望它是一块坚实的基座——一个可向上构建的内核。我们希望人们能够轻松地在 kimi-cli 的内核之上继续构建，同时也打磨出优雅而稳固的抽象，让源码更易于动手改造。

This emphasis on hackability echoes the origins of open source in the early days of the Free Software Movement—before GitHub even existed.

这种对可改造性的强调，呼应了开源在自由软件运动早期的起源——那时甚至还没有 GitHub。

We embrace this freedom fully. Even when our visions diverge or our roadmap doesn't align with your needs, you retain complete autonomy to fork and modify. We don't just permit this—we architect for it. Making kimi-cli easy to hack is a deliberate design goal, ensuring that divergence is as frictionless as possible.

我们完全拥抱这种自由。即使我们的愿景出现分歧，或者我们的路线图与你的需求并不一致，你仍然拥有 fork 并修改的完全自主权。我们不只是允许这种行为——我们也会在架构上为此做准备。让 kimi-cli 易于改造，是一个刻意的设计目标，确保分叉与分歧尽可能低摩擦。

Kernel, Not Super App

内核，而非超级应用

That said, we are not that strict. Some projects take an even harder line on external contributions. The most famous example is probably SQLite, which is open-source but explicitly not open-contribution:

不过，我们也没那么严格。有些项目对外部贡献的立场更强硬。最著名的例子大概是 SQLite：它是开源的，但明确不开放贡献：

Open-Source, not Open-Contribution

开源（Open-Source），但不开放贡献（not Open-Contribution）

SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.

SQLite 是开源的，这意味着你可以不受限制地复制任意多份，并对这些副本做任何你想做的事。但 SQLite 并不开放贡献。为了让 SQLite 保持在公有领域（public domain），并确保代码不被专有或受许可内容“污染”，该项目不会接受未提交宣誓书、将其贡献献入公有领域的人所提交的补丁。

https://sqlite.org/copyright.html

https://sqlite.org/copyright.html

Our biggest fear is that kimi-cli will lose its simplicity and become a bloated beast.

我们最大的担忧，是 kimi-cli 失去其简洁性，变成一头臃肿的怪兽。

Some people criticize that the TUI experience is shitty compared to Claude Code. That's intentional. I would not say it's shitty—just minimalistic and useful enough.

有人批评说，与 Claude Code 相比，TUI 体验很糟糕。这是刻意为之。我不觉得它“很糟”——只是极简，并且足够好用。

We deliberately do not want to build a super app in the terminal like Claude Code (which is a great product worthy of respect). Instead, we will focus our efforts on building kimi web (Kimi Code CLI Web Interface🥝) and the Kimi Code VSCode plugin.

我们刻意不想像 Claude Code 那样在终端里打造一个超级应用（它确实是一款很棒、值得尊重的产品）。相反，我们会把精力聚焦在构建 kimi web（Kimi Code CLI Web Interface🥝）以及 Kimi Code 的 VSCode 插件上。

That's also why we integrated @willmcgugan's Toad (best known for Rich and Textual) as kimi term—we leave TUI excellence to the experts.

这也是我们把 @willmcgugan 的 Toad（因 Rich 与 Textual 而广为人知）集成为 kimi term 的原因——TUI 的卓越体验交给专家来做。

We endorse "The Apache Way"—Community Over Code.

我们认同 “The Apache Way”——社区重于代码（Community Over Code）。

What We Welcome

我们欢迎什么

For us, GitHub will increasingly become a place for "open discussion." Bug reports are very important to us, and bugfix PRs are still welcome.

对我们来说，GitHub 将越来越成为一个用于“开放讨论”的地方。Bug 报告对我们非常重要，修复 bug 的 PR 仍然欢迎。

(That said, some bugfixes are not as obvious as they look and may affect overall system quality—so we might be slow to accept certain fixes.)

（当然，有些 bugfix 并不像表面看起来那么显而易见，可能影响整体系统质量——因此我们对某些修复的接受速度可能会比较慢。）

However, the dynamics of new feature PRs will be very different. We welcome "feature requests" and "idea discussions," but we will likely be slow in accepting such PRs. We need to carefully consider each change and push the project forward according to our roadmap, maintaining the stability and consistency of the kernel to ensure long-term sustainability. That said, you can use Pull Requests and KLIPs (Kimi CLI Improvement Proposals) as vehicles for idea discussion in the community. Your proposals may inspire us to adjust our roadmap if we see their value or recognize a genuine community need. Of course, for real pain points requiring immediate attention, we will prioritize them. And to make the project fit your specific needs, we encourage you to build on top of it—or fork it—to create your own "personal software." Share with us what you build.

然而，新功能 PR 的运作方式会很不一样。我们欢迎“功能请求”和“想法讨论”，但我们很可能会较慢地接收这类 PR。我们需要审慎评估每一次变更，并按照我们的路线图推动项目向前，维护内核的稳定性与一致性，以确保长期可持续。话虽如此，你可以把 Pull Requests 和 KLIPs（Kimi CLI Improvement Proposals，Kimi CLI 改进提案）作为社区里讨论想法的载体。如果我们看到其价值，或认识到真实的社区需求，你的提案可能会促使我们调整路线图。当然，对于需要立即关注的真实痛点，我们会优先处理。而为了让项目契合你的具体需求，我们也鼓励你在其之上继续构建——或者 fork 它——打造你自己的“个人软件”。也欢迎把你构建的内容分享给我们。

These principles and practices may not fit all projects. "Move fast and fail fast" OSS can succeed in its own way. But that's not the kind of OSS we want Kimi Code to be. We aim for something more deliberate, more sustainable—and ultimately, more useful to those who choose to build upon it.

这些原则与实践未必适用于所有项目。“Move fast and fail fast” 的 OSS 也可以以自己的方式成功。但那不是我们希望 Kimi Code 成为的那类 OSS。我们追求的是更克制、更可持续——并最终对那些选择在其之上构建的人更有用。

Link: http://x.com/i/article/2017139966565085184

链接: http://x.com/i/article/2017139966565085184

相关笔记

Thoughts on Open Source Software and Kimi Code CLI

  • Source: https://x.com/xiaoxxchan/status/2017152237689327784?s=46
  • Mirror: https://x.com/xiaoxxchan/status/2017152237689327784?s=46
  • Published: 2026-01-30T08:25:44+00:00
  • Saved: 2026-01-31

Content

@istdrc and I have been working on open source projects since even before we began our careers. We deeply understand the dynamics of open source—both from the contributor's perspective and the maintainer's. We know the joy, the frustration, and the burden it brings.

In the era of coding agents, one change is becoming increasingly apparent, as stated by @GergelyOrosz:

Actually, this is nothing new. Before AI, real open source projects already worked like this. Code contribution was never the most valuable part. Unless you were deeply involved in community discussions, proved your capability, and earned trust, your PR could easily be ignored—especially for large features. The key reason is that code needs maintenance. Unless you could prove you were willing to maintain your code, cared about the whole project and the community, or demonstrated that your PR was easy to maintain and beneficial to everyone (both users and maintainers), your PRs were often more of a burden than a help.

Coding agents now give more people the ability to create PRs, so newcomers may be surprised to find that open source doesn't actually work that way.

Before the era of coding agents, there were cases where the community had an aligned roadmap but lacked the manpower to implement it. In such cases, maintainers were happy to accept newcomers to build together—newcomers who might develop an interest in becoming long-term contributors or even maintainers themselves.

But now, with coding agents, the manpower for coding will never be a problem again. In fact, triaging PRs has become slower than maintainers collaborating with their own coding agents.

Does that mean open source is dead? Not at all. And why are we still open sourcing kimi-cli?

The Freedom to Modify

Consider the MIT License, which I believe captures the core spirit of open source:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, ...

Most importantly, we want to grant everyone the freedom to modify the software to fit their own needs.

We actually thought about this from day one of kimi-cli. We want it to be a solid foundation—a kernel for building upwards. We want to make it easy for people to build on top of kimi-cli's kernel, while also crafting elegant and solid abstractions that make the source code easy to hack.

This emphasis on hackability echoes the origins of open source in the early days of the Free Software Movement—before GitHub even existed.

We embrace this freedom fully. Even when our visions diverge or our roadmap doesn't align with your needs, you retain complete autonomy to fork and modify. We don't just permit this—we architect for it. Making kimi-cli easy to hack is a deliberate design goal, ensuring that divergence is as frictionless as possible.

Kernel, Not Super App

That said, we are not that strict. Some projects take an even harder line on external contributions. The most famous example is probably SQLite, which is open-source but explicitly not open-contribution:

Open-Source, not Open-Contribution

SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.

https://sqlite.org/copyright.html

Our biggest fear is that kimi-cli will lose its simplicity and become a bloated beast.

Some people criticize that the TUI experience is shitty compared to Claude Code. That's intentional. I would not say it's shitty—just minimalistic and useful enough.

We deliberately do not want to build a super app in the terminal like Claude Code (which is a great product worthy of respect). Instead, we will focus our efforts on building kimi web (Kimi Code CLI Web Interface🥝) and the Kimi Code VSCode plugin.

That's also why we integrated @willmcgugan's Toad (best known for Rich and Textual) as kimi term—we leave TUI excellence to the experts.

We endorse "The Apache Way"—Community Over Code.

What We Welcome

For us, GitHub will increasingly become a place for "open discussion." Bug reports are very important to us, and bugfix PRs are still welcome.

(That said, some bugfixes are not as obvious as they look and may affect overall system quality—so we might be slow to accept certain fixes.)

However, the dynamics of new feature PRs will be very different. We welcome "feature requests" and "idea discussions," but we will likely be slow in accepting such PRs. We need to carefully consider each change and push the project forward according to our roadmap, maintaining the stability and consistency of the kernel to ensure long-term sustainability. That said, you can use Pull Requests and KLIPs (Kimi CLI Improvement Proposals) as vehicles for idea discussion in the community. Your proposals may inspire us to adjust our roadmap if we see their value or recognize a genuine community need. Of course, for real pain points requiring immediate attention, we will prioritize them. And to make the project fit your specific needs, we encourage you to build on top of it—or fork it—to create your own "personal software." Share with us what you build.

These principles and practices may not fit all projects. "Move fast and fail fast" OSS can succeed in its own way. But that's not the kind of OSS we want Kimi Code to be. We aim for something more deliberate, more sustainable—and ultimately, more useful to those who choose to build upon it.

Link: http://x.com/i/article/2017139966565085184

📋 讨论归档

讨论进行中…