这两个月没写技术文章，我确实有点卡住了

中间不是没有想过更新，也不是完全没有东西可写。只是每次打开编辑器，写了几行，又觉得没什么意思。

以前写技术文章比较简单。工作里遇到一个坑，解决了，就把排查过程整理出来。

学了一门新技术，理解了一套机制，就把知识点串起来。

比如 RTOS 里的死锁、低功耗、任务调度、汽车电子里的系统选择，这些东西都有明确的问题、有明确的过程，也有明确的经验可以沉淀。

但最近这段时间，我明显感觉到，技术写作这件事变了。

不是技术不重要了，而是很多“过去值得写一篇文章的问题”，现在已经被 AI 在对话里消化掉了。

1

以前写文章，是因为问题解决得不容易

做嵌入式的人都知道，很多技术文章其实不是写出来的，是调出来的。

一个 bug 查了两天，最后发现是中断里调用了不该调用的接口。

一个低功耗问题折腾一周，最后发现是某个外设时钟没关干净。

一个 RTOS 的死锁，看起来像随机卡死，实际是优先级反转和资源锁顺序的问题。

这种文章为什么有人看？

因为它不是资料搬运。它里面有现场、有误判、有试错、有最后那一点“原来是这里”的感觉。

我以前写文章，大多也是这个逻辑。先在工作里遇到问题，再把问题拆开，把背景、现象、排查、结论写出来。文章的价值，来自这个问题本身不太好解决。

但现在不一样了。

很多问题刚露头，我还没来得及形成一篇文章，它就已经在和 AI 的几轮对话里被拆得差不多了。

2

最近做 C++ 项目，我其实是被 AI 带着走的

最近我们有个项目用的是 C++。

说实话，我平时主要写 C，对 C++ 工程并不熟。语法当然见过一些，但真到一个完整工程里，类怎么组织、对象生命周期怎么处理、资源怎么分配、接口之间怎么协作，这些东西一开始并没有那么顺。

如果是以前，我大概率会先硬啃代码。

先把目录结构看一遍，再把主要类和模块关系画出来，再找入口，再看线程、队列、资源分配，最后慢慢摸清楚这套工程的脾气。

但这次我没有完全按这个老方法来。

我只是先粗略知道这个工程大概做什么，用了哪些资源，哪些模块比较关键。

然后把局部代码、调用关系、类定义、我看不懂的写法，一段一段丢给 AI。

问它：
这个类大概负责什么？
这里为什么要用智能指针？
这个对象是谁创建的，谁释放的？
这个回调函数什么时候被调用？
这里如果用 C 的思路去理解，会踩什么坑？

我甚至会让它用“嵌入式 C 工程师能听懂的话”解释一遍。

几轮下来，很多原本要自己查资料、看博客、慢慢试的东西，AI 直接帮我拆开了。

当然，它说的东西我不会全信。涉及线程安全、资源释放、实时性、内存占用、异常处理这些地方，最后还是要回到代码和实际运行结果上确认。

但不得不承认，这种效率变化很明显。

以前是我自己一点点把工程摸熟；现在更像是我先抓住几个关键问题，再让 AI 帮我把周围的知识补齐。

3

问题被解决得太快，写作冲动反而少了

这也是我这两个月没怎么写文章的一个原因。

不是没有问题，而是很多问题已经不再像以前那样“值得单独写一篇”。

比如 C++ 里某个语法点不懂，以前可能要查几篇文章，比较几种说法，最后自己总结一篇。

现在问 AI，十分钟就能得到一个还不错的解释。如果它讲得太抽象，就让它用 C 的写法类比。如果它讲得不贴工程，就贴一段项目代码让它结合上下文讲。

最后问题解决了，但写文章的欲望没了。

因为我知道，这类内容再写一篇，可能也只是把 AI 能回答的东西重新说一遍。读者真的遇到类似问题，也很可能直接问 AI，而不是再去搜一篇博客。

这对技术作者来说挺微妙的。

以前我们分享知识，是在补信息差。现在很多基础信息差，正在被 AI 快速抹平。

4

更讽刺的是，平台也在推动 AI 写作

还有一个很现实的感受，是写作平台本身也变了。

以前写文章，大家都强调原创。标题旁边有“原创”两个字，会觉得这篇东西至少是作者自己写出来的，有自己的经验和判断。

现在再打开一些创作后台，看到的已经不只是编辑器，而是一整套 AI 内容生产流程。

输入标题，生成摘要，生成大纲，生成正文，甚至还能 AI 配图。

这件事说起来有点讽刺。

以前平台鼓励你写原创，现在平台也在告诉你，可以批量生成内容。

不是某一个平台的问题，这是整个内容行业都在发生的变化。平台要效率，作者要流量，读者要快速答案，AI 正好把这几件事连起来了。

看这些功能的时候，我心里其实有点复杂。

一方面，作为工程师，我知道工具进步是挡不住的。AI 能提高效率，就一定会被用起来。

另一方面，作为一个写过不少技术文章的人，又会觉得内容越来越像流水线。选题发现、内容生成、内容管理、内容分发、数据反馈，全都被产品化了。

这不是好或者不好那么简单。

这意味着写作者的位置变了。

以前你写得勤、写得细，就能积累一些优势。现在只靠“把资料整理一遍”已经不够了，因为这件事 AI 做得又快又便宜。

5

以后还能写什么

这段时间我也一直在想，以后还要不要继续写技术文章。

答案应该还是要写。

只是写法要变。

以前我可能会写：“C++ 智能指针怎么用”、“RTOS 死锁有哪些场景”、“低功耗模式需要注意哪些外设”。

这些内容当然还有价值，但如果只是把概念讲一遍，很容易被 AI 替代。

以后更值得写的，可能是这些东西：一个问题在真实项目里是怎么暴露出来的。当时为什么会误判。哪些信息一开始被忽略了。AI 给过哪些建议，哪些有用，哪些不靠谱。最后为什么选择这个方案，而不是另一个看起来更漂亮的方案。

换句话说，技术文章的重点，可能要从“告诉别人答案”，变成“展示自己怎么判断”。

答案会越来越便宜，判断反而会越来越值钱。

6

AI 不是可选项了

以前有人说要不要用 AI，我还会觉得这是一个选择题。

现在看，已经不是了。

对于工程师来说，不用 AI 不一定马上被淘汰，但效率差距会越来越明显。

别人用 AI 快速理解一套陌生代码，快速生成调试脚本，快速整理手册重点，快速写测试记录，你还坚持所有东西都从零开始查，当然也能做，但节奏会慢很多。

这不是说工程师可以偷懒。

恰恰相反，AI 出来以后，对工程师判断力的要求更高了。

因为它能很快给你一个看起来像答案的东西。你要判断它对不对，适不适合当前项目，会不会引入新的风险。

嵌入式尤其如此。

代码可以让 AI 帮忙看，手册可以让 AI 帮忙整理，C++ 工程也可以让 AI 帮忙解释。

但内存够不够、实时性有没有问题、硬件时序是否满足、异常分支会不会挂死，这些最后还是要工程师自己负责。

7

这两个月没更新，也算是一次提醒

回头看，这两个月没写文章，不完全是懒。

更多是我对技术写作这件事有点卡住了。

过去我熟悉的写作方式，是遇到问题、解决问题、整理文章。

现在问题还是有，但 AI 让问题解决得更快，也让很多知识点不再稀缺。与此同时，平台又在推动 AI 写作和内容批量生产。

这种变化对写作者有冲击，对工程师也有冲击。

但想来想去，最后还是绕不开一个结论：不能因为 AI 会写，就不写了。也不能因为 AI 会答，就不思考了。

以后我可能会少写一些纯知识点搬运，多写一些真实项目里的判断、取舍、踩坑和复盘。

AI 能帮我提高效率，但文章里真正有价值的部分，应该还是工程师自己的现场经验。

工具变了，写作方式也要变。

既然浪潮已经来了，站远一点抱怨没有意义。至少对我来说，更现实的做法是靠近它、使用它、理解它，然后尽量不被它推着走。

这大概就是我这两个月没怎么写技术文章的真实原因。

也是接下来继续写下去的理由。