ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

RooCode入门实战:在VS Code中让AI Agent自动完成多文件开发任务

RooCode入门实战:在VS Code中让AI Agent自动完成多文件开发任务 1. RooCode到底是什么它和终端里的AI助手差别在哪这些年AI编程工具层出不穷从最早补全代码的Copilot到后来能聊天的Cursor再到去年开始火起来的Claude Code这类终端Agent。工具越来越多但大部分人实际用下来的感受是补全类工具比较被动你写一行它补一行聊天类工具又隔着一层AI给你的代码你还得手动复制回文件里改错位置还得来回折腾。RooCode这个名字乍一看像个新冒出来的小工具实际它已经在AI辅助开发圈子里火了挺长一段时间。它是VS Code里的一款开源AI编程助手扩展前身是Roo Cline后来改名为RooCode。它最大的特点是不只是一个聊天的窗口而是一个真正能在你的项目里干活的代理。它能读你的目录结构、打开文件看代码、直接修改多个文件、在终端里跑命令、跑完测试自己看报错然后继续修整个过程基本不用你手动搬运代码。如果你用过Claude Code可以这样理解Claude Code在终端里跑适合那种我就在命令行里干活的工作流RooCode则直接把同样的Agent能力搬进了VS Code图形界面。你选中有问题的代码片段或者打开一个文件说清楚要改成什么它就在编辑器侧边栏里一步步执行每做一次操作你都能看到它读了什么文件、写了什么内容、跑了什么命令。这一层可视化对新手特别友好至少你知道它在干什么而不是一个黑盒子在终端里刷刷刷地输出。那RooCode到底适合谁来用我觉得分三类人第一类是写业务代码的前端、后端工程师手头有一堆多文件的改动要做比如改接口、加页面、重构公共组件这类活儿手工做繁琐交给RooCode做又快又不漏第二类是需要在已有项目上做增量开发的人RooCode读代码的能力比直接在空白窗口问AI要靠谱得多它是基于你项目真实上下文去改的第三类是刚开始接触AI编程、对命令行有点发怵的人VS Code插件的形式上手成本低第一次用基本零压力。还有一个关键点RooCode是开源的而且扩展性很强。它不止支持Claude模型还能接GPT系列、Gemini、国内各家大模型甚至本地Ollama跑的开源模型也行。这意味着你完全可以根据自己的预算、数据隐私要求和网络情况自由选择用哪个模型驱动它。我个人用了几个月下来最大的感受是它把我从复制粘贴-微调配错-再复制粘贴的循环里解放出来了特别是涉及多文件协作的任务效率提升不是一点半点。这个入门文章我就按自己实际踩过的路径来写怎么装、怎么配置、三种工作模式怎么用、自定义规则怎么写、完整跑一个任务示范、以及后期我沉淀下来的避坑经验。内容偏实战每一步我尽量说清楚为什么这么弄这样你之后遇到参数或者配置自己也有判断力。2. 安装和环境配置第一次跑通对话的完整路径这一Part我按自己当时的上手顺序来写从装插件到真正能用起来跑通一个任务。中间有些配置项官方文档写得比较绕我把它拆开揉碎说透。2.1 安装扩展本身这一步没什么难度打开VS Code左侧扩展面板搜索Roo Code认准全名Roo Code原Roo Cline作者信息一般显示为RooCode团队安装量百万级这个基本不会装错。装完之后侧边栏会出现一个Roo Code的小图标点开就是它的主界面。第一眼界面可能会让你有点懵左边是任务对话列表中间是当前任务的大块对话区域底部有模式选择、模型选择和一个输入框。输入框就是你跟它交流的地方——注意RooCode不是一个问一句答一句的聊天机器人它更像一个需要你把任务描述清楚的下属。你给它一个含糊的需求它就给你一个含糊的结果你给它一个明确、分步骤的任务它就能高效地完成。提示首次打开RooCode面板它会让你选择工作目录。我建议直接选择当前打开的项目根目录这样它能看到的代码范围是整个项目。如果选错了之后在权限设置里也能改。2.2 模型提供商配置这是入门第一道小门槛装完扩展之后真正拦住大部分人的是API Key的配置。RooCode本身不带模型算力它需要接一个模型服务商。在设置界面你会发现它支持长长一串Provider列表包括但不限于Anthropic、OpenAI、Google、本地Ollama、以及各种兼容OpenAI接口的中转服务。我当时第一次配置时用了Anthropic官方API因为RooCode很多针对代码任务优化过的特性比如强大的工具调用能力配合Claude模型效果最稳定。操作路径打开RooCode面板点击设置图标在API Provider下拉框里选择Anthropic然后填入你的API Key。如果你没有Anthropic账号也可以选OpenAI Compatible填入接口地址和密钥现在很多服务商都支持这种标准协议。表格里我整理几个常见配置路径供参考Provider需要准备的东西备注AnthropicAPI Key可能还需要配置出口网络配合Claude模型效果最稳工具调用能力强OpenAIOpenAI API Key选GPT-4o或更新的模型注意部分模型不支持工具调用就不行OpenAI Compatible接口Base URL、Key、模型名国内一些中转/聚合服务都是这种方式Google GeminiGoogle AI Studio Key免费额度友好适合尝试Ollama本地模型名完全离线但大模型跑本地需要电脑配置够硬填完之后强烈建议先发一条最简单的消息测试你好介绍一下你自己。如果它正常回复说明链路已通。如果有报错大概率集中在三处Key复制多了空格、模型名填不对、网络不通。模型名这个坑值得多说一句——如果你选的是OpenAI Compatible模型名称必须填服务商支持的准确名称比如gpt-4o不能随便写个gpt-4“chatgpt”否则接口直接报404。2.3 初始化环境里的几个选项怎么选配置完模型你会看到RooCode的初始化设置里有几个选项我一个个说我的选择和建议。第一个是任务目录管理。默认情况下RooCode在项目根目录生成一个roo文件夹用来存放任务历史如果你选的是使用项目目录存储。这个目录建议直接纳入.gitignore因为里面存的是任务对话快照没必要提交到代码仓库。第二个是工作区信任设置。VS Code本身有工作区信任机制RooCode遵循这一套。打开项目时选信任即可否则它在你的项目里执行写文件、跑命令这些操作会被限制。第三个是检查点Checkpoint功能这个默认开启。它会在Agent每次执行关键步骤之前自动保存当前文件快照万一改挂了能一键回滚。这个功能非常重要我后面有一节专门讲这里先开个开关。2.4 二次确认一下面板上的每个按钮都干什么很多教程直接跳过界面说明导致新手一上来到处乱点。RooCode主面板核心元素我梳理一遍顶部是会话选择器你可以同时开启多个任务会话每个会话是独立的互不干扰。中间对话区显示Agent的执行过程包括它阅读的文件、写的代码、执行的命令、报错信息。底部最左边是模式下拉框默认是Code模式中间是模型选择器可以随时切换模型甚至同一个任务里前一半用Claude、后一半切成GPT都可以最右边的大输入框是任务描述区旁边有个加号按钮可以附加文件内容。输入框旁边还有几个小图标值得注意一个是加号按钮点击可以引入文件或者把当前打开的编辑器内容作为上下文喂给RooCode还有一个是回形针按钮可以添加图片、PDF等辅助材料最右边那个快捷键按钮是设置自定义指令的这里攒着你的项目规范、代码风格要求Agent每次任务都会自动读一遍。跑通第一次对话之后基本都是这个路径输入任务描述按回车然后看Agent执行步骤遇到它需要确认的操作点允许直到任务结束汇报结果。3. 三种执行模式和权限体系理解RooCode的工作逻辑从这一节开始才是RooCode真正拉开和普通聊天工具差距的地方。它内置了一套分角色干活的模式体系本质上是把软件开发过程中的不同角色——写代码的人、设计架构的资深工程师、排查问题的调试者——抽象成了三种模式。3.1 Code模式默认主力让你的日常开发自动化Code模式是你打开RooCode时默认的模式也是日常用得最多的。它适合描述清晰、目标明确的任务比如给这个接口加上参数校验把这个组件里的loading状态补上写一个工具函数把时间戳转成指定格式的日期。这个模式下的Agent拥有完整工具集它可以列出目录、读取文件、编辑文件、创建新文件、在集成终端里执行命令。它的思维链路基本是理解你的要求观察相关代码设计方案修改代码运行测试或检查命令验证如果报错就继续修直到问题解决。第一次用的时候我给的指令是把src/utils/date.js里新增一个formatRelativeTime函数用来把时间戳格式化成3分钟前、2小时前这种相对时间。它先读了这个文件看现有代码风格又看了看依赖里有没有dayjs发现项目里已经引了dayjs就直接复用改完后还跑了一下相关的测试文件。整个过程大概持续两分钟期间它做了7、8次操作每步都会在界面上显示。这个体验比我自己去翻代码、想格式、查API要流畅得多。Code模式跑的时候有一类操作是需要人工确认的——比如执行危险的命令rm、git push这类、删除文件、修改文件。RooCode会弹出权限请求你在对话框下方点允许或者拒绝即可。你也能在设置里把某些操作改成自动允许让任务跑得更顺滑。3.2 Architect模式先想清楚再动手避免AI乱改代码我问过不少用过RooCode的人很多人都忽略了这个模式。Architect模式是RooCode的灵魂功能之一它模拟的是架构师角色不做直接的文件修改而是先读代码、分析问题、给出设计方案。这有什么用我举个例子。你接手一个老项目项目的鉴权逻辑散落在一堆中间件和工具函数里需求是新增一种角色权限类型。如果你直接在Code模式下让AI去改它很可能找到一个相关文件就动手改完一个又一个最后改得到处都是甚至踩了别的逻辑。而Archtect模式下它会把整个鉴权链路读一遍列出涉及的文件、数据流、如何在最小改动的前提下新增类型最后给你一份结构化设计方案你确认后再切到Code模式按方案实施。实际使用中我摸索出一个比较高效的工作流先用Architect模式描述需求让它产出一份实施方案我检查方案觉得合理切换到Code模式输入按刚才的方案实施Code模式会顺着上下文继续干活。这样既避免了AI随机乱改也保留了AI执行的高效。3.3 Debug模式让AI自己抓自己改BugDebug模式是第三板斧。它适合处理报错、行为异常这类问题。进入Debug模式后Agent会自动进入一种侦探式工作状态先重现问题收集报错信息查看相关日志定位到具体文件分析根因然后给出修复方案甚至直接动手修。有一个经典场景我记忆深刻。项目里一个上传功能一直正常某天后台报500排查半天无果。我把它切到Debug模式贴上报错堆栈它过了几分钟就定位到是一个第三方库版本升级后接口签名变了上传回调里还在用旧参数。它不光指出了问题还把修复代码写好了。AI这种东西最怕的就是给它一个现象让它猜Debug模式的好处在它可以自己在项目里搜索线索找根因而不是像普通聊天工具那样基于有限上下文瞎猜。3.4 权限体系该卡住的卡住不该卡的自然放行RooCode对Agent的行为有一整套权限控制理解了这套体系你就知道什么时候需要人工盯什么时候可以放手让它跑。权限控制分几个维度。文件读取操作默认是允许的因为只是读不会造成破坏文件写入操作默认需要确认但你可以在配置里设置为自动允许——用一段时间后你发现它的写操作绝大多数是可靠的于是可以选择对特定目录或特定操作类型开启自动批准命令执行是最危险的涉及删除、推送、安装依赖这类高危操作建议保持手动批准。它内部对命令有一个内置的安全分级写文件、git操作、查询类的命令有一级自动处理的默认策略rm -rf这类危险命令直接弹窗让你二次确认。除此之外还有检查点机制兜底。每次Agent执行写操作之前RooCode都会自动保存一个检查点快照。你随时可以在界面上看到这个任务执行过程中的快照记录如果发现改动不符合预期一键恢复到任意检查点。这相当于给Agent的操作加了一个后悔药机制哪怕它改错了、甚至连续改错几步你都能回退到某个正确状态重来一遍。理解了模式体系和权限体系RooCode就不只是个代码生成器了而是一个可以做方案、写代码、修Bug、自己验证的完整开发代理。接下来要聊的自定义指令则是把这套代理能力调教到贴合你项目习惯的关键手段。4. 自定义指令与上下文管理让AI真正懂你的项目用了几天RooCode之后你会发现一个现象同样的任务在A项目里它做得又快又对在B项目里却频频出错。差别在哪大概率是项目规范、技术栈提示、代码组织方式这些上下文没有给到位。RooCode核心优势之一就是支持项目级的自定义指令机制用好了它能稳稳拿捏你的代码风格。4.1 .roorules文件项目根目录下的隐形规则书RooCode支持通过在项目根目录创建.roorules文件或者配置里的Custom Instructions来设定团队级和项目级的AI行为规则。这个文件里的内容会在每次Agent执行任务时自动加载相当于给AI一份项目说明书。我自己的.roorules文件里现在沉淀了这些内容## 项目概览 这是一个基于Vue 3 TypeScript的中后台管理系统核心模块包括用户权限、订单管理、报表中心。 ## 代码规范 - 组件使用组合式API禁止Options API - 样式使用SCSS变量统一从/styles/variables.scss引入 - API请求统一走src/api目录下封装的request方法禁止直接使用axios - 新增业务组件必须包含Props类型定义类型放在组件同级types.ts - 日期处理统一使用dayjs禁止引入moment ## 架构约束 - 页面路由配置在src/router/routes.ts中集中管理禁止在页面组件内直接写路由跳转路径的硬编码 - 全局状态统一使用Pinia禁止使用任何本地变量做跨组件通信 - 后端接口数据结构不可直接作为前端类型使用必须在src/api/types.ts中定义前端需要的类型 ## 测试要求 - 新增工具函数必须补单测测试文件放在__tests__目录下 - 运行测试命令npm run test有了这份说明之后RooCode写的代码一眼看过去跟团队里其他成员写的几乎一致。比如之前放养状态它喜欢在组件里直接写axios调用配了规则之后它就规规矩矩通过/api/xx.ts里的封装方法请求。这就是规则文件的威力它像给AI戴上了一个团队规范的紧箍咒。4.2 全局自定义指令与项目级自定义指令的优先级RooCode区分两层自定义指令全局指令Global Custom Instructions和项目级指令Project Custom Instructions。全局指令在你所有项目里生效适合写关于个人偏好和通用习惯的内容比如所有注释用中文函数需要写JSDoc说明变量命名用camelCase。项目级指令则只针对当前项目生效存的是该项目专属的架构约束、目录结构和编码规范。优先级上项目级指令会覆盖全局指令里冲突的部分。你需要知道这种覆盖关系是细粒度的不是整个指令文件覆盖而是RooCode会两条读取冲突时以项目级的内容为准。所以写全局指令时尽量不涉及具体技术栈判断只写你通用的个人编码习惯项目级指令把技术栈规范写详细。这个分工能让两套规则各司其职。4.3 上下文管理不是所有项目代码都要一口气塞给它RooCode虽然有不错的上下文窗口Claude模型通常支持20万token左右最新的甚至200万但把整个仓库塞给它既不现实也完全没有必要。它的工作方式和人和一样带着目标去看相关代码而不是把所有代码背下来。那怎么让它在需要的时候能找到对的文件三个技巧第一在任务描述里明确指定相关文件。输入看下src/views/order/detail.vue里的状态管理为什么在刷新后会丢失之前它得先定位文件。你可以在描述里直接用引用或者用打开src/views/order/detail.vue分析...的语气让它先把目标文件读一遍。第二善用任务描述中的附加文件功能。当你需要它基于某个文件做改动时点输入框旁边的加号把当前打开的编辑器内容作为上下文附上。这个操作能确保它看到的是你当前工作区里最新保存的内容而不是它自己猜测的路径。第三拆任务。新手最容易犯的错误是一个任务里塞了太多子需求——帮我改下登录页、顺便把侧边栏菜单修一下、再优化一下首页请求的并发逻辑。这种多任务指派看起来省事实际会让Agent的执行计划混乱中途切换上下文还可能顾此失彼。更合理的做法是拆成三个独立任务逐个跑。这也和检查点机制契合——一个任务一步回滚。4.4 模型选型和上下文长度不要贪大基于实际的体感对于大部分互联网业务系统Claude系列模型在RooCode上综合表现最好指令跟随能力强、写代码准确率高GPT系列适合有明确技术文档需求的场景如果你用的是RooCode内置的通过OpenAI Compatible接入的一些模型效果取决于那个模型的水平一般建议选长上下文版本比较好。上下文长度有个使用上的小技巧RooCode界面上能看到当前任务的token占用情况。当占用率超过70%时我就习惯性新开一个任务会话把上一次的关键结论用一小段话描述出来带过去。比如已完成XXX功能开发代码在src/utils/xx.ts核心逻辑是XXX现在继续做YYY相当于给新会话一个简明交接文档。这样既规避了长上下文后半段模型注意力衰减的问题也让每次任务从干净状态开始效果反而更好。5. 实战演练用RooCode完成一个多文件的小需求光说不练假把式。这一节我拿一个完整的真实小需求带着大家看一遍从需求描述到最终验收的完整流程。这个需求我选择了新增一个CSV导出功能作为示例不复杂但涉及多文件改动刚好能展示Agent的实际干活流程。5.1 需求描述任务写得越清楚产出越稳定我当时的原始需求是在项目里加一个订单导出的功能用户在前端页面点击导出CSV按钮前端调用后端接口后端返回CSV文件流前端触发浏览器下载。前端是Vue 3 TypeScript后端是Node.jsExpress数据库用的是MySQL。这里我特别想强调一下任务描述的组织方式。一个好的任务描述至少要包含我要做什么、涉及哪些技术栈/目录、有什么约束条件、完成标准是什么。如果项目里有现成的类似功能比如参考用户模块的导出功能一定要写进去这会让Agent很快找到参照物照着已有模式做出来的代码风格高度统一。我写的实际任务描述大致是在这个项目里新增一个订单导出功能参考现有的用户导出功能实现 1. 后端新增接口 POST /api/orders/export支持按状态筛选status参数可选值pending/paid/shipped/completed从订单表查出数据后导出CSV表头为订单号、用户、金额、状态、创建时间。 2. 前端在订单列表页右上角加一个导出CSV按钮点击后调接口接收blob触发浏览器下载文件名格式为orders-YYYYMMDD.csv。 3. 接口需要鉴权token从header的Authorization里取复用现有的auth中间件。 4. 代码风格遵循项目现有约定。 完成标准前后端代码写完接口本地测试可返回CSV文件按钮点击能正常下载。5.2 Agent的执行过程拆解它到底干了些什么当我按下回车之后RooCode开始执行它的每一步操作在界面上逐条展开。我把典型的执行步骤梳理成一张表格方便你看懂它每一步在干什么、为什么这么干步骤Agent行为实际效果1列出项目根目录读取package.json确认技术栈、脚本命令、依赖情况2查看src/api目录结构找到现有API封装方式为新增接口调用做准备3读取用户导出相关代码复用类似的实现模式保证风格一致4查看orders模块的后端路由和控制器确定新接口应该放在哪里、怎么注册路由5生成CSV导出工具函数处理转义、编码、字段映射细节6写后端接口处理函数注册路由接口核心逻辑落地7写前端API方法、下载函数前端请求封装处理blob和文件名8修改订单列表页加导出按钮页面交互完成9启动后端服务、模拟请求验证接口自测环节发现小Bug会顺手修复10总结改动文件和注意事项输出一份任务总结第二次跑这个任务时它在第6步卡了一下查询订单时把金额字段的精度搞丢了数据库Decimal类型被转成了浮点型。它自己在自测时发现了这个问题然后追加了一个修复步骤——用toFixed(2)修一下精度。这种自修能力在AI编程工具里很重要你不是要一个只会写一次性代码的工具而是需要它能发现自己的问题并修正。5.3 人工介入的时机它不是全知全能的虽然Agent干活很利索但有几类情况我会主动介入。第一方案与技术选型。比如引入新的npm包需要确认引入时机和版本这个不能让AI自由发挥。在RooCode默认配置里安装新依赖属于高风险操作会弹窗让你确认。我看到它要引第三方库时会点掉这个确认请求改为在描述里明确不许引入新依赖用原生API实现这样它就会调整方案。第二数据安全和鉴权边界。涉及用户隐私数据导出这种场景我会专门在任务描述里强调导出数据必须过滤掉手机号字段中间4位脱敏然后检查它最终代码里有没有落实。这种业务层面约束AI没法自己判断需要人给它划红线。第三风格验收。虽然项目规则文件能约束大部分风格问题但偶尔它写的文件注释过多或过少。我在验收阶段会快速扫一遍改动文件重点看有没有不符合项目规范的地方。RooCode界面上有展示此次所有改动的文件列表点开就是一个diff视图我就在那里逐文件检查非常直观。5.4 一个不算小的坑CSV中文乱码问题这个需求里有个经典细节值得单独说CSV文件默认用Excel打开时中文很容易乱码。Agent写第一版导出代码时没处理这个问题因为从纯技术角度UTF-8编码的CSV在浏览器预览里没问题但用户下载后用Excel打开就乱。我在验收时发现问题让它修复——正确方案是在CSV文件开头加一个UTF-8 BOM头\uFEFFExcel才能正确识别编码。这个例子恰好说明为什么AI编程不能完全脱离人工审查。AI的很多知识是通用的但具体业务场景里的用户习惯、周边工具行为差异需要人提供输入。而RooCode的工作流刚好支持这种发现问题-反馈给Agent-它修复的闭环而不是你得自己改完再回去告诉它别犯了。6. 踩坑实录与提效心得我替你们趟过的几条河最后这部分分享一些我长期使用RooCode之后沉淀下来的经验每条都是真金白银换来的教训。6.1 第一个坑任务写得太泛AI自由发挥方向跑偏刚开始用RooCode时我喜欢用帮我优化一下登录页的代码这种极度模糊的描述。结果它花了半天时间把路由结构重构了一遍虽然代码本身没问题但根本不是我要的。后来我学会了一个套路写任务描述时把不做什么也写进去。比如优化登录页代码不要改路由和state结构只改动样式和交互细节约束到位了它的改动就锁定在合理范围内。6.2 第二个坑一个任务里同时塞了多个项目阶段如果你让RooCode先看看代码然后重构再写测试最后发个版本它会尽量按顺序做完但很容易在中后期忽略最初的目标或者第一阶段的产物还没验证就进入下一阶段。更科学的做法是拆成先后依赖的几个任务先分析并给出重构方案检查方案再按方案实施重构最后给重构后的代码补单测。每阶段都有人工确认点质量可控得多。6.3 第三个坑忽略Checkpoint回滚功能任务跑挂了只能手动还原有次我让它重构一个核心模块的公共组件它执行到一半因为一个边界情况没处理好写出的代码导致组件库报错。我当时不知道Checkpoint回滚的存在只好手动把改动一个一个撤销浪费了不少时间。后来我弄清楚了RooCode的检查点机制它在每个关键操作前会自动拍照存档界面上有一个恢复按钮选择某个时间点的快照就能把文件恢复到那个时候的状态。现在每次跑大任务我会盯一眼它的检查点有没有正常生成确认有后悔药保底才放心让它继续。6.4 如何有效控制API费用RooCode虽然开源免费但调模型API的费用得自己掏。我一开始让它跑一个大型重构任务一次就烧掉好几美刀的token心疼得不行。后来摸索出几条省钱经验能用Architect模式先出方案就不要直接Code模式开干方案阶段token消耗远低于全量代码改写。任务拆细每个会话做完一个功能就结束避免长上下文累积导致单条消息token暴涨。日常小任务用便宜的模型跑只有复杂任务才切换到顶级模型。RooCode支持在同一次会话中切换模型这个灵活性真的省钱。每次会话结束后让它总结这次任务的产出和下一步建议这能让下次会话从一个高密度起点开始减少重复阅读代码的消耗。6.5 团队协作把.roorules纳入版本控制我在团队内部推RooCode时最重要的一件事就是把.roorules文件提交到代码仓库让每个同事拉下代码的时候就自带规范。这样团队成员的AI工具产出的代码风格高度统一不会出现你的AI喜欢写箭头函数、他的AI喜欢写function这种混乱局面。最好再维护一个docs/ai-workflow.md的团队文档把常用任务类型的标准描述模板存下来。比如修复Bug类任务描述模板新增接口类任务描述模板前端页面开发类任务描述模板。这些模板经过实践检验表述清晰、约束到位新同事上手直接套用比从零摸索写任务描述快得多。6.6 未来的可能性MCP让它连接外部工具RooCode支持MCPModel Context Protocol协议这意味着你能通过它连接外部数据源和工具——比如让AI读取你公司的接口文档、连接数据库看表结构、调用内部组件库的文档查询组件用法。我目前只是接入了极少数的MCP服务已经在做一些自动查表结构生成CRUD接口之类的探索效率提升非常明显。如果你有志于深挖RooCode的潜力MCP是一个值得研究的进阶方向。从我个人的角度看RooCode这类AI编程工具的使用门槛并不在工具本身而在于你愿不愿意花时间把项目上下文、业务规则、团队规范喂给它让它真正成为团队里的一个提效角色。工具永远只是工具带着明确的目标和好的工作方法去用它它的价值才会完全释放出来。希望这篇入门经验能帮你少走一些弯路快速进入人机协(fa)作的舒服区。
返回列表