从Git提交到社交媒体：自动化技术分享的CLI工具设计与实现

1. 项目概述：从代码提交到社交媒体的自动化桥梁

最近在折腾一个挺有意思的小工具，起因是发现很多开发者（包括我自己）在社交媒体上分享技术进展时，常常会陷入一种“重复劳动”的尴尬。我们花时间写了代码、提交了有意义的提交信息（Commit Message），但到了要发推文或者技术社区帖子时，却得重新组织语言，把技术细节“翻译”成更通俗、更吸引人的故事。这个过程不仅耗时，还常常因为拖延而错过分享的最佳时机。于是，我动手做了一个命令行工具（CLI），它能自动读取你的 Git 提交历史，分析提交内容，然后生成可以直接发布或稍作修改就能用的社交媒体帖子草稿。

这个工具的核心价值在于“自动化”和“语境转换”。它不是一个简单的文本提取器，而是一个理解开发者工作流的助手。想象一下，你刚完成一个功能模块的优化，提交了一条信息量丰富的 Commit，比如feat(auth): implement JWT refresh token mechanism with configurable expiry。这条信息对开发者很清晰，但对更广泛的受众可能过于技术化。这个 CLI 工具能帮你把它转换成：“刚刚为身份验证系统加上了‘自动续期’的令牌机制，用户长时间使用应用再也不会被突然踢出登录了，并且管理员可以灵活配置令牌的有效期。#后端开发 #Web安全 #用户体验优化”。这样一来，技术成果的分享变得毫不费力。

它非常适合独立开发者、技术布道者、开源项目维护者以及任何希望更高效地建立技术个人品牌的程序员。你不需要离开终端，不需要打开额外的社交媒体管理工具，在完成编码工作的瞬间，就能顺手把工作成果“推销”出去。接下来，我会详细拆解这个工具的设计思路、实现的关键技术点、如何配置使用，以及我在开发过程中踩过的那些坑和总结出的实用技巧。

2. 核心设计思路与方案选型

2.1 为什么选择 CLI 而非 GUI 或 Web 应用？

首先得聊聊为什么做成命令行工具。核心原因有三个：场景贴合、效率至上和易于集成。

场景贴合：我们的操作对象是 Git 仓库和提交历史。开发者最熟悉、最常与之交互的环境就是终端。在终端里git log查看提交，紧接着运行我们的工具生成帖子，这是一个极其自然、上下文连贯的工作流。如果做成 GUI，你需要在文件管理器里找到项目，或者从 IDE 中启动另一个应用，流程就被打断了。

效率至上：CLI 可以通过管道（Pipe）和重定向与其他命令无缝协作。例如，你可以结合git log --oneline -5只获取最近5条提交的概要，然后通过管道传给我们的工具进行处理。这种组合的灵活性是 GUI 难以比拟的。同时，CLI 启动速度快，几乎没有界面渲染开销，对于这种轻量级、高频次的操作任务再合适不过。

易于集成：CLI 可以轻松地被集成到自动化脚本、CI/CD 流水线甚至 Git Hook（如post-commit）中。想象一下，每次提交后自动生成一条帖子草稿并保存到指定文件，或者每周日晚上自动汇总一周的重要提交生成周报推文，这都是 CLI 的天然优势。

2.2 核心功能模块拆解

这个工具虽然概念简单，但内部需要几个协同工作的模块：

1. Git 仓库交互模块：负责与本地 Git 仓库通信，执行git log等命令，获取原始提交数据。这里的关键是可配置性。用户需要能指定查看哪个分支（如main,develop）、查看多少条提交（--since,-n）、以及提交信息的格式（--pretty=format:...）。

2. 提交信息解析与增强模块：这是工具的“大脑”。原始的提交信息可能符合 Conventional Commits 规范，也可能是随意的描述。这个模块需要：

   • 分类：识别提交类型是feat（新功能）、fix（修复）、docs（文档）、refactor（重构）还是其他。
   • 提取关键信息：从主题行和正文中提取出修改的组件/范围（scope）、描述、以及可选的关联 Issue 编号（如#123）。
   • 语义增强：这是生成吸引人帖子的关键。例如，识别到fix和memory leak，可以关联到“性能提升”、“系统稳定性”；识别到feat和dark mode，可以关联到“用户体验”、“个性化”。

3. 内容生成与模板引擎模块：根据解析后的结构化数据，填充到预设的模板中，生成最终的自然语言帖子。模板需要支持变量插值（如{{commit_type}},{{description}},{{issue_ref}}）和简单的逻辑控制（如 if-else 判断不同的提交类型使用不同的措辞）。模板的风格应该可配置，以适应 Twitter（简洁）、LinkedIn（专业）、Mastodon 或技术论坛等不同平台的口吻。

4. 输出与发布集成模块：处理生成内容的去向。最简单的就是输出到终端（stdout）或文件。更高级的集成可以调用社交媒体平台的 API（如 Twitter API v2, LinkedIn API）进行草稿保存或直接发布（需谨慎，建议默认只生成草稿）。这一步必须把安全放在首位，妥善处理 OAuth 令牌等敏感信息。

2.3 技术栈选型考量

我选择了 Node.js 和其丰富的生态系统来实现，具体包的选择经过了仔细权衡：

• 核心语言：Node.js。它天生适合构建 CLI 工具，npm或yarn使得分发和安装极其简单（npm install -g commit-to-post）。其非阻塞 I/O 对文件系统和网络操作（如果集成 API）也很友好。
• 命令行框架：Commander.js。它是 Node.js 生态中最成熟、最流行的 CLI 框架。它帮我们处理参数解析（--since,--format）、生成帮助文档、子命令等繁琐工作，让我们能专注于业务逻辑。
• Git 操作：simple-git。一个优秀的 Promise-based 的 Git 包装库。相比直接执行child_process调用git命令，它提供了更安全、更易用的 API，能更好地处理错误和不同操作系统下的路径问题。
• 模板引擎：Handlebars。它轻量、逻辑清晰，语法简单（{{variable}}，{{#if condition}}），非常适合我们的内容生成场景。用户也可以自定义.hbs模板文件来完全控制输出格式。
• 配置管理：cosmiconfig。它支持从多种来源（package.json的属性、RC 文件、.config.js文件等）读取配置，非常灵活。用户可以在项目根目录放一个.commit-to-postrc.json文件来保存自己的默认模板、API 密钥（加密后）等设置。

这个选型平衡了开发效率、社区支持和工具的专业性，确保了工具既健壮又易于维护和扩展。

3. 核心细节解析与实操要点

3.1 提交信息的结构化解析策略

提交信息是原料，解析的深度直接决定了生成内容的质量。我们假设开发者或多或少遵循一些约定，但工具也必须足够健壮以处理自由格式的提交。

策略一：优先匹配 Conventional Commits 规范这是目前很多团队采用的标准，格式为：<type>(<scope>): <description>。我们的解析器会首先尝试匹配这个模式。

• type：直接映射为提交类型。我们内置一个映射表，将feat映射为“新功能”，fix映射为“问题修复”，perf映射为“性能提升”等，用于后续的语义增强。
• scope：指明了修改的影响范围，如auth,ui,api。这能让我们生成的帖子更具体，例如“改进了身份验证模块的...”。
• description：这是核心描述。我们会进行简单的 NLP 处理（关键词提取），识别技术栈（如React,Docker）、动作（如implement,optimize,remove）和对象（如login page,database query）。

策略二：回退到启发式分析如果提交信息不符合规范，我们就进行启发式分析：

1. 分词与停用词过滤：将描述拆分成单词，过滤掉a,the,and等无实义的词。
2. 关键词匹配：对照一个预定义的技术关键词库（如bug,error,feature,update,refactor,security）进行匹配，推断提交类型。
3. 寻找 Issue 引用：匹配类似#123,Closes #45这样的模式，将其提取为关联事项。

注意：解析永远不可能 100% 准确。因此，工具生成的帖子必须是草稿。我们的目标是提供一个高质量的、节省 80% 工作量的起点，而不是一个完全无需人工干预的“黑盒”。在输出时，明确提示用户“请检查并修改以下生成的草稿”是负责任的体现。

3.2 内容模板的设计哲学与技巧

模板是工具的灵魂，它决定了输出的“文风”。我设计了几套默认模板，并允许用户完全自定义。

1. 简洁公告型（适合 Twitter/X）

刚刚{{action}}了{{component}}！{{#if issueRef}} (解决了 {{issueRef}}){{/if}} #{{projectName}} #编程 {{#if techStack}}#{{techStack}}{{/if}}

• action：根据提交类型动态填入“发布”、“修复”、“优化”、“重构”。
• component：从scope或描述中提取的核心组件名。
• 特点：短小精悍，带话题标签，信息密度高。

2. 技术分享型（适合 LinkedIn、技术博客）

[{{type_cn}}] {{description_original}} 本次提交主要涉及 {{component}}。{{enhanced_context}} {{#if issueRef}}关联事项：{{issueRef}}{{/if}} 查看代码变更：{{commit_url}} (如果与仓库平台集成)

• type_cn：提交类型的中文翻译（如“功能新增”、“缺陷修复”）。
• enhanced_context：这是“魔法”所在。通过一个简单的规则引擎添加上下文。例如，如果提交类型是fix且描述中包含crash，则enhanced_context可以是“此举显著提升了应用的稳定性，避免了用户在使用过程中意外退出的糟糕体验。”
• 特点：更详细、更专业，适合深度分享。

3. 叙事故事型（适合项目日志、社区更新）

🚀 项目进展更新：我们刚刚迈出了一小步！ 为了{{goal}}，我/我们团队对 {{component}} 进行了调整，具体工作是「{{description_original}}」。 这虽然看起来是个技术细节，但它意味着用户将来能体验到{{user_benefit}}。开发不易，但每一步都算数！ #开源 #项目日志 #{{projectName}}

• goal：从描述中推断或由用户配置的更高层次目标（如“提升加载速度”、“增强安全性”）。
• user_benefit：将技术改动翻译成用户能感知的好处（如“更快的页面响应”、“更安心的数据保护”）。
• 特点：富有情感，强调价值和过程，容易引发共鸣。

实操心得：不要试图用一个模板适应所有平台。最好的做法是让工具支持多模板同时输出。例如，运行命令后，在终端并排显示为 Twitter、LinkedIn 和 Mastodon 生成的三个版本草稿，让用户根据情景选择或组合使用。

3.3 安全与隐私的底线设计

任何处理本地代码和可能涉及发布功能的工具，都必须把安全放在首位。

1. 本地优先：核心设计原则是所有数据处理均在用户本地完成。提交信息只从本地.git文件夹读取，内容生成完全在本地运行。除非用户明确配置并授权，否则工具不应将任何数据发送到外部服务器。

2. API 密钥管理：如果用户希望集成自动发布到 Twitter/LinkedIn，需要使用 OAuth 2.0。工具绝不能硬编码或要求用户明文传递密码。正确的做法是：

   • 引导用户到相应平台创建开发者应用，获取CLIENT_ID和CLIENT_SECRET。
   • 工具实现一个auth子命令，启动一个本地临时服务器，引导用户完成 OAuth 授权流程，获取并安全地存储access_token和refresh_token。
   • 将这些令牌加密后存储在用户系统级的密钥管理器中（如 macOS 的 Keychain、Linux 的 Secret Service、Windows 的 Credential Manager），而不是普通的配置文件里。可以使用keytar这样的库来实现跨平台的密钥安全存储。

3. 敏感信息过滤：在解析提交信息时，需要加入一个简单的过滤器，防止意外泄露敏感信息。例如，匹配类似密码、密钥、内部 IP 地址的模式（正则表达式），并在生成草稿时用[REDACTED]替换或直接发出警告。虽然 Git 历史中本就不该有这些信息，但多加一层防护总是好的。

重要提示：在工具的文档和每次涉及发布的交互中，必须强烈建议用户先生成草稿，手动审核后再发布。自动发布功能应作为一个需要显式开启的高级选项，并配有确认提示。

4. 完整实现流程与核心代码剖析

4.1 项目初始化与基础架构搭建

首先，创建一个新的 npm 项目，并安装核心依赖。

mkdir git-commit-to-post && cd git-commit-to-post npm init -y npm install commander simple-git handlebars cosmiconfig chalk figlet npm install --save-dev @types/node typescript ts-node jest

• chalk用于在终端输出彩色信息，提升可读性。
• figlet可选，用于生成一个酷炫的 ASCII 艺术 logo，在--version或启动时显示，增加工具的专业感。

接着，规划项目目录结构：

git-commit-to-post/ ├── src/ │ ├── cli.ts # 命令行入口，使用 Commander 定义命令和参数 │ ├── git-helper.ts # 封装 simple-git，提供获取提交历史的函数 │ ├── parser.ts # 提交信息解析器，实现前述的两种解析策略 │ ├── template-engine.ts # 处理模板加载、变量替换和渲染 │ ├── config.ts # 使用 cosmiconfig 管理用户配置 │ └── publishers/ # （可选）发布集成的抽象层和具体实现 │ ├── index.ts │ ├── twitter.ts │ └── linkedin.ts ├── templates/ # 默认的 Handlebars 模板文件 │ ├── twitter.hbs │ ├── linkedin.hbs │ └── narrative.hbs ├── dist/ # TypeScript 编译后的输出目录 └── package.json

在package.json中，定义bin字段来声明我们的 CLI 命令名，例如commit2post。

{ "name": "commit-to-post", "version": "1.0.0", "description": "Turn your git commits into social media posts.", "bin": { "commit2post": "./dist/cli.js" }, // ... 其他配置 }

4.2 核心逻辑实现：从 Git 提交到文本草稿

让我们深入src/cli.ts，看看主命令generate的实现骨架：

import { Command } from 'commander'; import { getGitLog } from './git-helper'; import { parseCommitMessage } from './parser'; import { renderTemplate } from './template-engine'; import { loadConfig } from './config'; import chalk from 'chalk'; const program = new Command(); program .name('commit2post') .description('Transform your git commits into ready-to-share social media posts.') .version('1.0.0'); program .command('generate') .description('Generate post drafts from recent commits.') .option('-n, --number <count>', 'Number of commits to process (default: 1)', '1') .option('-b, --branch <branch-name>', 'Specify the branch to check (default: current)', '') .option('-t, --template <template-name>', 'Template to use (twitter, linkedin, narrative)', 'twitter') .option('-o, --output <file-path>', 'Save output to a file instead of console') .action(async (options) => { try { console.log(chalk.blue('🚀 Fetching your recent commits...')); // 1. 加载用户配置 const userConfig = await loadConfig(); // 2. 获取 Git 提交历史 const commits = await getGitLog(options.branch, parseInt(options.number)); if (commits.length === 0) { console.log(chalk.yellow('⚠️ No commits found in the specified range.')); return; } // 3. 处理每一条提交 for (const commit of commits) { console.log(chalk.gray(`\n--- Processing: ${commit.hash.slice(0, 7)} ---`)); // 4. 解析提交信息 const parsedData = parseCommitMessage(commit.message, commit.body); // 5. 合并解析数据与额外上下文（如项目名、commit url） const templateData = { ...parsedData, projectName: userConfig.projectName || 'MyProject', commitHash: commit.hash, commitUrl: `${userConfig.repoUrl}/commit/${commit.hash}`, // 假设配置了仓库URL author: commit.author_name, date: commit.date, }; // 6. 使用模板引擎渲染 const renderedPost = await renderTemplate(options.template, templateData, userConfig); // 7. 输出结果 console.log(chalk.green.bold('\n✨ Generated Draft:')); console.log(chalk.cyan('---')); console.log(renderedPost); console.log(chalk.cyan('---\n')); console.log(chalk.gray('(Please review and edit before posting!)')); // 8. 如果指定了输出文件，则追加写入 if (options.output) { // ... 文件写入逻辑 } } } catch (error) { console.error(chalk.red('❌ Error:'), error.message); process.exit(1); } }); program.parse(process.argv);

关键点解析：

• 错误处理：整个逻辑包裹在try-catch中，确保任何一步出错（如不在 Git 仓库、网络问题等）都能给用户友好的错误提示，而不是崩溃。
• 用户反馈：大量使用chalk进行彩色输出，清晰地展示流程状态（获取中、处理中、完成）、成功和警告信息，提升交互体验。
• 数据流：清晰的管道式数据处理：Git Log -> Parse -> Enrich -> Render -> Output。

4.3 解析器 (parser.ts) 的深度实现

parseCommitMessage函数是工具智能的核心。以下是其简化但关键的实现逻辑：

// 类型定义 interface ParsedCommit { type: string; // 'feat', 'fix', 'docs', etc. type_cn: string; // 中文类型 scope?: string; description_original: string; description_clean: string; component?: string; action: string; // 映射的动作，如“发布了”、“修复了” enhanced_context?: string; issueRef?: string[]; } // 类型映射表 const TYPE_MAP: Record<string, { cn: string; action: string; context: string }> = { feat: { cn: '功能新增', action: '发布了', context: '这是一个令人兴奋的新功能！' }, fix: { cn: '缺陷修复', action: '修复了', context: '此举提升了系统的稳定性和可靠性。' }, perf: { cn: '性能优化', action: '优化了', context: '用户体验将因此变得更加流畅。' }, refactor: { cn: '代码重构', action: '重构了', context: '代码结构更清晰，为未来开发铺平道路。' }, docs: { cn: '文档更新', action: '更新了', context: '良好的文档是项目成功的关键。' }, }; function parseCommitMessage(rawMessage: string, rawBody?: string): ParsedCommit { const conventionalCommitRegex = /^(\w+)(?:\(([^)]+)\))?:\s*(.+)$/; const match = rawMessage.match(conventionalCommitRegex); let type = 'chore'; let scope: string | undefined; let description = rawMessage; // 策略一：匹配 Conventional Commits if (match) { [, type, scope, description] = match; type = type.toLowerCase(); } else { // 策略二：启发式分析 const lowerMsg = rawMessage.toLowerCase(); if (lowerMsg.includes('fix') || lowerMsg.includes('bug') || lowerMsg.includes('error')) { type = 'fix'; } else if (lowerMsg.includes('feat') || lowerMsg.includes('add') || lowerMsg.includes('new')) { type = 'feat'; } // ... 其他类型的推断 } // 提取 Issue 引用 const issueRefs: string[] = []; const issueRegex = /(?:closes|fixes|resolves)?\s*#(\d+)/gi; const combinedText = `${rawMessage} ${rawBody || ''}`; let issueMatch; while ((issueMatch = issueRegex.exec(combinedText)) !== null) { issueRefs.push(`#${issueMatch[1]}`); } // 提取核心组件（从 scope 或描述中） let component = scope; if (!component) { // 一个简单的启发：描述中第一个名词短语或特定的技术词 const componentKeywords = ['api', 'auth', 'ui', 'database', 'config', 'server', 'client']; for (const keyword of componentKeywords) { if (description.toLowerCase().includes(keyword)) { component = keyword.toUpperCase(); break; } } } // 获取类型映射信息 const typeInfo = TYPE_MAP[type] || { cn: '其他更新', action: '更新了', context: '' }; // 构建增强上下文（一个非常简单的规则引擎） let enhanced_context = typeInfo.context; const lowerDesc = description.toLowerCase(); if (type === 'fix' && (lowerDesc.includes('crash') || lowerDesc.includes('memory'))) { enhanced_context = '此修复解决了可能导致应用不稳定的关键问题，提升了整体健壮性。'; } else if (type === 'feat' && lowerDesc.includes('dark mode')) { enhanced_context = '深色模式不仅保护视力，也为用户提供了个性化的视觉体验选择。'; } return { type, type_cn: typeInfo.cn, scope, description_original: description, description_clean: description.replace(issueRegex, '').trim(), // 清理掉 issue 引用 component, action: typeInfo.action, enhanced_context, issueRef: issueRefs.length > 0 ? issueRefs : undefined, }; }

这个解析器虽然基础，但已经能处理大部分常见情况，并为生成有意义的帖子提供了足够的结构化数据。

4.4 模板引擎与配置系统的集成

template-engine.ts负责加载和渲染模板。它首先查找用户自定义的模板（通过cosmiconfig加载的配置路径），如果找不到，则回退到工具自带的默认模板。

import Handlebars from 'handlebars'; import fs from 'fs/promises'; import path from 'path'; import { loadConfig } from './config'; // 注册一个简单的 Handlebars 助手，用于条件判断 Handlebars.registerHelper('if', function (conditional, options) { if (conditional) { return options.fn(this); } else { return options.inverse(this); } }); export async function renderTemplate( templateName: string, data: Record<string, any>, userConfig: any ): Promise<string> { let templateContent: string; // 1. 优先从用户配置的模板目录查找 const userTemplatePath = path.join(userConfig.templateDir || '', `${templateName}.hbs`); try { templateContent = await fs.readFile(userTemplatePath, 'utf-8'); console.log(chalk.gray(`Using custom template: ${userTemplatePath}`)); } catch { // 2. 回退到内置模板 const builtInTemplatePath = path.join(__dirname, '../templates', `${templateName}.hbs`); try { templateContent = await fs.readFile(builtInTemplatePath, 'utf-8'); } catch { throw new Error(`Template "${templateName}" not found in built-in templates.`); } } // 3. 编译并渲染 const template = Handlebars.compile(templateContent); return template({ ...data, config: userConfig }); // 将用户配置也传入模板，以便使用 }

用户可以通过在项目根目录创建.commit-to-postrc.json来覆盖默认行为：

{ "projectName": "AwesomeOSS", "repoUrl": "https://github.com/yourname/awesome-oss", "templateDir": "./my-custom-templates", "defaultTemplate": "narrative" }

5. 常见问题、排查技巧与进阶用法

5.1 安装与初次使用避坑指南

问题1：全局安装后命令未找到 (command not found: commit2post)

• 原因：Node.js 的全局bin目录可能不在你的系统PATH环境变量中。
• 排查：
  1. 运行npm list -g --depth=0确认包已安装。
  2. 运行npm config get prefix查看 npm 的全局安装路径（例如/usr/local）。
  3. 检查该路径下的bin文件夹（如/usr/local/bin）是否在你的PATH中。可以通过echo $PATH（Linux/macOS）或echo %PATH%（Windows）查看。
• 解决：
  • Linux/macOS：将export PATH="$(npm config get prefix)/bin:$PATH"添加到你的 shell 配置文件（如~/.bashrc,~/.zshrc）中，然后执行source ~/.zshrc。
  • Windows：在系统环境变量PATH中添加 npm 的全局路径（如C:\Users\YourName\AppData\Roaming\npm）。
  • 临时方案：使用npx commit-to-post generate直接运行。

问题2：工具报错 “Not a git repository”

• 原因：你当前所在的目录不是一个 Git 仓库的根目录。
• 解决：确保在包含.git文件夹的项目根目录下运行命令。可以使用cd切换到你的项目目录。

问题3：生成的帖子内容空洞或不准

• 原因：你的提交信息过于简单（如update，fix bug），导致解析器无法提取有效信息。
• 解决：
  1. 治本：养成写规范、描述性提交信息的习惯。参考 Conventional Commits 规范。好的提交信息本身就是一份微型文档。
  2. 治标：使用工具的--template选项尝试不同的模板。narrative（叙事型）模板对简单提交的“包装”能力更强。或者，在运行命令前，使用git commit --amend修改最近一次提交的信息，为其添加更多上下文。

5.2 内容生成效果优化技巧

技巧1：为你的项目定制关键词映射工具内置的组件和上下文增强关键词是通用的。你可以在项目配置文件中扩展它们，让生成的内容更贴切。 在.commit-to-postrc.json中添加：

{ "componentKeywords": ["auth", "dashboard", "paymentGateway", "dataPipeline"], "contextRules": [ { "if": {"type": "feat", "descriptionContains": ["dashboard", "chart"]}, "then": "这次更新让数据可视化能力上了一个新台阶，决策支持更直观了。" }, { "if": {"type": "perf", "scope": "database"}, "then": "数据库查询的优化往往是提升应用响应速度最有效的一环。" } ] }

你需要稍微修改parser.ts来读取并使用这些自定义规则。

技巧2：批量处理与周报生成不要只局限于最近一次提交。利用-n参数处理多条提交，并结合 shell 脚本生成周报。

# 生成过去一周的所有功能(feat)和修复(fix)提交的汇总帖子 commit2post generate --since="1 week ago" --template=narrative | head -c 280 > weekly_update.md

你可以创建一个脚本generate_weekly.sh，里面包含更复杂的git log过滤逻辑（如git log --oneline --since="last Monday" --grep="^feat\|^fix"），然后管道传递给工具。

技巧3：与 Git Hook 集成，实现提交即提醒在.git/hooks/post-commit文件中添加以下内容（记得chmod +x .git/hooks/post-commit）：

#!/bin/bash # 只处理 main 或 master 分支的提交 BRANCH=$(git symbolic-ref --short HEAD) if [[ "$BRANCH" == "main" || "$BRANCH" == "master" ]]; then /usr/local/bin/commit2post generate -n 1 -t narrative --output=.git/LAST_COMMIT_POST.txt 2>/dev/null if [ -f ".git/LAST_COMMIT_POST.txt" ]; then echo "" echo "📝 已为本次提交生成分享草稿：" cat .git/LAST_COMMIT_POST.txt echo "" fi fi

这样，每次向主分支提交后，终端会自动显示生成的帖子草稿，提醒你可以去分享了。

5.3 处理复杂场景与边界情况

场景1：合并提交（Merge Commit）合并提交的信息通常是Merge branch 'feature/x'，这对生成帖子没有价值。

• 处理策略：在git-helper.ts中，获取日志时使用--no-merges选项来过滤掉合并提交。

  const log = await git.log({ [branchOption]: branch, n: count, '--no-merges': null });

场景2：多行提交正文（Body）规范的提交正文包含更详细的描述和动机，是极好的素材。

• 处理策略：在解析时，将rawBody传入。在模板中，可以通过{{body}}变量来引用。但要注意，正文可能很长，需要模板设计者决定是截断、摘要还是选择性使用。一个技巧是提取正文的第一段（到第一个空行前）作为摘要。

场景3：希望生成双语帖子有些开发者希望同时用中英文分享。

• 进阶实现：可以设计一个特殊的bilingual模板，或者运行两次工具，分别指定英文和中文模板。更优雅的方式是在解析器中就生成双语的结构化数据（如description_en,description_cn），然后由一个复合模板来渲染。这需要对解析器进行更深入的改造，可能需要集成翻译 API（谨慎考虑，会增加复杂度）。

开发这个工具的过程，让我再次体会到“磨刀不误砍柴工”的道理。一个好的 CLI 工具，其价值不仅在于它实现的功能，更在于它如何无缝地嵌入并优化现有的工作流。这个commit2post工具目前已经是我日常开发中不可或缺的一环，它把“分享”这个额外的动作，从一项需要鼓起勇气的任务，变成了一个水到渠成的习惯。如果你也在构建类似提升效率的工具，我的建议是：从解决自己最痛的一个点开始，设计时多想一步“用户可能怎么用”，实现时把错误处理和配置灵活性放在前面，这样创造出来的东西，自己才会愿意一直用下去。