企业官网建设流程全解析

简介：这份资源是百度IoT平台官方使用手册的完整Word整理版，面向准备将硬件设备接入百度天工物联网云平台的嵌入式开发者、物联网应用开发者及项目测试人员，帮助其在一个文档内理清平台从产品创建到应用配置的完整操作链路，降低接入与联调的学习成本。压缩包共1个文件，为doc格式，大小约1.35MB，属单文件文档型资料，便于离线查阅、打印或按章节检索。手册内容按研发管理、数据统计、服务与应用三条主线展开：研发部分覆盖创建产品、下载CA与Profile文件、心跳检测、数据点设置与测试、批量生产（单批次最多10000个Profile）、OTA固件升级（zip格式、上限10MB、支持静默与强弱提醒）；数据统计部分说明新增设备、设备存活、设备活跃、在网时间、在网时长分布与固件版本分布等指标口径；服务与应用部分则涉及服务列表、服务管理以及应用的创建与Android/iOS端参数配置。已有384人学习，适合需要快速查阅平台操作细节、排查心跳与烧录问题的读者参考。

1. 一份 Word 版 IoT 平台手册的价值：从“能连上”到“能交付”差哪几步

设备第一次联网成功，不等于项目能交付。这份完整 Word 版《物联网 IoT 基础平台使用手册》把产品创建、Profile/CA 下载、心跳检测、数据点、批量生产、OTA 和数据统计串成一条落地路径，适合嵌入式固件、平台接入、测试和项目交付的人对照使用。它解决的不是“某个 API 怎么写”，而是接入顺序、字段口径和批次边界：先建产品还是先烧录，心跳成功到底证明什么，数据点测试和批量生产之间还缺哪张记录表。很多返工不是代码写错，而是产品型号、Profile 批次、固件版本三件事没有对齐。这份手册的价值在于把平台侧操作拆成可检查的步骤，让新手能照着走，熟手能拿它做验收清单。

2. 产品与凭据先落位：产品创建、联网方式、Profile 与 CA 的下载顺序

2.1 为什么先定产品模型，而不是先烧录

设备接入最常见的误操作，是拿到 Profile 和 CA 就急着烧录，烧完发现产品型号选错、联网方式填错，最后只能重新建产品、重新下载凭据。平台里的“产品”不是随便起个名字的分组，它决定了设备身份、Profile 归属、数据点挂载位置，也影响后面的批量生产和 OTA 升级范围。手册把创建产品放在第一步，逻辑是对的：先有产品模型，再有设备凭据，最后才谈心跳和数据点。

产品类别、产品型号、联网方式、自定义配置这四个字段，落地时各有用途。产品类别用于平台侧归类，手册里举了智能家居、智能硬件等方向；产品型号更像产线和固件的共同标识，建议把产品线、硬件版本、联网方式编进型号名，不要用“测试1”“新设备”这种名字；联网方式决定设备侧链路选择，也影响后续心跳和 OTA 触达的判断；自定义配置是附加信息，常见做法是写产线编号或硬件批次，方便出问题时倒查。

提示：产品型号一旦进入批量生产，再改名称会带来对账成本。命名规则最好在新建产品前就定好，并写进接入规范。

2.2 创建产品的操作顺序与字段检查

手册里的创建路径很明确：完成注册后进入开发者中心，在设备接入页面点【新建产品】，设置产品类别、产品型号、联网方式，按需填写自定义配置，信息填完后点【新建】，产品会出现在新产品研发区域。这个流程本身不复杂，真正需要盯的是每一步之后的检查动作，而不是点完按钮就结束。

第一步，进入开发者中心后先确认当前账号所在的项目空间。多人协作时，常见翻车点是 A 同学在测试空间建了产品，B 同学在生产空间找不到，然后怀疑平台没保存。第二步，点【新建产品】前先把型号命名写在纸上，包含产品线、硬件版本、联网方式三段，例如“环境采集-硬件V2-WiFi”这种可读格式，避免后期靠记忆辨认。第三步，填写产品类别和联网方式时，以实际硬件为准，不要按“以后可能换”来填；联网方式变了，心跳和 OTA 的排查路径也会变。

第四步，自定义配置不要为了填而填。手册允许按自身需要设置，落地时可以把产线编号、硬件批次、固件大版本写进去，但不要塞敏感信息。第五步，点【新建】后回到新产品研发区域确认产品已经出现，再点进产品详情核对字段。这个“回看一遍”的动作很土，但能挡住大部分低级错误。熟手可以把它做成一张新建产品检查表，新手至少要把产品型号和联网方式读一遍再离开页面。

2.3 Profile 与 CA 的下载、烧录和心跳验证

产品创建完成后，手册要求下载 Profile 和 CA。操作路径是点开刚创建的产品，点【下载 Profile】和【下载 CA】，然后参考设备端开发者手册把文件烧录到设备。设备联网后，CA 会向平台定时发送心跳，平台用这个动作验证设备是否与云端互通。这里要分清两个东西：Profile 更像设备身份与接入配置的载体，CA 是设备与平台通信的凭据文件，两者要成对归档，不能只留一个。

烧录时最常见的错误不是文件损坏，而是“文件对、产品不对”。比如产品型号 A 的 Profile 烧进了型号 B 的设备，心跳检测可能一直失败，但串口日志看起来又像联网成功。我一般会在下载后立刻建一个目录，目录名用“产品型号-批次号-下载日期”，把 Profile、CA 和下载页面截图放在一起。截图不是为了好看，是为了后面核对平台侧字段。烧录完成后先别急着批量，拿一台样机做心跳检测：在设备接入页面点【心跳检测】，平台会自动检测设备是否已向云端上报心跳，成功会弹窗提醒，失败则回头检查烧录过程，并可以重新检测。

注意：心跳检测成功只说明设备已经向云端上报心跳，不等于数据点业务已经跑通。数据点还要单独设置和测试，别把两步并成一步。

2.4 把“心跳成功”变成可复现记录

心跳成功那一刻很容易让人放松，但批量生产最怕的就是“当时成功，后来找不到是哪台”。手册里的心跳检测是平台侧自动检测，失败时提示检查烧录过程并可重新检测，这说明它适合做单机验证，不适合替代批次记录。落地时我会加一张接入记录表，把设备编号、产品型号、Profile 批次、CA 下载日期、烧录时间、心跳检测结果、检测时间都记下来。字段不多，但出问题时能少走很多弯路。

这张表不需要多复杂，关键是每次心跳检测后立刻填。血泪经验是：等到批量生产再补记录，十有八九会对不上，因为产线换过电脑、换过烧录工具、换过操作人。把心跳成功变成一条可复现记录，后面的数据点测试、批量生产和 OTA 才有共同的参照物。

3. 心跳与数据点：把“设备在线”拆成可验证的三段链路

3.1 心跳不是玄学：平台侧检测与设备侧上报的边界

很多团队一说设备离线就查代码，其实先要分清平台侧心跳检测和设备侧上报是两件事。手册里的心跳检测是在设备接入页面点【心跳检测】，平台自动检测设备是否已向云端上报心跳；设备联网后，CA 会向平台定时发送心跳。也就是说，平台看的是“有没有收到心跳”，设备侧要保证“联网正常、凭据烧录正确、心跳逻辑在跑”。这三件事任何一件断了，平台侧都会表现成心跳失败。

心跳还直接连着数据统计口径。手册写得很清楚：设备首次向云端上报心跳，表示设备已激活，新增设备量是在指定时间范围内激活设备的数量；一次心跳代表设备在网 30 分钟；设备存活是有数据上报的设备，既包含心跳数据上报，也包含通过 APP 连接控制设备时进行的数据上报；设备活跃是在指定时间内有非心跳数据上报的设备。这几个定义看起来像统计问题，实际会影响验收：只看“存活”会把只发心跳的设备也算进去，只看“活跃”又可能漏掉刚激活还没业务的设备。

提示：排查顺序建议先看心跳检测，再看数据点测试，最后看统计口径。顺序反了，容易把统计差异当成接入故障。

3.2 数据点设置：类型、数据类型与命名

心跳通了之后，下一步才是数据点。手册的定义是：设备与云端的具体数据交互通过数据点进行定义。操作路径是进入产品数据点页面，选择需编辑数据点的相关产品，点新建数据点，选择数据点类型，再根据需要选择数据类型，编辑完后点【确认】创建成功，已创建的数据点还可以编辑和删除。这里的关键不是按钮在哪，而是数据点一旦被设备描述文件引用，后面改名字、改类型都要考虑兼容。

数据点命名建议带业务含义，不要用“点1”“参数A”。常见做法是“业务对象-属性-单位”，比如温度当前值、开关状态、告警等级这种可读结构。数据类型要按设备实际上报来选，不要为了看起来整齐全选同一种。手册没有展开所有类型细节，落地时以平台页面可选类型和设备端开发者手册为准。新建数据点后先别急着导出，回到列表逐个核对名称、类型、数据类型，确认没有重复项和拼写错误，再做数据点测试。

数据点设置不是一次性的。产品迭代时新增数据点，最好在批次记录里写清楚“本批次使用的数据点版本”。手册没有要求版本号，但实际交付时，设备描述文件一换，老固件可能就不认新数据点。把数据点变更当成配置变更来管理，比事后拍脑袋强。

3.3 数据点测试：Demo APP 扫码与设备描述文件

手册里的数据点测试步骤是：产品创建完数据点后，导出为设备描述文件，将其与 CA 集成，烧入设备，实现设备与云端的数据互通；然后在数据点设置页面点【数据点测试】，使用 Demo APP 扫描二维码开始测试。这个流程把“平台配置”和“设备端集成”连起来了，测试失败时不要只盯二维码，要往回查设备描述文件有没有重新导出、CA 有没有一起烧进去、设备固件是不是还在用旧描述文件。

我一般会在测试前做四件事：确认产品型号没选错；确认数据点列表没有刚改未保存的项；确认设备描述文件是本次导出的；确认样机烧录的是同一套 Profile、CA 和描述文件。扫码测试适合验证数据点通路，但它不是批量生产验证。二维码能扫通，只说明当前样机和当前数据点配置能对上，不代表产线每一台设备都没问题。

数据点测试通过后，把测试结果写进联调记录：数据点名称、类型、数据类型、上报频率、测试时间、测试人、失败重试次数。不要只丢一张截图，截图过两周就找不到上下文。记录表可以和前面的心跳记录放在同一个目录，形成“产品-凭据-心跳-数据点”的链路证据。

3.4 从数据点测试到联调记录

联调阶段最耗时的不是第一次测试，而是失败后不知道改了什么。数据点测试通过后，建议把设备描述文件、固件版本、Profile 批次、CA 下载日期、测试二维码截图放在同一份记录里。下一次改数据点，先对比这份记录，确认改动范围，再决定要不要重烧。手册里数据点可以编辑和删除，这很方便，但也意味着平台侧配置会变；设备端不跟着变，就会出现“平台显示有数据点、设备上报对不上”的情况。

这套记录看起来偏项目管理，但它解决的是技术复现问题。心跳和数据点都过了，才适合进入批量生产。否则批量生产出来的 Profile 越多，后面要返工的范围越大。

4. 批量生产与 OTA：10000 个 Profile 批次、10MB 固件包和四种通知策略

4.1 批量生产的触发条件与批次设计

手册明确写了：在产品数据点创建并检测无问题后，可申请批量生产，批量生成大量 Profile。操作是选择要批量生产的产品型号，点【新建批次】，设置批次信息，Profile 数量最多为 10000 个；创建完成后点击批次，可下载 Profile。这里的“检测无问题”不是一句客套话，至少要包含心跳检测通过、数据点测试通过、设备描述文件和 CA 集成烧录验证通过。少一项就批量，后面大概率要混批返工。

批次设计要围绕“可追溯”来做。一个批次不要混多个产品型号，也不要把不同硬件版本的设备塞进同一批，除非产线能逐台记录 Profile 与设备编号的对应关系。批次名建议带产品型号、生产日期、产线编号，例如“型号-日期-线体”这种结构。Profile 数量上限是 10000，不代表一次就要拉满；先小批量试产，抽检心跳和数据点，再放量，比一次性生成一大包更稳。

注意：批量生产前先把数据点测试记录、心跳记录、描述文件版本固定下来。批次创建后再改数据点，会让同一批 Profile 对应不同配置。

4.2 Profile 下载与产线烧录的核对表

批次创建完成后，点击批次可以下载 Profile。产线烧录时最怕“包对、设备不对”。我一般要求产线做三件事：第一，下载后先核对批次名和产品型号；第二，烧录工位记录设备编号与 Profile 文件的对应关系，哪怕只记流水号；第三，每批抽检若干台做心跳检测，抽检不合格就停线查烧录工具和文件版本。手册里的心跳检测可以重新检测，这给抽检留了余地，但抽检记录要留下。

产线常见做法是“先烧一批，再统一测”，这在小批量时没问题，大批量时容易把问题放大。更稳的做法是分段抽检：每烧录一定数量抽几台，心跳通过再继续。Profile 数量最多 10000，分批管理不会增加太多操作，但能显著降低混批风险。

4.3 OTA 固件包：10MB zip、版本号与通知方式

手册里的 OTA 操作是：在 OTA 升级页面选择要升级的产品，点上传固件，固件最大 10MB，格式为 zip；输入固件版本号及通知方式进行固件升级规则配置；配置完成。通知方式有四种：静默为直接对设备进行升级，无提醒，无需用户干预；强提醒、弱提醒和被动提醒为推送给 APP 端信息，可在 APP 中进行相应规则设置。这里有两个硬边界：固件包必须是 zip，且不能超过 10MB；版本号要能区分新旧，不能重复。

固件包超过 10MB 时，不要改后缀硬传。常见做法是裁剪调试符号、拆分资源、压缩静态文件，或者把大资源放到设备启动后单独下载。zip 包内目录结构要保持稳定，版本号和文件名对应，避免产线拿错包。上传前先在样机上做一次本地升级验证，确认升级后心跳正常、数据点正常，再走平台 OTA。

4.4 OTA 灰度与回滚的现实做法

OTA 最怕“全量推了才发现新固件心跳异常”。手册没有展开灰度策略，但平台有固件版本分布统计，这给回滚判断提供了依据。常见做法是先小范围设备升级，观察心跳、数据点上报和固件版本分布，再逐步扩大。回滚不是把旧包重新上传就完事，版本号要重新规划，确保设备能识别这是一次新升级；旧固件包要保留，别等出事再找。

提示：OTA 配置完成后不要马上全量。先看固件版本分布有没有按预期变化，再看设备存活和活跃有没有异常波动。

4.5 服务列表、服务管理与应用凭据配置

手册的服务部分分服务列表和服务管理。服务列表展示服务的基本信息，可在服务详情里点【查看文档】了解对应服务怎么用；服务管理用于查看服务的基础数据信息。落地时不要把服务列表当摆设，接入前先看对应服务的文档，能少走很多“参数填了但不生效”的弯路。服务管理里的基础数据适合做上线后的观察入口，尤其是服务调用异常时，先看这里有没有明显波动。

应用部分更关键。手册写的是：设备如需通过 APP 控制，需先创建应用，获取应用的 AK、SK 等基本信息后才可操作；创建应用时点【创建应用】，输入应用名称即可创建成功；配置应用时选择要配置的应用，可复制 APP 的 API Key、Secret Key，选择 APP 所处平台，带包名和签名的一类平台需要填写包名和应用签名，带 Bundle ID 的一类平台需要填写 Bundle ID。手册原文把 Bundle ID 写成了“Bunld ID”，这是个拼写坑，落地时按 Bundle ID 理解。

手册里同时出现 AK/SK 与 API Key/Secret Key，落地时以应用配置页实际字段为准，别把两套凭据贴反。创建应用和配置应用看起来是平台操作，实际影响 APP 控制设备能不能通。建议把应用名称、API Key 尾号、Secret Key 保管人、平台类型、包名/签名或 Bundle ID 写进交付记录，但 Secret Key 不要明文群发。

5. 避坑排查：心跳失败、数据点错位、OTA 不生效的 5 个高频翻车点

5.1 五个高频翻车点：现象、原因、解决

第一坑：心跳检测一直失败，但设备串口显示联网成功。现象是平台点【心跳检测】后失败，设备侧看起来已经连上网络。原因通常有三种：Profile 和 CA 烧录不完整，产品型号选错，或者设备实际联网方式与产品配置不一致。解决时先回到产品详情核对型号和联网方式，再重新烧录 Profile 和 CA，烧完用同一台样机重新检测；如果还失败，看设备侧心跳逻辑有没有真正发出，别只看网络连接状态。

第二坑：设备显示存活，但业务数据一条没有。现象是统计里能看到设备存活，数据点页面却没有预期数据。原因是心跳在发，数据点没按定义上报，或者设备描述文件还是旧版本。解决时先查数据点名称、类型、数据类型是否与设备端一致，再重新导出设备描述文件，与 CA 一起烧入设备，用 Demo APP 扫码做数据点测试。测试通过后再看统计，别拿存活数当业务成功数。

第三坑：批量生产后部分设备心跳失败。现象是同一批次里少数设备怎么检测都不通。原因多半是 Profile 混批、产线烧录工具缓存了旧文件，或者设备编号与 Profile 对应关系没记。解决时先锁定失败设备所属批次，核对下载时间和烧录记录，重新下载该批次 Profile 重烧；如果同一工位连续失败，停线查烧录工具和文件版本。批次记录这时候就是后悔药。

第四坑：OTA 固件上传失败。现象是上传按钮点了没反应或提示格式错误。原因通常不是平台玄学，而是固件包不是 zip，或者压缩后超过 10MB。解决时先看文件后缀和实际大小，再把调试符号、无用资源裁掉，保持 zip 包内目录结构稳定后重传。不要改后缀硬传，也不要把大包拆成多个随意命名的压缩包。

第五坑：OTA 推送后设备没升级。现象是平台显示配置完成，设备固件版本没变。原因是通知方式与 APP 侧规则不匹配，设备不在线，或者版本号没有递增。解决时先看固件版本分布，确认目标设备是否在线；再把通知方式改成更强提醒做小批量验证；最后核对版本号是否比当前版本新。静默升级适合强制修复，但不等于设备离线也能立即生效。

5.2 排查顺序：先身份，再链路，再业务，最后策略

出现问题时最怕东改一下西改一下。我一般按四层排查：第一层看身份，产品型号、Profile、CA 是否对得上；第二层看链路，心跳检测能不能过，设备是否真的向云端上报；第三层看业务，数据点定义、描述文件、Demo APP 测试是否通过；第四层看策略，批量生产批次、OTA 通知方式、APP 规则是否匹配。这个顺序的好处是每层都有明确证据，不会把统计口径问题误判成设备故障。

血泪经验是：先看心跳检测和固件版本分布，这两个入口能快速判断问题在设备侧还是平台侧。心跳不通先别碰数据点，数据点不通先别批量生产，OTA 没生效先别重复上传固件。按层排查，比凭感觉改参数稳得多。

6. 从手册到交付：用统计口径反推验收表与批量生产前检查

6.1 用统计口径反推验收表

手册里的数据统计不只是看板，它可以反推验收表。新增设备对应激活进度，设备存活对应在线情况，设备活跃对应业务数据是否真的在跑，设备在网时间按一次心跳 30 分钟统计，在网时长分布看长尾离线，固件版本分布看 OTA 是否到位。验收时不要只写“设备已连接”，要写清楚看哪个统计项、在什么时间范围内看、异常时找谁。

6.2 批量生产前我会强制走一遍的检查

批量生产前，我会把四张表摆在一起：产品与凭据记录、心跳检测记录、数据点测试记录、批次与固件版本记录。缺一张就不放量。然后再看三个数：样机心跳是否稳定、数据点测试是否通过、描述文件和 CA 是否是同一轮导出的。OTA 上线前再看两个边界：固件包是否 zip 且不超过 10MB，通知方式是否和 APP 规则对齐。

从那以后我每次做接入交付，都强制把心跳检测、数据点测试、批次记录、OTA 版本分布当成四张必填表，哪怕项目再小也不省。省一次记录，后面可能花十倍时间对账。希望帮到你。

本文还有配套的精品资源，点击获取