一句「被要 KYC 了」先被發成了求助：Claude 的帳號介面，在命令列上露出縫隙

2026 年 10 月 31 日凌晨，V2EX 上出現一則標題寫著「求經驗：claude 被要 kyc，cc cli 敢不敢換號使用？」的貼文。發文者 yodi 的常用帳號觸發了 KYC（身分驗證）要求，手上還有以前囤積、跑在不同 IP 與環境裡的舊帳號可用。他真正想問的其實是一個很具體的操作問題：Claude Code CLI 登入的是被要求驗證的那個帳號，直接刪掉登入憑證、重新 auth 一個可用的帳號，行不行？之前的 memory 還能不能用？

這則貼文只有四則回覆，資訊量不大，但它把一個平常藏在訂閱頁背後的東西攤到了命令列上：帳號本身，也是一種介面。

憑證與記憶，是兩件被綁在一起的事

先把事實釐清。依據貼文內容，yodi 的處境是：常用帳號被平臺要求 KYC，舊帳號在隔離環境裡仍可運作，Claude Code CLI 長期跑在虛擬機裡，幾個月沒出問題。第一則回覆來自 BreakTheBank，建議他先檢查網路環境，「其他都是次要的」；yodi 回說查過了，補上了漏掉兩個網域的規則。至於 KYC 之後帳號的處置、memory 是否隨帳號走，貼文裡沒有人給出答案。

值得觀察的是這個問題的結構。在一般消費者軟體裡，「登入」與「個人資料」的關係是被產品設計刻意隱藏的：換帳號時資料去哪裡、哪些跟著雲端走、哪些留在本機，介面通常會給出提示或選項。但到了命令列場景，這層設計幾乎不存在。yodi 面對的是一組檔案系統裡的憑證、一份本地的 memory、一個雲端的帳號狀態，三者之間的邊界要靠自己推測。他把問題拆成「刪憑證、重新 auth、memory 能否保留」三個步驟來問，恰好說明這個介面沒有為「換號」這個動作設計任何緩衝。

這與我們先前在Claude NPO 續用頁面的欄位觀察裡看到的情形同構：帳號的驗證狀態、帳單頁與資料邊界，往往要等到出事的那一刻，使用者才第一次看清楚它們各自被放在哪裡。

KYC 是一種介面姿態

KYC 本身值得單獨看。它是一個金融業借來的流程，在 AI 服務裡通常以風控觸發：帳號行為異常、環境特徵可疑，平臺便要求使用者交出身分證明。從設計角度看，KYC 是一種單向的介面姿態，平臺不解釋觸發原因，不提供申訴的對話空間，只給出一道要嘛配合、要嘛失去帳號的閘門。yodi 的應對方式正好是繞過這道閘門：換一個沒被點名的帳號繼續用。

這種繞法有它的成本。舊帳號跑在不同的 IP 與環境裡，本身就是一種需要持續維護的基礎設施；yodi 提到漏寫兩個網域的規則就足以觸發風控，說明這套自建的隔離環境，精密度要求不低於平臺自己的風控系統。第三則回覆裡 NoCarrier 問他想不想改用 OpenRouter 或 AWS 的 API 來避開封號風險，yodi 的回答是「我都被 kyc 了別問我了哈哈」。這句玩笑背後是一個實際的取捨：官方訂閱的介面體驗，對某些使用者來說值得承擔帳號被審查的風險。

沒有答案的貼文，本身就是一個介面樣本

這則討論最後停在沒有結論的地方。memory 是否隨帳號走、換號會不會連坐觸發新的風控，貼文裡都沒有可確認的答案，這裡也不宜替平臺補充未經證實的規則。但作為介面觀察的樣本，它已經足夠完整：一個服務把信任機制做成了閘門，把帳號切換做成了沒有欄位的操作，使用者只好把整個困境發成一篇求助文，用別人的經驗來填補介面沒有提供的說明。

命令列工具常常被認為是給懂的人用的，所以不需要多餘的介面。這則貼文提示了一個反例：越是懂的使用者，遇到沒被設計過的路徑時，付出的摸索成本反而越具體。刪憑證之前要先搞清楚 memory 存在哪裡，這件事本來可以寫在文件裡的某一行。