usage-based 做规划，request-based 做执行，简直是天作之合：
1. 规划需要多轮对话，如果用 request-based 会耗费掉很多次（虽然 Cursor 也有 Plan 模式，但不太好用）。如果用 usage-based 做规划，不用担心多轮次，而且非常省 token ；
2. 等规划好了多项待办任务，用 request-based 一气呵成做完，不要太划算！
结论：肯定要续费！而且不能停！

有点意思。我最近在做一个数据采集工作，想尽办法要降低成本。所以也遇到了类似的问题。

一般的数据采集，是一条流水线：搜索、访问、下载、预处理文本、提取要点、组织输出……，这个过程可能反复，比如第一轮搜索及采集的数据不理想，还需要再根据上一轮结果，发起下一轮。

其实里面需要用到 LLM 的「大智能」来判断的，只有一部分，比如判断某些片段是否包含所需信息，以及组织这些信息，而其他的比如访问、下载、预处理，只需要代码层面这些「小智能」去处理就可以。

上面的「大智能」「小智能」是一种形象比喻。

我现在的理解是，「大智能」「小智能」，它们需要组织成一个复杂的「混合物」。

「大智能」可以自己构建「小智能」，将不需要复杂智力判断的流程（搜索、访问、下载），委托给代码。而在「小智能」执行过程中，某些模块又可以调用「大智能」来处理，比如「判断搜索到的数据是否满足要求」。

这 2 者互相调用、互相嵌套，揉杂在一起。

程序员这份工作的本质到底是什么？

楼上提到了「手工生产」 vs 「工业化生产」的例子，来说明程序员其实是「手工艺人」，要被 AI 这一「工业自动化」替代掉。

可是程序员做的「手工」，不是那种固定的「流程性操作」，而是「复杂的脑力操作」。那么这种脑力的自动化，到底意味着什么？它自动化的到底是什么？

本来就是 2 份不同的工作。1 份是自己做，1 份是委托（ delegate ）给其他人做。
试问，有哪个老板工作能进入心流？

你们这样对待老板，就像 LLM 对待你们：口头说的很好，最后要结果时一地鸡毛。
等着吧，还有好戏！你们老板回头会找你们的。

看了下很有意思。不过文档有点模糊，问了 Agent 才弄懂：主要是 onIdle()处理队列那块没看懂，然后人机怎么协作也比较迷糊。看样子我已经比不过 AI 了。

才发现明天就要比赛了啊，现在报名也来不及了。后面慢慢弄吧！

@Pters 弹性自适应扩容！

偏个题，「下钻」这词到底哪儿来的？

如果按 Claude Code 订阅 40x 的倍率计算，只花了 4000 美元（ 16.5 万美元/40 ）。

@KumaAPI 我说错了。你可以看看后台，有没有击穿的。

老板，new api 似乎出 bug 了，余额可以被击穿，赶紧修复一下，要不然要被薅秃了！

没用过火山，但是领教了阿里的，文档写了一堆东西，找不着北。

@nakun233
我们永远也不会知道背后的真正原因。

很难相信这样的 bug 不会被发现。不管了，反正我到那个帖子里小小的施压了一下。

都传遍啦。

官方(支持人员)说是 buggie 已被修复：
https://forum.cursor.com/t/legacy-individual-plan-max-mode-required/164969/7#:~:text=A%20bug%20meant%20this%20wasn%E2%80%99t%20always%20being%20enforced.

@nakun233 #24 "A bug meant this wasn’t always being enforced. "

感谢分享，找到了原帖，都去发帖助助力： https://forum.cursor.com/t/legacy-individual-plan-max-mode-required/164969/7

这真的是 bug 吗？这么低级的 bug ？这么长时间没有发现？难以置信！

隔壁 L 站早就实现啦！