讲讲

Yes

Shopify 老板在开源模型上也跑成功了 Reason Act： https://twitter.com/tobi/status/1640788727243874312

我的两个 idea 没了，都被 openai 做掉了

我有一个 idea

https://llm4.dev/ 可以免费用

适合小的 commit，有时候想 commit 很费事，aicm 一下很方便

另外一个就是最好留一个注入 prompt 的接口，比如在~/.aicm 里加自己的定制 prompt，“我想要每个 commit message 带一个 emoji”之类的

嗯 选 N，再 copy 也是可以的

提个需求，比如这个生成的 message 不符合预期，我要编辑一下或者加 prompt 去掉前面部分，可以实现吗

不错

后台的搜索其实不需要全文检索，只需要 like 匹配，再加个索引就可以了，pg 的 like 是可以加索引的

不错

界面可以 内容不太行

👍

还没有

上了 hackernews 首页 https://twitter.com/Hooopo/status/1606398282628227072?t=QO_Rm8sOuzwykzqHesckiw&s=19

https://hashids.org/ 就是你指定一个 salt，就可以把你的整数 ID 暴露给客户端一个类似 youtube 格式的 id。查询之前再通过 salt 反向解析回整数 id。

数据库多机部署就是想的有点多了，真到那个规模你有很多种分布式数据库或中间件可以选。。

自增加 hashid

不错 写了个笔记 https://db4.dev/postgres-b-plus-tree-structure-note/

wish

优的地方在于顺序，mysql 的聚集索引是按主键顺序排好序的，而 pg 的是堆表，无序，在范围查询会有差异 比如 where id > 1000

有时间我可以详细写篇博客

我觉得你可以找个 graphql 的 demo 玩一下，看你的描述效果是一样的

graphql？

hashid

是

• pg 的主键和二级索引是没有区别的，都直接指向磁盘的一个位置
• mysql innodb 的主键和二级索引是有区别的，通过二级索引查询先找到主键，主键再找磁盘位置；二级索引上是会冗余主键值的。

所以 mysql 在主键查询场景优于 pg；pg 在二级索引查询场景优于 mysql

1. UUID + MySQL 的话，数据迁移是灾难，虽然数据迁移的概率很低，但估计要比迁移到分布式数据库发生的概率高很多
2. UUID + InnoDB 索引膨胀，因为 InnoDB 的二级索引是指向主键的，就是多一条二级索引就膨胀一些，当然还有 buffer pool 和磁盘之类一定也膨胀

所以选不选 uuid 是一个技术层面的需求，和你使用具体的 DB 直接相关。而业务相关的需求完全可以通过其他手段解决，比如 https://github.com/namick/obfuscate_id 你完全可以使用 bigint，然后暴露给外部 string，再反向解析回来。退一步讲，真的有分布式需求或者客户端同步需求，从 bigint 往 UUID 迁移也是容易的。

https://ossinsight.io/collections/web-framework/trends/?historical-trending=pr-creators&historical-rankings=pr-creators&bar-chart-race=pr-creators

从 PR 和 Contributer 角度看 rails 还是第一

流量多少可以收这么多