文章归档

嵌入式 Linux 入门的第一步，不是改内核，也不是写驱动，而是把开发环境搭起来，把板子稳定连上，把启动日志完整拿到。只要这一步不扎实，后面遇到启动失败、网络不通、应用跑不起来时，就会缺少最基本的排查入口。

学习嵌入式 Linux 最容易遇到的问题，不是资料太少，而是资料太散。今天看驱动，明天看 Buildroot，后天又去研究 U-Boot，结果每个概念都知道一点，但真正拿到一块板子时，还是不知道从哪里开始开发。

更合理的方式，是按真实项目的开发链路学习：先能把系统跑起来，再能改 rootfs，再能开发应用，最后再深入内核和驱动。

精简 Linux 系统里的时区问题经常被低估。桌面发行版通常有 systemd、timedatectl、完整 tzdata 和图形化配置，但嵌入式 rootfs 里可能只有 BusyBox、少量动态库和几个启动脚本。更常见的情况是 /etc/localtime 位于只读 rootfs 中，运行时不能直接替换；设备还需要通过 MQTT 接收其他设备下发的时区修改协议，并且重启后不能丢失配置。

AI 工具已经可以很快生成一个功能、修复一个问题，甚至顺手补上测试。但在真实项目里，“能生成”不等于“能合并”。代码进入主干之前，仍然需要经过可读性、边界条件、兼容性、测试和运维风险的检查。

更实用的做法，是把 AI 生成代码后的审查过程固定成一张清单。这样每次变更都能从“看起来能跑”推进到“可以被团队维护”，也能减少人工 review 时反复追问上下文的成本。

Android 性能优化不是上线前临时跑一次 Profiler，也不是看到卡顿后盲目改几行代码。真正稳定的做法，是把性能问题拆成可观测、可复现、可验证的工程流程：先知道慢在哪里，再判断为什么慢，最后用指标证明优化确实有效。

AI 编程工具最容易被低估的能力，不是一次性写出多少代码，而是能不能把一个任务从需求、修改、验证一路推进到可交付状态。很多团队在试用 AI 时，会把关注点放在“代码是不是能生成”，但真正影响效率的，是生成之后的闭环有没有建立起来。

如果只让 AI 写代码，不让它读项目约束、运行验证命令、说明风险边界，最后节省的时间很可能会被人工复查和返工抵消。更稳定的做法，是把 AI 当成一个可以执行任务的工程协作者，而不是一个只负责补全片段的工具。

Hexo 博客通常会涉及两个不同概念：源码仓库和发布仓库。源码仓库存放 Markdown、主题配置、脚本和静态资源；发布仓库存放 hexo generate 之后生成的 HTML、CSS、JS 和图片。

如果这两个仓库的边界不清楚，后续维护很容易混乱：源码没有保存，发布内容能访问但无法复现；或者把生成文件提交到源码仓库，导致 diff 变得很吵；再或者把源码误推到 GitHub Pages 仓库，影响线上站点结构。

AI 编程工具真正影响效率的地方，不只是“能不能写代码”，而是能不能稳定理解项目上下文。很多时候，同一个需求第一次让 AI 做，结果还可以；过几天换个窗口、换个模型、换个入口，再让它做类似任务，质量就开始波动。

原因通常不是模型突然变差，而是上下文没有被工程化管理。项目背景、目录约定、构建命令、测试方式、代码风格、风险边界都靠临时口头描述，AI 每次都要重新猜。

每天写技术博客最容易卡住的地方，往往不是不会写，而是流程太碎：选题、确认仓库格式、创建 Markdown、补 front matter、检查构建、再执行部署。每一步都不复杂，但合在一起就会变成一种阻力。

Codex CLI 适合处理这类重复性内容工作。它可以在当前仓库里阅读已有文章，理解 Hexo 的目录结构和 front matter 约定，然后按同样的风格新增文章。再配合一个小脚本，就可以把“生成今日文章”和“部署到 GitHub Pages”合成一个稳定入口。

GitHub 上的 AI 项目增长很快，但不同指标代表的含义不一样。累计 Star 更像是长期认可度，适合观察生态里已经被大量开发者验证过的工具；Trending 今日新增 Star 更像是短期热度，适合发现正在爆发的新方向。