這兩年我越來越受不了瀏覽器收藏夾了。收藏了一堆網(wǎng)頁真正要找的時(shí)候卻搜不到好不容易翻出來打開一看不是鏈接失效就是頁面改版內(nèi)容早就不是當(dāng)初那樣子了。后來我把思路換了一下與其“收藏一個(gè)網(wǎng)址”不如“下載一份內(nèi)容”。這個(gè) skills 干的事就非常直接把網(wǎng)頁正文抓下來轉(zhuǎn)成干凈的 Markdown 文件存到本地目錄里。全文可搜、可復(fù)制、可備份永久屬于你自己。如果你經(jīng)常需要整理技術(shù)資料、做知識(shí)管理或者單純對(duì)“收藏夾吃灰”這件事忍無可忍那這篇內(nèi)容應(yīng)該很適合你。我會(huì)把整個(gè)技能包的思路、核心實(shí)現(xiàn)、實(shí)操流程和踩坑經(jīng)歷都拆開來講盡量讓你看完就能自己動(dòng)手搭一套。1. 項(xiàng)目概述從“收藏網(wǎng)址”到“保存內(nèi)容”的轉(zhuǎn)變1.1 核心需求解析我先說下這個(gè) skills 解決的痛點(diǎn)。瀏覽器收藏夾本質(zhì)上保存的只是一個(gè) URL它假設(shè)網(wǎng)絡(luò)資源是永恒的。但現(xiàn)實(shí)里網(wǎng)頁每天都在變鏈接會(huì)失效排版會(huì)調(diào)整內(nèi)容會(huì)被刪除甚至整個(gè)網(wǎng)站都會(huì)關(guān)閉。你的收藏夾看似存了一堆“有用信息”實(shí)際上一打開全是 404、410、或者面目全非的首頁。用這個(gè) skills 保存網(wǎng)頁核心邏輯就一句話把網(wǎng)頁里的正文內(nèi)容抽取出來轉(zhuǎn)換成一站式 Markdown 文件存儲(chǔ)到本地。這樣做有幾個(gè)立竿見影的好處內(nèi)容不依賴原網(wǎng)站的生命周期斷網(wǎng)、關(guān)站、改版都影響不到你。Markdown 文件是純文本格式Grep 全文搜索效率極高日常檢索比在瀏覽器里翻收藏夾快得多。文件體積小方便同步配合云盤或 NAS 可以實(shí)現(xiàn)跨設(shè)備統(tǒng)一知識(shí)庫。方便二次加工你可以把保存下來的內(nèi)容直接喂給其他工具做整理、摘要、翻譯。這本質(zhì)上是一次信息管理習(xí)慣的升級(jí)。你不是在記一個(gè)位置而是在抓一個(gè)內(nèi)容。很多知識(shí)管理愛好者最終都會(huì)走到這一步區(qū)別只是有人用第三方工具有人自己寫一套完整方案。1.2 技能包整體形態(tài)這里說的 skills是一個(gè)結(jié)構(gòu)化的“網(wǎng)頁轉(zhuǎn) Markdown 處理技能包”整體邏輯圍繞“輸入 URL、解析正文、輸出 Markdown 文件”這條主線展開。它的設(shè)計(jì)目標(biāo)是既獨(dú)立可用又能作為通用處理組件嵌入其他工作流。一個(gè)可行的技能包內(nèi)部結(jié)構(gòu)可以這樣拆解獲取模塊負(fù)責(zé)抓取目標(biāo)網(wǎng)頁原始 HTML處理請(qǐng)求頭、編碼、重試邏輯。解析模塊識(shí)別正文主體剔除導(dǎo)航、廣告、推薦、頁腳等噪音區(qū)塊。轉(zhuǎn)換模塊將清洗后的 HTML 結(jié)構(gòu)化轉(zhuǎn)為 Markdown保留代碼塊、表格、圖片引用、鏈接錨點(diǎn)。存儲(chǔ)模塊生成帶日期的標(biāo)題、規(guī)范文件路徑、寫入本地目錄同 URL 重復(fù)保存時(shí)自動(dòng)做內(nèi)容去重或版本追加。校驗(yàn)?zāi)K保存后反饋標(biāo)題、字?jǐn)?shù)、圖片數(shù)量、保存路徑等摘要信息。實(shí)際運(yùn)行效果就是你把一個(gè) URL 交給這個(gè)技能它會(huì)在幾秒內(nèi)完成抓取、清洗、轉(zhuǎn)換和落盤然后告訴你“內(nèi)容已保存在哪個(gè)文件里”。整個(gè)過程沒有任何多余交互沒有一鍵收藏之后還要手動(dòng)整理的麻煩。2. 技術(shù)選型與方案設(shè)計(jì)思路2.1 正文抽取為什么不能直接“另存為 HTML”很多人會(huì)用瀏覽器的 CtrlS 把網(wǎng)頁存下來但那樣得到的 HTML 文件里全是導(dǎo)航、側(cè)欄、腳本和樣式表一個(gè)普通文章頁存出來的 HTML 可能有幾百 KB真正有用的正文只占很小一部分。這樣保存的內(nèi)容既難以閱讀也不利于后續(xù)檢索。這個(gè)技能的核心難點(diǎn)正是如何準(zhǔn)確識(shí)別正文主體。咱們不能用簡單的正則去切 HTML那樣太脆弱了。頁面結(jié)構(gòu)五花八門靠固定規(guī)則匹配很快就會(huì)失效。實(shí)際方案里更值得采用的方式是在 Python 環(huán)境里使用結(jié)構(gòu)化解析庫來識(shí)別主體區(qū)塊。比如用 Trafilatura 這類專門針對(duì)文本抽取的庫它內(nèi)部實(shí)現(xiàn)了一整套內(nèi)容評(píng)分和區(qū)塊權(quán)重的邏輯能夠根據(jù) HTML 的結(jié)構(gòu)分布來判斷哪一塊是正文哪一塊是導(dǎo)航、評(píng)論、推薦。它會(huì)把主要文本內(nèi)容、文章標(biāo)題、發(fā)布日期一起提取出來輸出結(jié)果相對(duì)干凈。選型上不要選重型瀏覽器內(nèi)核比如無頭瀏覽器雖然它能處理復(fù)雜動(dòng)態(tài)頁面但資源開銷非常大每次抓取起一個(gè)瀏覽器進(jìn)程速度和穩(wěn)定性都難以兼顧。我實(shí)際用下來的體驗(yàn)是對(duì)絕大多數(shù)文章類頁面輕量級(jí)請(qǐng)求加上結(jié)構(gòu)抽取就夠了只在少數(shù)動(dòng)態(tài)渲染頁面時(shí)才需要降級(jí)到無頭瀏覽器方案。2.2 Markdown 轉(zhuǎn)換鏈路設(shè)計(jì)拿到正文 HTML 之后下一步是把 HTML 轉(zhuǎn)換成 Markdown。這一步的技術(shù)點(diǎn)不在于“逐字翻譯標(biāo)簽”而在于保留內(nèi)容的語義結(jié)構(gòu)。舉幾個(gè)實(shí)際轉(zhuǎn)換中的細(xì)節(jié)問題代碼塊的呈現(xiàn)需要保留語言類型標(biāo)識(shí)以及每一行縮進(jìn)。表格結(jié)構(gòu)要正確映射成 Markdown 表格語法錯(cuò)一個(gè)分隔線整張表就亂了。圖片標(biāo)簽不能直接丟棄。其中的src屬性可能是相對(duì)路徑需要拼接成絕對(duì) URL否則保存下來的 Markdown 文件換個(gè)路徑打開圖片就掛了。多級(jí)標(biāo)題層級(jí)必須規(guī)范映射不能出現(xiàn)文章里h2跳到h6這種混亂。鏈接中的特殊字符需要處理避免 Markdown 語法沖突。思想上可以把它分成兩個(gè)階段先是“識(shí)別內(nèi)容”再是“無損轉(zhuǎn)寫”。HTML 是一種標(biāo)記語言自帶結(jié)構(gòu)層級(jí)。轉(zhuǎn) Markdown 的過程其實(shí)是在結(jié)構(gòu)層面做語言翻譯而不是在文本層面做字符替換。2.3 數(shù)據(jù)清洗與存儲(chǔ)策略清洗是整個(gè)流程里最有技術(shù)含量的一環(huán)。我們最終要的不是“網(wǎng)頁里所有內(nèi)容”而是“用戶值得保留的內(nèi)容”。這一步做得好不好直接決定保存下來的文件是知識(shí)資產(chǎn)還是帶格式的垃圾。清洗策略可以按優(yōu)先級(jí)設(shè)計(jì)優(yōu)先剔除頁面模板代碼比如導(dǎo)航欄、面包屑、底部推薦欄。然后識(shí)別并處理廣告區(qū)塊通過常見廣告模塊標(biāo)識(shí)和文本特征綜合判斷。再處理社交組件比如分享按鈕、評(píng)論框這類對(duì)離線閱讀毫無價(jià)值的內(nèi)容。最后做文本密集型區(qū)域評(píng)分如果一個(gè)區(qū)域同時(shí)滿足“文字量大”“密度高”“層級(jí)連續(xù)”就保留否則降權(quán)或丟棄。存儲(chǔ)策略上文件名可以遵循{域名}-{日期}-{標(biāo)題片段}.md的格式。只存日期可以避免文件名過長但沒法區(qū)分同一天保存的同域名內(nèi)容。所以我個(gè)人更推薦{日期}-{時(shí)間}-{域名}-{標(biāo)題片段}.md既保留時(shí)間軸信息也能有效防重名。在同一天對(duì)同一頁面做多次保存時(shí)還可以通過后綴-1、-2來自動(dòng)遞增版本避免相互覆蓋。清洗和存儲(chǔ)這兩個(gè)環(huán)節(jié)別看優(yōu)先級(jí)低它們決定的是整個(gè)知識(shí)庫的底座質(zhì)量。就算抓取和轉(zhuǎn)換做得再完美只要凈化和歸檔策略不靠譜時(shí)間長了知識(shí)庫照樣變成一鍋粥。3. 實(shí)操過程搭建并運(yùn)行一套完整的網(wǎng)頁轉(zhuǎn) Markdown 技能包3.1 環(huán)境準(zhǔn)備與依賴安裝這個(gè)技能包的運(yùn)行環(huán)境以 Python 為主選擇它的原因是生態(tài)完善從網(wǎng)絡(luò)請(qǐng)求、內(nèi)容抽取到格式轉(zhuǎn)換都有成熟庫支持幾乎不需要從零寫底層邏輯。推薦的基礎(chǔ)依賴組合是這樣Python 3.10 及以上版本類型注解和語法糖都有改善調(diào)試更省心。requests用于抓取網(wǎng)頁原始 HTML。它在處理 header、超時(shí)和重試這些基礎(chǔ)問題上已經(jīng)非常穩(wěn)定。trafilatura作為核心正文抽取庫它能返回干凈的文本和結(jié)構(gòu)信息。html2text處理 HTML 到 Markdown 的轉(zhuǎn)換。它對(duì)手工配置的源碼依賴度低在很多邊界情況上的處理都比自己寫的正則可靠。beautifulsoup4用于自定義清洗邏輯時(shí)的兜底解析。selectorlib 或 lxml在部分頁面需要“點(diǎn)名抓取”特定區(qū)域時(shí)用得上。安裝時(shí)用虛擬環(huán)境隔離依賴會(huì)省掉很多麻煩。直接pip install trafilatura html2text beautifulsoup4然后把三個(gè)庫裝到統(tǒng)一環(huán)境里后面的開發(fā)調(diào)試會(huì)順暢很多。不同庫之間可能會(huì)有依賴版本沖突虛擬環(huán)境可以從源頭避免這類“改一個(gè)庫動(dòng)一堆依賴”的問題。3.2 核心模塊實(shí)現(xiàn)細(xì)節(jié)技能包的核心處理流程可以分成幾個(gè)函數(shù)分別負(fù)責(zé)請(qǐng)求、抽取、轉(zhuǎn)換、存儲(chǔ)。請(qǐng)求部分可以這樣實(shí)現(xiàn)import requests def fetch_html(url: str) - str: headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, } response requests.get(url, headersheaders, timeout20, verifyTrue) response.raise_for_status() response.encoding response.apparent_encoding return response.text響應(yīng)統(tǒng)計(jì)是博客正文不要將請(qǐng)求部分的代碼示例直接放在正文中間應(yīng)該放在合適的位置例如放在案例展示或代碼塊中。正文不要過度描述代碼段。 我來修正代碼塊可以放在正文里但不要讓正文流水賬式描述代碼。以下代碼塊就放在實(shí)操環(huán)節(jié)合適的位置。核心抽取和轉(zhuǎn)換邏輯可以這樣寫import trafilatura import html2text def extract_and_convert(html: str) - dict: extracted trafilatura.extract( html, include_commentsFalse, include_tablesTrue, output_formatmarkdown, with_metadataTrue, ) if extracted: return {success: True, content: extracted} bare_html trafilatura.extract(html, output_formathtml) if bare_html: markdown html2text.html2text(bare_html) return {success: True, content: markdown} return {success: False, content: }這里有一個(gè)容易被忽略的點(diǎn)trafilatura的默認(rèn)抽取結(jié)果已經(jīng)是 Markdown 格式了它底層已經(jīng)做了一輪清洗。但如果抽取失敗就需要先用bs4做一次簡單的正文定位再交給html2text兜底轉(zhuǎn)換。兩個(gè)庫搭配起來能覆蓋更廣的場景幾乎不會(huì)出現(xiàn)完全抽不出來的情況。存儲(chǔ)部分的關(guān)鍵是路徑規(guī)范化和同名防覆蓋。from pathlib import Path import urllib.parse import re def sanitize_filename(name: str) - str: name re.sub(r[\\/:*?|], , name) return name.strip() or untitled def save_markdown(url: str, content: str, out_dir: str clippings) - str: Path(out_dir).mkdir(parentsTrue, exist_okTrue) domain urllib.parse.urlparse(url).netloc.replace(www., ) first_line content.strip().splitlines()[0] if content.strip() else 無標(biāo)題 title sanitize_filename(first_line[:40]) from datetime import datetime ts datetime.now().strftime(%Y%m%d-%H%M%S) path Path(out_dir) / f{domain}-{ts}-{title}.md path.write_text(content, encodingutf-8) return str(path)文件名帶了時(shí)間戳大部分場景下不會(huì)重名。但同一秒內(nèi)多次保存還是有極小概率沖突穩(wěn)妥一點(diǎn)的方案是把文件路徑作為鍵值存到一個(gè)索引庫里保存前先查一次。簡易方案上用timestamp加毫秒后綴也能解決。3.3 運(yùn)行時(shí)參數(shù)配置實(shí)際運(yùn)行技能包時(shí)合理配置參數(shù)能很大程度上避免各種詭異問題。我整理出幾個(gè)關(guān)鍵參數(shù)及其建議值參數(shù)建議值配置理由請(qǐng)求超時(shí)20 秒超過這個(gè)時(shí)間放棄避免卡死整個(gè)處理流程單次保存重試最多 3 次網(wǎng)絡(luò)抖動(dòng)時(shí)能自動(dòng)恢復(fù)但要限制次數(shù)防止無限空轉(zhuǎn)文件編碼UTF-8統(tǒng)一編碼才能避免后續(xù)跨設(shè)備讀寫時(shí)亂碼正文長度下限200 字符低于這個(gè)閾值大概率是重定向頁或驗(yàn)證碼頁不值得保存圖片處理默認(rèn)保留 URL本地化圖片需要額外下載和路徑替換默認(rèn)不開啟日志級(jí)別也是一個(gè)容易被忽略的參數(shù)。開發(fā)時(shí)用DEBUG能看清每一次請(qǐng)求和抽取的細(xì)節(jié)但到了批量處理場景INFO級(jí)別就夠了每保存一篇輸出一行記錄出問題時(shí)再針對(duì)單條 URL 單獨(dú)調(diào)試。這個(gè)習(xí)慣能幫你省下大量排查時(shí)間。3.4 運(yùn)行效果與產(chǎn)物示例跑一次完整流程假設(shè)輸入 URL 是一篇技術(shù)博客的文章頁輸出結(jié)果大致長這樣/知識(shí)庫/技術(shù)資料/blog.example.com-20240218-153000-理解分布式系統(tǒng)一致性.md文件內(nèi)容開頭通常是博客標(biāo)題和原文鏈接# 理解分布式系統(tǒng)一致性 原文鏈接https://blog.example.com/posts/distributed-consistency 保存時(shí)間2024-02-18 15:30 由 web2md 技能自動(dòng)保存 ## 什么是一致性 分布式系統(tǒng)的一致性是指多節(jié)點(diǎn)間數(shù)據(jù)狀態(tài)能否在同一時(shí)刻對(duì)用戶表現(xiàn)為一致...這樣保存下來的文件可以直接放進(jìn)任何 Markdown 閱讀器也可以在 Obsidian 這類知識(shí)管理工具里做雙鏈連接。由于內(nèi)容是純文本全文搜索響應(yīng)極快一篇一萬字的文章搜索耗時(shí)幾乎可以忽略不計(jì)。4. 常見問題與排查技巧實(shí)錄4.1 抓取結(jié)果為空正文識(shí)別失敗這個(gè)是我遇到最多的問題。部分網(wǎng)站使用前端框架渲染內(nèi)容初始 HTML 里只有一段 JS 腳本正文是瀏覽器執(zhí)行腳本后才出現(xiàn)的。這種情況用純 requests 抓返回的 HTML 里壓根沒有正文trafilatura 自然抽不出內(nèi)容。排查這類問題可以先手動(dòng)把頁面源碼拉下來用文本編輯器搜文章標(biāo)題或開頭的某句話如果能搜到說明 HTML 里有正文只是抽取配置不合適如果搜不到說明正文確實(shí)是動(dòng)態(tài)渲染出來的。對(duì)于動(dòng)態(tài)頁面有兩種降級(jí)方案第一種是尋找頁面的 RSS 輸出或 API 接口很多內(nèi)容型網(wǎng)站都有真實(shí)內(nèi)容源比爬 HTML 穩(wěn)定得多。第二種是調(diào)用無頭瀏覽器級(jí)別的內(nèi)容渲染服務(wù)讓腳本先執(zhí)行完再拿渲染后的 DOM 作為輸入。萬不得已才用這個(gè)方案因?yàn)樗_銷大、速度慢。還有一種隱蔽情況部分網(wǎng)站開啟了內(nèi)容壓縮或混淆HTML 里全是轉(zhuǎn)義字符肉眼看到的就是一堆亂碼但實(shí)際內(nèi)容是完整的。這種情況通過html.unescape()或調(diào)整編碼檢測邏輯就能解決。4.2 保存后 Markdown 表格或代碼塊混亂有段時(shí)間我保存不少技術(shù)教程發(fā)現(xiàn)代碼塊里的縮進(jìn)全沒了四個(gè)空格變成兩個(gè)再一打開整個(gè)代碼結(jié)構(gòu)都塌了。排查下來發(fā)現(xiàn)問題出在 HTML 到 Markdown 轉(zhuǎn)換時(shí)代碼塊內(nèi)的空白字符被壓縮處理了。代碼塊這類格式化文本必須保留原始空白。html2text默認(rèn)行為在部分版本上對(duì)代碼塊空白處理不夠穩(wěn)妥遇到這種情況可以做兩步處理先用pre標(biāo)簽把原始內(nèi)容單獨(dú)提取出來手動(dòng)拼接到 Markdown 代碼塊里再讓其他部分走庫轉(zhuǎn)換邏輯。表格混亂的情況通常是表頭分隔線錯(cuò)位根源在于各列內(nèi)容長度不齊時(shí)有些轉(zhuǎn)換庫對(duì)分隔線計(jì)算有 bug。只要最終產(chǎn)物是自己用的沒必要追求完美對(duì)齊Markdown 渲染器本來就會(huì)自動(dòng)適配。真遇到打不開的情況用支持寬松解析的編輯工具就行。4.3 圖片保存不完整默認(rèn)策略下圖片只是保留原文 URL。這樣做的最大問題是如果原網(wǎng)站做了防盜鏈Markdown 文件里的圖片會(huì)全部失效文本內(nèi)容保留下來了圖全掛了。如果你對(duì)圖片有強(qiáng)需求可以在技能包里加一個(gè)--save-images參數(shù)開啟后把圖片下載到文章同目錄的assets文件夾并將 Markdown 里的引用路徑改寫為相對(duì)路徑。這樣整篇文章就是完全獨(dú)立的切到任何設(shè)備都能正常打開。但要注意兩點(diǎn)一是圖片下載會(huì)顯著拖慢整體速度尤其是一篇包含幾十張圖的文章二是部分圖源對(duì)請(qǐng)求頭有校驗(yàn)直接 requests 抓會(huì)被拒需要帶上 Referer 偽裝成瀏覽器行為。第一次批量跑的時(shí)候圖全掛了一次后來加了 Referer 就正常了。4.4 同名文件覆蓋歷史版本丟失如果你沒有在文件名里加入時(shí)間戳只用了標(biāo)題做文件名那同一個(gè)頁面多次保存時(shí)后來者會(huì)把前面的文件直接覆蓋掉。你辛辛苦苦保存的內(nèi)容最后只剩最后一次的狀態(tài)。解決方式除了文件名加時(shí)間戳還有一個(gè)更嚴(yán)謹(jǐn)?shù)乃悸繁４鏁r(shí)給每個(gè)文件寫一段前置元信息包括原始 URL、保存時(shí)間、內(nèi)容哈希值。下次保存同一 URL 時(shí)先比對(duì)哈希如果內(nèi)容和上次完全一致就跳過如果內(nèi)容更新了就存成一個(gè)新版本文件保留歷史記錄展示演進(jìn)過程。我最終在技能包里實(shí)現(xiàn)的邏輯很簡單第一次見到的 URL 直接存。再次出現(xiàn)時(shí)計(jì)算內(nèi)容哈希相同則提示已存在。內(nèi)容不同則存為文件名-v2.md并預(yù)留一個(gè)index.md匯總所有版本。這套邏輯下來知識(shí)庫永遠(yuǎn)不會(huì)因?yàn)橹貜?fù)操作而丟失歷史內(nèi)容。5. 這個(gè)技能包的進(jìn)階使用場景5.1 批量歷史收藏夾遷移理論上講任何有著長期收藏習(xí)慣的人都可能積累了幾百甚至上千條收藏記錄。手動(dòng)一條條保存是不可能完成的任務(wù)但技能包可以批量處理。做法是把瀏覽器書簽導(dǎo)出成 HTML 文件解析里面的鏈接列表排重后逐條交給技能包處理。跑一次全量保存原來的收藏夾就變成了本地知識(shí)庫。唯一要留意的就是請(qǐng)求頻率控制連續(xù)快速抓取容易觸發(fā)目標(biāo)站點(diǎn)的風(fēng)控機(jī)制所以必須在技能包里加一個(gè)每請(qǐng)求間隔策略比如單條之間停頓兩秒如果碰到大量 429 響應(yīng)就自動(dòng)降低速度。這種批量場景下技能的穩(wěn)定性反而比單條抓取質(zhì)量更重要。跑一半失敗了要能斷點(diǎn)續(xù)跑所以保存索引很關(guān)鍵已經(jīng)處理過的 URL 要記錄在一個(gè)本地狀態(tài)文件里下一次啟動(dòng)時(shí)從中斷位置繼續(xù)。5.2 定時(shí)增量抓取動(dòng)態(tài)內(nèi)容源有些網(wǎng)頁內(nèi)容會(huì)定期更新比如官方文檔、技術(shù)周刊、產(chǎn)品更新日志與其每次手動(dòng)訪問不如讓技能包定時(shí)跑一遍更新過的文章自動(dòng)出新版本沒有變化的自動(dòng)跳過。整體思路類似于一個(gè)輕量級(jí)的網(wǎng)頁監(jiān)控功能。技能包每次跑完后把當(dāng)前時(shí)間和內(nèi)容摘要記錄到索引文件里。下次運(yùn)行前先判斷文章是否已存在且內(nèi)容未變化。如果是直接跳過完全無感。這個(gè)場景下的核心收獲是技能從“被動(dòng)保存工具”變成了“主動(dòng)內(nèi)容追蹤器”。間隔多長時(shí)間跑一次取決于內(nèi)容更新頻率文檔類適合一天兩次新聞?lì)惪梢砸恍r(shí)內(nèi)多次。5.3 與知識(shí)管理工具聯(lián)動(dòng)本地保存只是第一步Markdown 文件真正發(fā)揮威力是在知識(shí)管理工具里。你完全可以把技能包的輸出目錄直接掛到筆記類軟件的數(shù)據(jù)庫目錄下實(shí)現(xiàn)“瀏覽器端自動(dòng)裁剪知識(shí)庫端自動(dòng)入庫”的閉環(huán)。進(jìn)階方案可以再走一步在技能包里加一段智能處理邏輯自動(dòng)給保存的文章生成標(biāo)簽和關(guān)鍵詞摘要。用自然語言處理的方式對(duì)正文做高頻詞提取和主題歸類然后在文件開頭補(bǔ)充一段 YAML 前置元數(shù)據(jù)。這樣筆記工具打開時(shí)文章的標(biāo)簽、創(chuàng)建時(shí)間、來源鏈接全都能自動(dòng)化呈現(xiàn)。我實(shí)際使用中發(fā)現(xiàn)這個(gè)組合配合全文搜索功能比任何瀏覽器插件的“稍后讀”都好用資料管理效率明顯提升。最后再分享一點(diǎn)個(gè)人體會(huì)這套技能包我從第一版到最終穩(wěn)定用了很長時(shí)間中間踩了不少坑。如果你打算親手搭一套我最大的建議是永遠(yuǎn)不要低估網(wǎng)頁結(jié)構(gòu)的復(fù)雜性。你看到的是十篇文章的共性結(jié)構(gòu)但你保存的是互聯(lián)網(wǎng)上那剩下的百分之十的畸形頁面。清洗和兜底方案不是錦上添花它們是整個(gè)系統(tǒng)的地基。另外一個(gè)值得養(yǎng)成的習(xí)慣是“保存時(shí)多想一步”。打開鏈接看到內(nèi)容你只有一瞬間決定要不要保存。這個(gè)瞬間里如果操作足夠簡單、足夠快你就更愿意把它留下來。技能包的設(shè)計(jì)目標(biāo)就是把這個(gè)動(dòng)作壓縮到幾乎無感。與其花時(shí)間翻找網(wǎng)址不如讓內(nèi)容直接落到磁盤里想用的時(shí)候隨手就能搜到。別再用瀏覽器收藏了把內(nèi)容真正留在自己手里這種感覺只有試過才知道。