一、从传统编程过度到面向大模型编程

1. 传统编程与面向大模型编程（LOP）的差异

在探索如何让 AI 真正赋能我们的存量项目之前，我们需要先完成一次思维上的”升级”——从传统的编程模式，过渡到面向大模型（LLM）的编程模式。这不是简单的工具替换，而是一场编程范式的转换。下面是对两种模式简单对比：

  • 传统编程模式中，我们是代码的”上帝”。每一个字符、每一行逻辑都由我们精确控制，我们给计算机下达指令，计算机去执行。我们的核心工作就是把想法直接转化为代码。

  • 面向大模型编程模式则完全不同。我们更像一个”项目经理”或”架构师”，而不是一个”码农”。我们不再是逐行编写代码，而是通过自然语言向 AI 描述我们的”意图（Intent）”。AI 是我们能力超强的”实习生”或”结对伙伴”，它负责将意图转化为具体的代码实现。

2. 编辑器转换

很多朋友可能遇到过这个问题：AI 编辑器与自己使用的编辑器差异很大，无从下手，比如有朋友可能用 WebStorm、eclipse或者 Visual Studio 的，这些编辑器可能有很多强大的工具在现代 AI 编辑器中还未迭代出来。

  • 使用插件解决问题：我原本用的 VSCode，切换到 Cursor 属于是无痛切换。市面上的很多 AI IDE 我也下载了几个体验，基本都是类 VSCode 的。所以这里就大致理一下 VSCode 怎么用能更顺手，VSCode 本身的功能比较有限，得益于插件市场，极大的扩展了他的能力。所以要用好 VSCode，得先看看自己有哪些需求，然后找到符合自己要求的插件，比如我们可能已经习惯了用 WebStorm 的主题配色，突然换到 Cursor，配色等都不是我们熟悉的，可能会比较影响编码，还有就是用惯了 git 图形界面操作，在 Cursor 找半天，影响到代码提交等，这些都可以用插件解决。

  • 性能问题：有的朋友可能同时维护多个项目，每天都在不同的项目上救火，同时打开多个Cursor 窗口去运行不同的项目很麻烦，而且 CurSor 本身有性能问题，多开几个可能就卡死了。这里大家还是可以跟用其他IDE 一样，从项目根目录打开多个项目，比如我有一个 Work 目录专门用于存项目代码，里面有好几个项目，我有时候可能同时在处理两个项目的问题，就可以打开 Work 目录，用于使用 AI 进行协作，启动项目则是另外用 git bash 去跑命令，这样就达到了开一个 IDE 同时跑多个项目的目的，命令行中断不怎么吃性能，而且开了之后丢在那里不管就行，我们专注于 Coding。

另外一个困扰大家的问题可能就是，Windows 下，Cursor 太卡了，甚至到了不可用的程度，这里可以如果项目中用 Java 的朋友，可以看看有没有装 Java 插件，据我的经验，有个 Java 插件会导致这个性能问题，可以卸载试试。

二、你还只是在用 AI 写函数吗？（开始用 AI 写业务）

1. 如何让 AI 认识我们的项目(project rule)

大模型是无状态并且有上下文限制的，每次调用大模型，他对我们的项目都是一无所知的，想让大模型理解我们的代码库，需要我们给他提供信息。AI IDE 或者 agent 也是一样的道理，每次打开一个会话我们都需要给他提供一份代码库的信息，才能让大模型更好的理解我们的代码，给出符合场景的预测。

1.1 项目规则需要包含哪些内容呢

这里我们用经典的三W回答这个问题

  • 是什么(What)：告诉大模型我们的项目是什么，基本信息应该包含：技术栈、项目架构等，有了这些信息，大模型可以对我们的项目有个大致了解，当我们跟他说要改什么模块时，他可以有路径可循，而不是瞎子摸象。

  • 为什么(Why)：告诉大模型我们的项目是做什么的，哪些模块负责哪些逻辑，比如说我们有一个项目管理系统，这个项目管理系统是以工作项为基础的，然后还有配套的工作项详情，工作项新建等大的复用率高的模块，这些信息可以提供给大模型，让他对我们的业务有一定的了解。

  • 怎么做(How)：约束大模型的行为，描述我们使用 Coding Agent 时需要做哪些工作，不需要他做哪些，比如我们可能不希望他去阅读一些配置文件或者修改 md 文件。

此外，记住不要试图把各种奇怪的信息都塞到项目规则文件，并不是说信息越多越好，太多不相关信息会让大模型吐出的结果更差，Claude 经常会忽略给他的上下文信息，因为他内部加了一条规则，若是与当前任务相关性不大的上下文，就忽略，目的是为了提高模型输出内容的质量。

1.2 如何写好项目规则

下面列举一些如何写好项目规则的守则，大模型在不断进化，我们的使用场景也各种各样，这些守则并不一定各种场合一直适用，大家可以根据环境的变化或者自己的使用场景调整策略。

宁缺毋滥：我们可能会想，既然大模型不懂我们的项目，我们就把整个项目文档都塞到项目规则里就好了，上面也提到了，信息并不是越多越好，下面是研究显示的一些内容，也许可以帮我们破除这种误解。

  • 前沿思考型大模型（Frontier thinking LLMs）能够处理的上下文边界是150-200条指令，更小的模型能处理的指令数甚至更少，非思考型大模型上下文边界小于思考型大模型

  • 较小的模型性能下降得非常快、非常严重。具体来说，随着指令数量增加，较小模型的指令遵循能力呈现指数级衰退，而前沿思考型大模型则表现为线性衰退。因此，建议尽量不要使用较小模型执行多步骤任务或复杂的计划。

  • 大模型对提示词中位于边缘位置的指令存在明显偏好：即最开头部分（Claude Code 的系统提示和 CLAUDE.md/上下文规则文件），以及最末尾部分（最近的用户消息）

  • 随着提示词总数增加，提示词遵循质量会均匀的下降。这意味着当我们试图给模型更多提示词时，它并不是简单地忽略最新的提示词，而是开始均匀地忽略所有提示词。

对 Claude Code 框架的分析显示，其系统提示中已包含约50条内部指令。根据我们使用的模型不同，这已经占到智能体能够可靠遵循指令总数的三分之一左右——而且这还不包括后续的规则、插件、技能或用户消息。

通过上面的分析，我们可知，项目规则文件应尽可能少地包含指令——理想情况下，只保留那些对当前任务普遍适用的核心内容。

项目规则文件的长度和适用性：大模型在上下文包含任务相关信息、工具等内容时，表现会比非相关信息上下的情况下更优。所以在写项目规则时，尽量写得适用性高一点，避免写过于具体的内容，可能会降低大模型输出的内容质量。项目规则的内容简洁，一般小于 300 行，尽量短一点能把信息描述清楚，效果会更好。

1.3 规则渐进

要把我们的项目信息在一份文档里描述清楚很难，特别是还要限制上下文的情况下。我们可以分模块去写适用不同模块的规则，在特定模块下才使用该规则，比如使用 Cursor 我们可能会有一个项目规则文件夹，每个规则文件可以设置在什么情况下适用。但是记得不要把具体代码内容或者函数写进去，因为我们经常改动，很快就会过时，尽量描述一些确定性的内容。

1.4 不要试图让大模型做代码风格相关的工作

大模型消耗 token 目前来看还是很昂贵的，我们可以用格式化插件去做代码风格相关的工作，这样可以节省不少的成本，此外，大模型是有学习能力的，在编码过程中可以了解我们的代码风格，在输出时也会模仿我们的风格输出，所以没必要把代码风格相关的规则放到项目文档。

1.5 不要使用自动生成项目规则或者是相关模板

项目规则作为顶层上下文，将影响到我们每次的 AI 交互，如果说项目规则质量不好的话，大模型输出的内容质量可能也会不好，影响到我们的编码体验。

2. 约束

约束 (Constraint)：这是与 AI 协作的精髓。不要给 AI 一个开放性的问题，而要给它一个带有一系列约束的”填空题”。

  • Agent 设置：在提问时明确角色，例如”你现在是一个资深的后端工程师，请使用 NestJS…”。

  • Rule 设定：明确告知”不要使用 any 类型”、”必须进行错误处理”、”API 响应格式必须遵循 {code, data, message} 结构”等。

3. 工作流/任务拆解

工作流/任务拆解 (Task Decomposition)：不要指望 AI 一步到位完成一个复杂的需求（比如”开发一个用户登录功能”）。我们需要像敏捷开发一样，将大任务拆解成小步骤，然后引导 AI 逐一完成。

  • 步骤一：”请为用户登录功能设计数据库表结构，包含字段 a, b, c。”
  • 步骤二：”基于上面的表结构，使用 TypeORM 创建对应的 Entity 文件。”
  • 步骤三：”编写一个 login 的 Service 方法，实现登录逻辑，注意密码要加密比对。”
  • 步骤四：”为这个 login 方法编写单元测试。”

通过这种方式，每一步的输出都是可控和可验证的，最终组合成一个高质量的功能。

4. 如何保证代码质量

AI 对于自己自己不了解的东西经常会胡说八道，比如你跟他说制作单下要弹窗，他如果不了解你说的这个制作单是什么意思，可能会瞎改，或者大模型只局限于了解当前业务，不相关的没做兼容适配，可能会改出问题，这也是我们不敢用AI写的复杂业务代码的原因。所以，对于AI 洗的代码，至少要 check 三遍再采用。

  • 人工审查：AI 是副驾驶（Copilot），你才是机长（Pilot）。你必须完全理解 AI 生成的每一行代码，并为它的最终质量负责。绝对不能盲目地”CV”（Ctrl+C, Ctrl+V）。
  • Code Review：团队的 Code Review 流程变得更加关键。审查的重点可以从检查语法错误，转移到更高维度的架构设计、业务逻辑的合理性上。
  • 自动化测试：单元测试、集成测试是验证 AI 代码质量最可靠的手段。你甚至可以要求 AI “为我刚才生成的代码编写全面的单元测试”，让 AI 自己来辅助验证其工作的正确性。
  • 利用 AI 提升质量：反过来，我们也可以利用 AI 来提升已有代码的质量。例如，选中一段代码，让 AI “重构这段代码，使其更具可读性”、”为这段代码补充 JSDoc 注释”、”找出这段代码中潜在的性能问题”。

三、如何用 AI 提效（主要工具是 Cursor）

1. 模型差异

我们知道大模型之间是有差异的，下面是与朋友交流的一些简单总结（为什么不说是全是我自己的经验，因为有些 plus 会员我没开过，有的土豪朋友全部有账号，都体验过，这里结合我的使用经验和朋友的使用经验做说明）：

  • Claude 适合代码，中文支持一般，上下文是长但是你不主动说它永远不读文件。
  • Gemini 出原型和图很好，最近出的 Gemini Pro3，写代码也挺强了，输出内容更加有“人味”。
  • 综合任务，GPT plus 比较能胜任，项目分类，读取各类文件，记忆，连锁思考，深度研究都挺在行。
  • Grok 编程还行，也比较有人味，可以做一些内容向、工具向的任务。

以上仅对比一些我常用的国外大模型，国内模型我仅用于日常生活，没有试过用来写代码，这里就不做说明了。

2. 教学相长

AI 编程的经验是宝贵的财富。当你发现一个特别好用的 Prompt 模板，或者一套针对某个特定场景的 Rule 时，一定要记录下来。

建立个人 Prompt Snippets：将这些高效的指令和规则沉淀下来，形成自己的”弹药库”。下次遇到类似问题，可以直接调用。这个过程不仅是在”使用”AI，更是在**”训练”自己如何与 AI 高效协作**，构建自己新的认知体系。

参考文献