桌面应用数据分析数据可视化【免费下载链接】cs-demo-managerCompanion application for your Counter-Strike demos.项目地址https://gitcode.com/gh_mirrors/cs/cs-demo-manager点击查看免费下载AGENTS.md是 CS Demo Manager 仓库面向开发者包括人类与 AI Agent的入门指南它浓缩了这个跨平台 Electron 桌面应用的技术选型、开发命令、进程架构、目录组织与编码约定。本文以此文档为骨架结合仓库内真实的源码、配置与脚本逐节展开解读——读完你可以快速定位代码应该写在哪、用什么命令构建与测试、如何遵循既有规范提交高质量的改动。项目定位为 Counter-Strike 录像而生CS Demo Manager 是一个跨平台Windows / macOS / Linux的 Electron 桌面应用与 CLI 工具专门用于分析Counter-StrikeCS2 / CS:GO的 demo 录像文件。核心工作流是解析 demo → 将数据存入数据库 → 呈现与分析。按 AGENTS.md 的描述它的功能面覆盖了玩家日常复盘与分析的全部环节数据统计比赛、玩家、战队维度的统计配合图表ECharts可视化复盘能力2D 回合回放视图round viewer、热力图heatmaps录像与导出视频生成、从 Valve 与第三方平台下载 demo、XLSX / JSON 导出衍生功能封禁追踪ban tracking、语音音频提取等。这一点也能在 package.json 的元数据中得到印证——项目自述为Companion application for your Counter-Strike demos关键词包括CS2、CS:GO、electron、react当前仓库版本为3.20.1。注意文档中提及的 Counter-Strike 插件位于仓库顶层cs2-server-plugin/与csgo-server-plugin/C 实现它们是控制游戏进程的插件部分与分析器本身相互独立。技术栈全景一次看懂谁负责什么AGENTS.md 的Stack一节开宗明义地给出了一条最重要的工程约定本项目使用 Vitevp。所有依赖管理与脚本执行都必须使用vp而非pnpm且vpCLI 需要预先安装。这一点在 package.json 中可以看到vite-plus以1.0.0版本列入 devDependencies而pnpm12.6.0仅作为packageManager声明出现——vp是实际的前端工程化入口。整个技术栈可以按层拆解层次技术选型承担职责桌面框架Electron44.5.1主进程、窗口、托盘、自动更新语言TypeScript应用与 CLI、C插件与原生 Node addon类型安全 高性能桥接UIReact 19、Redux Toolkit、React Router、Tailwind CSS 4、ECharts、Motion渲染进程界面后端PostgreSQLpgkysely、WebSocketws数据持久化与进程通信数据库形态内置捆绑 PostgreSQL由 server daemon 启动也支持外部模式连接已有库零配置开箱 灵活部署i18nLinguiJS Crowdin多语言Lintoxlint linter/目录中的自定义规则静态检查测试Vitest经vite-plus/test引入单元测试构建Vite、esbuild、electron-builder打包分发CS 生态akiver/cs-demo-analyzerdemo 解析、akiver/csgo-voice-extractor、csgo-protobuf、csgo-sharecodeCounter-Strike 专用能力其中与 Counter-Strike 深度相关的库值得一提akiver/cs-demo-analyzer承担 demo 二进制解析csgo-protobuf用于解码比赛信息 protobuf 消息可在 valve-match 模块 看到实际应用csgo-sharecode负责 sharecode 解析这些直接支撑了Valve 比赛拉取与demo 分析两大核心链路。常用命令开发、构建与质量检查AGENTS.md 按用途把命令分成了三类以下逐一对应 package.json 中的 scripts 说明其真实行为。开发Development命令作用对应脚本实现vp run dev以热重载方式启动 Electron 应用执行node ./scripts/develop.mjsvp run dev:cli以热重载方式启动 CLI执行node ./scripts/develop-cli.mjs构建Build命令作用vp run build生产构建main / server / preload 用 esbuild 打包renderer 用 Vite 打包vp run package先build再用 electron-builder 产出可分发的安装包vp run i18n:extract提取可本地化字符串为.po文件供 Crowdin 使用以 build.mjs 为例生产构建时会注入IS_PRODUCTION/IS_DEV等编译期常量并且一个值得注意的细节是构建产物不压缩标识符以保证写入日志的函数名可读、可追溯——这解释了 AGENTS.md 中logger 在构建期注入的设计动机。另外构建流程会检查CROWDIN_PERSONAL_TOKEN环境变量未设置时跳过翻译下载、仅包含英文设置后则通过crowdin download拉取各语言包。代码质量Code quality命令作用vp run compile仅做 TypeScript 类型检查tsc --noEmit不产出文件vp run lint全项目 lintvp lintvp run lint:fix自动修复 lint 问题vp run format用 oxfmt 格式化代码vp fmtvp run test运行全部测试vp testvp test src/path/to/file.test.ts只跑指定文件的测试vp run test:watch监听模式跑测试vp run deadcode查找死代码底层是knip提交前的验证工作流Validation workflowAGENTS.md 要求任何改动在提交前必须依次通过以下四步这是保证仓库质量的门禁vp check—— 一次完成 lint、format 与类型检查在 vite.config.ts 中还可看到 staged 配置*: vp check --fix意味着暂存文件在提交前会自动执行 check 并修复vp run test—— 全部测试通过vp run deadcode—— 不引入未使用的代码vp run i18n:extract—— 若新增或修改了任何面向用户的字符串必须执行并提交更新后的英文源目录catalogs。这四步与 package.json 中的脚本一一对应构成了从类型 → 风格 → 行为 → 资源的完整回归链。进程架构四个参与者围绕一个 WebSocket 中枢AGENTS.md 指出应用运行三个 OS 进程main、server、renderer加上一个可选的 Counter-Strike 客户端全部通过本地的 WebSocket 服务器通信。更详细的进程分工与接线说明记录在仓库的 进程通信技能文档 中其拓扑如下Electron main process ←IPC→ Renderer process (UI) Counter-Strike CLI ↕ ↕ ↕ ↕ └──────────→ WebSocket server process (daemon) ←───┴───────────┘各进程的职责与入口可以整理为一张表进程入口职责electron-mainsrc/electron-main/main.ts窗口管理、托盘、自动更新、IPC 注册serversrc/server/start-server.tsWebSocket 中枢守护进程将消息分发给类型化 handler运行后台任务分析、下载、视频队列renderersrc/ui/renderer.tsxReact UI只通过 WebSocket 客户端src/ui/web-socket-client.ts通信preloadsrc/preload/preload.ts通过contextBridge把 Node.js API 桥接给渲染进程clisrc/cli/cli.ts独立 CLI连接已运行的 daemon 或自行拉起一个attach-or-spawn-daemon.ts几个值得强调的架构事实均可在 进程通信技能文档 中找到证据server 是一个可脱离 GUI 的独立守护进程daemonGUI 与 CLI 通过daemon.json发现文件共享同一个 daemonattach-or-spawn 机制当没有任何客户端连接且无后台任务时daemon 会空闲退出。所有 WebSocket 消息都是{ name, payload?, uuid? }形式的 JSONserver 将入站消息分发给类型化 handler并以Reply/ReplyError应答。所有消息名枚举与共享类型集中在src/server/messages/。UI 与 CLI 共享推送通道server 的 push 消息会同时扇出到 renderer 与所有 CLI 客户端因此 CLI 发起的任务进度能实时出现在 UI 中反之亦然。与 Counter-Strike 的双向通信游戏启动时通过 C 插件cs2-server-plugin/、csgo-server-plugin/连接 WebSocket server插件上报事件game-client-message-nameserver 也可下发命令game-server-message-name典型的命令-响应通过 src/server/counter-strike.ts 中的sendMessageToGame完成超时或未连接时抛出CounterStrikeNotConnected/CounterStrikeNoResponse错误。目录结构代码应该放在哪里AGENTS.md 给出了完整的顶层结构结合仓库实际内容可以逐项印证cs2-server-plugin/ # C CS2 server plugin用于控制游戏 csgo-server-plugin/ # C CS:GO server plugin用于控制游戏 src/ cli/ # CLI 相关代码 common/ # 所有进程共享类型、错误码…… electron-main/ # 仅 Electron 主进程 node/ # 纯 Node.js 代码可用于任何非 renderer 进程 database/ # 按实体组织的 Kysely 查询matches/、players/、demos/ … embedded/ # 捆绑 PostgreSQL server 的生命周期管理 settings/ # 应用设置相关代码 counter-strike/ # CS 进程检测、游戏交互等 video/ # 视频处理FFmpeg、HLAE、VirtualDub 集成 filesystem/ # 文件系统工具 preload/ # Electron preload 脚本向 renderer 暴露 Node API server/ # WebSocket server 与消息 handlers handlers/ renderer-process/ # 处理来自 UI 的消息 main-process/ # 处理来自 Electron 主进程的消息 ui/ # React renderer store/ # Redux 类型化 hooks 与 reducers components/ # 可复用 UI 组件 shared/ # UI 工具、颜色、元素 ID feature/ # 每个功能一个目录matches、demos、player、match …几个从源码结构可以推断的组织原则分层清晰、按进程隔离common/是唯一可跨进程引用的区域node/则覆盖所有非 renderer 场景server/只关心 WebSocket 消息与 handlerui/纯前端。例如共享的error-code.ts位于 src/common/error-code.ts正是所有进程共享的典型。feature 目录聚合在 src/ui 下matches/、demos/、player/、match/、settings/等每个业务域一个目录每个目录内再按职责拆分 hooks、actions、reducer、组件。实体化数据库访问src/node/database 下按matches/、players/、demos/、kills/等实体组织 Kysely 查询另设 migrations当前含 71 个迁移文件管理 schema 演进。编码约定把规范写进规则而非口头AGENTS.md 明确要求跟随仓库既有模式与 lint 规则绝不修改 lint 配置来绕过规则。这也是仓库把部分约束做成自定义 ESLint 规则的根本原因。导入别名csdm/*指向src/*所有跨目录导入必须使用csdm/*别名。该别名在 vite.config.ts 的resolve.alias中定义resolve: { alias: { csdm: srcFolderPath, }, },例如从 UI 中引入 server 消息枚举写法是import { RendererClientMessageName } from csdm/server/messages/renderer-client-message-name而不是相对路径的长串../../../。Styling以 Tailwind 为主、token 为准组件样式一律使用Tailwind utility class内联样式仅用于动态值设计 token 定义在 src/ui/styles/variables.css绝大多数 Tailwind 默认值在该文件中被清空只保留项目 token间距、文字、颜色严禁使用p-[7px]这类任意值——项目中不存在这些默认工具类。配合 vite.config.ts 中better-tailwindcss/*系列规则enforce-consistent-class-order、no-duplicate-classes、no-unknown-classes等Tailwind 类名的书写顺序与合法性都在 lint 阶段被强制。State managementRedux Toolkit 类型化 hooks全局状态使用Redux Toolkit简单局部状态用 React 的useState/useReducer禁止引入新的状态管理库useDispatch与useSelector必须从项目内类型化封装导入而不是直接从react-redux导入。这一约定不仅是文档要求更被做成了强制 lint 规则自定义规则 linter/no-react-redux-import.ts 会拦截react-redux中的useDispatch/useSelector/useStore导入并自动修复为csdm/ui/store/use-dispatch、csdm/ui/store/use-selector、csdm/ui/store/use-store。类型化封装的实际实现见 src/ui/store/use-dispatch.ts基于useDispatchRedux.withTypesAppDispatch()与 src/ui/store/use-selector.ts基于useSelectorRedux.withTypesRootState()。Logging用全局logger禁止consoleAGENTS.md 规定使用全局logger一个自定义ILogger实例写入日志文件替代console。两点关键机制no-console规则在整个项目生效唯一例外是src/cli/CLI 直接面向终端输出logger在构建期注入所有文件无需 import 即可使用——这正是 vite.config.ts 中 lintglobals声明logger: readonly、以及构建时注入常量的原因。logger 的实体实现位于 src/node/logger.ts。Testing与源码同目录共置目前只有单元测试集成/E2E 测试留待后续测试文件与被测源码同目录共置命名为*.test.ts必须从vite-plus/test导入describe与it而不是直接从vitest导入。这一点与vp test src/path/to/file.test.ts的命令设计一致仓库中如 exit-daemon.test.ts、attach-or-spawn-daemon.test.ts、sort-sequences-by-start-tick.test.ts 都遵循就近共置的约定。i18nLinguiJS 双目录 Crowdin 托管应用使用LinguiJS本地化源字符串用英文书写通过vp run i18n:extract提取到各语言的 catalogrenderer 进程的 catalog 为src/ui/translations/{locale}/messages.po主进程的 catalog 为src/electron-main/translations/{locale}/*.json主进程使用独立的 src/electron-main/lingui.config.ts采用 JSON catalog只有英文源目录en/messages.po与en/messages.json会被提交其余语言在 Crowdin 上管理、构建期下载因此被 gitignore 且永不手动提交本地/开发构建若没有CROWDIN_PERSONAL_TOKEN则跳过翻译下载、运行时回退英文添加或修改字符串时只提交英文源绝不手工翻译.po/.json。多语言行为由根目录 lingui.config.ts 定义共 9 种语言en、fr、es、pt-BR、zh-CN、zh-TW、de、ru、slsourceLocale为encatalog 指向src/ui/translations/{locale}/messages。UI 侧还有一整套宏使用规范详见 i18n 技能文档优先使用编译期宏lingui/react/macro下的Trans、useLingui、Plural等而非运行时组件——这条同样被做成了强制 lint 规则 linter/lingui-js-usage.ts该规则禁止从lingui/react导入除I18nProvider之外的任何成员并自动将导入源改写为lingui/react/macro消息保持简单避免复杂表达式它们会被占位符替代非 JSX 场景属性、alert、函数参数用useLingui的t宏数组/对象中定义消息用msg宏数量相关的文案用Plural宏_N语法处理精确数字匹配日期用useFormatDatehook数字用Intl.NumberFormat配合当前 locale显式id只在src/electron-main/中使用renderer 内严禁手写 ID由宏自动生成。Git commits约定式提交提交信息使用Conventional Commits格式type(scope): description例如feat(demos): add tickrate column in table。另外明确要求不要把 AI 工具添加为 co-author。小结一份可执行的仓库规范回看 AGENTS.md它的价值不在于罗列规则而在于每条规范都能在仓库中找到对应实现说用vp别用pnpm因为 package.json 的 scripts 全部经由vp或node ./scripts/*.mjs驱动说别从react-redux直接导入 hooks因为有 linter/no-react-redux-import.ts 在 lint 阶段强制说别用lingui/react运行时组件因为有 linter/lingui-js-usage.ts 自动修复导入说别用console、用全局logger因为 vite.config.ts 在构建期注入logger且no-console全局生效仅src/cli/豁免说四条提交流程验证因为vp check、vp test、vp run deadcode、vp run i18n:extract分别对应vp check、vp test、knip、lingui extract的真实脚本。对于想要为这个项目贡献代码或接入其开发流程的开发者来说按本文梳理的顺序——先理解技术栈与进程架构再熟悉命令与目录最后遵守编码约定并走完验证工作流——就能以最低成本进入一个高度工程化、规范即规则的 TypeScript / Electron / React 代码库。赞分享桌面应用数据分析数据可视化【免费下载链接】cs-demo-managerCompanion application for your Counter-Strike demos.项目地址https://gitcode.com/gh_mirrors/cs/cs-demo-manager点击查看免费下载相关推荐SkyPilot 开发者指南从仓库结构、工程规范到架构模式与提交流程SkyPilot 开发者指南从仓库结构、工程规范到架构模式与提交流程 本指南以 SkyPilot 代码库中的 CLAUDE.md 开发文档为骨架面向在 Sk后端任务调度MLOps集群管理mise 仓库贡献者开发指南从 mbx 构建缓存、registry 提交流程到源码架构的完整解读mise 仓库贡献者开发指南从 mbx 构建缓存、registry 提交流程到源码架构的完整解读 mise 是一个用 Rust 编写、用于管理开发环境、工具版开发工具CLIInfisical 仓库工程指南从 Monorepo 架构到全栈功能开发的 CLAUDE.md 权威解读Infisical 仓库工程指南从 Monorepo 架构到全栈功能开发的 CLAUDE.md 权威解读 Infisical 是一个开源的密钥、证书与特权访问后端前端密钥管理应用安全认证鉴权上一篇抖音无水印下载神器3分钟搞定批量下载的终极秘籍下一篇如何一键获取八大网盘直链下载地址完整免费指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考