“把代码优化一下”容易产生大范围重构，却无法证明更快。正确流程是先有基线，再锁定热点，做小改动，用同一方法复测。
建立可重复基线
先让 Claude 读取现有性能脚本和测试，提出测量方案，不要立即重写代码。优化前先固定输入、命令和三项结果：运行时间、资源占用或吞吐指标，以及正确性测试结果。
先不要修改。找到现有 benchmark 或可重复测试；说明输入规模、运行命令、采样次数和正确性检查。没有基线脚本就先给最小方案。定位一个热点
让 Claude 依据 profiler、查询计划或日志解释瓶颈，不接受仅凭代码外观判断。一次只改一个主要瓶颈，例如重复查询、无界循环或不必要序列化。
保留行为
修改前补齐关键行为测试，特别是空输入、上限值和失败分支。要求 Claude 列出可能改变的语义，并把非目标重构移出本次 diff。
复测与结论
使用与基线完全相同的输入、环境和命令复测，并运行正确性回归测试。记录多次结果而不是只选最快的一次；只有差异稳定且正确性不变，才保留补丁。
没有稳定测量结果时，只能称为重构或假设，不能宣称性能提升。开发机结果也不能直接代表生产负载。
如何判断测量可信
先预热运行环境，再在相同机器负载下重复多次。数据库和网络任务要记录缓存、数据量和服务状态；前端任务要区分开发构建与生产构建。若波动范围大于优化差异，应先减少噪声。还要比较内存、错误率和尾延迟，避免平均时间变快却牺牲稳定性。
资料与适用范围
小步重构与验证方式参考 官方常用工作流，命令执行边界参考 权限文档。本文未对你的代码做基准测试。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/30882.html
