使用了一个月gpt、grok、大肥鱼之后的一点心得

序言

我的项目中web前后端的占比很低，以python和cpp为主，项目规模都比较大。如果你不同意我的看法，那么以你的为准，你说的对。

开发

先说说开发吧，2026年8月应该不会有人在用superpowers brainstorm起手折磨自己了，我就说说我常用的三种开发起手式：

直接许愿

一句话就能描述清楚的问题，就没有必要上spec/plan那种重量级的东西了。这种情况下，gpt/grok/ds在完成度上不会有任何区别。

需要注意的是，sol有很大的概率给你加上各种不必要的过度防御。比如：通过语义分析甚至LSP都可以知道传入的参数10000%不会是nullptr，sol非要在函数入口判断一下传入的参数是不是nullptr。还有比如github workflow，明明是私有仓库却给你设计一堆防止恶意用户通过PR投毒的操作。我愿称其为AI界的慎勇。terra这种就更离谱了：提示词里写了我有三台虚拟机，帮我写一个调度虚拟机的小程序。它写出来的东西直接就是hardcoded三台写死的，代码里还校验了数量，多一台少一台都报错，都已经不是正常人能想出来的操作了。

/plan起手

常见于一些需要跨文件的复杂度较高的改动，我选择使用cc+大肥鱼，它更倾向于通过ask tool来跟你对齐需求，我会让其在完成任务后提交到dev分支并创建PR，然后把PR复制给sol进行review。review完成后人力排除掉过度防御的verdict，剩下的再贴回让大肥鱼继续改，直到通过二次review。

为什么我不用sol或者grok？因为：1、上面说过了sol喜欢在设计上就过度防御 2、grok4.6和gpt全系没一个说人话的，真用这俩的话在意图对齐这一块会付出过高的成本。

千行级别的大改

(1)帮我考察XXX (2)如果要把XXX改成YYY应该怎么改？ (3)把你说的改动流程总结成文档放到docs/plans/下 (4) 如果完全不在乎代码的人类可读性：呼叫gpt/grok执行plan。如果在乎代码是否对人类友好：呼叫opus5/fable5执行plan (5) 呼叫sol对代码进行review并重复/plan里提到的流程

这一步我一般会使用pi+大肥鱼，不用cc是因为这一步是只读的，所以要尽可能减少无关skill和mcp对上下文的影响。不用gpt/grok依然是因为这俩不说人话，没法在(2)里面人力对齐意图

Debugging

如果是复杂问题，毫无疑问的无脑用sol就行了。找问题稳准狠，至今没有碰到过它40分钟内解决不了的问题。如果有，那就是你工具没给够。

如果是一眼丁真的问题，那就随便了，dsv4flash都够了。

需要注意的是：sol给出的root cause基本可以信，但是绝对不要无脑信它给出的proposal fix。很多时候明明有更优雅的解法，它偏要绕一大圈用最蠢的办法解决问题。如果你自己有脑子，你就用你自己的脑子给出最优雅的proposal fix让它按你的想法修。如果你没有脑子，那至少把root cause转发给fable5或者其他更有代码品味的AI。

固定工作流的长程任务，比如：小作文级别的SKILL.md

luna-xhigh或者dsv4flash都行，评价为又快又好，用其他模型纯属浪费token

二进制逆向

我认为只有sol/opus具有可用性。你要是觉得其他模型也能逆向，那你说的对。

实测同一份代码编译出的一份无pdb的dll(pe32)、一份带dwarf的so(elf32)，接上ida-pro-mcp，让sol/grok4.6/dsv4p还原一个函数，在上下文里提供了完整源码目录和so的位置。

sol：能还原至跟源码一模一样

grok4.6：跑了半个小时的readelf然后放弃了

dsv4p：逆一半不动了，要我不停拷打才能逆完，并且有东西还逆错了。