...我不能想出一个理由说明这为何会不与Claude兼容，但我暂时还没尝试过Claude，所以不确定。

所以，我认为这对很多在这里的人来说可能并不是很有用的建议，但如果你和我一样，已经因为一段时间使用GPT模型而习惯了一种特定的工作流程，并且习惯了某些行为模式，这篇帖子可能对你有帮助。

(另外请注意，我不声称完全知道如何“最大化token”，这对我而言可能是token效率低。如果你担心在token预算中挤出每一滴可能的资源，那完全可以理解；除非纯粹是巧合，这里找不到。)

如果你一直在做以下事情：

  • 手动构建定义文件和数据结构。
  • 告诉GPT使用这些作为上下文，并构建逻辑模块来填补空白，因为之前就是这样做的。
  • 手动规划/构建占位符的垃圾内容

...这并不是使用Astra的最佳方式。如果你喜欢手动编辑，随意吧。但Astra更快且更节省token，如果你让它只负责规划，让它自己构建定义文件，让它创建占位符垃圾内容和初始值等。

下面是一个Astra提示的示例，让我了解在LLM聊天界面中的工作流程：

Perfect, thank you.

Can we please plan the implementation of a shotgun weapon currency, shotgun shell ammunition, and some environmental storage containers?

The shotgun should be a 1 x 3 piercing ranged weapon with a range of 6, a damage value of 5, a fatigue value of 1, an attack delay of 2 and requiring consumption of shotgun shell ammunition to be used (ranged weapons and ammunition usage is not yet established in the game and requires new implementation).

shotgun shells should be 1 x 2 currency with an ammunition pool of 12

I'd also like to ideally change the existing storage rack fixture to be actual storage containers that we could put shotguns and shotgun shells into. Could you recommend a means of doing that that would mesh with the game's existing systems?

Do not implement anything yet, this is just planning / discussion.

Note that you do need to instruct the LLM during planning not to implement anything, because otherwise it ain't got no brakes on the train.

Astra 会生成详细计划，并要求你填写任何上下文或模糊之处，回答那些问题。完成后：

That sounds great; Could you please implement that?

If you have any questions or require clarification, please ask either before or during implementation. Please create any additional modules you feel would be useful to have for this implementation, but only if they are needed.

你必须礼貌吗？可能不需要。但我选择礼貌。

询问澄清很重要，否则模型会做出很多后期需要撤销的假设。

如果让它创建模块，可以防止它只选一个文件，随意编写并把大量不同系统的代码塞进去，导致混乱。

作为一般规则，Astra 每条提示能处理的项目片段越大，token 使用越高效。但片段越大，工作会越被扭曲。因此你需要感受平衡点——在获得易读、易编辑代码与 LLM 乱码之间的权衡，后者的 token 使用和个人工作实际上是为了得到更干净的代码。

如果你还没有把机器从单纯的补缺角色转变为计划‑执行协作引擎，你大概应该这么做。这在速度和预算使用上是天壤之别（至少对我而言是这样）。

有相当多的人坚持让 Astra 先写出计划，然后把计划交给 Sol，以此节省大量 token，因为 Astra 只用很少的 token 进行规划，而执行却消耗大量 token，而 Sol 在执行时成本极低...

说实话，我不信任 Sol 处理这种程度的抽象层次。我并没有真正尝试过，但我对 Sol 能否跟随 Astra 的计划非常怀疑，尤其是在没有上下文的情况下（尽管 Sol 在其价格点上相当有能力，但其推理能力仍远逊于最新模型）。