LaunchRepo目录站已经收到你的提交、但还没有做出决定时，这个提交就处于待审核状态。当一个陌生人能打开上架页面，而页面上没有任何地方写着“待审核”时，它才是已上线。已排期表示平台确认了一个发布日期。单独的已提交只意味着你按下了按钮。这四个词描述的是四个不同的时刻，而一张把它们存成同一列“完成”的追踪表，报出的总数谁也无法为之辩护。本文解释每一种状态、什么才算证据，以及如何用站得住脚的数字来汇报一次目录站发布。关于这个总称的简短定义，请看上架状态（Listing status）词条；日常流程请看追踪目录站提交，避免重复计数这篇指南。
一列，五个问题
当你把产品提交到一个目录站时，关心结果的人想知道的是各不相同的事情：
- 我这边的工作做完了吗？ 我填完所有内容并按下按钮了吗？
- 平台收到了吗？ 一个感谢页面、一封邮件、账号里的一条记录。
- 它在等什么吗？ 审核、队列名额、批准、日期。
- 公众能看到它吗？ 一个未登录的人也能打开、而且不带“待审核”标签的 URL。
- 我需要做什么吗？ CAPTCHA、两步验证提示、网站上的徽章、关于付费路径的决定。
“完成”回答了第一个问题，却悄悄声称也回答了第四个。一张写着 40 的表格，最后实际只意味着 6，就是这么来的。前两个问题之间的区别有专门的词条：草稿与已提交。
待审核与已上线，已排期与已提交
这些是人们最常混淆的几对状态。每一行都是你在更改状态之前应该问的问题。
| 一对状态 | 区别 | 让它往前推进的证据 |
|---|---|---|
| 已提交 vs 待审核 | 已提交是你的动作；待审核是平台确认审核已经开始 | 平台给出的回执：成功页面、邮件或后台中的条目 |
| 待审核 vs 已上线 | 待审核在等一个决定；已上线是已发布且不带标签 | 公开 URL 在未登录状态下能打开，且没有“待审核”标签 |
| 已排期 vs 已上线 | 已排期有一个确认的日期；已上线有一个公开页面 | 在该日期当天或之后打开页面 |
| 排队中 vs 已排期 | 排队中在队伍里有一个位置；已排期有一个日期 | 平台给出了具体日期 |
| 已上线 vs 已收录 | 已上线来自这次提交；已收录在你开始之前就已存在 | 先检查是否已有上架页面 |
最后一行比看上去更重要。如果某个目录站已经收录了你的产品，再次提交会产生一个重复条目，平台可能会拒绝或删除它。这就是追踪表为它单独设一个状态的原因。
11 种状态，按它们回答的问题分组
LaunchRepo 追踪表（record.py，它写入 submissions.json，本地仪表盘也遵循同样的规则）使用 11 种状态。每一种状态在记录之前都要求一个最低限度的观察。仪表盘把每个平台恰好归入一个分组，所以各分组加起来总是等于尝试过的平台数。
| 问题 | 状态 | 仪表盘分组 | 下一步 |
|---|---|---|---|
| 你这边的工作 | draft |
draft |
完成并提交，或者放弃 |
| 你这边的工作 | prepared_needs_human |
needs_you |
完成指明的步骤：CAPTCHA、2FA、徽章、决定 |
| 已收到 | submitted_pending_review |
pending |
在公布的审核期过后重新检查 |
| 已收到 | queued |
queued |
等待排队；重新检查，绝不重新提交 |
| 已收到 | scheduled |
scheduled |
在确认的日期打开上架页面 |
| 已公开 | live |
live |
无需操作；保存好 URL |
| 已公开 | already_listed |
already_listed |
无需操作；不要再次提交 |
| 已停止 | blocked |
problem |
解决资格或账号限制问题，或者放弃 |
| 已停止 | unavailable |
problem |
等路径恢复可用后再试 |
| 已停止 | deferred_paid |
parked |
由你决定：在运行之外付费，或者跳过 |
| 已停止 | not_a_fit |
parked |
无 |
11 种听起来很多。实际上，每一种之所以存在，都是因为把它并入相邻状态至少造成过一次错误的报告。记录结果：状态、证据与 record.py这篇指南展示了每种状态对应的确切命令。
示例 1：SaaSHub，已公开但仍待审核
SaaSHub 的提交记录在公开的 SaaSHub 提交实战指南中，它生成了一个任何拿到链接的人都能打开的产品页面。页面上同时带着一个显眼的标签：Pending approval（等待批准）。
只有一列的追踪表会把它记为完成，甚至记为已上线，因为页面能打开。LaunchRepo 的规则正好相反：仅仅能公开访问，并不能证明已被接受。只要页面还写着待审核，这个上架就保持 submitted_pending_review。只有在有人再次打开它、看不到待审核标签、并用一个明确的确认标志记录 URL 之后，它才会变成 live。在提交当天，已上线的计数没有增加；这一行得到的是一个回头检查的日期。
示例 2：TinyLaunch，已排期但批准仍未完成
TinyLaunch 记录在 TinyLaunch 提交实战指南中，它在免费的 Standard 路径上提供了一个未来的每周发布名额。日期确认后，仪表盘在它旁边显示 Waiting for approval（等待批准）。
这里有两种错误的记录方式：记为 live，因为日历上有了日期；或者记为 submitted_pending_review，因为批准还没完成。追踪表记录的是 scheduled，附上确认的日期，并在备注里写明批准尚未完成。两个事实都得以保留：日期存在，但它不一定能兑现。追踪表还会拒绝早于该产品最早发布日期（发布日期下限）的 scheduled 日期，所以下周一的一个免费名额，不会在你的发布页面准备好之前就上线。已排期条目（Scheduled listing）词条用一段话讲清了这个状态。
追踪表会拒绝什么
写在页面上的规则很容易被跳过。下面这些由脚本强制执行。以下是2026年9月30日在一个全新工作区中、用一个示例产品进行的真实运行：先记录六个与公开实战指南一致的结果，然后尝试把 SaaSHub 提升为已上线。buckets.py 是为本文编写的一个四行辅助脚本；它打印的是仪表盘自身的分组函数返回的结果。
$ python3 scripts/record.py --project projects/my-product saashub submitted_pending_review --note 'Public page labelled Pending approval' --next-action 'Recheck the label after the review window'
Recorded saashub: submitted_pending_review
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 2, "scheduled": 2, "problem": 2}
$ python3 scripts/record.py --project projects/my-product saashub live --note 'Page loads' --next-action None
Tracker rejected input: Public states require a reviewed URL and --confirmed-public
$ python3 scripts/record.py --project projects/my-product saashub live --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Tracker rejected input: Platform exists: inspect the record and use --replace intentionally
$ python3 scripts/record.py --project projects/my-product saashub live --replace --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Recorded saashub: live
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 1, "scheduled": 2, "live": 1, "problem": 2}这里发生了三件事。“页面能打开”不足以记为 live：追踪表需要一个经过核实的公开 URL 和确认标志。已有的记录行绝不会被悄悄覆盖：要修改它，必须有意使用 --replace。而提升 SaaSHub，会把一个平台从待审核移到已上线，同时已提交仍然是 4，因为状态变化不是一次新的提交。一旦记录了一个已上线条目（Live listing），这一行就带有任何人都能核查的 URL。
用三个计数代替一个总数
一份好的报告从不只给一个数字。它给三个，每个回答一个不同的问题：
- 已提交： 有多少个平台收到了产品。在仪表盘中，这是
pending+queued+scheduled+live。 - 已上线： 今天你能链接到多少个公开上架页面。
- 需要你处理： 有多少行在等一个人来处理。
同样的规则决定了什么计入运行目标。工具包的操作手册在一个平台第一次到达 submitted_pending_review、queued、scheduled 或 live 时计数一次。草稿、交接、付费路径、被否决的候选以及 already_listed 永远不会推进目标，同一平台之后的更新也不会重复计数。一次真实的提交即使后来被审核拒绝，仍然计为已提交；只有误记的回执才会被更正，方法是使用 --invalidate-run-confirmation。
我们自己的试点说明了为什么要分开计数。2026年9月14日的 SeoMap 日志发布在创始人页面上，其中有 211 次提交尝试：20 个已上线、97 个待审核、24 个已排期。另外 70 次尝试还没有到达这三种状态中的任何一种。“211 个完成”在某种意义上是真的，但在每一种有用的意义上都是错的。
为什么智能体比你更需要这些
如果你手动提交五个目录站，你会记得哪个在待审核、哪个显示了日历。一个 AI 智能体运行一次会话、关闭它、明天再重新开始，甚至可能换成另一个智能体、在另一台机器上，它是记不住的。它先读取追踪表，然后根据状态做决定：
prepared_needs_human行和到期需要核实的scheduled发布排在最前面。- 公布的审核期已过的
submitted_pending_review行会被重新检查：检查的是已有的记录，绝不是为了插队而重新提交。 live行保持不动。
如果状态是错的，这些决定每一个都是错的。第一天就把 SaaSHub 记为已上线，就意味着没有人去检查它是否获得了批准。把 TinyLaunch 仅仅记为已提交，就意味着没有人在发布日核实页面。状态就是智能体的记忆，而本地仪表盘就是你读取它们的地方。
如果你正在准备自己的运行，LaunchRepo 的工作原理展示了追踪表在工作流程中的位置，面向 SaaS 创始人的页面介绍了拥有真实发布日历的产品该怎么做。追踪表、仪表盘和 299 份有效的平台指南（截至2026年9月24日）都包含在一次性许可中。
常见问题
待审核和已上线有什么区别？
待审核表示目录站收到了你的提交，但还没有完成审核。已上线表示上架页面已经公开，而且不带待审核标签。一个你能打开的页面仍可能处于待审核状态，所以要检查标签，而不只是看 URL。
已排期的上架已经上线了吗？
没有。已排期表示平台确认了一个发布日期；上架页面会在那一天公开，而批准可能仍未完成。在把它记为已上线之前，请在该日期当天或之后打开页面。
感谢页面意味着我的提交已被接受吗？
不是。感谢页面只说明表单已发送。它最多证明平台收到了，所以在平台发布上架页面之前，状态都是待审核。
提交会待审核多久？
平台的审核要多久，就会待多久。免费路径往往很慢；本站的一篇实战指南记录的预估时间超过 30 天。请以平台公布的审核期为准；如果平台没有公布，就约定一个跟进日期。
如果上架一直待审核，我应该重新提交吗？
不应该。在审核期过后重新检查已有的提交，如果平台规则允许，就联系平台。重新提交可能产生重复条目，也不会让你在队列中往前排。
来源：LaunchRepo 工具包 1.9.0 中的 RUNBOOK.md（状态表、计数和更正规则）、scripts/record.py 和 scripts/dashboard_status.py；2026年9月30日的一次真实追踪表运行；公开的 SaaSHub 和 TinyLaunch 实战指南（观察于2026年9月13日）；创始人页面上2026年9月14日的 SeoMap 日志。