我最近做一个技能商店时，重新遇到了一个看似简单、其实很难的问题：商品已经摆出来了，用户为什么还是不知道该买什么？目录可以按分类展示，详情页也能写出一长串能力，但普通用户通常不会先研究“技能”这个概念。他只有一个正在发生的任务：想把一件事做完，却不知道需要什么工具。
这改变了我对商店首页的判断。它不应该只是商品陈列架，也不应该只是把搜索框换成聊天框。更好的入口，是先听懂用户要完成什么，再结合预算、交付方式和风险，给出少量可解释的候选。如果没有合适的能力，也要明确说出来，并把用户带到下一步，而不是为了完成一次推荐，硬塞一个看起来相近的商品。
目录能展示商品，却不一定能帮助选择
最初的目录思路很自然：把技能分成若干类别，用户进入后浏览、点开详情、再决定是否购买。这种结构适合已经知道自己要找什么的人，却不适合第一次接触技能商店的人。用户可能知道“我要做一个短视频”，但不知道这件事对应哪个分类，也不知道多个相似技能之间究竟差在哪里。
当商品数量变多，分类的局限会更明显。分类是商店的组织方式，不一定是用户的思考方式。用户想的是“我能不能把这份材料整理成一篇文章”“有没有办法帮我处理一个网站问题”“我只有一笔有限预算，先买哪个最有用”，而不是“我应该点进哪个内部分类”。
商店的第一任务不是让用户看见更多商品，而是让他更快确认哪件事值得继续。
所以我会把技能卡从“它有什么功能”改成“它在什么场景下帮你完成什么”。先写痛点，再写交付结果，最后再解释能力边界。这样做不是降低专业度，而是把专业能力翻译成用户能判断的语言。用户不需要先理解工具名，才有机会理解工具价值。
自然语言入口，先问任务再问商品
后来我想到，可以让用户直接用一句话描述需求，例如“我想把一批资料整理成可以发布的内容，预算不要太高”。这并不意味着系统收到一句话后就立刻匹配一个商品。真正重要的是，它要从这句话里拆出几个判断维度：用户要完成的任务是什么，期待什么结果，有哪些约束，预算大致在哪里，以及这件事是否存在明显风险。
如果用户只说“帮我找个写作工具”，系统还需要知道他是在写报告、做广告文案，还是想把零散笔记整理成文章。不同场景即使都叫“写作”，交付内容也完全不同。预算也不能只作为筛选按钮。一个价格更低的技能，如果不能覆盖关键步骤，反而会让用户多买一次、重新试错一次。
我判断问答入口值得做，是因为它能承接用户原本就会说的话；但我不会让它代替所有静态信息。用户仍然需要看到候选的适用场景、交付方式和边界，必要时也应该能回到目录继续比较。自然语言的价值在于减少理解成本，不在于把所有选择都藏进一个黑箱回答里。
推荐必须解释为什么匹配
一个好的回答不应该只有“推荐你买某某”。它至少要让用户知道：这个候选解决了他哪一部分问题，为什么符合预算或交付要求，还缺哪些条件。比如，用户想要的是从需求梳理到最终成稿的一整套帮助，而候选只覆盖其中的资料整理，那么系统就应该说清楚“它适合前半段”，不能把局部能力包装成完整方案。
这里我会把技能信息结构化保存，而不是只把一段宣传文案交给模型自由发挥。每张技能卡至少要有适用场景、主要产出、限制条件、价格档位和交付形式。模型负责理解用户表达、排序候选和生成解释，事实仍然来自卡片。这样既能让回答更像对话，也能避免模型为了显得有帮助而补出不存在的能力。
如果候选有多个，我倾向于给出少量结果，并说明差异：一个更适合快速完成，一个覆盖范围更完整，一个更适合预算有限的试用。用户看到的是选择依据，而不是一串商品名。没有解释的推荐，会把原本的搜索负担换成新的信任负担。
预算和交付方式要一起说清楚
用户问预算，通常不只是想知道一个数字。他还在判断这笔钱能换来什么，以及购买以后如何真正开始使用。技能商店如果只展示价格，不说明交付方式，用户仍然会有疑问：买到的是一次回答、一个可安装的能力，还是一套需要自己配置的提示内容？
因此，推荐结果应该把“价格对应什么”说清楚。价格可以分成几档，但每档的差别要落到覆盖范围、复杂度或交付内容上，而不是只显示高低。用户如果要求“尽量便宜”，系统可以先推荐低门槛方案，同时提醒它可能不包含哪些步骤；如果用户更在意省时间，则可以推荐更完整的方案，并说明为什么值得多付这一档。
价格筛选只有和交付结果绑定在一起，才是真正的预算决策。
这也意味着，系统不能为了成交而把所有候选都说成“适合”。如果需求需要多个能力组合，应该坦白说明购买后还需要哪些动作；如果一个技能已经覆盖不了目标，就不要用“稍微调整一下就可以”来掩盖缺口。短期看，少推荐一个商品像是损失；长期看，减少一次错购，才是在建立商店的可信度。
不适合时，回答也要能继续往前走
我最在意的边界，是用户提出了不适合交给技能商店处理的请求。比如他要求投资买卖建议，或者要求系统代替他做一个需要专业责任判断的决定。这时最容易出现的错误捷径，是为了让对话看起来顺畅，继续推荐一个“相关”技能。这样做既没有解决问题，还可能让用户误以为推荐本身就是可靠结论。
更好的处理方式是三步。先直接说明不能提供什么，理由保持具体，不用含糊的“暂不支持”。再指出用户真正可能需要的下一步，例如整理公开信息、建立比较框架、准备要问专业人士的问题，或者转向人工和正式服务。最后，如果商店里确实没有合适商品，就给出静态目录、人工咨询或退出推荐的入口。用户至少要带着一个可执行的下一步离开，而不是只收到一段拒绝话术。
“不推荐”不是对话的终点，而是一次准确分流。边界做得好的系统，不会把每个问题都变成商品；它会在不适配时帮助用户少走一步错路。
下次我会怎么做
下次再做类似的技能商店，我会先整理一套用户任务词，而不是先扩充分类。把“写什么、改什么、查什么、产出什么”作为入口，再把技能映射到这些任务上。用户说出一句自然语言后，系统先提取场景、目标、约束和风险；信息不足时只追问最影响选择的1-2个问题，不把用户拖进冗长问卷。
接着，我会为每张技能卡补齐可以被验证的字段：适用场景、能交付什么、不能交付什么、价格档位、购买后的使用方式。推荐时只返回少量候选，每个候选都带上匹配理由和不匹配的地方。涉及高风险请求，则走边界分流，不进入普通商品排序。每次回答还要留下可回看的依据，让用户知道这次判断依赖了哪些条件，而不是把结果写成无法复核的结论。
最后保留两条兜底路径：用户可以回到静态目录自己比较，也可以在没有合适候选时获得人工或其他正式渠道的指引。这样做的目标不是让 Agent 替用户做完所有决定，而是让用户用一句话开始，并在每个关键判断处看得懂、选得明白。