0. Hola hermano y hermana
-
yo是谁： 我是一名芯片设计行业的PM/FAE，FPS玩家、csgo/pubg/ow
-
yo是怎么用 TRAE 把 Demo 做出来的： 第一次和 TRAE 开口前，我脑子里其实只有一团东西——“想做那种玩家一死就自动打开抖音的东西”。这话说出来自己都觉得飘。但 TRAE 没催我写需求文档，它直接让我把意图讲清楚。我打字的原话大概是：“检测电脑上运行的射击游戏，玩家阵亡时自动打开浏览器刷视频，再做一个前端页面配置重定向网站和看死亡统计。”
就这一句。换以前我会想：这要拆成几层架构？前后端怎么分？数据库要不要？结果 TRAE 没让我操心这些，它直接帮我拆成「桌面 Agent + 本地后端 + Web 看板」三端，连每端用什么技术栈（psutil / FastAPI / React+Vite）都给推荐了。那一刻我第一次觉得：原来一个完整的系统，可以从一句话里长出来。整个项目最让我头大的一关是 CSGO 怎么知道玩家死了 。游戏不会主动告诉你"嘿，我死了"。我一开始以为要去做屏幕 OCR，识别画面上的"阵亡"两个字——但这意味着要装 Tesseract、要截屏、要处理误识别，工程量巨大，我心里直打鼓TRAE 帮我跨过这道坎的方式很干脆：它告诉我 CSGO/CS2 控制台日志默认不写文件，但玩家可以在控制台执行 con_logfile “console.log” + con_log 1 开启，之后所有击杀/死亡都会输出到文件。它甚至帮我写好了正则—— Player X killed Y with Z 这种标准格式，外加 “you died”/“阵亡” 等关键词兜底。从"我以为要 OCR"到"原来 tail 一个日志文件就够了"，这一下让 demo 从"几乎做不出来"变成"周末就能跑通"。这是 TRAE 给我最大的那个坎—— 它让我知道有些坎其实根本不是坎，只是我不知道有更短的路 。
项目PRD在demo文件夹中的.trae\documents文件夹下
1. Demo 简介
-
是什么：GameDie 看板是 GameDie 项目的可视化前端，配合桌面 Agent 和后端服务使用。当玩家在射击游戏中阵亡时，Agent 自动打开浏览器跳转到预设视频网站刷视频；看板则让玩家配置重定向目标、实时查看死亡事件和观看时长统计。
-
面向谁：常玩 PUBG / CSGO / Apex / 守望先锋的 PC 玩家
-
功能主流程：
- 主流程：玩家打开看板 → 看板通过 WebSocket 连接后端 → 玩家继续游戏 → 阵亡时 Agent 上报后端 → 后端通过 WebSocket 推送给看板 → 看板实时刷新概览卡片与事件流，玩家同时看到浏览器自动打开刷视频。
- 配置流程：玩家进入配置页 → 选择预设网站或输入自定义 URL → 点击保存 → 后端 PUT /api/config → 立即生效（下次阵亡触发即跳转新 URL）。
-
核心功能描述：
-
看板主页（Dashboard）：实时概览 + 死亡统计 + 观看时长统计 + 当前游戏状态
-
配置页（Settings）：重定向网站选择、自定义 URL、Agent 参数
-
项目tech规格在demo文件夹中的.trae\documents文件夹下
2. Demo 创作思路
-
灵感来源：灵感来自一次真实的尴尬体验——在 CSGO 一局中被颗秒后，无聊到反复切屏刷抖音。突然意识到：“死亡时刻"其实是玩家情绪最低落、最需要转移注意力的瞬间，而这个瞬间完全可以被设计成一个"自动奖励窗口”。把"失败惩罚"反转为"娱乐奖励"，是这个创意的核心反转。
-
想解决的问题：这是个真实存在但被所有人默认忽略的痛点。在《CSGO》《PUBG》《Apex》《守望先锋》这类竞技射击游戏里：玩家平均每局死亡 5–15 次\每次复活等待 5–40 秒\累计占游戏总时长的 15%–25%。这段"死亡真空期"目前完全被浪费——玩家只能盯着死亡回放或倒计时发呆。按每天 5 局算，单日损失约 8 分钟， 年累计 48 小时 ，相当于整整两天纯娱乐时间被白扔。更深层的痛点是 情绪外溢 ：连杀带来的挫败感无法被即时消解，心态崩溃后操作变形，形成"死亡-烦躁-再死"的恶性循环，最终可能演变成摔鼠标、骂队友。而玩家自己甚至 无法量化 “我到底在游戏里浪费了多少时间”——因为没有人把这段死亡时间可视化出来。
-
为什么做这个方向：
- 判断一：选「日志解析」而非「屏幕 OCR」OCR 看起来通用，但工程量大、误识别率高、依赖 Tesseract。日志解析更精准——CSGO 控制台输出 Player X killed Y with Z ，一行正则就能命中，延迟 <1 秒。代价是需要玩家一次性配置开启日志输出，但这是一次性的，且我们做了自动脚本替玩家完成。 精准 > 通用，这是 demo 阶段最该做的取舍。
- 判断二：选「本地化」而非「上云」玩家数据（死亡次数、观看时长）完全在本地 SQLite，不上传任何服务器。理由有三：①玩家对游戏行为数据极敏感，上云会劝退；②本地部署零延迟，死亡瞬间 <1 秒打开浏览器；③参赛 demo 不需要后端运维成本。 牺牲了"多设备同步"这个伪需求，换来"开箱即用"这个真需求。
-
技术架构：
3. Demo 体验
项目demo已打包Zip，下载解压后，点击run.bat即自动启动，已封装好逻辑，本阶段实现csgo的自动检测以及配置&数据可视化的前端页面
https://my.feishu.cn/file/J5VYbnWDRoYTGixW6vHcuHHInue?from=from_copylink
4. TRAE 实践过程
.1892731060491351:56c5063e8cd7757704e0cd70d3a37108_6a4215b1d5772aa94796f7d7.6a43203157741486b446f898.6a432031df1b016ae989552a:Trae CN.T(2026/6/30 09:47:29)
.1892731060491351:6af77032f0339619f374c83b85fad1b3_6a4215b1d5772aa94796f7d7.6a4329c857741486b446fa61.6a4329c7df1b016ae989552b:Trae CN.T(2026/6/30 10:28:24)
.1892731060491351:1c25026e5ad67c83a1b8445e3efcebd2_6a4215b1d5772aa94796f7d7.6a432a9c57741486b446fa7c.6a432a9bdf1b016ae989552d:Trae CN.T(2026/6/30 10:31:56)
.1892731060491351:1ec3264bfb0fa0b3defd66e5f8f0d583_6a4215b1d5772aa94796f7d7.6a432bd757741486b446fa8f.6a432bd7df1b016ae989552e:Trae CN.T(2026/6/30 10:37:11)
.1892731060491351:c73cfa63b4f4cec2afd16d0011622455_6a4215b1d5772aa94796f7d7.6a432c8157741486b446fa99.6a432c81df1b016ae989552f:Trae CN.T(2026/6/30 10:40:01)
5. 对应的报名审核通过的帖子链接：
这工具不错
