背景与问题
最近在推进课程项目,方向是做一个旅行规划agent。进行到前端设计的时候,我和codex陷入了多轮的讨论和修正:
“不要这样,这个交互不好”
“把行程路线风格调整成…”
事后反思发现原因在于:
- 我不太清楚一个 “好的旅行规划助手的交互设计” 应该是什么样的;
- 同时, 我又能想到 “我明显不喜欢的交互设计” ,所以会不断patch
前者开发者视角,要设计一个让大部分人“用起来舒服”的页面,需要门槛较高的经验加持和前期设计;
后者用户视角,我觉得一个软件不好用,可能是因为它的设计还不成熟,也可能软件是成熟的但我有我自己的偏好需求
例如我是个P人,我希望旅行规划页面地图中,可以显示行程路线周围、会路过的好玩的地方
常见的开发范式中,这种需求可能要不断反馈、服务提供方进行评估、排期实现、发布更新这样的冗长闭环,甚至很多时候这种个人的需求很难通过评估
那有没有一种更好的开发范式,让软件更容易适配每个用户?
Better Way?
我想到之前刷到过的一个基于DSH开发工作台的演示。博主开发的工作台以插件的形式内嵌,他可以一边使用,一边告诉agent自己对哪里不满意,再让agent去修改。
基于Cordis的DSH实现了这一点:
用户正在使用的软件,也可以成为 agent 正在修改的对象。
这联系上了我之前的想法,一类以 agent 为中心、通过可插拔模块组织软件能力的底座。
从成熟基础出发,让用户塑造自己的软件
我的设想大致如下:

用回前面我的P人旅行需求例子,如果软件提供方提供了成熟的路线、地点搜索和地图能力,agent就能利用这些基础能力,根据我的需求开发适合我的前端并实时覆盖旧版前端
该设想下的用户需求适配 和 前面提到的反馈闭环 进行对比:

支撑设想的三个核心:

需要OS级别的基座?
和旅行规划场景一样,大部分软件主要应用都在移动端,而移动端的用户自由度又比较低,不像电脑能随便code ^-^ 现在手机也没有一个像电脑agent那样的东西
就算开放又需要一个合理的架构防止用户改着改着把手机变砖头了
…
End
上面是我经过一天开发后的突发奇想,假如佬友们有什么更成熟的想法,可以踢我一脚,或者说网上其实已经有类似的更深入的讨论,也可以踢我一脚 ^-^ ^-^
另外上面想到啥说啥的风格,可能让人读起来比较懵,我让AI润色了一下放在个人博客,佬友们可以看看: