企业官网建设流程全解析

复盘类文章最难写的地方，在于大多数人只会复述“当时做了什么”，却说不清“当时为什么敢这么做”。Muse项目复盘的价值恰恰在后半句。作为产品设计师，我很少见到一个AI类项目能把定位、交互、协作串得这么顺——它不是靠某一个爆款功能赢的，而是靠一连串符合逻辑的设计决策赢的。这篇复盘我会从设计师视角拆解Muse项目做对的几件事，重点讲每个决策背后的推理过程、踩过的潜在坑，以及哪些思路可以迁移到自己团队里。适合产品设计师、交互设计师、产品经理和AI产品负责人阅读。

老规矩，这个项目代号和公司信息我做了脱敏处理，文中统一用Muse项目指代。我不会讨论它具体的业务数据，只聊设计决策本身。毕竟复盘不是为了追忆过去，是为了下一次少走弯路。

1. 复盘从定位开始：Muse没有掉进“AI炫技”的坑

1.1 大多数同类产品挂在“捏造需求”上

过去几年我拆过不少AI产品，最大的感受是：很多团队先有了大模型，再反过来找场景。结果做出来的东西，技术演示很漂亮，用户打开两次就不想再碰。为什么会这样？因为从技术出发倒推需求，容易把“AI能做什么”误当成“用户需要什么”。

举个例子，有些AI写作工具一上来就宣传“一分钟生成千字长文”，但真实用户写文章时最痛苦的不是打字速度，而是“不知道从哪下笔”和“写到一半卡住”。前者是效率问题，后者是状态问题。产品如果只解决效率问题，用户用完即走；如果解决了状态问题，用户才会留下来。

Muse项目早期其实差点掉进同样的坑。内部一位参与早期方案的朋友告诉我，他们最初的Demo也是“大而全”——输入一句话，生成整篇方案、多种风格、多级标题。演示会上掌声不断，但进入用户测试后发现，真实用户根本不会用那种方式提问，他们要么不知道输入什么，要么嫌结果不可控。

1.2 定位转变：从“更快完成”到“更好共创”

Muse项目真正发生转折的点，是团队把一句话在不同会议里反复讨论了将近一个月：“我们到底是在帮用户更快地完成一件事，还是在帮用户更好地做一件事？”

这两个目标看起来差别不大，设计出来的产品却完全不同。“更快完成”导向的是效率工具：界面要简洁，路径要最短，结果要直接，恨不得用户一键拿到成品。“更好共创”导向的是创作伙伴：界面要留出对话感，结果要可编辑，流程要支持反复修改，用户在这条路径里要有“我正在参与创作”的感觉。

Muse最终选择了后者。这个定位看起来简单，但它是一切的根源。定位定了之后，设计师才能回答很多“这个交互应该怎么做”的问题：为什么不能一键生成后直接结束？因为共创需要用户介入；为什么结果展示不能只有一种样式？因为每个用户对“好”的定义不一样。

1.3 北极星指标换成“回访密度”之后，设计思路全变了

定位的转变最终落到一个可度量的指标上。Muse项目的复盘资料里有一页PPT让我印象很深，上面写着：“我们曾经考核生成次数和完成率，后来才意识到，对共创类产品来说，最重要的指标是回访密度。”

回访密度这个概念，我理解为“一个用户在一个完整创作周期内，愿意回到产品里继续操作的次数”。效率工具的回访靠需求触发，创作工具的回访靠体验牵引。如果用户来一次，生成一篇，走人，再也不回来，说明产品只是一个“生成器”；如果用户反复回来修改、续写、调整，说明产品真的成了创作流程的一部分。

指标一变，设计优先级就变了。团队开始把大量力气花在“修改体验”上，而不是继续堆生成能力。每处可编辑的交互、每个可撤回的步骤、每次中途保存的状态，都在服务这个指标。

2. 最有含金量的三个设计决策

2.1 决策一：做“限定制”而不是“自由生成”

Muse项目中最反直觉的一个选择，是刻意限制AI的“自由度”。

当时很多AI产品都在做无限制输入框，用户打任何字，AI都接话。Muse却在主要界面里做了一套“场景化入口+意图识别”机制：用户先选场景（写方案、写文案、做头脑风暴），再输入内容，最后选择一个输出方向。

听起来好像变麻烦了，但实际测试数据支持这套设计。原因是：无限制输入框对新手太不友好。面对一个空白对话框，绝大多数人不知道该怎么提问。心理学里有个词叫“空白页焦虑”，在AI对话框里同样存在。用户不知道AI能干什么，所以干脆什么都不干。

限定制实际上是在帮用户降低任务启动成本。它把“开口问AI”简化成“从几个选项里挑一个”。一位参与用户研究的同事说过一个细节：自由输入版本里，用户问出的问题五花八门，很多不在模型能力范围内；限定版本里，用户提的问题质量明显更高，因为他们先被场景引导了一次。

从设计师角度看，这里有一个值得抄走的逻辑：限制不是削弱，而是给用户一个清晰的行动路径。用四个字概括就是——聚焦生成。

2.2 决策二：把不确定性可视化，让用户建立预期

AI模型的生成结果天然带有不确定性，同一个问题，不同时间可能给出不同答案。对于设计师来说，不确定性是个需要认真处理的体验问题，而不是技术问题。

Muse项目在这一点上做了一个聪明的设计：把模型的不确定性从“黑盒状态”变成“可感知的轨道”。具体来说有三层设计——第一层是生成过程中的阶段性反馈，不再是一个干巴巴的转圈加载，而是类似“正在理解你的主题”“正在组织结构”“正在优化语气”这样的过程提示；第二层是结果置信度提示，系统会对生成内容做自我评估，告诉用户“这段内容与主题匹配度高，可以直接用”或“这部分可能需要你调整”；第三层是来源追溯，当模型参考了某些信息时，界面会给出引用来源，用户可以跳过去查证。

这里面的设计原理可以类比打车软件——当订单下完后，平台不会只显示“等待中”，而是显示“司机距离你1.2公里，预计3分钟后到达”。你依然在等待，但等待的焦虑因为“可见的进度”而大幅降低。Muse用同样的逻辑处理AI生成焦虑：用户不害怕等待和不确定性，害怕的是不知道还要等多久、结果是不是能用。

2.3 决策三：放弃“一键完成”，给用户保留中途介入

这是Muse项目所有决策里我学得最深的一个。他们刻意没有提供“一键生成最终成品”的操作，而是把流程做成了：生成草稿、局部修改、逐段精修、合并整合。

为什么说“一键完成”对创作类产品往往是个伪需求？因为我所在的设计团队做过一次对照测试：A版本提供“一键生成全文”，B版本提供“分段生成+手动合成”。测试结果挺颠覆——A版本的完成率确实高，但用户几乎不会回访；B版本生成耗时更长，但用户对结果的修改率、收藏率、二次使用率显著更高。

道理不复杂。用户面对一个AI生成的“完美成品”时，会产生两个心理问题：一是“这到底是不是我想要的”，二是“我如果不做修改，产出还算我的作品吗”。而分段生成让用户每一步都在做决策，每一段都与自己的意图对照过，最后合成的作品，用户会觉得“这是我做的，AI只是帮我打草稿”。

这个设计带来的隐性收益是：用户修改过程中产生的编辑行为，恰好是有价值的数据反馈。用户强调什么、删掉什么、替换什么，都在告诉算法团队模型的输出哪里需要优化。

3. 原型验证的关键链路：在模型成熟前先验证体验假设

3.1 低保真模拟就能验证的核心假设

很多AI产品团队有一个误区，认为AI产品的体验测试必须等模型能力到位后才能进行。Muse项目的复盘告诉我们，这是把技术依赖和体验假设混为一谈了。

所谓体验假设，比如“用户是否理解这个入口”“用户是否愿意修改AI生成的内容”“用户对生成速度的容忍阈值是多少”——这些根本不需要真实模型，用低保真原型就能验证。Muse团队在早期测试时，用的就是一份中间画好多种结果的Figma原型。用户点击“生成”按钮后，系统会停顿一段时间，再从预设好的素材库里“吐出”一份结果。这个手法相当于在产品设计领域的走查会议里先摆出“演员道具”，用来测试整场戏的逻辑顺不顺。

用这种方式，团队在模型还很不稳定的阶段就验证了几个关键假设：用户不是需要一个万能对话框，而是需要场景引导；用户不是害怕结果不完美，而是害怕结果“不能改”；用户不是没有耐心，而是没有预期的等待最熬人。

3.2 测试中容易误读的信号：客套满意与真实满意

复盘Muse项目的用户测试环节，我注意到他们踩过一个很典型的坑：用户说“满意”不等于真的满意。

早期测试中，几位用户对AI生成结果表示“挺好的”“可以用”，但后续回访数据却显示这些用户没有一个人再次打开产品。团队一开始非常困惑，直到拉出屏幕录制视频逐帧分析，才发现一个扎心的细节：那些说“挺好”的用户，几乎从不做任何修改操作，复制粘贴到文档里也多半放着不用。

真正满意的用户表现完全不同。他们会点击某一段重新生成，会调整某个措辞，会把生成的某句话删掉替换成自己的内容。用团队内部的话说：“用户会骂AI，说明他还在把AI当成创作伙伴；用户对AI客气，说明他已经在心里把它当成一次性工具了。”

这里有一个可以复用的判断标准：区分“沉默用户”和“主动用户”，看修改率，看回访率，看用户是否愿意把AI生成的产物作为基础继续加工，而不是只看满意度打分。

3.3 定性访谈与数据下钻的交叉验证

在线下原型测试找到信号之后，Muse团队还做了一件很扎实的事：把定性发现和线上数据放在一起验证。

有一个让我印象很深的案例。他们的新旧版本A/B测试中，新版本的“生成按钮点击率”明显低于旧版本。按照常规逻辑，点击率下降通常意味着设计变差了。但Muse团队没有直接改回旧版，而是通过回访访谈发现了一个被忽略的机制：新版本引入意图选择后，用户点“生成”的意愿虽然在那个入口降低了，但生成结果的采纳率反而提高了。

为什么？因为用户在点击生成之前多做了一个“想清楚自己要什么”的动作，带着更明确的意图去生成，一次命中率自然更高。如果只盯着点击率，这个正确设计很容易被误杀。这个案例给团队的教训是：数据下钻不能只看单点指标，要看完整的行为链路，把“点击”“生成”“修改”“采纳”串起来看，才不会得出倒因为果的结论。

4. 隐藏在设计背后的协同因素：设计系统、提示词与算法节奏

4.1 设计系统要为“生成内容的不可控”兜底

复盘Muse项目时，如果只看交互层，会低估它的设计系统工作。AI生成内容的文本长度、段落数量、信息结构都是弹性的，这给界面排版带来了一个常态化的挑战：同一个组件，昨天输出三行，今天输出十行，后天可能输出一张表格。

Muse的设计系统做对了什么？核心是定义了一套“弹性容器体系”。所有承载生成内容的模块，都按内容长度划分了明确的适配规则。比如短文本用紧凑卡片，长文本用自适应分栏，混合内容用结构化区块。视觉上看起来像一套规则，本质上是一套“接住不可控内容”的防御机制。

更妙的地方在于，这套设计系统不只服务于UI排布，还直接影响生成策略。当设计规范明确“卡片内标题不超过两行，超出部分折叠”时，算法团队会把这个约束纳入提示词模板，引导模型生成符合界面承载能力的输出。设计和算法在一个团队内部完成了对接，而很多团队到这一步还是“UI归UI，模型归模型”。

4.2 提示词模板其实是设计资产，设计师要参与

这一条值得重点说。Muse项目复盘里反复提到一个观念：提示词模板不只是工程师的参数配置，而是产品体验设计的一部分。

为什么这么说？因为提示词里隐藏的语气、站位、约束条件，最终都会变成用户看到的界面文字和生成内容风格。举个简单的例子，如果提示词里使用了“你是一位专业顾问”的设定，生成内容就会偏正式和权威；如果使用“你的身份是用户身边的朋友”，内容语气就会更口语更亲近。产品到底是“顾问”还是“朋友”，这不是技术决策，是品牌体验决策。

Muse团队后来成立了由设计师、文案、算法工程师组成的“语气小组”，专门维护一套提示词风格词典。这个词典既不归算法团队独有，也不归品牌团队独有，而是像设计Token一样被纳入设计系统统一管理。小到按钮文案是“开始生成”还是“帮我写一段”，大到生成结果的默认口吻，都有明确的风格约束。

4.3 设计与算法的对齐节奏：bad case评审机制

AI产品与普通产品最大的不同，是设计师无法在交付前穷尽所有状态。模型的一个小改动，可能导致输出结果整体漂移，把设计师精心准备的交互全盘打乱。

Muse项目解决这个问题的方法是建立了一个“bad case评审”机制。每周五，设计师从用户反馈和测试数据里收集一批典型问题案例，交给算法团队评审。评审会的目的不是追责，而是一起看案例背后的设计意图和技术可行性。设计师说清楚“这个页面期待的状态是什么”，算法工程师回答“当前模型卡在了哪里”，双方在同一个上下文里找解决方案。

这个机制的巧妙之处在于，它把原本两周一次、隔着文档的合作，压缩成了每周两小时的面对面讨论。设计师不再需要“绕过算法去改样式”，而是可以直接和算法同学一起讨论“要不要调整生成策略”。一位算法工程师在复盘访谈里说了一段很直白的话：“设计师提供的是场景和判断，我们提供的是方案和成本。坐到同一张桌上，很多问题当场就解决了。”

5. 可以抄走的三个设计清单

5.1 项目启动前的定位检查清单

复盘阶段，我把Muse项目的定位决策整理成一份可以倒查的清单。适合在项目启动时用，每条都可以用一句话回答：

• 这个功能是在提升用户的效率、质量，还是状态感受？三者不能模糊地混在一个定位里。
• 如果产品里没有AI，用户的原始工作流程还成立吗？如果不成立，说明AI是在替代流程而不是增强流程。
• 用户对AI产出的修改成本高不高？修改成本超过直接重写的成本，体验就会迅速崩塌。
• 有没有一个指标能反映“用户是否愿意再回来”？没有的话，定位就还没有落地。
• 团队所有人都能用同一句话说出产品服务的是哪类用户、在什么场景、解决什么问题吗？

5.2 交互设计阶段的自查清单

这部分是在原型设计完成后、进入开发前反复使用的，直接对标Muse项目那些高含金量决策：

• 用户是否能在两次点击以内建立起对“AI能做什么”的预期？入口尽量不要用无引导的自由输入框。
• 生成等待期有没有给出阶段性的过程反馈？哪怕只是“正在理解你的主题”这样一句话。
• 用户能否方便地修改生成结果？修改成本高不高？是否支持局部重写而不是整篇推倒？
• 生成内容超过两种类型时，界面有没有“接住”它们的弹性布局规则？
• 失败、超时、生成内容不适用时，系统是否预先设计了出路？用户在出错时看到的是报错，还是会得到一个“重新描述需求”的引导？

5.3 验证与迭代阶段的评估清单

最后这部分是给已经上线或进入迭代期的产品团队参考的。Muse项目在验证过程中踩过的坑，都可以转化成检查项：

• 你的用户满意度结论是否建立在“客套话”上？对照行为数据，用户修改率、回访率、收藏率是否支持这个结论？
• 单点指标出现波动时，是否先做了完整的行为链路下钻，再决定保留还是修改设计？
• 模型参与界面过程中产生的bad case，有没有稳定、低门槛的反馈渠道触达算法团队？
• 提示词模板、界面文案、品牌语气是否在同一个文档里统一管理？还是各改各的最后互相冲突？
• 每周有没有固定时间让设计师和算法工程师坐在一起过一轮真实用户案例？

三个清单连起来，其实覆盖了AI产品设计从定位到验证的完整闭环。照单自查，大多数“凭感觉做AI产品”的问题，在动手之前就能筛掉一大半。

最后再分享一点个人体会。我复盘过很多项目的共同感受是：做对的事情往往不是最聪明的那个方案，而是最想清楚的那个方案。Muse项目能拿出来说的几个决策，单独看都不算石破天惊，限制生成、展示过程、让用户参与修改，这些手段很多团队都想过。区别在于，Muse把这些决策建立在一个明确的定位之上，并且敢于为这个定位砍掉那些看起来很AI的功能。设计首先是做选择，然后是做减法。对AI产品设计师来说，这句话的份量比以往任何时候都重。如果你正在做类似方向的产品，不一定要复刻Muse的具体方案，但建议先回答清楚一个问题：你的产品，希望用户在AI旁边扮演什么角色？这个问题想通了，后续的每一个设计决策都会变得清晰。