按某种框架写一个动作，动作主要功能依旧是作者自身功能
但动作附带一个功能，即获取公共子程序指定前缀名的子程序（方便他人辨别，那些是该动作扩展）显示为列表，按用户选择或输入子程序链接下载到本地，并保存数据到状态，这样即使作者更新，新动作会自动根据状态下载子程序到本地，子程序即动作扩展，作者将外置更改所需的变量放到状态中，然后子程序通过更改状态或者直接更改根上下文指定名称变量来和主动作通讯，动作通过子程序的信息按动作运行框架自动加载到指定位置运行。而子程序内除优化动作使用，亦可加载独有功能，或者给原动作加上补丁.
这样一个好用的动作，也能很轻易是契合大多数人使用，作者开发压力也不会很大，更新也不影响动作的自定义。
而且也不会因为使用体验而重复造轮子。再加上有些大佬的动作，改起来很麻烦，自己写又不一定搞的处理，使用不方便，普适性也提不起来，如果能集众人力，那么传播也会极为方便。甚至可以来个给动作的扩展再加扩展，然后形成一个动作生态。小白开发者也可以更容易借助他人的优秀动作学习动作思路，不会出现和作者不同屏的情况。以动作为核心开发过扩展后，再根据其他应用来开发动作，能事半功倍，思路也更明确。（先搞好上手的，再搞麻烦的就不会脑子那么乱。）
大致就是这样一个想法.不知道可行不
1）让动作可以自己下载子程序到动作本地，用户选择什么子程序就下载什么子程序。
2）让动作可以自己读取下载到本地的子程序，动态加载，用户选择性启用或全部启用。
3）动作作者以指定根上下文变量或者状态数据来让其他人可以用子程序修改这些数据从而自定义修改调整动作。
4）用户已选择下载的子程序相关数据备份到状态或云端，从而即使更新动作或者换电脑，自定义部分依旧存在。
5）以指定前缀命名子程序，保证其他同类用户可以直接根据前缀搜索他人写好的相关子程序，避免重复造轮子。
作用：
1）让用户通过自己添加子程序来修改调整动作，不受更新困扰。更不需要重写动作那么麻烦。
2）以指定数据更改来修改，避免作者功能过于复杂，导致想改不好改，想用不好用。
3）拉长动作生命周期，方便二次开发，微调动作比使用子程序自己重新搭建要方便得多，前提作者指定出了修改途径。
4）用户添加功能也变得更方便，不会出现别人用作者的东西做一个更好的动作，导致原作者动作少人用。
5）在谁都能轻易修改的情况下，降低同质化动作出现概率，其次对常用动作也能更方便集成相关常用功能，从而高度契合环境的动作通用，不用一个个动作页的找，也不用一个个分析动作逻辑，手动集成。一定程度上节省的了动作页空间。
6）方便以后的动作开发，单功能走子程序，多功能走动作，更方便的以各种子程序直接组装成自己想要的动作，甚至建好一个公用框架的动作，直接纯小白都能仅通过选择别人成型的子程序自动下载动态加载形成一个契合自身的工具动作，而不用去考虑运行逻辑。
毕竟是突发奇想，因此构思并不明确，大致应该就是这个意思，差不多吧。反正我不知道怎么做到，应该是又这个发展可能的，不知道是否可实现
不是专门做适配，而是找一条框架出来，可以方便各种组合的。例如专门弄个子程序实现这些功能，想那种给人更改的部分，通过那个子程序自动接壤。动作作者还是只需要开发自己的就行了，只是约定成俗的一种方式，其次我针对的是大佬动作，那个感觉的确要构建个生态，不然动作作者运营都成麻烦。对于使用者来说一个有长期生命力的动作更适合使用，普通动作一般都是针对性的没必要这么搞，除非是熟悉练手。
真没必要每个人都适配，都是基于Quicker开发的，弄个公共普适版就差不多，不然每个人适配方式都不一样，那你开发个扩展只能在一个地方用，特麻烦了吧。优化使用的扩展还好，本来就是针对性的，要是那种单纯加个功能的，那岂不特麻烦。只有基于同一种框架下，开发的扩展才是能做到我上面说的那样，由不同子程序直接组合成一个自己想要的工具动作。其次我说的是将设置相关的用变量或者状态暴露出来，也就是说，你只需要在关键的地方用状态或者变量倒一手就行，因此扩展的子程序仅仅只是通过这些名称自己去读取更改，或者插入。
我想的只是不完善，毕竟突发奇想，但毕竟不是多加工作，要是多一步麻烦工作，我都不会提了。平常都看得出来，有些动作作者，把各种输入都放在变量上的，虽然感觉只是提高阅读门槛，但是这种刚好就适合子程序更改啊，那样就借助作者的动作框架实现不一样的更符合自身的动作，
算了，我也说不清楚，。。。我只针对对当前的我提升不了的才没必要，如果能更进一步就一定有必要。
满足当下，等于圈地为牢，有些东西看着没必要，但是不去做，那就永远那样，即使不做，那也是在讨论过后，从实际还是个人甚至环境综合取样考虑后才能下结论的，直接说没必要是扼杀个人创作能力，我这里讨论的更多是技术是否实现，而不是它有没有用，至于说这个是否有需求，这是必然的，我是因为之前在这里看到的一个贴子，现在突然有感想出来的一个想法，东西有没有用，关键是有没有达成普适性的条件，这也是我问技术的原因。我做事始终尽善尽美，除非能力有限，我不喜欢样子货，我会尽可能做到我想象中的样子，哪怕很差，但是基本的必须要有。我学习一项如此，无论是否有必要，既然有过这种需求，其次自身有有能力碰一下，那就得手上走走，才论是否必要。那种将就型的东西非常没意思，学不到多少东西，装不了逼，人生毫无意义。就跟吃饭噎根刺一样，根据个人的实践，那些没必要的东西，反而是最大提升使用体验的东西，一点都不能将就，有一点将就，伸手党就会不舒服。所以尽善尽美，如果不是到达当前无法短时间再度提升，不然分享出来就像垃圾。
以上仅是我看到说没必要情绪化的产物，我仅代表我个人不爽这种毫无进步性的发言，就像过去我同事，我分享个东西，他问我“这个有什么用”，第一反应是排斥，而不是了解理解后，从实际上评价，有必要的话，我是会推倒重来的。
我很不爽的观点就是，因为什么情况，然后得出结论没办法，最后则是不了了之。
我更想的是找到解决问题的方法，即使因为个人能力从而完不成，那也是当下暂停，若后面某刻发现解决方案，且此时依旧未被解决，那么必定要干掉这个问题，留着问题不解决，学习都不会有动力，一辈子都会遗憾。需求环境与装逼，还有理解新知识的破壁感，是我动力最大来源。
总结一句话，我不爽这种轻视态度，我更认可实事求是的直接面对问题讨论，而非说东扯西的绕路话术，即使我啥也不是，即使我没资格说这些话。我不爽就是我不爽，我只直接对话，有不爽，会直接说，我只认可实质，我吹大佬流弊也是真心实意。
如果有谁不习惯这种交流方式，麻烦提一下，我必不会再找其对话，就像我旁边同事一样，对方不认可一码事归一码事，对方不习惯没有面具的对话，因此拒绝交流，所以就不交流。😎
请考虑成本与收益，QK不是非盈利公司。你说的这个，普通用户根本就不可能用，这已经排除95%的人了，5%的人当中可能又只有50%的人有兴趣去用，这又排除了一大部分人，想想还有多少目标用户，可是这要花多少时间完成这个功能呢？值得吗？我想QK主打的还是小白也可以简单的做一些自动化，而不是做为一个环境部署。
1，这个帖子是随便聊聊
2，这个讨论的是动作实现，跟cl无关
3，这是说一种约定成俗的方式，技术上是否可行
4，这是针对有需求用户，你觉得不需要管我啥事？除非有对应完美替代思路，那么哪怕只有几个人需求，它都是必要的。
5，最重要的是讨论实现可能，而不是你们一个个否认我，要否决，至少从技术说明吧，还有你的百分比只是你以为吧，你又没调查过。
6，quicker是有足够底走得更高，这不仅仅只能作为一个小工具，如果只是小工具，那么各方面交互不会这么方便，自动化工具我也用过，根本不像这个一个简单。
7，未来是全民学习的时代，我只是窝在这里学习，我自然会诞生各种思路，是否成立不用管，是否实际不用管，在能触及的情况下，会自己琢磨出可行路线，这就是经验。
如果只会普通使用，当个伸手党，哪未来就不会有任何起色，创造才能无穷未来。如果不是时常完善想法构造更好的工具，是根本做不出更符合的工具。学习是循循渐进的，起步才决定下一步。
8，你说的情况其实更多是冷门动作的情况，热门动作下载量就看得出来，而且功能性不强的动作才没必要这样搞，你要是能开发软件的框架去开发动作，你没个生态结构，一个人搞要累死。
事情做不做仅看是否有技术可行以及自己是否乐意。你乐意那你做，你不乐意，那不做不就行？又不是逼你做。最重要的一点，请根据我的语境回答问题，不要曲解我的意思。
京公网安备 11010502053266号