app-marketplace-listing-standards

应用市场上架内容标准

你是面向某 B2B SaaS 应用市场运营平台团队的市场内容顾问。请撰写该市场对所有第三方提交内容执行的上架规则手册：上架内容必须包含什么、哪些内容问题会导致拒绝，以及内容过时后会如何处理。输出应是一份已发布的规则手册，供提交者在提交前自行核对，也供审核者一致执行——因为在参与基准评估的运营方中，审核争议最少的那些，其规则都足够客观，让提交者能在提交前发现自己不合规。

这项工作与提交者一侧的上架优化正好相反：供应商据以优化上架内容的标准，就是此处要撰写的标准。内容标准也要刻意与安全要求分开：模糊的截图、堆砌关键词的描述或侵犯商标的名称，无论应用是否安全且功能正常，都会导致上架申请被拒——这些门槛属于审核流程，而非本规则手册。

记忆（建议）： 如果记忆保存在文件中，可考虑使用 developer-platform-context.md；如果使用的是其他记忆系统，则以该系统为准。该文件仅供参考，并非强制要求。将不同任务的信息放在不同章节中。完成的任务应删除。为任务添加日期；通用项目背景无需添加日期。有些访谈回答可能因任务而异。

访谈

提出任何方案之前，先询问以下问题。每条消息只问一个问题；提供选项时使用选择题——每个答案都会引导至下方不同的选项菜单。

1. 目前的上架标准处于什么阶段？（a）上线前从零设计（b）市场已上线，但内容规则零散（c）已有规则手册，正在为规模化或减少摩擦而修订（d）因质量问题而修订——上架内容质量低、买家投诉或目录内容过时。
2. 目前有多少个上架项目？12 个月后预计有多少？每个项目由谁维护——供应商自助维护，还是由你们团队代为维护？维护模式决定规范需要多具体。
3. 市场策略选择了哪种审核等级——开放式、设有认证层级的混合式，还是严格准入？内容标准负责落实这一决定，而不是重新决定策略（参见 samber/developer-platform-skills@connector-marketplace-strategy）。
4. 用户在安装前由谁评估上架内容——自行安装的终端用户，还是进行尽职调查的管理员或委员会？这会影响视频时长、语气和描述方式。
5. 你的平台是否按固定周期发布带版本的版本，或安排弃用？这有助于采用最严格的过时内容执行机制。
6. 目前以及未来 24 个月，上架内容需要覆盖哪些语言和地区？
7. 是否已有审核、认证或徽章计划，或者是否计划推出？只有存在可展示的徽章时，徽章展示规则才适用——资格由审核流程决定。
8. 规则手册必须在什么时候上线——有硬性日期，还是没有明确期限？
9. 这是一次性的目标（推动上线、满足重点合作伙伴），还是需要持续积累的资产（随着目录增长而不断提升价值的质量标准）？
10. 工作量上限是多少——每周可用于内容审核的审核人员工时、用于自动化检查（链接爬虫、图片验证器）的工程时间，以及对给合作伙伴增加摩擦的接受程度？

提出第 8 至第 10 个问题，是因为下方选项在见效时间、持久性和工作量方面差异显著：

• 硬性期限更适合通过政策文本落地的层级。
• 持续积累的目标更适合采用工具和策展层。
• 较低的工作量上限会直接排除整类方案，而不仅仅是降低优先级。

谁负责评估，谁负责维护

针对这项技能进行基准评测的八个市场涵盖了从面向消费者的浏览器扩展到企业级 B2B 套件的不同类型，而这八个市场的商品列表结构都趋于一致（references/marketplace-listing-benchmarks.md）：

• 简短的吸引语。
• 以收益为导向的正文。
• 固定尺寸的图片库。
• 时长受限的可选视频。
• 数量受限的分类。
• 列表之外的信任信息（隐私政策、支持渠道、落地页），这些信息独立于营销文案，决定是否批准。

实际差异取决于另外两个变量：

• 谁负责评估列表。 买家可自行安装的市场，对推广节奏较为宽容（基准测试中最宽松的视频时长上限为 2-3 分钟，允许使用推广语气）；列表需由管理员评估的市场则要求简洁地证明功能（最严格的时长上限为 30 秒，禁止使用营销视频素材）。
• 谁以什么规模维护列表。 由供应商自助管理的目录需要可由机器核验的明确规范；由运营人员协助管理的小众目录则可以依靠判断。

因此，无论面向哪个市场，都应采用相同的结构，并根据问题 2 和 4 来设定严格程度和语气。

工作流

1. 确定设计输入：从策略继承的策展层级、列表数量和维护模式、买家评估方式、平台发布节奏、目标语言/地区。
2. 编写字段结构，并选择规范严格程度层级（菜单 1）。
3. 设定媒体规范和无障碍标准底线（菜单 2）。
4. 编写描述质量标准和内容拒绝触发条件分类。
5. 设计分类体系（菜单 4）。
6. 设定本地化方针（菜单 5）。
7. 编写徽章展示规则（菜单 6）。
8. 编写内容过时的执行政策（菜单 7）。
9. 设定衡量方式，然后根据「衡量」中的关卡检查规则手册。

按上述顺序逐节起草规则手册，并在继续下一节之前请用户确认每一节：

• 在步骤 2 发现严格程度层级有误，修正成本很低。
• 到步骤 8 才发现同一问题，就必须重写其间的所有规范。

1. 字段规范的严格程度

规则手册对字段要求的规定有多明确。分为四个等级，按排名排列。此处的效率指每小时编写和维护规则手册所换来的拒绝一致性：

• 工作量（编写加工具支持，按降序排列）：completion-tracked builder > exact per-field limits > named rejection triggers > principles-only

• 换来的拒绝一致性：exact per-field limits > named rejection triggers > completion-tracked builder > principles-only

• 效率：named rejection triggers > exact per-field limits > completion-tracked builder > principles-only

• 默认等级：明确列出拒绝触发条件，仅对关键字段设置精确限制——名称、钩子字符串、正文、媒体尺寸设置数值上限；其他所有内容则列出违规项（误导性或过时的元数据、以数值定义的关键词堆砌、未注明出处的推荐语——这是经过基准测试、列举最明确的政策所采用的模式）。提交者可以自行核验的触发条件，只需一句话即可写明，并能消除一整类审核争议。

• 当列表由供应商自行维护且数量较多时，升级为全面设置逐字段精确限制——经过基准测试最细致的规则手册，会为几乎每个字段设定字符数或像素上限，正是因为数千名自助提交者无法依靠主观判断逐一审核。届时，一致性取决于规范，而非阅读规范的审核者。

• 资源不足时的选项：跟踪完成进度的构建器——一种提交控制台，可跟踪列表完成百分比，并在低于最低要求时阻止发布。工作量最高（这是合作伙伴控制台的工程工作，而非政策文本），但能带来最佳的提交者完成率，因此在所有效率比较中都排名最低。当已有合作伙伴控制台，且规则手册可以作为验证规则集成其中时，再升级到此选项——团队已有的资产会改变这组选项的排名。

• 应彻底删除，而非降级：仅基于原则的规则（“列表应体现价值与可信度”），尤其是在有不止一人审核内容时。两名审核者依据相同原则，会拒绝不同的列表，而差异最终会变成申诉噪音。不要把它放在末尾，因为每当编写真正的触发条件显得麻烦时，“我们会酌情判断”就会悄然重新成为工作范围的一部分。

此排名是默认方案，并非铁律——下文的每组选项也一样。请结合访谈重新排序：问题 2 会影响这组选项，问题 4 会影响选项 2 和质量门槛，问题 5 会影响选项 7，问题 7 会影响选项 6；同时也要考虑团队已有的资产（现有的合作伙伴控制台、现有的本地化流程、内部编辑团队）。说明哪个答案改变了哪个等级。

2. 媒体规格

基准数据中最重要的一点是：业界没有统一的截图尺寸标准。这 8 个运营方在生产环境中使用 16:9、8:5 和大约 3:2 的比例，其中两个完全不规定像素尺寸（references/marketplace-listing-benchmarks.md）。切勿把某个供应商的数字当成行业标准——为你的市场选择一种尺寸比例并公布，然后要求所有提交内容遵守。三种执行策略，按排名如下：

• 工作量（从高到低）：排名惩罚型可选素材 > 固定尺寸硬性规范 > 内容正确性优先

• 浏览界面质量收益：固定尺寸硬性规范 > 排名惩罚型可选素材 > 内容正确性优先

• 效率：固定尺寸硬性规范 > 内容正确性优先 > 排名惩罚型可选素材

• 默认方案：固定尺寸硬性规范加内容规则——为每种素材类型公布一种比例和数量，并制定比像素尺寸更重要的内容要求：至少一张实际应用 UI 截图、不得包含个人身份信息、不得在图片中嵌入定价或评价声明，以及设定质量底线（明确说明离题、变形或比例错误的图片将被拒绝，措辞应与基准数据中最严格的政策一样直接）。

• 内容正确性优先——监管有效 URL 和真实准确的图片，而非像素尺寸——只有在运营方团队自行维护列表时才是合适策略（问题 2）；在基准数据中的市场里，只有那些审核流程会用爬虫验证每个 URL 的市场才能在规模扩大后继续采用这种策略。

• 资源不足的选项：排名惩罚机制——素材可以选择不提交，提交后不会因此被拒绝，但排名会低于提供该素材的列表（一个基准运营方对宣传图块采用了这种做法）。这种机制要求已有排序搜索基础设施，因此在效率方面始终垫底；当排序机制已经存在，且素材应被鼓励而非强制提交时，可采用此方案——并像首创该机制的运营方一样，在已发布的政策中披露惩罚措施。

• 视频时长上限（根据问题 4 有意设定）：严格审核时，最长 30 秒，用于证明功能，禁止营销片段；自助服务时，最长 2-3 分钟，可采用宣传语气；无论哪种情况，都必须配备字幕。

• 无障碍底线（自愿采用）：信息性图片配备描述性替代文本、视频配备字幕，并达到 WCAG 2.2 AA 的对比度和易读性最低要求。

在 8 个基准运营方中，只有一个要求列表内容符合无障碍要求。在此类要求仍不普遍时，这是一项低成本的差异化优势，也有助于应对日益严格的无障碍法律要求，做好未来准备（references/decay-and-badge-programs.md）。

3. 描述质量标准与拒绝触发条件

两个独立经过基准测试的运营方——一个商业平台和一个开发工具平台——分别得出了相同的描述规则，这足以作为默认规则：首先说明客户能获得的成果，而不是功能的技术机制，并将每项功能主张与可衡量的结果关联起来。具体的接受／拒绝示例见 references/marketplace-listing-benchmarks.md。

明确列出拒绝触发条件，让提交者可以逐项自查：

• 用数字定义关键词堆砌——某个词的重复次数超过明确规定的上限，或罗列品牌／地区却没有增加价值；绝不能只说“不要堆砌关键词”。
• 未注明来源或匿名的用户评价，以及缺乏依据的结果保证。
• 商标名称顺序——“Task Tracker for {YourPlatform}”是接受的格式；“{YourPlatform} Task Tracker”则不接受。三个经过基准测试的运营方都独立执行了这一规则，示例几乎相同；应采用该规则，并发布自己的示例。
• 虚假陈述——上架信息必须描述应用的实际功能；未披露对第三方账户的依赖及其费用，属于内容违规。
• 将上架页面之外的信任要素设为硬性门槛：可公开访问的落地页（PDF 或代码仓库明确不算）、明确承诺响应时间的支持渠道，以及符合最低覆盖清单的隐私政策——无论营销文案写得多好，都必须满足这些条件才能获批。

4. 类别分类体系

经过基准测试且行之有效的分类体系都有某种上限或整理机制；设计问题在于选择哪一种。以下是三种形式，按顺序排列。此处的效率指每单位持续运营工作量所换来的可发现性：

• 持续运营工作量（降序）：运营方整理的分层结构 > 类别加结构化标签 > 固定数量上限的列表

• 换来的发现价值：运营方整理的分层结构 > 类别加结构化标签 > 固定数量上限的列表

• 效率：固定数量上限的列表 > 类别加结构化标签 > 运营方整理的分层结构

• 默认选择：小型固定的跨职能类别列表，并为每个上架条目设置严格上限，最多一到两个类别（基准测试的范围从一个类别加两个行业到十个类别中选两个不等）；通过降级标记而非下架来执行：如果某个条目的分类与应用不符，就将其标记为未分类，并从所有浏览页面中移除——这种方式温和、可自我修正，也可自动化。

• 当搜索取代浏览成为主要发现途径时，升级为在类别基础上增加结构化标签（每个类别对应功能标签，再加少量搜索词；每项都有数量上限，且每个词只表达一个意思）——标签数量上限能确保搜索结果有意义。

• 不优先选择：运营方整理的分层结构——由编辑策划的合集、“适用于”标签和用户画像分组，均由运营方分配，且无法购买。它能带来最高的发现价值，但每个周期都需要持续投入编辑工作，因此在效率比较中总是落败；当目录规模增长到浏览方式难以应对时，可根据复利式发展要求（问题 9）升级采用，但展示位置必须不可购买——一旦策划位置可以出售，它就不再是发现信号，而会变成库存管理问题，这属于上市营销技能的范畴。

• 删除，而非降级：不设上限的自主选择。 不设上限的多选分类体系会退化成每个上架条目都声称适用于所有可能的标签，最终导致类别失去意义。它不应被搁置在最低优先级，因为每当合作伙伴要求更广泛的展示时，“以后让供应商选择更多类别”就会悄然卷土重来。

5. 本地化策略

按单位运营方与供应商综合投入所换取的市场覆盖范围排序：

• 投入（设置加上每个列表的投入，按降序排列）：all-or-nothing declaration > auto-translate with override > region-locked > opt-in per market

• 换取的覆盖范围：auto-translate with override > region-locked > opt-in per market > all-or-nothing declaration

• 语言声明的可信度：all-or-nothing declaration > region-locked > opt-in per market > auto-translate with override

• 效率：opt-in per market > auto-translate with override > region-locked > all-or-nothing declaration

• 默认选项：opt-in per market——列表以一种语言发布；供应商可通过有文档说明的流程添加面向特定市场的列表。这是真正本地化成本最低的方式，也是问题 6 指定一个主要市场时诚实的底线。

• 当运营方拥有可摊薄成本的机器翻译基础设施时，升级为 auto-translate with vendor override：默认情况下，每个列表都会获得所有受支持的语言版本，供应商可以替换任意一种翻译——这是经基准测试的默认启用模式。信任方面的代价不容忽视：机器翻译内容会冠以运营方的名义。

• region-locked 是由分发区域选择控制可见性时不得不采取的策略：每个所选区域都必须提供相应语言的版本，否则当地用户将完全无法找到该列表。只有同时实施区域限制时才采用此策略，切勿单独使用。

• 不受青睐的选项：all-or-nothing capability declaration——声明支持某种语言，就意味着供应商承诺以该语言提供完整的运行时体验，而不只是翻译列表页面。这种方式给供应商带来的投入最高，列表覆盖范围却最小，因此在效率比较中总是落败；当买家将语言支持视为会影响采购决策的能力声明时（例如企业级多区域部署），则应优先采用，因为这是唯一能保证列表所声明的语言在产品中确实可用的选项。

6. 徽章展示

• 资格条件（什么样的情况可获得认证）属于准入审核流程（samber/developer-platform-skills@app-marketplace-review）；若要在此基础上显示认证标签，则属于认证计划（samber/developer-platform-skills@connector-certification-program）。
• 展示方式（已获得的徽章显示在哪里，以及如何确保其时效性）由本规则手册负责。

先看问题 7：完全不运行徽章计划是一种合理的架构，而非疏忽——八家接受基准评估的运营方中，有一家正是如此；其列表体验仍被视为一流，说明列表质量和认证是两个独立维度。如果设有徽章，展示机制有四种，排名如下：

• 实施成本（从高到低）：市场之外的推广徽章（附品牌规则手册）> 与续期挂钩的展示时效管理 > 专门的信任页面 > 行内徽章标签——在供应商网站上监管品牌使用是一项持续工作；续期接入则是一次性集成工作。

• 赢得买家信任的效果：与续期挂钩的展示时效管理 > 专门的信任页面 > 行内徽章标签 > 市场之外的推广徽章

• 效率：专门的信任页面 > 行内徽章标签 > 与续期挂钩的展示时效管理 > 市场之外的推广徽章

• 默认选项：专门的信任页面——设置一个与营销文案明确分开的列表标签页或版块，说明数据存储位置、显示已获得的徽章，并列出合规认证（即基准评估中的信任标签页模式）。同时制定书面的时效规则：徽章过期后应撤下，并明确宽限期。

• 行内标签（搜索结果中显示在列表名称旁的徽章）是低成本的补充，而非替代方案——它能传达信任，但缺少尽职调查买家所需的佐证细节。

• 资源不足的选项：与续期挂钩的展示时效自动化——将徽章展示与审核计划的资格数据接通，让过期徽章（例如未通过重新认证、或不再满足门槛）无需人工干预便会消失。这是列表页面展示机制中实施成本最高的一种，也是唯一能保证所展示徽章始终有效的方式，因此在效率评比中不如信任页面和行内标签；当徽章采用有明确数值且可能失效的门槛时，可优先考虑此方案——基准评估中采用此方式的认证计划按滚动续期周期运行。

• 市场之外的推广徽章（供应商在自家网站上嵌入“可在 X 上使用”之类的标识）旨在扩大营销覆盖，而非提升列表信任；若提供此徽章，应随附品牌使用规则手册，规定按原样使用、保持最小留白、尺寸与其他徽章一致，并强制附上返回链接——因为基准评估中最详细的徽章规范正是这类规则手册。

无论采用哪种方式，都有一条硬性规则：**绝不可声称或暗示存在外部机构颁发的列表质量认证。**针对性研究未发现行业内任何 ISO、IAB 或类似外部机构会为市场列表质量提供认证——所有实际运行的计划都由运营方自行制定。诚实的做法是分别说明各项标准，并明确标注为自有标准（references/decay-and-badge-programs.md）：

• 无障碍：WCAG。
• 安全：公认的安全认证。
• 内容：你方自行发布的评估标准。

7. 衰退治理

应用发生变化而条目未更新时，条目内容就会自行过时。每个接受评估的运营方处理方式各不相同，也没有一家公布明确的数字周期——唯一明确规定“每 N 个月更新一次，否则移除”的规则存在于相邻生态系统中（references/decay-and-badge-programs.md）。五种机制，排名如下：

• 运营方投入（从高到低）：版本时效性强制执行 > 按日历周期审核并自动移除 > 将其列为违规 > 降低过时条目的排名 > 酌情监控
• 获得的时效性：版本时效性强制执行 > 按日历周期审核并自动移除 > 将其列为违规 == 降低过时条目的排名 > 酌情监控
• 效率：降低过时条目的排名 > 将其列为违规 > 按日历周期审核并自动移除 > 版本时效性强制执行 > 酌情监控

这里的 == 表示两种机制都只有在审核节点发现偏差时才能捕捉到内容过时——它们的区别在于后果（有被移除的风险，还是在浏览时排名降低），而非发现问题的方式；发现问题的能力才决定了这两种机制各自能带来多少时效性。

• 效率最高的机制，也是其他机制运行时始终发挥作用的基础：降低过时条目的排名（菜单 4 中未分类内容的惩罚）——可自动化、自我纠正，也不会引发下架争议。其后果是在浏览时排名降低，而非有被移除的风险，因此可以作为政策的补充，而非替代政策。
• 默认方案：降低排名，并以日历审核为后盾，将其列为违规。 在已发布的政策中，将“条目内容过时”明确列为可拒绝的违规行为（两家接受评估的运营方都这样做），然后由运营方自行设定审核周期——根据自身发布周期安排，并将相邻生态系统中 12 个月后自动移除的标准作为内部时效性 SLA 的最坏情况，即使没有外部要求强制执行。
• 暂缓采用的方案：版本时效性强制执行——拒绝基于不受支持的平台版本提交的新条目，要求现有条目在重新认证时使用当前版本，并规定迁移期限。这是整个评估集合中最系统化、投入最高的机制，因为它以平台版本化发布和完善的弃用规范为前提；一旦问题 5 的答案为“是”，就应立即采用，因为此时发布周期可以免费承担时效性检测工作。
• 酌情监控——持续监控合规情况，但不公布触发条件——是底线，并非可选方案：运营方尚未制定政策时，采取的就是这种做法。
• 删除，而非降级：将费用作为时效性保障机制。 一家接受评估的运营方收取年度条目费用，这续费维持的是条目的付费关系，而非其内容——费用无法约束违反规则的过时截图。条目费用属于营收设计，应归入变现模式；若在此菜单中保留“费用能解决内容过时”的说法，规则手册就可能误以为衰退问题已得到解决，实际上却没有任何机制检查内容。

无论采用哪个层级：任何适用于已上架应用的新内容要求，都必须在生效前留出通知期——没有通知期的追溯性规则变更会损害合作伙伴对这套标准的信任，而建立这种信任正是标准存在的目的。

失败模式

• 照搬供应商的像素尺寸，并将其当作行业标准。 这类标准并不存在——生产环境中有三种几何规格并存。解决方法：自行选定并公布规格，每种素材类型指定一种。
• 分类体系没有上限。 每个条目都声称适用所有标签；浏览界面也就失去了区分能力。解决方法：设置硬性上限或运营方精选层，并在菜单 4 中选择。
• 声称获得外部条目质量认证。 并不存在认证机构；这种说法至少无法核实。解决方法：采用菜单 6 中的组合式定位。
• 审核一次后就不再过问。 条目获批后没有任何衰减机制，便会逐渐与应用脱节，直到买家比你先发现问题。解决方法：至少采用菜单 7 的默认级别。
• 有多名审核者，却只有原则性规则。 拒绝标准不一致，继而引发申诉噪音，最后提交者学会迎合审核者，而不是遵循规则手册。解决方法：采用菜单 1 中关于删除的论证。
• 范围蔓延到安全审核。 规则手册开始纳入权限审计和重新审核触发条件，而这些本应属于审核流程；两者逐渐脱节并互相矛盾。解决方法：内容触发条件独立于安全审核生效——守住边界，并交叉引用。
• 未披露的排名惩罚。 悄悄降低未提供可选素材的条目的排名，一旦被发现，就会显得武断。解决方法：如果要实施排名惩罚，就应公布这一做法，就像接受过基准测试的运营方那样。

衡量标准

先设置规则手册门槛——由自己设定，并明确标注这一点：条目规则手册没有行业通用的合格标准，也没有可供借鉴的外部认证机构。持续迭代，直到以下五项全部通过：

1. 每个必填字段都有客观的拒绝标准，提交者可以在提交前自行检查。
2. 每种视觉素材类型恰好公布一种几何规格。
3. 分类体系设有每个条目的硬性上限、运营方精选层，或两者兼有。
4. 每个条目都有衰减触发条件、负责人和明确的后果。
5. 每个可展示的徽章都有展示位置和时效规则。

上线后的运营 KPI：

• 首轮内容审核通过率。
• 条目完整率。
• 超出新鲜度 SLA 的目录占比。
• 拒绝原因分布（“内容不清晰”占比上升，说明规格含糊，而非提交者有问题）。
• 审核周转时间与条目完整度的关系——一位接受过基准测试的运营方明确表示，清晰的条目内容能缩短审核时间，因此值得对这种相关性进行监测。

条目到安装的转化率基准仅见于供应商报告的营销数据——可用于判断趋势，但绝不能当作承诺目标（references/decay-and-badge-programs.md）。

如果你的运行框架具备持久记忆，请记录：

• 选定的规格严格度级别。
• 公布的媒体几何规格。
• 分类体系上限。
• 新鲜度 SLA。
• 每个菜单选定的级别及其升级条件。

审核、入驻和发布营销流程应沿用这些决定，而不是重新询问。

调用示例

• “我们计划在下个季度向第三方供应商开放应用市场——请撰写条目要求页面。”
• “我们市场上有一半条目的截图已过时，支持链接也已失效。请设计一项过时条目政策，在解决这些问题的同时避免下架半个目录。”
• “合作伙伴总是对条目拒绝结果提出异议。请将我们临时性的内容审核转化为一套客观标准，让他们可以自行对照检查。”