写在开始

这篇文章是对于我长期的ai coding的经历分享，主要是对于我的多个阶段失败尝试的归纳总结。可能因为我还在上学，接触的技术栈还很有限，所以项目本身的参考意义不大，但是对于与ai的交互我有很深的体会。我也会分享

我的ai coding经历

第一阶段：纯llm网页端

我大一开始学python与c的时候，正好gpt已经在写简单代码上完成度已经还可以了，我当时不会的作业就会整个复制到gpt中，gpt返回代码，我复制到ide中，报错就再发给gpt，如此反复。这也就是传统意义上的vibe coding。

在当时，我遇到了以下问题：

1. llm的上下文不足，经常性的在来回提问的拉锯战中，gpt直接撂挑子不干了。
2. gpt在当时本身的代码能力不足（当时thinking都没出，好像还是gpt3.5）
3. 同样由于上下文，一些长的需求（比如大作业），我直接就输不进去，即便输入了它的输出也效果不好。

这大部分是由于llm的原生能力带来的局限性。但是在这段时间我也有很大的收获：我第一次体验到了prompt设计的提效能力。我当时很喜欢让gpt做各种角色扮演，这样在特定领域中，gpt的能力由于我对于它的prompt的设计变强了。

可纯网页端的llm的局限还是存在，即便后续我有尝试了每个时期最强的coding llm，比如claude、gemini，llm无法直接得到代码库，全部给了又会爆上下文。

通过后续的学习，我发现虽然ai的能力边界还没有那么强，但是我与ai的交互方式是有问题的：我一直把一个高耦合度的问题直接交给ai，没有进行逻辑上的拆分、解耦。同样一个项目，我直接抛给ai让它直接帮我写与先开一个窗口进行抽象层级的设计与分模块，再分别开一个窗口去设计这个模块，后者效果显著提升。

但是需要我作为llm与ide之间的中介这件事还是让我很不爽，直到我遇到了cursor。

第二阶段：用coding agent来vibe coding

cursor的效果真的很惊艳，我用了免费额度，第一次体验到了有多个tool use的ai agent的强大能力。

后来，由于一个编写Django的博客的大作业，我第一次下单了cursor的pro，这个项目本身可能对我影响不大，但是它对于我的自动化编程的工作流以及样态产生了很大的影响。

我开始尝试让Cursor来完成整个项目的开发。最初的体验是惊艳的：它能够读取我的整个代码库（至少看似能够），我不再需要手动复制粘贴代码片段给LLM。通过简单的@指令，我就可以将文件、函数甚至整个目录作为上下文喂给AI。这使得AI对于项目有了一个整体性的认知，而不再是管中窥豹。

我当时还是在vibe coding，只是进行了最初的一些设计，然后就让cursor一步步做。

问题马上就来了，这种没事你就自己跑、遇事把报错抛给cursor改的方式，遇到了瓶颈：我发现即便是ai agent，它其实内核还是那些llm，只是通过一些方式简化、标注化了输出方式，当一个任务的上下文太长的时候，速度与效果都会很差。

第三阶段：体系化的使用coding agent

这个时候，我已经对于编程有了一些体系化的思考，我马上去学习了一些相关的cursor技巧，发现了一个很有效的解决方案：使用cursor的rules。

rules是一个cursor原生的system instruction模块，原本我只是用它来让cursor默认输出中文，但是经过了学习，我发现rules有更多的作用：

1. 规范cursor的行为，比如下图是我使用的后端代码规范的一部分。
2. 在外网的论坛上，我学到了memory bank，通过设计rules，每次项目开始cursor都会先初始化一个memory bank文件，它贵根据readme文件或者prd啥的已知信息，创建一个md文件，分别存放：项目概要、技术选型、项目结构（附上mermaid的流程图）、总todo list、项目已完成内容、正在进行。每次进行了一个阶段的行为，它就必须更新memory bank。这种设计有很大的好处，每次，llm的上下文不是冗长的之前的对话全文，而是条理清晰、边界明确的理解框架，这对于llm的提效有很多好处。（现在的版本的cursor好像原生的支持memory了，我还没有具体尝试）

在memory bank的加持下，我半天就完成了整个课程作业，至少可以跑得动，程序的逻辑也都跑通了，可以说效率极高。

但是ui就是依托，为了解决美观性的问题，我学习的MCP，使用了Context7来改良了我的前端，同时我还使用到了很多好用的MCP。比如sequential thinking，它赋能了我工作流最开始的项目解耦的过程，它可以把一个问题拆成最小模块的子问题，这让为的todo list的编写以及后续的项目开展提供了很大的帮助；比如exa search，它让我在cursor的联网搜索能力还很差的时候可以使用更好用的联网搜索工具。

claude code使用体验

最近使用了claude code一周，配置wsl花了我不少时间（之前没有玩过）。

当我第一次使用claude code的时候，给了我类似于最初使用cursor的那种惊艳感，它给了我一种错觉：llm的上下文已经不是问题了，它可以阅读我的代码库，然后进行全盘的分析。claude code原生支持了todo list以及一定的记忆模块。也可以设置通用配置与项目专用配置。

我兴致冲冲，做了一个有点复杂的ai agent项目，想要体验claude code的边界能力。

但我的项目实现却不是很成功（ps：最近在实习，所以基本是把claude code放在后台挂机，基本是给了claude code最大的自由，我直接用了claude–dangerously-permissions，让我不需要进行权限上的操作）

几天下来，几个明显感受：

• 上下文很长，但是不是无限长，所以规划与执行最好还是要分块、分层
• 如果不去给claude.md文件进行良好的prompt设计，效果会不够理想。
• 行为最好体系化规范化，claude code经常在我的根目录里塞一大堆文件，不论是测试文件还是改进方向的文档，在后续的设计中我要先设计良好的prompt，

结果上，当claude code跟我说已经可以打开项目时，我开始了无尽的报错修复循环，仿佛又回到了以前的纯vibe coding。光我现在发现的有api接口设计的问题、pip的交叉依赖、npm没装好当成装好了（这个是一个挺普遍的问题，claude code在设计命令行的工具时好像默认是不读命令行的返回信息的，这让很多报错没有在刚出现的时候被测试出来，后续需要用prompt改善）等等问题。

我的分析与改良方案

由于暂时使用的没有那么深度，我还没有配置mcp、专门设计system prompt，光就原生能力上，claude code的planner的能力是要强于cursor的（而且opus配额也比cursor便宜），但是在解决上下文的逻辑上，还是不够惊艳。

所以为了更好的使用claude code，后续我会做出以下设计：

1. 专门针对claude code设计通用的system prompt与项目的claude.md文档的模板。
2. 接入好用的mcp服务，赋能工作流中的需求解耦的部分。
3. 尝试在claude code中复现memory bank的逻辑，并规范化claude code的行为。

对于ai coding工具的思考

最近听到一种说法，招实习生和正式工的钱，不如拿来买Claude额度。创业和coding都是马太效应极其严重的，非优等能力的员工不如Claude Code，如果你没有“这个人真的比我牛逼”的想法，不值得吸纳进来。

这种说法其实揭露了当前像我这样的初级开发者的尴尬。

我看过软件开发领域的一本经典著作《人月神话》，它阐述了一个问题，在软件项目中，真正吞噬成本的往往不是技术实现本身，而是团队协作过程中产生的沟通损耗。

以前初级开发者在组织中的成长路径是有中高级开发者带，类似师徒制。中高级开发者因为精力问题或者人员培养要求，会把一些开发问题分给初级开发者去实现，初级开发者在实现的过程需要和高级开发者反复沟通。在这个过程中，初级开发者因为被实际工作锻炼过、被有经验的人指导过、有自己独立思考并解决过问题，会得到比较快的成长。

而现在，Claude Code或其它AI Coding工具在能力上可比初级开发者强多了。中高级开发者发现用AI沟通解决一个问题，要比和徒弟沟通解决起来更快，那为什么不直接和AI沟通。初级开发者的锻炼成长机会就少了。

所以现在我在主动培养我的一种产品经理思维，我越发感觉针对需求，能提出好问题、进行好的拆解在当前其实才是最重要的能力。

希望我的分享能够给大家带来一些启发与参考。