使用最新LLM进行“Vibe编码”实践（需求定义～功能实现①）

Information

为了覆盖更广泛的受众，这篇文章已从日语翻译而来。
您可以在这里找到原始版本。

引言

目前，我已订阅了 ChatGPT Pro 和 Claude Max (20×)，正在验证利用生成式AI提升开发流程效率的可行性。
为了了解其实际能力，我个人尝试了 Vibe 编码（vibe coding）。为了保持动力，我选择了笔者最近在玩的一款在线卡牌游戏 “Shadowverse:WB”（以下简称 WB）作为系统的题材。

前提

游戏进步的捷径被认为是：观看高水平玩家的对局，以及接受高水平玩家的指导（教练）。
前者可以通过对局视频和讲解视频轻松实现，但后者门槛较高。因此，决定试验一下利用最新的大规模语言模型（LLM），能够在多大程度上实现相当于赛后回顾的“AI教练”。
※（仅供参考）截止 2025/8/12 笔者的 WB 对局情况：

噩梦（Nightmare）：460 胜（使用“中速噩梦”登顶大师）
精灵（Elf）：50 胜（正在练习“Rinosaurus 精灵”）
主教（Bishop）：5 胜（尝试“守护主教”）
因从第二弹卡包开始的少量氪金，其他领袖尚未尝试
排位段位主要在蓝宝石和红宝石之间波动（有时钻石）

考察的系统（概述）

一个针对 Shadowverse:WB 对战视频进行自动分析，提取重要场景并给出改进建议的赛后回顾 AI。如果当前 AI 难以胜任回顾任务，则先用于收集对战视频的统计信息。

本次工作范围

作为第一阶段，按照 人发出提示 → AI生成 → 人确认并发出修正指示 的流程，完成了（1）需求定义、（2）基础设计、（3）一个功能（卡牌数据库）的实现。

需求定义・基础设计

1) 需求定义（创建与补充）

严格意义上的 Vibe 编码或许不需要从设计文档开始，但为了在初期头脑风暴时提供参考，并在向 AI 下指令时让其引用文档以省略解释，我们从编写需求定义书和基础设计书开始。
使用的模型是 ChatGPT 5 Thinking（截至八月的最新推理模型）。给予项目说明后，执行了“请创建需求定义书”这一提示。
初步成果包括目的与范围、用例、交付物/非功能需求、整体架构、数据模型等，但有几点值得注意：未考虑法律/合规方面，且对游戏的理解仅基于一般卡牌游戏知识及前作 Shadowverse。
因此，我们请求对提示进行追加修正。（提示内容为：“请调查权利与合规面可能存在的顾虑并补充说明”、“请参考（官网页面URL），总结 WB 的游戏系统”）
以下为实际生成结果。

需求定义书（点击展开）

Shadowverse: Worlds Beyond 游戏录像解析AI系统
#

需求定义书 v1.0
#

文档ID: REQ-2025-001
创建日期: 2025-08-09
最后更新: 2025-08-09
文档类型: 需求定义书
批准者: –
状态: 草稿

修订历史
#

版本日期变更内容创建者

1.0 2025-08-09 初版创建（从系统设计书重构为需求定义书） –

目录
#

引言

系统概述

利益相关者

业务需求

功能需求

非功能需求

外部接口需求

数据需求

法律・合规需求

约束事项

前提条件

术语定义

参考资料

1. 引言
#

1.1 目的
#

本文档定义了一个针对 Shadowverse: Worlds Beyond（以下简称 WB）对战录像进行自动解析并生成战略建议的 AI 系统的需求。

1.2 范围
#

包含范围: WB 对战录像的解析、卡牌识别、游戏状态推断、战略建议生成

不包含范围: 实时对战辅助、游戏客户端修改、自动对战功能

1.3 预期读者
#

项目经理

系统工程师

开发团队

法务/合规负责人

2. 系统概述
#

2.1 系统名称
#

Shadowverse: Worlds Beyond 游戏录像解析AI系统

2.2 系统目标
#

支援 WB 玩家进行赛后回顾，助力提升游戏技术。

2.3 系统定位
#

赛后回顾与学习支援工具

非官方、非合作的第三方工具

以教育与研究为目的

3. 利益相关者
#

3.1 主要利益相关者
#

利益相关者角色关注事项

WB 玩家终端用户对局改进、战略学习

开发团队系统开发与运维技术可行性、可维护性

法务负责人合规保障著作权、使用条例遵守

内容创作者视频制作者解析结果的利用、素材提供

4. 业务需求
#

4.1 现状问题
#

难以客观了解对局失误

学习最佳对局思路需要大量时间

赛后复盘容易带有主观偏见

4.2 系统引入后的改进
#

提供客观的对局分析

展示替代对局思路

自动提取关键场景

4.3 业务流程
#
flowchart LR
    A[视频录制] --> B[视频上传]
    B --> C[自动解析]
    C --> D[报告生成]
    D --> E[玩家回顾]
    E --> F[技能提升]
5. 功能需求
#

5.1 功能一览
#

功能ID 功能名优先级说明

F-01 视频导入API 必须对战视频的上传与管理

F-02 帧提取必须视频帧的切分

F-03 UI 元素检测必须 HP/PP/EP 等游戏信息识别

F-04 卡牌识别必须通过 OCR 与图像识别确定卡牌

F-05 事件提取必须检测出牌/攻击/进化等动作

F-06 状态还原必须按时间序列推断游戏状态

F-07 建议生成必须生成战略建议

F-08 报告生成必须将解析结果生成报告

F-09 知识获取必须收集与管理卡牌信息

F-10 向量索引推荐通过 RAG 实现知识检索

5.2 功能详细
#

F-01: 视频导入API

输入: 视频文件（MP4, AVI, MOV）

处理: 文件上传、验证、任务注册

输出: 任务ID、处理状态

F-04: 卡牌识别

要求准确率: Top-1 正确率 ≥ 95%（高清录像）

识别方式:

OCR 路径: 识别卡牌名称与费用文本

图像路径: 基于卡牌图像相似度进行检索

支持语言: 日语

F-07: 建议生成

生成内容:

推荐操作（Top-3）

风险评估

替代对局思路

理由（引用卡牌信息）

6. 非功能需求
#

6.1 性能需求
#

项目要求值测试条件

视频解析速度 15 分钟视频 ≤ 2 分钟 GPU: A100×1

卡牌识别准确率 Top-1 ≥ 95% 1080p 视频

事件检测准确率 F1 分数 ≥ 0.90 –

并发处理数 100 任务并行 –

响应时间 API 响应 ≤ 1 秒 95 百分位

6.2 可用性需求
#

可用率: ≥ 99.5%（月度）

计划停机: 每月一次，最长 2 小时

故障恢复: RPO: 1 小时，RTO: 4 小时

6.3 安全需求
#

认证: OAuth 2.0 / JWT

通信: TLS 1.3 及以上

数据加密: AES-256

访问控制: RBAC

审计日志: 记录所有 API 调用

6.4 扩展性需求
#

横向扩展: 支持工作节点水平扩展

模块扩展: 通过插件形式进行功能扩展

多语言支持: 考虑扩展至英文版

7. 外部接口需求
#

7.1 用户界面
#

Web UI: 响应式设计（支持 PC/平板）

主要界面:

视频上传页面

解析进度显示

报告查看

卡牌详情显示

7.2 外部系统集成
#

系统用途协议

YouTube API 获取视频元数据 REST

攻略网站收集卡牌信息 HTTP/爬取

云存储存储视频 S3 兼容 API

7.3 API 规格
#
# 视频解析 API
POST /api/v1/analyze
  Request:
    - video_url: string
    - options: object
  Response:
    - job_id: string
    - status: string

# 结果获取 API  
GET /api/v1/analyze/{job_id}
  Response:
    - status: string
    - progress: number
    - results: object
8. 数据需求
#

8.1 卡牌主数据
#

字段类型说明

card_id string 卡牌标识符

name_jp string 卡牌名称（日语）

cost integer 费用

attack integer 攻击力

defense integer 体力

card_class string 职业

card_type string 类型（随从/法术/护符）

ability_text string 能力文本

image_url string 卡牌图片 URL

is_token boolean Token 标志

8.2 事件数据
#
{
  "timestamp": 123.45,
  "turn": 5,
  "actor": "ally",
  "event_type": "play",
  "card_id": "10001110",
  "targets": ["unit_001"],
  "value": 3
}
8.3 数据保留期限
#

视频文件: 30 天

解析结果: 90 天

统计数据: 1 年

9. 法律・合规需求
#

9.1 基本方针
#

赛后回顾专用: 不提供实时对战辅助

非合作声明: 明示为 Cygames 非官方工具

著作权遵守: 最小引用并注明出处

9.2 禁止事项
#

修改游戏客户端

内存读取或通信监听

自动对战/BOT 功能

转载 WIKI 图片

比赛中实时使用

9.3 必要声明
#
© Cygames, Inc.
本服务与 Cygames 无关联或支持。
9.4 数据收集
#

遵守 robots.txt: 适当控制爬虫

速率限制: 1 秒≤1 次请求

删除请求响应: 72 小时内处理

10. 约束事项
#

10.1 技术约束
#

需要 GPU（推理处理）

日语 OCR 精度限制

视频质量影响识别准确度

10.2 运营约束
#

不提供 24/365 支持

含个人信息的视频不处理

商用需另行授权

10.3 法律约束
#

遵守各地区著作权法与相关规范

遵守平台使用条款

考虑比赛规则

11. 前提条件
#

11.1 技术前提
#

具备互联网连接环境

支持浏览器：Chrome/Firefox/Safari 最新版

视频格式：H.264/H.265 编码

11.2 运营前提
#

用户拥有视频使用权

解析结果仅做参考

接受系统维护时间

12. 术语定义
#

术语定义

WB Shadowverse: Worlds Beyond

PP Play Point（法力）

EP Evolve Point（进化点）

SEP Super Evolve Point（超进化点）

RAG Retrieval Augmented Generation（检索增强生成）

OCR Optical Character Recognition（光学字符识别）

Token 游戏中生成的特殊卡牌

Lethal 必杀，确定胜利的一击

13. 参考资料
#

13.1 相关文档
#

CLAUDE.md - 项目实施指南

database/schema_design.md - 数据库设计文档

crawlers/README.md - 爬虫实现规范

13.2 外部链接
#

Shadowverse: Worlds Beyond 官方网站

Cygames 发布指南

附录A: 用例详情
#

UC-01: 对战视频解析
#

参与者: WB 玩家
前置条件: 拥有视频文件
基本流程:

玩家上传视频

系统解析视频

识别卡牌与动作

推断游戏状态

生成战略建议

显示报告

备选流程:

2a. 视频质量较低时，显示警告

3a. 卡牌识别失败时，显示候选列表

后置条件: 生成解析报告

附录B: 界面示例
#

B.1 主仪表盘
#

视频上传区域

解析历史列表

统计摘要

B.2 解析报告界面
#

时间线展示

关键场景高亮

推荐操作及理由

卡牌使用记录

文档结束

版本	日期	变更内容	创建者
1.0	2025-08-09	初版创建（从系统设计书重构为需求定义书）	–

利益相关者	角色	关注事项
WB 玩家	终端用户	对局改进、战略学习
开发团队	系统开发与运维	技术可行性、可维护性
法务负责人	合规保障	著作权、使用条例遵守
内容创作者	视频制作者	解析结果的利用、素材提供

功能ID	功能名	优先级	说明
F-01	视频导入API	必须	对战视频的上传与管理
F-02	帧提取	必须	视频帧的切分
F-03	UI 元素检测	必须	HP/PP/EP 等游戏信息识别
F-04	卡牌识别	必须	通过 OCR 与图像识别确定卡牌
F-05	事件提取	必须	检测出牌/攻击/进化等动作
F-06	状态还原	必须	按时间序列推断游戏状态
F-07	建议生成	必须	生成战略建议
F-08	报告生成	必须	将解析结果生成报告
F-09	知识获取	必须	收集与管理卡牌信息
F-10	向量索引	推荐	通过 RAG 实现知识检索

项目	要求值	测试条件
视频解析速度	15 分钟视频 ≤ 2 分钟	GPU: A100×1
卡牌识别准确率	Top-1 ≥ 95%	1080p 视频
事件检测准确率	F1 分数 ≥ 0.90	–
并发处理数	100 任务并行	–
响应时间	API 响应 ≤ 1 秒	95 百分位

系统	用途	协议
YouTube API	获取视频元数据	REST
攻略网站	收集卡牌信息	HTTP/爬取
云存储	存储视频	S3 兼容 API

字段	类型	说明
card_id	string	卡牌标识符
name_jp	string	卡牌名称（日语）
cost	integer	费用
attack	integer	攻击力
defense	integer	体力
card_class	string	职业
card_type	string	类型（随从/法术/护符）
ability_text	string	能力文本
image_url	string	卡牌图片 URL
is_token	boolean	Token 标志

术语	定义
WB	Shadowverse: Worlds Beyond
PP	Play Point（法力）
EP	Evolve Point（进化点）
SEP	Super Evolve Point（超进化点）
RAG	Retrieval Augmented Generation（检索增强生成）
OCR	Optical Character Recognition（光学字符识别）
Token	游戏中生成的特殊卡牌
Lethal	必杀，确定胜利的一击

2) 基础设计（以需求定义为输入生成）

随后，我们将需求定义书和游戏概述作为输入，请 AI 生成基础设计书。提示为 “请基于附加的需求定义书和游戏概述创建基础设计书”。
结果包括功能列表与职责边界、通用设计（数据标识、存储、版权声明）、各功能的 I/O 与 SLO、测试视角与 KPI 等。
以下为实际生成结果概要。

基础设计书（点击展开）

WB 对战录像解析AI｜软件基础设计书（按功能） v1.0（已优化）
#

最终更新: 2025-08-08 JST 目标: 自 v0.1 起的修改。已将“Shadowverse WB 游戏概述”中的术语/数值纳入规格，并扩充 F-09/10（爬虫/RAG）。

0. 目录
#

本书定位 / 前提

功能列表与职责边界（更新）

通用设计（数据、日志、认证、版权声明）

各功能基础设计（详细更新）

测试视角（按功能）

KPI 监控/仪表盘

安全/法律

变更历史

1. 本书定位 / 前提
#

目标: 将系统设计落实至实现级别，明确 I/O、主要流程、数据项、异常、监测、SLO。

范围: 离线解析批处理。未来低延迟需求见非功能/扩展章节。

2. 功能列表与职责边界（更新）
#

功能ID 名称主要职责输入输出依赖

F-01 视频导入API 签名 URL 生成、任务创建、入队 video_url, options job_id S3, Queue, PG

F-02 帧提取解码、场景切分/关键帧、音频分离 video_object frameset(meta) FFmpeg

F-03 UI 元素检测 HP/PP/EP/SEP/剩余时间/手牌数/墓地 frameset ui_timelines YOLO, OCR

F-04 卡牌识别矩形抽取→OCR/图像相似→融合 frameset, ui_timelines card_detections CLIP/OCR

F-05 事件提取 play/attack/evolve/super_evolve/... detections events 规则+学习

F-06 状态还原规则约束的状态迁移 events, ui_timelines states 规则引擎

F-07 建议生成候选手探索、RAG-LLM states, knowledge advices LLM, RAG

F-08 报告/高光时间线、SRT、短片 MP4 events, states, advices report assets 前端

F-09 知识获取 爬取攻略 WIKI 并规范化 crawl_targets card_db, knowledge_db HTTP/HTML

F-10 向量索引 文本/图像嵌入与近邻搜索 card_db, knowledge_db vector_index Qdrant/Milvus

F-11 公共 API /v1/analyze、/v1/advise、/v1/cards HTTP JSON FastAPI

F-12 运维/监控指标、追踪、漂移检测各类事件仪表盘/告警 Prometheus

3. 通用设计
#

3.1 数据标识符
#

job_id (ULID), event_id (job_id/seq), state_id (job_id/turn/side), card_id (official-derived), kb_doc_id。

3.2 存储
#

S3/MinIO: 原视频/帧/缩略图/高光/报告 JSON/SRT。

PostgreSQL: jobs, analyses, cards, card_sets, card_keywords, card_traits, archetypes, decks, knowledge_docs, knowledge_chunks, sources, crawl_runs, advice_logs。

Parquet: events/states 存档。

3.3 认证/授权/版权
#

API Key/OAuth2(CC)。管理类权限使用 RBAC。UI 页脚常显 © Cygames, Inc. 与非合作声明。

4. 各功能基础设计（详细）
#

4.1 F-01 视频导入API（v0.1 微调）
#

入出力/异常/SLO 与先前一致。

4.2 F-02 帧提取
#

代表帧基于 SSIM 场景差异 + 关键帧。fps=15/30 可选。

4.3 F-03 UI 元素检测（更新）
#

检测器：HP/PP/EP/SEP/剩余时间条/手牌槽/墓地/额外 PP 按钮。

OCR：数字与符号专用。剩余时间条使用宽度回归辅助。

4.4 F-04 卡牌识别（更新）
#

两条路径（OCR/图像）融合解码。候选文本与卡牌数据库的效果文本一致性用于重排序。

4.5 F-05 事件提取（扩展）
#

新类型：super_evolve, fusion, act, enhance, extra_pp_use, crest_gain, countdown_tick, transform, bounce, banish。

检测依据：动画效果/字幕/数值变化/音效（可选）。

4.6 F-06 状态还原（扩展）
#

模式添加 sep, extra_pp_available, crests[], counters{}。

一致性校验: 手牌≤9/场上≤5/PP≤10、EP/SEP 使用次数限制、超进化视为进化。

4.7 F-07 建议生成（更新）
#

规则库：致胜搜索、EP/SEP与额外 PP最优使用、破护及屏障处理。

RAG 输入: (a) 目标卡牌评价与用法、(b) 当前卡组架构策略、(c) 对局/卡组匹配指南要点。

4.8 F-08 报告/高光
#

重要回合提取增加 EP/SEP 使用 与 大伤害/全流程 权重。

4.9 F-09 知识获取（本次更新重点）
#

4.9.1 官方卡牌数据库爬虫

源: 官方 Deck Portal“卡牌一览”。

采集: 名称/职业/类型/费用/攻击/体力/稀有度/卡包/关键字/类型/是否 Token/效果文本/进化后文本/图片 URL/详情 URL。

设置: Token 包含 ON/OFF，语言=ja。

ID 设计: 若能抓取官方 ID，即用之；否则生成 wb:{slug}（基于 URL/名称正则化）。

图片: UI 不直接展示，仅内部相似度比对使用。优先从用户视频中切帧。

差分: 使用 If-Modified-Since/ETag、哈希比较、指数退避重试。

4.9.2 攻略 WIKI 爬虫

目标: 国内主流网站（如 GameWith, AppMedia 及社区文章）。遵守 robots.txt/ToS，限速。

提取内容:

卡牌评价/用法（分级/Tier/理由/连携/注意点）

卡组架构（名称/核心卡/关键卡/策略）

示例卡组（列表/使用数量/替代建议）

对局匹配（开中末期、先后手、EP/SEP 用法、取胜范围）

换牌策略

规范化模式:
{
  "archetype_id": "ARC-...",
  "name": "Control Dragon",
  "class": "Dragon",
  "core_cards": ["WB-001", "WB-045"],
  "flex_cards": ["WB-123"],
  "gameplan": {"early": "...", "mid": "...", "late": "..."},
  "mulligan": ["..."],
  "matchups": [{"opponent_class": "Witch", "plan": "..."}],
  "sources": [{"url": "...", "site": "...", "last_crawled": "..."}]
}
RAG 用分块: 800–1200 字，附 {class, archetype, card_id} 元信息。仅保留短摘录+出处 URL。

再训练用: 提取“关键卡”“推荐数量”“连携对策”等弱标签，指导卡牌使用推断模型与建议规则。

4.9.3 管道
Crawl -> Parse -> Normalize -> Validate -> Upsert(PG) -> Embed -> Index(Qdrant) -> QA(引用验证)
验证: JSON Schema 校验、必填字段、URL 存活、域名白名单。限制引用长度。

运维: 官方卡牌每日更新，WIKI 每周更新（开发期手动触发）。

4.10 F-10 向量索引与搜索（扩展）
#

Embedding: 文本使用 E5-multilingual 等，图像使用 CLIP。

搜索 API: POST /internal/search（text/image_vec/filters），k=20，BM25+HNSW 混合检索。

过滤器: class,cost,type,keyword,archetype,kind(doc)。

4.11 F-11 公共 API（更新）
#

GET /v1/cards 查询: q, class[], cost[min,max], type[], keyword[], token?

GET /v1/knowledge/search（internal）: q, class, archetype, card_id, k

4.12 F-12 运维/监控（更新）
#

指标: 导入至完成延迟、UI 检测信心度分布、卡牌识别 Top-1、事件 F1、EP/SEP/ExtraPP 误检率、RAG 引用率、爬虫成功率/差分数

告警: 官方卡牌差分连续 N 日为 0、引用链接 404、Embedding 失败率上升

5. 测试视角
#

F-03: HP/PP/EP/SEP 系列一致率，剩余时间条→超时阈值验证

F-04: OCR 误读字典测试，图像近邻 Top-5 正确率

F-05: 各事件类型 Precision/Recall，super_evolve/extra_pp_use/act 再现率

F-06: 手牌/场上/墓地/PP/EP/SEP 的一致性、额外 PP 使用预测一致性

F-07: 建议引用 URL 附带率，引用合法性校验（自动/手动）

F-09: 官方卡牌→模式充足率，WIKI→必填键提取率，去重，引用长度上限

E2E: 15 分钟视频解析≤2 分钟，建议主观评分≥4.2/5

6. KPI 监控
#

仪表盘：解析延迟/失败率、UI 检测/OCR 信心度直方图、卡牌识别准确率、事件 F1、EP/SEP/ExtraPP 指标、RAG 引用率、爬虫差分数

7. 安全/法律
#

仅限赛后回顾。TDM 范围内社内使用。引用最小化并注明出处。图片原则上从自身录制视频切取。

8. 变更历史
#

v1.0: 详细设计官方卡牌/攻略 WIKI 爬虫、状态/事件模式扩展、建议/RAG 强化、测试/KPI 更新。

功能ID	名称	主要职责	输入	输出	依赖
F-01	视频导入API	签名 URL 生成、任务创建、入队	video_url, options	job_id	S3, Queue, PG
F-02	帧提取	解码、场景切分/关键帧、音频分离	video_object	frameset(meta)	FFmpeg
F-03	UI 元素检测	HP/PP/EP/SEP/剩余时间/手牌数/墓地	frameset	ui_timelines	YOLO, OCR
F-04	卡牌识别	矩形抽取→OCR/图像相似→融合	frameset, ui_timelines	card_detections	CLIP/OCR
F-05	事件提取	play/attack/evolve/super_evolve/...	detections	events	规则+学习
F-06	状态还原	规则约束的状态迁移	events, ui_timelines	states	规则引擎
F-07	建议生成	候选手探索、RAG-LLM	states, knowledge	advices	LLM, RAG
F-08	报告/高光	时间线、SRT、短片 MP4	events, states, advices	report assets	前端
F-09	知识获取	爬取攻略 WIKI 并规范化	crawl_targets	card_db, knowledge_db	HTTP/HTML
F-10	向量索引	文本/图像嵌入与近邻搜索	card_db, knowledge_db	vector_index	Qdrant/Milvus
F-11	公共 API	/v1/analyze、/v1/advise、/v1/cards	HTTP	JSON	FastAPI
F-12	运维/监控	指标、追踪、漂移检测	各类事件	仪表盘/告警	Prometheus

要件定義・基本設計工程的感想

作为草稿阶段，AI 能快速生成如此完整的需求与设计文档，耗时约 1–2 小时，对初期概念验证非常有帮助。
在真实开发中还需持续打磨设计，但本次重点是 Vibe 编码流程，因此将这些文档作为 AI 参考资料，直接进入实现阶段。

实现（Vibe 编码）①：卡牌数据库

定位与目标

本功能作为教练 AI 系统（游戏场景识别与建议）的基础，首要实现卡牌信息数据库。由于仅包含 Web 爬虫和存储，不涉及复杂 AI 功能，难度相对较低，故优先开发此项。

开发环境

Windows 11
Visual Studio Code
Claude Code (Opus 4.1)
Playwright MCP Server

模式设计

提示为 “请参考游戏概述和需求定义书，创建卡牌数据库模式”。AI 生成了针对 PostgreSQL/SQLite 的模式，与需求定义书中数据项一致。主要字段如下：

列名	类型	说明
card_id	TEXT PRIMARY KEY	卡牌唯一 ID（如: "10111010"）
name_jp	TEXT	卡牌名称（日语）
name_ruby	TEXT	卡牌名称 Ruby 注音
cost	INTEGER	卡牌费用
attack	INTEGER	攻击力
defense	INTEGER	体力
rarity	TEXT	稀有度（青铜/白银/黄金/传说）
card_class	TEXT	职业（中立/精灵/皇家/魔术师/龙族/噩梦/主教/审判者）
card_type	TEXT	卡牌类型（随从/法术/护符）
card_set	TEXT	卡包名称
skill_text	TEXT	能力文本
evolved_skill_text	TEXT	进化后能力文本
flavor_text	TEXT	风格台词
evolved_flavor_text	TEXT	进化后风格台词
cv	TEXT	声优（CV）
illustrator	TEXT	绘师
is_token	INTEGER	Token 卡标志（0: 否, 1: 是）
has_card_style	INTEGER	是否具有卡牌风格（0: 否, 1: 是）
style_count	INTEGER	风格数量（不含基础版）

官方页面解析与爬虫生成

官方卡牌一览页面结构清晰，可获取图片与文本信息，因而决定从该页面实现爬虫。提示为 “用 Playwright 打开卡牌一览页面，解析结构，定位卡牌 API 并用 Python 实现爬虫”。
实际操作中，使用 Playwright MCP 捕获页面结构，成功定位卡牌信息 API，并以 Playwright + Python 实现爬虫，将数据写入数据库。

卡牌数据示例（点击展开）

{
  "card_id": "10134120",
  "name_jp": "マナリアフレンズ・アン＆グレア",
  "name_ruby": "マナリアフレンズ・アン＆グレア",
  "cost": 5,
  "attack": 4,
  "defense": 4,
  "rarity": "レジェンド",
  "card_class": "ウィッチ",
  "card_type": "フォロワー",
  "card_set": "伝説の幕開け",
  "skill_text": "【ファンファーレ】『アンの大英霊』1枚を自分の場に出す。自分の手札すべては3回スペルブーストする。 【進化時】相手の場のフォロワー1枚を選ぶ。それに3ダメージ。",
  "evolved_skill_text": "【ファンファーレ】『アンの大英霊』1枚を自分の場に出す。自分の手札すべては3回スペルブーストする。 【進化時】相手の場のフォロワー1枚を選ぶ。それに3ダメージ。",
  "flavor_text": "「マナリアは自由だからいいよねっ、グレア！」\n「アンはちょっと自由過ぎるかも」\n「ふふっ！グレアといると楽しんだもん♪」\n――マナリアに咲く華、アンとグレア",
  "evolved_flavor_text": "大いなる才は一つ歪めば大罪に。\n道を違わずいられるのは、聡明なる友のおかげ。\n大いなる力を使わなければ持ち腐れ。\n恐れず腕を伸ばせるのは、明朗なる友のおかげ。",
  "cv": "日笠陽子/福原綾香",
  "illustrator": "みけぼし",
  "is_token": 0,
  "has_card_style": 0,
  "style_count": 0
}

首次运行收集到常规卡牌 275 张，但未包含特殊 Token 卡。经提示切换至“包含 Token”列表后，最终收集到所有 327 张卡牌，数据库功能实现成功。
Playwright MCP 服务器不仅适用于 E2E 自动化测试，也能高效实施 Web 爬虫。当页面过于庞大时可能触及 25,000 token 限制导致加载中断，需在后续针对该问题设计回避策略。

感想

通过 LLM 快速生成了高质量的需求定义与基础设计草稿。除了文档初稿，还能让 AI 代为进行合规调查等，从而大幅节省时间。
实现阶段亦遵循“人发提示 → AI 编码/测试/修复 → 人确认并修正”的循环，高效推进，少量返工即可完善细节。
虽然完全交由 AI 仍有难度，但在一天内完成至此，已足够震撼。系统要完成尚需更多步骤，但只要动力持续，将不断前行。