yishan/MiniGame-Studios
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

【S1W2 交叉评测】项目评测意见 #1

New issue
Open
opened 2026-05-15 21:28:05 +08:00 by zzzzz · 1 comment
zzzzz commented 2026-05-15 21:28:05 +08:00
Copy link

对 MiniGame Studio 项目组的评价

你们的项目展现了极强的工程化野心和对小游戏生态的深度理解。将 AI 开发从简单的提示词层面提升到 Harness Engineering（控制框架）高度，是解决 Vibe Coding 逻辑坍塌的有效方案。

  1. 亮点分析
    你们对微信小游戏底层约束的梳理非常到位。Readme 中列出的 API 禁区（如禁用 Proxy、Android 兼容性风险等）不仅是技术细节，更是实际交付中决定生死的分水岭。通过 12 条 Rule 和 14 个 Hook 建立的自动化护栏，确实能从根本上规避 AI 生成代码时的“环境幻觉”。
  2. 架构评价
    你们提出的三层级 Agent 协作体系（决策/主管/执行）逻辑非常清晰。特别是 design/registry/entities.yaml 这种“唯一真相来源”的设计，体现了资深游戏开发的思维，能有效解决多 Agent 协作时的配置同步问题。
  3. 挑战与疑问
    关于你们的方案，有几个实际落地的问题希望交流：

链路损耗问题：27 个 Agent 和 60 个 Skill 的配置非常庞大，在实际运行 Claude Code 时，复杂的上下文管理是否会带来巨大的 Token 消耗或响应延迟？
灵活性担忧：如此精密且标准化的 7 阶段研发管线，在处理玩法极度创新的“非标”游戏时，Agent 体系是否具备足够的适应性，还是会因为规则太死而限制创意的发挥？
环境依赖：目前架构高度绑定 Claude Code 插件，对于没有该环境的开发者来说，这套复杂的 YAML 和配置文件体系是否有降级使用的方案？

总结：
你们提交的不仅是一个小游戏项目，更是一套成熟的小游戏工业化研发标准。这种对“过程质量”的极致追求，是目前很多 AI 项目所缺失的。

对 MiniGame Studio 项目组的评价 你们的项目展现了极强的工程化野心和对小游戏生态的深度理解。将 AI 开发从简单的提示词层面提升到 Harness Engineering（控制框架）高度，是解决 Vibe Coding 逻辑坍塌的有效方案。 1. 亮点分析 你们对微信小游戏底层约束的梳理非常到位。Readme 中列出的 API 禁区（如禁用 Proxy、Android 兼容性风险等）不仅是技术细节，更是实际交付中决定生死的分水岭。通过 12 条 Rule 和 14 个 Hook 建立的自动化护栏，确实能从根本上规避 AI 生成代码时的“环境幻觉”。 2. 架构评价 你们提出的三层级 Agent 协作体系（决策/主管/执行）逻辑非常清晰。特别是 design/registry/entities.yaml 这种“唯一真相来源”的设计，体现了资深游戏开发的思维，能有效解决多 Agent 协作时的配置同步问题。 3. 挑战与疑问 关于你们的方案，有几个实际落地的问题希望交流： 链路损耗问题：27 个 Agent 和 60 个 Skill 的配置非常庞大，在实际运行 Claude Code 时，复杂的上下文管理是否会带来巨大的 Token 消耗或响应延迟？ 灵活性担忧：如此精密且标准化的 7 阶段研发管线，在处理玩法极度创新的“非标”游戏时，Agent 体系是否具备足够的适应性，还是会因为规则太死而限制创意的发挥？ 环境依赖：目前架构高度绑定 Claude Code 插件，对于没有该环境的开发者来说，这套复杂的 YAML 和配置文件体系是否有降级使用的方案？ 总结： 你们提交的不仅是一个小游戏项目，更是一套成熟的小游戏工业化研发标准。这种对“过程质量”的极致追求，是目前很多 AI 项目所缺失的。
yishan commented 2026-05-15 23:34:29 +08:00
Owner
Copy link

感谢反馈，我对反馈的理解是：

问题一：链路损耗问题

27 个 Agent 和 60 个 Skill 的配置非常庞大，在实际运行 Claude Code 时，复杂的上下文管理是否会带来巨大的 Token 消耗或响应延迟？

理解

Agent 定义文件的预加载：27 个 Agent 定义文件（每个约 50-170 行 Markdown）共计约 3,000+ 行。但每个 Agent 只在被 Task 工具调用时才加载其定义文件到子 Agent 的独立上下文中，并非全部 27 个同时驻留。

Skill 定义文件的按需加载：60 个 SKILL.md 同样遵循"用时才加载"的策略。例如执行 /dev-story 时，只加载 dev-story/SKILL.md 以及其引用的 Story 文件、GDD、ADR 等，不会一次性加载全部 60 个 Skill。

上下文预算制度：项目明确定义了三级 Token 预算——轻量（~3k）、中量（~8k）、重量（~15k），按任务复杂度分配。

模型分层降本：Haiku 处理只读状态检查，Sonnet 处理默认工作，Opus 仅用于高风险阶段门裁决（约 4-5 个场景），成本逐级收敛。

已内置的缓解策略

  • 增量节写入：多节文档逐节写入磁盘后，讨论上下文即可安全压缩。
  • 主动压缩：60-70% 上下文使用率时主动 /compact，而非被动应对。
  • 子 Agent 委派：研究/探索性任务委派给子 Agent 独立上下文执行，只返回摘要。
  • 文件即记忆：所有决策写入 active.md，压缩后可恢复；对话是临时的，文件是持久的。
  • pre-compact / post-compact Hook：压缩前自动 dump 当前关键状态，压缩后提醒恢复。
  • 自然压缩点：节写入文件后、提交后、完成任务后、开始新话题前。

总结

项目已经做了完善的上下文工程优化，不是"无脑加载全部配置"。实际运行中，每次会话启动时加载的项目引导上下文约在 5-8k tokens，后续按需增量加载。

问题二：灵活性担忧

如此精密且标准化的 7 阶段研发管线，在处理玩法极度创新的"非标"游戏时，Agent 体系是否具备足够的适应性，还是会因为规则太死而限制创意的发挥？

理解与反馈

用户驱动的协作协议：核心模式为「提问 → 选项 → 决策 → 起草 → 审批」。Agent 是顾问，用户是创意总监，拥有全部最终决策权。Agent 必须提供至少 2 个选项及其利弊，这从根本上保证了人类始终掌控创意方向，管线只是服务工具。

跳过/可选步骤设计：每个阶段中存在 required: false 的可选步骤（如阶段 1 的 wx-market-fit、阶段 4 的 prototype）。阶段门禁的判定是建议性的——"永不阻塞用户推进，记录风险，让用户决定。"

丢弃式原型机制：prototypes/ 与 src/ 物理隔离，不污染正式代码库。原型代码规范放宽（prototype-code Rule 明确"代码标准放宽但必须可独立运行"），专为验证高风险创新机制存在。

Brainstorm 阶段的开放性：支持完全自由探索模式（/brainstorm open），MDA 框架引导但不强制品类，每个概念必经微信平台适配性评估但不做创意否决。

轻量变更通道：quick-design Skill 提供轻量级设计变更，quick-specs/ 目录专门存放小型设计变更，避免每次小调整都走完整 GDD 周期。

总结

框架设计本质上不限制创意，人类始终保有最终决策权是核心安全阀。对于高度创新的非标游戏，使用 /prototype 快速验证核心机制；阶段门禁的 CONCERNS 判定允许带着风险推进；人类用户始终可以跳过某个步骤。

问题三：环境依赖

目前架构高度绑定 Claude Code 插件，对于没有该环境的开发者来说，这套复杂的 YAML 和配置文件体系是否有降级使用的方案？

理解与反馈

Claude Code 是一个免费软件，安装简单，配合 CC Switch 可以接入各种 AI 大模型。实际使用中搭配 Claude Code + DeepSeek V4 的组合，搭建简单。配合 DeepSeek V4 的高缓存命中率，性价比很高，可以直接投入到实际开发中。

Claude Code 是行业领先的 AI 编码工具，这也是选择它来构建 Harness 工程的原因。如今的编码 IDE 大同小异，不管是国外的 Open Code 和 Codex等等，还是国内的 Trae 和 Qoder等等，支持的功能越来越全，后续可以针对性去适配。重要的是这套针对小游戏领域的 AI Harness 构造理念。

总结

当前架构锁定 Claude Code 并非限制，而是基于其行业领先地位的最优选择。Claude Code 免费、易安装、可接入多种模型（如 DeepSeek V4），实际使用成本可控。Harness 工程的核心价值在于方法论层面——7 阶段管线、三层级 Agent 架构、协作协议——这些思想资产可迁移到任何编码平台，后续可针对性适配。

# 感谢反馈，我对反馈的理解是： --- ## 问题一：链路损耗问题 > 27 个 Agent 和 60 个 Skill 的配置非常庞大，在实际运行 Claude Code 时，复杂的上下文管理是否会带来巨大的 Token 消耗或响应延迟？ ### 理解 **Agent 定义文件的预加载**：27 个 Agent 定义文件（每个约 50-170 行 Markdown）共计约 3,000+ 行。但每个 Agent 只在被 `Task` 工具调用时才加载其定义文件到子 Agent 的独立上下文中，并非全部 27 个同时驻留。 **Skill 定义文件的按需加载**：60 个 SKILL.md 同样遵循"用时才加载"的策略。例如执行 `/dev-story` 时，只加载 `dev-story/SKILL.md` 以及其引用的 Story 文件、GDD、ADR 等，不会一次性加载全部 60 个 Skill。 **上下文预算制度**：项目明确定义了三级 Token 预算——轻量（~3k）、中量（~8k）、重量（~15k），按任务复杂度分配。 **模型分层降本**：Haiku 处理只读状态检查，Sonnet 处理默认工作，Opus 仅用于高风险阶段门裁决（约 4-5 个场景），成本逐级收敛。 ### 已内置的缓解策略 - **增量节写入**：多节文档逐节写入磁盘后，讨论上下文即可安全压缩。 - **主动压缩**：60-70% 上下文使用率时主动 `/compact`，而非被动应对。 - **子 Agent 委派**：研究/探索性任务委派给子 Agent 独立上下文执行，只返回摘要。 - **文件即记忆**：所有决策写入 `active.md`，压缩后可恢复；对话是临时的，文件是持久的。 - **pre-compact / post-compact Hook**：压缩前自动 dump 当前关键状态，压缩后提醒恢复。 - **自然压缩点**：节写入文件后、提交后、完成任务后、开始新话题前。 ### 总结 项目已经做了完善的上下文工程优化，不是"无脑加载全部配置"。实际运行中，每次会话启动时加载的项目引导上下文约在 5-8k tokens，后续按需增量加载。 --- ## 问题二：灵活性担忧 > 如此精密且标准化的 7 阶段研发管线，在处理玩法极度创新的"非标"游戏时，Agent 体系是否具备足够的适应性，还是会因为规则太死而限制创意的发挥？ ### 理解与反馈 **用户驱动的协作协议**：核心模式为「提问 → 选项 → 决策 → 起草 → 审批」。Agent 是顾问，用户是创意总监，拥有全部最终决策权。Agent 必须提供至少 2 个选项及其利弊，这从根本上保证了人类始终掌控创意方向，管线只是服务工具。 **跳过/可选步骤设计**：每个阶段中存在 `required: false` 的可选步骤（如阶段 1 的 `wx-market-fit`、阶段 4 的 `prototype`）。阶段门禁的判定是建议性的——"永不阻塞用户推进，记录风险，让用户决定。" **丢弃式原型机制**：`prototypes/` 与 `src/` 物理隔离，不污染正式代码库。原型代码规范放宽（`prototype-code` Rule 明确"代码标准放宽但必须可独立运行"），专为验证高风险创新机制存在。 **Brainstorm 阶段的开放性**：支持完全自由探索模式（`/brainstorm open`），MDA 框架引导但不强制品类，每个概念必经微信平台适配性评估但不做创意否决。 **轻量变更通道**：`quick-design` Skill 提供轻量级设计变更，`quick-specs/` 目录专门存放小型设计变更，避免每次小调整都走完整 GDD 周期。 ### 总结 框架设计本质上不限制创意，人类始终保有最终决策权是核心安全阀。对于高度创新的非标游戏，使用 `/prototype` 快速验证核心机制；阶段门禁的 CONCERNS 判定允许带着风险推进；人类用户始终可以跳过某个步骤。 --- ## 问题三：环境依赖 > 目前架构高度绑定 Claude Code 插件，对于没有该环境的开发者来说，这套复杂的 YAML 和配置文件体系是否有降级使用的方案？ ### 理解与反馈 Claude Code 是一个免费软件，安装简单，配合 CC Switch 可以接入各种 AI 大模型。实际使用中搭配 Claude Code + DeepSeek V4 的组合，搭建简单。配合 DeepSeek V4 的高缓存命中率，性价比很高，可以直接投入到实际开发中。 Claude Code 是行业领先的 AI 编码工具，这也是选择它来构建 Harness 工程的原因。如今的编码 IDE 大同小异，不管是国外的 Open Code 和 Codex等等，还是国内的 Trae 和 Qoder等等，支持的功能越来越全，后续可以针对性去适配。**重要的是这套针对小游戏领域的 AI Harness 构造理念。** ### 总结 当前架构锁定 Claude Code 并非限制，而是基于其行业领先地位的最优选择。Claude Code 免费、易安装、可接入多种模型（如 DeepSeek V4），实际使用成本可控。Harness 工程的核心价值在于方法论层面——7 阶段管线、三层级 Agent 架构、协作协议——这些思想资产可迁移到任何编码平台，后续可针对性适配。
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
yishan/MiniGame-Studios#1
No description provided.