当前时间: 2026-04-15 22:05:01
分类:办公文件
评论(0)
AI编程与组件化开发平台——天作之合导语
本想写再探cc(claude code)之生成Java代码的文章的。但是内容没啥新意,简要带过吧。本文重点谈一谈我对AI编程与组件化低代码平台之间的关系判断——简直就是天作之合!与昨天初探类似的玩法,这次我还是文本驱动,让CC写个Socket监听,实现如下逻辑:1.监听程序以service形态存在,可配置在svc.xml中,伴随启动自动加载;2.client请求上来后,监听程序收取请求内容,按照json格式解析请求字段放入context中4.从context中提取业务逻辑执行后的json返回数据,返回给client端直接说结果:按照要求成功生成,一次编译通过,运行成功。总体来说代码规范与我的书写习惯几乎一毛一样,备注也很相近,javadoc完整,变量命名规则很合我的胃口,甚至连那种偶尔的复杂英文单词记不住时使用拼音首字母命名变量的陋习都学过去了(拜托,学点好的不行吗
?)。乍一看,很满意。但是吧。。。逐行代码仔细推敲后发现了地雷
。PrintWriter只调用了flush,未调用close。这个坑很隐蔽的,代码可以运行,逻辑可以跑通,测试可以通过。但是这个服务是按照高并发短连接模式设计的,如果不手动close writer的话很容易造成内存泄漏的。一旦请求频度高起来,这就是不定时炸弹啊,而且测试环境压力不足基本上不可能发现,一旦生产环境产系统内存溢出后,想查明原因简直就是大海捞针一样。想想都后怕。3.业务逻辑的实现可读性高,且只要实现了即符合规范此部分内容自己尝试略有所得,但毕竟玩的时间尚短,更多参考了网上众多码友的体验。班门弄斧抄过来,行家勿怪,如有不妥,评论区一定要指出来,谢谢!1.AI编程在架构方面能力略逊,细节代码实现方面较好,但不完美;2.各种模型和AI辅助开发工具普遍存在开发前端界面能力较好,但生成后台程序代码存在隐患的情况;4.大型项目总控能力不足,超长上下文处理方面顾头不顾尾;5.AI写的代码还是需要人逐行细细审核的,一般情况下,AI要么不埋雷,一旦埋雷都会很深,不易被发觉。1.AI擅长利用存量模块进行组装,与组件化开发理念相合 想一想为什么AI做前端更稳?目前主流的前端框架基本上都是组件化的,前端展示逻辑的实现本质上是搭积木的行为,所见即所得。所以说AI利用现有知识组合解决问题的能力是靠谱的,这是AI编程的强项。这与组件化开发平台的初衷也是相符的。2.组件功能单一,逻辑内敛,上下文长度要求不高,是AI的长项 组件是可以复用的。就算是出现了新的应用场景片段,超出了现有组件的功能覆盖范围,需要实现新的组件支撑,那么新组建也必须按照可复用的原则进行抽象、设计、实现。 每个组件的功能都是内聚的,单一的。所以实现组件的过程完美的绕开了AI编程的弱点,充分发挥其优势。组件的设计最好还是由人类完成,精雕细琢后几乎到达伪码层次的提示词,再交由AI实现,基本上跑偏的概率就很低了。 新增组件一定必须是“非常态”的,所以不会频发,工程师可以投入更多的精力聚焦审核AI成果,充分细致检查并验证后再发布。可以说是一劳永逸的工作,细致一点不为过。3.一定程度上减少AI挖坑的可能,就算有坑,也比较明显,不会太深 绝大多数功能的实现可以使用现有组件直接组装完成。成品是前端交互界面与业务逻辑实现部分,AI没有机会在代码层面挖坑,它制造的偏差要么是在前端交互界面层,要么就是业务逻辑描述层。 前端交互层所见即所得,有坑很容易被测试验收过程发现; 好的组件化平台,业务逻辑描述层的可读性一般都是比较高的,复核工程师不必关注代码问题,聚焦业务逻辑,容易发现问题并解决问题。4.后期维护成本低,修改优化更容易,AI在维护优化过程中仍可发挥巨大作用 屎山代码?不存在的,那些组件基本上是被充分论证过的,不必怀疑其可用性和稳定性。后期维护过程中依旧可以聚焦业务逻辑进行升级改造调整,而不动代码。 由AI分析现有业务逻辑描述文件,并结合需求调整,比要求AI修改代码的风险要低很多,同第三点说法,修改后的内容复核、测试均较为简单。以CC为例,在项目描述文件claud.md中,除了cc自动分析框架生成的规范外,还需要增加一些重要的原则,例如:3.如需创建组件,必须说明必要性,并提供完整的设计,必须提示开发者,在确认后方可进行4.版本管理过程中如发现组件存在差异,务必要求工程师介入并确认。5.其实上述几点要求可以用更简单的方式实现,将所有存量组件打成jar包,附上源码。AI开发平台可以学习但是无法修改,新建的组件在源码区特别的突兀,很容易被发现。
基本
文件
流程
错误
SQL
调试
- 请求信息 : 2026-04-16 01:44:43 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/533192.html
- 运行时间 : 0.151931s [ 吞吐率:6.58req/s ] 内存消耗:4,669.63kb 文件加载:145
- 缓存信息 : 0 reads,0 writes
- 会话信息 : SESSION_ID=d519f79224a8404ce57bed7134d7eb8b
- CONNECT:[ UseTime:0.000629s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
- SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.001019s ]
- SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000339s ]
- SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000291s ]
- SHOW FULL COLUMNS FROM `set` [ RunTime:0.000617s ]
- SELECT * FROM `set` [ RunTime:0.000250s ]
- SHOW FULL COLUMNS FROM `article` [ RunTime:0.000709s ]
- SELECT * FROM `article` WHERE `id` = 533192 LIMIT 1 [ RunTime:0.000505s ]
- UPDATE `article` SET `lasttime` = 1776275084 WHERE `id` = 533192 [ RunTime:0.014744s ]
- SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.001933s ]
- SELECT * FROM `article` WHERE `id` < 533192 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000676s ]
- SELECT * FROM `article` WHERE `id` > 533192 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.004305s ]
- SELECT * FROM `article` WHERE `id` < 533192 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.004347s ]
- SELECT * FROM `article` WHERE `id` < 533192 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.020912s ]
- SELECT * FROM `article` WHERE `id` < 533192 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.004916s ]
0.155987s