Git 文档看不完?用 WorkBuddy 做一份能照着操作的新手手册

第一次学 Git，真正劝退人的往往不是命令，而是文档。

git init、git status、git add、git commit、git log，每个命令都有自己的说明页。对熟悉 Git 的人来说，这很完整；对第一次操作的人来说，却很难马上回答一个简单问题：

我现在到底该先做什么，看到什么才算正常，什么时候应该停下来检查？

这一次，我用 Git 官方文档做材料，让 WorkBuddy 只完成一件事：

把分散的命令说明整理成一份可以照着操作的中文 Word 新手手册。

公开给读者的路径仍然只有四步：

第 1 步｜放入材料

把要用的官方文档事实整理到同一个任务里。

第 2 步｜输入一段中文任务

写清读者是谁、只完成什么、哪些内容不要扩展。

第 3 步｜得到一个 Word

最终只让使用者接收一份能打开、能照做的操作手册。

第 4 步｜人工抽查

核对命令范围、占位符、可变输出和停止检查点。

我拿什么做实测

本期选择的是一个很小、但能完整验收的任务：

在 macOS 的独立练习目录中建立本地 Git 仓库，创建 README，完成第一次本地提交，再用状态和历史命令确认结果。

我把 7 个 Git 官方页面中的必要事实整理成 4 份材料：

• Git 官方教程^[1]与首次设置^[2]：版本检查和提交身份；
• git init 官方文档^[3]：怎样建立本地仓库；
• git status^[4]与git add^[5]：怎样识别未跟踪文件并加入暂存区；
• git commit^[6]与git log^[7]：怎样产生第一条提交并查看历史。

这些材料能支持命令事实和基本顺序，但不能替读者判断某个真实项目是否适合纳入 Git，也不能证明任何内容已经上传到其他平台。

所以这期刻意不讲远程仓库、团队协作、分支合并，只把第一次本地提交走通。

直接交给 WorkBuddy 的中文任务

如果你也要把官方文档整理成新手手册，可以保留下面这段任务的结构，再替换材料、目标读者和最终结果。

可直接复制｜官方文档转新手操作手册

请读取本任务附带的官方材料，为“已经安装 Git、第一次用命令行记录本地文件的人”生成一份中文 Word 新手操作手册，只交付这一个 Word，不生成其他附件。

手册只解决一个任务：在 macOS 的独立练习目录中建立本地 Git 仓库，创建 README，完成第一次本地提交，并用状态和历史命令确认结果。不要扩展到远程仓库、分支协作、合并或上传。

文档依次包含：能完成什么和不能完成什么、开始前检查、五步主流程、每一步的执行命令与预期结果、异常时先检查什么、最终验收、三个常见错误和一页人工确认清单。

命令必须完整、可复制。不要编造固定提交标识、固定终端路径或所有电脑都相同的完整输出。示例姓名和邮箱只写占位符，并提醒读者替换为自己的信息。

每一步都提供一个停止检查点。遇到报错时先查看当前状态，不让读者盲目重试或执行破坏性操作。

Word 生成后停止，不发布、不发送、不上传云端，也不替读者判断真实项目。

这段任务最重要的不是章节数量，而是先把三件事说死：

只服务一个新手目标，只交付一个 Word，每一步都允许人停下来确认。

图 1｜本机实测：官方材料和完整中文任务放在同一个独立任务中。

我用 WorkBuddy 实际跑了一遍

2026 年 8 月 10 日，我在本机 WorkBuddy v5.3.11 中执行了这项中文任务。WorkBuddy 生成了一份 新手操作手册.docx，内置预览可以直接查看目录、步骤、命令、常见错误和人工确认清单。

任务完成后停在人工确认点，没有发布、发送或上传云端。

图 2｜读者最终只需要接收一个 Word，不需要管理一批中间文件。

新手手册最重要的，不是解释更多

官方文档常按命令组织，新手操作却按目标推进。

因此，这份 Word 没有从 Git 的全部概念讲起，而是把任务压成五步：

1. 建立独立练习目录和 README；
2. 初始化本地仓库；
3. 只为当前练习仓库设置姓名和邮箱；
4. 只把 README 加入暂存区；
5. 完成第一次本地提交。

每一步只回答三个问题：

• 要复制哪条命令；
• 正常情况下会看到什么；
• 如果不同，应该先检查什么。

这比把所有背景知识塞进第一页更有用。新手不需要一次理解全部 Git，只需要知道当前动作是否安全、结果是否符合预期。

图 3｜每一步都有执行命令、预期结果和停止检查点。

示例输出不能写得像固定答案

新手手册里有一类内容特别容易误导：终端输出。

同一条命令，在不同系统、Git 版本、语言环境和目录中，可能出现不同措辞。提交标识也会按实际内容生成，不可能提前固定。

所以手册里要把三层内容分开：

• 官方事实：某条命令做什么；
• 流程编排：本期为什么把它放在这一步；
• 本机结果：读者实际运行后看到的路径、版本、状态和提交标识。

WorkBuddy 可以先把“应该核对什么”整理出来，但最终判断必须以读者自己的终端输出为准。

每一步都要有停止检查点

很多教程只给成功路径：复制命令、继续下一步、完成。

对新手更有帮助的是明确写出“什么时候不要继续”。例如：

• 当前目录不是专门的练习目录，先停；
• README 没有出现，先停；
• 准备提交的内容不止一个明确文件，先停；
• 姓名邮箱仍是示例占位符，先停；
• 提交出现报错，先查看当前状态。

停止检查点不是多余步骤。它能把“出错后随便试命令”改成“先确认当前位置和真实状态”。

最后一定要由人抽查什么

Word 生成后，我重点检查了五件事：

• 命令是否来自本期材料支持的范围；
• 示例身份是否只是占位符；
• 可变输出是否被误写成固定答案；
• 每一步是否有明确停止条件；
• 最终验收是否同时查看当前状态和本地历史。

人工确认清单的作用，是让读者在关闭终端前逐项打勾，而不是让 AI 替他宣布“已经完成”。

图 4｜常见错误先回到当前状态核对，最后由人逐项确认。

这类任务最值得复用的三个习惯

先缩小任务，再整理文档。

“学习 Git”太大，“完成第一次本地提交并验收”才是可以写成操作手册的具体任务。

把动作、预期和异常放在一起。

读者不需要来回翻页猜下一步，每一步都应该形成一个完整的小闭环。

最终只给使用者一个 Word。

来源核验和生产记录可以留在内部，公开给读者的使用路径保持简单：材料、一段中文任务、一个 Word、人工抽查。

WorkBuddy 官方文档说明，它可以接收自然语言任务、使用本地材料，并在结果区查看生成的文档；本期实测使用的就是这条路径：产品简介^[8]、任务对话^[9]、结果查看^[10]。

以后再遇到一组很长的官方文档，不要先让 AI “总结一下”。

先告诉 WorkBuddy：谁要用、只完成什么、按什么顺序、看到什么要停、最后交付什么。

这样得到的才不是一份看完仍然不会操作的摘要，而是一份真的能放在手边照着做的新手手册。

引用链接