在做的项目，每个一条：做了什么 + 一个关键决策。
2026 世界杯预测器,上线在 wcelo.com。核心是三个模型叠起来:用 Elo 评级衡量球队强弱,用 Dixon-Coles 模型建进球数分布(它对足球的低比分、以及强弱悬殊时的修正,比普通泊松更贴实际),再用蒙特卡洛把 495 场对阵各模拟几十万次,汇成每支球队的晋级和夺冠概率。
但它对我更像一个现场实验,而不是预测产品。开赛前预注册了三个命题,最想验的一个是:让大模型(LLM)读球队资料去预测,到底能不能赢过纯统计模型?为了不作弊,评分规则在开赛前就用代码写死、预测也在开赛前冻结,赛中每天由定时任务拉赛果更新。
先把评判标准和预测都锁死,再让比赛来判分——这样赛后就没有替自己找补的空间。
A 股一套、加密一套,信号系统各自为战久了,就想把它们收进一个统一平台——opsignal。
做架构设计时,我给自己定的核心判断是:先立骨架和契约(contract),而不是先堆因子。 平台的价值不在于它有多少个策略,而在于任何一个策略都能以同样的方式接进来、被同样地验证、被同样地投影出去。
几个关键决策:
多语言多仓:不同市场、不同团队用不同语言实现,平台只约定接口,不强求统一技术栈。
PublicSignal 脱敏投影:对外暴露的信号是内部信号的一个脱敏投影(projection),原始逻辑和参数留在里面,外面只看到结论。
verify 是硬门槛:一个信号要上平台,必须先过一致性验证——不是「跑起来了」,而是「离线和在线算出来一样」。
平台化最容易犯的错是先做花活(fancy 的策略),后补地基。我选择反过来:地基和契约先立死,策略再往上长。
YC Watcher 是一个追踪 Y Combinator 公司动向的全栈应用:抓取、翻译、按关注推送。技术栈是 Next.js + Auth.js v5(认证)+ Resend(邮件),几个模块都踩得很实。
认证做了两条腿:邮箱魔法链接(Resend)+ 以太坊钱包登录(SIWE,Sign-In with Ethereum),外加 ENS(以太坊域名)显示。SIWE 这条踩到两个协议级细节,单独记一下:
地址必须做 EIP-55 混合大小写校验和(checksum),不能只做小写比较,否则合法地址会被判非法。
SIWE 消息体走的是 ABNF 文法,对 ASCII 有洁癖——夹一个非 ASCII 字符就解析失败。这类坑,错误信息通常不直接告诉你是大小写还是编码问题,得回去啃规范。
通知是扇出(fan-out)+ 邮件摘要(digest):关注变动先扇出到各订阅者,再按人聚合成一封 digest。中间还接了大模型做翻译子系统,踩过 Qwen 思考模式必须关、空字符串死循环这些坑。
一个全栈小项目,认证 / 通知 / 翻译三块各有各的深坑,恰好把「现代 Web 应用的地雷分布」摸了一遍。
tt.hn 跑在开源博客引擎 Jant 上,Docker 自托管在阿里云,数据库是 SQLite,数据完全自己掌控。
选 Jant 而不是传统博客,是因为它的内容模型更省心:不逼你「憋长文」,而是 Note(随手写)/ Link(转发带评注)/ Quote(摘录)三种轻量格式,用 Thread 追一个课题、用 Collection 做分类。它还带 HTTP API 和 MCP,所以开篇这些内容是直接调 API 灌进来的,不是手敲——发布走脚本而不是后台手填,内容因此可以版本化、可批量、可复现。
它也刻意不做社交:没有关注者、点赞、算法信息流,也没有评论。别人「关注」的方式是 RSS。对个人档案来说,这种安静反而是特性。
