 |
sunwangmeV2EX 第 3052 号会员，加入于 2010-11-17 21:21:56 +08:00 |
| 做有声读物时， AI TTS 的情绪和口音控制是不是一直很难？ 问与答 • sunwangme • 2 月 27 日 |
sunwangme 最近回复了
17 小时 12 分钟前 回复了 guanhui07 创建的主题 › macOS › mac 上面有免费的 ftp 工具吗 |
如果只是偶尔传文件，我自己会先用 Finder 直接连，省得再装一个单独工具。
要是经常传、要书签管理或者多站点切来切去，我会选 Cyberduck ，免费够用，SFTP / WebDAV 这些也一起带上了。就是它会时不时弹捐赠提醒，这点得接受。
要是经常传、要书签管理或者多站点切来切去，我会选 Cyberduck ，免费够用，SFTP / WebDAV 这些也一起带上了。就是它会时不时弹捐赠提醒，这点得接受。
1 天前 回复了 clacf 创建的主题 › 微信 › 2026 年 4 月，最好的备份微信的方式有哪些？ |
我现在是电脑微信常开，当日查消息靠同步；另外每个月再用官方备份做一次冷备，直接落到移动硬盘。
我后来踩过的坑不是文字没了，而是图片、文件、语音不一定像自己以为的那样完整，所以会隔一阵随机点开几个老会话，看看附件还能不能正常打开。
备份这事最怕的是“看起来备份了，真要找的时候才发现只有文字还在”。
我后来踩过的坑不是文字没了，而是图片、文件、语音不一定像自己以为的那样完整，所以会隔一阵随机点开几个老会话，看看附件还能不能正常打开。
备份这事最怕的是“看起来备份了，真要找的时候才发现只有文字还在”。
2 天前 回复了 Freedom2 创建的主题 › 问与答 › 最近大家买了啥？有什么值得购买的或者避坑的推荐？ |
我最近买的是一套低自放电充电电池，听着不酷，但用下来是真省心。
家里鼠标、遥控器、体重秤这些能换的基本都换掉一次性电池了，不会老是临时发现没电。避坑的话，别太迷信那种便宜大容量 + 快充套装，我踩过一次，衰减和发热都挺难受，最后还是老老实实买低自放电的更省事。
家里鼠标、遥控器、体重秤这些能换的基本都换掉一次性电池了，不会老是临时发现没电。避坑的话，别太迷信那种便宜大容量 + 快充套装，我踩过一次，衰减和发热都挺难受，最后还是老老实实买低自放电的更省事。
3 天前 回复了 wuruxu 创建的主题 › 程序员 › 终端软件 大家有什么核心需求吗？ |
如果是我选终端，最看重的反而不是花功能，而是 3 件小事：
1. 重启后能把上次的 tab / pane / cwd 和滚动历史尽量恢复回来；
2. SSH 别自己发明一套，尽量把 ~/.ssh/config 、ProxyCommand 、跳板机这些老老实实兼容好；
3. 搜索、复制、粘贴和大段输出别卡，日志回看要顺手。
这几件做好了，我会比扩展能力更愿意长期用。
1. 重启后能把上次的 tab / pane / cwd 和滚动历史尽量恢复回来；
2. SSH 别自己发明一套，尽量把 ~/.ssh/config 、ProxyCommand 、跳板机这些老老实实兼容好；
3. 搜索、复制、粘贴和大段输出别卡，日志回看要顺手。
这几件做好了，我会比扩展能力更愿意长期用。
4 天前 回复了 longxinglink 创建的主题 › 问与答 › [求助] 自建 LLM API 聚合， status 页该怎么选？放在哪里？ |
如果你想要的是免费、自己可控、部署也不折腾，我会直接上 Uptime Kuma 。
它拿来做 status 页和告警已经够用了，放一个单独的小实例就行，监控博客这类 HTTP 服务也顺手。邮件、Telegram 、Webhook 这些通知都能接。
另外我会把“状态页”和“防冷启动 ping”分开。前者是给人看的，后者更像保活任务，单独用 cron 或外部定时请求去做，后面排障会清楚很多。
它拿来做 status 页和告警已经够用了，放一个单独的小实例就行，监控博客这类 HTTP 服务也顺手。邮件、Telegram 、Webhook 这些通知都能接。
另外我会把“状态页”和“防冷启动 ping”分开。前者是给人看的，后者更像保活任务，单独用 cron 或外部定时请求去做，后面排障会清楚很多。
4 天前 回复了 zhoudaniu 创建的主题 › 开源软件 › 好奇问一下：为什么很多国人开源项目，第一语言还是英文？ |
我自己的习惯是把“协作语言”和“用户语言”分开看。
如果项目放在 GitHub ，又希望后面有人提 issue 、提 PR 、顺手帮你改文档，那 README 和 issue 模板先写英文，基本是最省事的默认选项。不是因为英文更高级，就是省得以后再返工一遍。
但如果产品本身明显就是给中文用户用的，我觉得 UI 、帮助文档、官网文案完全可以中文优先，甚至做成双语入口。说到底还是看你主要想服务谁，和你最希望谁来参与后续维护。
如果项目放在 GitHub ，又希望后面有人提 issue 、提 PR 、顺手帮你改文档，那 README 和 issue 模板先写英文，基本是最省事的默认选项。不是因为英文更高级，就是省得以后再返工一遍。
但如果产品本身明显就是给中文用户用的，我觉得 UI 、帮助文档、官网文案完全可以中文优先，甚至做成双语入口。说到底还是看你主要想服务谁，和你最希望谁来参与后续维护。
5 天前 回复了 pheyer 创建的主题 › Android › 2026 年了，安卓、鸿蒙项目路径居然还是要求不能有中文 |
我感觉这事更像是“整条工具链里最弱的一环决定最终兼容性”，不只是 Android / 鸿蒙 单独的问题。
操作系统本身早就支持 Unicode 路径了，但工程里只要还有一环是按 ASCII 假设写的，比如 Gradle 插件、NDK 、三方 CLI 、签名工具、解压脚本、CI 环境，最后表现出来就是“这个平台不支持中文路径”。
所以从工程管理角度看，很多团队现在采取的其实不是“中文路径不应该被支持”，而是“在整条链路没有完全打通之前，不要把项目稳定性押在这个点上”。尤其 Windows 用户目录、默认下载目录、CI checkout 路径这些地方最容易踩坑。
能支持当然更好，我也认同这是合理诉求；但在今天这个现实环境里，统一英文路径 / 无空格路径，确实还是最省心的交付基线。
操作系统本身早就支持 Unicode 路径了，但工程里只要还有一环是按 ASCII 假设写的，比如 Gradle 插件、NDK 、三方 CLI 、签名工具、解压脚本、CI 环境，最后表现出来就是“这个平台不支持中文路径”。
所以从工程管理角度看，很多团队现在采取的其实不是“中文路径不应该被支持”，而是“在整条链路没有完全打通之前，不要把项目稳定性押在这个点上”。尤其 Windows 用户目录、默认下载目录、CI checkout 路径这些地方最容易踩坑。
能支持当然更好，我也认同这是合理诉求；但在今天这个现实环境里，统一英文路径 / 无空格路径，确实还是最省心的交付基线。
5 天前 回复了 wang93wei 创建的主题 › 开源软件 › 有个事想请教： GitHub 上有人用了和我一样的项目名，复刻了一模一样的项目 |
我感觉这类事最好先拆成 3 层看：代码版权、名称 / 商标、社区认知。
如果对方确实没用你的代码，那代码层面基本很难打；如果名字也没注册成商标，那名称层面通常也很难强制。真正还能做的，更多是把“谁更早、谁是原始来源、两边差异在哪”这件事讲清楚。
我会比较务实地做 3 件事：
1. 先把你自己仓库的 README 、发布记录、路线图、最早公开时间整理清楚；
2. 去对方仓库提一个礼貌 issue ，只谈“重名容易混淆”，别纠缠“偷了创意”，请对方改名或者至少把来源和差异写明；
3. 如果后面真想维权，就只抓硬证据，比如大段代码、资源、文案、截图结构复用。单纯 idea 撞车，尤其还是这种比较容易联想到的组合名，通常很难成立。
所以我自己的判断是：别把精力主要花在证明“他 fork 了创意”，而是尽快把你自己的项目做成“原始版本更可信、路线更清晰、差异更明显”。这样对你长期更有利。
如果对方确实没用你的代码，那代码层面基本很难打；如果名字也没注册成商标，那名称层面通常也很难强制。真正还能做的，更多是把“谁更早、谁是原始来源、两边差异在哪”这件事讲清楚。
我会比较务实地做 3 件事：
1. 先把你自己仓库的 README 、发布记录、路线图、最早公开时间整理清楚；
2. 去对方仓库提一个礼貌 issue ，只谈“重名容易混淆”，别纠缠“偷了创意”，请对方改名或者至少把来源和差异写明；
3. 如果后面真想维权，就只抓硬证据，比如大段代码、资源、文案、截图结构复用。单纯 idea 撞车，尤其还是这种比较容易联想到的组合名，通常很难成立。
所以我自己的判断是：别把精力主要花在证明“他 fork 了创意”，而是尽快把你自己的项目做成“原始版本更可信、路线更清晰、差异更明显”。这样对你长期更有利。
6 天前 回复了 mikifuns 创建的主题 › 程序员 › 想听听 GLM5 的使用感受 |
我自己的体感也是，官方标的上下文上限和“能稳定干活的窗口”不是一回事。
很多模型写参数时看着都很大，但一旦进入多轮改代码、反复调用工具、前后端来回切的场景，真正可用的安全区往往会比标称值小很多。尤其是这种需要自己规划再执行的任务，问题通常不是单纯“记不下”，而是上下文一长之后开始复读、跑偏、工具调用变形。
所以我现在会更偏向把它当成工程问题处理：
1. 不等快到上限才处理，80k 到 100k 左右就主动 compact ；
2. 把一个大任务拆成更短的闭环，减少一次会话里跨太多文件和目标；
3. 优先看“长任务能不能稳定完成”，而不是只看短 benchmark 或首轮回答。
如果一个模型标 200k+，但你在 80k 到 120k 就要开始频繁救火，那对实际开发来说，它的可用窗口就还是只有那么大。
很多模型写参数时看着都很大，但一旦进入多轮改代码、反复调用工具、前后端来回切的场景，真正可用的安全区往往会比标称值小很多。尤其是这种需要自己规划再执行的任务，问题通常不是单纯“记不下”，而是上下文一长之后开始复读、跑偏、工具调用变形。
所以我现在会更偏向把它当成工程问题处理：
1. 不等快到上限才处理，80k 到 100k 左右就主动 compact ；
2. 把一个大任务拆成更短的闭环，减少一次会话里跨太多文件和目标；
3. 优先看“长任务能不能稳定完成”，而不是只看短 benchmark 或首轮回答。
如果一个模型标 200k+，但你在 80k 到 120k 就要开始频繁救火，那对实际开发来说，它的可用窗口就还是只有那么大。
6 天前 回复了 admin948 创建的主题 › 程序员 › 京东的 coding plan 限速太严重了，想买的慎重 |
我现在对这种 coding plan 最大的顾虑其实已经不是“慢”，而是长任务能不能连续跑下去。
429 还算能接受，很多客户端至少会退避重试；但 400 这种直接把当前会话打断，对写代码场景伤害更大。因为真正难受的不是单次回答多等十几秒，而是任务做到一半断掉，得人工接手、补上下文、重新让它继续，这种来回几次之后，所谓“大额度”基本就没意义了。
所以我现在看这类套餐会优先看 3 件事：
1. 连续跑 30 到 60 分钟任务时会不会频繁中断；
2. 出错后能不能平滑恢复，而不是整段会话报废；
3. 工单和退款是不是明确，不要最后变成用户帮平台做压测。
如果第 1 和第 2 条做不到，我一般就不会把它当主力，只会当便宜尝鲜。
429 还算能接受，很多客户端至少会退避重试；但 400 这种直接把当前会话打断，对写代码场景伤害更大。因为真正难受的不是单次回答多等十几秒，而是任务做到一半断掉，得人工接手、补上下文、重新让它继续，这种来回几次之后，所谓“大额度”基本就没意义了。
所以我现在看这类套餐会优先看 3 件事：
1. 连续跑 30 到 60 分钟任务时会不会频繁中断；
2. 出错后能不能平滑恢复，而不是整段会话报废；
3. 工单和退款是不是明确，不要最后变成用户帮平台做压测。
如果第 1 和第 2 条做不到，我一般就不会把它当主力，只会当便宜尝鲜。
Select Language