从零搭建 Hexo + Fluid + GitHub Pages：把隐私检查放进发布链
个人技术站不只是把 Markdown 变成 HTML。更可靠的发布链应该同时管理源码、生成物、站内链接和公开边界，让敏感内容在推送之前就被阻止。 最小架构Hexo 把 source/ 中的 Markdown 和静态资源渲染到 public/： 12345source Markdown -> Hexo generate -> public static files -> checks -> Git...
Telink Matter 开发环境：把产品应用从 SDK 仓库中抽离
直接在 Matter SDK 的 example 目录里开发产品，开始很快，长期却会带来 SDK 升级困难、产品提交混入第三方源码、多个应用相互影响等问题。更稳定的方式是把 SDK 当作只读依赖，把产品应用、配置、生成物和构建入口放进独立仓库。 目标结构把环境分成两个边界： 12345678910111213141516171819vendor workspace├── matter/├── zephyr/├── module...
Wireshark + Thread 抓包：从信道到协议阶段的完整流程
Thread 抓包的关键不是“看到 802.15.4 帧”，而是让信道、时间、解密条件和设备日志对齐，再按 MLE、6LoWPAN、IPv6 和上层会话逐层判断。抓包只能证明捕获范围内发生的网络行为，不能替代设备端状态。 准备组成一个常见环境包括： 123456Thread device under testThread network / Border Router802.15.4 sniffer hardwarePyspi...
Obsidian + GitHub：建立可跨设备同步的私人知识库
Obsidian 适合编辑 Markdown，Git 适合保留历史，GitHub 私有仓库适合作为多设备之间的统一远端。稳定的知识库需要明确目录、同步顺序和敏感信息边界，而不是把所有文件直接扔进一个自动同步目录。 推荐架构12345678910Desktop Obsidian + Git │ ▼ GitHub private repository ...
AI + Zephyr + Matter：构建、烧录与串口调试的可控闭环
AI 可以把代码修改、构建、串口日志分析和回归测试连接成闭环，但“能执行命令”不等于“可以无限自动操作硬件”。可靠流程需要固定工程边界、明确设备身份、把烧录设为授权门，并让每轮结论都对应可复核证据。 闭环不是无限重试推荐状态机： 1234567891011理解需求 -> 读取工程规则与代码流 -> 修改产品代码 -> 静态检查 -> full build -> 人工烧录授权门 ->...
从日志到协议阶段：建立嵌入式排障的证据链
一条错误日志通常只能证明“某个位置观察到了异常”，不能自动证明根因。有效的嵌入式排障，需要先把事件还原成时间线，再把每条证据放回正确的协议层和代码阶段。 从现象开始，但不要停在现象设备掉线、入网失败或升级超时，都是用户能够感知的结果。它们可以作为调查入口，却不是足够精确的问题定义。 更有用的第一轮问题是： 最后一个明确成功的阶段是什么？ 第一个明确失败的阶段是什么？ 两者之间有哪些代码路径和异步事件？ 当前日志能证明什么，又...
Matter、Thread 与 Zigbee：先分清它们在哪一层
Matter、Thread 和 Zigbee 经常同时出现在低功耗智能设备中，但它们解决的问题并不相同。排障前先确认自己观察的是应用层、IP 网络还是完整的 Zigbee 协议栈，可以避免大量无效推断。 一个简化视图1234567891011Matter 应用与数据模型 │ ├── Thread ── IEEE 802.15.4 ├── Wi-Fi └── Etherne...
从私人笔记到公开文章：建立一条可控的输出路径
工作笔记追求及时，公开文章追求准确、完整和可传播。把两者放进同一个目录并自动同步，看起来省事，却容易带来上下文缺失、内容过期和敏感信息外泄。 两种内容承担不同职责私人笔记可以包含： 尚未验证的假设； 临时命令和原始日志； 与具体代码版本绑定的路径； 只对自己有意义的缩写和上下文。 公开文章则需要： 读者可以独立理解的背景； 明确的证据来源和适用范围； 已清理的示例； 稳定链接和可维护结构。 因此，私人知识库更适合作为选...