用 AI 命令维护自研工具：系统化独立开发第 4 部

用 AI 命令维护自研工具：系统化独立开发第 4 部 | 前端进阶之旅

Full translation

完整中文译文

本文最初发布于 e-shikumi-labo。

你好，我是 e-Shikumi-Labo 的 Shin。

这是《系统化思维》系列的最终篇（第 4 部分）。在这个系列中，我们使用 AI 构建自己的工具，并独立完成后续维护。

到目前为止，我们已经讨论了如何制作一个自动保存 Gemini 聊天记录的原型、如何将记录转换为 Markdown 并集成到 Obsidian，以及如何将它完善为一个安全的全自动系统。

在最后一篇中，我们将讨论一个在运营 Web 数据处理工具时无法避免的问题——“因页面规格变更而导致工具停摆的应对措施”，以及 AI 时代人类应当具备的“自立能力”究竟是什么。

开发过程中，我曾经想过：“我还想把每条聊天消息发送时的准确日期和时间（timestamp）记录下来。”

然而，无论我怎样分析 Gemini 的页面结构，每条消息的准确 timestamp 都不存在于 HTML 中。

Web 数据提取有一条基本原则：“浏览器页面上不存在的数据，就无法提取。”

只要你不是通过 API，而是从页面（DOM）中提取数据，那么强行获取原本不存在的信息，就需要引入复杂的推测处理，反而会成为问题的根源。

理解这种“技术边界”，对无法实现的功能果断放弃，并作出保持系统简洁的判断，也是构建工具时非常重要的一环。

只要你的工具需要从他人的网站提取数据，就必然会遇到这样的时刻：由于 Google 一方修改设计或进行更新，工具会在某一天突然停止工作。

“明明昨天还运行正常，今天却突然无法保存了。”

这并不是工具本身的缺陷，而是依赖他人平台时无法逃避的“宿命”。

重要的并不是追求一个“绝对不会坏的完美工具”，而是接受工具终究会坏这一前提，掌握“坏了以后应该修改哪里、怎样修改”，并建立一种自己能够快速恢复运行的状态。

在这次制作的 “Chat Saver for Gemini” 中，从页面读取数据的处理（DOM parsing）被拆分到了一个名为 parser.js 的独立文件中。

像这样，将通信处理（content.js）和解析处理（parser.js）分离后，即使 Gemini 的页面设计发生变化，也只需要修改 parser.js 中指定的位置，例如 CSS selectors。

如果工具因页面变更而停止工作，人类需要执行的任务如下：

使用 DevTools（Inspect Tool）检查新元素。在 Chrome 中打开 Gemini，按 F12 键（或者右键单击并选择 “Inspect”），检查并复制 prompt 区域和 response 区域的新 HTML 结构。

请求 AI 修复。你不需要亲自直接重写代码。将复制下来的最新 HTML elements 和当前使用的 parser.js 一并交给 AI，并要求它进行修正。

“由于 Gemini UI 更新，parser.js 已经无法正常工作。我附上了当前的 parser.js 代码，以及 prompt 区域和 response 区域的最新 HTML elements。请根据这些信息修改 selector 相关部分。”

即使你自己无法读懂代码，只要把发生变化的部分（输入信息）提供给 AI，它就能在几秒钟内生成修正后的代码。

贯穿这四个部分，我真正想传达的并不只是如何构建一个工具。

第 1 部分：即使你没有完全理解代码语法，只要将任务交给 AI，也能构建工具。

第 2 部分：根据自身的业务问题（例如可读性问题），扩展现有机制。

第 3 部分：识别 AI 生成代码中的风险（例如账号被封禁），并及时拉紧缰绳、加以控制。

第 4 部分：以工具终究会坏为前提设计系统结构，并使用 AI 自行维护。

你不需要背诵 JavaScript 语法，也不需要记住详细的编码方法。

人类真正需要理解的，是整个系统结构的地图——“输入（从页面提取）” → “处理（过滤重复内容）” → “输出（发送到 GAS）”——以及对数据提取来源保持审慎思考的视角。

只要这张结构地图存在于你的脑海中，你就能察觉 AI 生成的危险代码，并命令它修正；即使页面发生变化，也能给出准确指令，继续安全地掌控工具。

从被工具支配的一方，转变为指挥 AI、运营系统的一方。

希望大家也能学会与 AI 正确相处的方式，获得一种“自立能力”：构建并维护真正适合自己的安全系统。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。