最近这几个月，我一直在高强度折腾 Vibe Coding，我发现了一个特别反直觉的现象：当你面对越来越强大的 Agent 时，你给出的提示词越详细、规定的步骤越精确，它最后交付的结果反而越差。
然后我突然意识到，这其实是软件工程里臭名昭著的 X-Y Problem，正在 AI 时代以一种全新的形态大规模重演。
什么是 X-Y 问题？很多非技术童鞋可能对这个概念比较陌生，我举个例子：
你周末坐在卧室打游戏，网络卡得走不动道。你花了一上午查资料，然后跑去数码论坛发帖求助：“请问怎么硬改路由器的天线，并刷入第三方固件来锁定特定的信道频段？”
论坛里的大神们围着这个问题讨论了半天，给你丢了一堆复杂的电焊教程和底层编译代码，结果你折腾到半夜，路由器直接变砖了。
直到有个老鸟多问了一句：“你费这么大劲，到底想干嘛？”
你回答：“我就是坐在卧室打游戏老掉线，想让网速稳一点。”
老鸟无语了：“那你直接花 20 块钱买根十米长的网线插上啊！折腾什么路由器？”
这就是典型的 X-Y 问题：你试图解决核心问题 X，但你凭经验觉得方案 Y 能搞定，于是你跑去死磕“怎么实现 Y”，绝口不提 X。结果大伙儿跟着你在 Y 的泥潭里挣扎，最后发现 Y 压根就不是个好方案。
这个老生常谈的沟通陷阱，放在现在的 AI 时代，反而成了我们自己给自己挖的坑。
提示词工程的“路径依赖”
在 LLM 刚诞生那会儿，为了控制大模型的行为和输出质量，我们诞生了一门玄学——提示词工程（Prompt Engineering）。
那时候大家都习惯了写巨长的 Prompt，把 AI 当成一个聪明但毫无经验的实习生去指导。有时候甚至精确到每一个步骤：第一步干什么，第二步干什么，强制它使用特定的逻辑链。这在当时是合理的，但也让我们养成了一个坏习惯：我们习惯了把嚼碎的方案 Y 直接喂给 AI。
现在的 AI，不再需要你教它做事
但是这个原则放在现在，逐渐不太适用了。当我们步入 Agent 时代，大模型具备了极强的逻辑推理、工具调用和自主探索能力。这个时候，精确的计划和详细的执行步骤，反而成了限制模型能力的枷锁。
举个例子。假设你刚在微信群里收集了几十个人的团建报名和餐饮忌口接龙，格式五花八门，有带括号的，有带全角冒号的，乱七八糟。
按照以前的习惯，你可能会给 Agent 下达这样的指令：“帮我写一段 Excel 提取公式：先查找冒号前面的名字，再用正则截取后面的菜品，如果遇到括号里的过敏备注，就用 MID 函数提取到 C 列。”
好家伙，你连数据清洗的实现路径都帮它规定死了。Agent 乖乖照做，给了你一段嵌套了三四层的天书公式。结果呢？你把公式贴进表格，就因为某个人少打了一个冒号，或者用错了中英文符号，公式直接大面积报错 #VALUE!。最后你花在修补公式上的时间，比纯手动复制粘贴还要多。
但如果你直击本质，把真实需求抛给它：“这是一段格式极度混乱的微信群接龙记录，帮我统计一下所有人的报名情况和饮食禁忌，直接给我整理成一个干净的 Markdown 表格。”
让它自己去发挥（Explore），它根本不需要费劲去写什么脆弱的 Excel 公式。它直接利用大模型极其强大的自然语言理解能力，无视了所有的错别字和符号不统一，五秒钟内直接把一份完美的表格“画”在了你的屏幕上。
Let it think：思维转换
这就是新时代的 X-Y Problem：你需要实现功能 X，你认为可以通过 Y 这样实现，然后告诉 Agent 用 Y 实现；其结果绝对不如直接告诉 Agent 你需要实现 X。
精确的计划和详细的执行步骤，在 Agent 面前不再是“清晰的指令”，而是“视野的遮罩”。大模型的脑子里装着无数条通往罗马的道路，当你强制它走你铺好的那条小道（Y）时，你就扼杀了它乘坐飞机直接空降罗马（X）的可能性。
所以，面对越来越强大的 AI，我们需要完成一次思维模式的跃迁：
1. 从“微观管理者”变成“产品经理”
不要再纠结于具体的执行细节。我们现在的核心价值，在于清晰地定义需求（X），提供充足的背景信息（Context），设定好边界（比如预算、稳定性要求），然后对 Agent 交付的结果进行验收。
2. 永远问自己：这是 X 还是 Y？
在敲下回车键让 AI 开始生成之前，审视一下你的 Prompt：你是在描述你面临的困境（X），还是在要求 AI 帮你完善一个你脑子里的半成品方案（Y）？如果是后者，退后一步，把原始问题抛给 AI 看看。
在过去，人类负责构思方案，机器负责执行。
在早期 AI 时代，人类负责提供步骤，AI 负责生成细节。
而在 Agent 时代，人类的终极任务，是提出一个真正有价值的好问题。
