1. 项目概述从“生成代码”到“工程化编码”的范式跃迁如果你和我一样在过去一年里深度使用过 Claude Code、Cursor 这类 AI 编程助手你肯定经历过这样的场景你向 AI 描述一个需求它“唰”地一下生成了一大段代码。你满怀期待地运行结果要么是编译错误要么是逻辑 Bug要么是性能拉胯。于是你开始和它进行漫长的“对话调试”——“这里不对改一下”、“那个函数跑得太慢了优化优化”。几个回合下来你发现自己花在解释、纠错和验证上的时间可能比亲手写代码还要多。这本质上还是“人在给 AI 打工”远未达到“AI 自主完成工程任务”的愿景。今天要聊的 Godmode就是试图从根本上解决这个问题的开源项目。它不是一个替代 Claude 或 Cursor 的新 AI而是一个为现有 AI 编程助手注入“工程化思维”的插件系统。你可以把它理解为一个“AI 的副驾驶”或者更准确地说是一个“AI 的工程总监”。它的核心目标非常明确让 AI 的代码输出从“一次性的、充满不确定性的草稿”变成“经过迭代验证、可交付的工程制品”。简单来说Godmode 为 AI 编程引入了软件工程中最核心的反馈循环测量 - 修改 - 验证 - 决策保留/回滚- 重复。它内置了 134 个覆盖全生命周期的工程技能从架构设计、性能优化、安全审计到部署上线7 个可并行工作的智能体以及一套严谨的“作者纪律”准则来约束 AI 的创作过程。最让我印象深刻的是它的“失败记忆”系统——每一次被回滚的糟糕修改都会被分类、记录并分析确保 AI 不会在同一个地方反复跌倒。2. 核心设计哲学为什么“纪律”比“聪明”更重要在深入技术细节前有必要先理解 Godmode 背后的设计哲学。这直接决定了它和那些“一次性生成代码”的工具有着本质区别。2.1 纪律优先于速度大多数 AI 编码工具都在追求“快”——更快地生成代码更快地响应。但 Godmode 认为在软件工程中“对”比“快”更重要。一个错误的设计决策或代码实现后期修复的成本可能是指数级增长的。因此Godmode 强制为每一次修改都套上了三层“纪律枷锁”修改前思考Think Before CodingAI 在动笔前必须明确陈述其所有假设如果遇到歧义比如用户说“优化这个 API”但没指定是响应时间还是吞吐量它不能自作主张选一个而是必须抛出NEEDS_CONTEXT要求澄清。这直接借鉴了 Andrej Karpathy 对 LLM 编码常见问题的观察。简单性优先Simplicity First在生成代码前AI 会运行一个“预修改检查清单”主动剔除那些“顺带手”添加的、与核心目标无关的“炫技”代码比如不必要的配置项、过度设计的辅助函数。这防止了代码库在无人监管的情况下变得臃肿。外科手术式修改Surgical Changes这是我最欣赏的规则之一。它要求 AI 修改的每一行代码都必须能直接追溯到用户的原始请求。如果你让 AI “修复登录接口的 SQL 注入漏洞”它就不能“顺便”把整个用户模型的代码风格也重构了。任何这类“范围漂移”的代码块都会在提交前的审计中被自动丢弃。2.2 证据优先于断言在传统的 AI 编码交互中AI 经常会说“我优化了查询现在应该更快了”。但在 Godmode 的范式里“应该”、“看起来”这种主观词汇是无效的。一切改进都必须有可量化的证据支撑。例如当你运行/godmode:optimize来优化 API 响应时间时Godmode 会做以下几件事首先它会运行一个基准测试比如用curl测量当前 API 的 P95 延迟并记录为“基线”。然后它提出一个优化方案比如给某个字段加数据库索引实施这个单一的、原子性的修改并提交到 Git。接着它用完全相同的基准测试命令再次测量。决策时刻如果新的延迟比基线低且通过了所有预设的“守卫”测试如单元测试、Lint则保留这次提交如果更差或持平则自动执行git reset回滚。这个循环会一直持续直到达到目标如“延迟降低 50%”或迭代次数上限。这个过程完全自动化不需要人工介入。你最终得到的不是一个“声称”更快的代码而是一个有着完整 Git 历史、记录了每一次尝试和结果的数据表格.godmode/optimize-results.tsv以及最终被客观数据证明的、更优的代码版本。2.3 Git 即记忆失败即知识Godmode 将 Git 不仅仅视为版本控制工具更视为其“实验记忆”的核心载体。每一次尝试性的修改都是一个 Git Commit每一次回滚都是一个 Git Reset。这意味着整个探索过程是完全可追溯、可复现的。更关键的是其“失败记忆”系统。每一次被回滚的修改都会被分类到 8 种失败类型中例如guard_failed守卫测试失败、regression性能回退、scope_drift范围漂移等并记录到.godmode/skill-failures.tsv。当一个技能连续失败 3 次后AI 会触发一次“反思诊断”分析失败模式并将教训写入.godmode/lessons.md。这些知识会在后续的会话中被读取从而避免重蹈覆辙。这相当于为 AI 装上了“经验学习”的能力。3. 架构深度解析七类智能体与四层令牌优化理解了哲学我们再来拆解 Godmode 是如何实现这些理念的。它的架构可以概括为“一个编排器 七类智能体 四层优化栈”。3.1 七类专业智能体分工协作Godmode 不是一个大而全的“超级 AI”而是由 7 个各司其职的智能体组成的“特种部队”。这种设计借鉴了人类软件团队的协作模式智能体核心职责工作模式规划者 (planner)需求分解与任务规划将宏观目标如“构建用户认证系统”拆解成可并行执行的原子任务子集并选择协调模式如“扇出/扇入”。构建者 (builder)代码实现与 TDD在独立的 Git 工作树中以测试驱动开发的方式实现具体任务。严格遵守“作者纪律”并在提交前进行“丢弃审计”。审查者 (reviewer)代码质量审查对合并前的代码进行多维度审查正确性、安全性、性能、代码风格。相当于团队的资深工程师。优化者 (optimizer)性能迭代优化执行“测量-修改-验证”循环专注于提升特定指标延迟、吞吐量、内存使用等。探索者 (explorer)代码库侦察只读模式。快速扫描代码库理解架构、依赖和入口点为其他智能体提供上下文。常用于“研究”阶段。安全专家 (security)安全审计与渗透采用 STRIDE 威胁建模和 OWASP Top 10 清单并模拟四种攻击者角色进行审计。测试者 (tester)测试套件开发专门生成单元测试、集成测试、端到端测试并维护“红-绿-重构”的 TDD 节奏。在实际执行复杂任务时Godmode 的编排器会启动“多智能体并行执行”模式。例如构建一个认证系统规划者将其分解为 4 个任务认证中间件、用户模型、API 端点、集成测试。编排器同时启动 4 个构建者智能体每个智能体获得一个独立的 Git 工作树互不干扰地并行工作。所有子任务完成后编排器按顺序将工作树合并回主分支每合并一个就运行一次完整的测试套件确保增量集成稳定。最后审查者智能体对合并后的代码进行最终审查。这种“隔离开发、顺序合并、即时验证”的模式极大地提升了复杂任务的完成效率和代码质量。3.2 四层令牌优化栈与成本共舞让 AI 进行长时间、多轮次的自主循环最大的挑战之一是上下文令牌的消耗成本。Godmode 通过一个精心设计的四层优化栈将路由阶段的上下文消耗降低了约 90%整体输出令牌减少了 40-60%。第一层渐进式披露路由这是最核心的优化。Godmode 的 134 个技能文件每个都遵循统一的“分层”结构第一层文件最开始的约20行包含## Activate When部分明确说明该技能在什么条件下被触发。第二层技能的核心工作流程和硬性规则。第三层示例和错误恢复等详细信息用!-- tier-3 --标记。当用户发出一个指令如“优化我的API”时编排器只读取所有技能文件的第一层总计约2700行就能完成路由决策决定调用哪个或哪几个技能。如果读取全部技能文件约27000行则需要10倍的令牌。这相当于一个高效的“索引”系统。第二层标准输入/输出压缩AI 在与系统交互时经常需要执行git log、cat file、ls -la等命令这些命令的原始输出可能非常冗长。Godmode 定义了一套 13 个“规范命令模式”引导智能体使用信息密度更高的变体git log-git log --oneline -20只显示最近20条提交的概要cat large_file.txt-wc -l large_file.txt或head -100 large_file.txt先看行数或头部ls -la-ls -1简单列表 这从“输入侧”减少了需要处理的无关信息。第三层简洁输出模式从自主循环的第二轮开始Godmode 会自动激活“简洁模式”。在此模式下循环摘要、状态报告等内容的输出会被大幅压缩减少40-60%。但是关键信息如表格数据、生成的代码、错误信息、提交消息和最终总结保持详细输出。用户可以通过/godmode:terse off关闭此模式。第四层令牌可观测性skills/tokens/技能会在每个循环中使用字符数/4的启发式方法估算并记录输入和输出的令牌消耗到.godmode/token-log.tsv。这让你可以量化地回答“我的优化循环是越跑越便宜还是越跑越贵” 便于进行成本分析和优化。这四层优化是乘数效应它们共同作用使得长时间、多技能的自主循环在成本上变得可行。4. 实战演练从安装到完成一次自主优化理论说了这么多我们上手实操一遍看看 Godmode 到底能做什么。这里以 Claude Code 环境为例。4.1 环境准备与安装首先你需要一个已安装 Claude Code 的环境。然后安装 Godmode 插件非常简单# 在 Claude Code 终端中执行 claude plugin install godmode安装完成后Claude Code 的指令面板中就会出现/godmode开头的命令。你也可以通过bash adapters/claude-code/verify.sh来验证安装是否成功。其他平台Cursor, Codex, Gemini CLI, OpenCode的安装脚本在adapters/目录下过程类似。注意Godmode 本身是开源免费的但它需要运行在已有的 AI 编程助手之上。这些助手可能有各自的订阅费用。4.2 初体验让 AI 自主优化一个慢 API假设我们有一个简单的 Node.js Express API 端点/api/posts它从数据库查询文章列表但响应很慢。我们想让 Godmode 来优化它。第一步设定明确目标我们不需要告诉 AI 具体怎么做只需要告诉它目标和衡量标准。在 Claude Code 的聊天框中输入/godmode optimize the /api/posts endpoint to reduce response time, measured by time curl -s -o /dev/null -w %{time_total} http://localhost:3000/api/posts这个指令非常关键optimize是技能名/api/posts endpoint是优化对象reduce response time是优化方向引号内的curl命令是可机械执行的、返回数值的成功标准。Godmode 只认这种客观指标。第二步观察自主循环发出指令后你就可以暂时离开座位了。Godmode 会开始它的工作流探索首先探索者智能体会扫描你的代码库定位到/api/posts相关的路由、控制器、模型文件。建立基线运行你提供的curl命令多次例如5次计算平均响应时间作为基线比如 850ms。进入优化循环 a.构思优化者智能体分析代码提出一个可能有效的、原子性的优化方案。例如“当前查询使用了SELECT *且没有索引。优化方案为posts表的user_id字段添加索引并只查询需要的字段。” b.修改构建者智能体实施这个修改。在修改前它会运行‘预修改检查清单’确保不添加无关代码。修改后在提交前运行‘丢弃审计’移除任何‘范围漂移’的代码块。c.验证首先运行“守卫”命令如npm test确保测试通过然后再次运行基准curl命令。 d.决策如果新的平均响应时间比如 600ms显著优于基线则保留这次 Git 提交。如果更差或没有显著改善则执行git reset --hard HEAD回滚。 e.记录无论保留还是丢弃结果耗时、改进百分比、采取的行动都会被记录到.godmode/optimize-results.tsv。丢弃的原因会被分类记录到.godmode/optimize-failures.tsv。重复优化者会尝试下一个方案例如“启用 Gzip 压缩”、“实现查询结果缓存”继续循环。第三步查看结果循环结束后你会在终端看到一个清晰的总结表格就像项目介绍中的那样Goal: Reduce /api/posts response time Iterations: 8 BASELINE 850ms ROUND 1 600ms KEPT (-29.4%) -- added index on user_id, selected specific fields ROUND 2 550ms KEPT (-8.3%) -- enabled gzip compression middleware ROUND 3 520ms KEPT (-5.5%) -- added simple in-memory cache with 5s TTL ROUND 4 800ms REVERTED -- tried connection pooling (caused errors) ROUND 5 480ms KEPT (-7.7%) -- implemented pagination (limit 20) 850ms -- 480ms (43.5% improvement) Keeps: 4 | Discards: 1同时你的代码库留下了清晰的 Git 历史记录了每一次成功的优化提交。.godmode目录下的文件则包含了完整的实验数据。4.3 进阶使用多智能体并行构建功能现在假设我们要构建一个完整的用户认证系统。这是一个包含多个模块的复杂任务。/godmode build a complete user authentication system with JWT, secure password hashing, and rate limiting.发出这个指令后Godmode 的工作流如下思考与研究think技能被触发分析需求。由于任务涉及外部库JWT且范围较大research技能被自动派发探索者智能体会快速搜索项目内已有的认证相关代码并可能生成一个.godmode/research.md文件汇总常用的 Node.js 认证库和最佳实践。规划plan技能被触发规划者智能体将任务分解。它可能会输出类似这样的计划Plan: Fan-out/Fan-in Coordination - Task 1: Implement JWT token generation/verification middleware (agent: builder-1) - Task 2: Create User model with password hashing using bcrypt (agent: builder-2) - Task 3: Implement /api/auth/login and /api/auth/register endpoints (agent: builder-3) - Task 4: Write integration tests for the auth flow (agent: builder-4) - Merge Strategy: Sequential merge with test after each merge. - Final Review: Security and code style review (agent: reviewer)注意它声明了使用“扇出/扇入”协调模式。并行构建编排器同时启动 4 个构建者智能体每个智能体都在一个独立的 Git 工作树中工作。这避免了任务间的冲突和干扰。顺序合并与测试所有构建者完成后编排器按顺序将工作树合并回主分支。关键点每合并一个工作树就运行一次完整的测试套件。如果测试失败则停止合并触发fix技能进行修复。这确保了系统的增量稳定性。最终审查所有代码合并后审查者智能体启动进行安全审查检查是否有硬编码的密钥、密码强度策略等、性能审查和代码风格审查。整个过程你作为开发者只是在开始时给出了一个宏观指令并在最后验收成果。中间的分解、并行开发、集成、测试、审查全部由 Godmode 协调完成。5. 技能体系与自定义打造你自己的 AI 工程手册Godmode 的强大之处在于其可扩展的技能系统。134 个内置技能覆盖了软件工程的方方面面但你完全可以添加属于自己的技能。5.1 技能文件解剖每个技能都是一个 Markdown 文件存放在skills/目录下。它的结构有严格约定以确保与渐进式披露路由等工作机制兼容。# Skill: database_index_advisor ## Activate When - User asks about “slow query”, “database performance”, “index” - The explorer agent finds SQL files or ORM models with sequential scans in query plans - The current phase is optimize or debug ## Workflow 1. **ANALYZE**: Use EXPLAIN ANALYZE (PostgreSQL) or equivalent on the slow query identified. 2. **IDENTIFY**: Look for sequential scan operations and the columns used in WHERE/JOIN/ORDER BY clauses. 3. **PROPOSE**: Suggest a single-column or composite index. Format: CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_name ON table_name (column1, column2); 4. **GUARD**: Before applying, check index count on the table (SELECT COUNT(*) FROM pg_indexes WHERE tablename table_name). If 5, warn about over-indexing. 5. **APPLY**: Run the CREATE INDEX statement in a transaction. 6. **VERIFY**: Re-run EXPLAIN ANALYZE. The sequential scan should be replaced by an Index Scan or Bitmap Heap Scan. 7. **DECIDE**: If query cost reduced by 15%, KEEP. Else, DISCARD (drop the index). ## Hard Rules - Rule 0: Inherits all default activations from SKILL.md §14. - Rule 1: Only propose one index per iteration. Atomic changes only. - Rule 2: Always check for existing indexes to avoid duplication. - Rule 3: The VERIFY step must use the exact same query and parameters as the baseline. - Rule 4: If the table is write-heavy, consider index maintenance overhead in the decision. !-- tier-3 -- ## Examples ... (具体例子) ## Error Recovery ... (错误处理流程)## Activate When这是第一层内容供路由器快速匹配。必须清晰定义触发该技能的精确条件。## Workflow第二层定义技能执行的步骤。必须具体、可操作像一份精确的剧本。## Hard Rules第二层定义不可违反的规则。第一条规则通常是继承默认激活项。!-- tier-3 --标记之后是第三层内容包含示例和错误恢复仅在技能被激活后才会载入。5.2 如何添加一个自定义技能假设你们团队频繁进行代码库的国际化i18n工作你想创建一个技能来自动扫描未翻译的字符串并生成待办列表。找到参照在skills/目录下找一个领域相近的技能作为模板比如skills/frontend/ui.md。创建文件在skills/下创建i18n_string_audit.md。编写技能在## Activate When中写明当用户提到“i18n”、“translation”、“missing strings”或项目中有i18n.js、translations/等目录时触发。在## Workflow中定义a) 使用grep或特定解析工具如i18next-scanner扫描源代码中的硬编码用户可见字符串。b) 与现有的语言资源文件如en.json进行比对。c) 生成一个 Markdown 格式的报告列出文件路径、行号、原始字符串。d) 建议是否直接调用翻译 API需配置密钥或仅生成待办列表。在## Hard Rules中设定仅扫描.js、.jsx、.ts、.tsx文件忽略测试文件和 node_modules字符串长度小于 2 的忽略可能是变量名。测试技能在项目根目录运行bash scripts/test_skill.sh i18n_string_audit如果存在或手动创建一个测试用例用/godmode find untranslated strings来触发它。通过这种方式你可以将团队的工程实践、代码规范、甚至是部署检查清单都固化为 Godmode 的技能。随着技能库的丰富你的 AI 助手将变得越来越懂你的项目和团队。6. 常见问题与实战避坑指南在实际使用和研究了 Godmode 的源码后我总结了一些常见问题和需要注意的细节这能帮你节省大量时间。6.1 性能与成本权衡问题Godmode 的自主循环会不会导致 API 调用成本激增解答这是最需要关注的点。Godmode 的四层令牌优化就是为了解决这个问题。但你需要有策略地使用明确迭代预算在指令中指定--iterations 10来限制最大尝试次数。善用“守卫”确保你的测试套件npm test、Linteslint .和构建命令npm run build是快速且可靠的。这些“守卫”会在每次修改后运行失败的守卫会立即触发回滚避免在错误的道路上浪费令牌。从简单任务开始先让 Godmode 处理范围明确、验证成本低的任务如优化一个已知瓶颈建立信心并观察成本。分析令牌日志定期查看.godmode/token-log.tsv识别哪些技能或任务消耗最大考虑为其编写更精确的## Activate When条件避免误触发。6.2 与现有工作流的集成问题Godmode 的自动提交和回滚会不会搞乱我的 Git 历史解答Godmode 的设计哲学是“Git 即记忆”它认为实验过程值得记录。但你可以这样管理使用特性分支在运行 Godmode 前创建一个新的特性分支如feat/godmode-optimize-api。所有实验性提交都会在这个分支上。完成后你可以选择用git merge --squash将多次优化提交合并成一个整洁的提交再合并到主分支。理解回滚机制Godmode 的DISCARD操作是git reset --hard HEAD。这意味着被丢弃的修改会从工作区和暂存区彻底消失但如果你在循环开始前没有提交那么最初的更改也可能会丢失。最佳实践是在启动 Godmode 前确保你的工作区是干净的git status无修改或者所有想保留的修改都已提交。6.3 技能触发的精确性问题我添加了一个自定义技能但 Godmode 似乎不触发它或者在不该触发的时候触发了。解答这几乎总是因为## Activate When部分写得不够精确。避免模糊描述不要写“当用户需要优化时”要写“当用户输入包含‘optimize’、‘speed up’、‘make faster’等词且上下文涉及 API 端点或数据库查询时”。利用探索者智能体的发现你可以使用{explorer_findings}之类的占位符具体语法需参考 Godmode 的上下文变量来匹配代码库特征。例如- The explorer agent finds files matching ‘*router*.js’ or ‘*controller*.js’。测试路由Godmode 提供了一个调试模式来查看路由决策。可以尝试在指令前加上GODMODE_DEBUG1环境变量来查看哪些技能被匹配到。6.4 处理模糊需求与“范围漂移”问题AI 有时还是会过度发挥添加一些我没要求的“改进”。解答这正是“作者纪律”和“预提交丢弃审计”要解决的问题。如果发现这种情况检查原则预读确保skills/principles/SKILL.md文件被正确加载。每个智能体在首次编辑前都应该读取它。审查丢弃审计日志在.godmode/目录下查看相关日志看是否有line_scope_drift类型的代码块被成功丢弃。如果没有可能是审计规则不够严格。强化你的指令在指令中更明确地排除某些修改。例如“优化/api/posts的查询性能只修改数据库查询相关代码不要改动身份验证中间件或日志格式。”6.5 平台适配与限制问题我在 Cursor 上使用能享受到所有功能吗解答Godmode 的核心技能在所有支持的平台Claude Code, Cursor, Codex, Gemini CLI, OpenCode上都能工作。但高级协调功能特别是多智能体并行执行依赖于底层平台是否支持后台/并行运行智能体。Claude Code和Codex通常支持最完整能实现真正的并行工作树。Cursor、Gemini CLI、OpenCode如果平台本身是顺序执行模型的那么 Godmode 的“并行”任务会退化为“顺序”执行。规划者仍然会分解任务但构建者会一个接一个地串行工作。这会影响完成复杂任务的速度但不会影响最终结果的质量。最后我的体会是Godmode 代表了一种更成熟的 AI 辅助编程范式。它不再把 AI 当作一个偶尔灵光一现的代码补全工具而是将其整合进一个严谨的、可测量的、持续改进的工程系统里。它要求开发者以更工程化的思维与 AI 协作定义清晰的目标、设立客观的度量标准、建立自动化的验证屏障。一开始你可能会觉得这种“纪律”有些束缚但一旦适应你会发现它带来的代码质量提升和心智负担的降低是显著的。它最适合那些重复性高、模式固定、且结果容易量化的工程任务比如性能调优、安全漏洞修复、遵循固定模式的 CRUD 代码生成等。对于高度创新、探索性极强的算法或架构设计它可能不是最佳工具但它能确保你在确定的道路上走得更稳、更快。