【交叉评测S1W3】MiniGame Studio — AI驱动的微信小游戏智能开发工作室 (yishan/MiniGame-Studios-S1W3) #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
评测基于完整仓库文件：README.md（35KB）、Specs.md（70KB）、CLAUDE.md（4KB）、settings.json、27个Agent定义、17条Rule、13个Hook、24份规范文档、12份微信API参考，以及实际读取的creative-director.md、gameplay-code.md、session-start.sh、coding-standards.md等核心文件内容。
项目理解
本项目是一个面向微信小游戏开发的AI Harness工程，品牌名为 MiniGame Studio。核心定位是：将AI（Claude Code插件框架）转化为一个具备完整组织架构的"虚拟游戏工作室"，通过27个专业Agent、71个Skill、17条Rule、13个Hook和24份规范文档，系统化地辅助开发者完成微信小游戏的完整开发流程。
核心架构：
• 三层级Agent体系：决策层（3个：创意总监、技术总监、制作人）→ 主管层（7个：美术总监、音频总监、游戏设计师、主程序员、QA主管、关卡设计师、系统设计师）→ 执行层（17个：各专项程序员、设计师、测试员、文案等）
• Rule系统：17条规则覆盖代码规范、资产规范、协作协议、平台约束（微信小游戏4MB包体限制、Canvas 2D渲染、ES6兼容性等）
• Hook系统：13个钩子覆盖会话启动/停止、Git提交验证、资产验证、包体大小检查、Agent日志等
• 文档体系：24份规范文档 + 12份微信API参考
项目基于Claude Code插件框架，目标用户是微信小游戏开发者/团队，核心命题是：通过AI Harness将"一个人+AI"的生产力提升到接近"一个小型游戏工作室"的水平。
项目亮点
2.1 组织架构设计极其专业且完整
27个Agent不是简单的"prompt列表"，而是按照真实游戏工作室的职能层级设计的：
• 决策层：创意总监（愿景守护、支柱冲突裁决）、技术总监（架构决策、技术债务管理）、制作人（排期、资源、里程碑）
• 主管层：美术总监、音频总监、游戏设计师、主程序员、QA主管、关卡设计师、系统设计师
• 执行层：AI程序员、美术程序员、玩法程序员、UI程序员、UX设计师、音效设计师、技术美术、多分辨率专家、网络程序员、性能分析师、原型师、QA测试员、文案、微信API专家、微信Canvas程序员、微信云专家、微信项目结构师
每个Agent都有：明确的职责边界、协作协议、升级条件、委托关系图、禁止事项、输出格式规范。这种"组织即架构"的设计在AI Harness领域非常罕见。
2.2 微信小游戏平台深度适配
项目不是"通用游戏开发工具"，而是深度绑定微信小游戏生态：
• 包体约束：4MB主包、20MB总包、2MB单文件限制，每条Rule和Hook都围绕这些约束设计
• 渲染层：Canvas 2D专用规范（脏矩形优化、离屏Canvas生命周期、纹理图集、对象池）
• API封装：所有wx.调用必须通过src/platform/封装层，禁止业务代码直接调用
• ES6兼容性：详细的iOS/JavaScriptCore vs Android/V8差异表，包含Proxy、Array.values()、eval()等禁用说明
• 内存管理：150MB上限、内存警告监听、场景切换资源释放
• 社交裂变：创意总监职责中明确包含"分享机制、排行榜竞争、好友互助"的社交裂变设计
• 变现设计：IAA（激励视频广告）和IAP（内购）的创意决策有专门的Rule（monetization-code.md）
2.3 Rule系统工程化程度高
17条Rule不是简单的"编码规范"，而是覆盖了：
• 代码规范：AI代码、游戏逻辑代码、渲染代码、UI代码、网络代码、原型代码、变现代码
• 资产规范：资产大小限制、数据文件规范
• 协作规范：协作协议（6.4KB，包含沟通协议、决策流程、冲突解决）、设计文档规范
• 平台约束：模块通信、多分辨率、微信API使用、微信项目配置
• 测试规范：测试标准（2KB）
每条Rule都有具体的正确/错误示例，如gameplay-code.md中展示了"数据驱动+deltaTime+事件总线" vs "硬编码+直连UI"的对比。
2.4 Hook系统实现完整的DevOps流水线
13个Hook覆盖了开发全生命周期：
• SessionStart：环境自检（bash/jq/python可用性）、Git状态检测、项目差距检测（5类差距：缺少微信必需文件、近乎空项目、有代码缺设计、缺生产管理目录、有assets缺规范）、活跃会话状态恢复
• SessionStop：会话总结、未完成任务检测、Git状态检查、TODO/FIXME统计
• PreToolUse：Git提交验证（检查提交信息格式、关联Sprint/Bug）、Git推送验证
• PostToolUse：资产验证（尺寸/格式/大小）、微信项目验证（game.json/project.config.json字段完整性）、Skill变更验证、包体大小检查（4MB/20MB/2MB限制）
• Notification：Agent切换通知、任务完成通知
• Pre/PostCompact：会话压缩前后的上下文管理
• SubagentStart/Stop：Agent调用日志记录
这些Hook用bash脚本实现，包含完整的错误处理、路径检测、JSON解析（jq）、条件判断。
2.5 规范文档体系极其详尽
24份规范文档覆盖了：
• 编码标准（9KB）：微信小游戏JavaScript规范、内存管理、ES6兼容性、Canvas 2D、wx API调用、数据驱动、代码结构、云开发、包体约束
• 协作规则（18.5KB）：Agent间协作协议、冲突解决、升级流程、决策框架
• 目录结构（10KB）：完整的项目目录规范（src/、design/、production/、docs/、assets/等）
• 上下文管理（4.8KB）：会话状态、活跃任务、上下文持久化
• 评审工作流（5.8KB）：代码评审、设计评审、测试评审流程
• Hooks参考（7.6KB）：所有Hook的触发条件、功能说明、配置方式
• Rules参考（13KB）：所有Rule的适用路径、核心约束、示例
• Skills参考（7.8KB）：71个Skill的分类、用途、触发方式
• 微信API速查（9.2KB）：wx API调用规范、常见陷阱
• 微信 pitfalls（7.5KB）：微信小游戏开发常见陷阱和解决方案
• Agent-Tool映射（4.5KB）：每个Agent可用工具的映射表
• Workflow目录（13.9KB YAML）：完整的工作流目录，定义了所有工作流
2.6 settings.json配置极其精细
• 权限系统：明确的allow/deny列表（允许git操作、ls、node、python、mkdir；禁止rm -rf、git push --force、chmod 777、.env文件操作）
• 模型版本锁定：sonnet/haiku/opus三层模型映射
• Hook配置：完整的matcher匹配规则（如"Bash(git commit)"触发validate-commit.sh）
• 工具权限：defaultAllowedTools（Read/Glob/Grep）和defaultDisallowedTools（Bash(rm *)等）
• npm限制：仅开放给cloudfunctions/目录，game代码禁止npm依赖
• 注释充分：每个配置项都有详细的注释说明
2.7 产品价值定位清晰
README和Specs中明确回答了：
• 为谁：个人开发者、小团队、原型验证者
• 解决什么：微信小游戏开发的技术门槛高、平台约束多、调试困难、包体限制严格
• 如何不同：不是"AI写代码"，而是"AI扮演完整工作室"——有组织架构、有协作协议、有质量门禁
• 成功标准：从0到可运行原型的时间缩短、代码质量提升、平台合规性保证
当前不足
3.1 缺少可运行的演示/原型（核心问题）
src/目录下只有CLAUDE.md（6KB），没有任何实际的游戏代码、assets、配置文件。这意味着：
• 评审方无法看到"一个Agent实际运行后产出的代码是什么样的"
• 无法验证27个Agent协作流程是否真的能产出可编译的微信小游戏
• 无法验证Hook系统（如包体大小检查、资产验证）在实际项目中的效果
• 无法验证Rule系统（如"禁止硬编码"）是否能被AI实际遵守
建议：至少提供一个完整的"Hello World"微信小游戏示例（包含game.json、project.config.json、入口JS、至少一个场景），展示Agent从0到可运行项目的完整流程。
3.2 缺少自动评测和验证机制
虽然Specs.md中提到了"验证驱动开发"和"自动化测试规则"，但：
• 没有eval.mjs或类似的自动评测脚本
• 没有固定输入→预期输出的测试用例（如"输入'创建一个消除类游戏'，期望产出包含哪些文件"）
• 没有Agent输出的质量评分机制（如"代码是否符合gameplay-code.md规范"的自动检查）
• 没有端到端的工作流验证（如从/start到/ship的完整流程是否能在30分钟内完成）
建议：增加tests/目录，包含至少5
10个端到端测试用例，覆盖核心工作流（如快速设计、原型开发、迭代优化）。5个已实际测试过的多Agent协作场景及其结果。3.3 Agent协作的"涌现行为"未经验证
27个Agent的协作协议设计得非常详细，但：
• 实际运行时，Agent之间的上下文传递是否顺畅？（如创意总监的"支柱决策"是否能正确传递给游戏设计师和美术总监）
• 冲突解决机制（升级条件表）在实际中是否有效？（如当游戏设计师和美术总监对UI风格有分歧时，是否真的会上报到创意总监）
• 多层Agent调用（决策层→主管层→执行层）的延迟和token消耗是否可接受？
• 当多个Agent同时修改同一文件时，是否有冲突检测和合并机制？
建议：在README中补充"已验证的协作场景"章节，列出至少3
3.4 缺少用户上手路径和教程
对于新用户（微信小游戏开发者），面对27个Agent、71个Skill、17条Rule、13个Hook，入门门槛极高：
• 没有"5分钟快速开始"教程
• 没有"第一个小游戏"的step-by-step引导
• 没有常见场景的命令速查表（如"如何创建一个消除类游戏"、"如何添加排行榜"）
• 没有故障排查指南（如"Agent不遵守Rule怎么办"、"Hook报错如何处理"）
建议：增加docs/getting-started.md和docs/tutorials/目录，包含至少3个完整教程（从空项目到可运行游戏）。
3.5 微信小游戏生态的时效性风险
Specs和文档中引用的微信小游戏API和限制（如4MB主包、ES6兼容性表）是基于当前（2026年5月）的平台状态。但：
• 微信小游戏平台规则可能变化（如包体限制调整、新API发布、旧API废弃）
• 没有版本化机制来跟踪平台规则的变化
• 没有自动检测平台规则变化的机制
建议：在文档中标注所有平台相关约束的"最后验证日期"，并设计一个定期更新的流程。
3.6 缺少与其他AI工具的对比
项目声称"不是AI写代码，而是AI扮演完整工作室"，但：
• 没有与Cursor、GitHub Copilot、Cline等AI编程工具的对比分析
• 没有与Lovable、v0等AI应用构建工具的对比
• 没有说明"27个Agent"相比"1个通用Agent+详细prompt"的优势在哪里
建议：增加docs/competitor-analysis.md，对比现有AI开发工具，明确MiniGame Studio的差异化价值。
总体结论
这是一个架构设计极其专业、文档体系极其完备的AI Harness工程，但当前阶段更偏向"完整的AI开发框架设计规范"，而非"可验证的AI开发工具"。
项目最大的优势在于：
组织架构的真实感：27个Agent按照真实游戏工作室的职能层级设计，每个Agent都有明确的职责、协作协议、升级条件，这种"组织即架构"的设计理念在AI Harness领域非常独特。
微信小游戏的深度适配：不是通用工具，而是深度绑定微信小游戏生态（4MB包体、Canvas 2D、ES6兼容性、社交裂变、IAA/IAP变现），平台专业性极强。
工程化程度高：Rule系统（17条）、Hook系统（13个）、settings.json配置、规范文档体系（24份）都体现了高度的工程化思维。
项目当前最需要解决的问题是：
缺少可运行的演示项目：src/目录为空，评审方无法验证27个Agent协作是否真的能产出可编译的微信小游戏。
缺少自动评测机制：没有端到端测试用例，无法验证Agent输出是否符合Rule规范。
缺少用户上手路径：面对27个Agent和71个Skill，新用户的入门门槛极高。
如果能在下一轮迭代中补充一个完整的演示项目（如"消除类微信小游戏"的完整开发流程）和自动评测脚本，该项目在AI Harness赛道的竞争力将显著提升。
对反馈的理解
感谢反馈。以下是对各项反馈的理解。
1、"缺少可运行的演示/原型"
半决赛的阶段要求是交付一个具备交互能力的智能体，而 MiniGame Studio 当前已经完全可以交互使用——克隆后运行
/start，从 0 开始跟着 Agent 引导完成一个微信小游戏项目。欢迎大家克隆到本地实际体验。这套 Harness 工程也已经投入到了我实际的游戏开发中。目前游戏正在优化阶段，同时在微信官方审核流程中，后续可以直接提供二维码供大家扫码游玩。
更重要的是，我相信只有通过一个个真实项目的打磨与反馈，才能持续优化当前的 AI Harness 工程。这种"反馈→优化→再反馈"的迭代过程，本身就是 Harness 工程的生命力所在，要一直进行下去。
2、"缺少自动评测和验证机制"
项目已经建立了多层级的自动评测与验证体系，贯穿研发管线全流程。这套体系不是事后补救的测试环节，而是嵌入到每个开发阶段中的自动化质量护栏。
Hook 层：事件驱动的自动门禁
13 个事件驱动 Hook 在关键节点自动触发验证，无需人工干预，以下是几个举例：
validate-wx-project：在写入game.json/project.config.json时自动校验微信项目结构完整性、JSON 合法性、ES6 转译设置、分包配置等check-package-size：自动校验主包 ≤ 4MB、总包 ≤ 20MB、单文件 ≤ 2MB 等平台硬约束validate-commit/validate-push：Git 操作前自动执行代码规范检查，拦截未通过验证的提交validate-assets：美术资源写入时自动检查命名规范、格式合规、尺寸限制validate-skill-change：Skill 文件变更时自动校验契约完整性，防止框架退化Skill 层：标准化评测工作流
比如，质量保障类 Skill（9 个）覆盖从单元测试到生产验证的完整链路：
qa-plantest-setupsmoke-checkregression-suitesoak-testtest-evidence-reviewtest-flakinessci-integrationtest-helpersAgent 层：分层次审查体系
比如：
/gate-check由三个总监 Agent 并行审查，任一未通过则阻塞推进这套体系的核心理念是：评测不是独立环节，而是嵌入到每一次文件写入、每一次阶段推进中的自动化事件响应。Hook 让你写代码时自动校验，Skill 让你主动触发深度审查，Agent 让你在关键节点获得专家评审——三层协同，形成完整的自动化质量闭环。
3、"缺少用户上手路径和教程"
MiniGame Studio 已经内置了完善的引导机制：
/start引导式入门：根据项目当前状态智能路由，从零基础到已有成果都有对应路径/help上下文感知帮助：读取当前项目阶段，动态推荐下一步操作project-stage-detect自动审计：全面扫描项目状态，生成分优先级的缺口清单新用户不需要一次性理解所有概念——Agent、Skill、Rule、Hook、ADR、Epic、Story、GDD 这些概念分散在研发管线的不同阶段，跟着
/start的互动走，大模型会根据 Harness 的配置自动问答、自动引导。概念数量多，是因为这套体系完整覆盖了小游戏从创意到发布的全部环节——这是体系完整度的代价，而不是使用门槛。玩家只要顺着互动走下去就行了。
另外，有任何问题或疑惑，你都可以直接在输入框里询问。大模型会把当前项目的各种细节都告诉你。
workflow-catalog.yaml已经完整标注了每个 Skill 所处的研究阶段、由哪个 Agent 执行、是 required 还是可选。而 Skill 文件本身是 AI Native 的——Agent 会按需加载。开发者不需要自己去翻阅 71 个 SKILL.md 文件来决定该用哪个。开发者用自然语言告诉 Agent 想做什么——「我想做个什么什么样的游戏」「各种各样的需求」——Agent 会在 Harness 框架的引导下，自动选择合适的 Skill 来响应。4、"微信小游戏生态的时效性风险"
这个担忧是合理的。微信小游戏平台确实在持续迭代——API 的新增与废弃、包体限制的调整、基础库版本的升级都是客观存在的风险。项目的应对策略分为现状机制和演进方向两个层面。
现状：已落地的时效性保障
版本锁定：所有 wx API 参考文档（
docs/wx-reference/下 12 份文档）均标注"基于基础库 3.5.0 验证"，明确了当前参考基准的时间锚点。这不是一个模糊的"支持微信小游戏"声明，而是精确到基础库版本的 API 契约。锁定一个"过去的稳定版本"而非盲目追最新版，是微信小游戏开发的通用实践，背后有两个深层原因：
兼容性覆盖：微信小游戏的用户设备分布极为广泛——很多用户的手机型号老旧、微信版本停留在较旧的迭代上。如果开发时直接使用最新版基础库的 API，这些用户可能根本无法运行游戏。微信官方对老版本基础库提供了充分的向下兼容，因此选取一个经过市场验证的、覆盖绝大多数用户设备的稳定版本（如基础库 3.5.0），是最大化用户触达的务实策略。
API 稳定性：最新版基础库中的 API 可能存在未充分验证的边缘行为或后续调整。锁定一个已发布一段时间、被大量开发者验证过的稳定版本，意味着参考文档中的 API 签名、参数约束、返回值格式都是可靠的，不会出现"照官方最新文档写出的代码在真机上表现不一致"的情况。
平台层隔离：项目强制所有
wx.*API 调用必须通过src/platform/封装层，业务代码禁止直接调用平台 API。这意味着当平台规则变化时，只需要修改封装层即可适配——不需要改动遍布全项目的业务逻辑。wx-api-specialist 专职 Agent：技术搭建阶段有专门负责平台合规审查的 Agent，在 ADR 审批时逐条检查平台兼容性，确保架构决策不依赖已被废弃或即将变更的 API。
wx-api-usageRule：路径绑定规则在每次涉及 wx API 的代码写入时自动触发，强制检查调用是否符合当前参考文档的契约。演进方向：定期更新流程
项目目前缺少"自动检测平台规则变化"的机制——这确实应该纳入后续迭代。理想的方案是：
wx-api-specialistAgent 对照微信官方最新文档，逐条审计docs/wx-reference/中的 API 参考、禁区和性能约束这一点记录为待办事项，感谢指出。
5、"缺少与其他 AI 工具的对比"
基础定位的区分
Cursor、GitHub Copilot、Claude Code 等属于底层基础。
MiniGame Studio 作为AI Harness 工程，是在底层基础之上构建的一层"控制框架"。它不是替代底层，而是通过 Agent 编排、Skill 工作流、Rule 约束、Hook 自动化四套体系，让 AI 能够在游戏研发这个复杂的工程领域里安全、可靠、可审计地完成工作。
从"提示词工程"到"Harness 工程"：AI 辅助开发的代际跃迁
要理解为什么需要一套完整的 Harness 框架，需要先看懂 AI 辅助开发范式的演进路径：
MiniGame Studio 正是第三代范式的实践——它不是在写更好的 prompt，而是在构建一套让 prompt 能被系统化管理、Agent 能被编排协作、行为能被实时约束、质量能被自动验证的完整框架。
"1 个通用 Agent + 详细 prompt"为什么不够？
有人可能会问：把 27 个 Agent 的知识、71 个 Skill 的流程、17 条 Rule 的约束全部写进一个超长的系统 prompt 里，用一个通用 Agent 来执行，不是更简单吗？
这条路在工程实践中已经被证明行不通：
这正是 AI Harness 工程诞生的原因——把"一个超大 prompt"拆解为"一套可编排的控制系统"：Skill 按阶段懒加载（不影响上下文窗口）、Rule 按文件路径精确触发（不产生指令冲突）、Agent 按角色独立配置（确保角色专注）、Hook 在事件节点自动执行（弥补 prompt 无法覆盖的运行时约束）。
提前设计好 Agent 和 Skill，与让大模型自己开子 Agent 执行有什么区别？
这是一个关键的设计决策。让大模型在运行时根据任务动态创建子 Agent（类似"自我分拆"），与提前设计好完整的 Agent/Skill 体系，两者有本质区别：
wx-api-specialistAgent 经过了精心设计，系统提示词中包含了所有 wx API 的能力边界、常见陷阱、兼容性矩阵；而动态生成的"API 检查子 Agent"只有一个简短的任务指令，无法承载同等深度的领域知识。打个比方：预设计的 Agent 体系像是一家有明确岗位编制和 SOP 的公司，每个人知道自己负责什么、上下游是谁、出现问题时怎么升级；而动态创建子 Agent 像是每次接到项目临时招人——短期看灵活，长期看交付质量、协作效率和知识积累都无法保障。
直接使用 AI Coding 工具落地商业化项目的实际困境
用 Cursor 或 Claude Code 直接完整开发一个工程化项目，会遇到各种问题，以下是几个说明：
pre-compact/post-compactHook 自动 dump 和恢复会话状态，配合resume-storySkill 实现会话连续性。story-done8 阶段审查流程、tech-debt定期扫描来解决。27 个 Agent 相比 1 个通用 Agent 的优势
这不是简单的"数量堆砌"。27 个 Agent 按三层级架构组织。比如：
wx-canvas-programmer的上下文里满载 Canvas 2D 渲染最佳实践和脏矩形优化策略，economy-designer的上下文聚焦 IAA/IAP 变现模型——这些专精知识不可能塞进一个通用 prompt 里而不超过上下文窗口MiniGame Studio 是在构建一个专业领域细分领域的 AI Harness 工程：如何让 AI 在一个有严格平台约束、性能预算、商业要求的垂直领域里，完成从创意到交付的全流程工程任务。
再次感谢这些反馈。每一个问题的审视都在帮助 MiniGame Studio 变得更完整、更扎实。