AI产品的用户体验为何总让用户感到疲惫？从桌游助手的数据整理到OpenAI的'Harness Engineering'概念，本文揭示了AI产品设计中普遍存在的'裸马'问题——用户被迫在每次交互中重复构建上下文。文章深度拆解产品层面的'马具'设计三要素：任务边界的锁定、上下文的预置以及可见的验收标准，为产品经理提供从聊天框思维转向任务配置思维的实战方法论。

为什么你做的AI产品，用户用起来总觉得累？

上个月在做一个桌游助手的POC，核心功能是帮用户查三国杀的武将技能和规则裁定。

需求不复杂，但我踩了一个很典型的坑。当时在收集武将牌数据，三国杀从标准版、风火版、神将版到各种联动版，武将加起来几百个，每个武将有技能名、技能效果、限定技触发条件……我随手打开对话框，想让AI帮我把数据整理成统一格式，省点时间。

我说：帮我把这些武将信息整理成结构化数据，方便后面做RAG。

它出来一个表格，字段设计完全不符合我们的检索逻辑——它把”限定技”和”觉醒技”归在同一个字段里，但这两种技能的触发机制完全不同，混在一起之后检索结果会乱掉。我重新说了一遍，它这次把技能描述原文照搬进去，没有做任何格式标准化。

来回四五轮，我才意识到问题出在哪：它不知道这份数据最终要被谁用、用在什么场景、”结构化”对我来说意味着什么具体的字段和格式规范。这些背景信息对我来说理所当然，但对它来说是完全空白的。

在这片空白里，它只能猜。猜哪些字段重要，猜格式怎么定，猜做到什么程度算完成。

几乎每次，都猜错了。

前段时间OpenAI提出了一个叫”Harness Engineering（驾驭工程）”的概念。Harness本意是马具，套在马身上的缰绳和鞍具。现在的大模型就像一匹极度强壮的马，但不给它套马具，它跑两步就会被路边的东西吸引，没法带你到任何地方。

驾驭工程说的是：不要一句一句教AI干活，而是给它搭一个有边界、有标准、有验收条件的执行环境，让它能自主把复杂任务从头跑完。

这个概念出来之后，大多数讨论集中在个人工作流上——怎么给自己的Agent设好文件路径、明确风格参考、写清楚完成标准。这些都对。但我想从另一个角度聊：作为产品经理，我们怎么把”马具”设计进产品里，而不是扔给用户自己去套？

我们正在交付的，是一匹裸马

打开现在大多数AI产品，核心交互都是一个聊天框。

用户进来，面对空白的输入栏，系统最多给一句”你好，有什么可以帮你”。然后用户开始打字，AI开始猜，猜不准就追问，追问多了用户烦了，任务做到一半就放弃了。

这不是用户不会用。

是产品根本没给他们提供骑马所需的条件。

从设计转产品的朋友应该特别有感触。以前做UI，每次改稿有明确的评审依据：视觉规范、组件库、设计原则，改了什么为什么改，有迹可循。但很多AI设计工具，你说”帮我优化这个界面”，它出的方案风格可能完全跑偏，因为它不知道你的品牌调性、用户是谁、”优化”对你来说指的是哪个维度。

用户每次都要从头解释，每次都要重建上下文，交付物的质量全靠这次对话运气好不好。

这就是把裸马交给用户，然后说”这马挺好的，你自己骑一下试试”。

产品层面的”马具”，拆开来是三件事

驾驭工程放到产品设计里，翻译过来是：在用户开口之前，把该说清楚的东西提前设计进去。

第一件：锁定任务边界。

AI不擅长在开放空间里做正确决策，它需要知道自己在哪个房间里工作。

还是拿桌游助手举例。三国杀有标准版、神将、界限突破，每个版本的同一个武将技能描述可能不同，甚至裁定方式也不一样。如果产品边界是”全版本都支持”，AI在回答时就要在几个版本的规则之间反复横跳，用户一问”刘备的仁德怎么用”，它不知道该按哪个版本答。

最后我们把这个产品的边界锁定在”标准版+界限突破版”，其他版本的查询直接提示”暂不支持”。边界缩小了，AI能做出正确判断的概率反而大幅提升。

边界不是功能的减法，是执行稳定性的保证。这件事不能靠用户在聊天里自己说清楚，是产品经理在设计阶段就要锁定的。

第二件：预置上下文。

每次对话开始，系统对用户的了解是零。但好的产品可以提前沉淀这些信息，然后把它们作为每次对话的隐藏前缀。

做武将数据那次踩的坑，后来我在系统提示词里加了一段：明确了字段定义、技能分类逻辑、哪些内容需要标准化处理、输出格式是什么。加完之后再跑同样的任务，基本不用来回调整了。

这个逻辑放到产品设计里，就是在用户引导环节多收集几个关键参数——他们的使用场景、偏好风格、历史满意的结果是什么样的——然后在每次交互里静默地带上这些信息。用户不需要每次重新解释自己是谁、要什么，系统已经记住了。

第三件：让验收标准可见。

这是最容易被忽略的一层。

用户说”帮我写一段武将介绍”，什么叫完成？多少字？要不要带技能分析？语气是百科风格还是游戏攻略风格？这些如果没有事先定义，”完成”就是一个薛定谔的状态——AI觉得它完成了，用户觉得完全不是这么回事。

好的产品设计会在流程里设置可见的验收节点。任务开始前，让用户看到”这次输出大概是什么样的”，而不是等AI交稿了再来争论”这不是我要的东西”。

设计师/PM转型做AI产品，这个思路特别值得内化

设计师的核心训练是”在约束里解决问题”。做UI的时候，从来不会把空白画布扔给用户说”你自己排版吧”——你会设计好布局，预置好组件，限定好操作路径。

做AI产品是同一件事，只不过你约束的不是像素，而是AI的执行空间。

你比纯技术背景的人更清楚一件事：用户的认知负担是真实的成本。让用户每次都从头构建上下文，就像让他们每次打开软件都要重新调一遍所有默认设置——理论上能用，实际没人愿意用。

这种”用户不应该被迫做额外工作”的直觉，放进AI产品设计里，就是驾驭工程在产品侧的核心逻辑。

我最近看到一些AI产品开始朝这个方向走，不是聊天框，而是”任务配置面板”。用户进来先选模板、填参数、确认验收标准，然后启动，AI去跑，跑完对着标准核查。更像项目管理工具，不像对话机器人。

对用户来说，认知负担降低了。对产品来说，驾驭AI的工作从用户那里接了过来，放在了设计阶段本来就应该完成的地方。

这件事谁先想清楚，谁的产品留存就会好看得多。