翻了一下后臺，上一篇真正按我自己節奏寫的技術文章，已經是兩個月前了。
中間不是沒有想過更新，也不是完全沒有東西可寫。只是每次打開編輯器，寫了幾行，又覺得沒什么意思。
以前寫技術文章比較簡單。工作里遇到一個坑，解決了，就把排查過程整理出來。
學了一門新技術，理解了一套機制，就把知識點串起來。
比如 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 能幫我提高效率，但文章里真正有價值的部分，應該還是工程師自己的現場經驗。
工具變了，寫作方式也要變。
既然浪潮已經來了，站遠一點抱怨沒有意義。至少對我來說，更現實的做法是靠近它、使用它、理解它，然后盡量不被它推著走。
這大概就是我這兩個月沒怎么寫技術文章的真實原因。
也是接下來繼續寫下去的理由。
