一、SLEF介绍
我是过去互联网时代的一名产品经理，现在转行做 IC 设计中的 AI 赋能工程师——平时除了在芯片设计流程里用 AI 提效、做工具链赋能，还喜欢天马行空地用 AI 做各种软硬件 idea
-
为什么做这个作品：源于日常真实的游戏体验，在csgo中被颗秒后，无聊到反复切屏刷抖音。突然意识到"死亡时刻"其实是部分玩家情绪最低落、最需要转移注意力的瞬间，而这个瞬间完全可以被设计成一个"自动奖励窗口"。把"失败惩罚"反转为"娱乐奖励"，是这个创意的核心反转
-
我擅长什么：我对 AI 技术与框架熟悉且热爱，过往的工作经验以及产品经验让我与AI协作把需求场景交付闭环成完整系统
-
Vibe Coding / 编程年限：接触 Vibe Coding 约 1 年，编程断断续续 3 年，主要靠与 AI 结对推进
-
性格标签：FPS重度爱好、PM、纸片人、高强度冲浪
二、Product介绍
是什么
gameDie 是一个纯本地运行的 AI 游戏助手（Local AI Game Companion）。它通过 GSI（Game State Integration）+ 控制台日志感知游戏状态，在玩家阵亡时自动打开浏览器跳转预设视频网站刷视频；并在看板上把"死亡—娱乐—时长"完整可视化，同时延伸出自动录屏、AI 精彩片段、AI 复盘点评、外设推荐等能力，形成"越死越想刷"的轻量游戏化闭环
形态：桌面 Agent + 本地后端 + Web 看板 三端组成，纯本地运行，零上云、零侵入游戏（不修改游戏文件、不注入 DLL、不读取内存）
核心价值：把"阵亡等待复活"的枯燥时间，自动转化为可量化的娱乐时长，并在此基础上叠加 AI 复盘与自动内容创作，让玩家只需"启动 → 游戏 → 结束"就能自动获得总结、录像与精彩片段
面向谁
- 核心用户：常玩 CSGO/CS2、PUBG、Apex、守望先锋的 PC 玩家
- 典型场景：
- 竞技对局中被击杀后 5–40 秒复活等待期，从不报点的人在刷视频；
- 想量化"我在游戏里浪费了多少时间"的自我数据党；
- 想自动产出对局复盘 / 精彩片段的内容创作者。
完整功能清单与用户使用路径
A. 初赛Demo已实现的核心功能清单
| 模块 | 功能 | 说明 |
|---|---|---|
| Agent 进程检测 | 自动识别运行中的射击游戏 | psutil 轮询 + 进程名匹配，支持 CSGO/CS2 实测，PUBG/Apex/OW 占位适配器 |
| 死亡检测 | CSGO/CS2 双重检测 | GSI 主策略（本地 HTTP 接收 CS2 推送，通过 player.match_stats.deaths 计数递增精确判死）+ 控制台日志兜底（正则匹配 Player X killed Y with Z） |
| 自动打开视频 | 阵亡即跳转 | 拿到 watch_session_id 后最小化游戏窗口，打开默认浏览器跳转抖音/B站/YouTube/自定义 URL |
| 看板主页 | 实时概览 | 总死亡数、观看时长、当前游戏、最近死亡时间，含环比 delta，数字滚动动效 |
| 看板主页 | 死亡趋势图 | 柱状/折线复合图，按日或按小时聚合，可切游戏筛选 |
| 看板主页 | 观看时长图 | 堆叠面积图，按日聚合，按视频网站分组 |
| 看板主页 | 死亡游戏分布 | 环形图 + 图例 |
| 看板主页 | 最近事件流 | 实时滚动，新事件顶部插入并高亮闪烁 |
| 配置页 | 重定向网站选择 | 抖音 / B站 / YouTube / 自定义预设卡片，点击切换即时生效 |
| 配置页 | 测试按钮 | 立即触发一次模拟死亡，验证重定向链路 |
| 通信 | WebSocket 实时推送 | 死亡 / 观看 / 游戏状态事件实时广播到看板 |
| 数据 | 本地 SQLite | 死亡记录、观看会话、配置持久化，零上云 |
| 国际化 | 中英双语 | react-i18next，看板与配置页全覆盖 |
| 部署 | 一键启动脚本 | run.bat 自动检测环境 + 安装依赖 + 配置 CSGO + 启动三端 |
B. 复赛新增与打磨的已落地功能
| 模块 | 新增功能 | 说明 |
|---|---|---|
| 自动返回游戏 | Dashboard 自动关闭 + Alt+Tab 回游戏 | 支持 5/10/30 秒/自定义，关闭后自动切回游戏，降低使用成本 |
| Timeline 时间轴 | 比赛事件时间轴页面 | 展示 00:32 击杀 / 01:20 死亡 / 02:15 ECO / 03:44 ACE，点击事件可跳转对应录像片段；尊重用户手动选择历史比赛，不被实时比赛抢占 |
| AI Match Summary | 比赛结束自动复盘 | AI 生成 MVP / 最大失误 / 最佳操作 / 死亡原因 / 经济分析 / AI 点评 |
| 自动录屏 | ffmpeg + gdigrab 自实现录屏 | 对局开始自动录制，死亡回捞死亡前片段，比赛结束停止；硬件编码器自动探测降级，无 N 卡也能用 |
| 精彩片段库（Media） | 媒体库页面 | 统一管理录像 / 封面 / 字幕，按比赛分组，支持筛选与播放 |
| AI 标题/简介生成 | 一键 AI 生成视频标题与简介 | 视频详情页大按钮 + 卡片  快捷按钮，基于比赛时间轴生成适合短视频平台的标题 |
| 外设推荐 | Gear 配置页 + AI 外设顾问 | 读取本地 DPI / 键盘 / 耳机 / 网络延迟，AI 个性化推荐外设配置 |
| FPS 与网络监控 | 实时游戏 FPS 与延迟 | GSI 2 秒窗口计算 FPS（10-500fps 过滤），检测加速器进程获取公网 IP 测延迟 |
| Agent 注册表 | AI Agent 集中管理 | Settings 中可启用/禁用各 AI Agent（复盘 / 外设 / 死亡分析 / 视频标题） |
C. 用户使用路径（复赛完整闭环）
相比初赛 Demo 的升级
| 维度 | 初赛 Demo | 复赛成品 |
|---|---|---|
| 定位 | 阵亡自动刷视频看板 | 本地 AI Game Companion |
| 死亡检测 | GSI + 控制台日志双重检测 | 继续保持 + 精准识别本地玩家 SteamID，观战队友不再误触发 |
| 闭环 | 检测→刷视频→看板统计 | 检测→统计→录屏→精彩片段→AI复盘→外设推荐 |
| 用户操作 | 需手动切回游戏 | 自动返回游戏 + 可配延时 |
| 内容产出 | 无 | AI 总结 + 精彩片段 + AI 标题简介 + 素材库 |
| 数据洞察 | 死亡/观看统计 | + 实时 FPS + 网络延迟 + 外设画像 |
| 商业化方向 | 无 | SDK 授权 + 设备合作双方向 |
| 部署 | 手动分步启动 | run.bat 一键启动 + 环境自动配置 + CSGO 自动配置 |
三、产品演示视频
共 3 支视频，分别覆盖完整使用教程与三大核心功能演示：
视频 1：【gameDie】如何使用项目的教程（完整流程与使用教程）
https://www.bilibili.com/video/BV1Jo346uEaA/
从 run.bat 一键启动开始，完整走查项目全部流程：环境自动检测 → 三端启动 → 看板主页 → 配置页 → Timeline 时间轴 → Media 精彩片段库 → Review 复盘页 → Settings Agent 注册表，一眼看懂完整产品全貌与使用
视频 2：核心功能①和② — 自动跳转与返回 + AI 分析演示
https://www.bilibili.com/video/BV16R3466E6Q/
实机演示玩家阵亡瞬间的核心闭环：
- 功能①·自动跳转：GSI 检测到死亡 → 最小化游戏 → 自动打开浏览器刷视频；
- 自动返回游戏：可配延时（5/10/30 秒）后自动 Alt+Tab 回游戏；
- 功能②·AI 分析：比赛事件实时进入 Timeline，比赛结束自动生成 AI 复盘点评（MVP / 失误 / 最佳操作 / 死亡原因）
视频 3：核心功能三 — 自动录制与 AI 生成功能演示
https://www.bilibili.com/video/BV1oF3t6KEXH/
实机演示自动录屏与 AI 内容创作闭环：
- 对局开始自动启动录屏（编码器自动探测降级）；
- 死亡/击杀/ACE 触发回捞精彩片段；
- 比赛结束停止录屏 → Media 精彩片段库自动生成封面/字幕；
- 一键 AI 生成视频标题与简介（ 按钮）
四、产品心路历程
灵感诞生
灵感来自一次真实的尴尬体验——在 CSGO 一局中被颗秒后，无聊到反复切屏刷抖音。突然意识到：玩家平均每局死亡 5–15 次、每次复活等待 5–40 秒，累计占游戏总时长的 15%–25%。按每天 5 局算，单日损失约 8 分钟，年累计 48 小时，相当于整整两天纯娱乐时间被白扔。
更深层的痛点是情绪外溢：连杀挫败感无法即时消解，心态崩溃后操作变形，形成"死亡—烦躁—再死"的恶性循环。而玩家自己甚至无法量化"我到底在游戏里浪费了多少时间"——因为没有人把这段死亡时间可视化出来。
把"失败惩罚"反转为"娱乐奖励"，是这个创意的核心反转。
最真实的 FPS 玩家需求洞察
这个项目不是拍脑袋想出来的，而是每一个 FPS 玩家都经历过、但没人把它做成产品的真实需求。
场景一：死亡后的本能动作
如果你问任何一个 CSGO / PUBG / Apex 玩家"你死了之后会做什么"，答案几乎一致——“切出去刷手机"或"Alt+Tab 看网页”。这是竞技射击游戏玩家的集体本能行为。因为在 5–40 秒的复活等待期里，玩家无事可做，大脑需要一个快速的"情绪重置"——而刷一条 15 秒的抖音短剧，恰好是成本最低、效果最好的情绪重置方式。
GameDie 做的，就是把"切出去刷手机"这个本能动作自动化、零延迟、无缝化。
场景二：连续死亡对情绪的摧毁性影响
FPS 玩家都懂那个"死亡螺旋"：被颗秒 → 烦躁 → 急着返场 → 操作变形 → 又死了 → 更烦躁 → 摔鼠标 → 喷队友 → 连败。GameDie 的价值不仅仅是"帮你打发时间"，而是在每一次死亡瞬间给你一个正向的替代体验，切断"死亡—烦躁"的神经回路。
场景三：你根本无法量化"情绪损失"
GameDie 的 Dashboard 就是第一面照妖镜。当玩家看到"本周死亡 47 次，累计等待 23 分钟"时，这个数据本身就是一种觉醒。
第一次开口：一句话长成一个系统
第一次和 TRAE 开口前，我脑子里只有一团东西——“想做那种玩家一死就自动打开抖音的东西”。我打字的原话大概是：
“检测电脑上运行的射击游戏，玩家阵亡时自动打开浏览器刷视频，再做一个前端页面配置重定向网站和看死亡统计。”
就这一句。换以前我会想：这要拆成几层架构？前后端怎么分？数据库要不要？结果 TRAE 没让我操心这些，它直接帮我拆成「桌面 Agent + 本地后端 + Web 看板」三端，连每端用什么技术栈（psutil / FastAPI / React+Vite）都给推荐了。那一刻我第一次觉得：原来一个完整的系统，可以从一句话里长出来。
关键坎一：CSGO 怎么知道玩家死了
整个项目最让我头大的一关。我一开始以为要去做屏幕 OCR，识别画面上的"阵亡"两个字——工程量巨大。TRAE 帮我跨过这道坎的方式很干脆：它告诉我 CSGO/CS2 控制台日志默认不写文件，但玩家可以在控制台执行 con_logfile "console.log" + con_log 1 开启，之后所有击杀/死亡都会输出到文件，一行正则 Player X killed Y with Z 就能命中。从"我以为要 OCR"到"原来 tail 一个日志文件就够了"，让 demo 从"几乎做不出来"变成"周末就能跑通"。
关键坎二：从日志到 GSI，精度再上一个台阶
初赛阶段日志解析跑通了，但依赖玩家一次性开启控制台日志。进入复赛后，TRAE 又带我发现了 GSI（Game State Integration） 这条更精准的路：在 CS2 cfg 目录写入配置文件，启动本地 HTTP 服务器接收 CS2 主动推送的游戏状态 JSON，通过 player.match_stats.deaths 计数器递增即可精确判断本地玩家死亡，无需玩家任何手动配置。最终采用 GSI 为主策略 + 控制台日志为兜底策略 的双重检测，实测延迟 <1 秒。
复赛迭代中还发现一个坑：GSI 在观战模式下会切换到队友数据，导致队友死亡时也误触发开浏览器。TRAE 帮我定位到 GSI 配置必须带上 provider 字段才能拿到本地玩家 SteamID，于是在 gsi_server.py 中提取本地 SteamID，只有当前 player 的 SteamID 与本地一致时才触发死亡事件——观战队友死亡不再误触发。
关键坎三：视频录屏——AI 想用"最高级方案"，但我选了"最合适方案"
这是整个复赛过程中我最想分享的一段工程心得。
开发自动录屏功能时，AI（TRAE）一开始就倾向于给我推荐"最高级"的方案：基于 ffmpeg + 硬件编码（h264_nvenc） 来录制——这套方案的好处很明显，显卡直接硬编码出视频，CPU 占用极低，画质与帧率都顶。
但问题来了：这套方案受限于显卡。h264_nvenc 只在 NVIDIA 显卡上可用，而使用这个项目的玩家不一定有 N 卡。我在自己的机器上就遇到了——ffmpeg 编译时支持 h264_nvenc，但运行时因为驱动/硬件不可用直接崩溃，录屏文件损坏（0xc00d36c4 错误）。
通过和 TRAE 的多轮工程权衡，最终我做了一个决定：不绑定"最高级"，改用"最朴素且最直接"的做法——
-
编码器运行时探测：不靠编译时列表判断，而是实际跑一次 test encode 验证编码器是否真的可用；
-
硬件优先 + 软编兜底：按 h264_nvenc → amf → qsv → libx264 顺序探测，任何一个能用就用，全不行就 libx264 软编；
-
采集层用 gdigrab -i desktop：不绑定游戏窗口（DirectX 窗口捕获会黑屏），改为捕获整个桌面，配合 CS2"无边框窗口"模式即可正常录制。
这段经历给我的启发：AI 天然倾向于给你"技术上最优"的方案，但"技术最优"不等于"项目最优"。一个方案再高级，如果它把用户门槛抬高、把通用性砍掉，那它对产品就是负担。最终还是要选择合适的、低成本的方案来做，这样能让整个项目的通用性、快捷性、以及快速迭代的上限，都达到预期。 这也是我作为产品经理转 AI 工程师最深刻的体会——技术选型的第一性原理不是"多炫"，而是"多适配"。
关键设计与技术决策
-
判断一：选「日志/GSI 解析」而非「屏幕 OCR」——OCR 看起来通用，但工程量大、误识别率高；日志/GSI 更精准，延迟 <1 秒。精准 > 通用。
-
判断二：选「本地化」而非「上云」——玩家数据完全在本地 SQLite，零延迟、零隐私顾虑、零运维成本。牺牲了"多设备同步"这个伪需求，换来"开箱即用"这个真需求。
-
判断三：插件化适配器架构——Agent 采用
BaseAdapter+ 多游戏子类，动态加载实现游戏切换无感，为后续多游戏扩展留好接口。 -
判断四：三端解耦 + WebSocket——Agent / 后端 / 前端完全解耦，任何一端可独立替换。
-
判断五：录屏模块可插拔——录屏模块独立目录、独立表、独立 service 层，即使整个删除，现有 Agent 也能正常运行。
开发关键步骤过程截图证明
.1892731060491351:412ee69d94c51c10c6c8bc62935dc552_6a616d0a6ba491a265b78956.6a6180e56ba491a265b78dea.6a6180e5ed2a88cffd0584dc:Trae CN.T(2026/7/23 10:48:05)
.1892731060491351:0b8b274f8ccd64ff731bd79f1fa012ff_6a60a7216ba491a265b78699.6a61b61cd536ee4491d89d10.6a61b61ccbbe7f9937fc5d59:Trae CN.T(2026/7/23 14:35:08)
.1892731060491351:2b83eccc9ea04d26965b44a0ac6a9420_6a6063b06ba491a265b782a7.6a6063ce6ba491a265b782a9.6a6063ceed2a88cffd0584be:Trae CN.T(2026/7/22 14:31:42)
.1892731060491351:f24fdfe2ed8a3d22d266457b86648060_6a66afbb7c16f52b517d5e7d.6a66b95b7c16f52b517d60ad.6a66b95b578add4431e8b9eb:Trae CN.T(2026/7/27 09:50:19)
.1892731060491351:246a2efaa853e570206242978f6b1d72_6a66afbb7c16f52b517d5e7d.6a66b9cd7c16f52b517d60ca.6a66b9cc578add4431e8b9ec:Trae CN.T(2026/7/27 09:52:13)
.1892731060491351:7b0830c2302db75524e8c35d1d19723e_6a6188f06ba491a265b790da.6a62cbdb8952030fb2b7b039.6a62cbda3564a6a1d064d805:Trae CN.T(2026/7/24 10:20:11)
六、技术方案思考与商业化分享
技术栈：
| 层 | 技术 | 说明 |
|---|---|---|
| 桌面 Agent | Python + psutil + FastAPI | 进程检测、GSI HTTP 服务器、事件采集、ffmpeg 录屏 |
| 后端 | Python + FastAPI + SQLite | 数据持久化、WebSocket 广播、AI Service 层 |
| 前端 | React + Vite + TypeScript + Tailwind | 看板、Timeline、Media 库、Settings |
| 图表 | ECharts | 死亡趋势、观看时长、游戏分布 |
| 录屏 | ffmpeg + gdigrab + 编码器自动探测 | 硬件优先软编兜底，无 N 卡也可用 |
| AI | LLM API + Agent 注册表架构 | 复盘 / 外设 / 死亡分析 / 视频标题 4 个 Agent |
| 国际化 | react-i18next | 中英双语 |
关键实现思路：
- GSI 双重检测：GSI 为主（精确，
player.match_stats.deaths递增）+ 控制台日志为兜底（正则匹配），延迟 <1 秒； - 本地玩家精准识别：从 GSI
provider字段提取 SteamID，仅本地玩家死亡才触发，避免观战误触发； - 录屏编码器运行时探测：不靠编译时列表，而是实际 test encode 验证，按 nvenc → amf → qsv → libx264 降级；
- 录屏模块可插拔架构：前端独立路由/store/API 客户端，后端独立 router/database/service，Agent 侧独立目录，删除不影响现有功能；
- AI Agent 注册表：
registry.py集中管理，新增 Agent 只需注册一条 AgentMeta，Settings 中可启用/禁用。
商业化与社会价值分析
商业化两步走：
- AI 复盘 + 内容创作订阅：面向内容创作者的 AI 剪辑、AI 标题、自动发布能力，按月订阅；
- 设备合作方向：读取本地 DPI / 键盘 / 耳机 / 网络延迟，AI 个性化推荐外设三件套 / 加速器 / 游戏电脑，与设备商家分成。
长期价值——Game Context Engine：未来任何 AI 游戏产品（Cursor for Game / Claude Game / OpenAI Game / 腾讯AI / 网易AI）都需要知道"玩家在哪、有没有死亡、有没有开局、当前比分、经济、地图"，它们不会自己写感知层，而是 npm install gamedie 然后 subscribe() 收到 PlayerKilled / PlayerDead / BombPlant / RoundStart / RoundEnd 事件。通过 SDK 授权 + API 调用 + 商业 License 收费，这是长期价值所在。
社会价值：把"失败惩罚"反转为"娱乐奖励"，用行为心理学中的"刺激重置"切断"死亡—烦躁"的恶性循环，帮助玩家管理情绪、量化时间损失，提升游戏心理健康。
产品迭代规划
- P2 多游戏适配：插件化支持 PUBG / Apex / LOL / Valorant，OCR 作为辅助识别方式；
- P2 AI Coach：根据历史数据生成成长报告、训练建议、英雄/武器推荐；
- 阶段 B 抖音自动发布：抖音开放平台 OAuth 授权 + 视频上传 + 发布（待权限审核）；
- 多信号融合架构：Log / GSI / Replay / OCR / Vision 多信号融合，提升检测精度与游戏覆盖度。
