[分享创造] 我做了个多语言版本的 deepwiki，可以为 github 仓库生成免费中文报告
网站名
www.repothread.com
先说重点
1. 听取 V 友的建议，添加了 AI 聊天功能，目前用户比较少，所以用的 GLM-4.7 模型，欢迎体验(求大佬憋刷我 API ，小本买卖)
2. 感觉 deepwiki 的聊天和文档太割裂了，所以抄了 google 的布局方案
3. 还开发了一些支付和专业版报告里的功能，目前还没放开，放开后给 V 友们详细介绍，会在 V 站发放专业版的免费邀请码
下面是照本宣科的项目简介
厌倦了接手项目时面对一堆没有文档的代码？ RepoThread 来帮你。
它能做什么？
只需输入 GitHub 仓库地址，AI 自动分析代码结构，生成交互式项目文档，包括架构图、模块说明、调用关系等。还能直接和 AI 对话，问它"这个函数是干嘛的"、"数据流是怎么走的"。
核心亮点：
● 📊 自动生成 Mermaid 架构图和流程图
● 🌍 3 种语言界面，中英日，后期会扩展更多语言，有特殊语言要求的 V 友评论区提，优先支持
● 💬 AI 对话功能，边看文档边提问
适合场景：新人 onboarding 、代码审查、技术调研、遗留系统梳理。
via V2EX
网站名
www.repothread.com
先说重点
1. 听取 V 友的建议，添加了 AI 聊天功能，目前用户比较少，所以用的 GLM-4.7 模型，欢迎体验(求大佬憋刷我 API ，小本买卖)
2. 感觉 deepwiki 的聊天和文档太割裂了，所以抄了 google 的布局方案
3. 还开发了一些支付和专业版报告里的功能，目前还没放开，放开后给 V 友们详细介绍，会在 V 站发放专业版的免费邀请码
下面是照本宣科的项目简介
厌倦了接手项目时面对一堆没有文档的代码？ RepoThread 来帮你。
它能做什么？
只需输入 GitHub 仓库地址，AI 自动分析代码结构，生成交互式项目文档，包括架构图、模块说明、调用关系等。还能直接和 AI 对话，问它"这个函数是干嘛的"、"数据流是怎么走的"。
核心亮点：
● 📊 自动生成 Mermaid 架构图和流程图
● 🌍 3 种语言界面，中英日，后期会扩展更多语言，有特殊语言要求的 V 友评论区提，优先支持
● 💬 AI 对话功能，边看文档边提问
适合场景：新人 onboarding 、代码审查、技术调研、遗留系统梳理。
via V2EX
[Apple TV] 大家在 Apple TV 上怎么屏蔽流媒体广告？
我目前的网络配置是自己部署的服务，两台 VPS 一台网络好，另一台流媒体。在 Apple TV 上现在是直接用 TV 版的 Surge 分流。
在 macOS 用 Surge + AdGuard ，在浏览器里看流媒体是没有广告的。我试过把 AdGuard 的 Outbound proxy 配成 Surge 的代理，然后让 Apple TV 直接通过 Gateway 模式把网络连到 mac 上，看 Disney+、HBO 这些服务最便宜的订阅，还是会有广告，但 Peacock 倒是不再有广告了，所以似乎流量是从 AdGuard 那出去了，但对大部分流媒体没起作用？
另外 AdGuard DNS 它检测到看流媒体的 VPS IP 是非家庭宽带，就没法注册设备。
有什么方式能在 Apple TV 上屏蔽掉美区流媒体的广告么？
via V2EX
我目前的网络配置是自己部署的服务，两台 VPS 一台网络好，另一台流媒体。在 Apple TV 上现在是直接用 TV 版的 Surge 分流。
在 macOS 用 Surge + AdGuard ，在浏览器里看流媒体是没有广告的。我试过把 AdGuard 的 Outbound proxy 配成 Surge 的代理，然后让 Apple TV 直接通过 Gateway 模式把网络连到 mac 上，看 Disney+、HBO 这些服务最便宜的订阅，还是会有广告，但 Peacock 倒是不再有广告了，所以似乎流量是从 AdGuard 那出去了，但对大部分流媒体没起作用？
另外 AdGuard DNS 它检测到看流媒体的 VPS IP 是非家庭宽带，就没法注册设备。
有什么方式能在 Apple TV 上屏蔽掉美区流媒体的广告么？
via V2EX
[分享创造] 强迫症福音！为中西文排版添加空白的浏览器扩展
2026 年了，中英文混排时你还在手动敲空格？其实现在所有浏览器的渲染引擎都已经支持 CSS
不过遗憾的是，现阶段
安装地址：
● Chrome:https://chromewebstore.google.com/detail/hgpoalphijlhjfpfgmabhicbpalndged
● Edge: https://microsoftedge.microsoft.com/addons/detail/dpiioklocgacljopopjdlklbebkfmkom
BTW：浏览器厂商已经同意将来会把默认值改为
关于
via V2EX
2026 年了，中英文混排时你还在手动敲空格？其实现在所有浏览器的渲染引擎都已经支持 CSS
text-autospace: normal 了。它会自动帮你在中文与英文/数字之间添加“空白”（注意是在页面渲染时添加“空白”，而不是在输入时添加“空格”），解决了长久以来 Web 上的中英文排版的问题。以后不用再靠手工敲空格了！不过遗憾的是，现阶段
text-autospace 的默认值是 no-autospace，也就是默认不启用，需要网站的开发者手工启用（ opt-in ）。所以我做了一个浏览器扩展，功能非常简单，就是自动向页面添加 text-autospace: normal。这样在阅读网页时就可以立即带来更好的阅读体验了。安装地址：
● Chrome:https://chromewebstore.google.com/detail/hgpoalphijlhjfpfgmabhicbpalndged
● Edge: https://microsoftedge.microsoft.com/addons/detail/dpiioklocgacljopopjdlklbebkfmkom
BTW：浏览器厂商已经同意将来会把默认值改为
normal，也就是默认启用这个功能。在那之前这个扩展至少解决了现在的问题。关于
text-autospace 我还专门写了一篇介绍文章，感兴趣的可以看这里《告别“盘古之白”：CSS text-autospace 与中文排版的圣杯时刻》via V2EX
[分享创造] 我是欧维 Ove，一名独立开发者。2026，我要送你一份礼物🎁
我是欧维 Ove ，一名独立开发者。 2026 ，我要送你一份礼物🎁
正式发布！！！ 不需要付费！ 不需要加入社群！ 不需要登录！ 免费中文 SEO 知识库已上线！ 全程干货，内容秒杀很多付费社群！
[独立开发前线｜ SEO 从 0 到 100 ] https://lownrain.feishu.cn/wiki/AS5nwII3picsY1kijJicXWOUnSc
我的目标是希望搭建一个最大的中文 SEO 免费知识库，帮助更多人免费学习 SEO ，通过 SEO 的方式，推广自己的产品，获取流量，打造被动收入。 我一直在运营独立开发前线这个社区，老实说，社区根本不赚钱，但我依然投入了大量的时间精力。
一方面是自己的热爱，我热爱创造，热爱产品，热爱探索新东西。另一方面是希望提升国内的独立开发氛围，帮助更多人一起成长，在这个环境下，找到属于自己的一条路。
过去我也写了很多文章，发表在了独立开发前线网站、公众号等地方，累计阅读量也有上千万了。 这个知识库是我第一次系统性的整理 SEO 的知识。我希望它是一个长期有价值的内容产品，不管你是小白，还是 SEO 高手，在这个知识库都能有所收获。当然，我也会持续更新，丰富知识库的内容。
目前知识库 1.0 已上线，欢迎收藏访问，也欢迎投稿共建！ 一起创造，让这个世界更加美好
via V2EX
我是欧维 Ove ，一名独立开发者。 2026 ，我要送你一份礼物🎁
正式发布！！！ 不需要付费！ 不需要加入社群！ 不需要登录！ 免费中文 SEO 知识库已上线！ 全程干货，内容秒杀很多付费社群！
[独立开发前线｜ SEO 从 0 到 100 ] https://lownrain.feishu.cn/wiki/AS5nwII3picsY1kijJicXWOUnSc
我的目标是希望搭建一个最大的中文 SEO 免费知识库，帮助更多人免费学习 SEO ，通过 SEO 的方式，推广自己的产品，获取流量，打造被动收入。 我一直在运营独立开发前线这个社区，老实说，社区根本不赚钱，但我依然投入了大量的时间精力。
一方面是自己的热爱，我热爱创造，热爱产品，热爱探索新东西。另一方面是希望提升国内的独立开发氛围，帮助更多人一起成长，在这个环境下，找到属于自己的一条路。
过去我也写了很多文章，发表在了独立开发前线网站、公众号等地方，累计阅读量也有上千万了。 这个知识库是我第一次系统性的整理 SEO 的知识。我希望它是一个长期有价值的内容产品，不管你是小白，还是 SEO 高手，在这个知识库都能有所收获。当然，我也会持续更新，丰富知识库的内容。
目前知识库 1.0 已上线，欢迎收藏访问，也欢迎投稿共建！ 一起创造，让这个世界更加美好
via V2EX
[问与答] 现在 Agent 的写代码的成本不低啊
claude-4.5-sonnet 3.3M US$1.51
composer-1 622.7K US$0.22
grok-code-fast-1 536.5K US$0.02
上面是最近的 3 次 agent request
cursor 起步价一次 Request 0.01$折合接近 1 毛钱
常简单的任务我只敢用那个最便宜经济实惠的 grok-code-fast-1, 每次差不多 0.02-0.1$左右
稍复杂的用 composer-1, 一次至少 0.1$起步
复杂任务 Sonnet 4.5 基本上一次在 1$上下
Opus 4.5 在 Sonnet 4.5 应该要再上浮 50%
像我这种这么克制地用, 精打细算的那种, 估计 20$也很难撑到一个月
via V2EX
claude-4.5-sonnet 3.3M US$1.51
composer-1 622.7K US$0.22
grok-code-fast-1 536.5K US$0.02
上面是最近的 3 次 agent request
cursor 起步价一次 Request 0.01$折合接近 1 毛钱
常简单的任务我只敢用那个最便宜经济实惠的 grok-code-fast-1, 每次差不多 0.02-0.1$左右
稍复杂的用 composer-1, 一次至少 0.1$起步
复杂任务 Sonnet 4.5 基本上一次在 1$上下
Opus 4.5 在 Sonnet 4.5 应该要再上浮 50%
像我这种这么克制地用, 精打细算的那种, 估计 20$也很难撑到一个月
via V2EX
[程序员] [独立开发] 既然不做 99.99% SLA，我决定用“空手套白狼”解决分布式竞态问题
前言：完美的架构，失效了？
我是个写 Rust 的独立开发者。在我的交易模拟系统里，我引以为傲地设计了一套纯内存的领域事件驱动架构。
没有 Kafka ，没有 RabbitMQ ，就靠 Rust 强大的内存通道，实现了微秒级的模块解耦。交易服务只管平仓，根本不需要关心是谁在发通知、是谁在算奖励。
直到有一天，我发现了一个幽灵般的 Bug 。
第一章：消失的奖励（ The Race Condition ）
场景很简单：用户注册成功 -> 后端发放“新手大礼包” -> 推送弹窗通知。
逻辑看起来天衣无缝：后端提交注册事务，紧接着发送一个“注册成功”的内部事件。
然而测试发现，用户注册进去了，奖励也发了，但前端死活收不到弹窗。
排查日志后，我发现这是一个经典的分布式竞态条件（ Race Condition ）。虽然我是单体应用，但前后端在时间维度上是割裂的：
后端（光速）：事务提交、触发事件、计算奖励、尝试 Websocket 推送。此时发现用户尚未建立连接（因为是刚注册完），于是只能两手一摊，丢弃消息。
前端（龟速）：收到注册成功 200 OK ，保存 Token ，初始化 SDK ，请求个人信息，最后才建立 Websocket 连接。
这就好比：后端这边的发令枪响了，奖杯也扔出去了，前端的运动员还在系鞋带。等他抬起头，奖杯早就摔碎在底上了。
第二章：教科书式的“正确”方案（ The Inbox Pattern ）
遇到这种“发太快、连太慢”的问题，资深架构师（其实就是我自己）的第一反应是：上持久化，用信箱模式（ Inbox Pattern ）！
方案极其正统：
建表：搞个“用户通知表”。
落库：不管用户在不在，消息先插进数据库，标记为“未读”。
推拉结合：后端试着推一下；前端连上 WS 后，立马调一个 HTTP 接口拉取未读消息。
这个方案完美吗？完美。可靠性高吗？极高。 但我看着手里的键盘，犹豫了。
作为一个独立开发者，为了这就加一张表？写一套 CRUD ？前端还得改逻辑去轮询？如果未来我有 10 种消息都要这么搞，数据库会不会爆炸？我只有一双手，我要的是功能上线，不是在代码里建一座大教堂。
“复杂性是独立开发者的墓志铭。” 我把这个方案否了。
第三章：来自内存的暴力美学（ The Spin-Wait ）
我开始反思：通过数据库中转，本质上是用空间（磁盘）换时间（等待）。 那我能不能直接用时间换时间？
Rust 的协程（ Task ）极其廉价，开几万个跟玩一样。我为什么不直接在内存里“等”前端上线呢？
于是，诞生了这个**“异步自旋重试”**方案。
我并没有修改复杂的架构，而是写了一个简单的“蹲守”逻辑：
当需要发送奖励而用户不在线时，后端并不会直接放弃，而是派出一个轻量级的后台协程（相当于一个临时工）。
这个协程的任务非常简单粗暴：它拿着信站在门口，每隔 0.5 秒看一眼“用户连上 Websocket 了没？”
如果连上了，立马把信塞进去，任务结束。
如果没连上，就睡一会儿再看。
如果等了 60 秒（超时阈值）还没人影，那就算了，毁灭吧。
第四章：取舍与哲学
这个方案在“架构师”眼里可能是离经叛道的：
不可靠：万一这 60 秒内服务器重启，内存里的消息就丢了。
不优雅：居然用轮询（ Polling ）这种原始手段？
但对于我的场景，它是最合适的：
零基础设施：不需要 Redis ，不需要新表，不需要改前端 Pull 逻辑。
极致简单：就在通知服务里加个小函数，其他地方完全无感。
用户体验：前端注册完，卡顿了 3 秒才连上，第 3.5 秒后端那个“蹲守协程”刚好醒来，把奖励推过去。用户看来就是：注册 -> 自动登录 -> 砰！奖励弹窗。丝般顺滑。
关于丢消息：如果服务器真的在那几十秒重启了，用户仅仅是少看了一个“获得奖励”的弹窗，但他账户里的钱（ DB 事务保证）是一分不少的。这个 SLA ，我可以接受。
结语
我们在做架构设计时，往往容易陷入“大厂思维”的陷阱，追求理论上的完美和绝对的可靠。
但在独立开发的世界里，代码量越少，Bug 越少；依赖越少，睡得越香。
用 Rust 的高性能去弥补架构的“土”，用内存的易失性去换取开发的“快”。这就是我作为一个 CRUD Boy 的生存之道。
via V2EX
前言：完美的架构，失效了？
我是个写 Rust 的独立开发者。在我的交易模拟系统里，我引以为傲地设计了一套纯内存的领域事件驱动架构。
没有 Kafka ，没有 RabbitMQ ，就靠 Rust 强大的内存通道，实现了微秒级的模块解耦。交易服务只管平仓，根本不需要关心是谁在发通知、是谁在算奖励。
直到有一天，我发现了一个幽灵般的 Bug 。
第一章：消失的奖励（ The Race Condition ）
场景很简单：用户注册成功 -> 后端发放“新手大礼包” -> 推送弹窗通知。
逻辑看起来天衣无缝：后端提交注册事务，紧接着发送一个“注册成功”的内部事件。
然而测试发现，用户注册进去了，奖励也发了，但前端死活收不到弹窗。
排查日志后，我发现这是一个经典的分布式竞态条件（ Race Condition ）。虽然我是单体应用，但前后端在时间维度上是割裂的：
后端（光速）：事务提交、触发事件、计算奖励、尝试 Websocket 推送。此时发现用户尚未建立连接（因为是刚注册完），于是只能两手一摊，丢弃消息。
前端（龟速）：收到注册成功 200 OK ，保存 Token ，初始化 SDK ，请求个人信息，最后才建立 Websocket 连接。
这就好比：后端这边的发令枪响了，奖杯也扔出去了，前端的运动员还在系鞋带。等他抬起头，奖杯早就摔碎在底上了。
第二章：教科书式的“正确”方案（ The Inbox Pattern ）
遇到这种“发太快、连太慢”的问题，资深架构师（其实就是我自己）的第一反应是：上持久化，用信箱模式（ Inbox Pattern ）！
方案极其正统：
建表：搞个“用户通知表”。
落库：不管用户在不在，消息先插进数据库，标记为“未读”。
推拉结合：后端试着推一下；前端连上 WS 后，立马调一个 HTTP 接口拉取未读消息。
这个方案完美吗？完美。可靠性高吗？极高。 但我看着手里的键盘，犹豫了。
作为一个独立开发者，为了这就加一张表？写一套 CRUD ？前端还得改逻辑去轮询？如果未来我有 10 种消息都要这么搞，数据库会不会爆炸？我只有一双手，我要的是功能上线，不是在代码里建一座大教堂。
“复杂性是独立开发者的墓志铭。” 我把这个方案否了。
第三章：来自内存的暴力美学（ The Spin-Wait ）
我开始反思：通过数据库中转，本质上是用空间（磁盘）换时间（等待）。 那我能不能直接用时间换时间？
Rust 的协程（ Task ）极其廉价，开几万个跟玩一样。我为什么不直接在内存里“等”前端上线呢？
于是，诞生了这个**“异步自旋重试”**方案。
我并没有修改复杂的架构，而是写了一个简单的“蹲守”逻辑：
当需要发送奖励而用户不在线时，后端并不会直接放弃，而是派出一个轻量级的后台协程（相当于一个临时工）。
这个协程的任务非常简单粗暴：它拿着信站在门口，每隔 0.5 秒看一眼“用户连上 Websocket 了没？”
如果连上了，立马把信塞进去，任务结束。
如果没连上，就睡一会儿再看。
如果等了 60 秒（超时阈值）还没人影，那就算了，毁灭吧。
第四章：取舍与哲学
这个方案在“架构师”眼里可能是离经叛道的：
不可靠：万一这 60 秒内服务器重启，内存里的消息就丢了。
不优雅：居然用轮询（ Polling ）这种原始手段？
但对于我的场景，它是最合适的：
零基础设施：不需要 Redis ，不需要新表，不需要改前端 Pull 逻辑。
极致简单：就在通知服务里加个小函数，其他地方完全无感。
用户体验：前端注册完，卡顿了 3 秒才连上，第 3.5 秒后端那个“蹲守协程”刚好醒来，把奖励推过去。用户看来就是：注册 -> 自动登录 -> 砰！奖励弹窗。丝般顺滑。
关于丢消息：如果服务器真的在那几十秒重启了，用户仅仅是少看了一个“获得奖励”的弹窗，但他账户里的钱（ DB 事务保证）是一分不少的。这个 SLA ，我可以接受。
结语
我们在做架构设计时，往往容易陷入“大厂思维”的陷阱，追求理论上的完美和绝对的可靠。
但在独立开发的世界里，代码量越少，Bug 越少；依赖越少，睡得越香。
用 Rust 的高性能去弥补架构的“土”，用内存的易失性去换取开发的“快”。这就是我作为一个 CRUD Boy 的生存之道。
via V2EX
[分享创造] 我是 FortArcade 的站长，邀请大家来摸鱼/玩游戏！
大家好！
我是 FortArcade.com 的站长。我想邀请大家来我的小站逛一逛，放松一下心情。我们专注于收集好玩、解压的网页游戏（无需下载，点开即玩）。
目前站内有一些非常热门的游戏，也许正是你喜欢的：
Slice Master: 强迫症福音，解压切切切！
Bloxd.io: 类似 Minecraft 的沙盒建造与对战。
Snake Arena: 经典贪吃蛇的现代大乱斗版。
Space Waves: 节奏感极强的波动闯关。
Shell Shockers: 硬核又可爱的“蛋蛋”射击游戏。
网站还在成长中，我知道它肯定还有很多不足。如果你在体验过程中有任何不爽的地方（比如加载慢、找不到游戏、或者希望增加某个特定游戏），请务必在评论区告诉我！
每一条建议对我来说都非常珍贵。希望能把这里建成大家最喜欢的游戏角落。
传送门 👉 FortArcade.com
感谢大家的支持！❤️
via V2EX
大家好！
我是 FortArcade.com 的站长。我想邀请大家来我的小站逛一逛，放松一下心情。我们专注于收集好玩、解压的网页游戏（无需下载，点开即玩）。
目前站内有一些非常热门的游戏，也许正是你喜欢的：
Slice Master: 强迫症福音，解压切切切！
Bloxd.io: 类似 Minecraft 的沙盒建造与对战。
Snake Arena: 经典贪吃蛇的现代大乱斗版。
Space Waves: 节奏感极强的波动闯关。
Shell Shockers: 硬核又可爱的“蛋蛋”射击游戏。
网站还在成长中，我知道它肯定还有很多不足。如果你在体验过程中有任何不爽的地方（比如加载慢、找不到游戏、或者希望增加某个特定游戏），请务必在评论区告诉我！
每一条建议对我来说都非常珍贵。希望能把这里建成大家最喜欢的游戏角落。
传送门 👉 FortArcade.com
感谢大家的支持！❤️
via V2EX
[求职] 12 年资深运维老兵求远程工作机会，
个人优势:
丰富的互联网行业经验：前腾讯高级架构师，10 年以上互联网行业运维管理&技术咨询经验，熟悉游戏/电商/金融/运 营商等行主
流业务场景和解决方案。
深耕云计算行业：对腾讯云/阿里云/aws/gcp/cloudflare/等国内外主流云产品有 8 年以上线上大规模业务环境应用及调优 经验，
熟悉公有/私有/混合云项目从解决方案编写到实施交付落地全流程。
深厚的运维&稳定性建设和团队管理经验：熟悉自建 IDC 机房全流程，具有万台服务器多云多数据中心场景下架构设计经验， 具备
618/双 11 活动大促高并发大流量场景下的运维保障经验，擅长从 0 到 1 建设立运维自动化体系，深入理解 Sre,DevOps,FinOps,AiO
ps,SecOps,微服务架构，云原生等主流运维技术理念,曾带领 40+混合型技术团队 高效支撑业务。
擅长的技术领域：SRE 体系建设，混合云架构设计，云产品方案选型，云环境成本治理，迁云上云全生命周期护航，云环境安全治
理。
掌握的工具&平台&技术栈：
可观测性：ELK,grafanfa,Prometheus,zabbix,nagios,cacti,open-falcon
研运一体&自动化：K8s,docker,ansible,saltstack,Jenkins,terraform,gitlab
中间 件&DB：mysql,redis,mongodb,kafka,lvs,nginx,tomcat
云平台：腾讯云,阿里云,aws,gcp,cloudflare
云原生容器：k8s,docker,ha
联系邮箱 victor.wangcc@gmail.com
via V2EX
个人优势:
丰富的互联网行业经验：前腾讯高级架构师，10 年以上互联网行业运维管理&技术咨询经验，熟悉游戏/电商/金融/运 营商等行主
流业务场景和解决方案。
深耕云计算行业：对腾讯云/阿里云/aws/gcp/cloudflare/等国内外主流云产品有 8 年以上线上大规模业务环境应用及调优 经验，
熟悉公有/私有/混合云项目从解决方案编写到实施交付落地全流程。
深厚的运维&稳定性建设和团队管理经验：熟悉自建 IDC 机房全流程，具有万台服务器多云多数据中心场景下架构设计经验， 具备
618/双 11 活动大促高并发大流量场景下的运维保障经验，擅长从 0 到 1 建设立运维自动化体系，深入理解 Sre,DevOps,FinOps,AiO
ps,SecOps,微服务架构，云原生等主流运维技术理念,曾带领 40+混合型技术团队 高效支撑业务。
擅长的技术领域：SRE 体系建设，混合云架构设计，云产品方案选型，云环境成本治理，迁云上云全生命周期护航，云环境安全治
理。
掌握的工具&平台&技术栈：
可观测性：ELK,grafanfa,Prometheus,zabbix,nagios,cacti,open-falcon
研运一体&自动化：K8s,docker,ansible,saltstack,Jenkins,terraform,gitlab
中间 件&DB：mysql,redis,mongodb,kafka,lvs,nginx,tomcat
云平台：腾讯云,阿里云,aws,gcp,cloudflare
云原生容器：k8s,docker,ha
联系邮箱 victor.wangcc@gmail.com
via V2EX