1. 项目概述一个为开发者准备的“AI智能体食谱”仓库如果你和我一样每天都在和代码打交道同时也在积极拥抱AI编程助手比如Cursor、Claude Code、Aider那你肯定遇到过这样的时刻面对一个复杂的任务比如给一个大型PR做全面的代码审查或者把一堆JavaScript文件迁移到TypeScript你明知道AI能帮上大忙却不知道该怎么向它“点菜”。你需要在聊天框里绞尽脑汁地组织语言描述背景、设定角色、明确步骤、给出示例……这个过程本身就很耗时而且每次都要重新来一遍。最近我发现了一个名为Sagargupta16/agent-recipes的GitHub仓库它完美地解决了这个痛点。你可以把它理解为一个“AI智能体工作流食谱”合集。这个社区驱动的项目收集了大量开箱即用的、针对真实世界开发任务的AI提示词模板。每一个“食谱”都是一个自包含的、结构化的提示词你可以直接复制粘贴到Claude Code、Cursor或者任何你喜欢的AI编程助手中它就能立刻化身为一个专业的代码审查员、测试生成器或者架构顾问。这个项目覆盖了开发者日常工作的核心场景代码审查、测试、迁移、文档、安全和DevOps。它不是另一个教你“如何与AI对话”的理论指南而是一个实实在在的工具箱里面的每一件工具都经过设计能让你把AI的潜力更高效、更精准地应用到实际开发流程里。无论你是想提升代码质量、加速项目迁移还是想自动化那些繁琐的文档工作这里都可能有一份现成的“食谱”等着你下锅。2. 核心设计思路为什么“食谱”模式是高效的在深入具体“食谱”之前我们先拆解一下这个项目的设计哲学。它之所以有用是因为它精准地捕捉到了开发者使用AI助手时的几个关键瓶颈并通过“食谱”模式提供了优雅的解决方案。2.1 解决“提示词工程”的重复劳动对于复杂的任务一个有效的AI交互往往不是一两句话能完成的。它需要上下文设定、角色扮演、步骤分解、格式要求和示例输出。例如让AI进行代码审查你需要告诉它“假设你是一个资深的后端工程师专注于系统安全和性能。请以表格形式从安全性、性能、可维护性、代码风格四个维度逐行审查下面这段代码。对于每个发现的问题请标明严重程度高/中/低、具体行号、问题描述和修改建议。”每次执行类似任务都手动输入这么一大段提示词是不现实的。agent-recipes将这些精心设计的、针对特定任务的完整提示词固化下来形成“食谱”。这本质上是一种提示词模板的复用将开发者从重复的“提示词工程”中解放出来直接进入执行阶段。2.2 提供标准化、可预期的输出很多开发者抱怨AI的输出“不稳定”有时很好有时又答非所问。这种不稳定性部分源于输入提示词的模糊和多变。“食谱”通过标准化输入极大地提高了输出的可预期性。每一份食谱都经过了设计或社区贡献者的实践检验明确了AI的角色、任务边界和输出格式。例如PR Review食谱会明确要求AI以特定结构如分点列表、表格来呈现问题这使得生成的审查意见立刻就能整合到团队的协作流程中无需二次加工。2.3 降低使用门槛赋能所有开发者不是每个开发者都有兴趣或时间去深入研究如何撰写最优提示词。agent-recipes作为一个社区项目汇集了众人的智慧。一个刚入行的工程师可以直接使用“安全审计”食谱让AI辅助检查自己代码中的潜在漏洞这相当于瞬间获得了一位安全专家的视角。它降低了高级开发实践如架构评审、性能剖析的门槛让AI成为团队中一个普惠性的能力放大器。2.4 模块化与可组合性项目采用目录分类的方式组织食谱每个食谱都是一个独立的Markdown文件。这种模块化设计带来了极大的灵活性。你可以直接使用找到对应场景复制粘贴立即生效。混合使用在处理一个大型功能开发时你可以先后使用“架构评审”、“生成单元测试”、“API文档生成”等多个食谱形成一个小型的工作流。自定义修改每个食谱都包含“自定义”部分你可以基于基础模板融入自己团队的编码规范、技术栈特点打造专属的强化版提示词。这种设计思路让项目不仅仅是一个静态的列表而是一个可生长、可适配的生态系统的基础。3. 六大核心“食谱”类别深度解析与实操要点仓库的食谱分为六大类基本涵盖了一个现代软件开发生命周期的关键环节。我们逐一深入看看每个类别下有哪些“硬菜”以及使用时需要注意什么。3.1 代码审查从“看代码”到“系统性审计”代码审查是保证软件质量的核心实践但人工审查耗时耗力且容易遗漏细节。这里的食谱将AI定位为你的第一轮审查员或专家顾问。PR ReviewPull Request审查这是最常用的食谱之一。它不只是检查语法错误而是进行安全性、性能、代码风格和可维护性的综合检查。我实测时它会提示AI关注诸如硬编码凭证、可能的SQL注入点、循环内的低效操作、不符合团队约定的命名等问题。注意AI审查不能替代人工审查。它擅长发现模式化问题和潜在风险但对于业务逻辑的合理性、架构决策的优劣仍需资深开发者把关。最好将AI审查意见作为人工审查的补充清单。Architecture Review架构评审这个食谱用于更高层次的审视。你可以喂给AI整个模块或服务的代码结构让它分析模块间的耦合度、依赖关系的合理性、是否符合分层架构原则等。对于重构或新项目初期设计评审很有帮助。Dependency Audit依赖审计自动检查package.json、pom.xml或requirements.txt等文件识别过时的、有已知安全漏洞的或可能已不再使用的依赖包。这能帮你将依赖管理这项日常工作自动化。Performance Review性能审查针对性能敏感型代码块如复杂算法、数据库查询、循环让AI分析时间复杂度、内存使用情况并提出优化建议比如建议使用更高效的数据结构或缓存策略。实操要点使用代码审查类食谱时务必提供足够的上下文。除了要审查的代码差异diff最好能附带相关的接口定义、配置文件片段。告诉AI项目所用的主要框架和语言版本能让它的建议更精准。3.2 测试填补测试覆盖率的空白编写测试尤其是全面的单元测试和E2E测试是另一项繁重但至关重要的工作。这类食谱旨在让AI成为你的测试协作者。Generate Unit Tests生成单元测试针对一个具体的函数或类AI可以快速生成覆盖各种输入正常值、边界值、异常值的测试用例。这对于为遗留代码补充测试或者在新开发中快速搭建测试骨架非常有效。心得AI生成的测试用例有时会过于“理想化”或遗漏某些复杂的模拟Mock。你需要检查生成的测试确保它正确地模拟了外部依赖如数据库、API调用并且断言Assert了正确的行为而不仅仅是调用了函数。E2E Test Writer端到端测试编写器根据用户故事或功能描述生成模拟用户完整操作流程的端到端测试脚本例如使用Cypress或Playwright。这能加速E2E测试套件的建设。Coverage Gap Finder覆盖率缺口查找器结合现有的测试代码和业务代码让AI分析哪些代码分支、边界条件还没有被测试覆盖到并给出编写对应测试用例的建议。3.3 迁移自动化版本升级与范式转换技术栈的升级和代码范式的迁移如从JavaScript到TypeScript从React类组件到函数式组件Hooks是令人头痛的大工程。这类食谱提供了自动化的转换方案。JavaScript to TypeScript这不仅仅是添加.ts后缀。一份好的食谱会指导AI如何推断变量类型、定义接口和类型、处理any类型并添加必要的类型声明文件.d.ts引用。React Class to Hooks将基于类的React组件及其生命周期方法componentDidMount,setState等转换为使用函数式组件和useState,useEffect等Hooks。AI需要妥善处理状态逻辑的迁移和副作用的管理。CJS to ESM将CommonJS的require/module.exports语法转换为ECMAScript Modules的import/export语法。需要注意处理默认导出和命名导出的区别。重要警告对于任何自动化迁移都必须进行彻底的人工复查和测试AI可能无法理解某些复杂的动态依赖或特定库的怪异用法。迁移后务必运行完整的测试套件并仔细检查核心业务逻辑是否被正确转换。建议先在单独的分支上对非关键模块进行试验。3.4 文档让文档与代码同步“代码即文档”是理想但良好的外部文档如README、API文档对于项目协作和上手至关重要。这类食谱能基于代码现状自动生成文档草稿。README Generator分析项目结构、主入口文件、配置文件如package.json和关键的文档注释生成一个结构化的README.md包含项目描述、安装步骤、使用示例、配置说明等章节。API Docs Generator扫描代码中的路由定义、控制器、请求/响应模型生成符合OpenAPISwagger规范的API文档。这能极大减轻后端开发者的文档负担。Changelog Writer解析Git提交历史将格式化的提交信息如遵循Conventional Commits规范归纳整理成版本更新日志CHANGELOG。实操技巧生成的文档是一个优秀的起点但缺乏“灵魂”。你需要为其补充项目背景、设计决策的缘由、更丰富的使用场景示例以及故障排查指南。把AI生成的文档看作一个需要你润色和丰富的初稿。3.5 安全将安全左移融入开发流程安全不再是事后的渗透测试而应贯穿开发始终。这些食谱帮助开发者在编写代码时就引入安全思维。Secret Scanner密钥扫描器在代码库中搜索可能硬编码的密码、API密钥、令牌、私钥等敏感信息。正则表达式是基础但AI能结合上下文更好地判断一个字符串是否是真正的密钥而非普通常量。OWASP Top 10 Audit对照OWASP Top 10十大Web应用安全风险如注入、失效的身份认证、敏感信息泄露等检查代码中是否存在相应的漏洞模式。Input Validation输入验证针对API端点检查其是否对用户输入进行了充分的验证和清理sanitization如果没有则建议添加相应的验证逻辑或库如Joi、validator.js。核心原则安全食谱的输出应被视为高风险警告。对于任何AI指出的潜在安全问题无论看起来多微小都必须由开发者进行人工确认和修复。切勿盲目信任AI的安全判断。3.6 DevOps基础设施即代码的AI助手从容器化到持续集成DevOps的配置工作同样可以借助AI来简化和优化。Dockerfile Generator根据项目类型Node.js, Python, Go等和依赖文件生成一个遵循最佳实践的多阶段构建Dockerfile以减小最终镜像体积。CI/CD Pipeline分析项目结构、测试脚本和构建工具生成GitHub Actions或GitLab CI的配置文件.yml包含典型的流水线阶段安装依赖、构建、测试、打包。Monitoring Setup为服务添加基础的健康检查端点、应用性能指标如使用Prometheus客户端和日志记录配置的建议。使用建议DevOps配置与具体的技术栈、云环境强相关。AI生成的配置是一个很好的模板但你必须根据自己团队的实际部署环境Kubernetes、AWS、Azure等和监控工具链Prometheus、Grafana、ELK等对其进行深度定制。4. 如何高效使用与集成从复制粘贴到工作流融合知道了有什么“菜”下一步就是学习如何“烹饪”。仓库提供了基本的使用方法但结合我的经验这里有更深入的集成策略。4.1 基础使用直接复制粘贴这是最直接的方式。以在Cursor中使用为例打开目标食谱的.md文件例如recipes/code-review/pr-review.md。复制## Prompt章节下的全部内容。在Cursor的AI聊天框中粘贴。紧接着在同一个对话中提供你需要审查的代码可以是整个文件也可以是Git diff片段。发送等待AI根据食谱的指令进行分析和输出。这种方式灵活适用于任何支持长文本输入的AI助手。4.2 进阶使用创建自定义指令/命令对于你高频使用的食谱将其保存为AI助手的自定义命令可以极大提升效率。在Claude Code中你可以将食谱文件复制到.claude/commands/目录下然后通过/command_name的方式快速调用。在Cursor中你可以利用Cursor的“自定义指令”功能。将食谱的提示词核心部分保存为一个指令并为其设置一个触发词如/review。之后在任何编辑器界面只需输入/reviewCursor就会自动将当前文件或选中代码块作为上下文并应用预设的审查提示词。在Aider中Aider本身通过.aider.conf.yml文件支持自定义指令你可以将复杂的提示词封装成一条条命令。我的工作流设置我为PR Review、Generate Unit Tests和JS to TS Migration这三个最常用的食谱在Cursor里创建了自定义指令。在收到PR通知后我只需在差异视图上运行/reviewAI的初步审查意见几乎瞬间就生成了为我的人工审查提供了清晰的焦点。4.3 组合使用构建自动化工作流脚本对于更复杂的场景你可以将多个食谱串联起来通过Shell脚本或简单的Node.js/Python脚本进行调度。例如一个针对新提交代码的自动化质量检查流水线可能包含以下步骤伪代码#!/bin/bash # 1. 获取最新的代码变更diff GIT_DIFF$(git diff HEAD~1 --name-only *.js *.ts *.py) # 2. 对每个变更的文件进行代码审查 for file in $GIT_DIFF; do cat recipes/code-review/pr-review.md | ai_assistant --input $(cat $file) --output review_${file}.md done # 3. 检查依赖更新 cat recipes/code-review/dependency-audit.md | ai_assistant --input $(cat package.json) --output deps_audit.md # 4. 汇总报告 # ... 将上述生成的报告汇总 ...当然这需要你的AI助手提供命令行接口或API。目前一些先进的AI编程工具正在向这个方向演进。5. 定制与贡献让“食谱”更适合你的厨房开源项目的生命力在于社区。agent-recipes的价值不仅在于使用更在于参与和定制。5.1 如何定制现有食谱每个食谱的## Customization部分是你的起点。通常你可以从以下几个方面入手修改调整审查标准在代码审查食谱中加入你自己团队的编码规范如命名约定、注释要求、特定的设计模式偏好。限定技术栈上下文在提示词开头明确指定项目使用的框架、库的版本。例如“本项目使用Next.js 14 App Router, TypeScript 5.x, 和Tailwind CSS。请基于此技术栈进行评估。”强化输出格式如果你希望AI的输出能直接导入到Jira、Linear或你的内部代码审查工具可以修改提示词要求它以特定的Markdown表格、JSON或YAML格式输出结果。增加示例在提示词的## Example部分加入一个你项目中典型的“好代码”和“坏代码”对比示例这能极大地引导AI理解你的质量要求。5.2 如何贡献一个新的食谱如果你设计出了一个能高效解决某个特定问题的AI工作流强烈建议你贡献出来。流程非常标准Fork仓库。确定分类你的食谱属于代码审查、测试、迁移、文档、安全还是DevOps或者有必要创建一个新类别遵循格式严格按照仓库规定的## Recipe Format编写你的.md文件。一个结构清晰的食谱包含清晰的名字、一句话描述、使用场景、完整的提示词、输入输出示例、自定义指南和相关的标签。提交PR确保你的食谱是自包含的、经过你自己测试有效的并且描述清晰。构思新食谱的方向框架特定例如“为Vue 3 Composition API组件生成单元测试”、“优化React Native应用的Bundle Size”。云服务特定例如“为AWS Lambda函数生成Serverless Framework配置”、“生成Terraform代码以部署到GCP”。代码质量深化例如“识别并重构过长的函数/类上帝对象”、“检查并建议应用设计模式如工厂、策略模式的时机”。6. 局限、风险与最佳实践理性看待AI协作者在热情拥抱这类工具的同时我们必须保持清醒的认知了解其局限并规避风险。6.1 当前的主要局限上下文长度限制所有AI模型都有输入令牌限制。对于非常大的代码库或复杂的PR你可能需要将代码分块输入这可能会影响AI对整体架构的理解。理解深度有限AI基于模式匹配和统计概率生成内容。它可能无法真正理解某些高度抽象的业务逻辑、复杂的算法意图或深层的设计权衡。它给出的“优化建议”有时在技术上是正确的但在业务上下文里是无效的。“幻觉”问题AI有时会自信地给出错误的信息或编造不存在的库、API。对于它生成的代码、建议的依赖包版本必须进行验证。静态分析局限目前的食谱大多基于对静态代码的分析。对于运行时行为、并发问题、内存泄漏等动态缺陷AI难以仅从代码表面发现。6.2 必须遵守的安全与合规红线这是最重要的一条。在使用任何AI工具处理代码时必须牢记绝不输入敏感信息永远不要将含有真实密钥、密码、用户数据、商业秘密或未公开API的代码提交给公共AI服务。即使你信任服务提供商也存在数据泄露风险。注意代码许可证向AI输入他人拥有版权的代码并让其生成衍生代码可能涉及许可证合规问题。确保你拥有输入代码的相应权利。审查所有生成内容AI生成的代码、配置、建议在并入生产代码库前必须经过严格的人工审查和测试。你不能将AI视为一个自动通过的审查环节。6.3 最佳实践总结定位为“副驾驶”而非“自动驾驶”AI是你的强大助手能处理繁琐、模式化的工作并激发灵感但决策权和最终责任在你手中。从小处着手逐步验证先在一个小的、非核心的模块或任务上试用食谱验证其效果和准确性再逐步推广到更重要的场景。提供高质量上下文你给AI的输入代码提示词质量直接决定其输出质量。确保提供的代码片段完整、相关并在提示词中清晰说明背景和要求。建立团队共识在团队内部分享有效的食谱并讨论AI辅助开发的边界和流程。例如规定AI生成的代码必须经过谁审查、哪些类型的任务适合用AI先行处理。持续迭代与反馈将使用AI过程中发现的错误或不足反馈给提示词修改本地自定义版本或者思考如何改进工作流程。这是一个需要你和AI共同进化的过程。Sagargupta16/agent-recipes这个项目为我们提供了一个极佳的起点它将散落的AI应用智慧系统化、产品化了。我个人在深度使用几个月后最大的体会是它节省的远不止是打字的时间更重要的是它帮我建立了一套更严谨、更全面的代码思考框架。每次使用那些审查食谱我都在被提醒去关注那些平时可能忽略的安全、性能细节。当然它不会取代深度思考和经验判断但它确实让高质量的开发实践变得更加触手可及更像是一种可以随时调用的“肌肉记忆”。如果你还没尝试过我建议就从你最头疼的那项重复性任务开始选一个对应的食谱看看这位不知疲倦的AI协作者能帮你做到哪一步。