我们是如何打造 Salty Poker 的:spec-driven development

大多数扑克平台的打造方式,跟大多数扑克手牌的打法差不多 — 快,凭感觉,边打边想。我们不会那样做。

从第一天起,我们就有意识地决定用 spec-driven development 来构建这个平台。这是在 AI 辅助工程圈里正在获得认真关注的一种方法论,也是我们所构建的一切所依赖的基础。

Spec-driven development 是什么意思

在写下第一行生产代码之前,先写下了规格说明。超过 100 页。二十三个模块,覆盖系统的每一个领域 — 基础设施、数据库 schema、API 契约、服务边界、合规控制、CI/CD 流水线、运维 runbook。

这套方法论分为三个层次。Spec-first:在任何代码之前先写出完整的规格,然后用它来驱动开发。Spec-anchored:随着项目不断成熟,规格和代码库一起保持存活并共同演化。Spec-as-source:人类只接触规格本身 — 代码完全由它生成。

还有一种失败模式值得命名:spec-once — 规格启动了项目,然后随着开发深入被悄悄抛弃。蓝图最终变成一件古董。

我们在设计上就明确地反对这种情况。我们的规格是一份活文档。它会随着决策落地、边缘情况浮现、架构演进而更新。每当一次会话结束,规格就反映出当前已经构建的东西;下一次会话开始时,它会准确地从上次中断的地方接着往下走。

为什么这件事对扑克平台至关重要

扑克平台的失败方式是可以预测的 — 而且几乎所有失败都回到同一个根本原因:早期偷的懒,随着时间推移积累成严重问题。

一个没有正确复式记账 ledger 的钱包系统。一个没有经过边缘情况压力测试的游戏引擎。一层事后补装、而不是从第一天就嵌入的合规。一个在 50 个玩家时一切正常、在 500 个玩家时崩溃的平台。

Spec-driven development 就是防止这些事情的那份自律。每一个服务边界在构建之前就被定义好。每一个数据流在实现之前就被写进文档。每一个合规要求在第一条迁移脚本运行之前就已经写进规格。没有那种 "这个我们之后再想" 的决策 — 因为 "之后" 就是玩家已经坐在牌桌旁的时候。

把 Agentic AI 当作执行引擎

我们正在用 agentic AI 来构建这个平台 — 这跟大多数人熟悉的那些 AI 工具有一个重要区别。

Agentic AI 不只是回答问题或自动补全代码。它在明确定义的边界内自主地执行多步工作流 — 写代码、跑测试、捕获失败、修复、提交 — 不需要人在每一步都盯着。它会把一个任务从头做到尾,并在遇到应由人来拍板的决策时把控制权交回。

规格就是让这一切既安全又可预测的东西。Agent 在一份已经定义好、被评审过、受版本控制的规格之上工作。每次会话加载一小组聚焦的模块 — 一次 2 到 4 个 — 精确地给 agent 它需要的上下文,而不多给其它任何东西。每次会话都有明确的范围。一个检查点把守通往下一阶段的门。在清单没走干净之前,什么都不往下走。

Agent 不决定要造什么。规格来决定。Agent 负责执行。

最终结果

一个以它应得的严谨来打造的平台。每一个架构决策都有文档。每一处服务边界都是有意为之。每一条合规要求都在它变成问题之前就被处理掉。

这就是我们正在构建的东西。等你上去玩的时候,你会感受到差异。

作为一种方法论 —— 围绕决策、工具链、会话结构,以及它在扑克之外的意义 —— 我在 The Salty Korean 上专门写 spec-driven development。如果你对工程这一面感兴趣,更深入的内容都在那里。

关于这套方法论的更多内容:Heeki Park 的 Using Spec-Driven Development with Claude Code。

Stay salty.