试点申请 / 受邀注册
当前不是公开自助注册，而是先走试点 intake 和邀请制开通。
`/register` 只负责说明当前的申请和开通方式，不承诺“填个表单就直接拿到租户”。 现阶段会先把业务场景、交付模式、责任人和前置条件收口，再决定是否进入试点评估、受邀注册和实例开通。
正式公开站点以 clawo.net 为准；clawo.co 仅作为跳转入口。微信 service-account 也暂不作为注册或开通入口。
当前注册规则
公开站只提供规则说明和分流，不把售前 intake、试点排期和已开通支持混成同一个入口。
当前机制
邀请制 + 试点制，不开放公开自助租户注册
主站入口
clawo.net
当前边界
微信 service-account 暂不作为注册入口，clawo.co 仅作跳转
路径分流
先分清新申请、受邀开通和已开通用户，不把三种状态混在一起。
公开站的任务是把路径分清楚，而不是强行把所有人塞进同一个“注册”入口。 对已经拿到账号和实例的用户，最短路径始终是登录和控制台，而不是重新发起申请。
受邀开通
已经受邀并拿到凭据，就直接登录控制台
当前不提供公开自助租户注册。受邀后应直接进入登录入口，开始后续实例、方案和 API 控制台操作。
这条路径只面向已经受邀并拿到账号的用户。
进入登录页交付确认
如果还在确认交付边界，先看交付方式
当你还在收口 SaaS、托管、私有化或硬件预装路径时，不建议直接推进账号开通，先把交付边界定清楚。
页面负责说明规则，不在公开站直接暴露自助开通表单。
先看交付方式仍在评估
如果还没进入受邀阶段，请回到试点 intake
你还没有受邀凭据时，不应把 `/register` 当成直接开通入口。请先回到试点 intake，按统一路径准备信息。
统一入口能减少售前、试点和开通流程互相打断。
回到试点 intakeIntake 顺序
申请后先收口四件事，再决定是否进入受邀注册或开通。
当前更看重的是把范围和前置条件说清楚，而不是尽快生成一个空账号。这样可以减少试点中途反复改路径和补上下文的成本。
1. 先收口场景
先判断你是在评估平台商品、需要外贸助手试点，还是已经有明确的交付目标。没有最小场景定义时，不会直接进入开通。
2. 对齐交付模式
提前说明更接近 SaaS、托管部署、私有化还是预装硬件，避免把完全不同的交付路径混成一轮申请。
3. 指定责任人
无论是业务负责人、技术 owner 还是交付接口人，都需要在申请阶段明确下来，否则试点推进会很快失焦。
4. 检查前置条件
包括网络环境、域名、服务器、数据来源、可用 API、验收时间窗口与成功标准。只有这些条件明确后，才会进入受邀注册或开通安排。
申请前准备
先准备这些信息，试点 intake 会更快进入有效判断。
如果上述信息一项都不明确，通常意味着还处在了解阶段。那时应先回到交付方式、产品目录和联系页，而不是急着推进注册。
业务场景
当前最想验证的是部署落地、运行控制、交付能力，还是外贸助手的具体业务链路。
交付模式
SaaS、托管部署、私有化、预装硬件里，哪些可接受，哪些不可接受。
责任人
请明确业务 owner、技术 owner 和交付接口人，避免进入排期后才发现没有人负责推进。
前置条件
包括网络环境、域名、服务器、数据来源、可用 API、合规要求与验收窗口。
下一步入口
新申请去 intake，已开通用户回登录，交付判断先看交付方式。
这样可以避免同一批用户在售前说明、试点排期和已开通支持之间来回绕路，也能让公开站和控制台的职责继续保持清晰。