在你用一个大型代理群体在新项目上消耗大量代币之前，老木工的格言“量两次，切一次！”值得修订为“检查你的珠子 N 次，实施一次”，其中 N 基本上是你能忍受的次数。 我发现，即使是微妙的改进，随着你连续多次运行 Opus 4.5，你会不断获得更多的改进（请注意，以下提示仅在你已经使用我最近在关于工作流程的非常长的帖子中给出的其他提示将初始 markdown 计划转化为珠子之后使用）： “重新阅读 AGENTS dot md，以便它仍然在你脑海中清晰。仔细检查每个珠子——你确定它有意义吗？它是最优的吗？我们能否更改任何内容以使系统对用户更好？如果是，请修订珠子。在我们开始实施这些内容之前，在“计划空间”中操作要容易得多和快得多！ 不要过于简化事情！不要失去任何功能或特性！ 此外，确保在这些珠子中包含全面的单元测试和端到端测试脚本，并提供详细的日志记录，以便我们可以确保在实施后一切正常。记住，只使用 `bd` 工具来创建和修改珠子，并将依赖项添加到珠子中。使用 ultrathink。” 我过去只在开始实施之前运行一两次，但我最近尝试连续运行 6 次以上，它不断带来有用的改进。 如果在珠子的增量改进方面开始平稳，你可以尝试开始一个全新的 CC 会话，开始时使用： “首先仔细阅读所有 AGENTS dot md 文件和 README dot md 文件，并理解两者的所有内容！然后使用你的代码调查代理模式来充分理解代码、技术架构和项目的目的。使用 ultrathink。” 然后跟进与上面显示的相同提示，但前面加上： “我们最近将一个 markdown 计划文件转化为一堆新的珠子。我希望你非常仔细地使用 `bd` 和 `bv` 来审查和分析这些。” 你的 markdown 计划越复杂和精细，这种技术就越相关。如果你有一个小的、微不足道的计划和一个非常简单的项目，这显然是过度的。但在这种情况下，你可能会发现每轮的增量收益/变化很少，因此何时停止应该是相当明显的。 只需记住：计划代币远比实施代币少且便宜。即使是一个非常大、复杂的 markdown 计划也比几个实质性的代码文件短，更不用说整个项目了。 而且，当推理一个非常详细且充实但仍然足够小以轻松适应其上下文窗口的计划时，模型会更聪明（这实际上是我对计划的强烈关注的关键见解，以及我为什么在那部分花费 80% 以上的时间）。 如果你在网络应用中依赖 GPT Pro 进行初步规划，如我强烈建议的那样（也就是说，创建和改进你的 markdown 计划，最终将其转化为珠子），你基本上可以在 Pro 计划中无限制地获得这些，因此充分利用它！ 在处理容易适应其上下文窗口的输入时，没有其他模型可以与网络上的 Pro 相提并论。这真是独一无二的。 ...