给现有产品接入 AI：构建一个懂产品的 AI 专家

给已有产品加一个聊天入口，用户马上就会问：“这个参数为什么不能选？”通用模型很容易解释参数的概念，却未必知道页面处于只读状态，也未必知道用户用的是哪个版本。

我想做的产品助手，要能把说明书里的规则和眼前的状态对上。它答不出来时，能说出缺什么；需要操作时，能给出明确提议，而不把一段建议写成已经完成的结果。

组件复用以后，数据和交互如何一起复用

卡片样式存成模板，下次复用很方便。可卡片一旦带上设备、时间和联动，复制就可能把原页面的依赖一起带走。新页面长得没问题，查询的却仍是原来的设备。

最近做模板和参数相关功能，我把“复制”拆成了不同意图：沿用外观、复制图表后换数据、整页连同导航一起复用。它们不能都由一个不透明的 JSON 拷贝完成。

可视化产品做久了，配置面板会越来越长。字号、间距、图例，每一项都有一个合理需求。问题是，用户搭趋势图时，通常只想选数据、定时间、看到结果，不想在空白页面上把全部选项学一遍。

最近做设计器和组件需求，我不再只看能删掉多少配置项。配置怎样参与任务、值从哪里来、改变依赖以后如何处理，更影响实际使用。

独立产品接入统一权限平台，表面上是换登录和菜单，实际上是在替换一批原来藏在代码里的约定。原来的管理员管多大范围，已有页面属于谁，后台任务以谁的身份跑，都要重新核对。

这次集成，我把资源映射与授权切换单独设计。界面接入只是可见部分，原有用户的数据范围不能在迁移时被悄悄放大。

菜单少一个通常一眼就能发现，数据少几台设备却难得多。用户看到的是“这张图不对”，研发拿管理员身份一查又有结果，讨论很容易变成来回加权限。

我更习惯固定一个用户、一项应用、当前组织和一个资源，从实际查询的范围往回查。数据可见性由几层条件共同决定，任何一层不包含它，最后都不会出现。

几个应用都能用同一个账号登录，演示通常很顺。用户实际点开的却可能是一台设备的详情，链接里还带着日期和筛选条件。认证后只回到首页，登录虽然成功，原来的工作却断了。

这次接入里，我把认证回调、本地会话和业务目标分别处理。它们发生在一条访问路径上，但不能共用一个未经约束的跳转参数。

做权限平台时，一个“能编辑”就足够让几个人讨论半天。有人指按钮能点，有人指某个空间里的页面能改，还有人把发布也包括在里面。角色表容易建，麻烦在于大家用的是同一个词，说的却不是同一件事。

最近接入应用，我把授权判断收到了几个明确对象上：谁发起操作，动作是什么，资源归谁，在什么范围内生效。角色只负责把一组职责组织起来，不能把后面这些条件全部塞进角色名。