我给 Gemini 写了一份操作指南让它帮我完成了 Astro 主题的无痛升级 • 0xd00's blog

作为开发者，我们都清楚保持项目依赖更新是多么重要，它几乎是一种“必要的恶”。一方面，新版本带来了新功能、性能优化和安全补丁；另一方面，手动更新的过程却常常枯燥、繁琐，甚至暗藏风险。你需要仔细阅读更新日志，比对文件差异，然后像拆弹专家一样，小心翼翼地修改代码，祈祷不要引入新的问题。

我的个人博客，用的是一款名为 astro-theme-pure 的 Astro 主题。最近，我发现它已经从我使用的 4.0.6 版本迭代了数次。一想到要手动追赶这些更新，我就感到一阵头疼。

但这一次，我决定换个玩法。我不想再自己动手了，我想试试让 AI 来完成这一切。

这篇文章，就是我如何通过向 Google Gemini 发出一个指令，让它扮演我的高级前端工程师，安全、增量地完成整个 Astro 主题升级的完整记录。

编写提示词#

我想让 Gemini 扮演的，不是一个只能聊天的语言模型，而是一个能独立思考、使用工具、并严格遵循流程的“高级前端开发工程师”。要做到这一点，关键在于为它提供一份清晰的岗位说明书和必要的系统权限（函数调用）。

我花了一些时间，精心设计了一份初始指令，并将其保存在项目的 GEMINI.md 文件中。这份文件，就是 Gemini 在这次任务中的行动纲领与行为准则：

你好。现在，你将扮演我的高级前端开发工程师和构建系统专家，专门负责Astro框架。
你的任务是：将我当前项目中使用的 astro-theme-pure 主题，安全、增量地更新到最新的版本。
你的核心目标是： 通过小步、迭代的方式完成更新，确保每一步都能成功构建（npm run build），并在成功后进行一次Git提交，最终在不引入任何错误（尤其是水合错误）的情况下，将主题更新到最新。
你的信息源：
官方更新文档: https://astro-pure.js.org/docs/advanced/update
GitHub 主分支提交记录: https://github.com/cworld1/astro-theme-pure/commits/main/
请严格遵守以下协作流程 (The Workflow):
1.  **分析变更**: 你的第一步是访问并分析上述两个URL，理解从我当前版本（假设是一个较早的版本）到最新版本之间所有的变更。将这些变更在你的脑海里分解成一个个逻辑块（例如：配置文件变更、组件API变更、样式变更等）。
2.  **增量提出方案**: 不要一次性进行所有的修改。你需要根据提交记录的顺序或更新文档的步骤，一次提出一个逻辑上独立的、最小化的变更集。
3.  **提供精确指令**: 对于每一步变更，注意以下原则：
    *   需要修改的文件名。
    *   具体的代码修改，最好使用diff格式（以+和-标示增删）或直接提供修改后的完整代码块。
    *   对这项变更的简要解释（例如：“这是为了适配Astro 4.0的新配置格式”）。
4.  **修改代码，然后运行 npm run build**。
5.  **处理构建结果**: 查看构建结果：
    *   **构建成功**，你需要为这次变更提供一个标准的Git Commit Message（例如 feat(theme): Sync config updates from vX.X），然后继续提出下一个变更集。
    *   **构建失败** 并附上错误日志，你的任务是分析错误日志，并进行调试，进行修复。要特别关注与`client:`指令、UI框架（如React/Svelte）相关的错误，因为它们是水合错误的常见来源。

现在，请开始吧。分析信息源，按照我的要求进行更新。

markdown

这份指令的核心，是将一个模糊的“更新任务”，变成了一个清晰、可执行的算法。我给了它目标、信息源、工具，以及最重要的——一个标准化的工作流程。

低交互，高自动化的工作#

准备就绪。我在配置好指令的 Gemini CLI 中，发出了第一个请求。

我: 我当前的版本是 4.0.6，请帮我更新到最新的版本。

Gemini 领命而去，严格按照我预设的 The Workflow 开始了它的工作。 AI 扮演开发伙伴的工作流示意

第一阶段信息收集

它做的第一件事，是调用内置的 web_fetch 工具，访问我提供的官方更新文档和 GitHub 提交历史。它像一个经验丰富的开发者一样，“阅读”并消化了从 4.0.6 到最新版之间的所有变更日志和代码提交。

第二阶段制定计划

基于分析结果，Gemini 没有鲁莽地一次性应用所有变更。它将整个更新过程拆解成了一系列逻辑独立的微小步骤，在脑海里形成了一份增量更新计划。例如：

先更新 astro.config.ts 中的配置项。
再替换某个已经废弃的组件 API。
然后调整 tailwind.config.ts 的样式配置。
……

第三阶段 “修改-构建-验证”的闭环

接着，好戏上演了。对于计划中的每一步，Gemini 都一丝不苟地执行着一个“修改 -> 构建 -> 验证”的循环，这构成了整个流程的核心。

精准修改 Gemini 会调用 read_file 读取目标文件，然后使用 replace 或 write_file 工具，将新的代码应用进去。它提供的代码变更极其精确，完全复刻了源仓库的修改，避免了任何手动复制粘贴可能引入的错误。
立即构建 代码修改完成后，它会立刻调用 run_shell_command 工具执行 npm run build。这一步是至关重要的“守门人”，确保了每一步微小的改动都不会破坏项目的完整性。
处理结果
- 如果构建成功，Gemini 会向我汇报成功，并草拟一条符合规范的 Git Commit Message 等待我确认。这不仅保证了更新历史的清晰可追溯，也让我对整个过程了如指掌。
- 如果构建失败，它会捕获错误日志，并立刻进入“调试模式”。它会分析错误原因，然后在下一步操作中提出修复方案。

AI 扮演开发伙伴的工作流示意2 AI 扮演开发伙伴的工作流示意

一些思考#

我们正处在一个激动人心的时代。AI 不再仅仅是编辑器里的“自动补全”插件，它正在演变为一个能够理解复杂任务、使用工具、并遵循预定工作流的“智能体”（Agent）。

这次实践让我深刻体会到，将大型语言模型作为开发“协作者”的巨大潜力。它将原本可能需要数小时的人工操作，压缩到了几分钟的机器执行时间；它用机器的精确性，取代了人工操作的易错性。更重要的是，通过一份精心设计的 Prompt，我们可以将团队的最佳实践（如增量更新、构建验证、清晰提交）固化为 AI 的行为准则，从而保证了工程质量。

可以预见，未来更多繁琐、重复的开发任务，像是复杂的代码重构、跨项目依赖管理、甚至根据设计稿自动生成组件代码，都可能被 AI 接管。而我们开发者，则能将宝贵的精力，投入到架构设计、用户体验和业务创新这些更具创造性的工作中去。

当然，目前的流程仍需人的监督与引导，但它无疑为我们打开了一扇通往“人机协作编程”新世界的大门。