为啥子程序的变量不能加个作为状态呢

这有什么意义呢，一个子程序就可以解决的事，非要额外再建个动作，况且子程序也不是不让实现状态，只是现在太麻烦了

仅仅是个设计决定而已，并没有什么额外的意义。

子程序没有可以保存状态数据的地方，多个子程序也可能产生冲突。

还是希望观察一下有没有可能出问题，然后加上这个功能。现在用存取状态太繁琐，且容易遗漏导致问题，除此以外倒是没发现别的冲突问题。动作的话，调用起来太麻烦。动作多了不好管理，如果不是大量使用子程序，动作随便就过百了，而且传递参数很麻烦，多个参数更麻烦，甚至得设计表单，还有调用动作一直显示的是ID，时间长了想不起来调用的哪个，调用名称不保险。诸如此类的问题，都不如直接用子程序方便

我猜CL设计之初肯定考虑过了这个问题，应该是不合适，所以没有加。子程序是可以多个动作共用的，如果存在状态变量，可能导致动作A通过子程序存储的变量意外被动作B修改，造成动作A不能正常工作。另外，像这种比较底层的东西更新要考虑对已有旧动作的兼容性，不然容易造成本来正常运行的一批动作突然不能正常运行。如果CL觉得不太可行，还是建议你寻找一下别的更简单的方法去实现你的需求吧~

把你想要保存的值写入到一个json文件里(ini文件也行)，需要用到的时候再读取，也是个办法

CL说的冲突问题我没法判断，可能是数据调用之间容易出现问题，那就没办法了。但你说的几点应该不是问题，第一，子程序是允许通过存取步骤设定状态的，也就是子程序本身可以支持这项功能。第二，存储变量是否会产生问题，应该是谁编写谁负责，既然设置了保存变量，就得自行考虑会不会出错，这是开发者自己的问题。第三，旧动作肯定是默认不保存，不会有影响。第四，子程序保存的变量未必就是作为输入输出参数的，有时候要使用保存的数据，配合其他参数一起使用，所以还是很有用的。他的主观逻辑我能理解，但实际使用上，就像我说的，有时候调用动作远没有子程序方便，甚至特别麻烦。软件么，都是慢慢迭代的过程，新功能总要有，我用QK有两年了吧，完全推翻重做的功能也不是没有，改完又改回去的也有，修修补补更是不计其数，在能保证安全稳定的前提下，我还是希望作为软件，尽可能提供更多的功能，然后让用户去选择用什么，不用什么

呃，感觉更麻烦了呢。。。。

感谢，回头试一下