工具与服务
HAKUROKUDO 不只做游戏，也把发布、文案说明和外部报告里反复出现的动作沉淀成工具。这里展示的是已经公开的工作流样本，以及它们各自解决的问题。
游戏画面生成控制系统：先写 SCREEN_BRIEF，再锁 LAYOUT_CONTRACT 和 prompt，出图后用 IMAGE_REVIEW 判定 pass / revise / redo，最后形成开发交接说明。
用于把一个已经完成的游戏、工具、文章或产品介绍整理成站内页面：包含主图、入口链接、文案结构、政策链接和上线前检查。它存在的原因很简单，官网更新如果总是临时拼页面，就很难保持结构一致。
把一段游戏教程或新手引导拆开来看，判断它到底是在解释目标、解释动作，还是只是在制造噪音。这个流程更接近编辑工作台，而不是炫技式 AI 演示，重点在于给出能落地修改的结论。
这类页面展示的是 HAKUROKUDO 如何把一个可独立购买或体验的轻量产品公开成清楚页面：说明输入是什么、输出是什么、适合谁、结果如何保存或删除，以及用户为什么要在这个页面停留而不是只看一句广告语。
使用原则
我们把“工具与服务”单独列出来，是为了避免官网只剩一串游戏链接。一个站点如果既承载项目发布，也承载说明、运营和协作入口，就需要把这些职能分开，不然玩家会看不懂哪些页面是产品，哪些页面是工具，哪些页面只是开发侧的内部语汇。
因此，只有满足两个条件的内容才会被放到这个栏目：它确实对应重复出现的工作流程，而且页面本身能够解释清楚输入、输出和使用场景。如果某个概念还没有达到这个标准，我们宁可不放出来，也不想用模糊词汇把它包装成看似完整的服务。
对外公开这些流程还有另一个原因。很多轻量产品真正被低估的部分，不是模型本身，而是“如何把结果讲清楚”。HAKUROKUDO 更重视页面结构、用户理解路径和最终可交付的表达，而不是只堆一个按钮和一张海报。