一個產(chǎn)品經(jīng)理出身的開發(fā)者，用3個斜杠命令把技術(shù)博客的產(chǎn)出時間從4小時壓到15分鐘。這不是工具的勝利，是對"文檔必須痛苦"這個行業(yè)默認(rèn)假設(shè)的打臉。

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

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

傳統(tǒng)工作流把開發(fā)和文檔切成兩段。Longshore的觀察是：工作本身包含了文檔所需的全部信息，缺的是提取和結(jié)構(gòu)化。他設(shè)計的系統(tǒng)把發(fā)布簡化為運行一條命令，核心洞察用他自己的話說：「解決問題的對話過程比最終方案更有教學(xué)價值?！?/p>

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

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

兩條命令，兩種敘事策略

他最終構(gòu)建了兩套獨立的命令系統(tǒng)。

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

同一批工作產(chǎn)物，通過不同的提取邏輯生成不同的敘事。Longshore的總結(jié)很直接：「技術(shù)讀者想要實現(xiàn)細(xì)節(jié)，Portfolio讀者想看解題能力?！?/p>

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

今天這套系統(tǒng)產(chǎn)出了什么

Longshore用剛搭建的系統(tǒng)文檔化當(dāng)天的工作，順便完成了倉庫清理：重構(gòu)了~/.claude/commands/目錄結(jié)構(gòu)，更新了README文檔，清理了冗余的測試命令文件，為兩個博客站點建立了標(biāo)準(zhǔn)化發(fā)布流程。

文檔從"開發(fā)完成后單獨做的任務(wù)"變成了"開發(fā)流程的內(nèi)置環(huán)節(jié)"。他在項目筆記里寫：「自動化的投入，每次運行命令都在產(chǎn)生復(fù)利?！?/p>

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

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

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

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