干了 8 年业务系统,最后只剩一句话:能不重写就不重写 8 年时间,做过订单结算、比价、实体匹配、主数据治理 4 个领域。 最近整理过往项目时发现一个规律: 我做过的几次大改造,跨度 5 年, 没有一次是"推倒重来"成功 的——但全部"逐步替换"成功了 。 不是我胆小。是真的踩过坑。 最近带 mentee 时这个判断反复被问,所以想完整写一次。 1. 老订单系统从 .NET 迁到 Java 跨 2 年。 方式不是停掉老的、上线新的——是同时跑,新订单走新系统、老 订单仍走老系统,通过比对工具持续校验差异。 切流粒度很细。从 0.1% 灰度开始, 最小灰度颗粒到具体业务 ID 维度 ,最终切完用了 14 个月。 期间老系统改了 3 次,新系统改了 7 次, 两边互相对照修了 11 个"看起来对但不对"的 bug ——这种 bug 单独跑任何一边 都看不出来。 2. 比价系统的 Redis 重构 跨 1 年。 原系统有个增量更新机制,因为时间窗口判断 bug 导致比价数据 偶尔晚更新 30 秒,凌晨流量小时不易发现。 我没有重写整个 Redis 层。 只重写了"时间窗口判断"这一段 ——把它从老系统拆出来,做成独立模块,通过开关控制走新逻辑还 是旧逻辑。 灰度过程是常规节奏:1% → 10% → 30% → 50% → 100%, 每阶段保持 2-4 周观察。 总改动:老系统代码改了不到 200 行。新模块约 1500 行。 但是这 200 行让"凌晨偶发数据延迟"这个 5 年没解决的问题彻 底消失。 3. 实体匹配的 SOA 改造 跨 1.5 年。 原系统是单体,匹配规则散落在 4 个 service 里互相调用。 我没急着拆。 先把 4 个 service 之间的调用关系画成图 (drawio,约 60 个节点)——然后把每个调用边一条一条剪 掉,改成事件驱动。 不是一次性切——是一次切一条。每剪一条边,跑 1 周回归,确认 指标无变化,再剪下一条。 剪了 23 条边用了 11 个月 。期间老的同步调用代码一直没 删——新事件链路稳定 3 个月后才彻底清理。 4. 主数据治理整合 跨 1 年。 4 个团队的主数据库要合并成一个。常规做法是搞个"统一数据中 心",大家停 2 周迁移过去。 我们的做法: 老系统全部保留,只在中间加一层"主数据视图层" 。 A 团队看视图 V1,B 团队看视图 V2,但底层数据已经合并。 6 个月后,老库一个一个下线—— 因为没人在用了 。 这 4 件事的共同模式 不是"先想好架构再切一刀"。 是" 先切一刀,看能不能切得动,切不动退回去 "。 具体动作就 4 条: 把要改的东西 从大块切成小块 ——小到一周能做完 新老并存 ——不是切完老的再上新的,是两边一起跑 比对工具先做 ——不能比对的改动等于不存在 回滚开关比上线更优先 什么时候不该用这套? 我也踩过一次。 某个项目我用同样套路想做"渐进迁移"。结果发现: 新需求每周改一次 ,老系统跟新系统都得跟着改 改一处,要在 2 个系统都改,工作量翻倍 6 个月后老系统不仅没"自然死掉",反而变得更复杂 最后我们停了渐进迁移, 直接停 2 周做切换 ——结果反而很顺利。 事后总结: 当业务还在快速变化时,渐进迁移会拉长事故面 。 渐进式只适合"业务相对稳定、需要保留长期可对照"的场景。 写在最后 带 mentee 时最常说的一句话是: "先不要想架构图。先想第一刀切在哪、切错了怎么退回去。" 很多技术决策不是"什么是对的",是" 什么是可逆的 "。 可逆的方案,允许你在错的时候不死;不可逆的方案,要求你一开始 就对——但谁能保证一开始就对呢? (以上 4 个项目都做了脱敏处理。 如果你做过类似改造, 欢迎评论区聊聊你踩过的坑—— 我特别想知道你们行业里"渐进式不适用"的具体场景是什么。)
Codex 编码问题怎么解决？ PowerShell 重写污染了,这个文件编码不是 UTF-8，apply_patch 直接改会炸 7 个帖子 - 7 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 项目开源地址： GitHub - wnzzer/rank-analysis: 基于Tauri 2 + Rust，构建的一个LOL 英雄联盟腾讯服战绩查询助手，创新式标签标记机制，一键分析的混子、牛马队友 · GitHub 大家好，我是只会写 bug 的靓仔。 之前发过几篇 LOL 排位分析工具的帖子（ 项目介绍 | v1.2 更新 ），当时还是 Electron + Go 的架构。有老哥评论说"这么大？"，确实如此，尤其我经常在网吧这种裸连 github 的环境中使用 —— 一个查战绩的小工具，安装包 128 MB ，下它比打一把排位还久。 因此去年花了几个月，把整个技术栈从 Electron+Go 迁到了 Tauri 2 + Rust 。结果： 安装包： 128 MB → 5 MB （缩小 96%，GitHub Release 截图为证） 冷启动： ~1.5s → ~500ms 进程架构： Electron 壳 + Go server 两个程序 → 单个 Tauri 二进制 （砍掉独立后端进程和 localhost HTTP 那一跳） 内存： ~306 MB → ~241 MB （WebView2 那部分是系统共享的，虽然 tauri 应用增加这个效果会变得更好） 下面把迁移过程和踩的坑记录一下，如果你也在做类似的桌面端项目，或者 Electron / Tauri 之间纠结，这篇应该能帮你省点时间。 先说老架构为什么非换不可 最早的设计是这样的： 但三个绕不开的痛点： 128 MB 劝退用户 Electron 自带 Chromium runtime，光这就 60~80 MB，加上 Go binary 30 MB+。v1.0 打出来 128 MB 。后来挤了又挤，稳定在 85~93 MB。 一个查战绩的工具下 100 多 MB，用户等下载的时间够再开一把了。这是后来下定决心换 Tauri 最直接的原因。 体积不是"技术债"，是用户会不会用你的第一道门槛。 两个进程，启动和调试都难受 启动流程：Electron 起 → 拉起 Go server → Go 监听端口 → Electron 前端轮询 Go 是否就绪 → 才能调 LCU。任何一环卡住都是"加载中"。 Go 那边 panic 了，Electron 这边只看到 fetch 超时。调试得在两个终端间来回切，日志打两份。这种痛谁用谁知道。 localhost HTTP 是隐性税 每次前端调后端：JS 对象 → JSON 序列化 → HTTP body → loopback 网络 → Go 反序列化 → 业务逻辑 → 再原路返回。虽然是 loopback，HTTP 头解析、TCP 握手、JSON 双向序列化的开销都是实实在在的。查战绩这种"一次拉 10 个召唤师 + 各自 20 场"的场景，延迟肉眼可见。 为什么是 Tauri 2 + Rust Tauri 1 vs 2 ：Tauri 1 在 Windows 用 Edge HTML 兜底，2 全面切 WebView2，兼容性和稳定性好太多。插件系统也重做了（v2），autostart / single-instance / fs 都有一等公民支持。还有新的 Capability + Permission 模型，后面会说到踩坑。 为什么不是 Go 了 ：Tauri 所有 #[tauri::command] 、State、AppHandle、事件总线都是 Rust API。继续用 Go 等于再绕一层 cgo/HTTP，那迁了个寂寞。Rust 直接编译进 Tauri 主进程，单二进制分发，不需要子进程。 那为什么不是 Wails？ 这个问题我猜 Go 老哥们第一个就要问 —— Wails 不就是 Go + 系统 WebView 嘛，照理说我后端一行都不用重写，最省事。我也认真纠结过。最后没选它，原因挺主观的：一是当时 Wails 在多窗口、自动更新、权限这些一等公民支持上，体感不如 Tauri 2 厚实，遇到坑社区里能搜到的答案也少；二是说实话有点私心，就想趁这个项目顺手学一下 Rust。所以这不是"Wails 不行"，而是"我想学 Rust + 赌 Tauri 生态"。如果你就是想保留 Go 又要小体积，Wails 完全值得先试一把，别被我带跑。 UI 库也顺便从 TDesign 换成了 Naive UI ，暗色主题和表格组件更顺。这一步单独做了一周，没掺在迁移里。 迁移路径：不是一锅煮的 很多博客写"我用一个周末把 X 重写成 Y"。我没那么神。实际上是 两条线分头推 ，节奏完全不一样： 迁移线 起点 终点 耗时 前端壳 ：Electron → Tauri 2025-03-30（v1.5.4 双轨试水） 2025-04-19（v1.5.6 纯 Tauri） ~1 个月 后端语言 ：Go → Rust 2025-03-31 2025-12-13（删 4274 行 Go） ~8 个月 前端壳为什么 1 个月就切完了 用户用脚投票。 v1.5.4 同时发了 Electron 86 MB 和 Tauri 10 MB 两个包： 同一天、同一版本、同一功能集， 86.3 MB vs 10.2 MB 。这还纠结啥？2 周后 v1.5.6 就只发 Tauri 了。 后端为什么磨了 8 个月 因为对用户来说，Go server 也好、Rust 也好， 功能没差 。没有压差就不急： 2025-03-31 ：新建 Tauri 目录，跟旧 Go 目录并存 2025-04 ~ 2025-12 ：一个 endpoint 一个 endpoint 往 Rust 搬。期间 没冻需求 ，新功能照加 2025-12-13 ： -4274 行 Go / 34 个文件 ，旧服务彻底删 为什么不一刀切？因为 用户在线 啊（虽然没多少用户）。项目每 1-2 周发一版，停下来做半年大重写不现实。旧 Go server 保留着继续吃 bug fix，新功能直接写 Rust（有点像最近 bun 迁移 rust 的思路），旧 endpoint 按频率从高到低搬过去，搬完一个前端就切流量。并存期间项目目录长这样（确实丑，但能持续发版）： 三个大坑 每个都卡了我至少半天，写出来希望大家别再踩。 坑 1：LCU 自签证书 —— Rust 的 API 名把 “danger” 写脸上了 LCU API 是 HTTPS，但用的是每次客户端启动时动态生成的自签证书。Go 里关掉 TLS 校验很简单： tr := &http.Transport{ TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, } client := &http.Client{Transport: tr} 到了 Rust 的 reqwest ： let client = reqwest::Client::builder() .danger_accept_invalid_certs(true) .build()?; 看到 danger_accept_invalid_certs 这个名字的时候我愣了一下 —— 但 LCU 场景下这是唯一解，Riot 不可能给你 CA 证书。 更大的坑是 port 和 auth-token 怎么拿。 这俩是 LCU 每次启动随机生成的，写在自己进程的命令行参数里（ --app-port=xxxxx --remoting-auth-token=yyy ）。网上清一色用 wmic 去查，但那玩意要 管理员权限 。我之前专门写过一篇 无管理员权限的获取方法（全网首发 Go） ，原理是调 Windows 的 NtQueryInformationProcess API： use windows::Win32::System::Threading::*; let h = OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, false, pid)?; let mut buf = vec![0u8; 4096]; let mut ret_len = 0u32; NtQueryInformationProcess( h, ProcessCommandLineInformation, buf.as_mut_ptr() as _, buf.len() as _, &mut ret_len )?; // 解析 UNICODE_STRING → 正则抠 --app-port / --remoting-auth-token PROCESS_QUERY_LIMITED_INFORMATION 是低权限级别，拿不到敏感数据。但 进程命令行不算敏感 —— Windows 设计里被忽视的一个口子，刚好让我们绕过了管理员要求。 那 NtQueryInformationProcess 吐出来的那坨 buffer，怎么变成 port 和 token？谜底就在这块 buffer 的结构上 —— 它开头是一个 UNICODE_STRING （ Length + MaximumLength + 一个指向宽字符串的指针），真正的命令行数据就跟在后面。把宽字符串转成 String ，剩下的就是正则的活了： #[repr(C)] struct UnicodeString { length: u16, maximum_length: u16, buffer: *mut u16 } // buf 就是上面 NtQueryInformationProcess 填好的缓冲区 let us = unsafe { &*(buf.as_ptr() as *const UnicodeString) }; let wide = unsafe { std::slice::from_raw_parts(us.buffer, (us.length / 2) as usize) }; let cmdline = String::from_utf16_lossy(wide); // 命令行里把这两个随机值抠出来 let re_port = Regex::new(r"--app-port=(\d+)").unwrap(); let re_token = Regex::new(r"--remoting-auth-token=([\w-]+)").unwrap(); let port = re_port.captures(&cmdline).and_then(|c| c.get(1)).map(|m| m.as_str().to_string()); let token = re_token.captures(&cmdline).and_then(|c| c.get(1)).map(|m| m.as_str().to_string()); （边界检查和错误处理我省了，能看懂思路就行；完整实现在上面那篇全网首发的文里。） 坑 2：Tauri 2 的 Permission 模型 —— 配对了跑不通，报错还不告诉你 Electron 安全模型基本就是开/关 nodeIntegration 二选一。Tauri 2 是 白名单粒度 ，每个能力都要显式声明： { "permissions": [ "core:default", "shell:allow-open", "http:default", "core:window:allow-start-dragging" ] } 第一次写很容易陷入**“代码明明对了为啥跑不通”**的死循环 —— 因为权限不足的报错不指向配置文件，而是给你一个看起来像"函数不存在"的错误。比如我漏配 dialog 权限时，前端 invoke 收到的是这么一句： command plugin:dialog|open not allowed. Permissions associated with this command: dialog:allow-open 乍一看像命令名写错了，对着代码翻来覆去找不出毛病。其实谜底就在报错的后半句 —— 它已经把你要加的权限名（ dialog:allow-open ）报出来了，只是第一次根本不会想到往那看。我在这上面浪费了大半天。 后来踩熟了，记了几个具体坑： http:default 要写两遍 ：第一遍启用 fetch 命令，第二遍配 URL 白名单 scope。只写第一遍，命令存在但 fetch 调用静默失败，连个报错都没有 动态窗口要通配符 ：项目给每场对局弹详情窗口，label 是动态的（ match-detail-{id} ），capability 里得写 "windows": ["main", "match-detail-*"] 。漏了就所有 command 调不通 core:window:allow-start-dragging ：项目禁了原生标题栏，整个拖拽靠这个 API。漏配了窗口就拖不动，你猜我怎么发现的 经验 ：每加一个新 Tauri command 或新窗口，第一件事查 capabilities/default.json 。权限先行，代码后行。 坑 3：Rust struct 和 TS type 的同步 —— 手动对齐的酸爽 旧前端调 Go 是 fetch ，新前端调 Rust 是 invoke ： // 旧 const data = await fetch('/api/match-history?puuid=xxx').then(r => r.json()) // 新 const data = await invoke('get_match_history', { puuid: 'xxx' }) 表面上是换了个调用方式。但真正头疼的是： Rust 那边 struct 改一个字段，TS 怎么知道？ 我试过 ts-rs、specta 这些自动生成工具，最后没用，纯手动对齐。原因很实际： 总共就十几个核心 struct，自动生成引入的构建管线复杂度超过了收益 Rust 这边统一用 #[serde(rename_all = "camelCase")] ，自动转 camelCase，写 TS 的时候照着来就行 TS 文件头注释直接标注对应的 Rust 文件路径： /** * AI 标签建议相关类型，与 Rust schema * (src-tauri/src/command/user_tag_config.rs) 严格同构。 */ CI 两边都跑 typecheck（前端 vue-tsc ，后端 cargo clippy ），能挡住大部分 但确实出过 bug —— Rust 的 RecentData 有 select_mode ，TS 那边多写了 wins 和 losses 两个字段，Rust 根本不返回这俩。运行时永远是 undefined ， 不报错但数据是错的 。当时前端那块胜负数永远显示空，我对着前端代码看了半天没看出毛病，最后跑去 grep Rust 的 struct 才发现：人家压根没这俩字段。这种静默 bug 比崩了还可怕，你不专门盯根本发现不了。 建议 ：struct 超过 30 个或者多人协作，老老实实用 ts-rs / specta 自动生成。手动对齐只在一个人写、量不大的情况下才省心。 顺手白嫖的一个好处：自动更新 这个本来没在计划里，迁完才发现是非常好用的功能。 Electron 时代我也想做自动更新，但 electron-updater 那套配下来挺烦：要么自己搭个更新服务器，要么拿 GitHub 当源，还要处理签名、增量包，配置一大坨。我当时嫌麻烦一直没正经做，全靠用户自己去 Release 页手动下新版。 Tauri 2 有个官方的 tauri-plugin-updater ，配置就几行： // tauri.conf.json { "plugins": { "updater": { "endpoints": ["https://github.com/wnzzer/rank-analysis/releases/latest/download/latest.json"], "pubkey": "你的公钥" } } } 更新源就是挂在 GitHub Release 上的一个 latest.json （等下"效果对比"那节，v1.8.2 截图里第一行那个 10.8 KB 的 latest.json 就是它），长这样： { "version": "1.8.2", "pub_date": "2026-05-24T00:00:00Z", "platforms": { "windows-x86_64": { "signature": "更新包的签名串", "url": "https://github.com/wnzzer/rank-analysis/releases/download/v1.8.2/lol-record-analysis-app-1.8.2-setup.exe" } } } 前端启动时调一下 check() ，有新版就提示下载安装，三五行的事： import { check } from '@tauri-apps/plugin-updater' const update = await check() if (update) { await update.downloadAndInstall() // 下完自动重启 } 这里有个容易搞混的点得说清楚 ：Tauri updater 要你用一对自己生成的密钥（ tauri signer generate ，免费）给「更新包」签名，公钥填进上面的配置 —— 这个签名是给自动更新做校验用的，和 Windows 上那种要花钱买的「代码签名证书」完全是两码事。我穷，没买代码签名证书，所以首次安装时 Windows SmartScreen 还是会弹个"未知发布者"，这个坑我到现在没填。但自动更新本身一分钱没花就跑通了，对一个免费小工具来说，够用了。 效果对比（有图有真相） 安装包体积演变 每一行都是 GitHub Release 公开记录，可以去 Releases 页 核对： 版本 日期 大小 阶段 v1.0 2025-01-13 128 MB Electron + Go 起点 1.1 → 1.5.3 01~03月 ~85-93 MB Electron 时代 v1.5.4 2025-03-30 86.3 MB + 10.2 MB 双轨同框 v1.5.6 2025-04-19 10.3 MB 纯 Tauri v1.6.0 2025-10-08 6.7 MB 升 Tauri 2 v1.8.2 2026-05-24 5.01 MB 当前 起点 v1.0 —— 128 MB ： 转折点 v1.5.4 —— Electron 和 Tauri 同框 ： 当前 v1.8.2 —— 5.01 MB ： 内存占用 旧版 Electron + Go（稳态 ~306 MB） ： 新版 Tauri + Rust（稳态 ~241 MB） ： WebView2 那 ~200MB 看着大，但 系统里只要装了 Edge 或者别的 Tauri 应用，这部分就是共享的 ，边际内存远小于这个数。 截图里 实用工具 (6) 的 6 个进程是 WebView2 的渲染 / GPU / 管理器等辅助进程 —— 和当年 Electron 的多进程模型一个道理，这部分跑不掉。前面"进程架构"那条说的"单个二进制"，指的是 app 自己不再额外起一个 Go server 子进程 + localhost HTTP ，不是说 OS 层只剩 1 个进程。 几句废话 说实话，一开始决定迁的时候心里也没底。毕竟 Electron + Go 虽然，但它跑着呢。万一迁到一半翻车了，那才叫社死。 后来想通了： 128 MB 对一个查战绩的工具来说太离谱了。 用户不会关心你用的什么框架，他们只关心下完打开能不能用。Tauri 让安装包从 128 MB 变成 5 MB —— 不是"技术优化"，是 让产品有被打开的机会 。 如果你也在做类似的桌面端项目，我的建议就三条： 别一刀切 ，留旧项目并存，新目录单独建，随时能 ship 先迁用户感知最强的功能 ，不是代码量最小的 别在迁移里掺重构 ，已经够复杂了，UI 改版分开做 就这些。希望对在做类似项目的朋友有帮助。 相关链接： 仓库： github.com/wnzzer/rank-analysis 最新版下载： releases/latest LCU 凭据获取（坑 1 详细实现）： 无管理员权限 LCU auth-token、port 获取 历史版本： ① 项目介绍 | ② v1.2 | ③ 分页设计 觉得有用的话帮忙点个赞 有问题也可以去 GitHub 提 issue 交流 5 个帖子 - 5 位参与者 阅读完整话题
phoronix.com OpenCV 5.0 Released With Rewritten DNN Engine, Built-In LLM & VLM Support OpenCV 5.0 released today as a major update to this widely-used, open-source computer vision (CV) library. [!quote]+ OpenCV 5.0 今天发布，是这个广泛使用的开源计算机视觉 (CV) 库的重大更新。 OpenCV 5.0 采用了重写的深度神经网络（DNN）引擎，ONNX 覆盖率超过 80%，内置大型语言模型（LLM）和视觉语言模型（VLM）支持，以及新的硬件抽象层和更好的 3D 视觉工具包。 OpenCV 5.0 目前已为英特尔 IPP（内核经过 SSE/AVX 优化）、Arm KleidiCV、高通 FastCV 和 RISC-V Vector RVV 调整了路径。 接下来，OpenCV 开发人员计划在其新的 DNN 引擎中开发原生 GPU 支持。 OpenCV 5.0 在与微软 ONNX Runtime 的较量中表现出色： OpenCV – 5 Jun 26 OpenCV 5 Is Here: The Biggest Leap in Years for Computer Vision OpenCV 5 is here! A massive modernization brings a graph-based DNN engine, over 80% ONNX coverage, hardware acceleration, LLM/VLM support, and a faster Python-first core. Learn why this isn't just an incremental update. Est. reading time: 19 minutes 3 个帖子 - 3 位参与者 阅读完整话题
现在在跑了 reasonix setup 后会往 .env 写入DeepSeek的密钥等。而 .env 是很多项目的默认环境变量配置文件……DeepSeek-Reasonix的这一操作及其可能会污染项目，甚至api泄露。谨慎使用吧。 PS，为什么不用之前的 .reasonix 目录这一问题，我死活想不通。 后悔升级v1了，DeepSeek-Reasonix未来也不敢用了。佬友有别的DS4高缓存命中率AGENTS推荐吗？ 3 个帖子 - 3 位参与者 阅读完整话题
最近闲来无事，想着说不定可以跳槽，就做了一个多agent协同的工作流来优化简历，佬友们帮忙给点建议！目前还只是初始阶段。 一键直达: Mutil-Agent Resume Reviewer 佬友们可以游客进去试试！用的中转的gpt-5.5，请佬友手下留情不要给我额度刷没了！ 使用方法: 每一个节点的结果可以直接点击节点卡片查看！最后会生成一个markdown格式的优化后的简历和pdf文件供下载。 目前我只测试过我自己的简历感觉中规中矩，想看看不同情况下效果如何！ 1 个帖子 - 1 位参与者 阅读完整话题
请问各位佬友有没有Quantumult X的qq音乐的过滤或者重写规则推荐？主要是屏蔽广告，如果能净化那更好 1 个帖子 - 1 位参与者 阅读完整话题
[开源] 各位大佬好，分享一个我最近折腾的项目。 起因是我在用 mrkrsl/web-search-mcp （ TypeScript ，⭐ 910 ）的时候，发现几个不太够用的地方：没有 Google 和百度、CAPTCHA 直接挂掉、页面提取绑死在搜索流程里……改着改着发现改动量太大了，索性用 Python 从头重写了一遍。 GitHub: https://github.com/duanshiwen/seach-mcp-craft-agent 和原版的核心区别 原版 (TypeScript) 改进版 (Python) 语言 TypeScript + JavaScript Python 3.10+ 搜索引擎 Bing / Brave / DuckDuckGo Google / Bing / 百度 / DuckDuckGo / Yahoo CAPTCHA ❌ 无处理 ✅ 自动检测 + 弹窗等待手动验证 浏览器管理 共享实例 全局队列锁 + per-engine 独立 profile 网页提取 绑在搜索流程里 独立 web_fetch 工具，auto/http/js 三种模式 百度 ❌ ✅ 浏览器 + HTTP 双保险 目标用户 本地 LLM （ LM Studio / LibreChat ） 所有 MCP 客户端 为什么用 Python 重写？ 原版的引擎层、浏览器生命周期、CAPTCHA 处理等核心模块都绑在 JS 生态里。我的改动涉及这些底层，与其在原版上打补丁，不如用 Python 重写——httpx + selectolax 替代 Axios ，代码更简洁，后续加新引擎也方便。 两个核心改进 1. CAPTCHA 自动检测 + 手动验证 原版遇到 CAPTCHA 直接挂。我的版本用可见浏览器模式搜索，触发 CAPTCHA 时： 自动检测到验证码页面 用户在同一个浏览器窗口手动完成验证 程序每 2 秒轮询，验证通过后自动提取结果并关闭窗口 默认等待 300 秒超时，超时返回空结果并建议换引擎 每个引擎用独立的浏览器 profile ，不会污染你的日常 Chrome 。 2. 独立的 web_fetch 网页内容提取 原版的页面提取是绑在搜索流程里的，我把拆成了独立工具： { "url": "https://example.com/article", "render_mode": "auto", "extract_mode": "markdown" } auto 模式先走轻量 HTTP ，检测到 JS-only 页面自动 fallback 到 Playwright 自动去除广告、导航栏等干扰，提取正文 超时上限 12 分钟，SPA 页面也能搞定 搜索完直接用 web_fetch 抓全文，不用再接别的工具。 为什么不用 SerpAPI / Brave Search API ？ 这是做这个项目之前我自己纠结过的问题，说说我的判断： SerpAPI ：免费版每月 100 次搜索，付费版 $50/月起。对个人开发者做个 demo 够了，但跑 Agent 工作流每天可能就要几百次搜索，一个月下来成本不低。 Brave Search API ：$5/1000 次请求，每月送 $5 额度（≈ 1000 次免费）。价格比 SerpAPI 友好很多，但问题是——它只能搜 Brave 的索引，结果质量和 Google 差距明显，尤其是中文内容。 Google Custom Search API ：免费 100 次/天，超出 $5/1000 次。看似便宜，但 100 次/天对 Agent 来说杯水车薪，而且返回的结果不如直接浏览器搜索丰富。 我的选择：直接用浏览器搜索。 结果最全最实时，和你手动打开浏览器搜的一样 完全免费，没有调用限制 支持 5 个引擎，不是只搜一个索引 代价是需要 Playwright 和真实浏览器，比 API 调用重一些。但对 Agent 工作流来说，搜索质量比速度更重要——你宁可多等 3 秒拿到准确结果，也不要秒回一个过时的摘要。 安装 git clone https://github.com/duanshiwen/seach-mcp-craft-agent.git cd seach-mcp-craft-agent uv sync # 或 pip install -e . playwright install chromium MCP 客户端配置： { "mcpServers": { "search-engine-mcp": { "command": "python", "args": ["-m", "src.server"], "cwd": "/path/to/seach-mcp-craft-agent" } } } 使用示例 { "query": "Rust async best practices", "engine": "google", "max_results": 5 } 引擎选择建议： 快速查询 → DuckDuckGo （轻量 HTTP ，1-3s ） 要最全结果 → Google （浏览器模式，3-10s ） 中文内容 → Bing 或百度 项目结构 src/ ├── server.py # MCP 服务主入口 ├── engines/ │ ├── base.py # HTTP 引擎基类 │ ├── browser_base.py # 浏览器引擎基类（ CAPTCHA 、队列锁、profile 隔离） │ ├── google.py │ ├── bing.py # 浏览器 + HTTP fallback │ ├── baidu.py # 浏览器 + HTTP fallback │ ├── duckduckgo.py │ └── yahoo.py ├── fetcher.py # web_fetch 实现 └── types.py / utils.py 加新引擎只需要继承对应基类、实现几个方法就行，README 里有详细说明。 碎碎念 做这个项目过程中的几个观察： JS 渲染是 2026 年搜索工具的门槛了 。Google 的搜索结果甚至需要 JS 执行完才会出现，纯 HTTP 方案基本不可用 免费方案反而比付费 API 好用 。直接浏览器搜结果最全最实时，API 受限太多 失败兜底比成功路径更重要 。CAPTCHA 、超时、页面变化都是常态，双路渲染+队列管理这些"不性感"的设计才是稳定性的基石 感谢原作者 mrkrsl 的优秀工作 欢迎各位大佬试用提 PR ，有问题直接回复聊~
[开源] 各位大佬好，分享一个我最近折腾的项目。 起因是我在用 mrkrsl/web-search-mcp （ TypeScript ，⭐ 910 ）的时候，发现几个不太够用的地方：没有 Google 和百度、CAPTCHA 直接挂掉、页面提取绑死在搜索流程里……改着改着发现改动量太大了，索性用 Python 从头重写了一遍。 GitHub: https://github.com/duanshiwen/seach-mcp-craft-agent 和原版的核心区别 原版 (TypeScript) 改进版 (Python) 语言 TypeScript + JavaScript Python 3.10+ 搜索引擎 Bing / Brave / DuckDuckGo Google / Bing / 百度 / DuckDuckGo / Yahoo CAPTCHA ❌ 无处理 ✅ 自动检测 + 弹窗等待手动验证 浏览器管理 共享实例 全局队列锁 + per-engine 独立 profile 网页提取 绑在搜索流程里 独立 web_fetch 工具，auto/http/js 三种模式 百度 ❌ ✅ 浏览器 + HTTP 双保险 目标用户 本地 LLM （ LM Studio / LibreChat ） 所有 MCP 客户端 为什么用 Python 重写？ 原版的引擎层、浏览器生命周期、CAPTCHA 处理等核心模块都绑在 JS 生态里。我的改动涉及这些底层，与其在原版上打补丁，不如用 Python 重写——httpx + selectolax 替代 Axios ，代码更简洁，后续加新引擎也方便。 两个核心改进 1. CAPTCHA 自动检测 + 手动验证 原版遇到 CAPTCHA 直接挂。我的版本用可见浏览器模式搜索，触发 CAPTCHA 时： 自动检测到验证码页面 用户在同一个浏览器窗口手动完成验证 程序每 2 秒轮询，验证通过后自动提取结果并关闭窗口 默认等待 300 秒超时，超时返回空结果并建议换引擎 每个引擎用独立的浏览器 profile ，不会污染你的日常 Chrome 。 2. 独立的 web_fetch 网页内容提取 原版的页面提取是绑在搜索流程里的，我把拆成了独立工具： { "url": "https://example.com/article", "render_mode": "auto", "extract_mode": "markdown" } auto 模式先走轻量 HTTP ，检测到 JS-only 页面自动 fallback 到 Playwright 自动去除广告、导航栏等干扰，提取正文 超时上限 12 分钟，SPA 页面也能搞定 搜索完直接用 web_fetch 抓全文，不用再接别的工具。 为什么不用 SerpAPI / Brave Search API ？ 这是做这个项目之前我自己纠结过的问题，说说我的判断： SerpAPI ：免费版每月 100 次搜索，付费版 $50/月起。对个人开发者做个 demo 够了，但跑 Agent 工作流每天可能就要几百次搜索，一个月下来成本不低。 Brave Search API ：$5/1000 次请求，每月送 $5 额度（≈ 1000 次免费）。价格比 SerpAPI 友好很多，但问题是——它只能搜 Brave 的索引，结果质量和 Google 差距明显，尤其是中文内容。 Google Custom Search API ：免费 100 次/天，超出 $5/1000 次。看似便宜，但 100 次/天对 Agent 来说杯水车薪，而且返回的结果不如直接浏览器搜索丰富。 我的选择：直接用浏览器搜索。 结果最全最实时，和你手动打开浏览器搜的一样 完全免费，没有调用限制 支持 5 个引擎，不是只搜一个索引 代价是需要 Playwright 和真实浏览器，比 API 调用重一些。但对 Agent 工作流来说，搜索质量比速度更重要——你宁可多等 3 秒拿到准确结果，也不要秒回一个过时的摘要。 安装 git clone https://github.com/duanshiwen/seach-mcp-craft-agent.git cd seach-mcp-craft-agent uv sync # 或 pip install -e . playwright install chromium MCP 客户端配置： { "mcpServers": { "search-engine-mcp": { "command": "python", "args": ["-m", "src.server"], "cwd": "/path/to/seach-mcp-craft-agent" } } } 使用示例 { "query": "Rust async best practices", "engine": "google", "max_results": 5 } 引擎选择建议： 快速查询 → DuckDuckGo （轻量 HTTP ，1-3s ） 要最全结果 → Google （浏览器模式，3-10s ） 中文内容 → Bing 或百度 项目结构 src/ ├── server.py # MCP 服务主入口 ├── engines/ │ ├── base.py # HTTP 引擎基类 │ ├── browser_base.py # 浏览器引擎基类（ CAPTCHA 、队列锁、profile 隔离） │ ├── google.py │ ├── bing.py # 浏览器 + HTTP fallback │ ├── baidu.py # 浏览器 + HTTP fallback │ ├── duckduckgo.py │ └── yahoo.py ├── fetcher.py # web_fetch 实现 └── types.py / utils.py 加新引擎只需要继承对应基类、实现几个方法就行，README 里有详细说明。 碎碎念 做这个项目过程中的几个观察： JS 渲染是 2026 年搜索工具的门槛了 。Google 的搜索结果甚至需要 JS 执行完才会出现，纯 HTTP 方案基本不可用 免费方案反而比付费 API 好用 。直接浏览器搜结果最全最实时，API 受限太多 失败兜底比成功路径更重要 。CAPTCHA 、超时、页面变化都是常态，双路渲染+队列管理这些"不性感"的设计才是稳定性的基石 感谢原作者 mrkrsl 的优秀工作 欢迎各位大佬试用提 PR ，有问题直接回复聊~
[开源] 各位大佬好，分享一个我最近折腾的项目。 起因是我在用 mrkrsl/web-search-mcp （ TypeScript ，⭐ 910 ）的时候，发现几个不太够用的地方：没有 Google 和百度、CAPTCHA 直接挂掉、页面提取绑死在搜索流程里……改着改着发现改动量太大了，索性用 Python 从头重写了一遍。 GitHub: https://github.com/duanshiwen/seach-mcp-craft-agent 和原版的核心区别 原版 (TypeScript) 改进版 (Python) 语言 TypeScript + JavaScript Python 3.10+ 搜索引擎 Bing / Brave / DuckDuckGo Google / Bing / 百度 / DuckDuckGo / Yahoo CAPTCHA ❌ 无处理 ✅ 自动检测 + 弹窗等待手动验证 浏览器管理 共享实例 全局队列锁 + per-engine 独立 profile 网页提取 绑在搜索流程里 独立 web_fetch 工具，auto/http/js 三种模式 百度 ❌ ✅ 浏览器 + HTTP 双保险 目标用户 本地 LLM （ LM Studio / LibreChat ） 所有 MCP 客户端 为什么用 Python 重写？ 原版的引擎层、浏览器生命周期、CAPTCHA 处理等核心模块都绑在 JS 生态里。我的改动涉及这些底层，与其在原版上打补丁，不如用 Python 重写——httpx + selectolax 替代 Axios ，代码更简洁，后续加新引擎也方便。 两个核心改进 1. CAPTCHA 自动检测 + 手动验证 原版遇到 CAPTCHA 直接挂。我的版本用可见浏览器模式搜索，触发 CAPTCHA 时： 自动检测到验证码页面 用户在同一个浏览器窗口手动完成验证 程序每 2 秒轮询，验证通过后自动提取结果并关闭窗口 默认等待 300 秒超时，超时返回空结果并建议换引擎 每个引擎用独立的浏览器 profile ，不会污染你的日常 Chrome 。 2. 独立的 web_fetch 网页内容提取 原版的页面提取是绑在搜索流程里的，我把拆成了独立工具： { "url": "https://example.com/article", "render_mode": "auto", "extract_mode": "markdown" } auto 模式先走轻量 HTTP ，检测到 JS-only 页面自动 fallback 到 Playwright 自动去除广告、导航栏等干扰，提取正文 超时上限 12 分钟，SPA 页面也能搞定 搜索完直接用 web_fetch 抓全文，不用再接别的工具。 为什么不用 SerpAPI / Brave Search API ？ 这是做这个项目之前我自己纠结过的问题，说说我的判断： SerpAPI ：免费版每月 100 次搜索，付费版 $50/月起。对个人开发者做个 demo 够了，但跑 Agent 工作流每天可能就要几百次搜索，一个月下来成本不低。 Brave Search API ：$5/1000 次请求，每月送 $5 额度（≈ 1000 次免费）。价格比 SerpAPI 友好很多，但问题是——它只能搜 Brave 的索引，结果质量和 Google 差距明显，尤其是中文内容。 Google Custom Search API ：免费 100 次/天，超出 $5/1000 次。看似便宜，但 100 次/天对 Agent 来说杯水车薪，而且返回的结果不如直接浏览器搜索丰富。 我的选择：直接用浏览器搜索。 结果最全最实时，和你手动打开浏览器搜的一样 完全免费，没有调用限制 支持 5 个引擎，不是只搜一个索引 代价是需要 Playwright 和真实浏览器，比 API 调用重一些。但对 Agent 工作流来说，搜索质量比速度更重要——你宁可多等 3 秒拿到准确结果，也不要秒回一个过时的摘要。 安装 git clone https://github.com/duanshiwen/seach-mcp-craft-agent.git cd seach-mcp-craft-agent uv sync # 或 pip install -e . playwright install chromium MCP 客户端配置： { "mcpServers": { "search-engine-mcp": { "command": "python", "args": ["-m", "src.server"], "cwd": "/path/to/seach-mcp-craft-agent" } } } 使用示例 { "query": "Rust async best practices", "engine": "google", "max_results": 5 } 引擎选择建议： 快速查询 → DuckDuckGo （轻量 HTTP ，1-3s ） 要最全结果 → Google （浏览器模式，3-10s ） 中文内容 → Bing 或百度 项目结构 src/ ├── server.py # MCP 服务主入口 ├── engines/ │ ├── base.py # HTTP 引擎基类 │ ├── browser_base.py # 浏览器引擎基类（ CAPTCHA 、队列锁、profile 隔离） │ ├── google.py │ ├── bing.py # 浏览器 + HTTP fallback │ ├── baidu.py # 浏览器 + HTTP fallback │ ├── duckduckgo.py │ └── yahoo.py ├── fetcher.py # web_fetch 实现 └── types.py / utils.py 加新引擎只需要继承对应基类、实现几个方法就行，README 里有详细说明。 碎碎念 做这个项目过程中的几个观察： JS 渲染是 2026 年搜索工具的门槛了 。Google 的搜索结果甚至需要 JS 执行完才会出现，纯 HTTP 方案基本不可用 免费方案反而比付费 API 好用 。直接浏览器搜结果最全最实时，API 受限太多 失败兜底比成功路径更重要 。CAPTCHA 、超时、页面变化都是常态，双路渲染+队列管理这些"不性感"的设计才是稳定性的基石 感谢原作者 mrkrsl 的优秀工作 欢迎各位大佬试用提 PR ，有问题直接回复聊~
微软近日证实，正在对 Windows 11 中所有沿用多年的传统对话框进行全面重写，目标不仅是补齐深色模式等视觉体验，而是用现代 WinUI 3 框架替换老旧界面，实现设计与性能的系统级升级。 目前，Windows 11 中大量弹窗和对话框仍依赖传统界面组件，只在局部尝试了深色模式等改造，这一状况有望在下一次重大版本更新中发生明显改变。 微软此前多次强调，将对 Windows 11 进行“根本性改进”，其中包括内存管理、整体性能以及设计语言一致性等关键领域。 在性能方面，系统已通过诸如“低延迟配置文件（Low Latency Profile）”以及提升 explorer.exe 可靠性等更新，逐步改善卡顿和崩溃问题。 在设计层面，微软近期已为部分旧版对话框引入深色模式，优先覆盖文件操作相关弹窗，如复制、删除、剪切等。 用户只要启用系统深色模式，再进行跨分区移动文件等操作，即可直接看到全新的深色文件传输界面。 不过，微软也承认，单纯给旧对话框“上个深色皮肤”并不能算真正的现代化，只有用 WinUI 3 编写的新界面彻底替换 Win32 时代的旧组件，才符合其长期设计规划。 以 Windows 中历史悠久的“运行（Win+R）”对话框为例，这一组件最早可以追溯到几十年前，如今微软已基于 WinUI 为其开发新版界面，并以可选功能的形式推送测试。 新版运行框在外观上更精简，还加入了历史记录等现代功能，用于探索未来系统级对话框的统一方向。 此次大规模重写计划的更多细节来自微软设计团队高管在社交平台上的回应。 有用户指出，尽管运行对话框的现代化是积极信号，但系统中仍存在大量老旧界面，例如“通用文件打开对话框”，即在应用内浏览分区、文件夹、路径时经常弹出的选择窗口。 该用户以及其他网友随即点名多位微软 Windows 团队成员，呼吁对这些关键交互界面进行彻底升级。 对此，微软设计合伙人总监 March Rogers 明确表示，团队已经在梳理所有老旧对话框清单，并逐项用 WinUI 3 重新实现。 他透露，文件复制对话框在内部版本中已经完成重写，而通用文件对话框则在待办列表上，未来也将迁移到新的框架上。 这意味着 Windows 用户在日常操作中最常接触的多个核心弹窗，将逐步摆脱几十年前遗留下来的界面逻辑和视觉风格。 外界长期担心的一点是：WinUI 这类现代 UI 框架是否会拖慢系统，削弱微软近年推动的性能优化成果。 许多用户的直观感受是，现代应用往往比传统 Win32 程序更“重”，文件资源管理器（File Explorer）早期的现代化尝试也曾因卡顿和窗口缩放迟滞而备受争议。 不过，随着 Windows 11 25H2 及 2026 年 5 月更新的推进，基于 WinUI 的文件资源管理器性能已有明显改善，微软也公开表示，WinUI 在性能和响应速度方面已取得实质性进展。 运行对话框的重写被视为验证这一进展的典型案例。 按微软公布的数据，传统运行对话框的中位启动时间约为 103 毫秒，而基于 WinUI 的新版本在相同场景下可在约 94 毫秒内完成加载。 从数字上看，这一差距并非巨大，但至少说明现代 UI 框架不再必然意味着“更慢”，在合理实现和优化下，完全有可能与乃至超越旧版体验。 微软内部高管也表示，他们正在与合作伙伴和开发者一起继续打磨这些新界面，力求在视觉统一的同时保持界面响应“利落”。 面对部分用户对传统界面的情感依赖，微软也释放出相对谨慎的信号。 以运行对话框为例，原版基于 Win32 的组件依然“工作良好”，不少用户早已养成用它快速运行命令、打开目录，甚至用来清除文本格式的习惯。 为避免强行替换导致使用习惯被打断，微软选择将新版运行对话框作为完全可选项，用户需自行在系统“设置”应用的高级设置中手动开启。 在此基础上，有合理预期认为，其他采用 WinUI 重写的对话框也可能先以可选功能形式推出，征集用户反馈后，再逐步推广为默认选项。 对于那些偏爱旧式界面的用户，这意味着在相当一段时间内仍能继续使用熟悉的交互方式，而对追求统一视觉和新功能的用户，新版界面则可以更早“尝鲜”。 微软希望借此在“现代化”和“传统体验”之间取得平衡，同时通过分阶段上线降低大规模界面迁移带来的风险。 微软尚未披露全部对话框完成重写的具体时间表，但结合目前文件复制窗口已在内部完成、通用文件对话框正在推进的情况，可以判断这一工作将持续一段周期，并可能与未来数个功能更新节奏交织展开。 对 Windows 11 而言，这不仅是一场视觉上的翻新，也涉及系统底层 UI 技术栈的迭代与统一。 在传统与现代并存多年的 Windows 界面体系中，这轮重写有望成为将“屎山”真正融入统一体验的一次关键尝试。 查看评论
之前那版太像“丢个附件完事”了，重写一下。 这份 PPT 是给那种情况用的：论文读完了，方法也大概懂了，但一打开编辑器就不知道从哪写。尤其是强化学习复现，最容易一上来就让 Codex 生成 train.py ，然后报错一堆，最后自己也说不清 Env、reward、算法到底哪里偏了。 我整理这份的思路很简单：别让 Codex 一次性“复现论文”，而是把论文拆成一组能验证的小任务。每一步都能跑、能检查、能继续改，这样才不容易变成玄学调参。 如果只想快速看重点，建议先看 P04、P10-P15、P18。 P01 封面：先把任务说清楚 这不是“AI 自动复现论文”的鸡血课件，重点是怎么让 Codex 做工程助手，而不是让它替你理解论文。 P02 目录：三段路 先搭 RL 代码骨架，再把论文方法拆到代码，最后用训练曲线判断有没有学起来。 P03 第一步先别写代码 强化学习复现第一件事不是写算法，而是把 Env、Agent、训练循环、评估拆开。 P04 最值得看的总图 这页是整份课件的骨架：论文 Methods 里的系统模型、MDP、算法、实验设置，分别应该落到哪个代码模块。 P05 Gym Env 是地基 Env 写错了，后面 PPO 再漂亮也没用。这页可以拿来检查 observation、action、reward、info 有没有对应论文。 P06 先判断算法类型 很多复现卡住不是代码问题，是动作空间和算法骨架没对上。先分清离散/连续，再选 PPO、SAC、DQN。 P07 为什么用 CleanRL CleanRL 的好处是透明，单文件好改，适合和论文伪代码一项项对。不是说它万能，而是方便拆。 P08 Codex 应该站在哪 Codex 适合生成、运行、修 bug、做一致性检查；论文边界和公式真假还是要人来把关。 P09 第二部分开始落地 从这里开始，不再讲概念，转成一组可以直接复制改的 prompt。 P10 五步拆法 Env、Reward、算法接入、启动检查、报错修复。每一步都有产物，别让任务糊成一团。 P11 Prompt 1：只写 Env 这个 prompt 的关键是“只实现 Env”。先把交互接口跑通，别同时要 PPO、画图、实验报告。 P12 Prompt 2：单独查 reward reward 最容易被模型写得像那么回事但其实没对齐论文。这一步要把分项和 info 都留出来查。 P13 Prompt 3：接 CleanRL 这里让 Codex 自己看 CleanRL，但要求它说明选哪个骨架、为什么选，避免盲改。 P14 Prompt 4：先 smoke test 不要上来长训。先验证上下层 observation、action、reward、done、info 都能走通。 P15 Prompt 5：报错不是失败 这一页很实用：把 traceback 当下一轮输入，让 Codex 顺着错误修，直到 smoke test 过。 P16 第三部分：别只看能不能跑 代码跑起来只是第一关，RL 还要看曲线、loss、指标，不然很可能是在随机游走。 P17 监控工具怎么选 一个人本地调参 TensorBoard 够用，团队/多实验追踪再考虑 W&B、MLflow、Aim。 P18 怎么看训练曲线 RL 回报有噪声正常，关键看平滑趋势有没有上升、后期有没有平台。 P19 总结：复现是闭环 论文拆解、代码生成、运行报错、修复验证、训练监控，这条链闭上才算靠谱。 P20 最后一页 如果佬友手上有具体论文，可以按这个结构把 Methods 先拆一遍，再喂给 Codex。 原 PPT 放这里，站内不让传 pptx，所以 zip 里就是原文件： 从论文到代码.zip (184 KB) 如果你也在复现 RL/优化类论文，建议别急着要完整代码，先按 P10 那个五步拆一遍。这样 Codex 才是真的省时间，不是帮你制造一堆更难查的 bug。 1 个帖子 - 1 位参与者 阅读完整话题
最近把自己的简历重写了一遍，没用 Notion 也没套模板，当成一个正经前端工程在做。聊几个我觉得有点意思的设计，顺便求 Star 和拍砖。 一句话介绍：Vite + React 写网站，Remotion 写"简历视频"，同一份 zod 校验过的双语数据驱动两端。 几个自己比较得意的点： Monorepo 里两个 source-only 包 。 @resume/data 和 @resume/ui 都没有 build 步骤， exports 直接指向 src/*.ts ，Vite / Vitest / Remotion 的 webpack / tsc 全部直接吃 TS 源码，少一层产物，少一类玄学。 简历数据单一事实源 。基于 JSON Resume schema 扩展，zod 校验，所有字符串都是 LocalizedString { zh, en } ,网站 section 、Remotion composition 、CLI 渲染脚本全都读同一份 resume.ts ,改一行全部同步。 视频三级降级 ,按用户偏好/网络自动挑： prefers-reduced-motion → 静态 poster saveData / 慢网 → 预渲染 mp4 默认 → 懒加载 @remotion/player ,进入视口才挂载,离开自动暂停回首帧 Remotion 双入口 。CLI/Studio 用 index.ts 注册 root,网页端只 import exports.ts (纯组件 + zod schema + 默认值 + 元信息),两边复用 composition 但互不污染。 CI 渲染按内容哈希缓存 。 apps/remotion/src + packages/data/src 哈希没变就跳过 render,首次部署 5–8 分钟,之后 1–2 分钟。 技术栈：pnpm + Turborepo / React 18 / Remotion 4 / Tailwind(自写 cyberpunk preset)/ react-i18next / @ antfu /eslint-config 。 仓库： https://github.com/JS-mark/personal-resume-website Demo： https://js-mark.com/personal-resume-website/ 任何拍砖都欢迎,尤其想听听别人是怎么处理 Remotion 网页端复用和视频降级这块的。
最近把自己的简历重写了一遍，没用 Notion 也没套模板，当成一个正经前端工程在做。聊几个我觉得有点意思的设计，顺便求 Star 和拍砖。 一句话介绍：Vite + React 写网站，Remotion 写"简历视频"，同一份 zod 校验过的双语数据驱动两端。 几个自己比较得意的点： Monorepo 里两个 source-only 包 。 @resume/data 和 @resume/ui 都没有 build 步骤， exports 直接指向 src/*.ts ，Vite / Vitest / Remotion 的 webpack / tsc 全部直接吃 TS 源码，少一层产物，少一类玄学。 简历数据单一事实源 。基于 JSON Resume schema 扩展，zod 校验，所有字符串都是 LocalizedString { zh, en } ,网站 section 、Remotion composition 、CLI 渲染脚本全都读同一份 resume.ts ,改一行全部同步。 视频三级降级 ,按用户偏好/网络自动挑： prefers-reduced-motion → 静态 poster saveData / 慢网 → 预渲染 mp4 默认 → 懒加载 @remotion/player ,进入视口才挂载,离开自动暂停回首帧 Remotion 双入口 。CLI/Studio 用 index.ts 注册 root,网页端只 import exports.ts (纯组件 + zod schema + 默认值 + 元信息),两边复用 composition 但互不污染。 CI 渲染按内容哈希缓存 。 apps/remotion/src + packages/data/src 哈希没变就跳过 render,首次部署 5–8 分钟,之后 1–2 分钟。 技术栈：pnpm + Turborepo / React 18 / Remotion 4 / Tailwind(自写 cyberpunk preset)/ react-i18next / @ antfu /eslint-config 。 仓库： https://github.com/JS-mark/personal-resume-website Demo： https://js-mark.com/personal-resume-website/ 任何拍砖都欢迎,尤其想听听别人是怎么处理 Remotion 网页端复用和视频降级这块的。
最近把自己的简历重写了一遍，没用 Notion 也没套模板，当成一个正经前端工程在做。聊几个我觉得有点意思的设计，顺便求 Star 和拍砖。 一句话介绍：Vite + React 写网站，Remotion 写"简历视频"，同一份 zod 校验过的双语数据驱动两端。 几个自己比较得意的点： Monorepo 里两个 source-only 包 。 @resume/data 和 @resume/ui 都没有 build 步骤， exports 直接指向 src/*.ts ，Vite / Vitest / Remotion 的 webpack / tsc 全部直接吃 TS 源码，少一层产物，少一类玄学。 简历数据单一事实源 。基于 JSON Resume schema 扩展，zod 校验，所有字符串都是 LocalizedString { zh, en } ,网站 section 、Remotion composition 、CLI 渲染脚本全都读同一份 resume.ts ,改一行全部同步。 视频三级降级 ,按用户偏好/网络自动挑： prefers-reduced-motion → 静态 poster saveData / 慢网 → 预渲染 mp4 默认 → 懒加载 @remotion/player ,进入视口才挂载,离开自动暂停回首帧 Remotion 双入口 。CLI/Studio 用 index.ts 注册 root,网页端只 import exports.ts (纯组件 + zod schema + 默认值 + 元信息),两边复用 composition 但互不污染。 CI 渲染按内容哈希缓存 。 apps/remotion/src + packages/data/src 哈希没变就跳过 render,首次部署 5–8 分钟,之后 1–2 分钟。 技术栈：pnpm + Turborepo / React 18 / Remotion 4 / Tailwind(自写 cyberpunk preset)/ react-i18next / @ antfu /eslint-config 。 仓库： https://github.com/JS-mark/personal-resume-website Demo： https://js-mark.com/personal-resume-website/ 任何拍砖都欢迎,尤其想听听别人是怎么处理 Remotion 网页端复用和视频降级这块的。
RT 10B以下的模型，需求是用于简单重写prompt或者用来翻译。 有没有佬友知道哪儿有可以免费用的，主要图个速度快，速度太慢的不行 。 补充一下: 我是考虑过自己部署，但是习惯先找白嫖方案。 13 个帖子 - 9 位参与者 阅读完整话题
我看有个公众号说2026年5月26发布了rust-v0.134.0版本 真的假的，重构后会更流批么 补充：再也不看微信公众号了，全特么骗人得，感觉有点丢脸了 15 个帖子 - 11 位参与者 阅读完整话题
GNOME Commander 是 GNOME 桌面的传统文件管理器，其灵感来源于 Norton Commander，现在已使用 Rust 编程语言重写，并且还使用了 GTK4 工具包。GNOME Commander 最初是用 C++ 编写的，但随着本周发布的 GNOME Commander 2.0 版本，它现在主要由 Rust 代码构成，并且正在过渡到使用 GTK4 工具包。 GNOME Commander 2.0 还增加了一个嵌入式终端来显示 GNOME Commander 运行的命令的输出，重新设计了快速搜索功能，改进了搜索对话框，增强了内部查看器，提高了辅助功能，并增强了键盘快捷键对话框。 GNOME Commander 2.0 还带来了改进的 Wayland 支持和其他现代化改进。 GNOME Commander 2.0 文件管理器版本 可以通过GitHub 下载，还可以了解更多详情。 查看评论
如题， 重写一个老的 go 服务端，自定义协议的，大概 10w 行+的规模。 一开始我是边和 ai 对话边人工审核，后来代码生成速度太快，就没人工审核全程 ai 。 ai 完工后开始人工检查，发现到处是问题。 代码是能跑通就行，代码主路径能通，然后问题一堆，包括不限于： 资源泄露、重复代码、糟糕的架构、副分支逻辑错误、功能缺失等等。 然后一个一个的修， 靠 ai 修的话又是大范围修改代码，改了的代码又要大量重新人工审核。 整个流程变成了，生成代码->人工审核->生成代码->再次人工审核不断循环。 这部分耗时大概达到了编写的耗时 10-20 倍还没完成。 目前整体耗时已经超过了当时手写第一版的时间，但是现在项目还没完工，到处是 bug 。
如题， 重写一个老的 go 服务端，自定义协议的，大概 10w 行+的规模。 一开始我是边和 ai 对话边人工审核，后来代码生成速度太快，就没人工审核全程 ai 。 ai 完工后开始人工检查，发现到处是问题。 代码是能跑通就行，代码主路径能通，然后问题一堆，包括不限于： 资源泄露、重复代码、糟糕的架构、副分支逻辑错误、功能缺失等等。 然后一个一个的修， 靠 ai 修的话又是大范围修改代码，改了的代码又要大量重新人工审核。 整个流程变成了，生成代码->人工审核->生成代码->再次人工审核不断循环。 这部分耗时大概达到了编写的耗时 10-20 倍还没完成。 目前整体耗时已经超过了当时手写第一版的时间，但是现在项目还没完工，到处是 bug 。