夜雨聆风你有没有遇到过这种事：某个软件就差一个小功能，用了就完美了，但官方就是不做。想要个深色模式，等了三年；想要个导出按钮，反馈了五遍没下文。以前你的选择只有两个：忍，或者换。现在有了第三个选择——让 AI 直接改它的源码。
这不是我编的，是 8 月 3 日 Hacker News 上一个 719 分热帖的核心观点。帖子标题只有一句话："开发者工具必须开源"（Devtools must be open source）。两百多条评论里，一线工程师吵翻了天。
先给结论：当 AI 代理能读改源码，"源码"本身就成了最强大的扩展接口——插件系统、配置项、扩展 API 这些传统机制，正在被"直接改源码 + 自动同步上游"取代。开源的"用户可修改"理想第一次真正兑现，但硬币的另一面，是开源赖以生存的商业模型正在被同一股力量瓦解开。
五年前，没人给自己写工具
理解这个观点，先看一个反差。
五年前，你问工程师"有没有为自己写的程序"，绝大多数人答不上来。不是不想，是账算不过来：要学懂一个庞大的代码库、做点修改、还要在每次上游更新时把本地改动重新合并一遍——对个人来说是个填不满的坑。所以大家只能靠配置文件、插件、扩展系统，在软件允许的范围内调一调。
2025 年之后，AI 代理读改真实代码库从演示变成了日常，这笔账被改写了。改写它的不是更聪明的插件，而是两条提示词。
第一条，个性化："下载这个软件的源码，本地构建。记住：以后任何修改都从源码出发，不要碰配置文件里的开关。"
第二条，更关键，同步："设一个每晚运行的定时任务：拉取上游更新，把本地改动 rebase 上去，验证功能正常后替换当前版本。"
就这两条。不需要插件市场，不需要读几十页配置文档，不需要等作者排期。AI 同时解决了"开始定制"和"持续维护"两个难题——这正是以前个人定制软件 ROI 算不过来的原因。
实战：一条提示词，集成一个功能
帖子作者用亲身经历做了演示。
他写了个叫 meat.dev 的小工具：用 AI 把代码 diff 里不重要的内容（import 块、空值检查、错误处理）剥掉，让人专注看关键的"肉"。他嫌在终端里看体验差，想让工具集成进自己的写作软件 Shelley，并且提交一创建就在后台自动预处理。
他给 AI 下了一条提示词："把 meat.dev 集成进 Shelley。安装到 PATH。当创建 git commit 时，后台启动 meat 处理。在 Diffs 视图加个切换按钮……"
一条提示词，全做完了。他自己感叹：这事要是走 VS Code 的扩展 API，"几乎是不可完成的任务"——不是做不到，是扩展点的形状根本不对，投入产出完全不成比例。
评论区里这样的案例越来越多：有人 fork 了终端模拟器 Ghostty，让 AI 保持与上游同步、自动处理 issue——"软件的未来是每个用户一个定制版"；有人等上游修内存泄漏等不到，花一周让 AI 帮自己写了个终端模拟器；有人维护着 6 个自己的 fork，用 AI 同步上游"极其轻松"。
插件系统，正在变成历史名词
这些案例指向同一个判断：在 AI 代理时代，单用户软件不需要插件系统了。
想要字体大一点？给 agent 源码，告诉它改。是硬编码的位图字体？它会下载一个新的替换掉，甚至用工具现场生成一个。以前你只能等官方开放一个配置项才能做的事，现在是一句自然语言指令。
知名开发者 Simon Willison 说得很透：开源软件"用户可以检查和修改"的理想说了几十年，但绝大多数人根本没时间读代码、改代码——LLM 第一次让这个原始梦想真正可行。他每天的工作流就是"让 Claude 把某个仓库克隆下来，告诉我它是怎么工作的"。
对个人开发者是这样，对小团队也一样：与其买一个"极其可配置"的任务管理系统、花几周学习配置、再把团队硬塞进它的框架，不如用通用模块组装一个正好合身的。博客文章都能变成"量身定制"的专属软件，只因为组装它的成本已经趋近于零。
但硬币的另一面，同样刺眼
该说反方观点了，而且评论区里反对的声音一点都不弱。
第一，改配置和改源码的效率差距，差着数量级。 有人反驳：改个字体颜色，配置文件里改一个数字是一劳永逸；改源码意味着下载代码、定位行、搭构建环境、维护构建链——"用这种方式改字体大小，简直是疯了"。你的工具会变成一个需要长期维护的"副项目"。
第二，"永续 fork"的负担只是被推迟了，没有消失。 你 fork 了软件，上游每次重构，你都面临合并冲突；每次安全更新，你都要重新修补丁。有人的亲身经历更扎心：他帮一个库改了一行代码，提交 PR 时因为带 AI 生成痕迹被直接拒绝——"把关是维持质量的唯一方式，一旦让 slop 进来，它会以疯狂的速度堆积"。
第三，维护者正在被 AI slop 淹没。 "人们想把你的软件拽向一百万个互不兼容的方向，写个大补丁，你不合并且他们就生气。" 这是开源维护者的真实处境。
第四，也是最深的担忧：开源正在被"武器化"。 有评论说得尖锐："连斯托曼和 Linus 都没靠开源赚到钱……现在'开源'被用来把整个公司的价格压到地板，维护软件的变成了编码代理——开源软件作者成了软件世界的新'饥饿艺术家'。" 更有人预判反向趋势：如果你发明了一个天才的新索引算法并开源，我只要让编码代理看一眼你的代码，几分钟就能模仿出你的洞察。 那谁还敢开源？
什么才值得闭源？
这场争论其实引出了一个更有价值的问题：当 AI 能解剖一切代码，"什么值得闭源"的标准变了。
以前，功能就是壁垒——你有的功能别人没有，你就能收费。现在，能被 AI 一句话复刻的功能不再构成壁垒。真正的壁垒变成了三类：数据（用户产生的、别人拿不到的）、网络效应（人越多越好用）、持续服务（托管、支持、合规）。
这也是为什么评论区有人替"闭源工具"辩护：我们做托管产品不开源，因为"我来这里不是为了维护工具，是为了用工具干活"。也有人提出中道路线：不开源但给一个好的 API 和 SDK（像 Obsidian），agent 一样能自由调用，用户获得全部定制能力，公司保住核心秘密。
至于开头说的那个"开发者工具必须开源"——原文里有一个很硬的分野：OpenAI 的 Codex 是开源的，你可以个性化它；Anthropic 的 Claude Code 是闭源的，你只能用它预留的钩子。"如果你想要的 agent 工作方式不适合它们的钩子，那就换一个能让你个性化的。"
三条建议
如果你是开发者：试着让 AI 改一次你天天用的开源工具的源码——哪怕只是换个字体、加个快捷键。这个体验会刷新你对"定制"的理解。但记住：改之前先想清楚，你愿意为这个 fork 承担多久的维护责任。
如果你是开源维护者：AI 时代你的处境会更难——贡献变多，但质量参差；代码更容易被"学习"。能救你的不是拒绝 AI 贡献，而是建立清晰的贡献标准和自动化验证，以及，把商业模式从"卖代码"转向"卖服务"。
如果你是创业者：问自己一个问题——你的产品如果明天被开源，还能活吗？如果答案是"不能"，那它可能根本不值得做；如果能，想想为什么——那多半是你真正的护城河（数据、网络效应、服务），而不是代码本身。
回到开头那个等了三年的深色模式。下一次，你可以不用等了。当 AI 能读懂每一行代码，源代码就成了这个时代最强大的扩展接口——而选择把自己锁在接口之外的工具，正在失去它最后的竞争力。
工具会变，但"工具应该为我所用"这件事，从来没变过。
如果这篇文章对你有帮助或有启发：
⭐ 关注账号 — 持续解读 AI 时代开发者生态与技术趋势
👍 点赞 — 让更多人看到"源码即扩展系统"这个新范式
💬 留言 — 你让 AI 改过自己用的工具吗？体验如何？
🔄 转发 — 转给那个还在等官方功能排期的开发者朋友