核心摘要

最近，带有"送钱者"、"CTRL"等标签的 SBTI 测试 刷屏了朋友圈。作为一个独立开发者或产品经理，你是否想过：如果让我来做一个类似的爆款测试，需要多久？过去可能需要一周的前后端开发，但在 AI 时代，通过 OpenSpec + Spec Coding + Vibe Coding，这个时间可以被压缩到 半天。本文将复盘我们如何用 AI Agent 编程工具（如 Trae / Cursor），从 OpenSpec 提案、任务拆解、结果算法到海报生成，构建一个高颜值、带 15 维雷达图海报的 SBTI 测试站点。

目录

核心要点

  • 开发范式转变：从"手写代码"转变为"用 OpenSpec 管理 proposal、spec、tasks，再让 Agent 执行"。
  • 架构设计：使用 Next.js 独立路由 (/quiz/[slug]) 配合 i18n 多语言体系。
  • 动效优化：利用 requestAnimationFrame 解决答题卡片切换时的视觉闪烁。
  • 踩坑实录：分享如何绕过 html2canvas 渲染 rgba 颜色和阴影的 Bug。

🔧 体验成品：你可以先访问 SBTI 在线测试，体验我们用 AI 辅助开发的最终产品。

Vibe Coding vs Spec Coding

在开始之前，我们需要明确两种 AI 辅助开发的流派：

  1. Vibe Coding（氛围编程）：跟着感觉走，直接用自然语言告诉 AI "我要一个什么样的页面"，边看边改。适合快速 MVP 和灵感验证。
  2. Spec Coding（规格编程）：工程化思维。先用 OpenSpec 产出 proposal.md、specs/spec.md、tasks.md 等制品，确认无误后再让 Agent 批量执行。适合复杂状态管理和长线项目。

在复刻 SBTI 测试站点的过程中，我们采用了 "前期 Spec Coding + 后期细节 Vibe Coding" 的混合模式。

OpenSpec 实操：先把想法变成可执行变更

真正的 Spec Coding 不是"让 AI 先写一份文档"这么简单，而是要让需求进入一个可追踪的变更生命周期。以 SBTI 测试站为例，第一步不是让 AI 直接写页面，而是先在项目里初始化 OpenSpec：

graph LR A["openspec init"] --> B["/opsx:propose"] B --> C["Review specs & tasks"] C --> D["/opsx:apply"] D --> E["Test & iterate"] E --> F["/opsx:archive"] style B fill:#e1f5fe,stroke:#01579b style D fill:#fff3e0,stroke:#e65100 style F fill:#e8f5e9,stroke:#2e7d32
bash 
# 全局安装 OpenSpec
npm install -g @fission-ai/openspec@latest

# 在项目根目录初始化
cd qubittool
openspec init

这会生成 openspec/ 目录，让 AI IDE 能识别 SDD 工作流。接下来在 Trae、Cursor 或 Claude Code 的对话框中使用 propose 命令创建变更：

text 
/opsx:propose build-sbti-quiz

这一步的目标不是立刻写 React 组件，而是让 AI 先生成一组可审查的工程制品：

文件 作用 在 SBTI 项目里的重点
proposal.md 说明为什么要做、做什么、不做什么 明确这是轻量人格测试，不是医学心理诊断
specs/spec.md 定义用户可观察行为 首页、答题、计分、结果页、图鉴页、分享海报
tasks.md 拆成可执行任务 数据模型、页面路由、结果算法、雷达图、i18n、验收

在运行 apply 之前，必须人工审查这些文件。尤其是 spec.md 和 tasks.md，它们决定 Agent 后面会不会乱改代码。

第一步：需求拆解与生成 Spec（1 小时）

SBTI 测试看似简单，其实包含复杂的流转：首页 (Intro) → 答题页 (Quiz) → 结果计算 → 结果海报页 (Result) → 人格图鉴 (Gallery)。

SBTI 人格测试结果卡片设计 - JOKE-R 类型 在生成 Spec 时，我们首先拆解了源站的核心视觉（如小丑 JOKE-R 的人物卡片设计）

我们首先在 AI IDE（如 Trae 或 Cursor）中打开对话框，把高维度需求交给 OpenSpec 的 propose 阶段，而不是让 Agent 直接写代码：

Prompt 示例： "我要构建一个类似 SBTI 的 15 维性格测试网站。前端框架为 Next.js (Pages Router) + CSS Modules。 核心需求：

  1. 数据源：从 quiz-definitions.ts 读取 30 道题和 15 个人格维度映射。
  2. 路由：独立的 /quiz/sbti 体系，支持 SSR。
  3. UI：高保真复刻，要求支持移动端响应式，包含毛玻璃效果。
  4. 功能：答题结束后生成 15 维雷达图，并支持长按保存海报。 请使用 /opsx:propose build-sbti-quiz 的方式创建 OpenSpec 变更，先生成 proposal.md、specs/spec.md 和 tasks.md，不要直接写代码。"

执行 propose 后，AI 会在 openspec/changes/build-sbti-quiz/ 下生成变更制品。此时你要先审查 proposal.md、specs/spec.md 和 tasks.md，确认它准确捕获了数据结构、组件层级和验收场景。只有当 Spec 足够严谨（比如明确状态存在父组件还是子组件、结果算法如何归一化、分享海报是否依赖 Canvas），后续的生成才不会陷入"无限循环的幻觉 Bug"中。

审查完成后再执行：

text 
/opsx:apply build-sbti-quiz

这时 AI 会读取 tasks.md，逐条实现代码并勾选任务。相比"帮我做一个 SBTI 测试网站"这种大 Prompt，这种流程能显著减少它随机修改无关文件的概率。

第二步：核心架构与组件生成（2 小时）

在确认 Spec 后，授权 AI Agent 开始批量执行（Execute）。在这个阶段，AI 的爆发力得到了完美体现：

1. 动态路由体系

AI 自动生成了 /pages/quiz/[slug]/index.tsx 和 /pages/quiz/[slug]/result/[code].tsx，这意味着系统不仅能跑 SBTI，未来还能零成本接入 MBTI、九型人格等其他测试。

2. 状态机流转

AI 生成了基于 useState 的视图切换逻辑，在不刷新页面的情况下实现了： IntroView → QuizView → ResultView 的无缝切换，并保留了答案数组的上下文。

3. 多语言 i18n

只需提供一份基础的中文 JSON，AI Agent 就能自动补全英文 JSON，并在所有组件中植入 useTranslation('sbti-test') 钩子。

这里 OpenSpec 的价值是把"必须双语"写成验收条件，而不是靠开发者事后提醒：

markdown 
#### 场景：中英文页面内容一致
- **WHEN** 用户访问 `/zh/quiz/sbti` 和 `/quiz/sbti`
- **THEN** 两个页面都应展示相同题目数量、相同结果类型和相同维度解释
- **AND** 所有文案必须来自 `public/locales/{lang}/sbti-test.json`

第三步：死磕高保真体验（1.5 小时）

骨架搭好了，但真正的魔鬼都在细节里。这时候我们切回 Vibe Coding 模式，针对具体 Bug 进行逐个击破：

痛点 1：答题卡片切换闪烁

当用户点击选项时，下一题的出现会有极其短暂的闪烁。

  • Vibe 沟通："现在的 setTimeout 动画有闪烁感，请帮我重构，用纯 CSS transition 解决。"
  • AI 方案：AI 引入了 双重 requestAnimationFrame (rAF) 模式。先将卡片 opacity 设为 0，等待浏览器渲染一帧后，更新题目索引，再在下一帧恢复 opacity: 1，实现了极其丝滑的淡入淡出。

痛点 2：海报生成红框 Bug

结果页需要用 html2canvas 截取 DOM 生成海报。但在测试时，海报边缘莫名出现了红框，且排版错乱。

SBTI 测试结果海报 - html2canvas 生成的 15 维雷达图 这是最终修复后生成的完美海报效果
- **Vibe 沟通**："`html2canvas` 截图时 `box-shadow` 渲染错误，且 rgba 背景色发黑。" - **AI 方案**：AI 迅速识别出这是 `html2canvas` 的已知缺陷。它帮我批量将 CSS 中的 `rgba()` 转换为等效的 Hex 颜色，移除了截图区域的复杂阴影，并在外层包裹了一个定宽的截图容器，完美解决了海报生成问题。

痛点 3：微信浏览器下载拦截

  • Vibe 沟通："在微信里点击'保存海报'没反应。"
  • AI 方案：AI 增加了一段 navigator.userAgent 嗅探代码。如果检测到 MicroMessenger，则隐藏下载按钮，并在顶部弹出提示："请长按图片保存"。

OpenSpec 产物示例：SBTI 的 spec 和 tasks 怎么写

为了让这篇复盘更可复用，下面给一份简化版的 OpenSpec 产物。实际项目中不要让 Agent 只看一句"做一个 SBTI 测试"，而要把行为写成 WHEN/THEN 场景。

specs/spec.md 示例

markdown 
### 需求：用户完成 SBTI 答题并获得结果

#### 场景：首次进入测试页
- **WHEN** 用户访问 `/quiz/sbti`
- **THEN** 系统展示测试介绍、开始按钮和结果示例
- **AND** 页面应支持移动端首屏完整展示核心 CTA

#### 场景：用户完成全部题目
- **WHEN** 用户回答完所有题目
- **THEN** 系统根据答案累加 15 个维度分数
- **AND** 将分数归一化为 0-100
- **AND** 根据最高权重组合匹配一个 SBTI 结果 code

#### 场景：用户保存结果海报
- **WHEN** 用户点击保存海报
- **THEN** 系统生成包含人格 code、15 维雷达图和分享文案的图片
- **AND** 在微信浏览器中提示用户长按保存

tasks.md 示例

markdown 
- [ ] 定义 `sbti` quiz 数据结构，包括题目、选项、维度权重和结果映射
- [ ] 实现 `/quiz/[slug]` 通用测试入口
- [ ] 实现答题状态机：intro -> quiz -> result
- [ ] 实现 15 维分数归一化和结果 code 匹配
- [ ] 实现结果页雷达图和人格说明
- [ ] 实现 `html2canvas` 海报生成，并处理微信保存提示
- [ ] 补齐 `zh` / `en` i18n 文案
- [ ] 增加移动端验收：375px 宽度无横向滚动、CTA 可见

执行过程中，如果 AI 发现 html2canvas 对某些 CSS 支持不好，不要让它在聊天里随便改。正确做法是先更新 OpenSpec：

markdown 
#### 决策：截图区域使用简化 CSS
- 海报 DOM 内不使用复杂 `box-shadow`
- 截图背景使用不透明 Hex 色值
- 截图容器固定宽度，避免移动端 DPR 导致排版漂移

然后再继续 /opsx:apply。这样 OpenSpec 仍然是单一事实来源，后续维护者也能知道为什么海报区域没有使用复杂毛玻璃效果。

最佳实践：给独立开发者的避坑指南

  1. CSS Modules 比 Tailwind 更容易微调：虽然 Tailwind 写起来快，但在让 AI 进行像素级 UI 修改（比如处理移动端的负 Margin 导致的空间冗余）时，隔离的 CSS Modules 能大幅减少样式污染。
  2. 单一数据源 (Single Source of Truth)：不要让 AI 在页面里硬编码题目。务必让 AI 先写一个 quiz-definitions.ts，所有组件只读这个文件。
  3. OpenSpec 先行，Vibe Coding 后置：页面架构、数据模型、结果算法必须先写进 OpenSpec；颜色、动效、间距这类体验细节再用 Vibe Coding 快速微调。
  4. 分阶段 Commit：AI 也是会把代码改坏的。每当完成一个大模块（如答题逻辑），立刻 commit。一旦 AI 陷入改 Bug 的死循环，立刻回滚，重新思考 Spec。
  5. 完成后 archive：功能上线后执行 /opsx:archive build-sbti-quiz，把 proposal、spec 和 tasks 归档为项目记忆，避免下一轮 Agent 重复推理。

常见问题 (FAQ)

Q1: Vibe Coding 真的能完全替代手写代码吗？

目前不能。Vibe Coding 负责"快速起量"，但对于复杂的动画渲染时序（如 rAF）、特定的跨端兼容性问题（微信浏览器），仍然需要开发者有查错能力，引导 AI 去修复。

Q2: Spec Coding 适合什么样的项目？

适合有明确数据流转、涉及多个文件联动的项目（如包含用户系统、状态管理的 Web App）。如果是单页面的计算器工具，直接 Vibe Coding 即可。

Q3: 为什么要将测试结果页做成独立路由？

为了 SEO 和社交裂变。如果只有一个 /quiz/sbti，用户分享出去的链接别人打开只能看到首页。使用 /quiz/sbti/result/ATM-er 这种独立路由，配合 Open Graph 标签，可以实现"点击别人分享的链接，直接看到别人的测试结果"的裂变效果。

Q4: OpenSpec 在这个项目里最有价值的环节是什么？

最有价值的是 propose 阶段。它把"做一个 SBTI 测试"拆成了可审查的 proposal、spec 和 tasks，提前暴露了题库建模、结果算法、i18n、海报生成、移动端适配这些风险点，避免 Agent 一上来就写一堆不可控代码。

总结

从需求拆解到最终部署，借助 OpenSpec、Spec Coding 和 Vibe Coding，一个原本需要几天工作量的全栈多语言性格测试站点，被浓缩到了一个下午。

在这个时代，代码实现能力正在被 Agent 放大，而产品定义、规格审查和验收设计能力正在变得更重要。OpenSpec 的意义不是让 AI 更自由，而是让 AI 在清晰轨道上快速执行。

👉 去看看 Vibe Coding 的成果：体验 SBTI 测试

相关资源