如何让AI真正用好你的工具：Claude Code

目录如何让AI真正用好你的工具Claude Code一个让人困惑的现象为AI写工具和传统编程有什么区别三步迭代法从原型到精良工具第一步快速搭建原型第二步运行评估用数据说话第三步与AI协作迭代黄金设计法则法则一克制是美德不要提供所有工具法则二命名即引导划定边界法则三返回上下文而非数据法则四Token效率是隐形天花板法则五工具描述需要提示词工程结语从程序员到认知架构师如何让AI真正用好你的工具Claude Code我们一直在用编写确定性系统的思维来为非确定性系统设计工具。这种错位是AI智能体用不好工具的根本原因。一个让人困惑的现象你是否遇到过这样的情况精心封装了一个天气查询API告诉AI“输入城市名返回天气信息”。结果AI问用户“您所在城市的邮编是多少”——它自己把“城市名”理解成了“邮编”。又或者你给AI配置了通讯录搜索工具它每次搜索都返回全部1000个联系人然后在上下文中逐条“阅读”消耗海量Token速度慢得像蜗牛爬。更常见的是你把内部所有微服务都封装成了工具兴致勃勃地交给AI结果它要么在几十个工具之间反复横跳要么干脆“忘记”了某些工具的存在。这不是AI“笨”而是我们的工具设计出了问题。我们一直在用编写确定性系统函数的思维来为非确定性系统AI设计“认知工具”。这种错位才是问题的根源。在构建Claude Code的过程中Anthropic团队经历了从“写工具”到“为AI设计认知延伸”的范式转变。这篇文章就是他们的实战复盘。为AI写工具和传统编程有什么区别先看一个例子。传统编程中你写一个get_all_contacts()函数返回所有联系人。程序遍历列表逐个处理毫无压力——计算机内存廉价CPU循环高效。但如果AI智能体调用同样的工具返回1000个联系人它需要逐Token阅读每一个人名、邮箱、电话。这不仅消耗宝贵的上下文窗口还让AI在无关信息中“游泳”难以聚焦真正相关的联系人。对计算机来说廉价的操作对AI来说可能是沉重的认知负担。这意味着为AI设计工具本质是在设计它的认知延伸——工具决定了AI能“看到”什么、如何“思考”、怎样“行动”。好的工具扩展AI的能力边界差的工具则成为AI的认知枷锁。基于这个认知Anthropic团队摸索出了一套方法论。三步迭代法从原型到精良工具第一步快速搭建原型别在会议室里反复推敲工具设计。先做一个能用的版本放到真实场景中测试。如果你用Claude Code来编写工具记得把相关SDK和API的文档提供给Claude。Anthropic官方推荐在文档网站提供llms.txt文件例如他们的API文档就有方便AI直接读取。将工具封装到本地MCP服务器或桌面扩展DXT中在Claude Code或Claude Desktop里实际跑一跑。亲自测试找到那些“看起来没问题但AI就是用不好”的粗糙之处。关键洞察很多设计缺陷只有在AI真正调用时才会暴露。纸上谈兵发现不了问题。第二步运行评估用数据说话这是整个方法论中最有价值的环节。生成评估任务让Claude Code基于你的工具快速生成数十个“提示词-响应对”。提示词必须基于真实使用场景和真实数据——内部知识库、真实客户记录、实际业务逻辑。避免使用过于简单的“沙盒”环境那会让工具在虚假的舒适区里看起来很完美一上战场就垮掉。高质量的评估任务通常需要多次工具调用。比如“客户ID 9182报告说他们在一次购买尝试中被扣了三次款。查找所有相关日志条目确定是否有其他客户受到同样问题的影响。”运行评估通过直接调用LLM API以编程方式运行。在系统提示词中要求AI不仅输出结构化响应块用于验证还要输出推理和反馈块——这能触发思维链行为让你看到AI“为什么这么想”。除了准确率还要追踪工具调用总次数、总Token消耗量、工具错误数、任务运行时间。这些指标会告诉你很多故事。分析结果这是最有趣的部分。观察你的AI在哪里卡壳、困惑、犯错。大量冗余的工具调用 → 分页或Token限制参数需要调整大量无效参数错误 → 工具描述需要更清晰或需要更好的示例AI不断跳过某个工具 → 该工具可能根本没有存在的必要把评估日志直接喂给Claude Code让它帮你分析问题并提出改进方案。这就是“人机协作迭代”的闭环。第三步与AI协作迭代将评估智能体的记录拼接起来粘贴到Claude Code中。Claude擅长分析记录和一次性重构大量工具。Anthropic团队发现这种协作方式甚至能超越“专家级”工具实现——无论是研究人员手动编写的工具还是Claude自己生成的工具在反复迭代后都能获得额外性能提升。核心循环是人类设定目标 → AI执行评估 → AI分析结果 → 人类指导改进 → 新一轮评估。黄金设计法则法则一克制是美德不要提供所有工具最常见的错误把现有软件功能或API端点不加选择地全部封装成工具。对AI来说更多工具并不等于更好。以通讯录场景为例与其实现list_all_contacts返回所有人不如实现search_contacts按关键词搜索和message_contact发消息给指定联系人。后者让AI像人类一样“先搜索再操作”而不是“先暴力读取再大海捞针”。整合那些高频串联的操作❌ 多个分散的工具✅ 一个整合的工具list_userslist_eventscreate_eventschedule_event自动查找空闲时间并安排read_logs全部日志search_logs只返回相关行上下文get_customerlist_transactionslist_notesget_customer_context一次性汇总所有资讯确保每个工具都有清晰、明确、不可替代的目的。功能重叠的工具会让AI选择困难最终影响任务完成率。法则二命名即引导划定边界AI智能体可能同时访问几十个MCP服务器和数百个工具。当工具功能相似时AI会混淆该用哪一个。用命名空间来划定边界按服务划分asana_searchvsjira_search再按资源细分asana_projects_searchvsasana_users_search。有趣的是选择前缀式还是后缀式的命名方式对工具使用评估有不可忽视的影响。不同LLM的反应不同建议通过你的评估数据来决定哪种更有效。核心原则工具名称应反映任务的自然细分方式。好的命名帮助AI在正确的时间选择正确的工具。法则三返回上下文而非数据工具应该返回高价值信息而不是“原始数据”。低级技术标识符UUID、ID、MIME类型对AI的决策帮助有限。相反语义化的名称和描述能直接为AI的下一步行动提供信息。Anthropic团队发现仅仅将任意字母数字UUID解析为更有语义意义的名称就能显著提高Claude在检索任务中的精确度。举个例子❌ 返回一堆ID✅ 返回有意义的上下文{user_id: a3f9k2, dept_id: d7e1}{name: 张三, department: 技术部}但也要注意灵活性AI可能需要技术ID来触发后续工具调用比如搜索到name张三后需要user_id来发送消息。解决方案在工具中暴露一个response_format枚举参数让AI自主控制返回“详细版”还是“简洁版”。类似GraphQL的设计让AI按需获取信息。法则四Token效率是隐形天花板对可能消耗大量上下文的工具响应务必实施分页、过滤、截断的组合策略并设置合理的默认值。Claude Code默认将工具响应限制为25,000个Token。即使上下文窗口在增长对上下文高效工具的需求将持续存在。截断时要有“引导”不要生硬切断而是用清晰的提示告诉AI“响应已被截断建议缩小搜索范围重试”。错误信息也要设计❌ 无用的错误✅ 有用的错误Error Code: 500 - Internal Server Error搜索返回了5000条结果超过限制。建议添加更具体的关键词或缩小日期范围后重试。把晦涩的堆栈跟踪变成可操作的建议让AI知道下一步该怎么做。法则五工具描述需要提示词工程这是提升工具使用准确率性价比最高的方式。工具描述会被加载到AI的上下文中它们共同构成了AI对工具的“认知地图”。写工具描述时想象你在向新员工介绍这个工具——那些你以为“不言而喻”的上下文都要明确写出来。好的描述应该包含明确的输入格式参数名要自解释用user_id而不是user边界情况说明什么时候工具不能用返回什么使用场景提示什么情况下应该调用这个工具示例参数直接展示正确用法Anthropic的Claude Sonnet 3.5在SWE-bench Verified上达到最先进性能的突破正是源于对工具描述的精确改进——大幅降低了错误率提高了任务完成率。微小的描述改进可能带来质的飞跃。结语从程序员到认知架构师回顾整个方法论一条主线贯穿始终为AI设计工具不是技术问题而是认知问题。我们不再是在“写代码”而是在设计AI智能体的认知延伸。好的工具扩展了AI能够有效解决问题的范围差的工具则成为AI的枷锁。这套方法论的核心是评估驱动——不靠直觉和猜测而是用真实数据和系统化评估来迭代改进。在这个循环中AI不仅是工具的使用者更是工具设计的协作者。未来无论MCP协议如何演进LLM本身如何升级系统化的、评估驱动的方法论将持续有效。当我们把角色从“程序员”转变为“认知架构师”为AI设计工具这件事就会变得清晰而有力。而这一切的起点就是放下“函数思维”开始追问一个更根本的问题“这个工具是在帮助AI思考还是在阻碍它思考”本文内容基于 Anthropic官方工程博客结合作者在Claude Code源码学习中的实践心得整理而成。