本期涵盖 3 月 21 日至 3 月 23 日的资讯。
Rust 社区开始正面讨论 AI 的边界
来源：https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html
Rust 项目里围绕 AI 的分歧，这次被摊开讲了。Niko Matsakis 汇总了社区成员的长篇讨论，明确说这不是 Rust 官方立场，而是一份把不同声音并排摆出来的记录。文件里既有支持者，也有明显保留态度的人。支持者的共同点不是「AI 已经无所不能」，而是强调它已经进入一个不能假装看不见的阶段，尤其在代码检索、文档搜索、review 辅助、半结构化数据处理这些环节，已经开始产生稳定价值。
这份总结里比较有意思的一点，是它没有把争论简化成「会用」和「不会用」两派。很多发言其实都指向同一个现实：AI 结果好不好，很大程度取决于使用方式。上下文怎么给，问题怎么拆，工具怎么接，边界怎么设，这些都在影响结果。也正因为如此，社区里会同时出现「已经很好用」和「基本没法用」两种几乎相反的体验。
更敏感的部分是治理问题。有人担心项目会被低质量 AI 生成内容淹没，也有人担心 Rust 生态如果完全抗拒，会错过新一代开发流程。把这种讨论公开化，本身就说明一件事：AI 已经不是边角话题，而是会影响项目文化、贡献门槛和维护成本的核心变量。
我的看法是，这篇总结最重要的地方，不在于它给出了答案，而在于 Rust 这种工程气质很重的社区，开始认真把问题拆细。现在最怕的不是支持或者反对，而是继续用情绪化口号代替判断。Rust 这次的做法更像一次压力测试：先把真实顾虑讲透，再谈规则。
如果后面 Rust 真形成一套公开的 AI 使用边界，它对整个开源圈都会有示范意义。很多项目其实也在经历同样的事，只是还没把话说得这么明白。
用 Git 管住 coding agent，开始变成基本功
来源：https://simonwillison.net/guides/agentic-engineering-patterns/using-git-with-coding-agents/
Simon Willison 新增了一篇 agentic engineering 指南，主题很直接：别把 Git 只当成代码仓库，要把它当成控制 coding agent 的主界面。文章把一套非常实用的提示词和工作流摆得很清楚，比如让 agent 先看最近提交、随手 commit、从 main 合并最新改动、用 reflog 找回丢失代码、用 git bisect 定位 bug。
这篇文章的重点，不是教人背 Git 命令，而是提醒大家换个脑子：既然 agent 天生会用 Git，那人类就应该把版本控制设计成一个约束系统。commit、branch、stash、rebase 这些过去让很多人头疼的东西，现在反而成了管理 agent 风险的最好办法。
这类文章价值很高，因为它不是在讨论模型参数，而是在补「人怎么跟 agent 协作」这一层的操作系统。接下来团队之间拉开差距，未必只是模型谁更强，更多可能是谁先把 Git、测试和 review 流程改造成适合 agent 的形状。
一个人把 Claude 训练成移动端 QA 工程师
来源：https://christophermeiklejohn.com/ai/zabriskie/development/android/ios/2026/03/22/teaching-claude-to-qa-a-mobile-app.html
Christopher Meiklejohn 写了一篇很扎实的实战记录：他一个人维护 Zabriskie 这款应用，需要同时覆盖 Web、iOS 和 Android，但移动端一直没有自动化 QA。为了解决这个空白，他把 Claude 接进自己的测试流程，让它驱动 Android 和 iOS 客户端、批量截图、识别视觉问题，然后自动提交 bug。
文章里最有价值的是细节。Android 这边，他借助 adb reverse 解决本地联通问题，再通过 Android WebView 暴露出来的 Chrome DevTools Protocol 直接控制应用，90 分钟就把整套流程打通。iOS 则麻烦得多，折腾了 6 个多小时，恰好反衬出 2026 年两边自动化工具链成熟度的差距。
更关键的是，这不是炫技 demo。作者已经把它变成每天早上定时跑的任务，扫 25 个页面，发现问题就自动发到生产环境的 bug 论坛。也就是说，agent 在这里不是写代码，而是在补一个独立开发者最缺的人力岗位。
这件事让我在意的地方，是 AI 开始吃掉一些原本很难外包、也很难长期坚持的人肉流程。移动端 QA 以前常常因为太碎、太烦、ROI 不明显，被小团队一路拖着不做。现在只要能把环境接通，agent 就有机会把这些灰活接过去。
Bram Cohen 想重写版本控制这件老事
来源：https://bramcohen.com/p/manyana
BitTorrent 作者 Bram Cohen 发布了 Manyana，一个还很早期的版本控制实验项目。他想解决的不是「Git 再快一点」这种小修小补，而是从底层改掉传统版本控制里最恼人的合并体验。Manyana 的核心思路是把 CRDT 用到版本控制里，让 merge 在定义上永远成功，冲突不再表现成阻塞流程的失败状态，而是变成一种可以被标注、解释和审查的信息层。
他给的例子很直观：同一段函数，一边删除，一边在中间插入新代码，Git 往往只会甩给你两团难读的冲突块。Manyana 想展示的是「左边删了什么，右边改了什么」，把冲突从结果对撞，变成操作历史的可视化。另一个有意思的点，是他认为 rebase 不应该靠伪造历史换来整洁，而应该在保留完整历史的前提下得到类似效果。
这东西现在还只是 demo，离真正可替代 Git 还早得很。但它踩中的问题是真问题。agent 时代代码 churn 暴涨，分支更多，提交更碎，也更容易把现有的 review 和 merge 流程压垮。过去很多人觉得 Git 难用但还能忍，现在这个「还能忍」的前提正在松动。
我的看法是，Manyana 值得关注，不是因为它短期会取代 Git，而是因为它逼大家重新想：版本控制到底是在管理文件，还是在管理并行意图。只要 agent 继续扩大改动规模，后一个问题迟早躲不过去。
让模型读完 1000 条评论，再反向画像一个人
来源：https://simonwillison.net/2026/Mar/21/profiling-hacker-news-users/
Simon Willison 分享了一个有点不舒服、但很能说明问题的实验：把某个 Hacker News 用户最近 1000 条评论丢给模型，再让模型写人物画像。数据来源并不神秘，直接调用 Algolia 的 Hacker News API 就能拿到，甚至还能在浏览器里做成一键复制的小工具。Simon 的结论很直接：效果好得吓人。
他给自己做了一次示范，模型不仅能概括公开身份、技术兴趣、争论风格，连长期关注的话题、表达习惯和一些生活侧面都能拼出来。读完以后，最明显的感受不是「模型真聪明」，而是公开语料一旦够多，个人画像其实已经接近低成本自动化。
这篇文章没有故作惊悚，它反而因为写得克制更值得看。Simon 一边展示效果，一边承认这种能力有明显的侵犯感。问题不在于技术上能不能做，而在于社会默认还没跟上：很多人知道自己在公开发言，却未必真的意识到这些碎片已经足够让模型拼出一个相当完整的人。
接下来这类能力大概率会先渗进招聘、风控、销售和内容平台。真正需要补课的，不只是模型安全，还有公众对「公开数据可被重新组合」这件事的心理预期。