在技術(shù)領(lǐng)域深耕多年我常常思考一個(gè)問題我們每天面對海量的代碼、框架和工具真正的核心競爭力究竟是什么最近讀到安全大師 Bruce Schneier 的一個(gè)觀點(diǎn)深有感觸。他認(rèn)為“寫作是思維訓(xùn)練AI 無法替代”。這并非一個(gè)文學(xué)性的論斷對于開發(fā)者而言這恰恰點(diǎn)明了從“代碼搬運(yùn)工”到“問題解決者”蛻變的關(guān)鍵。本文將圍繞這一核心觀點(diǎn)結(jié)合我們?nèi)粘５拈_發(fā)實(shí)戰(zhàn)探討寫作此處特指技術(shù)寫作如撰寫設(shè)計(jì)文檔、代碼注釋、技術(shù)博客、故障復(fù)盤報(bào)告等如何系統(tǒng)化地錘煉我們的工程思維以及為什么在 AI 輔助編碼日益強(qiáng)大的今天這項(xiàng)能力反而愈加珍貴。1. 寫作的本質(zhì)思維的編譯與調(diào)試在編程中我們將高級語言“編譯”成機(jī)器可執(zhí)行的指令。而寫作則是將腦中模糊、跳躍、不完整的想法“編譯”成線性、結(jié)構(gòu)化、他人可理解的語言。這個(gè)過程本身就是一次嚴(yán)密的思維訓(xùn)練。1.1 從混沌到清晰定義問題邊界當(dāng)我們接到一個(gè)需求或遇到一個(gè) Bug 時(shí)最初的認(rèn)知往往是模糊的?！跋到y(tǒng)慢了”、“頁面報(bào)錯(cuò)了”、“功能不好用”——這些都是現(xiàn)象而非定義。技術(shù)寫作的第一步就是逼迫自己厘清問題邊界。示例一個(gè)模糊的需求 vs. 一個(gè)清晰的定義模糊的需求“優(yōu)化數(shù)據(jù)庫查詢速度。”通過寫作梳理后的清晰定義背景訂單列表頁在數(shù)據(jù)量超過 100 萬條時(shí)頁面加載時(shí)間從平均 200ms 上升至 5s 以上用戶體驗(yàn)下降?，F(xiàn)狀分析當(dāng)前查詢語句為SELECT * FROM orders ORDER BY create_time DESC LIMIT 20未對create_time字段建立索引且在WHERE子句中包含了對status和user_id的等值查詢。優(yōu)化目標(biāo)在 1000 萬條數(shù)據(jù)量下將頁面加載的 p99 耗時(shí)控制在 1s 以內(nèi)。預(yù)期方案為create_time字段添加降序索引并考慮建立復(fù)合索引(user_id, status, create_time)。需要評估索引對寫入性能的影響。僅僅是把問題寫下來我們就完成了一次重要的思維活動(dòng)定位場景、量化指標(biāo)、分析現(xiàn)狀、設(shè)定目標(biāo)。這個(gè)過程 AI 可以輔助整理語句但問題定義的深度、對業(yè)務(wù)上下文的理解、對技術(shù)權(quán)衡的判斷必須來自于開發(fā)者自身的思考。1.2 邏輯鏈條的顯式化設(shè)計(jì)文檔的價(jià)值寫設(shè)計(jì)文檔Design Doc或技術(shù)方案是鍛煉系統(tǒng)設(shè)計(jì)能力的絕佳方式。它要求你將“怎么做”的腦圖轉(zhuǎn)化為他人可以評審和執(zhí)行的線性敘述。一個(gè)簡單的 REST API 設(shè)計(jì)思考片段## API 設(shè)計(jì)用戶積分變更接口 **需求**用戶完成特定行為后增加或扣除積分。 **初步想法**提供一個(gè) POST /api/points/update 接口。 **寫作梳理后的問題** 1. **冪等性**網(wǎng)絡(luò)超時(shí)導(dǎo)致客戶端重試如何避免積分被重復(fù)增加 2. **一致性**積分更新和用戶行為記錄必須在同一個(gè)事務(wù)中如何保證 3. **可追溯性**積分為什么變動(dòng)需要記錄詳細(xì)的變更日志。 4. **安全性**接口能否被惡意調(diào)用給自己隨意加積分 **優(yōu)化后的設(shè)計(jì)** - **接口**POST /api/points/transactions - **冪等性**客戶端必須生成唯一的 request_id服務(wù)端基于此做去重。 - **事務(wù)**在數(shù)據(jù)庫事務(wù)內(nèi)先插入一條積分交易記錄包含行為類型、變更點(diǎn)數(shù)、request_id再更新用戶總積分。 - **日志**積分交易記錄表即作為審計(jì)日志。 - **安全**行為類型和點(diǎn)數(shù)對應(yīng)關(guān)系在后端硬編碼客戶端只能觸發(fā)預(yù)定義的行為。寫作迫使你面對自己邏輯中的漏洞。在“寫下來”之前你可能覺得方案“大概沒問題”但“寫下來”之后那些隱藏的邊界條件、并發(fā)沖突和數(shù)據(jù)一致性問題就無處遁形了。這比直接寫代碼再調(diào)試成本低得多。2. 寫作作為“元認(rèn)知”工具提升代碼質(zhì)量寫作不僅作用于文檔更直接作用于代碼本身。清晰的代碼注釋、有意義的提交信息、詳細(xì)的 PR 描述都是“寫作”的體現(xiàn)它們能極大提升代碼的可維護(hù)性和團(tuán)隊(duì)協(xié)作效率。2.1 代碼注釋寫給未來自己和他人的信很多人討厭寫注釋認(rèn)為“好代碼自解釋”。但“自解釋”是結(jié)果而注釋是達(dá)到這個(gè)結(jié)果的思考過程記錄。糟糕的注釋 vs. 有效的注釋// 糟糕的示例陳述顯而易見的事實(shí) public int calculatePrice(int quantity, int price) { return quantity * price; // 計(jì)算總價(jià) } // 有效的示例解釋“為什么”這么做 public void updateUserStatus(User user, Event event) { // 使用雙檢鎖Double-Checked Locking懶加載初始化緩存。 // 因?yàn)?getUserCache() 方法可能被多個(gè)線程頻繁調(diào)用且初始化成本高。 // 參考https://en.wikipedia.org/wiki/Double-checked_locking if (userCache null) { synchronized (this) { if (userCache null) { userCache loadCacheFromDatabase(); // 耗時(shí)操作 } } } // 業(yè)務(wù)規(guī)則僅當(dāng)事件類型為‘激活’且用戶當(dāng)前狀態(tài)為‘未驗(yàn)證’時(shí)才更新為‘活躍’。 // 避免因消息重復(fù)消費(fèi)導(dǎo)致狀態(tài)錯(cuò)誤覆蓋。 if (event.getType() EventType.ACTIVATION user.getStatus() Status.UNVERIFIED) { user.setStatus(Status.ACTIVE); userRepository.save(user); } }寫注釋的過程是在審視自己的代碼決策。當(dāng)你無法簡潔地寫出“為什么這樣寫”時(shí)往往意味著代碼本身可能存在問題比如過于復(fù)雜、邏輯不清晰。AI 可以生成格式規(guī)范的注釋但它無法替代你理解業(yè)務(wù)約束和設(shè)計(jì)權(quán)衡后做出關(guān)鍵解釋。2.2 提交信息Commit Message項(xiàng)目的演進(jìn)日志好的提交信息是項(xiàng)目的歷史書。它遵循一定的規(guī)范如 Conventional Commits不僅說明“改了啥”更說明“為何改”。規(guī)范示例feat(訂單服務(wù)): 增加下單時(shí)庫存預(yù)占功能 - 在 OrderService.createOrder 方法中調(diào)用新的 InventoryService.reserveStock 接口。 - 引入分布式事務(wù)消息表確保庫存預(yù)占與訂單創(chuàng)建最終一致。 - 解決了在高并發(fā)下超賣的問題相關(guān)issue #123。 BREAKING CHANGE: Order 實(shí)體新增 reserved_inventory_id 字段需執(zhí)行數(shù)據(jù)庫遷移腳本。撰寫這樣的提交信息要求開發(fā)者對本次修改的目的、方案、影響范圍有全局認(rèn)知。這本身就是對一次代碼變更的完整復(fù)盤和抽象。長期堅(jiān)持能極大地培養(yǎng)你的工程規(guī)范意識(shí)和模塊化設(shè)計(jì)思維。3. 技術(shù)博客與故障復(fù)盤從經(jīng)驗(yàn)到知識(shí)的升華將項(xiàng)目中的實(shí)踐、踩過的坑、解決的難題寫成技術(shù)博客或內(nèi)部復(fù)盤報(bào)告是最高階的思維訓(xùn)練。它要求你完成從“具體操作”到“抽象模式”的躍遷。3.1 技術(shù)博客教是最好的學(xué)當(dāng)你試圖向他人解釋一個(gè)技術(shù)點(diǎn)時(shí)你必須徹底理解它并構(gòu)建一個(gè)從易到難、循序漸進(jìn)的敘述邏輯。寫作結(jié)構(gòu)訓(xùn)練你的知識(shí)體系構(gòu)建能力背景引入為什么需要這個(gè)技術(shù)解決什么痛點(diǎn)定義問題核心概念它是什么關(guān)鍵術(shù)語解釋。建立知識(shí)錨點(diǎn)環(huán)境與示例一步步展示如何做。提供可復(fù)現(xiàn)的路徑原理深入它為什么能工作探究本質(zhì)最佳實(shí)踐與坑點(diǎn)根據(jù)經(jīng)驗(yàn)?zāi)男┑胤饺菀壮鲥e(cuò)如何優(yōu)化提煉模式總結(jié)回顧與展望。形成閉環(huán)這個(gè)過程迫使你查漏補(bǔ)缺將零散的知識(shí)點(diǎn)串聯(lián)成網(wǎng)。很多在“以為懂了”階段忽略的細(xì)節(jié)在寫作時(shí)都會(huì)暴露出來。3.2 故障復(fù)盤Post-mortem將教訓(xùn)轉(zhuǎn)化為團(tuán)隊(duì)資產(chǎn)故障復(fù)盤報(bào)告不是追責(zé)而是學(xué)習(xí)。寫作一份好的復(fù)盤報(bào)告需要嚴(yán)謹(jǐn)?shù)慕Y(jié)構(gòu)化思維。一份簡化的復(fù)盤報(bào)告大綱## 故障概述 - 標(biāo)題某服務(wù)因緩存雪崩導(dǎo)致 API 大面積超時(shí) - 時(shí)間2023-10-27 22:00 - 23:30 - 影響訂單下單失敗率上升至 35%持續(xù)約 1.5 小時(shí)。 ## 時(shí)間線Timeline - 22:00 發(fā)布新版本包含一項(xiàng)針對緩存 Key 的改動(dòng)。 - 22:05 監(jiān)控顯示 Redis 連接數(shù)飆升CPU 打滿。 - 22:10 開始收到大量超時(shí)告警... - 23:30 服務(wù)完全恢復(fù)。 ## 根本原因Root Cause 1. **直接原因**新代碼錯(cuò)誤地設(shè)置了大量不同的緩存 Key導(dǎo)致同一批數(shù)據(jù)被重復(fù)緩存數(shù)千次擊穿本地緩存所有請求直達(dá) Redis。 2. **深層原因** - 代碼評審未識(shí)別出該緩存模式的風(fēng)險(xiǎn)。 - 壓測環(huán)境未模擬出緩存 Key 激增的場景。 - 缺乏對 Redis 單 Key 訪問頻次的監(jiān)控。 ## 行動(dòng)項(xiàng)Action Items 1. **立即修復(fù)**回滾有問題的版本修復(fù)緩存 Key 生成邏輯。負(fù)責(zé)人張三截止日已完成 2. **流程改進(jìn)**在代碼評審清單中增加“緩存使用規(guī)范”檢查項(xiàng)。負(fù)責(zé)人李四截止日2023-11-10 3. **工具建設(shè)**開發(fā)監(jiān)控看板增加對熱點(diǎn) Key 和異常緩存模式的檢測。負(fù)責(zé)人王五截止日2023-11-30寫作復(fù)盤報(bào)告是一個(gè)系統(tǒng)的歸因分析過程。它要求你超越“某個(gè)工程師寫錯(cuò)了一行代碼”的表象去審視流程、工具、監(jiān)控、測試等系統(tǒng)性問題。這種結(jié)構(gòu)化歸因的能力是高級工程師和架構(gòu)師的必備素質(zhì)。4. AI 的輔助與無法替代的邊界當(dāng)前AI 編碼助手如 GitHub Copilot、通義靈碼等已成為強(qiáng)大的生產(chǎn)力工具。它們能極大提升代碼片段的生成速度、補(bǔ)全重復(fù)模式、甚至提供算法思路。在技術(shù)寫作中AI 也能幫助我們語法潤色讓表達(dá)更流暢、專業(yè)。結(jié)構(gòu)建議提供文章或文檔的大綱。信息檢索快速匯總某個(gè)技術(shù)的要點(diǎn)。但是AI 無法替代寫作背后的核心思維活動(dòng)決策與權(quán)衡在多個(gè)可行方案中根據(jù)業(yè)務(wù)上下文、團(tuán)隊(duì)技術(shù)棧、未來擴(kuò)展性、運(yùn)維成本做出選擇。AI 可以列出選項(xiàng)但無法替你決策。抽象與建模如何將混亂的現(xiàn)實(shí)業(yè)務(wù)需求抽象成清晰的數(shù)據(jù)模型、系統(tǒng)邊界和 API 契約這需要深刻的領(lǐng)域理解和創(chuàng)造性的設(shè)計(jì)思維。建立因果與敘事如何將一次故障的根本原因、間接原因、行動(dòng)項(xiàng)邏輯清晰地串聯(lián)起來形成一個(gè)有說服力的故事這需要嚴(yán)密的邏輯和系統(tǒng)思考。經(jīng)驗(yàn)與直覺為什么“這里最好加個(gè)重試機(jī)制”為什么“那個(gè)索引可能不生效”這些往往來自于過去踩坑形成的“直覺”是隱性的、難以言傳的知識(shí)Tacit Knowledge無法被 AI 簡單學(xué)習(xí)。批判性思維對 AI 生成的代碼或文檔能否發(fā)現(xiàn)其中的邏輯漏洞、潛在的性能問題或安全風(fēng)險(xiǎn)這需要你具備比 AI 更深刻的批判性審查能力。AI 是強(qiáng)大的“副駕駛”但它沒有“目的地”的概念。寫作就是定義目的地、規(guī)劃航線、記錄航行日志的過程。這個(gè)過程訓(xùn)練的是作為“船長”的你自己。5. 實(shí)踐建議將寫作融入開發(fā)工作流如何有意識(shí)地培養(yǎng)這項(xiàng)能力以下是一些可立即執(zhí)行的建議5.1 從小處著手強(qiáng)化代碼溝通堅(jiān)持寫有意義的提交信息每次 commit 前花一分鐘思考如何用一行摘要和幾行正文說清楚這次修改。在復(fù)雜函數(shù)前寫注釋在實(shí)現(xiàn)一個(gè)算法或復(fù)雜業(yè)務(wù)邏輯前先用注釋寫下你的思路偽代碼。寫完代碼后再回頭潤色這份注釋。編寫清晰的 PR 描述模板化你的 PR 描述必須包含“變更背景”、“測試方法”、“影響范圍”等。5.2 建立個(gè)人知識(shí)庫使用筆記工具用 Obsidian、Notion 或簡單的 Markdown 文件記錄日常遇到的技術(shù)問題及其解決方案。不要只收藏鏈接要用自己的話復(fù)述一遍。定期整理與重構(gòu)每隔一段時(shí)間回顧筆記將零散的點(diǎn)歸類、合并、提煉成更系統(tǒng)的小文章。這個(gè)過程就是知識(shí)的“重構(gòu)”Refactoring。5.3 嘗試技術(shù)分享從內(nèi)部分享開始在團(tuán)隊(duì)周會(huì)上用 10 分鐘分享你上周解決的一個(gè)技術(shù)難點(diǎn)。準(zhǔn)備簡單的幻燈片或文檔強(qiáng)迫自己結(jié)構(gòu)化表達(dá)。寫作技術(shù)博客選擇一個(gè)你最近深入研究的技術(shù)點(diǎn)按照“背景-概念-實(shí)踐-原理-總結(jié)”的結(jié)構(gòu)寫一篇博客。不必追求長篇大論500-1000 字的深度總結(jié)就很有價(jià)值。參與代碼評審在評審他人代碼時(shí)不僅指出“哪里不對”更要嘗試寫出“為什么不對”以及“如何改進(jìn)更好”。這既是幫助隊(duì)友也是鍛煉你清晰表達(dá)技術(shù)觀點(diǎn)。5.4 擁抱“慢思考”在急于敲代碼之前給自己 5-10 分鐘在紙上或文檔里畫一畫、寫一寫這個(gè)模塊的輸入輸出是什么邊界條件有哪些會(huì)不會(huì)有并發(fā)問題有沒有更簡單的設(shè)計(jì)這種“慢思考”帶來的前期設(shè)計(jì)優(yōu)勢往往會(huì)節(jié)省后期大量的調(diào)試和重構(gòu)時(shí)間。寫作是將內(nèi)部模糊的思維進(jìn)行外部化、線性化和結(jié)構(gòu)化的過程。對于開發(fā)者而言它遠(yuǎn)不止是文檔輸出而是一種核心的元技能——一種關(guān)于如何思考的思考。它訓(xùn)練我們定義問題、設(shè)計(jì)系統(tǒng)、厘清邏輯、歸因分析、傳播知識(shí)。在 AI 時(shí)代編寫標(biāo)準(zhǔn)化代碼的門檻會(huì)越來越低但定義問題、權(quán)衡方案、構(gòu)建系統(tǒng)、傳承經(jīng)驗(yàn)的能力會(huì)越來越重要。這些能力恰恰需要通過持續(xù)的、有意識(shí)的“寫作”這種思維訓(xùn)練來獲得和強(qiáng)化。所以無論工具如何進(jìn)化請堅(jiān)持寫作堅(jiān)持思考堅(jiān)持將你獨(dú)一無二的經(jīng)驗(yàn)和洞察固化下來分享出去。這不僅是構(gòu)建你的技術(shù)影響力更是在塑造你作為一個(gè)解決問題的人的根本能力。