- 所有用户看到同一个界面，结果是新用户看不懂，老用户又对早就知道的内容感到厌烦。
- 按用户调整界面确实有用，但必须说得出用户为什么看到这样的界面，而且要能关掉。
- 分界线在于：调整是为了帮用户把事情办成，绝不能用来诱导用户下单。
传统网站和应用做不到的地方
好的店家跟新客户和老主顾说话的方式不一样：新客户需要指引，老主顾图的是快。可大多数应用给所有人看同一个界面，于是新客户摸不着头脑，老客户也觉得烦。
所有人共用一套流程的应用，开发起来容易，用起来难。新手需要指引，熟手需要快捷方式，有风险的个案还需要多一道检查。
千人一面的网站和应用，逼着用户自己去琢磨系统怎么对应自己的角色。新员工面对一长串菜单，老用户每次都得把同样的说明再看一遍，在语言、视力或设备上有局限的客户，可能会卡在一条根本没为他们设计的使用路径（Journey）里。传统的个性化（Personalization）通常只换横幅，或者换一下推荐的商品。
自适应 AI 产品（Adaptive AI Product）更进一步，会根据情境调整顺序、步骤、说明和帮助内容。但调整要有边界，产品才依然好学、可预测。用户应当知道哪些地方调整了、为什么调整，能修改系统记住的内容，并且随时可以回到标准体验。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 预先划分用户群（Segment），在几个固定位置更换内容 | 根据当前情境动态选择说明、工具和自动化程度，同时让用户看得到、也控制得了这些调整 |
自适应产品要把事件、用户画像（Profile）、规则和功能开关（Feature Flag）连起来，并保留一个始终可用的默认版本。AI 帮忙挑选合适的帮助方式，但权限、价格和核心组成部分仍要遵循可预测的规则。
企业可以用上的新能力
按用户调整，正确的做法是先看这个人是刚上手还是已经用熟了，再相应调整顺序和说明；同时随时说得出他为什么看到这个界面，并让他随时可以切回完整版。
项目形态
系统先有一条人人都能走完的核心路径（Core Journey），再根据情境增减帮助，比如给新手的上手引导（Onboarding）、给熟手的精简界面，或者按行业定制的说明。调整不应该总是挪动重要按钮的位置，只在明显能减轻负担的地方做。
可以有的功能
功能可以包括自适应上手引导、动态表单、情境帮助、下一步最佳行动（Next-best Action）、按角色划分的工作区、偏好记忆、无障碍模式，以及“重置”和“为什么显示这个”的界面。用户必须看得到、也管得了系统记住的信息，并且可以拒绝自己不想要的调整。
技术与数据
数据层可以包括埋点（Event Tracking）、用户画像存储（User/Profile Store）、功能开关和同意（Consent）管理。规则和模型配合选出要展示的版本（Variant），再通过实验平台（Experimentation Platform）衡量效果。重要功能必须有一个默认版本，在 AI 宕机、新用户数据还很少，或者用户不同意系统记住自己的时候，照样能用。
好处与投入的理由
新用户上手更快，熟练用户用更少的步骤完成工作，客服团队收到的、因界面和角色不匹配而产生的提问也少了。企业可以根据真实行为改进体验，不必另做好几个版本。不过，价值要通过任务成功率（Task Success）和用户的理解程度来衡量；只看停留时长或点击次数是看不出来的。
- 渐进式引导（Progressive Guidance），按熟练程度决定说明多少
- 动态工具集（Dynamic Toolset），只开放符合当前状态和用户权限的操作
- 生成式界面（Generative UI），生成贴合任务的数据结构或摘要，不会毫无限制地随机生成布局
- 偏好控制（Preference Control），让用户修改系统的记忆，或恢复默认设置
模拟案例
实际使用场景
一款旅行规划应用给新手看引导式提问和详细说明；老用户用几句话说出目标，就能拿到一份可以修改的行程。出行有特殊限制的家庭，还会多一道检查步骤。
在另一个模拟案例中，一款项目管理 Web 应用的使用者有企业主、经理和新员工。企业主看到的是例外情况和待做的决定，经理看到工作队列和任务之间的依赖关系，新员工则得到一步步的指引。大家用的是同一套记录，也可以切换视图。
如果用户经常拒绝建议或返回上一步，系统会降低调整的力度，直接问用户想要什么，不会悄悄自己下结论。对还没有任何数据的新用户，应用使用团队预先设计好的默认路径（Default Journey），不会单凭年龄、设备或所在地这类可能出错的信号去猜测用户的角色。
调整预算（Adaptation Budget）
规定系统可以调整什么、什么必须保持不变，以及用户怎样恢复原样。
先从内容和引导开始调整，导航和重要操作放到后面。
范围、风险与效果评估
写给开发团队 · 技术指标
Personalization 可能演变成暗中引导用户，或者造成信息茧房（Filter Bubble）。凡是涉及价格、权限或承诺的部分，禁止在未告知用户的情况下调整。要衡量 Task Completion、Error、Undo、Help Request、User Control，以及不同用户群之间的结果差异，并检查实验有没有降低 Accessibility。
个性化可能造成信息茧房，或者让体验变得难以预测，所以需要默认版本、解释说明、隐私保护和无障碍测试。
写给开发团队 · 技术指标
应跟踪的指标：Task Success by Segment、Time-to-Proficiency、Preference Correction、Accessibility Error 和 Retention
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
如果撤销操作和求助次数上升，某些用户群完成任务的比例下降，或者客服团队已经没法向用户解释界面，就该收回调整。每一个版本都必须能单独关闭，而且关闭之后核心路径照常可用。
BUSINESS & PRODUCT READINESS
好的个性化说得清原因、用户管得住，产品也依然可以预测
建立一张情境地图（Context Map），把用户主动告诉系统的信息、观察到的行为和系统推测的内容分开。每一类都需要各自的同意规则、保存期限和置信度。先调整引导和内容，再动导航或操作，以控制影响范围。
写给开发团队 · 技术指标
定义 Default Experience 和恢复原设置的方法。测试要覆盖各个 Segment、Accessibility，以及还没有数据时的 Cold Start（冷启动）。衡量 Preference Correction：用户频繁纠正系统，说明 Personalization 在给他们添麻烦。
情境地图要区分用户自己提供的数据、可以观察到的数据和系统推断出的数据，并为每一类写明保存期限和保存理由。然后设定调整预算，限制每条使用路径里能变化的部分有多少，让产品保持熟悉感，测试工作量也不至于失控。
写给开发团队 · 技术指标
每条 Adaptive Rule 都应有 Owner、Hypothesis、Metric、Default 和 Rollback。先从一两个有证据表明用户会卡住的环节（Moment）入手，比如 Onboarding 或很长的表单。不要一上来就改整个应用，否则分不清哪部分带来了效果、哪部分造成了困惑。
系统可以调整哪些地方？
用户看得到原因吗？
系统的记忆什么时候过期？
默认版本还能完整使用吗？
设计能帮上用户、又不夺走控制权的智能功能
DNA Maker 帮助产品团队绘制情境、偏好和调整地图（Context/Preference/Adaptation Map），划出红线：哪些可以变，哪些必须保持不变。我们会访谈不同熟练程度的用户，免得个性化只围着重度用户（Power User）或容易收集的数据转。
我们的 UX 团队为从新手到老用户的不同人群做出多个原型版本，附带解释说明和控制选项供大家试用。测试重点放在任务成功率、用户是否困惑和无障碍，活跃度只是其中一项参考。
DNA Maker 协助开展角色与情境调研，规划自适应体验地图（Adaptive Experience Map），标明哪些环节应保持不变、哪些可以调整，以及用户如何掌控。我们先做出多个版本的原型，测试用户能否看懂，再开发真正需要的数据与事件模型、同意管理和记忆功能。
解决方案可以包括自适应的 Web 或移动应用、用户画像与偏好中心、AI 引导、功能开关和实验仪表盘，并按用户群分别做评测。如果您的产品有某个页面，新用户每次都要去问客服，我们可以拿这个页面做一次小规模实验，衡量完成率、用户的信心和撤销次数。
我们能开发自适应 Web 和移动应用、用户画像与同意管理中心、记忆功能、动态指令、基于 Schema 的生成式界面，以及实验与评测平台。架构支持更换模型，AI 还不成熟时也可以直接关掉。
如果您的产品用户水平差异大到一套流程照顾不过来，DNA Maker 可以帮您只挑 1–2 个值得调整的环节先做实验，再考虑在整个系统里做个性化。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
讨论随情境变化的界面、系统记忆、有约束的生成和无障碍设计时，可以用到这些术语。也可以拿这些术语来问：用户对这些调整知道多少、能控制多少，数据不够时默认用什么。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Adaptive UI | 按规则随情境变化的界面。可调整的部分应当有限，并且有默认状态，让用户仍然能预料东西在哪里、产品的主要功能怎样运作。 | 新手会看到更多引导 | 哪些部分可以调整，哪些必须保持不变？ |
| Dynamic Profile | 随用户画像状态变化的一组指令和工具，其中包括会随时间改变的情境，所以要有明确的数据来源、新鲜度和权限，还要让用户能纠正系统理解错的信息。 | 用户选择旅行模式时，打开行程规划工具 | 用户画像由谁定义？ |
| Memory | 系统用来跨会话记住情境的数据。记忆只应保存对任务有帮助的内容，并设定明确的有效期；偏好、事实和对话历史要分开存放，以控制风险。 | 经用户同意，记住他的饮食禁忌 | 用户能查看、修改和删除吗？ |
| Guided Generation | 让 AI 的输出保持在规定的结构内。系统在 AI 生成之前先给它结构、选项和规则，这样质量更稳定，也给人在关键环节留出检查的空间。 | 行程按天列出，每天写明活动 | Schema 能处理数据缺失的情况吗？ |
| Accessibility | 让各种各样的人都能使用产品的设计。从颜色、字体、键盘操作、读屏软件到浅显的文字，都要从一开始就设计进去，并找真实用户测试，事后补上是不行的。 | 支持读屏软件（Screen Reader）和大字体 | AI 改动界面之后，还符合无障碍标准吗？ |