电脑上的豆包输入法感觉非常慢，而手机上的非常快。所以我在想能不能用手机作为语音输入端，然后把输出的内容同步到电脑上？
我的设想是，在手机上有一个 APP，带有文本框，可以用豆包输入法输入文本。然后这个 APP 可以实时将文本传到电脑上，并自动复制进电脑的剪贴板。这样我只需要在手机上说好一段话，然后在电脑上按一下 Ctrl V 就可以了。
甚至进一步，如果有什么工具可以让手机端的文本框实时传到电脑上，并实时输入到目前电脑光标所在的文本框，就更好了。
由于涉及到电脑和手机的配对，所以最好不要每次开机都要重新配对一下，尽可能每次开机都自动配对。

项目简介
腾讯元宝口令红包活动持续一周了，互刷口令太繁琐了，于是我写了这个口令互助池，大家可以：

上传自己的口令，分享给他人
随机获取别人的口令，领取红包
自动爬虫从贴吧采集口令（24小时不间断）

核心理念：我为人人，人人为我 
这时候发布确实是有些晚了，但说不定明年可以旧瓶装新酒。

 在线体验
已部署地址：http://111.229.5.230:18080/

 无需注册登录
 完全匿名使用
 实时更新口令池


 Github地址
地址：GitHub - Vhfuhv/YuanBao-Share: 一个简单匿名的腾讯元宝红包口令分享平台。上传你的口令，获取他人的口令，一起分享好运！

 功能特性
1. 智能口令分发

优先级机制：优先分发用户上传的口令，爬虫口令作为补充
IP过滤：不会获取到自己上传的口令
防重复：每个口令最多被展示3次（符合元宝规则）

2. 自动爬虫系统

双策略爬取：

方案1：每30分钟爬取指定帖子的最新口令
方案2：每1小时爬取元宝吧首页前10个帖子


时间过滤：只采集20分钟内的新口令
智能清理：每小时清理过期口令，每天0点重置

3. 用户体验

一键复制：点击即可复制口令
报告无效：发现无效口令可直接删除
实时统计：显示当前可用口令数量
限流保护：防止滥用（每分钟最多获取20次）


 碎碎念
抽了几天下班后的时间总是完成了。
我也不知道百度什么时候又会抽风，给我加个安全验证。总之，我尽力解决吧。
感谢@Xeron的前端支持。

咋回事儿啊佬友们，有人知道没

大家好，我想请教一个问题。我在使用 Codex 输入时，经常是按 Control + Space，但随后删除时往往会一下子删掉一大片内容。相比之下，Claude 就很正常，删除时只删一个词或词组。我想知道，有没有办法让 Codex 也采用这种类似 Claude Code 的分词（删除）方式？

他们在官网中，宣布将使用全新商标Logo，日后将不再使用 Western Digital，请叫它WD。与此同时，WD将会启用全新的商标 Logo，象征公司在运营、财务和战略层面的转型。当中也提到说，在日常沟通中人们很习惯将 Western Digital 称为 WD，甚至连员工也只会说在WD上班。

好用的app 好看的~

找 Claude code Max 一块拼车的，有没有一起要拼的，还有位置

近日看了几部动态漫，放空大脑，代入主角，发现还是挺上头的，回顾后，发现这些视频大多数源自于网络小说或者漫画，得益于现在的AI，帮助到了业内人员，动态漫愈来愈多。
由于以往我接触网络文学（小说/漫画）比较少，继而我好奇，大家平日里是否阅读过什么网络小说，都是以什么渠道下载/看的网络小说，有没有什么推荐作品？
最后通过我最近看的几部作一个简单观感分享:
我看的几个作品无一不是让我感受到了主角的“爽”，若自己代入主角的世界，我会很想看下去，究竟会发生什么。
无论是借助于系统还是借助于主角的天赋，开挂也好，暴富也好，其所有内容都是与日常生活的平淡所不一样，有的还融合了推理、校园生活、冒险、奇幻修仙战斗等要素，有的作品对角色的塑造十分细腻，进而让我十分向往那个世界并成为那个主角，再加上剧情的反转，所以几个小时沉迷其中就在所难免了。
不过可惜的是，许多网络小说的内容十分长，我看的几个视频都是10-20个小时，我感觉已经很长了，但是似乎原作小说的进度还未过半，看久了就容易发现视频后续套路都相似，缺少那种惊喜感。
若让我认真思考回忆其剧情、框架，我估计已经记不住太多，甚至可能1天前看的内容都忘得差不多了，不过要是有对的上自己兴趣的主题，花几个小时当一回视频里的主角，也不失为一种放松的选择

除了chatgpt team和pro会员，还有什么方法可以使用chatgpt pro吗

之前写了一篇关于这方面方案的咨询，如何通过摄像头画面判断是否有人靠近
但是感觉都差强人意一些，于是经过几天的现场实测，采用了这样的方案
物理设备：固定机位的摄像头，无测距功能，放置在自助xx机器身上，桌面环境或周边
现场环境：酒店大堂，普通商店，亦或是路边街道
需求：对路过有意向从而靠近机器的行人进行欢迎语播报和介绍
实机部署方案：采用face_detection_yunet_2023mar模型进行人脸识别，频率为每0.5秒检测一次，当第一次检测到人脸时，需持续至2.5秒后仍能检测到，则视为有效顾客，播报欢迎语。当连续十秒未能检测到人脸后，则重置状态
相对于行人检测的优点来说，yunet模型适配性好，并且速度很快，误检率极低，在低画质摄像头上的表现非常好，通过人脸朝向更能精准捕捉到意向客人，同时，由于人脸大小较为均匀，亦可通过对检测到的人脸矩形框面积进行模糊的距离判定，可在一定程度上控制播报时机
还有什么可精进的欢迎补充讨论

接触Ai这么久了,慢慢的涉及到境外支付的问题，好多地方银联都不支持而且感觉特别麻烦 ，有佬友推荐搞一个虚拟钱包，我自己去看了一下YouTube和b站上很多教程，目前来看很多博主推荐欧易，币安，Bitget，这几个平台较多，所以我想请问各位见多识广的佬友们，就单纯的当个支付工具用最好是推荐哪个平台呢 ！

项目背景
由于业务需求，团队需处理海量的电子文档。单个表单涉及的 PDF 数量通常在 1000 至 5000 份不等。自 2025 年 12 月启动知识库项目以来，我们在几个月的实战中遇到了以下瓶颈：

超长文档解析难：部分文档页数过多，解析速度极慢，且极易触发内存溢出（OOM）。
工程图纸识别精度低：项目中包含大量工程图纸，通用解析工具常将其误识别为普通图片，导致要素提取缺失或严重失真。
多格式兼容性差：用户上传的文件涵盖 PDF、图片、CAD 及 Office 办公文档。虽然 PDF 解析相对成熟，但对于超多列的复杂 Excel 表单，解析效果堪称“灾难”。
深度问答可靠性不足：对于高难度的逻辑推理问答，单纯依赖通用 LLM 的语义检索往往难以达到业务精度要求。
其他长尾问题：如离线部署环境下的资源分配、响应延迟等。


选型调研与避坑指南
考虑到研发周期，我们优先对市面主流的开源 RAG 框架进行了评测，以下是各产品的实测反馈：
1. RAGFlow
地位：RAG 领域的重量级框架。
核心优势：

多租户架构：具备完善的团队/租户权限管理。
工作流编排：支持灵活的问答流程定制。
DeepDoc：其自研的解析神器，是目前对复杂文档适配度较高的方案之一。

实测痛点：

精度与性能平衡：面对复杂图纸时要素遗漏较多。CPU 模式解析极慢，GPU 模式虽有提升但仍非实时；且由于是内部框架，二次开发门槛较高。
OCR 适配：第三方 OCR 引擎接入尚处于实验阶段，底层仍高度依赖内置引擎。
幻觉问题：纯向量检索难以应对结构化查询，需引入 MCP（Model Context Protocol）结合 SQL 查询来增强。

开源协议：Apache License 2.0。
2. Dify
地位：生态最丰富、上手门槛最低的 RAG 平台。
核心优势：极其出色的流程编排与插件功能，支持外挂 RAGFlow 知识库。
实测痛点：

知识库“偏科”：Dify 的核心在于 Agent 编排，其自带的文档切割与索引功能相对基础。虽可通过插件强化，但需投入额外开发精力。

商业限制（需留意）：

其修改版的 Apache 2.0 协议规定：禁止未经授权运营多租户 SaaS；必须保留 UI 标识。
结论：若需多租户或深度去标识化商用，必须通过 API 接入自研前端。

3. Yuxi-Know（语析）
特点：界面友好，符合国人逻辑。
实测痛点：OCR 引擎对接方案较为生涩，虽然选项多，但实际落地效果不佳，更适合处理中短篇幅的简单文档。
开源协议：MIT（极度友好）。
4. Weknora (腾讯)
特点：模块化架构，融合多模态预处理，大厂出品。
实测痛点：OCR 引擎内聚程度过高，几乎无法灵活切换或自定义识别逻辑，改造难度大。
开源协议：MIT。
5. AnythingLLM
特点：功能全家桶，内置 TTS/STT，开箱即用体验好。
实测痛点：OCR 依旧是短板，面对专业领域的重度文档显得力不从心。
开源协议：MIT。

核心痛点汇总

OCR 解析能力的“资源与精度”悖论：在离线部署的有限硬件資源下，难以同时满足“高速度”与“高精度”的解析需求。
混合检索与统计分析缺失：业务问答不只是语义匹配，往往涉及大量数据库统计（Chat2SQL）。纯 RAG 方案在处理这类问题时容易“抓瞎”。


OCR 专项分析




方案
优点
缺点
适用场景




MinerU
结构化还原（Markdown）效果好，支持 VLM 模式。
内存开销极大（3000页PDF可达100G+），离线部署资源成本极高。
对精度有极致要求的离线单任务。


DeepDoc
适配广，针对 RAG 场景优化。
复杂图纸易遗漏，解析效率随页数增加线性变慢。
通用文档解析。


Paddle/Rapid
部署轻量，GPU/CPU 兼容性好。
缺乏对文档版面还原（Layout Analysis）的深度支持。
简单文字识别。


VLM/大模型类
逻辑理解能力最强。
成本高、受限于上下文窗口，难以处理千页以上的超长文档。
关键要素精准抽提。




总结与反思
目前项目处于“深水区”：通用框架在面对工业级、超长、复杂版面文档时，均出现了明显的边际效应。
下一步我们可能需要跳出“全盘依赖开源框架”的思维：

解耦解析层：建立独立的 OCR 解析集群，将长文档切片并行处理，并引入 VLM 进行关键要素校准。
强化 MCP 架构：不再强求 LLM 读懂整个 Excel，而是通过 Agent 调用 SQL 插件进行数据分析。