用 Gemini 对话生成并编辑 Google Docs

这篇能做出什么

做完这篇教程，你能用一条对话走完下面这条链路：

1. 在 Gemini 里用一段结构化的需求描述，直接生成一份有标题层级、有列表、有结论的文档初稿；

2. 把初稿一键放进 Google Docs（或直接在 Docs 里从对话创建），得到一份可以继续编辑的在线文档；

3. 用「定位 + 动作 + 约束」的改稿指令，让 Gemini 按你的意思改第二版、第三版，而不是整篇重写；

4. 用一段 Apps Script 把从对话里带出来的杂乱格式（多余空行、假标题、行距不一致）批量整理干净；

5. 导出成 .docx 或 PDF 交付，并且清楚知道哪些事 Gemini 不能替你做（改共享权限、留审阅痕迹、处理涉密内容）。

一个具体场景：你手上是一堆零散的会议记录和三条语音转写要点，目标是产出一份 2 页的《项目启动说明》，发给客户。传统做法是新建文档、想结构、写、排版，四十分钟起步；用下面的流程，第一版通常几分钟内就能出来，剩下的时间花在校对和调语气上。

需要强调的是：Gemini 负责的是「把想法变成有结构的文字」，格式规范、权限设置、对外交付这些仍然由你负责。把这条边界记牢，后面所有步骤都会顺很多。

前置条件清单

动手前先确认这些条件，缺哪一条后面都会卡住：

• 一个 Google 账号，并且该账号可以访问 Gemini。Gemini 在 Google Docs 里的写作与侧边面板功能是否开放，取决于你的 Workspace 版本或订阅类型，具体以官方页面的当前说明为准；不同版本能用的功能不一样，不要默认同事能用你也能用。
• 浏览器：Chrome、Edge 或 Firefox 的较新版本，关闭会拦截弹窗的扩展，避免侧边面板加载不出来。
• 素材：文档要回答的问题、目标读者、必须出现的要点（人名、日期、金额、范围）。这些是提示词里真正决定质量的部分。
• 一个专用文件夹：在 Drive 里建一个「Gemini 草稿」文件夹。从对话生成的文档会散落在 Drive 根目录，事后找起来很痛苦。
• 权限认知：只有文件所有者或被授予「编辑者」权限的人，才能更改共享设置。这条听起来基础，但它决定了你能不能把文档发出去。

第一步：先把「交付标准」写清楚

很多人上来就写「帮我写一份项目启动说明」，结果得到的是一篇看似正确、但没法用的通稿。问题不在模型，在于需求没交代清楚。

在 Gemini 的对话框里，先粘一段「文档约定」。这段文字可以存成便签，每次复用：

```text

【文档契约】

• 文档类型：项目启动说明
• 目标读者：客户方项目经理（懂业务，不熟悉我们的内部流程）
• 篇幅：正文 800–1200 字，不超过 2 页 A4
• 结构：一句话结论 → 项目范围 → 双方分工 → 关键时间点 → 待确认事项
• 语气：陈述句为主，不用感叹号，不出现「非常」「极其」
• 格式：一级要点用「## 」开头，二级要点用「### 」开头，步骤用有序列表
• 不确定的信息统一写成「待确认：xxx」，不要自行补全数字和日期
• 输出为一个完整文档，不要分多轮补充

```

三个要点值得单独说：

• 「不确定的写成待确认」这一条价值很大。 它会明显减少编造出来的日期、金额和版本号，你必须自己回填，但至少不会被假数据误导。
• 用 ## / ### 作为标题标记，是为了后面在 Docs 里用脚本批量转成真正的标题样式，比手工点样式快得多。
• 明确字数区间。只写「简短一点」几乎不起作用，写「800–1200 字」才有约束力。

第二步：在 Gemini 对话里生成初稿

把文档约定和素材一起发出去。素材部分建议用无序列表，每条一行，避免写成一整段：

```text

按上面的【文档契约】写文档，素材如下：

• 项目名称：华东区门店巡检系统上线
• 客户方对接人：张经理（业务）、李工（IT）
• 我方角色：系统实施 + 两周现场支持
• 计划启动日期：待确认，客户希望本月内
• 已确认范围：门店巡检表单电子化、异常上报、周报导出
• 明确不在范围：硬件采购、门店网络改造
• 风险：三家试点门店的平板型号不统一

```

发出后，如果 Gemini 支持 Canvas（画布）式的文档编辑区，文档会出现在对话右侧的编辑面板里，你可以直接在面板上让它改某一段。如果当前版本没有画布，就在对话里让它输出完整的 Markdown 文本，下一步手动搬运。

初稿出来后，先别急着改文字，花三十秒检查三件事：结构是否和你要求的五段一致、有没有凭空出现的数字、待确认项是否都标出来了。这三项不对，改词句是浪费。

第三步：把初稿放进 Google Docs

有三条路径，按场景选：

路径 A：直接从对话导出。 在 Gemini 的文档编辑面板里找导出或「在 Google Docs 中打开」一类的入口（不同版本叫法不同，以当前界面为准）。这种方式会新建一个 Docs 文件，作者是你，落在你的 Drive 里。

路径 B：在 Docs 里从对话创建。 打开 docs.new，在侧边面板里描述需求，让 Gemini 生成内容插入正文。适合你已经在 Docs 里、只想要某一段的场景。

路径 C：复制粘贴。 通用性最好。在 Gemini 里复制全文，回到 Docs 用 Ctrl + Shift + V（macOS 是 Cmd + Shift + V）无格式粘贴，再套用样式。这一步的差别很大：普通 Ctrl + V 会把网页字体、颜色、行内样式一起带进来，后面清理很麻烦。

无论走哪条路，第一件事是把文件移动到第一步建好的「Gemini 草稿」文件夹，并改名。默认名字通常是「未命名文档」或提示词的前几个字。

第四步：多轮改稿的指令怎么写

改稿效果差的常见原因，是指令太模糊。「优化一下」「让它更专业」这类要求，模型只能猜。有效的改稿指令包含四个部分：

```text

【改稿指令模板】

• 位置：第 3 节「双方分工」第二段
• 动作：把「我方负责系统部署」拆成三条具体职责
• 约束：每条不超过 25 字，保持原有的人称和时态，不新增承诺
• 范围：只改这一段，其他段落原样保留

```

几个实战例子：

• 「把全文的『我们将』改成『我方将』，只做替换，不改句子结构。」
• 「第 4 节的时间点全部改成表格，两列：阶段、时间。」
• 「给『待确认事项』补一句说明：每一项需要谁在什么时候确认。」
• 「把开头的结论段压到 80 字以内，保留项目名和上线目标，删掉背景描述。」

「只改这一段」这种范围限定非常关键。不加限定，Gemini 常常顺手把整篇重写一遍，你上一轮调整的语气和措辞就白做了，还会引入新的编造内容。

另外一个实用习惯：每改完一轮，在 Docs 里手动留一个版本标记。Docs 的版本历史会自动记录，但在一段密集改稿之后，靠自动历史找回「上一版更好的那段话」并不轻松。

第五步：格式收尾，用脚本批量处理

从对话带出来的文本，通常有这些问题：连续空行、用 ## 当标题但样式还是正文、列表缩进不一致、行距忽大忽小。手工调一份两页文档大概十分钟，文档一多就不划算。

在 Docs 里打开「扩展程序 → Apps Script」，粘贴下面这段脚本，保存后运行：

```javascript

// 清理从对话粘贴进来的杂乱格式：合并空行、统一正文行距

function tidyDoc() {

const doc = DocumentApp.getActiveDocument();

const body = doc.getBody();

// 从后往前遍历，避免删除元素后索引错位

const paras = body.getParagraphs();

for (let i = paras.length - 1; i > 0; i--) {

const cur = paras[i].getText().trim();

const prev = paras[i - 1].getText().trim();

if (cur === '' && prev === '') {

paras[i].removeFromParent();

}

}

// 统一正文段落行距与段间距，标题不动

body.getParagraphs().forEach(function (p) {

if (p.getHeading() === DocumentApp.ParagraphHeading.NORMAL) {

p.setLineSpacing(1.5);

p.setSpacingBefore(6);

p.setSpacingAfter(6);

}

});

}

```

再把 ## 前缀批量转成真正的标题样式：

```javascript

// 把文本前缀 "## "、"### " 转成 Docs 的二级、三级标题

function applyHeadingByPrefix() {

const doc = DocumentApp.getActiveDocument();

const body = doc.getBody();

const rules = [

{ prefix: '### ', heading: DocumentApp.ParagraphHeading.HEADING3 },

{ prefix: '## ', heading: DocumentApp.ParagraphHeading.HEADING2 }

];

body.getParagraphs().forEach(function (p) {

const text = p.getText();

rules.forEach(function (r) {

// 先匹配长前缀再匹配短前缀，避免 "### " 被 "## " 误判

if (text.indexOf(r.prefix) === 0) {

p.setHeading(r.heading);

p.editAsText().deleteText(0, r.prefix.length - 1);

}

});

});

}

```

运行前记住两点：第一次先在一份副本上试；脚本作用在当前打开的文档上，选错文件会改错东西。

如果文档里没有前缀、纯粹是一堆短行需要变成标题，脚本就帮不上了，老老实实用样式刷，或者选中那行按 Ctrl + Alt + 1/2/3 套用标题。

第六步：导出与交付

导出之前在 Docs 里过一遍这份清单：

• 「文件 → 下载」选 Microsoft Word (.docx) 还是 PDF，取决于对方是「要改」还是「要看」。要对方回改就给 docx，只给客户存档就 PDF。
• PDF 导出前检查分页：标题是否孤零零留在页尾、表格是否被切断。Docs 的「文件 → 打印预览」比下载更快。
• 表格列宽、图片位置在 docx 和 PDF 之间可能微调，交付前用导出的那份文件自己再看一眼。
• 文件名统一成「项目名_文档名_日期」格式，例如 巡检系统_启动说明_20250312.docx。

第七步：权限与协作，哪些事 Gemini 不替你做

这一节是很多人踩坑的地方，逐条说明：

• 共享设置必须你自己改。 Gemini 不会把文档分享给任何人。导出或生成后，点右上角「共享」，决定是「受限」（只有被点名的人能进）还是「知道链接的任何人」。
• 侧边面板只能读你有权限的文件。 你让 Gemini 参考某个 Drive 文件，它看到的内容范围不会超过你自己的访问权限。反过来，别在个人账号的 Gemini 里粘贴公司内部文档，个人账号与企业账号的数据处理策略不同。
• 生成的内容以普通正文插入，没有「作者」标记。 协作者看到的就是一段正常文字，不会显示「这段是 AI 写的」。需要留痕，用「文件 → 版本历史」看时间线，或者用「建议模式」让改动以建议形式出现，人工逐条接受。
• 评论与建议需要人处理。 Gemini 不会替你回复评论、解决建议。
• 协作者能不能用同样的功能，取决于他们自己的许可。 你分享出去的文档，对方没有相应订阅时，侧边面板里的写作功能可能是灰的，但正文照样能看能改。
• 引用要人工核。 让 Gemini 补一段依据时，它给出的来源可能不准确。对外交付的文档里出现的每个数字和引用，自己核一遍来源。

常见坑与排错

下一步建议

• 把「文档约定」沉淀成模板库。 周报、需求说明、复盘各存一份，每次只换素材那一段，输出质量会稳定很多。
• 结构先行。 与其让 Gemini 一次写全文再大改，不如先让它只输出三级大纲，你确认结构后，再让它逐节展开。大改的成本远高于微调。
• 把「待确认」当成流程的一部分。 文档里所有「待确认：xxx」都进你的待办清单，交付前清零。这一步决定文档是「像样」还是「可用」。
• 重复性整理交给脚本。 上面两段 Apps Script 可以合并成一个函数、绑定到菜单，之后每份从对话来的文档先跑一遍再人工看。
• 需要批量生成时看 Docs API。 如果你要按同一模板生成几十份文档，Apps Script 配合 Drive 的格式转换能力已经够用；规模再大就去看 Google Docs API 的官方文档，版本与配额以官方页面为准。

最后留一句提醒：这套流程省的是「从零到有结构的第一版」的时间，省不了「核对事实、拿捏对外语气、管好谁能看」的责任。把这几件人工环节固定成习惯，对话式写作才真正可靠。