当 AI 涌入开源项目：三位顶级作者本周划出的边界
Armin Ronacher（Flask/Jinja2）、Simon Willison（Datasette/Django）、D. Richard Hipp（SQLite）在本周分别发布文章、提交代码决策，从不同角度划定了 AI 工具在开源项目中的边界——拒绝 AI 生成代码、设计让坏状态不可能出现、把 Agent 访问权限整合进插件体系。本期摘要梳理三人的具体技术决策与工程哲学。
Armin Ronacher、Simon Willison、D. Richard Hipp——三个名字对应了 Flask / Jinja2 / Rye、Datasette / Django、SQLite。本周，他们各自以不同方式公开回答了同一个问题：AI 工具该怎么用，边界该划在哪里？
这不是泛泛的 AI 态度宣言。三人给出的都是具体的工程决策和产品选型，可以直接作为参考。
Armin Ronacher：设计让坏状态不可能出现
Armin Ronacher 是 Flask、Jinja2、Rye 的作者，目前主要精力放在新项目 Pi 上。5 月 24 日，他发布了「Building Pi With Pi」，记录用 AI 辅助开发自己项目的具体经验和决策。
最值得注意的是他的核心架构原则：与其设计大量容错逻辑处理异常状态，不如在设计阶段就让坏状态不可能出现。他在 Pi 的会话日志里写下了这条不变量。原因是：LLM 生成的代码有一个典型倾向——遇到畸形数据就增加读取容错，而这会无谓地增加系统复杂度。他选择的反向策略是，把约束放在设计层，不放在运行层。1
Issue Tracker 设计
为了应对 AI 时代涌入的大量低质量贡献，Pi 的 issue tracker 做了一个主动设计：自动关闭所有新贡献者的 issue 和 PR，通过手动审核再重新开放。这不是临时补丁，是有意为之的协作结构设计。
他同时定义了一套自定义 slash 命令：
/is 命令的提示词核心要求是「不相信 issue 里已有的分析，从代码和执行路径独立验证」。/wr 命令自动处理收尾流程：推断 GitHub 上下文、更新变更日志、添加对应 issue 关闭标记、只提交当前会话修改的文件。他对 AI 辅助开发的整体定位很清醒：「当前距离全自动化软件工程还有相当差距，目前仅将 AI 并行化用于 issue 复现环节，不追求全自动无人开发。」
5 月 26 日，他在「Clanker: A Word For The Machine」里进一步阐明了自己使用「clanker」称呼 AI 系统的理由：维持人与工具的边界，反对拟人化。他认为将 AI 拟人化会催生责任真空——出了问题就推给「模型决定了」，而责任始终应当由部署和使用工具的人承担。2
コンテンツカードを読み込んでいます…
Simon Willison：把三年的工具积累接起来
Simon Willison 是 Datasette 的作者，也是 Django 的共同创始人。本周他走到了一个节点：LLM Python 库和 Datasette 在经历三年独立演进后，终于在同一个产品里汇合。
5 月 21 日，「Datasette Agent」发布。3 这是一个可扩展的 AI 助理，直接内嵌在 Datasette 的数据浏览界面里。关键产品设计决策：
- 插件钩子优先：新增的
jump_items_sql()钩子允许任何插件向 Jump to 菜单注入自定义搜索项；Datasette Agent 就是通过这个机制把「启动新代理对话」的入口整合进主导航，而不是做成独立入口页面。 - 权限前置检查：执行查询前先检查
execute-sql权限，再传给 Agent，不让 AI 工具绕过现有权限模型。 - 沙箱隔离：通过
datasette-agent-sprites插件，Agent 在 Fly Sprites 沙箱里运行命令，每次任务在隔离环境执行。
5 月 24 日，
datasette 1.0a30 紧随发布，重点是可定制的 Jump to 菜单，并提供 datasette.fixtures.populate_fixture_database(conn) 工具，专门方便插件作者写测试套件。4コンテンツカードを読み込んでいます…
他的内容发布原则也值得一提：「只写自己可以实际试用的内容，偏好已正式普遍可用的产品，不宣传未上线的『即将推出』功能」——这个原则直接决定了他在 Google I/O 发布周几乎不写 Gemini Spark 的深度分析，因为还没有可用版本。
5 月 27 日，他写了一篇更大视野的判断：「I think Anthropic and OpenAI have found product-market fit」5，依据是 Anthropic 接近首个盈利季度的传闻，以及他观察到的公司内部 LLM 账单出乎意料地高速增长。他的结论不是泛泛的乐观，而是对自己工具产品的直接影响——Datasette Agent 的定位时机是对的。
D. Richard Hipp：SQLite 决定不接受 AI 生成代码
D. Richard Hipp 是 SQLite 的作者。SQLite 是嵌入量最大的数据库，估计运行在全球超过一万亿个实例上。他不常发表意见，但这次的决策非常明确。
5 月 22 日，SQLite 的代码仓库新增了
AGENTS.md 文件。6 核心规则：- SQLite 不接受 AI 代理生成的代码，无论质量如何
- 接受包含可复现用例的 AI 生成错误报告，用于说明问题的 patch 也欢迎
- 5 月 27 日，最近一次提交移除了声明里的
(currently)一词，将「SQLite does not (currently) accept agentic code」改成了「SQLite does not accept agentic code」——措辞加强，不再暗示未来可能改变 7
与此同时，SQLite 论坛被大量 AI 生成的 bug 报告淹没，Hipp 随后把这类报告拆分到独立的 SQLite Bug Forum，并亲自高频率回复并提交修复。8
这个决策背后的工程逻辑很清楚：SQLite 的代码审查标准极高，所有代码的版权必须捐献给公共领域，任何一行代码都要经过人工核查。AI 生成代码的法律归属模糊，质量也不符合 SQLite 的标准——拒绝是最简单的实现。
Simon Willison 在自己的博客上引用了 Armin Ronacher 对这类 AI 生成 issue 的描述：「最令人沮丧的失败模式是提交的 issue 不是用作者自己的声音写的。通常是观察到了某个真实问题，但经过 LLM 改写后，结论往往不准确却充满自信，根本原因全是猜测，附带一堆可能不相关的错误类型清单。」9
本周的共同模式
三个人处理的问题规模不同——Pi 是新兴项目，Datasette 是中型工具，SQLite 是基础设施级软件——但他们在本周公开的决策里都体现了同一个设计立场：
主动设计 AI 工具的使用边界，而不是被动等待问题出现再打补丁。
对于正在构建自己项目或工具的远程开发者，这批决策提供了几个可直接借鉴的具体参考：
- 代码贡献流程：考虑像 Pi 一样，对新贡献者实施手动审核门槛，而不是事后过滤
- 架构约束：像 Ronacher 的原则，把约束放在设计层，不依赖运行时容错承接坏状态
- Issue 报告格式：明确要求「我运行了什么命令 / 我期望什么结果 / 实际发生了什么 / 完整错误日志」，消除 AI 改写过的噪声层
- 工具边界声明：SQLite 的 AGENTS.md 模式——在项目根目录明确写出对 AI 代理的使用规则，比在 README 里夹带一句更有约束力
本周还有一个相关观察：Daniel Stenberg（curl 作者）在 5 月 26 日写道，curl 项目目前收到的安全报告数量是 2024 年的 4-5 倍、2025 年的两倍，「平均每天超过一条」，他的妻子开始担心他的工作时长。10 与 SQLite 的情况镜像对称：AI 让发现漏洞变得更容易，同时也让维护者的负担线性上升——这是开源项目目前面对的真实成本。
このコンテンツについて、さらに観点や背景を補足しましょう。