最近在跑一个 X workflow goodcase 的采集任务。
目标其实很简单：从 X / Twitter 上找一些真实的、第一人称的 workflow 案例，后面用来做测款数据集合。
但实际跑下来，我的体感是：越跑越慢，效率极低。三天跑了不到30条
不是机器慢，而是整个过程开始变重：
- 每一轮都要我审
- 审完又要改策略
- 改完再跑一轮
- 新一轮又出现新的问题
- 最后我开始怀疑，任务目标是不是被我自己改漂了
我当时在 TG 里问了一句：
会不会每次我都要审查它的效果，让它更改策略，最后导致任务目标慢慢漂移？
复盘之后，我觉得这个问题很典型。
它表面上是在问 Agent 采集任务，背后其实是另一个更常见的问题：
有时候越想快，反而越慢。
一开始只是想快一点
最早的结果太严。
几轮跑下来，100 条里只过了 3 条。
这个时候我的第一反应很自然：太慢了，放宽一点。
于是开始放宽标准：
- query 换一下
- 浏览量门槛调一下
- long post 多收一点
- 评论区展开型也算进去
- X Article 也提高权重
- 一些过滤规则先别卡那么死
放宽之后，数字确实好看了。
120 条里过了 48 条。
但新的问题也来了：营销号、擦边内容、泛赚钱文案、课程引流、工具清单、不是第一人称实操的内容，都开始混进来。
这时候我又开始收紧。
于是系统进入了一个循环：
过得太少 -> 放宽
脏东西太多 -> 收紧
漏掉评论区展开 -> 改入口规则
混进营销文案 -> 加坏例过滤
结果又变少 -> 再放宽每一步都很合理。
但叠在一起之后，事情就变慢了。
慢不是因为没努力，而是因为题目在变
这条线里真正的问题，不是 Agent 不努力，也不是搜索能力完全不行。
更根本的问题是：我没有一开始就冻结“什么叫 good case”。
最开始我只是想找“workflow 案例”。
后来我发现，要第一人称，要有实操过程，不能是推广，不能是课程引流，不能只是工具清单，评论区展开型也可以，但必须是作者自己的方法论。
这些标准都是在过程中一点点长出来的
所以前几轮和后几轮，其实不是同一个题目。
这就很像写代码时没有先定接口。
你一边写实现，一边改输入输出，一边改验收标准。短期看，好像每次都在快速响应问题；长期看，每次修改都会让系统更难判断自己到底有没有变好。
最后不是“跑得更快”，而是“每轮都要重新解释一次什么叫对”。
过早优化会制造更多返工
我这次最明显的教训是：很多所谓“提速”的动作，其实是在把成本推迟。
比如为了多抓一点，我放宽了入口。
短期看，候选变多了。
但候选变多不等于有效样本变多。它只是把更多不确定的东西推到了人工审查阶段。
再比如，为了不漏掉评论区展开型内容，我放宽了主帖判断。
这确实能召回一些好东西，但也会带来更多包装得很像经验贴的营销内容。
于是我后面又要补过滤、补回填、补重判。
这就是“想快”的代价：
前面省掉的判断，后面会以人工审查和返工的形式回来。
而且回来时更贵。
因为这时候数据已经进了候选池，甚至可能进了最终 JSON / goodcase 文档 / board。你再清理，就不是简单地调一个规则，而是要回头区分哪些是候选，哪些是待审，哪些是真的 approved。
人越频繁介入，系统越容易漂
我之前的操作有点像在线教学：
这一轮不行，你改一下。
这个不要，那个可以。
这类太松，那里太严。
再跑一轮看看。
这听起来很敏捷，但其实有风险。
因为每一次反馈都会让系统更偏向“修正最近一次错误”，而不是稳定地追求原始目标。
某一轮混进营销号，就猛加营销过滤。
某一轮漏掉评论区展开，就放宽主帖入口。
某一轮通过率太低，就降低门槛。
最后系统学到的可能不是“什么是好案例”，而是“怎么避免下一轮被指出问题”。
这会让它越来越保守，也越来越依赖我。
表面上我在加速它，实际上我让它变成了一个每轮都需要人工扶正的流程。
真正的快，是先慢下来定标准
这件事让我重新意识到一个很朴素的工程道理：
想让系统跑得快，前面就不能省掉定义问题的时间。
后面我会先做三件事。
第一，先冻结一个 v1 rubric。
比如：
- 第一人称实操
- 有可复现的方法 / 步骤 / 工具链
- 非推广 / 非课程 / 非工具清单 / 非营销引流
- 有明确结果，或者至少有清晰闭环
先按这个版本跑一段时间，除非发现重大缺陷，否则不轻易改题目。
第二，把候选和入库分开。
候选池可以宽一点，最终库必须干净。
raw_candidates -> review_queue -> approved_library不要因为想快，就把还没确认的东西提前塞进最终资产里。
第三，人工审查不要变成每轮教学。
我更应该做抽样质检：每轮看一部分样本，记录主要错误类型，然后决定是否开一个新版本。
人的职责不是一直盯着它跑，而是定义清楚：
什么叫好，怎么证明变好了，什么东西永远不能进最终库。
结论
这次采集任务本来只是一个小 workflow，但它暴露的问题很常见。
我太想让它快一点，所以不断放宽、修正、补规则。
结果不是更快，而是目标变得更松动，审查变得更重，返工变得更多。
很多时候慢不是因为执行慢，而是因为一开始没有把标准定稳。
真正的提速，可能不是马上多跑几轮，而是先停下来问清楚：
我到底要什么？什么算好？怎么验收？
这些问题如果不先回答，后面每一次“快速调整”，都会变成新的成本。