先看证据
一份性能报告，拆成两个模型任务
Simon Willison发布了 web-edit 0.1a1，这是一个在浏览器中编辑本地文件夹内容的 Web 应用预发布版本。此次发布包含性能优化：Willison把一份由 GPT-6 Astra生成的 Python 3.15 性能剖析报告交给 Claude Opus 5.5，再由后者据此修改代码。
这条工作流的关键不是“让模型把程序变快”，而是把问题拆成可检查的环节：先从运行数据里找热点，再针对热点改实现，最后用测试和基准核对结果。人负责提供任务上下文、选择报告并推动修改进入发布；模型的作用集中在分析线索和实现改造，而不是取代整个维护过程。
剖析数据指向的不是整款应用
优化前的 profiler 记录了 15,296 个栈样本，其中 preserve_endings 出现在 64.8% 的样本里，SequenceMatcher.find_longest_match 出现在 38.3%。这两个比例有重叠，不能相加。它们指向一个具体操作：保存文件时，程序要尽量保留未修改行原有的换行符，而通用匹配在某些输入上花费了大量时间。
这不是一次对所有使用场景的完整性能诊断。报告来自刻意构造的负载，重点是保存含混合换行符的大文件。它告诉维护者在哪里值得先动手，却不能单凭热点占比证明真实用户最常遇到的瓶颈也是这条路径；剖析报告本身也没有测量浏览器前端性能。
快路径来自识别文件结构
改造没有简单地把原有匹配器换成另一个通用算法，而是先区分文件的换行结构。若原文件只有 LF 或只有 CRLF，程序跳过逐行匹配，规范化编辑后的文本，再统一换回原有换行符。结构简单时走短路径，避免为每一行寻找对应关系。
混合换行则不能这样处理，因为不同的未修改行可能需要保留不同的结束符。新逻辑把两侧都只出现一次的相同行作为锚点，用 bisect 找出顺序一致的锚点，再让 SequenceMatcher 只处理锚点之间的空档。优化的核心是缩小昂贵匹配的范围，而不是消除所有匹配工作。
基准中的大幅提速，说明了什么
PR的基准在 Linux x86_64、4 CPU、Python 3.13.16 上运行，使用 12,000 行文件和包含 800 个文件的目录，报告重复运行的中位数。单一 LF 文件的 preserve_endings 从 61.1 毫秒降到 1.1 毫秒，单一 CRLF 文件从 63.9 毫秒降到 1.7 毫秒。混合换行文件每 5 行修改 1 行时，从 3,963 毫秒降到 29 毫秒；每 20 行修改 1 行时，从 1,117 毫秒降到 25 毫秒。
改善也不只发生在保存路径上：同一负载下，Uvicorn loopback HTTP 测试的编辑循环吞吐从每秒 6.5 次升到 12.7 次，浏览 800 个文件从 28.5 毫秒降到 8.6 毫秒。目录遍历改用 os.scandir 和字符串路径，二进制文件检测改用 bytes.translate，写入时则边复制边计算哈希，避免写完后再读一次目标文件。这些数字证明特定基准中的实现成本显著下降，但不能改写成整款应用对所有用户都快了同样比例。
性能之外，还要看行为是否保持
换行符优化有行为上的取舍：混合换行文件可能出现个别行没有保留原来的结束符。PR用 600 个样本文件、共 266,444 行未修改行进行比较，新方法整体正确保留率为 99.93%，旧方法为 99.80%。但这并不意味着差异不存在：有 25 次新方法比旧方法少保留了正确换行符，每次影响 1 到 6 行。
验证覆盖面也值得准确描述。PR称 130 项测试在 Python 3.11 至 3.15 上通过，并用 20,000 个随机案例比较换行匹配逻辑；但性能剖析来自 Python 3.15，基准却在 Python 3.13.16 上运行。对技术负责人来说，合理的判断是把这次改造看成一项有明确收益、也有已知行为差异的局部优化。若把这套流程用于自己的系统，应在代表真实文件分布的负载上重测，并把内容正确性和性能分别列为验收条件。