“现代前端太复杂了，我该从哪里开始？”
设想收到这句话的是你。求助者做过后端，想给自己的小工具加个网页界面。他开了一个模板，遇见路由、构建、状态管理和一串陌生依赖，两晚过去，页面还没有显示出第一条数据。
你可以给他一篇教程。也可以问：“你希望周末以后，自己学会这部分，还是别人已经能用上这个工具？”
这两个愿望常常藏在同一句求助里，却会把人带向不同地方。
如果他想学习，一个删去大部分依赖的小项目，可能比完整教程更适合作为起点。有人陪他把工作拆成取数据、显示列表、处理一次点击，他就能把已有经验接过来。若他只想尽快分享工具，现成界面或另一位开发者的短时帮助，可能更直接。
在这段虚构对话里，最初的问题并没有被“理解错”。它本来就还没有长成一个明确的任务。回答者参与了任务的形成。
很多协作系统期待相反的顺序：先写清需求，再描述能力，最后进行匹配。这个顺序适合已经清楚自己要什么的人。对于还在摸索的人，它把很大一部分工作留在了系统门外。
我更感兴趣的是，能不能从一个不完整的表达开始，让回应帮助它变得具体。
这种回应未必来自最有资历的人。一个刚刚走过同样弯路的学习者，可能知道他被哪个陌生词卡住；一位模板维护者，可以给出足够小的起点；一个朋友自己帮不上忙，却愿意介绍合适的人。相似经历、互补能力和关系介绍，分别带来不同的帮助。
它们也不必一次全部出现。先找到一个可运行的页面，求助者也许就能独自继续。只有试过以后仍然存在的困难，才需要下一段关系。让三位专家同时进入对话，有可能比原来的技术问题更难协调。
这里有一项适合 AI 做的细活：把零散材料整理成别人容易接住的邀请。
我已有一个返回 JSON 的接口，想在周末前做出可分享的列表页面。我能写后端，不熟悉前端构建。这里是最小接口样例。有人愿意用半小时帮我选一个简单起点吗？
有了目标、起点和范围，对方才容易判断自己能否帮忙。收到回应以后，这段邀请还可以再改：半小时足够选工具，却未必足够教会使用；求助者看过最小页面，也可能决定先认真学习，而不急着发布。
于是，系统每次找到的不只是一个人，也得到了一次修正问题的机会。下一轮寻找的对象，可能与第一轮不同。
这会改变我们评价发现系统的方式。相关列表可以作为中间结果，但一次帮助最终留下了什么，更值得看：求助者做出了第一屏，找到了可以继续的材料，还是把工作重新分配给了合适的人？双方为此花了多少时间？
如果他最后只是多开了十个标签页，我们还没有帮他走出那两个晚上。
ToWow 所关心的发现，可以从这里开始：让一个暂时无法准确描述困难的人，也能得到可尝试的帮助。下一步足够小，才容易发生；回应足够具体，最初那句话才有机会发生变化。