叠甲:一点点纯个人想法,我没写过卡,纯使用角度的感受的思考(
最近deepseek v4pro出了,不用折腾gemini&claude api了回坑玩,发现社区里很多状态栏&交互做的相当复杂相当有意思了,但是实现思路好像还是指定格式然后永正则套UI里去渲染
众所周知,llm有时候会抽风导致正则匹配不上,然后掉格式之类的
同时因为llm的消息没状态,一些连续性的UI展示性也不好,比如聊天室之类的,每次都渲染新的
此外纯html + css 写复杂UI交互其实挺麻烦的,复用性也低,重构也麻烦
这些问题在一些ai交互领域已经被解决了相当部分了,比如copilotkit以及其他llm交互的UI库,核心思路是UI组件作为一种function call之类的东西,按照json/yaml格式注入数据来实现渲染,用react来开发UI组件交互也好写一些,复用性难度也相对低
酒馆可能是受到纯文本思路的限制,走了这么一套正则的方案
说到复杂的交互,这里其实有另一种解法,就是游戏化/程序化的思路来做,比如现在很多市面上的侦探游戏,扮演游戏,但是这种定制化程度太高,不够酒馆自由,而且开发成本比较高,创作门槛比较高
其实游戏为主体,llm为辅助扮演还是llm为主体,图形化状态展示与交互算是天平两端?我觉得酒馆没有很好平衡
因为很多涉及数值的游戏,我个人觉得纯llm填数值不是特别好,我会担心llm乱填&反馈不明确的问题,我觉得应当是有一种更均衡的解法的,比如程序是主体,ai只负责每个stage/scene的演绎

最近deepseek v4pro出了,不用折腾gemini&claude api了回坑玩,发现社区里很多状态栏&交互做的相当复杂相当有意思了,但是实现思路好像还是指定格式然后永正则套UI里去渲染
众所周知,llm有时候会抽风导致正则匹配不上,然后掉格式之类的
同时因为llm的消息没状态,一些连续性的UI展示性也不好,比如聊天室之类的,每次都渲染新的
此外纯html + css 写复杂UI交互其实挺麻烦的,复用性也低,重构也麻烦
这些问题在一些ai交互领域已经被解决了相当部分了,比如copilotkit以及其他llm交互的UI库,核心思路是UI组件作为一种function call之类的东西,按照json/yaml格式注入数据来实现渲染,用react来开发UI组件交互也好写一些,复用性难度也相对低
酒馆可能是受到纯文本思路的限制,走了这么一套正则的方案
说到复杂的交互,这里其实有另一种解法,就是游戏化/程序化的思路来做,比如现在很多市面上的侦探游戏,扮演游戏,但是这种定制化程度太高,不够酒馆自由,而且开发成本比较高,创作门槛比较高
其实游戏为主体,llm为辅助扮演还是llm为主体,图形化状态展示与交互算是天平两端?我觉得酒馆没有很好平衡
因为很多涉及数值的游戏,我个人觉得纯llm填数值不是特别好,我会担心llm乱填&反馈不明确的问题,我觉得应当是有一种更均衡的解法的,比如程序是主体,ai只负责每个stage/scene的演绎











