1. 项目概述当AI开发助手“变身”成腌黄瓜瑞克如果你和我一样经常用Gemini CLI来辅助写代码、重构模块或者搭建新项目那你肯定遇到过这种情况你给AI一个复杂的任务它吭哧吭哧写了一大堆结果跑起来一堆bug或者代码风格乱七八糟你不得不再三给它提要求来回拉扯效率低下。这感觉就像在教一个聪明但有点马虎的实习生你得时刻盯着反复纠正。今天要聊的这个项目galz10/pickle-rick-extension就是为了彻底解决这个问题。它不是一个普通的插件而是一个“角色扮演”模组能把你的Gemini CLI变成一个名叫“腌黄瓜瑞克”的AI工程师。这个名字来源于动画《瑞克和莫蒂》剧中的天才科学家瑞克把自己变成了一根腌黄瓜却依然能用逆天的智慧解决所有问题。这个插件赋予AI的就是这种“腌黄瓜状态”——尽管形态受限在CLI里但能力爆表且极度自负、挑剔对低质量的“AI垃圾代码”零容忍。简单来说它通过一套强制性的、循环迭代的工程流程把一次性的、可能不完美的AI交互变成了一个可以“自动驾驶”的、持续改进的开发循环。你只需要给它一个清晰的任务描述比如“重构用户认证模块并确保所有单元测试通过”它就会自己分析代码库、制定计划、分步实施、运行测试、重构优化直到任务完成或达到预设的迭代上限。整个过程AI会以“瑞克”的口吻和你交流充满嘲讽但执行力极强它会把工作拆解成工单生成详细的设计文档并且每一次迭代都能看到上一次的成果在此基础上进行优化。这非常适合那些目标明确、但过程繁琐的编码任务比如为一个新功能添加完整的CRUD接口和测试或者将一堆意大利面条式的代码重构成清晰的服务层。当然它也不是万能的对于需要大量主观审美判断比如UI设计或者探索性极强、成功标准模糊的任务可能就不太合适。它的核心价值在于将AI从一个需要你不断微调提示词的“代码生成器”升级为一个能遵循严格软件工程生命周期、自主推进项目的“初级技术负责人”。2. 核心原理与设计思路拆解2.1 “拉尔夫·维格姆”技术一切循环的起点要理解Pickle Rick必须先提它的理论基础“拉尔夫·维格姆”技术。这个有点滑稽的名字背后是一个极其简单的洞见“拉尔夫就是一个Bash循环”。其核心思想是与其手动一次次地给AI模型相同的提示不如写一个简单的Bash脚本自动将AI的输出作为下一次的输入形成一个自我迭代的循环。原始的“拉尔夫”循环可能长这样while true; do # 1. 将任务描述喂给AI # 2. AI输出代码或解决方案 # 3. 将AI的输出保存到文件 # 4. 将“基于当前文件状态继续完成任务”的提示再次喂给AI # 5. 重复直到手动中断或检测到完成信号 done这个循环的威力在于AI在每次迭代中都能“看到”自己上一轮修改后的代码文件通过读取文件内容从而可以基于一个不断演进的工作上下文进行下一步操作而不是每次都从零开始。2.2 Pickle Rick的进化从外部循环到内部钩子Pickle Rick插件没有采用外部Bash脚本来驱动循环而是做了一个更优雅的集成利用Gemini CLI的钩子机制在AI会话内部创建了一个自反循环。这是关键的设计差异。外部循环Bash是你作为用户在控制循环的启停和每次迭代的输入。而Pickle Rick的“内部循环”则是这样的用户发起你输入一次命令/pickle “重构登录逻辑”。AI工作Gemini CLI启动加载Pickle Rick人格和技能开始分析、计划、编码。尝试退出当AI认为当前步骤完成准备结束会话时会触发一个“退出”信号。钩子拦截Pickle Rick插件注册的AfterAgent钩子位于hooks/handlers/stop-hook.js捕获了这个退出信号。循环再造钩子阻止了会话的正常退出并将最初的那个/pickle命令重新喂给AI同时附带上一个更新了的会话上下文包含了本轮已修改的文件列表、git状态等。重复过程AI再次启动但这次它看到的是一个已经部分完成的项目状态于是它基于此继续工作。这个设计的精妙之处在于用户体验无缝你只需要发起一次命令然后就可以泡杯茶等着或者去处理别的事情。循环在后台自动进行无需你手动敲击“继续”。上下文持续因为循环发生在同一个Gemini CLI会话实例内通过钩子重置AI能够保持对之前所有思考和决策的部分记忆虽然每次迭代模型本身会重置但工作成果已固化在文件系统中。专注度提升原始任务提示在每次迭代中都被重新注入确保了AI不会在迭代过程中偏离核心目标。2.3 人格与技能系统不只是循环更是专业流程如果只有循环那它只是一个自动化的代码生成器。Pickle Rick的核心附加值是它强制注入的“腌黄瓜瑞克”人格和与之配套的工程技能系统。人格的作用这个人格设定不仅仅是好玩。它被精心设计为“傲慢、挑剔、追求极致”。在提示工程中人格是引导模型行为的有力工具。一个“谦逊的助手”可能会对模糊的需求妥协产出“差不多就行”的代码。而“腌黄瓜瑞克”则会嗤之以鼻要求绝对清晰的PRD产品需求文档鄙视任何“杰瑞式的工作”指动画中瑞克女婿杰瑞的平庸并坚持“上帝模式”的编码标准——即最高效、最健壮、最优雅的解决方案。这实际上是在利用模型的角色扮演能力来逼近一个资深、严苛的工程师的决策过程。技能系统的运作插件定义了一系列技能Skills如prd-drafter,ticket-manager,code-researcher,implementation-planner等。这些技能本质上是高度特化的系统提示System Prompts和工具使用指南的集合。AI不会一次性激活所有技能而是在不同的工程阶段激活对应的技能。例如在“研究”阶段code-researcher技能被激活AI会收到指令“现在你是一个代码研究员你的任务是深入分析src/auth/目录下的所有文件绘制出数据流图识别出设计模式和潜在的缺陷。” 这比一个通用的“请分析代码”指令要有效得多因为它框定了AI的思考框架和输出格式。整个流程被固化为一个严格的软件工程生命周期PRD → 分解 → 研究 → 计划 → 实施 → 重构。AI被强制要求按这个流程走每个阶段都有对应的技能和产出物如Markdown文档、工单列表、架构图描述。这极大地提升了产出的结构性和可预测性。注意这种强流程约束是一把双刃剑。对于非常规或探索性任务它可能显得僵化阻碍创造性解决方案的产生。但对于大多数常见的、模式化的开发任务增删改查、模块重构、测试覆盖它能提供远超自由发挥的稳定性和质量。3. 环境准备与核心配置详解在迫不及待想运行/pickle之前有几个关键的配置步骤必须完成。很多初次使用者遇到的问题十有八九都出在配置上。3.1 前置条件检查版本与依赖首先确保你的基础环境符合要求Gemini CLI版本必须 0.25.0-preview.0。这个版本引入了对扩展Extensions、钩子Hooks和技能Skills的稳定支持。你可以通过gemini --version来检查。如果版本过低需要按照官方指南更新。Node.js插件的钩子逻辑是用JavaScript/TypeScript写的运行需要Node.js环境。建议使用LTS版本如18.x, 20.x。3.2 安装Pickle Rick扩展安装过程很简单一行命令gemini extensions install https://github.com/galz10/pickle-rick-extension这条命令会从GitHub仓库拉取扩展并将其安装到你的本地Gemini扩展目录通常是~/.gemini/extensions/下。安装成功后你应该能在Gemini CLI中使用/pickle等新命令。3.3 关键配置启用钩子、技能与包含目录这是最核心也最容易出错的一步。你需要修改Gemini CLI的配置文件通常是~/.gemini/settings.json。如果文件不存在就创建它。配置项一启用实验性功能Pickle Rick依赖的“钩子”和“技能”在写作时仍属于实验性功能需要手动开启。{ tools: { enableHooks: true }, experimental: { skills: true } }enableHooks: true允许插件注册钩子如拦截退出的AfterAgent钩子这是实现内部循环的基石。skills: true启用技能系统让AI能够加载和使用prd-drafter等专业化指令模块。配置项二包含扩展数据目录极易忽略这是很多用户踩坑的地方。Pickle Rick在运行过程中会在其扩展目录下~/.gemini/extensions/pickle-rick/sessions/创建会话文件夹里面存放着PRD、研究笔记、工单、计划等所有中间产物。AI需要在每次迭代中读取这些文件以了解项目进度。如果这个目录不在Gemini的“可读”范围内AI就会变成“瞎子”——它不知道上一轮自己写了什么循环就失去了意义。因此你必须把这个目录添加到includeDirectories配置中。{ context: { includeDirectories: [ ~/.gemini/extensions/pickle-rick ] } }实操心得路径中的~代表用户家目录。确保这个路径是绝对路径且可访问。你也可以使用绝对路径如/Users/yourusername/.gemini/extensions/pickle-rick。配置完成后最好通过gemini -s进入shell模式然后尝试ls ~/.gemini/extensions/pickle-rick来验证路径是否正确。完整的settings.json示例 将上述配置合并一个完整的最小化配置如下{ tools: { enableHooks: true }, experimental: { skills: true }, context: { includeDirectories: [~/.gemini/extensions/pickle-rick] } }3.4 安全配置沙盒与工具限制强烈建议Pickle Rick被设计为可以执行Shell命令、读写文件、运行Git操作。虽然它内置了一些安全护栏比如在修改文件前会询问但在一个不熟悉的新项目上全速运行它仍然存在风险。推荐做法在沙盒中运行最安全的方式是在一个Docker容器或虚拟机中运行Gemini CLI和Pickle Rick。这样即使AI行为异常也不会影响到你的宿主机。如果你使用Docker可以这样启动一个交互式容器docker run -it --rm -v $(pwd):/workspace -v ~/.gemini:/root/.gemini -w /workspace your-gemini-image gemini -s -y这里-v $(pwd):/workspace将当前目录挂载到容器内-v ~/.gemini:/root/.gemini将你的Gemini配置和扩展包括Pickle Rick挂载进去-y参数启用“YOLO模式”自动批准所有工具执行在沙盒中这很安全。工具限制策略即使不在沙盒中你也可以在项目级的.gemini/settings.json中精细控制AI能使用的工具。例如为了防止它不小心把实验分支推送到远程仓库你可以禁止git push{ tools: { exclude: [run_shell_command(git push), run_shell_command(rm -rf)], allowed: [ run_shell_command(git add), run_shell_command(git commit), run_shell_command(git diff), run_shell_command(npm test), run_shell_command(python -m pytest) ] } }exclude列表是黑名单优先级更高。allowed列表是白名单如果设置了白名单则只有列表内的命令可以被执行。对于生产环境或重要项目使用白名单是最稳妥的。4. 完整工作流程与核心命令实战现在假设我们已经在一个安全的测试项目目录中完成了所有配置。让我们通过一个具体的例子来完整走一遍Pickle Rick的工作流程。我们的任务是“为这个简单的Express.js API添加用户注册和登录功能使用JWT进行认证并编写完整的单元测试。”4.1 阶段一交互式PRD制定可选但推荐在直接投入循环之前最好先让AI帮你把需求理清楚。使用/pickle-prd命令/pickle-prd “为当前Express.js API添加用户注册和登录功能使用JWT令牌进行认证并编写完整的单元测试。”这个命令不会立即开始编码循环而是会启动一个交互式会话。AI会以“腌黄瓜瑞克”的身份向你提出一系列问题来澄清需求例如“现有的用户模型数据结构是什么需要新增哪些字段如passwordHash,emailVerified”“JWT令牌的密钥你打算如何管理环境变量密钥管理服务”“注册时需要邮箱验证吗登录失败多少次后需要锁定账户”“单元测试要覆盖哪些边界情况无效密码、重复邮箱、令牌过期”你需要回答这些问题。这个过程结束后AI会生成一份结构化的PRD文档保存在sessions/目录下并询问你是否要将此任务加入“腌黄瓜罐” (/add-to-pickle-jar) 稍后执行或者直接开始。实操心得花时间做好PRD阶段能极大提升后续循环的效率和质量。一份模糊的需求会导致AI在循环中不断猜测可能产生偏离预期的代码。清晰的PRD等于给了AI一张精确的图纸。4.2 阶段二启动主循环如果你已经通过PRD阶段明确了需求或者你对任务非常清晰可以直接启动主循环/pickle “基于PRD-20241027-001实现用户认证模块。” --completion-promise “所有端点测试通过覆盖率90%”或者更简单地/pickle “实现用户注册和登录功能使用JWT写测试。” --max-iterations 10 --max-time 30关键参数解析--completion-promise “TEXT”这是循环停止的“信号”。AI在认为任务完成时需要在输出中包含promiseTEXT/promise这个特定标签。例如你设置--completion-promise “DONE”当AI输出“...重构完成。 DONE ”时循环才会停止。这是控制循环何时结束的最精确方式建议与可验证的客观标准结合使用如“所有测试通过”。--max-iterations 5安全阀。防止AI陷入死循环。默认5次对于中等复杂度任务通常足够。--max-time 60总时间限制分钟。防止任务消耗过多时间。--worker-timeout 1200单次迭代中每个“工人”执行具体子任务的AI实例的运行时间限制秒。防止单个步骤卡住。4.3 阶段三观察与干预命令发出后Pickle Rick就接管了。你会在终端看到类似以下的输出流[Pickle Rick] 启动。任务实现用户认证模块。迭代 1/5。 [技能加载] prd-drafter - ticket-manager。 [工单创建] TICKET-001: 分析现有项目结构。 [工单创建] TICKET-002: 设计User模型和数据库迁移。 [工单创建] TICKET-003: 实现/api/auth/register端点。 ... [执行] 运行 npm test... 测试失败缺少jsonwebtoken包。 [行动] 执行 npm install jsonwebtoken。 [执行] 再次运行 npm test... 通过3项失败1项。 [分析] 失败原因密码哈希比较逻辑错误。正在修复...你可以看到AI在自动地创建工单、执行命令、分析结果、修复问题。整个过程中它会以瑞克那种不耐烦但又专业的口吻进行“汇报”。干预命令/eat-pickle立即终止当前循环。所有中间文件会保留在会话目录中。/add-to-pickle-jar将当前进行中的任务保存起来以后可以通过/pickle-jar-open统一执行罐子里的所有任务。这适合被打断时保存现场。/pickle --resume如果你退出了CLI可以用这个命令恢复上一个或指定路径的会话。4.4 阶段四审查产出循环结束后无论是成功完成还是达到限制所有的工作产物都保存在~/.gemini/extensions/pickle-rick/sessions/session-name/目录下。典型的目录结构如下sessions/auth-module-20241027/ ├── prd.md # 产品需求文档 ├── tickets/ # 工单目录 │ ├── TICKET-001-analysis.md │ ├── TICKET-002-model-design.md │ └── ... ├── research/ # 研究笔记 │ └── existing-codebase-analysis.md ├── plans/ # 技术设计文档 │ └── implementation-plan-v1.md └── src/ # AI生成的或修改的源代码 ├── models/ │ └── user.js ├── routes/ │ └── auth.js └── tests/ └── auth.test.js你应该仔细审查src/下的代码特别是业务逻辑和测试。虽然Pickle Rick追求高质量但AI生成的代码仍可能存在边界情况处理不当或理解偏差。永远不要盲目信任AI的输出将其视为一个强大的初级工程师的初稿而你则是负责最终审查的资深工程师。5. 高级技巧与深度配置解析当你熟悉了基本流程后下面这些技巧能帮助你更好地驾驭Pickle Rick应对更复杂的场景。5.1 利用会话目录进行“热修改”和调试会话目录不仅是存档还是一个强大的调试和引导工具。如果AI在某个迭代中走偏了比如研究文档里得出了一个错误结论你可以直接去修改会话目录下的Markdown文件。例如你发现research/existing-codebase-analysis.md里对数据库连接池的配置理解有误。你可以在AI进入下一轮迭代前手动编辑这个文件修正描述。当下一轮迭代开始时AI会读取这个修正后的研究文件从而基于正确的前提进行规划。这相当于在AI的“思考过程”中插入了一个人工校正点对于复杂或遗留系统改造项目非常有用。5.2 自定义技能与提示工程Pickle Rick的技能定义在skills/目录下每个技能都是一个.md文件里面包含了详细的系统提示和操作指南。如果你对某个特定环节比如代码审查有特别的要求可以修改对应的技能文件。例如你觉得默认的ruthless-refactorer技能对代码格式要求还不够严格你可以编辑skills/ruthless-refactorer.md在末尾加上你的团队规范... 在完成所有功能后必须额外执行以下操作 1. 运行 prettier --write . 统一代码格式。 2. 使用 eslint . --fix 修复所有可自动修复的代码风格问题。 3. 确保所有函数、类的JSDoc注释完整。注意修改扩展文件后需要重启Gemini CLI会话才能生效。这是一种高级用法需要对提示工程有一定了解不当的修改可能导致技能失效或行为异常。5.3 管理并行任务与“莫蒂”实例项目提到了一个内部命令/send-to-morty。这暗示了Pickle Rick架构可能支持一种“管理者-工作者”模式。主“瑞克”会话负责协调和规划而具体的、耗时的子任务比如运行一整套端到端测试或处理一个大型文件可以被派发给一个或多个“莫蒂”工作者实例去并行执行。虽然当前公开版本的用法文档没有详细展开这一点但这为我们指明了扩展方向。对于超大型项目你可以设想这样的工作流一个主Pickle Rick循环负责架构分解然后将多个独立的子模块开发任务通过类似机制并行化极大缩短整体交付时间。这需要更深入的插件二次开发。5.4 性能与成本考量Pickle Rick的循环意味着多次调用AI模型。每次迭代都可能包含多次工具调用运行命令、读写文件和长上下文推理。这会带来两方面影响Token消耗消耗量会显著高于单次问答。尤其是在代码库很大、研究阶段需要读入大量文件时。你需要关注你的API使用成本。插件计划中的“Token会计”功能正是为了解决这个问题。执行时间虽然AI思考很快但等待外部命令执行如npm install,docker build会占用大量时间。合理设置--max-time和--worker-timeout很重要。对于I/O密集型的任务循环可能会在等待中耗掉大量时间配额。优化建议对于已知依赖安装耗时的项目可以在启动Pickle Rick之前手动安装好核心依赖。或者在PRD阶段就明确告诉AI“项目依赖已就绪无需执行npm install”从而避免每个迭代都重复安装。6. 常见问题排查与实战避坑指南即使配置正确在实际使用中也可能遇到各种问题。下面是我在多次使用中总结出的常见“坑”及其解决方案。6.1 循环不启动或立即退出症状输入/pickle “任务”后AI简单回应一句就退出了没有进入循环。检查1钩子是否启用确认settings.json中enableHooks: true已设置并且没有语法错误。可以尝试在Gemini shell中直接输入/pickle看是否有帮助信息弹出如果没有说明扩展可能未正确安装或加载。检查2技能是否启用确认skills: true已设置。检查3会话目录权限确保Gemini进程有权限在~/.gemini/extensions/pickle-rick/sessions/下创建和写入文件。在Linux/macOS上可以检查目录所有权和权限。6.2 AI“看不见”自己上一轮的工作症状每次迭代AI都像是从头开始不提及之前创建的文件或修改。根本原因includeDirectories配置错误或未生效。这是最常见的问题。解决方案绝对确认settings.json中的路径是正确的。可以用realpath ~/.gemini/extensions/pickle-rick获取绝对路径并填入。重启你的Gemini CLI会话。配置更改需要重启才能加载。在Gemini shell中尝试让AI列出该目录输入ls ~/.gemini/extensions/pickle-rick/sessions/看AI是否能正确读取。如果不能说明路径配置仍有问题。6.3 循环停不下来无限循环症状AI不断迭代即使任务看似已完成也不输出promise标签。原因1完成承诺Promise太模糊。如果你设置--completion-promise “完成”AI可能认为“代码写完了”就是“完成”而忽略了测试。应该设置为可客观验证的标准如--completion-promise “所有单元测试和集成测试通过”。原因2AI卡在某个错误上。例如一个测试始终无法通过AI每次迭代都尝试不同方法修复但都失败。它会一直循环直到达到max-iterations。应对使用/eat-pickle手动中断。检查最新的会话日志和代码看AI卡在了哪里。手动修复那个问题然后使用/pickle --resume恢复循环AI可能会基于你修复后的状态继续前进。在任务描述中更精确地定义“完成”的边界条件。6.4 AI执行了危险操作症状AI试图运行rm -rf /或git push --force等危险命令。预防如前所述务必在沙盒中运行或配置严格的tools.allowed白名单。补救如果已经发生立即中断进程。如果使用了Git可以通过git reflog和git reset尝试恢复。如果删除了文件在沙盒外的影响可能较小否则需要从备份恢复。教训永远不要在有未提交重要更改或非沙盒环境下对AI授予过高权限。将git push、rm、format等命令加入exclude列表是基本安全准则。6.5 性能缓慢迭代间隔长症状每次迭代之间等待时间很长。分析用top或任务管理器观察。慢通常不是因为AI思考慢而是因为外部命令执行如安装依赖、编译项目、运行大量测试。网络延迟如果AI需要调用网络API非本地模型时。大型上下文如果项目文件非常多每次迭代AI都要重新读取大量文件到上下文会拖慢速度并消耗大量Token。优化在.geminiignore文件中忽略node_modules/,build/,.git/等无需AI分析的大型目录。将耗时长的准备工作如安装依赖、构建镜像在循环开始前手动完成。考虑将大项目拆分成更小的、边界清晰的子任务分别用Pickle Rick处理。Pickle Rick扩展代表了一种非常前沿的AI应用模式将大模型从一个被动的问答工具转变为一个遵循严格流程、具备“人格”驱动、能够自主迭代的主动执行体。它把“提示工程”的复杂度封装进了一个精心设计的系统里让开发者能够以更高的抽象层级来使用AI——你不再需要微调每一个编码步骤的指令而是定义好工程目标和标准然后让一个“虚拟工程师”去负责执行。当然它目前还不是银弹。它对任务定义的清晰度要求极高在探索性、创造性任务上可能显得笨拙且运行成本和风险需要谨慎管理。但毫无疑问对于标准化程度高的开发任务写CRUD、加测试、修bug、代码重构它能带来效率的质变。我个人最欣赏的一点是它强制产出的PRD、研究文档和工单即使最终代码需要调整这些中间产物本身也具有极大的文档价值让项目的思考过程变得可追溯、可审计。最后一个小技巧刚开始使用时不妨用一个你非常熟悉的、代码量小的玩具项目来练手。这样你可以清晰地观察Pickle Rick的每一个决策和操作快速理解它的行为模式并建立起对它的“信任感”。当你看到它真的能一步步把一个模糊的需求变成可运行、有测试的代码时那种感觉确实有点“Wubba Lubba Dub-Dub”的味道了。