{
  "manualOnly": true,
  "providerRequests": 0,
  "locale": "zh",
  "group": "social-bookmarking-backlinks",
  "title": "社交书签外链：判断一次贡献是否适合社区",
  "notice": "这是手动规划资料，不是实时审计、发布站点库存或排名预测。案例为虚构示例。本页不会抓取或提交数据，下载文件保留在您的设备上。",
  "columns": [
    "决策步骤",
    "虚构案例中的问题",
    "未解决时的行动",
    "需要保存的证据"
  ],
  "rows": [
    {
      "id": "rules",
      "title": "1 · 规则",
      "values": [
        "是否允许这个主题以及投稿自己的资料？",
        "禁止时停止；确认参与资格之后再继续，不以能打开表单代替许可。",
        "真实规则与复核日期，而不是主观推断的允许状态。"
      ]
    },
    {
      "id": "relevance",
      "title": "2 · 相关性",
      "values": [
        "教程是否回答图表无障碍问题？",
        "修订描述，指向相关教程而非通用首页，让读者看到准确任务。",
        "明确的受众问题，以及真正提供帮助的具体章节。"
      ]
    },
    {
      "id": "disclosure",
      "title": "3 · 披露",
      "values": [
        "贡献者是否与该资源有关？",
        "披露作者或商业关系，再检查社区是否还有额外要求。",
        "准确的署名、所属关系或商业利益说明，不伪装独立推荐。"
      ]
    },
    {
      "id": "observation",
      "title": "4 · 公开观察",
      "values": [
        "引用是否被接受并公开显示？",
        "观察输出之前保持待审核或拒绝状态，不把提交成功算作已发布。",
        "来源、日期、语境、目标与实际渲染属性，便于以后复查。"
      ]
    }
  ],
  "example": "设想一个虚构设计社区正在收集无障碍图表教程。您的文章讲解键盘访问，但书签草稿只写“最佳SEO网站”，并指向首页。决策路径先检查参与规则，再把说明与目标改成读者的实际任务。修订稿应说明教程哪一节解释如何用键盘检查图表，并直接指向该资源。这个改写不是为了塞入更多关键词，而是让读者在点击前就知道能解决什么问题，也让审核者能核对描述是否准确。",
  "decision": "如果规则禁止这项贡献，或者您不满足参与条件，应停止。若主题合适但说明隐瞒商业关系，或没有解释具体好处，则先修订。即便检查通过，编辑仍可拒绝；有权提交不代表保证发布。本表提供的是人工判断步骤，不是自动批准工具。不清楚的条件应标为未确认，而不是因为想完成表格就推测许可。若规则要求声明作者关系，应如实填写，而非换账号伪装成无关读者推荐。",
  "checklist": [
    "准备投稿前先读参与规则。",
    "说明对该社区的具体帮助。",
    "如实披露关系，不伪装独立。",
    "把提交尝试与公开结果分别计数。"
  ],
  "reviewRecord": "在另行得到授权的提交之后，记录真正可见的结果：来源URL、观察日期、周围描述、最终目标和链接属性。将待审核、拒绝、公开的状态分开保存。表单成功提示不证明存在可抓取的a元素；公开链接也不证明产生了搜索收益。后来若文字被缩短、目标改写或链接删除，应追加新的观察与时间，保留此前状态。只有这样，报告才能说明哪些是提交动作，哪些是已经发生且仍可核对的发布结果。 例如，提交后页面只返回受理编号，就应保存编号和发送时间，把公开URL栏留为未确认。若后来收到通过通知，还要访问实际页面，核对描述是否仍指向键盘访问教程，而不是改到了账户主页。如果页面需要登录才能阅读，应如实记录可见范围，不将自己的登录视图当作所有访客都能看到的页面。发现管理员删去了商业说明时，也不能因此宣布关系已经不存在，应保留原有关系信息并检查是否需要纠正。记录中的状态变化要有观察依据，不能只因为等待时间足够长就自动从待审核变成已发布。维护人员接手时，应能从记录看懂哪些步骤已经验证，哪些只是提交者的预期。"
}