博文

AI 辅助编程有感

-
我想写这个内容很久了，但是迟迟不知道该站在何种立场上来写。是凸显自己如何精于 AI 结对编程，提升了 XXX 的效率，创造了 XXX 的价值？是嘲笑现在的 AI 大跃进，批判资本家穷途末路不得不 AI 造神，终将被海量的技术债务反噬？还是假装理性，说一些模棱两可、似是而非的废话，来确保无论 AI 未来是陷入瓶颈还是再次爆发潜能，我的文字都能自圆其说？非常纠结，而且心态实时随着 AI 的产出内容而摇摆不定——它出乎意料的智能，我就开始疯狂地焦虑，觉得程序员的末日要来了；它出乎意料的愚蠢，我就暗自得意，AI 总归还是个辅助工具嘛~ 想来想去，我就只写史实吧，只当是记录一下自己的 AI 编程经历和心得。现在这个年代，不用 AI 生成和润色的长篇文字，已经可以算得上珍贵的记录了。 2022 年 12 月，我第一次听到 ChatGPT，试用了一下觉得很愚蠢。12 月 9 号的下午，我还发了朋友圈嘲笑它的回答，“一本正经的胡说八道，难怪被 Stack Overflow 给禁了”。 2023 年初，Copilot 横空出世，那时候还是完全免费的。尝鲜可以，但真正在项目开发里用起来只能说优劣参半吧！思考的速度有时候会比人慢，在人开始敲代码的时候又突然给出提示，反而形成干扰。夏天的时候知道它要开始收费了，就卸载掉了。 2024 年 4 月，对国产的模型及编程工具实在失望，正式成为 Copilot 的付费用户，时至今日，它依然是我心目中最好用的代码助手。还是很怀念那段时光的，AI 就静静的辅助我编程，不会喧宾夺主（agent 模式在我看来有点吵闹了），也没有那些“使用 AI 就一定要提高多少多少效率”的外界压力。 2025 年 2 月，DeepSeek 的深度思考能力震撼到了我。2 月 5 号那天，我和我老公的聊天记录里充满了对 DeepSeek 的崇拜和对 ChatGPT 的鄙视，哈哈。 2025 年 6 月，Grok 进入我的视野，这是第一个让我和 AI 聊天聊上瘾的模型。它的能力中规中矩，但是免费且速度快，所以性价比在我这里排名第一，我也多次和同事好友推荐。它同时也是第一个让我用提示词来创建定时任务的模型，虽然效果一般，但是在当时看来，这个能力还是挺有趣的。 等到了 2025 年年底的时候，画风就开始渐渐转变了。此前，AI 一直是我的好帮手，可以帮我省去无聊的工作，可以帮...
发表评论
阅读全文

小记

-
我始终苦恼于【UI 设计稿 → 前端样式代码】这一步无法 AI 化，图像识别不精准、语言描述很匮乏。直到今天我突然顿悟了，设计稿可以转成 .html 文件啊！真不错，感觉离自己被 AI 完全替换掉又近了一步呢😂
发表评论
阅读全文

部署 OpenClaw + 飞书协同

-
图片
  一、目标： 1. 公司内部 Windows 服务器上部署 OpenClaw 2. 集成任意模型，免费的最好 3. 对接飞书机器人 二、用时： 整整一天😪 三、成果： 四、归纳流程： 1. 前期准备：服务器上的可用工具少到令人发指，中途不得不多次暂停以解决如下这些问题。 ① 配置代理：OpenClaw 有依赖需要从 GitHub 上拉代码，所以必须要配置代理，不然无论是 install.cmd 还是 npm 的方式，都会失败。 ② 安装 node 和 git：重要性无需多言。 ③ 配置 WSL 内存：服务器上的 docker 运行在 WSL 环境里，之前分配的内存太少了（半个月前，服务器故障，频繁自动关机，当时以为是 docker 太耗内存了，所以修改了配置，结果后来发现是硬件故障，可是这个配置就没有再改回来），运行不了本地大模型。 2. docker 安装 ollama docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama 3. 拉个免费的通义千问模型 docker exec -it ollama ollama run qwen3.5:2b 4. npm 安装 OpenClaw npm install -g openclaw@latest 5. 配置 OpenClaw： ① provider 那一步选择 vLLM，实测 Qwen provider 验证可能失败，通过 vLLM 以 OpenAI 兼容模式调用阿里云 API 更稳定； ② 如果选择基于 ollama 的模型，base url 写  http://localhost:11434/v1 ，api key 随便填； ③ 因为免费模型速度实在太慢了，我后面又增加配置了 qwen-plus 模型，base url 写  https://dashscope.aliyuncs.com/compatible-mode/v1 ； ④ 我原本还想接 claude 模型来着，中转平台实在不给力，屡次验证失败，最终只能遗憾放弃。 6. 协同飞书： ① 创建飞书机器人：进入 飞书开放平台 ，创建企业自建应用 → 添加机器人 → 配...
发表评论
阅读全文

iPhone 科学上网

-
图片
换了新手机以后最苦恼的就是如何重新下载 Shadowrocket，风控越来越严格，折腾废了 3 个账号，终于在农历的大年初一，我又可以看见外面的花花世界了哈哈哈😉 1. Mac 上注册新的 Apple 账户：使用全新的手机号和邮箱，地区选择美国。这一步成功率非常高，几乎没有失败过；不放心的话，可以开美国节点的代理，Mac 里的地区也设置成美国，Chrome 设置语言为英文。 2. iPhone 上登录该账户： ① 重置 App Store：这一步卡了我好久啊😭每次一切换账号，美区就变成国区，快被逼疯了。具体方法就是在 Safari 中打开链接（itms-apps://itunes.apple.com/WebObjects/MZStore.woa/wa/resetAndRedirect?dsf=143441&cc=us），自动跳转至 App Store，完成重置和重定向。 ② 登录账号：没什么好说的，简单确认下还在美区就可以了。 3. 下载 Shadowrocket： ① 购买 App Store 礼品卡：我尝试过无数次按照常规流程绑定 PayPal，最终都宣告失败了，后面还是决定采取更稳妥的充值礼品卡的方式。选用的是 Pockyt Shop（https://shop.pockyt.io/pc/home），充值了 $3，获取到礼品卡号后转至 App Store 中进行兑换。 ② 下载软件：点击“获取”，会弹窗提示填写账单地址，我是找了一个【美国随机地址生成器】，这一步也没什么难度。 4. 胜利✌
发表评论
阅读全文

Claude Code Skills 实践

-
最近 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. 自己不熟悉的领域...
发表评论
阅读全文

从 prop drilling 的泥潭到请求共享的天堂

-
图片
亲爱的朋友，你有遇到过这样的场景吗？ 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 中实现...
发表评论
阅读全文

Web 应用 ---> 桌面应用

-
图片
目标安装机器是储能柜的 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 的😥可能后期跨平台构建和样式兼容的工作量要远大于现在吧？
发表评论
阅读全文