sillydaddy

而且你说 4.6 鸡肋，你这要求。。是不是有点高了。。？

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 了。

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