这是「古法编程」系列的开篇。在正式聊技术之前，我想先说说，为什么在我打算把过去十年攒下的笔记一批批的整理出来。
一、关于AI，我的看法
先说个观察，外界对程序员的看法悲观得有点夸张。"AI 要取代程序员了"、"写代码这行快不行了"——类似的话我听了不下百遍。再加上 Coding Agent 和LLM 确实吊，u1s1很多完全不会写代码的人，现在也能让 AI 写代码去实现自己想做的东西，甚至我都还没有AI写得好😭。
年初我也是慌，学习研究各种Agent，学习搭建个人RAG，本地部署大模型，学习各种AI Coding 开发范式，也很想要让AI帮我做很多事儿，帮公司做很多事儿，但现在我释怀了。
原因很简单：当内容创作和内容生成门槛降低了，到处都会存在大量品质廉价，比较低的内容充斥着市场的时候，稀缺的还是独立判断和决策能力。
- 独立判断：这段方案对不对？这个架构选型合不合理？AI 给的答案能不能信？
- 决策能力：面对一个真实的生产问题，先排查什么、后排查什么、什么时候该重构什么时候该打补丁？
- 踩过坑的直觉：哪些"看起来没问题"的写法，在特定平台、特定版本上会炸？
这些东西，AI 短期内给不了你。它给得了代码片段，给不了"我在这上面栽过跟头，所以我知道要绕开"的经验。
AI能提升效率，但效率不是价值的本身，如果只是更快的产出垃圾，这就不是生产力。
所以「古法编程」这个名字，不是怀旧，是一种态度。在 AI 能帮你生成代码的时代，反而更值得把那些"为什么要这么写"的底层逻辑、那些只有亲手踩过才记得住的坑，老老实实地写下来。AI 负责提效，但判断力和经验密度，得靠人去攒。
二、我准备干什么
说回我自己。
我做了快十年 Android 开发了，不算强，但是中高级往上能摸一摸，在我个人的有道云笔记里攒了 300 多篇笔记——有工作里踩的坑、有学某个模块时做的笔记、有排查疑难 bug 时的完整推演、也有读源码时随手记的设计感悟。这些笔记一直躺在我的私人笔记本里，只有我自己看得懂。
现在我想把它们"搬出来"。
说实话，以前不搬，一方面是懒，另一方面是觉得"笔记嘛，自己看就行，写成博客还得润色排版，太费劲"。但 AI 把这最后一公里的成本打下来了——我现在可以把一篇只有自己看得懂的草稿，丢给 AI 帮我理顺结构、补全背景、画好配图，然后变成一篇陌生人也能读懂的文章。
这就是我这段时间在做的事：用 AI 完成从「个人知识笔记」到「面向所有人的博客」的最后一公里。 笔记里的经验和判断是我的，AI 负责把它从"草稿"变成"成品"。
而这最后一公里走完之后，终点是开放给所有人。
原因很简单：我走到今天，靠的是开源社区和前辈们无偿分享的资料。那些散落在博客、论坛、GitHub 里的开源代码，虽然我也有买过，付费过很多课程视频等，但很多牛逼的大佬们都忠于分享，开源，都实实在在帮过我。没有这些分享，我走不到现在。所以我也愿意把我学到的的东西，原样反哺回去。
还有一个现实原因：Android 系统开发这块，掘金上成体系的内容其实不多。 你搜 "自定义 HAL"、"Android Framework 不同版本的适配"，能找到的大多是零散的片段，东一榔头西一棒子，初学者拼不出全貌。而成体系的内容，确实在另一些平台上能找到——但得开 VIP，得买专栏，一篇想看的文章点进去先弹个付费墙。甚至有些大佬们免费的文章都搞成了付费，说的是谁 懂的都懂😏。
三、更新计划
大概这样安排：
-
频率：一周 1-2 篇，不贪多，保证每篇都经得起回看
-
路线：分三个阶段推进
- 系统/车载常规开发：先从 AOSP 和 AAOS 开发的常见套路和流程入手——自定义 HAL、SELinux 配置、Framework 适配这些"做过的人觉得简单、没做过的人到处碰壁"的硬骨头
- 原理解析：再往深走、讲启动流程这些"知其然还要知其所以然"的东西
- 嵌入式驱动开发：最后会挑战一个驱动方向，从内核模块写到设备树，把"Android 系统开发"和"底层驱动"这条线彻底打通
这些知识本来就是社区喂大的，现在还回去😎
