最近整理作品集时,我发现自己做过的很多 B 端项目,本质上都在反复处理同一个问题:任务。
不是先想页面怎么排,也不是先想组件怎么画,而是先判断:产品到底要给用户下发什么任务?用户自己原本又带着什么任务?这两个任务是不是同一个东西?
很多 B 端体验的问题,表面看是信息太多、流程太长、状态不清楚,但往深一层看,常常是任务没有被找准。
先找准产品要下发的任务
B 端产品经常要把组织目标翻译成用户任务。
比如安全产品希望管理员完成配置,审核系统希望审核员快速准确地判断内容,开放平台希望开发者完成接入和调试。产品侧看起来是一个业务目标,但落到用户身上,就会变成一个个具体任务。
如果这个任务没有定义清楚,后面所有设计都会开始摇晃。
一个典型问题是:产品经理会把不同阶段的任务糅合在一起。初始化配置、日常运维、异常处理、结果反馈,本来是不同时间阶段下的事情,却被放在同一张页面、同一条流程里。用户会同时面对“我怎么开始”和“我之后怎么维护”,理解和上手成本都会变高。
设计师要做的第一件事,是把这些任务重新拆出来。
再找准用户自己的任务
产品下发的任务,不一定等于用户心里的任务。
产品可能希望用户“完成配置”,但用户真正关心的是“我现在安全吗”“下一步应该做什么”。产品可能希望用户“创建报告”,但用户真正关心的是“我能不能看出审核员的问题在哪里”。产品可能希望开发者“调试成功”,但开发者真正关心的是“我错在哪里,怎么最快修掉”。
所以 B 端设计不能只顺着功能走,还要把产品任务翻译成用户任务。
一旦翻译清楚,设计方向也会清楚很多:页面不只是承载功能,而是在回答用户当前最关心的问题。
把大任务拆成清晰的子任务
找准任务之后,下一步是拆任务。
一个大的 B 端任务,通常都不应该直接丢给用户。它需要被拆成一个个子任务,每个子任务都要足够清晰、高效、可判断。
比如首次配置应该帮助用户一步步配通,日常运维应该帮助用户快速发现过期、失效和异常;数据分析应该先帮助用户判断整体情况,再进入具体维度;安全治理应该先给用户水位感,再给下一步行动。
我越来越觉得,B 端设计的手感,很大一部分来自这种拆分能力。
拆得好,用户会觉得产品“懂我现在要做什么”;拆得不好,用户就会觉得自己被一堆功能和状态围住。
还有一类任务是情绪性的
但 B 端设计也不只是理性的任务拆解。
有些用户其实是被动进入任务的。他们不一定想做这件事,但工作要求他们必须做;不一定有选择权,也不一定有退出权。审核员、管理员、客服、运营,很多时候都是这样。
这时设计要抓住的,就不只是任务效率,还有情绪和时机。
情感化设计不是在页面上多写几句温暖的话,而是判断用户在什么时刻最需要被看见。等待任务时、切换状态时、完成一天工作时、遇到阻断和失败时,这些时刻都可能比主流程里的大页面更重要。
但时机也必须克制。太早会打扰,太晚没有意义,太多会变成噪音。情绪设计的关键不是表达得多,而是出现得刚刚好。
我的总结
我现在对 B 端设计的理解更接近这样:
先找准任务,判断产品要给用户下发什么任务,也判断用户自己真正想完成什么任务。
再把任务拆成清晰的子任务,让每一步都高效、明确、可继续。
如果用户是在被动、高压、重复的状态里完成任务,还要抓住他的情绪和时机,在最合适的地方给出一点支持。
好的 B 端设计不是冷冰冰地把功能摆出来,而是同时做到两件事:
一方面,理性地组织任务。
另一方面,温和地理解人。
作为一个设计师,一直在持续观察 AI 生图的能力。今天刷 Twitter 的时候,刷到了 @小小东 的图片提示词,看到之后瞬间给我干惊了。我之前对 GPT image 图能生成的图想想还是有限,他能够把简单的文字让 GPT image 2 生成出 直击人心的效果。我分享出来给大家玩玩。我也用 Claude 分析了下他的提示词思路。先看看大佬的作品
我自己也用这套提示词给我的公众号生成了 2 张图片,完完全全表达了我内心深处想表达的内容。让我有种 AI 懂我的喜极而泣!
完整版提示词有点长,我放到文末,需要的朋友自取。
背后的思路
看完大佬的提示词之后,我想如果后续我遇到其他的场景,能不能也写出这么好的提示词呢?我试着用 Claude 分析了下他的撰写思路。
告诉 AI 不要做什么
我发现他的提示词不是描述想要什么,而是堵住 AI 默认会犯的错。反复强调 AI 默认会怎么翻车?然后针对每一种翻车,写一条防御性约束。比如
AI 默认会让主体悬浮在背景上 → 我加了一条"必须有承载面"
AI 默认会乱加假署名假坐标 → 我加了一条"严禁伪装饰性小字"
AI 默认会用彩虹色显得"丰富" → 我给了一个配色公式 + 一份反例清单
详细告诉 AI 怎么做
我们撰写的提示词经常非常的模糊不清,一方面因为我们懒,另一方面因为我们不懂得行业 Know-how (这个行业怎么做对)。
翻开 @小小东 的提示词,他详细要求了 AI 的工作流必须要理解语义、分析情绪和关系。这点是在一般的 AI 生图过程中没有的。用即梦和微信公众号生图出来的效果都只是把文字硬生生的塞到了画面里。
其次是他给 AI 提供了详尽的构图、色彩、材质、风格、文字的约束,这也让 AI 输出和他的预期进一步对齐。
一旦你真的开始维护知识库,你很快就会发现:这件事远比“记录”累得多。因为记录可以靠一时兴起,维护却是一个持续动作。你得不断整理、更新、回看、合并、重写。而这恰恰是最容易拖延、最容易积压、也最容易烂尾的部分。我一开始也在想,既然维护这么累,那能不能让 AI 来帮我?
我的踩坑经历
我最早的思路,其实很自然:让 AI 帮我自动归类、自动打标签、自动归档。你记下一条内容,AI 帮你判断放到哪里;你存进来一篇资料,AI 帮你归到对应目录;你写了一段想法,AI 帮你补一点结构、补一点标签。
这个方向听上去挺顺的,因为它确实能省掉一点机械劳动。但后来我发现,这条路只能解决很表面的问题。因为它优化的其实只是“收纳”。它只是让 AI 帮你把东西放进更合适的抽屉里,但整个知识库最重的活,还是你自己在做。你还是得判断这条内容值不值得留下;还是得判断它和旧内容是什么关系;还是得回头整理那些已经堆起来的笔记;还是得自己一点点把零散输入收成结构。
# 先设置所有群默认不需要 @openclaw config set channels.feishu.requireMention open --json# 然后给特定群单独设置必须 @(群 ID 只是示例,替换成你的真实 ID)openclaw config set channels.feishu.groups.oc_xxxxxxxxxxxxxxx.requireMention true --json
代码
4.5 第三步:获取群聊 ID
要把特定的飞书群绑到特定的 Agent,你需要知道群聊的 `chat_id`(格式类似 `oc_xxxxxxx`)。获取方法有两种:
方法一:在目标群里 @你的机器人发一条消息(比如问"当前的群 ID 是多少"),机器人会回复当前群聊的 chat_id。
方法二:群成员点击飞书群右上角的菜单,进入"群设置"页面,即可查看群 ID