北京
同樣是拿到一個域名，期望輸出干凈的公司檔案——名稱、簡介、行業、社交賬號、聯系方式、位置——有人說，這不過是把頁面扔給大模型，一行調用的事。另一些人則早已踩過坑：你永遠不知道下一個域名背后，是停放頁、三層點擊才露面的聯系信息，還是返回空殼的JavaScript應用。雙方的分歧其實指向同一個事實：模型很少是瓶頸，頁面發現、缺失值和校驗才是。
最初級的演示確實誘人：抓取首頁，將HTML原樣喂給大語言模型，直接拿到JSON。在 stripe.com 這類結構清晰的站點上，效果無可挑剔。但一旦換成一個連內容都沒有的停放域名，或者聯系地址塞在某個深層路徑下，前面那套“一招鮮”立刻失效。模型面對缺失信息時，習慣性地猜測一個“看起來合理”的值，比如填一個符合區號的電話號碼，而不是返回 null。這時，整個流水線的可信度就崩塌了。
這個問題的解法，并不是去找更聰明的模型。真正讓工作流脫胎換骨的，是一個思維切換：讓模型能低成本地誠實。如果頁面上根本沒有顯示電話，最正確的答案就是 null，而不是一個碰巧拼湊出來的幻覺。基于這條原則，一套四步流程就能把從域名到公司檔案的轉化，從“碰運氣”推向可批量運行。
第一步是規范化域名。輸入的形態遠比你想的混亂：companyenrich.com、https://companyenrich.com、www.companyenrich.com/，這些變體都需要收斂成統一的 https:// 加凈域名，不帶尾斜杠。用 Python 的 urlparse 拆解再拼回即可，不用引入任何額外依賴。
第二步是抓取，并且刻意保留頁腳。許多網頁抓取工具默認開啟“僅正文提取”，會丟棄頭部、導航和頁腳。這對文章閱讀是福音，對公司信息提取卻是災難，因為社交鏈接、聯系電話、地址往往就藏在頁腳中。使用 Firecrawl 時，需要將 onlyMainContent 設為 false，并開啟 removeBase64Images 和 blockAds 以減少噪音。此外，單靠首頁通常不夠。同一輪抓取返回的鏈接中，優先匹配同域名下包含 /about、/company、/contact、/locations、/team 等關鍵詞的頁面，作為輔助頁面加入，數量控制在2-3個。
第三步是用大語言模型提取結構化字段。將拼接好的多頁 Markdown 文本截斷到每頁12000字符以內，調用 OpenAI 的結構化輸出接口，字段名稱明確，要求模型在信息缺失時輸出 null。這里的關鍵是，提示中要顯式聲明“如果頁面沒有提供某信息，必須返回 null，不要編造”，而不是僅僅依賴模型對指令的模糊遵守。這一步的代碼就是一段純 HTTP 請求，不依賴任何特定的編程語言SDK，因此可以輕松遷移到Node、Go或其他環境。
第四步是校驗和結果決策。提取出來的原始JSON需要經過規則校驗，例如判斷網址是否歸屬公司官方域、社交鏈接是否確實指向公司賬號。更重要的是，建立一套打分機制：當核心字段（名稱、行業、至少一種聯系方式）的置信度較低時，自動觸發人工審核或直接標記為數據不足。這套流程的終點，不是強行產出看似完整的檔案，而是產出有明確置信邊界的檔案。
那些一開始把這件事想得極為簡單的人，和那些踩過坑后傾向于自己搭建全套系統的人，本質上是在兩個極端之間拉扯。可行的判斷反而更務實：當支持頁面已經窮盡同域名下的線索，當模型已經按要求返回 null 而不是幻覺，剩下缺失的信息可能原本就不在公開網頁上。到了這個節點，繼續投入工程資源自己構建，邊際收益就迅速衰減。能讓模型誠實地說“不知道”，遠比讓它猜出一份漂亮的謊言更有價值。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
