52亿Token实战：用Cursor一人打造商业级RBAC后台系统

从一封邮件模板开始的AI编程之旅

今年3月底，一位开发者抱着试水的心态开始使用Cursor进行编程开发。最初的目标非常朴素——只是想写一个邮件发送模板。然而，正是这个小小的起点，让他真正感受到了AI辅助编程带来的力量。

从3月20号到8月，短短几个月的时间里，他一个人用Cursor从零开始，把一套完整的后台系统推进到了能够上线运营的程度。这个项目名为「Aus Community」，是一套采用前后端分离架构的RBAC（基于角色的访问控制）数据权限后台。

RBAC是企业级应用中最主流的权限管理模型之一，其核心思想是将权限分配给角色，再将角色赋予用户，而非直接将权限绑定到个人。这种模型最早由美国国家标准与技术研究院（NIST）在1992年正式提出，经过三十多年的发展，已经衍生出RBAC0到RBAC3四个层级，从最基础的用户-角色-权限映射，到支持角色继承、互斥约束等复杂场景。而「数据权限」则是在RBAC之上更进一步的精细化控制——不仅控制用户「能做什么操作」，还控制用户「能看到哪些数据」。例如，同样是「查看订单」的权限，区域经理只能看到自己辖区的订单，而全国总监能看到所有订单。这种行级数据隔离的设计复杂度远超简单的功能权限控制，需要在数据库查询层面动态注入过滤条件，对架构设计的要求极高。在前后端分离架构下，权限系统还面临额外的挑战：前端需要根据用户角色动态渲染菜单和按钮，后端则必须对每一个API接口进行独立的权限校验，两者的权限逻辑必须严格同步，否则就会出现「前端隐藏了按钮，但直接调用API仍然能操作」的安全漏洞。

你可能没注意到，在整个开发过程中，他消耗了高达52亿Token。这个数字直观地反映了AI辅助编程在真实商业级项目中的深度介入程度——AI不再只是写几行代码的玩具，而是能够全程参与设计、开发、测试与部署的生产力工具。

为了理解52亿Token这个数字的真实规模，需要先了解Token的概念。在大语言模型中，Token是文本处理的最小单位，一个英文单词通常对应1-2个Token，一个中文字符通常对应1.5-2.5个Token。一篇标准的技术文档大约包含2000-3000个Token，而GPT-4的一次对话上下文窗口约为12.8万Token。52亿Token意味着什么？如果按照每次对话平均消耗3000-5000个Token来估算，这相当于开发者与AI进行了大约100万到170万轮有效交互。如果折算成文字量，大约等同于2500-3500本标准书籍的文本总量。这个数字也从侧面说明了AI编程并非「一句提示词就能搞定一切」，它需要大量的迭代对话、反复调试和持续修正，每一个功能模块可能都经历了数十甚至上百轮的人机交互才最终打磨成型。

单人全流程交付：设计、开发、测试、部署

这个项目最令人印象深刻的地方，在于它是由一个人独立完成的。在传统开发模式下，一套商业级的RBAC权限后台往往需要一个小型团队协作数月才能完成，而借助Cursor，单人也能覆盖从设计到部署的完整闭环。

Cursor是一款基于VS Code深度改造的AI原生代码编辑器，由Anysphere公司于2023年推出。与GitHub Copilot等以插件形式嵌入IDE的AI编程工具不同，Cursor将AI能力深度集成到了编辑器的每一个环节。它支持多种大语言模型（包括GPT-4、Claude等），能够理解整个项目的代码库上下文，而不仅仅是当前打开的文件。开发者可以通过自然语言对话让AI理解需求并直接在代码中生成、修改内容，也可以让AI分析整个项目结构来回答架构层面的问题。Cursor的一个关键能力是「Codebase Indexing」——它会对整个项目的代码进行向量化索引，使得AI在回答问题或生成代码时，能够参考项目中其他文件的实现逻辑，从而生成与现有代码风格和架构更一致的结果。

项目启动时，开发者做了一个大胆的决定：把旧的前后端代码几乎全部删除，只保留了后端几个还能复用的模块，然后基于AI辅助从头重构。

从数据上看，GitHub上这个项目相关仓库的前后端推送次数大约达到了1200多次。如此高频的提交背后，是AI大幅降低了编码门槛与试错成本，让开发者能够快速迭代、频繁验证。1200多次Git提交在五个月内完成，意味着平均每天约8次提交，这个频率在传统开发中几乎只在大型团队的CI/CD流水线中才能看到，而这里却是一个人完成的。

快不等于能交：AI编程的核心认知

然而，这位开发者的实践经验中，最有价值的部分并非「速度」，而是他对AI编程本质的清醒认知。他反复强调一个核心观点：

Cursor写得快，但快不等于能交。

对于商业级项目而言，代码能运行只是最低标准，真正决定项目质量的是架构设计、边界处理和工程规范。

他举了一个具体的例子：接口注解的优先级问题。公开注解、内部注解、登录注解——当这些注解同时存在时，谁应该优先生效？

在Java Spring框架（以及类似的后端框架）中，注解（Annotation）是控制接口行为的核心机制。以权限系统为例，开发者通常会定义多种自定义注解来标记API接口的访问级别：@Public表示无需登录即可访问（如注册、登录接口）；@LoginRequired表示需要用户登录；@InternalOnly表示仅限内部服务调用。问题在于，当一个Controller类上标记了@LoginRequired，而类中的某个具体方法又标记了@Public时，系统应该如何处理？这就涉及到注解的继承与覆盖机制设计。常见的设计模式包括：方法级注解优先于类级注解（就近原则）、高安全级别注解优先于低安全级别注解（安全优先原则）、以及通过显式的优先级数值来裁决冲突。这些决策没有标准答案，必须根据具体业务场景来权衡。AI可能会给出一个「能跑」的实现，但它无法理解「公开注解在这个业务场景下是否应该覆盖登录要求」这种需要领域知识和安全意识的判断。

这类需要深度业务判断的设计决策，必须由人来思考并形成闭环，而不能完全甩给AI。

人负责设计，模型负责落地

这里揭示了一种高效的人机协作模式：人负责想清楚设计逻辑，模型负责高效落地实现。 AI擅长把明确的意图快速转化为代码，但它无法替代开发者对系统架构的整体把控。

换句话说，AI编程的「围栏」比「速度」更重要。开发者需要为AI划定清晰的边界，让它在正确的轨道上高效运转，而不是任由它随意发挥。这种协作模式本质上是一种「声明式编程」的升级版——过去开发者用SQL声明「我要什么数据」，数据库引擎负责「怎么查」；现在开发者用自然语言声明「我要什么系统行为」，AI负责「怎么实现」。但声明越精确，结果越可控；声明越模糊，AI「自由发挥」的空间越大，翻车的概率也越高。

用Cursor Rules约束AI：对抗技术债的关键策略

在实践中，这位开发者总结出了一套行之有效的方法论——把规则明确写进Cursor的规则文件（Rules）。

Cursor Rules是Cursor编辑器提供的一种项目级配置机制，开发者可以在项目根目录下创建.cursor/rules文件夹，在其中编写自然语言或结构化的规则文档。这些规则会被Cursor在每次AI交互时自动加载为系统提示词（System Prompt）的一部分，从而持续约束AI的代码生成行为。例如，你可以在规则文件中写明「所有Service层方法必须有对应的单元测试」「禁止在Controller中直接操作数据库」「API响应格式必须遵循项目统一的ResponseWrapper结构」等。这种机制相当于为AI设置了一套「项目宪法」，让AI在生成任何代码时都必须遵循这些约定，而不是仅依赖模型自身的通用编码习惯。

通过规则文件，他为AI设定了硬性的工程标准，例如：

• 后端代码必须包含单元测试
• 必须有架构测试来保证代码结构符合设计规范
• 接入SonarQube等代码质量分析工具进行持续把关

这套机制的核心价值在于对抗AI编程时代日益凸显的问题：技术债。

技术债（Technical Debt）这一概念由Ward Cunningham在1992年提出，它将软件开发中为了短期速度而牺牲代码质量的做法，类比为金融中的债务——你现在「借」到了速度，但未来必须连本带「利」地偿还，利息就是后续维护、重构和修复Bug所需的额外成本。SonarQube是由SonarSource公司开发的开源代码质量持续检测平台，它能够对代码进行静态分析，自动检测代码异味（Code Smell）、潜在Bug、安全漏洞、重复代码等问题，并将技术债量化为具体的时间成本——例如「修复当前代码中的所有问题预计需要47个工作日」。在AI编程时代，SonarQube这类工具的重要性被急剧放大：AI可以在一天内生成过去一周才能写完的代码量，但如果这些代码缺乏一致的错误处理模式、存在冗余的逻辑分支、或者违反了项目的架构分层规则，技术债就会以过去数倍的速度积累。

他一针见血地指出：接上代码质量检测工具后会发现，写得越快，技术债涨得越凶。AI的高生产力是一把双刃剑——它能让你在短时间内产出大量代码，但如果缺乏质量约束，这些代码可能迅速积累成难以维护的负担。

因此，配合SonarQube这类工具，让代码质量在快速开发的同时保持可控，成为了商业级AI编程项目能否真正「交付」的分水岭。这也呼应了软件工程中一条经典法则：发现缺陷的时间越晚，修复成本呈指数级增长。在AI编程的语境下，这条法则变得更加尖锐——因为AI的产出速度太快，如果不在生成阶段就设置质量关卡，问题会在极短时间内膨胀到无法收拾的地步。

对AI编程实践者的启示

这个52亿Token、1200多次提交的真实案例，为想要用AI进行商业级开发的实践者提供了几点重要启示：

第一，AI能显著提升单人开发的能力上限。 过去需要团队完成的项目，现在个人借助Cursor也有可能独立扛下来，这对独立开发者和小团队是巨大的机会。从行业趋势来看，Y Combinator 2024年冬季批次中，超过25%的初创公司代码库大部分由AI生成，「一人公司」或「两人团队」完成过去十人团队工作量的案例正在快速增加。这并不意味着团队协作会消失，而是说AI正在重新定义「最小可行团队」的规模下限。

第二，人的角色从「写代码」转向「定规则、做设计」。 开发者的核心价值不再体现在敲键盘的速度上，而在于对架构、边界和优先级的判断能力。这实际上要求开发者具备更高层次的抽象思维能力——你需要能够清晰地描述「系统应该是什么样的」，而不仅仅是「代码应该怎么写」。这种能力转变意味着，未来优秀的AI编程实践者，可能更像是软件架构师与产品经理的混合体，而非传统意义上的程序员。

第三，质量工程必须前置。 单元测试、架构测试、代码质量扫描不是可选项，而是驾驭AI高产出的必备手段。没有质量围栏的AI编程，只会让技术债失控。这里的「架构测试」值得特别说明——它指的是使用ArchUnit等工具，通过编写测试用例来验证代码结构是否符合预定的架构规则，例如「Service层不能直接依赖Controller层」「所有Repository接口必须放在指定包下」。这种测试在传统开发中属于进阶实践，但在AI编程中几乎成了必需品，因为AI在生成代码时很容易打破人类开发者心中默认遵守的架构约定。

从一个邮件模板到一套能上线的商业级后台，这段实践生动地展示了AI编程的真实能力边界：它足够强大，但只有在人类工程智慧的引导下，才能真正发挥价值。