V2EX 热门帖子
1. 荣耀笔记本与 Linux - 性能管理
这两天在 2024 独显版的MagicBook 16 Pro ( U5 125H + 4060 mobile )上装了Fedora 43 Workstation ,安装过程很顺利,驱动基本都自动装上了。
现在唯一有个问题:不知道怎么调整高性能模式
所有游戏一启动独显功耗在 40W 左右波动,一分钟左右掉到 20W ,整个系统都卡起来了。tuned ,nvidia-smi 设置频率,gamescope 都试过了,基本没啥影响。我能确定不是兼容层或 Wayland 的问题,因为 Minecraft ( OpenGL )也会卡,也试过 mint 但没效果。
Fn + P 是笔记本调整性能模式的快捷键,也是我唯一能复现的提高 GPU 功率的方法,不过提高后不到一分钟又会掉下去。按这个快捷键的时候能通过
acpi_listen看到wmi PNP0C14:03 000000a0 00000000,不过我没有找到任何有用的 acpi 接口。其他基本的因素也考虑过:RAM 基本没超过 2/3 ,CPU 没降频也没满载,iGPU 基本是空闲。
我还去问了荣耀客服,让我留电话和邮箱说之后有工程师回复我,最后就等来了 “关于您反馈的在 linux 系统下的性能调度怎么调整问题我们已收到, 目前是未核实到相关信息和相关功能。”
要是有高人看到这里能指点一下,我将感激万分。
闲谈
不玩游戏的话,系统用起来没啥毛病。装了达芬奇还没试性能如何,估计跟游戏差不多拉跨。之后再装 linux 的话,笔记本电脑还是慎重考虑吧,尤其是喜欢搞自研的这几家。
我唯一舍不得的应用是 OneNote ,我想要能书写的笔记软件,要是各位有用过的话能推荐几个吗?或者如何在 linux 上用 OneNote ?
作者: PeterTerpe | 发布时间: 2025-12-27 06:57
2. 程序员对 AI 的偏见
今天 HN 最火的一贴无疑是 Rob Pike 吐槽 AI 。(吐槽可能有点委婉,应为基本是纯骂,甚至是没什么逻辑性的骂)
这让我大跌眼镜。Rob 在我心里一直是一个理性,儒雅的技术人,也是我最敬重的程序员之一。他写的 C 和 Go 都很精妙,还有 UTF-8 的设计。他的技术分享我当圣经一样诵读。
而 HN 大部分程序员也都是站 Rob 一边,国内 V2EX 也是严格禁止 AI 文。
这令我深思。为什么程序员对 AI 有这么大的偏见。是不是有点过了?
作者: cj323 | 发布时间: 2025-12-27 14:43
3. 阿里云也有免费 CDN 了,支持国内区域加速还是无限流量
ESA Entrance 版套餐免费,不限量不限速、直接注册账号就能免费用,我一直续费到了 2050 年 我注册的是国际版,国内版的支持大陆地区的优化加速 之前一直用的 Cloudflare ,但是 Cloudflared 的速度在国内真是一言难尽,时不时还会有阻断的问题,阿里云的套餐我自己实测下来速度还是不错的,个人用完全足够了,Cloudflare 的常用功能阿里云 ESA 都有支持
同时还支持部署 Pages 的功能,ESA 免费领取链接: http://s.tb.cn/e6.0Fu67m
作者: Aliesz | 发布时间: 2025-12-27 14:10
4. 记录一下使用 AntiGravity 压榨 AI 开发一个 Android APP 的事情,并推广这个 APP
说在前面:关于节点的选择
我知道站内推广的东西应该放到推广节点,但是这不单单是一篇推广的文章,更像是一份给予 AI 高权限之后的心得体会记录(姑且可以成为“用后感”吧,哈哈)
为什么有这个想法?
关于 AI 的使用大家都有各自的原因,我这里就不过多赘述了,从刚开始的不信任,到现在的授予高权限,AI 的发展整体是向上并且超出我预期的,在公司也要求我们更多的将一些工作内容尝试交给 AI 完成,因此最近几个月来我用 AI 用的越来越多,这为 Pixel Meter 项目埋下了一开始的种子。
其实自从李跳跳不再维护开始,我是有想过自己写一个跳过广告的 APP ,为此我创建了仓库,参考一些别人博客的文章在开发自己的 APP ,但是从最开始的兴趣满满,到最后不想打开 IDE 写代码,一时兴起而产生的想法动力越发的不足,最后我放弃了,相信不少人都有过这样子的经历与体会(我不止是弃坑了这一个 app ,还有很多的东西都经历过这个流程)。
那时候我总觉得产生一个想法很简单,但是实现这个想法,哪怕是最开始的原型验证试水,对于个人来说成本还是太高了一些(毕竟需要花自己的空闲时间)。
同样的,这个周一开始( 2025 年 12 月 22 日起),我突然就想要在我的 Pixel 10 Pro 上面能够实时查看网速的显示。几年前玩过 Android (类)原生的玩家都知道,因为(类)原生系统都是毛坯房,所谓的设备维护者其实更多是因为他们自己在使用这部设备,因此维护者偶尔会添加他们认为应该有的东西,例如一些系统动画、CJK 字重、网速显示等。而这些东西,国产 Rom 基本都是自带,而我们 Pixel 用户要么不用,要么只能自己想办法了。
于是我开始寻找网速显示的一些 APP ,并就此询问了 Gemini 的一些推荐
(它居然在推荐列表里面把 Windows 的 TrafficMonitor 混进去,还告诉我说有 Android 版)。最终呢下载了几年前就在用的一些 APP ,当然都有缺点:
- NetSpeed Indicator:网速显示统计 VPN ,经典问题,流量数据翻倍(流量从 tun0 到网卡,计算的时候把所有网卡加起来,导致实际流量被重复计算)
- Internet Speed Meter Lite:统计数据粗略查看应该是没有重复,但是界面太老了,让我回想起了刚使用 Material Design 的感觉,免费版本带有广告,看着膈应,还塞进去了一个对我毫无卵用的流量统计功能
- Netspeed Indicator Magisk Module:要 ROOT 或者刷模块,直接 pass
- 其他的一些 app 以前没听过名字,现在也没兴趣一个个去试
突然,我有一个想法:为什么我不自己写一个?
因此我开始询问 AI ,被 Gemini 吹了一通彩虹屁
,我觉得自己突然行了
付诸实施
既然有了想法,加上没有太多空闲时间,因此这一次我打算给 Gemini 高权限,如果可以的话,让它从 0 开始生成代码,直到所有功能完成
于是,我开始和它进行架构设计的探讨(架构探讨并不是第一次,公司的一些项目我也在和 AI 进行架构设计),技术栈的选型
最终敲定了使用双模式的方案进行开发:普通模式尽量精准,不准也无所谓;高权限模式(借助 Shizuku )从数据源层面排除掉 VPN 网卡的流量数据,做到绝对的准确。
当然,这里我犯了一个错误,一开始我就应该在 AntiGravity 中发起会话的,这样 Gemini 能拿到完整的上下文直接开始生成代码,网页版 Gemini 则需要将这些“记忆”压缩成 md 文件再喂给 AntiGravity 。
压榨 AI
拿到这些压缩记忆的 md 文件之后,我通过 Android Studio 创建新项目,然后删除默认创建的一些测试依赖和测试类,使用 AntiGravity 打开项目,切到 Agent Manager 模式。
让 AI 根据这些压缩的记忆开始完善信息丢失的部分(信息在传递的过程中是会有丢失的),哪怕都是 Gemini ,毕竟是在两个地方打开,就像现实中的两个开发人员一样,同 A 沟通的内容,让 B 去做需要让 B 能够完全理解。这个步骤就是让 AI 根据文档对我发起反问,然后根据我的回答完善它的记忆以及文档。
具体的压榨过程就不一一描述了,扔个图就行,反正让它从昨晚工作到了现在(当然我睡觉的时候它也在“睡觉”),详细的一些方向性变更通过仓库提交记录也反映了出来。
整个使用过程我还觉得挺不错的,在这个过程中,我主要复杂代码审查和方向把控,代码审查是为了看它有没有按照我的想法进行编写,方向把控是为了纠正它可能出现的牛角尖状态,我觉得会话长了或者需要开启一个和当前任务关联性很小的需求,就单独开了一个会话。
到最后,整个项目 90%的代码(我手动写过一些代码,主要是审查以及纠正)、所有的文档内容( README 、ChangeLog 、隐私政策)、上架 Google Play 的一些说明内容(简短说明、详细说明,甚至置顶大图) 都是让 Gemini 生成的。
用后感
和两年前我开发 SkipperL (跳广告的项目,已归档) 相比,AI 发展的太快了。两年前我还在为快速消退的热情而觉得可惜,两年后我们完全可以让 AI 帮助我们短时间内完成原型的验证,甚至完成开发!
项目推广
最后推广一下让 Gemini 做的这个项目吧: Pixel Meter
(是的,它甚至是开源的)Pixel Meter 是一款专为 Google Pixel 和原生 Android 设备设计的网速监控应用。它可以解决在使用 VPN 时,传统网速显示应用因同时统计物理接口和虚拟接口流量而导致显示速度翻倍的问题。
它和那些老前辈相比,除了更加现代化的 UI 界面之外,更重要的是使用标准的 API 解决了 VPN 网卡的流量计算问题(没有使用 Shizuku )。
核心原理就是
TrafficStats.getRxBytes(ifaceName)这个从Android S新增的 API ,它允许 app 获取指定网卡的流量数据,因此我们只需要遍历所有网卡,然后排除 VPN 网卡就行了,整体用起来达到的效果是:有TrafficStats的效率,有NetworkStatsManager的精准。旧版本 API 的局限性:
- 老版本中只有
TrafficStats.getTotalRxBytes()和TrafficStats.getTotalTxBytes()函数,获取到的数据已经包含了重复计算的部分,但是这个 API 响应快,计算差值也方便- 而
NetworkStatsManager并不适合用差值来计算网速,因为这个 API 主要用来统计流量,它是隔一段时间将数据写入,所以用起来的时候会出现一些奇怪的情况:上一秒流量显示正常,下一秒流量为 0 ,具体原因如下:
解决了数据源的问题之后,另一个难受的点是:网速显示太小了,虽然我们使用了绘制 Bitmap 的方案实时生成一个“通知图标”,但是这个图标的区域太小了,勉强只能看清楚数字,而单位很不清楚(一众老前辈都是用的这个方案)。另一个展示的方案是悬浮窗,这倒是能解决大小问题,但是会带来一个讨厌的顽固通知“XXX 正在其他应用的上层显示内容”
而 Pixel Meter 带来了一个创新的展示方案:Live Update Notification
这还是我在查阅关于发送通知的相关 API 的时候,偶尔看到的,实时活动+比通知图标宽 的两大优势,让我瞬间觉得,这就是应用层最适合网速显示场景的东西,因此,我开始让 AI 基于此进行代码开发。
另一个大的改变是:我懒得适配旧版本的系统
(旧版本系统就用老旧 APP 足够了,反正都用不了实时活动),并且这东西优先向我进行适配,因此我将项目的 MinSDK 设置为了 36 。(旧版本如果有需要可以自行 fork 进行修改,符合开源协议即可)
)
而推广的目的,除了让大家知道这个方案之外,也是为了上架 Google Play 需要大家一起进行 14 天的封闭测试,期间收到邀请的账号才能够下载 APP ,感兴趣的小伙伴可以留下你们的 Google 账号,也可以通过邮箱发送给我。
邮箱地址:
bXlzdGVyeTBkeWw1MjBAZ21haWwuY29t本文同步发布: https://blog.mystery0.vip/archives/ai_power_for_pixel_meter
作者: Mystery0 | 发布时间: 2025-12-27 16:34
5. 为什么使用 Tomcat 算违反国产化要求,但是使用 Netty 却不算。
RT. 都是海外的开源软件,licence 也都是一样的。
背景
项目上遇到了相关的需求,要求包里不能有 Tomcat 。
公司上面给的方案却是让换成 Netty 而不是打成 war 包来接入客户提供的国产化 web 服务器。
由于之前是 spring-web ,阻塞式的,改成 netty 工作量巨大。是不是因为 Tomcat 有 TongWeb 这种国产替代。但是国内没人做 Netty 的替代。
所以 Tomcat 才会上黑名单,但是 Netty 就活着。
作者: MelodYi | 发布时间: 2025-12-27 02:55
6. 兄弟们,推荐一个稳定好用的 Claude Code 中转站
皓臻云 AI POOL 是我们自建的大模型中转服务,支持 claude code ,内部已经试用测试一个月了,非常稳定,终于可以拿出来推广了。
优势:
- 国内原生部署,兼容 VS Code / 终端 / API 调用。
- 自研多节点集群 + 智能调度,响应 5 秒内,比直连快,承诺 99.9% 可用性
- 微信 / 支付宝直接充,额度实时到账,不用绑 Visa 。
- 代码全程加密传输,不落地不缓存,合规红线绝不碰。
- 核心研发来自国内一线大厂,技术靠得住。
同时如果还有独立开发者要做支付接入的,我们也提供支付服务,可以点击我们网站了解: https://www.haozpay.com
作者: mattpeng | 发布时间: 2025-12-27 16:54
7. vibe coding 生成的 UI 界面很丑怎么办?
我虽然不会设计但是我就觉得很丑,就是那种很明显的 ai 味道,有什么好的提示词或者好的工具或者网站,能帮助我生成漂亮一点的 UI 吗?
作者: punny | 发布时间: 2025-12-27 16:25
8. [分享] 我整理了 200+ 个高质量 RSS 订阅源(涵盖科技/独立博客/新媒体)
体验地址:hot.uihash.com 整理的数据源大部份都是有检验更新日期,大部份博客还是值得收藏,丰富了平台数据;(上次有小伙伴反馈要看外网新闻的,现在也是可以的,至少都是科技,开发类的 rss ),本来测试了国外很多网站,包括 youtube 都可以添加,懂的都懂,但是为了规避风险,还是禁用了,不过大家可以自行部署 RSS: https://github.com/sundt/uihash-hotnews/blob/main/rss_feeds.csv gitee: https://gitee.com/david-sunny/hotnews github: https://github.com/sundt/uihash-hotnews
下一步目标: 将微信公众号纳入进来,然后 RSS 不断更新,这样你就可以选择自己想看的了,不被算法裹挟;
![]()
![]()
作者: David666 | 发布时间: 2025-12-27 12:41
9. 为什么创业不要选择做面向程序员的产品
有很多程序员在用某一款产品的时候,发现了一些不爽的地方。然后心想:
“老子自己也会开发,为啥不自己弄一个,
说不定有很多人也有一样的需求,我做一个 XXX Plus ,肯定比现在这个 XXX 更牛逼,用的人更多。”于是,很多程序员创业时,第一想法都是做一个给程序员用的产品,包括但不限于:
- 一个开发框架
- 一个开发小工具
- 一个只有程序员才需要的 APP
如果不考虑盈利, 那你爱做啥就做啥,别人管不到。
但如果你指望着靠这些产品盈利,请三思而后行。因为:程序员是最难被赚钱的群体。
- 多数程序员都是打工心态。即使你的产品很好用,他也不可能高尚到“为了做老板的项目,而花自己的钱去买一个提效工具”。老板也不可能高尚到“为了牛马干活轻松,而多花一分钱”,因为他认为他已经付过工钱了
- 程序员是非常理性的群体,每一笔消费都是挑三拣四、反复对比过的。你确定你的产品能在对比中取胜?
- 程序员只会购买他这辈子都开发不出来、并且无法免费破解的产品(比如 AI 编程)。多数程序员的选择思路是:先找破解版;再找免费版平替;最后宁愿自己撸,也不可能让同行赚到钱(因为让其他程序员赚到钱了,等于承认其他程序员比自己牛逼,这是在侮辱自己)。
- 你以为程序员的需求是提升开发效率?不是的,程序员真正的需求是:”不用干活,又能赚很多钱“。
因此,当你现在创业想做面向程序员的产品时,务必三思。非行业巨头,不建议走这个路线。
作者: xuld | 发布时间: 2025-12-27 04:18
10. 就没有一个好用的 chrome/edge 下载扩展么?
去下载国外网盘的东西,浏览器自带的下载老是断开连接就傻傻的停在那里了。
本来想着去搞个插件,chrono download manager 结果也是停了就停了
接下来高血压的来了。网络风吹草动,就 kuang 提示一下下载出错。然后就没法接续了。
眼看着都下载了 50%了,点击重新开始,tnnd 给我重置为 0% 了。。
这年头下载工具连「断点续传」这种基操都不会了?
有没有无限自动重试+断点续传的扩展推荐?
太高血压了。
作者: est | 发布时间: 2025-12-27 15:08
11. 公有云对象存储计费疑云:一次普通的上传/下载 HTTP 请求产生多次读/写操作,请求次数按哪个算?
国内公有云的对象存储服务的 API 请求费用官网大多标价 1 元/百万次,但是这个计费的细则,今天核对了两家的流水账单才发现之前理解的一直都错的。
不考虑分片上传、多线程下载这些复杂的场景。就拿最普通的简单下载/上传来说,一次下载/上传 HTTP 请求在后台存储系统内部实际会产生多次读/写操作。
实际的请求费用计次是按 HTTP 请求次数算,还是存储系统内部内部的读/写次数来算?
之前我一直以为是前者,但从账单、后台数据统计与实际业务执行情况数据来分析,显然都与我之前理解的规则不符。
想探讨下目前公有云上各家的计费规则哪种更常用?一次下载请求,多少次读操作属于合理区间?不同的底层实现,计费差异是不是也挺大的?
作者: Adven | 发布时间: 2025-12-27 15:10
12. 用了十几年的 MySQL 了,突然发现 PostgreSQL 可能更加适合我,大家怎么看?
从 13 年毕业开始就开始使用 MySQL ,当时不理解 DBA 把用户表分成了 100 张,后来在别人的一通解释下也渐渐理解了。
17 年自己开始作为主程负责一个新项目,当时因为把用户表分成 100 张还跟老板吵过架(因为当时另外一个项目的负责人本身就是个混混,还给老板一通乱说,弄的我特别郁闷,无奈自己当时的心理素质不是特别强大)。后来我也觉得 100 张表可能太多了,可能没有那么多用户,索性就只分了十张。
20 年新的项目,开始尝试使用 MongoDB ,经别人推荐,说 MongoDB 怎么适合游戏。当时觉得这东西好啊,但是在实际使用时,并不是那么美好。
24 年另外一个项目,负责人全部使用了 MongoDB ,但是用法相当暴力,也就是每次全量存储用户的数量到 MongoDB 中,感觉跟使用 MySQL 也没有什么实质性的区别。
今年负责另外一个项目时,最开始设计者将用户的 JSON 数据先进行 base64 encode ,然后异或加密存储到了 MySQL 中。因为最开始的客户端的设计是纯单机,后面加了服务器存储用户的存档而已。
新的需求是要将这个单机版本做成一个联网版本,因为我之前有将单机变成联网的成功经验(某合成游戏变成联网版本,国内流水过五亿)。
现在的存储结构没有规划过,JSON 结构下面有超过 200 个字段,活动配置占用超过了 90% 的存储以上,平均用户的存储占用在 100KB 以上。 存档中存储活动配置的原因:活动开启之后,则配置不再发生变化。
我重新设计了存储结构,使用 Protobuf 重新设计了数据存储,将活动配置数据跟游戏存档分离。活动配置单独存档在一张配置表,用户的存储中只记录对应的唯一 ID 。同时提供了接口,可能将旧的数据转换为新的 Protobuf 存储结构。
用户的数据存储中,使用 JSON 存储,存储的内容为 Protobuf 对应的 JSON 数据。用户更新数据时,提供了 FieldMask 仅修改部分数据(只前每次都是全量更新)。
当这个版本成功上线之后,我发现某些接口调用比较慢,例如在用户转换存档时,我将客户端提供的原始数据、转换之后的结果存储到了
conversion_logs配置表(数据类型均为 JSON ),内网的虚拟机上平均耗时为 200ms 。因为最近在研究 PostgreSQL ,索性就试了一下性能对比,结果 PG 只需要 20ms 左右。最关键的是,表空间存储的占用上,PG 远低于 MySQL ,因为 PG 存储使用的类型为 JSONB 。我尝试对比纯 TEXT 字段的记录时,PG 占用的空间也只有 MySQL 的 1/3 ,现在的数据表现就是在存储和插入速度 MySQL 远低于 PG 。更新的速度还没有完全验证。
SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(index_length / 1024 / 1024, 2) AS index_mb FROM information_schema.tables WHERE table_schema = 'merge_island' AND table_name IN ('conversion_logs','game_saves','activity_saves','activity_config'); +-----------------+----------+---------+----------+ | TABLE_NAME | total_mb | data_mb | index_mb | +-----------------+----------+---------+----------+ | activity_config | 216.83 | 209.55 | 7.28 | | activity_saves | 0.16 | 0.16 | 0.00 | | conversion_logs | 70.55 | 70.52 | 0.03 | | game_saves | 7.48 | 7.39 | 0.09 | +-----------------+----------+---------+----------+ SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total_size FROM pg_catalog.pg_statio_user_tables WHERE relname IN ('conversion_logs','game_saves','activity_saves','activity_config'); table_name | total_size -----------------+------------ activity_config | 32 MB activity_saves | 376 kB conversion_logs | 13 MB game_saves | 1976 kB另外把用户分为 100 张的操作在 PG 这里完全是反模式的,因为 PG 号称单表轻松过亿。另外十多年前的老设计本应该也要被淘汰了,毕竟现在都是云服务,空间存储可以轻松扩充,不用再担心这个问题。
有没有使用 PG 淘汰 MySQL 的大佬来分享一下自己的经历,一起学习哈。
作者: Rooger | 发布时间: 2025-12-27 02:54
13. Google 账号被停用是不是申诉也没用?
我怀疑是我手机号有毒,昨天更改了下密码,然后今天前面正常登入,后面跳出要手机号发个验证码验证,然后输入验证码后就给我停用了!!!
这 Google 账号敢用啊,直接给你封了。之前也封过一个,我这手机号就收了这俩账号的验证码,用了不到两年
作者: mingtdlb | 发布时间: 2025-12-27 06:55
14. Gemini cli 怎么样?
最近趁优惠,充了 Google one 的年包( https://one.google.com/ai-nye)
以前用的 Claude code ,很好用。
后来切换到 codex ,有点慢,但是也还凑合。
现在准备切换到 Google AI 了,不知道 Gemini CLI 怎么样,有没有 v 友分享一下。或者有没有什么办法用 Claude code 调用 Gemini 模型?
作者: ninjaJ | 发布时间: 2025-12-27 13:18
15. 求教一加 13 刷机后的 play integrity
最近把一加 13 解锁刷到 LineageOS 23, 在只安装 apatch 且不装任何 zygisk 或模块情况下,play integrity 的结果是”no integrity”
可是我的另外一个红米 note 12 turbo ,一模一样的设置,结果是 basic integrity.
想问下这个是我的设置有问题,还是传说中一加炸 tee 导致的呢?你们一加刷机后能保持 basic integrity 吗?
PS: basic integrity 对我来说够用了
作者: s82kd92l | 发布时间: 2025-12-27 11:21
16. 不喜欢 codex diff 的体验, 写了个 vscode diff 插件: diff tracker
Codex 的 diff 体验一直不顺手: 必须在独立面板里看 diff, 有时候 revert 甚至失败. 忍无可忍下, 写了一个新 vscode 插件解决这件事.
只要点一下 recording, 所有改动都会实时以 inline 形式呈现, 也支持双栏对比, 还能类似于 curosr 那样对局部改动进行 accept/revert.
这下 Codex 用起来舒服太多了
效果图:
Editor Inline View
Editor Inline View (hover effect)
Inline Review2 (read only)
Side-by-side diff
github 地址: https://github.com/wizyoung/DiffTracker
vscode marketplace: https://marketplace.visualstudio.com/items?itemName=Wizyoung.diff-tracker
openvsx marketplace: https://open-vsx.org/extension/Wizyoung/diff-tracker
一些局限: 因为 vscode 的 api 原因, 无法像第三方 cursor 那样, 在代码块右下角显示浮动的 accept/reject, 以及删除的 diff 下无法把删除前的内容以虚拟行的方式显示. 如有更好的方式望告知~
作者: frinstioAKL | 发布时间: 2025-12-27 13:28
17. 推荐一款中小互联网、物联网企业、独立开发者极低成本的数据化运营神器,各类指标,分分钟搞定!
推荐一款中小互联网、物联网企业、独立开发者极低成本的数据化运营神器,各类指标,分分钟搞定!
中小互联网企业、物联网企业、独立开发者想要监控线上业务或设备的运行指标,但苦于没有一个低成本的工具,今天就向大家推荐这一款软件神器:XL-LightHouse 。
它和市面上 BI 产品有比较大的差异,从技术方案上来说:BI 产品主要是通过 SQL 查询关系数据库、OLAP 等进行聚合运算获取数据指标,但 XL-LightHouse 不同,它是以”流式计算技术”为基础的指标获取工具。
那流式计算是什么东西呢?其实很容易理解,就是基于实时传入的数据流进行计算的技术,比如线上服务产生的各类日志、设备心跳包等都是典型的实时数据流,xl-lighthouse 就是基于这种实时的、源源不断的数据流进行计算的一款工具。
这个工具和 BI 产品相比,它有两个突出的优势就是:
- 1 、接入和计算流程更加简便、灵活,不依赖业务表,这在很多针对线上日志、设备心跳的指标计算场景会非常便利,因为不需要创建数据库、数据表、不需要存储和维护数据就能实时计算出各种指标了。
- 2 、它聚焦于解决繁杂业务场景下大批量数据指标的并行计算问题,可以用来计算各种各样的细粒度指标。
比如:app 的启动次数、每天的打开人数、app 启动耗时、某个页面打开次数、某个表单的提交人数、甚至某个按钮的点击次数、某个列表的点击率、某个接口的异常量和耗时情况、某个商品的点击加购次数等等。
总之就是:只要你有业务需要,XL-LightHouse 可以为你计算大批量的、各种各样的、零零散散的数据指标,这一点和 BI 产品区别比较大。BI 产品的计算逻辑是强依赖于业务表,对数据源要求比较苛刻,要计算某个指标必须要有相应的库表结构,而且字段还得比较工整、规范才可以。
很多企业买一套 BI 回来,可能发现它只能用分析订单表、商品表,但是如果你想看 app 启动、商品点击、搜藏、加购等相关指标数据就会有很大的局限性。而 xl-lighthouse 却可以遍布整个业务上下游链条,提供更全面的数据指标网络,这对于中小互联网企业、物联网类企业帮助非常大。
如何部署
这个项目支持单机版和大数据版,中小企业、独立开发者单机版本就足够了。
首先安装 docker 环境
这个网上搜索就行了,一大堆的资料,也可以参考这里: https://dtstep.com/docs/110156/
安装 xl-lighthouse
下载最新版的 Docker 部署安装包 (下载页面: https://dtstep.com/docs/110027/)
解压安装包
tar zxvf lighthouse-docker-x.x.x.tar.gz
进入项目目录,执行部署命令
cd lighthouse-docker-x.x.x/ #进入工程目录
cd scripts #进入脚本目录
./deploy.sh #执行部署命令,输入 yes 即可部署完之后,访问: http://x.x.x.x:8181 就可以访问系统页面了。
另外:在 scripts/example 下有一个演示工程,直接启动就可以在 web 端看到系统内置的一个演示工程和演示数据了。
如何接入
它提供 http 和 java 版本的 api ,根据自己情况选择,整体使用流程非常非常简单,文档几乎都不用看,就明白怎么回事了。
主要是几步操作:
- 创建统计工程、统计组
这个项目使用”统计工程-统计组-统计项”的三层结构管理所有数据指标,每个统计工程下可包含若干个数据指标,而基于同一份元数据的数据指标叫做一个统计组。 创建操作直接在 web 端就可以完成。
- 创建统计项
统计项的创建是按照它内置的格式指定指标的计算逻辑,也非常简单,一看就明白了。
- 数据接入
完成了以上创建之后,只要通过 http 或 java 上报原始消息既可以了,然后就能在 web 端查看数据指标的结果。
App 收款数据监控
下面通过一个小例子介绍它的整体使用。
比如我们 app 内有用户充值的操作,现在要计算 app 充值相关指标。
有这样几个需求:
+ 每 10 分钟 app 充值次数、充值人数、总充值金额 + 每小时 app 充值次数、充值人数、总充值金额 + 每天 app 充值次数、充值人数、总充值金额 + 每天 app 内各充值渠道的充值次数、充值人数、总充值金额 + 每天充值金额大于 100 元的充值次数和充值人数
创建统计工程
创建统计组(也就是一个类似于表结构的配置信息)
创建统计项
每个指标对应一个统计项,创建统计项遵循系统内置的 xl-formula 的配置格式。
![]()
然后通过 java 或 Http 进行数据接入就可以了
public class Test {
public static void main(String[] args) throws Exception{ LightHouse.init("10.206.6.27:4061"); long t = System.currentTimeMillis(); for(int i = 0;i<6032;i++){ //修改统计组参数值、Token 和秘钥 HashMap<String,Object> paramMap = new HashMap<>(); paramMap.put("user_id", RandomID.id(6)); paramMap.put("channel", RandomID.id(2)); Double d = ThreadLocalRandom.current().nextDouble(1000); paramMap.put("amount",String.format("%.3f", d));//防止上面随机数出现科学计数法 System.out.println("send message:" + JsonUtil.toJSONString(paramMap)); LightHouse.stat("Dc7:recharge_stat","dpDLFgP20zTvKqWddqOgm9ktjQDvzDE9GSVZZtIn",paramMap,t); } System.out.println("send ok."); }}
页面查看数据指标
作者: xueling | 发布时间: 2025-12-27 12:49
18. 从快手直播故障,看全景式业务监控势在必行!
近日,快手平台遭遇有组织的黑产攻击,大量直播间在短时间内被劫持用于传播违规内容。这一事件不仅造成了巨大的负面影响,更暴露了当前互联网平台在应对新型网络攻击时的脆弱性。在较长时间无法解决问题后,最终的解决方案竟然是完全关闭直播入口。我们在强烈谴责黑产违法犯罪行为的同时,行业必须清醒认识到:企业当前的防护模式,在面对高度规模化、组织化、自动化的“闪电战”时已力不从心,必须要对当前的防护体系进行全面升级。
本篇文章从技术层面阐述这一事件以及我对平台防护体系改进方案的个人观点,包括以下三方面内容:
- 1 、黑产的攻击链路;
- 2 、当前互联网平台防护体系现状;
- 3 、全景式业务监控势在必行;
黑产攻击的账号类型
由于平台尚没有详细披露本次被攻击的方式,我们只能从当前简单的陈述之中猜测黑产可能的攻击手法。
- 老账号被黑产部分盗取,并以老账号进行攻击;
攻击链路:钓鱼链接 → 获取老账号凭证 → 窃取有效会话 Token → 绕过二次验证 → 获取设备控制权 → 以”合法老用户”身份发起攻击。
- 黑产批量注册新账号,并绕过实名认证体系,以新账号进行攻击;
攻击链路:接码平台/卡商获取手机号 → 自动化脚本批量注册 → 伪造或绕过实名认证 → 养号(模拟正常行为)→ 等待时机发起攻击。
账号是攻击行为实施的载体,不同的账号类型攻击手法是不同的,产生的危害力也有差异:
一般来说,老账号拥有正常的注册时间、历史行为、社交关系、消费记录等,设备指纹和登录模式可能已通过平台信任白名单。风控系统会将其判定为“低风险用户”,极难触发警报,单个老账号攻击更具有迷惑性和危害性。不过黑产获取老账号凭证方式主要通过钓鱼链接、木马病毒或者撞库等手段实现,获取难度较高,账号数量规模应该不会太大。
而新账号没有历史行为、交易、社交关系等记录,历史评级很低,容易被系统风控方案判定为高风险账号,单个账号的攻击力相对较低。不过新账号攻击可能意味着黑产已经掌握了平台账号体系漏洞,而可以进行大批量注册形成规模化攻击,如果没有及时修补危害极大。
账号凭证是什么
账号凭证是一个广义的身份集合,包括登录账号(手机号/用户名)、密码(或其变种)、已登录态下的会话 Token/Cookie 、受信任设备指纹等信息。
什么叫伪造和绕过实名认证体系
现在企业广泛采用的实名认证体系是:用户首先提交身份证图片,然后打开手机,摄像头采集人脸视频信息,app 发出眨眼、张嘴等指令,在用户按指令进行上述操作后完成实名认证。
- 绕过实名认证体系
绕过实名认证体系也就是说黑产已经破解了当前平台认证接口的加密和签名验证等机制,可以直接发送”认证成功”这种篡改伪造的数据包到认证接口,从而绕过这一体系。
- 伪造实名认证体系
伪造实名认证体系是指黑产可以利用手机漏洞(比如:android 漏洞)在实名认证时直接注入预先准备好的人脸识别视频数据流。而这也意味着黑产已通过多种渠道获取到了大量的真实身份证图片,并根据上面的”照片”通过类似 deepfake 等技术手段预先生成眨眼、张嘴的认证视频片段。比如 App 发出”眨眼”的指令,就传入一个”眨眼”的视频片段,从而起到欺骗平台认证体系的作用。
伪造和绕过实名认证体系两者差异很大,修复漏洞的方式也截然不同。相对而言绕过实名认证体系对平台来说更容易修补,但如果黑产已经具备技术手段可以伪造实名认证体系,则潜在危害非常巨大,这就不在是一个互联网企业的问题而是所有互联网企业均要面对的问题。
黑产的攻击方式
流量劫持与内容注入
首先,介绍一下直播技术基本流程:
- 摄像头采集主播视频信息,将 1 桢的数据拆分成若干个数据包,每个数据包叫做一个 Chunk ,都包含 Key 、直播间 ID 、时间戳、设备指纹、IP 、视频流数据、加密验签信息、视频分辨率、码率等,将数据包压缩、编码后并上传到服务器;
- 只要开播,每个直播间的数据包( Chunk )会源源不断的上报;
- 服务端接收到 Chunk 进行转码并将连续数据包合并成视频片段;
- 所有直播间的视频片段汇总排队分发给审核机制;
- 视频片段首先经过 AI 机审进行违规信息检测评分,低于阈值直接放行,高于阈值则转入人审;
- 如果审核违规,则由审核人员进行封禁直播间的指令(当然也有自动化机制);
- 审核通过的视频片段则会放行,并再次转码为数据包并被用户拉取后看到;
上面是一个基本流程,真实环境中可能存在一些不同:
- 为了用户体验的流畅度,审核和分发流程也可能会并行处理;
- 由于人审的速度非常缓慢,在大量数据包积压时为了快速的完成当前的审核,审核人员也可能会”手动丢弃”积压的数据包;
- 平台账号体系会预先划分高风险、低风险账号,两类账号的审核逻辑略有差异;
在了解上面流程之后就知道黑产可针对多个环节通过不同的技术手段分别进行攻击。
什么叫做”预制违规视频”
这里的预制违规视频都是黑产特殊处理后的视频,而不是随便找的。也就说这些视频大多都是对”AI 机审大模型”有抗体的视频。黑产通过一些工具可以对视频的特征进行轻微调整,将原违规视频转化为”对抗性样本”,起到躲避被大模型识别的效果。
具体的攻击方式
黑产的攻击方式可分为多种,比如:
- 1 、攻击人员直接模拟平台推流协议将预制视频拆分成数据包上传,伪装成正常的数据包,这些数据包被 AI 大模型定义为低风险直接被放行;
- 2 、攻击人员可以前期探测出一个平台 AI 机审的大概阈值范围和人审的承载力,然后制作专门的视频造成人审的洪峰,从而直接压垮平台人审体系;
- 3 、攻击人员可以从技术层面绕开审核体系(不知道现行直播平台是否会有部分情况下无需审核的机制,而被黑产盗用,或者黑产使用老账号具有较高权重,无需严格审查);
- 4 、攻击人员可以间歇性发送”正常视频”和”违规视频”,大规模直播账号的正常视频可以压垮人审体系,另外也可以造成审核体系的错觉,获取基础信任,而通过对平台审核体系的承压探测,可以灵活调整违规视频的时长,比如 5 分钟的视频里面可能只有 10 秒钟是违规的,从而最大化攻击效果;
- 5 、攻击人员可以人为制造”举报”等核心接口的阻塞,从而让平台反馈体系失灵;
“肉鸡”的种类
由黑产直接控制的发动攻击的设备称为”肉鸡”,在移动互联网时代的肉鸡和 PC 时代的肉鸡已经有些不同。移动互联网时代的肉鸡可以分为多种:
- 1 、黑产直接控制了大量老账号原主人的手机设备(设备指纹和账号是完全绑定的,IP 地址非常分散,隐蔽性极高,难以被风控体系发现,但是控制原主人的手机非常困难,需要长期的”钓鱼”,控制成本极高,很难实现规模化攻击);
- 2 、黑产控制一批真实的设备农场,比如是从二手市场批量购买的廉价手机,这些设备是真实存在的,设备指纹等信息都完全真实(优势在于:设备完全真实,成本可控,可规模化部署,但 IP 地址一般相对集中、而且群体特征比较明显,相对容易被风控体系识别);
- 3 、黑产在服务器上批量部署 Android 模拟器,创建出来的虚拟设备(优势在于:成本很低,可规模化,但很多模拟器的设备指纹已经可以被识别出来);
- 4 、黑产控制一些不相干的用户手机,在手机内植入木马程序可以最小化、用户无感知的情况下运行 app 进行直播(优势在于:IP 地址非常分散,隐蔽性高,但同第一种一样控制成本比较高);
“肉鸡”的攻击形式
黑产通过中心化的系统来控制所有肉鸡,包括升级攻击脚本和下发指令。肉鸡的攻击形式可分为三种:
- 模拟真人操作进行攻击
也就是由脚本控制 app 的打开、关闭、处理弹窗、自动点击直播按钮进入直播页面,随后脚本将从摄像头采集视频改为推流协议直接上传。
- Hook 注入
Hook 注入是首先逆向破解 app 客户端内的代码执行逻辑,通过 Hook 技术手段直接侵入 app 进程之内,完全绕开 app 自身的 UI 逻辑,然后直接调用内部函数,通过篡改里面的参数传入实现违规视频的上传。
- 协议层请求
攻击者首先破解平台推流接口的加密验签逻辑,然后直接模拟 http 请求发送违规视频数据包。
一次完整网络攻击,会同时使用多种手段,而攻击者也可能在攻击前进行了数月的准备工作,也就是”养号”,在这期间会让账号进行正常的登录、浏览等操作,来让它的行为轨迹看起来很合理,从而提高账号的权重。
企业应该排查的优化点
应对网络攻击和网络攻击的溯源是多个部门互相协同的工作,而不仅是网安一个部门的职责,跨部门的协作、沟通、数据共享非常重要。
这一起网络攻击事件所需要排查的技术点和优化点很多,也都比较明显,比如几个相对重要的排查点:
- 推流接口协议的加密、验签逻辑的升级改造;
- 反馈等核心接口是否存在被人为阻塞和过载攻击的可能;
- 数据库中仍然可能存在潜在攻击者账号,如何进行辨别;
- 客户端是否存在被模拟真人操作的可能,需要增加必要的防护措施;
- 客户端代码是否存在被 Hook 注入的可能,需要提升代码混淆的等级以及增加必要的启动完整性校验等逻辑;
- 实名认证体系是否存在被绕过和伪造的可能;
- AI 机审的准确率提升;
- 账号等级的评估体系和风控体系所依赖特征是否足够广泛,特征的实时性是否满足需要; …
从”网络攻击事件”看企业数据化运营能力的不足和预警机制的缺失
这类网络攻击事件不仅暴露出企业自身防护体系的薄弱,更深层次地折射出企业在数据化运营能力和实时预警响应机制上的严重不足。其根本原因可归结为以下两点:
- 风控体系缺乏高质量的实时特征
风控系统所依赖的、能够准确反映“当前业务状态”的实时特征极为匮乏。这种“实时特征贫血”导致风控模型在面对新型或突发攻击时反应滞后、识别能力弱。此外,现有特征往往片面、零散,容易被黑产通过模式变异或一些技术手段欺骗。
- 缺乏跨部门、跨业务的实时协同指标,监控指标碎片化
网安团队在日常监控与应急响应中,缺少跨业务线、跨功能模块的“实时交叉指标”。没有这些全局性、关联性的数据指标作为决策依据,团队很难在攻击发生时快速定位问题根源,难以实现跨环节的联动防御。
全景式业务监控势在必行
什么是全景式业务监控
本文提出的全景式业务监控,是基于通用型流式大数据统计技术构建的新一代业务监控与预警体系。它突破了传统监控方案在实时性、覆盖面和关联分析上的局限,具备以下核心价值:
- 为管理层及决策者提供极高密度、多维度的实时业务指标体系;
- 为风控、账号等级评估等 AI 模型持续输送大批量、高质量、可关联的实时特征,提升模型训练的及时性与预测准确性;
- 实现从用户端到服务端、从业务触发到数据落盘的全链路可观测性。
相对而言,全景式业务监控更侧重于:全链路覆盖、多维度实时指标、跨系统数据关联和面向风控与决策的实时特征供给。
从一个简单业务场景看传统业务监控方案的不足
举一个例子:App 某页面有一个表单模块,表单提交后数据写入 DB ,我们要实时统计表单提交量,应该如何统计呢?
按照当前企业的做法毫无疑问是统计数据库的写入量。从业务逻辑层面来说这是完全没有问题的,但如果从业务监控的角度来说,假如这个业务较为重要,这种方案就存在着明显不足。
比如:
- 如何判断出数据是否存在接口被盗刷写入的可能呢?
- 如何判断出来后端接口是否响应正常,是否存在大量客户端请求异常的可能呢?
- 数据流转经过多个环节,如果线上出现数据异常等问题,如何快速的定位问题原因呢?
而更为规范的做法是:
- 客户端提交表单并上报日志,日志服务接收后消费日志进行数据统计;
- 后端接收请求后调用统计模块进行请求量统计;
- 后端服务在写入 DB 成功或失败后调用统计模块;
全景式业务监控提倡在一个业务的所有重要环节进行全链路监控,每个监控指标做到数据吻合。
从直播攻击场景,谈全景式业务监控的优势
网络攻击应急机制包括两个核心操作:1 、快速判断出黑产的攻击方式,2 、根据攻击方式的特征筛选出直播账号列表然后进行封禁。
全景式业务监控在这一过程中具有天然优势,比如:
- 协议破解与接口盗刷
这种攻击方式只要在 App 内推流数据包上传逻辑前添加监控埋点,并将埋点数据和推流接口的请求量数据进行比对,就可以明显判断出是否存在黑产盗刷接口的可能。而通过两方面的实时日志关联( App 埋点日志和接口服务日志)就可以快速初步筛选出黑产攻击账号列表。
- 肉鸡同时发动攻击
肉鸡为了击垮平台的”人审”体系,会在短时间内同时发起开播和推流,而这种操作也会形成前一刻和后一刻明显的流量异常,而通过关联两个时段的实时日志也可以初步筛选出攻击账号列表。
- 反馈接口过载攻击
反馈接口是否存在过载攻击,大多数情况下可以通过反馈接口服务监控埋点和 App 上报的反馈日志埋点进行对比分析,快速判断出过载攻击的可能,而且关联实时日志库可以提取攻击设备信息然后进行阻断。
从 App 启动、用户交互、开播按钮点击、推流接口调用、数据分发到内容审核,业务流程中充满各类细节与依赖。全景式业务监控旨在为企业构建一个“遍布全身”的实时指标感知网络,支持从整体业务层面到细分维度(如 App 版本、IP 段、设备指纹、直播间等)的立体化监控,全面提升企业对此类事件的应急响应能力。
通用型流式大数据技术介绍
目前之所以企业的”实时指标”和”实时特征”极为匮乏,根本原因在于指标获取所采用的技术方案仍然以:Flink 、Spark 、ClickHouse 、Doris..等技术实现,这些技术方案过于臃肿、笨重难以低成本、高效率的实现大批量实时指标。
而通用型流式大数据统计技术侧重于解决”大批量数据指标的并行计算问题”,擅长应对繁杂的实时指标计算场景,对于企业应急机制建立具有非常重要的实际意义。
可参考开源项目:xl-lighthouse ,开源地址: https://github.com/xl-xueling/xl-lighthouse
目前互联网大厂的数据指标数量可以达到 10 万
30 万个,而其中的实时指标数量更为匮乏,而通用型流式大数据统计技术可将大型企业数据指标数量提升到 1000 万3000 万个,帮助企业建立更完善的数据化运营体系,全方位提升企业对于紧急事件的应对能力!
作者: xueling | 发布时间: 2025-12-27 12:17
19. 安卓里面有没有那种非商业化的 9 格的输入法?
最近发现手机输入法打字候选词每次都要选,非常不智能。 但是每次新装输入法,感觉候选词功能都要好一些。 然后用上一些时间,又回去了。
然后电脑上是装的鼠须管,rime-ice 的词库,感觉还不错。 想着是不是能手机上也有类似的方式。
然后找了一圈发现有个同文输入法,然后发现输入法键盘不支持 9 格的。这个我年纪大了,不适应 26 格啊。 所以问问大佬们,安卓上有没有那种非商业化的支持 9 格那种。 要是能用上 rime 的词库,那就更好了。。。
作者: hefish | 发布时间: 2025-12-27 06:22
20. 有啥提供稳定可靠 TTS 的服务商?
自己有显卡跑 indextts2 ,但仅适用于自己玩玩。
想着有可靠的 indextts2 的服务商直接用他们的 api 来就方便了。
作者: ethusdt | 发布时间: 2025-12-27 04:39
21. 让 AI 带着镣铐跳舞
最近临时在帮朋友做一些外包,基本上代码都是 AI 写的,我想如果不是有 AI, 我大概不会帮这个忙,因为即使这些活不难,我还是要写很多代码。但现在,我可以一个人同时做 2-3 个项目。
在这个过程中,更加让我确定了对于程序员来说,软件开发的范式已经彻底彻底改变了。生成代码再也不是程序员「应该」做的事情,而是应该被放手给 AI 做的事。
这也让我对判断一个程序员的能力从代码能力转变成了使用 AI 的能力,我想,如果我现在要为团队招程序员,我会在面试时着重了解这个人如何使用 AI 完成一个需求。
对于程序员来说,「使用 AI 的能力」包含很多维度,这些维度综合起来,才决定 AI 是否真正能成为程序员的杠杆:
对业务的理解
软件是为解决用户的需求而生的,对业务充分理解,才能给 AI 足够的业务场景上下文,才能让 AI 写出覆盖边界条件的代码。
对业务的理解同时决定了程序员是否可以做好数据库建模。在接我朋友的外包项目时,我发现我人工干预最多的就是数据库建模。只要我思考好建模,AI 就能基于这个数据库模型编写任何接口。
对技术栈的理解
如果能让 AI 限定在特定的技术栈中,你会发现 AI 更能稳定发挥,更可控。让 AI 「带着镣铐跳舞」。无论用什么技术栈,重点都是给 AI 一条稳定的轨道。比如我在所有项目的 AGENT.md 中都会列出非常细节的选型,例如 CC Mate 的 https://github.com/djyde/ccmate/blob/main/CLAUDE.md
当 AI 知道技术栈后,通过 context7 这样的 MCP, 它能在生成代码时,找到对应的文档作为上下文,生成出更不容易出错的代码。换句话说,确定好技术栈,让 AI 成为这个技术栈的专家为你编写代码。
因此,在这个层面,程序员的「使用 AI 的能力」意味着,这个程序员知道什么样的场景适合什么样的技术栈,也侧面反映了这个程序员对技术社区是否保持敏锐的嗅觉。这是我认为 AI 时代程序员的一种硬实力。
对架构的理解
在《代码之外》听友线下见面会中,有听友提问,在 vibe coding 的时候,AI 只能做些一次性的软件,多次迭代后就会变成灾难。我的回答是,这是因为没有给 AI 提供一个你设计好的工程架构,让他在这个架构中行动。在这个新的时代,程序员应该以架构师的角度来工作。
我在 AI coding 一个项目前,我的脑海里会大概有一个工程架构的设计,比如,通用工具应该被统一放到一个什么文件,前端页面应该如何组织,接口应该遵循什么样的规范,错误处理应该怎么做等等。只要架构设计好,写在 AGENT.md 中,AI 自然会按照你的设计去做,而不是让 AI 天马行空地发挥。
不仅是在启动这个项目前要做好架构的思考,在维护的过程中,你指挥 AI 完成一个新的需求时,就应该思考完成这个需求的时候,将会有什么代码被写在哪一个地方。这个场景也适合使用各个 AI coding agent 的 Plan Mode 来完成,当 AI 告诉你它将要如何行动时,适当二次确认它要如何组织新的代码。
做到以上三个理解,我相信程序员可以游刃有余地使用 AI. 但我曾经在很多场合接触一些在一线写代码的程序员,发现他们对 AI 的接受程度是如此地低。很大程度上,我认为是一个缺乏以上三个理解的程序员,很难对 AI 建立信任关系,合作关系。
和我合作的一位程序员,在共同完成一个需求的时候,我在他旁边观察了一下他如何使用 AI, 结果只是非常浅地使用 auto complete. 我问他,为什么不尝试让 AI 完整地完成这个需求,他表示他认为 AI 不能胜任这个任务。
我说:
- 我的后端接口已经写好了,而且有了 openapi 的 YAML 文件( AI 生成的)
- 你知道这个需求涉及前端的哪个页面,在前端项目中,也有对数据请求层进行封装( AI 一定能知道怎么写数据请求)
满足了这两个条件,你只需要把接口文档给 AI, 然后告诉 AI 这次的需求,再告诉 AI 一点提示,大概是在哪个文件中修改。以现在旗舰模型的能力,AI 大概率能一次性完成。
他将信将疑,我直接在他电脑上给他演示这个操作,果然,AI 直接完美地完成了这个需求,不到 2 分钟。
而同时我也在思考,到底 AI 时代是否还需要程序员,或说需要怎样的程序员,好像渐渐有了答案。
作者: djyde | 发布时间: 2025-12-27 05:46
22. 求助 prompt 样例搜集
我在设计一套 prompt 在不同模型里面迁移适配的方案,大概流程是原 prompt -> 中间件 -> 新模型可用的 prompt ,旨在减少迁移模型时的适配工作。
现在需要有原始 prompt 输入并进行验证,用 gemini 和 gpt 生成了几套尝试了一下,发现效果并不稳定。
所以求助大家,如果大家有现在正在稳定使用的 prompt ,可以将在用的模型+prompt 内容分享给我吗?
如果这套方案最终可行,我会再返回一个针对在用模型的新 prompt ,验证一下效果
感谢~
作者: ikooma | 发布时间: 2025-12-27 04:35
23. 我是不是有病啊?
AI 说话很有礼貌,我跟 AI 也有礼貌
作者: red13 | 发布时间: 2025-12-27 11:26
24. win11 defender 如何不卡 Python 启动运行
现象就是我一个小项目,每次机器启动之后首次 第二次 或者 1 小时后运行 这个 python 程序,都会卡 10 多秒出来启动菜单(我的 python 程序有启动菜单来选执行某个功能)
作者: admirez | 发布时间: 2025-12-26 23:40
25. immich 有备份还是炸了
1 系统备份 pg 到文件,默认只保留最近 15 次备份文件
- 2 数据备份用的 sync ,会同步删除( DB 备份被删除,无法恢复)
作者: mintongcn | 发布时间: 2025-12-26 12:13
26. 今天 AntiGravity 登录不上了
起来发现 AntiGravity 登录不上,换账号换 vpn 都不行,妈的😓
作者: tt83 | 发布时间: 2025-12-27 01:54
27. sublimetext 开发 GO 使用体验怎么样
一直使用 vs code 开发 go,主要搞 web ,最近体验了一下 sublime-text ,发现这个曾经流行的开发工具对 GO 的支持很一般,插件还是很多年前的,是不是我不会配置,有没大神使用 ST 开发?
作者: siesta | 发布时间: 2025-12-26 15:49
28. 学习能力不是很强 现在需要学 py 有什么好的推荐吗?
fastapi 框架。 很明确了就是要学这个。
原来是 phper ,后来一直搞数据库 服务器了…
py 需要从哪里入手,就是希望找一些获得比较实用的学习资料的捷径 推荐一下书籍 博主之类的。
要带娃 实在是没有太多的时间 感激不尽!!!
作者: gyinbj | 发布时间: 2025-12-26 16:55
29. 有必要把内网服务开放到公网吗?
我现有方案是开放到公网,在纠结要不要切换会内网,通过 Tailscale 访问。
作者: mssi | 发布时间: 2025-12-26 01:18
30. 千万不要开 anti-gravity 的全自动模式
写个接口修改 mongodb 的测试密码,改了几下,忘记密码了,又尝试了几下。结果给哦重装 mongodb ,说时迟那时快,直接干掉了我的 k8s 里面的 mongodb deployment 。。。。
这要是生产,我就可以打包回家了。
作者: clacf | 发布时间: 2025-12-26 09:03
31. AI 时代的开发哲学:如何用“最小工程代价”实现快速交付?
很多开发者在转型做 AI 应用时,容易陷入“重度开发”的思维定式:从选型后端框架、搭建数据库,到手写前端交互逻辑。但在 AI Native 应用的语境下,核心竞争力在于 Prompt 的调优和业务逻辑的闭环,而非基础组件的重复实现。 要想快,就得学会给开发工作“瘦身”。
- 架构逻辑的“去中心化” 传统的应用开发是“功能驱动”,而 AI 应用是“流程驱动”。 现在的趋势是采用 Serverless + LLM API + 轻量化前端 的架构。后端不再需要复杂的微服务,而是作为一个“管道”,负责处理 API Key 的安全隔离、上下文( Context )的简单存储以及 Stream 流的转发。把重逻辑交给模型,把交互交给组件,是 2 天内上线的先决条件。
- UI 范式的统一:从 GUI 转向 LUI 过去我们要为每一个功能设计复杂的菜单、按钮和表单( GUI )。但在 AI 时代,交互界面高度统一为了对话框( LUI )。 这种转变对开发者其实是极大的利好:你不再需要为每个页面单独设计 UI 。一个标准化的、支持多模态输入(语音、文件、图片)的聊天界面,就能承载 90% 的业务需求。这种“界面标准化”是提升交付速度的关键。
- 跨端能力的“降维打击” 如果你想验证一个 AI 产品的市场反应,只做 Web 端是不够的,移动端的即时性更符合 AI 助手的定位。 但从头开发 iOS 、Android 和 H5 的成本太高。利用小程序容器技术或跨端组件库,实现“一套代码,多端复用”,是独立开发者和小团队快速切入市场的捷径。
- 警惕“细节陷阱” 很多项目卡在最后 20% 的进度上,比如: 如何让对话界面在不同尺寸的手机上都不变形? 如何处理语音输入时的降噪和波形显示? 如何让生成的代码块在移动端也能完美高亮且支持一键复制? 这些细节非常耗费工时,但又直接决定了产品的“商业卖相”。 选对工具,就是省掉一个前端团队 如果你正在尝试快速上线一个 AI 原型,我建议不要在 UI 细节上过度消耗精力。 我近期在做的几个 Demo ,底层 UI 框架都直接切到了 FinClip Chatkit 。它的逻辑非常符合“快速交付”的原则: 把“工程坑”当成标准品: 它把我们上一篇提到的流式渲染、自动滚动、键盘适配等细节全部做成了默认配置。你不需要写一行 CSS ,就能得到一个媲美原生体验的对话界面。 天然的跨端基因: 因为它是针对 FinClip 生态设计的,你可以非常轻松地把 AI 能力集成到现有的 App 里,或者发布成小程序。这种“插件化”的集成方式,比重构整个 App 效率高出几个数量级。 适配多模型生态: 无论是接入 OpenAI 、Claude 还是国内的文心一言、通义千问,它在前端的数据解析层做了很好的抽象,换个模型只需改几行配置。 结语 在 AI 浪潮下,“先上线,再迭代” 比“闭门造车”更重要。开发者的时间非常值钱,不应该浪费在反复调试对话框的高度和字节流的乱码上。 利用像 FinClip Chatkit 这样的生产力工具,把 80% 的通用交互交给成熟的方案,把剩下的 20% 精力花在打磨产品的核心价值上,这才是 2025 年开发者应有的工程观。
作者: FinClip | 发布时间: 2025-12-26 10:16
32. [万字长文] 效率就是一切:并行计算如何重塑 AI 训练与现代应用
这三个看似无关的问题,背后藏着同一条主线:无状态 → 并行计算 。
本文分三部分:
- 并行已经重塑了什么 ——云计算和 AI 训练的成熟实践
- 推理为什么还是串行的 ——自回归生成和思维链到底是怎么回事
- 推理并行化的探索方向 ——从学术思路到前沿框架
…
从云计算到 AI 推理,一文看懂并行计算的底层逻辑
从云计算到 AI 训练,从游戏架构到智能工作流,**”解耦”与”并行”的思维模式**正在改变整个技术世界。
这不仅是 AI 时代的效率密码,更是构建一切可扩展系统的底层逻辑。
在微信支付的复盘中,一个影响开发效率十分高频的词就是**”等待”**。
想想你手头最慢的那段流程——不管是写代码、写文档、做运营,还是其他什么——慢在”计算”,还是慢在”等待别人/等待上一步”?你能把哪一段改成自包含?
并行的本质不是”同时做很多事”,而是”让每件事都不需要等别人”。
无状态不是没有状态,而是把状态交给别人保管,自己轻装上阵。
自包含是解耦的终极形态:我只需要知道”做什么”,不需要知道”来龙去脉”。
作者: xiaoshu | 发布时间: 2025-12-26 03:24
33. gmail 支持修改邮箱用户名,大概什么时候会全面开放?
https://support.google.com/accounts/answer/19870
想要新用户名,但又不想注册新账号,因为新账号可能风控更高。
如果全面开放的话就可以解决这个问题了,目前还没有全面开放,不知道还要等多久。
作者: zictos | 发布时间: 2025-12-25 16:08
34. 前端样式请教
有大佬知道 https://antfu.me/posts blogs 的这种花纹是怎么做的吗?
作者: karashoukpan | 发布时间: 2025-12-26 15:22
35. AWS 的控制台打开巨慢,有没有大佬知道什么原因?
Chrome 浏览器每次想登录 AWS 控制台都巨慢,一直转圈圈,转几分钟才能加载出来,尝试过换网络,VPN 开全局,换浏览器,都无解。
作者: notejava | 发布时间: 2025-12-26 13:01
36. 有什么办法彻底把视频号从微信禁用了,发现页关闭了,公众号信息流还能刷到,总是忍不住刷 app 还没发卸载
作者: CathayChen | 发布时间: 2025-12-26 06:05
37. 有偿请教大佬, android 后台导航问题
android app 需求:用户无感知导航,也就是后台导航,无页面导航但又需要获取到实时导航的界面截图,可以理解为进入高德导航界面后,通过技术手段隐藏掉该 activity ,但又要截图他的 bitmap
无平台限制,高德,百度,华为,能实现均可
本人尝试了几个方案: 1.集成高德导航后,开启导航,会有新的导航 activity 打开,并且无法隐藏,哪怕再 theme 里设置了透明也无效 2.先不说隐藏的问题,直接对该界面截图,发现底层地图是黑底,可能 sdk 做了一些限制,但系统截屏则正常
作者: kimiler | 发布时间: 2025-12-26 07:37
38. “快手直播事件”引发的技术思考
先来看下,近几年大厂发生的几个影响较大的运营事故:
这几起事件的共同点:影响范围广、故障时间长、造成非常负面的舆论影响;
这次快手的事情,还是远远超出了我的想象,服务故障只会影响正常使用,但是被攻击进而导致了大面积非法活动 ;对于监管来说,没有比这更严重的事情,属于妥妥的红线 。
为什么会发生
黑客、灰产,从互联网诞生之初,就一直存在,今天我们不去讨论黑客如何操作大规模账号、如何进行的实名认证,我们从开发这个角度去考虑,怎样去避免事件的发生?
直播和视频播放不一样,它的内容属于实时产生,平台没有办法提前审核;因此直播平台建设怎样的审核机制,就关系平台能否控制用户的直播内容。
大部分直播审核机制我们可以简化为上图:截取画面、音频等,通过模型自动化判定,然后再人工复审,最后处罚封禁。
瓶颈节点
在开发中,我们经常会提一个瓶颈节点的概念,意味着它决定着整个链路的承载量,如果它停止工作,则整个链路瘫痪。
而在上面的审核链路中,可以认为人工复审是一个瓶颈节点,因为人力是有限的;也许平时只需要 1000 个审核员既可以应对,但是当极端情况出现,同时涌现出上万个甚至更多非法直播时,这套机制自然就被攻破了。
我们可以猜测,黑客操作大量账号,同时开启非法直播,当部分账号被封禁后,又不停的新增非法账号直播,人工复审节点一直处于过载状态,没办法处理全部的审核。
可能的解决方式
假设我们按照上图的审核机制,怎样优化可以解决同时出现大量非法直播的问题呢?
自动判定节点
根据模型分析结果,辅助额外账号信息,自动判定是否需要“二次人工复审”,对于不需要的案例,直接处罚。当然自动判定存在误判的风险,而快手这次事件,可以看到大部分直播是常规的淫秽视频,通过模型辅助账号信息是可以精确判定的。
为了让自动判定足够精确,我们需要做些什么?
- 模型不断训练更加精准
- 收集更多维度信息,账号活跃度、登录 ip 、设备等等风控数据
目的
减轻“人工复审”节点的压力,使它不再是瓶颈节点,是我们的最终目的,毕竟其他节点都可以通过扩容的方式解决。也许自动判定可能会存在误判的情形,但是我们可以不断优化,不断减少误判的概率。
思考
小概率事件
对快手而言,“同时出现大规模非法直播”是一个小概率事件,在它们设计审核机制时,可能也有考虑到过?但是可能认为“几万人同时直播黄片”是几乎不可能出现的事情 ,因此并没有做预案。
在互联网领域,尤其是后端模块,海量用户+长时间运行,任何小概率 bug 都演变成必然触发 ;如果没有完美解决方案,则往往可以采取有损的妥协折中方案。
欢迎快手同学现身说法!
最后宣传下自己的技术公众号:欢迎关注,讨论交流
![]()
作者: youngxxx | 发布时间: 2025-12-25 07:07
39. 我用 NestJS 结合 YJS 实现了一个工作流协同编辑的 Demo,方便想学习 YJS 协同的朋友
这两天使用 NestJs 结合 YJS 实现了一个工作流协同的 DEMO ,前后端协同方法都是使用 y-protocol 的方法自定义实现的,对于想学习 YJS 有很大的帮助,感兴趣可以对源码进行学习。
源码地址:FlowSync
本项目是 DocFlow 项目协同编辑功能的基础实现示例。如果你想学习更完整的协同编辑解决方案(包括富文本编辑、权限管理、AI 集成等企业级功能),请访问 DocFlow 项目。
💬 联系作者: 如有问题或想深入交流,欢迎添加作者微信
yunmz777
作者: moment082 | 发布时间: 2025-12-26 08:29
40. 猫猫自托管方案分享
底层基建
我目前使用Dokploy作为底层应用。所有容器都部署在这个上面,此前用的是 EasyPanel 一款闭源的产品。替换他的目的就是因为他很多功能都是需要付费的,而且由于不开源,也不能贡献什么。
用这些的目的呢,其实也很简单,就是懒,上面有很多现成的模板和做好的备份方案,相比于自己管理日志简单的多。
Dokploy 是一个开源的轻量级 PaaS 平台,定位上可以视作 Vercel / Netlify 的自托管替代方案。
主要特性:
- 支持 Docker / Docker Compose
- Git 自动部署
- 自动 HTTPS / SSL
- 内置备份与回滚机制
- 资源占用低,部署简单
相关文章:写过一些教程,可以看看
CDN
我使用的是 Cloudflare CDN + Zero Trust
统一接入 Cloudflare CDN , 部分私有访问的借用 Cloudflare Zero Trust 实现:
- 内网服务安全暴露
- 服务隐藏与访问控制
备份
这里我使用 HostBrr 的 7 美元一年 500G 的存储盒(通过 SFTP/rsync 定时同步)和 Cloudflare R2 结合备份。
邮局
NameCrane
NameCrane 提供域名邮箱服务,20 刀 3 年 的套餐性价比很高,支持自定义域名收发邮件。
相当的经济实惠,还支持每小时 300 封的邮件投递,投递速度比较慢。
短链接
S.EE
S.EE 兽兽短链接服务,终身 55 刀 买断。自己搭短链接服务太麻烦,这个价格买个省心。
应用
这里有很多,这里就不在这里一个个展示了。
有兴趣可以去我博客看看。
作者: sayyiku | 发布时间: 2025-12-26 01:22









)











