人们常说"没有蠢问题"，这是我们彼此说的善意话语之一，对人类来说这也是事实。一位新同事问计费代码放在哪里，是在了解系统的整体结构；这个问题能建立共同的上下文，而回答只需要一分钟。但自主智能体不是刚站稳脚跟的新同事。它能在你读完这句话的时间里读完整个代码仓库。对智能体来说，有些问题确实是蠢问题——而最蠢的那些，就是它本可以自己去看一看就能回答的问题。
对智能体来说，什么是蠢问题
蠢问题是指答案已经存在于代码库中的问题。"处理这个的代码在哪里？""构建命令是什么？""我们是不是已经有处理这类事情的模式了？"人类在入职第一天问这些都很合理。但一个智能体问出这些问题，等于是在宣布：它宁愿让别人把上下文喂到嘴边，也不愿自己去找——尽管去找答案正是它明显比你更擅长的事。
判断标准是答案是否可被发现。如果智能体本可以通过读一个文件、在代码树里做 grep、查看 CI 配置，或读一读最近修改过这块区域的几次提交来得到答案，那么向你提问就不是谨慎，而是把本该自己完成的工作推还给你。
异步智能体为问题付出的代价是整天整天算的
对于坐在你旁边的聊天助手来说，提问的代价很低：你就在那儿，回答一下，它就能继续。TaskGoblin 不会坐在你旁边。它由 issue 分配、一次提及，或一个新的合并请求触发，然后在沙箱中独自工作——而这时你可能正在开会、睡觉，或身处不同时区。在那样的世界里，一个问题不是停顿，而是彻底的中止。
一个智能体问"这个该放到 services/ 还是 lib/？"然后等待答复，就把一次原本几分钟就能完成的运行，变成了一次要等到你下次碰巧看到该线程时才会结束的运行。一个是非题，如果问在错误的时刻，可能会用三十秒的真实思考换来一整天的时钟时间损失。让这个智能体有价值的那种异步、无人值守的模式，恰恰也是让一个本可避免的问题变得如此昂贵的原因。
过度指定是同一个错误，只是提前犯了
面对一个爱提问的智能体，人们自然的防御方式是提前把一切都讲清楚：把目录结构粘贴进提示词，列出所有命令，把命名约定一条条讲明，附上要遵循的模式片段。这看起来很负责任。实际上只是同一个错误换了张脸。
手写的上下文，会在代码继续演进的那一刻起就开始过时。当你在提示词里预先写上"我们把仓库层放在 app/Repositories"时，你其实是在赌：这句话现在依然成立，你记住了每一个相关细节，而且这些内容都没有让智能体偏向昨天的做法。通常这几个赌注里至少有一个会输，于是智能体就自信地在你提供的这个事实之上继续构建，而不是它本可以读到的那个真相。你把真正的工作——理解系统当前的状态——替换成了关于这项工作的工作，结果反而让产出变差了。
好的智能体会自己回答自己的问题
出路不是写一份更好的提示词，而是让智能体把你的指令当作目标，然后自己去核实事实。
这正是为什么一次 TaskGoblin 的运行会先把整个仓库克隆到它的沙箱里——不只是待审查的那部分差异，而是整棵工作树——这样第一手事实就摆在那里供它阅读。它会阅读文件、阅读它要修改区域的历史记录、阅读触发它的那个 issue 及其讨论，还有同一线程中前几次运行留下的交接记忆。它可以在沙箱里运行项目自己的命令，看看到底什么能真正构建通过、什么能真正跑通，而不是相信六周前有人在提示词里随手打下的一条构建命令。当它需要来自你所用工具的实时状态时，它会通过自己的集成直接读取，而不是要求你转达。
结果是，这个智能体最终达到的理解，和一位优秀工程师读上一个小时代码后所能达到的理解相当——只不过它只需要几秒钟，而且它面对的是代码今天的真实样子，而不是某个人记忆中的样子。
什么时候它仍然应该提问
这并不意味着智能体永远不该提问。真正值得问的问题，是代码本身确实无法回答的那些：你到底想要两种可接受行为中的哪一种，一次有风险的迁移是否在这次任务的范围之内，一个只存在于你脑海里的产品决策。这些不是蠢问题——它们是只有你才能做出的判断，而好的智能体会尽早、清晰地把它们摆出来，而不是靠猜。
这个区分正是关键所在。一个问你代码放在哪里的智能体，是在浪费它最擅长的能力。一个问你到底想构建这两种产品中的哪一个的智能体，则是把你的时间用在了你唯一最擅长的那件事上。我们构建 TaskGoblin，就是为了让它自己回答第一类问题，这样真正传到你这里的问题，才是真正值得你关注的那些。
