JitAi与Cursor不同的AI Coding新范式

毫无疑问，Cursor是一款非常成功的AI编码工具。开发者只需用自然语言描述需求，它就能调用大模型生成代码和文件，为日常编码工作带来显著提效。然而，几乎所有用户在使用中都会遇到一些难以回避的痛点。

首先是准确性问题。生成的代码往往存在错误，需要开发者手动修正。更棘手的是，如果让Cursor自己修正错误，它又可能改动原本正确的其他部分，想让Cursor一次性完成完整的业务系统开发几乎不可能。代码最终要服务于业务，在业务系统开发这个场景下，我们当然要追求更高的可靠性。

其次是使用门槛。经验和评判能力不足的开发者难以掌控Cursor的输出，缺少作为代码主人应有的掌控感，依然可能创造出混乱的工程。另一种情况是，即便开发者有足够的经验和能力，但如果缺乏责任心，不严格把关AI的输出质量，同样会产生问题。这两种情况都不是我们想看到的。

第三是成本问题。背后的原因是大量持续的token消耗。即便随着技术发展，大模型的推理成本会持续降低，但持续的高token消耗本身就是不必要的浪费，谁不想少花钱多办事呢？

要让Cursor这样的AI编程工具精准、高效、低成本地完成业务系统开发是不现实的。真正适合业务系统开发的工具应该具备三个特点：高准确度、低门槛、低成本。

准确度高

AI幻觉是客观存在的，让AI理解的内容越多，出错的可能性就越大。规范化的大颗粒度内容更易理解，微观的细颗粒度内容则更难把握。让AI生成大颗粒度的规范化、模板化、模型化的内容，准确率远高于细颗粒度的内容。原生编程语言虽然规范，但颗粒度很细，这就导致了AI代码生成的准确率其实不高。

业务应用系统的开发本质上是大颗粒度的工作。系统的模块构成、模块分类、稳定的技术实现部分和个性化部分，这些在过去30年的发展中已经沉淀出大量规范化的功能模式和组件。企业Web应用系统无外乎都由门户、页面、组件、模型、服务、审批、事件、任务、权限、组织架构、登录方式等元素构成。相比于业务层的灵活配置，这些组件背后的技术实现是确定和稳定的。AI去理解业务层的接口和配置项，要比理解复杂微观的技术层容易得多，基于业务层接口和配置项生成业务系统模块的准确度也会更高。

这本质上是应用架构设计问题。JitAi提出并实现了高度可扩展的Meta/Type/Instance分层模块结构。Meta定义领域和类别，Type封装技术实现并开放数量可控的配置项，Instance承载应用层的个性化业务配置，一个业务系统由许多不同分类的这种分层模块构成。这种结构将复杂度控制在应用层之外，使应用层的复杂度极低，易于理解。AI在Instance层要应对的复杂度远低于面对原生编程语言的复杂度，生成的准确度自然更高。

门槛低

并非每个开发者都是高级工程师。能不能让初级工程师也能开发出高内聚、低耦合、易扩展的应用工程？能不能让不太懂编程的业务专家独立完成项目交付？能不能让业务专家一个人同时搞定多个客户的项目？

答案是可以的。业务系统的开发并不需要全程依赖专业程序员。在JitAi的可视化开发平台中，业务专家只需理解业务逻辑，就能像搭积木一样交付项目。再加上AI助理的加持，效率会迎来革命性提升。AI+GUI的开发模式，会带来充分的Vibe Coding体验。

可视化开发产生的也是高质量的原生代码。即便在极端情况下不得不让专业程序员介入，只需切换到全代码模式，就能继续使用专业程序员熟悉的开发工具，无缝衔接。这时借助Cursor这样的工具进行局部优化，完全没有问题。

成本低

模板化、大颗粒度的模块规范，带来了更高的AI理解准确度。准确度高意味着更少的返工和修正，开发速度自然更快，token消耗也更少。这形成了一个正向循环：架构合理带来准确度高，准确度高带来成本低。

在AI开发业务系统这件事上，JitAi的思路是务实可行的。目前FDE（Forward Deployed Engineers）概念的热度在快速上升，FDE是一种兼具工程能力与业务理解的技术角色，他们的职责是为企业客户定制、部署并扩展复杂的AI或数据驱动系统，JitAi显然非常适合这种模式。