<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>技术实践 on 向叔记事簿</title>
        <link>https://ttf248.life/categories/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5/</link>
        <description>Recent content in 技术实践 on 向叔记事簿</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh-cn</language>
        <lastBuildDate>Fri, 10 Jul 2026 21:50:05 +0800</lastBuildDate><atom:link href="https://ttf248.life/categories/%E6%8A%80%E6%9C%AF%E5%AE%9E%E8%B7%B5/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>同一个模型，为什么这次 Claude Code 把性能优化做完了</title>
        <link>https://ttf248.life/p/minimax-m3-coding-agent-performance-optimization/</link>
        <pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate>
        
        <guid>https://ttf248.life/p/minimax-m3-coding-agent-performance-optimization/</guid>
        <description>&lt;p&gt;同一份提示词、同一个 Minimax M3、同一类性能优化任务，昨天却给了我一次很不普通的工具切换体验：Claude Code 在约二十分钟里留下了可复盘的优化过程；Codex 跑了一个多小时，截至我停止时，没有留下我愿意保留的优化。它不是一场工具排名，而是一次关于执行纪律的现场记录。&lt;/p&gt;
&lt;p&gt;我原本以为，这场对比没什么意思：同一份性能优化提示词，同一个 Minimax M3 模型，换两个编码工具跑一跑而已。结果差别大到让我没法再把它当成一次普通的工具切换。&lt;/p&gt;
&lt;p&gt;这不是工具排行榜。我没有多轮、可公开复现的基准，只能记录昨天这个现场：Claude Code 把我交代的活落到了地上；Codex 则运行了一个多小时，到我停止时，没有产出值得保留的优化。&lt;/p&gt;
&lt;h2 id=&#34;我给它们的规矩只有四步&#34;&gt;我给它们的规矩只有四步
&lt;/h2&gt;&lt;p&gt;性能优化最怕改动越堆越多，最后既不知道哪一刀有效，也没法干净地退回来。所以这次我把规则卡得很死：一次只做一个小改动，立刻验证，对照性能数据；有效就留下，无效就回退。&lt;/p&gt;
&lt;p&gt;模型用的是 Minimax M3。我知道它未必能一下找到什么大招，所以我更在乎它会不会守住这四步。这里的“性能数据”是我在任务里用来决定保留还是回退的结果；具体代码、指标数值和基准细节不在本文公开，因此这不是可复现的性能测评。&lt;/p&gt;
&lt;p&gt;我对齐了提示词、模型和任务目标；工具自身的上下文、命令调用、默认工作流，以及运行环境和版本等变量，并没有被做成严格控制。本文要记录的，是这一次工作流体验和交付过程的不同，不是严格的工具横评。&lt;/p&gt;
&lt;h2 id=&#34;让我服气的不是二十分钟&#34;&gt;让我服气的不是二十分钟
&lt;/h2&gt;&lt;p&gt;Claude Code 大约二十分钟完成。这里的“完成”，是指它给出了经本次验证后我选择保留的改动；这个时长也只是我对这一次执行的观察，并不是它的稳定耗时承诺。&lt;/p&gt;
&lt;p&gt;真正让我改观的不是时间数字，而是后来翻任务文档时看到的过程。文档把每一轮的尝试方向、改动后的结果，以及保留或回退的决定排在一起。我能顺着它接手：知道哪个方向继续，哪个方向到此为止。&lt;/p&gt;
&lt;p&gt;这件事在性能优化里很值钱。哪怕某一轮没有结果，也不等于白烧时间——它至少留下了一个被排除的方向。更重要的是，我写进提示词里的规则没有停在提示词里，而是变成了实际工作节奏。&lt;/p&gt;
&lt;p&gt;反过来看 Codex 那次，它未必什么都没做，但最终没有留下我能核对的“改动—数据—决定”链条，也没有产生我愿意保留的优化。性能任务里，跑得久不等于多做了事；没有证据把改动和结果扣起来，久有时只是更贵的迷路。&lt;/p&gt;
&lt;p&gt;我当然不会用一次任务给产品判死刑，更不会宣布谁全面领先。这次差异也可能来自任务拆解、工具调用、上下文管理、验证循环、默认权限或运行环境等因素。至于我听到的 Claude Code 受限消息，我没有核验，本文不据此推断任何厂商动机。&lt;/p&gt;
&lt;p&gt;但在这个具体现场里，我确实佩服 Claude Code 的落地能力。对我来说，能力受限的模型只要被放进“小改、验证、记账、回退”的流程里，也能一步步把结果挪出来；没有这套约束，屏幕上再多改动，也不等于留下了一次可用的性能优化。&lt;/p&gt;
&lt;h2 id=&#34;适配更好只是下一轮要验证的猜测&#34;&gt;“适配更好”只是下一轮要验证的猜测
&lt;/h2&gt;&lt;p&gt;我的第一个猜测是：Minimax M3 在 Claude Code 里，是否更容易被带进这种节奏？这只是猜测，不是结论。也可能根本不是模型适配，而是 Claude Code 在任务拆解、执行约束和验证闭环上，更能把同一个模型推着往前走。&lt;/p&gt;
&lt;p&gt;要把这个问题说得更硬，需要同一份代码、同一套基准、相近的环境和更多轮次；还要把各自的改动、数据、回退和最终验收条件都留下来。否则，我最多只能说：昨天这一单，体验差距非常明显。&lt;/p&gt;
&lt;p&gt;OpenCode 还没测，正好可以放进下一轮。我会继续沿用这套约束，记录每次改动、数据和回退。最后比的不是谁说得漂亮，而是谁留下了我能继续接手的结果。&lt;/p&gt;
&lt;h2 id=&#34;参考资料&#34;&gt;参考资料
&lt;/h2&gt;&lt;p&gt;本文基于作者亲历记录，未引用外部资料。&lt;/p&gt;
&lt;h2 id=&#34;写作附记&#34;&gt;写作附记
&lt;/h2&gt;&lt;h3 id=&#34;原始提示词&#34;&gt;原始提示词
&lt;/h3&gt;&lt;p&gt;$blog-writer 阿里云发新闻禁用了 claude code，市场都知道他家喜欢搞小动作，但是昨天的开发任务，让我佩服他的落地能力，一样的提示词，都是做性能优化，对接一样的模型，都是 Minimax M3 模型，由于模型能力比较弱，我指定了每次小改，逐步验证，对比性能数据，有效果保留，没效果就回退。codex 跑了一个多小时，什么有用的都没折腾出来，claude code，二十分钟做完了，翻看文档记录，清楚的记录了每轮的尝试方向，迭代以后的效果。我可以说是 Minimax 就是对 claude code 适配更好，确实他家有先发优势，各家都要适配他的 claude code，但是这个差距也太明显了。opencode 还没去测试，空了再去试试。&lt;/p&gt;</description>
        </item>
        
    </channel>
</rss>
