抄舊網站資料容易漏東西，重新生成文章也容易把手改的心血洗掉

這幾天主要在處理兩件事：幫忙生成網拍商品文案的工具，補上了一個新的舊網站資料來源，也修好了「重新整理內容會把手改的文字沖掉」這個問題；另外在自己的個人作品集網站上，發現一件可能要注意但還不急著動手的事。

只換真的變動的那句話，其他手改的文字不動

這個工具原本的用法是：填好商品資料，按一個按鈕，一次生成整篇貼文。但如果貼文寫好之後發現某個欄位要補或要改，以前唯一的做法就是整篇重新生成，若貼文先前已經手動微調過某些句子，重新生成會把這些手改的地方全部沖掉，等於白改了。

現在多了一個「更新」按鈕，邏輯是只挑出真的有變動的那個欄位所對應的句子去替換，其他手動改過的句子完全不動，而且會明確列出哪些句子是手動改過、這次沒被更新影響到的。

flowchart TD
    A[發現某個欄位要修改] --> B[以前：整篇重新生成]
    A --> C[現在：只換變動的那句話]
    B --> D[手改的文字也被沖掉]
    C --> E[手改的文字維持原樣]

任何一個會「重新產生」內容的工具，如果沒有特別設計成只改變動的部分，使用者辛苦調整過的內容隨時可能在下一次操作中被整篇蓋掉，而且通常不會有任何警告提醒你東西不見了。

note技術細節：更新功能的對齊方式

以段落 genKey 對齊、逐行比對，逐段產生抽成 buildSectionsFromValues()，「生成貼文」原本的整段輸出流程不變。商品卡：拖曳反白文字放開時不切換勾選、不重畫，反白可右鍵複製。商品尺寸多行保留：simplifySize() 改為每行各自套單行規則、保留各自標籤，以 / 串接。

抓一個很舊的日文網站資料，要先摸清楚它的怪規矩

工具要抓的其中一個網拍來源是 BONES 官方商店，一個做模型公仔的日本品牌網站。這個網站用的是很舊的網站技術，連文字編碼都是老式的日文格式，跟現在多數網站通用的編碼不一樣，等於是拿一台老式收銀機，你打的關鍵字它未必看得懂。

寫這支抓取程式時，特別處理了幾個容易出錯的地方：搜尋關鍵字要先轉換成這個網站看得懂的舊格式才抓得到東西；網站翻頁偶爾會失敗，失敗就重試一次，翻了很多頁還沒抄完，就先停下來標記「還沒抄完」，而不是假裝已經抄完；遇到商品已經下架、頁面找不到的情況，會老實回報抓不到，不會生出一筆假資料充數。另外有些商品沒寫清楚的預購截止日期，就改抓網頁上「到某個日期前訂購保證會準備好」這句話當作截止日期，這是我看過網站實際情況後自己決定的規則。

抓舊系統的資料，容易出錯的地方常常藏在查不到、翻頁卡住、資訊沒寫全這些邊邊角角的例外裡。這些狀況如果沒有事先想過，程式遇到時不會喊救命，只會默默給一個看起來正常、其實是錯的結果。

note技術細節：BONES 抓取程式的規則

scrapers/bones.js，對象是 ecbeing 系統的舊版頁面，編碼為 Shift_JIS。支援作品／分類／特集／搜尋／單品頁面。翻頁失敗重試一次並記錄 failedPages，超過 25 頁回傳 truncated。搜尋網址自動補 search=x，UTF-8 關鍵字轉 Shift_JIS 才能命中搜尋結果。沒有受付期間標示時，orderDeadline 取「…までのご予約で確実にご用意」日期。

部落格自動生成文章的排名風險，先看數據再決定要不要動

在整理部落格文章同步流程時，順手修正了一篇日誌裡誤打成簡體字的錯字，也順勢想到一個問題：這個部落格幾乎每天都會自動產生一篇開發日誌，搜尋引擎會不會因為看到網站每天冒出大量格式很相似的文章，就認定是灌水內容，進而調降網站的排名。

查了網站在搜尋引擎後台的數據，目前沒有看到被懲罰的跡象。我決定把這件事列成一個之後要追蹤的項目：先持續觀察數據，等看清楚趨勢、想好有哪些選項，再由我自己決定要不要調整。這件任務被我刻意排到年底之後才開工。

懷疑一個東西可能有風險，跟真的動手去改它，中間應該隔一個「先看數據」的步驟。沒有異常訊號的時候按兵不動，比憑感覺搶先修改更安全，改錯方向反而會製造新的問題。

note技術細節：延後處理的追蹤任務

P20 全部完成並歸檔（T-90 經本人同意後 push，正式站實測通過）。新開 P21／T-93，標記為阻塞，預計 2026-12-19 之後才開工。內容是查 Search Console 上 /blog/ai-log-* 系列文章的表現數據，列出可能的處理選項交由本人裁決，目前不預先改動任何設定。

接下來

追蹤部落格文章的搜尋引擎數據，年底再決定要不要調整每日自動發文的方式
尚未驗證：BONES 這個新加入的抓取規則，在長期大量使用下是否都能穩定運作

本篇由跨專案自動彙整產生，素材為 2026-09-19 之後 2 個專案的提交紀錄與 0 則知識投遞。