web-edit 0.1a1 发布：AI 接力优化性能的实践样本

Simon Willison 发布了 web-edit 0.1a1，一个看似简单的版本号更新，背后却藏着一个颇具标本意义的 AI 工作流。

一个版本号背后的分工链条

这次发布的核心内容只有一句话：包含性能优化。但真正有趣的是这些优化的产生方式——它们由 Claude Opus 5.5 编写，而 Claude 接收的输入，是一份由 GPT-6 Astra 生成、针对 Python 3.15 的 profiling 报告。

也就是说，从性能瓶颈定位到代码改写，两个不同厂商的模型各司其职：一个负责「诊断」，一个负责「开方」。人类开发者 Simon Willison 在这条链路中的角色，是把诊断报告作为上下文喂给第二个模型，然后审阅、合并并发布结果。

Profiling（性能剖析） 是指通过运行时采样或插桩，测量程序各部分的执行时间、调用次数与资源消耗，从而定位性能瓶颈的技术手段。常见工具包括 Python 的 cProfile、py-spy，以及各类采样型 profiler。profiling 报告通常包含调用栈、累计耗时（cumtime）、自身耗时（tottime）等结构化数据。它的价值在于把「程序慢」这种模糊感受，转化为「哪一行代码、哪个函数被调用了多少次、占总耗时多少」的可量化事实。正因为它高度结构化，才适合作为机器可读的中间产物在不同工具或模型之间传递。

两个模型接力，各自擅长什么

这条链条值得拆开看。Profiling 报告本质上是数据密集型的——它需要从大量调用栈、耗时分布中找出真正值得优化的热点，并且给出可读的结论。这恰好是 GPT-6 Astra 在这类任务中被选择的原因：处理结构化性能数据、生成人类可读的分析。

而 Claude Opus 5.5 拿到这份已经结构化的结论后，做的是代码层面的改写。它不需要重新做一遍性能分析，只需要理解「哪里慢、为什么慢」，然后写出对应的优化实现。据 PR #1 的信息，这部分工作直接以 pull request 的形式提交，说明输出是可审查、可合并的工程产物，而不是一段需要人工搬运的代码片段。

Pull Request（PR） 是 Git 协作平台（如 GitHub）上提出代码变更的标准机制：开发者在一个独立分支上修改代码，然后发起 PR，请求将其合并进主分支。PR 附带 diff（逐行差异）、提交历史与讨论区，使变更可以被逐行审阅、评论、要求修改，最后才合并。它之所以重要，是因为 PR 是一种「可审查的工程产物」——无论改动由人还是模型生成，都必须经过同样的审阅流程才能进入主干。当 AI 直接以 PR 形式提交优化时，意味着它的输出被纳入了既有的代码评审与版本控制体系，而非游离在流程之外。

为什么这件事值得关注

单个 AI 写代码早已不新鲜。真正有信息量的是：这条链路把「模型能力」变成了「模型协作能力」。

过去我们讨论 AI 编程，默认场景是一个模型 + 一个开发者。而这里出现的是一个更接近真实工程团队的分工：分析角色和执行角色分离，中间用结构化文档（profiling 报告）作为交接协议。文档本身不是给人看的，而是给下一个模型看的——它承担了上下文传递的功能。

这带来一个可复用的模式：当你有一个擅长分析的工具和一个擅长执行的工具时，不必强求用同一个模型做完所有事。把前者的输出格式化为后者的输入，反而可能得到更稳定的结果，因为每一步的任务边界都很清晰。

多模型协作（multi-model orchestration） 指的是让不同模型在一条流水线中各承担擅长的环节，而非用单一模型端到端完成任务。其典型形态是「分析者—执行者」分离：前者处理数据密集、需要归纳与判断的任务（如从性能数据中提取结论），后者处理生成密集、需要遵循约束的任务（如按结论改写代码）。两者之间需要一份交接协议——通常是结构化的中间产物，如报告、schema 化的 JSON 或规格文档。这种设计的收益在于每一步的任务边界清晰、可独立验证，从而减少单个模型在一次超长任务中出现的上下文漂移与错误累积。

Python 3.15 作为背景变量

报告中提到 profiling 针对 Python 3.15。这一点在原文中只是顺带提及，但它解释了为什么需要专门跑一次性能分析：新版本解释器的行为可能改变原有代码的热点分布，旧有的优化经验未必仍然成立。

对于维护长期项目的开发者来说，这是一个提醒——升级 Python 版本之后重新 profile，可能会发现新的优化空间，而这些空间的挖掘和实现，现在部分可以交给 AI 模型来完成。

解释器版本升级为何会改变性能热点：Python 每个大版本都会调整解释器内部实现，例如字节码指令集、自适应特化（adaptive specializing interpreter）、内联缓存、垃圾回收策略等。这些改变会让原本昂贵的操作变便宜，也可能让依赖旧实现细节的代码（如过度的缓存、手写的手动优化）失去优势。因此，过去总结的优化经验具有版本依赖性，不能简单沿用。定期在新版本上重新跑一次 profiling，本质上是对「当前真实热点」的重新测绘，这也是为什么报告中专门针对 Python 3.15 生成分析结果具有实际意义。

0.1a1 这个版本号的信号

从版本号看，web-edit 仍处于早期阶段，0.1a1 意味着 alpha 通道上的第一个迭代。这个阶段的发布通常不是为了功能完整性，而是为了验证方向。

把性能优化放在如此早期的版本里完成，本身也说明了一件事：AI 辅助的代码优化正在降低「提前做性能工作」的成本。过去性能优化往往被推迟到项目成熟之后，因为需要投入专门的工程时间。现在这条链路的门槛变低之后，早期项目也有余力把性能问题顺手处理掉。

项目已附上带 profiling 和 projects 标签，方便后续按主题检索这条工作流的演进。