一个产品经理出身的开发者，用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的项目目前处于个人工具阶段，但方法论本身具有普适性。把隐性工作流显性化，再将其压缩为可复用的命令，这个思路对任何知识工作者都适用。
你最近一次因为"写文档太麻烦"而放弃分享的洞察，是什么？
热门跟贴