矩：技能包本地化改造時最容易犯的四個錯)
別照抄 Karpathy 的規(guī)矩技能包本地化改造時最容易犯的四個錯【免費下載鏈接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.項目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skillsAndrej Karpathy 關(guān)于 LLM 編碼缺陷的幾條觀察在 2026 年幾乎成了 AI 編程圈的公共常識模型會替你做出錯誤假設(shè)然后悶頭執(zhí)行、會把 100 行的需求實現(xiàn)成 1000 行的抽象堆砌、會順手改掉它沒看懂但無關(guān)緊要的注釋還會在沒有明確成功標準的情況下盲目循環(huán)。圍繞這些觀察andrej-karpathy-skills這個倉庫給出了一份極簡的答案——一個CLAUDE.md文件、四條行為準則。社區(qū)熱度也一路走高掘金上有《一天一個開源項目》專門拆解它媒體以專治 AI 瞎寫、失憶、造屎山來概括其價值2026 年 8 月的 GitHub Trending 月度觀察中Agent Skills 更是被列為當月開源圈的關(guān)鍵詞之一。但熱度高不意味著能照抄。恰恰相反這個倉庫的所有文檔里都寫著一句常被忽略的前提——Merge with project-specific instructions as needed按需與項目特定指令合并。這篇文章不重復(fù)講這四條原則是什么而是結(jié)合倉庫源碼本身拆解本地化改造這個動作里最容易犯的四個錯以及一份可落地的檢查清單。一、先搞清楚原版規(guī)矩是為誰的代碼庫寫的先看這個倉庫的真實結(jié)構(gòu)。它不是一個技能框架而是把一套行為準則同時打包成了三份載體CLAUDE.mdClaude Code 按項目讀取的根指令文件skills/karpathy-guidelines/SKILL.md帶 YAML frontmatter 的可復(fù)用技能包通過 .claude-plugin/plugin.json 掛載.cursor/rules/karpathy-guidelines.mdcCursor 項目規(guī)則alwaysApply: true。三份文件的正文幾乎逐字一致這是倉庫作者刻意為之的單源多端設(shè)計——CURSOR.md 里明確要求貢獻者改動四條原則時必須三份同步。也就是說原版規(guī)矩的設(shè)計目標是跨工具一致而不是貼合某個具體代碼庫。這也是它不適合直接照抄的根本原因原版描述的是一個通用場景下的理想 Agent而你面對的是一個有歷史包袱、有既有風(fēng)格、有真實測試基建的倉庫。Karpathy 本人在訪談里也反復(fù)強調(diào)這一點——他把現(xiàn)在的 AI 編碼助手定位成能力出眾但還不穩(wěn)定的實習(xí)生實習(xí)生可以負責(zé)底層實現(xiàn)細節(jié)但規(guī)格設(shè)計、品味、頂層架構(gòu)決策必須由人來定。如果連規(guī)矩本身都原封不動地交給模型就等于放棄了最不該外包的那部分判斷。倉庫自己在 CLAUDE.md 開頭就埋了一條權(quán)衡聲明Tradeoff:These guidelines bias toward caution over speed. For trivial tasks, use judgment.偏向謹慎而非速度是一個權(quán)衡取向不是一個普適默認值。你的代碼庫如果是一個快速迭代的腳本倉庫或是一個多人協(xié)作、review 極嚴的微服務(wù)倉庫這條取向的權(quán)重應(yīng)該是完全不同的。不調(diào)整這條基線就是所有本地化錯誤的源頭。二、四個典型改造錯誤與后果錯誤一把不確定就問從兜底條款升格為默認協(xié)議原版第一條原則Think Before Coding的原文是- State your assumptions explicitly. If uncertain, ask. - If multiple interpretations exist, present them - dont pick silently. - If something is unclear, stop. Name whats confusing. Ask.注意原文的措辭順序先明確陳述假設(shè)再呈現(xiàn)多種解釋最后才是停下來問。這是一條兜底條款——只有當歧義真實存在、且錯誤猜測的代價大于澄清成本時才觸發(fā)。但很多人在本地化時會把最后一句刪掉前置條件直接改寫成所有任務(wù)開始前先列出問題清單甚至寫進系統(tǒng)提示詞強制每次開工先提問。后果是可以量化的倉庫在第四條原則里自己寫了判斷標準——Strong success criteria let you loop independently. Weak criteria (make it work) require constant clarification.強成功標準讓模型獨立循環(huán)弱標準則需要不斷澄清。當澄清變成默認協(xié)議每一次任務(wù)都被迫先消耗一輪往返原本一分鐘能完成的瑣碎改動被拖成多輪對話吞吐量直接腰斬。這也正是 SKILL.md 里那句For trivial tasks, use judgment想防的事。正確的本地化姿勢保留先陳述假設(shè)和呈現(xiàn)權(quán)衡這兩個低成本的主動行為把提問嚴格限定在假設(shè)被證偽會破壞正確性的場景同時為項目維護一份已知約定清單命名規(guī)范、分層約定、異常策略讓模型先查約定、再判斷是否需要問。錯誤二拿簡潔優(yōu)先當推倒重寫的許可證第二條原則Simplicity First里有一句極具煽動性的條文If you write 200 lines and it could be 50, rewrite it.這句話在原語境里約束的是模型自己剛寫出的新代碼——寫的時候發(fā)現(xiàn)膨脹了就重寫。但本地化改造時最常見的誤讀是把它當成對存量代碼的審判標準——這段舊代碼 200 行明顯能精簡到 50 行重寫它。這就和第三條原則Surgical Changes直接打架了。后者寫得很死- Dont refactor things that arent broken. - Match existing style, even if youd do it differently. - If you notice unrelated dead code, mention it - dont delete it.不要重構(gòu)沒壞的東西即使你更喜歡別的寫法也要匹配現(xiàn)有風(fēng)格——EXAMPLES.md 里那張反模式對照表把這個沖突講得更直白LLM 最常見的錯誤恰恰是為了修一個 bug 順手改進了相鄰代碼、加了沒人要的用戶名校驗、改了注釋和 docstring。一個把200 行改 50 行奉為圭臬的規(guī)則文件等于給這種順帶重構(gòu)發(fā)了許可證。后果在 diff 審查時爆發(fā)無關(guān)改動淹沒真正的修復(fù)reviewer 無法快速定位變更意圖PR 體量膨脹甚至引入回歸。Karpathy 自己在訪談里也承認他想讓 LLM 幫他進一步精簡 nanoGPT 的代碼模型的表現(xiàn)非常糟糕——簡化是最難被自動化引導(dǎo)的工程行為之一它依賴對業(yè)務(wù)語義的完整理解而這恰恰是實習(xí)生最欠缺的。正確的本地化姿勢把重寫條款的適用范圍限定為本次任務(wù)新產(chǎn)生的代碼并補一條硬規(guī)則——任何對存量代碼的結(jié)構(gòu)性精簡必須先單獨提出并等待確認不得與功能改動混在同一個提交里。錯誤三抽掉驗證回路只留目標口號四條原則里Goal-Driven Execution是唯一自帶閉環(huán)機制的把指令式任務(wù)轉(zhuǎn)化為可驗證目標例如Add validation → Write tests for invalid inputs, then make them pass Fix the bug → Write a test that reproduces it, then make it pass并且為多步任務(wù)規(guī)定了顯式的驗證格式1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check]這套機制的成立前提是你的倉庫存在可執(zhí)行的驗證手段。它默認你有測試框架、能寫一個復(fù)現(xiàn) bug 的測試然后讓它通過。但大量存量項目根本沒有測試基建——老代碼、腳本庫、一次性任務(wù)倉庫連pytest都沒有。在這種倉庫里照抄這條規(guī)則得到的結(jié)果是模型每次都輸出verify: test passes這樣的空殼檢查項驗證回路變成裝飾性文本規(guī)則名存實亡。更隱蔽的后果是偽可驗證沒有測試兜底時模型會把構(gòu)建成功或編譯通過誤當成業(yè)務(wù)正確的證據(jù)Karpathy 訪談里談的可驗證性概念正是關(guān)鍵——模型能力呈鋸齒狀只有在結(jié)果可驗證的領(lǐng)域它才可靠。本地化時如果不為每條規(guī)則掛上項目里真實存在的驗證鉤子就等于把規(guī)則建立在了模型最不可靠的地基上。正確的本地化姿勢為每條成功標準指定本項目實際可用的驗證手段——有測試就用測試沒有測試就退化為明確的可觀察斷言如手動跑通某條命令、檢查特定輸出、對照 checklist 逐項勾選如果連斷言都做不了這條任務(wù)就不該被交給 Agent 獨立循環(huán)。錯誤四整包粘貼三份規(guī)則互相打架這個倉庫最大的坑藏在安裝方式里。README 提供了三種入口Claude Code 插件市場/plugin install andrej-karpathy-skillskarpathy-skills、按項目的curl -o CLAUDE.md、以及 Cursor 的.cursor/rules/項目規(guī)則。很多人的本地化改造就是把這三種方式各來一遍項目里同時出現(xiàn)了一份插件注入的SKILL.md、一份追加的CLAUDE.md、一份.mdc規(guī)則——三份內(nèi)容一致但生效優(yōu)先級和讀取機制完全不同。CURSOR.md 里其實寫了一句關(guān)鍵提示Cursor 默認不讀.claude-plugin/和CLAUDE.md反之 Claude Code 也不讀.cursor/rules/。如果你在 Cursor 項目里只粘貼了CLAUDE.md整個規(guī)則對 Cursor 就是透明的——你以為裝上了其實一條都沒生效。反過來三份都放但內(nèi)容各自改了一版模型在不同工具里拿到的行為準則不一致輸出風(fēng)格來回漂移比不裝更糟。更深一層的沖突來自合并這一步被跳過。README 的 Customization 章節(jié)給出了標準姿勢——在現(xiàn)有CLAUDE.md里追加項目特定指南小節(jié)例如使用 TypeScript 嚴格模式所有 API 端點必須有測試遵循src/utils/errors.ts的錯誤處理模式。原版規(guī)則的設(shè)計意圖是作為通用層與項目層疊加而不是整文件覆蓋。直接整包粘貼會帶來一類典型事故項目約定匹配現(xiàn)有風(fēng)格規(guī)則卻要求如果 200 行能寫成 50 行就重寫——兩條指令同時存在時模型只能隨機選一條執(zhí)行。正確的本地化姿勢確立一份源文件 按工具生成三份副本的維護模型倉庫作者在 CURSOR.md 里就是這么要求貢獻者的項目層約定以追加小節(jié)的方式注入并給規(guī)則標注優(yōu)先級——項目特定指南優(yōu)先于通用指南沖突時以項目特定指南為準。三、一份本地化改造檢查清單結(jié)合上面的四個錯誤本地化一份 Karpathy 風(fēng)格技能包時建議逐項對照保留權(quán)衡聲明并為本倉庫重寫它明確寫下本倉庫哪些場景要求謹慎、哪些場景允許快速放行不要沿用原文的通用取向。給提問加觸發(fā)條件澄清只發(fā)生在假設(shè)被證偽代價高的場景為項目維護約定清單讓模型先查后問。重寫簡潔優(yōu)先的作用域明確200 行改 50 行只適用于本次任務(wù)新產(chǎn)生的代碼存量重構(gòu)必須單獨提 PR。為每條成功標準掛上真實的驗證鉤子測試、命令、斷言、人工 checklist至少占一樣沒有驗證手段的任務(wù)不承諾獨立循環(huán)。統(tǒng)一維護入口規(guī)則正文只維護一份源文件建議 skills/karpathy-guidelines/SKILL.mdCLAUDE.md、.mdc、插件配置均由此生成杜絕三份漂移。聲明沖突仲裁規(guī)則項目特定指南與通用規(guī)則沖突時項目特定指南優(yōu)先并把這個仲裁條款寫進文件頭部。對照生效信號驗收倉庫在 How to Know Its Working 里給了四組可觀察信號——diff 里無關(guān)改動變少、因過度復(fù)雜導(dǎo)致的重寫變少、澄清問題發(fā)生在實現(xiàn)之前、PR 干凈且無順帶重構(gòu)。改造后應(yīng)能以這四項做回歸驗收。四、判斷本地化成敗的最終標準README.md 最后一段其實已經(jīng)給出了檢驗本地化的終極標尺這些規(guī)則起作用的標志不是模型記住了多少條文而是代價發(fā)生的時機是否前移——澄清發(fā)生在實現(xiàn)之前而不是犯錯之后diff 里只出現(xiàn)被請求的改動重寫不是因為過度復(fù)雜而是因為需求變化。換句話說Karpathy 的規(guī)矩本質(zhì)上是把人管理實習(xí)生的方式顯式化給出成功標準、明確作用邊界、要求及時匯報困惑。本地化改造做得對不對不看它被抄得多完整而看它是否在你的倉庫里真的改變了那些代價的分布。照抄只會得到一個行為乖張的實習(xí)生改對了你才擁有一個知道什么時候該問、什么時候該動手的穩(wěn)定協(xié)作者。畢竟就像 Karpathy 在訪談里反復(fù)引用的那句話你可以外包你的思考但你無法外包你的理解。規(guī)則文件可以外包給模型執(zhí)行但為你的代碼庫裁剪規(guī)則這件事理解必須留在你這邊。【免費下載鏈接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.項目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 別照抄 Karpathy 的規(guī)矩：技能包本地化改造時最容易犯的四個錯
別照抄 Karpathy 的規(guī)矩技能包本地化改造時最容易犯的四個錯【免費下載鏈接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.項目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skillsAndrej Karpathy 關(guān)于 LLM 編碼缺陷的幾條觀察在 2026 年幾乎成了 AI 編程圈的公共常識模型會替你做出錯誤假設(shè)然后悶頭執(zhí)行、會把 100 行的需求實現(xiàn)成 1000 行的抽象堆砌、會順手改掉它沒看懂但無關(guān)緊要的注釋還會在沒有明確成功標準的情況下盲目循環(huán)。圍繞這些觀察andrej-karpathy-skills這個倉庫給出了一份極簡的答案——一個CLAUDE.md文件、四條行為準則。社區(qū)熱度也一路走高掘金上有《一天一個開源項目》專門拆解它媒體以專治 AI 瞎寫、失憶、造屎山來概括其價值2026 年 8 月的 GitHub Trending 月度觀察中Agent Skills 更是被列為當月開源圈的關(guān)鍵詞之一。但熱度高不意味著能照抄。恰恰相反這個倉庫的所有文檔里都寫著一句常被忽略的前提——Merge with project-specific instructions as needed按需與項目特定指令合并。這篇文章不重復(fù)講這四條原則是什么而是結(jié)合倉庫源碼本身拆解本地化改造這個動作里最容易犯的四個錯以及一份可落地的檢查清單。一、先搞清楚原版規(guī)矩是為誰的代碼庫寫的先看這個倉庫的真實結(jié)構(gòu)。它不是一個技能框架而是把一套行為準則同時打包成了三份載體CLAUDE.mdClaude Code 按項目讀取的根指令文件skills/karpathy-guidelines/SKILL.md帶 YAML frontmatter 的可復(fù)用技能包通過 .claude-plugin/plugin.json 掛載.cursor/rules/karpathy-guidelines.mdcCursor 項目規(guī)則alwaysApply: true。三份文件的正文幾乎逐字一致這是倉庫作者刻意為之的單源多端設(shè)計——CURSOR.md 里明確要求貢獻者改動四條原則時必須三份同步。也就是說原版規(guī)矩的設(shè)計目標是跨工具一致而不是貼合某個具體代碼庫。這也是它不適合直接照抄的根本原因原版描述的是一個通用場景下的理想 Agent而你面對的是一個有歷史包袱、有既有風(fēng)格、有真實測試基建的倉庫。Karpathy 本人在訪談里也反復(fù)強調(diào)這一點——他把現(xiàn)在的 AI 編碼助手定位成能力出眾但還不穩(wěn)定的實習(xí)生實習(xí)生可以負責(zé)底層實現(xiàn)細節(jié)但規(guī)格設(shè)計、品味、頂層架構(gòu)決策必須由人來定。如果連規(guī)矩本身都原封不動地交給模型就等于放棄了最不該外包的那部分判斷。倉庫自己在 CLAUDE.md 開頭就埋了一條權(quán)衡聲明Tradeoff:These guidelines bias toward caution over speed. For trivial tasks, use judgment.偏向謹慎而非速度是一個權(quán)衡取向不是一個普適默認值。你的代碼庫如果是一個快速迭代的腳本倉庫或是一個多人協(xié)作、review 極嚴的微服務(wù)倉庫這條取向的權(quán)重應(yīng)該是完全不同的。不調(diào)整這條基線就是所有本地化錯誤的源頭。二、四個典型改造錯誤與后果錯誤一把不確定就問從兜底條款升格為默認協(xié)議原版第一條原則Think Before Coding的原文是- State your assumptions explicitly. If uncertain, ask. - If multiple interpretations exist, present them - dont pick silently. - If something is unclear, stop. Name whats confusing. Ask.注意原文的措辭順序先明確陳述假設(shè)再呈現(xiàn)多種解釋最后才是停下來問。這是一條兜底條款——只有當歧義真實存在、且錯誤猜測的代價大于澄清成本時才觸發(fā)。但很多人在本地化時會把最后一句刪掉前置條件直接改寫成所有任務(wù)開始前先列出問題清單甚至寫進系統(tǒng)提示詞強制每次開工先提問。后果是可以量化的倉庫在第四條原則里自己寫了判斷標準——Strong success criteria let you loop independently. Weak criteria (make it work) require constant clarification.強成功標準讓模型獨立循環(huán)弱標準則需要不斷澄清。當澄清變成默認協(xié)議每一次任務(wù)都被迫先消耗一輪往返原本一分鐘能完成的瑣碎改動被拖成多輪對話吞吐量直接腰斬。這也正是 SKILL.md 里那句For trivial tasks, use judgment想防的事。正確的本地化姿勢保留先陳述假設(shè)和呈現(xiàn)權(quán)衡這兩個低成本的主動行為把提問嚴格限定在假設(shè)被證偽會破壞正確性的場景同時為項目維護一份已知約定清單命名規(guī)范、分層約定、異常策略讓模型先查約定、再判斷是否需要問。錯誤二拿簡潔優(yōu)先當推倒重寫的許可證第二條原則Simplicity First里有一句極具煽動性的條文If you write 200 lines and it could be 50, rewrite it.這句話在原語境里約束的是模型自己剛寫出的新代碼——寫的時候發(fā)現(xiàn)膨脹了就重寫。但本地化改造時最常見的誤讀是把它當成對存量代碼的審判標準——這段舊代碼 200 行明顯能精簡到 50 行重寫它。這就和第三條原則Surgical Changes直接打架了。后者寫得很死- Dont refactor things that arent broken. - Match existing style, even if youd do it differently. - If you notice unrelated dead code, mention it - dont delete it.不要重構(gòu)沒壞的東西即使你更喜歡別的寫法也要匹配現(xiàn)有風(fēng)格——EXAMPLES.md 里那張反模式對照表把這個沖突講得更直白LLM 最常見的錯誤恰恰是為了修一個 bug 順手改進了相鄰代碼、加了沒人要的用戶名校驗、改了注釋和 docstring。一個把200 行改 50 行奉為圭臬的規(guī)則文件等于給這種順帶重構(gòu)發(fā)了許可證。后果在 diff 審查時爆發(fā)無關(guān)改動淹沒真正的修復(fù)reviewer 無法快速定位變更意圖PR 體量膨脹甚至引入回歸。Karpathy 自己在訪談里也承認他想讓 LLM 幫他進一步精簡 nanoGPT 的代碼模型的表現(xiàn)非常糟糕——簡化是最難被自動化引導(dǎo)的工程行為之一它依賴對業(yè)務(wù)語義的完整理解而這恰恰是實習(xí)生最欠缺的。正確的本地化姿勢把重寫條款的適用范圍限定為本次任務(wù)新產(chǎn)生的代碼并補一條硬規(guī)則——任何對存量代碼的結(jié)構(gòu)性精簡必須先單獨提出并等待確認不得與功能改動混在同一個提交里。錯誤三抽掉驗證回路只留目標口號四條原則里Goal-Driven Execution是唯一自帶閉環(huán)機制的把指令式任務(wù)轉(zhuǎn)化為可驗證目標例如Add validation → Write tests for invalid inputs, then make them pass Fix the bug → Write a test that reproduces it, then make it pass并且為多步任務(wù)規(guī)定了顯式的驗證格式1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check]這套機制的成立前提是你的倉庫存在可執(zhí)行的驗證手段。它默認你有測試框架、能寫一個復(fù)現(xiàn) bug 的測試然后讓它通過。但大量存量項目根本沒有測試基建——老代碼、腳本庫、一次性任務(wù)倉庫連pytest都沒有。在這種倉庫里照抄這條規(guī)則得到的結(jié)果是模型每次都輸出verify: test passes這樣的空殼檢查項驗證回路變成裝飾性文本規(guī)則名存實亡。更隱蔽的后果是偽可驗證沒有測試兜底時模型會把構(gòu)建成功或編譯通過誤當成業(yè)務(wù)正確的證據(jù)Karpathy 訪談里談的可驗證性概念正是關(guān)鍵——模型能力呈鋸齒狀只有在結(jié)果可驗證的領(lǐng)域它才可靠。本地化時如果不為每條規(guī)則掛上項目里真實存在的驗證鉤子就等于把規(guī)則建立在了模型最不可靠的地基上。正確的本地化姿勢為每條成功標準指定本項目實際可用的驗證手段——有測試就用測試沒有測試就退化為明確的可觀察斷言如手動跑通某條命令、檢查特定輸出、對照 checklist 逐項勾選如果連斷言都做不了這條任務(wù)就不該被交給 Agent 獨立循環(huán)。錯誤四整包粘貼三份規(guī)則互相打架這個倉庫最大的坑藏在安裝方式里。README 提供了三種入口Claude Code 插件市場/plugin install andrej-karpathy-skillskarpathy-skills、按項目的curl -o CLAUDE.md、以及 Cursor 的.cursor/rules/項目規(guī)則。很多人的本地化改造就是把這三種方式各來一遍項目里同時出現(xiàn)了一份插件注入的SKILL.md、一份追加的CLAUDE.md、一份.mdc規(guī)則——三份內(nèi)容一致但生效優(yōu)先級和讀取機制完全不同。CURSOR.md 里其實寫了一句關(guān)鍵提示Cursor 默認不讀.claude-plugin/和CLAUDE.md反之 Claude Code 也不讀.cursor/rules/。如果你在 Cursor 項目里只粘貼了CLAUDE.md整個規(guī)則對 Cursor 就是透明的——你以為裝上了其實一條都沒生效。反過來三份都放但內(nèi)容各自改了一版模型在不同工具里拿到的行為準則不一致輸出風(fēng)格來回漂移比不裝更糟。更深一層的沖突來自合并這一步被跳過。README 的 Customization 章節(jié)給出了標準姿勢——在現(xiàn)有CLAUDE.md里追加項目特定指南小節(jié)例如使用 TypeScript 嚴格模式所有 API 端點必須有測試遵循src/utils/errors.ts的錯誤處理模式。原版規(guī)則的設(shè)計意圖是作為通用層與項目層疊加而不是整文件覆蓋。直接整包粘貼會帶來一類典型事故項目約定匹配現(xiàn)有風(fēng)格規(guī)則卻要求如果 200 行能寫成 50 行就重寫——兩條指令同時存在時模型只能隨機選一條執(zhí)行。正確的本地化姿勢確立一份源文件 按工具生成三份副本的維護模型倉庫作者在 CURSOR.md 里就是這么要求貢獻者的項目層約定以追加小節(jié)的方式注入并給規(guī)則標注優(yōu)先級——項目特定指南優(yōu)先于通用指南沖突時以項目特定指南為準。三、一份本地化改造檢查清單結(jié)合上面的四個錯誤本地化一份 Karpathy 風(fēng)格技能包時建議逐項對照保留權(quán)衡聲明并為本倉庫重寫它明確寫下本倉庫哪些場景要求謹慎、哪些場景允許快速放行不要沿用原文的通用取向。給提問加觸發(fā)條件澄清只發(fā)生在假設(shè)被證偽代價高的場景為項目維護約定清單讓模型先查后問。重寫簡潔優(yōu)先的作用域明確200 行改 50 行只適用于本次任務(wù)新產(chǎn)生的代碼存量重構(gòu)必須單獨提 PR。為每條成功標準掛上真實的驗證鉤子測試、命令、斷言、人工 checklist至少占一樣沒有驗證手段的任務(wù)不承諾獨立循環(huán)。統(tǒng)一維護入口規(guī)則正文只維護一份源文件建議 skills/karpathy-guidelines/SKILL.mdCLAUDE.md、.mdc、插件配置均由此生成杜絕三份漂移。聲明沖突仲裁規(guī)則項目特定指南與通用規(guī)則沖突時項目特定指南優(yōu)先并把這個仲裁條款寫進文件頭部。對照生效信號驗收倉庫在 How to Know Its Working 里給了四組可觀察信號——diff 里無關(guān)改動變少、因過度復(fù)雜導(dǎo)致的重寫變少、澄清問題發(fā)生在實現(xiàn)之前、PR 干凈且無順帶重構(gòu)。改造后應(yīng)能以這四項做回歸驗收。四、判斷本地化成敗的最終標準README.md 最后一段其實已經(jīng)給出了檢驗本地化的終極標尺這些規(guī)則起作用的標志不是模型記住了多少條文而是代價發(fā)生的時機是否前移——澄清發(fā)生在實現(xiàn)之前而不是犯錯之后diff 里只出現(xiàn)被請求的改動重寫不是因為過度復(fù)雜而是因為需求變化。換句話說Karpathy 的規(guī)矩本質(zhì)上是把人管理實習(xí)生的方式顯式化給出成功標準、明確作用邊界、要求及時匯報困惑。本地化改造做得對不對不看它被抄得多完整而看它是否在你的倉庫里真的改變了那些代價的分布。照抄只會得到一個行為乖張的實習(xí)生改對了你才擁有一個知道什么時候該問、什么時候該動手的穩(wěn)定協(xié)作者。畢竟就像 Karpathy 在訪談里反復(fù)引用的那句話你可以外包你的思考但你無法外包你的理解。規(guī)則文件可以外包給模型執(zhí)行但為你的代碼庫裁剪規(guī)則這件事理解必須留在你這邊。【免費下載鏈接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.項目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考