别替 Agent 做判断：把你想到的每件事都扔给它
写给那些已经用上 Codex、Claude Code、OpenClaw、DeepSeek Harness，却还在"精打细算"下达任务的人。
一个反直觉的事实：你在替 Agent 省事，其实是在替自己设限
很多人拿到 Codex、Claude Code、OpenClaw、DeepSeek Harness 这类工具后，第一反应是"它能帮我写什么"。
于是任务清单长这样：补个函数、改个 bug、写个单测、重命名一下变量。都是你明确知道"它肯定能做"的事。
这恰恰是把最强的一把武器用成了螺丝刀。
你有没有想过另一面——那些你"不确定它能不能做"的事，才是收益最大的地方。因为你的不确定，本来就只源于一件事：你的经验里没有样本。而 Agent 的能力边界，早就溢出了你脑子里那张地图。
老程序员正在被自己的经验反噬
我见过太多资深工程师，用 Agent 时小心翼翼得像在带实习生：
- "这个仓库几十万行，它肯定读不明白，我先把关键文件指给它。"
- "让它查第三方库的兼容性问题？算了吧，它又不知道我们踩过什么坑。"
- "让它自己去定位那个偶发的 502？别闹了，我自己都查了两天。"
这些话背后有一套自洽的逻辑，而且这套逻辑曾经让他们在职业生涯里做出过正确判断：我知道什么事做不了，所以我不浪费时间。
问题在于，这条经验现在失效了。
你的判断来自"代价"——读几十万行代码要三天、排查一个分布式偶发问题要两天、摸清一个陌生库的 breaking change 要一整天。基于这些代价，你合理地认为"不值得让它试"。
但 Agent 的代价结构和你 完全不同：
- 它读完一个仓库是几分钟，不是三天；
- 它可以同时开五个分支、跑十种假设，然后自己回滚；
- 它试错不消耗情绪，不需要上下文切换，不会在第三天放弃。
你砍掉任务，是因为你知道代价。而它不承担那个代价。 于是你用你的人力成本模型，去剪裁一个算力成本模型——这是整件事里最隐蔽、也最贵的一个错误。
更狠一点说：经验正在从资产变成牢笼。 你越资深，脑中"这件事做不成"的清单越长；而这份清单，正在精准地圈出你交给 Agent 的任务范围的上限。
把决策权交出去：描述目标，而不是描述步骤
真正的转变发生在你改变下达任务的语法。
以前的写法：
打开
src/order/目录，找到createOrder方法，在第 120 行附近加一个库存预占的校验，异常类型是StockShortageException，记得写单测。
现在的写法：
我们的下单流程在秒杀场景会超卖，你去把这个问题解决掉，附带能复现的测试和压测数据。
前者是你在替它规划。后者是你在提需求。
区别不只是省事。当你指定了目录、行号、异常类型，你其实已经把解法框死了——你用自己脑子里那版（很可能不是最优的）方案，堵死了它提出更好方案的可能。它就算想到了分布式锁 + 预扣 + 异步对账的组合，也会因为你说了"在第 120 行加校验"而乖乖照做。
你给的约束越细，拿回的结果就越像你自己写的那版。 而你自己写的那版，本来就不是你求助的理由。
试一试那些"看起来不靠谱"的想法
我一直有一个私人习惯：每周挑一两件"我觉得它肯定干不了"的事，扔给 Agent，不抱期待地跑一遍。
结果大概是这样的：
- 觉得它读不动整个 monorepo → 它两小时内给出了一份模块依赖图和三处循环引用；
- 觉得它定位不了偶发 502 → 它翻了三周的日志，用脚本统计出一个我没注意到的 upstream 超时分布；
- 觉得它写不了压测方案 → 它自己装了 k6，写脚本、跑数据、把报告做成了带图表的 HTML；
- 觉得它搞不定设计稿还原 → 它读了 Figma 导出，调了八轮，最后像素差在 2px 内。
成功率不是 100%，大概三到四成能直接落地。但你想想：哪怕只有 20% 的成功率，一件"你本来根本不会开始"的事，期望收益也是正的——因为你的投入只是写一句话。
而且更关键的收益不是那几次成功，而是你的能力边界估计被重新校准了。每一次"卧槽它真干成了"，都会把你下一次愿意下达的任务范围往外推一格。这个校准是复利的。
反过来，每一次你因为"感觉不行"而没有下达指令，你的边界认知就原地不动，甚至因为一两次失败而收缩。
资料的两种给法：给足，或者放手
关于上下文，有两条路都要走通。
第一种：能给的，尽量给足，而且要"喂结构化"。
Agent 不是读不懂，是你给的东西没法用。比起甩一句"这个项目用了 Postgres"，不如给：
- 一份
CLAUDE.md/AGENTS.md：构建命令、测试怎么跑、代码风格约定、哪些目录别碰； - 一两个"好样例"：你认可的 PR、你认为写得对的那段代码；
- 失败案例：踩过的坑、被否决过的方案及原因（这个极其值钱，因为文档里通常只写"怎么做对"，不写"为什么不能那样做"）；
- 评判标准：什么叫"做完了"——测试通过、性能不退化、diff 不超过 200 行。
第二种：给不了的，别硬凑，直接让它自己去找。
这一条更反直觉，但我越来越确信它是对的。
你说不清数据格式 → 让它自己读数据库 schema、抓一份真实响应回来； 你不确定某个库的 API → 让它去读源码、读 changelog、写个最小 demo 跑一遍； 你不知道线上的配置是什么 → 让它去查配置中心、看 CI 脚本、翻部署清单。
而且它找到的，常常比你给的更好。
原因很简单：你是凭记忆给的。你的记忆里装的是"上次用到的时候"的版本，掺杂着两年前的旧约定和已经重构掉的模块。而它是带着这个具体问题，去现场取的最新事实——顺带还能发现"文档里写的是 A，实际代码是 B"这种你根本不会去查的不一致。
更妙的是，它找资料的过程会留下痕迹：它读了哪些文件、跑了哪些命令、 验证了什么假设。这些痕迹本身就是一份可复用的排查记录。你给资料，换来的是一次结果；它自己找资料，换来的是结果加一份路径地图。
当然，放手不等于放养。你要做的是定边界：哪些命令不能跑（rm、drop table、推 master）、哪些环境只读、改动多大需要先停下来问你。约束住爆炸半径，然后让它横冲直撞。
三条马上能用的做法
- 把"这个它做不了吗"改成"让它试一下要多久"。 前一句触发你的偏见，后一句触发一个可执行的动作。
- 每天留一个"浪费任务"。 专门挑一件你认为不值得或不可能的事丢给它，不看结果好坏，只看它能不能推进。这是在给你的边界估计持续采样。
- 先说目标，后说约束。 第一句话只讲问题和验收标准，等它给出方案后，再用你的经验去纠偏。让它的"发散"和你的"收敛"各归其位。
最后
程序员这个职业，前几十年训练的是一种能力：在动手之前，准确判断一件事值不值得做、能不能做成。 这套判断力让我们避免了无数无效劳动。
现在环境变了。当"动手"的成本趋近于零，判断力的最佳用法就不再是"筛掉不可能"，而是"优先发起尝试"。
你不需要比 Agent 更懂它能干什么。你只需要比它更懂你想要什么。
剩下的，交给它去撞。撞出来的那些惊喜，是你坐在工位上替它做判断时，永远拿不到的。