UnitMesh架构释放AI编程的全部潜力，程序员将成为代码

　　UnitMesh是一种基于人工智能生成的分布式架构，与传统的分布式架构不同，UnitMesh中的服务单元（Unit）是由AI生成的，应用程序中的服务和数据抽象为一个个独立的单元，并通过统一的控制平面进行管理和部署。
　　在上一篇文章《未来可期的AI编程：到底是程序员的终极解放还是失业的开始？》里，我们介绍了人类食用AI编程的考虑要素质。在这一篇文章里，我们将继续探索AI编程的可能性一种AI编程下的可能性：UnitMesh架构，大抵也是现阶段比较可行的方式。
　　PS：之所以叫UnitMesh，是因为我们写了一个底层服务叫UnitServer，还有参考了ServiceMesh和DataMesh架构理念，所以AI取建议我们叫UnitMesh。
　　UnitMeshElementsTLDR版本
　　我们初步定义的这个版本（0。1，称之为UnitGenius）的核心三个特性：语言与框架的DSL（领域特定语言）抽象：抽象非的编程语言和框架特性，以简化出错的可能性。REPL即服务：运行AI生成的代码，并提供对应的API服务。AI设计的适应性结构：自我适应的API服务架构，以在不同的环境下自动调整和优化。
　　开发者可以通过与AI交互，生成一定程度的DSL抽象化代码，然后在REPL即Serverless服务上运行和测试这些代码。开发者还可以将这些代码提交给AI进行自动化运维，AI会对代码进行优化和调整，从而进一步提高API服务的性能和可靠性。
　　开始正文的废话版本。UnitMesh初步Demo：DSLREPLUnitServer
　　详细过程，见本文的后半部分。
　　前端页面：https：prompt。phodal。comzhCNclickflowunitmeshunitserver
　　首先，你需要克隆一下，UnitServer的代码：https：github。compromptengineeringunitserver，然后，选择kotlinrepl或者typescriptrepl对应Kotlin、TypeScript两种语言。
　　然后，按对应的README运行起你的UnitServer。
　　接着，在ChatFlow里让ChatGPT生成如下的代码，并点击Run按钮：springRestControllerobjectPages｛GetMapping（）funmain（）Itworks！｝
　　最后，你就可以得到一个正在运行的服务（该功能还在开发中）：http：localhost：8080，访问该服务后，如果的应该是Itworks。
　　PS：这里有一个手动加入调用Application类和调用main方法的代码，因为需要做静态分析，才能确定使用的框架，暂时没写在UnitServer代码中。UnitMesh架构
　　再重复一下定义：
　　UnitMesh是一种基于人工智能生成的分布式架构，与传统的分布式架构不同，UnitMesh中的服务单元（Unit）是由AI生成的，应用程序中的服务和数据抽象为一个个独立的单元，并通过统一的控制平面进行管理和部署。UnitMesh核心思想：AI生成的代码即Unit
　　UnitMesh是围绕于Unit为核心的架构模式。AI生成Unit。即AI应该生成的代码都应该是可运行的Unit，上到React组件、下到后端服务都是可运行的。校验Unit。由人类来检查和校验Unit，如果AI生成的代码有问题，那么人类只需要修复即可。Unit自适应部署架构。在部署时，Unit可以组成Serverless架构、微服务架构、单体架构、Mesh架构，而不需要人类来干预。
　　碳基嘛，就适合当一个Verifier。UnitMesh架构核心要素
　　结合我们设计的UnitServer，我们设计的UnitMesh架构由以下三要素构成。语言与框架的DSL抽象：封装不稳定的抽象
　　由于AI生成的代码会有各种问题，诸如于无法对接内部的云平台、出错的imports等等，所以我们要设计领域特定语言来解决这个问题，并封装抽象。
　　简单来说：我们需要抽象将所有不稳定的元素，便能构建出稳定的元素。
　　详细的设计会在后面的UnitServer部分展开。
　　PS：而由于大语言模型是有上下文能力限制的，像我这样的、搞不到充值的就只配4k。因此，我设计的Unit要称之为4kUnitMesh，我设计的DSL要称之为4kUnitDSL，有的人可能就是99kDSL。REPL即服务：AI代码修复师的日常
　　在有了DSL之后，我们还需要一个REPL（ReadEvalPrintLoop）服务，能直接运行起AI生成的Unit，然后让人类来测试生成的代码是否是正确。如果生成的AI有错误，就需要AI代码修复师来对代码进行修复。
　　而对于一个服务来，如果我们是一个API，就需要是Serverless服务，这就是为什么我们在图里称之为：REPL即Serverless服务。详细可以参见后面设计的UnitServer。AI设计的适应性结构
　　人类设计系统的一个缺点是，如果设计时、开发时、运行时的单元不一样，那么就会出现各种疑虑。于是，我们会偏向于设计成三态一致的架构模式，而这本身对于架构的适应性优化就是个问题。
　　而既然，代码都是Unit。那么，设计时可以是微服务，开发时可以是Serverless，线上可以是单体。正如Google的ServiceWaver所做的事情，我们不决定运行时的架构，让你来选择。
　　所以，AI怎么运行我们的Unit，就让AI来决定吧。
　　AdaptiveArchitecture
　　PS：本来吧，标题应该是适应性架构（AdaptiveArchitecture），但是我想了想就只是代码结构之类的，又重新考虑了一下。UnitMesh设计心得：反直觉才是出路
　　在去年年底，研究低延迟架构之时，便被这个领域的各种反直觉架构模式所震撼，诸如于：GC是问题那就不要GC。
　　因此当设计UnitMesh时，我们的问题依旧是：如何Openyourmind。即抛开现有的思维模式和固有知识，打破常规思考，所以我们的主要挑战是如何拓展思维，开放心智。要点1：如果分层架构是瓶颈，那么就不要分层架构
　　在那篇《未来可期的AI编程里》分层架构是我们最大的挑战，于是，提出理想的方式就是ServerlessFaaS的方式，而这种方式则是基于现有的械，又过于理想化。
　　而随着我们写了UnitServer之后，我们发现，还可以ClassasaService的方式嘛（手动狗头）。
　　既然我们的代码运行在云端，由AI生成的，那么人类还要看代码吗？人类要在什么时候看代码？无非就是检入的时候，还有审查架构的时候，所以只需要在审查的时候，生成架构不就行了。
　　示例：我想分析xx服务的调用情况，以及对应的代码，请帮我调取出来。要点2：如果依赖是问题，那么就不要依赖
　　我们遇到的第二个挑战是依赖问题，而依赖是两个问题：项目的库依赖。即类似于Gradle、Maven、NPM这一层的库依赖代码依赖。即代码源文件的import
　　复读机ChatGPT并不能很好解决问题，所以就要让GPT忘记这些。理想的编程体验，应该是我要用Spring，智能就会自动分析依赖，如IntelijIDEA。所以，我们在UnitServer中采用了spring样的Jupytermagic语法，以自动解决这两类问题。要点3：如果Serverless部署是问题，那么就不用Serverless部署
　　起初在UnitServer里，我们把UnitServer设计成了一个类Serverless架构，所以我们遇到了一个问题：Serverless架构的成本并非所有的人能接受的。所以，我们只需要在测试Unit时，采用Serverless作为开发时，在线上合并成一个单体或者微服务架构，那么就能完美解决这个问题。
　　而在这时，还需要突破刚才的分层架构，既然每次代码是生成的，那么我们只需要一个包名即可，诸如于：org。clickprompt。unitmesh，所有的代码都在这个包下；又或者，我们可以通过业务进一步划分成不同的包，结合工具来对代码进行归类。UnitMesh探索之路：从REPL到UnitServer
　　上面讲的太理论了，来看看我们的探索之路，一共分为四步：从最小的Hello，world开始优化构建一个REPL环境抽象、简化设计重复。接入真实世界的Prompt。
　　详细可以查看UnitServer和ChatFlow的提交纪录。从最小的Hello，world开始
　　首先，让我们看一个KotlinScript编写的Spring的Hello，World：file：DependsOn（org。springframework。boot：springbootstarterweb：2。7。9）import。。。importjava。util。ControllerclassHelloController｛GetMapping（hello）funhelloKotlin（）：String｛returnhelloworld｝｝SpringBootApplicationopenclassReplApplicationfunmain（args：ArrayString）｛。。。｝main（arrayOf（server。port8083））
　　在这个示例里，你会发现一系列的无用代码，依赖信息、import信息、main函数。而作为一个4kUnitMesh的创作者，我必须把这些不稳定的无用信息去掉，才能正确运行，所以它变成了：usespringControllerclassHelloController｛GetMapping（hello）funhelloKotlin（）：String｛returnhelloworld｝｝
　　这样一来，我只需要让ChatGPT返回Controller即可。构建REPL环境：WebSocketmagic
　　既然，我们已经有了一个简化的DSL，接下来就是引入KotlinScript来构建一个UnitServerless服务器，也就是我们的：https：github。compromptengineeringunitserver。
　　UnitServer的源码是基于KotlinJupyterAPI所构建的，而KotlinJupyter则是封装了Kotlin的REPL环境。我们之所谓基于KotlinJupyter而不是KotlinREPL的主要原因是，可以使用magic和DSL来抽象细节，诸如于：springtoJson。encodeToString（SimpleLibraryDefinition（importslistOf（org。springframework。boot。，org。springframework。boot。autoconfigure。，org。springframework。web。bind。annotation。，org。springframework。context。annotation。ComponentScan，org。springframework。context。annotation。Configuration），dependencieslistOf（org。springframework。boot：springbootstarterweb：2。7。9）））
　　即可以自动添加Spring的依赖和Import信息，就可以支持步骤的Hello，World方式。除了Spring，我们还需要其它的库的magic。
　　最后，再使用WebSocket暴露出这个接口，以提供给ChatFlow使用。抽象、简化设计循环
　　当然了，只是有一个hello，world是不够的，所以我们需要更多的例子，诸如于接入数据库。而由于Spring的扫描机制影响，外加我们并不想（主要是不会）针对Spring做太多的特化，所以我们换成了Kotlin里Kotr框架。
　　PS：值得注意的是，我们还需要对框架进行抽象，但是Ktor对我们预期的好一点。所以，我们的第二个版本来了：usekotlessuseexposeddataclassUser（valid：Int，valusername：String）classServer：KotlessAWS（）｛overridefunprepare（app：Application）｛Database。connect（jdbc：h2：mem：test，driverorg。h2。Driver）transaction｛SchemaUtils。create（Users）｝app。routing｛post（register）｛valusercall。receiveUser（）validtransaction｛InsertthenewuserintothedatabaseUsers。insert｛it〔username〕user。username｝getUsers。id｝valnewUserUser（id，user。username）call。respond（newUser）｝｝｝｝objectUsers：org。jetbrains。exposed。sql。Table（users）｛validinteger（id）。autoIncrement（）valusernamevarchar（username，50）。uniqueIndex（）overridevalprimaryKeyPrimaryKey（id，namePKUserID）｝
　　在这个版本里，我们使用了Exposed作为数据库的ORM，使用H2作为数据库。当然，要拿这个代码作为Unit还差了10的距离，不过，基本上已经可以解决大部分的CRUD场景。
　　PS1：这里的KotlessAWS只是一个AWSServerless的抽象，并不影响我们的操作，我们可以直接封装一个UnitMesh的类，就是懒。
　　PS2：我们只需要通过静态分析拿出routing中的代码，再优化即可。更多的探索过程代码可以见：samples。一个真实世界的Prompt
　　现在，让我们来结合AI跑一下：请帮我使用KtorKotlinExposed实现一个用户注册的RESTfulAPI，要求如下：涉及到数据库的地方，请直接使用Database。connect。只返回核心逻辑，并写在Server类里，我要部署在Serverless服务器里。请使用KotlinDSL的方式编写代码。不返回其它的无关代码，如：注释、依赖、import等。最后，你只返回类的代码，返回格式如下：classServer：KotlessAWS（）｛overridefunprepare（app：Application）｛Database。connect（jdbc：h2：mem：test，driverorg。h2。Driver，userroot，password）transaction｛SchemaUtils。create（Users）｝app。routing｛｛｛｛｝｝｝｝｝｝
　　人生苦短，欢迎加入我们的Watchlist，一起讨论未来。JoinWaitlist
　　狗头，现在Waitlist工程师们，你可以就加入UnitMesh的Watchlist：
　　https：github。compromptengineeringunitmesh