Claude把寫文檔藏成斜杠命令，開發者發現后集體破防

一個產品經理出身的開發者，用3個斜杠命令把技術博客的產出時間從4小時壓到15分鐘。這不是工具的勝利，是對"文檔必須痛苦"這個行業默認假設的打臉。

Jeremy Longshore（以下簡稱Longshore）在維護兩個Hugo博客站點時發現，它們運行正常，但更新頻率低得可憐。排查后他意識到：問題不在技術棧，在人——寫文檔的摩擦成本太高，高到足以讓有價值的洞察爛在本地倉庫里。

從"寫完代碼再寫文檔"到"代碼即文檔原料"

傳統工作流把開發和文檔切成兩段。Longshore的觀察是：工作本身包含了文檔所需的全部信息，缺的是提取和結構化。他設計的系統把發布簡化為運行一條命令，核心洞察用他自己的話說：「解決問題的對話過程比最終方案更有教學價值。」

技術實現上，他在~/.claude/commands/目錄下創建了自定義命令文件。但初期遇到了典型的工具鏈適配問題——Claude Code沒有識別這些命令。系統化排查后發現兩個關鍵點：文件命名格式必須嚴格匹配，且需要顯式聲明命令模式。

早期版本只分析git提交記錄，丟失了工作會話中的問題解決上下文。Longshore迭代后的方案捕獲三類信息：git歷史、項目文件結構、開發過程中的實際交互記錄。這讓他能重建"當時怎么想的"而非僅呈現"最后怎么做的"。

兩條命令，兩種敘事策略

他最終構建了兩套獨立的命令系統。

技術博客命令（/blog-startaitools）面向開發者同行，輸出包含：項目上下文分析、技術實現細節、架構決策理由、代碼片段與配置、部署流程。Portfolio博客命令（/blog-jeremylongshore）面向潛在雇主/客戶，側重：問題陳述、解決方案概述、技能展示、成果量化、專業反思。

同一批工作產物，通過不同的提取邏輯生成不同的敘事。Longshore的總結很直接：「技術讀者想要實現細節，Portfolio讀者想看解題能力。」

兩條命令都覆蓋完整工作流：內容生成、Hugo構建、git提交、觸發部署。自動化處理機械部分，但保留人工審核環節——降低摩擦，但不消滅判斷。

今天這套系統產出了什么

Longshore用剛搭建的系統文檔化當天的工作，順便完成了倉庫清理：重構了~/.claude/commands/目錄結構，更新了README文檔，清理了冗余的測試命令文件，為兩個博客站點建立了標準化發布流程。

文檔從"開發完成后單獨做的任務"變成了"開發流程的內置環節"。他在項目筆記里寫：「自動化的投入，每次運行命令都在產生復利。」

這套框架的擴展性超出博客場景。任何具有清晰結構的重復工作流——代碼審查模板、發布檢查清單、客戶溝通紀要——都可以被類似地自動化。Longshore提到FAQ快速回復和代碼片段復用作為潛在方向。

一個值得注意的細節：他在命令設計中刻意保留了"審核后發布"的斷點。完全的自動化不是目標，讓人愿意開始寫才是。這個平衡抓得很準——太多自動化讓人失去控制感，太少又讓人干脆放棄。

Longshore的項目目前處于個人工具階段，但方法論本身具有普適性。把隱性工作流顯性化，再將其壓縮為可復用的命令，這個思路對任何知識工作者都適用。

你最近一次因為"寫文檔太麻煩"而放棄分享的洞察，是什么？