每次只改一个变量地迭代

被浪费掉的 Suno 生成次数，大多来自同一个错误：这一版已经快对了，于是一口气改了三处，下一版以一种全新的方式跑偏，而你完全不知道是哪一处造成的。

受控实验单次更慢，走到成品却快得多。

先说出最主要的那一个问题

听完之后，用一句话说出最不对的地方：风格、结构、人声、歌词、结尾，或者出现了多余的元素。不要列清单——只挑那个"如果修好，收益最大"的。

这比听起来难，因为一版让人失望的结果，往往感觉哪儿都不对。但还是要强迫自己排序。如果人声被埋掉、鼓又太响，这两件事通常是同一个问题，选定其中一个，你才能得到一个真正回答了问题的版本。

在动蓝图之前，先写下简短的听感笔记。这只花十秒钟，却决定了你的版本历史是"可读的记录"还是"一串编号的尝试"。

然后基于这条笔记创建下一个版本。当前版本会被完整保留、不被覆盖，所以每一次改动都能追溯回引发它的那一版。如果改完更糟，上一版原封不动地还在，而你得到的是一条具体的结论，而不是弄丢了一个好结果。

结果可用时，把它标记为 keeper。这是一个独立于"记录问题"的明确动作，重要性比看上去高：keeper 是一个你随时能退回来的基准。

没有它，好结果只是列表里的又一条记录；而典型的结局是——你继续迭代、越过了它，事后想不起它是第几版，也回不去了。

结果不好时，本能反应是把整段风格描述重写一遍。这偶尔管用，但你什么也学不到——你同时改了太多东西，无论结果好坏都无法归因。

每次只改一个变量，会积累出重写永远给不了你的东西：一张"在这首歌、这个流派、这个模型上，哪些控制项真正起作用"的地图。四五个受控版本之后，你会不再靠猜来调速度和制作方向，而是能给出站得住脚的判断。

在归咎于蓝图之前，先做一个快速核对：如果某个控制项似乎完全不起作用，先确认它在你面向的模型上确实存在。Suno 各个模型开放的控制项并不相同，而"模型忽略了这个设置"看起来和"这个设置没生效"一模一样。这部分见选择目标模型。