❌

阅读视图

发现新文章，点击刷新页面。
🔲 ☆

AI 时代的开源：当 Coding Agent 接管 GitHub，我们该何去何从？

✇Tony Bai
bigwhite

本文永久链接 – https://tonybai.com/2026/03/01/open-source-ai-era-coding-agent-takes-over-github

大家好，我是Tony Bai。

如果我们把时间拨回到 2023 年之前，一个开源项目的诞生往往伴随着一位或几位核心维护者（Maintainer）数周甚至数月的辛勤耕耘。

但在刚刚过去的几个月里，我们见证了一种全新的物种崛起。

以 OpenClaw（其前身是火遍全网的 Moltbot/Clawdbot）为代表，这类项目的代码库中，接近 100% 的代码都是由 AI Coding Agent（如 Claude Code等）编写的。甚至连最初的 README、项目结构、测试用例，都是由 AI 在几分钟内“吐”出来的。

这是一个极其震撼的信号！它意味着，代码的生产成本正在趋近于零。

当 Gastown、Beads 等由 Agent 驱动的项目如雨后春笋般涌现，GitHub 上的 Commit 频率开始呈现出非人类的特征——一个小项目可能在一天内产生数百次提交，每一次都包含了完整的逻辑和测试。

近期，SemiAnalysis也曝出一个惊人数据：目前，GitHub上4%的公开提交（commits）都是由Claude Code生成的，到了2026年底这个数字将达到20%以上。

这种Coding Agent生产力的“核爆”，正在对我们熟悉的开源世界发起一场降维打击。Github开源的那个被奉为圭臬的 opensource.guide，其中的许多条款在今天看来，似乎已经过时了。

当 Coding Agent 开始接管 GitHub，传统的“人-人”协作模式将面临怎样的崩塌与重建？我们，作为人类开发者，又该何去何从？

旧秩序的崩塌：信任与注意力的危机

开源社区的基石，建立在两个稀缺资源之上：人类的时间 和 人与人之间的信任。

在过去，当你向一个项目提交 PR（Pull Request）时，维护者默认会认为：你付出了时间，你阅读了代码，你是来帮忙的。这种“工作量证明（Proof of Work）”构建了基本的信任。

但在 Coding Agent 时代，这个逻辑被打破了。

垃圾 PR 的洪流 (Spam PRs)

现在的贡献者，可能只是在 Cursor 或 Claude Code等Coding Agent 里输入了一句：“帮我给这个项目加个功能。”

几秒钟后，一个包含几百行代码的 PR 就生成了。

贡献者可能根本没看懂代码，甚至没跑过测试，就直接点击了 Create Pull Request。

对于维护者来说，这是一场灾难。你面对的不再是带着诚意的贡献者，而是成千上万个不知疲倦的“Prompt 搬运工”。

人工 Review 的物理极限

人类阅读代码的速度，是有生理极限的。

当 AI 一天能生成人类一年才能写完的代码量时，“人工 Code Review” 这个环节彻底瘫痪了。

即使维护者 24 小时不睡觉，也无法审核完那些由 Agent 生成的、逻辑似是而非的代码。

贡献者的异化

传统的开源贡献者，通过阅读源码、理解架构来提升自己。

现在的部分贡献者，变成了“刷单机器”。他们关心的不是项目本身，而是 GitHub Profile 上的绿色格子。

当贡献不再代表能力，而只代表算力时，开源社区的荣誉体系也随之崩塌。

开源 2.0 的新法则：机器优先治理

面对这场危机，我们不能坐以待毙。开源社区必须进化出一种新的秩序——开源 2.0。 在这个新时代，核心法则将从“以人为本”转向“机器优先（Machine-First）”。

法则一：Agent 审查 Agent

既然人类无法处理机器生成的洪流，那就让机器去对抗机器。 未来的开源项目，将标配一个 “守门员 Agent” (Gatekeeper Agent)。

  • 当 PR 提交时，首先迎接它的不是人类，而是守门员冷酷的扫描。
  • 它会运行测试，检查代码风格，甚至进行逻辑推理(这一点尤为重要)：“这段新增的代码是否与项目的架构原则冲突？”
  • 只有通过了守门员预审的 PR，才会被打上 human-review-needed 的标签，呈现在人类面前。

这不再是简单的 CI/CD，这是具备认知能力的 AI 门卫。

法则二：规范即源码

在 AI 时代，提交代码（Implementation）可能不再是最高效的协作方式。

因为代码是廉价的，是易变的。真正昂贵且恒定的，是意图（Intent）和约束（Constraint）。

未来的开源贡献，很大可能会演变成：

  • 提交 Spec：“我希望增加一个 User 模块，接口定义如下…”
  • 提交 Test Case：“这是一个复现 Bug 的测试用例…”

维护者的 Agent 接收到这些 Spec 后，会自动生成实现代码。

“与其给我鱼（代码），不如给我渔网（Spec）。”，或者说 **“Do not show me your code, Show me your spec”。这将彻底改变 Git 的协作流。

法则三：声誉协议的重构

我们需要一套新的机制来识别“高质量贡献者”。

仅仅看 Commit 数量已经没有意义了。未来的 GitHub 可能会引入基于 AI 评估的声誉分。

  • 你的 PR 是否一次性通过了 Agent 审查？
  • 你的代码是否被下游项目广泛引用？
  • 你的 Spec 是否具有创新性？
  • … …

灵魂拷问：我们为什么还要开源？

这可能是最深层的存在主义危机。

如果每个人都有一个全能的 Coding Agent，只需要说一句“我要一个高性能 HTTP 路由库”，AI 就能现场写出一个完美的版本（甚至根据你的业务场景定制），那么——我们还需要开源 express 或 gin 吗？

当代码的边际生产成本归零，传统的“共享代码以复用”的经济学基础就被动摇了。

悲观视角：开源库的贬值

通用的、工具性质的开源库（Utils, Helpers），可能会大量消亡。因为 AI 现场生成的成本，比你去 GitHub 搜索、安装、阅读文档的成本还要低。“即时软件（Just-in-Time Software）” 将成为现实。

乐观视角：开源的本质回归

但开源不会死。因为开源的本质不是共享代码，而是共享智慧。

我们依然需要共享：

  • 架构模式 (Architecture Patterns)：如何组织复杂的系统？
  • Agent Skills (智能体技能)：如何教会 AI 完成特定任务？
  • 评估标准 (Benchmarks)：什么是好的代码？

未来的开源，将很可能从“代码托管”进化为“智能体能力托管”。GitHub 可能会变成一个巨大的 Agent Hub，我们在这里分享 Prompt、分享 Context、分享让 Agent 变得更聪明的知识。

平台的进化：GitHub 的自我救赎

作为开源的基础设施，GitHub（或者它的挑战者）必须做出改变，以迎合 Coding Agent 时代。

我们不妨大胆预测一下 GitHub 的未来功能：

  • AI Gatekeeper 集成：仓库设置里增加一个“开启 AI 预审”的开关。
  • Semantic Search（语义搜索）：传统的关键词搜索在海量生成的代码面前已经失效。我们需要“意图搜索”——“帮我找一个能处理 PDF 解析且兼容 Python 3.12 的 Agent Skill”。
  • Interactive README：README.md 不再是静态文档，而是一个Chat Interface。你可以直接问项目：“怎么安装？”“报错了怎么办？” 项目自带的 Support Agent 会回答你。
  • A2A Protocol 支持：GitHub 可能会标准化 Agent-to-Agent 的协作协议或演进现有的A2A协议，让不同项目的 Agent 能够跨仓库协作（例如：依赖更新 Agent 自动向你的项目提交 PR）。

小结：最后的守夜人

在这个机器轰鸣、代码如洪流般涌现的时代，人类维护者将成为“最后的守夜人”。

我们的职责不再是亲自砌每一块砖（写代码），也不再是亲自检查每一块砖的纹理（Review 代码）。

我们的职责是：定义蓝图（Spec），设定标准（Evaluation），以及在机器迷失方向时，握住方向盘（Alignment）。

未来开源并不会死，它只是进化了。

它从一群手工匠人的集市，进化成了一座高度自动化的未来城市。而我们，是这座城市的规划师。

你的“开源”新角色

开源的 2.0 时代正在开启。作为开发者或维护者，你更看好“规范即源码”的协作模式，还是依然怀念那种“人与人、面对面”的代码交流？你认为 AI 带来的 PR 洪流是加速了项目的进化，还是仅仅制造了更多的数字噪音？

欢迎在评论区分享你的真实感受与预判！让我们一起探讨如何在机器的时代守住人的智慧。

如果这篇文章引发了你对职业未来的深思，别忘了点个【赞】和【在看】，并分享给那些依然奋斗在 GitHub 第一线的战友们！

构建你的开源防御体系

在这个开源新秩序建立的前夜，作为一个开发者，你该如何适应？ 是继续用肉身对抗机器的洪流，还是学会构建自己的 Agent Guardrails？

在我的极客时间专栏《AI原生开发工作流实战》中，我们将深入探讨：

  • AI Code Reviewer 实战：如何利用 Claude Code 和 GitHub Actions 构建自动审查流水线？
  • Spec-Driven Contribution：如何设计一套基于 Spec 的开源贡献规范？
  • Agent Skills 开发：如何将你的经验封装成 Skill，发布到未来的开源市场？

不要被时代抛弃。扫描下方二维码，掌握驾驭机器军团的能力。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

  • 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
  • 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
  • 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

🔲 ⭐

你的 CLAUDE.md 写错了：为什么指令越多，AI 越笨？

✇Tony Bai
bigwhite

本文永久链接 – https://tonybai.com/2026/01/29/write-a-good-claude-md

大家好，我是Tony Bai。

在使用 Claude Code、Cursor 或 Gemini Cli 等 AI 编程工具时，你是否遇到过这样的情况：

明明在项目根目录写了 CLAUDE.md（或 AGENTS.md），洋洋洒洒列了几十条项目规范：“使用 TypeScript”、“不要用 any”、“单元测试覆盖率要达标”……

但 AI 就像个叛逆的实习生，经常对这些指令视而不见，反复犯同样的低级错误。

是你写的 Prompt 不够严厉吗？还是模型不够聪明？

最近，HumanLayer 团队发布的一篇深度分析文章揭示了真相：

问题恰恰在于你写得太多了。

Claude Code 的内部机制会给模型注入一条系统级提醒：

“IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant.”
（重要：此上下文可能与您的任务无关。除非高度相关，否则请忽略。）

这意味着，你的 CLAUDE.md 越臃肿，包含的无关信息越多，它被系统判定为“噪音”并整体忽略的概率就越大。

今天，我们来聊聊如何用工程化的思维，重构你的 AI 上下文管理。

第一性原理：AI 是无状态的“新员工”

要写好 CLAUDE.md，首先要理解 LLM 的本质：它是无状态的（Stateless）。

每次你开启一个新的 Session，对于 AI 来说，都是入职第一天。它对你的代码库一无所知。CLAUDE.md 是它唯一的“入职手册”和“长期记忆”。

但这并不意味着你要把公司历史全塞给它。一个优秀的入职手册应该包含什么？

HumanLayer 的文章中 总结了 “The Trinity”（三要素）：

  1. WHAT（地图）： 技术栈是什么？项目结构是怎样的？（特别是 Monorepo，告诉它哪里是 App，哪里是 Lib）。
  2. WHY（目标）： 这个项目的核心价值是什么？核心模块的职责边界在哪里？
  3. HOW（工具）： 怎么构建？怎么跑测试？用 npm 还是 bun？

除此之外的任何废话，都是在消耗 AI 宝贵的注意力。

最佳实践一：少即是多 (Less is More)

研究表明，即便是最前沿的推理模型（Thinking Models），能稳定遵循的指令上限也就在 150-200 条左右。而小模型（如 Haiku 或 GPT-4o-mini）的遵循能力随着指令数量增加呈指数级下降。

更糟糕的是 “位置偏见（Position Bias）”。LLM 高度关注开头（System Prompt）和结尾（最新对话），夹在中间的 CLAUDE.md 如果过长，极易沦为“被遗忘的中间层”。

因此，请遵循以下黄金法则：

  • 不要试图涵盖所有边缘情况。
  • 将根目录的 CLAUDE.md 控制在 300 行以内，HumanLayer 的生产环境甚至控制在 60 行以内。
  • 每一行都要问自己：“如果没有这句话，AI 真的干不了活吗？”

最佳实践二：渐进式披露 (Progressive Disclosure)

如果你确实有很多规范要交代，怎么办？

答案是：不要把所有鸡蛋放在一个篮子里。

想象一下，HR 会在入职第一天把 500 页的《数据库运维手册》扔给一个前端开发吗？不会。

你需要构建一套“渐进式”的文档体系：

1. 建立文档库：

在项目中创建一个 .ai/docs/ 目录，存放特定领域的指南：

  • testing.md：详细的测试编写与运行指南。
  • database.md：Schema 定义与迁移规范。
  • architecture.md：核心架构图与数据流。

2. 建立索引：

在主 CLAUDE.md 中，只保留“触发器”：

  • “编写或运行测试前，请务必阅读 .ai/docs/testing.md。”
  • “涉及数据库变更时，请参考 .ai/docs/database.md。”

这样，当 AI 只是在写一个前端组件时，它的上下文窗口就不会被无关的后端 Schema 污染。保持注意力的纯净，是提升 AI 智商的关键。

最佳实践三：别把 AI 当 Linter 用

这是最常见的资源浪费：在 CLAUDE.md 里写了 50 行关于代码风格的规定——“缩进用 2 个空格”、“花括号不换行”、“变量名用驼峰”……

请记住：LLM 是昂贵的推理引擎，不是廉价的格式化工具。

让 AI 去关注缩进，就像让法拉利去送外卖，既贵又慢。而且，AI 即使知道规则，也经常因为概率性生成而“手滑”。

正确的解法是：Tooling > Prompting。

  1. 配置工具： 使用 Prettier, Biome, ESLint, govet 等确定性工具来处理格式。
  2. 设置 Hook： 配置 Claude Code 的 Stop Hook。如果 AI 生成的代码格式不对，让 Linter 报错，把错误信息喂回给 AI。
    • AI: (生成代码)
    • System: “Lint Error: Missing semicolon.”
    • AI: “Ah, fixing it.”

AI 极其擅长修复报错，但并不擅长凭空遵守“隐形的规则”。

小结：杠杆的层级

在 AI 原生开发中，CLAUDE.md 处于“杠杆层级”的顶端。

  • 写错一行代码 = 1 个 Bug。
  • 写错一行 CLAUDE.md = 成百上千次错误的规划、错误的检索、错误的代码。

不要盲目依赖 /init 自动生成的文件，那只是个起点。你需要像维护核心代码一样，精心雕琢你的 CLAUDE.md。

现在，打开你的项目，检查一下那个文件。

删掉那些废话，把长文档拆分，把格式化交给工具。

给你的数字员工减负，它才能跑得更快。

资料链接：https://www.humanlayer.dev/blog/writing-a-good-claude-md

你的 CLAUDE.md 有几行？

读完这篇文章，不妨现在就去检查一下你项目里的 CLAUDE.md。它是清爽的“入职手册”，还是臃肿的“裹脚布”？你目前的行数是多少？

欢迎在评论区晒出你的“瘦身”成果！让我们一起给 AI 减负。

如果这篇文章帮你解决了 AI “不听话”的难题，别忘了点个【赞】和【在看】，并转发给你的团队，规范大家的 Prompt 工程！

构建工程化的 AI 工作流

CLAUDE.md 只是构建 AI 原生工作流的起点。

  • 如何配置 Hooks 来实现自动化代码审查？
  • 如何编写 Sub-Agents 来处理隔离的脏活累活？
  • 如何设计 Slash Commands 来固化团队的 SOP？

如果你想深入掌握 Claude Code 的高阶玩法，不仅仅是写 Prompt，而是构建一套“自动纠错、按需加载”的工程化体系。

欢迎关注我的极客时间专栏《AI 原生开发工作流实战》。

我们不聊虚的，只讲能在生产环境中落地的 AI 工程实践。

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

  • 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
  • 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
  • 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

❌