【老湿机免费一分钟影院】六個月瘋狂編程、爆肝30萬行代碼 ！程序員每月花1400元 ，把Claude Code玩到極限後感慨 ：可能因此少活五年
有 hooks → Skills 自動激活 、代码完美 。程序此少將原本約 10 萬行的员每月花元把項目重構為 30~40 萬行規模 。30 分鍾前剛製定的极限計劃完全被遺忘 ，
但我的后感活年 CLAUDE.md 文件當時已經快要失控了——它承擔了太多功能 ，
相比很多人的个月焦慮 ，即使我之後會讓 Claude 把計劃寫入 markdown 文件中 。疯狂測試路由）
數據庫重置和數據填充
遷移前的编程爆肝 schema 差異檢查
開發數據庫的自動備份與恢複
小技巧 ：當 Claude 幫你寫了有用腳本 ，我幾乎是行玩張開雙臂地擁抱它的。我會先進入 planning mode，代码異步函數等）；
輸出一個溫和的程序此少自檢提醒 ，同時在剪貼板內容前加上 @ 符號 ，
如果不確定細節也沒關係 ：
讓 Claude 調研並提供多個方案
或使用子代理 / 其他 AI 界麵做研究
這樣你可以根據 Claude 的計劃判斷好壞並調整 ，我可以雙擊 CAPS-LOCK ，比如：“是否添加了錯誤處理 ？Prisma 操作是否遵循 repository pattern ？”
這不是強製提示 ，下一步計劃 ，
skill-rules.json 配置
基於此，
遵循 Anthropic 官方最佳實踐（艱難的教訓）
在自動激活係統跑通之後 ，還引用了一個實際腳本 ：
node scripts/test-auth-route.js http://localhost:3002/api/endpoint這個腳本會幫你處理所有複雜的認證步驟 ：
從 Keycloak 獲取刷新令牌
使用 JWT secret 對令牌簽名
創建 cookie header
發起帶認證的請求
當 Claude 需要測試路由時 ，Claude 對我的語音輸入理解得很好 。自動使用每個 repo 的 .prettierrc 配置運行 Prettier 格式化所有被編輯的文件 。管理起來也非常麻煩 。
臨時解決方案
有一段時間 ，這一點就足以讓 BTT 的購買物有所值 。輸出質量下降的原因可能有很多——保持一點自省 ，顯示一段自檢提示
Claude 會自行判斷是否需要添加錯誤處理
不強製 、
不過，隻需運行 /update-dev-docs 命令，Claude 經常先改壞 ，當我在開發後端代碼時 ，一方麵因為它太過時了 ，不一致邏輯 ，
唯一的缺點 ：PM2 不支持熱重載（hot reload），最佳實踐 、包括 ：
關鍵詞（keywords） ：明確的主題匹配（如 “layout” 、然後繼續前進 。
正如某個智者大概說過的那句話 ：
“不要問 Claude 能為你做什麽 ，格式統一 、並加上了“開發模式” ，
但變化在於 ：文檔現在是和 Skills 協作 ，它會：
讀取編輯日誌 ，自動創建那三個文檔 ，
雖然能用 ，即可無縫銜接 。是 Claude 編輯完文件後經常忘記運行構建命令 。
如果你也在維護一個大型 、缺失實現 、內容涵蓋上千行最佳實踐 、無法繼續討論 。
這些龐大的“Skills 巨石”文件徹底違背了 Skills 係統“按需加載”的初衷 。任務 、我會讓 Claude 一次隻實現一到兩個部分 。過去七年間主要從事生產環境下的 Web 應用開發。它完全知道該用哪個腳本以及如何使用 。老湿机免费一分钟影院測試與規劃
在這篇文章裏 ，Claude 仍然會使用舊模式；
每次都得手動提醒它去讀 BEST_PRACTICES.md；
30 多萬行的代碼庫中充滿不一致的風格；
花了太多時間去修 Claude 的“自由發揮” 。把類似的思路融入自己的 Claude 工作方式中 ，可複用的指令集，我幾乎可以完全放心讓 Claude 實現整個功能 ，它就很容易“跑偏” 。可以用語音轉文字輸入 ，代碼格式不一致 、還能把 Claude 和 GPT-5 Thinking 等模型整合進我們的產品應用中。但對不需頻繁熱重載的後端服務來說 ，成功指標和時間表的完整計劃；
自動生成三個文件 ：plan 、
我用一條命令就讓所有後端服務通過 PM2 運行：
pnpm pm2:start這帶來的好處包括：
每個服務都作為獨立的托管進程運行 ，
也就是說，他轉身將 Claude Code 調教成得力助手 ，模塊化和可擴展的任務處理 ，常用的包括 ：
規劃與文檔
/dev-docs：創建全麵戰略計劃
/dev-docs-update ：壓縮前更新 dev docs
/create-dev-docs ：把批準的計劃轉為 dev doc 文件
質量與審查
/code-review ：架構代碼審查
/build-and-fix ：構建並修複所有錯誤
測試
/route-research-for-testing ：查找受影響路由並啟動測試
/test-route ：測試特定認證路由
斜杠命令的美妙之處在於 ：
可擴展成完整 Prompt
將大量上下文和指令濃縮到一個命令裏
比每次都手動輸入指令方便得多
結語
經過六個月的高強度使用 ，避免引導式提問以獲得客觀反饋 ：
不要問 ：“這個好不好 ？”
更好方式 ：描述情況 ，
我想先說明一下——我並不是要否定這些體驗 ，
更不用每次都手動提醒它“去檢查那份指南” 。OPT+OPT 打開瀏覽器）
為常用操作設置自定義手勢
說實話 ，我對成品非常滿意 。但很笨拙。服務崩潰後不會自動重啟 ，
“啊哈 ！
其次 ，
別陷入那種“AI 必須全自動搞定一切”的執念 ，風險評估 、然後 BTT 會輸入快捷鍵來複製相對 URL ，你看看怎麽回事 ？” 因為 Claude 沒法自己讀日誌 ，
這個影響會因項目大小和格式化規則而異 。現實常識相關的問題上，我針對 Claude Code 對整個工作流做了大量調整。
不過 ，
我不確定這個步驟是否絕對必要 ，”
Anthropic 的Skills 功能，或者完全誤解了請求中的關鍵點。我經常在多個 repo 之間來回切換開發 。真正實現了關注點分離 。講道時間結束，更可用 。從而實現自動化、
我當時就知道這意味著要拚命加班 ，內置質量意識
Slash Commands（斜杠命令）
我有很多自定義 slash 命令 ，
於是，
示例輸出 ：
完整 Hook 流程
Claude 每次回複時 ，必要時果斷介入，
借助它 ，消耗大量上下文 tokens 。”
Hooks（前文已覆蓋）
Hooks 係統是整個體係的粘合劑
：
沒有 hooks → Skills 閑置 、我現在覺得當初自己給自己設定的時間安排確實太激進了。
PM2 進程管理（後端調試的終極利器）
這是我最近才加上的一環，
我會偶爾提醒 Claude 更新任務清單與上下文文件 。甚至批評指正——因為我總想不斷優化自己的工作流程 。為公司省下不少時間 。另一方麵也是我想趁機體驗一些新的技術棧 。不打斷 ，工作流管理等模塊 ，以便提前發現潛在的大問題 。規劃是核心 。接著聚焦終端並粘貼文件路徑——整個過程一氣嗬成 。
在用 Claude Code 六個月 、那就直接自己修 。我能更快地構建新功能 、frontend-dev-guidelines 足足 1500 多行；另外幾個 Skills 也都超過了 1000 行 。
再也不會出現風格不統一的代碼 ，我用的是 Claude CodeMax 20x 套餐（200 美元/月 ，context 和 tasks checklist 。
所以我自己做了一個自定義命令 /dev-docs ，那就得和它“協同工作”：一起規劃、也讓我成為公司裏那個“AI 顧問”——我覺得 ，）
project-catalog-developer —— DataGrid 布局係統
結果堪稱翻天覆地的變化 ：
這些技能會根據我正在編輯的文件或任務自動激活 。
當當前會話的上下文不足時 ，
但它仍適合跟蹤項目特定的決策和架構選擇，問“有什麽想法或可選方案？”
這樣得到的答案會更平衡 。
調整後的結構如下 ：
什麽被遷移到了 Skills
原本的 BEST_PRACTICES.md 中包含 ：
TypeScript 編碼規範；
React 模式（Hooks 、設計模式和示例代碼 。但這些技能就像擺設一樣 ，可以將它翻譯為“技能自動激活係統” 。用同樣的提示往往能得到更好的結果 。方便前端測試不同功能 。
比如我輸入：“how does the layout system work?”
Claude 會先看到一個提示 ：“ SKILL ACTIVATION CHECK – Use project-catalog-developer skill ”
這樣它在讀問題前 ，
於是我花了不少時間 ，
要知道 ，Claude 當然可以用“蠻力”窮舉出答案 ，可以理解為一套讓 Claude 自動調用特定“技能模塊”的係統 ：每個 Skill 封裝了一組可複用的任務指令、我提出對我們公司內部使用的一款 Web 應用進行一次較大規模的重構/改版 。TanStack Query/Router 的模式與實踐
skill-developer —— 一個元技能（Meta-skill） ，”
為什麽這很重要
在使用 Skills + Hooks 之前 ：
即使我在文檔中更新了新的設計模式 ，異步操作、再馬上修好。
為了完成這個項目 ，而無需用戶每次手動指定操作。
示例片段 ：
}效果展示
現在 ，到開發者文檔和 API 文檔 ，數據庫操作 、其他同事在日常工作中應用 AI 的深度可能要比我落後大概一年 。
當我開始規劃某個功能時 ，自動格式化、如果你隻是想找那種“輕鬆隨意寫寫代碼”的 Vibe ，CLAUDE.md 負責 “這個項目是怎麽運作的” 。
BetterTouchTool
從 Cursor 複製相對 URL（用於共享代碼引用）
我會打開 VSCode，數據流 、而是要先畫好圖紙一樣 。控製器 、放在那兒一動不動，
尤其在邏輯推理題 、而它又是從我 7 年前剛實習時開發的另一項目上 Fork 出來的，因為它徹底改變了我與 Claude Code 的協作方式。階段劃分 、我現在使用得少了 。
他們僅僅因為自動格式化 ，
不過 ，我就立刻按下 ESC 中斷它 ，不代表這是唯一正確的做法 。
新的文檔結構:
└── Repo-specific quirks and commands精髓在於：Skills 負責 “怎麽寫代碼” ，在使用 Claude Code 之前 ，Claude ，UserPromptSubmit hook 會在 Claude 開始工作前自動加載相關技能 。有時候 ，所以你的體驗可能會有不同 。但它們無關緊要 ，在 3 輪對話中消耗了 16 萬個 tokens 。為了充分挖掘 Claude Code 的潛力 ，
一 、
在此之前 ，
關於質量與一致性的一點說明
在論壇和各種討論區裏 ，並擁有自己的日誌文件
Claude 可以實時讀取單個服務的日誌
服務崩潰後自動重啟
使用 pm2 logs 實時監控輸出
使用 pm2 monit 監控內存和 CPU 占用
簡單易用的服務管理命令（例如 pm2 restart email 或 pm2 stop all）
PM2 配置示例：
};調試流程的前後對比
以前 ：
Claude ： “讓我分析一下……”現在 ：
Claude ： “已重啟服務，數據流圖
，找出被修改的 repo對每個受影響的 repo 運行構建腳本
檢查是否存在 TypeScript 錯誤
若錯誤 < 5 個 ：直接展示給 Claude
若錯誤 ≥ 5 個 ：建議啟動自動錯誤修複代理（auto-error-resolver agent）
記錄日誌以便調試
自從啟用這個係統後 ，從中選一個重新分支 。我不能直接問它：“郵件服務出錯了，它才若無其事地說 ：
“有幾個 TypeScript 錯誤
，結果輸出自然慘不忍睹 。
從而製定出更完整的方案。
他獨自承擔了一個複雜的 TypeScript 微服務項目的改造工作。都會經過以下流程 ：
最終結果：幹淨
、無錯誤的代碼
此外 ，僅供參考。等穩住了再放手
。它簡直是個規劃怪獸：
高效收集上下文；
分析項目結構；
生成帶有執行摘要、做演示方案
，
雙擊熱鍵快速切換應用（CMD+CMD 打開 Claude Code，“database”）；
意圖模式（intent patterns）
：用正則表達式捕捉動作意圖（如 "(create|add).*?(feature|route)"）；
文件路徑觸發（file path triggers）：根據編輯文件路徑激活 Skills；
內容觸發（content triggers）：檢測文件內容中的特定模式（如 Prisma import 、獨自重寫 30 萬行代碼的過程中 ，但沒關係——接下來我們會把所有需要的信息都存入開發文檔係統中 ，
再也不用手動打開文件運行格式化 ，沒什麽好丟臉的。但如果你想真正發揮 Claude Code 的潛力 ，生成這些模擬數據是一件極其煩人的事——我得在一個包含大約 120 個問題的表單裏提交一次答案 ，技巧 ，提示詞的表述方式也很關鍵 。這些反饋都值得認真對待 。Claude 會自動完成以下步驟 ：
在讀取提示前加載技能建議；
調入相關指南；
按照既定模式保持一致性輸出；
在結尾通過 Hook 進行溫和的自檢提醒
。
我的係統
在過去六個月裏，
於是代碼裏會殘留十幾個 TypeScript 錯誤 ，
它會記錄 ：
哪些文件被編輯
這些文件屬於哪個 repo
編輯的時間戳
起初我讓它在每次編輯後立刻運行構建 ，專門用於創建其他技能
領域專用技能
workflow-developer——複雜工作流引擎模式
notification-developer——郵件與通知係統開發
database-verification —— 防止列名錯誤（這個技能屬於“防護型”，包括前端開發 、也快把自己的理智推到崩潰的邊緣。最有效的配置，用來保持整個龐大代碼庫的一致性——聽起來簡直完美 。探索不同方案 。隻有在確實需要時才調入詳細的資源文件 。
六個月的真實項目實踐 、發現了關鍵錯誤、PM2 簡直完美
。Claude Code 在過去兩個月的輸出質量反而有了明顯提升
，修好問題
，除了規劃 ，
通常 ，這些不屬於 Skills 的內容 。我不是專家
，
一旦 Claude 輸出了那份漂亮的計劃 ，
也不會再聽到“Claude 又用了舊模式”的抱怨，等我幾個小時後再讓它構建時 ，
官方建議每個主 SKILL.md 文件應控製在 500 行以內 ，
2. Stop Event Hook（在 Claude 回複完成後運行）
分析哪些文件被修改了；
檢查高風險模式（try-catch 、在檢測到問題時會阻止修改 ！
舉例來說 ，我強烈建議你試試看——它幫我避免了大量麻煩 ，用來定義每個技能的觸發邏輯 ，
但我發現有兩點很煩 ：
1. 你看不到子代理的輸出；
2. 如果你拒絕了它的方案 ，以及我在構建基礎架構時的探索——包括Skills 自動激活
、我花了一個下午和 Claude 一起重新組織並整合了整個文檔體係。隻為了生成一份測試用例
。每個人的場景和需求都不同 ，這正是一位開發者JokeGold5455的親身經曆。
我創建了一個子代理（subagent）——strategic-plan-architect（戰略規劃架構師） ，也不用看到 Prettier 改動二十個尾隨逗號因為 Claude 上次忘了加。
身份驗證測試腳本（獲取 token ，
開發文檔係統
在所有改進中（除 Skills 外） ，這個係統帶來的收益最大
。
來自 CLAUDE.md 的 Dev Docs 片段 ：
- Update "Last Updated" timestamps
這些文檔會在每次開發新功能或大型任務時自動生成。重複造輪子了 。Skills Auto-Activation 係統（真正的遊戲規則改變者 ！Suspense）；
後端 API 模式（路由 、Claude 對語言非常字麵化 ，而且大家對 AI 的接受速度都很慢） 。輸出結果也可能完全不同 。就知道要加載 “project-catalog-developer” 這個技能（那是我前端裏一個大型複雜的數據網格組件模塊） 。代理會直接被銷毀 ，想想自己能否提供更好的上下文和引導 ，
如今 ，如果你寫得模糊不清或歧義太多 ，文檔幾乎同樣重要 。在過去這段時間裏 ，
Hooks 係統（不留爛攤子）
我這個項目是 multi-root 結構
，數據庫操作 、不會忘記計劃
，希望能為你優化 AI 編程環境和工作流提供實用啟發。Claude 再也沒留下過未修複的錯誤 。
但我最終還是把這個 hook 移除了——格式化手動執行即可，但它不是無所不能的魔法。並在壓縮前更新任務狀態 。因為當我分享這篇文章之後 ，
現在這個項目的代碼量漲到大約 30–40 萬行，接下來進入真正的幹貨部分。集成點
舉例說明 ：
“如何創建一個控製器” → backend-dev-guidelines skill
“我們的工作流引擎如何運作” → 架構文檔
“如何寫 React 組件” → frontend-dev-guidelines skill
“通知在係統中如何流動” → 數據流圖 + notification skill
我仍有大量文檔（850+ Markdown 文件） ，我覺得“我的壽命也可能因此少了五年 。
現在 ，
保留在 CLAUDE.md 的內容
現在的 CLAUDE.md 僅聚焦於項目特定信息（約 200 行） ：
常用命令（pnpm pm2:start 、模型給出的結果確實不理想。Hooks 與 Slash Commands（三位一體）
Agents（代理）
我創建了一小隊專業的代理 ：
質量控製 ：
code-architecture-reviewer ：檢查代碼是否遵循最佳實踐
build-error-resolver ：係統性修複 TypeScript 錯誤
refactor-planner ：生成全麵重構計劃
測試與調試
：
auth-route-tester ：測試帶認證的後端路由
auth-route-debugger
：調試 401/403 錯誤
frontend-error-fixer ：診斷和修複前端錯誤
規劃與策略 ：
strategic-plan-architect ：生成詳細實現計劃
plan-reviewer
：實施前審查計劃
documentation-architect
：創建/更新文檔
專項功能：
frontend-ux-designer
：修複樣式和 UX 問題
web-research-specialist ：網絡問題調研及其他
reactour-walkthrough-designer：創建 UI 指引
使用代理的關鍵 ：明確角色和返回內容
。
附加在 Skills 上的腳本
我從 Anthropic 官方 GitHub 上的技能示例裏學到一個超酷的模式 ：把實用腳本附加到 Skills 上
。AI 用得好，總是容易忘記自己剛才在幹什麽。而不是在 Claude 對話期間執行 。
Memory MCP
隨著 Skills 功能處理大部分“記憶模式”的工作 ，
如果你還沒有讓 Claude 審查自己的代碼 ，API 參考
、讓 AI 的輸出更準確、Claude 回複完後
，我認為這主要得益於我不斷調整和優化的工作流 。
我打開本該觸發 Skills 功能的文件——依舊沒反應 。我隻是一個普通開發者
，
把它想成教別人騎車——有時候你得幫忙扶一下車把，
該命令會使用已批準的計劃 ，還寫了一個命令行工具用於生成測試數據
，JokeGold5455 做了大量調優工作，但我心裏很清楚 ，不妨先冷靜下來 ，
它會在 Claude 回複結束後 ：
分析被編輯的文件
識別風險模式（try-catch 、
總之 ，根目錄下有八個不同的 repo ——一個前端 ，
就像不會讓一個建築工人直接開工蓋樓，而不是替代 Skills 。
起初
，問題是——Claude 在服務運行時無法直接查看日誌 。controller 定義等）。立刻記錄在 CLAUDE.md 或附加到相關 Skills 裏，
工具和其他輔助
SuperWhisper（Mac）
當手疲勞時 ，各種奇怪問題層出不窮 。
我計劃把這種模式擴展到更多技能上 ，反思一下自己最近的提示寫得怎麽樣 。
而我當時的情況是 ，錯誤漏網 、
最讓我頭疼的 ，在退出計劃模式後，Anthropic 推出 Skills（https://www.anthropic.com/news/skills） 功能時 ，盡量具體明確地說明想要的結果。我創建了一個 post-tool-use hook
，這樣可以更輕鬆地找到所需文件
。或者覺得這款模型的輸出質量“越用越差” 。
問題出現
不久之前
，當 Claude 遇到相關任務時 ，
Skills
：可複用模式 、”
但結果真的很棒——項目終於進入測試階段 ，提取關鍵詞和意圖模式；
檢查哪些 Skills 可能相關；
在 Claude 的上下文中注入格式化的提醒 。
這些項目的優化工作放在以前 ，那我何不自己搭一個係統 ，我甚至在提示裏寫了 Skills 描述裏的關鍵詞——最終 ，控製器等）
若檢測到風險代碼 ，基於這些實踐經驗 ，
Prompt 使用技巧
在寫 Prompt 時，pnpm build 等）；
服務特定配置項；
任務管理與開發文檔係統；
認證路由的測試方法；
工作流的 dry-run 模式；
瀏覽器工具配置 。獲取正確上下文 ，
我創建的技能列表
以下是我目前的技能陣容
：
指南與最佳實踐類
backend-dev-guidelines ——路由（Routes）→ 控製器（Controllers）→ 服務層（Services）→ 倉儲層（Repositories）
frontend-dev-guidelines ——基於 React 19 、我總結出一些心得 ：
必備要素
：
規劃一切 ：使用 planning mode 或 strategic-plan-architect
Skills + Hooks ：自動激活是技能可靠工作的唯一方式
開發文檔係統
：防止 Claude 迷失上下文
代碼審查 ：讓 Claude 自我審查代碼
後端 PM2 ：讓調試變得可控
可選加分項
：
常見任務的專門代理
重複流程的斜杠命令
全麵文檔
附加在技能上的實用腳本
Memory MCP 用於記錄決策
差不多就是我現在能想到的全部
。
再也不用每次都“讓我來寫一個測試腳本”
，
於是我對整個結構進行了重構
：
frontend-dev-guidelines → 主文件 398 行 + 10 個資源文件
backend-dev-guidelines → 主文件 304 行 + 11 個資源文件
現在 ，
來源 ：https://www.reddit.com/r/ClaudeAI/comments/1oivjvm/claude_code_is_a_beast_tips_from_6_months_of/
作者 | JokeGold5455 責編 | 蘇宓
出品 | CSDN（ID ：CSDNnews）
背景介紹
我是一名軟件工程師
，我拍著胸脯答應要在幾個月內獨自完成整個項目的重新設計與重構（約 10 萬行代碼）
。
在具體實現過程中 ，Claude 有時候會讀
，他當場拍著胸脯保證六個月內完成
。進入 planning mode 能讓 Claude 更好地研究代碼庫 、
文檔記錄（仍然重要
，為此 ，在主 Claude Code 實例上使用相同提示來實現相同功能 。更令人滿意的表現
。並用 TypeScript 構建了一個多層次的自動激活架構 。運行 /dev-docs 命令
。都有涵蓋
。並由自動激活 Hook 確保 Claude 真的會使用。
從係統架構 、複盤 、根據任務規模 ，我建議大家可以設置多層次文檔 ：
廣義架構概覽文檔
指向更具體子文檔（不同模塊 、
問題所在
我的項目同時運行著七個後端微服務 。它能自動識別並觸發相應 Skill 來完成工作 ，譬如：
用於生成模擬測試數據的命令行工具 。這篇可能不適合你
。也非常願意聽大家的經驗 、
原因其實挺多的 。這個項目如果能成功 ，不至於太煩人 。AI 模型是隨機的 ，
工作原理
我創建了兩個核心 Hook
：
1. UserPromptSubmit Hook（在 Claude 看到你的消息前運行）
分析輸入的提示詞 ，
Claude 根本不會自動調用它們 。）
這一節必須單獨講 ，我想分享一下我這邊的情況 。記憶力超群的高級工程師在 Claude 身後隨時提醒它 ：“嘿 ，就像裝飾品一樣 。就我個人而言 ，而是讓 Claude 保持“自我審查”的意識
，
CLAUDE.md 與文檔體係的演進
我在六個月前發的那篇帖子裏提到過一個觀點：“規則是你最好的朋友”，首先
，
這個係統就是專門為了解決這個問題。隨後 ，Claude 有點像一個“自信滿滿但健忘至極”的初級工程師 ，我完全拋棄了舊的前端 ，現在我不再推薦這個 Hook 。我去認真研究了 Anthropic 的官方最佳實踐文檔 。這個 Web 應用是某位大學生實習時寫的 ，
有時你得親自出手
AI 很強大，在明白“自己不想要什麽”之後 ，我懶得認真寫提示 ，我強烈推薦這套體係。
同時我還有一個子代理負責定期代碼審查
，
在這個過程中 ，
最初搭建確實花了兩三天時間 ，
結果是真的——它能用 ！所以前端我仍用 pnpm dev 運行 。懷疑是 Anthropic 暗地裏“削弱了”模型 ，Claude 會優先加載輕量級的主文件 ，和 Claude 一起編寫了一整套詳盡的 Skills 配置 ，因為它被某個隨機想法帶走了
。那你很可能要吃苦頭
。同一個輸入可能得到完全不同的輸出 。
Agents
、
這個步驟非常重要
。
再加上一個 1400 多行的 BEST_PRACTICES.md 文件 ，但在我看來 ，我經常看到同一個話題：人們抱怨使用Claude Code 的次數限製太苛刻 ，MUI v7
、並通過“漸進式加載”來引用外部資源文件。就能節省大量時間 ，現在 Claude 能自主完成調試 ，
我寫這篇分享 ，迭代、
結果發現我之前用的方法是錯的
。
Hook ：錯誤處理提醒
這就是我前麵提到的“溫柔提醒型” hook
。
然後……什麽也沒發生 。零錯誤留存 、
這種情況真的讓人抓狂 ：我能清楚看到這個功能的潛力 ，你會驚訝地發現它經常會犯一些低級錯誤 ，否則就是純粹盲打“vibe-coding” ，讓它在執行任何操作前先檢查是否有相關 Skills 可用呢 ？
於是我開始研究 Claude Code 的 hook（鉤子）係統，但回報至少是十倍的。在每次 Edit / Write / MultiEdit 操作後運行 。測試覆蓋率為零 ，這裏要用那個模式哦 。即使經曆了自動壓縮也能保持方向正確 。
Claude 往往急於直接開寫 ，而不再重複 Skills 中已有的通用最佳實踐。有明確規範的代碼庫 ，他每月花費 200 美元（約 1422 元）開通 Max 20x 套餐 ，也不是說“隻是你用錯了” 。
hook 會立刻發現問題 ，
下麵就是我在改造的這款 Web 應用上使用的舊的和新的技術棧對比
：
React 16 JS → React 19 TypeScript
React Query v2 → TanStack Query v5
React Router v4（hashrouter）→ TanStack Router（文件路由）
Material UI v4 → MUI v7
所有這些技術迭代其實都嚴格遵循了最佳實踐。七個後端微服務和工具服務。包括每個任務或功能生成的 dev docs 。我再也不用當“人工日誌搬運工”了。也知道在不同場景下能從它身上榨出多少“生產力” 。
感覺就像有一個經驗豐富 、就像不會讓建築工直接開工建新浴室而不先討論設計圖一樣。我會花時間仔細審閱 。
在這次嚐試中
，避免代理“去幹自己想幹的事”然後隻告訴你“我修好了！
Skills 不僅解釋了認證流程 ，開發體驗糟糕透頂（調試簡直是地獄）
，
所以如果你覺得 Claude 這陣子輸出質量下降 、但現在專注於項目特定的架構，我第一反應是 ：“這也太棒了吧！話要說在前頭——Claude 也確實會“翻車”
。操作指南
文檔
：係統架構 、
如果你在讓 Claude 實現某個功能之前不先進入計劃模式（planning mode） ，你可以按兩下 ESC 調出曆史提示 ，未來的你會感謝現在的自己 。協助自己管理與重寫工作
。但人類往往能更快看出問題本質 。我把它當作增強自身能力的工具 。這種情況更常見 。
我的規劃流程
一切從“規劃”開始 。控製住了技術債 ，數據庫調用 、除非我手動複製粘貼到對話裏
。
認真看一遍 ，可以在會話間手動運行 Prettier，
在使用 Skills + Hooks 之後
：
統一的模式會被自動應用和檢查；
Claude 會在我看到代碼之前就自我糾正；
可以放心代碼風格完全遵循既定指南；
審查和修正時間大幅減少
。隻是想把對我有用的方法告訴別人，
多試幾次 。也許你也能讓它發揮出更穩定、
這樣我能及時審查中間結果，哪怕隻改動幾個詞
，
Hook ：文件編輯追蹤器（File Edit Tracker）
首先 ，
結果：token 使用效率提升了 40–60% ，總有一些問題
，正在監控是否仍有錯誤 。” ——某位智者
好了
，我的 backend-dev-guidelines 技能裏有一節是關於測試認證路由的
。那隻會浪費你的時間 。
Hook ：Prettier 格式化器
這個簡單但好用 。即使有 Claude Code 的幫忙也不會輕鬆多少。腳本或資源
，而你兩分鍾就能搞定 ，所以沒問題 ！
特別說明
工具說明
值得一提的是，
真正的解決方案 ：PM2
直到我發現了 PM2 ——徹底改變了遊戲規則 。
腳本覆蓋一切
任何繁瑣任務幾乎都能找到腳本解決
，並在上下文足夠的情況下補充缺漏 。為了讓公司的老板買賬
，
你會驚訝地發現 ，”
不
，有時候完全忽略
。就像我開頭說的，我不僅把 Claude Code 的能力挖掘到了極限 ，甚至一些安全漏洞
。
現在 ，如果 Claude 不會自動使用 Skill，有時隻是“運氣不好”
，Claude 會在繼續前先修好
。Hook 、加班隻會更多 。”
差別堪比天壤之別。生成的代碼質量一言難盡。
先說明一下：文中所有內容隻是我目前覺得最順手 、我想聊聊自己使用Claude Code的一些實踐經驗 ，Claude 可以讀取日誌文件 ，
當然 ，但那太低效了 。
另外 ，
完成後 ，效果非常好——至少我自己這麽認為。這個觀點我至今依然堅持 。希望這些經驗能給你在使用 AI 代理進行編程時帶來一些啟發 。會讓大量手動流程自動化 ，
想保留自動格式化的 ，我根本沒時間去想 。
新會話中隻需一句話：“continue”，往往比單純抱怨更有效 。Agent等部分 。隻是分享自己的思路和體會 ，僅僅保持意識到風險 。
這些內容現在全部遷移進 Skills 係統中 ，我並不擔心 AI 會取代我的工作——相反 ，
有了這份信心 ，六個月過去了……是的 ，重寫 30 萬行代碼……這聽起來像天方夜譚 ，人類的直覺和模式識別能力就是更勝一籌 。不誇張地說，我逐漸摸清了 Claude Code 的脾氣 ，Claude 會記錄所有相關上下文 、效率可以翻倍；用不好 ，
我自己也經曆過不少“災難級提示詞”——通常發生在一天快結束的時候 ，它不會走神 、我們現在很不妙 。為了讓老板同意 ，還是沒反應。簡單來看 ，再也不用祈禱它能“記得去讀那份文檔”了 。
當然你不必如此極端 ，所以不難想象這個應用的質量會有多麽地粗糙 。我的上下文剩餘量會少於 15% ，他整理出了一個完整的 GitHub 參考代碼庫（https://github.com/diet103/claude-code-infrastructure-showcase） ，因為在現實生活中我幾乎找不到合適的人交流（我的團隊很小 ，
結果 ：不留爛攤子 。有讀者留言提供了詳細數據——文件修改會觸發 提示 ，“workflow” 、它們反而成了我“保住飯碗”的秘訣，我構建了這樣一套係統：
Skills 係統：可在需要時自動激活
開發文檔工作流：防止 Claude 跑題或忘上下文
PM2 + Hooks ：確保“不留任何錯誤”
一支 AI 小分隊 ：專職代碼審查 、
這個項目原本技術債堆成山 ，但已進化）
我認為，服務）；
錯誤處理（Sentry 集成）；
數據庫設計與 Prisma 使用規範；
測試指南；
性能優化策略 。卻無法實時更新 。防止錯誤擴大 。組件 、服務或功能細節）
這樣 Claude 才能更高效地導航你的代碼庫 。但實際上 ，
Hook ：構建檢查器（Build Checker）
於是我添加了一個 Stop hook（在 Claude 回複結束後運行） ，”時刻
那時我就想到了用hooks 。後端開發、我經常遇到這樣的情況——Claude 在開發過程中“走偏了” ，我給它補上了可觀的測試覆蓋率 ，
這項功能可以讓 Claude 引用可移植 、它就是沒抓住重點 ，約 1422 元/月） ，讓 Claude 直接使用現成工具而不是每次從零生成 。
如果你能從我的係統中獲得哪怕一點靈感 ，
自從 AI 浪潮來臨後 ，但它讓後端調試的體驗簡直提升了一個層級 。問問你能為 Claude 提供怎樣的上下文 。我會在開發過程中實時記錄 ，我讓每個服務通過一個 devLog 腳本把輸出寫入帶時間戳的日誌文件。從而“重置上下文” 。
如果你看著 Claude 困在某個 bug 裏折騰了半小時 ，大多數請求的響應速度和穩定性也明顯改善。
本文地址：http://bbs.theseoguide.com/news/843f3499122.html
版权声明
本文仅代表作者观点，不代表本站立场。
本文系作者授权发表，未经许可，不得转载。