我们能造出来，但能评判它吗？
让我兴奋的，不只是把设计师拉近代码能让我们构建得更快，而是我们能更直接地塑造用户最终拿到的东西。我已经把设计团队带进了 VS Code 和 GitHub Copilot 的世界，让代码成为探索和实现的共同媒介。目标很明确：让我们的意图、我们交付的东西，以及用户实际能完成的事情之间，连接得更紧密。
我的团队已经在向生产环境提交拉取请求了，但创意构思需要另一种节奏。加载并测试完整的产品应用，拖慢了探索和利益相关者反馈的速度。我们的 UX 工程师做了一个更轻量、模块化的产品版本——Mini-Foundry，现在有 100 多名设计师和产品经理在用。共享组件、相关数据，加上针对代码仓库的智能体技能，帮助大家借助 GitHub Copilot 把想法变成可交互的原型。设计师在做这件事的过程中学会了 Git：创建分支、提交代码、在别人的改动基础上继续开发。Mini-Foundry 让我们在参与生产贡献的同时，有了更快分享和打磨想法的方式。
旅程评估给这些更快的工作指明了方向。Stephanie Keske 是我团队里一位出色的 UX 工程师，她一直在制定我们以 UX 为核心的评估量规。我们一起试验了不同的目标和维度，把旅程成功评估与人工测试、系统思维评审结合起来。这些实验帮助我们优化流程，并排查生产环境和原型中的重大问题。它们的价值在于激发了对话：体验在哪里出了问题、为什么重要、接下来什么值得我们关注。一个通过/不通过的结果能说明需求是否满足，而旅程证据帮我们搞清楚一个体验为什么成功或失败，以及接下来该改什么。Jenny Lanier Wolski 那篇关于产品简洁性的文章，正好说明了这件事为什么对我们 CoreAI 设计团队如此重要。共享组件并不会自动带来连贯一致的体验。一个个单独看都合理的决定，可能让用户在不同产品之间不得不重新学习交互模式。
对设计而言，机会在于围绕穿行于这些环节的用户，把各部分串联起来。要从任务出发，而不是从界面出发。设想一位 AI 开发者用 Foundry 构建托管智能体。他熟悉 VS Code，但对 Foundry 如何把配置、工具和评估连接起来还不熟。在这个示意性的旅程中，他用 Foundry Toolkit 创建并测试一个智能体，然后进入门户做监控。要做到这一点，他需要找到刚测试过的那个智能体的监控视图，确认自己在正确的项目中，并弄清自己的改动是否生效。即便两个界面都能正常使用，只要开发者不得不在它们之间自行重建上下文，这段旅程对他们的要求还是太高了。系统思维式的审视能帮我们看清这些关联：早先的一个选择如何造成后来的困惑，一处小小的说明又如何帮人带着把握继续走下去。它要求我们越过自己负责的那一部分，去看看用户实际经历到的完整体验。检查工艺。评估旅程。视觉工艺给了我们一个实用的起点。代码检查可以验证组件和 token 的使用，视觉比对则帮我们注意到字体、边距和组件状态的变化。其中一些检查是确定性的：输入和规则相同，结果就相同。但合规不等于有品味。旅程质量是另一个层次，不是更长的视觉检查清单。每个界面都可以满足各自的要求，而界面之间的路径却让人不确定自己在哪里、发生了什么变化、接下来该怎么继续。评估这条路径，意味着考察决策和上下文如何跨步骤传递，而不是把各个界面的质量简单相加。> 旅程质量是另一个层次，不是更长的视觉检查清单。我们的 UX 工程团队一直在开发一套旅程评分量表 Lab，围绕一条既留有严谨、也留有判断空间的原则：能检查时就检查，需要判断时就判断。每份量表都包含标准、示例、可执行检查或评判提示词，以及一份报告。确定性检查可以验证具体要求，而基于模型的评估则对照标准和带标注的示例来解读证据。
后者的判断可能带有不确定性，不同次运行的结果会有差异，因此需要反复评估，并依靠人工校准。报告把各项评估与旅程层面的证据关联起来，评审者可以深入调查某个具体发现，而不必只看一个汇总分数。
工具负责执行，团队负责定义成功、解读证据。
对设计师或产品经理来说，起步要先为流程写一份简报：旅程从哪里开始，谁在尝试，他们需要完成什么，哪些可观察的证据才算成功。然后提供应用 URL 和任务边界，选择模型与评估设置，再针对这条流程运行评分标准。反复尝试有助于看清这条路径在哪些环节可靠、在哪些环节会中断。
下一步是检查单次运行记录，包括那些没成功的尝试，而不是只看总体得分。改动之后，用同一份简报重跑，就有了对比的依据。工具负责执行，团队负责定义成功、解读证据。
一个旅程评分标准条目的示例。人工测试与审查也是这套机制的一部分。
一条告警应当指出受影响的步骤、相关维度，以及可能出问题的证据。同事查看证据，尝试复现问题，再用调研验证或质疑这个发现。自动化运行能暴露疑点，但无法说明真实用户的体验。它的价值在于帮助团队把重要的问题看清楚，从而采取行动。
执行旅程的模型和评判旅程的模型，角色不同。执行模型依据用户画像、任务要求和安全边界，获得一份关于可见内容、控件和状态的紧凑文本快照。它结合用户目标解读这些信息，返回一个动作交给浏览器工具执行。需要时可以用截图分析等可视化检查工具做更细致的检查。要判定完成，必须有可见证据表明既定结果已经达成。
我们的实验既暴露了视觉解读上的差异，也说明不同模型需要量身定制的导航指引：在我们的实验中，GPT Sol 和 Astra 在视觉解读上表现突出。我们使用简短、直接、聚焦下一步操作的指令。GPT Terra 还会额外收到关于编辑字段、等待加载或空白页面、避免重复点击的指引。Claude Sonnet 会收到清晰分开的优先级、工具规则和完成检查，并限制重复验证和等待。Claude Opus 则收到更轻量的提示，把更多规划留给模型自己。这些是我们这套设置里的观察和提示词选择，并不构成通用排名。人工评审有助于把产品本身的摩擦与模型、指令或浏览器交互方面的困难区分开来，也能让人始终看清成本、延迟和质量：一次跑得快，只有产出团队信得过、能据以行动的结论才有用。
维度更少，方向更清
我们的实验还教会我们一件事：关于专注。给我们看重的每一项都单独设一个维度，未必真能帮我们改进。相互重叠的评判标准可能把同一个问题重复计数，而一个总分又可能掩盖某人卡住的那一刻。我最近和 Figma 的 Setor Zilevu 博士有过一次很棒的交流，谈到为什么三到五个稳定的维度，往往是聚焦改进的甜点区。维度更少，并不降低目标。它们让我们更容易把力气用对地方，也更容易看清进展。
三到五个稳定的维度，往往是聚焦改进的甜点区。
在这次构建智能体（agent）的旅程中，五个示例性的评分维度有助于把质量标准变得具体可见：
- 任务成功：开发者能否创建、测试并监控目标智能体？
- 连续性：当开发者从 VS Code 切换到 Foundry 门户时，智能体的配置和项目上下文是否仍然清晰易懂？
- 清晰度：开发者能否判断发生了什么变化、结果意味着什么、下一步该做什么？
- 进展：开发者能否朝着目标持续前进，而不会有过多循环、重复步骤或走进死胡同？
恢复能力：失败时能否定位问题、继续推进，而不必从头再来？ 这些示例用更宽泛的语言表达我们制定评分标准的意图，而非复述其内部维度或分数。权限和资源边界始终是明确的检查项，不能靠其他方面的高分来抵消。
关键在于学会定义成功、解读各步骤的证据，并把判断转化为团队可验证的改动。
示例和标签同样重要。当评审者对比体验、解释为何某个方案达标时，判断就成了团队可以共享的东西。分歧可能暴露出缺失的背景信息或模糊的标准。
学会定义成功、解读各步骤的证据，并把判断转化为团队可验证的改动。保持场景和评分示例稳定，我们就能把某项针对性改动与其基线对比，同时观察改进和退化。如果评分标准变了，就重新评估基线。目标是更好的体验，而非更好看的数字。
我们测试中 0–4 分制的维度评分示例。
让学习成为交付的一部分
我们的工作横跨探索和交付。Mini-Foundry 让我们能以轻量方式，在方向尚未定型时与利益相关者分享可运行的思路。生产环境的 PR 则把明确的改进变成经过评审的改动。VS Code Agents 窗口通过多智能体会话和自动化，帮助我的团队在这类工作中保持专注。
原型预览不能证明改动已可投入生产——测试、真实集成和评审仍然必不可少。保持改动小，是为了让工作更易评审，而不是减轻我们的责任。
更大的机会在于让质量分析足够可重复，从而跟上产品的节奏。
更大的机会在于让质量分析足够可重复，从而跟上产品的节奏。人工运行的评估和研究能提供深度，但覆盖范围和频率受限于可投入的时间和人力。它们的发现只描述某一时刻的体验。
成本更低、速度更快的自动化运行，让团队可以在产品不断变化的过程中，反复检查更多已定义的用户路径，发现新的故障点，并确认之前的发现是否仍然成立。随着产品迭代重复评估，能让证据保持新鲜；人工审查和持续维护的评分标准，则能让解读保持准确。
Stephanie 和我一致认同两个目标：把关键的产品故障暴露出来，覆盖生产环境和原型；帮助功能团队主动跟进改进。在集中找 bug 的活动之前先做辅导，能让团队有一个起点，去运行评分标准、解读证据。随着功能演进不断重复这套做法，评估就不再是一次性的检查，而会变成一种共同发现问题、调查问题、推动改进的方式。
一条有意义的用户路径、三到五个稳定的评估维度，以及一个对改进负责的团队。
对我而言，设计领导力意味着帮助更多人识别质量、为质量负责，而不是让自己成为每个决策的最终把关人。让设计师更接近代码，可以扩大我们能改变的范围；用户路径评估则帮助把这份能力引导到真正重要的问题上。一条有意义的用户路径、三到五个稳定的维度、一个对改进负责的团队——发布一个聚焦的变更，对比证据，把学到的东西带入下一次迭代。这样，更快的构建才能变成更好的交付，同时不丢失设计意图。
文章《We can build it. Can we judge it?》最初发布于 Command Line。
当智能体 AI（agentic AI，能自主规划并执行任务的 AI）把从想法到交付代码的过程大幅缩短，对用户旅程的评估就成了一项关键的设计能力。