好好的井底空间

最近 agent skills 这个名词很火啊，怎么能不掺和一下呢？ 从日常开发工作中挑选了一个非常流程化的场景——根据后端提供的 swagger 文档，在前端项目中写入所需接口及数据类型——进行试验。 简易的 Skills 本质上就是放在 .claude/commands/ 目录下的 Markdown 文件。文件名就是命令名，文件内容就是提示词。这次选中的场景比较简单，提示词自然也不复杂，借助 AI 用了半个小时就写好并测试通过了。大概包含了如下几块内容： 1. 核心流程： ① 用户输入：定义用户需要提供的内容，包含环境和所需接口 url； ② 数据获取：提示 AI 通过 curl 命令获取对应环境下的 swagger 文档； ③ 信息提取：给出示例脚本，告知 AI 需要获取的字段信息，例如后端定义的接口方法名称、HTTP 方法、请求参数、响应类型等； ④ 命名规则：强制 AI 使用提取到的字段信息组成方法名、类型名，确保前后端命名一致； ⑤ 类型转换：针对特殊字段进行特别的处理，例如 id 字段往往被后端声明为 Long 类型，而后在 VO 类的字段级别借助 @JsonSerialize 注解进行转换，以字符串的格式传给前端，故而需要特别定义来覆盖 swagger 文档中读取到的类型； ⑥ 冲突处理：例如出现重复命名时，必须中断并询问客户； 2. 代码生成位置： ① 接口方法代码存放位置； ② 接口类型代码存放位置； 3. 代码模板：给出几个典型案例； 4. 用户额外需求占位符 - $ARGUMENTS。 流程跑通后，选择了一个接口（总计需增加 32 行代码）进行耗时测试： 1. AI 生成代码： ① 编写 prompt：只包含 skill 命令 + 环境名 + 接口名，用时几乎可以忽略不计； ② AI 思考并编写代码：2 分 43 秒，期间多次申请操作权限，使用者需要持续在场响应； ③ 人工检查生成的代码：49 秒。 2. 人工开发代码：2 分 36 秒。当然，这其中是有 Copilot code completion 的功劳的。即使禁用了 AI，我也习惯借助  typeof-jsonc 等插件帮助写入类型字段，总体耗时差距不会太大。 以我目前对 AI 的理解，它能够大幅提效的主要场景还是集中在： 1. 自己不熟悉的领域...

亲爱的朋友，你有遇到过这样的场景吗？ 1. 希望严格遵循 React 哲学、维护单向数据流，于是状态提升提升再提升，提升到最后发现这个状态值似乎和当下组件没什么逻辑关联，只是它凑巧了，是共用这个状态值的那两个远房孙组件最近的共同父组件； 2. 写出一版提测了，产品经理指着页面说，“还是把这个统计数据移到上面那块展示吧，排版更好看一点，不难吧？”于是吭哧吭哧重写了组件树中所有被牵涉到的组件的 props，加班加点荣获了「效率低下」的美名，代码也被评价为「扩展性太差」； 3. 眼看着层层的 prop drilling 太反人类了，想想干脆祭出 useContext 吧，可转念又觉得大材小用、加剧耦合、倍感不值，只能背地里吐槽产品的设计毫无章法、后端的接口乱组数据，硬着头皮做他们的粘合剂； 4. 下定决心不能再被 best practice 捆绑了，放飞自我，就是天王老子来了也得是在直接使用到数据的组件里调用获取数据的接口，但是后端赶在天王老子之前来了，“你这一个页面里怎么能同时调用两次接口呢？会不会写前端啊？知不知道服务器压力有多大啊？” 前端已死，都去报名学习 AI 吧……呃，不是🚫 经人指点，在项目中封装了一个 Hook -- useSharedRequest，顾名思义，就是方便在多个组件间共享接口请求，但共享的不是接口返回的数据，而是这个请求的 promise。该 Hook 基于 ahooks 库的 useRequest 封装而来，写法完全一致，只需要在配置项中增加一个 shareKey 作为请求的唯一标识，就可以实现： 1. 在直接使用到数据的组件里调用获取数据的接口，保证组件逻辑内敛； 2. 同一页面多个组件调用相同接口时，只发送一次真实的网络请求，减轻后端压力； 3. 改造和维护成本极低，不管是接口替换还是组件层级变化，都不会牵扯到大面积修改。 基础用法如下图所示： 详细来讲， 1. 定义一个请求共享管理器类 RequestShareManager。 2. 在 RequestShareManager 中声明一个 Map<shareKey, Promise> 类型的私有属性 pendingRequests，用于存储正在进行中的请求。 3. 在 RequestShareManager 中实现...

目标安装机器是储能柜的 EMS 触控一体机，核心需求是：低内存、少空间、高性能。于是选定了 Tauri 框架进行构建。 大致步骤如下： 1. 安装 Rust 及配套工具链（下载速度慢的话可以考虑换国内镜像） 2. 安装 Visual Studio Build Tools（在 Rust 编译时要用到） 3. 安装 tauri-app 依赖 4. 执行 tauri init 命令进行配置初始化 5. 执行 tauri dev 命令启动开发模式 6. 执行 tauri build 命令生成桌面应用安装包 最后，安装包 3.7M，应用程序 7.1M，运行时内存占用 3.6M，基本满足需求😏 除了前两步卡住了一下，其它流程整体上还是 love and peace，但我有种不详的预感：我只在自己 Windows 系统的电脑上跑通了，但是据说真实的安装环境是 Linux 的😥可能后期跨平台构建和样式兼容的工作量要远大于现在吧？

话不多说，直接上效果图： 从 0 创建到 1 还是很容易的，从 1 优化到 100 就很耗时了。动画的流畅度，交互的灵敏度，边缘情况的特殊处理，每一步都是个坎儿啊！很遗憾 resize 的部分纠缠了很久也没有处理好，但其余的效果都达到了我的目标值。技能点 + 1 ~~~

  偷得浮生半日闲，画了一个思维导图，把一些 AI 相关的热门概念理一理。当然了，AI 的知识浩如烟海，我了解到的也只是沧海一粟，权当一个简陋的备忘录吧！

 这周还算清闲，做了一个【接口使用情况】的查询工具，主要是应对后端和测试总时不时来问“这个接口前端用到了吗”“那个接口在哪里调用的啊”……忙到飞起的时候真的会顾不过来😒 页面很简单，列表页主要负责基础查询，可以了解指定接口是否有被前端调用，以及是在哪些系统里被调用的；详情弹窗则负责更进一步的查询，可以详细看到使用该接口的菜单，方便用户前往核查。 后端是用 node 搭建的，对接代码仓库的 API，实时读取前端各项目的源码文件，进而借助正则匹配和 AST 解析来提取接口信息，并查找使用接口的文件，根据文件路径匹配到菜单信息，返回给前端。 实现这个工具主要的难点在于源代码的精准解析，前置的工作很多，几个系统有关接口调用的部分我几乎都重构了一遍，就是为了保证代码格式尽可能的统一；还有的系统因为各种历史原因，存在大量的未使用但也未移除的代码，导致我不得不又写了几个脚本文件，检测未被引用的接口、类型和常量，删除干净以后整个人都神清气爽了。即便如此，解析源代码也需要额外兼容很多的情况，比如微信小程序和 web 项目工程结构的差异、动态路由的拼接、不同后端服务的分辨，以及花了好大力气才排查出来并发读取源文件时可能有丢包的情况（我一直当是自己解析文件的代码哪里写错了😓😓） 总之，这个工具已经运转起来了，满足了同事们简单场景下的查询需求，稍微复杂点的场景肯定还是远远不够用的啦！静待同事的随时召唤🙇