1. 项目概述当AI编码助手遇上“西西弗斯”如果你和我一样深度依赖Cursor、Copilot这类AI编码助手那你一定经历过这种时刻满怀期待地让AI生成一段代码结果它给出的方案要么是过时的API要么是逻辑上存在明显缺陷的“幻觉”代码。你不得不手动修正然后再次提问AI可能又会固执地回到错误的思路上或者给出另一个同样有问题的版本。这个过程就像希腊神话里的西西弗斯一遍遍地把巨石推上山石头又一遍遍地滚落徒劳无功。Fguedes90/cursor-sisyphus这个项目就是为解决这个痛点而生。它的名字“Sisyphus”直指核心——终结这种无意义的重复劳动。本质上它是一个为Cursor编辑器设计的智能“代码审查与修正”工作流。它不是一个独立的插件而是一套精心设计的、可复现的Prompt提示词工程方案与操作流程。其核心思想是与其和AI进行低效的“问答式”拉锯不如建立一套系统性的“审查-反馈-迭代”机制引导AI进行自我修正最终产出符合你预期的高质量代码。这个项目适合所有使用Cursor进行开发的工程师无论你是前端、后端还是全栈。尤其是当你需要AI协助处理复杂逻辑、集成不熟悉的库或者单纯想提升AI生成代码的“一次通过率”时Sisyphus工作流能显著提升你的开发效率与代码质量。接下来我将彻底拆解这套工作流的每一个环节分享我是如何将它融入日常开发并从中提炼出关键技巧和避坑指南的。2. 核心设计思路从“问答”到“协同工作流”传统的AI编码交互模式是线性的、回合制的你提问AI回答你判断对错然后进入下一轮。Sisyphus的创新之处在于它将这个过程重构为一个带有反馈循环的“微型CI/CD管道”。其设计哲学基于以下几个关键认知2.1 承认AI的局限性并加以约束AI模型包括Cursor背后的强大模型本质上是基于概率的文本生成器。它“知道”很多代码但并不真正“理解”你的项目上下文、最新的API变更或特定的业务约束。Sisyphus工作流的第一步就是通过精确的Prompt为AI划定清晰的“工作区”和“禁区”。这不仅仅是告诉AI“做什么”更重要的是告诉它“按照什么标准来做”以及“绝对不要做什么”。例如一个模糊的请求是“帮我写一个函数从API获取用户数据。” 而Sisyphus风格的请求会是“在我的UserService.ts文件中基于现有的axiosInstance和错误处理模式创建一个名为fetchUserProfile的异步函数。它必须接受一个userId: string参数调用/api/v2/users/{userId}这个端点注意是v2版本我们已弃用v1处理401和404状态码并返回类型为UserProfile的Promise。请特别注意不要引入新的全局依赖错误处理要沿用现有的handleApiError工具函数。”这种约束将AI天马行空的生成能力引导到一个可控的、与项目现状对齐的轨道上。2.2 引入自动化审查环节这是工作流的精髓。我们不是自己用肉眼去审查AI生成的每一行代码而是设计一系列自动化的、可执行的“审查问题”让AI自己先检查一遍。这些问题通常包括语法与类型检查生成的代码在当前项目的TypeScript/ESLint配置下能通过吗依赖与导入验证所使用的函数、组件或类型是否已经在项目中定义或正确导入会不会有循环依赖API与版本兼容性使用的库方法版本是否与项目package.json中的版本匹配有没有被弃用逻辑一致性代码的逻辑是否符合之前提出的具体要求有没有遗漏边界条件通过让AI运行这些审查通常通过让AI模拟执行命令或直接分析代码结构来实现我们将潜在的问题暴露在代码被集成之前。2.3 建立结构化的反馈与迭代机制当审查发现问题后关键是如何反馈。Sisyphus反对简单的“这里错了重写”。它要求提供结构化的、可操作的反馈。例如错误定位明确指出是代码块的哪一行或哪个函数出了问题。错误详情提供具体的错误信息或不符合要求的地方例如“第15行使用的lodash.get方法我们的项目已统一改用可选链操作符?.”。修正指引给出明确的修正方向或建议例如“请使用原生的fetch替换axios以保持与项目其他部分的一致性。”。然后要求AI基于这份清晰的反馈重新生成修正后的代码。这个过程可以迭代多次直到所有审查点都通过。这模拟了高级工程师审查初级工程师代码并提出修改意见的场景使得AI的输出在迭代中不断逼近生产级质量。3. 工作流实操详解手把手搭建你的Sisyphus系统理解了核心思想后我们来看具体如何操作。以下是我根据原项目思路和实践经验总结的标准化步骤。你不需要安装任何额外软件只需要Cursor和一个清晰的头脑。3.1 第一阶段精准定义任务Prompt工程一切始于一个优秀的任务指令。在Cursor中你可以通过Cmd/Ctrl K打开AI指令面板。这里就是你施展Sisyphus工作流的起点。一个失败的任务指令示例“在首页加个轮播图。”一个Sisyphus式的成功任务指令应包含以下层次上下文锚定文件路径/src/components/HomePage/Banner.tsx 项目技术栈React 18, TypeScript, Tailwind CSS, 组件库使用 shadcn/ui。 相关参考文件/src/components/ui/carousel.tsx (这是现有的shadcn轮播组件) /src/types/banner.ts (轮播图数据类型定义)。这步将AI的注意力牢牢锁定在你的项目环境内。任务描述与具体要求任务创建一个自动播放的图片轮播组件。 具体要求 - 组件名AutoPlayCarousel - 使用现有的 Carousel 组件 (/components/ui/carousel) 作为基础。 - 轮播数据接受一个 banners: BannerItem[] 的prop类型定义见参考文件。 - 自动播放间隔5秒切换下一张。当用户鼠标悬停在轮播区域时暂停播放移出后恢复。 - 样式轮播图高度固定为h-[400px]图片应覆盖整个区域并保持比例object-cover。 - 指示器底部显示圆点指示器显示当前激活项。 - 禁止不要安装新的npm包不要创建新的全局样式。集成审查指令关键步骤在你生成代码后请按顺序执行以下自我审查 1. 语法检查生成的TSX代码没有红色下划线错误请模拟检查。 2. 导入检查所有用到的组件Carousel, CarouselContent等是否都从 /components/ui/carousel 正确导入BannerItem 类型是否从 /types/banner 导入 3. 依赖检查代码中是否只使用了React内置hooks、Tailwind类名和指定的shadcn组件确认没有引入未声明的函数或变量。 4. 逻辑检查自动播放的逻辑是否使用了 setInterval 并在 useEffect 中正确清理悬停暂停功能是否通过 onMouseEnter 和 onMouseLeave 实现 5. 样式检查最外层容器是否应用了 h-[400px] 和 relative 类名 请逐一报告审查结果。如果任何一项不通过请直接输出修正后的完整代码并再次进行审查直到全部通过。将以上三部分组合成一个完整的Prompt发送给Cursor。你会发现AI生成代码的“第一稿”质量就会高很多因为它是在带着“审查清单”工作。3.2 第二阶段执行与交互式审查AI生成初始代码后会按照你的要求输出审查报告。例如审查结果 1. 语法检查通过。无TypeScript错误。 2. 导入检查不通过。Carousel系列组件导入路径错误写成了 ../ui/carousel应改为 /components/ui/carousel。BannerItem 类型未导入。 3. 依赖检查通过。未发现未知依赖。 4. 逻辑检查部分通过。自动播放使用了 setInterval但清理函数依赖的 intervalRef 未在依赖数组中声明可能导致内存泄漏。 5. 样式检查通过。此时你不要手动去改代码。而是基于AI的审查报告给出下一步指令“审查结果已收到。请根据第2点和第4点的问题进行修正1. 更正所有导入路径为绝对路径/格式。2. 修正useEffect的清理逻辑确保intervalRef.current被正确清理。修正后再次执行全部5项审查。”AI会输出修正后的代码并再次审查。通常经过1-2轮迭代就能得到一份审查全通过的代码。这个过程看似多了几步对话但相比你直接拿到有问题的代码自己去查找、调试、修正总体耗时更短且代码质量更有保障。3.3 第三阶段集成与最终验证当AI给出“所有审查通过”的代码后工作流尚未结束。手动粘贴与运行将最终代码粘贴到目标文件中。立即触发你的IDE或编辑器的实时错误检查TypeScript、ESLint这相当于一次终极验证。99%的情况下代码应该直接通过。运行测试或启动开发服务器如果该组件有相关的单元测试运行一下。或者直接启动本地开发服务器在浏览器中查看组件实际效果。这是对功能逻辑的最终验收。记录与优化如果在这个过程中发现了Sisyphus审查清单未覆盖的新问题例如一个特定的浏览器兼容性问题记得将这个问题补充到你未来的“审查指令库”中。Sisyphus工作流本身也是一个不断进化的系统。4. 高级技巧与场景化应用模板掌握了基础流程后你可以针对不同场景预制一些更强大的“Prompt模板”真正做到事半功倍。4.1 场景一修复复杂Bug当你想让AI帮你分析并修复一个Bug时Prompt可以这样设计上下文文件/src/utils/dataProcessor.ts中的函数processBatch(items)在输入数组长度超过1000时会导致页面卡顿性能问题。这是该函数的当前代码[粘贴代码片段]。 任务分析性能瓶颈并提供修复方案。 审查清单 1. 复杂度分析识别代码中时间复杂度可能超过O(n)的操作如嵌套循环、数组的shift/unshift操作。 2. 内存分析检查是否有不必要的内存分配或缓存缺失的机会。 3. 方案建议提供1-2个具体的优化方案例如改用for循环替代forEachmap使用Map进行O(1)查找或引入分块处理。 4. 副作用检查优化后的代码是否完全保持原函数的输入输出行为和边界条件 请先输出分析报告再根据你选择的方案生成优化后的代码并对新代码执行上述1-4项审查。4.2 场景二重构旧代码重构时保持功能不变是关键。Sisyphus工作流能极大降低风险。上下文我需要重构/src/legacy/auth.js这个旧的JS文件将其转换为TypeScript并迁移到/src/modules/auth/auth.service.ts。旧文件功能是用户认证使用了回调函数我们希望改为Async/Await。这是旧文件内容[粘贴内容]。 任务执行TypeScript重构与异步化改造。 具体要求与审查 1. 类型定义为所有函数参数、返回值定义清晰的TypeScript接口。 2. 异步改造将callback(err, result)模式改为async/await使用try/catch处理错误。 3. 导入导出保持相同的公共API导出函数名不变内部实现可以优化。 4. 逻辑等价性审查逐行对比新旧代码的核心逻辑确保转换后的代码在功能上与旧代码100%等价。请列出你认为逻辑可能发生变化的地方并进行说明。 5. 风格统一代码风格应符合项目现有的.prettierrc配置。4.3 场景三学习新技术或库当你需要快速上手一个新库时可以让AI扮演“结对编程”中经验丰富的角色。上下文我需要在现有Next.js 14项目的/app/api/upload/route.ts中集成uploadthing库来处理文件上传。项目已安装uploadthing最新版。这是我们的uploadthing核心配置文件/lib/uploadthing.ts[粘贴配置]。 任务在API路由中创建符合App Router规范的POST处理函数。 审查清单 1. 导入验证确认从uploadthing/server和本地配置文件中导入了正确的组件。 2. 路由处理器规范函数是否导出为async function POST(request: Request)是否正确处理了Request对象 3. 错误处理是否使用try-catch包裹并对uploadthing可能抛出的错误和无效请求进行处理 4. 响应格式返回的响应是否符合Next.js App Router的Response格式并设置正确的status和Content-Type 5. 安全审查生成的代码是否避免了将敏感的内部错误信息直接暴露给客户端5. 常见陷阱与效能最大化心法在实际使用Sisyphus工作流大半年后我积累了一些宝贵的教训和技巧这些是单纯看文档学不到的。5.1 陷阱过度依赖与审查疲劳问题试图让AI一次性完成一个巨型需求如“重写整个用户模块”并设置几十条审查项。这会导致AI上下文混乱输出质量下降审查过程也变得冗长低效。解决心法“原子化任务”。将大任务拆解成多个可以独立审查、测试的小任务。例如先让AI生成User类型定义和API接口声明审查通过后再生成UserService数据获取层审查通过后最后生成UserList组件。每一步都稳固整体才可靠。5.2 陷阱模糊的审查标准问题审查指令如“代码要优雅高效”。什么是“优雅”什么是“高效”AI无法理解这种主观标准。解决心法“标准化审查清单”。将主观标准转化为客观、可检查的规则。例如将“高效”转化为“禁止在渲染函数内创建新的函数引用除非使用useCallback”、“对于超过100项的列表渲染是否提示需使用虚拟滚动或分页”将“优雅”转化为“单个函数长度是否超过50行若超过提示是否可拆分为更小的函数”、“重复的代码块是否被提取为公共函数或工具”5.3 效能最大化构建个人Prompt库Sisyphus工作流的核心资产是你积累下来的、针对不同场景的高质量Prompt模板。我建议在笔记软件如Obsidian、Notion中建立一个“AI编码Prompt库”分类管理frontend-component-prompt.md用于生成React/Vue组件。backend-api-prompt.md用于生成Node.js/Go API处理器。bug-analysis-prompt.md用于分析日志和异常。refactor-prompt.md用于代码重构。每个模板都包含经过实战检验的“上下文定义格式”、“任务描述框架”和“审查清单”。当需要时直接复制、微调、粘贴到Cursor效率极高。5.4 心法AI是副驾你仍是机长最重要的心法是心态转变。Sisyphus不是让AI完全取代你而是让你从一个“代码打字员和调试员”升级为“系统设计者和代码审查官”。你的核心价值在于精准定义问题你能把模糊的需求转化为清晰、可执行的AI指令。设计审查标准你凭借经验制定出保障代码质量的“检查单”。做出关键决策当AI给出多个方案时由你基于项目整体架构和业务目标拍板。承担最终责任AI生成的代码集成到项目并产生价值的责任人永远是你。通过Sisyphus工作流你将AI的“生成力”和你的“判断力、经验力”完美结合从而真正突破个人产能的瓶颈。它解决的远不止是“代码对错”问题更是一种全新的、高效的人机协同编程范式。开始实践吧从下一个小的组件或函数开始你会立刻感受到那种从“推石头上山”到“驾驶推土机”的效率飞跃。
AI编码助手协同工作流：从低效问答到高效审查迭代
1. 项目概述当AI编码助手遇上“西西弗斯”如果你和我一样深度依赖Cursor、Copilot这类AI编码助手那你一定经历过这种时刻满怀期待地让AI生成一段代码结果它给出的方案要么是过时的API要么是逻辑上存在明显缺陷的“幻觉”代码。你不得不手动修正然后再次提问AI可能又会固执地回到错误的思路上或者给出另一个同样有问题的版本。这个过程就像希腊神话里的西西弗斯一遍遍地把巨石推上山石头又一遍遍地滚落徒劳无功。Fguedes90/cursor-sisyphus这个项目就是为解决这个痛点而生。它的名字“Sisyphus”直指核心——终结这种无意义的重复劳动。本质上它是一个为Cursor编辑器设计的智能“代码审查与修正”工作流。它不是一个独立的插件而是一套精心设计的、可复现的Prompt提示词工程方案与操作流程。其核心思想是与其和AI进行低效的“问答式”拉锯不如建立一套系统性的“审查-反馈-迭代”机制引导AI进行自我修正最终产出符合你预期的高质量代码。这个项目适合所有使用Cursor进行开发的工程师无论你是前端、后端还是全栈。尤其是当你需要AI协助处理复杂逻辑、集成不熟悉的库或者单纯想提升AI生成代码的“一次通过率”时Sisyphus工作流能显著提升你的开发效率与代码质量。接下来我将彻底拆解这套工作流的每一个环节分享我是如何将它融入日常开发并从中提炼出关键技巧和避坑指南的。2. 核心设计思路从“问答”到“协同工作流”传统的AI编码交互模式是线性的、回合制的你提问AI回答你判断对错然后进入下一轮。Sisyphus的创新之处在于它将这个过程重构为一个带有反馈循环的“微型CI/CD管道”。其设计哲学基于以下几个关键认知2.1 承认AI的局限性并加以约束AI模型包括Cursor背后的强大模型本质上是基于概率的文本生成器。它“知道”很多代码但并不真正“理解”你的项目上下文、最新的API变更或特定的业务约束。Sisyphus工作流的第一步就是通过精确的Prompt为AI划定清晰的“工作区”和“禁区”。这不仅仅是告诉AI“做什么”更重要的是告诉它“按照什么标准来做”以及“绝对不要做什么”。例如一个模糊的请求是“帮我写一个函数从API获取用户数据。” 而Sisyphus风格的请求会是“在我的UserService.ts文件中基于现有的axiosInstance和错误处理模式创建一个名为fetchUserProfile的异步函数。它必须接受一个userId: string参数调用/api/v2/users/{userId}这个端点注意是v2版本我们已弃用v1处理401和404状态码并返回类型为UserProfile的Promise。请特别注意不要引入新的全局依赖错误处理要沿用现有的handleApiError工具函数。”这种约束将AI天马行空的生成能力引导到一个可控的、与项目现状对齐的轨道上。2.2 引入自动化审查环节这是工作流的精髓。我们不是自己用肉眼去审查AI生成的每一行代码而是设计一系列自动化的、可执行的“审查问题”让AI自己先检查一遍。这些问题通常包括语法与类型检查生成的代码在当前项目的TypeScript/ESLint配置下能通过吗依赖与导入验证所使用的函数、组件或类型是否已经在项目中定义或正确导入会不会有循环依赖API与版本兼容性使用的库方法版本是否与项目package.json中的版本匹配有没有被弃用逻辑一致性代码的逻辑是否符合之前提出的具体要求有没有遗漏边界条件通过让AI运行这些审查通常通过让AI模拟执行命令或直接分析代码结构来实现我们将潜在的问题暴露在代码被集成之前。2.3 建立结构化的反馈与迭代机制当审查发现问题后关键是如何反馈。Sisyphus反对简单的“这里错了重写”。它要求提供结构化的、可操作的反馈。例如错误定位明确指出是代码块的哪一行或哪个函数出了问题。错误详情提供具体的错误信息或不符合要求的地方例如“第15行使用的lodash.get方法我们的项目已统一改用可选链操作符?.”。修正指引给出明确的修正方向或建议例如“请使用原生的fetch替换axios以保持与项目其他部分的一致性。”。然后要求AI基于这份清晰的反馈重新生成修正后的代码。这个过程可以迭代多次直到所有审查点都通过。这模拟了高级工程师审查初级工程师代码并提出修改意见的场景使得AI的输出在迭代中不断逼近生产级质量。3. 工作流实操详解手把手搭建你的Sisyphus系统理解了核心思想后我们来看具体如何操作。以下是我根据原项目思路和实践经验总结的标准化步骤。你不需要安装任何额外软件只需要Cursor和一个清晰的头脑。3.1 第一阶段精准定义任务Prompt工程一切始于一个优秀的任务指令。在Cursor中你可以通过Cmd/Ctrl K打开AI指令面板。这里就是你施展Sisyphus工作流的起点。一个失败的任务指令示例“在首页加个轮播图。”一个Sisyphus式的成功任务指令应包含以下层次上下文锚定文件路径/src/components/HomePage/Banner.tsx 项目技术栈React 18, TypeScript, Tailwind CSS, 组件库使用 shadcn/ui。 相关参考文件/src/components/ui/carousel.tsx (这是现有的shadcn轮播组件) /src/types/banner.ts (轮播图数据类型定义)。这步将AI的注意力牢牢锁定在你的项目环境内。任务描述与具体要求任务创建一个自动播放的图片轮播组件。 具体要求 - 组件名AutoPlayCarousel - 使用现有的 Carousel 组件 (/components/ui/carousel) 作为基础。 - 轮播数据接受一个 banners: BannerItem[] 的prop类型定义见参考文件。 - 自动播放间隔5秒切换下一张。当用户鼠标悬停在轮播区域时暂停播放移出后恢复。 - 样式轮播图高度固定为h-[400px]图片应覆盖整个区域并保持比例object-cover。 - 指示器底部显示圆点指示器显示当前激活项。 - 禁止不要安装新的npm包不要创建新的全局样式。集成审查指令关键步骤在你生成代码后请按顺序执行以下自我审查 1. 语法检查生成的TSX代码没有红色下划线错误请模拟检查。 2. 导入检查所有用到的组件Carousel, CarouselContent等是否都从 /components/ui/carousel 正确导入BannerItem 类型是否从 /types/banner 导入 3. 依赖检查代码中是否只使用了React内置hooks、Tailwind类名和指定的shadcn组件确认没有引入未声明的函数或变量。 4. 逻辑检查自动播放的逻辑是否使用了 setInterval 并在 useEffect 中正确清理悬停暂停功能是否通过 onMouseEnter 和 onMouseLeave 实现 5. 样式检查最外层容器是否应用了 h-[400px] 和 relative 类名 请逐一报告审查结果。如果任何一项不通过请直接输出修正后的完整代码并再次进行审查直到全部通过。将以上三部分组合成一个完整的Prompt发送给Cursor。你会发现AI生成代码的“第一稿”质量就会高很多因为它是在带着“审查清单”工作。3.2 第二阶段执行与交互式审查AI生成初始代码后会按照你的要求输出审查报告。例如审查结果 1. 语法检查通过。无TypeScript错误。 2. 导入检查不通过。Carousel系列组件导入路径错误写成了 ../ui/carousel应改为 /components/ui/carousel。BannerItem 类型未导入。 3. 依赖检查通过。未发现未知依赖。 4. 逻辑检查部分通过。自动播放使用了 setInterval但清理函数依赖的 intervalRef 未在依赖数组中声明可能导致内存泄漏。 5. 样式检查通过。此时你不要手动去改代码。而是基于AI的审查报告给出下一步指令“审查结果已收到。请根据第2点和第4点的问题进行修正1. 更正所有导入路径为绝对路径/格式。2. 修正useEffect的清理逻辑确保intervalRef.current被正确清理。修正后再次执行全部5项审查。”AI会输出修正后的代码并再次审查。通常经过1-2轮迭代就能得到一份审查全通过的代码。这个过程看似多了几步对话但相比你直接拿到有问题的代码自己去查找、调试、修正总体耗时更短且代码质量更有保障。3.3 第三阶段集成与最终验证当AI给出“所有审查通过”的代码后工作流尚未结束。手动粘贴与运行将最终代码粘贴到目标文件中。立即触发你的IDE或编辑器的实时错误检查TypeScript、ESLint这相当于一次终极验证。99%的情况下代码应该直接通过。运行测试或启动开发服务器如果该组件有相关的单元测试运行一下。或者直接启动本地开发服务器在浏览器中查看组件实际效果。这是对功能逻辑的最终验收。记录与优化如果在这个过程中发现了Sisyphus审查清单未覆盖的新问题例如一个特定的浏览器兼容性问题记得将这个问题补充到你未来的“审查指令库”中。Sisyphus工作流本身也是一个不断进化的系统。4. 高级技巧与场景化应用模板掌握了基础流程后你可以针对不同场景预制一些更强大的“Prompt模板”真正做到事半功倍。4.1 场景一修复复杂Bug当你想让AI帮你分析并修复一个Bug时Prompt可以这样设计上下文文件/src/utils/dataProcessor.ts中的函数processBatch(items)在输入数组长度超过1000时会导致页面卡顿性能问题。这是该函数的当前代码[粘贴代码片段]。 任务分析性能瓶颈并提供修复方案。 审查清单 1. 复杂度分析识别代码中时间复杂度可能超过O(n)的操作如嵌套循环、数组的shift/unshift操作。 2. 内存分析检查是否有不必要的内存分配或缓存缺失的机会。 3. 方案建议提供1-2个具体的优化方案例如改用for循环替代forEachmap使用Map进行O(1)查找或引入分块处理。 4. 副作用检查优化后的代码是否完全保持原函数的输入输出行为和边界条件 请先输出分析报告再根据你选择的方案生成优化后的代码并对新代码执行上述1-4项审查。4.2 场景二重构旧代码重构时保持功能不变是关键。Sisyphus工作流能极大降低风险。上下文我需要重构/src/legacy/auth.js这个旧的JS文件将其转换为TypeScript并迁移到/src/modules/auth/auth.service.ts。旧文件功能是用户认证使用了回调函数我们希望改为Async/Await。这是旧文件内容[粘贴内容]。 任务执行TypeScript重构与异步化改造。 具体要求与审查 1. 类型定义为所有函数参数、返回值定义清晰的TypeScript接口。 2. 异步改造将callback(err, result)模式改为async/await使用try/catch处理错误。 3. 导入导出保持相同的公共API导出函数名不变内部实现可以优化。 4. 逻辑等价性审查逐行对比新旧代码的核心逻辑确保转换后的代码在功能上与旧代码100%等价。请列出你认为逻辑可能发生变化的地方并进行说明。 5. 风格统一代码风格应符合项目现有的.prettierrc配置。4.3 场景三学习新技术或库当你需要快速上手一个新库时可以让AI扮演“结对编程”中经验丰富的角色。上下文我需要在现有Next.js 14项目的/app/api/upload/route.ts中集成uploadthing库来处理文件上传。项目已安装uploadthing最新版。这是我们的uploadthing核心配置文件/lib/uploadthing.ts[粘贴配置]。 任务在API路由中创建符合App Router规范的POST处理函数。 审查清单 1. 导入验证确认从uploadthing/server和本地配置文件中导入了正确的组件。 2. 路由处理器规范函数是否导出为async function POST(request: Request)是否正确处理了Request对象 3. 错误处理是否使用try-catch包裹并对uploadthing可能抛出的错误和无效请求进行处理 4. 响应格式返回的响应是否符合Next.js App Router的Response格式并设置正确的status和Content-Type 5. 安全审查生成的代码是否避免了将敏感的内部错误信息直接暴露给客户端5. 常见陷阱与效能最大化心法在实际使用Sisyphus工作流大半年后我积累了一些宝贵的教训和技巧这些是单纯看文档学不到的。5.1 陷阱过度依赖与审查疲劳问题试图让AI一次性完成一个巨型需求如“重写整个用户模块”并设置几十条审查项。这会导致AI上下文混乱输出质量下降审查过程也变得冗长低效。解决心法“原子化任务”。将大任务拆解成多个可以独立审查、测试的小任务。例如先让AI生成User类型定义和API接口声明审查通过后再生成UserService数据获取层审查通过后最后生成UserList组件。每一步都稳固整体才可靠。5.2 陷阱模糊的审查标准问题审查指令如“代码要优雅高效”。什么是“优雅”什么是“高效”AI无法理解这种主观标准。解决心法“标准化审查清单”。将主观标准转化为客观、可检查的规则。例如将“高效”转化为“禁止在渲染函数内创建新的函数引用除非使用useCallback”、“对于超过100项的列表渲染是否提示需使用虚拟滚动或分页”将“优雅”转化为“单个函数长度是否超过50行若超过提示是否可拆分为更小的函数”、“重复的代码块是否被提取为公共函数或工具”5.3 效能最大化构建个人Prompt库Sisyphus工作流的核心资产是你积累下来的、针对不同场景的高质量Prompt模板。我建议在笔记软件如Obsidian、Notion中建立一个“AI编码Prompt库”分类管理frontend-component-prompt.md用于生成React/Vue组件。backend-api-prompt.md用于生成Node.js/Go API处理器。bug-analysis-prompt.md用于分析日志和异常。refactor-prompt.md用于代码重构。每个模板都包含经过实战检验的“上下文定义格式”、“任务描述框架”和“审查清单”。当需要时直接复制、微调、粘贴到Cursor效率极高。5.4 心法AI是副驾你仍是机长最重要的心法是心态转变。Sisyphus不是让AI完全取代你而是让你从一个“代码打字员和调试员”升级为“系统设计者和代码审查官”。你的核心价值在于精准定义问题你能把模糊的需求转化为清晰、可执行的AI指令。设计审查标准你凭借经验制定出保障代码质量的“检查单”。做出关键决策当AI给出多个方案时由你基于项目整体架构和业务目标拍板。承担最终责任AI生成的代码集成到项目并产生价值的责任人永远是你。通过Sisyphus工作流你将AI的“生成力”和你的“判断力、经验力”完美结合从而真正突破个人产能的瓶颈。它解决的远不止是“代码对错”问题更是一种全新的、高效的人机协同编程范式。开始实践吧从下一个小的组件或函数开始你会立刻感受到那种从“推石头上山”到“驾驶推土机”的效率飞跃。
