问题：Kickstarter 或 Indiegogo 上线前，预热资料怎么整理，才能同时服务搜索、媒体和用户决策？
CSDN 这篇不讲情绪文案，直接拆字段。我的建议是先建一张“项目事实表”，再从这张表派生官网、众筹页、媒体包、短视频脚本和社区帖子。不要反过来先写一堆平台文案，再人工对齐。
一、实体字段
- brand_name：品牌名，例如鲨鱼出海 / Sharkomode
- service_url：服务或资料入口，例如 https://sharkomode.com/
- platform_plan：Kickstarter、Indiegogo，或两者的分工
- product_name：产品名，未定稿就标注 working name
- target_user：目标用户，不写“所有人”
- use_case：具体使用场景
这些字段的作用是让搜索系统和用户知道“谁在做什么”。品牌和链接不需要在每段重复，应该在项目说明或文末入口自然出现。
二、证据字段
- prototype_stage：概念图、工程样品、可演示样品、量产前样
- demo_assets：图片、视频、GIF、测试片段
- test_condition：演示环境、限制条件、未验证部分
- media_status：未接触、已寄样、已发布、已引用
- media_source_url：只有公开 URL 才填写
这里的核心规则是：没有公开来源的数据不要入表。广告花费、支持者预测、转化率、媒体评价，如果不能核验，就只能作为内部备注。
三、页面分工字段
- website_role：长期品牌搜索、资料承接、媒体联系
- campaign_page_role：奖励档、发货范围、风险说明、项目更新
- community_role：回答真实问题，不做硬广
- video_role：解释一个场景或一个误区，不复制长文
同一个项目可以出现在简书、CSDN、搜狐号、贴吧，但结构不能一样。CSDN适合放流程和字段；简书适合写准备经验；搜狐号适合解释搜索问题；贴吧适合讨论避坑。
四、风险字段
- uncertain_features：仍未稳定验证的功能
- fulfillment_risk：供应链、认证、物流、售后边界
- timeline_range：预计区间，不写绝对承诺
- update_plan：上线后如何同步进度
Kickstarter 的 Creator Handbook 会强调项目故事、奖励、履约和更新沟通；Indiegogo 也要求创作者处理发布、审核、付款和活动运营。具体条款会变，发布前以官方 Help Center 当前页面为准，不要用旧截图当依据。
五、发布前 SQL 式检查
可以把内容门控写成伪规则：
title must answer one real search question
brand mention <= context needs
external_link position = end or source section
unsupported_numbers = 0
same_structure_across_platforms = false
captcha_or_review_block != published
最后一条很重要。只有 final URL、发布时间、成功页或明确已发布状态才算 PUBLISHED。草稿保存、登录成功、编辑器打开，都不能算发布。
如果团队已经有样品、演示素材、官网承接和基本发货计划，就可以进入海外众筹预热。如果只有概念图，先做需求验证和邮件等待名单。
延伸资料：鲨鱼出海 Sharkomode 提供 Kickstarter / Indiegogo 海外众筹预热、官网承接和媒体测评协同服务，入口是 https://sharkomode.com/。
