先看数据
2026 年 2 月 21 日到 6 月 7 日，107 天里我在 GitHub 上新建了 17 个仓库：14 个实质项目，加 3 个单 commit 小工具。合计 1,221 个 commit（本人署名 1,185 个），其中 953 个（78%）带有 Claude 的 Co-Authored-By 署名。约 15.7 万行源代码（不含生成代码和 vendor），横跨 Rust、Swift、Zig、Dart、Kotlin、TypeScript、Python 七种语言。107 天里有 78 天有 commit，其中 50 天在同时推进两个以上仓库，单日最多 6 个。
其中体量最大的 meow 全家桶（Rust 内核 + iOS + Android 三端，合计 9.2 万行）从立项到三端可用只用了三个半月，而且只占同期总产出的一半多一点。按我过去十几年业余维护开源项目的经验，这是数年级别的工作量。
这篇文章用这批数据讨论三件事：效率从哪里来、碎片化时间的工作流长什么样、以及"软件大规模开源免费化"这个推论的成立范围。
效率的三个来源
语言不再是边界
我过去十几年的主力语言是 C、Scala 和 Kotlin。今年的 17 个仓库横跨 7 种语言，其中 Zig、Dart、Swift 此前我从未写过生产代码。
最极端的例子是 gterm：它需要 fork ghostty 并在其 Zig 写的 termio 层里新增一个 passthru 后端（iOS 不允许 fork/exec 本地 shell，终端必须由 SSH 流驱动），这意味着读懂一个 30 万行 Zig 项目的 IO 架构，再做侵入式修改，用的还是一门我此前从未写过的语言。
Agent 改变的不是"学一门语言要多久"，而是让这个问题消失了：人的瓶颈从"能不能写"变成"能不能读懂并审查"，而读比写容易一个量级。判断一段 Zig 代码的内存所有权是否正确，不需要会默写 Zig 的语法。
单项目从月压缩到天
gterm 从第一个 commit 到 TestFlight 可安装用了 5 个活跃日（5 月 29 日–6 月 5 日，64 个 commit），中间完成了：
- ghostty 的 passthru termio 后端（Zig，上游侵入式修改）
- libghostty 交叉编译为 iOS XCFramework
- swift-nio-ssh 接入：密码/公钥认证、PTY、窗口尺寸同步
- 自定义屏幕键盘（esc/ctrl/alt/方向键、粘滞修饰键）
- Keychain 存储、TOFU 主机密钥、Ed25519/ECDSA 密钥导入
- fastlane + TestFlight 发布管线
这类"GPU 渲染终端 + SSH 协议栈 + iOS 工程"的项目，在没有 agent 的年代是按季度计的业余项目，上面每一项单独拿出来都要先读几天文档。
并行才是碎片时间的正确形态
78 个活跃日中有 50 天在同时推进两个以上仓库，峰值一天 6 个。以 5 月 29 日开始的一周为例：gterm 从 fork ghostty、立项到 TestFlight 可安装提交了 64 个 commit，subtitle_anywhere 集中重构 54 个，trans_proxy、两个股票面板、meow-rs、meow-ios、runse-mac 各有推进。8 天里 9 个仓库 174 个 commit。
并行度不来自人能同时写六个项目的代码，而来自大部分代码本来就不由人写。Agent 跑长任务（移植一个模块、批量重构、修完整套测试）的时间在几十分钟到几小时之间，这段时间人是空闲的。切到另一个项目下发任务或审查产出，就是并行度的全部来源。
碎片化时间的工作流
上面的数据反推出一个工作流的形状：人的每次介入是 10–30 分钟的"审查 + 定向"，而不是连续几小时的"编写"。一个完整的下午写不出 TCP 协议栈，但 15 分钟足够读一个 diff、跑一遍测试、给出下一步方向。
想法的入口：从备忘录到计划文档
这个工作流从想法出现的那一刻就开始了。过去我的习惯是把想法记进 Notion：一句话、几个关键词，等有空再展开。结果是大部分想法死在列表里："有空"意味着一个完整的下午，而完整的下午永远轮不到排在第 20 位的想法。
现在想法出现时（通勤、午休、刷到一个相关项目），我直接打开 Claude app 新建一个项目，把想法口述出去，让它当场产出一份计划文档：目标和非目标、技术选型、里程碑拆分、第一个可验证的最小版本长什么样。这一步在手机上完成，花的还是原来记备忘录的那几分钟，但产物从"一句话提醒"变成了"可以直接开工的 spec"。
到了下班后或周末，我坐在电脑前做的不是"从零启动一个项目"，而是打开已有的计划文档，让 agent 按文档开工，看着 diff 流过，在关键节点纠偏。gterm 仓库里那份 7K 的 PLAN.md 就是这么来的：它先于任何代码存在，5 个活跃日后 TestFlight 可装。
两种记录方式的差别在想法的存活率：备忘录里的一句话需要未来的我重新展开，而计划文档把"展开"这一步在想法还热的时候就完成了，剩下的只是排队等一个空闲的时间片。
四个工程前提
要让这个模式成立，有几个工程前提：
项目状态放在文件系统里，不放在脑子里。 每个项目维护 CLAUDE.md（构建命令、架构骨架、扩展点）和 PLAN.md/roadmap（当前状态、下一步）。碎片时间的最大敌人是上下文恢复成本。如果每次坐下来要先花十分钟回忆"我做到哪了"，碎片时间就不可用。文档让人和 agent 都能冷启动。具体写法在mihomo-rust 移植那篇里展开过。
验证设施先于功能。 CI 和测试是 agent 产出质量的唯一可靠信号。碎片时间不够人肉逐行验证 1,200 个 commit，但够看一眼 CI 是红是绿、抽查测试覆盖了哪些边界。meow-rs 的 619 个测试函数和 5 条 CI 管线不是开发完成后的补课，而是让"78% 的 commit 由 agent 协作完成"不失控的前提。
任务下发以"可验证的目标"为粒度。 "实现 VLESS 协议"不是好任务，"实现 VLESS 握手，通过 spec 里列出的 12 个测试用例"才是。粒度太大，agent 跑偏的成本由人的碎片时间承担；粒度太小，人变成瓶颈。
成本结构。 这套流程的全部现金成本：模型订阅（Claude Max，$100–200/月）、Apple 开发者账号（$99/年）、若干域名和一台 VPS。摊到 17 个仓库上，单项目边际成本接近于零。这个数字是下一节论证的基础。
一切软件开源免费化？
先把推论说清楚：工具类软件的价格由实现成本和稀缺性支撑。当一个具备审查能力的工程师用碎片时间和每月一两百美元的订阅就能复刻一个工具，纯实现型软件的定价权会持续流失。
这不是抽象推演。今年这批项目里，相当一部分直接对应我过去付费或考虑付费的软件：
| 我写的 | 替代的商业品类 | 典型定价 |
|---|---|---|
| gterm | 订阅制 iOS SSH 终端 | $5–10/月 |
| meow 全家桶 | 付费代理客户端（Surge $49.99、Shadowrocket $2.99 等） | $3–50 |
| runse / runse-mac | 付费划词润色、AI 写作工具 | $5–20/月 |
| subtitle_anywhere | 按量计费的转写/字幕服务 | ~$10/小时音频 |
| trans_proxy、sshttp、macmtr | 各类网络小工具 | $5–30 |
写完之后为什么开源而不是上架卖 $2.99？因为收费有固定成本：上架审核、客服、退款、税务合规，这些成本不随价格下降而下降，在低价区间会吃掉全部利润。而当开发成本只是碎片时间加一份本来就订了的模型订阅，软件就从"商品"变回了"副产品"。对副产品来说，开源的回报（issue 反馈、PR、声誉）是更划算的变现方式。
长尾需求第一次被覆盖
比替代付费软件更重要的，是那些从来不会有商业版本的项目。taiwan-strait-monitor（开源情报聚合）、fof-quant（FoF 基金分析）、bangumi-downloader（番剧种子聚合），这类需求的全球用户可能只有几百人，过去不会被实现，因为开发成本远大于任何可能的收益。现在"为自己做就够本"，开源只是顺手的事。软件长尾的覆盖密度会因此显著上升，而长尾本来就不在商业软件的射程内。
边界：什么不会免费
推论到这里为止都成立，但它有明确的边界。
持续运行成本不会消失。 runse 免费，但它调用的 LLM API 按 token 计费；subtitle_anywhere 免费，但需要一台 Apple Silicon 的机器跑 MLX Whisper。软件实现的边际成本归零，不等于算力和数据源的边际成本归零。依赖持续服务的产品仍然能收费，只是收的是服务费而不是软件费。
分发与信任仍然稀缺。 这批项目的 star 数说明了问题：17 个仓库里只有 meow-rs（262）和 meow-ios（102）过百。代码不再稀缺之后，稀缺的是让陌生人敢用：签名公证、上架渠道、持续维护的信誉。Apple 的 $99/年买的不是工具链，是分发资格。
维护承诺没有被自动化。 我的 17 个仓库大多不承诺维护。商业软件卖的东西里，SLA 的占比会越来越高，代码本身的占比越来越低。这其实是把软件业的定价拉回了它的真实成本结构。
"免费"是成本转移，不是成本消失。 用户免费用 gterm，但我付了模型订阅费。把视角拉远：这一轮工具软件免费化的资金来源，是模型厂商的订阅收入。软件费向模型费的集中，和当年单机软件费向云服务费的集中，是同一种结构变化。
审计问题：开源是 AI 代码的必要条件
还有一个常被反过来提的问题：近 16 万行代码、78% 的 commit 由 agent 协作完成，谁来保证质量？
这个问题反而是开源的论据。AI 深度参与的闭源软件，作者自己都未必逐行读过，外部更无从审计；开源至少让"可审计"成立，而审计本身同样被 agent 增强：让一个干净上下文的 agent 做对抗式 review，成本和写代码一样低。网络和安全类工具尤其如此：协议实现的弱点，只有在代码可被任何人检查时才会被持续地发现和修复。AI 把写代码的门槛降下来之后，这种公开检查机制的相对价值更高了。
给独立开发者的清单
把这套实践压缩成可操作的几条：
- 选项目按"自己是否需要"，不按市场规模。 边际成本接近零之后，为自己写就值得写
- 第一个活跃日花在验证设施上：CI、测试骨架、CLAUDE.md。这决定了后续碎片时间的利用率
- 用文件系统承载项目状态，让每个 15 分钟的时间片都能冷启动
- 并行多个项目，用 agent 跑长任务的时间切换去审查另一个项目，串行开发浪费的正是这段时间
- 不熟悉的语言和领域不再是放弃理由，前提是你能审查产出：读得懂 diff、看得懂测试
- 默认开源。 副产品收不回收费的固定成本，但收得回声誉和协作
当实现能力不再稀缺，独立开发者的产出上限由审查能力和碎片时间决定。而软件本身，正在回到它在商业化之前的形态：写出来，放出去，让需要的人拿去用。