1. 為什么我會(huì)盯上代碼評(píng)審自動(dòng)化這件事先說個(gè)真實(shí)場(chǎng)景。上個(gè)月底我們團(tuán)隊(duì)迭代節(jié)奏加快PR 一下子堆了二十幾個(gè)我每天下午基本都泡在評(píng)審頁面里。打開一個(gè)改動(dòng)幾十個(gè)文件的 PR先要花十幾分鐘理清楚這次到底動(dòng)了哪些模塊再逐行看有沒有低級(jí)的空指針、資源沒關(guān)閉、異常被吞掉這類問題。等我看完澡也忘了洗天也黑了。最難受的是我還不能保證自己狀態(tài)好的時(shí)候看出來的問題和狀態(tài)差的時(shí)候看出來的問題一樣多。后來我跟某位之前帶過我的老同事吐槽他說了一句話讓我印象很深人做重復(fù)性審查一定會(huì)疲把你疲的時(shí)候會(huì)漏掉的東西交給工具你才有精力去盯架構(gòu)、盯設(shè)計(jì)、盯那些機(jī)器判斷不了的事。他說的就是代碼評(píng)審自動(dòng)化這件事。我順著這個(gè)思路去找開源方案最后盯上了 open-code-review 這個(gè)項(xiàng)目。它的定位很直接不替代人而是把代碼評(píng)審里最耗精力的那部分體力活——diff 分析、規(guī)范檢查、重復(fù)代碼提醒、常見反模式掃描——從人手里接過去。項(xiàng)目本身完全開源可以自托管支持常見的 Git 工作流也能作為命令行工具跑在本地或者 CI 里。這篇東西不是官方文檔的復(fù)讀是我自己從部署到接入、再到被誤報(bào)折磨了一下午的真實(shí)過程記錄。如果你也在做團(tuán)隊(duì)內(nèi)的代碼評(píng)審質(zhì)量提升或者單純不想每次 PR 都靠肉眼硬扛這篇應(yīng)該對(duì)你有用。工具本身解決什么問題、核心邏輯是怎么設(shè)計(jì)的、真正跑起來有哪些坑我會(huì)一條一條講清楚。順便說一句工具能幫你兜住 80% 的機(jī)械性錯(cuò)誤剩下那 20% 的這個(gè)設(shè)計(jì)合理嗎還是得靠人來回答。2. open-code-review 的工作方式它到底怎么看你的代碼很多剛接觸這類工具的人都會(huì)有個(gè)誤解覺得它跟那些老牌的靜態(tài)分析工具差不多跑一遍全量代碼然后給你吐出一堆幾千條的歷史遺留問題。實(shí)際用過之后你會(huì)發(fā)現(xiàn)open-code-review 的思路完全不一樣。2.1 核心入口先解析 diff而不是重掃全庫它默認(rèn)的輸入是 git diff。也就是說它只關(guān)注你這次改動(dòng)涉及的行、涉及的函數(shù)、涉及的文件而不是把整個(gè)倉庫從上到下掃一遍。這個(gè)設(shè)計(jì)我很喜歡原因有兩個(gè)第一評(píng)審本來就是針對(duì)增量的。你不可能在每個(gè) PR 里要求開發(fā)者把十年前的歷史代碼全部修一遍那樣評(píng)審就沒法推進(jìn)了。只看增量才能把注意力集中在這次改動(dòng)有沒有引入新問題上這跟人的評(píng)審邏輯是一致的。第二只處理 diff 讓性能壓力小了很多。我在一個(gè)中等規(guī)模的倉庫上試過改動(dòng) 50 個(gè)文件、大約 3000 行 diff 的情況下完整跑一輪規(guī)則檢測(cè)加報(bào)告生成也就十來秒。這個(gè)速度意味著你可以把它掛在 CI 里每個(gè) PR 跑一遍都不會(huì)讓人覺得等得難受。它內(nèi)部會(huì)先把 diff 按文件拆分再調(diào)用語言識(shí)別模塊判斷每個(gè)文件的類型比如 Python、JavaScript、Java、Go然后針對(duì)不同語言選擇對(duì)應(yīng)的解析器。解析之后它會(huì)建立一個(gè)變更上下文——不光是看改了哪一行還會(huì)把這一行所在的函數(shù)、附近的相關(guān)調(diào)用都拉進(jìn)來。這一步很關(guān)鍵因?yàn)楹芏嘁?guī)則如果不看上下文單獨(dú)的增刪行是判斷不出問題的。我用一個(gè)最簡(jiǎn)單的例子說明。假設(shè)你在一個(gè)函數(shù)里加了這樣一行result config.get(timeout, DEFAULT_TIMEOUT)如果只看這一行它沒毛病。但 open-code-review 會(huì)把整個(gè)函數(shù)體拿來看一遍如果函數(shù)里已經(jīng)有一個(gè)局部變量叫 result它就會(huì)提示你變量 result 可能被重復(fù)賦值建議確認(rèn)是否覆蓋了之前的引用。2.2 規(guī)則引擎基于 AST 的檢查才是靠譜的檢查diff 解析只是前置步驟真正的檢測(cè)邏輯是在規(guī)則引擎里完成的。open-code-review 的規(guī)則不是靠正則匹配代碼文本那樣誤報(bào)率會(huì)高到?jīng)]法用。它走的是 AST抽象語法樹路線也就是先把代碼真實(shí)地解析成一棵語法樹然后規(guī)則在語法樹上去找特定的節(jié)點(diǎn)模式。舉個(gè)例子它內(nèi)置了一條禁止吞異常的規(guī)則。在 Python 里很多人寫異常捕獲是這樣的try: do_something() except Exception: pass如果用正則去匹配你很容易被各種寫法繞過去。但用 AST 就不同了解析器能明確告訴你這個(gè) except 塊里只有一個(gè) pass 語句沒有任何日志、沒有重新拋出、也沒有返回錯(cuò)誤信息。這種判斷是結(jié)構(gòu)性的非常可靠。它還內(nèi)置了不少類似規(guī)則我挑幾個(gè)實(shí)際用下來命中率很高的列一下規(guī)則類別檢測(cè)目標(biāo)我實(shí)測(cè)的感受空指針/空值風(fēng)險(xiǎn)未判空就訪問對(duì)象屬性或調(diào)用方法命中率不錯(cuò)但會(huì)有誤報(bào)后面細(xì)說資源未關(guān)閉打開文件、連接、游標(biāo)后沒有 close這類基本一抓一個(gè)準(zhǔn)日志參數(shù)占位符日志語句的格式化參數(shù)和變量數(shù)量不匹配很實(shí)用尤其 Java 項(xiàng)目里重復(fù)代碼片段同一文件內(nèi)超過閾值的相似代碼塊對(duì)重構(gòu)很有參考價(jià)值潛在并發(fā)問題共享變量在無鎖環(huán)境下被修改需要配合上下文分析誤報(bào)中等每條規(guī)則都能配置嚴(yán)重級(jí)別。我習(xí)慣把空指針資源未關(guān)閉設(shè)為 error 級(jí)別一旦命中就阻塞合并把重復(fù)代碼日志風(fēng)格問題設(shè)為 warning 級(jí)別只提示不阻塞。分級(jí)的好處后面講團(tuán)隊(duì)落地的部分我會(huì)再展開。2.3 評(píng)審結(jié)果怎么呈現(xiàn)檢測(cè)完之后open-code-review 會(huì)生成一份統(tǒng)一的評(píng)審報(bào)告。默認(rèn)有兩種輸出格式一種是 Markdown適合直接貼在 PR 評(píng)論里另一種是 JSON適合給 CI 或者其他自動(dòng)化流程消費(fèi)。Markdown 報(bào)告的結(jié)構(gòu)大概是這樣的變更概覽改了哪些文件、哪些是新增、哪些是刪除、涉及的語言占比問題列表按文件分組每條問題都包含行號(hào)、規(guī)則名、嚴(yán)重級(jí)別、具體描述統(tǒng)計(jì)摘要本次檢測(cè)發(fā)現(xiàn)了幾條 error、幾條 warning、整體通過還是需要人工復(fù)核我通常把 Markdown 報(bào)告直接作為 PR 的機(jī)器人評(píng)論發(fā)出去開發(fā)者打開 PR 就能看到不需要登錄任何額外系統(tǒng)。這個(gè)體驗(yàn)很重要因?yàn)楣ぞ呷绻卦谀硞€(gè)獨(dú)立的網(wǎng)頁里很多人根本不會(huì)主動(dòng)去點(diǎn)開把結(jié)果推到代碼評(píng)審發(fā)生的那個(gè)頁面里才是最自然的交互方式。3. 接入過程實(shí)錄從拉代碼到第一條機(jī)器評(píng)審意見下面這部分是完整的實(shí)操記錄我假設(shè)你是在自己的服務(wù)器或者本地環(huán)境接入代碼倉庫是常見的 Git 平臺(tái)。整個(gè)過程我走完大概花了一個(gè)小時(shí)其中一半時(shí)間花在配置文件上。3.1 部署方式我為什么選了 Dockeropen-code-review 官方提供了幾種部署方式直接下載二進(jìn)制、Docker 容器、以及從源碼構(gòu)建。我推薦直接用 Docker省去一大堆依賴管理的麻煩尤其是你要掛到 CI 里的時(shí)候一個(gè)鏡像就能保證所有環(huán)境行為一致。我用的啟動(dòng)命令大概長(zhǎng)這樣docker run -d --name ocr \ -p 8080:8080 \ -v /opt/ocr/config:/app/config \ -v /opt/ocr/reports:/app/reports \ local/ocr:latest第一次跑的時(shí)候我犯了個(gè)小錯(cuò)忘了掛載配置文件目錄結(jié)果容器起來之后所有規(guī)則都是默認(rèn)配置連代碼倉庫的地址都不知道在哪里填。后來老老實(shí)實(shí)把目錄掛上用官方給的示例配置改了一版才算正式跑通。這里插一句如果你是在本地做驗(yàn)證不需要容器也可以直接用 CLI 模式open-code-review --repo /path/to/repo --diff HEAD~1 --format markdownCLI 模式的好處是調(diào)試起來很快改完規(guī)則立刻就能在本地跑一遍小 diff 看效果不需要走一遍完整的倉庫事件流程。3.2 配置文件里最重要的事告訴它倉庫長(zhǎng)什么樣open-code-review 的配置文件是 YAML 格式我把它放在 /opt/ocr/config 下面。最核心的幾個(gè)配置項(xiàng)是repository: type: git remote: https://your-git-host/your-team/your-repo.git default_branch: master review: languages: [python, javascript, java] severity: error: [null-deref, resource-leak] warning: [duplicate-code, log-style] rules_dir: /app/config/rules reporter: format: markdown output_dir: /app/reports這個(gè)文件里有幾個(gè)點(diǎn)需要注意。languages那個(gè)列表其實(shí)不寫也行工具會(huì)自動(dòng)識(shí)別但如果你明確知道團(tuán)隊(duì)主力語言寫清楚可以跳過一部分文件類型的探測(cè)時(shí)間在超大 monorepo 里能省不少。severity是關(guān)鍵因?yàn)槟J(rèn)情況下所有規(guī)則的級(jí)別都是 warning如果你想讓某些問題直接卡住 CI必須在這里把它們提級(jí)。另一個(gè)容易坑到人的是default_branch。工具在做增量分析的時(shí)候需要知道跟哪個(gè)基線做對(duì)比。如果你倉庫的主分支叫 main 而不是 master沒改這個(gè)配置的話它會(huì)把整個(gè)倉庫當(dāng)成全部新增代碼來處理第一輪跑出來的報(bào)告能有一百多個(gè)問題直接把人看懵。3.3 和代碼倉庫的聯(lián)動(dòng)webhook 還是輪詢部署起來之后open-code-review 要跟代碼倉庫通信才能拿到有新 PR 了這個(gè)信號(hào)。它支持兩種方式webhook 推送和定時(shí)拉取。我實(shí)際用下來更推薦 webhook。在代碼托管平臺(tái)的后臺(tái)配置一個(gè) webhook 地址指向 open-code-review 的監(jiān)聽端口然后選擇觸發(fā)事件為PR 創(chuàng)建和PR 更新。這樣每次有新的提交或者新的 PR托管平臺(tái)會(huì)主動(dòng)通知它工具再拉取最新的 diff 跑一輪檢測(cè)檢測(cè)完成后把報(bào)告通過平臺(tái)的 API 作為評(píng)論發(fā)回去。如果你用的托管平臺(tái)不支持 webhook或者網(wǎng)絡(luò)環(huán)境比較特殊那就退而求其次用輪詢。配置一個(gè)定時(shí)任務(wù)每隔幾分鐘檢查一次有沒有新 PR有就處理。輪詢的缺點(diǎn)很明顯評(píng)審結(jié)果不是實(shí)時(shí)的開發(fā)者可能已經(jīng)等了半天才看到機(jī)器人評(píng)論。但對(duì)于內(nèi)部測(cè)試環(huán)境來說這也不是不能用。跑通之后的第一份報(bào)告我記得很清晰一個(gè)簡(jiǎn)單的改配置 PR總共改了 3 個(gè)文件報(bào)告里提示了一條 warning說有一個(gè)日志語句的參數(shù)占位符和實(shí)際變量數(shù)量對(duì)不上。還真是實(shí)測(cè)實(shí)打?qū)嵉膯栴}。那一刻我的感受是這東西真能干活值了。4. 誤報(bào)風(fēng)暴排查一個(gè)空指針檢查讓我折騰了一下午工具跑通只是開始真正讓我差點(diǎn)想把它卸載掉的是接入后第三天的一場(chǎng)全線標(biāo)紅事件。如果你也準(zhǔn)備上這種自動(dòng)化評(píng)審工具我這段排查記錄應(yīng)該能幫你提前避開不少坑。4.1 現(xiàn)象五十多個(gè)報(bào)錯(cuò)全是同一類當(dāng)時(shí)團(tuán)隊(duì)一個(gè)同事提了個(gè) PR里面有一個(gè) Python 服務(wù)模塊的重構(gòu)改動(dòng)量不小。open-code-review 跑完之后報(bào)告里出現(xiàn)了五十多條 error清一色都是空值檢查規(guī)則null-deref命中的。我當(dāng)時(shí)的表情基本是呆滯的——這代碼我看著整體質(zhì)量還行怎么突然冒出來五十多個(gè)必現(xiàn)空指針點(diǎn)開幾個(gè)具體條目看了一下模式很統(tǒng)一工具在變量 x 可能為 None 的情況下檢測(cè)到后續(xù)直接訪問了 x.attr于是判定為空值風(fēng)險(xiǎn)。比如下面這種代碼data fetch_data() if data: process(data.items)工具的邏輯是fetch_data()的返回值可能為 None如果你在沒有重新賦值的情況下直接訪問了data.items那就危險(xiǎn)。但真實(shí)情況是data在這個(gè)函數(shù)前面已經(jīng)被賦值過一次而且調(diào)用方保證了它不會(huì)是 None。工具的上下文追蹤范圍有限沒看到那個(gè)賦值就一刀切地給你標(biāo)紅了。五十多條這種誤報(bào)堆在一起任何團(tuán)隊(duì)都會(huì)第一時(shí)間懷疑工具是不是有問題。那時(shí)候我有兩個(gè)選擇一是直接在配置里把空值規(guī)則關(guān)掉二是一條條加白名單。兩個(gè)都不太對(duì)。關(guān)掉規(guī)則等于把真正有用的檢查也丟了加白名單遇到代碼改動(dòng)就得維護(hù)容易越加越亂。4.2 順著日志還原排查鏈路我決定先看它的分析日志搞清楚它到底是從哪一步開始跟丟的。open-code-review 在啟動(dòng)時(shí)加--debug參數(shù)會(huì)把每次規(guī)則命中的詳細(xì)上下文都打出來包括它的 AST 遍歷路徑和分析到的調(diào)用鏈。翻了幾條日志之后我找到了一個(gè)規(guī)律它處理跨函數(shù)調(diào)用的時(shí)候只會(huì)跟著函數(shù)簽名走不會(huì)做跨函數(shù)的數(shù)值流分析。也就是說process(data.items)這行代碼里它無法知道data在process函數(shù)內(nèi)部其實(shí)已經(jīng)被if data這個(gè)判斷保護(hù)過了因?yàn)樵谒磥磉M(jìn)入process的那一刻data是有可能為 None 的。從工具的角度這個(gè)判斷邏輯并不能說錯(cuò)——保守的空值分析在不知道外部保證的情況下提醒你注意這里可能為空其實(shí)是合理的。只是它的提醒粒度太粗表達(dá)方式又是 error 級(jí)別才會(huì)造成五十多條的全線標(biāo)紅讓人誤以為這個(gè) PR 爛透了。我后來找了個(gè)折中方案把空值規(guī)則的級(jí)別從 error 降為 warning然后加了一條自定義規(guī)則的新邏輯專門跳過已經(jīng)被if x:這類判空包裹的后續(xù)訪問場(chǎng)景。自定義規(guī)則寫起來不難YAML 里定義觸發(fā)節(jié)點(diǎn)類型和過濾條件就行。改完之后重新跑了一遍同樣那個(gè) PR有效告警從五十多條降到了個(gè)位數(shù)剩下的幾條經(jīng)過人工確認(rèn)有兩條確實(shí)是真問題只是之前被五十條誤報(bào)淹沒沒人注意到。4.3 這次排查給我留下的幾條教訓(xùn)第一任何靜態(tài)分析工具的保守性都比你想象的高。它只會(huì)按照確定的路徑做分析遇到跨函數(shù)、跨模塊的數(shù)據(jù)流它的判斷能力是有限的。不要因?yàn)榈谝惠唸?bào)告難看就直接否掉工具先看看誤報(bào)集中在哪個(gè)規(guī)則針對(duì)那個(gè)規(guī)則做調(diào)整。第二規(guī)則級(jí)別一定要從一開始就設(shè)計(jì)好。如果一上來把所有規(guī)則都設(shè)為 error團(tuán)隊(duì)的第一個(gè) PR 就會(huì)被大量提示淹沒直接失去對(duì)工具的信任。這跟跑步一樣你得先慢跑建立習(xí)慣再逐漸加大強(qiáng)度。第三白名單機(jī)制能不用就不用。見過不少團(tuán)隊(duì)為了消除誤報(bào)往白名單里塞了幾十條路徑最后新增代碼重名了都檢測(cè)不到。更好的做法是像上面那樣從規(guī)則層面去修正誤報(bào)邏輯讓工具自己變得更聰明而不是繞開它。5. 把默認(rèn)配置調(diào)教成團(tuán)隊(duì)想要的樣子工具跑順之后我開始認(rèn)真琢磨怎么讓它在團(tuán)隊(duì)里真正落地而不僅僅是有個(gè)機(jī)器人偶爾冒泡。這一步比部署和接入花的時(shí)間多得多但也是收獲最大的部分。5.1 規(guī)則分級(jí)的團(tuán)隊(duì)實(shí)踐我前面提過嚴(yán)重級(jí)別的概念這里展開講一下具體怎么用。我們團(tuán)隊(duì)最終的分級(jí)策略是這樣的阻塞級(jí)error空值風(fēng)險(xiǎn)、資源未關(guān)閉、明顯的越界訪問。這些一旦出現(xiàn)PR 不允許合并。警告級(jí)warning重復(fù)代碼、日志風(fēng)格、注釋缺失、可疑的復(fù)雜度超標(biāo)。信息級(jí)info格式化偏好、命名風(fēng)格這類不涉及正確性的問題只做提示。這個(gè)分級(jí)的核心思想是不要把工具變成吹毛求疵的機(jī)器把必須改和建議改清晰地分開。實(shí)際上從團(tuán)隊(duì)反饋來看大家普遍能接受 error 級(jí)的阻塞因?yàn)槔碛沙浞?、問題明確但如果你把命名風(fēng)格也設(shè)為 error那基本每天都有 PR 被卡住開發(fā)者很快就會(huì)恨上這個(gè)工具。另外提一句規(guī)則配置的改動(dòng)建議走 git 管理。我們的規(guī)則文件放在倉庫里單獨(dú)一個(gè)目錄下改之前先提 PR大家 review 過了再合入。這樣規(guī)則本身的變更也是有跡可循的而不是某天某個(gè)人悄悄在服務(wù)器上改了配置第二天所有人都開始收到奇怪的通知。5.2 評(píng)審報(bào)告的正確閱讀姿勢(shì)工具的報(bào)告生成之后怎么讀也是有講究的。剛開始我們團(tuán)隊(duì)的開發(fā)者是打開報(bào)告逐條看效率很低。后來我建議按這樣順序看先看統(tǒng)計(jì)摘要了解整體情況是干凈通過還是有幾個(gè) error。再看 error 列表這些是必須處理的問題。然后看 warning挑跟本次改動(dòng)相關(guān)的那些看那些歷史遺留的重復(fù)代碼可以先放著。最后才是 info 類的風(fēng)格提示這類一般集中在一個(gè)迭代統(tǒng)一處理一次就行。其實(shí)工具的報(bào)告字段也可以調(diào)整。open-code-review 支持在配置里設(shè)置report.fields可以只輸出行號(hào)、規(guī)則名、描述不輸出那些特別長(zhǎng)的代碼片段。字段少了之后報(bào)告的可讀性會(huì)明顯提升開發(fā)者掃一眼就能定位到問題不用滾很久的屏幕。5.3 幾個(gè)我后來覺得非常值得的擴(kuò)展玩法基本能力摸透了之后可以做幾件事讓工具的價(jià)值再上一個(gè)臺(tái)階。第一件事把 JSON 報(bào)告接入到團(tuán)隊(duì)自己的數(shù)據(jù)看板里。我們?cè)?CI 階段會(huì)把每次評(píng)審的 JSON 結(jié)果收集起來統(tǒng)計(jì)每個(gè)模塊的問題密度、每次迭代引入的新問題數(shù)量。這些數(shù)據(jù)用來做團(tuán)隊(duì)質(zhì)量復(fù)盤特別有用能看到哪個(gè)模塊長(zhǎng)期是問題重災(zāi)區(qū)哪些規(guī)則實(shí)際命中率極低需要調(diào)整。第二件事寫一個(gè)自定義規(guī)則專門檢查我們團(tuán)隊(duì)自己約定的規(guī)范比如某些核心模塊禁止直接 import 某些基礎(chǔ)設(shè)施庫。這種團(tuán)隊(duì)內(nèi)部的特殊約束通用工具是不知道的但 open-code-review 的規(guī)則引擎留了擴(kuò)展口子寫一個(gè) YAML 規(guī)則就能實(shí)現(xiàn)。第三件事把工具跑在 pre-commit 階段配合本地 CLI 模式。開發(fā)者在提交代碼之前本地跑一遍問題在提交前就解決掉而不是等到 PR 被機(jī)器人攔截了一次再回來改。這個(gè)流程能極大減少 PR 來回的輪數(shù)。我們落地之后PR 的平均評(píng)論往返數(shù)量明顯下降了。6. 最后再分享一個(gè)實(shí)際運(yùn)維小技巧跑了大半個(gè)月之后我發(fā)現(xiàn)一個(gè)容易被忽略但很重要的細(xì)節(jié)open-code-review 所在的那臺(tái)機(jī)器磁盤會(huì)被報(bào)告文件慢慢塞滿。因?yàn)樗看卧u(píng)審都會(huì)往 reports 目錄寫一份 Markdown 和 JSON 文件時(shí)間一長(zhǎng)體積很可觀尤其大倉庫頻繁更新的時(shí)候。我當(dāng)時(shí)就是吃了這個(gè)虧某天中午 CI 突然開始報(bào)錯(cuò)查了半天發(fā)現(xiàn)是磁盤滿了。后來我在服務(wù)器的 crontab 里加了一條清理任務(wù)保留最近 30 天的報(bào)告find /opt/ocr/reports -type f -mtime 30 -delete其實(shí)類似的問題很多工具部署時(shí)都會(huì)遇到。日志輪轉(zhuǎn)、報(bào)表清理這種運(yùn)維細(xì)節(jié)官方文檔通常不會(huì)著重提醒但實(shí)際跑久了全都會(huì)冒出來。自動(dòng)化評(píng)審工具的價(jià)值再大前提也得是它自己穩(wěn)定可靠地跑著。如果你正在評(píng)估要不要在團(tuán)隊(duì)里引入這一類工具我的建議很簡(jiǎn)單先選一個(gè)真實(shí)的中等規(guī)模 PR用 CLI 模式本地跑一遍看看它的報(bào)告是不是說人話誤報(bào)多不多。如果第一輪你看下來覺得這些問題正是我平時(shí)人肉在找的那么部署價(jià)值就非常大值得像上面這樣完整接入。如果第一輪報(bào)告全都是無關(guān)痛癢的風(fēng)格提示那你需要的可能是另一個(gè)類別的工具。畢竟代碼評(píng)審自動(dòng)化這件事適合的方案才會(huì)越用越順不適合的方案只會(huì)變成一個(gè)沒人看的機(jī)器人。