Local-First Conf 出现了一个很能说明当下开发者心态的场景。
据文章作者观察，现场不少人批评 LLM 带来的代码垃圾、平台依赖和社区损耗，电脑上却普遍开着 Claude Code。嘴上警惕，手上不停。不是因为批评失效，而是工具已经好用到很难靠道德姿态拒绝。
另一个反差更直接：Pi.dev 团队为了挡住低成本提交，选择自动关闭多数 PR 和 issue。AI 降低了贡献门槛，也让维护者开始怀疑每一次“贡献”背后究竟投入了多少思考。
作者本人同样处在矛盾中央。他列出 LLM 的多项代价，却仍然重度使用，并称自己在 2026 年 6 月花了 9838.85 美元购买 token。
这个数字只能按作者自述处理。现有材料没有附上可追溯账单或完整成本明细，日期也属于需要单独核验的高风险信息。它能证明的只有使用强度，不能证明这些 token 换来了多少收入、节省了多少工时，更不能拿来代表行业投入产出。
批评没有阻止使用，成本却落到了社区身上
这篇文章列出的风险并不新鲜，但放在同一个重度用户身上，分量不一样。
| 风险 | 具体表现 | 现实后果 |
|---|---|---|
| 垃圾贡献变便宜 | 几分钟生成 PR、issue、文档和功能建议 | 维护者把时间花在筛选和拒绝上 |
| 代码投入难以判断 | 输出完整、措辞专业，却未必经过验证 | 过去用于识别认真贡献者的信号失真 |
| 新人培养激励下降 | 资深工程师更愿意调用模型，不愿反复带新人 | 初级工程师更难获得真实任务和反馈 |
| 平台依赖加深 | 模型访问、价格和服务区域由供应商决定 | 涨价、断供、政策限制都可能打断工作流 |
Local-First Conf 和 Pi.dev 都只能算个案，不能外推成整个开发者社区的共识。自动关闭多数外部提交，也未必适合所有项目。小型核心团队、攻击面较大的项目，和依赖社区贡献的大型开源项目，承受能力完全不同。
但这些个案指向了同一个问题：生成端的成本下降后，审核端的成本没有一起下降。
一份 PR 过去至少暗示着贡献者读过代码、理解过问题、愿意花时间修改。这个信号本来就不完美，现在更弱了。模型可以快速补齐代码、测试说明和礼貌措辞，维护者却仍要逐行确认安全性、兼容性和维护成本。
表面上，代码供应增加了。真正稀缺的工程判断没有增加。
Pi.dev 的做法因此可以理解。维护者不是天然排斥外部贡献，而是在保护有限的注意力。但自动关门也会误伤真正愿意投入的新人。社区若长期只剩熟人提交，开源项目会更高效，也会更封闭。
这笔账不能只算今天省下了多少审核时间，还要算两年后还有没有新维护者接班。
生成成本接近零，旧的信誉信号开始失灵
电子邮件普及后，发送一封信的成本大幅下降，垃圾邮件随之泛滥。邮箱系统没有因此放弃通信，而是补上过滤、信誉评分、限流和身份验证。
LLM 带来的变化有些相似，但不完全一样。垃圾邮件主要争夺注意力，垃圾代码还会进入依赖链、生产环境和长期维护清单。一次草率合并，可能让整个团队几年都在还债。
技术社区过去用提交记录、讨论质量、代码风格和持续参与来判断一个人是否可靠。LLM 可以模仿其中很多表面特征，却不能承担后果。
这也是作者提出的那条信誉测试为什么有价值：一个人是否愿意把提交内容逐字公开朗读，并为结果背书？
它不必真的变成每个项目的仪式。它检验的是更朴素的东西：
- 贡献者能否解释每一处关键改动；
- 能否说明哪些内容由模型生成；
- 测试失败或线上出事时，谁负责修；
- 三个月后，是否还愿意维护这段代码。
机器能代劳生成，不能代替责任。
我不太买账的是，把“用了 AI”直接等同于“没有投入”。熟练工程师也可能借助模型快速完成严肃工作，手写代码同样可能敷衍。真正该被审查的是理解深度、验证过程和后续承诺，而不是输入方式。
因此，简单禁止 AI 贡献并不高明。它很难执行，还会把使用行为赶到地下。更有效的办法，是把责任要求写进贡献流程。
工具可以放开，责任必须钉牢
如果你正在带软件团队，近万美元的 token 账单不该让你兴奋，也不该让你恐慌。先把它放回正常的工程核算里。
| 对象 | 更现实的动作 | 不该拿什么自我安慰 |
|---|---|---|
| 技术负责人 | 单列模型费用，跟踪交付周期、返工量、缺陷逃逸和审查时间 | token 用得多，不等于生产力高 |
| 软件工程师 | 标注模型参与范围，保留关键提示、测试依据和人工修改记录 | 代码能运行，不等于自己理解了 |
| 开源维护者 | 要求先说明问题，再提交小范围 PR；新贡献者限流，关键改动必须讲解 | 自动生成了测试，不等于测试覆盖了风险 |
| 社区组织者 | 给新人保留人工反馈和低风险任务，不让模型吃掉全部学徒环节 | 短期合并更快，不等于人才培养更有效 |
维护者还可以把贡献规则写得更具体：是否允许 AI 生成代码，是否必须披露，哪些目录禁止自动提交，安全相关改动需要谁复核。规则越清楚，越不必靠猜疑维持秩序。
技术负责人则要补一笔常被忽略的账：资深工程师用模型节省了时间，这些时间去了哪里？
如果只是多接任务，团队可能得到短期产出。如果节省下来的时间用于架构、审查和带新人，模型才可能改善组织能力。若资深员工从此不再解释问题、不再培养初级工程师，企业省下的是今天的工时，透支的是明天的人才梯队。
作者支持本地运行和开放权重模型，这个方向有现实价值。它能降低单一厂商涨价、停止服务或限制地区访问带来的风险，也让团队更容易保留模型和数据控制权。
但开放权重不等于完全自主。
模型仍需要硬件、部署能力、推理优化和维护预算。许可证也可能限制商用范围。能把权重下载回来，不代表运行成本低，更不代表输出质量可靠。它解决的是一部分可用性和供应风险，无法自动修复开源社区的质量与信任问题。
接下来真正该看的，不是哪家模型又提高了几分榜单成绩，而是项目和团队会不会建立新的信誉机制：贡献披露能否执行，生成代码由谁长期维护，AI 预算能否换来可测量的工程收益，新人是否还能获得真实训练。
“天下熙熙，皆为利来。”模型厂商卖 token，团队买效率，贡献者买速度，维护者却在支付审核成本。谁生成，谁解释；谁合并，谁负责。少了这两条，再强的模型也只会让噪声跑得更快。