Godmode 快速入门

这是什么？适合谁？

Godmode 是给 AI coding agent 的可组合工程工作流目录：你的 agent 已经会写代码，Godmode 教它”如何做工程”——编辑前先设计、声称完成前先测试、独立评审、用新鲜证据验证。它是 planning / TDD / code-review 等生产级 Agent Skills 的组合集合，85 个 fork 对 90 star 的高占比说明用户是真的在拿它干活。

适合人群：觉得 coding agent “下手太快、收工太草” 的开发者、想给 Agent 装上工程纪律的团队、研究 Agent 行为治理的工程师。 使用前提：任一支持 skills/config 加载的 coding agent（Claude Code / Codex / Cursor 等）、Python 环境。

快速上手（3 步）

第一步：安装

git clone https://github.com/thiientv/godmode
# 按仓库 README 将 skills 目录安装到你的 agent（支持 Claude Code 等，含中英双语文档）

第二步：理解行为转变

没有 Godmode 的 Agent：“Build authentication” → 立刻写代码 → 测试/安全/集成最后补 → “看起来完成了”。 装上 Godmode 后：“Build authentication” → 方案设计 → API + 数据库 + 安全专业能力介入 → 实现计划 → 按计划实现 → 证据验证 → 才宣告完成。

第三步：给它一个任务验收

选一个你熟悉的认证/CRUD 任务，让 Agent 完整跑一遍，对比产出：是否有设计文档、测试是否先行、结论是否附验证证据。

初级用法

• 按需启用工作流：planning（先设计后动手）、TDD（先测试后实现）、code-review（独立评审）等可单独装载，不必全家桶。
• 中英双语：README 提供 English / 简体中文双版本，中文团队接入无障碍。
• 看 catalog：每个 skill 是一段可读的工作流定义，读目录即知道它会改变 Agent 的哪些行为。

高级玩法

1. 流水线组合：planning → TDD → code-review 三连，让 Agent 从”需求”到”已验证实现”全程有纪律。
2. 团队规范固化：把团队的工程规范（分支策略、测试覆盖率门槛、评审清单）改写进 Godmode 的 skill 定义，新成员的 Agent 自动继承规范。
3. 行为对照实验：同一任务开两个会话（带/不带 Godmode），diff 产出质量与返工率，量化技能包价值。

常见踩坑（5 条）

踩坑 1：期望开箱即变强

• 现象：装完觉得提升不明显
• 原因：skills 是行为约束，不是能力注入；弱模型+好纪律仍有限
• 解决：搭配强模型使用，并在提示词里点名调用对应工作流

踩坑 2：流程变慢

• 现象：小任务也走完整设计+测试+评审
• 原因：全家桶默认启用
• 解决：小改动只挂 code-review，大特性再开 planning + TDD

踩坑 3：与既有 skills 冲突

• 现象：Agent 行为混乱
• 原因：同类工作流（自带的 plan mode）与 Godmode 叠加
• 解决：同类只留一套，禁用重复项

踩坑 4：证据验证被跳过

• 现象：Agent “声称”测过了
• 原因：验证 skill 未启用或提示词未强调
• 解决：明确要求”结论必须附可复现的验证命令与输出”

踩坑 5：中文团队直接用英文版

• 现象：理解偏差
• 原因：部分 skill 描述只有英文
• 解决：以 README.zh-CN.md 为索引，关键 skill 翻译后纳入内部版本

FAQ（5 个常见问题）

Q1：Godmode 免费吗？ A：MIT 开源免费。

Q2：它是独立的 Agent 吗？ A：不是——它是装在你现有 coding agent（Claude Code / Codex / Cursor 等）上的工程行为技能包。

Q3：和 Claude Code 自带的 plan mode 重复吗？ A：有重叠但更系统：Godmode 覆盖设计、TDD、评审、证据验证的完整链路，且跨 agent 通用；同类环节建议二选一避免叠加。

Q4：支持哪些 agent？ A：任何能加载 skills/config 的 coding agent；硬性 hooks 类能力以各 agent 支持为准。

Q5：会显著增加 token 消耗吗？ A：会增加（更多推理与验证回合），换来的是返工率下降；小任务建议裁剪启用。

小技巧（5 条）

1. 从 code-review 切入：单挂评审工作流见效最快、侵入最小。
2. 大特性前显式说 “plan first”：触发 planning skill 的可靠方式。
3. 验收看证据：养成”没有验证输出不算完成”的团队口径。
4. fork 定制：按团队规范 fork 后维护自己的版本。
5. 观察行为 diff：保留同一任务的带/不带产出对比，向团队证明价值。

进阶学习建议

• 通读 catalog 中每个 skill 的工作流定义，理解”行为注入”式 prompt 工程的设计模式
• 把 TDD skill 与你现有测试栈（pytest/vitest）结合，定制”先写失败测试”的团队版本
• 研究 code-review skill 的”独立评审”机制与多 Agent 评审（如 eve Software Factory 的 Reviewer 工站）的异同
• 用行为对照实验数据（返工率、缺陷率）为团队建立 Agent 使用规范

参考链接

• Godmode GitHub 仓库
• Godmode 官方文档站

本文基于公开资料于 2026-08-17 整理，社区指标反映 GitHub 公开数据。独立实测未进行，功能和配置项可能随版本更新而变化，请以官方文档为准。