我的 Agent 总是调错工具,我一直骂模型"笨",直到我读了一遍自己写的工具描述:模糊得连我自己都看不懂

这是一个让我从"甩锅给模型"到"反躬自省"的故事。我做了一个有好几个工具的 AI Agent——有查订单的、有查物流的、有查退款政策的、有发起退款的。可它用起来,总是"不太聪明":用户问"我的订单到哪了",它有时去调了"查订单"工具(只查到了订单状态、没查到物流),有时甚至去调了"查退款政策";用户想退款,它有时却去调了"查退款政策"而不是"发起退款"。总之,它经常选错工具,或者该调 A 却调了 B。

一开始,我把这一切,都归咎于"模型不够聪明"——"这模型真笨,这么简单的意图都判断不对!"我甚至想换个更强的模型。可在换之前,我抱着试试看的心态,做了一件事:我把我给这些工具写的"描述(description)",一条条地,认真读了一遍。读完,我羞愧得脸都红了——我那些工具描述,写得模糊、含混、甚至有歧义,模糊到连我自己,都很难一眼分清"这个工具到底是干嘛的、什么时候该用它"!比如,"查订单"工具我写的描述是"获取订单信息",而"查物流"我写的是"获取订单的物流信息"——这俩描述这么像,模型怎么分得清"查订单到哪了"该用哪个?我这才幡然醒悟:Agent 调用工具,完全是依据我给每个工具写的那段"描述",来判断"这个工具是干什么的、什么场景该用它"的。而我那些写得又烂又模糊的描述,根本没能给模型,提供清晰、准确的判断依据——模型不是"笨",它只是,在我给它的、那些糟糕的信息的基础上,已经尽力了。我一直在骂模型笨,可真正"笨"的,是我那些写得稀烂的工具描述。

故障现场:连人都看不懂的工具描述

我把我那些"烂描述",和改进后的"好描述",对比一下,你一看就明白差距了:

# 我最初写的工具描述(又烂又模糊, 模型当然分不清)
tools = [
    {
        "name": "query_order",
        "description": "获取订单信息",      # ✗ 太模糊! "订单信息"包含什么? 物流算不算?
    },
    {
        "name": "query_logistics",
        "description": "获取订单的物流信息",  # ✗ 和上面太像! 模型怎么分清?
    },
    {
        "name": "refund_policy",
        "description": "退款相关",          # ✗ "退款相关"?! 是查政策还是发起退款??
    },
    {
        "name": "do_refund",
        "description": "退款",             # ✗ 和上面的 refund_policy 撞了! 都跟退款有关!
    },
]
# 模型拿到这些描述, 面对"我的订单到哪了":
#   - "获取订单信息" vs "获取订单的物流信息" —— 俩都沾边, 模型蒙了, 经常选错。
# 面对"我要退款":
#   - "退款相关" vs "退款" —— 这俩到底啥区别?? 模型分不清, 经常调错。
# → 不是模型笨, 是我给的"描述", 根本没让模型分得清这些工具的区别和用途!

看着自己写的这些"描述",我恨不得找个地缝钻进去。问题的核心,是我没有理解 Agent 调用工具的根本机制:大模型在决定"该调用哪个工具、传什么参数"时,它唯一的依据,就是我为每个工具提供的那段"描述(以及工具名、参数说明)"。它会把用户的意图,和每个工具的"描述",做匹配,然后选出它认为"最匹配"的那个。这就意味着:工具描述的"质量",直接、且决定性地,影响着模型选择工具的"准确率"。一段清晰、准确、能让模型一眼分清"这个工具是干嘛的、什么时候该用"的描述,会引导模型做出正确的选择;而一段模糊、含混、有歧义的描述,则会让模型"无所适从"、频频选错。而我写的那些描述,恰恰是后者:"获取订单信息"和"获取订单的物流信息"——两者高度雷同,模型面对"订单到哪了"这个意图,根本分不清该用哪个;"退款相关"和"退款"——这俩描述简直是在"难为"模型,它怎么可能分清"一个是查政策、一个是真退款"?所以,模型频频选错工具,根本不是它"笨",而是我提供给它的"判断依据(工具描述)",本身就是模糊的、有歧义的、连人都看不懂的!模型,只是在我给的这堆烂信息的基础上,做出了它能做出的、最好的(但依然经常出错的)判断。我一直怪罪的"笨模型",其实一直在替我那些"烂描述",背着黑锅。

第一件事:搞懂 Agent 是"靠描述来理解和选择工具"的

定位到根源,我必须把"Agent 如何理解和选择工具"这个机制,彻底搞清楚:对一个 AI Agent 来说,它看不到你工具的内部实现(它不知道 query_order 这个函数里写了什么代码);它能"看到"的,只有你为这个工具提供的"元信息"——工具名(name)、描述(description)、参数定义(parameters)。它就是纯粹地,根据这些"文字描述",来理解"这个工具是干什么的、什么时候该用它、该传什么参数"的。所以,这些描述,就是 Agent 认识和使用你工具的唯一窗口;描述写得好不好,直接决定了 Agent 用得对不对。

Agent 如何理解和选择工具:

# Agent 看不到工具的"实现", 只看得到工具的"描述(元信息)":
#   工具 = { name(名字), description(描述), parameters(参数定义) }
#   ↑ Agent 对这个工具的全部认知, 就来自这三样"文字"!

# Agent 选工具的过程(简化):
#   1. 理解用户的意图(用户想干什么)
#   2. 把这个意图, 和每个工具的"描述", 做匹配
#   3. 选出"描述最匹配这个意图"的那个工具
#   4. 根据工具的"参数定义", 从对话里提取/生成参数

# 所以, 工具描述, 就是 Agent 的"工具说明书":
#   - 说明书写得清楚 → Agent 知道每个工具是干嘛的、何时用 → 选得准
#   - 说明书写得模糊/有歧义 → Agent 分不清、蒙圈 → 选得错(我的坑)

# 一个关键的认知转变:
#   写 Agent 的工具, 不只是"写好工具的代码实现",
#   更重要的, 是"写好工具的描述"—— 因为那是 Agent 理解工具的唯一依据!
#   → "工具描述", 是给"AI 这个使用者"看的"说明书", 要为 AI 写清楚。

# 这本质上是一种"提示工程(prompt engineering)":
#   工具描述, 是你给模型的"提示"的一部分;
#   提示给得清楚, 模型表现就好; 提示给得烂, 模型表现就差。
#   "Garbage in, garbage out"——你给的信息烂, 模型的输出就烂。

原理终于清晰了。对一个 AI Agent 而言,它看不到你工具的内部实现(它不知道你那个函数里写了什么代码);它能"看到"的,只有你为工具提供的"元信息"——工具名、描述、参数定义。它就是纯粹地、完全地,依据这些"文字",来理解"这个工具是干什么的、什么时候该用它、该传什么参数"。所以,Agent 选工具的过程是:理解用户意图 → 把意图和每个工具的"描述"做匹配 → 选出"描述最匹配"的那个。这意味着,工具的"描述",就是 Agent 认识和使用你工具的唯一窗口、就是给 Agent 看的"工具说明书"——说明书写得清楚,Agent 就知道每个工具是干嘛的、何时用,选得准;说明书写得模糊、有歧义,Agent 就分不清、蒙圈,选得错(正是我的坑)。这给了我一个重要的认知转变:写 Agent 的工具,不只是"写好工具的代码实现",更重要的、也更容易被忽略的,是"写好工具的描述"——因为那,才是 Agent 理解和使用工具的唯一依据!而这,本质上,是一种"提示工程(prompt engineering)":工具描述,是你给模型的"提示"的一部分;提示给得清楚,模型表现就好;提示给得烂,模型表现就差。"Garbage in, garbage out(垃圾进,垃圾出)"——我给模型的工具描述是垃圾,模型选工具的表现,自然也好不到哪去。我一直怪模型笨,可问题的根源,是我喂给它的"提示(工具描述)",本身就是垃圾。

第二件事:正解——把工具描述,当成"给 AI 看的说明书"来认真写

搞懂了根因——"描述模糊,模型没法分清工具"——正解就清晰了:把每个工具的描述,当成一份"写给 AI 看的、清晰准确的说明书"来认真打磨——清楚地写明"这个工具是做什么的、什么时候该用它(以及什么时候不该用)、每个参数是什么";对于容易混淆的工具,更要明确地写出它们的"区别"。

# 正解: 把工具描述, 当成"给 AI 看的说明书"来认真写
tools = [
    {
        "name": "query_order_status",
        # ✓ 清楚地写: 做什么 + 何时用 + 和相似工具的区别
        "description": "查询订单的【状态】(如待付款、已发货、已完成)和基本信息"
                       "(下单时间、金额、商品)。注意: 本工具【不查物流轨迹】,"
                       "用户问'物流到哪了/快递信息'时, 请用 query_logistics。",
    },
    {
        "name": "query_logistics",
        "description": "查询订单的【物流轨迹】(快递公司、运单号、当前位置、"
                       "配送进度)。当用户问'我的快递/包裹到哪了''什么时候到'时, 用本工具。",
    },
    {
        "name": "query_refund_policy",
        "description": "查询退款【政策/规则】(如几天内可退、什么条件可退)。"
                       "仅用于'解答关于退款规则的咨询', 【不会真的发起退款】。",
    },
    {
        "name": "create_refund",
        "description": "为指定订单【实际发起退款】操作(会真的退钱!)。"
                       "仅当用户【明确要求为某个具体订单退款】时使用。这是高危操作。",
        "parameters": {
            "order_id": {"type": "string", "description": "要退款的订单号(必填)"},
        },
    },
]
# 改进后, 模型一看描述, 就清清楚楚:
#   "订单到哪了" → query_logistics(描述明确说了"物流轨迹""快递到哪了用本工具")
#   "退款规则" → query_refund_policy(明确"查政策, 不真退款")
#   "给我退款" → create_refund(明确"实际发起退款, 用户明确要求时")
# → 描述清晰了, 模型选工具的准确率, 立刻大幅提升!

这个正解的核心,是转变一个意识:工具描述,不是写给"人(你自己)"看的、可以随便糊弄的注释,而是写给"AI 这个使用者"看的、必须清晰准确的"说明书"——你要像给一个新人写操作手册那样,把每个工具,讲得明明白白。一份好的工具描述,应该清楚地包含几样东西:这个工具做什么(查物流轨迹)、什么时候该用它(用户问"快递到哪了"时)、甚至什么时候不该用它(本工具不查物流);对于容易混淆的工具,还要明确地点出它们的区别(查政策 vs 真退款);对于参数,也要说清每个参数是什么。你看我改进后的描述:"查询订单的物流轨迹……当用户问'快递到哪了'时用本工具"、"查询退款政策……不会真的发起退款"、"实际发起退款……仅当用户明确要求为某个具体订单退款时使用"——这些描述,把每个工具的用途、适用场景、和相似工具的区别,都讲得清清楚楚。于是,模型再面对"订单到哪了",一看描述,就知道该用 query_logistics;面对"给我退款",就知道该用 create_refund。描述清晰了,模型选工具的准确率,立刻就大幅提升了——而我,根本没换模型,只是把那些烂描述,改成了清晰的说明书。这印证了那句话:与其抱怨工具(模型)笨,不如先把给它的'说明书(描述)',写清楚。

下面这张图,对比了"烂描述"和"好描述"对 Agent 选工具的影响:

这张图的对比很清楚:左边红色那条,工具描述模糊、雷同、有歧义,模型分不清哪个工具合适、频频选错,而你还以为是模型笨;右边绿色那条,工具描述清晰地写明"做什么+何时用+和相似工具的区别",模型一眼看清每个工具的用途、准确地选对工具。两条路的根本分野,在于你有没有把工具描述,当成"给 AI 看的说明书"认真写清楚。

第三件事:写好"给 AI 看的提示",是一门正经的功夫

填平了"工具描述"这个坑,我意识到:这其实是"提示工程(prompt engineering)"的一个具体体现。我系统地总结了一些"如何为 AI 写好提示/描述"的要点:

如何为 AI 写好"提示/工具描述"(提示工程的要点):

# 1. 清晰、具体, 别模糊
#   ✗ "获取订单信息"  ✓ "查询订单的物流轨迹(快递公司、运单号、当前位置)"

# 2. 写明"何时用"和"何时不用"(给出适用边界)
#   "当用户问 X 时用本工具; 注意, Y 情况请用另一个工具"

# 3. 消除歧义, 尤其点出相似项的区别
#   有多个相似工具时, 在描述里明确写出它们的区别, 帮模型区分。

# 4. 给例子(few-shot)往往很有效
#   "例如, 用户说'我的快递到哪了', 应调用本工具。"

# 5. 参数说明要清楚: 每个参数是什么、什么格式、是否必填
#   "order_id: 要查询的订单号, 字符串, 必填"

# 6. 关键约束/注意事项要强调
#   "这是高危操作(会真的退钱), 仅在用户明确要求时使用。"

# 7. 站在 AI 的角度想: "如果我是模型, 看了这段描述, 能准确判断吗?"
#   写完, 自己读一遍, 问: 它清楚吗? 有歧义吗? 够模型做对决策吗?

# 核心: 模型的表现, 极大地取决于你给它的"提示/上下文/描述"的质量。
#   "写好给 AI 看的提示", 不是雕虫小技, 而是用好 AI 的一门核心功夫。
#   很多时候, "模型表现不好", 不是模型的错, 而是你的"提示"没写好。

这一总结,让我对"提示工程"这门功夫,有了正经的认识。我这次的坑,本质上,就是"提示工程"没做好——工具描述,是我给模型的提示的一部分,而我没把它写好。而"如何为 AI 写好提示/描述",是有章法、有要点的:清晰具体(别写"获取订单信息"这种模糊的,要写"查询物流轨迹,包含快递公司、运单号、当前位置");写明适用边界(何时用、何时不用);消除歧义(尤其点出相似工具的区别);给例子(few-shot,"例如用户说 X 时用本工具",往往很有效);参数说清楚;强调关键约束(这是高危操作)。而其中最重要的一条,是"站在 AI 的角度想"——写完一段描述/提示,自己以"模型"的身份读一遍,问问自己:"如果我是模型,看了这段话,我能准确地判断吗?它清楚吗?有歧义吗?够我做对决策吗?"我那次,正是从来没站在模型的角度,审视过我写的那些描述——所以我才写出了连自己都看不懂的、模糊的描述。归根结底,我领悟到一个用好 AI 的核心道理:模型的表现,极大地取决于你给它的"提示、上下文、描述"的质量。"写好给 AI 看的提示",绝不是雕虫小技,而是这个 AI 时代,用好 AI 的一门核心功夫。很多时候,我们抱怨"模型表现不好",其实,不是模型的错,而是我们没有把"给它的提示",写好。学会清晰、准确地,向 AI 表达你的需求和提供它所需的信息,是和 AI 高效协作的、第一项、也是最重要的一项能力。

第四件事:工具设计本身,也影响 Agent 用得好不好

除了"描述",我还反思了"工具设计"本身——我发现,工具该怎么划分、怎么设计,同样深刻地影响着 Agent 能不能用好它们。我总结了几条"为 Agent 设计工具"的原则:

为 Agent 设计工具的原则(不只是写好描述, 工具本身也要好设计):

# 原则1: 工具的"职责"要单一、清晰, 别"大而全"
#   ✗ 一个 "manage_order" 工具, 又能查、又能改、又能退 → 模型难判断、易用错
#   ✓ 拆成 query_order / update_order / refund_order, 各管一摊, 清晰

# 原则2: 工具的"粒度"要合适
#   - 太细: 工具太多, 模型选择困难(几十个工具, 选都选晕了)
#   - 太粗: 一个工具干太多事, 参数复杂, 模型容易传错
#   → 找一个"既不太多、又职责清晰"的平衡。

# 原则3: 工具名要"见名知意"
#   ✗ tool_1, do_stuff, handle  ✓ query_order_status, create_refund
#   好的工具名, 本身就是一种"提示"。

# 原则4: 参数设计要简单、明确
#   - 参数越少越简单, 模型越不容易传错
#   - 用枚举(enum)限定取值范围, 别让模型自由发挥("status 必须是 A/B/C 之一")
#   - 必填/选填要清楚

# 原则5: 工具的返回, 要清晰、对模型友好
#   - 返回的内容, 要让模型能看懂、能用于下一步决策
#   - 出错时, 返回清晰的错误信息(让模型知道哪错了、能纠正)

# 原则6: 减少"相似/易混淆"的工具
#   - 如果两个工具功能相近, 考虑合并, 或在描述里极力区分。

核心: Agent 用工具用得好不好, 是"工具设计 + 工具描述"共同决定的。
  你给 Agent 的工具集, 就像给一个新员工的"工具箱和说明书"——
  工具箱设计得合理、说明书写得清楚, 它才能用好。

这一反思,让我对"为 Agent 设计工具"有了更全面的认识。Agent 用工具用得好不好,不只取决于"描述"写得好不好,还取决于"工具本身设计得好不好"。几条关键的设计原则:原则1(职责单一):别设计"大而全"的工具(一个工具又能查又能改又能退,模型难判断、易用错),要拆成职责单一、清晰的小工具。原则2(粒度合适):工具太细则数量太多、模型选择困难,太粗则一个工具干太多事、参数复杂易传错,要找一个平衡。原则3(见名知意):工具名本身就是一种提示,create_refund 比 do_stuff 好得多。原则4(参数简单明确):参数越少越不易传错,用枚举限定取值范围(别让模型自由发挥),必填选填要清楚。原则5(返回对模型友好):工具的返回要让模型能看懂、能用于下一步决策,出错时返回清晰的错误信息(让模型能纠正)。原则6(减少相似工具):功能相近的工具考虑合并、或极力区分。这些原则共同说明:你给 Agent 的工具集,就像给一个新员工的"工具箱 + 说明书"——工具箱(工具设计)设计得合理、说明书(工具描述)写得清楚,这个新员工(Agent)才能用好它们、把活干漂亮。如果工具箱里塞满了职责不清、名字混乱的工具,说明书又写得含糊其辞,那再聪明的员工,也会频频用错。把'工具设计'和'工具描述'都做好,是让 Agent 能可靠地使用工具的、两个同等重要的方面。把工具设计的原则整理成一张表:

第五件事:别急着怪工具,先看看自己给的"输入"对不对

这次踩坑,在思维层面给了我最大的触动——它纠正了我"一遇问题就甩锅给工具"的坏习惯。我把这个反思沉淀了下来:

深刻反思: 别急着怪工具(模型), 先看看自己给的"输入"

# 我的第一反应(错误的): "模型真笨!"
#   - 把问题, 第一时间, 归咎于"工具/外部"
#   - 想着"换个更强的模型"(换工具), 而不是"改进我自己的输入"

# 真相: 问题出在"我给的输入"(模糊的工具描述), 而非"工具"

# 这是一个普遍的、值得警惕的思维误区:
#   - 代码报错 → "这库有 bug!"(其实是自己用错了)
#   - 模型表现差 → "这模型笨!"(其实是自己提示没写好)
#   - 工具不好用 → "这工具烂!"(其实是自己没看文档、没用对)
#   → 习惯性地"甩锅给外部", 而不去反省"自己的输入/用法"。

# 正确的思维顺序:
#   遇到问题, 先反省: "是不是我自己给的输入/用法有问题?"
#   - 模型表现差 → 先检查: 我的提示/描述, 写清楚了吗?
#   - 库报错 → 先检查: 我用对了吗? 看文档了吗?
#   - 确认自己这边没问题了, 再去怀疑工具本身。

# 为什么先反省自己? 因为:
#   1. "自己的输入有问题"的概率, 往往大于"成熟工具有 bug"的概率。
#   2. "改进自己的输入", 是你能控制的; "工具有 bug", 你也改不了。
#   3. 先反省自己, 能让你更快地, 找到那个"真正能解决问题"的方向。

核心: 工具(尤其 AI)的输出质量, 极大地取决于你给它的输入质量。
  遇到"工具表现不好", 先别急着甩锅, 而要先反省: "我给它的输入, 够好吗?"

这层反思,是这次踩坑给我最高维度的收获。复盘我的第一反应——"这模型真笨!"——我发现,自己有一个很坏的思维习惯:一遇到问题,就第一时间、习惯性地,把锅甩给"工具/外部",想着"换个更强的模型"(换工具),而不是"改进我自己的输入"。可真相是,问题恰恰出在"我给的输入"(那些模糊的工具描述)上,而非"工具(模型)"本身。而这,是一个普遍的、值得警惕的思维误区:代码报错,就怪"这库有 bug"(其实是自己用错了);模型表现差,就怪"这模型笨"(其实是自己提示没写好);工具不好用,就怪"这工具烂"(其实是自己没看文档、没用对)——我们太习惯于"甩锅给外部",而不去反省"自己的输入和用法"。而正确的思维顺序,应该是:遇到问题,先反省"是不是我自己给的输入/用法有问题?"——模型表现差,先检查"我的提示写清楚了吗";库报错,先检查"我用对了吗、看文档了吗";确认自己这边确实没问题了,再去怀疑工具本身。为什么要"先反省自己"?因为:第一,"自己的输入有问题"的概率,往往大于"一个成熟工具有 bug"的概率;第二,"改进自己的输入",是你能控制的,而"工具有 bug",你也改不了;第三,先反省自己,能让你更快地,找到那个"真正能解决问题"的方向(就像我,反省自己、改了描述,问题就解决了,根本不用换模型)。归根结底:工具(尤其是 AI)的输出质量,极大地取决于你给它的输入质量;遇到"工具表现不好",先别急着甩锅,而要先反躬自省一句——"我给它的输入,够好吗?"这份'先内省、再外求'的习惯,不仅能让你更高效地解决问题,更是一种难得的、成熟的心态。把"甩锅给外部"和"先反省自己"两种思维对比成一张表:

一套"该怎么给 Agent 写工具"的决策流程

把这次踩坑的全部教训,我浓缩成了一张"为 Agent 设计/描述工具时,该怎么做"的决策图,贴在了团队做 Agent 的文档里:

这张图,把我"血泪换来"的整套方法论,串成了一条可执行的路径:给 Agent 加工具,先把工具本身设计好(职责单一、名字见名知意);再认真写描述——做什么、何时用、何时不用/和谁易混、参数是什么;写完,站在 AI 的角度自检一遍(读着模糊就重写,直到清晰无歧义);上线后,观察 Agent 选工具准不准——如果选错了,第一反应不是怪模型,而是回头看描述够不够清。这条路径里,我特意标黄了那个最关键的、也是我曾经�best错的环节——"别先怪模型,先回头看描述":这正是我这次最深的教训,把它放在流程里,提醒自己和团队,永远别再犯。

我立下的几条"给 Agent 设计工具"的规矩

这次"骂错了模型"的踩坑,让我把"如何为 Agent 设计和描述工具"这件事,认真地立成了几条规矩:

1. 工具描述,是写给 AI 看的"说明书",必须认真写。它不是可有可无的注释,而是 Agent 理解和选择工具的唯一依据。描述写得好不好,直接决定 Agent 用得对不对。
2. 描述要清晰、具体,杜绝模糊和歧义。别写"获取订单信息"这种含混的,要写"查询订单的物流轨迹(快递公司、运单号、当前位置)"这种具体的。
3. 写明"何时用"和"何时不用"。给出工具的适用边界,尤其对相似工具,要明确点出它们的区别,帮模型区分。
4. 参数说明要清楚。每个参数是什么、什么格式、是否必填,都讲明白;用枚举限定取值范围。
5. 工具本身也要设计好。职责单一、粒度合适、名字见名知意——好的工具设计,本身就降低了模型用错的概率。
6. 站在 AI 的角度自检。写完一段描述,以"模型"的身份读一遍,问:"我看了这段,能准确判断吗?有歧义吗?"
7. Agent 表现不好,先反省自己的输入,别急着怪模型。模型选错工具,先回头看是不是描述没写清——大多数时候,问题出在我们给的"提示"上,而非模型本身。

写在最后

这次"我一直骂模型笨,最后发现是自己工具描述写得稀烂"的经历,是我在 AI 应用开发路上,一次很打脸、却也很受用的成长。它教给我的,远不止"工具描述要写清楚"这一条技术经验,更是一种用好 AI 的根本心态——AI(模型)的输出质量,极大地、决定性地,取决于你给它的输入(提示、上下文、工具描述)的质量。"Garbage in, garbage out"——你给的信息是垃圾,它的输出就是垃圾;你给的信息清晰准确,它才能表现出色。

所以,当你的 Agent 表现不好、当模型"不听话"、当 AI"很笨"的时候,请先别急着骂它、别急着想换个更强的模型——而要先冷静地、反躬自省地,回头看一眼:我给它的输入,够好吗?我的提示,写清楚了吗?我的工具描述,有歧义吗?很多时候(就像我这次),你会发现,那个"笨"的,根本不是模型,而是我们自己提供的、那些模糊不清的信息。学会清晰、准确地向 AI 表达需求、提供它所需的信息——这门"给 AI 写好提示"的功夫,正是这个 AI 时代,我们每个人都该修炼的、用好 AI 的第一项核心能力。

愿你的 Agent,都能用上清晰的"说明书";也愿你我,在抱怨工具之前,都能先反省一下自己的输入。共勉。

—— 别看了 · 2026