你已經有的越多，新工具能給的越少
五月中評估一個叫 planning-with-files 的熱門工具，第一輪分析我列了 8 個值得借鑑的點，其中一個還標成最高優先。深查下去，四個招牌賣點全部站不住。小丑竟是我自己🤣
回頭看，問題出在順序：我先讀工具的 README 列亮點，再回頭找自己哪裡可以對接，整個人被亮點吸引。我原本以為自己在做評估，後來才發現是在幫工具找理由。這篇講的就是從這次誤判修出來的評估方法，後來陸續走了近二十案，順手固化成一個 skill 叫 check-my-stack。
順序就是方法的全部
讀工具的賣點之前，先列出自己在這個領域已經有什麼、各自多成熟，再把賣點一條一條對上去。每個賣點還剩多少價值，看的是你手上等價物的成熟度。手上的版本越成熟，工具剩下能給你的越少，常常不剩什麼。
順序顛倒就是起源案那次的死法。先看亮點再找對接點，每個亮點看起來都很香；先盤點自己再看亮點，四個招牌賣點當場垮掉。同一個工具、同一個人、同一天，只差順序。
為什麼大多數工具到我這就不剩什麼
我的解釋是：通用工具解決的是大眾市場的痛點，也就是「沒有紀律化的個人基礎設施」。plan 工具、memory 工具、session 工具、hook 工具，全都在解這個。對一個已經自己把這些東西建起來、寫了規則、還留了紀錄的人，這個痛點不存在，我手上的版本往往比工具更整合。所以走完整框架的評估，絕大多數收斂成「競品觀察」，少數剩一點薄殘值。
要先講清楚一件事：這個前提對我成立，對你不一定。基礎設施還在起步的人，手上等價物少，同一個工具可能真的有用。但「先盤點自己、再看工具」這個順序對誰都成立，差別只在算出來的答案分布。
比零更糟的那一種
工具剩下的價值不只「零或不零」兩種，還有一種是負的：它的差異化賣點，剛好是你已經反覆否決、結案的路線。評估它等於重付一次已經付過的研究成本。
代表案是 obsidian-second-brain，43 個指令把筆記庫變成會自我改寫的 AI 第二大腦。周邊功能像研究、行事曆、session 管理，我各自有更整合的版本，這部分歸零；而它最得意的賣點「筆記自我改寫、自動整併、夜間 agent」，正是我反覆否決、已經結案的 LLM 整併式記憶這條軸。同一條軸被不同包裝重複撞上：這條軸裡 mempalace 是我唯一親手用過再退役的（已經寫成這系列第一篇），claude-soul、後面會講的 ECC 自動萃取功能，還有好幾個同路線的，全是紙上評估直接套先例結論。差異化越強，對我越負。
唯一親手裝過再移除的：ECC
affaan-m/ECC 則是走完整框架的近二十案裡，唯一裝過、用過、再親手移除的，2026 年 4 月 24 號移除有 commit 紀錄。一個月後它又紅回我的時間軸，重評確認三件事：
- 我現有的規則目錄有一部分根本蒸餾自它，好幾個自製指令對得上它舊版的 changelog。意思是借鑑早就做完一輪了，「曾經從它學到東西」跟「現在不需要它」同時成立。
- 新版比當年裝的更大包：skill 數 119 變 232、agent 數 28 變 60，還要在背景常駐跑一個管理服務來統籌這些東西，方向跟我「流程固化成 skill、不蓋整套框架」的姿態相反。
- 主打的自動萃取功能，撞上面說的記憶整併軸。
順帶看健康度：commit 數第一名 1415、第二名 47，單人主導；付費方案加贊助漏斗一應俱全。這類訊號跟功能列表一樣要看——它們決定的是你敢不敢把日常流程押在這個專案上。
我後來真的只看三件事
完整流程有六步，壓縮起來是三件事。
硬性門檻：讀工具 README 之前，先列自己已有什麼、多成熟。清單裡最強的訊號是「試過又移除的工具，加上記錄在案的理由」。
算式：每個賣點對「我已有的等價物」算還剩多少。盤點時會浮出自己在這個領域唯一的真缺口，直接問工具補不補「那個」缺口，不補就不准用「補缺口」當理由。
反面清單：先列亮點再找對接、不看成熟度的裸借鑑清單、沒對到真缺口就喊補缺口、虛構先例幫工具背書。每一條都是踩過或差點踩的。
問「補不補缺口」這關，我自己踩過兩個彎。
一個是缺口會認錯。評估 qiaomu-anything-to-notebooklm 的時候，我嘴上說缺的是一種東西，工具實際補的是另一種，差點把「它有補東西」當成「它補了我的缺」。先弄清楚自己缺的到底是哪一類，再判斷工具對不對得上。順帶一提，它宣稱有 6 層處理流程，翻原始碼才發現其中兩層是永遠執行不到的死碼，實際只有 4 層——工具宣稱「幾層、幾階段」這種數字，要翻過原始碼才算數。
另一個是「沒有」不等於「缺」。評估 Agent-Reach 時我發現自己管線裡有個資料來源壞了很久，一直沒人修。沒修這件事本身就是答案：真的痛，早就動手修了。所以工具能補上的空白，不代表那是你的痛點。
它不是只會說不
收斂判決有三類：可以改變現狀的候選、只剩薄殘值、競品觀察。前兩類也真實發生過：
- Agent-Reach：本體不裝，但抽出其中一個零依賴的公開 API 端點，寫進自家管線。罕見的部分採用案。
- alibaba/open-code-review：本體不採用，但它的確定性工程層（純資料加規則、不靠 LLM）可以偷，已經衍生出自家工具的增強試用。
- brooks-lint：只偷 6 個分類學詞彙，嫁接進既有的 reviewer。
- headroom：罕見親手跑過 dry-run 量化的案，最後否決的理由是整合架構風險，跟壓縮品質無關。
注意這些殘值幾乎都是「偷架構、不裝工具」。殘值是一個獨立工作項，當不了引入工具的理由。
真的要照做，我自己的最小版本是三欄：我已經有什麼；工具的每個賣點對應到哪一欄；剩下的那點殘值，是採用、偷架構，還是只記一筆競品觀察。
數字要誠實
寫這篇的時候，我自己差點灌了一次數字。記憶整併那條軸我否決過很多次，本來想寫成「我否決了十幾個記憶工具」，講起來很像戰績。但回頭數，真正親手裝過、用過、再否決的只有 mempalace 一個，其餘全是讀文件、讀原始碼的紙上評估，連裝都沒裝。否決的「次數」跟親身踩坑的「個數」是兩回事，混著講就是灌數字。
所以這篇出現的每個數字，我都講清楚它量的是哪一層。每天刷到就快篩掉的，一天好幾次、不留紀錄；值得留檔深評的，從五月初以來的五週累積六十多個具名工具；值得走完整流程的，截至 2026-06-11 累積 19 案。六十多個裡面走到完整流程的不到二十個——快篩量這麼大，正是需要這套方法的原因。紙上評估就寫紙上評估，數字帶範圍、帶時點。講方法論的文章，自己得先過這一關。
紀錄是會增值的
固化成 skill 那天我做了個對照實驗：把 skill 拿掉，看模型會不會退回「先看亮點」的老路。結果測不出差別，因為這套紀律早就滲進常駐記憶，這台機器上的模型本來就會先盤點再對照。所以這個 skill 的正當理由不是教模型新招，是上保險：memory 可能被裁切、誤刪、沒載入，skill 是不會掉的那一份，順帶換來可維護、可分享。
評估工具最大的成本是每次都從零開始研究，裝錯反而事小。這套方法的副產品是把「自己有什麼」變成一份隨時可用的清單，每評一次就更新一次；先例紀錄讓同一條軸第 N 次被不同包裝撞上時，成本趨近於零，直接套結論。工具的價值是相對於你已經有什麼算出來的。先把自己有的列清楚，大多數熱門工具會自己歸零，剩下的那一點，才值得認真看。供大家參考。