· 2 min read
游牧周记第74期
· 5 min read
开发
Polymarket改版
- pUSD取代之前的代币 要先convert,然后看api
- api升级v2 幸好之前就升级了,直接就可以用; (AI让我检查funder address是否也变了,我发现没有,api直接生效。)
- older API问题来了 在读取行情方面都ok,但在下单时报错older version啥的,其实很明确,就是让codex查一下官方文档修改,为了节省GPT-5.5的tokens,做这种容易出错的修改,我都先去chatGpt用thinking分析一遍,然后让它给一适合AI处理用的说明文档,然后再到Codex把文档交给api来处理。
Tauri自己有图标生成命令
处理多个不同尺寸app图标一直是难题,我请AI做了个1024的icon,之前一般去线上找在线生成器。 现在发现Tauri自带此功能:
pnpm tauri icon ./poly-flux.png
连android/ios图标都一口气处理好了,这生态友好度似乎超过expo啊。
Caddy是啥?如何实现免费TLS
最近云服务器上的一个服务要求https和wss,证书必须要,AI提醒 只要有域名都好办,正好我有;然后它就建议了Caddy这个服务,并且帮我搞定了,我请ChatGPT介绍一下这个东西:
**Caddy** 是一个用 Go 写的 Web Server / 反向代理 / TLS 终止器,定位有点像 **Nginx + 自动 HTTPS**。它最大的特点是:默认启用 HTTPS,并自动申请、配置、续期 TLS 证书。
官方文档说明:Caddy 默认会对站点启用 HTTPS;对公网域名,它会通过 ACME 协议从 Let’s Encrypt 或 ZeroSSL 这类公开 CA 获取证书;对 `localhost`、内网域名、IP 等,它可以使用本地自签 CA。([Caddy Web Server](https://caddyserver.com/docs/automatic-https?utm_source=chatgpt.com "Automatic HTTPS — Caddy Documentation"))
游牧周记第73期
· 2 min read
开发
即使有AI,也要先把核心功能先打通
这个教训太沉痛了。 折腾了几个星期,多少不同LLM的额度都用完了,之后没那么好的价格了。 一个Tauri项目,本来自己就不会rust,还先搭建完善框架,UI,然后才慢慢推进到核心功能,光mock就耗费了一半精力,最后落地测试,根本不是那么回事,关键点都没搞明白。 AI也不会主动帮你想明白的。 哎,累死了。 都想放弃。 流程要反着来。 superpowers那玩意真的没必要,自己先从第一性原理出发,把核心功能调通才是关键。 人需要及时的正反馈,不然会陷入忧郁。

Polymarket api有些讲究
坑好多,比如说:
- 有地区限制,我换到日本ip就好了。
- 据说对ip纯净度有要求,还没看出来。
- limit限价下单,share数量不能小于5,总额不能小于1usdc。
- 有时买单会部分成交,卖单似乎要准确的shares数。
- 有个手续费问题,基本是1%?成交了才收。
- api中有个时间服务器校正问题,需要随时取,约-0.4秒。
- 动态slug的timestamp可以估算出来,gemini教的。
- 注意WebSocket和https api的使用场景选择。
- 各种apikey和address的配置,很折腾。
- SDK据说效能不高,AI都推荐自己写代码调用Api,但它们自己会参考官方开源sdk的写法。
- api文档貌似丰富,但文字说明很不清楚。
游牧周记第72期
· 4 min read
游牧周记第71期
· 6 min read
开发
date-fns日期库替代Dayjs
在我基本所有项目中使用的轻量高效好用的Dayjs,已经n年了,实在找不出它有任何缺点。不过既然有新的了,我们请AI对比一下。 根据搜索结果,我为你整理出 date-fns vs dayjs 的全面对比表格:
核心对比表
| 维度 | date-fns | dayjs |
|---|---|---|
| 架构先进性 | 函数式编程,纯函数设计 | 面向对象,链式调用 API |
| 包体积 | 按需导入 <3KB (单函数仅1-2KB) | 核心2-7KB,插件累加 |
| Tree-shaking | ✅ 原生完美支持 | ✅ 支持,但核心整体导入 |
| 运行时性能 | 更快 | 快,略逊于 date-fns |
| API 风格 | 函数式:format(date, 'yyyy-MM-dd') | 链式:dayjs().format() |
| Moment 兼容 | ❌ 不兼容 | ✅ API 几乎完全一致 |
| TypeScript | 内置支持 | 内置支持 |
| 国际化 | 80+ 语言,模块化导入 | 需插件,语言包较小 |
| 时区支持 | 需 date-fns-tz 扩展 | 需插件,功能有限 |
| 生态活跃度 | 活跃,周下载量高 | 更活跃,周下载量 29M+ |
| 学习成本 | 中等(函数式思维) | 极低(Moment 用户零成本) |
关键差异总结
| 场景 | 推荐选择 |
|---|---|
| 极致体积控制 | date-fns(按需导入最小) |
| Moment 迁移 | dayjs(无缝切换) |
| 函数式/模块化项目 | date-fns |
| 快速原型/简单需求 | dayjs |
| 复杂日期运算 | date-fns(功能更完整) |
| 高频操作性能敏感 | date-fns |
一句话结论
- date-fns:先进、性能更好、体积最小(按需),适合现代模块化项目
- dayjs:上手最快、Moment 替代品,适合快速开发和迁移场景
两者都碾压 Moment.js,选谁都不踩坑,看团队技术栈偏好。
哈哈,都在提Moment.js不知道这个如何了? 我觉得国际化的方便性可能是个选择关键点,在下一个Tauri项目中使用了。

