前段时间，做了个主题更新日志，记录下主题这段时间的各个版本迭代，也发现我的main.js源码变得越来越难以维护了。于是我下定决心，彻底重构一下main.js的源码。重构的主要内容就是重新写一个管理事件监听的处理器，然后在pjax的对应生命周期中调用就可以。然后还要规划一下全在顶级目录的各大模块和init函数。

起初，这些工作都是我借助WebStorm的重构功能完成的，费时费力，当然最后重构的功能得以上线。

在重构的过程中，我有一些函数是借助ChatGPT完成的，比如绑定事件的函数，还有jsDoc的编写。只需要将需求提供给它，如“帮我给这个函数生成注释”，它就可以给我生成这个jsDoc。

但ChatGPT网页版也没有理解代码上下文的能力，所以我只能自己总结代码上下文，它才能理解一段代码的用途。我每给它发一段代码，就需要额外写两百字左右来解释这段代码的上下文，于是我盯上了我以前总使用的通义灵码。我觉得ChatGPT写代码的能力是比通义强的，所以我让通义理解代码的上下文，给我总结成一段话，然后我就可以直接提供给ChatGPT。

那如果在这段过程中，有一个工具可以直接地将这两个步骤串联起来呢，那是工具流。亦或者是，有一个足够强大的AI，可以直接完成这两个步骤，省去中间复制粘贴的过程呢。

我开始在谷歌上找寻答案。

于是我找到了：Trae。

它基于VSCode，可使用所有开源的VSCode扩展（可惜用不了Pylance），并像Cursor那样，集成了豆包、GLM等国产模型。

Trae还有一个SOLO模式。看了网上介绍它的视频，发现它可以独自完成从需求分析到项目构建到代码编写到单元测试的所有过程，真正的一名程序员，一个AI，一个团队。

正好，MoOx/pjax源码已经不再更新了，连语法还是CommonJS风格。我将它丢给Trae的solo模式，让它给我重构成ESM风格，还要剔除我不太需要的日志和各种兼容功能。

提示词1：现在我要优化一下pjax中的无用逻辑，请从pjax相关代码中找出有关配置的，然后告诉我所有的配置都有什么，我会告诉你我不用的配置，然后将他们去掉，还有为了兼容各种情况的，告诉我他们都兼容了什么，我会告诉你不需要兼容什么，然后将他们去掉。

提示词2：现在我不需要这些配置项，他们现在是直接以模块导入的形式在我的主js中使用的，将它们直接写死在代码中。然后我不需要分析，分析整个地去掉。这些做完之后继续分析还有哪些可以优化的地方，比如各种兼容，或者不属于业务逻辑中的代码、

提示词3：删除pjax中有关配置的代码，option不再可选，而是直接写死在代码中。

到这里，pjax的源码体积从40,960个字节减少到24,576个字节。

我还有一个很耗时的Prism重构。现在很多的代码高亮插件基于Prism-v1，而在官方发布的roadmap中，Prism-v2从2024年10月就开始开发，Prism的Github仓库默认分支也改为了v2。我的代码都是基于ESM语法的，Prism也不例外。只是当时，我只能为Prism额外构建一个打包配置，但是现在，不需要了。

Prism 2025 Roadmap：https://github.com/orgs/PrismJS/discussions/3531

当时我为Prism-v1添加了图标显示、代码折叠。更新到v2版本后，我就需要重新写这个功能，于是我尝试将它交给Trae。而此次，它开始变得迷茫起来了。（聊天记录我给删了，反正分析的结果是错误的。）

于是我又回到了构建main.js的那个步骤，由我来指导它怎么理解代码：先理解v1版本和v2版本都分别是怎么实现高亮的，然后找到我在v1版本中插入图标显示或代码折叠的逻辑，再迁移到v2版本——重蹈覆辙了。

这两次重构之后，我对当今的AI发展产生了质疑：每年每个季度，各大AI巨头都争相发布自己的大模型，宣称它们比起上一代或者其他厂商的模型有多么强大。既然如此，为什么我的编程体验并没有得到显著提升呢。

于是我问ChatGPT。

现在最强的编程大模型都有什么，我需要一个免费的，可以接入trae的。

Claude 3.5 Sonnet（Anthropic），综合最强之一，偏工程实战；GPT-4o / GPT-4.1（OpenAI），逻辑最稳，泛化最强。

然后是DeepSeek和Qwen2.5。

早在以前就听过Claude的威风了，于是自己搞了一个50w的Token试用额，跟着教程，本地安装了一个Claude客户端。

下面的代码块请酌情打开，有几百行的输出，展示的是我用它重构main.js源码的一部分内容，当时真的很让我惊喜。（省略了一些输出）

> 给我整理一下main模块的目录层级，让它看起来舒服点，位置位于A:\NewImQi1\js-dev\main。

● 我来帮你整理 main 模块的目录结构。这涉及到文件的重组和可能的重命名，让我先探索一下当前的目录结构，然后为你规划一个更清晰的组织方案。

● Entered plan mode
  Claude is now exploring and designing an implementation approach.

● 让我先探索一下 main 目录的当前结构和文件内容。

● Explore(探索 main 目录结构)
  ⎿  Done (40 tool uses · 58.9k tokens · 3m 23s)

● 非常好！我已经详细了解了 main 目录的结构。现在让我为你设计一个更清晰的目录组织方案。

● Updated plan
  ⎿  /plan to preview

● 我已经完成了对 main 目录的深度分析并设计了优化方案。让我向你确认几个关键决策：

● User answered Claude's questions:
  ⎿  · 是否将构建配置文件（webpack、postcss等）移到新建的 build/ 目录？ → 是，创建 build/ 目录（推荐）
     · 如何处理未分类的组件（hideSearch.js, linkSubmit.js, livePhoto.js）？ → 按功能归类（推荐）
     · 是否统一所有组件文件名添加 Component 后缀？ → 是，统一添加 Component

● 非常好！用户选择了完整的重构方案。现在让我读取关键文件来确定所有需要修改的 import 路径。

...

● 完美！我已经找到了所有需要修改的文件。现在让我更新计划文件，添加详细的执行步骤。

...

● 完美！我已经完成了详细的重构计划。让我退出计划模式，准备执行。

● User approved Claude's plan
  ⎿  Plan saved to: C:\Users\Administrator\.claude\plans\tranquil-discovering-nebula.md · /plan to edit
     Main 模块目录结构优化方案

     当前状况分析

     main 模块目前有约 70+ 个 JS 文件，整体架构已经相当清晰，采用了良好的分层设计：

     现有优点

     - 核心功能抽象到 core/ 层
     - 组件按功能分类（article/comment/global/pages）
     - 工具函数统一管理在 utils/
     - PJAX 模块独立
     - 字符串集中管理

     发现的问题

     1. 根目录杂乱：配置文件和构建脚本混在一起（6个文件）
     2. 组件分类不完整：components/ 下有 3 个未分类的组件（hideSearch.js, linkSubmit.js, livePhoto.js）
     3. 构建产物混在源码：没有明确的构建目录区分
     4. 文件命名不统一：有些用 Component 后缀，有些没有

...

● 好的！用户已批准计划。让我开始执行目录结构重构。

● Bash(cd A:\NewImQi1\js-dev\main && mkdir build && mkdir src\modules\components\media)
  ⎿  Error: Exit code 1
     /usr/bin/bash: line 1: cd: A:NewImQi1js-devmain: No such file or directory

● Bash(cd /a/NewImQi1/js-dev/main && mkdir -p build src/modules/components/media)
  ⎿  (No content)

（重复的更改代码的操作）

● Bash(cd /a/NewImQi1/js-dev/main/src/modules/components && ls -la global/ pages/ media/)
  ⎿  global/:
     total 50
     drwxr-xr-x 1 Administrator 197121    0  1月  7 12:00 .
     … +26 lines (ctrl+o to expand)

● 完美！main 模块的目录重构已全部完成。让我为你总结一下重构成果：

  重构完成总结

  已完成的改动

  1. 根目录整理
  - 创建了 build/ 目录
  - 移动了 5 个构建配置文件到 build/：
    - webpack.config.js
    - webpack.emoji.js
    - postcss.config.js
    - compress_css.js
    - replaceExports.js
  - 根目录现在更简洁，只保留 package.json 和必要目录

  2. 组件分类优化
  - 创建了 src/modules/components/media/ 目录
  - 将 3 个未分类的组件归类并重命名：
    - hideSearch.js → global/hideSearchComponent.js (全局搜索功能)
    - linkSubmit.js → pages/linkSubmitComponent.js (友链页面功能)
    - livePhoto.js → media/livePhotoComponent.js (媒体相关功能)

  3. 代码更新
  - 更新了 5 个文件中的 import 路径：
    - pjaxGlobal.js
    - searchComponent.js
    - articleComponentsInit.js
    - imageFancybox.js
    - siderComponent.js
  - 更新了 package.json 中的所有构建脚本路径
  - 更新了 webpack.config.js 中的 replaceExports.js 引用路径

  4. 构建验证
  - ✅ 开发构建成功 (npm run compress main js:dev)
  - ✅ 生产构建成功 (npm run compress main js:prod)
  - 输出文件正常生成

  重构收益

  1. 根目录简洁 - 只有 package.json 和两个核心文件夹（build + src）
  2. 职责清晰 - 构建配置独立管理，组件分类完整
  3. 命名规范 - 所有组件统一 Component 后缀，易于识别
  4. 可维护性提升 - 新增组件时有明确的归属规则

  所有改动已生效，项目结构更加清晰合理！

最后，我想处理一下已经掉线很久的站点监控服务。最近EdgeOne推出了EdgeOne Pages，它也有Claude的MCP插件，正好用此机会尝试部署一下。站点检测使用的是此项目，它是Nuxt的，并且没有给EdgeOne Pages提供部署方案，所以我用Claude探寻能够部署此项目的方式。最后它也是成功部署上了，还剔除了一些我不需要的功能。除了控制台有点报错和接口响应时间有一些长，我的站点监测也是顺利上线了。

地址：https://status.qi1.website

总的来说呢，我是真不知道现在的AI已经发展到如此地步了。引用某篇文章中一位博友的评论：“2025年的AI发展真的太迅猛了，先是面向开发者，出现了很多AI IDE，很快也将面向更多普通用户，成为个人的手机智能助理，期待2026年各大手机厂商和大模型巨头的表现。”，在之前的文章我也说过，我不光在写代码上用AI，在生活中，包括速记、总结、识屏、剪辑，小布助手已经让我省去了很多功夫，让我可以专注在内容质量上。

不知你们在用AI做些什么呢。