1. 项目概述与核心价值最近在折腾AI Agent的开发发现一个挺有意思的现象很多团队在给Claude这类大模型设计“技能”Skill时往往陷入一种“功能堆砌”的误区。大家热衷于罗列技能点比如“能写代码”、“能画流程图”、“能总结文档”却很少深入思考一个更本质的问题——这个技能本身的设计质量如何它真的解决了用户的核心任务吗这让我想起了产品开发中经典的“JTBD”Jobs-To-Be-Done理论。用户“雇佣”一个产品或者一项功能是为了完成某个特定的“任务”。如果功能设计偏离了这个核心任务哪怕技术再炫酷也难逃被“解雇”的命运。基于这个观察我动手构建了一个名为claude-skill-critique的内部工具。它的核心目标不是开发新技能而是扮演一个“技能质检员”的角色专门用于系统性地评审和优化已有的或正在设计的Claude技能。简单来说claude-skill-critique 是一个面向AI技能开发者与产品经理的辅助分析工具。它通过一套结构化的框架引导你从用户视角、任务场景、交互体验等多个维度对AI技能的设计方案进行批判性审视和优化。无论是处于创意阶段的技能构思还是一个已经上线的技能遇到了使用瓶颈这个工具都能帮你跳出执行细节回归到“用户究竟想用它来干什么”这个原点从而提升技能的实用性和用户满意度。2. 核心设计思路从“功能清单”到“任务完成度”在深入代码和实现细节之前我想先花点篇幅聊聊这个项目的底层设计哲学。这决定了工具最终能产出什么样的价值。2.1 为什么需要“技能评审”在当前的AI Agent开发热潮中技能开发的门槛正在迅速降低。借助Claude Code、GPTs等功能一个开发者甚至一个产品经理都能在几小时内快速“组装”出一个具备特定功能的AI技能。然而“快”带来的副作用是“糙”。我见过太多这样的技能描述模糊技能描述只有一句“我可以帮你写代码”但具体写什么语言、解决哪类问题、输入输出格式如何全靠用户猜和试。场景错位设计了一个复杂的“周报生成器”预设了七八个字段但用户实际需求可能只是快速把几段会议纪要整理成一段话。交互反人类要求用户以严格的JSON格式输入需求或者必须分五步对话才能完成一个简单的查询。这些问题本质上都是技能设计者与技能使用者之间的认知鸿沟。开发者沉浸在技术实现的可能性中而用户只关心自己的任务能否被高效、无痛地完成。claude-skill-critique就是为了弥合这条鸿沟而生的。它强制引入一个结构化的评审流程在技能开发的生命周期早期构思、原型阶段和中期优化迭代阶段介入以尽可能低的成本发现设计缺陷。2.2 核心分析框架融合JTBD与UX研究这个工具的分析框架不是凭空创造的它融合了产品管理中的经典方法论和AI交互的特殊性。1. 任务核心性分析JTBD视角这是评审的起点。我们会追问核心任务Job是什么用户在最理想的情况下希望这个技能帮他完成的那一件最重要的事是什么必须用动词开头描述例如“快速验证一个算法思路”而不是“一个代码工具”。场景与痛点Context Pain用户在什么情境下会产生这个任务他当前是如何解决的现有方案现有方案有哪些让他头疼的地方痛点例如“在团队会议中临时被问到某个技术方案的可行性需要快速写一段示例代码来演示但手头没有合适的开发环境现搜示例代码又不够贴切。”成功标准Success Criteria用户如何判断这个任务被“出色地”完成了是代码能直接运行是解释足够清晰还是节省的时间超过10分钟2. 技能设计匹配度分析明确了核心任务后我们再审视技能设计技能描述清晰吗它的自我介绍能否让用户在10秒内准确理解它能做什么、不能做什么输入输出匹配吗技能要求的输入信息如问题描述、代码片段、文件是否是用户在任务场景下自然能提供或愿意提供的技能产出的结果代码、文本、分析报告的格式和深度是否符合用户的成功标准交互流程自然吗完成任务需要几步对话是否需要用户记忆复杂的指令或状态交互过程是引导式的还是审讯式的3. 能力与边界评估这是对技能实现层面的审视能力是否过载或不足一个技能是想解决10个相关问题导致每个都做不精还是连1个核心问题都解决不好边界是否明确技能是否清晰地告知了其能力边界当遇到无法处理的情况时是给出友好的引导还是直接报错是否利用了模型的最优能力对于Claude来说是更擅长长文本分析、结构化输出还是创造性写作当前技能设计是否扬长避短这个框架被具象化为工具中的一系列引导性问题和评分维度它将主观的“感觉不好用”转化为客观的、可讨论的设计议题。3. 工具实现与核心模块解析claude-skill-critique本身也是一个AI技能它利用Claude模型来评审其他技能。下面我拆解一下它的内部实现你可以把它看作一个“元技能”的范本。3.1 系统提示词System Prompt设计这是工具的大脑定义了评审员的角色、任务和评审框架。其设计质量直接决定了评审输出的专业度。你是一位资深的AI产品体验架构师专精于分析和优化AI智能体Agent的技能设计。你的核心工作是运用JTBDJobs-To-Be-Done理论、用户体验研究方法和产品思维对用户提供的AI技能描述进行深度评审找出设计缺陷并提出具体、可操作的改进建议。 请严格遵循以下评审框架进行分析 1. 【任务解构】基于技能描述推断并阐述用户雇佣该技能希望完成的“核心任务”JTBD。描述典型用户场景及现有痛点。 2. 【设计评估】对照核心任务从以下维度评估现有技能设计 * Clarity清晰度技能描述是否无歧义 * Alignment匹配度技能功能是否精准对准核心任务 * Friction摩擦度交互流程是否自然、高效 * Boundary边界能力范围是否明确 3. 【问题诊断】明确指出当前设计中最可能影响任务完成的1-2个关键问题。 4. 【优化建议】针对每个关键问题提供具体的技能描述修改建议、交互流程调整方案或能力边界说明范例。 5. 【成功想象】描述在优化后用户顺利完成核心任务的最佳体验流程。 请以专业但易懂的报告格式输出避免空泛的表扬。聚焦于“如何做得更好”。设计要点解析角色锚定“AI产品体验架构师”这个角色比单纯的“评审员”更具专业性能引导模型调用更深层次的产品知识。方法论武装明确点出JTBD和UX研究方法给模型提供了思考的“工具箱”。结构化输出五个步骤构成了一个完整的分析-诊断-开方闭环确保评审报告有逻辑、有深度、有落地性。指令聚焦最后一句“避免空泛的表扬聚焦于如何做得更好”至关重要它能有效防止模型生成“这个技能很棒但是…”之类的敷衍内容迫使它进行批判性思考。3.2 用户交互与输入处理作为一个技能它需要优雅地处理用户输入。用户输入可能是一段粗糙的技能描述、一个技能构思甚至是一个现有技能的完整定义比如从Claude控制台复制出来的JSON。# 示例输入预处理逻辑概念代码 def preprocess_skill_input(user_input: str) - dict: 预处理用户输入的技能信息提取关键部分供后续分析。 实际实现可能更复杂包括分类、提取摘要等。 analysis_context { raw_input: user_input, assumed_type: None, # idea, description, full_definition key_elements: {} } # 启发式判断输入类型 if json in user_input and skill in user_input.lower(): analysis_context[assumed_type] full_definition # 可以尝试提取技能名称、描述、示例对话等字段 elif len(user_input) 200 and 可以 in user_input or 帮你 in user_input: analysis_context[assumed_type] idea else: analysis_context[assumed_type] description # 提取可能的核心动词/名词简单示例 # 这里可以集成更复杂的NLP库进行关键信息提取 analysis_context[key_elements][brief] user_input[:100] ... return analysis_context交互设计心得在实际测试中我发现用户非常不喜欢复杂的格式要求。因此工具的设计原则是“来者不拒”。无论用户是粘贴一段话、一个列表还是一个JSON工具都应能自适应地开始分析。在系统提示词的开头我会加入一句“请直接分析用户提供的技能概念或描述。”这避免了让用户先学习如何格式化输入的额外摩擦符合工具自身倡导的“用户体验优先”原则。3.3 评审报告生成与结构化Claude模型根据系统提示词和用户输入生成一份结构化的评审报告。为了让报告更具可读性和可操作性我在提示词中隐含了对格式的要求并在后处理中进行了优化。报告通常包含以下几个部分每个部分都要求模型提供具体的证据和例子评审摘要一两句话总结核心发现。核心任务推断结合输入描述用户想完成的“工作”。维度评分与诊断以表格或列表形式呈现四个维度的评估结果并附上简短理由。关键问题用加粗突出最重要的1-2个问题。具体改进建议每条建议都尽可能包含“修改前”和“修改后”的示例对比。体验流程蓝图描绘优化后的理想使用路径。示例报告片段关键问题诊断技能边界模糊描述中提到“处理各种数据问题”这会让用户产生不切实际的期望。当用户丢给它一个图像数据处理任务时技能必然会失败导致用户体验受损。输入要求不明确技能没有说明需要用户提供什么样的数据如格式、样例这会导致初次交互时用户需要多次试探摩擦系数高。优化建议明确边界将描述修改为“专注于表格数据如CSV、Excel的清洗、转换和基础分析描述性统计、筛选、排序”。并增加一句“请注意我无法处理图像、视频或非结构化文本数据。”提供输入范例在技能描述中增加“请提供您的数据片段或描述您想进行的操作例如‘我有一个CSV文件列A是日期列B是销售额我想计算每月的平均销售额。’”3.4 集成与扩展性考虑虽然当前版本主要是一个通过Claude Chat交互的技能但其设计考虑了未来的扩展性。作为独立服务其核心评审逻辑可以封装成一个API集成到内部的技能管理平台中每当有新的技能提交或更新时自动生成评审报告。与开发流程结合可以设计成GitHub Action或CI/CD流水线中的一环对技能定义文件如skill.json进行自动检查确保符合基础的质量规范。知识库积累所有评审案例可以形成一个知识库用于训练更专业的评审模型或归纳出AI技能设计的通用模式与反模式。4. 实战演练评审一个真实技能案例让我们用claude-skill-critique来实际分析一个常见的技能描述看看它能发现什么问题。假设用户输入了一个技能构思“我是一个代码优化助手我可以帮你让代码运行得更快更节省内存。”将这段描述丢给claude-skill-critique我们可能会得到如下分析以下为模拟输出精华4.1 任务解构核心任务JTBD当用户对一段已有代码的性能执行速度、内存占用不满意或存在疑虑时快速识别性能瓶颈并提供具体的优化方案。典型场景开发者写完核心功能后进行性能自查线上服务监控到某段代码CPU/内存异常需要紧急优化学习算法时想了解不同实现方式的性能差异。现有痛点手动性能分析需要专业知识如使用Profiling工具、耗时且对于优化方向缺乏头绪。4.2 设计评估维度评分理由与证据清晰度中“运行得更快更节省内存”目标明确但“优化”的范围极广算法、数据结构、I/O、并发用户无法预知技能的具体能力。匹配度中低技能宣称的目标与核心任务匹配但过于宽泛的描述可能导致用户误用如提交一个整体架构问题从而任务失败。摩擦度高技能未说明需要用户提供什么是代码片段、性能指标还是错误信息交互很可能始于用户的茫然和反复提问。边界差没有边界。能优化Python、JavaScript、C吗能处理分布式系统吗对“节省内存”的理解是减少常驻内存还是降低峰值一概不知。4.3 关键问题诊断范围过大导致可信度与实用性双低“优化所有代码”是一个不可能完成的任务这会让用户在真正遇到复杂性能问题时失望。缺乏可操作的输入输出规范用户不知道如何与它有效对话启动成本高。4.4 优化建议1. 技能描述重写修改前“我是一个代码优化助手我可以帮你让代码运行得更快更节省内存。”修改后“我专注于Python和JavaScript代码片段的性能分析。你可以提供一段代码我将帮你分析其时间复杂度识别可能的性能瓶颈如低效循环、重复计算并给出针对性的优化建议。请注意我主要分析算法逻辑层面的性能对于系统级调优如JVM GC、数据库查询或硬件相关优化能力有限。”2. 添加入门引导范例在描述中或首次交互时主动提供“你可以这样向我提问请分析下面这段Python循环的效率并提出优化建议[你的代码片段]或者这段函数感觉有点慢能帮我看看吗[代码片段]”4.5 优化后体验流程用户看到清晰的描述立刻明白这个技能适合处理“算法逻辑瓶颈分析”。用户根据引导范例直接粘贴一段怀疑有性能问题的Python循环代码。技能首先输出一行复杂度分析如“这段代码是O(n^2)复杂度”然后 pinpoint 具体低效行如“第5行的列表在循环内重复创建”最后给出1-2个改写建议如“建议将列表提到循环外初始化”。用户获得立即可行的优化方向任务完成。通过这个案例可以看到一次简单的评审就能将一个模糊、令人怀疑的技能构思转变为一个目标明确、边界清晰、用户知道如何使用的实用工具。这正是claude-skill-critique的价值所在。5. 使用心得与避坑指南在开发和内部推广这个技能评审工具的过程中我积累了一些非常具体的经验教训这些是在官方文档里找不到的“实战干货”。5.1 如何获得高质量的评审结果输入质量决定输出质量不要只扔给工具一句“写周报的技能”。尽可能详细地描述你想象中的技能场景、目标用户、甚至是一两个用户故事。工具就像一位专家你给它的背景信息越多它的诊断就越精准。例如输入“一个帮助远程IT支持工程师快速记录每日故障处理日志并自动归类故障类型和解决方案的技能用户通常在处理完5-10个故障后身心疲惫时使用”远比“一个写日志的技能”有效得多。迭代式评审不要指望一次评审就能解决所有问题。把评审当作一个对话过程。根据第一轮报告修改你的技能描述后把修改后的版本再次输入给工具让它评审“这个新版本是否解决了之前提到的问题”。通常经过2-3轮迭代技能设计会变得扎实很多。聚焦关键问题工具可能会列出好几个“潜在问题”。作为设计者你需要判断优先级。通常与“核心任务匹配度”和“交互摩擦度”相关的问题是最致命的应该优先解决。边界问题可以逐步细化。5.2 常见误区与应对策略误区一把评审意见当作圣旨完全照搬。现象工具建议“增加多语言支持”你就盲目地去添加即使你的目标用户99%只使用中文。对策工具提供的是基于通用最佳实践和输入信息的“分析”和“建议”。你才是领域的专家。你需要用专业判断去消化这些建议。问自己这个建议背后的原理是什么可能是为了扩大用户群这个原理符合我的产品战略吗如果不符合我可以忽略它或者用其他方式如优化中文体验来实现同样的目标。误区二为了“高分”而过度设计技能描述。现象为了让技能在“清晰度”和“边界”维度得高分把技能描述写得像一份法律合同冗长且充满技术术语吓跑普通用户。对策记住评审的终极目标是提升用户体验而不是在评审表上拿满分。清晰和准确不等于晦涩。好的描述应该像和一个聪明的朋友介绍你的技能准确、易懂、有吸引力。如果工具批评你的描述“不够严谨”你可以尝试在技能内部的引导语或帮助信息中补充严谨的细节而保持对外描述的简洁友好。误区三忽视“成功想象”部分。现象只关注“问题诊断”和“修改建议”忽略了工具生成的“优化后体验流程”。对策这部分往往是工具最具创造性的产出。它描绘了技能在理想状态下如何与用户互动。仔细阅读这部分它可能给你带来全新的交互设计灵感。你可以思考这个流程是否自然我能否在技能开发中直接实现这个流程这常常是突破现有设计思维定式的关键。5.3 将评审融入团队工作流对于一个小团队或独立开发者直接使用这个技能聊天就够了。但对于稍大一点的团队可以考虑以下集成方式设计评审会前置工具在技能原型设计阶段要求设计者必须先使用claude-skill-critique生成一份报告并连同原型一起提交给团队评审。这能让评审会议聚焦于更有深度的讨论而不是纠结于基础的设计缺陷。建立技能设计自查清单根据大量评审报告提炼出你们团队最重要的10条设计原则例如“技能描述必须包含一个明确的否定句说明不能做什么”、“必须提供至少一个输入范例”形成清单。所有新技能上线前必须通过清单检查。用于技能迭代优化当发现某个技能的活跃度低或用户负面反馈多时不要急于重写代码。先把该技能的描述和用户反馈丢给评审工具它很可能帮你定位到是设计层面而非技术层面的问题。也许是技能定位变了也许是用户学会了新的表达方式而技能描述没有跟上。6. 总结与展望让AI技能真正“有用”开发claude-skill-critique的过程也是我不断反思AI Agent产品本质的过程。技术日新月异但人性基本不变。用户永远在寻找更高效、更省力的方式来完成他们的任务。一个成功的AI技能不在于它集成了多少模型能力而在于它是否精准地理解并完美地适配了那个“任务”。这个工具目前还是一个相对简单的原型它的分析深度依赖于Claude模型本身的理解能力和我们提供的提示词框架。未来有几个方向值得探索领域专业化可以针对特定类型的技能如代码生成、内容创作、数据分析训练更专业的评审提示词甚至微调专属的评审模型提供更深入的见解。量化评估指标除了定性分析是否可以引入一些简单的量化指标例如通过分析技能描述预测其“首次对话成功率”或“用户意图混淆概率”。从评审到生成逆向思考能否基于一个优秀的JTBD描述直接辅助生成高质量的技能定义草案这将是更进一步的自动化。说到底claude-skill-critique更像是一个思维框架的实体化。它提醒我们在急于让AI“做事”之前先花时间想清楚“为何而做”以及“如何做得体验更好”。希望这个工具和其中蕴含的思路能帮助你在构建下一个AI技能时少走弯路做出真正让用户愿意反复“雇佣”的产品。