1. 项目概述一个为 Cursor 设计的自主多智能体架构如果你和我一样每天都在用 Cursor 写代码那你肯定也经历过这种时刻给 AI 提一个稍微复杂点的需求比如“给这个 React 组件加个表单验证再优化一下状态管理”结果它要么给你一个过于简化的方案要么写着写着就忘了上下文最后出来的代码还得你自己大改。这感觉就像你雇了个实习生交代任务时得把每一步都掰开揉碎了讲不然准出岔子。Sisyphus 这个项目就是为了彻底解决这个问题而生的。它不是一个简单的代码生成工具而是一个运行在 Cursor 内部的、完整的自主智能体Autonomous Agent架构。简单来说Sisyphus 把 Cursor 从一个“听话的代码助手”变成了一个能自己思考、会分工协作、还懂得质量自检的“AI 开发团队”。它内置了 9 个各司其职的智能体Agent比如有负责复杂深度开发的hephaestus有擅长战略规划的prometheus还有专门做架构决策和深度调试的oracle。当你提出一个需求时Sisyphus 会像项目经理一样先分析你的意图评估当前代码库的状态然后把任务拆解分派给最合适的专家智能体去执行。更重要的是它有一套强制性的验证协议和生命周期钩子Hooks确保每个智能体交上来的“作业”都经过测试和检查不达标准绝不放过。这就像是给整个开发流程装上了自动驾驶和质检流水线让你能从繁琐的监督和调试中解放出来专注于更高层次的设计和决策。这个项目完全基于 Cursor 的原生功能Agents, Rules, Skills, Hooks构建不需要额外的服务器或复杂配置。无论你是独立开发者想提升效率还是团队 leader 希望规范 AI 辅助开发的流程Sisyphus 提供的这套多智能体协作与质量保障体系都能让你用 Cursor 的体验上升好几个维度。接下来我就带你深入拆解它的设计思路、核心机制并分享从安装到实战的完整避坑指南。2. 架构核心多智能体分工与自治系统Sisyphus 的核心思想是“专业的人做专业的事”并通过制度规则和钩子来保证结果质量。这听起来很像一个运转良好的科技公司而它的架构也确实如此设计的。2.1 九大智能体角色解析这 9 个智能体不是随意命名的每个名字都源自希腊神话其职责也与之暗合。理解它们的分工是高效使用 Sisyphus 的关键。atlas擎天神 - 主协调器这是整个系统的“大脑”或“项目经理”。它不直接执行具体编码任务而是负责接收用户指令进行意图分类和代码库评估然后将任务委派给其他智能体。atlas的核心工作是做决策和协调确保正确的任务被分配给正确的专家。hephaestus赫菲斯托斯 - 深度实现工匠对应神话中的火神与工匠之神。他是处理复杂、艰巨编码任务的“主力工程师”。当你需要实现一个算法、重构一个模块或者进行任何需要深入思考和大量代码变更的工作时atlas通常会调用他。他专注于“怎么做”并且能进行长时间的、专注的深度工作。prometheus普罗米修斯 - 战略规划顾问这位“先知”负责宏观规划和方案设计。在你动手之前可以先用/prometheus指令让他为你创建一个详细的行动计划存储在.sisyphus/plans/目录下。这个计划会拆解步骤、识别依赖、预估难点为后续执行提供蓝图。oracle神谕 - 架构师与调试专家当系统遇到棘手难题、架构决策点或者hephaestus多次尝试仍失败时oracle会被请出来。他提供高层次的见解、进行深度调试并在失败达到一定阈值时建议回滚。他是团队里的“终极技术顾问”。librarian图书管理员 - 外部研究专员他的职责是跳出当前代码库去查阅外部文档、库的 API、最佳实践文章等。当任务涉及不熟悉的技术栈或需要研究第三方库时librarian会被激活与explore指令并行工作为执行智能体提供必要的背景知识。metis墨提斯 - 预分析专家在正式规划之前metis可以进行一次快速的“差距分析”。她审视当前状态与目标之间的鸿沟提前识别可能的风险和未知领域为prometheus的规划提供更扎实的输入。momus摩摩斯 - 计划审查员神话中是嘲弄与批评之神。在这里他负责对prometheus生成的计划进行“挑刺”式审查找出逻辑漏洞、不切实际的假设或潜在阻塞点。这是一个可选的但非常有价值的质量门禁。sisyphus-junior小西西弗斯 - 聚焦任务执行者这是处理那些被明确分解出来的、相对独立且明确的小任务的智能体。比如“在这个文件里添加一个工具函数”、“更新这个配置项”。他效率高适合做“搬砖”类工作避免让hephaestus这样的大神被琐事打扰。multimodal-looker多模态观察者 - 视觉内容分析师这个智能体专门处理非文本信息。你可以让他分析项目中的 UML 图、架构草图图片、甚至是 PDF 格式的需求文档或设计稿。他能提取其中的关键信息并将其转化为代码实现的上下文。注意这 9 个智能体并非每次任务都会全部上场。atlas会根据“行为规则”中的分类映射categories规则智能地选择最合适的一个或几个组合来完成任务。这种按需调度的方式既保证了能力覆盖又避免了资源浪费。2.2 五大生命周期钩子自动化的质量守门员钩子Hooks是 Sisyphus 实现“自治”和“质量保障”的关键技术。它们在智能体生命周期的特定时刻自动触发强制执行某些检查不通过则任务无法完成。verifier钩子最重要的质量关卡。每当一个智能体尤其是hephaestus或sisyphus-junior试图标记任务完成时这个钩子会自动运行项目内预设的测试命令如npm test,pytest,cargo test或构建命令如npm run build。如果测试失败或构建出错钩子会阻止智能体完成并生成一个包含错误信息的followup_message发回给该智能体强制它修复问题。这确保了任何代码变更都不会破坏现有功能。boulder-check钩子防止“半吊子”工程。这个钩子检查当前活跃计划active plan中是否还有未完成的待办事项todos。如果有它同样会阻止智能体完成并提醒它还有任务没做完。这有效避免了智能体在复杂任务中“做到一半就以为做完了”的情况确保计划的完整性。comment-checker钩子代码可读性卫士。每当文件被编辑后这个钩子会扫描代码中是否存在明显的、无意义的 AI 生成式注释例如大量重复的“Here is the implementation”或过于笼统的描述。它会标记这些模式提醒智能体或开发者优化注释使其更有价值。这有助于维护代码的长期可读性。notepad-loader钩子上下文传承者。在子智能体如hephaestus开始工作前这个钩子会从.sisyphus/notepads/目录加载与当前任务相关的笔记文件并将其作为上下文提供给智能体。这实现了跨智能体、跨会话的“累积智慧”传递。subagent-retry钩子失败安全网。当子智能体执行失败时此钩子会触发指导系统进行重试并在重试过程中保留关键的上下文信息避免因完全重置状态而导致的知识丢失。这五个钩子共同构成了一条自动化流水线将人工需要反复检查的环节跑测试、查TODO、看注释变成了强制执行的程序规则极大提升了产出代码的可靠性和工程规范性。2.3 七大行为规则智能体的“宪法”规则Rules定义了智能体们如何思考、如何协作、如何保证代码质量。它们是写入每个智能体“潜意识”里的行为准则。sisyphus-core这是核心规则集规定了智能体如何进行意图分类、评估代码库成熟度、在何时应倾向于委派任务而非亲力亲为以及需要避免哪些反模式如过度设计、硬编码等。delegation-patterns明确了任务委派的具体模式。例如如何根据任务类型选择智能体何时可以采用并行探索让多个智能体尝试不同方案如何构建结构化的提示词Prompts来确保指令清晰以及如何保持会话的连续性。verification-protocol这是硬性规定每一次代码变更后都必须进行验证。它定义了一个失败升级阶梯escalation ladder比如第一次验证失败由原智能体修复第二次失败可能触发更严格的检查或通知第三次失败则必须上报给oracle介入。categories一个任务领域到智能体技能组合的映射表。它告诉atlas“如果是前端 UI 任务优先考虑hephaestus并激活frontend-ui-ux技能如果是 Git 操作则用sisyphus-junior配合git-master技能。” 这是实现智能调度的知识库。code-quality代码质量守则。包括模式匹配鼓励使用某些设计模式禁止某些不良模式、注释标准要求注释解释“为什么”而不仅仅是“是什么”、以及禁止无意义或用于单纯压制警告的代码抑制Suppressions。testing-standards测试规范。强制要求测试代码遵循 AAA 模式Arrange-Act-Assert使用统一的命名约定并确保测试输出干净、无冗余信息。notepad-protocol规定了笔记的格式、存储位置.sisyphus/notepads/、如何在智能体间加载和追加内容。这是实现“累积智慧”的制度保障。2.4 四大专项技能赋予智能体“超能力”技能Skills是对 Cursor 内置能力的封装和扩展让智能体能执行更专业的操作。ast-search基于抽象语法树AST的代码搜索。这比简单的文本搜索强大得多。例如你可以让它“查找所有调用useState但未使用解构的 React 组件”它能精准定位到语法结构层面。git-master高级 Git 操作。不仅仅是commit和push还包括遵循约定式提交Conventional Commits规范、智能处理合并冲突、创建有意义的提交信息等。frontend-ui-ux现代前端 UI/UX 模式库。当智能体处理前端任务时此技能会提供关于组件设计、可访问性a11y标准、响应式布局、状态管理如使用 Zustand 而非滥用 Context等的最佳实践指导。browser-automation利用 Cursor 内置的browser-use功能进行浏览器自动化测试。智能体可以编写脚本自动在浏览器中运行并验证 UI 交互实现端到端的测试。3. 工作流深度剖析从指令到产出的完整旅程理解了静态的组件我们再来动态地看 Sisyphus 如何处理一个用户请求。整个流程是一个精心设计的、带有反馈循环的决策与执行链条。3.1 核心工作流智能路由与强制验证整个系统的运转遵循一个清晰的流程我们可以将其理解为一次“任务工单”的完整生命周期。用户指令输入你像平常一样在 Cursor 的聊天框里输入需求比如“重构UserService类将数据库访问层抽离并添加缓存机制”。意图分类与评估atlas智能体被激活。它首先运用sisyphus-core规则对你的指令进行意图分类识别出这是“重构”、“架构调整”和“性能优化”然后快速评估当前代码库的成熟度和复杂程度比如UserService的当前结构、依赖关系。专家委派根据categories规则atlas判断这是一个复杂的、涉及架构更改的任务最适合的专家是hephaestus。于是atlas将任务连同之前评估的上下文一起委派给hephaestus。在委派前notepad-loader钩子会运行将之前任何关于UserService或缓存设计的笔记加载进来作为额外上下文。专家执行hephaestus开始工作。他可能会激活ast-search技能来全面分析UserService的调用关系也可能会参考frontend-ui-ux或browser-automation技能如果任务涉及前后端交互。他会按照自己的“工匠”风格进行深度代码修改。尝试完成与钩子拦截当hephaestus认为任务完成准备发送完成信号时两个“停止钩子”自动触发verifier钩子运行npm test假设是 Node.js 项目。如果测试失败钩子会生成错误报告并强制hephaestus进入“修复模式”无法结束任务。boulder-check钩子检查任务计划。如果计划中还有“编写缓存失效策略”的 TODO 项没勾选钩子会提醒hephaestus此项未完成。循环或完成hephaestus根据钩子的反馈进行修复和补充。只有当他通过了所有钩子的检查测试通过、TODO 清空任务才真正标记为完成。同时hephaestus会将本次重构中的关键决策、遇到的坑、缓存选型理由等作为笔记追加到.sisyphus/notepads/下的相关文件中供未来参考。这个流程确保了产出不是“一次性”的代码而是经过测试验证、符合计划、且知识得以沉淀的可靠成果。3.2 计划驱动的工作流复杂任务的蓝图对于极其复杂或开创性的任务Sisyphus 推荐采用更严谨的“计划驱动”工作流。这就像大型工程开工前必须先有详细设计图纸。预分析你可以先让metis对任务进行快速扫描。输入“分析一下我们如果要把认证系统从 JWT 切换到 Session主要难点在哪”。metis会给出一个初步的差距分析报告。战略规划使用/prometheus指令正式启动规划。例如输入“为从 JWT 切换到 Session 认证制定详细实施计划”。prometheus会创建一个详细的计划文件如.sisyphus/plans/auth_migration_plan.md里面可能包含现状分析、目标架构、阶段划分先改后端 API再适配前端、数据迁移策略、回滚方案、风险评估等。计划审查使用/momus指令让他来审查prometheus制定的计划。momus会犀利地指出“计划中低估了前端 SDK 的兼容性影响”“没有考虑移动端 App 的令牌刷新机制”等等。这一步能提前发现重大疏漏。计划执行最后使用/atlas指令并引用这个计划文件说“请执行.sisyphus/plans/auth_migration_plan.md中的阶段一”。atlas会作为总指挥按照计划中的步骤协调hephaestus改核心逻辑、librarian研究新的 session 库、sisyphus-junior更新配置文件等多个智能体并行或串行工作并全程受钩子监督。这种模式将人类的战略规划能力与 AI 的自动化执行能力完美结合特别适合大型重构、技术栈迁移或复杂新功能的开发。3.3 累积智慧系统笔记协议的实际运作“笔记”Notepad系统是 Sisyphus 区别于普通 AI 助手的精髓之一。它解决了 AI 上下文有限、跨会话记忆丢失的核心痛点。存储所有笔记都以 Markdown 或文本格式存储在项目根目录的.sisyphus/notepads/文件夹下。建议按领域或模块组织文件如notepads/auth.md,notepads/database_schema.md,notepads/known_bugs.md。加载当atlas委派任务给hephaestus时notepad-loader钩子会根据任务关键词如“auth”、“UserService”自动查找并加载相关笔记文件的内容并将其作为系统提示词的一部分注入给hephaestus。这意味着hephaestus在开始编码前就已经知道“哦之前我们决定用 Redis 做缓存并且UserService的第 45 行有一个已知的并发问题需要绕开。”追加任务完成后智能体会被要求将其工作成果中的“洞察”追加到笔记中。例如hephaestus在重构后可能会在notepads/caching.md中追加“为UserService实现了基于 Redis 的缓存键名格式为user:{id}TTL 设为 30 分钟。注意在集群部署下需要确保 Redis 配置一致。”价值这个系统使得项目知识得以持续积累和复用。新加入的开发者或新的智能体会话能迅速获得项目上下文。它也让 AI 的行为更具一致性和可预测性因为它总是基于不断丰富的“团队记忆”进行决策。4. 实战部署与配置指南理论讲得再多不如动手装一遍。Sisyphus 的安装非常灵活你可以根据个人或团队的工作流选择最适合的方式。4.1 安装方式详解与选择建议官方推荐了四种安装方式各有优劣。方式一克隆并符号链接推荐给个人开发者这是我最推荐个人使用的方式因为它平衡了简单性和可更新性。# 1. 将插件克隆到一个全局位置 git clone https://github.com/Fguedes90/cursor-sisyphus.git ~/.cursor-plugins/sisyphus # 2. 在你的项目根目录下创建 .cursor 文件夹如果不存在 mkdir -p .cursor # 3. 创建符号链接指向全局的插件组件 ln -sf ~/.cursor-plugins/sisyphus/agents .cursor/agents ln -sf ~/.cursor-plugins/sisyphus/rules .cursor/rules ln -sf ~/.cursor-plugins/sisyphus/skills .cursor/skills ln -sf ~/.cursor-plugins/sisyphus/scripts .cursor/scripts ln -sf ~/.cursor-plugins/sisyphus/hooks/hooks.json .cursor/hooks.json优点更新极其方便只需在全局目录执行git pull。所有使用符号链接的项目都会立即获得最新版插件。缺点需要手动执行几条命令对纯新手稍有门槛。方式二一键脚本安装最快捷如果你追求极简并且信任远程脚本这是最快的方法。curl -fsSL https://raw.githubusercontent.com/Fguedes90/cursor-sisyphus/main/install.sh | bash这个脚本会自动完成克隆和符号链接的步骤。优点一条命令搞定。缺点你需要审查脚本内容这是好习惯且更新时可能仍需手动进入目录git pull取决于脚本的实现。方式三克隆并复制适合临时试用或不可变环境这种方式将插件文件物理复制到你的项目里。git clone https://github.com/Fguedes90/cursor-sisyphus.git /tmp/sisyphus-plugin mkdir -p .cursor cp -r /tmp/sisyphus-plugin/agents/ .cursor/agents/ cp -r /tmp/sisyphus-plugin/rules/ .cursor/rules/ cp -r /tmp/sisyphus-plugin/skills/ .cursor/skills/ cp -r /tmp/sisyphus-plugin/scripts/ .cursor/scripts/ cp /tmp/sisyphus-plugin/hooks/hooks.json .cursor/hooks.json rm -rf /tmp/sisyphus-plugin优点项目完全自包含与外部无依赖。缺点无法通过git pull更新每个项目都需要单独复制管理多个项目时会很繁琐。方式四Git 子模块推荐给团队项目如果你的项目本身就用 Git 管理并且希望团队成员能同步使用相同的 Sisyphus 配置这是最佳选择。# 在项目根目录执行 git submodule add https://github.com/Fguedes90/cursor-sisyphus.git .cursor-plugins/sisyphus # 然后同样创建符号链接但指向子模块目录 ln -sf .cursor-plugins/sisyphus/agents .cursor/agents # ... 其他符号链接同理优点插件版本作为项目的一部分被 Git 管理团队成员克隆项目后子模块也会被初始化确保环境一致。缺点需要团队成员了解基本的子模块操作git submodule update --init。实操心得对于个人我强烈推荐方式一符号链接。我通常在~/.cursor-plugins/下维护多个插件每个项目里的.cursor目录都通过符号链接指向它们。这样我可以在一个中心位置管理所有插件版本更新一次全部生效。记得将~/.cursor-plugins/也加入你自己的版本控制比如一个私有的 dotfiles 仓库以便在新电脑上快速恢复开发环境。4.2 关键配置与自定义调整安装完成后Sisyphus 基本可以开箱即用。但为了让它更贴合你的项目有几个地方值得配置。1. 验证钩子 (verifier) 的配置这是最重要的配置。你需要告诉verifier钩子如何测试你的项目。钩子脚本位于~/.cursor-plugins/sisyphus/scripts/verifier.sh符号链接方式。你需要根据项目类型修改它。默认的脚本可能很简单比如#!/bin/bash # verifier.sh echo “Running verifier...” # 这里默认可能只是 echo你需要替换为实际的测试命令 # npm test # pytest # cargo test # go test ./...你需要将其改为你项目的实际测试命令。例如对于一个 Node.js 项目#!/bin/bash echo “Running project tests...” if [ -f “package.json” ]; then npm test if [ $? -ne 0 ]; then echo “Tests failed. Blocking completion.” exit 1 fi else echo “No package.json found. Skipping test verification.” fi对于一个 Python 项目你可能会用pytest#!/bin/bash echo “Running pytest...” if command -v pytest /dev/null; then pytest if [ $? -ne 0 ]; then exit 1 fi else echo “pytest not found. Skipping.” fi要点确保你的测试命令在项目根目录下能正确运行。钩子脚本以非零退出码exit 1表示失败这将阻止智能体完成任务。2. 笔记目录的初始化虽然笔记系统会自动创建目录但一个好的开始是主动建立结构。在你的项目根目录mkdir -p .sisyphus/notepads touch .sisyphus/notepads/architecture.md touch .sisyphus/notepads/dependencies.md touch .sisyphus/notepads/decisions.md在decisions.md里你可以记录一些重要的技术决策比如“本项目使用 React Query 而非 Redux 进行服务端状态管理原因见链接...”。这样当智能体处理相关任务时这些决策会自动成为它的上下文。3. 自定义规则与技能高级Sisyphus 的规则和技能是纯文本文件你可以按需修改或创建新的。修改规则例如你觉得code-quality规则里对注释的要求太松你可以编辑~/.cursor-plugins/sisyphus/rules/code-quality.md添加你们团队的特定规范。创建技能如果你的项目有特殊需求比如需要与某个内部 API 交互你可以创建一个新的技能文件my-api-skill.md放在.cursor/skills/目录下描述如何调用该 API。然后在categories规则中将相关任务映射到这个新技能上。4.3 验证安装与初步测试安装并简单配置后如何验证 Sisyphus 已正常工作检查目录结构在你的项目里确保.cursor目录下有agents,rules,skills,scripts子目录和hooks.json文件。并且.sisyphus目录也存在。触发一个简单任务在 Cursor 聊天框中输入一个清晰的任务比如“在项目根目录创建一个README.md文件简要描述本项目”。观察 Cursor 的响应。成功迹象你会看到 Cursor 使用的“代理”Agent名称可能变成了atlas或sisyphus-junior。它可能会先输出一个计划或者直接开始执行。完成后检查是否真的创建了文件。检查钩子如果verifier钩子配置了测试在创建文件后你可能会在 Cursor 的输出中看到“Running verifier...”之类的信息。测试笔记系统先手动在.sisyphus/notepads/test.md里写一句“本项目所有配置文件都使用 YAML 格式。” 然后让智能体执行一个任务比如“创建一个新的配置文件”。观察它的响应中是否提到了使用 YAML 格式。如果它创建的是.json文件说明笔记加载可能有问题需要检查钩子配置和笔记文件路径。5. 常见问题排查与实战技巧在实际使用中你可能会遇到一些困惑或问题。这里我整理了一份从社区反馈和个人实践中总结的常见问题与解决技巧。5.1 安装与初始化问题问题1安装后Cursor 没有出现新的智能体选项或行为没变化。检查点1Cursor 版本。确保你使用的是支持自定义 Agents、Rules、Skills 的 Cursor 版本通常是较新的 Insider 版本。在 Cursor 设置中查看版本信息。检查点2.cursor目录位置。必须在项目根目录下创建.cursor目录和相应的符号链接或文件。在子目录中打开 Cursor 可能无法正确识别。检查点3重启 Cursor。安装或修改插件后完全关闭并重新打开 Cursor 应用以确保它重新加载所有配置。检查点4hooks.json文件。检查.cursor/hooks.json文件内容是否正确引用了verifier.sh等脚本。文件内容应该类似{ “stop”: [“../scripts/verifier.sh”, “../scripts/boulder-check.sh”], “edit”: [“../scripts/comment-checker.sh”], “subagent_start”: [“../scripts/notepad-loader.sh”], “subagent_stop”: [“../scripts/subagent-retry.sh”] }注意路径是相对于.cursor目录的。如果你用的是符号链接路径通常是正确的如果是复制方式可能需要调整路径如“scripts/verifier.sh”。问题2verifier钩子没有运行或者运行了但没阻止错误提交。检查点1脚本可执行权限。在终端中进入.cursor/scripts/目录运行chmod x verifier.sh boulder-check.sh确保脚本有执行权限。检查点2脚本退出码。verifier.sh脚本必须在测试失败时使用exit 1退出。用echo $?可以检查上一条命令的退出码。确保你的测试命令如npm test在失败时确实返回非零码。检查点3钩子触发时机。stop钩子只在智能体主动尝试停止标记任务完成时触发。如果智能体因为错误或你手动中断而停止钩子可能不会运行。5.2 智能体行为与协作问题问题3感觉atlas总是把任务派给hephaestus即使是很小的任务。这通常与categories规则中的映射和你的指令清晰度有关。atlas根据意图分类做决策。如果你说“修复这个 bug”它可能认为这是复杂问题。尝试更精确的指令比如“sisyphus-junior将utils.js文件中的formatDate函数导出方式从module.exports改为 ES6 的export default”。直接指定智能体可以绕过自动路由。你也可以修改categories.md规则文件调整任务类型与智能体的映射关系使其更符合你的偏好。问题4智能体似乎没有读取笔记Notepad里的内容。检查点1笔记文件路径和格式。确保笔记文件在.sisyphus/notepads/目录下并且是.md或.txt等文本格式。检查点2notepad-loader.sh脚本。检查该脚本是否正常工作。你可以手动运行它看看输出。脚本的逻辑是搜索笔记内容并将其注入到上下文。如果脚本有 bug 或路径错误加载会失败。检查点3任务相关性。notepad-loader会根据当前任务的关键词去匹配笔记文件名和内容。如果笔记是关于“数据库”的而你在处理一个纯前端任务它可能不会被加载。确保笔记内容与任务相关或者考虑在指令中明确提示“请参考.sisyphus/notepads/xxx.md中的内容”。问题5多智能体协作时上下文似乎丢失了。这是 AI 模型的固有局限。虽然笔记系统帮助传递了静态知识但动态的、长链条的对话上下文仍然可能丢失。最佳实践是对于复杂任务坚持使用“计划驱动”工作流。让/prometheus创建一个详细的计划文件然后让/atlas严格按计划文件执行。计划文件本身就是一个强大的、不会丢失的上下文载体。在每个子任务开始时atlas都会重新将整个计划作为上下文加载。5.3 性能与效率优化技巧技巧1控制任务粒度不要一开始就扔一个“重构整个项目”的巨无霸任务。这会让智能体陷入混乱产生大量无意义的输出。应该像对待人类工程师一样将大任务拆解。先用/prometheus制定计划然后分阶段、分模块地让atlas去执行。例如“执行plan.md中的‘阶段一抽离用户认证模块’”。技巧2善用直接指令与规划指令直接指令对于明确、微观的任务直接指定智能体。例如“librarian帮我找一下 React 中性能优化useMemo和useCallback的最佳实践对比文章”。规划指令对于模糊、宏观、创新的任务使用规划指令。例如“/prometheus我们需要一个仪表盘页面展示用户活跃度、收入概览和系统健康状态。请设计一个技术方案和实现计划”。技巧3主动管理笔记系统不要完全依赖智能体自动追加笔记。定期比如每天或每个功能完成后去检查和整理.sisyphus/notepads/目录。合并重复的笔记修正错误补充智能体可能遗漏的深层逻辑。把笔记系统当作你的项目维基来维护它的价值会随着时间指数级增长。技巧4自定义规则以符合团队规范如果你的团队有严格的代码规范如 ESLint 配置、提交信息格式强烈建议你将它们融入到 Sisyphus 的规则中。例如在code-quality.md中详细列出你们的 ESLint 规则摘要在git-master技能中固化你们的提交信息模板。这样AI 生成的代码会从一开始就更贴近团队标准减少后期修改成本。技巧5理解并接受当前局限性Sisyphus 是一个强大的框架但它仍然建立在现有大语言模型LLM的能力之上。它无法解决 LLM 固有的问题如“幻觉”生成错误但看似合理的信息、对极新技术的了解不足、以及复杂逻辑推理的局限性。它的价值在于将人类的意图和规划通过一套可靠的流程和规则转化为 AI 高效且质量可控的执行。你仍然是项目的总架构师和最终决策者Sisyphus 是你手下那个永不疲倦、严格遵循流程的超级执行团队。