w2solo - 独立开发者社区

我让 AI 替我写 Git 提交信息，老板以为我每天工作 16 小时

193577746 — Sun, 17 May 2026 12:36:40 +0800

公司要求提交信息必须规范：feat: xxx、fix: xxx、还要带 tapd 链接。我每次 git commit 都要憋五分钟，写出来的还是 “改了点东西”。后来我让 AI 替我写提交信息——diff 一丢进去，它自动生成规范格式，还帮我加上 “影响范围” 和 “为什么改”。老板看 Git 日志，说：“xxx 最近提交质量很高啊，你每天工作到几点？” 我：“正常六点下班。”

前言

Git 提交信息这件事，说大不大，说小不小。小到你随便写个 “update”，不影响跑代码。大到代码回滚、发版生成 CHANGELOG、甚至背锅溯源时，一句清晰的 “fix: 修复订单金额计算溢出” 比 “改了一下” 值一万倍。

但人都有惰性，尤其加班赶业务时，谁有空写小作文？AI 就不一样，它看 diff 快、理解上下文、还能按约定格式输出。今天我就教你用 AI 自动生成高质量的 commit message，顺便集成到 Git 钩子里，让你以后闭着眼敲 git commit 就行。

一、为什么你讨厌写 commit message？

没灵感：改了好几个文件，不知怎么概括。
规范记不住：feat/fix/docs 又要查表。
懒：反正也没人看，写个 “x” 交差。

但规范化的 message 真的有用：

自动生成 CHANGELOG.md。
git blame 时一眼看出某个改动的原因。
同事 review PR 时不用猜你改了啥。

既然人是懒的，就让 AI 当你的 “秘书”。

二、AI 怎么写 commit message？

核心思路：git diff --staged 拿到本次变更的代码差异，丢给 AI，让它根据 Conventional Commits 规范生成消息。

我给你写了一个脚本 ai-commit（Python 版，你也可以用 Node）：

#!/usr/bin/env python3
import subprocess
import sys
from openai import OpenAI

client = OpenAI(api_key="你的key")

# 获取暂存区的 diff
diff = subprocess.check_output(["git", "diff", "--staged"]).decode("utf-8")
if not diff.strip():
    print("没有暂存的变更，请先 git add")
    sys.exit(1)

prompt = f"""
请根据以下 Git diff，按照 Conventional Commits 规范生成一条提交信息。
格式：<type>(<scope>): <subject>
其中 type 可选：feat, fix, docs, style, refactor, perf, test, chore
scope 可选（如组件名或模块名），subject 简短描述（不超过50字）。
如果变更涉及多个不相关改动，请拆成多条（用换行分隔）。
只输出提交信息，不要解释。

diff:
{diff[:8000]}
"""

response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
)

message = response.choices[0].message.content.strip()
print(message)

把这个脚本保存为 ai-commit，放到 PATH 里。以后你只需要：

git add .
ai-commit   # 它会打印出 AI 生成的 message
git commit -F <(ai-commit)   # 直接使用

或者再懒一点：用 git commit -m "$(ai-commit)" 一行命令。

三、集成到 Husky，每次 commit 自动调用

你可以在 .husky/prepare-commit-msg 里加入脚本，让 AI 自动填充编辑器：

#!/bin/sh
# 自动生成 commit message 并预填到编辑器
exec < /dev/tty
AI_MSG=$(ai-commit)
echo "$AI_MSG" > "$1"

这样你敲 git commit 时，编辑框里已经有 AI 写好的草稿，你只需要检查一下，不满意就改，省得自己从头敲。

四、真实案例：AI 写的 message 有多专业？

某次我改了订单模块的一个 bug：之前只判断了 user.discount 存在性，没判断类型，传了个字符串导致计算错误。AI 根据 diff 生成了：

fix(order): 优惠金额类型错误导致计算异常

- 增加 discount 字段的类型校验，确保为 number
- 添加单元测试覆盖字符串场景

还帮我分了一行 body 说明？其实 Conventional Commits 允许 body，但我的提示词没要求。厉害的是，它居然知道这是 “类型错误” 和 “计算异常”，而且自动给定了 fix(order)。

另一个案例：我重构了一个函数，把 if-else 改成了策略模式。AI 生成：

refactor(payment): 用策略模式替换多层条件分支

提升可扩展性，便于新增支付渠道

这一看就是老手写的。

五、进阶：结合 TAPD/Jira，自动关联任务

很多公司要求 commit 里带任务 ID。你可以在提示词里加入当前分支名（分支名通常含任务号）：

branch = subprocess.check_output(["git", "branch", "--show-current"]).decode().strip()
# 假设分支名为 feature/TAPD-1234

然后把 “请从分支名提取任务 ID，加入提交信息” 写进 prompt。AI 会生成类似：

feat(order): 添加满减优惠券

TAPD-1234

连 hook 都不用改，全自动。

六、局限性：AI 不是每次都完美

巨大 diff：超过上下文长度，AI 看不到全貌。可以只改最近几个文件，或者用 git diff --cached --stat 先给 AI 看概览，再让它选择重点文件。
多个无关改动：AI 可能会合并成一条，而你应该拆成多条。这时候手动分两次 commit 就好。
隐私：代码 diff 会发给 OpenAI API，公司敏感项目慎用。可以本地跑开源模型（CodeLlama、DeepSeek Coder）替代。

七、效果：我的 Git 日志变 “教科书”

之前我的日志：

fix
update
修改

现在：

feat(user): 支持手机号登录
fix(cart): 修复商品数量为0时仍可结算的bug
perf(list): 虚拟滚动优化，长列表滚动帧率提升50%
docs(readme): 更新环境配置说明

老板进仓库看了一圈，专门在群里说：“xxx 的提交信息写得真规范，大家学习一下。” 我默默把 AI 脚本分享给了同事。现在全组都在用，老板还纳闷：怎么大家突然都变 “专业” 了？

八、总结：把时间花在改 bug 上，不是写小作文

AI 写 commit message，省时、规范、专业。
集成到 Git 钩子，无感使用。
支持从 diff 推断 type、scope、甚至业务含义。
敏感项目换本地模型。

下一回你 git commit 时，让 AI 替你写。你只需要 review 一下，不满意手动改两字。从此 Git 日志不再是 “xxx: 111”，而是真正的 “项目史书”。

评论区聊聊：你见过最离谱的 commit message 是什么？

+86 用户专属：一个不用折腾代理、不用交 smsfee 的 TG 登录方案

huo — Sun, 17 May 2026 10:08:26 +0800

最近想上 TG 跟进几个技术频道，结果第一步就被卡住了——注册/登录。

+86 手机号，官方客户端登录时弹出一个叫"smsfee"的提示，按指引交了费用，短信验证码却像石沉大海。试了三四次，换了不同时间段，依旧收不到。搜了下社区讨论，发现这不是个案，运营商层面的拦截让不少人在这条路上折返。

正当准备放弃时，朋友推荐了一款基于官方 12.5.1 版本二次编译的客户端。抱着试试看的心态用了几天，记录如下。

登录环节

最大的变化是绕过了 smsfee 的拦路虎。按照内置引导操作，从输入手机号到成功登录，整个过程大约两分钟，验证码到达速度正常。对于被官方注册流程劝退的人来说，这个入口友好很多。

语言环境

开箱即用的中文支持。界面菜单、群组列表、频道内容均显示为中文，没有出现常见的编码乱码或翻译生硬的问题。日常浏览不需要在脑子里做中英文切换，阅读效率明显提升。

网络连接

内置了网络层的调优方案。启动后自动完成连接，不需要手动填写代理参数，也不用额外配置工具。测试期间在不同网络环境下（家庭宽带、移动数据、公共 WiFi）均能稳定连上，没有出现频繁断线或消息延迟的情况。（说人话就是不用再翻墙了，大家也都知道最近国内很严！）

功能完整性

核心功能与官方版保持同步：私聊、群组讨论、频道订阅、消息推送、多账号切换均可正常使用。后台驻留稳定性不错，消息提醒及时，没有出现漏收通知的情况。界面交互逻辑熟悉，老用户上手零门槛。

适用人群画像

被官方注册流程卡住、急需使用 TG 的 +86 用户

不想在代理配置和网络调试上花费时间的普通使用者

偏好中文环境、希望开箱即用的日常浏览者

客观总结

这款客户端本质上是官方代码的本地化编译版本，在保留核心功能的前提下，针对性解决了 +86 用户常见的注册障碍和网络连接问题。它不是一个"增强版"，更像是一个"无障碍通道"——让原本被门槛挡住的人能够顺利进入，专注于内容本身。

如果你也卡在登录这一步，或者只是想要一个省心的中文 TG 环境，可以留意评论区获取方式，按需自取即可。

Anthropic 内部数百个 Claude Code Skills，他们总结的这套方法值得看

Immerse — Sat, 16 May 2026 15:42:16 +0800

大家好，我是 Immerse

专注分享 AI 玩法、独立开发与AI 出海的 AGI 实践者，更多干货欢迎关注公众号 #沉浸式AI 或访问 yaolifeng.com

个人 AI News 站更新啦：news.yaolifeng.com

Anthropic 工程师 Thariq 最近在 X 上发了一篇长文，说他们公司内部现在有上百个 Skills 在跑，整理了一批踩坑经验。

大多数人第一次接触 Claude Code Skills，以为它就是个 Markdown 文件——写点提示词，丢进去，完事。

实际上 Skills 是文件夹，不是文件。里面可以放脚本、资产、数据、配置，整个目录结构都是上下文工程的一部分。

这篇文章整理他们的方法论：Skills 的分类体系、写好一个 Skill 的关键技巧，以及团队内部怎么分发和管理。

9 种类型

他们把内部所有 Skills 整理了一遍，大概在这几个方向上

1. 库和 API 参考

用来解释如何正确用某个库、CLI 或 SDK。不管是内部自己的库，还是 Claude 经常用错的外部库，都可以做成这类 Skill。

这类 Skills 通常带一个 references/ 文件夹，里面包含一个参考代码片段和踩坑清单。

比如：

billing-lib — 公司内部库，重点是边界情况和容易踩的坑
internal-platform-cli — 内部 CLI 工具的每个子命令，以及使用示例
frontend-design — 让 Claude 更好地理解你们的设计系统

2. 产品验证

描述怎么测试或验证代码能不能正确运行。一般配合 Playwright、tmux 使用。

Thariq 说得很直接：让一个工程师花一整周专门打磨验证 Skill，这个时间花得值

比如：

signup-flow-driver — 跑完整的注册流程（注册 → 邮件验证 → 引导），用 headless 浏览器，每步都有状态断言
checkout-verifier — 用 Stripe 测试卡驱动结账 UI，验证发票状态落地是否正确
tmux-cli-driver — 交互式 CLI 测试，用于需要 TTY 的场景

3. 数据获取和分析

连接你的数据和监控系统。这类 Skill 会带上权限凭证的数据获取库、dashboard ID，以及常见的一些操作指南。

比如：

funnel-query — "注册 → 激活 → 付费"这条漏斗用哪些事件表 JOIN，canonical user_id 在哪张表
cohort-compare — 对比两个用户群的留存或转化，标记统计显著的差异，链接到细分定义
grafana — datasource UID、集群名称、问题到仪表盘的映射表

4. 业务流程和团队自动化

把重复的工作流自动化成一个命令。指令本身通常比较简单，但可能依赖其他 Skill 或 MCP。

可以把历史执行结果存进日志文件是个好习惯，可以帮 Claude 做前后对比，而不是每次从头开始。

比如：

standup-post — 汇总你的 ticket 系统、GitHub 动态和昨天的 Slack，生成只有增量变化的站会帖子
create-ticket — 强制执行字段 schema（枚举值、必填字段），创建后自动触发后续流程（通知审核人、在 Slack 贴链接）
weekly-recap — 合并的 PR + 关闭的 ticket + 部署记录，格式化成周报

5. 代码脚手架和模板

为代码库里的某个功能生成框架代码。这类 Skill 特别适合那些有自然语言要求、纯代码覆盖不了的脚手架场景。

比如：

new-workflow — 按你们的注解规范，生成新 service/workflow/handler 的脚手架
new-migration — 数据库迁移文件模板，附带常见坑
create-app — 新建内部应用，预置好你们的 auth、日志和部署配置

6. 代码质量和审查

在团队内部执行代码质量标准，辅助代码审查。可以包含确定性脚本，也可以在 hooks 或 GitHub Actions 里自动触发。

adversarial-review — 起一个新的 subagent 用全新视角批判代码，实现修复，迭代直到问题只剩鸡毛蒜皮
code-style — 强制执行代码风格，尤其是 Claude 默认不做的那些规范
testing-practices — 指导怎么写测试、测什么

7. CI/CD 和部署

帮助拉取、推送、部署代码，可能会引用其他 Skill 来收集数据。

比如：

babysit-pr — 监控 PR → 重试不稳定的 CI → 解决合并冲突 → 开启自动合并
deploy-service — 构建 → 冒烟测试 → 灰度流量 + 错误率对比 → 自动回滚
cherry-pick-prod — 隔离 worktree → cherry-pick → 解决冲突 → 附模板的 PR

8. Runbooks

接收一个问题症状（Slack 线程、告警、错误特征），它会执行多工具调查，输出结构化报告。

比如：

service-debugging — 把症状映射到工具和查询模式，针对流量最高的服务
oncall-runner — 拉取告警 → 检查常见嫌疑点 → 格式化调查结论
log-correlator — 给一个 request ID，从所有可能经过的系统里拉对应日志

9. 基础设施运维

执行日常维护和操作流程。破坏性操作放进 Skill 可以一层护栏，避免手滑导致不可逆的风险

比如：

orphans-cleanup — 找孤立的 pod/volume → 发 Slack → 等待期 → 用户确认 → 级联清理
dependency-management — 你们组织的依赖审批流程
cost-investigation — "为什么存储/出流量账单突然涨了"，定位到具体 bucket 和查询模式

写好一个 Skill 的关键技巧

不要放很常识的东西

Claude 已经懂很多编码知识，有自己的默认判断。如果你写的 Skill 主要是常识，它没什么价值。要把精力放在那些会把 Claude 推出默认思维的信息上。

Anthropic 内部的 frontend-design Skill 是个好例子——一个工程师跟用户迭代，专门调教 Claude 的设计品味，让它避开 Inter 字体和紫色渐变这类 AI 审美。这类东西 Claude 默认是不知道的。

Gotchas 部分信噪比最高

一个 Skill 里信噪比最高的部分就是 Gotchas。这里记录 Claude 实际使用你的 Skill 时踩过的坑——不是你预测它会踩的，是真的踩了的。边用边更新，遇到新的 edge case 就补进去。

Skill 是文件夹，不是 md 文件

把整个文件系统当成一种上下文工程和渐进式披露的手段。在 SKILL.md 里告诉 Claude 有哪些文件，它会在合适的时候去读。

最简单的做法是把详细内容拆到其他 md 文件里。比如函数签名和用法示例单独放到 references/api.md，Claude 需要的时候再去读，而不是一开始就全部加载进上下文。

你还可以这样组织：

assets/ 放模板文件，Claude 要生成对应格式的输出时直接复制用
scripts/ 放可以直接调用的工具脚本
references/ 放参考代码片段和文档

给 Claude 信息，不要给 Claude 剧本

因为 Skill 是高度复用的，过于具体的指令反而会出问题。给 Claude 它需要的信息，但给它适应当前情况的空间。不要把每一步都写死，把判断权留给 Claude。

Setup 环节要想清楚

有些 Skill 需要用户提供上下文才能工作

最常见模式：配置信息存在 Skill 目录下的 config.json 里，如果配置不存在，Agent 去问用户。要给出结构化的多选题，可以在 Skill 里指示使用 AskUserQuestion 工具。

description 字段是给模型看的触发条件

Claude Code 启动时会给每个 Skill 建一个带 description 的列表，扫这个列表来判断「有没有对应这个请求的 Skill」。所以 description 要写清楚触发时机，而不是 Skill 功能的摘要。

Skills 可以有记忆

Skill 里可以包含一种记忆，通过在 Skill 目录里存数据实现。从简单的 append-only 文本日志、JSON 文件，到复杂的 SQLite 数据库都可以。

比如 standup-post Skill 维护一个 standups.log，记录每次写的内容，下次运行时 Claude 读自己的历史，知道哪些是新变化。

注意：存在 Skill 目录里的数据升级时可能被删掉。持久数据应该存到 ${CLAUDE_PLUGIN_DATA}，这是每个插件独立的稳定存储路径。

在 Skills 里放脚本

给 Claude 代码比给指令有效得多。有了脚本和库，Claude 就能把时间花在组合和决策上，而不是每次从头重建样板代码。

比如数据科学类 Skill 里放一组从事件源取数的 helper 函数，Claude 就可以按需动态生成脚本来做进一步分析，而不是每次自己写逻辑。

按需 Hooks

Skill 可以包含只在 Skill 被调用时激活的 hooks，持续到这个 session 结束。这适合那些场景特定、不想一直开着的强约束 hook。

两个典型例子：

/careful — 通过 PreToolUse matcher 拦截 rm -rf、DROP TABLE、force-push、kubectl delete。只在你知道自己要动 prod 的时候才需要，常开会让人崩溃
/freeze — 拦截所有不在指定目录里的 Edit/Write。调试时很有用："我想加日志，但我总是顺手把别的东西改了"

怎么在团队里分发 Skills

分发方式取决于团队规模：

小团队：把 Skills 提交进代码仓库（./.claude/skills 目录）。团队人不多、仓库也不多的情况下，这样最简单直接。

大团队：搭内部插件市场，按需安装。这是因为每个提交进仓库的 Skill 都会给模型的上下文增加一点点体积，规模大了之后就不可忽视了。内部市场让每个人自己决定装哪些。

Skills 互相引用

如果你有一个 Skill 要依赖另一个 Skill，直接在指令里引用另一个 Skill 的名字就行，Claude 会在它已安装的情况下调用它。这个依赖管理目前还没有原生的 Skill 系统支持，但这种方式能跑通。

Skill 使用情况

Anthropic 用 PreToolUse hook 记录公司内部的 Skill 使用情况。这样能看到哪些 Skill 频繁被用，哪些触发率低于预期——后者意味着 description 没写好，或者这个 Skill 根本没解决真实需求。

发现 Skill 很少被触发，先检查 description 是不是清楚地描述了触发场景。

大部分 Skill 在 Anthropic 内部也是从几行指令、一个 Gotcha 开始的，遇到新 edge case 就补进去，慢慢变好的。挑一件你每天重复干的事，写一个最简版，先跑通。

全自动产品开发，没有设计师也能自己设计产品。电商福音

yea032 — Sat, 16 May 2026 14:16:07 +0800

这个网站解决了想做新产品，但又不懂设计的难题，没有设计师公司的福音！

这个网站其实很简单，就是为了帮那些有产品设计思维，但不会使用专业绘图软件的老板，产品经理，个人。解决产品开发的难题。

每一个做产品卖产品的公司，包括一些小店，个人，都会有开发新品的想法，尤其是一些加工厂，电商公司；都会希望在每一个阶段上新品。有时候老板自己本人或者产品经理，可能也有自己的产品开发想法，但是自己又不懂怎么使用绘图软件，然而，身边又没有设计师；若专门去外面找一个设计师，成本高，还不一定能找到合适的。这个网站就是解决这个问题的。

人人都可以在上面开发自己的产品，它并不是换材质，迁移，换颜色那么简单，而是可以帮你创作出一个新的产品；虽然创作出来的图不一定能直接生产使用，但是能给你发散思维，让你的想法直观化，看得见，为你开发产品节约时间和脑力！

而且网站当前还可以免费入驻设计师和供应商！当你生成的图需要专业人士调整时，就找网站内部的设计师调整；当你想打样，生成的时候，就找网站内部的供应商。也就是说，从灵感开发到落地，都包含在内了。

本站用法很简单，只需要上传一张你想开发的对标产品图，如果你有自己想法，就把想法写在图片中；如果你想结合其他图的特征设计，就上传其他参考图；网站会自动思考，结合你所上传的所有参考图，用它自己的思维帮你创作出一个原创新品。全程不用设置，不用写提示词，会用鼠标就可以。

你感觉这个网站怎样？能帮到你吗？网址：https://www.takingai.cn/

AI Rapper 说唱音乐生成器

finekewei — Sat, 16 May 2026 13:35:26 +0800

写了个在线说唱音乐的项目，有兴趣的可以试试看 https://rapper.im/

可以用来表达观点，或者作为短视频背景声音啥的

这网站有点意思。只要一张对标产品图，就能设计出新的产品，还不用提示词。

yea032 — Sat, 16 May 2026 11:24:06 +0800

这个网站解决了想做新产品，但又不懂设计的难题，没有设计师公司的福音！

这个网站其实很简单，就是为了帮那些有产品设计思维，但不会使用专业绘图软件的老板，产品经理，个人。解决产品开发的难题。

你感觉这个网站怎样？能帮到你吗？网址：https://www.takingai.cn/

一款简约，纯粹的 AI 工具导航站

fly63 — Sat, 16 May 2026 11:21:25 +0800

这是一个专门收集和整理 AI 工具的网站。现在市面上的 AI 工具越来越多，ChatGPT、Midjourney、Stable Diffusion 这些名字你可能都听过，但真要找一个适合自己的工具，往往要翻半天。

这个网站就是帮你解决这个问题的——它把各种 AI 工具按类别整理好，你打开网站就能看到，点一下就能用。

网站首页按分类展示工具，比如 AI 写作、AI 绘画、AI 编程、AI 视频等等。每个分类下面列出对应的工具，有工具名称、简介和图标，一目了然。看到感兴趣的工具，点进去就能看到详细介绍，包括这个工具能干什么、有什么特色、适合什么场景、常见问题怎么解决。

地址：https://ai.fly63.com

Gemini cli 登录异常解法

sphinx30 — Fri, 15 May 2026 23:05:25 +0800

事情是这样的。

今天下午，有个项目要用到 Gemini CLI，我想着那就登一下吧，反正之前也用过。

结果终端输完命令，点完授权，跳完浏览器，回到终端。

就给我看这个。

全网都在教你调代理

嗯？

什么情况？

我以为是网络波动，重试了两次，还是一样。

于是我去搜了一下，好家伙，一搜才发现，这个问题已经爆了快一个月了。整个中文互联网搜 gemini cli 登不上，出来的帖子能翻十几页，从 CSDN 到知乎到 GitHub Issue，所有人都在骂。

然后你猜所有人给出的解决方案是什么？

清一色，检查代理。

什么检查环境变量啊，什么给 PowerShell 单独设置 WinHTTP 代理啊，什么用 proxychains 啊，还有说要在环境变量里配置谷歌云项目 ID 的。

我当时还真信了。

于是我照着网上的教程，一步一步来。

先在 PowerShell 里敲 netsh winhttp show proxy，看看代理是不是生效。

显示正常。

不放心，又手动设了一遍 netsh winhttp set proxy 127.0.0.1:7890。

然后再去登。

还是失败。

我当时就有点懵了。

我甚至把代理关了又开，开了又关，节点换了好几个，从香港换到新加坡换到日本，甚至试了美国原生家宽。

没用，就是登不上。

。。。

真正的原因，被所有人忽略了

这个时候我突然想起一件事。

大概两周前，我发现 Google AI Studio 打不开了，浏览器里直接 403，当时以为是谷歌又封了什么区域，也没在意。

这两件事会不会有什么联系？

我于是去搜「Google AI Studio 403」，出来的结果让我一下子就反应过来了。

原来，谷歌从上个月开始，悄悄给所有用户发了一封邮件，要求进行年龄验证。

你没看错，年龄验证。

因为之前注册谷歌账号的时候，那个年龄你随便填的，谷歌根本不会真的去验证。你说你 18 你就 18，你说你 80 你就 80。

但现在不行了。

谷歌说，不行，我现在要开始认真了。如果你不做年龄验证，那所有跟 AI 相关的服务，你就别想用了。

包括 AI Studio，也包括 Gemini CLI。

我靠。

我突然想起来，那封邮件我确实收到过，当时扫了一眼标题，觉得又是谷歌什么乱七八糟的通知，直接就给删了。

谁能想到，就这么个破事，能把我卡一下午？

于是我赶紧去把年龄验证做了，链接放这里，你们遇到同样问题的也可以直接去。

https://myaccount.google.com/age-verification

验证完，我先去打开 AI Studio，果然能进了。

然后回到终端，再敲一遍 gemini 登录。

授权，跳转，确认。

成了。

写在最后

我当时坐在屏幕前，真的就是一声叹息。

你说这叫什么事啊。

整整一个月，整个中文互联网所有人都在教你怎么调代理，所有人都在骂谷歌的反人类网络设置。

结果真正的原因，是你没去填那个年龄验证。

没有任何一篇文章提到这件事。

所有人都在错误的方向上，互相抄来抄去，把一个根本不存在的问题，越描越复杂。

最后甚至形成了一种集体幻觉，好像真的是代理的问题，好像真的只要你多换几个节点，多试几次，总能成功。

我后来在想，为什么会这样？

大概是因为，我们已经太习惯「谷歌的服务出问题，那肯定是代理的锅」这个条件反射了。以至于当真正的问题出在别的地方时，我们甚至连想都不会往那个方向去想。

我们只会一遍又一遍地，在同一个错误的地方，用同一种错误的方法，试图得到一个正确的结果。

这跟现在很多人用 AI 的状态，是不是也有点像？

遇到问题，第一反应不是去想「这个问题的本质是什么」，而是去搜「别人是怎么解决的」，然后照着抄一遍。抄来抄去，所有人都在同一个坑里打转，就是没人愿意停下来，多问一句，真的是这样吗？

哦对了，如果你现在去谷歌搜「gemini cli 登录不上」，排在前几的那几篇文章，还是在教你怎么设置代理。

没有人更新。

没有人发现真正的原因。

所有人都还在那个坑里。

信息差啊，朋友们。

有时候，你跟正确答案之间的距离，不是你不够努力，也不是你技术不够好。

就只是，没有人告诉你，真正的问题是什么。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

公众号：大强同学

我让 AI 当了 24 小时全年无休的 “毒舌考官”

193577746 — Fri, 15 May 2026 19:45:35 +0800

公司开了个仓库，前端团队从 3 人扩到 12 人，我定规矩：所有 PR 至少 1 个 Review 才能合。好的，大家开始互相送 “LGTM ⭐” 了——一眼都没看，点完就跑。线上挂的时候谁也背锅，群消息全是 “不是我”。我一气之下拉了 AI 进来当永久 Code Reviewer，0 薪水 7x24 小时在线，什么混子、什么歪代码，全部兜住。

前言

PR 审查这件事，经历过的都懂：平时没人看，一出事全是 “我早说了”。你认真看了 500 行 diff 给出了 3 页修改意见，人家回复一个 “done”，你都不知道改没改对。

Code Review 的最大矛盾是什么？要快，就水；要细，就慢。AI 时代，你猜怎么着？这活儿最适合交给机器人。不需要情商，直接喷；不需要开会，秒回；不需要记住项目规范，每次都按最新标准来。

今天我来实操：用 AI 在自己的 PR 里自动跑 Code Review，准确到几行代码，还能直接输出 “P0 严重”、“P1 重要”、“P2 建议” 的结构化报告。准备接受 AI 对你代码的无差别吐槽了吗？

一、AI 当 reviewer 会 “胡说八道” 吗？

你先不用管它会胡说八道。你只要让它遵循的原则是 “如果这条建议可能不对，就闭嘴”。

打个比方，你让人工 review：“这个 useEffect 漏了清理函数” → 这是对的。“你这里最好改用 useMemo” → 有时是对的，但也可能是在显摆。

AI 也一样，你调校它的方式不是 “提示词”，而是给它喂规则。

来看看我用了大半年的一套 AI Code Review 命令行工具能 “喷” 什么：

security：检测登录态是否在前端 localStorage 明文存密码、有没有 XSS 注入风险、SQL 注入隐患。
performance：看你有没有在 React 组件里直接写 const style = { margin: 10 }（每次渲染新建对象）。
accessibility：img 缺 alt、button 缺类型、颜色对比度稀烂。
code quality：文件超过 500 行给你标黄、catch 了错误只 console.log（等于没 catch）、变量名拼写错误。

这套逻辑用下来，我的体感：AI 发现问题的速度是人类的 20 倍以上，遗漏率比人类 reviewer 低得多，而且从不得罪人——因为它不带 “你写得好烂” 的情绪，只有纯技术判断。

二、一行命令立刻拥有

我最近一直在用一个叫 ai-review-pipeline 的工具，它的理念很好：“AI 审查 AI 写的代码”——现在是 AI 辅助编程时代了，写得快但容易藏 bug，我正好需要这种【7x24 小时兜底】

这个工具的特点是用 AI 自动 review + 生成测试 + 自动修复。你就无脑给它一个文件或目录，它出来的是评分 + 问题清单 + 修复建议 + 测试用例。

npx ai-review-pipeline --file src/ --full

它的流程很清晰：先跑确定性规则检查（比如 ESLint 已有的问题一次性过滤掉，不让 AI 重复废话），然后 AI 带着你配置好的团队规范去读 diff，每发现一个问题就给等级、给修复建议、给代码示例。如果你加 --fix 参数，它甚至会尝试自动修然后重新 review。

你说：“万一自动修复改错了逻辑呢？” 错不了，AI 只敢改那些确定性高的低质量代码（多余空格、未使用的变量、非空断言错误等）。业务逻辑？它先绕开，你合并之前自己把关。

而且支持绝大部分场景（后端 Java, Go, Python, Rust 也能喷）：

前端代码 review（React / Vue / TSX、CSS、a11y）
backend-code-review（API 设计、数据库、并发安全）
自动修复（默认只修格式、未使用的变量、确定的 lint 类问题，不敢动业务逻辑）
Multi-LLM（OpenAI、Claude、DeepSeek、Gemini、Ollama 都能跑）

三、调 AI 的 “毒舌参数”，让它喷得更专业

我用过 Grok、Claude 和 DeepSeek，相对用得最深的是 DeepSeek 和 OpenAI。调教参数也很简单：

# 预设深度更狠一点，让它给你抓出 P0~P3 等级的分类
ai-review config set strictness=high
ai-review config set outputFormat=structured

AI 的审查结果可以直接挂在 GitHub PR 里当 Comment，每条对应具体行数和问题等级。一旦 AI 给了 P0（严重） ，CI 直接 block 合并，你必须解决。

注意：如果你的项目有特别明确的 “业务规范”，你可以写到 .ai-pipeline.json 配置文件里，例如 “禁止引入 moment.js”、“禁止在循环中使用 await”，AI 会把这部分自动纳入审查范畴，跟内置规则并排跑。

四、这套 AI Code Review 还解决了哪些痛点？

1. 跨语言能力 + 敏感信息排查

检查出来的问题几乎横跨你代码库所有位置：泄漏的 API endpoint、调试信息意外留到生产、图片 dead link 甚至无障碍视觉回归。

它有一个特殊技巧：让多个 LLM 并行审查、互相辩论，然后一个 “法官 agent” 给出最终裁决。不同模型能逮到不同 bug，通过共识机制滤掉噪音。

2. CI 门禁，上线之前最后一道防线

你可以把 ai-review-pipeline 挂在 GitHub Actions 上，每次 PR 自动执行。如果评分低于阈值（比如 80 分），CI 直接标红，连人都不用到场干预。

某互联网团队落地类似系统后，代码审查周期缩短了 65%，基础性缺陷拦截率提升了 82%。这个数据就是 AI review 正面效果的最好说明。

五、毒舌吐槽大会：AI 喷过的那些人类代码

我随便举几个真实案例，括号里是 AI 原话（节选）：

案例 1：setTimeout(() => { ... }, 0) 用来模拟 “异步一下”。AI 喷：“用 setTimeout 0 是反模式，你应该用 Promise.resolve().then() 或者 queueMicrotask。——另外，你连错误处理都没有？”
案例 2：自己封装了一个 request 函数，每个请求都 console.log 全部响应体数据。AI 喷：“你在生产环境把整个 API 响应结构暴露到控制台，包含了敏感字段。P0 严重。建议只 log trace id。”
案例 3：<img src={userInput} />。AI 喷：“你直接把用户输入当 src？明天你的网站就变成菠菜广告基地。用 DOMPurify 或者干脆用 background-image 托管。”

这套 AI 让我晚上睡得踏实。自从它上线，我再也没有过 “线上又崩了，测试也没测出来” 的半夜来电。

六、总结：AI 帮你 review 代码不是替代人，而是让你做更高价值的事

AI 擅长一致性检查、边界检测、安全底网，还能给出可落地的修复示例。人类 reviewer 只需要关注架构、业务语义、用户体验。
成本几乎为零，你只需要提供几个免费 API（Ollama、Groq 或各家入门额度）+ 一条 npx 命令。
未来方向：不只是 review，还开始蔓延到自动修复 + 测试生成 + 知识沉淀，AI 在 PR 里已经可以替你完成 80% 的 “找茬” 工作。

我的建议：今天就拉一个这样的工具进你的私有仓库和团队。领导不批预算？不用批，无门槛，立刻跑起来。等下次有人 PR 又是 “空代码 + 俩表情包” 来糊弄时，AI 会替你第一时间上去喷它：“你写的代码，想让我怎么 review？请自重点。”

给 Shipstry 加了个外链提交追踪功能，解决独立开发者分散提交的痛点

coryso — Fri, 15 May 2026 18:08:34 +0800

做独立开发的朋友应该都有这个经历：产品上线后要往各种目录网站提交，Product Hunt 、Reddit 、GitHub Pages 、各种 AI 工具目录……

然后很快就失控了：

哪些提交了、哪些没提交，记不清
哪些通过了、哪些被拒了，没追踪
靠 Excel 或者 Notion 记，就是手工活多一点

所以我给自己的产品 Shipstry 做了个 Backlink Submissions 功能，专门解决这个问题。主要功能：

Discover：内置 800+ 目录，按 DR（ Domain Rating ）排序，GitHub DR96 、Gravatar DR97 、Reddit DR95 这些都有
Queue：看中哪个目录直接加队列，不用手动复制粘贴
状态追踪：Unstarted → Planned → Submitted → Live ，全流程标记
筛选：按 DR 、费用、dofollow/nofollow 、接受类型过滤
多产品管理：每个产品独立追踪，下拉切换

界面大概长这样（见截图），核心思路就是把散乱的外链提交变成一个可管理的 pipeline 。

shipstry.com/backlinks

有在做外链建设的朋友欢迎试试，也欢迎提建议 🙏

只要一张对标产品图，就能设计出新的产品，无提示词。

yea032 — Fri, 15 May 2026 15:53:25 +0800

这个网站 https://www.takingai.cn/ 解决了想做新产品，但又不懂设计的难题！

这个网站的初衷其实很简单，就是为了帮那些有产品设计思维，但不会使用专业绘图软件的老板，产品经理，个人。解决产品开发的难题。

你感觉这个网站怎样？能帮到你吗？

最近 AI 图像生成变化太快，GPT Image 2 值得看看

13025154939 — Fri, 15 May 2026 13:14:51 +0800

最近明显感觉 AI 图像生成这个领域又开始加速了。前段时间大家还在对比 Midjourney、Nano Banana Pro、Firefly 这些工具，主要看画面质感、风格稳定性和创意表现。现在新的重点开始变成：谁能更好理解提示词、谁能更准确生成文字、谁更适合真实商业场景。

我这几天也试了一些工具，感觉 GPT Image 2 这个方向挺有意思。相比单纯追求 “好看” 的图片，它更适合做一些实用型内容，比如海报、广告图、社媒配图、产品展示图、信息图这些。尤其是图片里的文字渲染，比以前很多 AI 图片工具稳定不少。

现在 AI 图像工具已经不只是 “生成一张漂亮图片” 了，而是越来越接近真正的设计辅助工具。比如一个产品图、活动海报、Banner 草图，以前可能需要反复找素材、调版式，现在用提示词就能先快速生成几个方向，再慢慢优化。

如果你最近也在关注 AI 图片生成，或者想找一个偏实用、偏商业创作的工具，可以试试这个：https://gptimage2app.com/

不用梯子、不用接验证码，我发现了一个国内用户直接上 Telegram 的客户端

huo — Fri, 15 May 2026 11:34:14 +0800

说实话，+86 手机号登录 Telegram 这件事，坑了我太多次。

SMSfee 弹窗、验证码收不到、接了码还被风控、梯子不稳定断连... 每次想上 TG 查个资料，光登录就要折腾半小时。

后来我大量尝试第三方，终于得到一款让我满意的!

这个客户端解决了什么

1. 不用翻墙，直连 Telegram

不是内置代理、不是修改 hosts、不是找节点。网络层做了深度适配，安装完直接打开，消息收发、图片加载、频道浏览，全部正常。（我知道你们最关心这个，直接说：不需要任何梯子工具。）

2. 不用跳转接码平台，成品号直登

内置了成品号购买入口，一个已经验证过的号，输入账号密码直接登录。跳过 SMSfee，跳过 +86 接码地狱，跳过"请稍后再试"的无限循环。对于已经被封过号、换过多次手机号的老用户，这是目前最干净的方案。

3. 打开就是中文，和官方客户端功能完全一致

基于官方 12.5.1 源码编译，没有阉割任何功能。私密聊天、群组、频道订阅、文件传输、消息撤回，全部原生保留。界面默认简体中文，不需要手动导入翻译包。

适合谁用

被 SMSfee 卡过、验证码死活收不到的 +86 用户
不想折腾梯子、不想每个月买节点的轻度用户
需要稳定使用 Telegram 但不想在登录环节花时间的效率党
之前用过各种第三方客户端，但要么要翻墙、要么功能残缺的

实测数据

我自己 + 内测群 30 多人，覆盖移动/联通/电信三网，近两周登录成功率 100%，消息收发延迟和官方客户端无明显差异。

获取方式

评论区自取

有问题直接下面留言，我每天都在。

最后说句实在的：他的存在不是为了替代官方客户端，是解决一个具体场景的具体痛点。如果你也被登录 Telegram 折磨过，试试这个，不好用回来骂我。

BeddyColor - 免费儿童涂色画打印下载

jack-jack — Fri, 15 May 2026 10:02:32 +0800

BeddyColor 是一个免费的儿童涂色画打印网站，提供数千张高质量涂色页。

主要特点：

丰富主题：动物、卡通、节日、教育等多个分类
高质量：所有涂色页均为高清设计，打印效果出色
完全免费：无需注册，直接下载打印
持续更新：定期添加新的涂色内容

网址：https://beddycolor.com

欢迎大家体验，有任何建议欢迎反馈！

Google 搜索 CLI：给 AI Agent 装上谷歌搜索能力

sphinx30 — Thu, 14 May 2026 23:00:50 +0800

AI Agent 不能联网真的太蛋疼了。试了五六种搜索工具，没有一个让人省心——要么要配 API Key，要么要跑后台服务，要么结果一塌糊涂。

直到发现 gsearch-cli。Rust 写的，单二进制，小得离谱，跑起来快得惊人。最妙的是它能直接复用 Gemini CLI 的 OAuth 认证，零配置，装完就能用。

现在 Claude Code 终于有真正的谷歌搜索能力了。

安装

方式一：有 Rust 环境

cargo install gsearch-cli

方式二：macOS

brew install aeroxy/tap/gsearch

装完先登录一次：

gsearch --login

浏览器打开授权页面，点一下确认就完事了。

怎么用

1. 命令行直接用

gsearch 新加坡天气

不用加引号，空格直接搜。

2. Claude Code 自然语言调用

这才是终极形态——让 Agent 获得真正的联网能力。

直接用项目自带的 Skill：

# 从源码里复制，或者手动创建
cp gsearch-cli/skill/gsearch/SKILL.md ~/.claude/skills/gsearch/

作者已经写好了完整的 Skill，包含：

自动触发条件（搜索谷歌、查找资料、需要实时信息）
完整的使用流程说明
输出格式和引用说明

配置完就能用！ 下次直接说：

帮我搜一下 2026年5月有什么新的AI模型发布

Claude Code 会自动识别并调用这个 Skill，不需要写复杂的 System Prompt。

设计亮点

1. 终端 Markdown 自动检测

这个细节特别用心：

if stdout().is_terminal() {
    termimad::print_text(&formatted);  // 终端输出 → 彩色渲染
} else {
    println!("{}", formatted);          // 文件/管道 → 纯净 Markdown
}

效果：

直接运行 gsearch xxx → 看到彩色、粗体、高亮的排版（给人看）
gsearch xxx > out.md → 文件里是纯净 Markdown，没有乱码字符（给程序用）

2. 引用来源机制

搜索结果带 Gemini 的 grounding 数据，正文插入 [1] [2] 标记，末尾自动列出 Sources 链接。

注意：不是每次都有 Sources：

✅ 时效性新闻、技术文档、冷门事件 → 有完整引用
⚠️ 最新财报、热点新闻 → 可能有注
❌ 常识历史内容（如马斯克早年经历）→ Gemini 认为训练数据已有，不联网

核心原理

这个工具最巧妙的地方在于——它伪装成了官方的 Gemini CLI。

1. 认证复用

直接读 ~/.gemini/oauth_creds.json，用的是和 Google 官方 Gemini CLI 完全相同的 Client ID/Secret。如果你已经登录过 Gemini CLI，装完直接能用。

2. 调用内部 API

不走公开的 Gemini API，用的是 Gemini CLI / Cloud Code 插件的内部端点：

cloudcode-pa.googleapis.com/v1internal:generateContent

User-Agent 也伪装成 GeminiCLI/...，Google 根本分不清是 gsearch 还是官方客户端。

3. 原生联网搜索

调用 Gemini 时开启 googleSearch 内置工具，用的是 Gemini 的 Grounded Search 原生能力，不是爬虫，比所有第三方搜索工具都稳。

4. 自动维护

Token 过期前 5 分钟自动刷新
自动检测 HTTPS_PROXY，忽略证书验证，公司内网也能跑
不需要 API Key，不需要 Google Cloud 项目

源码结构

总共就 4 个文件：

main.rs - 主入口和命令行解析
auth.rs - OAuth 认证和 token 管理
api.rs - Gemini 内部 API 调用
grounding.rs - 搜索结果格式化

MIT 协议开源，随便改。

最后说两句

不是什么惊天动地的大项目，但它把一个很小的问题解决得特别干净。没有花里胡哨的功能，没有复杂的配置，装完就能用。

对于折腾 AI Agent 的人来说，这玩意儿就是刚需——你的 Agent 终于能真正"上网"了。

有扣子（Coze）工作流大佬吗？这篇文章你一定要看！

ALLENREN — Thu, 14 May 2026 21:54:52 +0800

一、扣子（Coze）是什么？能做什么？

扣子（Coze）是字节跳动推出的一款 AI Bot 开发平台，不需要用代码也能构建、调试和部署智能体（Bot）或工作流。你可以实现从基础对话到复杂任务自动化的全流程 AI 应用开发。以下是具体的操作场景和能力：

零代码搭建智能体：通过可视化编排设定人设、配置插件和知识库，无需编程即可快速创建具有专业能力的对话机器人。
构建自动化工作流：使用拖拽方式设计任务链条，并可在代码节点中用 JavaScript 或 Python 编写自定义逻辑，实现复杂的自动化处理。
部署全能 AI 办公助手：让 AI 自主拆解长期任务（如写竞品报告）、一键生成 PPT 和海报、处理 Excel、将图文转为播客，甚至通过对话直接编程并部署网站。
调试与分发：在配置界面右侧，你可以随时与正在搭建的智能体对话，测试效果并即时调整。完成开发后，你可以将智能体一键发布到多个渠道，例如：小米应用商店（AI 智能体专区）、微信公众号、小程序、企业微信等。

扣子本身主要处理对话逻辑和工作流编排，如果想要智能体具备真正的图像生成、图像识别或视频创作能力，就需要接入专业的视觉生成模型。GrsaiApi 官方提供了——“GrsaiApi——图像生成对话工具” 插件工具，可在扣子插件商店收藏使用。

Grsai API（https://grsai.com com 需要魔法，没有 com 改 Ai 国内直连）作为国内 AI 大模型 API 源头供应商，提供图片、文本、视频模型生成接口，包括：gpt5.4、gpt5.5、gpt-image-2、Nano banana、Nano banana Pro、Nano banana2、Gemini....等模型，支持高并发、失败秒退。模型列表：https://grsai.ai/zh/dashboard/models

通过 GrsaiApi 提供的插件，你的 Bot 可以用最低的价格调用 Grsai API 内所有模型，包含语言、画图、视频。

二、GrsaiApi 扣子插件：GrsaiApi——图像生成对话工具

在扣子中，只需要在插件商店搜索 “GrsaiApi——图像生成对话工具” 插件并收藏，即可使用 GrsaiApi 内置所有模型，有 6 个工具，分为旧版和新版，有什么区别该怎么选择请仔细看接下来的介绍。

1.新旧版啥区别？

GrsaiAPI 的旧版文档（https://grsai.ai/zh/dashboard/documents/gpt-image）中，不同厂商的模型拥有各自独立的接口，例如 GPT-image 模型使用/v1/draw/completions，而 Nano banana 模型则使用/v1/draw/nano-banana。由于接口不统一，调用不同模型需要编写不同的工具代码，导致用户在切换模型时无法快速完成。

Grsai_Old_NanoBa：支持 GrsaiApi 所有 Nanobanana 模型
Grsai_Old_image_2：支持 GrsaiApi 所有 Gpt-image-2 模型
Grsai_Old_Get_Results：支持上述两个模型的异步任务查询

GrsaiAPI 新版文档（nano-banana 接口 - Grsai API https://qmy27nhsd9.apifox.cn/452392911e0 ）采用了统一接口，只需调用 https://{base_url}/v1/api/generate 即可使用平台内除文本模型外的所有图片与视频生成模型。由于新旧文档模型参数不同，异步任务的查询仍需使用新版文档配套的工具。

请注意：新旧版 “Get_Results” 异步查询工具不可混用！

Grsai_New_All_image（推荐）：支持 GrsaiApi 所有画图/视频模型
Grsai_New_chat_image：open 格式支持 Grsai 内所有模型（文本、图片、视频模型；注意图片不支持分辨率选择）
Grsai_New_Get_Results：异步生成结果查询接口，仅支持使用 “Grsai_New_All_image” 工具并设置了 replyType:"async"参数生成的 id 查询

2.创建 apiKey

在 GrsaiApi 控制台：https://grsai.com/zh/dashboard/api-keys（com 需要魔法，没有改成 ai 即可访问）创建 ApiKey，复制使用。请勿泄漏你的 key 给其他人。

填入工具的 apiKey 参数中，注意不要外泄！

3.收到设置超时时间

建议所有用户在使用的时候将工具异常处理的 “整体执行超时” 超时时间设置在 600s，以免任务还没有生成扣子就返回失败。

4.不同模型区别

gemini-2.5-flash-image 对应：

nano-banana：1-2k 清晰度
nano-banana-fast：1-2k 清晰度

gemini-3-pro-image-preview 对应：

nano-banana-pro（推荐）：1-4k 清晰度高峰期稳定，偶有波动
nano-banana-pro-cl（推荐）：4k 画质清晰，pro 备用渠道，稳定速度快
nano-banana-pro-vt：高峰期不稳定，4k 画质清晰
nano-banana-pro-vip：1-2k 清晰度，付费渠道，稳定但贵
nano-banana-pro-4k-vip：4k 清晰度，付费渠道，稳定但贵

gemini-3.1-flash-image-preview 对应：

nano-banana-2：1-4k 清晰度
nano-banana-2-cl：1-2k 清晰度
nano-banana-2-4k-cl：4k 清晰度

Chatgpt image 2.0 对应：

gpt-image-2：仅支持 1k 清晰度
gpt-image-2-vip：支持 1k/2k/4k 清晰度，支持选择质量

渠道不同导致模型版本较多，请按需选择。具体信息看 GrsaiAPi 模型列表：https://grsai.ai/dashboard/mode

5. Grsai6 个扣子工具详细介绍

1.Grsai_Old_NanoBa

工具介绍：旧文档接口工具，可使用 GrsaiApi 内所有 nano banana 画图模型
支持模型：
nano-banana-2
nano-banana-2-cl
nano-banana-2-4k-cl
nano-banana-pro
nano-banana-pro-vt
nano-banana-pro-cl
nano-banana-pro-vip
nano-banana-pro-4k-vip
nano-banana-fast
nano-banana
输入参数：
apiKey（必填，控制台复制秘钥 sk-xxx）
model（必填，模型名称）
prompt（必填，提示词）
urls（参考图，支持多图）
webhook（异步回调填 “-1” 会返回 id）
aspectRatio（尺寸）
imageSize（分辨率）

2.Grsai_Old_image_2

工具介绍：旧文档接口工具，可使用 GrsaiApi 内所 gpt-image-2 画图模型
支持模型：gpt-image-2、gpt-image-2-vip
输入参数：
apiKey（必填，控制台复制秘钥 sk-xxx）
model（必填，模型名称）
prompt（必填，提示词）
urls（参考图，支持多图）
webhook（异步填 “-1” 会返回 id）
aspectRatio（尺寸/具体像素值，仅 gpt-image-2-vip 支持 2K、4K 像素值，例如 “2048x2048”）
quality（质量）
shutProgress（进度提醒）

3.Grsai_Old_Get_Results

工具介绍：旧文档接口工具，异步任务结果查询（仅支持带有 “Old” 画图工具的异步任务）
支持工具：Grsai_Old_NanoBa、Grsai_Old_image_2
输入参数：
apiKey（必填，控制台复制秘钥 sk-xxx）
id（必填，任务 id）

当你使用旧版画图工具提交异步任务后（webHook："-1"），用这个工具轮询获取生成结果。

4.Grsai_New_All_image（推荐）

工具介绍：旧文档接口工具，可使用 GrsaiApi 内所 gpt-image-2 画图模型，支持同步/流式/异步三种返回模式。
支持模型：gpt-image-2、gpt-image-2-vip
输入参数：
apiKey（必填，控制台复制秘钥 sk-xxx）
model（必填，模型名称）
prompt（必填，提示词）
urls（参考图，支持多图）
replyType（回复类型，支持选择参数）
json：返回 json
stream：返回 stream
async：异步轮询，需要通过 “Grsai_New_Get_Results"查询结果”
aspectRatio（图像比例/具体像素值，具体像素值仅对 Gpt 模型生效，特别注意 gpt-image-2-vip 的 2K、4K 分辨率需要通过填入对应分辨率像素值，例如 “2048x2048”）

5.Grsai_New_chat_image

工具介绍：新接口文档工具，open 格式支持 Grsai 内所有模型（对话 + 生图 + 视频），通过 “imageurls” 参数可上传图片、视频、文件链接
支持模型：
Chatgpt image 2：
gpt-image-2
gpt-image-2-vip
香蕉 2：
nano-banana-2
nano-banana-2-cl
nano-banana-2-4k-cl
香蕉 pro：
nano-banana-pro
nano-banana-pro-vt
nano-banana-pro-cl
nano-banana-pro-vip
nano-banana-pro-4k-vip
香蕉 1：
nano-banana-fast
nano-banana
语言模型：
gemini-3.1-pro
gemini-3-pro
gemini-2.5-pro
gpt-5.5
gpt-5.4
输入参数：
apiKey（必填，控制台复制秘钥 sk-xxx）
model（必填，模型名称）
messages（必填，提示词）
imageUrls（参考图，图片/视频/文件链接（支持多图））

“messages” 需要填入 JSON 内容参考

[
  {
    "role": "user",
    "comtent": [
      {
        "type": "text",
        "text": "组合成一张图片"
      }
    ]
  }
]

6.Grsai_New_Get_Results

类型：新接口异步结果查询工具，仅查询通过 “Grsai_New_All_image ” 并设置 replyType: "async" 生成的任务
支持工具：Grsai_New_All_image
输入参数：
apiKey（必填，控制台复制秘钥 sk-xxx）
id（必填，任务 id）

通过使用「GrsaiApi——图像生成对话工具」插件，你扣子的智能体就能具备图像生成、识别和视频创作等视觉能力。

测试妹子让我写单测，我偷偷用 AI 一天干完一周的活

193577746 — Thu, 14 May 2026 21:28:36 +0800

公司要求单元测试覆盖率 80%，我看着那几千行的屎山组件，眼泪掉下来。手写？写到下个月。测试妹子天天在群里 @ 我：“帅哥，你的单测呢？” 我灵机一动，让 AI 帮我写。一天后，测试覆盖率 91%，0 bug，测试妹子发了条朋友圈：“某前端切图仔突然开窍了。” 我没敢告诉她，那是 GPT-5.5 的手笔。

前言

写单测这事，比写业务代码还痛苦。业务代码至少能跑，能看到按钮，能点。单测？Mock 一堆，断言一堆，跑起来全红，改到怀疑人生。尤其接手老项目，一个组件几百行，手动补测试？告辞。

但我发现，AI 写单测的水平已经超过大部分初级工程师。你只要给它组件代码，它能给你生成结构清晰的测试用例：渲染测试、交互测试、异步测试、边界测试，甚至能帮你 mock 掉依赖的 API。

今天我就教你用 AI（Copilot / ChatGPT / Cursor）自动生成高质量 Jest + Testing Library 测试，把一周的活压缩到一天。测试妹子开心，我也能准时下班。

一、为什么 AI 写单测比你手写强？

不嫌烦：重复的渲染、快照、事件触发，AI 从不喊累。
覆盖全：它记得各种边界条件（空数组、null、undefined），你容易漏。
速度快：几秒钟生成几十个测试用例，你手打要半天。
风格统一：输出固定模板，代码规范。

缺点：生成的测试可能不够精准（比如断言了不重要的属性），需要你微调。但总比从零开始强。

二、实战：用 Cursor + GPT-5.5 给 React 组件生成测试

我们用一个实际的组件：UserProfile，它接收 userId，内部 fetch 用户数据，显示 loading、error、和用户信息。

// UserProfile.jsx
import { useState, useEffect } from 'react';
import { fetchUser } from './api';

export function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    fetchUser(userId)
      .then(setUser)
      .catch(setError)
      .finally(() => setLoading(false));
  }, [userId]);

  if (loading) return <div>加载中...</div>;
  if (error) return <div>出错了：{error.message}</div>;
  if (!user) return <div>无数据</div>;
  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
}

步骤 1：打开 Cursor，选中组件代码，右键 -> “Generate Tests”

或者在 ChatGPT 里粘贴代码，加上提示词：

请为以下 React 组件生成 Jest + React Testing Library 的单元测试。需要覆盖：初始加载状态、成功获取数据后显示用户信息、请求失败时显示错误信息、loading 结束后的渲染。请 mock 掉 fetchUser 这个 API。

步骤 2：AI 生成的测试（稍加整理）

import { render, screen, waitFor } from '@testing-library/react';
import { UserProfile } from './UserProfile';
import { fetchUser } from './api';

// Mock API 模块
jest.mock('./api', () => ({
  fetchUser: jest.fn(),
}));

describe('UserProfile', () => {
  beforeEach(() => {
    jest.clearAllMocks();
  });

  test('显示 loading 状态', () => {
    fetchUser.mockImplementation(() => new Promise(() => {})); // 永不返回
    render(<UserProfile userId={1} />);
    expect(screen.getByText('加载中...')).toBeInTheDocument();
  });

  test('成功加载后显示用户信息', async () => {
    const mockUser = { name: '张三', email: 'zhangsan@example.com' };
    fetchUser.mockResolvedValue(mockUser);
    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByText('张三')).toBeInTheDocument();
      expect(screen.getByText('zhangsan@example.com')).toBeInTheDocument();
    });
  });

  test('请求失败时显示错误信息', async () => {
    const error = { message: '网络错误' };
    fetchUser.mockRejectedValue(error);
    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByText(/出错了：网络错误/)).toBeInTheDocument();
    });
  });
});

看，连等待异步的 waitFor 都帮你写好了。 你只需要改一下错误信息的正则，或者加几个边界测试（比如 userId 为空）。

三、进阶：让 AI 生成更全面的测试

你可以在提示词里详细要求：

除了基本测试，还需要测试：

当 userId 变化时，会重新请求数据（之前的请求应被忽略或取消）

组件卸载时，不应再调用 setState

快照测试（可选）

AI 会给你生成类似：

test('userId 变化时重新获取数据', async () => {
  const mockUser1 = { name: 'User1' };
  const mockUser2 = { name: 'User2' };
  fetchUser.mockResolvedValueOnce(mockUser1);
  const { rerender } = render(<UserProfile userId={1} />);
  await waitFor(() => expect(screen.getByText('User1')).toBeInTheDocument());

  fetchUser.mockResolvedValueOnce(mockUser2);
  rerender(<UserProfile userId={2} />);
  await waitFor(() => expect(screen.getByText('User2')).toBeInTheDocument());
  expect(fetchUser).toHaveBeenCalledTimes(2);
});

连 rerender 都懂，你还想怎样？

四、效率对比：手写 vs AI

步骤	手写时间	AI 时间
写第一个测试（渲染 + loading）	10min	5s
写成功场景 + mock	15min	5s
写错误场景	10min	5s
写 userId 变化场景	15min	5s
调试断言	20min	5min
总计	70min	~6min

速度提升 10 倍以上。而且 AI 不会忘记清理 mock、不会漏掉 waitFor。

五、真实故事：我用 AI 补完了 2000 行老代码的单测

接手一个电商项目的购物车模块，几乎没测试。我写了脚本，把每个组件文件内容喂给 GPT-4（分批，用 API），让它输出测试代码。然后手动改几个断言，跑一遍。两个晚上，覆盖率从 12% 升到 86%。测试妹子在群里发了个烟花表情，我回了个狗头。

六、注意事项（坑）

AI 生成的 mock 路径可能错，比如 jest.mock('./api') 如果你的 api 文件是 services/api.js，需要手动改。
异步测试里 waitFor 的超时，有些场景需要增加 timeout 配置。
不要盲目相信：AI 可能会生成冗余测试（比如测试 div 的 className），需要你删除。
快照测试：AI 喜欢生成 toMatchSnapshot()，但快照容易 “假绿”，建议换成具体的断言。

七、总结：AI 不是来取代你，是来帮你下班的

用 AI 生成单测模板，再人工微调，效率翻 10 倍。
适合重复性高、边界条件多的纯函数和 React 组件。
业务逻辑复杂、需要特定上下文的，AI 可能不准，但至少给你搭好架子。
以后测试妹子再催你，你可以说：“已经在写（让 AI 写）了。”

最后送大家一句话：AI 写单测，你喝咖啡。测试全绿，准点下班。

评论区聊聊：你试过用 AI 写单测吗？有没有翻车？

兴业银行卡，如何无限额度结算 Google，apple 海外美金收益？

jiehuiV-heyu960812 — Thu, 14 May 2026 17:06:00 +0800

代练护航三角洲护航跑刀陪玩电竞代练代打小程序服务号系统，源码系统成品系统一次付费非租用

dkqqll — Thu, 14 May 2026 15:36:21 +0800

三角洲跑刀上分接单俱乐部下单代练护航系统（小程序 + 公众号 +APP）多端适配，是一套支持多类型用户、多领域应用且具备灵活支付功能的综合性代练管理系统。具体介绍如下：

用户类型与下单权限

平台客户：通过访问主页注册，下单时可选择所有平台下的打手指定下单。

工作室客户：通过工作室的二维码或链接注册，下单时只能选择该工作室下的打手，且只有工作室有管理订单的权限，平台客服无此权限。

下单流程

用户下单后，系统会分配打手，打手接单后需上传截图，最后由客服审核。

退款规则：打手未接单前，用户可自主申请退款；打手接单后，用户需联系客服协商退款，客服同意后可操作主动退单。

教程指南：

准备服务器：一般推荐 4 核 8G5M 的服务器，装 Centos 系统
备案域名：要企业认证且备案的域名才能使用

注意事项：

服务器要安装环境，Nginx 或者 Apache 请选择 PHP7.3 数据库 mysql5.6

要申请认证小程序，且备案；公众号也需要认证

申请商户号，用于收款，申请各个接口等。

游戏分类：后台添加设置游戏分类

点阵数显驱动 IC 数显驱动芯片 LED 控制器原厂 VK6932

18124687938 — Thu, 14 May 2026 14:55:43 +0800

一概述 VK6932 是一种数码管或点阵 LED 驱动控制专用芯片，内部集成有 3 线串行接口、数据锁存器、LED 驱动等电路。SEG 脚接 LED 阳极，GRID 脚接 LED 阴极，可支持 8SEGx16GRID 的点阵 LED 显示面板。主要应用于 LED 显示屏驱动。采用 SOP32 的封装形式 Z113+133

二特点 • 工作电压 3.0-5.5V

• 内置 RC 振荡器

• 8 个 SEG 脚，16 个 GRID 脚

• SEG 脚只能接 LED 阳极，GRID 脚只能接 LED 阴极

• 3 线串行接口

• 8 级整体亮度可调

• 内置显示 RAM 为 8x16 位

• 内置上电复位电路

• 封装 SOP32（21.00mm × 7.50mm PP=1.27mm) 三.

• 小家电

• 电磁炉/微波炉

• 压力表

静态显示存储器（RAM）结构为 8×16 位，存储所显示的数据。RAM 的内容直接映射成 LED 驱动器的显示内容，显示地址为 0xC0-0xCF，共 16 个显示单元。如果要打开/关闭某个 LED，只需把对应的显示 RAM 位置 1 或者清 0，例如控制 SEG1 脚和 GRID1 脚驱动的 LED1 亮灭，只需把对应的显示 RAM（地址 0xC0）的 bit0 位置 1 或者清 0。应用中没有使用的 SEG 脚对应的 RAM 位清 0。VK1637 3.0～5.5V 驱动点阵：48 共阴驱动：6 段 8 位共阳驱动：8 段 6 位通讯接口：CLK/DIO 静态电流/待机电流：--/-- 按键：8*2 封装：SOP20/DIP20

VK1616 3.0～5.5V 驱动点阵：28 共阴驱动：7 段 4 位共阳驱动：4 段 7 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：--- 封装：SOP16/DIP16 抗干扰能力强

VK1618 3.0～5.5V 驱动点阵：35/36/35/32 共阴驱动：5 段 7 位；6 段 6 位；7 段 5 位；8 段 4 位
共阳驱动：7 段 5 位；6 段 6 位；5 段 7 位；4 段 8 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：5*1 封装：SOP18/DIP18 抗干扰能力强

VK1620B 3.0～5.5V 驱动点阵：48/45/40 共阴驱动：8 段 6 位；9 段 5 位；10 段 4 位
共阳驱动：6 段 8 位；5 段 9 位；4 段 10 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：--- 封装：SOP20 抗干扰能力强

VK1624 3.0～5.5V 驱动点阵：77/72/65/56 共阴驱动：11 段 7 位；12 段 6 位；13 段 5 位；14 段 4 位
共阳驱动：7 段 11 位；6 段 12 位；5 段 13 位；4 段 14 通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：--- 封装：SOP24/DIP24 抗干扰能力强

VK1S68C 3.0～5.5V 驱动点阵：70/66/60/52 共阴驱动：10 段 7 位；11 段 6 位；12 段 5 位；13 段 4 位
共阳驱动：7 段 10 位；6 段 11 位；5 段 12 位；4 段 13 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：10*2 封装：SSOP24 抗干扰能力强

VK1Q68D 3.0～5.5V 驱动点阵：70/66/60/52 共阴驱动：10 段 7 位；11 段 6 位；12 段 5 位；13 段 4 位
共阳驱动：7 段 10 位；6 段 11 位；5 段 12 位；4 段 13 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：10*2 封装：QFN24 抗干扰能力强

VK1668 3.0～5.5V 驱动点阵：70/66/60/52 共阴驱动：10 段 7 位；11 段 6 位；12 段 5 位；13 段 4 位
共阳驱动：7 段 10 位；6 段 11 位；5 段 12 位；4 段 13 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：10*2 封装：SOP24/SSOP24 抗干扰能力强

VK1628 3.0～5.5V 驱动点阵：70/66/60/52 共阴驱动：10 段 7 位；11 段 6 位；12 段 5 位；13 段 4 位
共阳驱动：7 段 10 位；6 段 11 位；5 段 12 位；4 段 13 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜1mA/-- 按键：10*2 封装：SOP28 抗干扰能力强

VK1S38A 3.0～5.5V 驱动点阵：64 共阴驱动：8 段 8 位共阳驱动：8 段 8 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜5mA/-- 按键：8*3 封装：SSOP24 抗干扰能力强

VK1638 3.0～5.5V 驱动点阵：80 共阴驱动：10 段 8 位共阳驱动：8 段 10 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜5mA/-- 按键：8*3 封装：SOP28 抗干扰能力强

VK1629 3.0～5.5V 驱动点阵：128 共阴驱动：16 段 8 位共阳驱动：8 段 16 位通讯接口：CLK/STB/DIN/DOUT 静态电流/待机电流：＜5mA/-- 按键：8*4 封装：LQFP44(QFP44 正方形)；抗干扰能力强

VK1629A 3.0～5.5V 驱动点阵：128 共阴驱动：16 段 8 位共阳驱动：8 段 16 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜5mA/-- 按键：--- 封装：SOP32 抗干扰能力强

VK1629B 3.0～5.5V 驱动点阵：112 共阴驱动：14 段 8 位共阳驱动：8 段 14 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜5mA/-- 按键：8*2 封装：SOP32 抗干扰能力强

VK1629C 3.0～5.5V 驱动点阵：120 共阴驱动：15 段 8 位共阳驱动：8 段 15 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜5mA/-- 按键：8*1 封装：SOP32 抗干扰能力强

VK1629D 3.0～5.5V 驱动点阵：96 共阴驱动：12 段 8 位共阳驱动：8 段 12 位通讯接口：CLK/STB/DIO 静态电流/待机电流：＜5mA/-- 按键：8*4 封装：SOP32 抗干扰能力强

VK6932 3.0～5.5V 驱动点阵：128 共阴驱动：8 段 16 位共阳驱动：16 段 8 位通讯接口：CLK/STB/DIN 静态电流/待机电流：＜0.1mA/-- 按键：--- 封装：SOP32 抗干扰能力强

(永嘉微电/VINKA 原厂-FAE 技术支持，主营 LCD 驱动 IC； LED 驱动 IC；触摸 IC； LDO 稳压 IC；水位检测 IC)

LED 驱动、LED 屏驱动、数显驱动 IC、LED 芯片、LED 驱动器、数码管显示驱动、LED 显示驱动、LED 数显驱动原厂、LED 数显驱动芯片、LED 驱动 IC、点阵 LED 显示驱动、LED 屏驱动 IC、数显驱动芯片、数码管芯片、数码管驱动、数显屏驱动、数显 IC、数显芯片、数显驱动、LED 数显 IC、数显驱动原厂、LED 屏驱动芯片、LED 数显驱动 IC、LED 数显驱动 IC、LED 驱动电路、数显 LED 屏驱动、LED 数显屏驱动、LED 显示屏驱动、LED 数码管驱动、数显 LED 驱动、LED 数显驱动、数码管显示 IC、数码管显示芯片、数码管驱动芯片、LED 显示驱动芯片、显示数码管驱动、LED 控制电路、数显 LED 驱动芯片、数显 LED 驱动 IC、LED 驱动芯片、数码管显示屏驱动、数码管驱动原厂、LED 驱动厂家、LED 驱动原厂、LED 数码驱动、LED 数码屏驱动、LED 数显芯片、数码管驱动 IC、显示 LED 驱动、数码管 LED 驱动、LED 显示 IC、点阵数显驱动、点阵数码管驱动、点阵 LED 驱动、点阵数显驱动芯片、点阵数显驱动 IC、点阵 LED 驱动芯片、点阵 LED 驱动 IC、LED 数显原厂、点阵数码管显示芯片、数码管驱动厂家、数显 LED 原厂