一般都会配个AI辅助coding，比人的bug定位能力更强。
问题就在于AI有时候自己陷入了报错循环，不管怎么喂代码和报错信息都不回改，这种情况就需要人调试。
怎么调试：找到参数/错误传递路径
可以问问AI这个值是怎么传递的，然后具体看看每个文件里的代码，让AI帮忙在代码前后加上报错打印点调试，一方面，判断真正出错的是哪个路径的哪一步。
Cursor使用
最近用了Cursor，感觉特别好用，但也有要 注意 的地方和 使用技巧 ：
- 一般我使用 Agent模式 ，但设置Agent不能自己修改代码或运行指令
- 必须 人工 检查模型提出的修改是否合理：
- 如果Cursor给出了过于 激进 的修改尝试，大概率是错误的方向，改不出来，或者改出来会出现其他逻辑错误（比如违反了其他功能的逻辑）
- 如果模型自己的想法多，但拿不准它自己是否能圆回来，可以 给它参考代码逻辑 ，这样在1-3轮复盘修改中一般就解决了。因为模型修改不好的原因，很多时候在于，我的参考代码已经有正确的片段了，但模型脱离参考代码自己写版本，但是又没有完全理解代码整体，开始激进的修改。这时候如果你对原理也不清楚，很有必要让模型回到源代码 。（PS：借鉴参考代码这点，我觉得Cursor做的比其他模型好，其他模型很容易不理解原码直接照搬产生问题）
- 在适当的时机，例如没有编译错误、基本的跑通之后，提出你自己对于 原理（例如过程、模块关系、参数传递计算等等）的一些阐述 ，如“
请你检查我的代码是否满足：1.在only_eval: False模式下，先进行一个epoch的训练，然后进入eval逻辑评估准确率，保存checkpoint（名称例如为”checkpoint_5“,5是当前epoch数）2.上一轮epoch结束后，在前一轮训练的权重基础上进入下一个epoch训练”，然后输给Agent让它帮忙检查。如果你觉得它检查的逻辑不够仔细，论证不够清晰（有可能Agent忽略了一些细节，然后告诉你代码没有问题，实际上有问题），那就再问一轮。 - 如果你一次贴的输出篇幅很多，Agent可能只会抓住主要的信息，漏掉一些小的输出问题点，需要你自己检查再贴上去问。这时候我建议选择自己的终端（例如我是扩展屏放
ITerm），而不是用Agent对话的内嵌终端，这样卡住了还能直接贴给AI不用在内嵌终端空等，而且方便观察输出细节。
- 惨痛教训 ：每次跑通bug后 及时上传Github ，哪怕是tmp code也建议commit tmp版本，不然正确的版本到后面修改了就很难复原回来。如果你debug是纯靠运气，那么弄丢了之前的正确版本，只能先回到你确定的版本，再根据cursor历史尝试几遍复原了
Gemin使用
和Cursor相比，Cursor写代码、测试脚本的能力很强，执行力好，但是对于长文本、多格式（如pdf）文本分析是短板，不管有没有开claude(实际上按照我下面的方法，auto模型完全够用)。
因此当我们需要解决某个任务，可以先把服务器代码同步到远程仓库，从github上下载相关代码，再加上论文一起丢给Gemini，让他分析。
案例1（Gemini+Cursor配合使用）
Gemini prompt:
prompt附件：代码+论文pdf
【Gemini分析】
然后你可以把Gemini给出的解决方案（回答），整个copy下来，作为prompt喂给Cursor，让Cursor执行。相当于一个是决策官，一个是执行官。
案例2（调教：如何优化Gemini回答）
首先我发现一个问题：我的版本代码模型训练结果和baseline相比，每一个stage呈现出断崖式下降。这是一个实验现象，而且比较难分析。 如果我让Gemini直接分析背后原因，八成答错，或者解决方案挠痒痒。
所以，我们需要新开一个chat，客观地让Gemini先主动分析对比我的代码和baseline代码，此为第一轮对话。然后再告诉它：
- 我的实验/代码出现了XX现象
- 两个代码版本差异是什么
- 如果我的代码正确，应该像baseline一样（怎样怎样……）
第二轮对话的回答一般来说正确率就比直接问高很多。然后你要用自己的脑子判断一下，它说的对不对，对的话再像案例1一样，让它提出解决方案。
另外，
Gemini prompt - Round1:请问我的lora-only版本代码(run_lora_only.py + coconut_gating_model_lora_only.py)，如果使用全量训练，不使用lora训练，是否原理和计算逻辑完全和coconut baseline (origin_run.py+coconut.py)一样？