如何组织管理自己的程序系统

随着自己使用人工智能编写的脚本内容越来越多，如何管理它们已经成为一个极其重要的问题。

首先，因为要同时处理cad文件，图像文件，文本文件，应该按照文件类型分类。而且即使是图像，由于ps很开明地允许我们使用程序控制，那么保留它的文件处理是一个大类是可以的。这个类就叫TxPs类。其它的图像多半用不同的python包处理，可以归为Txpy类。这是关于图像处理的大类。其次，与cad文件相关的操作，归于Dwg类，与docx文件操作相关的大类归于Dox类。与程序文件py和text文本相关的归于Tex类。目前，我们需要这五个基本大类。TxPs,TxPy，Dwg,Dox,Tex类。考虑到3维建模，还应该引入操作skp文件的大类MoSu类。

我主张将将这些基本大类放在一个脚本中，就是因为两个原因。一个是我们必然要研究一些综合性的同时相关的函数程序。另一个是它们必然会用到一些关于一般文件及文件夹上操作的函数，归于通用类CzWj类。如果脚本确实太大不方便，今后再进行分解处理即可。总的来说，还是放一起好。除了最普遍文件的操作，还需要针对列表CzLb类的操作，字典CzZd的操作，CzZf字符串的操作的类。

还需要一个数学函数类,MaSt类。

这十一大类足够将我们的函数清晰分流了。

在每一个大类中，通常是围绕某个工作目标建立一系列的函数。最好是在工作流程中，直接将别的大类的函数就写在该工作目标的主函数区域。问题解决后以后再归回大类。这就需要确认是否可以将类的函数分开放，与其它类混杂。

现在要继续解决的问题就是函数程序久了读不懂和不会用的问题。应该伴随脚本建立一个独立的文件夹体系。我们在D盘，建立了《英语学习》的文件夹，脚本放在该文件下的CAOZ文件夹。如果我们要统一整个系统，只需要在D盘继续建立其它如《文本制作》《CAD绘图》等项目名称。考虑到某些软件包排斥汉语，这些名字还是换成英文或拼音为好。但因为可以替换查找，发现问题再处理也不迟。应该在D盘建立一个统一的moxinganli文件，存放所有函数使用到的案例文件。我们的想法是，为每个函数设立一个jh=1的默认激活参数，但是每个函数的下方，都紧跟一个标准应用示例，除了限制它只在主程序执行时执行，我们还将它的jh参数调为jh=0，这样，时间久了，要查看某个函数的运行示例，只要手动将激活参数删掉，按默认参数运行即可产生运行结果。

上面的处理可以解决函数越来越多，也越来越乱，并且久了不知道怎么使用的问题。

另一个需要解决的问题是，要调用第三方软件的操作，应该同样按照标准的格式处理。第一，如果没有第三方软件打开一个已经激活的文件，就自己打开一个新的来自于系统的文件。第二，如果已经有了打开的激活文件，就连接上它并控制它。不管是docx文件还是dwg文件都适合这个模式。而我们的脚本本身的运行，不应该直接连接和启动打开新文件。

关于函数的出错处理，应对实际的不可预设的复杂环境，必须在函数出错后继续尝试3-5次。不要害怕层层嵌套，这反而加大了对错误的控制。如果函数s1因为错误要尝试3次，它包含在函数f1中又要因为出错尝试3次，那么s1就有尝试9次的可能。我们并不是真要尝试9次。在大多数情况下是不会出问题的。我们需要的是一个标准模式，定义基本的不包含错误处理的函数F(X)，使用通用的错误处理模式获得目标函数及其最终命名。

关于自动化操作这一块，很多情况下，直接使用pyautogui其实是最可靠简洁的。只需要确保把桌面显示清理干净，能够按照图片找到按钮点击就可以了。不管是图像还是cad文件，很多情况下，在天正和ps平台上操作其实是更稳定可靠和方便的。程序的研究不能脱离历史的渊源。

我们还要研讨一个重要的问题。复杂函数尽量不要把打开，关闭文件操作撸在一起。把一个文件打开，操作一番又关闭，这样的函数也是有的。但最好是在打开的文件上直接上操作。打开文件，使用别的命令，或者人工打开。关闭文件特殊一些。关闭也可以采用专门的关闭函数。

也许计算机模式更适合文件分散成多个文件的较小模式。这是因为，对于图形对象的选择，大量文件放在一起，将造成遍历大量对象的尴尬。分开一个大文件，就实际上实现了选择的分区。一般来说，单个文件的操作通常都是很稳定的。所以我们可以尝试平面立面都分开在不同的文件。当然，使用pyautogui，我们可以调用图层关闭方便选择对象。屏幕选择可以实现点击一点和另一点。结合pyautogui才能很好解决这个难题。轻量化的单文件也是稳定的基石。对这种文件进行同时打开，处理，关闭通常是不会有问题的。

绘图的本质是表达三维空间的真实逻辑。我们不能想着去建立一个三维模型，再去死板地将三维模型表达为二维图。我们应当直接从简单的三维轮廓的理解表达成二维图形。一个复杂的坡屋顶设计，不是用三维设计好再转变为二维，这是一种不成功的模式。应该在绘制三维模型信息时同时生成二维图。画一个三维box，它就应该同时在画平面剖面立面。不需要借助别的软件做成3维模型。如果我想表达一个box，两个视图就够了，其余的应该是按照默认自动完成。如果不是，应该继续画完整几个大框架，其余的细节程序再完整。例如我只要画单框线，其余它自己细化。如果我画一个楼梯平面，它就自己把各层楼梯和剖面都画好了。不对的地方在于默认的不对。我得提供更多的细节区分默认表达。至少得提供较详尽的单线关系才能完整描绘一个楼梯的结构。文字的表达也是很有意义的。结合文字和简单的图形框架，我们可以指令程序自己去完善很多的细节。
对于文本，对于图像，一些专业软件包的基本学习还是必要的。我们需要一些相对完整的认知，这可以少走弯路。当然人工智能是非常强大的，它把极其浩繁的知识壁垒实际上给捅破了。那些人为设置的小九九变得非常惨淡无力。

上面考虑将两个类代码暂时混杂是不对的。应该采取动态继承和扩展。这样，原来的类及其任何使用不必发生改变，新的继承类实际上是动态扩展的新类，不管它怎样使用原来的类都不会影响原来的代码，也不会影响现在的和将来的代码。在这样的考虑下，实际上新的继承和扩展类又递归为老的类，从而可以一直循环下去，解决类的扩展和引用问题。我们有一个标准模式：对每一个类A，在其最后一行代码之后紧跟一个实例a的定义。这是写在共同的脚本中，目的是为后续的代码引用A的全部方法。

# 原始类定义和实例化

class A:
    def __init__(self):
        pass

    def method_a1(self):
        print("Method A1 called")

    def method_a2(self):
        print("Method A2 called")

a = A()  # 创建A类的实例

class B:
    def __init__(self):
        pass

    def method_b1(self):
        print("Method B1 called")
    
    def method_b2(self):
        print("Method B2 called")

b = B()  # 创建B类的实例

# 扩展类定义和实例化

class A_e(A):
    def __init__(self):
        super().__init__()

    def method_a3(self):
        print("Method A3 called")
    
    def call_b_method(self):
        print("Calling method_b1 from A_e")
        b.method_b1()

ae = A_e()  # 创建A_e类的实例

class B_e(B):
    def __init__(self):
        super().__init__()

    def method_b3(self):
        print("Method B3 called")
    
    def call_a_method(self):
        print("Calling method_a1 from B_e")
        a.method_a1()

be = B_e()  # 创建B_e类的实例

# 控制代码

if __name__ == "__main__":
    # 调用A_e类的方法
    ae.method_a1()
    ae.method_a2()
    ae.method_a3()
    ae.call_b_method()
    
    # 调用B_e类的方法
    be.method_b1()
    be.method_b2()
    be.method_b3()
    be.call_a_method()

这样，在某种意义上，我们其实认为A，B类和它各自的扩展A_e,B_e仍然是A类和B类，只是版本不同而已。我们不能去更改A，B的名字为A_e,B_e，否则就意味着完全的大范围重整修改，并影响到外部引用。

实际上，对于脚本《英语学习控制文件11.py》，我设计了另一个类脚本和非脚本的控制文件《编程和应用控制-英语.py》，这是非常方便和重要的。一般来说，可以按日期标记每天使用到的一些命令，按项目存放一些重要的数据和代码。它可以很容易将代码和数据复制到正式脚本中，但不需要按程序的严格规矩。可以在里面记录各种重要测试经验，用到的函数名。这样，下次使用，就可以直接查阅，而不用满脚本去搜索。而每次每天用到的重要函数名都聚集在这里了。最重要的是，我们可以这里记录某个工作目标的控制流程。第一步，生成什么。第二步，找到什么。第三步，实现什么，直到最后一步，完成任务。把这个控制流程整理好，它的有序，意义胜过脚本本身。实际上，当脚本很大时，我们都是使用搜索找到函数位置进行调整修改或复制引用，并不很关心它的位置乱不乱。反倒是这个“类脚本却非脚本”的过渡文件非常省心有用。只要在这里找到一些工作目标的相应函数，直接复制就可以在交互面板上修改一下使用了。

当正式脚本在运行时，我们需要复制它的副本来继续运行做点别的什么事。这是副本的最基本逻辑。也是在与人工智能的交互中，学会了动态变量法。将大量数据定义为列表，使用python命令写入 py格式的文件。然后就可以直接调用这些数据了。至少在我研究《5500英语单词》这样的案例中，跑2天2夜才能用完的数据，就简单地存在与脚本一起的目录里就可以了。它的文件加起来只有约3.5MB。也许我们该考虑数据库技术了，如果我们要将几百本规范进行处理的话。至少按照这个类比，在本地提供几百兆空间就能存天量的数据。

常见的本地数据库：

1. SQLite：轻量级的嵌入式数据库，非常适合单用户应用和小型应用。
2. Microsoft Access：适合小型个人或团队项目的本地数据库。
3. Local MySQL/MariaDB：在本地安装和运行MySQL或MariaDB，可以作为本地开发和测试环境。
4. PostgreSQL：本地安装和使用PostgreSQL，非常适合需要高级功能和扩展性的场景。