1. 待测模型介绍

名称 开发商 使用媒介 个人评价
Gemini 3 Pro Google Trae 感觉是水桶型选手,可能没有一项是顶尖的,但是每一项都很强,而且对话很舒服,我是说,感觉很有情商。我还是挺青睐Google的AI生态的,但是可惜了,我用不了AntiGravity。
GPT-5.1-CodeMax OpenAI Trae 写代码可能不太强,不过改bug确实厉害,就是慢了点。我对Chatgpt的印象还停留在2022年的Gpt-3.5,那时候感觉有点偏文,不过推理速度是真的快的离谱,跟秒出答案差不多了。后来Gpt-4我也是印象很差,实在是感觉没什么效率,不过Codex系列确实让人眼前一亮。另外,有一说一,这玩意是真冷血啊。
GPT-5.2-Codex OpenAI Github Copilot 相比于GPT-5.1-CodeMax,5.2版本推理速度快了不少,代码能力应该也有所提升。
KIMI-K2-0905 KIMI Trae 嗯…感觉国产的模型,可能还得看一下GLM吧。
Claude 4.5 Sonnet Anthropic Github Copilot 这个好像是公认的代码能力最强的模型之一吧,但是我总是感觉,废话有点多,我问个简单的问题,他能写一篇论文和好多个脚本,报错还挺严重,但实际上,我只需要简单的回复即可。
Claude 4.5 Opus Anthropic Github Copilot 算是Claude 4.5 Sonnet的升级版。
Raptor Mini GitHub Trae Github Copilot
Windsurf SWE 1.5 Codeium Windsurf 怎么说呢,你说它很强吧,它解决问题确实效率不高,你说它很弱吧,它又总是能在一次次试错中把问题给解决了。但是话说回来,他是一个免费的模型,已经比很多付费的都强了。

2. 测试准备

Action! 24核此时不发力更待何时。
微信图片_20260202153400_119_52(1).webp

2.1 测试环境准备

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
## 📌 项目定位
- **核心目的**:提供统一的 React + Vite + TypeScript 技术栈环境。
- **业务核心**:遵循 [ENGINE_SPEC.md](./ENGINE_SPEC.md) 中定义的 Rider-Waite-Smith (RWS) 塔罗体系与 Fisher-Yates 洗牌算法。
- **测试用途**:所有待测模型均基于此目录下的结构进行功能扩展与 UI/UX 优化。

## 📂 目录结构说明

base/
├── config/ # [配置层] 决定引擎运行规则
│ ├── deck_manifest.json # 牌组全局索引(图片路径与数据文件关联)
│ └── spreads.json # 牌阵逻辑定义(位置、含义、抽牌数量)
├── data/ # [数据层] 78张牌的静态内容数据库
│ ├── 01_major_arcana.json # 大阿卡纳 (0-21)
│ └── 02-05_*.json # 小阿卡纳 (权杖、圣杯、宝剑、星币)
├── src/ # [逻辑与表现层]
│ ├── components/ # UI 组件库
│ ├── services/ # 数据加载与核心逻辑服务
│ ├── App.tsx # 应用主入口
│ └── main.tsx # 渲染挂载点
├── types/ # [契约层] TypeScript 全局类型定义
└── ENGINE_SPEC.md # [核心规范] AI 必须严格遵守的算法与逻辑说明

## 🛠 技术栈
- **框架**: React 18
- **构建工具**: Vite
- **语言**: TypeScript
- **样式**: Tailwind CSS + Framer Motion (动画)
- **图标**: Lucide React

2.2 塔罗引擎规格

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
# Tarot Engine Specification (v1.0)

# Tarot Project Architecture & File Map

## 1. Directory Tree (目录结构)

tarot-project/
├── config/ # [配置层] 决定引擎如何运行的规则
│ ├── deck_manifest.json # 牌组清单:定义图片路径与数据文件索引
│ └── spreads.json # 牌阵规则:定义占卜玩法的逻辑结构

├── data/ # [数据层] 静态内容数据库 (Content Database)
│ ├── 01_major_arcana.json # 0-21号牌 (大阿卡纳)
│ ├── 02_wands.json # 权杖组 (火元素)
│ ├── 03_cups.json # 圣杯组 (水元素)
│ ├── 04_swords.json # 宝剑组 (风元素)
│ └── 05_pentacles.json # 星币组 (土元素)

├── types/ # [契约层] TypeScript 类型定义
│ └── tarot.d.ts # 统一定义卡牌、牌阵与运行时的数据接口

└── docs/ # [文档层] 逻辑与算法规范
└── ENGINE_SPEC.md # 核心算法规范 (洗牌、抽牌、正逆位逻辑)


## 2. File Roles & Responsibilities (详细作用说明)

以下表格详细描述了每个文件在系统中的职责,以及 AI 应该如何使用它们。

| 文件路径 (File Path) | 核心作用 (Role) | 详细描述 (Description) | AI 开发指令建议 |
| :--- | :--- | :--- | :--- |
| **`config/deck_manifest.json`** | **全局索引** | 系统的入口文件。它告诉程序图片资源存在哪里,以及具体的牌面数据存储在哪些 JSON 文件中。它实现了“数据分片”的索引功能。 | "读取此文件以获取 `assets_base_url` 和数据文件的加载路径。" |
| **`config/spreads.json`** | **业务规则** | 定义了占卜的“玩法”。不论是单张牌还是凯尔特十字,抽几张牌、每张牌代表什么意思(过去/现在/未来),全由这个文件配置。 | "根据用户选择的 `spread_id`,从此文件中读取 `card_count` 和 `positions` 定义。" |
| **`data/*.json`** | **内容仓库** | 存储了 78 张牌的富文本信息。包含正逆位解读、关键词、画面描述等。被设计为按需加载(Lazy Load)。 | "当抽到 ID 为 10 的牌时,根据 Manifest 加载对应的 JSON 并提取其 `meanings`。" |
| **`types/tarot.d.ts`** | **类型契约** | 定义了数据结构的标准。保证前端(UI)和后端(Logic)对数据格式的理解是一致的,防止字段拼写错误。 | "在编写 TypeScript 代码时,必须引用此文件作为 Interface 定义。" |
| **`docs/ENGINE_SPEC.md`** | **逻辑蓝图** | 纯文本的算法说明书。包含了洗牌算法(Fisher-Yates)、正逆位随机概率(40%)以及体系定义。 | "严格按照此文档中的伪代码逻辑实现 `shuffle()` 和 `draw()` 方法。" |


## 1. System Constants (体系定义)
本引擎严格遵循 **Rider-Waite-Smith (RWS)** 体系。

### 1.1 Deck Composition
* **Total Cards**: 78
* **ID Range**: 0 to 77 (Integer)
* **Structure**:
* **Major Arcana (大阿卡纳)**: IDs `0` - `21` (22 cards)
* **Minor Arcana (小阿卡纳)**: IDs `22` - `77` (56 cards)
* **Wands (权杖)**: `22` - `35`
* **Cups (圣杯)**: `36` - `49`
* **Swords (宝剑)**: `50` - `63`
* **Pentacles (星币)**: `64` - `77`


## 2. Core Algorithms (核心逻辑)

### 2.1 The Card Object (Runtime)
在运行时(抽牌后),每张牌必须包含以下状态属性:

{
"cardId": 45, // 原始静态ID
"isReversed": true, // 正逆位状态 (true=逆位, false=正位)
"positionIndex": 0 // 在牌阵中的位置索引
}

### 2.2 Shuffling Logic (洗牌算法)
为了保证 Web 环境下的真随机性,必须强制使用 **Fisher-Yates Shuffle** 算法,严禁使用简单的 `sort(random)`。

**Algorithm Flow:**
1. **Initialize**: Create an array `deck` containing integers `[0...77]`.
2. **Orientation (正逆位决定)**:
* Iterate through each card.
* Apply randomization: `isReversed = random() < THRESHOLD`.
* *Recommended Threshold*: `0.4` (40% chance of being reversed).
3. **Shuffle (Fisher-Yates)**:
* Loop `i` from `77` down to `1`:
* Pick random integer `j` where `0 <= j <= i`.
* Swap `deck[i]` with `deck[j]`.

### 2.3 Drawing Logic (抽牌算法)
1. **Input**:
* `shuffledDeck`: The array from step 2.2.
* `count`: Number of cards needed for the selected spread.
2. **Process**:
* Slice the first `count` items from `shuffledDeck`.
* (Optional Feature): "Cutting the deck" - Pick a random index, move the top chunk to the bottom before drawing.
3. **Output**:
* An ordered array of `DrawnCard` objects.


## 3. Spread Definitions (牌阵规则)

以下是核心支持的牌阵逻辑。`id` 必须与前端配置保持一致。

### 3.1 Single Card (单张指引)
* **ID**: `single_card`
* **Count**: 1 Card
* **Logic**:
* **Pos 0 (Core)**: Returns the direct answer or "Yes/No" energy.

### 3.2 Three Card Spread (圣三角 - 时间流)
* **ID**: `time_flow`
* **Count**: 3 Cards
* **Logic**:
* **Pos 0 (Past)**: Represents root causes, background context.
* **Pos 1 (Present)**: Current situation, immediate challenges.
* **Pos 2 (Future)**: Likely outcome if current path is unchanged.

### 3.3 Love Cross (爱情十字)
* **ID**: `love_cross`
* **Count**: 4 Cards
* **Logic**:
* **Pos 0 (Querent)**: User's attitude/mindset in the relationship.
* **Pos 1 (Partner)**: Partner's attitude/mindset.
* **Pos 2 (Status)**: Current dynamic or bridge between them.
* **Pos 3 (Advice)**: Future trend or action to take.

### 3.4 Two Paths (二选一抉择)
* **ID**: `two_paths`
* **Count**: 5 Cards
* **Logic**:
* **Pos 0 (Significator)**: The current dilemma.
* **Pos 1 (Path A - Action)**: Short-term effect of Option A.
* **Pos 2 (Path A - Result)**: Long-term outcome of Option A.
* **Pos 3 (Path B - Action)**: Short-term effect of Option B.
* **Pos 4 (Path B - Result)**: Long-term outcome of Option B.

### 3.5 Celtic Cross (凯尔特十字 - 完整版)
* **ID**: `celtic_cross`
* **Count**: 10 Cards
* **Logic**:
* **Pos 0 (The Present)**: The core situation (covering the significator).
* **Pos 1 (The Challenge)**: Immediate obstacle or crossing energy.
* **Pos 2 (The Past)**: Foundations, distant past events.
* **Pos 3 (The Future)**: Recent past events influencing now.
* **Pos 4 (The Goal)**: Higher power, best outcome, or conscious goal.
* **Pos 5 (Near Future)**: Immediate future (next few weeks).
* **Pos 6 (The Self)**: Querent's internal state.
* **Pos 7 (Environment)**: External influences (family, work).
* **Pos 8 (Hopes/Fears)**: Psychological undercurrents.
* **Pos 9 (Outcome)**: Final resolution (3-6 months).

2.3 统一Prompt语句

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# Role: Senior Frontend Developer & UI Designer

# Goal
Build a "Minimalist Tarot Web App" using React + Tailwind CSS.
The app must work WITHOUT any external image files. All UI must be programmatically generated.

# Context
I have provided the JSON data files (`data/*.json`, `config/*.json`) and TypeScript definitions (`tarot.d.ts`).

# Requirements

## 1. The <Card /> Component (No Images)
Instead of loading JPEGs, create a beautiful, CSS-styled card component.
- **Aspect Ratio**: Standard Tarot card ratio (approx 2:3.5).
- **Dynamic Styling**:
- If `type === 'Major Arcana'`: Use a Mystical Purple/Gold gradient background.
- If `element === 'Fire'`: Use a Warm Red/Orange gradient.
- If `element === 'Water'`: Use a Calm Blue/Teal gradient.
- If `element === 'Air'`: Use a Sharp Gray/Sky gradient.
- If `element === 'Earth'`: Use a Natural Green/Brown gradient.
- **Content**:
- Center: Display the specific Icon for the suit (use Lucide-React icons or Emojis).
- Top/Bottom Corners: Display the Roman Numeral (for Major) or Number (for Minor).
- Bottom Center: Display `name_cn` (Chinese Name).
- **Reversal**:
- If `isReversed === true`: The card visual container should be rotated 180deg.
- *UX Note*: Ensure the text label (`name_cn`) is readable (either don't rotate the text, or place the text outside the rotated container).

## 2. The Logic (Engine)
- Implement the `shuffle` and `draw` logic as defined in `ENGINE_SPEC.md` (if provided) or use Fisher-Yates shuffle.
- Load data from the provided JSON files.

## 3. The Flow (UX)
1. **Selection Screen**: User selects a spread from `spreads.json` (e.g., "圣三角").
2. **Shuffle Animation**: Show a CSS-only animation of cards shuffling.
3. **Draw Screen**: User clicks a deck to draw cards one by one.
4. **Result Screen**:
- Show the cards in the layout defined in `spreads.json`.
- Clicking a card reveals its `description` and specific `meaning` (based on upright/reversed status).
- For `spreads` like "Three Card", match the card position index to the meaning in `spreads.json` (e.g., "Card 1: Past").

## 4. Tech Stack
- React (Next.js or Vite)
- Tailwind CSS (for rapid styling)
- Framer Motion (for smooth animations - highly recommended for the card flip effect)
- Lucide React (for icons)

# Deliverable
Please generate the full code structure, specifically the `Card` component and the `TarotBoard` page.

3. 测试结果分析

3.1 KIMI-K2-0905

KIMI-K2-0905 模型在代码出现两个静态错误,导致界面渲染失败,仅呈现基础界面而无实际功能。
图片 1.webp

界面布局存在对齐问题。
图片 2.webp

静态错误导致应用功能完全无法运行,仅显示初始界面。
图片 3.webp

3.2 Gemini 3 Pro

Gemini 3 Pro 模型生成的初始界面设计良好,包含动画效果。
图片 4.webp

洗牌动画效果流畅。
图片 5.webp

牌面图案存在重复现象,但鉴于无图片资源限制,此为预期结果。实际上在选牌的时候也并没有很好的控制索引,选10张虽然索引到了10,但没有跳转,点一下到了11才跳转的。
图片 6.webp

整个过程没有一个静态逻辑报错或运行时报错,Google的网页开发确实厉害。
图片 7.webp

3.3 Raptor Mini

Raptor Mini 模型在布局设计上存在明显缺陷,水平和垂直对齐均未达到标准,文字排版亦有待改进。
图片 8.webp

洗牌动画效果一般。
图片 9.webp

单张牌阵模式下允许选择多张牌,违反了预设规则。抽牌过程中按钮被牌面遮挡,影响操作。牌面解读界面按钮布局混乱。
图片 10.webp

虽然没有报错,但是交互体验很差。总体给人一种什么都能实现,但都只能堪堪实现的感觉。
图片 11.webp

3.4 Windsurf SWE 1.5

界面做的还行,布局也还可以,但感觉有点鲜艳,高级感不足。
图片 12.webp

我的天,这个动效真的牛。
图片 13.webp

感觉布局还可以优化,看到那个按钮了吗Raptor mini,好好学一下。但是那几个颠倒的牌面是什么意思呢。算了,你比另一个免费的好多了。
图片 14.webp

没有报错,但是抽牌的时候感觉很难受,卡顿比较明显。
图片 15.webp

3.5 GPT-5.1-CodeMax

GPT-5.1-CodeMax 模型未能成功生成可运行界面,应用启动失败。
图片 16.webp

你果然还是适合改bug而不是开发吗
图片 17.webp

3.6 GPT-5.2-Codex

GPT-5.2-Codex 模型制作的开始界面算是排版做的比较舒服的了。
图片 18.webp

洗牌的动效优秀。
图片 19.webp

抽牌流程设计出色,为当前最佳实现。
图片 20.webp

仍存在对齐问题。
图片 21.webp

全程无编译错误。
图片 22.webp

3.7 Claude 4.5 Sonnet

怎么感觉和Gemini 3 pro做的很像,不过这个感觉做的好一些
图片 23.webp

洗牌动画效果良好。
图片 24.webp

抽牌流程设计优秀。
图片 25.webp

无编译错误。
图片 27.webp

3.8 Claude 4.5 Opus

Claude 4.5 Opus 模型尽管代码量达 1600 行,但界面设计未展现相应复杂度。
图片 28.webp

洗牌页面设计最佳,包含动态提示语句,根据提示调整特效。
图片 29.webp

文字布局过于紧凑。
图片 30.webp

解读页面做的挺好的,但是一个一个点,一次次的弹窗再关闭会不会有点麻烦呢
图片 31.webp

无编译错误。
图片 32.webp

4. 问题总结

我并没有进行过任何的web应用开发,所以目前只能发现下面几个问题:

1.应当在开始界面加上各种牌阵的详细说明,占扑的具体流程,以及各种牌面的信息与展示。

2.牌面样式问题,目前牌面重复度较高,这是不给予图片文件的弊端,但是可以尝试让AI绘制更复杂更具有辨别性的牌面样式。

3.排版对齐问题,但是无法让AI完全解决,只能调试发现进行纠正。

4.抽牌应当让用户更有参与感,最好是把当前牌阵的所有卡牌展示出,让用户自行进行抽取。

5.在占卜进行的过程也应当给予相关信息引导,因为部分用户会在不够了解的情况下直接进行占卜。

其他的更多问题我暂时无法发现,毕竟我也说过了,我并没有进行过任何的web应用开发。

我选择在Gemini的基础上进行后续的完善,因为gemini的前端做的好,作为玩具来讲,我更在意视觉效果。