UXTOOLS-探索数字化体验

AI时代，工具的终极形态是消失

Thu, 19 Feb 2026 19:28:50 -0800

这是一次Claude Code团队成员Boris、Cat参与的一次播客，讨论了几个非常本质的问题：

当模型每3个月就吞噬掉你的脚手架，什么该被保留？什么该被删除？
工具的终极形态是什么？
当人和AI共享同一个界面、同一套工具，人的角色是什么？

一个被"误用"出来的范式

Boris 手写了入职后的第一个 PR。代码审查被拒："你居然自己手写代码？用 Claude。"

那时候 Claude 还叫 Clyde，启动要一分钟，索引跑很久。Boris 输入任务描述，等了五分钟，它一次搞定——虽然还要手动修几处错误，但某个念头冒出来了：也许根本不需要 IDE。

几个月后，Boris 在终端搭了个小聊天应用。随手给模型加了几个工具。然后魔法发生了：模型疯狂使用工具，自己写 bash，写 AppleScript，像天生就会。

Claude Code 就这么出来了。不是规划的产物，是"意外"演化的。它干掉了文本编辑器，让 AI 直接面对终端。

Bash的胜利

任何人构建 AI agent，第一反应都是创建一堆工具：find_file、open_file、search_code……

Claude Code 只给模型一样东西：bash，而且出奇好用。

团队每周都在删工具。上周删了 OS 工具，因为在 bash...Read More

数字世界的场景重构：信息架构与用体验设计

Thu, 19 Feb 2026 19:09:04 -0800

引言：数字时代的“场景问题”

我们正面临一个日益严峻的战略性挑战：在数字与物理结构交织的世界中，我们如何理解并设计清晰的“场景”（Context）。

信息架构理论家安德鲁·辛顿（Andrew Hinton）曾生动地描述过一次在机场的经历：面对着会员等级、信用卡权益、座位升级等多重身份标签，他无法确定自己应该排在哪条安检队伍中；手机上的航空应用因网络连接问题无法显示登机牌，而另一个应用则在锁屏界面上以一种他前所未见的、违反其操作习惯的方式弹出提醒。这个场景生动地描绘了现代用户普遍面临的“场景模糊性”与“场景断裂”——我们迷失在由数字、语义和物理结构共同构成的复杂网络中。

随着数字技术渗透到生活的每个角落，我们赖以理解世界的传统物理线索正在被削弱。这种场景设计的失误不仅会带来困惑，更可能导致严重的后果。2007年，Facebook推出的“Beacon”服务便是一个典型的、因场景模型错配而导致的战略性失败案例。该系统在未获得用户明确同意的情况下，自动将用户在合作网站上的购买行为发布到其社交动态中。这一设计严重违背了用户对于“购物”和“社交分享”这两个场景的心理预期，导致了大规模的用户隐私泄露和信任危机，最终以用户集体诉讼和服务的彻底关闭告终。

本文试图为信息架构师、用户体验设计师以及所有数字产品创造者，提供一个严谨的理论框架。我们将深入剖析场景在数字环境中被破坏与重构的内在机制，并为设计更人性化、更直观、更值得信赖的数字产品提供实践指导。我们将揭示，我们设计的不仅仅是界面或功能，而是在构建人们生活于其中的环境。

为了厘清数字场景的复杂性，我们必须首先回归本源，从人类理解场景的根基——我们所栖居的物理世界——开始探讨。

1. 场景的根基：物理信息与具身认知

在深入探讨数字场景的复杂性之前，我们必须首先理解人类感知世界和与环境互动的最基本方式。这并非多余的理论铺垫，而是所有用户体验设计不可或缺的基石。本章将深入分析，物理世界如何通过其固有的结构——即“物理信息”——为我们提供稳定、直观的场景线索。这些线索根植于我们的身体经验，塑造了我们对一切交互行为最底层的期望。

1.1 具身认知：我们并非孤立思考的大脑

长期以来，主流的认知科学观点（可称为“非具身认知”理论）倾向于将大脑视作一台计算机，身体仅仅是其输入和输出设备。在这种模型中，认知被看作是发生在大脑内部的纯粹计算过程。

你真的懂“场景”吗？颠覆你设计思维的5个真相

Thu, 19 Feb 2026 19:03:51 -0800

引言：当一切都“理所应当”时，我们为何还会屡屡犯错？

首先回想一下经常会经历的一种场景：你正准备赶赴一场跨国商务飞行，航空公司的App提醒你办理值机，你熟练地点击、确认，整个过程行云流水。然而，当你拖着行李箱抵达一个陌生的机场时，混乱开始了。你应该排哪个队？“天合联盟优享”（SkyPriority）、你购买的“高端经济舱”、你持有的“银卡”会员身份，到底是什么关系？你掏出手机想查看电子登机牌，App却因为连不上机场的付费Wi-Fi而无法刷新。

乘客在机场的信息场景

在数字与物理世界日益交织的今天，我们常常因为对环境规则的误解而感到压力重重。我们每天都在谈论“用户场景”，设计着各种“场景化”体验，但我们真的理解“场景”到底是什么吗？安德鲁·辛顿（Andrew Hinton）在他的著作《理解场景》（Understanding Context）中，提出了一系列颠覆性的观点，彻底挑战了我们对“场景”这个核心概念的传统认知。

一、场景不是被动的背景，而是我们主动的“行为”

我们通常认为，场景就是人物、物体、事件所处的“环境”。它像一个静态的容器，比如“用户在咖啡馆里使用App”。然而，这个看似无懈可击的定义却隐藏着巨大的误导。计算机科学家保罗·杜里什（Paul Dourish）提出了一个颠覆性的观点：

“场景不是用来描述环境的；它是人们所做的事情……它是互动中涌现出来的特性，在当下和行动中被决定。换句话说，场景和……活动……是无法分离的。场景……源于活动本身，并由活动本身来维持。”

这个观点彻底改变了游戏规则。场景不是一个被动的背景，而是一个动态的过程，由我们的行为和理解共同创造。基于此，安德鲁提出了一个新的有效定义：

这对所以需要基于场景开展工作的人意味着什么？如果我们仅仅将场景视为一个静态的“容器”，就会忽略一个至关重要的事实：用户在与产品互动的过程中，他们的理解和行为本身就在不断地创造和重塑着场景。过去，我们以为场景是预设的；这个真相揭示了，场景其实是生成的。我们的工作不是为某个静态背景设计，而是为用户持续创造场景的动态过程提供支撑。

一、当下的困局：疲于奔命的AI追逐游戏

过去两年，AI行业像是按下了狂飙键：

- 每个月都有新模型发布

- 每周都有新工具上线

- 每天都有人分享"最新最强"的AI神器

于是，一场集体性的追逐开始了。

企业疲于评估新工具，员工疲于学习新功能。个人的AI订阅列表越来越长——Claude、ChatGPT、MinMax、Cursor、各种Copilot……每个月的订阅费，已经超过了几个流媒体平台的总和。

你会发现自己陷入怪圈：看到新工具就想试，试完几次就放弃，然后又去追下一个"更强大"的。工具箱堆满了各种AI应用，但真正每天在用的，还是那两三个。那些被寄予厚望的"生产力革命"，最终只是在浏览器里多了几个吃灰的标签页。

更讽刺的是：

很多企业花费数百万采购了最新的AI解决方案，员工却还在用它写周报、生成PPT汇报材料、润色邮件。那些号称能"重塑业务流程"的AI工具，最后的使用场景和一个搜索引擎没什么区别。

2025年全球企业在AI上的投入超过2000亿美元，但如果问一个残酷的问题：这些投入真正改变了什么？

答案可能会让人失望：

- 90%的企业AI项目仍停留在试点阶段

- 员工真正高频使用AI的场景不超过3个

- ROI能达到预期的不到20%

我们见证了AI能力的飞跃，却没能把它变成真正的生产力。

原因很简单：我们一直在追逐新模型、新工具、新功能，却从未停下来思考一个本质问题——AI到底需要什么才能真正工作？

我们不得不承认一个事实：

智能体将吞噬记录系统

Sat, 07 Feb 2026 17:20:44 -0800

作者：Zain Hoda

原文：https://x.com/zain_hoda/status/2019049069134417975

在企业软件领域，有一个名词叫“记录系统”（System of Record）。它指的是某一特定类型数据的权威来源。Salesforce 是你客户数据的记录系统；Workday 是你员工数据的记录系统；NetSuite 则是你财务数据的记录系统。

在企业软件中，占据“记录系统”的地位是最稳固的护城河。你的 UI（界面）是否笨重，或者功能是否落后于竞争对手，其实并不重要。只要数据住在你这里，所有人就必须来找你。所有的集成都指向你，所有的工作流都经过你。从字面意义上讲，你就是“单一真理来源”。

然而，这个地位即将崩塌。

数据量其实很小

关于“记录系统”，实际的情况是：它们包含的数据量并不大。

你的整个 Salesforce 实例可能只有几 MB 到几 GB。这涵盖了全公司的每一个客户、联系人、商机和活动。即使算上图片，你公司整个 Jira 历史记录（每一个曾创建过的工单）可能也就 1 GB。你的 HubSpot、Asana、Monday 看板、Notion 工作空间：所有这些加在一起，可能还没你手机里的一段视频文件大。

在过去，当与数据交互的唯一方式是由于应用程序的界面时，这并不重要。数据虽然小，但被“困”住了。你必须登录 Salesforce 才能看到 Salesforce 的数据。应用程序和数据是熔为一体的。

AI 智能体打破了这个假设。

智能体需要访问权限才能工作

为了发挥作用，人工智能代理需要访问您的系统。因此，您需要将其连接到您的客户关系管理系统 (CRM)、项目管理工具和文档系统，并为其提供 API 凭据。这才是关键所在。您希望代理能够查找信息、更新记录并代表您执行操作。

但接下来的事情发生了：

智能体在履行职责的过程中，开始抓取数据。它需要上下文来回答你的问题；它需要了解你的客户来辅助销售；它需要查看你的项目来协助管理。

数据量很小，而 API 是开放的。在几分钟甚至几秒钟内，智能体就已经拥有了所有内容的完整副本。

语义层失败了，接下来是场景图谱……除非我们能做对。

Sat, 07 Feb 2026 00:49:11 -0800

作者：Prukalpa

原文：https://x.com/prukalpa/status/2018703494744600908

上下文图谱是近来热门的话题。然而，我总觉得这个故事似曾相识……

回想一下几年前语义层的热潮。各种会议、博客和推特都在宣称它是现代数据栈中缺失的一环。人们争论语义层应该放在中心层还是继续嵌入到工具中。作为首发合作伙伴，我亲历了dbt发布其语义层的过程，以及dbt和Transform在我们公司内部展开的激烈竞争。数据大辩论数据世界迅速攀升至过高的期望之巅，我们也悄然滑落至失望的低谷。

快进到今天，这种感觉惊人地相似。场景图谱的热潮始于去年12月，由Jaya Gupta发起和 Ashu Garg 的发布的文章，认为场景图谱是下一个万亿美元的商机。自那以后，人们一直在争论场景图谱应该是什么样子，如何构建它，以及它将如何影响更广泛的数据生态系统——包括来自 Glean 公司的首席执行官 Arvind Jain。而且，嗯，我首席信息官们纷纷发表对 LinkedIn 的热情评论，而各地的创业公司则将他们的产品定位为“X 的场景层”。

我完全赞同——关于场景图谱的讨论与我过去几年从数据领导者那里听到的观点不谋而合。上下文至关重要，而场景图谱有潜力解决这个问题。但我同时也目睹了当一个精妙的理论遇到混乱的企业现实时会发生什么。

所以我的问题是：

语义层为何失败

曾经流行的观点，事后看来往往错得离谱。我们会改写历史，仿佛缺陷一直显而易见，结局也一直不可避免。

但事实并非如此，语义层并非源于糟糕的想法或不成熟的技术。事实上，从理论上讲，它具备所有成功要素。

语义层的核心承诺既简单又强大：

一个所有人都理解的通用指标定义平台。
无合约限制——客户可以自由切换工具
定义一次，即可处处使用

问题与价值的契合度非常高。所有人都认同这是必要的，数据人员宁愿跳窗逃生也不愿再为相互矛盾的指标或“活跃用户”的真正含义争论不休。问题与解决方案的契合度也无可挑剔——这项技术行之有效，dbt 的工具就证明了这一点，例如MetricFlow, Transform, Cube。

问题在于：产品与市场的契合度始终未能实现。语义层始终未能作为一个独立的类别脱颖而出。这并非因为人们不需要它，而是因为它遇到了三个结构性问题。

1.激励机制错位

对于 Power BI、Tableau 和 Looker 等公司而言，语义并非普通商品，而是护城河。尽管指标本身存在局限性，但它们早已存在于 BI 系统中。如果将它们放到独立的语义层，就意味着客户可以轻易地从一款 BI 工具切换到另一款。

BI没有动力去支持独立的语义层。本·斯坦西尔换句话说，“他们（BI...Read More

如何构建场景图谱？

Sat, 07 Feb 2026 00:00:42 -0800

作者：Jain Arvind

原文：https://x.com/jainarvind/status/2019553277571190821

场景图谱正迅速成为企业人工智能领域最热门的话题之一，投资者们也对此非常关注。Foudantion Capital的Jaya Gupta和Ashugarg称其为“价值万亿美元的商机”。

这是因为，尽管人工智能模型现在可以使用工具，但它们仍然缺乏真正实现工作自动化所需的流程知识。记录系统可以捕捉决策，但真正起工作的发生在会议、聊天、电子邮件和文档中。如果缺乏对实际工作方式的结构化了解，人工智能就无法可靠地实现自动化。

在各种宣传攻势下，社交媒体上的帖子始终围绕着两个问题：什么是场景图谱？以及如何构建场景图谱？在这篇博客中，我们将详细阐述Glean公司构建场景图谱的方法，并解释我们为什么采取了我们所采取的方法。

什么是场景图谱？

场景图谱是一种模式，它将企业实体（人员、文档、工单、系统）与它们之间操作和事件的时间轨迹连接起来。然后，它从这些轨迹中挖掘出可操作的洞察，使人工智能能够理解工作的实际完成方式。

场景图谱可以帮助人工智能回答诸如以下的问题：

“P1事件在这里通常是如何解决的？”
“关于产品 X，最常见的升级问题有哪些？”
“从‘试点项目启动’到‘交易完成’之间通常会发生什么？”
“对于这个团队来说，‘入职培训完成’究竟意味着什么？”
“典型的部署需要多长时间？为什么？”

目前的智能体难以处理端到端流程或长期任务（跨越数周或数月），这些任务需要综合来自多个不同系统的知识。

当将跨越不同事件的多个任务关联起来时，需要整合来自各种来源和众多人员的信息，而每个人执行工作的方式都略有不同，流程中还包含一些局部例外和特殊情况。但记录系统通常只显示当前状态，很少能捕捉到这种执行差异或完整的历史背景，因此依赖这种不完整的视图可能会导致盲点和次优结果。

相反，建立一个组织真实流程的内部模型——一个由实际行动轨迹构建的场景图谱——就成了了解要遵循的结构和工作背后意图的最佳途径。

从“是什么”到“如何做”

场景图谱描述了工作流程，它从描述“存在什么”转变为描述变化“如何发生”：

“什么”：传统数据和知识系统对事物进行建模：客户、工单、文档、人员、系统。
“如何”：场景图谱对行为进行建模：谁在哪些应用程序中做了什么，以什么顺序做，以及产生了什么效果。

场景图谱是必不可少的，统一场景层（UCL）能让场景图谱真正发挥作用——构建能够消费、学习和行动的系统。这才是智能体真正实现自主的方式。

问题与解决方案，尽在一图。供应商延误，风险评分飙升，截止日期临近。没有UCL时：数据孤立，纠纷持续 2-3 天，流程不受监管，没有审计追踪。有了 UCL：四个数据源融合为一个统一的平台，情境分析对信号进行评分和路由，三个协作方接收受监管的上下文信息包，证据账本记录每一个决策——从 08:15 检测到信号到第 4 天准时交付。

执行摘要

企业级人工智能正在大规模失败。标普全球市场情报公司的数据显示，到2025年，42%的公司将放弃大部分人工智能项目，高于一年前的17%。对财富2000强企业部署情况的行业分析表明，87%的企业级人工智能实施未能达到投资回报率目标。智能体会造成上下文信息碎片化，并且在没有合约的情况下将数据写回运营系统。

问题不在于模型能力。基础模型已经发展得非常完善。问题在于环境——支离破碎、缺乏管控，并且被视为副产品而非精心设计的基础设施。

场景图谱已成为一个引人注目的理论——它以结构化的方式表示企业知识，使人工智能能够进行推理，而不仅仅是检索。但上下文图作为一种数据结构是必要的，而非充分的。一些难题仍然悬而未决：

智能体决策：智能体必须分析情境并做出决策，而不是遵循脚本。这需要系统能够“消费”图：遍历图、推理、评估选项并确定响应。否则，智能体就无法真正自主。
代理生产化：部署必须在运行时不断演进。这需要基于图进行操作的系统：创建、合并、修改、连接——每次执行都积累智能。否则，代理在发布后就会停滞不前，并在生产环境中逐渐失效。
企业集成：企业在ERP、EDW、流程挖掘和IT服务管理（ITSM）等领域投入了数十年时间。这些系统蕴含着企业所需的信号和机构知识。任何解决方案都必须整合这些投资，而不是忽略它们。

将元数据直接导入 Neo4j 并不能让智能体正常工作。你需要消费结构（读取系统的机制）、变更操作（写回系统的机制）以及受控激活（安全运行的机制）。这才是真正自主智能体与脚本辅助驾驶系统之间的区别。

本报告将统一场景层 (UCL)视为企业级上下文工程的领先架构——该架构实现了上下文图的运行，并使真正自主的代理能够在企业治理中运行。

1. 场景工程：一门正式学科

1.1 定义和范围

上下文工程是对大型语言模型在推理时所接收的所有信息进行系统化的设计、优化和管理。这一定义源于对超过1400篇研究论文的调查（arXiv...Read More

场景图谱

Fri, 06 Feb 2026 21:22:37 -0800

作者：徐成进，李牧之，杨策浩，姜旭辉，鹿鸣源

原文：https://arxiv.org/html/2406.11160v3

知识图谱（KG）是许多人工智能应用的基础结构，它通过三元组来表示实体及其相互关系。然而，基于三元组的知识图谱缺乏关系知识的上下文信息，例如时间动态和来源细节，而这些信息对于全面的知识表示和有效的推理至关重要。上下文图谱（CG）则通过整合时间有效性、地理位置和来源溯源等额外信息来扩展传统的知识图谱结构。这种整合提供了对知识更细致、更准确的理解，使知识图谱能够提供更丰富的洞察并支持更复杂的推理过程。本文首先讨论了基于三元组的知识图谱的固有局限性，并引入了上下文图谱的概念，重点阐述了其在知识表示和推理方面的优势。然后，我们提出了一种上下文图推理范式CGR 3，该范式利用大型语言模型（LLM）来检索候选实体及其相关上下文，根据检索到的信息对其进行排序，并推理是否已获得足够的信息来回答查询。我们的实验结果表明，CGR 3显著提高了知识图谱补全 (KGC) 和知识图谱问答 (KGQA) 任务的性能，验证了将上下文信息融入知识图谱表示和推理的有效性。

1介绍

知识图谱（KG）是一种结构化的知识库（KB），它将事实性知识组织成三元组的形式，即（头部实体、关系、尾部实体）。这些三元组相互交织，形成类似图的结构，其中每个节点代表一个实体，每条边代表一种关系。这种结构化的表示方法使机器能够轻松理解和推理知识，从而支持各种智能应用，例如问答系统（Sun et al.）。2024），语义分析王和舒（2023），推荐系统 Wang 等人（2019），以及更多。

图1：基于三元组的知识图谱的局限性示例(a) 举例说明知识图谱构建过程中上下文信息的丢失可能导致提取出相互矛盾的三元组；(b) 举例说明基于三元组的表示方法难以表示涉及相同实体和关系但发生在不同上下文中的两个事实；(c) 举例说明基于三元组的知识图谱推理方法通常会学习知识图中频繁出现的规则模式，但它们往往会忽略可能影响这些规则有效性的上下文；(d) 举例说明基于三元组的知识图谱推理方法难以回答涉及关系知识或超出知识图谱三元组范围的上下文信息的问题。

虽然这种基于三元组的结构通过使用模式和本体提供了清晰的语义和精确性，但它丢失了知识的上下文信息，并且无法捕捉现实世界知识的复杂性和丰富性（董）。2023由于我们无法仅用实体和关系清晰地对领域中的知识进行建模，因此许多近期的知识图谱（KGs） Pellissier Tanon 等人（2020塔拉尼（2021知识图谱（KG ）的设计理念是半结构化的：它们既利用了结构化数据（例如本体）的刚性模式所提供的清晰语义，又兼具非结构化数据的灵活性。这类知识图谱集成了多模态知识，包括实体描述、图像、时间戳和其他元数据，所有这些都可以被视为三元组知识的上下文。在本文中，我们将这类知识图谱称为上下文图（CG）。通过整合这些语义上下文，上下文图谱能够提供更全面、更细致的知识表示，超越了传统的基于三元组的方法。这使得知识图谱在知识表示和推理方面拥有更高级的能力。

此外，在海量文本语料库上预训练的大型语言模型（LLM）已展现出强大的语义理解能力（Brown等人）。2020a）。而且，将LLM用于知识图谱推理已成为研究热点（Wei等人）。2023廖等人2024）；孙等人（2024然而，知识图谱可能包含大量的实体和关系，但并非所有实体和关系都得到了完整的标注和连接，导致数据稀疏性。这种稀疏性使得逻辑推理模型（LLM...Read More

别再追逐人工智能工具了，开始了解你自己吧

Fri, 06 Feb 2026 18:49:02 -0800

作者：Tatiana Tsiguleva

原文：https://x.com/ciguleva/status/2012570975163031785

每周都有新的AI工具问世。

有时每天都会发生。

Midjourney 更新。Veo 3.1 发布。Kling 性能提升。某个你从未听说过的中国品牌突然成了“最佳”。Krea、Magnific、Runway、Pika、Luma、Leonardo、Higgsfield、Nano Banana Pro、Recraft——名单无穷无尽。

你还是不知道该用什么。

你落后不是因为缺乏资源，也不是因为缺少教程。你感到不知所措是因为你试图学习一切，而不是精通任何一项。

转变之处在于：