每条内容都有自己的编号了

前阵子，一个接入群历 API 的 AI agent 在干活：读任务链接，自动把处理结果写成评论。它从任务 URL 里抄下数字，调用评论接口——结果评论出现在了另一条毫不相干的内容下面，还通知了那条内容的关注者。

排查下来，没有人写错代码。问题出在我们身上：群历里有两套长得一模一样的数字——任务有自己的编号（#1042），每条内容又各有一个全局 ID。人看到链接会读上下文，agent 只会忠实地把数字抄进 API。抄对了位置是巧合，抄错了位置就串台。

数字本身不携带任何信息，这是隐患的根源。所以我们做了一次彻底的升级。

每条内容一个编号

现在，群历里所有内容都有一个带类型前缀的编号：

前缀加数字，团队内唯一。看到 T1042 就知道是任务，看到 D203 就知道是文档。大小写不敏感，带不带 # 都能识别。

之前只有任务有编号，现在这套系统覆盖了一切。

每条内容的网址现在是 qunli.co/<团队>/<编号>，比如：

qunli.co/2025/T15750

短到可以在会上口头念给同事。更重要的是，这个链接永久有效：内容从一个项目转移到另一个项目，链接不变。以前的网址里带着项目路径，内容一转移，旧链接就断了；现在编号跟着内容走，链接永远指向它。

所有历史链接依然可用，收藏夹和旧文档里的链接不受影响。

在搜索框输入 #1042、T1042 或 #T1042，直接命中那条内容。同事说"看一下 T1042"，你搜一下就到。

这次升级最重要的原则是：你在网页 URL 里看到的编号，可以原样抄进 API 路径。

给任务 T1042 发评论：

POST /api/v1/accounts/:account_id/recordings/T1042/comments

拿到一个编号但不知道它是什么？一个接口解决：

GET /api/v1/accounts/:account_id/recordings/T1042

它返回这条内容的完整信息——是任务就带任务字段，是邮件就带邮件字段。

因为编号带着类型，抄错位置的编号不会再命中别的内容，只会得到一个明确的 404。评论接口也加了防呆：往一条评论上再发评论、把回复挂到别的讨论串下面，都会被直接拒绝，而不是悄悄落到错误的地方。

这些规则都写进了 API 文档——agent 接入时自己就能读懂，不需要人在旁边解释。

越来越多的 API 调用来自 AI agent，而不是人手写的代码。agent 的特点是：给它清晰的规则，它就极其可靠；留下模糊的空间，它就会在你想不到的地方出错。

带前缀的编号，对人来说更好读、好搜、好口头传达；对 agent 来说消除了歧义。这不是巧合——对人清晰的设计，往往也是对机器清晰的设计。