只找“該刪什么“的過度設(shè)計(jì)代碼審查技能)
Ponytail ponytail-review一個(gè)只找該刪什么的過度設(shè)計(jì)代碼審查技能【免費(fèi)下載鏈接】ponytailMakes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/po/ponytailPonytail 把最懶的資深工程師裝進(jìn)你的 AI Agent其中/ponytail-review是它提供的六個(gè)技能之一專門做一件事審查當(dāng)前 diff只找過度工程over-engineering并輸出一份刪除清單。讀完本文你將掌握這條審查規(guī)則的完整輸出格式、五種發(fā)現(xiàn)標(biāo)簽delete / stdlib / native / yagni / shrink的判定標(biāo)準(zhǔn)、評(píng)分機(jī)制與邊界約束以及它如何在 Claude Code、Codex、Hermes、pi 等宿主中以命令、技能或插件形式被觸發(fā)——這套規(guī)則本身就是一份可以直接抄進(jìn)任何 Agent 工作流的減法式審查規(guī)范。定位它不查正確性只查復(fù)雜度skills/ponytail-review/SKILL.md 的 frontmatter 把技能定位寫得很明確輸入是一次代碼改動(dòng)diff任務(wù)是對(duì)不必要的復(fù)雜度做審查每條發(fā)現(xiàn)一行位置、該刪什么、用什么替代目標(biāo)是讓 diff 變得更短——The diffs best outcome is getting shorter觸發(fā)條件用戶說 review for over-engineering、what can we delete、is this over-engineered、simplify review或直接調(diào)用/ponytail-review與常規(guī)審查的關(guān)系是互補(bǔ)常規(guī)審查找正確性 bug、安全漏洞、性能問題而這個(gè)技能只獵殺復(fù)雜度this one only hunts complexity。這種切分不是隨口一說它和 Ponytail 主技能的設(shè)計(jì)一脈相承。主技能 skills/ponytail/SKILL.md 定義了一條階梯ladder要求 Agent 寫代碼前停在第一級(jí)站得住的橫檔上這段代碼需要存在嗎YAGNI代碼庫里已經(jīng)有了嗎復(fù)用別重寫標(biāo)準(zhǔn)庫能做嗎用它平臺(tái)原生能力能覆蓋嗎用原生如input typedate勝過日期選擇器庫已安裝的依賴能解決嗎用它能一行搞定嗎一行最后才寫能工作的最小代碼ponytail-review 的五種標(biāo)簽下一節(jié)詳述正是對(duì)這條階梯的逆向檢查delete:對(duì)應(yīng)第 1 檔stdlib:對(duì)應(yīng)第 3 檔native:對(duì)應(yīng)第 4 檔yagni:對(duì)應(yīng)只有一個(gè)實(shí)現(xiàn)的抽象這類第 1 檔違規(guī)shrink:對(duì)應(yīng)第 6/7 檔。也就是說主技能管寫的時(shí)候別多寫ponytail-review 管寫完之后審掉多寫的。輸出格式一行一個(gè)發(fā)現(xiàn)技能文件給出的格式規(guī)范只有一句模板Lline: tag what. replacement.對(duì)多文件 diff前面加上文件名file:Lline: ...格式刻意壓縮到最簡(jiǎn)不寫段落、不寫論證、不寫建議考慮。每條發(fā)現(xiàn)必須包含三個(gè)要素——位置行號(hào)或文件:行號(hào)、該刪/該換什么、替代品。替代品可以為無即直接刪掉。五種標(biāo)簽delete、stdlib、native、yagni、shrinkSKILL.md 的 Tags 小節(jié)定義了完整的標(biāo)簽表這是整個(gè)技能的核心判定標(biāo)準(zhǔn)標(biāo)簽判定標(biāo)準(zhǔn)替代物要求delete:死代碼、沒人用的靈活性、投機(jī)性功能替代品無nothingstdlib:手搓了標(biāo)準(zhǔn)庫本身就帶的東西必須點(diǎn)名那個(gè)標(biāo)準(zhǔn)庫函數(shù)native:依賴或代碼在做平臺(tái)已經(jīng)會(huì)做的事必須點(diǎn)名那個(gè)平臺(tái)特性yagni:只有一個(gè)實(shí)現(xiàn)的抽象、沒人設(shè)置的配置、只有一個(gè)調(diào)用者的層—shrink:同樣的邏輯、更少的行數(shù)必須展示更短的寫法注意后三列替代物的強(qiáng)制性stdlib:不能只說用標(biāo)準(zhǔn)庫必須寫出具體函數(shù)名如dict(zip(...))、Intl.DateTimeFormatnative:必須寫出具體平臺(tái)特性shrink:必須給出更短形態(tài)本身。這保證了審查結(jié)果是可直接執(zhí)行的刪除清單而不是需要再翻譯一遍的評(píng)論。yagni:的判定措辭也值得對(duì)照主技能 skills/ponytail/SKILL.md 的 Rules 一節(jié)no interface with one implementation, no factory for one product, no config for a value that never changes——一個(gè)實(shí)現(xiàn)接口的抽象、一個(gè)產(chǎn)品的工廠、一個(gè)永不變更值的配置就是 yagni 標(biāo)簽的三個(gè)標(biāo)準(zhǔn)形態(tài)。而惰性不是疏忽的底線信任邊界校驗(yàn)、數(shù)據(jù)丟失防護(hù)、安全、可訪問性永不裁剪同樣適用于審查主技能 AGENTS.md 中 Not lazy about 一節(jié)列出的那些東西審查時(shí)同樣不應(yīng)標(biāo)記為可刪。示例拒絕模糊只給結(jié)論SKILL.md 的 Examples 小節(jié)先給了一個(gè)反面教材再給了五個(gè)正面樣例。反面教材展示了 Ponytail 明確反對(duì)的審查腔調(diào)? This EmailValidator class might be more complex than necessary, have you considered whether all these validation rules are needed at this stage?這個(gè) EmailValidator 類可能比必要的更復(fù)雜你考慮過這個(gè)階段是否需要所有這些校驗(yàn)規(guī)則嗎——含糊、無定位、無替代物。然后是五個(gè)正面樣例完整繼承如下? L12-38: stdlib: 27-line validator class. in email, 1 line, real validation is the confirmation mail. ? L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps. ? repo.py:L88: yagni: AbstractRepository with one implementation. Inline it until a second one exists. ? L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it. ? L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.五條樣例恰好各用一個(gè)標(biāo)簽也各自示范了標(biāo)簽的硬性要求stdlib:樣例同時(shí)點(diǎn)名了替代函數(shù)并補(bǔ)了一句業(yè)務(wù)判斷——真正的校驗(yàn)是確認(rèn)郵件本身把校驗(yàn)邏輯的成本歸零native:樣例點(diǎn)名了Intl.DateTimeFormat并量化了收益 0 depsyagni:樣例展示了多文件 diff 的repo.py:L88寫法替代動(dòng)作是內(nèi)聯(lián)直到出現(xiàn)第二個(gè)實(shí)現(xiàn)delete:樣例展示了替代品為無的寫法并且給出的刪除理由是語義性的冪等的本地調(diào)用套重試包裝沒有意義shrink:樣例直接寫出了更短的那一行代碼dict(zip(keys, values))。倉庫 examples/ 目錄下的實(shí)戰(zhàn)案例如 examples/email-validation.md、examples/debounce.md展示了同一套思維在寫代碼側(cè)的產(chǎn)物ponytail-review 則是把同樣的判斷標(biāo)準(zhǔn)用在審代碼側(cè)。評(píng)分唯一重要的指標(biāo)是凈刪行數(shù)Scoring 小節(jié)規(guī)定審查必須以唯一重要的指標(biāo)收尾net: -N lines possible.如果沒什么可刪輸出Lean already. Ship.已經(jīng)是精簡(jiǎn)的直接發(fā)布然后停止。這個(gè)收尾設(shè)計(jì)有兩個(gè)作用一是把審查結(jié)果量化成單一數(shù)字讓這次審查值不值可比較二是給了無可刪一個(gè)明確出口避免 Agent 為了交差而硬湊發(fā)現(xiàn)——代碼本來夠精簡(jiǎn)時(shí)正確的輸出就是沒有發(fā)現(xiàn)。邊界不修、不越界、可退出Boundaries 小節(jié)劃出了四條硬邊界這也是使用這個(gè)技能時(shí)最容易踩錯(cuò)的點(diǎn)范圍僅限過度工程與復(fù)雜度。正確性 bug、安全漏洞、性能問題被明確排除在范圍外explicitly out of scope應(yīng)當(dāng)路由到常規(guī)審查流程而不是在這條通道里報(bào)最低限度的測(cè)試不算臃腫。單個(gè)冒煙測(cè)試或基于assert的自檢是 Ponytail 體系的最低要求而非 bloat——主技能 skills/ponytail/SKILL.md 的 When NOT to be lazy 一節(jié)規(guī)定非平凡邏輯要留下一個(gè)可運(yùn)行的檢查審查時(shí)必須與這條自洽永遠(yuǎn)不能把這類測(cè)試標(biāo)記為刪除對(duì)象只列清單不執(zhí)行修復(fù)does not apply the fixes, only lists them可退出用戶說 stop ponytail-review 或 normal mode 時(shí)回退到冗長的常規(guī)審查風(fēng)格。第 3 條讓它天然適合嵌入流水線審查產(chǎn)出是一份待辦刪除清單是否執(zhí)行、何時(shí)執(zhí)行由人決定Agent 不越權(quán)改碼。在宿主中如何調(diào)用ponytail-review 作為技能存放在 skills/ponytail-review/SKILL.md各宿主通過各自的適配層把它注冊(cè)成命令或技能適配規(guī)則見 docs/agent-portability.mdskills/ 持有核心行為宿主文件只是讓它容易被加載的適配器。從源碼結(jié)構(gòu)看幾種典型宿主的接入方式如下Claude Code / Codex 插件倉庫根目錄的 commands/ponytail-review.toml 是命令適配器內(nèi)容與技能文件同源——它把整條規(guī)則壓縮成一段 prompt 注入description Review changes for over-engineering, what can be deleted prompt Review the current code changes for over-engineering only, not correctness. One line per finding: Lline: tag what to cut. replacement. Tags: delete (dead code/speculative feature), stdlib (reinvented standard library), native (dependency doing what the platform does), yagni (abstraction with one implementation), shrink (same logic, fewer lines). End with the net lines removable. If nothing to cut: Lean already. Ship.這段 prompt 完整保留了技能文件的全部要素單行格式、五個(gè)標(biāo)簽、net 行評(píng)分、Lean already. Ship. 出口。安裝與調(diào)用方式/plugin marketplace add/plugin install ponytailponytail詳見 README.md 的 Install 一節(jié)之后直接在會(huì)話中發(fā)/ponytail-review即可對(duì)當(dāng)前改動(dòng)執(zhí)行審查。Hermes Agentplugin.yaml 把ponytail-review同時(shí)注冊(cè)在provides_commands和provides_skills兩個(gè)列表里即它既是斜杠命令/ponytail-review也可作為ponytail:ponytail-review技能引用after-install.md 給出的命令清單里它是/ponytail-review [target]支持指定審查目標(biāo)。pi agent harnesspi-extension/index.js 中pi.registerCommand(ponytail-review, ...)把命令映射為/skill:ponytail-review的別名發(fā)送即復(fù)用同一份 SKILL.md 的完整規(guī)則。Codex技能以前綴調(diào)用寫作ponytail-review見 README.md Commands 一節(jié)的說明。指令級(jí)宿主Cursor、Windsurf、Cline、Copilot 等無技能支持的宿主沒有斜杠命令只有常駐規(guī)則集此時(shí)可以把 skills/ponytail-review/SKILL.md 的正文內(nèi)容直接貼給 Agent 作為一次性審查指令使用——因?yàn)樗旧聿灰蕾嚾魏芜\(yùn)行時(shí)。與 ponytail-audit 的區(qū)別diff 與全庫容易混淆的相鄰技能是 skills/ponytail-audit/SKILL.md。它的開頭一句話就說明了關(guān)系ponytail-review, repo-wide. Scan the whole tree instead of a diff.——同一個(gè)標(biāo)簽體系、同一套邊界只是掃描范圍從當(dāng)前改動(dòng)擴(kuò)大到整個(gè)代碼樹且結(jié)果按刪得最多的排最前排序收尾指標(biāo)也多了一項(xiàng)依賴數(shù)net: -N lines, -M deps possible.。兩者都只列清單、不執(zhí)行修復(fù)。選哪個(gè)取決于問題粒度審查一次提交用 review體檢整個(gè)倉庫用 audit??沈?yàn)證性與工程約定這條規(guī)則并不是孤立的文本倉庫 scripts/check-rule-copies.js 負(fù)責(zé)在修改緊湊規(guī)則文本時(shí)校驗(yàn)各宿主的副本保持一致npm test測(cè)試見 tests/會(huì)校驗(yàn)技能與其派生包如 OpenClaw 技能包不出現(xiàn)漂移。這意味著你從任何一個(gè)宿主看到的 ponytail-review 行為都來自這一份 skills/ponytail-review/SKILL.md且各宿主副本受腳本與測(cè)試約束對(duì)齊。小結(jié)把刪當(dāng)作審查的第一性ponytail-review 的價(jià)值不在它發(fā)現(xiàn)了什么模式而在它對(duì)審查形態(tài)的強(qiáng)制約束一行一個(gè)發(fā)現(xiàn)、標(biāo)簽必須對(duì)應(yīng)可執(zhí)行動(dòng)作、替代物必須點(diǎn)名、以凈刪行數(shù)收尾、無可刪則明說。它把 code review 從意見交換變成刪除清單并且用邊界條款不查正確性、不刪最低限度測(cè)試、不改碼保證了自己不會(huì)變成另一個(gè)什么都說的常規(guī)審查器。如果你的 Agent 工作流里需要一個(gè)瘦身專用的審查通道這份不到六十行的 SKILL.md 本身就可以作為規(guī)范直接引用?!久赓M(fèi)下載鏈接】ponytailMakes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/po/ponytail創(chuàng)作聲明:本文部分內(nèi)容由AI輔助生成(AIGC),僅供參考