Codeberg 新规引发争议：AI 代码与开源基础设施的中立性困境
Flask 作者 Armin Ronacher 评论 Codeberg 新规禁止主要使用生成式 AI 编写的开源项目。他认为虽然 Codeberg 有权这样做，但模糊的“大部分”定义执行困难，且民主决策不等于基础设施所需的可预测性与中立性。文章指出开源社区在 LLM 问题上的分裂令人遗憾，呼吁社区思考如何与未来协作，而非简单排斥。
Armin Ronacher
Armin Ronacher 关于 Python、Rust、编程语言设计、开源与 Web 开发的博客。Flask 框架作者。
评论
点赞
收藏巴别塔持续增高：AI代理如何消解软件协作的共同语言
我总觉得，有些经过振动编码的软件会以某种随机且出人意料的方式发生改变。 这让我开始思考布鲁盖尔的《巴别塔》——这幅画作生动地描绘了 一座本已相当混乱的巴别塔。故事通常被讲述为一则关于骄傲与野心的故事，以及最终为何人们不再说同一种语言的寓言。然而，它同样也是一个关于团结协作、推动技术进步的故事。 文本开篇便提及了一项技术升级： 他们彼此说道：“来吧，我们造砖，把它们烧得透彻。”于是，他们用砖块当...
更好的模型，更差的工具调用表现
最近两天，一个非常奇怪的Pi 问题 把我引向了迷宫般的境地。简而言之，最新的 Claude 模型有时会在嵌套的 edits[] 数组中，额外添加一些虚构的字段，然后调用 Pi 的编辑工具。而且，这可不是 Haiku 或其他小型模型——而是 Opus 4.8。编辑本身通常没有问题，但参数与 Schema 并不匹配：模型自创了一些虚构的键值，因此 Pi 拒绝接受该工具调用，并要求重新尝试。 仅凭这...
即将到来的循环时代：当 AI 接管编程工作流
我再也不会主动“催促”克劳德了。我早已编写好了循环，不断向克劳德提出问题，并在其中摸索该如何应对。我的工作，就是编写这些循环。 ——鲍里斯·切尔尼 在过去几个月里，我目睹越来越多的人在编码代理的基础上构建出一些全新的成果， 这些成果与单纯使用编码代理相比，有着截然不同的意义和价值。 其中一些成果甚至建立在 Pi 之上——看到这样的进展，无疑令人倍感欣喜！ 不过，无论在何处，其运作模式都大同小异...
仅限美国人的危险技术：从Anthropic出口管制看AI地缘政治与欧洲困境
作者结合Anthropic因美国出口管制限制外国人访问其最新模型的事件，深入分析了AI技术日益成为地缘政治和国家安全工具的趋势。文章批评了以美国为首的“技术民族主义”和排他性安全观，指出这不仅是安全问题，更是种族主义和民族主义的体现。作者进一步反思了欧洲在科技生态、资本市场和监管上的结构性弱点，呼吁欧洲停止盲目依赖或单纯模仿美国，而是通过加强内部团结、开放源代码和国际合作来重建自主性，避免世界陷入分裂对抗。
对开放性的煤气灯操纵
Flask作者Armin Ronacher撰文批评科技巨头利用安全和隐私叙事限制开源与数据访问，指出Anthropic和Apple在DMA监管压力下以“保护用户”为名行封闭之实，呼吁重视技术民主化并警惕叙事操纵。
Clanker：为机器而造的一个词
在上一篇帖子中，我曾相当频繁地使用“clanker1”一词，作为“agent”的一种替代用法——而且很可能用得有些过度。 没想到，这一选择在那篇帖子的Hacker News评论区引起了比预期更多关注，不少网友对此反应强烈：在他们看来，这听起来像是带有贬义的辱骂用语， 甚至在某些情况下，还与那个“n字”词汇有直接关联。 这种反应多少让我感到意外，但也让我意识到，自己应该把“clanker”这个词的...
用Pi构建Pi：关于AI辅助开源开发的思考
本文作者反思使用Pi构建Pi时的经历，重点探讨了AI在问题跟踪器中生成的问题带来的挑战。文章指出，AI经常错误诊断问题，并提出了一种简洁的问题格式，强调人类观察的重要性。作者还讨论了AI生成的代码如何增加不必要的复杂性，并呼吁开源社区加强协作而非孤立工作，以应对AI时代带来的新压力。
内容的意义：LLM泛滥及其对社会的冲击
本文探讨了大型语言模型（LLM）对语言使用、讨论质量和社会互动的影响，重点关注AI生成内容如何侵蚀信任和人类沟通。作者通过个人观察和数据分析，指出LLM不仅改变了词汇选择，还影响了文本结构和写作风格，导致许多人开始模仿AI的写作方式。文章还讨论了社交媒体和内容创作领域因LLM而出现的低效内容和自动化互动现象，以及这些现象对社会信任和真实人际交流的负面影响。最后，作者提出了应对建议，包括提高透明度、限制社交互动速率、增加平台上的摩擦机制等，以缓解这一问题。
以专注与打磨推动本地模型发展
I really, really want local models to work. I want them to work in the very practical sense that I can open my coding agent, pick a local model, and get something that feels competitive enough that I...
为欧洲人解析“equity”：跨文化理解所有权与公平的概念
If you spend enough time in US business or finance conversations, one word keeps showing up: equity. Coming from a German-speaking, central European background, I found it surprisingly hard to fully ...
自己动手：远离 Rust 生态中的依赖项更新循环
本文作者对 Rust 生态中依赖项频繁更新的问题进行了批判，提倡一种“自己动手编写代码”的新风气。文章通过 terminal-size 等例子，说明了过多依赖项带来的编译时间增加和安全风险等问题。作者认为，虽然使用依赖项可以提高开发效率，但过度依赖会导致维护负担加重，甚至可能成为安全问题的根源。文章呼吁开发者应重视编写简单、稳定的代码，减少不必要的依赖，以降低维护成本和提升安全性。
我不觉得异步压力有多大[2020]
本文深入探讨了异步编程中的背压（back pressure）管理问题，指出异步系统因缺乏流量控制机制可能导致严重过载。作者以Python的asyncio为例，结合机场行李分拣系统的真实故障案例，说明背压机制如何避免系统崩溃。文章还对比了线程与异步编程在资源限制处理上的差异，并提出了通过服务抽象层实现动态负载反馈的方案，最后呼吁开发者重视流控设计，避免“脚踩火坑”式的技术债务。内容包含大量技术细节、架构反思和实用建议，适合对高并发系统设计感兴趣的开发者。
马里奥与Earendil
Today I’m very happy to share that Mario Zechner is joining Earendil. First things first: I think you should read Mario’s post. This is his news more than it is ours, and he tells his side of it bett...
Absurd 在生产环境中的表现：一个完全基于 Postgres 的持久执行系统
About five months ago I wrote about Absurd (/2025/11/3/absurd-workflows/), a durable execution system we built for our own use at Earendil, sitting entirely on top of Postgres and Postgres alone. The ...
微依赖与开源信任扩展
本文深入探讨了Node.js生态中微依赖（micro-dependencies）带来的信任与安全问题。作者以Python和npm的对比为例，指出npm依赖爆炸导致的安全隐患：一是依赖数量庞大且难以审计，二是每个依赖都带来潜在风险；三是签名认证无法解决信任问题，需从生态机制层面改进。文章通过具体案例（如isarray包被下载1800万次但仅两人关注），揭示小代码包因低关注度易成为攻击目标，并强调版本锁定策略的漏洞。最后呼吁npm需引入自动化分析、CC0许可证等改革措施，否则可能引发严重安全危机。
Pi：OpenClaw 中的最小代理
本文介绍了作者钟爱的极简编码代理 Pi，由 Mario Zechner 开发。Pi 拥有极小的核心和扩展系统，允许扩展在会话中持久化状态，非常可靠。文章详细阐述了 Pi 的设计哲学、功能特点以及如何在构建代理时利用其灵活性和扩展性，并展示了多个实用扩展示例，如 /answer、/todos、/review 等，强调了 Pi 在构建软件方面的强大能力和潜力。
人工智能与忒修斯之船：代码重实现及其后果
本文探讨了随着AI和测试套件的发展，代码可以被以不同方式重新实现的现象。文章通过chardet库的实例，展示了从LGPL到MIT许可证的重新实现引发的版权争议。作者讨论了开源许可证（如GPL）面临的挑战，以及AI生成代码可能带来的法律和社会影响。文章还提出了关于软件未来走向的思考，包括专有软件是否可能重新以开源形式出现等问题。作者认为，这一现象不仅涉及技术层面，更触及了知识产权、道德和法律等多个领域，是一个值得深入探讨的新议题。
最终瓶颈：如何跟上我们自己创造的速度
本文探讨了软件开发和开源项目在速度激增后面临的不可持续瓶颈问题。作者通过纺织业和工业革命的类比，指出当某个环节加速时，下游环节会成为新的瓶颈。当前代码审查和合并的积压问题日益严重，自动化无法完全解决人类理解与责任承担的问题。文章质疑机器无法真正承担责任，并呼吁为新型工程实践创造必要条件。作者认为，尽管技术进步带来了前所未有的交付速度，但人类仍需对产出负责，否则将面临类似历史上的卢德运动困境。 
LLM API 是状态同步问题
本文深入探讨了大型语言模型（LLM）API 背后的分布式状态同步问题。作者指出，尽管核心模型仅处理 token，但云端 API 引入了复杂的隐藏上下文（如角色标记、工具定义等），导致客户端与服务端状态难以同步。Completion API 因每次重传完整历史而效率低下，Responses API 虽尝试保存服务端状态，却面临同步模糊性和潜在故障风险。文章呼吁借鉴本地优先（local-first）技术中的冲突解决机制，将 KV 缓存视为派生状态，并设计支持增量同步、容错的标准 API，而非拘泥于现有消息式抽象。最终强调，未来 API 应基于模型真实行为，而非历史惯例，以解决状态同步这一根本挑战。