需求起点：大家都只是想再加几个字段
在设备管理系统里，一张设备台账最开始往往并不复杂。
设备名称、型号、厂家、序列号、安装位置、使用部门、当前状态……这些信息构成了一台设备最基本的档案。
但随着系统覆盖的业务越来越多，新的需求会不断出现。
维修人员希望看到故障类型、最近一次维修、维保周期和备件信息；质控人员关心检查标准、最近一次质控结果和风险状态；资产管理人员需要采购金额、启用时间、折旧方式和资产归属；管理者还可能希望增加开机率、利用率、收益等经营指标。
每一个需求单独看都很合理。
于是最自然的产品处理方式，就是继续加字段。字段放不下了，就增加区块；一个页面装不下，就增加 Tab；再复杂一点，再给不同角色配置显示权限。
久而久之，一台设备的“详情页”会越来越完整，也越来越庞大。
问题也在这时逐渐出现：信息确实越来越多了，但使用体验并没有随着信息完整度一起变好。
信息越来越完整，为什么还是不好用？
维修人员并不想看到资产折旧，资产管理员也不关心每一次维修过程，管理者更不会希望从几十个原始字段里自己拼出设备经营状况。
于是传统系统很自然地走向了另一种解法：配置。
给不同角色配置显示哪些字段，哪些字段隐藏；给不同部门配置不同列表；再进一步，允许用户自己调整列顺序、保存常用视图。
在业务范围还小时，这种方式看起来很灵活。但随着字段、角色和场景不断增加，配置本身很快就会变成新的复杂度来源。
新增一个字段，不只是把它加进数据表。还要继续判断：哪些角色能看？哪些页面要展示？详情页放在哪里？列表要不要作为一列？是否允许导出？历史配置是否需要同步调整？
角色一多，这些规则就会形成一张越来越难维护的配置矩阵。更麻烦的是，角色也不等于使用场景。同一个维修负责人，在处理一次具体故障、查看本月维修情况和评估设备更新时，需要的信息本来就不同，很难靠一套固定的“维修角色视图”解决。
而字段显隐还只是相对容易配置的一部分。
列表里应该默认展示什么？哪些字段值得成为筛选条件？不同业务场景下应该怎样组合筛选项？首页应该给管理者摘要什么？进入一台异常设备后，又应该优先提示什么？
这些问题已经很难用“把这个字段打开 / 关掉”来表达。
因为系统必须进一步知道：这些信息分别意味着什么，它们和当前正在处理的问题有什么关系。
配置可以控制一个字段出现在哪里，却很难解释它为什么此刻重要。
当越来越多的业务差异被翻译成字段显隐、页面配置和角色权限时，系统表面上变得越来越“灵活”，底下却积累了一套越来越难维护的配置规则。
这时再继续问“一台设备到底应该显示哪些字段”，已经很难得到稳定答案。
往下追问：一台设备真的只有一个“详情”吗？
最开始设计系统时，我们很容易问：
一台设备到底应该有哪些字段？
但随着业务不断展开，这个问题本身就开始变得不够准确。
一台设备当然有一些相对稳定的身份信息，例如它是什么设备、属于什么型号、安装在哪里、当前总体处于什么状态。但大量业务信息其实并不是平铺在“设备”上的静态属性，而是在不同业务过程中产生的。
维修关注的是设备作为维修对象时的状态、历史和处理过程；质控关注的是它作为检查对象时是否满足某些标准；资产管理关注的是它作为资产的归属和生命周期；经营分析又会从利用率、成本和收益的角度重新观察同一个对象。
现实中的设备还是那一台设备。
变化的是：我们当前从哪个业务域看它，以什么视角看它，以及此刻为什么要看它。
如果这些不同问题全部被压缩成一张二维表，“设备详情”就会逐渐变成所有信息的集合，而不是任何一个场景真正需要的表达。
这时，问题就不再是“这一页还能不能再塞下几个字段”，而是需要重新考虑：哪些信息属于对象本身，哪些属于围绕它发生的业务；不同使用者在不同场景下，到底需要看到哪一部分。
重新设计：保留完整世界，而不是展示完整世界
解决这类问题，并不是简单地把一张大表拆成很多张小表。
完整的信息仍然需要存在。系统依然要知道这台设备是谁、发生过哪些业务、当前处于什么状态，以及不同信息之间如何关联。
需要改变的是这些信息被组织和呈现的方式。
在实际设计中，可以先把设备相对稳定的身份与关键状态保留为对象摘要，再把维修、质控、资产等信息按照各自的业务域组织起来。使用者进入设备时，不必首先面对所有字段，而是先看到与当前工作最相关的一组信息，再根据需要继续进入具体业务。
例如，一名维修人员看到的设备摘要，可以优先呈现设备当前状态、故障情况、最近维修和相关任务；管理者看到同一台设备时，摘要则可能更多强调风险、利用率和近期异常。
同一份底层业务事实，由于当前视角和目的不同，可以形成不同的摘要。
这和传统的“给不同角色隐藏几个字段”并不完全是一回事。真正重要的是，系统开始知道这些信息分别属于什么业务语义，以及它们为什么会在某个场景下变得重要。
系统需要保留完整的业务世界，但没有必要每次都把完整世界展示出来。就像地图会根据当前是停车、找酒店、导航等不同场景，动态呈现不同的信息。
再往前一步：界面一定要提前画死吗？
传统软件必须提前决定页面长什么样。
产品经理设计一个设备详情页，再根据已知角色和业务场景配置不同字段、区块和操作入口。这在过去是很自然的，因为软件只能按照预先定义好的界面运行。
但当 AI 开始参与系统交互，这个前提也开始发生变化。
如果底层已经能够明确表示设备是什么，它与哪些业务对象有关，当前处于什么状态，不同信息属于哪个业务域，又能够识别使用者当前正在解决的问题，那么系统未必还需要为所有场景提前设计一套固定页面。
同一台设备，在“处理故障”“评估是否需要更换”“查看本月质控风险”这些不同问题下，本来就应该呈现不同的信息组合。
AI 可以参与的，并不是把一张越来越长的设备大表重新总结一遍，而是在稳定的业务表征之上，根据当前意图组织合适的摘要、关系、历史和操作入口。
AI 不是替人读完一张大表，而是基于稳定的业务表征，为当前问题生成合适的视图。
这也意味着，AI Native 系统真正需要重构的，可能并不只是界面的生成方式。
在它之前，还需要先回答一个更基础的问题：
现实中的对象、关系、状态和业务差异，究竟以什么方式存在于数字世界里？
这也是“表征”成为 AI 落地基础问题的原因。