Coding After Coders：AI 辅助编程正在把开发者分成两派
来源：https://simonwillison.net/2026/Mar/12/coding-after-coders/
Clive Thompson 这篇长文把软件行业眼下最真实的分裂写出来了：一派把 AI 当放大器，另一派还是把手写代码当成这份工作的核心乐趣和价值。Simon 说程序员某种意义上算幸运，因为代码至少还能跑测试、能验真假。跟法律、咨询这些行业比，AI 在编程里的落地条件确实更成熟一些。
真正让人在意的，不是「AI 会不会写代码」，而是公司内部会不会把这件事迅速变成一种默认立场，让不想 fully embrace agent 的人越来越难开口。
我的看法：编程不会消失，但编程的重心确实在上移。以后拼的可能不是谁敲得快，而是谁更会设边界、写约束、搭验证。
Anthropic：用一组并行 Claude 造一个 C 编译器
来源：https://www.anthropic.com/engineering/building-a-c-compiler-with-a-team-of-parallel-claudes
Anthropic 这次拿出来的不是那种轻巧 demo，而是直接上编译器这种系统级任务，难度和说服力都高很多。关键不只是「Claude 能不能写出来」，而是任务怎么拆、harness 怎么搭、多个 agent 的结果怎么收束成可验证产物。
这基本说明一件事：agent 工程已经不再是「和模型聊得好不好」，而是「编排、约束、回收、验证」这一整套工程能力。
我的看法：这类文章最有价值的地方，在于它不空谈愿景，直接把真正难的部分摊开来讲。agent 的瓶颈越来越像系统工程问题，而不是单纯的模型问题。
OpenAI 发布 IH-Challenge：专门训练模型处理指令层级冲突
来源：https://arxiv.org/abs/2603.10521
这篇论文盯住的是 instruction hierarchy，也就是 system、developer、user、tool 指令冲突时，模型到底该听谁的。按作者的说法，引入在线对抗样本后，模型在 16 个基准上的稳健性平均提升了 10 个百分点，同时把不安全行为压下去不少。
更关键的是，数据集公开了。这样一来，prompt injection 和 agent 安全至少有机会从闭门做题，变成能共享、能复现、能比较的工作。
我的看法：如果说 2025 年大家还在聊 agent 有多酷，那 2026 年真正卡住落地的，很可能就是 instruction hierarchy。OpenAI 把数据集公开出来，是个不小的信号。
Understudy：演示一次任务，就把桌面操作教给 agent
来源：https://news.ycombinator.com/item?id=47353957
Understudy 想做的是一个跨桌面应用、浏览器、终端的本地 agent，但卖点不是自动点点点，而是「你做一次，它学一次」。它记录的不是死板坐标，更像是语义化任务步骤，所以理论上会比传统 macro 稳，也更容易复用。
项目还早，不过这个方向挺关键：GUI agent 不能永远停留在「看图点击」，迟早得走向 demonstration、memory 和任务抽象。
我的看法：值得盯着看的信号项目。真有前景的 desktop agent，多半不会只靠 vision model，而是会把示范学习、记忆和 fallback route 绑在一起。
Axe：一个 12 MB 的 agent 运行时，想把 AI 框架做成 Unix 工具
来源：https://github.com/jrswab/axe
Axe 的思路很直白：别再把 agent 做成大而全的聊天系统了，干脆做成可以用 stdin / stdout 串起来的小工具。它支持 sub-agent delegation、memory、MCP 和多模型，但强调的是组合性，而不是一个永远在线、上下文无限膨胀的大脑。
这种味道其实很工程师：更像 shell 工具链，而不是又一个重 UI、强控制感的平台。
我的看法：如果这条路跑通，AI tooling 会越来越像「可脚本化基础设施」，不太像「AI IDE 一统天下」。对很多工程团队来说，这反而更实用。
Wayfair 把 OpenAI 用进商品目录和客服流程
来源：https://openai.com/index/wayfair
Wayfair 这不是新模型发布，但案例很典型：拿模型去做工单分流、客服辅助、商品属性修正，目标都很务实。这也再次说明，电商里最先被 AI 吃下来的，往往不是前台花活，而是目录治理、数据清洗和 support workflow。
从 ROI 的角度看，这类事情通常比「做一个很聪明的聊天框」更容易长期成立。
我的看法：企业 AI 真正的主战场还是流程层和数据层，不是表面的 chatbot 体验。后者容易出彩，前者才更容易留下来。
Google AI 在澳大利亚偏远地区做心脏健康筛查
来源：https://blog.google/innovation-and-ai/technology/health/google-ai-heart-health-australia/
Google 把 AI 放进偏远地区的心脏健康筛查场景，本质上是在医疗资源稀缺的地方做早期识别和转诊支持。这种项目的价值从来不只是模型参数有多强，而是能不能嵌进真实的公共卫生流程。
如果落地够稳，AI 在医疗里的叙事可能会慢慢从「辅助医生」转向「扩大基础覆盖能力」。
我的看法：这种项目最难的往往不是模型，而是责任边界、误报漏报的代价，以及它怎么和本地医疗体系协同。最后能不能推广，还是系统工程说了算。
Simon Willison：Claude 做交互式排序算法演示
来源：https://simonwillison.net/2026/Mar/11/sorting-algorithms/
Simon 用 Claude Artifacts 在手机上直接做了排序算法演示，还一路把需求加到 Timsort 和多算法同时运行。有意思的其实不是排序算法本身，而是这种「边想边做、边改边试」的互动式原型能力，已经越来越顺手了。
他还顺手让 GPT-5.4 Thinking 去 review Claude 的实现。多模型协同这件事，现在真的开始像日常工作流，而不是表演项目。
我的看法：这种小例子反而最说明问题。AI coding 真正改变的，不是某个宏大口号，而是原型速度和试错成本在被持续压低。
Steve Yegge 谈从 IDE 到 AI Agents 的迁移
来源：https://newsletter.pragmaticengineer.com/p/from-ides-to-ai-agents-with-steve
Steve Yegge 的判断很鲜明：软件工程正在从「人用 IDE 写代码」往「人指挥 agent 产出代码」迁移。这会改写开发者的能力结构。经验、判断、任务拆解和质量控制，可能会比语法熟练度更值钱。
但这不等于低门槛万岁。恰恰相反，越往 agent 走，越考验你对系统边界和失败模式的理解。
我的看法：这类判断这两年听得很多，但 Steve 的好处在于，他总能把趋势翻译成工程语境，不容易飘。
ByteByteGo：Stateless architecture 的收益和代价
来源：https://blog.bytebytego.com/p/stateless-architecture-benefits-and
文章把 stateless 架构为什么更容易扩缩容、做负载均衡和故障恢复梳理得很清楚。但它也提醒了一个老问题：状态并没有消失，只是被你转移到了数据库、缓存或者消息系统里。
真正成熟的系统设计，不是迷信 stateless，而是清楚哪些状态该放哪里，以及谁来为这些状态负责。
我的看法：这篇不算特别新，但很适合工程团队拿来复盘架构决策。别为了「看起来现代」就把复杂性悄悄转嫁出去。