效果不好别急着怪模型——你可能连 Agent 都没开（一层层自查，看清你卡在哪）

发表于2026-08-24|更新于2026-09-15|AI

|总字数:6.1k|阅读时长:18分钟|浏览量:

很多人对 AI 的态度，建立在两个错误上。

一个是用的时候：效果不好，第一反应是”模型不行”。但有没有一种可能——你是在 chat 模式裸用的，连工具都没给；或者你甩了一句”帮我优化下”，然后怪它没懂你。

另一个是评的时候：拿一道”洗车店 50 米该开车还是走路”的残缺题去考 AI，AI 答”走路”就被制成表情包全网嘲。可那道题在传播中，早把”我想洗车”这个条件弄丢了。

这篇不聊怎么调 prompt 的玄学，而是给你一张分层自查表：你用不好 AI，基本就是下面四层里某层卡住了；而网上那些”AI 翻车”的笑话，往往也是出题人自己没说清。

先自测一下，答”否”越多，你越该往下读：

你用 AI 时，开的是 Agent、给了工具，还是一直拿对话框当万能？
你提需求，是”明确可验收的目标”，还是”帮我弄个好用的东西”这种猜谜？
你会不会把规划放权给强模型、让一般模型执行，并按任务选模型方向？
你会不会配 harness、权限、上下文，让分工真正落地？

这四层从下往上，顺序不能反。下面一层层拆。

一、先定位：你卡在哪一层的”使用断层”

很多人以为”用不好 AI”是个单一问题，要么怪模型、要么怪自己不会写 prompt。但真正的情况是一张分层图——你大概率是其中某一层断了，而且往往是最底下那层。

层	它在解决什么	典型症状（中了几条？）
L0 模式层	你给没给 AI 工具、开没开 Agent	一直用裸 chat；以为所有产品都一样；从没看过”模式”切换
L1 描述层	AI 知不知道”做完了”长啥样	甩”帮我优化下””做个高大上的 PPT”；连验收标准都没有
L2 授权/分层层	哪些放权 AI 去 plan、强模型还是一般模型干	要么事无巨细写死，要么全甩锅；不知模型有方向差异
L3 基建层	工具/权限/上下文能否落地	不会配 harness；模型再强也施展不开

有意思的是，绝大多数人卡在 L0，却跑去怪 L3 以上的东西。连 Agent 都没开，就在抱怨”模型不行”——这跟考一个不许打草稿的学生、然后宣布他数学差，是同一件事。这一点我们在《别让 AI 心算》里专门拆解过：chatbox 是让 AI 心算，Agent 是给它递草稿纸。

所以正确的排查顺序永远是：先确认模式 → 再谈描述 → 然后分层 → 最后搭基建。 下面按这个顺序走，每一层都先讲”为什么它排在这”，再讲”断了会怎样”。

二、最底层 L0：你可能连 Agent 都没开

为什么 L0 排第一？因为模式没开，上面所有技巧都是空谈。你连工具都没给 AI，描述再精准、分层再漂亮，模型也只是在一个没有手和脚的壳里空转。

这正好和《别让 AI 心算》联动：那篇说的 chatbox 和 Agent 的区别，本质是”有没有给草稿纸”。裸 chat 模式下，模型只能靠记忆心算——你问 3847 × 2763，它逐位”猜”答案，十有八九错；换成 Agent 模式让它写段代码真跑，一步都不会错。做数学、查资料、出文件全被阉割；Agent 模式下，它能写代码真跑、能读写文件、能深度搜索。同一个模型，两种形态的产出天差地别。

所以本文真正的核心观点得从工具的角度说：有些人整天觉得”模型不好、效果不好”，但有没有一种可能——他是在 chat 模式下用的，连工具都不给 AI，连 Agent 模式都没开？ 他拿一场闭卷口算的成绩，宣布这个学霸不行。这跟前面说的”描述问题””明确目标”是两件事：描述再好，你把 AI 绑在裸对话框上，它也施展不开。

为什么要从 Agent 基建的角度触发？一个现实原因是：Agent 工具本身也在变得越来越复杂。 从最早的”能跑一段代码”，到今天的文件系统访问、多步搜索、浏览器操作、子 Agent 调度、权限边界、上下文管理……基建的复杂度肉眼可见地涨。工具越强，不代表你自动就用得好；恰恰相反，工具越复杂，你越需要理解”怎么搭工作流”。

而本文的另一个目的也正在于此：让那些不会搭建 Agent 工作流的人，一出场（开箱）就能有一个好的体验。 不是要求每个人都去手写 harness、配沙箱、调权限，而是至少先搞清三件事——

先确认模式：快问快答用 chatbox；要让 AI 动手干活，请先开 Agent / 给工具，别拿 chat 当万能。
再谈描述：模式对了，才轮到”明确目标””简略授权”那些技巧发挥作用。
最后分层：强模型做规划、一般模型执行、选对能力方向、把基建边界设好。

顺序不能反。很多人卡在第一步——连 Agent 都没开，就在抱怨模型不行，后面的所有方法论对他都是空谈。

三、描述层 L1：一句话行不行，看是不是”明确目标”

过了 L0，才轮到描述。因为工具都给了，下一步要解决的问题是：你怎么把需求说清楚，让 AI 知道”做完了”长什么样。

先立一个判断标准：一句话能不能使唤动 AI，取决于这个目标有没有”验收标准”。

有明确目标的一句话：复现某个算法、按给定规范实现接口、把 A 格式转 B 格式、给报错定位原因。这类目标在现实里有标准答案或可判错的判据，AI 拿到就能展开。
猜谜式的一句话：”帮我优化下””写个好用的东西””做个高大上的 PPT””整理下数据”。没有验收标准，AI 只能凭语料编一个”看起来像那么回事”的东西。

关键结论：描述质量的第一性原理不是”详细”，是”目标可验证”。一个目标明确的人，哪怕只写一句话，AI 也有思路；一个目标模糊的人，写三段小作文，AI 也是在瞎蒙，因为连”对”长啥样都不知道。

这也是为什么”复现某个软件或算法”特别适合极简描述——Dijkstra 就是 Dijkstra，输入邻接表、输出最短路径，教科书有标准实现，你不用解释什么是图。但”做个用户系统”不行，因为每个人心里的边界都不一样。

下面分开发、生产、办公三个真实场景，把”明确目标”拆开揉碎。这一层例子最多，因为它最容易被一句话装下，也最容易被一句话搞砸。

开发：明确目标最容易被一句话装下

开发是”明确目标一句话”收益最高的地方，因为代码本身可验证——能跑、过测试、符合接口，就是对。

例 1：复现算法

❌ 猜谜式：”写个找最短路径的程序。”

AI 会问：什么图？有向无向？要权重要不要？返回路径还是距离？它只能自己编一套，大概率和你预期的数据结构对不上。

✅ 明确目标（一句话就够）：”用 Python 实现 Dijkstra，输入是邻接表 dict[int, list[tuple[int, float]]]，输出起点到所有点的最短距离 dict，附 3 个单元测试。”

这句很简略，但目标完全可验收：接口签名定死、输入输出定死、还要带测试。AI 根本不用猜，直接照标准算法写，写出来一跑测试就知道对不对。

例 2：业务功能实现

❌ 模糊：”做个用户登录。”

登录怎么存密码？用框架吗？返回 token 还是 session？表结构长啥样？AI 全得编。

✅ 简略但明确：”用 Flask + JWT 写登录接口，用户表字段 id/name/password_hash，密码用 bcrypt 校验，成功返回 access token，失败返回 401。”

这句没写”详细文档”，但把技术栈、表结构、加密方式、返回形态都钉死。剩下实现细节授权 AI 去 plan，它做得很有章法。

例 3：调试排错

❌ 灾难式：”我的代码报错了，帮我修。”（没有报错内容、没有上下文，AI 约等于算命）

✅ 明确目标：”pytest 在 test_calc.py:42 抛 AssertionError，期望 res == 5 实际是 None，compute() 作用是带缓存地算斐波那契。先告诉我可能哪错了，再给最小修复。”

这里目标非常清晰：定位 + 诊断优先 + 最小改动。AI 拿到的不是”救救我”，而是一个可被推理的问题定义。注意——这种”先诊断再改”的指令，本身就是把验收标准写进了过程。

例 4：解释与重构

❌ “解释下这段代码。”

✅ “用大白话解释这段 SQL 在算什么，重点讲清楚两个 JOIN 的关联逻辑，别贴代码，用三层意思说。”

后者明确了”输出形式”（大白话、讲 JOIN、三层、不贴代码），AI 的回答立刻从”把代码翻译一遍”变成”真的在解释”。

开发小结：凡是目标能被”接口 / 输入输出 / 验收方式”钉死的需求，一句话就够，因为代码天然可验证；凡是涉及”业务边界、产品定义、用户体验”这些没标准答案的部分，你省下的描述，AI 会用猜来补，补出来基本要返工。

生产：明确性不是省事，是安全

生产和开发最大区别是出错代价高。开发里 AI 写错代码，你本地跑挂了重来；生产里一句模糊的运维脚本，可能删错文件、清错库。所以生产里”明确目标”从”效果好不好”升级成”会不会出事”。

例 1：数据清洗

❌ “把数据整理一下。”

整理成啥？空值填 0 还是删掉？日期格式统一成哪种？输出什么文件？AI 一通操作，可能把脏数据清得更脏。

✅ “把 raw.csv 的 date 列转成 ISO 格式，无法解析的填 NaT，数值列空值填 0，输出 clean.parquet，保留原列顺序。”

这句简略，但每个动作都可验证、可回滚。生产里你要的就是这种”AI 做完你能立刻核对”的明确性。

例 2：运维脚本

❌ “帮我搞个清理临时文件的脚本。”

清哪？多久的？日志记不记？sudo 吗？这种一句话扔进 crontab，某天它可能把不该清的清了。

✅ “写个 shell 脚本，每天 3:00 删除 /tmp 下修改时间超过 7 天的文件，操作前先 dry-run 打印将要删除的清单，确认无误才真删，记录到 /var/log/clean.log。”

明确到”dry-run 再执行”，这就是把安全边界写进了目标里。

例 3：监控告警

❌ “给服务加个告警。”

告警啥指标？阈值多少？持续多久？通知到哪？AI 默认给你加个 CPU>90% 瞬时告警，结果半夜被抖动吵醒。

✅ “Prometheus 里对 api_server 配一条告警：CPU 使用率 > 80% 且持续 5 分钟才触发，通知到 #alerts 频道，附当前 top 进程。”

“持续 5 分钟”这一个条件，就把误报率压下去了——这种细节，就是明确目标和生产安全的接缝。

例 4：容器化部署

❌ “弄个 docker 把它跑起来。”

✅ “写 Dockerfile，基础镜像 python:3.12-slim，先拷 requirements.txt 装依赖再拷代码，暴露 8000，用非 root 用户运行，启动命令 gunicorn app:app -b 0.0.0.0:8000。”

“非 root 运行”这一句，是生产常识但 AI 不会主动给，你不写它就默认 root——明确目标在这里直接等于安全基线。

生产小结：生产里别迷信”简略”，要迷信”可核对 + 有边界”。一句话能用的前提是，这句话里藏着验收和止损条件。你省掉的每一个约束，都可能变成一次线上事故。

办公：目标 = 受众 + 格式 + 要点

办公里”验收标准”往往是人——老板满不满意、客户看不看得懂、听众抓不抓得住重点。所以办公里的明确目标，核心是把”受众”和”产出形态”说清。

例 1：写邮件

❌ “写个请假邮件。”

✅ “给主管写封请假邮件：明天病假一天，工作已交接给小李，语气正式但简短，结尾留联系方式。”

后者把受众（主管）、事由（病假一天）、状态（已交接）、语气（正式简短）全钉死，AI 写出来的能直接发。

例 2：做汇报 PPT

❌ “做个高大上的 PPT。”（经典猜谜，”高大上”是形容词不是目标）

✅ “给部门季度汇报做 8 页大纲，主题 Q3 用户增长，每页一个结论 + 数据支撑，用 bullet 不要大段文字，最后一页放风险和下一步。”

这句简略但目标清晰：页数、主题、每页结构、风格（bullet）、收尾内容都定了。AI 出的是大纲骨架，你填数据即可，而不是从零猜你要讲啥。

例 3：会议纪要

❌ “总结一下刚才的会。”

✅ “把这段会议录音整理成待办清单，按’负责人 — 事项 — 截止时间’三列，没提到截止的就标’待定’，去掉闲聊。”

“三列格式 + 去掉闲聊 + 待定标记”，这就是办公里的验收标准。没有它，AI 给你一段抒情散文。

例 4：给老板写摘要

❌ “把这份技术文档润色一下。”

✅ “把这份 20 页技术文档改写成给非技术老板看的一页摘要，只留三件事：做了啥、花了多少、有啥风险，用他的业务语言别用术语。”

受众（非技术老板）、长度（一页）、内容三角（做了/花了/风险）、语言要求（去术语）——全明确，产出才能直接用。

例 5：数据汇报

❌ “分析下这个月的销售。”

✅ “从 sales.xlsx 算出各区域环比增长率，给一句结论 + 一张’区域 — 本月 — 上月 — 环比’的表，环比下滑超 10% 的标红。”

“标红”这种小指令，就是办公场景里的明确性——它定义了什么叫”重点突出”。

办公小结：办公里”明确目标” = 说清受众是谁、要什么形态、突出什么。你越能把”老板想看什么”翻译成可执行的产出规格，AI 越像助理；你越甩形容词，AI 越像在帮你凑字数。

四、授权与分层 L2：简略描述的底气，来自”放权”和”分层”

描述清楚了，下一步要解决的问题是：怎么”省着用”描述——即把哪些事放权给 AI，又怎么调度不同模型。

模型变强后，描述确实可以更简略——但”简略”和”扔一句话就跑”是两回事。中间差着一层能力：授权。

你给一句”我想搞清楚用户流失和哪些行为相关，数据在 df 里，你先给分析思路，我确认后再跑”——很简略，但它做对了一件事：把”怎么分析”的规划和”从哪几个角度头脑风暴”的发散，明确授权给了 AI。 你没写具体看哪些字段、用什么方法，因为你信它能先想出来给你挑。

而”一句话甩锅”是：”帮我分析下这个数据。”——连边界都没给。简略描述的底气，来自你知道自己在授权什么；不是不知道给什么，而是主动选择不给细节，让 AI 去 plan、去头脑风暴补全。这是授权，不是偷懒。

真正的分层调度是：简略需求 → 丢给能力强的模型做规划和发散，把模糊补成详细方案 → 再把执行步骤交给一般点的、便宜的模型去跑。 像”架构师 + 施工队”。强模型贵但调用少，只用在最吃脑力的环节；一般模型便宜量大，负责把定好的方案机械执行。很多人以为”用好 AI = 找个最强模型一路用到底”，其实反过来——会分层的人，总成本更低、效果反而更稳，因为强模型不会被重复脏活拖垮上下文，一般模型也不会被硬塞不擅长的规划任务。

不会用 AI 的人卡在哪？要么全程一个模型（拿贵的当便宜的用，或拿便宜的硬扛规划），要么根本不知道”模型之间还有能力方向的区别”——有的推理强适合规划，有的代码稳适合执行，有的长上下文好，有的多模态，有的便宜适合批量。选错方向比描述不清更致命：让不擅长推理的模型做规划，怎么调 prompt 都救不回来。会用人则相反：他脑子里有一张”模型能力地图”，知道什么时候切到哪个、该把哪类任务交给哪个方向。

五、基建层 L3：让分工落地的最后一公里

描述和分层都想清楚了，最后要解决的问题是：怎么让这套分工真正跑起来——这就是基建。

基建视角：你会不会给 Agent 配工具、设权限、管上下文边界？同一个模型，接不接得上文件系统、能不能跑命令、上下文窗口怎么裁剪，体验天差地别。模型是发动机，harness 是底盘——描述再好，基建没搭对，AI 也落不了地。

工具使用者视角：人和 AI 的分工应该是——人是”总监”，定方向、做判断、兜底；AI 是”执行层”，负责展开和试错。你之所以敢把描述写得简略，是因为你信得过这层分工：方向你定，中间 plan 和头脑风暴放权给强模型，执行下沉给一般模型和工具。

把 L0–L3 合起来看，完整拼图是：

维度	它解决什么	不会用 AI 的人卡在哪
模式（L0）	给没给工具、开没开 Agent	连 Agent 都没开，裸 chat 当万能
目标明确性（L1）	AI 知不知道”做完了”长啥样	甩猜谜式一句话，连验收都没有
授权/分层（L2）	哪些放权 AI 去 plan、强还是一般模型干	要么写死，要么甩锅；不知模型有方向差异
Agent 基建（L3）	工具/权限/上下文能否落地	不会配 harness，模型再强也落不了地

合起来可以画一条”描述策略谱”：

明确目标型（复现算法、格式转换、按规范实现）——一句话就够，验收标准天然存在。
简略授权型（”先给分析思路我再确认”）——你给目标边界，plan 放权给强模型。
必须详细型（模糊业务、开放创作、涉及安全）——你越省描述，AI 越瞎编，反而要补背景约束。

不会用 AI 的人，在开发、生产、办公里翻的是同一类车：连 Agent 没开、描述不清、不会选模型、不会搭基建。

六、照照镜子：那些用来”考”AI 的荒谬一句话测试

前面都是从”你怎么用”讲。最后聊一类很能说明问题的现象：网上那些用来”证明 AI 不行”的一句话测试——它们往往也是出题人自己没说清、还不懂原理。

最出圈的是”洗车难题”。原问题是：”我想洗车，洗车店离我家 50 米，该开车还是走路？”答案显而易见——车得开过去才能洗。但 2026 年 2 月这题爆火后，传播链上发生了一件讽刺的事：很多人把”我想洗车”这个条件传着传着弄没了，变成了”离洗车店 50 米该开车还是走路”。然后拿这个残缺版去测 AI，AI 答”走路”就被当笑话疯传。

可如果真只给”离家 50 米有个洗车店”这一句，AI 列出几种情形反而合理：洗车店很大、50 米可能还在院子里走过去就行；你是员工走去上班；你把钥匙给店员让他开进去。模型没有”我在洗车”这个前提，只能按字面推理——这恰好是 L1 说的”目标不明确，AI 只能猜”。而且现实里洗车店面积差异本来就大，这场景本就没那么非黑即白。

更关键，很多人嘲讽时根本不知道大模型原理。CMU 后来发论文量化出”启发式主导比”：这题里”距离 50 米”这个表面线索对决策的影响力，是”洗车”这个目标线索的 8.7 到 38 倍。模型不是”蠢”，是被概率性地押注在更显眼线索上。而且人类对照组里，1 万个真人只有 71.5% 选开车——这题对人也没到”送分”程度。拿一个自己都可能答错、还被人改残了的题去宣布”AI 完了”，才是真荒谬。

同类测试还有一串：”9.11 和 9.9 哪个大”、”Strawberry 里有几个 R”、盘子放苹果上端去餐厅苹果在哪、动物过河问题……拿 Strawberry 说，很多人不知道：好一点的英文大模型处理拼写时，向量里会联动这个单词，把它按字母顺序拆开、带一套额外的关联值，所以有可能猜对。这不是”数了字母”，而是大模型本质是概率性的——预测下一个 token 基于概率分布，不是查字典。

被忽视的真相：严格意义上，人说话其实也是概率性的。 你脱口而出的下一个词，也是基于语境和习惯的概率，不是逐字检索。既然如此，”概率性”不该被当成 AI 原罪。不懂原理的人，用”它数不对字母”证明 AI 不行，约等于用”人也会口误”证明人没智能。

把这一节和前面串起来：那些一句话测试翻车，往往不是模型不行，而是出题人既没把条件说清（甚至传播中把条件丢了），也不懂模型怎么工作。而当你真想用好 AI，前文说的多模型交叉验证（让几个模型就难题互辩，单个翻车的错误很快被纠正）、以及补上下文（把目标讲清楚，启发式就被推理压过），才是正经解法——别拿残缺题和概率性当笑料，先把自己问题描述清楚。