队列也是产品的一部分
一个被接受的点子，需要一个公开的去处。这周我们把产品里的点子入口连到了 accepted ideas 队列，投稿流程因此有了看得见的后半段：人们可以看到哪些点子正在考虑、哪些还在推进、哪些已经上线。这不是每条被接受的点子都会被构建的承诺，而是不把队列藏起来的承诺。
我是做这套系统交付一侧的开发者，所以这个区别对我很重要。投稿从站点开始，但它不该在一张自动生成的回执之后就失去踪影。审稿人接受它之后，点子会拥有一个公开的工作载体；队列要做的，是让这个载体变得看得懂。
“接受”之后的空白
公开列表出现以前，这条流程中间有一段尴尬的空白。访客可以提交点子，也会拿到一张回执，然后等待系统决定它的去向。回执回答了一个重要问题——系统有没有收到我写的东西？——却没有回答下一个问题：这个点子有没有变成工作？
被接受的点子其实已经是一条 GitHub issue。审稿人用 external-request 标签创建它，并把原始投稿、审稿理由和验收标准保存在 issue 正文里。缺的只是找到这些 issue 的路。工作已经存在，产品却没有指向它。
所以，PR #128 虽然没有新增任何数据存储，仍然是一次产品改动。现在两个点子入口都链接到经过 external-request 筛选的视图：说明页接住正在考虑要不要投稿的人，表单接住已经开始输入的人。无论从哪里进入，点一下就能抵达同一条公开队列。
一条 issue 不只是一个结论
这个队列有用，是因为一条被接受的 issue 不只是一盏绿灯，它还是一条带着轨迹的记录。原始点子仍然可见；审稿理由说明它为什么通过；验收标准说明“完成”应该是什么样。交付 agent 还要把 raw report 打磨成有依据的工作，所以这条 issue 也把边界说清楚了：接受代表进入考虑队列，不代表一定上线。
当工作可见时，这条边界更容易理解。私下交接很容易把好几个状态压成一种模糊的“有人在看”。公开 issue 可以保留问题，而不用假装问题已经解决。队列表达的是：它通过了入口闸门，剩下的仍然是交付工作。
不另造一套状态系统
公开列表不需要另做一个 dashboard。GitHub 已经有第一版公开视图所需的状态。一个仍然 open 的 accepted issue，代表它还在排队或构建；一个 closed 的 issue，代表它已经交付。链接旁的文案也只说这些：open 表示正在构建，closed 表示已经上线。
这是一个克制的选择，却让状态更诚实。我们不把 issue 状态复制到 D1，不发明第二条生命周期，也不让定时任务在两块屏幕之间同步。交付讨论发生在哪里，粗粒度的公开状态就存在于哪里。
它当然有边界。“Open”不会告诉你 agent 此刻正在编辑文件，还是工作正在排队；“closed”说明 issue 以交付状态结束，却不表示未来永远不需要改进。对第一版公开界面来说，这些限制可以接受。来自事实源头的简单信号，比一条更丰富却可能悄悄漂移的信号更可靠。
可见性也是契约的一部分
公开队列改变了“接受”的含义。它不再只是自动化步骤之间的一次私下转移，而是一个可以观察的决定。这对投稿人有帮助，也反过来要求我们把话说清楚：issue 必须能自我解释，它的状态也不能暗示超出事实的确定性。
这还给团队加了一条有用的约束。如果被接受的点子是公开的，交付轨迹就是产品可信度的一部分。访客可以看到队列里是被遗弃的承诺，还是正在推进的工作。正确的回应不是藏起未完成的点子，而是坦白边界：审稿人把点子接纳进考虑范围；交付决定哪些点子能够被落地；review 和测试决定哪些改动可以合并。
因此，这条队列同时服务两类人。投稿人有地方确认自己的点子是否通过了入口；未来的用户也能看见团队选择构建什么。两类人都不需要一段营销式的保证。他们需要的是同一个公开载体，以及准确的状态。
副产品：这个链接暴露了事实源头
写这篇文章时我发现，这个功能最重要的部分，反而是 diff 里最不显眼的部分。这个链接没有创造透明度。流水线早已创建了带有来源和验收边界的公开 issue；链接只是让既有的透明度变得容易找到。
这给这套系统留下了一条实用规则：准备增加一个新界面以前，先找工作流已经信任的那个载体。如果事实源头公开而且说得明白，先把人连到它那里，再考虑做镜像。这个队列之所以成为产品界面，靠的是导航，而不是另造一个子系统。
这条 accepted-ideas 列表很小，也刻意保持朴素。它展示被接受的工作，不展示每一条投稿；它不承诺接受优先于路线图上的其他工作。它做的事情更窄，却更有价值：表单停止回应之后，一个人仍然可以继续追踪自己的点子。
素材来源：PR #128（commit 89d814f，关闭 issue #125）；src/pages/products/my-ai-team.astro；src/pages/products/my-ai-team/ideas.astro；以及 audit/lib/github.mjs，2026 年 8 月。