寫博客的朋友應該都有一個共同的經歷新建文檔時順手命名成“無標題”然后這個“無標題”就安靜躺在文件夾里一躺就是幾個月。看似是個空文檔里面其實堆滿了復制粘貼的鏈接、隨手記的片段、突然冒出來的想法雜亂得像一間堆滿雜物的房間。我自己的“無標題”文檔不下十個有的寫著寫著變成了正式文章有的到現在還在那里積灰。這篇東西想聊的正是一套把“無標題”狀態(tài)里的散亂信息變成一篇結構清晰、內容扎實、能拿得出手的博文的方法。這套方法不只適用于寫技術博客寫項目總結、經驗分享、行業(yè)觀察甚至整理一份給團隊看的內部文檔底層邏輯都通用。核心思路僅有四步先搞清楚你手里的材料到底是什么再搭出一個不依賴靈感的結構骨架然后把每塊骨頭上填上實打實的血肉最后花點心思打磨標題和開頭。整個過程不靠天賦靠的是可復制的流程。1. “無標題”狀態(tài)的本質信息有了結構還沒出生既然有“無標題”文檔存續(xù)下來核心問題通常不是“沒內容”而是“內容太多不知如何安放”。這一節(jié)先從根源上理解這種狀態(tài)弄清楚要做的事到底是什么。1.1 拆穿“無標題”的三層假象第一層假象以為沒主題。點開一個“無標題”文檔讀一遍里面的零散片段大部分情況下主題早就浮現了。十來條內容都在說某個工具如何配置主題就是“該工具的使用經驗”七八條都在吐槽某類業(yè)務場景的坑主題就是“這類場景的避坑指南”。之所以覺得沒主題是因為主題淹沒在瑣碎信息里還沒被抽象成一句話。第二層假象以為沒結構。零散片段之間其實存在天然關聯(lián)可能是時間上的推進關系也可能是一件事的不同側面還可能是問題的“現象—原因—解法”鏈條。只是這些關聯(lián)沒有被顯式標記出來視覺上自然顯得混沌。第三層假象以為需要從頭寫。很多博主最容易卡在這一步總覺得要先把所有細節(jié)想清楚才能動手寫正文。真相是細節(jié)是在寫的過程中逐步浮現的坐在那里空想反而越想越亂。關鍵是先搭好骨架讓每一塊信息都知道自己該待在哪。1.2 想法變成文章的必經三階段任何一篇有價值的博文都逃不過三個階段。多數文章夭折是因為試圖直接跨過第二階段完成第三階段。第一階段是收集信息雜亂無章是正常態(tài)不必急著整理。第二階段是結構化目標是把散亂信息歸類、排序、建立層級產出的是大綱。第三階段才是表達把大綱中的每個要點擴展成段落?！盁o標題”文檔通常已經完成了第一階段甚至積累了大量素材。而寫不出文章卡就卡在第二階段——沒有一套系統(tǒng)性的方法把素材轉化成大綱。于是很多人退回第一階段繼續(xù)無止盡地添加素材文檔越來越重卻始終沒有成品。1.3 目標讀者是誰決定一切結構取舍先回答一個看似屬于寫作前的問題這篇文章是寫給誰看的技術類博文要區(qū)分是寫給零基礎小白還是同類從業(yè)者生活類經驗要區(qū)分是寫給同齡同處境的人還是寫給想提前了解這條路的后來者。目標讀者決定了術語密度、案例詳略、章節(jié)順序。舉個例子一篇講短視頻剪輯技巧的文章面向普通用戶開頭就要從天時地利人和等人人都懂的層面切入用大白話解釋時間軸、關鍵幀等概念面向從業(yè)者可以直接從“導出設置里碼率與分辨率如何取舍”這類實操細節(jié)講起讀者才有興趣讀下去。知道了讀者是誰結構才有一個穩(wěn)固的判斷基準。后續(xù)每一處取舍——案例要不要展開、術語要不要解釋、背景鋪墊寫多少——都圍繞這個基準來定文章才不會一邊寫得過于淺顯、一邊突然冒出高深術語。2. 撐起骨架的實操方法用信息分類替代憑空構思結構不是靠靈感拍出來的是靠一套可推導的流程搭出來的。這里給出從零散信息到完整大綱的完整路徑。2.1 把素材全部攤開篩選出真正的核心信息第一步要做的是把“無標題”文檔里的所有素材都搬到一張白紙上新建一個文檔也行然后逐條標注“類型”。分類建議只有四種觀點、事實、數據、案例。觀點是“我認為應該這么做”事實是“這個工具在某某版本以后改了默認行為”數據是“測試結果顯示性能提升了40%”案例是“當時線上發(fā)生了一起故障排查過程如何如何”。標注過程中質疑精神很有必要——有些素材看起來是事實仔細一想其實是某個特定環(huán)境下的個案有些數據缺失來源屬于孤證。這些將來要么剔除要么需補鏈。篩選標準同樣只有一條這條信息對目標讀者有沒有價值。沒有價值的信息哪怕再精彩也要果斷舍棄。不心軟的取舍是文章信息密度的重要保障。2.2 歸類合并找出素材之間肉眼可見的關系完成標注后開始歸類。把講同一個主題的素材歸到同一組給每組起一個名字。這個名字不需要追求文采直白就行比如“配置方法”“常見報錯”“性能對比”“適用場景”。歸類過程中素材之間的邏輯關系會逐漸顯現。舉一個實際案例手頭有一個“無標題”文檔零散內容包含“某容器編排工具網絡插件存在兼容性問題”“生產環(huán)境出現域名解析失敗”“官方文檔對底層網絡模式解釋較少”“最終通過切換網絡模式解決”。歸類后出現了三條關系鏈問題現象域名解析失敗、問題原因網絡插件兼容性和文檔缺失、問題解法切換網絡模式。這三條關系鏈天然構成一篇排錯經驗類博文的骨架——問題怎么發(fā)現的、怎么定位的、怎么解決的。2.3 推導大綱照著“四大問題”自問自答有了素材分組和關系鏈理論上可以嘗試排列組合但大多數人會陷入“怎么排都感覺不對”的窘境。這種時候用一套通用問題逐組追問結構會自己浮現出來。這套問題只有四個這個東西是什么解決什么問題為什么需要它不用的代價是什么具體怎么做關鍵步驟有哪幾步做完之后會遇到哪些問題如何應對對任何領域的內容這四個問題都覆蓋了讀者最關心的話題。如果手頭的素材足夠回答其中兩三個問題博文主體框架就能搭建起來。如果四個問題有素材缺口這說明收集階段的內容還不夠全面需要補一步針對性搜索或做個小實驗。補充說明一點這四個問題的順序并非一成不變。有的文章適合直切問題第4問再回頭解釋這是什么第1問有的文章適合先講代價第2問再引出方案。順序的邏輯在于匹配目標讀者的認知路徑而不是死板套用模板。2.4 大綱成型的標志每章能說出一句人話大綱是否合格有一個簡單直接的檢驗方法為每個大章節(jié)寫一句“人話摘要”這句話是你在飯桌上跟朋友聊天時會說的那種話不是書面語。比如“這一章講網絡插件兼容性問題導致的域名解析失敗以及如何通過切換網絡模式解決”就是一句合格的人話而“本章旨在深入探討網絡插件兼容性問題并提出基于實踐經驗的解決方案”就是不合格的表達需要重寫。能用人話概括每一章說明對這章的信息已經想清楚了。如果哪個章節(jié)憋了半天都憋不出一句人話大概率是這一章的信息還不夠或者這章壓根沒有存在的必要。這個檢驗方法也間接保證成文后的可讀性——一句話能說清楚的東西寫出來通常不會太差。3. 填血肉的寫作過程從提綱到可用初稿的關卡骨架搭好后進入了最考驗功底的環(huán)節(jié)把每個章節(jié)擴展成可讀、可信、有用的正文。這個過程也有一些可供依循的章法。3.1 每個論點都要有支撐案例、數據與出處一篇有信息量的博文每個核心觀點背后都要有支撐。支撐的形式可以是親歷的重現、精確的數據、權威來源的引用、或者至少一個推理過程的展示。以“網絡模式切換解決了域名解析問題”這個觀點為例支撐要素包括出現問題時的具體報錯信息、相關環(huán)境的版本參數、排查時做過哪些嘗試、最后切換了什么模式、切換之后效果如何。有了這些支撐讀者才能真正判斷這個結論是否適用于自己的場景而不只是看到一個含糊的結論。一個很實用的技巧是寫作時假設讀者會當面提出質疑“你憑什么這么說”每一次能在心里給出有理有據的回答這一段就會自然寫得充實。反之如果自己的想法也是含糊的這段文字通常會有明顯的“空轉感”——講了很多卻什么都沒講透。遇到這種情況要么補信息要么刪掉這一觀點沒有第三條路。3.2 細節(jié)優(yōu)先原則好文章是“寫具體”不是“寫正確”博文初學者最容易犯的毛病是通篇正確的廢話“配置時需要小心”“要注意性能問題”“細節(jié)決定成敗”。這類句子的通病是經不起追問——“怎么小心”“什么性能問題”“哪些細節(jié)”“寫具體”意味著把每一句能引發(fā)追問的地方都交代清楚?！靶枰⒁馀c容器網絡相關的兼容性問題”不說“配置時需要小心”“在128MB內存的云主機上該插件啟動耗時約3秒”不說“要注意性能問題”“配置文件中網卡名稱與宿主機不一致會導致啟動失敗”不說“細節(jié)決定成敗”。為了讓細節(jié)落地寫作時可以用一個很笨但很有效的方法在每一段核心內容里強制自己放入一個具體的時間、一個具體的數值、一個具體的路徑或一個具體的動作。先不管文筆好不好細節(jié)到位了文章的可信度和實用價值就立住了一半。3.3 控制段落節(jié)奏每段至少150字的信息承載量寫完初稿后檢查每個段落。如果一個段落少于150字通常意味著這個段落表達太薄、內容不足。這不代表字數本身有魔力而是150字是一個信息承載量的閾值——太少難以包含一個完整的意思加上鋪墊與展開往往撐不起來。舉個例子“這個插件兼容性不好建議別用。換成另一個模式就行?！薄@類段落太單薄讀者雖然有結論卻不清楚兼容性哪里不好、另一個模式是什么、怎么換。擴充成一段完整的內容后則要交代清楚“網卡驅動的兼容問題在何種場景下觸發(fā)”“切換的具體路徑”“切換后需要注意什么”信息量要能達到一段足夠自洽的表達。當然也不是每段都要越長越好而是在成段寫完后審視這一段的意思是否已經說透讀者能否不加猜測就領會要點如果不能就要擴寫如果能即便只有兩三行也合理。實際上寫長容易刪長難先多寫不受限再無情刪減就好。3.4 從“說明文”到“經驗分享”加減法并行的手段很多博文寫得像產品說明書條理清楚但讀起來乏味。產品說明書式的寫法本身是“說明文”的表達習慣以客觀事物為主體動詞多用第三人稱結果導向缺乏第一人稱的參與與主觀判斷。一篇能讓人讀下去的經驗分享型博文則要在說明文基礎上做兩種改動。加法是補上個人視角當時為什么會踩進這個坑排查過程中想過哪些錯誤方向某個現象發(fā)生時第一反應是什么。減法則是刪掉冗余背景函數內部實現邏輯并非重點、官網上已有解釋的概念不必重復。加減之后文章會呈現出一種獨特質感既保持技術準確性又像聽一個前輩坐在對面復盤。3.5 順一遍邏輯保證“每一章都在打下一章的地基”各章節(jié)寫完之后從頭到尾順讀一遍重點檢查章節(jié)之間的邏輯銜接。一篇流暢的博文章節(jié)間的關系往往是遞進的前文建立的認知是后文展開的前提。比如一篇講技術選型的文章第一段說明“為什么有這個需求”第二段對比各方案優(yōu)劣第三段詳述選定方案的落地細節(jié)。讀者跟到這個位置已經理解了選A方案的原因第三段就不再需要重復解釋A方案的優(yōu)勢直接進入細節(jié)即可。如果這段銜接失敗讀者讀到第三段時會覺得莫名其妙“A方案到底解決了什么問題”遇到銜接不暢的段落不用著急全文重寫。通常補一兩句過渡即可解決問題一句承上簡單總結上文結論一句啟下引導讀者進入下一場景。過渡句不必復雜甚至可以很口語化“解決了選型的猶豫接下來要面對的就是更實際的問題——具體怎么配置?！?. 標題與開頭的打磨讓讀者愿意點進來看的最后一公里內容是里子標題和開頭是面子。好不容易寫出干貨不能壞在“不會起標題、不會寫開頭”上。4.1 標題不是“描述內容”而是“提供閱讀理由”很多博主起標題的思路是這篇文章講的是什么標題就是什么。這種思路固然沒大毛病但吸引力有限?！盁o標題”狀態(tài)下的項目標題通常只是它正式標題的最初雛形需要專門花費精力打磨。過去經常聽到的說法是標題要“吸引眼球”“制造懸念”但如果處理好信息量的提煉可以走一條更穩(wěn)的路。好的標題至少要完成兩個任務第一讓相關領域的讀者一眼識別出“這篇文章跟我的工作/興趣相關”第二讓識別出的讀者有足夠的理由點進來。犯愁時的一個技巧是把目標讀者中最高頻的三個實際問題直接放進標題比如從“無標題”到“一篇從零到一的技術分享五個核心設計決策”比“我的技術成長之路”更能擊中愿意讀技術分享的人群。更直接的實踐是列一組選項從中選一個最符合內容氣質的再打磨兩三遍直到讀起來像一個同行在聊天時說的話不像一個通告。4.2 開頭的核心指標前100字內出現主要關鍵詞開頭是正文的第一個部分寫得成不成功有一個硬指標前100字內主要關鍵詞是否已經出現。關鍵詞對一篇博文的重要程度類似路標對行人的意義——它讓搜索引擎知道這篇文章的定位也讓讀者快速判斷“這里有沒有我想要的東西”。一件比較常見的通病是前幾段寫得很發(fā)散先交代個人近況、再感嘆人生繞了半天才進入正題。這種寫法放在日記里沒問題放在以傳遞訊息為導向的博文里卻會直接影響讀者判斷這篇文章“值不值得讀”。應該做的是在前100字內就亮出主題。這不意味著開頭必須生硬地羅列關鍵詞而是把它自然融入第一段的口語化陳述中。例如“如果你也在用某某平臺做內容大概會經常遇到這個問題……”——關鍵信息已在背景鋪墊中帶出。4.3 開頭需要解答的最短問題清單“是什么、關我什么事、適合誰”經驗上一個靠譜的開頭至少要在最短篇幅內給出三個問題的答案這是什么、它解決了什么問題或與讀者有什么關聯(lián)、適合誰看或適合什么場景使用。這三個答案不需要篇幅很長可以用兩三句話融合。舉個例子“精力管理是個常被誤讀的能力很多人都以為它是讓自己更高效地擠時間其實它的核心是做好取舍。今天這篇文章就是寫給每天被任務列表淹沒、總覺得時間不夠用的上班族的。”——三個問題都覆蓋到了關鍵詞也出現了作為開頭是合格的。若一篇博文遲遲寫不出合適的開頭我會反過來先寫正文讓結構提示開頭應有的內容而不是死磕第一段。寫完整篇文章后回頭補開頭通常會順利得多。4.4 正文之外編排的細節(jié)決定了閱讀的流暢度標題和開頭之外還要照顧到閱讀體驗。合理使用二、三級標題組織段落讀者在瀏覽內容時能快速找到自己關心的板塊。技術類內容適當使用代碼塊與表格生活經驗類內容多用短段落與列表但都要克制不要濫用。每段控制在150字以上但不等于整篇文章段落越長越好。長段落要拆分短段落要合并目標是讓每一屏閱讀都有呼吸感。如果對著成品數了一下整整一版全是長段落讀者很可能在手機屏幕上產生畏難情緒——這也是真實發(fā)布環(huán)境中影響完讀率的關鍵因素之一。5. 常見“無標題”變體不同場景下的應對模板不同應用場景里的“無標題”解法稍有差異。抽出幾個典型場景給出可直接套用的應對思路。5.1 技術排錯場景現象—定位—根因—修復—驗證這類文檔常見于處理線上問題時隨手記錄的一堆日志、命令輸出和猜測。適合的結構模板是問題現象是怎么暴露的、排查看過哪些環(huán)節(jié)、最終定位到哪一層、根因是什么、修復動作是什么、事后怎么驗證。這套結構之所以可靠是因為它完全復刻了排查問題的時間線。讀者順著時間線走一遍相當于跟著思路做了一次“思維實驗”對解決問題的理解深度遠超直接看結論。5.2 工具使用場景需求—選型—實操—注意事項這類內容常見于整理某個工具的使用心得。記錄中經?；祀s對多個工具的零散評價。整理時可按“最終選擇一個工具的過程”作為主軸為什么有這個需求、比較了哪些候選方案、為什么選了這個、核心操作步驟、用下來的注意事項。區(qū)別于單純的工具文檔要突出“為什么選它”的判斷依據。正因為這些判斷依據因人因場景而異文章才具備真正的參考價值。5.3 行業(yè)或領域觀察場景現狀—問題—趨勢—啟示這類內容素材來源更雜可能是幾篇文章的摘要、一些數據截圖、幾條個人思考。結構模板建議采用邏輯鏈條現狀描述——當前存在什么問題——問題背后推動著怎樣的變化趨勢——這種趨勢對從業(yè)者或用戶意味著什么。值得注意的是趨勢部分最容易寫出“正確的廢話”。應對方式是要放在具體的數據與現象上比如引用給定版本更新后的精確時間線、具體參數變化而不是泛泛而談“越來越重要”“迎來新的機遇期”。5.4 生活/職場經驗場景背景—做法—反饋—反思這類場景以個人經驗為主結構相對靈活。適合的模板是背景交代清楚當時的處境與目標、做法部分講清具體采取的行動、反饋部分說明實際效果、反思部分升華出可遷移的方法論。注意反思部分不要拔得太高。拔高失敗的典型跡象是出現類似“人生就是這樣只有在經歷后才能懂”的句子。有效的反思通常更具體針對某一類特定處境給出可以復用的判斷原則。6. 發(fā)布前的自查清單避免“寫完就忘”的常見小坑終于熬到正文完成先別急發(fā)布。發(fā)布前用幾分鐘做一次快速掃描能大幅減少文章里的低級錯誤與觀感問題。6.1 重讀一遍專挑“含糊其辭”的句子第一輪重讀目標明確找到文章中所有含糊其辭的表述?！按蟾拧薄耙苍S”“某種意義上”“往往”這類詞如果頻繁在一段話中密集出現通常意味著信息確定性不足。逐個追問這個大概是多少這個也許是什么條件下這個往往有多大比例回答不上來的就去補資料或者重新措辭讓表述更精確。一種例外確實無法精確表達的信息比如“不同環(huán)境表現可能有差異”這種地方保留模糊表述情有可原。但要確保這不是因為筆者偷懶。6.2 站在讀者視角檢查讀者能否按文操作很多技術分享的翻車現場都是這樣的文章全程描述方案很美好讀者按步驟操作后卻失敗了。翻車原因通常是細節(jié)缺失——某個前置條件沒交代、某個版本差異沒說清、某個隱藏步驟被跳過。寫完初稿后找一位符合目標畫像的朋友讓他在不咨詢你的前提下照做一遍。這種方式能在復現問題的同時把文章的缺陷暴露得很徹底。沒條件找人的話至少自己頭腦里完整過一遍操作流程把每一步前置條件、依賴、預期結果全部列出來逐項核對文中是否已覆蓋。6.3 格式細節(jié)統(tǒng)一代碼塊、標題層級、鏈接格式技術類博文對格式規(guī)范性的要求相對較高。盡量統(tǒng)一代碼塊的語法高亮標注二三級標題層級不要錯亂鏈接格式保持開放穩(wěn)定。發(fā)布到不同平臺時還要額外注意編輯器兼容性問題改版后格式錯亂的文章往往閱讀體驗嚴重下降。這輪檢查不需要太多時間但對文章的“職業(yè)感”貢獻極大。同樣是技術分享排版混亂與排版清晰的文章讀者評價差距是相當大的。6.4 心態(tài)管理不是每篇文章都必須完美最后這一點寫給完美主義傾向的博主博文不是論文允許有局限不必等所有細節(jié)都打磨到完美才發(fā)布。發(fā)布之后根據讀者評論和反饋隨時可以更新、修正、補充內容。這樣形成的“初稿—反饋—修訂”循環(huán)比憋大招一次性發(fā)布“完美”文章更健康也更有成長空間。話說回來真正寫出一篇干貨文章的最佳時機往往恰好是“無標題”文檔中存在大量素材的時候。因為素材本身就是最真實的經驗沉淀。反而等素材散失后再憑記憶硬寫寫出來的反而空洞。如果你手頭也躺著一批“無標題”文檔不妨現在挑一篇素材最多的按上面的思路從分類篩選開始到搭出骨架再到填充正文。過程中你會發(fā)現寫下第一行沒有想象中那么難關鍵思考到位后剩下的只是時間問題。