标签 AI辅助开发 下的文章

一、什么是低代码(low-code)?为什么需要低代码?

(一)信息化难题

企业在信息化转型过程中常面临诸多困境:传统软件开发周期长(通常3-6个月),无法快速响应业务变化;专业开发人才稀缺且成本高昂,中小企业难以承担;各部门系统孤立形成数据孤岛,集成难度大;业务人员需求与技术开发脱节,落地效果不佳;简单部门级应用需排队等待IT团队开发,效率低下。

(二)低代码(low-code)介绍

为破解上述难题,低代码应运而生。低代码是一种可视化应用开发方法,通过图形化界面、拖拽组件和模型驱动逻辑,以最少手工编码快速构建应用程序,本质是一组数字技术工具集合。它能降低开发门槛,实现业务与技术协同,将应用交付周期缩短至2-4周,助力企业快速完成信息化落地,适配各类业务场景与复杂系统搭建需求。

(三)低代码与传统开发对比

相较于传统开发,低代码优势显著:开发效率提升500%以上,无需从0到1编写全部代码;成本降低60%以上,大幅减少专业开发人才依赖;上手门槛低,业务人员可参与搭建,无需深厚编码基础;迭代灵活,可快速响应业务调整,无需大规模重构系统;集成便捷,能快速对接企业现有ERP、CRM等系统,打破数据孤岛。

(四)低代码的衍生概念

1、无代码:低代码的简化形态,完全无需编写代码,纯通过拖拽组件、配置参数即可完成应用搭建,门槛更低,适合非技术人员(业务人员)快速搭建简单表单、审批类应用,如伙伴云、简道云等平台侧重此类模式,但灵活性略低于低代码。

2、aPaaS(应用平台即服务):低代码是aPaaS的核心形态,aPaaS更侧重提供完整的云端应用开发、部署、运维一站式平台,除低代码可视化开发能力外,还包含服务器、数据库、安全防护等基础服务,如Zoho Creator、明道云均属于aPaaS范畴,支撑企业全流程应用开发与落地。

二、国内主流低代码平台十大能力测评对比

(以下内容来自作者的深度测评)

(一)织信Informat

1、平台介绍

织信是深圳基石协作科技有限公司自研的企业级AI低代码平台,团队主创由曾主导平安、微众、腾讯、华润、华为等知名企业信息化项目的核心团队组建,从专注企业数字化转型解决方案起步,逐步打磨成兼具灵活性与实用性的企业级低代码开发平台。

深耕低代码行业十余年,见证了从早期简单表单工具到如今企业级全流程解决方案的迭代,今天要测评的织信低代码,是由基石协作于2019年推出的核心产品,其核心团队成员均具备丰富的大型企业数字化系统研发经验,凭借多年行业实践沉淀,逐步升级为可提供“数据+流程+AI”全场景能力的企业级低代码平台,为各行业企业提供一站式数字化转型解决方案,助力企业快速实现国产化、自主可控的信息化部署,兼顾效率与安全,适配从中小规模到大型企事业单位的多样化需求。

2、核心能力

▐ 基础能力

织信低代码的主要功能模块围绕数据引擎、流程引擎、权限引擎三大核心展开,搭配仪表盘、AI辅助开发、拓展功能等模块,以“高效搭建、灵活拓展”为核心,兼顾易用性与企业级需求,覆盖从基础表单到复杂系统的全场景搭建。

▐ 数据引擎

作为织信低代码的核心基础,数据引擎的实用性堪称行业上游水平,其展现方式贴合企业日常操作习惯,支持多达5个大类、35种字段组件(可自定义组件),拖拽即可生成对应表单,无需复杂操作。用户可根据业务场景,为表单设置缜密的逻辑规则,实现字段联动、实时更新,有效打破数据孤岛。

此外,数据引擎还支持80+种高级函数,覆盖运算、日期、字符串等各类业务场景,满足复杂数据处理需求。数据录入支持Excel导入、在线编辑等多种方式,同时可通过链接分享实现内外协作,权限控制细致,保障数据安全。

▐ 流程引擎

织信低代码的流程引擎适配性极强,完全不输专业流程管理工具,采用可视化拖拽+连线操作,无需代码即可设计完整业务流程,遵循BPMN2.0规范,支持自由流程、固定流程、分支流程、并行流程等多种模式,可满足企业所有业务流程需求。

流程审批功能全面,支持审批、退审、加签、撤回、手写签名等操作,处理人可根据实际情况灵活应对;同时支持待办工作流设置,可配置触发条件、负责人及状态,实现流程智能流转,大幅减少人工干预。

▐ 权限引擎与仪表盘

权限引擎提供团队、应用、数据三级权限管控,可灵活配置不同人员的数据查看、操作权限,搭配数据智能预警功能,当数据出现异常时,可第一时间向负责人推送消息,保障数据安全与业务合规。

仪表盘模块支持创建各类统计卡片,提供丰富的可视化报表功能,可多维度展示数据、实现数据对比,同时支持电脑端、移动端多端查看,让移动办公更便捷,帮助企业实现数据全面掌控。

▐ 低代码+AI

织信低代码的核心特色的是AI与低代码的深度融合,区别于普通低代码平台的基础搭建能力,其提供AI自动建模、AI辅助开发、AI组件开发三大核心能力,用户输入简单指令即可快速构建数据表业务模型,30s可实现从需求到成品页面的快速生成,大幅提升开发效率。同时支持API接口、脚本、拓展包等多种拓展方式,可集成第三方服务,满足企业个性化定制需求。

3、优势

可扩展性强,适配复杂场景。织信低代码支持代码开发、API接口、拓展包等多种拓展方式,可轻松集成第三方服务,同时支持分布式架构、集群部署,能承载上亿级数据,适配ERP、OA、CRM等复杂管理系统的数字化升级,满足中大型企业的复杂业务需求。

AI赋能,开发效率突出。其AI辅助开发能力大幅降低了开发门槛,无论是技术人员还是非技术人员,都能快速上手搭建应用,同时支持私有化部署,保障企业数据隐私与安全,适配央国企、军工等对合规性要求高的行业。

行业模板丰富,适配性广。平台沉淀了CRM、ERP、HR等多种行业解决方案模板,覆盖制造、金融、医疗、地产等多个领域,减少企业从零搭建的工作量,同时可根据自身需求微调,适配不同行业的个性化需求。

4、不足

深度定制门槛较高 虽然基础搭建无需代码,但进行深层次业务逻辑定制时,仍需要一定的代码知识和技术能力,对无开发背景的团队来说,学习成本较高,可能需要专门安排技术人员支持。

学习资源与社区氛围待提升 相比成熟低代码平台,织信的学习教程、案例分享相对偏少,初次上手的用户可能需要自行摸索,官方客服支持虽到位,但社区答疑、视频教程等资源仍需完善。

5、商业模式及持续生存能力

▐ 商业模式

织信低代码采用订阅制+定制化服务的商业模式,分为面向中小企业的标准版、面向中大型企业的定制版、面向高合规需求企事业单位的旗舰版,不同版本在数据量、功能权限、服务支持上有所差异,同时提供个性化定制服务,适配不同规模企业的预算与需求。

▐ 持续生存能力

织信低代码由具备大厂信息化经验的核心团队操盘,自2019年推出以来,历经多年打磨,已积累4万家企业用户,服务吉利控股、君乐宝乳业、某飞机设计研究院等行业头部客户,凭借扎实的产品能力和广泛的行业适配性,持续生存能力强劲。

6、客户画像

经过多年发展,织信低代码累计服务4万家企业用户,主要客户规模为50人以上的中大型企业,行业覆盖国防军工、央国企、生产制造、金融证券、生物医疗等多个领域,尤其受到对合规性、数据安全、系统稳定性要求高的企业青睐。

7、评测结论

织信低代码综合评分(满分100分,一颗★2分)

易上手度:★★★★

基础能力:★★★★★

数据管理:★★★★★

API能力:★★★★★

低代码能力:★★★★★

性价比:★★★★

模板质量:★★★

样式交互:★★★★★

AI能力:★★★★★

市场口碑:★★★★

整体评分:90分

8、选用建议:

中大型企业有复杂业务系统搭建需求,且对数据安全、合规性、可扩展性要求较高的,可优先选用。

需要AI辅助开发、追求高效搭建,或有私有化部署需求的企事业单位,织信低代码适配度极高。

国防军工、制造、金融等对系统稳定性和数据承载能力有高要求的行业,可重点考虑,其行业解决方案能快速适配业务需求。

(二)宜搭

1、平台介绍

宜搭是由深耕企业数字化领域多年的阿里钉钉团队打造,历经从基础零代码工具到宜搭Plus低代码平台的迭代打磨,逐步升级为一个为企业提供全场景数字化搭建服务的低代码PaaS平台,为企业的办公协同、业务管理、流程审批等场景提供一站式解决方案。

依托阿里集团的技术积淀与生态资源,搭配灵活的代码扩展能力和丰富的插件支持,兼顾易用性与定制化需求,适配从小微企业到中大型企事业单位的多样化数字化转型诉求。

2、基础能力

宜搭的主要功能模块由表单、流程、报表、插件中心与低代码扩展五大核心部分组成,以“生态联动、灵活拓展”为核心,依托钉钉生态优势,实现办公场景与业务场景的深度融合,让低代码搭建更贴合企业实际使用需求。

▐ 表单

进入表单配置页,采用可视化拖拽操作,上手门槛适中,其提供的页面组件超过70个,在同类低代码平台中表现突出,组件规范度与成熟度极高,涵盖基础输入、数据关联、附件上传等各类场景,可满足不同行业的表单搭建需求。配置完成后的效果实时预览,无需反复调试,所见即所得。

表单支持Excel导入、在线编辑等多种数据录入方式,同时可依托钉钉生态实现内部协作共享,权限控制细致,可针对不同人员配置表单查看、编辑、提交等权限,保障数据安全。此外,表单还支持逻辑规则配置,实现字段联动、必填校验等功能,提升数据录入的准确性。

▐ 流程

虽然宜搭早期以零代码工具起步,但流程引擎功能已十分完善,丝毫不逊色于专业流程管理平台。其遵循BPMN2.0规范,采用可视化拖拽+连线的配置方式,无需代码即可设计完整的业务流程,支持固定流程、分支流程、并行流程等多种模式,适配企业审批、业务流转等各类场景。

流程审批功能全面,支持审批、退审、加签、撤回等常用操作,处理人可根据实际业务需求灵活应对;同时支持流程触发条件配置,实现数据提交后自动触发审批流程,大幅减少人工干预,提升流程处理效率。

▐ 报表

宜搭的报表模块与表单、流程数据深度联动,支持多数据源聚合分析,可将多张表单数据进行统计、筛选、合并、运算等操作,生成各类可视化报表。提供多种图表类型,支持多维度数据展示、对比分析,可根据企业需求自定义报表样式,帮助企业快速掌握业务数据情况。

报表支持实时更新,数据变化后无需手动刷新即可同步展示,同时可嵌入钉钉工作台,方便员工随时查看,实现数据驱动决策。

▐ 低代码+插件中心

宜搭在各个功能层次均预留了代码扩展槽,将定制能力大量开放给用户,专业开发者可通过代码对表单、流程、报表、页面等能力进行扩展,满足企业深层次的个性化定制需求,在数据逻辑定制上几乎无限制。

其插件中心是核心特色之一,可便捷接入各类扩展能力,目前已支持发票识别、身份证识别、公章识别等插件,用户通过可视化配置即可快速接入,无需额外开发,进一步提升搭建效率(目前部分插件仍在内测阶段)。

3、优势

组件丰富,拓展性强 宜搭拥有70+成熟组件,覆盖各类业务场景,同时预留充足的代码扩展槽,专业开发者可灵活定制,搭配插件中心的拓展能力,既能满足基础搭建需求,也能应对复杂业务场景的定制化诉求。

钉钉生态联动优势 依托阿里钉钉生态,宜搭可与钉钉办公场景深度融合,实现应用嵌入钉钉工作台、钉钉消息推送等功能,无需额外下载APP,企业员工可直接通过钉钉使用搭建的应用,大幅降低推广与使用成本。

大厂背书,稳定性强 由阿里钉钉团队操盘,依托阿里集团的技术积淀,平台稳定性与安全性有保障,同时产品迭代速度快,持续优化功能体验,能及时响应企业数字化转型的新需求。

4、不足

对新手不够友好。产品设计偏技术导向,配置过程中会出现较多开发语言相关内容,有开发经验的用户接受度较高,但非技术背景的业务人员想要快速搭建趁手的应用,学习成本较高,必须有IT人员协助。

应用模板质量欠佳。目前宜搭的应用模板数量较少,且大多只是基础框架,内容相对简单,安装后需要进行大量配置才能正常使用,缺少成熟复杂的行业模板,无法有效减少用户从零搭建的工作量。

5、商业模式及持续生存能力

▐ 商业模式

宜搭目前有四个付费版本,面向小微企业的普惠版(50个账号免费);面向中小企业的标准版(58元/账号/年);满足中大型企业定制需求的企业版(98元/账号/年);全定制化能力开放的尊享版(168元/账号/年)。不同版本对数据集数量、附件容量及自定义功能做了明确限制,其商业模式带有阿里一贯风格,现阶段重点聚集合作伙伴、引流阿里云,收费并非主要诉求。

▐ 持续生存能力

宜搭倚靠阿里集团的优越资源,推出后快速迭代,从零代码工具升级为低代码平台宜搭Plus,短短时间内已服务上千家企业,聚集数百家生态开发者,产品生态逐步成熟。依托阿里的技术与资金支持,产品创新能力与持续生存能力极强,未来仍将持续拓展功能边界。

6、客户画像

经过多年发展,宜搭已积累大量企业用户,客户规模覆盖小微企业到中大型企业,行业涉及面较广,尤其受到依托钉钉办公的企业青睐,其中小微企业与中小企业占比最高,多用于轻量级办公审批、简单业务管理等场景。

7、评测结论

宜搭综合评分(满分100分,一颗★2分)

易上手度:★★★★

基础能力:★★★★★

数据管理:★★★★★

API能力:★★★★

低代码能力:★★★★

性价比:★★★★

模板质量:★★★★

样式交互:★★★★

AI能力:★★★★

市场口碑:★★★

整体评分:82分

8、选用建议:

依托钉钉办公、需要实现办公与业务场景深度融合的企业,可优先选用宜搭,生态联动优势突出。

有专业IT人员支持、既需要基础搭建功能,又有深层次定制化需求的企业,宜搭的扩展能力可充分满足诉求。

中大型企业有复杂业务系统搭建需求,且注重平台稳定性与安全性,同时希望依托大厂技术保障的,可重点考虑。

(三)微搭

1、平台介绍

微搭,是由深耕云计算与企业数字化领域的腾讯云核心团队打造,历经从微信生态专属开发工具到全场景低代码平台的迭代打磨,逐步升级为一个聚焦“生态连接+高效开发”的企业级低代码PaaS平台,为企业的小程序开发、内部管理、客户运营等场景提供一站式解决方案。

依托腾讯集团的技术积淀、微信生态资源及云原生能力,搭配AI辅助开发与灵活的代码扩展能力,兼顾易用性与企业级需求,适配从小微企业到中大型企事业单位的多样化数字化转型诉求,尤其在C端应用搭建上具备天然优势。

2、基础能力

微搭的主要功能模块由表单、流程、报表、低代码IDE与生态联动五大核心部分组成,以“微信生态深度适配、多端协同开发”为核心,依托腾讯云技术底座,实现小程序、H5、Web端一次开发、多端部署,让低代码搭建更贴合企业C端运营与内部管理需求。

▐ 表单

进入表单配置页,采用可视化拖拽操作,上手门槛较低,其提供了丰富的UI组件,涵盖基础输入、数据关联、附件上传、身份识别等各类场景,可满足不同行业的表单搭建需求。配置过程实时预览,所见即所得,无需反复调试,大幅提升搭建效率。

表单支持Excel导入、在线编辑等多种数据录入方式,同时可轻松连接腾讯云数据库、腾讯文档等数据源,无需强制迁移数据,灵活适配企业现有数据体系。权限控制遵循RBAC权限体系,可针对不同人员配置表单查看、编辑、提交等权限,搭配SSO单点登录能力,保障数据安全与企业级协同需求。

▐ 流程

微搭的流程引擎兼顾基础审批与简易业务流转需求,采用可视化拖拽+连线的配置方式,无需代码即可设计完整流程,支持固定流程、分支流程等基础模式,适配企业内部审批、业务上报等轻量级流程场景。

流程审批功能简洁实用,支持审批、退审、加签等常用操作,可与企业微信深度联动,审批消息实时推送至企业微信,方便员工及时处理;同时支持流程触发条件配置,实现数据提交后自动触发审批,减少人工干预,提升流程处理效率。但相较于老牌BPM厂商,其复杂流程处理能力略有不足。

▐ 报表

微搭的报表模块与表单、数据源深度联动,支持多数据源聚合分析,可将多张表单数据进行统计、筛选、运算等操作,生成曲线、饼图、表格等多种可视化报表。报表支持实时更新,数据变化后无需手动刷新即可同步展示,帮助企业快速掌握业务数据情况。

此外,微搭新增用户数据分析能力,可直接查看小程序新增用户、活跃用户等数据,支持自定义查看方式,为企业C端运营提供数据支撑。

▐ 低代码+生态联动

微搭的核心特色是微信生态深度集成与多端开发能力,支持小程序、H5、Web多端开发,一次开发即可多端部署,小程序注册、开发、预览、发布全流程一步到位,1个人7天即可完成小程序和管理系统的定制开发与上线。

其提供低代码IDE,支持自定义组件和代码扩展,专业开发者可通过代码进行深度定制;同时内置AI生成能力,支持AI生成应用、组件、代码等,大幅提升开发效率。此外,微搭支持公有云与私有化部署,可一键将应用部署至自有服务器,保障数据主权。

3、优势

微信生态优势突出 与微信小程序、企业微信原生集成,调用流程免签名、免权限配置,小程序开发效率极高,是需要快速搭建小程序、H5营销页的企业首选,能最大化发挥微信生态的协同价值。

云原生与AI赋能 深度集成腾讯云Serverless等能力,实现弹性伸缩,服务器搭建、网络安全等无需企业自行处理;AI辅助开发能力覆盖全开发流程,大幅提升开发效能,人效产值可提升60%-150%。

大厂背书,部署灵活 依托腾讯云技术积淀,平台稳定性与安全性有保障;支持公有云与私有化部署,适配不同企业的数据安全需求,同时服务上海浦东国际机场、河南圆方物业等各行业客户,落地案例丰富。

4、不足

传统To B能力薄弱 在传统To B管理软件领域,生态和模板丰富度暂不如宜搭等平台,复杂业务流程处理能力相较于老牌厂商略有不足,难以适配大型企业复杂的业务管理场景。

模板实用性不足 虽提供多场景模板,但多为基础框架,行业针对性不强,安装后需要进行大量配置才能正常使用,无法有效减少用户从零搭建的工作量,尤其缺乏复杂行业解决方案模板。

5、商业模式及持续生存能力

▐ 商业模式

微搭目前有多个付费版本,所有用户均可享有体验版无限期试用资格,但发布应用有时效限制;面向初创团队、专注小程序开发的团队版(88元/月起);面向中大型企业的企业版(10800元/年),不同版本在资源配额、功能权限上有所差异,商业模式侧重生态引流与云服务联动,兼顾自助搭建与企业级定制需求。

▐ 持续生存能力

微搭倚靠腾讯集团的技术与资金支持,迭代速度较快,不断新增AI辅助开发、用户数据分析等能力,产品生态逐步成熟。目前已服务上千家企业,聚集大量生态开发者,同时拥有完善的官方培训、认证体系,助力合作伙伴快速上手,持续生存能力极强。

6、客户画像

经过多年发展,微搭已积累覆盖多行业的企业用户,客户规模从初创团队到中大型企业均有涉及,尤其受到需要快速开发小程序、依托微信生态或企业微信办公的企业青睐。行业覆盖交通、文旅、房地产、农业等,多用于小程序开发、轻量级内部管理系统搭建等场景。

7、评测结论

微搭综合评分(满分100分,一颗★2分)

易上手度:★★★★

基础能力:★★★★

数据管理:★★★★

API能力:★★★★★

低代码能力:★★★★★

性价比:★★★★

模板质量:★★★★

样式交互:★★★★★

AI能力:★★★★

市场口碑:★★★★

整体评分:80分

8、选用建议:

需要快速开发小程序、H5营销页,或依托微信生态、企业微信办公的企业,可优先选用微搭,生态联动优势无可替代。

初创团队、零经验团队,想要快速搭建轻量级应用或小程序,微搭的易用性与AI辅助能力可大幅降低开发门槛。

对数据安全有要求、需要私有化部署,且注重平台稳定性,同时有轻量级业务管理需求的企业,可重点考虑。

声明:本测评仅为笔者经验总结的个人观点,与产品不存在利益相关。相关信息、功能描述均来自于网络公开信息、产品官方渠道及笔者使用体验,若有偏差,可与我们取得联系,我们核实后将进行勘误。

在上一篇《Claude Code × 智谱 BigModel 实战集成指南》中,我们已经完成了一次完整的项目实战。项目可以正常运行,但在后续代码 Review 时,一个问题逐渐暴露出来:

生成的代码虽然能跑,但大量 API 和用法已经过时,与最新官方文档存在明显偏差。

这在 AI 辅助开发中其实非常常见——模型的训练数据更新速度,往往赶不上框架和 SDK 的迭代速度。

正巧这时,一位朋友向我推荐了 Anthropic 最新发布的 Agent Skills,通过 plugins 的方式,让 Claude 在生成代码时 动态读取最新官方文档和工具能力,从而显著降低“写得像,但跑不通”的概率。

本文就是这次探索的完整记录。


一、Agent Skills 是什么?

官方仓库地址:

https://github.com/anthropics/skills

Agent Skills 可以理解为:

一套可插拔的“能力模块”,用于教会 Claude 如何用正确的方法、最新的工具、可重复的流程 来完成特定任务。

在技术层面上:

  • 每个 Skill 本质上是一个文件夹
  • 内部包含:

    • 指令(instructions)
    • 脚本(scripts)
    • 资源文件(resources)
  • Claude Code 会在运行时动态加载这些 Skills

它能解决什么问题?

Agent Skills 的核心价值在于 “降低幻觉 + 提高一致性”,典型应用场景包括:

  • 按公司/团队的编码规范生成代码
  • 按最新官方文档调用 API(而不是靠模型记忆)
  • 执行固定的工程化流程(初始化项目、生成目录结构、部署脚本等)
  • 自动化个人或组织级任务

简单来说:

Skills 不是让模型更聪明,而是让模型更“守规矩”。

二、在 Claude Code 中安装 Agent Skills

在 Claude Code 命令行中执行:

/plugin marketplace add anthropics/skills

安装完成后,你就已经具备了使用官方 Skills 的能力。

这一步相当于为 Claude Code 打开了“官方增强模式”。

PixPin_2026-01-22_10-07-25.png


三、安装 context7 插件(关键步骤)

接下来是本文的重点:context7

1️⃣ 打开插件管理

在 Claude Code 中输入:

/plugins

然后使用键盘 ➡️ 进入 Discover

2️⃣ 搜索并安装 context7

在搜索框中输入 context7,完成安装。

context7 本质上是一个 MCP(Model Context Protocol)插件,
能让 Claude 直接参考并对齐最新的官方文档内容

PixPin_2026-01-22_10-09-22.png


四、使用 context7 生成项目代码

安装完成后,就可以在 Prompt 中显式声明使用 context7

示例 Prompt

---
name: context7
description: 使用 Context7,基于框架最新的官方文档
---

# context7

## 指南
已使用以下技术栈生成企业级项目:
- 使用 Context7,基于最新的官方文档
- FastAPI 0.128.0,带 Token 认证
  - 使用 sqlite 生成 token
  - 不使用 JWT,仅做 Token 校验
- langchain 1.2.6,使用 create_agent
- langchain-ollama 1.0.1
  - model:qwen3-vl:32b
  - embedding:qwen3-embedding:8b
- langgraph 1.0.6
- Milvus(pymilvus)2.6.6
- langfuse 3.12.0

通过这种方式,你是在明确告诉 Claude

不要靠“印象”写代码,而是以当前官方文档为准

PixPin_2026-01-22_10-29-45.png


五、实际体验与问题分析

真实结论只有一句话:

效果明显提升,但依然不能“一次生成直接可用”。

优点

  • API 使用明显更接近最新文档
  • 过时参数、废弃方法显著减少
  • 工程结构更合理,思路更偏向“真实项目”

仍然存在的问题

  • 复杂技术栈组合(LangChain + LangGraph + Milvus + Langfuse)
  • 仍然需要 多轮调试才能完全跑通
  • 某些边界用法依然存在偏差

我的判断

并不是 context7 不行,而是模型生成速度,依然落后于框架演进速度。

context7 做到的是:

  • 让 Claude 看得到 最新文档
  • 但最终“怎么拼起来”,仍然依赖模型本身的推理与代码能力

六、总结

如果你正在使用 Claude Code 做偏工程化、偏企业级的项目开发,我的建议是:

一定要上 Agent Skills

能用 context7 就用 context7

❌ 不要再完全相信“模型记忆里的 API”

但同时也要有一个清醒认知:

AI 辅助开发 = 更快的起点,而不是免调试的终点。

在当前阶段,最理想的模式依然是:

AI 生成 + 人类 Review + 多轮修正

后续我也会继续记录 Claude Code + MCP + 多模型协作 的实践经验,欢迎关注。

哈喽,我是老刘

2025年已成过往。随着iOS、Android、桌面端、Web与各类小程序的持续发展,原生开发的高墙已难以维系,成本与效率的矛盾达到顶峰。

跨平台不再只是备选项,而是个人和团队的必选项。但面对Flutter的全平台一致体验、React Native的新架构性能突破、uni-app x的原生编译能力、KMP的Compose全栈统一,究竟谁才是2026年的最优解?

如何在这个AI重塑代码的时代,把有限的资源发挥出最大的效率?

老刘每个月为大家画出最新的跨平台技术选型地图,帮你快速做决策。

本月,各大框架在“原生体验”与“AI提效”上都有重磅更新。


1. 2025年跨平台技术简单总结

  • 性能仍是核心

2025年,各个框架都在寻找性能的突破点。

Flutter全面普及Impeller引擎,解决了最后一公里的卡顿问题。

uni-app x和KMP则选择了另外一条路,通过编译为原生代码(Native Compilation),直接从物理层面消除了性能鸿沟。

RN则全面切换到新架构来实现性能的突破。

性能上向原生看齐是2025年跨平台技术的一个重要趋势。

  • 平台拼图补全

框架们不再满足于能跑,而是追求各个平台的完美适配。

Flutter在桌面端和Web端(Wasm)持续发力,真正实现六端同源。

KMP推出了Kotlin-to-Swift导出功能,让iOS开发者也能优雅地接入,填补了跨平台在iOS原生生态上的最后一块拼图。

  • AI与框架深度融合

AI不再只是外部辅助,而是开始进入框架内部。

Flutter推出的Dart MCP Server让AI能直接理解项目结构和组件树。

MAUI也在不断完善其AI功能,如Copilot Agent,试图通过AI赋能来改善开发者体验。

应该说我们离描述即应用的时代不远了。

2. 最新技术动态

2.1 React Native 新架构全面启用

React Native 0.83 发布日志: https://reactnative.dev/blog

React Native 0.83 版本随 Expo SDK 55 正式到来。新架构(New Architecture)已成为默认标准,遗留架构代码正在被加速移除。新版本集成了 React 19.2,并在构建时间和应用体积上取得了显著优化。开发者现在可以享受到更接近原生的性能体验,以及更强大的 DevTools 支持。

2.2 Kotlin Multiplatform 生态成熟加速

Kotlin 2.3.20-Beta1 新特性: https://kotlinlang.org/docs/whatsnew-eap.html

Kotlin 2.3.20-Beta1 于本月发布,标志着 KMP 生态的进一步成熟。

Compose Multiplatform for iOS 已经稳定,越来越多的团队开始从原生转向 KMP。

K2 编译器的全面普及以及 JetBrains 在 AI 辅助开发(如 Koog 和 Mellum)上的投入,使得 KMP 的开发效率达到了新高度。

2.3 .NET MAUI 企业级发展

.NET MAUI Roadmap: https://github.com/dotnet/maui/wiki/Roadmap

.NET 11的规划和早期迭代正在进行中。当前重点依然是提升产品质量和性能稳定性。微软正在深度集成 GitHub Copilot 和 Copilot Agent,试图通过 AI 赋能来改善 MAUI 的开发者体验。尽管社区仍有关于稳定性的讨论,但其在企业级市场的地位依然稳固。

2.4 Flutter 平台更新

Flutter 最新动态: https://docs.flutter.dev/release/whats-new

虽然社区对 Flutter 4.0 充满期待,但截止 2026 年 1 月,Flutter 3.38 仍是官方维护的最新稳定版本。目前的更新重点在于 Impeller 渲染引擎 的进一步优化与稳定性提升,该引擎现已在 iOS 和 Android 上默认启用,彻底解决了 shader 编译造成的卡顿问题。此外,Flutter 团队修复了 Android 端 Activity 销毁时的内存泄漏问题,并对 Android 15 的 16KB Page Size 提供了完整支持,继续巩固其在跨平台渲染一致性上的优势。

2.5 uni-app x 进展

uni-app x 更新日志: https://uniapp.dcloud.net.cn/release.html

近期 uni-app x 迎来了一系列重要更新(v4.87)。核心亮点包括:

  • 多线程能力增强
    新增 uni.createWorker API,正式支持 Worker 线程,显著提升复杂计算场景下的性能表现。
  • 鸿蒙生态深度适配
    将逻辑层 JSVM 迁移至独立子线程,彻底解决主线程阻塞问题;新增微信登录、分享及屏幕亮度调节等原生能力。
  • 新设备与系统兼容
    修复 Android 16KB 页大小模式下的录音问题,并提前适配 iPhone 17 系列机型。

2.6 Valdi 进展

Valdi GitHub 仓库: https://github.com/Snapchat/Valdi

本月Valdi框架没有新的进展,最新发布版本仍然是beta-0.0.1

接下来老刘按照跨平台技术框架的三种路线,分别介绍一下目前主流的跨平台技术。


3. 自渲染类框架

简单来说,就是框架自己携带渲染引擎,自己画界面,不用系统提供的组件。

这样做有什么好处?

  • 界面完全一致
    UI渲染不依赖系统组件,多端展示效果完全统一。
  • 性能媲美原生
    跳过系统UI层直接操作GPU绘制,架构与原生一致。
  • 无兼容性Bug
    不调用系统原生组件,规避了因系统差异导致的兼容性问题。

3.1 Flutter

2024年Stack Overflow调查显示,Flutter是最受欢迎的跨平台框架。

全球有超过500万开发者在使用。

连阿里巴巴、腾讯、字节跳动都在使用Flutter。

为什么这么多大厂选择Flutter?

  • 性能强劲
    切换Impeller引擎后,Flutter性能已与原生应用一致。
  • 开发高效
    热重载实现秒级预览,Dart语言在功能性与复杂度间达成完美平衡。
  • 生态成熟
    pub.dev拥有超4万插件,涵盖地图、支付等各类功能,开箱即用。
  • 测试友好
    拥有客户端领域最佳的单元测试支持,是TDD及敏捷团队的最优选择。
  • 拥抱AI

    • AI Toolkit

    集成Gemini API,快速实现聊天、识别等功能。

    • 本地部署

    支持TensorFlow Lite/ONNX,保障隐私安全。

    • Dart MCP Server

    让AI助手直接理解项目,辅助编码与调试。


4. 中间层类框架

简单来说,就是在你的代码和系统原生组件之间,加了一个"翻译官"。

比如你用JavaScript写界面逻辑,框架帮你翻译成原生的Button、TextView。

核心特点:

  • 成熟的开发体验
    复用React/Vue/C#等生态成熟的开发思路,上手快,学习成本低。
  • 原生组件渲染
    最终映射为系统原生组件,UI符合平台规范,质感原生。
  • 桥接性能损耗
    通过中间层与原生通信存在"翻译"开销,交互密集场景性能稍弱,常规界面无感知。

4.1 React Native

React Native是第二受欢迎的跨平台框架,是Facebook开源的项目。

为什么这么多人选择React Native?

核心优势:

  • 零门槛上手
    React开发者可直接复用JSX、组件化及状态管理经验,一周即可转型。
  • 生态庞大
    npm拥有超15万相关包,共享Web生态,导航、支付等库应有尽有。
  • 动态热更新
    支持不发布新版本App直接在线更新,无需发版即可修复Bug或上线新功能,迭代极快。
  • 架构升级
    Meta持续投入,新架构引入Fabric和TurboModules,性能提升30%,旧架构已退役。

4.2 .NET MAUI

2024年5月,微软正式停止了Xamarin的支持,.NET MAUI(Multi-platform App UI)成为微软官方的跨平台解决方案。

核心优势:

  • 企业级保障
    微软提供长期技术支持(LTS),确保企业应用所需的稳定性。
  • 数据处理强
    C#擅长处理复杂业务逻辑,特别适合金融、ERP等数据密集型应用。
  • 生态深度集成
    与Azure、SQL Server等微软全家桶无缝对接,集成体验最佳。

5. 转译类框架

简单来说,就是把你写的高级语言代码,"翻译"成目标平台的原生代码。

比如你用Kotlin写业务逻辑,框架帮你"翻译"成iOS的Swift代码。

或者你用类TypeScript的语法写界面,框架帮你"翻译"成Android的Kotlin和iOS的Swift。

核心特点:

  • 性能接近原生

因为最终运行的就是原生代码,没有任何中间层损耗。

就像你直接用Swift写iOS应用,用Kotlin写Android应用一样。

  • 能享受原生生态

转译后的代码可以直接调用平台的所有API。

  • 转译效果可能不完美

毕竟是机器"翻译"的代码,有时候可能不如手写的原生代码优雅。

特别是复杂的业务逻辑,转译后的代码可能需要人工优化。

但这个问题随着AI技术的发展,正在快速改善。

5.1 Kotlin Multiplatform (KMP)

KMP的核心用法:业务逻辑用KMP共享,UI用Compose Multiplatform统一开发

这是KMP的最新发展方向,结合了Compose Multiplatform的强大能力。

一套Compose代码可以运行在Android、iOS、Desktop、Web等所有平台。

KMP的特点

  • 真正的一套代码多平台

不仅业务逻辑共享,UI也可以共享,开发效率大幅提升。

  • 保持原生性能

    Compose Multiplatform在各平台都编译为原生代码,性能接近原生应用。

  • 技术栈统一

全部使用Kotlin生态,学习成本更低,团队协作更高效。

  • 渐进式迁移

你不需要重写整个应用,可以先从一个模块开始。

比如先把网络层用KMP重写,然后逐步迁移UI到Compose Multiplatform。

  • 生态仍需完善

生态仍在加速建设,注意版本兼容与插件成熟度,第三方库相对较少,但发展很快。

5.2 uni-app / uni-app x

传统uni-app
基于Vue.js + JavaScript,更适用于小程序开发

uni-app x
全新架构,使用UTS语言,性能达到原生级别

uni-app x的技术特点

  • 平台支持最全

一套代码可以发布到:iOS、Android、Web、各种小程序、快应用、鸿蒙...

总共支持14+个平台,这是其他框架做不到的。

  • 小程序优先的设计理念

如果你的产品需要同时支持App和小程序,uni-app几乎是唯一的选择。

其他框架都是App优先。

  • 国产化支持

对鸿蒙、信创等国产化平台支持最好。

这对国内企业来说非常重要。

  • uni-app的局限

    生态相对封闭
    主要依赖DCloud的生态
    国际化程度低
    海外开发者使用较少
    技术栈绑定
    主要适合Vue技术栈

5.3 Valdi

Valdi的核心思路属于转译方案的范畴,但是并发代码级转译。

它采用了介于转译和中间层之间的混合架构,将UI组件树编译为原生组件并交由C++引擎管理生命周期,同时保留业务逻辑在TS层(Worker)运行,从而实现无JS Bridge的高性能渲染。

这样的好处是在一定程度上避免了转译类方案代码翻译不到位造成的一些问题。

但是仍然会有中间层方案在高UI交互场景下的性能问题,这部分就需要把处理逻辑放到C++/Swift/Kotlin编写的Polyglot模块解决。

站在纯粹客户端跨平台开发的角度,转译类方案老刘目前更推荐KMP。

Valdi可以作为一个有潜力的备选,等生态更加成熟后再重新考虑。


6. 技术选型指南

看了这么多技术栈,是不是更晕了?老刘把复杂的选型逻辑浓缩成一份实战决策指南,帮你快速拍板。

6.1 核心推荐:Flutter (通用首选)

对于 90% 的新启动 App 项目,Flutter 是当前版本的最优解

  • 性能强悍
    自带 Impeller 渲染引擎,不依赖系统组件,体验无限接近原生。无论是复杂的动画还是高性能列表,都能轻松驾驭。
  • 效率极高
    Hot Reload (热重载) 让改代码像刷新网页一样快。一套代码覆盖 Android、iOS、Web 甚至桌面端,研发成本降低 40% 以上。
  • AI 友好
    作为 Google 亲儿子,Cursor、Claude 等 AI 工具对 Dart/Flutter 的支持极为成熟,能自动生成高质量 UI 代码。

⚠️ 避坑提示
如果你的应用极度依赖原生比如有大量历史遗留的原生代码,或对包体积有苛刻要求 (<10MB),需谨慎评估。

6.2 潜力观察:Kotlin Multiplatform (KMP)

极度依赖原生的最佳选择。

  • 核心定位
    逻辑共享,UI 原生
    它不强求 UI 统一,而是让 Android 和 iOS 共享数据层、网络层和业务逻辑代码。
  • 适用场景

    • 已经在原生层面积累了大量的UI组件和功能模块,可以逐步把业务逻辑切换到KMP。
    • 应用强依赖系统底层能力 (蓝牙、NFC、深度硬件交互),同时又希望保持跨平台的优势。
  • 现状判断
    技术理念先进,但第三方生态仍在爬坡期。2026 谨慎全量 All-in。

6.3 谨慎评估需求:App + 小程序 ≠ 一套代码

一个产品有App和小程序不代表他们的业务逻辑是完全一致的,小程序在产品定位上不应该是App的简化版。

  • 最佳实践:App和小程序承担不同的产品职责

    • App (Flutter/原生)
      负责沉浸式体验、复杂交互、高粘性留存 (如阅读、创作、社交)。
    • 小程序 (原生/Uni-app)
      负责营销裂变、即用即走、低成本获客 (如分享落地页、简单工具)。
  • 决策依据
    只有当功能重叠度 > 80% 且交互极其简单 (如纯展示类新闻、简单电商) 时,才推荐使用 Uni-app/Taro 等方案同时生成 App 和小程序。

6.4 决策速查表

你的项目场景推荐技术栈理由
从 0 到 1 新项目Flutter效率与体验的最佳平衡点
原生项目转型跨平台Flutter可以增量迁移,混合开发风险低
重度依赖原生底层KMP风险低,渐进式重构
App与小程序功能重叠Uni-app小程序支持好
系统级工具纯原生 (Swift/Kotlin)无中间层损耗,完全掌控硬件
团队 Web 背景React Native学习曲线平滑,社区资源丰富

7. 总结与建议

写了这么多,老刘最后给你一个终极建议。

2026年跨平台开发,记住这三个关键词:务实、聚焦、长期主义。

7.1 务实

软件开发没有银弹。

Flutter性能好但包体积大,React Native动态性好但有桥接损耗,KMP接近原生但生态不成熟。

选择技术的核心是:在当前约束条件下,哪个方案的收益最大。

7.2 聚焦

没有项目需要超过2种跨平台框架同时使用。

同样也不推荐团队同时在多个不同的跨平台框架上投入时间和精力。

建议:选定一个主力技术栈,最多再备一个备选方案。

7.3 长期主义

真正决定项目生死的,是你选定技术栈之后做的那些事。

  • 架构设计够不够清晰?
  • 开发流程够不够规范?
  • 代码规范够不够严格?
  • 技术债务管理够不够及时?

选定技术栈不是终点,而是起点。

做好这些基础建设,才是项目能持续健康演进的根本。

否则,再好的技术栈也救不了你。

最后,希望这篇跨平台开发地图能帮你避开那些坑,找到最适合你的路。

如果看到这里的同学对客户端开发或者Flutter开发感兴趣,欢迎联系老刘,我们互相学习。

点击免费领老刘整理的《Flutter开发手册》,覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。

覆盖90%开发场景的《Flutter开发手册》

作者:王元

1. 背景与痛点:存量代码的“多语言噩梦”

在前端开发中,将一个成熟的中文存量项目进行国际化多语言(i18n)改造,往往面临着以下困境:

•工作量巨大: 项目包含数百个 .vue/.js/.ts 等文件,散落着成千上万个硬编码的中文字符串。

•人工易错: 手动提取容易遗漏,且极其枯燥,极易产生 Copy/Paste 错误。

•命名困难: 为每一个中文词条想一个语义化的英文 Key(如 homePageTitle)不仅耗时,而且难以保证团队风格统一。

•维护成本高: 翻译文件(zh.ts/en.ts)的维护和代码中的替换需要同步进行,稍有不慎就会导致报错。

如果按照传统的人工查找替换方式,预计需要耗费数周的人力。为了打破这一僵局,我决定利用 JoyCode 结合我开发的 i18n-mcp 工具,打造一套自动化的国际化多语言解决方案。



2. 解决方案:JoyCode + i18n-mcp

我基于 MCP (Model Context Protocol) 开发了一个工具 i18n-mcp,通过 JoyCode 的 AI 能力来调度和执行以下三个核心步骤,实现了从“提取”到“替换”的全链路自动化。

流程图

以下是i18n-mcp的流程图(由JoyCode生成)

在这里插入图片描述

核心流程拆解

第一步:智能提取中文与去重

i18n-mcp 自动扫描所有源文件。利用正则或 AST(抽象语法树)精准识别代码中的中文字符串(包括 Template、Script 和 JSX 部分)。

•全量扫描(full-project-scan工具): 文件过多的时候,全量扫描会有问题。可以通过指定文件夹的方式,扫描该文件夹下面的文件。

•增量扫描(git-change工具):针对git变更的文件,进行扫描。精准定位变更文件,仅处理本次变更涉及的代码,大幅提升效率。

•智能去重: 对提取出的文本进行去重,确保相同的中文文案(如“确认”、“取消”)只生成一个 Key,避免冗余。

第二步:AI 辅助翻译与文件生成

•翻译缓存: 优先查询 数据存储层 中的 Translation Cache,已翻译过的文案直接复用,显著降低 Token 消耗并加速流程。

•自动化翻译: 提取的中文列表没有在缓存中或zh文件中的,被发送给 LLM,自动翻译成英文。

•语义化 Key 生成: 区别于传统 Hash 值,LLM 根据代码上下文(Context)自动生成符合语义的 Key(如将“请输入密码”生成为 pleaseInputPassword),提升代码可读性。

•文件落地: 自动在 lang 文件夹下生成标准的 zh.tsen.ts 文件。



生成示例: zh.ts: { "pleaseSelect": "请选择" } en.ts: { "pleaseSelect": "Please Select" }





第三步:一键代码替换

•变更预览 (Preview): 在实际修改前,可调用 preview-changes 工具展示即将变更的代码对比,确保修改符合预期。

•AST 节点替换: 使用 extract-and-replace 工具,将源代码中的硬编码字符串精准替换为国际化方法(如 $t('pleaseSelect'))。

•无损格式保持: 基于 AST 的替换策略能够完美保留原代码的缩进、换行和注释,修改后的代码无需二次 Lint 即可直接提交。





3. 成果与收益:从“数周”到“数小时”

通过引入 JoyCode + i18n-mcp 的实践,我在项目的国际化改造中取得了显著的成效:

📊 定量收益

维度传统人工方式JoyCode + i18n-mcp提升幅度
单页面改造耗时约 10-30 分钟< 1 分钟效率提升 90%+
词条遗漏率质量显著提升
变量命名耗时需人工构思AI 秒级生成完全自动化

💡 定性收益

1.解放生产力: 从枯燥的“搬运工”工作中解脱出来,可以专注于业务逻辑和核心功能的开发。

2.代码规范统一: AI 生成的 Key 风格高度统一(全驼峰),避免了“千人千面”的命名混乱。

3.可维护性增强: 建立了自动化的语言包管理机制,后续新增词条只需运行脚本即可。



4. i18n-mcp开发

i18n-mcp是我首次开发MCP,整体难度相对较低。对于前端部分,基于github模板进行开发,随后发布至公司NPM私服即可。

核心代码主要由JoyCode的编码功能协助完成。按照上述核心流程步骤通过问答交互的方式,引导JoyCode完成核心代码的开发工作。

整个i18n-mcp架构图如下所示(架构图亦由JoyCode生成)。

在这里插入图片描述



MCP配置如下

{
  "mcpServers": {
    "i18n-mcp": {
      "autoApprove": [],
      "disabled": true,
      "timeout": 180,
      "command": "npx",
      "type": "stdio",
      "transportType": "stdio",
      "args": [
        "-y",
        "@jd/i18n-mcp@latest"
      ],
      "env": {}
    }
  }
}

效果

配置之后,输入prompt “调用i18n-mcp的auto-i18n-process方法”

效果如下:

在这里插入图片描述

5. 总结

尽管目前 i18n-mcp 仍存在一些不足,例如在全面扫描大量文件时可能出现连接错误、翻译和替换结果不够准确等问题,仍需人工进行二次校验,但其在短时间内辅助开发的价值依然显著。在本次实践过程中,我主要通过 JoyCode 的交互式问答完成开发工作。JoyCode 不仅在代码补全方面发挥了重要作用,更凭借其强大的智能调度和自动化执行能力,成为高效处理复杂任务的核心中枢。结合 i18n-mcp 的开发,AI技术的深度赋能得以充分体现,大幅提升了开发的效率。

后续,我将持续研究 AI 在前端开发中的落地场景,充分发挥 AI 辅助开发的强大能力。通过深入探索和应用 AI 技术,进一步释放其在业务创新与效率提升方面的巨大潜力。

作者:王元

1. 背景与痛点:存量代码的“多语言噩梦”

在前端开发中,将一个成熟的中文存量项目进行国际化多语言(i18n)改造,往往面临着以下困境:

•工作量巨大: 项目包含数百个 .vue/.js/.ts 等文件,散落着成千上万个硬编码的中文字符串。

•人工易错: 手动提取容易遗漏,且极其枯燥,极易产生 Copy/Paste 错误。

•命名困难: 为每一个中文词条想一个语义化的英文 Key(如 homePageTitle)不仅耗时,而且难以保证团队风格统一。

•维护成本高: 翻译文件(zh.ts/en.ts)的维护和代码中的替换需要同步进行,稍有不慎就会导致报错。

如果按照传统的人工查找替换方式,预计需要耗费数周的人力。为了打破这一僵局,我决定利用 JoyCode 结合我开发的 i18n-mcp 工具,打造一套自动化的国际化多语言解决方案。



2. 解决方案:JoyCode + i18n-mcp

我基于 MCP (Model Context Protocol) 开发了一个工具 i18n-mcp,通过 JoyCode 的 AI 能力来调度和执行以下三个核心步骤,实现了从“提取”到“替换”的全链路自动化。

流程图

以下是i18n-mcp的流程图(由JoyCode生成)

在这里插入图片描述

核心流程拆解

第一步:智能提取中文与去重

i18n-mcp 自动扫描所有源文件。利用正则或 AST(抽象语法树)精准识别代码中的中文字符串(包括 Template、Script 和 JSX 部分)。

•全量扫描(full-project-scan工具): 文件过多的时候,全量扫描会有问题。可以通过指定文件夹的方式,扫描该文件夹下面的文件。

•增量扫描(git-change工具):针对git变更的文件,进行扫描。精准定位变更文件,仅处理本次变更涉及的代码,大幅提升效率。

•智能去重: 对提取出的文本进行去重,确保相同的中文文案(如“确认”、“取消”)只生成一个 Key,避免冗余。

第二步:AI 辅助翻译与文件生成

•翻译缓存: 优先查询 数据存储层 中的 Translation Cache,已翻译过的文案直接复用,显著降低 Token 消耗并加速流程。

•自动化翻译: 提取的中文列表没有在缓存中或zh文件中的,被发送给 LLM,自动翻译成英文。

•语义化 Key 生成: 区别于传统 Hash 值,LLM 根据代码上下文(Context)自动生成符合语义的 Key(如将“请输入密码”生成为 pleaseInputPassword),提升代码可读性。

•文件落地: 自动在 lang 文件夹下生成标准的 zh.tsen.ts 文件。



生成示例: zh.ts: { "pleaseSelect": "请选择" } en.ts: { "pleaseSelect": "Please Select" }





第三步:一键代码替换

•变更预览 (Preview): 在实际修改前,可调用 preview-changes 工具展示即将变更的代码对比,确保修改符合预期。

•AST 节点替换: 使用 extract-and-replace 工具,将源代码中的硬编码字符串精准替换为国际化方法(如 $t('pleaseSelect'))。

•无损格式保持: 基于 AST 的替换策略能够完美保留原代码的缩进、换行和注释,修改后的代码无需二次 Lint 即可直接提交。





3. 成果与收益:从“数周”到“数小时”

通过引入 JoyCode + i18n-mcp 的实践,我在项目的国际化改造中取得了显著的成效:

📊 定量收益

维度传统人工方式JoyCode + i18n-mcp提升幅度
单页面改造耗时约 10-30 分钟< 1 分钟效率提升 90%+
词条遗漏率质量显著提升
变量命名耗时需人工构思AI 秒级生成完全自动化

💡 定性收益

1.解放生产力: 从枯燥的“搬运工”工作中解脱出来,可以专注于业务逻辑和核心功能的开发。

2.代码规范统一: AI 生成的 Key 风格高度统一(全驼峰),避免了“千人千面”的命名混乱。

3.可维护性增强: 建立了自动化的语言包管理机制,后续新增词条只需运行脚本即可。



4. i18n-mcp开发

i18n-mcp是我首次开发MCP,整体难度相对较低。对于前端部分,基于github模板进行开发,随后发布至公司NPM私服即可。

核心代码主要由JoyCode的编码功能协助完成。按照上述核心流程步骤通过问答交互的方式,引导JoyCode完成核心代码的开发工作。

整个i18n-mcp架构图如下所示(架构图亦由JoyCode生成)。

在这里插入图片描述



MCP配置如下

{
  "mcpServers": {
    "i18n-mcp": {
      "autoApprove": [],
      "disabled": true,
      "timeout": 180,
      "command": "npx",
      "type": "stdio",
      "transportType": "stdio",
      "args": [
        "-y",
        "@jd/i18n-mcp@latest"
      ],
      "env": {}
    }
  }
}

效果

配置之后,输入prompt “调用i18n-mcp的auto-i18n-process方法”

效果如下:

在这里插入图片描述

5. 总结

尽管目前 i18n-mcp 仍存在一些不足,例如在全面扫描大量文件时可能出现连接错误、翻译和替换结果不够准确等问题,仍需人工进行二次校验,但其在短时间内辅助开发的价值依然显著。在本次实践过程中,我主要通过 JoyCode 的交互式问答完成开发工作。JoyCode 不仅在代码补全方面发挥了重要作用,更凭借其强大的智能调度和自动化执行能力,成为高效处理复杂任务的核心中枢。结合 i18n-mcp 的开发,AI技术的深度赋能得以充分体现,大幅提升了开发的效率。

后续,我将持续研究 AI 在前端开发中的落地场景,充分发挥 AI 辅助开发的强大能力。通过深入探索和应用 AI 技术,进一步释放其在业务创新与效率提升方面的巨大潜力。


Crab - Go Web 框架

用最简单的代码,写出最清晰的架构。有教无类,拒绝防御性编程。

技术栈

  • Fiber + Xorm (pgsql) + Redis(强依赖)

目录结构

boot/    - 启动层
common/  - 业务公共层  
pkg/     - 基础设施层
module/  - 业务模块

内置能力

  • 限流、链路追踪、Prometheus 监控、结构化日志
  • WebSocket / MQ / Cron 封装(支持多节点集群)
  • 邮件服务、对象存储等业务组件

模块拆分思路

按请求量、代码量、复杂度来划分模块:

  • admin - 后台 CRUD,可以全放一个模块
  • web - 前端 API
  • 高并发场景(如秒杀)独立模块
  • AI 多 Agent 场景:每个 Agent 独立模块,一个提示词对应一个 Go 文件

这种设计的好处:人类易读,AI 易写。无论是重构、生成代码、理解需求,还是多 Agent 协作开发,都能轻松应对。

FAQ

Q: 为什么不用 GORM?
A: 不喜欢它的日志输出和执行速度。

Q: 为什么选 Fiber 而不是 Gin?
A: 性能更好,日志更友好,支持自定义 JSON 解析器。

Q: 这种架构设计的核心优势?
A: 对人友好,对 AI 友好。代码结构清晰,适合 AI 辅助开发。


代码由 Claude 编写,架构迭代一年有余。

GitHub: GitHub - nuohe369/crab: A modular Go web framework with clean layered architecture. Run as monolith or split modules into separate services from the same codebase.


PS: 整理完项目就开源基于这个项目写的 AiSaas 框架带前端 类似于 Shipany (价值 1700)


📌 转载信息
原作者:
nuohe
转载时间:
2026/1/16 12:51:42

谷歌发布了新的 Gemini CLI 预览扩展Conductor,为 AI 辅助软件开发引入了结构化、上下文驱动的方法。该扩展旨在解决基于聊天的编码工具的一个常见限制:跨会话丢失项目上下文。

 

Conductor 将开发上下文从瞬态会话中转移到直接存储在存储库中的持久 Markdown 文件中。这些文件定义了产品目标、架构约束、技术选择和工作流偏好,并作为开发人员和 AI 智能体的共享真相来源。其目的是使 AI 辅助开发随着时间的推移更加可预测、可审查和可重复。

 

Conductor 鼓励的不是直接从提示到代码的转换,而是规划优先的工作流。开发人员在调用代码生成之前定义规范和实现计划,并且这些构件在特性的整个生命周期中仍然是代码库的一部分。这种方法旨在支持更大的任务,如特性开发、重构和在已建立的项目上工作,在这些任务中,理解现有的结构和约束是至关重要的。

 

Conductor 的一个核心概念是轨迹,它代表了一个离散的工作单元。每个轨迹包括一个书面规范和一个面向任务的计划,该计划被分解为阶段和子任务。只有在计划被评审之后,实施才能继续进行,并在计划文件中直接跟踪进度。由于状态存储在存储库中,因此可以暂停、恢复或修改工作,而不会丢失上下文。

 

早期用户强调了基于轨迹的工作流,认为这是对临时提示的实际改进。Forrester 的工程和产品负责人 Devin Dickerson

 

对于这个扩展我最喜欢的特性是轨迹的概念。在这次发布之前,我一直在使用自己构建的 Conductor 开源版本,我最终构建了自己的特性切片。现在轨迹已经内置了,我可以扔掉那个了。

 

Conductor 还支持团队范围的配置。项目可以一次性定义共享标准配置,如测试策略、编码约定和工作流程偏好,并将它们一致地应用于所有 AI 辅助的贡献。这使得扩展不仅适用于个人开发人员,也适用于寻求跨贡献者和机器一致性的团队。

 

试用预览版的开发人员指出,它强调了明确的规划和测试驱动的工作流。Navid Farazmand描述道

 

当 Gemini CLI 发布时,我立即尝试用.md 文件创建类似的东西。Conductor 要好得多——特别是它采用的测试驱动开发方法。

 

Conductor 是 Gemini CLI 的预览扩展,可以从其公共GitHub仓库安装。谷歌将这次发布定位为初始步骤,随着开发人员和团队的反馈指导未来的迭代,计划进行进一步的改进。

 

原文链接:

https://www.infoq.com/news/2026/01/google-conductor/

半个小白,试着用 vibe coding,三周的空闲时间用 Claude 做出来的一个 mac 上的剪贴板历史工具 PasteMine 🤠
主打 轻量 / 隐私 / 本地化,全程纯本地存储,无网络请求、无第三方 SDK,数据不会上传。
目前仅支持文字和图片。

推荐授予 通知辅助功能 权限。通知是为了提醒复制、粘贴成功;辅助权限是用于自动粘贴。
快捷键唤醒后,直接方向键上下选,回车粘贴,输入节奏很顺。

除了核心的复制、粘贴,还做了几个小功能:

  • 固定几条历史信息
  • 图片悬停预览
  • 复制信息的 App 分类
  • 指定 App 或敏感类型,忽略复制

(注:目前未做 Apple 签名/公证,首次打开可能需要在「系统设置 → 隐私与安全性→划到底部」里点“仍要打开”。)

免费的,可以去下个 dmg 装了试试。大家轻喷 😈,有什么问题多交流。
头一次和 AI 沟通做东西挺有趣,像包工头拿着图纸站在工地,我讨论,AI 施工。
🖼️ 图片加载失败