vince
1
我发现当前的AI助理的配置，是在页面上配置对应的助手。
在使用中，我发现有几点想要提供更强大能力的地方，罗列如下：
1、样式问题。当给页面配置了AI助理之后，在实际页面时，关闭AI助理对话框，页面的其他组件宽度不会动态占满剩余宽度。如果有弹窗的话，还会遮盖AI助理对话框，这不太符合使用常理。建议将AI助理的容器与页面布局容器级别一致，使得AI助理的对话框与页面原有组件的展示互不影响。
2、支持配置多个助理。AI助理一般不是设置成通用需求助理，一般是设置多个不同专业领域处理问题的助理。那么针对一个页面可能出现的功能，理应是可以配置多个助理，用户在使用时可以按需使用。
3、助理支持预设一些常见技能。这些预设的常见技能，可以提高用户使用的便捷性。比如翻译助理，可以预设几个常见技能（1、将表单内容的中文翻译成英文，2、将表单内容的英文翻译成中文），大部分场景的时候，用户使用时直接点击具体的技能，就能满足他们的日常使用。
4、组件级别配置助手。比如在表格组件或者chart组件，可以接入数据分析助手，在表单填写表单，可以接入表单填写助手，以此可以类推，完全可以让开发者自定义diy各种对用户有价值的助手。
5、助手对话框支持选择上下文。这个上下文主要是用户在与AI助手对话时，能够选择页面的组件，将选中组件的内容当做上下文传递给AI助理，有利于助理分析和执行得更加准确。
灵感来源如图：
样式问题：
技能灵感
组件级别绑定助手灵感
添加上下文灵感
TIanxh
2
这个样式问题，是在IDE中预览页面时的一个bug，我们会尽快修复。正式运行时没有这个问题。
其他需求很有价值，我们先记录下。
使用AI助理的路由节点，进行路由决策。
另一个思路：AI功能未必非得用聊天框的形式提供。
直接把一些确定性的AI能力做到页面上的某些点击或事件函数逻辑中，函数逻辑中是可以直接调用AI助理、AI Agent、AI大模型元素执行函数的，在函数逻辑中把需要的上下文传进去，比如：表格当前选中行变量的文本值。
这个开发模式适用于你提到的2、3、4三点，应用开发者使用该开发模式的发挥空间是很大的。
不仅是前端可视化使用，后端函数逻辑中也可以
想让AI获取页面组件内容作为上下文？不需要用户使用助理时手动去选，只需要在Agent元素中添加前端页面函数即可。
AIAgent中支持将页面函数、组件函数添加为工具，比如：表格当前选中行。运行时Agent会自动通过对这些前端函数的调用可以获取到页面或组件内容作为上下文。（前提是在Agent的系统提示词中定义Agent的任务以及什么时候使用这些函数获取数据）
这种使用模式必须搭配JitAi AI助理元素才可以，对前端工具的调用是由AI助理执行的。（其它类型的后端工具调用则没有该限制）
1 Like
vince
4
在新版开发文档中，我已经找到了一些实现场景的具体方案，这些现有方案也为我补充了不少新的思路。非常感谢，确实很有帮助。
从用户角度来看，使用体验越直观越好。而作为平台开发者，我们所面向的使用者正是应用开发者。当前提供的灵活实现方式，无疑为他们提供了很大的便利，这一点毋庸置疑。
但站在应用开发者的立场，我们的最终用户是终端使用者。一些通用能力的预设（例如技能、多助理等方案），实际上是在为终端用户保留一定的灵活性。正如您所说，当前平台已经为开发者提供了非常充分的开发空间，但如果在最终呈现给用户时功能过于固化，任何一点新想法都需要开发者介入调整，这反而会在一定程度上增加开发者的重复工作量，影响整体效率。
需要说明的是，我并不是否定极态云目前的实现方式。相反，我非常认可平台目前所具备的能力！只是希望在现有基础上，产品方也能更多地从终端用户的实际使用场景出发，做一些更贴近他们需求的考量。
