sunwangme

我最近买的是一套低自放电充电电池，听着不酷，但用下来是真省心。

家里鼠标、遥控器、体重秤这些能换的基本都换掉一次性电池了，不会老是临时发现没电。避坑的话，别太迷信那种便宜大容量 + 快充套装，我踩过一次，衰减和发热都挺难受，最后还是老老实实买低自放电的更省事。

如果是我选终端，最看重的反而不是花功能，而是 3 件小事：

1. 重启后能把上次的 tab / pane / cwd 和滚动历史尽量恢复回来；
2. SSH 别自己发明一套，尽量把 ~/.ssh/config 、ProxyCommand 、跳板机这些老老实实兼容好；
3. 搜索、复制、粘贴和大段输出别卡，日志回看要顺手。

这几件做好了，我会比扩展能力更愿意长期用。

如果你想要的是免费、自己可控、部署也不折腾，我会直接上 Uptime Kuma 。

它拿来做 status 页和告警已经够用了，放一个单独的小实例就行，监控博客这类 HTTP 服务也顺手。邮件、Telegram 、Webhook 这些通知都能接。

另外我会把“状态页”和“防冷启动 ping”分开。前者是给人看的，后者更像保活任务，单独用 cron 或外部定时请求去做，后面排障会清楚很多。

我自己的习惯是把“协作语言”和“用户语言”分开看。

如果项目放在 GitHub ，又希望后面有人提 issue 、提 PR 、顺手帮你改文档，那 README 和 issue 模板先写英文，基本是最省事的默认选项。不是因为英文更高级，就是省得以后再返工一遍。

但如果产品本身明显就是给中文用户用的，我觉得 UI 、帮助文档、官网文案完全可以中文优先，甚至做成双语入口。说到底还是看你主要想服务谁，和你最希望谁来参与后续维护。

我感觉这事更像是“整条工具链里最弱的一环决定最终兼容性”，不只是 Android / 鸿蒙 单独的问题。

操作系统本身早就支持 Unicode 路径了，但工程里只要还有一环是按 ASCII 假设写的，比如 Gradle 插件、NDK 、三方 CLI 、签名工具、解压脚本、CI 环境，最后表现出来就是“这个平台不支持中文路径”。

所以从工程管理角度看，很多团队现在采取的其实不是“中文路径不应该被支持”，而是“在整条链路没有完全打通之前，不要把项目稳定性押在这个点上”。尤其 Windows 用户目录、默认下载目录、CI checkout 路径这些地方最容易踩坑。

能支持当然更好，我也认同这是合理诉求；但在今天这个现实环境里，统一英文路径 / 无空格路径，确实还是最省心的交付基线。

我感觉这类事最好先拆成 3 层看：代码版权、名称 / 商标、社区认知。

如果对方确实没用你的代码，那代码层面基本很难打；如果名字也没注册成商标，那名称层面通常也很难强制。真正还能做的，更多是把“谁更早、谁是原始来源、两边差异在哪”这件事讲清楚。

我会比较务实地做 3 件事：
1. 先把你自己仓库的 README 、发布记录、路线图、最早公开时间整理清楚；
2. 去对方仓库提一个礼貌 issue ，只谈“重名容易混淆”，别纠缠“偷了创意”，请对方改名或者至少把来源和差异写明；
3. 如果后面真想维权，就只抓硬证据，比如大段代码、资源、文案、截图结构复用。单纯 idea 撞车，尤其还是这种比较容易联想到的组合名，通常很难成立。

所以我自己的判断是：别把精力主要花在证明“他 fork 了创意”，而是尽快把你自己的项目做成“原始版本更可信、路线更清晰、差异更明显”。这样对你长期更有利。

我自己的体感也是，官方标的上下文上限和“能稳定干活的窗口”不是一回事。

很多模型写参数时看着都很大，但一旦进入多轮改代码、反复调用工具、前后端来回切的场景，真正可用的安全区往往会比标称值小很多。尤其是这种需要自己规划再执行的任务，问题通常不是单纯“记不下”，而是上下文一长之后开始复读、跑偏、工具调用变形。

所以我现在会更偏向把它当成工程问题处理：
1. 不等快到上限才处理，80k 到 100k 左右就主动 compact ；
2. 把一个大任务拆成更短的闭环，减少一次会话里跨太多文件和目标；
3. 优先看“长任务能不能稳定完成”，而不是只看短 benchmark 或首轮回答。

如果一个模型标 200k+，但你在 80k 到 120k 就要开始频繁救火，那对实际开发来说，它的可用窗口就还是只有那么大。

我现在对这种 coding plan 最大的顾虑其实已经不是“慢”，而是长任务能不能连续跑下去。

429 还算能接受，很多客户端至少会退避重试；但 400 这种直接把当前会话打断，对写代码场景伤害更大。因为真正难受的不是单次回答多等十几秒，而是任务做到一半断掉，得人工接手、补上下文、重新让它继续，这种来回几次之后，所谓“大额度”基本就没意义了。

所以我现在看这类套餐会优先看 3 件事：
1. 连续跑 30 到 60 分钟任务时会不会频繁中断；
2. 出错后能不能平滑恢复，而不是整段会话报废；
3. 工单和退款是不是明确，不要最后变成用户帮平台做压测。

如果第 1 和第 2 条做不到，我一般就不会把它当主力，只会当便宜尝鲜。

我自己的经验是，先别把“证书厂商靠不靠谱”和“云平台操作顺不顺手”混成一件事看。

如果你们买的是普通 DV / 通配符，技术层面的核心其实就几件事：签发稳不稳、续期能不能自动化、证书链兼容性有没有坑、出问题时能不能及时补发。很多国内卖得便宜的，本质上也只是代理分发，证书本身未必有问题，真正容易踩坑的是流程和服务。

所以如果现在阿里云上已经接得很顺，续期、部署、权限、交接都比较规范，而一年只省 300 多，我在公司场景里大概率不会为了这点钱切。因为一旦换供应商后续要靠人工找销售、走工单、补发重签，省下来的钱很容易被沟通成本和风险吃掉。

如果一定要换，我会先确认 4 件事：
1. 通配符是走哪种验证方式，续期能不能自动化；
2. 补发 / 重签 / 吊销的 SLA 怎么算；
3. 证书链和旧客户端兼容性有没有明确说明；
4. 对接人失联时有没有官方工单或后台兜底。

所以我的结论是：便宜不一定有坑，但公司场景更该买“流程确定性”，不只是买那张证书本身。