Posts

任务 拿到一个安装包，要求做到四件事： 搞清楚该类型安装包的具体名称； 搞清楚它的内部信息存储结构，尝试解析存储结构中字段的含义，并用结构体实现相关定义； 搞清楚该安装包内嵌文件的存储方式，以及如何还原出内嵌文件； 在前两步的基础上，通过代码实现该类型安装包的解包程序——输出包内部信息，甚至还原出包内的内嵌文件。 第 1 条的答案这篇不写，所以下面所有截图和描述都只到「某类安装包」这一层。留着的只有方法路径、偏移量、结构体字段，以及几个我自己踩过的判断。原始样本只以 GPG 加密的形式随仓库发布。 这四条的排列本身就值得说一句：它是一条从"这是什么"到"我能复刻"的递进链，而不是四个并列的问题。名称和结构是认知，存储和还原是操作，最后代码只是把前三步的结论固化下来。做的时候如果跳过 2 直接奔 4，写出来的东西通常只对眼前这一个包成立。 一、寻找 buf 既然是安装包，资源肯定在自身。 第一反应是走 PE 资源：安装包嘛，图标、版本信息、对话框都在资源段里，内嵌文件大概也在那。打开资源看了——没有找到有用信息。这条路是死的，划掉。 ...

这篇讲什么 不讲某个站怎么抓，讲的是：**从零开始要把「一整本小说」落到本地 txt，中间必须依次解决哪几件事。**顺序错了，代码就只是碰巧能跑。 边界先说清：全文不出现站点名、域名、书名，也不放任何章节原文，只讲方法。 一、先拿目录，别先拿正文 最常见的错误起手是：打开某一章，F12，把正文框选出来，写个循环。这么写能抓一章，抓不了一本书。 正确的第一个目标是目录页。理由很实在：正文页会缺章、会挂「上一页/下一页」、会插推荐位，而且正文页给不出「这本书一共多少章」这个信息。目录页是唯一同时提供「章节有序清单 + 每章地址」的地方，它是整本书的真相来源。数量对不对、顺序对不对，后面都得回到它来核。 目录页要取两样东西，分两次取：链接列表和标题列表，然后按同一个下标配对。这么写有个前提——两个列表长度必须相等。一旦目录里混进非章节链接，两个列表整体错位，你会拿到一堆用章节名命名、内容却是简介页的文件。而书名页同时挂「相关推荐」「作者其它作品」是非常普遍的做法。 **所以限定结构层级，比把所有链接取出来重要。**宁可只取目录容器里某个特定路径下的 a，也不要 //a 全取。目录这一步我愿意花的功夫基本就在这。 二、URL 是相对还是绝对，要在下载之前判断 模板站的章节链接经常是 /book/123/4567.html 这种相对路径。直接丢给 requests 要么报错，要么拿到莫名其妙的东西。 ...

先说结论：我花了 2002 轮 agent loop、29.1 小时墙钟，拿到一支 27 秒的宣传片，而它的评审分数在中途从 13/12 掉到 10/6。 成品在这儿，你们自己判断值不值： 【AIGC】世界游戏 · 27 秒宣传片 我对画面本来就不满意。但比画面更让我无语的是成本结构——所以我今天不吐槽美术，吐槽 loop。 一、账单 这是我从那次会话的完整记录里逐条数出来的（jsonl，28MB / 10818 行）： ...

起因：博客发完，流程本身值得沉淀 前几天 AI 帮我剪 R6S 游戏视频，剪完我觉得可圈可点，让它把经验总结进了知识库，还顺带写了一篇「我是如何用 AI 帮我剪视频」的博客，发布到了我的博客站点。 博客发完，我想到另一件事：这次发布的过程——拟稿、审阅、提交、验证——也是一套值得固化的流程。下次再发博客，不该从头摸索。于是让 AI 把"AI 发布博客"这件事整理成一份标准操作流程（SOP），存进知识库新开的 sop/ 目录。 初版 SOP 是三段式： 前置：内容先经我审阅——拟大纲 → 拟全文 → 我点头才发布 流程：clone 仓库 → 文章放进 content/posts → commit → push 验证（必做，缺一不可）：Actions 构建 success、两个入口 200、页面标题对上 初稿看着完整，但我审了一遍，提了两处修正。 ...

最近让 AI 帮我剪了一批《彩虹六号：围攻》的高光视频：5 个 1GB 的游戏录屏，每个 20 分钟，最后产出 8 条几十秒的精彩片段，发布到抖音和 B 站。整个过程里 AI 干的活不是「自动剪」，而是「按我定的审美规则执行流水线」——我想聊聊这中间的差别，以及踩过的坑。 为什么是「AI 帮我剪」，而不是「AI 自动剪」 游戏录屏有个特点：体量大、密度低。一个 1GB、20 分钟的文件里，真正值得剪的回合可能就两三段，每段几十秒。让 AI「全自动」剪，它很容易把「有人开枪」当成「精彩」，剪出来是一堆没人味的枪声合集；人肉剪呢，对着 20 分钟视频一帧一帧找高光，一场打完要花掉大半个晚上。 ...

前言（唯一的人类部分） 哦，其实并非，因为ai没有图片能力，所以图片都是我插的。 首先感谢豆姐，豆包工作下载即送30天会员（不是广告） 豆姐都不嫌我穷，我还怎么嫌豆姐弱呢？真的，蹬了一天了，蹬不完，根本蹬不完，别看我1天快把7天的量蹬光了，但是我今天又是更新知识库，又是同步github，又是组织迁移，又是宣发，又是让豆姐处理issue，又是整理文档记忆啥的。 omg，这都蹬不完，豆姐大气，太大气了，这不宣传一下真没话说。 对了，b站那边我发了（只有上传和发布是我干的，其他时候全是豆姐干的，ai忠诚的手这一块）。说起来豆姐不仅有全套剪辑能力（其他的没有），还有云电脑，终于不用担心电脑风扇转太快崩掉了。 太久不写md了，正在思考怎么写引用…… 【AIGC】这个对战棋，是一个人两天半肝出来的 【AIGC】30 秒学会《烽决》—— 比军棋多三个玩法 【AIGC】15 秒，看懂这盘棋有多狠 【AIEC】两天半，从 0 到可玩 alpha：一个人的游戏工作室 欢迎体验，也欢迎提issue（在本博客下面留言，我会处理） 起因 《烽决》(duelchess) 是我和我的 Agent 用两天半做出来的游戏——严格说，是一套完整的「游戏工作室管线」：130 次提交、9,453 行代码（72 个文件）、74 个单元测试、173 张美术素材、30 个音效（15 类）、4 张地图，当前版本 v1.0.0-alpha.1（可玩 alpha）。 ...

前情：《两天半，1 个人 + 1 个 AI，我造了一家游戏工作室》——我靠一个 WorkBuddy Agent，两天半做出可联机桌游《烽决》。这篇拆方法论的内核：怎么把一个 AI 当一支团队使。 一、先纠正一个误区：「一个 AI」不等于「一个员工」 大多数人对 AI 编程的想象是：一个很能干的员工，你下需求，他写代码。这么用，你只能得到一个累死的全栈实习生。 我的用法是：一个 Agent，多个会话，每个会话绑定一个专家角色——PM、前端、后端、规则设计师、美术、音效、DevOps。它们不共享对话记忆，但共享同一批 Git 仓库和文档。这支「团队」的组织结构长这样： 你（创意总监 + 终审） │ WorkBuddy Agent ┌────────┬────────┼────────┬─────────┐ PM 会话 前端会话 后端会话 美术会话 音效会话 │ │ │ │ │ └─────────┴────┬───┴────────┴─────────┘ 共享记忆：Git 仓库 + 文档 （五仓结构 / PRD / 数据清单 / 进度复盘 / 工作日志） 关键不是「多开会话」，而是每个会话只干一类事、只看自己该看的文档。PM 会话不写代码，前端会话不管部署，美术会话不碰规则。 ...

如果我说，一个只会写代码、不会画一张图、不会写一段旋律的人，用两天半时间，从零做出一款能联网对战的桌游——你大概会觉得我在吹牛。 但这是真的。更关键的是：我没有雇人，没有外包，背后是一支「AI 工作室」——一个 WorkBuddy Agent，在我这个「创意总监 + 终审」的指挥下，分饰 PM、前端、后端、规则设计师、美术、音效、DevOps 八个角色。 下面是这份「两天半造一家游戏工作室」的完整复盘。 一、先上硬核数据 两天半 · 1 个人 · 1 个 WorkBuddy · 130 次提交 · 5 个仓库 9.5 千行核心源码 · 74 个单元测试全绿 · 4 张地图 · 173 张美术贴图 · 30 个音效 8 大管线一人包揽：前端 / 后端 / 规则引擎 / 地图编辑器 / 美术 / 音效 / CI·CD / 文档 （游戏叫《烽决》，一款军棋变体的双人——同屏 / 联机——战棋桌游。先记住名字，文末有试玩。） ...

最近拉 GitHub 上的 release 和 raw 文件，速度又回到了熟悉的几 KB/s。第三方聚合加速站（比如 github.akams.cn 那种测速导航）确实方便，但用别人的节点总有点不踏实：下载 URL 全程经过陌生人的 Worker，人家理论上能记录你访问了什么仓库、甚至改写内容，防不胜防。而且节点质量参差不齐，三天两头失联。 既然自己有 Cloudflare，干脆自建一个。 原理其实很简单 这类加速站的内核基本都是 hunshcn/gh-proxy 这个项目，逻辑一句话能讲完：把请求里的 GitHub 域名重写成代理域名，Worker 收到请求后转发给 GitHub，再把响应（顺便处理 302 跳转、CORS 头）流式吐回来。release 资产、raw 文件、archive 压缩包、git clone（smart http），理论上都走这一条链路。 ...

家里有台小服务器，平时跑着 AI 助手和一些自动化任务。大部分时间倒也没啥问题，但七八月份的室温一上去，加上编译大项目或者跑模型推理，CPU 和 GPU 温度经常蹭蹭往上涨。 最烦的是——你根本不知道它热了。等你发现的时候，可能已经 90°C+ 跑了几个小时。 需求其实很简单 我需要一个东西满足三件事： 安静监控：开机就在后台跑，别弹窗、别占资源 过热告诉我：不用我主动去看，CPU/GPU 超阈值了自动通知 别刷屏：同一次过热只通知一次，冷却期内别重复发 正好我电脑上一直开着 TrafficMonitor（一个轻量的系统监控工具，直接在任务栏显示网速和温度），它提供了插件接口，看了一圈没人做过飞书告警的插件，那就自己写一个。 TempWebhook：一个 C++ 写的 DLL 插件名叫 TempWebhook，本质上是一个 TrafficMonitor 插件 DLL。代码量不大，核心就 800 多行 C++： ...