官网会持续生长：产品、案例与学习资源的完善节奏
官网不是一次上线就定格的宣传册。
对 HikariThings 来说，站点本身就是交付能力的一部分：产品写清楚，案例经得起对照，学习资源能跟着动手——这些都需要按真实项目节奏慢慢长出来，而不是为了「看起来丰满」一次堆满占位文案。
这篇想坦白说明三件事：现在已经有什么、接下来会补什么、我们按什么原则更新。
我们选择「慢慢完善」，而不是「一次写完」
物联网内容有个特点：写得太虚，对不上现场；写得太满，又容易和真实版本、真实交付脱节。
所以官网会坚持：
- 先结构，后厚度——导航、专栏、案例骨架先立住，细节随项目沉淀补齐
- 先可核对，后可炫耀——每一段能力描述，尽量能对应到可点开的页面或可沟通的交付项
- 先帮人下手，再堆名词——学习资源优先「能跟着做」，再谈体系完整
慢，是为了准；准，才对得起来找我们交付的人。
产品：从清单到可说明的能力
当前 产品页 已列出核心能力方向，例如：
- ThingsBoard 二开
- 信创支持（Kingbase + TDengine）
- 智能照明 / 室内照明
- 汽车涂装线 MES
- RFID 语音播报
- 离线地图
后续会完善的：
- 每类能力的适用边界（适合什么、不适合什么）
- 常见交付组合（平台 + 硬件、方案 + 联调等）
- 与设备、案例、学习资源的交叉入口，减少「看完还是不知道找谁」
产品页会保持清晰清单；更深的原理与操作，放到学习资源与博客，避免一个页面既当广告又当手册。
案例：用真实场景把能力说具体
案例 里已经有照明、RFID、涂装、泵站、畜牧等方向。它们回答的是：「别人怎么用这些能力落地？」
后续会完善的：
- 补充更多行业与现场约束（网络、协议、部署形态）
- 把「痛点 → 链路 → 价值」写得更可对照你的现场
- 与产品和设备页互链，方便从故事跳回选型
案例不追求数量爆炸，追求读完能判断像不像自己的问题。
学习资源：专栏会越写越深
学习资源 按专栏组织：ThingsBoard、Node-RED、IoT Gateway、TBMQ、Mobile、Transport……左侧是知识点目录，右侧是正文。
这是故意设计的：物联网知识适合「一篇一个点」，而不是一篇巨文从头到尾。
后续会完善的：
- 每个专栏持续增加可执行的知识点（部署、接入、映射、排错）
- 补齐与官网产品、设备（如 DTU）相关的实践篇
- 保持目录可读、路径清晰，旧文也会按反馈修订
如果你正在学某一环，欢迎从对应专栏进入；缺哪一篇，也欢迎通过 联系方式 告诉我们。
你可以用官网的方式
在内容还在生长时，不妨这样用：
| 你的目的 | 建议入口 |
|---|---|
| 看我们能做什么 | 产品 · 关于我们 |
| 对照自己的场景 | 案例 |
| 动手部署与排错 | 学习资源 |
| 了解站点与服务全貌 | 官网启航 |
结构已经可用；厚度会随交付与反馈一周周加进来。
写在后面
完善官网，和做物联网项目其实同一件事：先把链路跑通，再把细节打磨漂亮。
产品、案例、学习资源不会停在今天这一版。我们会按真实项目往前推——写清楚的留下，过时的改掉，空缺的补上。
感谢你愿意把 HikariThings 官网当作一张还在生长的交付地图。下一篇见。