w2solo - 独立开发者社区

我的 Chrome 插件月活从 0 到 8000，推广费为 0，分享我的五个野路子

freemanbrent40 — Tue, 23 Jun 2026 10:19:45 +0800

先交代背景：我做的是一个网页批注工具，功能很简单——在任意网页上高亮、记笔记，数据同步到 Notion。

2024 年 3 月上线，现在月活 8000，付费转化率 2.3%。没团队、没预算、没投广告。今天分享几个真正有用的冷启动方法，以及我踩过的坑。

野路子一：在目标用户扎堆的地方出现，而不是发广告

我的第一批用户来自 Reddit 的 r/Notion。但我没发推广帖，而是回答了一个问题："有没有办法在网页上高亮内容，自动同步到 Notion？"

我认真写了 500 字，说明为什么现有方案不好用，最后提了一句"我自己做了个工具，如果你愿意可以试试"。那个回答拿了 200 多赞，当天来了 300 多个安装。

关键是：先提供价值，再提产品。直接发链接会被删，但真诚回答问题不会。

野路子二：把用户反馈变成内容

有个用户在 Twitter 上吐槽："同步好慢啊"。我回复他："确实，我正在优化，预计下周发布。如果你愿意，我可以先给你发测试版。"

他同意了，测试后发了条 Tweet 说"开发者响应好快，问题解决了"。这条 Tweet 被转发了 30 多次，带来一波安装。

后来我养成了习惯：每次修复 bug 或发新功能，主动找之前抱怨过的用户试用。他们变成"自来水"的概率很高。

野路子三：蹭大事件的流量

Notion 有一次大更新，改了 API。很多第三方工具挂了，我的也差点挂。但我提前一周看到了预告，连夜适配，更新说明里写了"已适配 Notion 最新 API"。

那周搜索"Notion API update"的人暴增，我的插件因为关键词匹配，安装量翻了 3 倍。

野路子四：别忽视 Chrome 商店本身的优化

截图展示真实使用场景，不是 UI 截图。我第一张图是一个研究论文页面，上面有高亮和笔记，用户一眼就知道这工具是干嘛的

描述前两句包含核心关键词

回复每一条评论，哪怕只有"谢谢"。Chrome 商店算法奖励高互动率

我踩过最大的坑：过早收费

上线第一个月我就加了付费功能，结果付费用户没几个，免费用户因为功能限制给了很多差评。第二个月改成完全免费 + 捐赠，口碑回升，第三个月再推出 Pro 版，转化率反而更高。

独立开发者的信任积累很慢，先让用户爱上产品，再谈钱。

现在的困惑：

8000 月活卡了两个月了，自然增长见顶。我在考虑要不要试试 Google Ads，但听说插件类 ROI 很低。有没有做过付费推广的兄弟？求分享经验，或者还有其他野路子推荐吗？

三套方法论，10 个 AI 技能，我做了一个会自我进化的 Obsidian 知识库

sphinx30 — Mon, 22 Jun 2026 21:40:34 +0800

收藏夹吃灰、笔记找不到、灵感转眼忘——问题不是你不够努力，而是没有一套系统。

我花了两个月时间，把三套顶级方法论整合在一起，做了一个会自己整理的 Obsidian 知识库模板。

一套基于 PARA + Zettelkasten + LLM Wiki 三套方法论整合的知识管理系统。

三套方法论，各管一件事

方法论	提出者	管什么	核心理念
PARA	Tiago Forte	信息分类	按行动性分类，不是按主题
Zettelkasten	Niklas Luhmann	知识连接	卡片 + 链接，越积累越产生新洞见
LLM Wiki	Andrej Karpathy	自动维护	知识编译一次，持续更新

这套模板，就是把他们的方法整合在一起，让你直接用。

知识库的四层结构

大多数知识管理的失败，是因为「只存不流」。我设计了一套有流动方向的四层结构：

┌─────────────────────────────────────────────────────────┐
│  输入层：原始资料（外部输入，不可变）                       │
├─────────────────────────────────────────────────────────┤
│  中间层：Wiki（LLM 提炼，可查询）                         │
├─────────────────────────────────────────────────────────┤
│  输出层：项目（你的作品：视频、文章、产品）                 │
├─────────────────────────────────────────────────────────┤
│  沉淀层：领域（你的方法论、经验、指南）                     │
└─────────────────────────────────────────────────────────┘

知识怎么流动？

外部世界
  ↓
原始资料（网页剪藏、文章、论文）—— 不可变
  ↓ /ingest 技能
Wiki（LLM 自动维护）—— 结构化、可查询
  ↓
  ├→ 你查询 → 直接使用
  ├→ 沉淀到 领域 → 你的方法论
  └→ 输出到 项目 → 视频、文章

关键区别：Wiki 是「别人的知识」，领域是「你的知识」。 从 Wiki 到领域，不是复制，而是重新写——加入你的理解、你的应用、你的经验。

每个目录的职责

目录	本质	谁写	谁读	类比
灵感库	碎片想法	你	LLM	便利贴
原始资料	外部输入	你放	LLM	文件柜
Wiki	结构化知识	LLM	你	图书馆
领域	你的方法论	你 +LLM	你	笔记本
参考资料	外部原始资料	你 +LLM	你	资料夹
项目	具体任务	你 +LLM	你	任务清单
归档	已完成内容	自动	你	档案室

PARA：按行动性分类

PARA 的核心不是按主题分类，而是按行动性分类：

分类	含义	特征	举例
Projects	项目	有截止日期，做完就结束	这期视频、这次活动
Areas	领域	长期维护，没有终点	内容创作、客户服务
Resources	资源	外部资料，可能有用	官方文档、别人教程
Archive	归档	不再活跃，保留记录	完成的项目、过时资料

三个原则：

按行动性分类，不是按主题
定期流动，项目完成 → 归档
领域只放自己的，参考资料放外部的

Zettelkasten：卡片 + 链接

Zettelkasten 的核心是原子化 + 链接。每个想法写成一张独立卡片，用 [[]] 把相关卡片串起来。

三种卡片类型：

类型	说明	举例
闪念卡	突然想到的碎片	灵感库里的内容
洞见卡	经过思考的结论	某个方法论的核心观点
文献卡	从外部摘录的内容	读书笔记、文章摘录

链接原则：不要只链接「相关的」，要链接「能产生新想法的」。一张卡片至少链接 2 张其他卡片。

LLM Wiki：让 AI 帮你维护

传统 RAG 每次提问都从原始文档重新检索，没有积累。LLM Wiki 的核心区别是：知识编译一次，持续更新。

传统 RAG：  原始文档 → 每次重新检索 → 回答（无积累）
LLM Wiki：  原始文档 → LLM 编译成 wiki → 持续更新 → 回答（有积累）

三层架构：

层级	说明	谁负责
Raw Sources	原始资料（文章、论文、图片、数据）	你（不可变，只读）
The Wiki	LLM 生成的 markdown 文件	LLM（创建、更新、维护）
The Schema	配置文件（如 CLAUDE.md）	你和 LLM 共同演化

三个核心操作：

操作	功能
Ingest	处理新来源 → 提取关键信息 → 整合到现有 wiki
Query	基于 wiki 回答问题，有价值的写回 wiki
Lint	定期健康检查：矛盾、过时、孤儿页面

10 个 AI 自动化技能

技能	命令	功能
知识卡片	`/card`	灵感/口播 → 结构化卡片（钩子 + 痛点 + 方案 + 金句）
卡片可视化	`/card-picture`	文字 → 学术风格信息图
视频脚本	`/card-video`	卡片 → 口播逐字稿
摄入	`/ingest`	新文章/论文 → 自动整合到 wiki
查询	`/query`	基于 wiki 回答问题，有价值的写回 wiki
健康检查	`/lint`	扫描矛盾、孤儿页面、过时内容
项目管理	`/project`	创建项目、更新进度
每日复盘	`/daily`	扫描灵感库、检查进度、输出报告
发布	`/publish`	生成封面标题、发布标题、标签
归档	`/archive`	自动归档已完成项目

五套模板

模板	用途
视频脚本模板	封面标题、发布标题、标签、状态
知识卡片模板	来源、关联卡片
项目模板	截止日期、任务清单
文章模板	平台、阅读量
学习笔记模板	来源、学习时长

实际工作流

场景 1：看到一篇好文章

1. 剪藏到 原始资料/文章/
2. /ingest → Wiki 自动生成结构化页面
3. 有问题 → /query → 从 Wiki 中找答案
4. 有价值 → 沉淀到 领域/
5. 要做内容 → 调用 Wiki 和领域 → 输出到 项目/

场景 2：突然有个灵感

1. 语音转文字，记录到 灵感库/
2. /card → 生成钩子+痛点+方案+金句
3. /card-picture → 自动生成可视化配图
4. /card-video → 自动转成口播逐字稿
5. /publish → 自动生成标题和标签
6. 录制视频，发布，归档

场景 3：读一本书

1. 记录读书笔记到 参考资料/
2. 提炼方法论，沉淀到 领域/
3. /card 生成视频脚本
4. 录制视频，发布，归档

场景 4：每日复盘

/daily
  ↓ 自动扫描灵感库、项目进度、wiki 健康
  ↓ 输出复盘报告 + 建议行动

设计原则

先捕捉，后整理 — 不要让灵感溜走
用自己的话 — 不要只是摘抄
定期回顾 — 发现新的链接和洞见
输出倒逼输入 — 写作是最好的学习

适合谁？

✅ 内容创作者（视频、文章、课程）
✅ 知识工作者（需要管理大量信息）
✅ 终身学习者（读书、学课程）
✅ 想用 AI 提升效率的人
❌ 纯轻量笔记需求（备忘录就够了）

总结

这套知识库的核心就一句话：

你只管输入，系统帮你输出。

灵感不丢失，知识有连接，AI 帮整理，输出更高效。

以上，既然看到这里了，如果对你有所帮助，还望不吝点赞与关注，这也是对我最大的鼓励与支持。

感谢你拨冗阅读，山高水长，我们期待下篇文章与你再见。

>/ 更多 Agent 实战干货迎访问我的博客：dqtx.cc

文章来源：点此查看

AI 生成的代码能跑就行？这 5 个坑迟早炸

193577746 — Mon, 22 Jun 2026 18:36:40 +0800

AI 写代码的效率毋庸置疑，但"能跑"和"能维护"之间隔了一道鸿沟。这篇文章总结了 AI 生成代码最常见的 5 个质量问题，每个都附反面案例和修复方案，最后给出一份 5 条验收 checklist。

2026 年了，AI 写代码已经不是新鲜事。但我发现一个普遍现象：很多人的工作流是——

让 AI 生成代码
能跑就提交
出了 bug 再让 AI 修

这个循环看似高效，实际上在代码仓库里埋了一堆定时炸弹。下面是我 review AI 代码时反复遇到的 5 个问题，从高频到低频排列。

第一坑：过度工程化——3 行能解决的事写了 30 行

AI 特别喜欢上设计模式。你让它写一个"判断用户是否登录"的函数，它能给你整出工厂模式 + 策略模式 + 抽象基类：

// AuthStrategyFactory.js
class AuthStrategyFactory {
  static createStrategy(type) {
    const strategies = {
      jwt: new JwtAuthStrategy(),
      session: new SessionAuthStrategy(),
      oauth: new OAuthStrategy(),
    };
    return strategies[type] || new JwtAuthStrategy();
  }
}

// JwtAuthStrategy.js
class JwtAuthStrategy extends BaseAuthStrategy {
  validate(context) {
    const token = context.getToken();
    const decoder = new TokenDecoder(this.config);
    const result = decoder.decode(token);
    if (!result.isValid) {
      return AuthResult.failure(AuthErrorCode.INVALID_TOKEN);
    }
    return AuthResult.success(result.payload);
  }
}

// 另外还有：BaseAuthStrategy.js、TokenDecoder.js、AuthResult.js、AuthErrorCode.js

6 个文件，200 多行，就为了判断用户有没有登录。而这个项目从头到尾只用了 JWT 一种方式，不可能有 session 和 OAuth。

实际需要的代码：

export function checkAuth() {
  const token = localStorage.getItem('token');
  if (!token) {
    window.location.href = '/login';
    return false;
  }
  try {
    const payload = JSON.parse(atob(token.split('.')[1]));
    return payload.exp * 1000 > Date.now();
  } catch {
    localStorage.removeItem('token');
    window.location.href = '/login';
    return false;
  }
}

一个文件，15 行，功能完全一样。

为什么会这样： AI 倾向于"展示它知道的所有设计模式"，而不是"用最简单的方式解决问题"。它没有偷懒的本能，而偷懒有时候是好事——逼你写出最简方案。

怎么防： 拿到 AI 代码先问自己——"删掉一半代码还能跑吗？"如果能，那删掉的就是过度设计。

第二坑：幽灵代码——大量函数从未被调用

让 AI 写一个"订单模块的工具函数"，它会把所有它能想到的都给你：

// utils/orderHelpers.js

export function calculateOrderDiscount(order, discountRules, userLevel) {
  // ... 45 行折扣计算逻辑
}

export function formatOrderForExport(orders, format = 'csv') {
  // ... 60 行导出格式化逻辑
}

export function validateOrderTransition(currentStatus, targetStatus) {
  // ... 30 行状态机校验
}

写得都挺好，逻辑也对。但问题是——项目根本没有折扣功能，没有导出功能，状态机也没用到。

这些就是"幽灵代码"：活在仓库里，从未被执行，但你维护的时候会把它们当成有用的代码去读、去理解。实际有效代码 5000 行的模块，可能躺了 3000 行死代码。

为什么会这样： AI 不知道 YAGNI（You Ain't Gonna Need It）。它基于"这个场景可能需要什么"生成代码，而不是"现在到底需要什么"。

怎么防： 前端用 knip 检测，比 depcheck 更准：

npx knip --include exports

一条命令揪出所有未被使用的导出函数、类型、组件。

第三坑：假注释——注释和代码说的不是同一件事

这个坑最阴，因为你只看注释的话，逻辑是通的：

// 检查用户是否有该订单的操作权限
async function checkOrderPermission(userId, orderId) {
  const order = await db.orders.findById(orderId);
  const formattedOrder = {
    ...order,
    createdAt: dayjs(order.createdAt).format('YYYY-MM-DD'),
    updatedAt: dayjs(order.updatedAt).format('YYYY-MM-DD'),
    items: order.items.map(item => ({
      ...item,
      price: (item.price / 100).toFixed(2),
    })),
  };
  return formattedOrder;
}

注释说"检查权限"，代码在做数据格式化。返回值不是 boolean，是一个格式化后的对象。

调用方写成了这样：

const order = await checkOrderPermission(userId, orderId);
if (!order) throw new Error('无权限');

恰好，当 orderId 不存在时 findById 返回 null，!null === true，所以"权限检查"碰巧能跑。纯属巧合。

为什么会这样： AI 先生成了一个权限检查函数，后来被要求加数据格式化逻辑，改了函数体但没改函数名和注释。这种"假注释"比没注释更危险——没注释你会认真读代码，有注释你会下意识信任它，跳过代码。

怎么防： 好的代码不需要注释。与其修注释，不如改函数名——checkOrderPermission 改成 formatOrderForDisplay，删掉注释，可读性反而更高。

第四坑：万能 try-catch——出了 bug 永远定位不到

AI 特别喜欢给每个函数都包一层 try-catch：

async function createOrder(params) {
  try {
    const validated = validateParams(params);
    const order = await db.orders.create(validated);
    await notifyUser(order);
    await updateInventory(order);
    return order;
  } catch (error) {
    console.log('Error in createOrder:', error);
    return null;
  }
}

async function validateParams(params) {
  try {
    // ... 校验逻辑
  } catch (error) {
    console.log('Error in validateParams:', error);
    return null;
  }
}

每一层都默默吞掉错误，打个 console.log 就完事。

结果：线上出 bug，Sentry 里只有 "Error in createOrder: null"。是创建失败了？通知失败了？库存扣减失败了？你不知道。所有上下文都被 catch 吃掉了。

更要命的是 return null。调用方拿到 null 以为"没有订单"，继续往下跑，导致后面一连串空指针。一个本该在源头暴露的错误，被层层掩盖，最后在距离原始问题八百里远的地方炸出来。

正确做法：错误冒泡，只在边界捕获。

async function createOrder(params) {
  const validated = validateParams(params); // 校验失败直接抛
  const order = await db.orders.create(validated); // 数据库错误直接抛

  // 只有不影响主流程的旁路操作才 try-catch
  try {
    await notifyUser(order);
  } catch (error) {
    logger.warn('通知发送失败，不影响订单创建', { orderId: order.id, error });
  }

  return order;
}

为什么会这样： AI 出于"安全感"给每个函数加 try-catch——它不想让任何错误导致程序崩溃。但过度防御恰恰让 debug 变成噩梦。错误处理不是越多越好，是在正确的位置处理。

第五坑：data、data2、data3——变量名丢失业务语义

这个问题随处可见：

async function handleSubmit() {
  const data = await fetchData();
  const data2 = processData(data);
  const data3 = data2.filter(item => item.status === 'active');
  const result = await submitData(data3);

  if (result.code === 0) {
    const data4 = result.data;
    setList(data4);
  }
}

读到 data3 的时候你已经忘了 data 是什么了。对比一下：

async function handleSubmit() {
  const allOrders = await fetchOrders();
  const formattedOrders = formatForDisplay(allOrders);
  const activeOrders = formattedOrders.filter(order => order.status === 'active');
  const submitResult = await submitOrders(activeOrders);

  if (submitResult.code === 0) {
    setOrderList(submitResult.data);
  }
}

一眼就知道每一步在做什么。

另一个变种更常见：

const res = await api.get('/orders');
const res2 = await api.get('/users');
const res3 = await api.get(`/orders/${res.data[0].id}/items`);

三个完全不同的接口，返回值都叫 res。改 bug 的时候搜 res，搜出来 47 个结果，祝你好运。

为什么会这样： AI 在生成整段代码时倾向于用通用名词。data 是最安全的命名——不会出错，但也不传达任何信息。它没有你的业务上下文，不知道 data 其实是"订单列表"。

怎么防： AI 生成代码后，第一件事搜 data、res、result、temp、item，全部改成业务名词。

AI 代码验收 Checklist

以上 5 个坑归结起来，就是一句话：AI 的代码和实习生的代码一样，能跑但需要 review。

每次 AI 生成代码后，花 5 分钟过一遍：

#	检查项	怎么查
1	删减测试	删掉一半代码还能跑吗？能跑的就是过度设计
2	死代码检测	跑 `npx knip --include exports`
3	注释一致性	每条注释和代码对一下，不确定就删注释
4	错误处理	搜 `catch`，是不是只有 `console.log`？该冒泡还是该吞？
5	命名审查	搜 `data`/`res`/`result`/`temp`，全改成业务名词

5 分钟能省你三天的 debug 时间。

你在 review AI 代码时踩到过什么坑？评论区聊聊。

Square face generator

Harlan — Mon, 22 Jun 2026 17:45:49 +0800

一个好玩的头像生成器，欢迎使用： https://square-faces.com

纵马赴夏日，豪礼皆自达影帝梁家辉实力背书 EZ-60 马年版上市 EZ-6 超级置换季开启

yuanguanhua — Mon, 22 Jun 2026 17:28:44 +0800

纵马赴夏日，豪礼皆自达。即日起至2026年5月31日，长安马自达继续加码全系车型购车礼遇。MAZDA EZ-60（以下称 EZ-60）马年版领衔登场，售价 13.99 万起，全系车型至高可享 23,000 元购车权益，进店试驾即赠国家非遗金陵金箔。MAZDA EZ-6（以下称 EZ-6）限时超级置换季开启，至高可享 17,000 元置换厂补和 20,000 元以旧换新国补。

EZ-60 马年版：千面影帝梁家辉实力背书合资新能源 SUV 最优选

作为连续 6 个月蝉联合资新能源中型 SUV 销量冠军的全球车型，EZ-60 持续优化产品阵容，马年版车型在北京车展正式上市，以增程 200 马年版 13.99 万元、纯电 600 马年版 14.59 万元的诚意定价，成为五一小长假自驾、露营、跨城出游的座驾最优选。活动期间，EZ-60 全系车型在至高 20,000 元以旧换新国补基础上，叠加 6 重专属购车礼遇：

置换礼：至高可享 7,000 元置换厂补；
拥车礼：免费赠送价值 950 元交强险；
自燃包赔礼：赠送价值 7,999 元终身零燃权益，不限车主、不限里程；
畅充礼：免费赠送价值 3,999 元原厂充电桩；
升级礼：免费赠送 3,000 元专属选装基金；
金融礼：支持 0 首付 5 年低息购车方案，年均费率低至 1.99%。

作为全球唯一同时斩获德国 iF、美国 IDA 等 7 项国际顶级设计大奖的新能源 SUV，EZ-60 马年版完整传承了车型硬核实力，更精准响应马粉需求：开放原顶配车型专属紫色内饰选装，满足个性化定制需求；标志性 9 风道空气动力学设计，兼顾魂动美学与空气动力学性能，高速自驾时车身更稳；2,902mm 超长轴距带来宽绰车内空间，轻松容纳全套露营装备、婴儿车与多件行李箱，后排座椅放倒秒变 2 米纯平大床，景区游玩间隙随时躺平休息；中日德三国四地工程师联合调校，搭配 “人马一体” 的精准操控，无论是高速、山路，还是非铺装路面，都能带来从容稳定的驾乘体验，更有马自达独家 “不晕车” 黑科技，老人孩子长途乘坐也能全程舒适。

EZ-6：限时超级置换季开启至高享 17000 元置换厂补 +20000 元国补

作为斩获 “2026 世界年度设计车大奖” 的全球战略车型，同时也是首款达成全球主流安全认证大满贯的合资新能源轿车，EZ-6 自上市以来便树立了合资新能源 B 级轿车价值标杆。电感「人马一体」的调校，精准复刻马自达标志性线性加速与弯道操控，兼顾舒适家用和操控乐趣；越级的车身尺寸与宽绰座舱，兼顾前排驾驶体验与后排乘坐舒适性，出行久坐不累，更有母婴级环保座舱材质，新车无异味，全家出行更安心。活动期间，进店试驾 EZ-6 即可获赠国家非遗金陵金箔，更有多重购车权益，全方位降低用户购车与用车门槛：

限时超级置换季：至高 17,000 元置换厂补，至高 20,000 元以旧换新国补；
拥车礼：免费赠送价值 3999 元原厂充电桩 + 价值 950 元交强险；
金融权益礼：支持 0 首付 5 年低息购车方案，年均费率低至 1.99%；
自燃包赔礼：赠送价值 7,999 元终身零燃权益，不限车主、不限里程。

CX-50 行也：焕新一口价 13.98 万起至高享 21,000 元补贴

“山系生活宽体 SUV” CX-50 行也，天生适配户外出行生活方式，完美契合当代家庭 “城市通勤 + 户外旅行” 的多元出行需求。4785mm 越级车长搭配宽体车身设计，带来远超同级的车内空间与后备箱容积，帐篷、天幕、折叠桌椅、山地自行车等户外装备均可轻松收纳；高离地间隙搭配专业级底盘调校，城市铺装路面、乡间非铺装小路、山野轻度穿越路况皆可从容应对，带你解锁更多小众风景。活动期间，CX-50 行也焕新一口价 13.98 万元起，叠加 6,000 元置换厂补与至高 15,000 元以旧换新国补，综合补贴可达 21,000 元。

与此同时，长安马自达多款经典燃油产品同步奉上五一专属福利，全面覆盖不同用户的出行需求：

次世代 MAZDA 3 昂克赛拉：全系 8.99 万起，购车可享至高 14,000 元以旧换新国补，灵活好开、油耗经济，是年轻群体城市通勤、假日出游的乐趣之选；

MAZDA CX-5：限时 11.58 万起，至高可享 15,000 元以旧换新国补与 6,000 元置换厂补，全球超 400 万用户口碑背书，兼顾家用舒适与操控乐趣，全家出行无压力；

MAZDA CX-30：全系 9.99 万起，叠加至高 14,000 元以旧换新国补，潮酷造型灵动小巧，城市打卡、山路自驾都能轻松驾驭，是自驾出行的个性之选。

即日起，可前往长安马自达全国授权经销商门店，或通过 “悦马星空” APP、官方小程序查询政策详情、预约试驾及预订新车。无论是燃油车时代，还是新能源时代，长安马自达将持续以全球顶级的安全品质、越级的产品实力与诚意满满的福利政策，携手每一位用户，在马年开启更多美好出行新旅程。

怎么做三角洲电竞代练护航陪玩小程序？全面介绍系统功能和搭建准备流程

dkrjkf — Mon, 22 Jun 2026 14:43:48 +0800

面对 “三角洲行动” 催生的刚性护航需求，成熟的技术方案可在 48 小时内上线全流程陪玩小程序。技术生态已高度成熟，市面上存在商用级护航小程序系统源码，采用 ThinkPHP6+MySQL5.6 后端、Uniapp+Vue2 前端、自研 WorkermanIM 引擎实现毫秒级消息推送，独立部署兼容阿里云、腾讯云。系统覆盖用户、店员、客服、工作室、管理后台五端，包含发单、派单、结算、评价等全流程闭环。建议先以小程序跑通获客→下单→服务→复购流程，前端页面展示老板端/下单：极速下单选择游戏品类、大神、规格并支付，需求发布客服智能匹配派单，大神列表多维度筛选，钱包充值支持微信/支付宝，评价系统积累口碑，退款申请一键发起，转盘抽奖增加趣味性，老客一键填单。店员/客服端支持三模式接单、多品类独立开关、等级认证、保证金管理、收益明细。搭建需准备营业执照、法人信息、对公账户、邮箱手机号等资质，及服务器、域名、服务号、小程序等第三方产品，安装后端并打包前端，申请接口调试参数，申请服务号备案小程序，后台完善参数上传审核。核心适配电竞服务、游戏工作室、陪玩行业，延伸适配游戏博主私域变现、综合数字平台增值服务，支持段位提升、代肝任务等游戏增值服务。技术生态层面系统方案已高度成熟。目前市面上已有多套商用级护航小程序系统源码，技术栈普遍采用：

后端：ThinkPHP 6 + MySQL 5.6，支持高并发

前端：Uniapp + Vue2，一套代码编译微信小程序、H5、iOS/Android APP 多端

即时通讯：自研 Workerman IM 引擎，零成本实现毫秒级消息推送

部署方式：独立部署，兼容阿里云、腾讯云，48 小时内可上线

功能体系完善。成熟的系统已覆盖用户端、店员端、客服端、工作室端、管理后台五端协同，包含快速发单、智能/自选派单、订单流转、自动结算、车队单分成、保证金体系、评价投诉、售后退款等全流程闭环。

如果你正在考虑入局这个赛道，建议先以小程序跑通"获客→下单→服务→复购"

老板端/下单

✅ 极速下单选择游戏品类 → 选大神 → 选规格 → 支付，最快 3 步完成下单

✅ 需求发布填写段位/声音/性别等需求，客服智能匹配后派单

✅ 大神列表筛选按性别、等级、价格、关注多维度筛选，快速找到合适大神

✅ 钱包充值支持微信/支付宝充值，余额明细、消费记录实时查询

✅ 评价系统服务结束后打分、文字评价，帮助平台积累口碑

✅ 退款申请订单页一键发起退款，上传凭证，实时查看审核进度

✅ 转盘抽奖购买带抽奖的订单后，可在订单页参与幸运转盘

✅ 老客一键填单再次下单时自动读取上次订单的游戏昵称/ID/大区/联系方式，一键填入

高效下单，灵活选服老板可快速筛选热门游戏类目，按需选择服务模式 —— 支持指定心仪打手、等待打手抢单或由平台客服专业派单，无需繁琐操作，3 步即可完成下单，精准匹配游戏需求。

店员 /客服端

⭐ 三模式接单选人下单 + 抢单（主动抢）+ 客服派单，三种模式并行不干扰

✅ 多品类独立开关王者/吃鸡/LOL 等游戏卡片式开关，一个账号可同时开启多个品类接单

✅ 等级认证与主页店员等级标识、个人主页背景图、动态帖子，打造专属人设

✅ 接单开关一键在线/隐身，不影响已接订单继续执行

✅ 保证金管理查看保证金余额、主动缴纳、查看扣缴记录

✅ 收益明细每笔订单收益、佣金、提现记录一目了然

✅ 流程建议只需接单 - 服务 - 上传完成截图

如何搭建护航陪玩小程序平台？需要准备：

一、需要资质

1.营业执照：个体户和企业执照都行，主要用于各种认证和小程序服务号及域名的备案等

2.法人信息：认证信息需要

3.对公账户：企业执照需要对公账户，个体户可用法人的银行卡；申请微信商户号用于平台收款

4.邮箱、手机号：申请各个平台的账号和登录

二、需要第三方产品

1.服务器：安装承载系统的运行

2.域名：需备案，用于访问系统

3.服务号、小程序：都需要认证，且小程序要备案

三、源码系统后端源码：Thinkphp6

前端源码： UNI-APPvue2.0（支持一键式发布 H5、微信小程序、安卓/iOS 苹果 app）

宝塔：安装后台、管理网站

搭建流程和上线步骤：

1.获取源码（源码交付、永久域名授权/非租用版）

2.安装后端并打包前端（H5+ 小程序 +APP）

3.申请接口并调试参数（商户号）

4.申请服务号、备案小程序

5.后台填写并完善各个参数

6.上传小程序进行审核

推荐源码

核心适配行业（游戏服务相关匹配的领域）：

1.FPS 或竞技网游陪玩、护航、代肝的电竞服务行业，

2.管理私域订单和打手团队的游戏工作室，

3.提供上分陪玩等服务的电竞陪玩行业，

4.淘宝拼多多上的游戏代练电商店铺；

延伸适配行业 (可拓展使用该系统的领域)：

1.游戏博主用它实现粉丝私域变现，

2.综合数字平台增加游戏增值服务类目，

3.创业团队快速搭建游戏服务平台；

适配业务类型 (系统能支持的具体服务内容)：

1.包括段位提升、代肝任务、游戏护航、陪玩等标准化或定制化的游戏增值服务。

明确系统的目标用户和应用场景，旨在帮助不同类型的运营者判断是否适合使用该系统。

做了个免费 AI 图片去字工具：PicTextRemover，也能顺手去水印和去杂物

xuseen — Mon, 22 Jun 2026 13:56:25 +0800

最近把 PicTextRemover 主站重新整理了一下，核心还是做 “图片里的字干净去掉”，适合处理截图标题、海报文案、商品图标签、旧活动字样这些场景。

我自己最在意的是别把背景抹糊，所以现在的思路是：先手动涂抹要去掉的区域，再让 AI 做局部重建，尽量把周围纹理、边缘和光影接回来。

现在主要有 3 个入口：

PicTextRemover：偏通用的图片去字 / 去说明文字
Watermark Remover：更适合去水印、logo、印章
Object Remover：更适合去路人、杂物、穿帮元素

比较适合的图：

商品图和详情图
截图里的字幕、标签、时间字样
海报和社媒图上的旧文案
想复用但被水印或小杂物影响的图片

目前是免费可用版本，想先多收一些真实反馈，尤其想听听大家对下面两点的看法：

去字时你更在意 “干净”，还是更在意 “速度”？
你们最常见的图片清理场景是什么？

如果你愿意试试，欢迎直接拍砖。

KidoX, 一个开源的 macOS Launchpad 替代 App

defcc — Mon, 22 Jun 2026 13:14:30 +0800

最近升级 macOS Tahoe 后，一切都感觉挺好的，最不适应的是 Launchpad 没了，取而代之的是一个不可拖动、窗口大小也不能调整的 Apps 窗口。

所以我做了一个叫 KidoX 的小工具，目标是尽量还原一个更好用的 Launchpad：可以快速打开应用、整理应用、隐藏不常用应用，也支持一些外观和交互设置。

目前第一个版本已经基本可用。

网站： https://kidox.app

源码： https://github.com/defcc/kidox.app

源码是公开的，你可以自己 build 使用，完全免费。如果不想自己构建，也可以直接从网站下载已经打包好的安装包。

欢迎大家试用，也欢迎提 issue / PR 。

Telegram 登录验证机制的技术观察：多通道容错设计与 +86 号码的实践记录

quyb63232 — Mon, 22 Jun 2026 10:11:09 +0800

最近在研究即时通讯产品的登录流程，Telegram 的验证机制有一些值得记录的细节。这篇算是技术笔记，分享给有同样兴趣的开发者。

一、Telegram 的验证通道架构

Telegram 的登录流程在简洁的 UI 之下，其实实现了一个多通道容错的验证系统。作为开发者，拆解一下它的设计思路：

通道 1：SMS 验证码

默认路径，依赖运营商 SMS 网关

在部分场景下（漫游、运营商策略限制）存在送达率问题

通道 2：语音验证码（Voice Call）

在 SMS 等待界面提供 fallback 选项

系统主动呼入语音电话，自动播报验证码

实测在 Android 和 iOS 上实现一致，送达率高于 SMS

通道 3：已登录设备授权

利用现有登录设备作为"信任锚点"

新设备请求验证时，已登录设备推送确认通知

完全绕过手机号接收环节，适合多设备开发者场景

通道 4：桌面端先行 + 移动端扫码

桌面端（Telegram Desktop）完成登录

移动端通过二维码扫描接入

对于频繁切换测试设备的开发者，这是最顺畅的路径

二、+86 号码的实测记录

我的账号绑定的是 +86 号码，用了比较长时间。

差异主要与运营商层面的策略有关，而非 Telegram 服务端的问题。

三、对独立开发者的启发

Telegram 的登录设计有几个值得借鉴的点：

多通道降级策略

不要假设单一路径永远可用。SMS、语音、设备授权三条路径互为 backup，任何一条通畅就能完成验证。这种设计思路在产品架构中很有参考价值——尤其是当你的产品依赖第三方服务（如短信服务商、支付网关）时。

信任链的渐进式构建

已登录设备成为后续设备的信任基础，减少了重复验证成本。类似的设计可以应用在多设备同步、会话管理等功能中。

跨平台一致性

Android 和 iOS 的登录流程几乎完全一致，背后是协议层的统一设计。对于需要同时维护多端的独立开发者来说，这种"协议先行、UI 跟随"的思路能减少很多适配成本。

四、结语这篇没有"教程"的野心，只是记录了一个开发者在使用 Telegram 过程中观察到的一些技术细节。如果你也研究过其他 IM 产品的登录机制（比如 Signal、WhatsApp 的设计差异），欢迎在评论区交流。

我会把我的登录方法分享在评论区，大家可以去试试，然后即可一起讨论他的登录流程~

【限时福利免费试用】动态住宅低至 0.5$/GB 静态 ISP 低至 3.8$/条

Novproxy6 — Mon, 22 Jun 2026 10:08:50 +0800

海外公司注册前，建议先想清楚这几个问题

api_to_inc — Mon, 22 Jun 2026 09:18:14 +0800

很多客户一开始咨询海外公司注册时，都会先问：

注册哪里比较好？
香港公司好还是新加坡公司好？
岛屿公司是不是更方便？

其实在回答这些问题之前，更建议先想清楚 “公司准备用来做什么”。

因为海外公司不是注册完就结束了，后续还涉及年审、审计、开户、维护、税务申报、知识产权归属等问题。

注册前可以先确认几个问题：

公司主要用途是什么？
是跨境业务、海外客户签约、品牌出海，还是架构安排？
是否需要银行账户？
如果需要开户，要提前了解账户维护和资料要求。
是否需要长期使用？
如果只是短期试水，要考虑后续维护成本。
是否涉及知识产权？
比如商标、专利、版权是否需要用公司名义申请。
是否能接受后续维护？
不同国家和地区，对年审、审计、报税的要求不同。
如果公司不用了，是否知道如何处理？
很多公司不是 “不用了就放着”，后续可能还需要正常注销。

常见海外公司包括香港公司、新加坡公司、BVI、开曼、塞舌尔等。不同主体没有绝对好坏，主要看实际用途和后续维护需求。

我所在公司主要做海外/离岸公司注册、公司开户协助、年审审计、全球知识产权注册等基础服务，已有多年行业经验。我们不介入客户具体业务操作，但可以协助客户完成主体搭建和后续维护。

如果大家对某类主体感兴趣，比如香港公司、新加坡公司、岛屿公司，也可以后续单独聊聊它们各自适合的情况。

如何快速制作高考班级毕业去向分布图

huayemao — Sun, 21 Jun 2026 15:46:12 +0800

高考已经落下帷幕，在 6 月 23 日全国各省就将陆续迎来出分、报志愿和录取... 在这少年各赴山海之际，如何用一张毕业去向分布图，留住全班奔赴各地的温柔印记？

今天给大家介绍我打造的这款毕业蹭饭图快速制作工具。不需要任何专业设计，轻松在线操作，就能生成一张专属班级的毕业去向分布图。

打开 china edu atlas 高校名录数据可视化平台，点击进入毕业去向分布图制作工具
在标题设置中修改地图标题，如"师大附中 2026 届 5 班毕业去向分布图"
点左上角进入数据选项卡，清除预置数据
手动输入班级内的学生录取院校信息，也可以根据固定格式的 excel 模板，一键导入 excel 表格。
自由挑选喜欢的样式与配色：数据录入完成后，可切换到样式 Tab ，调整布局风格、配色组合、字体配置、其他布局参数等。
导出图片：点击右上角的【导出高清图】按钮导出制作好的班级毕业去向图。或者也可直接截图保存。

Codex App 接上微信，我开始在厕所里改 Bug 了

sphinx30 — Sun, 21 Jun 2026 15:28:09 +0800

这两天折腾了一个挺有意思的东西：

把个人微信接到 Codex 上。

以后不用一直坐在电脑前开着 Codex APP。人在外面，手机微信里发一句话，家里或办公室那台电脑上的 Codex 就能收到任务，继续帮你改代码、查项目、跑命令、整理文件。

项目地址 https://github.com/Gan-Xing/CodexBridge

它做的事情很直接：把微信消息转成 Codex 能处理的请求，再把 Codex 的回复发回微信。

简单理解就是：

个人微信 -> CodexBridge -> 本机 Codex -> CodexBridge -> 个人微信

Codex 还是跑在你的电脑上，项目文件也还是在你的电脑上。微信只是多了一个远程入口。

最简单的接入方式

如果你已经安装好了 Codex APP，可以直接把下面这句话发给 Codex：

https://github.com/Gan-Xing/CodexBridge 帮我对接个人微信

Codex 会自动处理后面的流程：克隆项目、安装依赖、检查环境、生成二维码、等待扫码、启动桥接服务。

扫码登录

依赖安装完之后，它会给你一个二维码。

用个人微信扫一下，然后在手机上确认登录就行。

这里注意一点：二维码有效期比较短。如果提示「二维码已过期」，让 Codex 重新生成一张再扫，不用纠结。

成功后怎么测试

扫码成功后，本机会生成微信账号凭证，通常在：

C:\Users\你的用户名\.codexbridge\weixin\accounts\

Windows 上还可以注册成计划任务，任务名一般是：

CodexBridge-Weixin

这样以后登录 Windows，它会自动启动。

接入成功后，打开微信，给桥接会话发：

/h

或者：

/status

如果能收到回复，说明链路已经通了。

后面就可以直接发自然语言任务，比如：

帮我看一下 D:\project2026\fuwari 这个项目最近有哪些改动，整理成一段提交说明。

常用命令

命令	作用
`/h`	查看帮助
`/status`	查看当前桥接状态
`/new 路径`	切换到新的项目目录
`/threads`	查看历史线程
`/open 2`	打开某个历史线程
`/stop`	停止当前正在跑的任务
`/retry`	重试上一条请求

日常远程使用，先记住这几个就够了。

几个注意点

一、Windows 脚本路径可能要改

项目自带的 .cmd 里可能写着作者自己的电脑路径，需要改成你本机的 Codex 路径和工作目录。

比如：

D:\software\Codex\app\resources\codex.exe
D:\zed-workspace

如果你是让 Codex 自动接入，它一般会自己检查并替你改掉。

二、二维码过期很正常

看到二维码就马上扫。过期了就重新生成。

三、电脑要保持在线

这个桥接不是云服务。CodexBridge 跑在你本机上，所以电脑关机、睡眠、断网，微信就收不到回复。

如果打算长期使用，建议关闭自动睡眠，并用 Windows 计划任务保持服务常驻。

四、注意权限边界

微信消息最后会变成 Codex 在你电脑上的任务，所以不要随便开放给别人用。建议只处理私聊，群聊默认关闭，或者只允许指定用户。

适合什么场景

它不是为了替代 Codex APP，而是给 Codex 多开了一个入口。

电脑端适合认真操作，微信端适合随手派活。

比如你在外面突然想到一个需求、一段文案、一个代码修改点，就可以直接发给微信里的 Codex。只要电脑在线，它就能在背后继续干活。

总结

这次接入之后，我最大的感受是：

AI Agent 真正变好用，不只是模型变强，而是入口变近。

以前你要坐到电脑前，打开软件，找到项目，再开始说需求。

现在变成了：

想到什么，微信发一句。

对于改代码、整理文件、写博客、查项目状态这类任务，这个体验已经很实用了。

以上，既然看到这里了，如果对你有所帮助，还望不吝点赞与关注，这也是对我最大的鼓励与支持。

感谢你拨冗阅读，山高水长，我们下次再见。

>/ 更多可落地干货教程欢迎访问我的博客：dqtx.cc

2026 年了，这 6 个 npm 包可以卸载了——浏览器原生 API 已经能替代

193577746 — Sun, 21 Jun 2026 12:32:36 +0800

前几天我跑了一下 npx depcheck，发现项目里有 47 个依赖，其中至少 6 个完全可以用浏览器原生 API 替代。卸载之后，打包体积直接少了 82KB（gzip 后少了 23KB），首屏加载快了 300ms。这篇文章把每个包的原生替代方案都写出来，附迁移代码，直接抄。

为什么要清理依赖

每多一个 npm 包，你的项目就多了：

打包体积：用户每次访问都要多下载这些代码
供应链风险：还记得 event-stream 投毒事件吗？依赖越少，攻击面越小
版本冲突：包 A 依赖 lodash@4，包 B 依赖 lodash@3，解决冲突的时间比写代码还长

2026 年的浏览器已经非常强大了。很多你以为"必须装包"的功能，原生 API 早就支持了。

1. 卸载 `lodash.cloneDeep` → 用 `structuredClone()`

之前：

npm install lodash.cloneDeep   # 5.3KB gzip

import cloneDeep from 'lodash.cloneDeep';

const copy = cloneDeep(complexObject);

现在：

const copy = structuredClone(complexObject);

完了。一行，零依赖。

structuredClone 是浏览器原生的深拷贝方法，支持 Map、Set、Date、RegExp、ArrayBuffer、循环引用——这些 JSON.parse(JSON.stringify()) 做不到的，它全能做。

兼容性： Chrome 98+、Firefox 94+、Safari 15.4+，2026 年你不需要担心兼容性。

唯一限制： 不支持拷贝 DOM 节点和函数。如果你的对象里有函数属性，这个方案不适用。但说实话，你的数据对象里不应该有函数。

能省多少： lodash.cloneDeep 单独引入约 5.3KB gzip，卸载后直接省掉。

2. 卸载 `uuid` → 用 `crypto.randomUUID()`

之前：

npm install uuid   # 2.7KB gzip

import { v4 as uuidv4 } from 'uuid';

const id = uuidv4(); // 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

现在：

const id = crypto.randomUUID(); // 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

输出格式完全一样，都是标准的 UUID v4。

兼容性： Chrome 92+、Firefox 95+、Safari 15.4+，全线支持。

Node.js 也支持： Node 19+ 内置 crypto.randomUUID()，前后端通吃。

如果你只需要一个唯一 ID 而不需要严格的 UUID 格式，还有更轻量的方案：

const simpleId = Math.random().toString(36).slice(2, 11);
// '5x3g7k9m2'

3. 卸载 `dayjs` / `moment` → 用 `Intl.DateTimeFormat` + `Temporal`

这个是最重磅的。moment.js 光 gzip 就 72KB，dayjs 虽然轻（2KB），但大多数场景你连 2KB 都不需要。

场景一：格式化日期显示

// 之前：dayjs
import dayjs from 'dayjs';
dayjs(date).format('YYYY年MM月DD日');

// 现在：原生 Intl
new Intl.DateTimeFormat('zh-CN', {
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
}).format(date);
// '2026/06/21'

场景二：相对时间（"3 小时前"）

// 之前：dayjs + relativeTime 插件
import dayjs from 'dayjs';
import relativeTime from 'dayjs/plugin/relativeTime';
dayjs.extend(relativeTime);
dayjs(date).fromNow();

// 现在：原生 Intl.RelativeTimeFormat
const rtf = new Intl.RelativeTimeFormat('zh-CN', { numeric: 'auto' });
rtf.format(-3, 'hour');  // '3小时前'
rtf.format(-1, 'day');   // '昨天'
rtf.format(2, 'month');  // '后2个月'

场景三：日期计算

// 之前
dayjs().add(7, 'day').toDate();

// 现在：Temporal API（2026 年主流浏览器已支持）
const now = Temporal.Now.plainDateISO();
const nextWeek = now.add({ days: 7 });
console.log(nextWeek.toString()); // '2026-06-28'

什么时候还需要 dayjs： 如果你要做大量复杂的时区转换、日历系统切换（农历之类），dayjs 的插件生态还是有价值的。但如果只是格式化显示和简单计算，原生足够了。

4. 卸载 `classnames` / `clsx` → 用模板字符串

之前：

npm install classnames   # 0.6KB gzip

import cn from 'classnames';

<div className={cn('btn', {
  'btn-primary': isPrimary,
  'btn-disabled': isDisabled,
  'btn-large': size === 'large'
})} />

现在：

<div className={[
  'btn',
  isPrimary && 'btn-primary',
  isDisabled && 'btn-disabled',
  size === 'large' && 'btn-large',
].filter(Boolean).join(' ')} />

如果你觉得 filter(Boolean).join(' ') 写起来啰嗦，封装一个两行的工具函数：

const cn = (...args) => args.filter(Boolean).join(' ');

// 用法完全一样
<div className={cn(
  'btn',
  isPrimary && 'btn-primary',
  isDisabled && 'btn-disabled',
)} />

2 行代码替代一个 npm 包。

更好的方案： 如果项目用了 Tailwind CSS，tailwind-merge 比 classnames 更合适，因为它能处理 Tailwind 的类名冲突（比如同时写了 p-2 和 p-4）。这种场景下原生方案做不到。

5. 卸载 `node-fetch` → 用原生 `fetch`

之前（Node.js 环境）：

npm install node-fetch   # 8.4KB gzip

import fetch from 'node-fetch';
const res = await fetch('https://api.example.com/data');

现在：

const res = await fetch('https://api.example.com/data');

Node.js 18+ 内置了 fetch，不需要再装 node-fetch。2026 年还在装这个包，大概率是因为 package.json 里一直没清理。

注意： 如果你的 Node.js 版本低于 18，还是需要 node-fetch。但 2026 年了，Node 18 已经是 EOL，你至少应该在 Node 20+ 上。

6. 卸载 `qs` → 用 `URLSearchParams`

之前：

npm install qs   # 6.2KB gzip

import qs from 'qs';

// 序列化
const query = qs.stringify({ page: 1, size: 20, keyword: '前端' });
// 'page=1&size=20&keyword=%E5%89%8D%E7%AB%AF'

// 解析
const params = qs.parse('page=1&size=20');
// { page: '1', size: '20' }

现在：

// 序列化
const query = new URLSearchParams({ page: 1, size: 20, keyword: '前端' }).toString();
// 'page=1&size=20&keyword=%E5%89%8D%E7%AB%AF'

// 解析
const params = Object.fromEntries(new URLSearchParams('page=1&size=20'));
// { page: '1', size: '20' }

唯一限制： URLSearchParams 不支持嵌套对象和数组的序列化。如果你的查询参数是 { filter: { status: ['active', 'pending'] } } 这种结构，还是需要 qs。但大多数前端场景的查询参数都是扁平的 key-value。

实操：怎么找出项目里可以卸载的包

第一步：找出未使用的依赖

npx depcheck

它会列出 package.json 里声明了但代码里从未 import 的包，直接删。

第二步：分析打包体积

npx vite-bundle-visualizer
# 或 webpack 项目
npx webpack-bundle-analyzer

看看哪些包占了大头。通常 moment、lodash 完整包是体积杀手。

第三步：逐个替换

按本文方案替换后，跑一遍测试，确认功能正常再发版。

总结对照表

npm 包	gzip 体积	原生替代	限制
lodash.cloneDeep	5.3KB	`structuredClone()`	不支持函数和 DOM
uuid	2.7KB	`crypto.randomUUID()`	无
dayjs	2KB	`Intl` + `Temporal`	复杂时区场景不够用
classnames	0.6KB	`filter(Boolean).join(' ')`	无
node-fetch	8.4KB	原生 `fetch` (Node 18+)	需要 Node 18+
qs	6.2KB	`URLSearchParams`	不支持嵌套对象
合计	~25KB	0KB	—

25KB gzip 看起来不多，但在移动端弱网环境下，这就是 200-500ms 的加载时间差距。

更重要的是：少一个依赖，就少一个供应链攻击的入口，少一个版本冲突的可能，少一个 npm audit 的告警。

如果你的项目里还有其他可以用原生 API 替代的包，评论区说一下，我补充进来。点赞收藏一下，下次 Code Review 看到同事装多余的包，直接把这篇甩给他。

出海挣美元分享之：怎么购买域名？

my126sw — Sat, 20 Jun 2026 23:29:52 +0800

上一篇文章给大家分享了《出海挣美元分享之：什么是域名？》，其中就给大家介绍了什么是域名、域名与 IP 地址的关系，以及为什么每个网站都需要一个域名。

这里在简单说一下，域名就是网站的网址，例如：

google.com

freeai.run

timestampcameras.com

有了域名之后，用户才能方便地访问你的网站。

那么问题来了：

域名在哪里买？

域名怎么注册？

买域名需要准备什么？

国内和国外购买有什么区别？

今天就带大家一步一步完成自己的第一个域名购买。

一、购买域名前需要准备什么？

其实非常简单，只需要准备两样东西：

1、一个邮箱

用于注册账号、接收域名到期提醒以及找回密码。

推荐使用：

国外常用的就是：Gmail

国内大家常用的就是：QQ 邮箱、网易邮箱

2、一种支付方式

国内平台一般支持：

微信支付

支付宝

银行卡

国外平台一般支持：

Visa

MasterCard

PayPal

二、中国大陆用户如何购买域名？

如果你的网站主要面向国内用户，或者你不太熟悉英文操作界面，可以优先选择国内域名注册商。

比较常见的平台有：

阿里云

腾讯云

华为云

这些平台的优点是：

全中文界面

支持支付宝和微信支付

操作简单

客服沟通方便

购买流程

第一步：注册账号

使用手机号注册即可。

第二步：搜索想要的域名

例如：

mywebsite.com

如果显示：

可注册

说明还没有人购买。

如果显示：

已注册

说明已经被别人注册了，需要换一个名字或者换一个后缀。

第三步：加入购物车并付款

付款成功后，域名就属于你了。

一般情况下：

.com 域名每年几十元到一百元左右

.cn 域名通常更便宜一些

三、面向海外用户的网站如何购买域名？

如果你的目标是：

AI 工具站

SaaS 产品

Google SEO

海外博客

独立开发项目

那么我更推荐使用国外域名注册商。

原因很简单：

国际认可度更高

DNS 功能更完善

与海外服务兼容更好

后续迁移更加方便

推荐平台一：Cloudflare Registrar

Cloudflare Registrar

优点：

基本按成本价出售域名

没有各种隐藏加价

DNS 服务非常优秀

我目前大部分域名都放在 Cloudflare。

推荐平台二：Namecheap

Namecheap

优点：

老牌域名注册商

经常有优惠活动

新手容易上手

推荐平台三：Porkbun

Porkbun

优点：

价格便宜

免费隐私保护

近年来在独立开发者圈子里口碑很好

国外平台注册流程

基本与国内一致：

注册账号

搜索域名

加入购物车

完成支付

域名注册成功

整个过程通常只需要几分钟。

四、域名后缀怎么选？

很多新手第一次购买域名时都会纠结：

.com .net .cn .xyz .top .ai

到底选哪个？

我的建议很简单：

第一选择：.com

如果能买到 .com，优先购买 .com。

因为：

用户最熟悉

最容易记忆

品牌认可度最高

第二选择：.ai

如果是 AI 产品项目，可以考虑：

yourproduct.ai

近几年很多 AI 创业公司都在使用。

不过价格通常比 .com 贵不少。

第三选择：其他后缀

例如：

.net .io .xyz .run

如果预算有限或者 .com 已经被注册，也完全可以使用。

很多成功的网站最开始也并不是使用 .com。

五、购买域名时的几个避坑建议

1、优先选择短域名

例如：

freeai.run

明显比：

bestfreeaitoolswebsite.com

更容易传播。

2、避免数字和横线

不推荐：

my-ai-tool-123.com

我做了个局部重绘 AI 工具：涂抹一下，想改哪改哪

zhengqiagood — Sat, 20 Jun 2026 21:06:02 +0800

把美工省掉。

3 毛钱，修一张图。

前阵子有个澄海玩具厂的客户，他们想生成玩具车的设计图，整张图风格都挺像样，问题就出在细节上——后视镜跟设计稿不一样。（对方要求保密，无法上图）

要是整张图重来吧，费时间不说，明明看好的设计稿，重新生成就全部都变样了。

他说：要是有个"局部重绘"就好了，把后视镜那块擦一擦，描述一下想要的形状，AI 顺手给改掉，效率能高不少。

于是我就把这个工具做出来了。底层用的是目前顶级的 GPT-4 的 image2 模型，真实感与一致性都有保障。

图片

工具超简单，整个页面就是一张画布，上传、生成、修改都在这上面进行，72 小时自动删除图片，保护版权、保护隐私。

核心亮点：局部重绘

用法也很简单：上传图片，鼠标选区涂抹，输入文字描述，AI 就会把那块区域智能替换掉。关键是，它还能保持原图的光影和风格，不至于改完后跟整张图不是一个画风。

来个示例，先上传一张图片，如下图：

图片点击底部工具栏就可以上传，也可以生成图片。

点击图片后，上方就会出现工具栏：

图片然后第 2 个就是局部重绘工具，可以用橡皮擦也可以用矩型把指定位置圈起来：

图片然后点右边的勾勾，就会出现提示示框：

图片告诉它：

换成哆啦 A 梦就这么简单。

稍等一会，图就修改好了：

图片而且原图还给你保留着。

再换一下墙壁上的照片：

图片

这次换成大雄的照片吧：

图片

这次只是用文字描述，我们来试个新的：局部图生图

局部图生图

图片

还是用刚才这张图，还是一样选择局部重绘工具，这次我们改下她的手机，把她的手机换成我们指定的手办，上传一张我们的图：

图片这时你会看到有两种模式选择：

图片

参考重绘：当你想把图中物体作为参考物融入主图时使用，其结果可能与原图有差别，适合把卡通人物变成娃娃之类的场景。

高保真迁移：当你想把图中物体 100% 融入主图时使用，适合把产品广告或人物合照之类的场景。

现在这个手办，得用高保真模式，看看最后生成啥样：

图片那么什么情况下使用 “参考重绘” 呢？

比如，你想把下面这只猫兄卡通变成娃娃：

图片这是一张手绘的卡通猫，想变成娃娃自然不能再用高保真，只能让它重绘，重绘后的图如下：

图片

核心亮点：支持多并发

你可以同时生成、修改多张图，同时并行，互不干扰。

除了局部重绘，还有其它的玩法：

• 图片生成（文字生成图片）：一句话出图，适合快速出创意或找灵感。 • 背景替换/去除：商品拍在杂乱场景也没事，一键换成白底或品牌背景，电商卖家会很方便。 • 一键去水印：去掉角落的 logo 或水印，快速复用素材。 • 智能洗稿（改写图片风格）：把一张图改成不同的风格，作为创作起点也不赖。 • 修改尺寸：按平台规格快速裁剪和调整比例。 • 滤镜美白：一些基础的调色和优化，省得再打开其他软件。 • 裁剪翻转：常见编辑操作一应俱全。

…………等等，自己去闹吧。

图片像美白的、去水印的，这些就不一一描述了，自己探索更多的可能性吧。

小红书玩家还可以进行 X 稿：

图片不过我们小红书 X 稿也有专门的工具，这个只是配套而已。

图片让女生抱着哆啦 A 梦。

图片换背景。

总的来说，画布操作也挺顺手：鼠标滚轮缩放、自由拖拽，细节看清楚后再涂抹，定位更准。

使用方式：用完即走，隐私无忧

使用方式上，主打一个"拖入即用"。图片直接拖进页面或点上传就开工，所有处理在云端完成，不用安装软件。我做了个"用完即走"的设计理念——图片仅保留 72 小时，之后自动清理，保护隐私。

适用场景我简单列几个：

• 电商卖家：快速修图、换背景、去水印，提升出图效率。 • 设计师：找灵感、快速尝试不同方案、局部调整。 • 普通用户：趣味改图、日常美化，门槛很低。

修图价格约 0.3 元，其它的都是约 0.12 元，新用户可试用

如果你也有这种痛点——局部要改、风格要一致、又不想整图重来，试试看。

👉 复制以下网址体验： https://www.vicoco.cn/p/239

同事每天催我 Code Review，我写了个脚本让 AI 替我 review PR——现在他反过来催 AI 了

193577746 — Sat, 20 Jun 2026 12:31:23 +0800

先说结论：用 GitHub Actions + Claude API 实现全自动 PR review，配置一次，以后每个 PR 推上去，AI 10 秒内给出详细评审意见，覆盖代码质量、潜在 bug、安全风险三个维度。这篇文章把完整配置都给你，拿走直接用。

背景：CR 慢是前端团队的通病

我们团队有个不成文的规定：PR 提上去，要在 1 个工作日内完成 review。

听起来很合理，但实际情况是这样的：

早上刚到公司，打开 GitHub，待 review 的 PR 已经排了 6 个
每个 PR 少则 200 行，多则 800 行
还有自己的需求要写
还有各种会

于是每天我的 review 质量是这样的：

上午的 PR：认真看，写评论
下午的 PR：大概扫一下
晚上的 PR：approve，👍

然后有一天，同事 A 在群里 @ 了我：

"我那个 PR 提了两天了，能帮我看一下吗？"

我翻出来一看——800 行，涉及三个模块。

我当时脑子里只有一个念头：要是有人能替我先过一遍就好了。

解决思路：AI 做初审，人做终审

理想的工作流是这样的：

开发者 push PR
    ↓
AI 自动分析 diff
    ↓
AI 在 PR 里发评论（10秒内）
    ↓
人工看 AI 的意见 + 做最终判断
    ↓
approve 或 request changes

好处显而易见：

AI 处理掉 80% 的机械检查（代码风格、潜在空指针、未处理的 Promise reject）
人只需要关注 AI 标注出的问题点 + 业务逻辑
平均 review 时间从 30 分钟压缩到 8 分钟

坏处也要说清楚：

AI 不理解你的业务逻辑，会漏掉业务层面的 bug
AI 有时候会给"误报"，需要人来过滤
不能完全替代人工 review

所以定位是：AI 初审 + 人工终审，不是 AI 替代人工。

实现方案：GitHub Actions + Claude API

第一步：申请 Claude API Key

去 console.anthropic.com 注册，免费额度足够测试用。

把 Key 存到 GitHub 仓库的 Secrets：

仓库 → Settings → Secrets and variables → Actions
新建 ANTHROPIC_API_KEY

第二步：创建 workflow 文件

在你的仓库里创建 .github/workflows/ai-review.yml：

name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm install @anthropic-ai/sdk @octokit/rest

      - name: Run AI Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          REPO_OWNER: ${{ github.repository_owner }}
          REPO_NAME: ${{ github.event.repository.name }}
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: node .github/scripts/ai-review.js

第三步：创建核心脚本

创建 .github/scripts/ai-review.js：

const Anthropic = require('@anthropic-ai/sdk');
const { Octokit } = require('@octokit/rest');
const { execSync } = require('child_process');

const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });

async function getDiff() {
  const diff = execSync(
    `git diff ${process.env.BASE_SHA}..${process.env.HEAD_SHA} -- '*.js' '*.ts' '*.tsx' '*.jsx' '*.vue'`
  ).toString();

  // 超过 8000 字符截断，避免超出 token 限制
  return diff.length > 8000 ? diff.slice(0, 8000) + '\n... [diff truncated]' : diff;
}

async function reviewWithClaude(diff) {
  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-6',
    max_tokens: 2048,
    messages: [{
      role: 'user',
      content: `你是一个资深前端代码审查工程师，请对以下 PR diff 进行代码审查。

**审查重点：**
1. 潜在 Bug（空值引用、异步竞态、边界条件未处理）
2. 安全风险（XSS、敏感信息泄露、输入未校验）
3. 性能问题（不必要的重渲染、大对象序列化、内存泄漏）
4. 可维护性（函数过长、命名不清晰、重复代码）

**输出格式：**
用 Markdown 输出，包含以下几个部分：
- 🔴 严重问题（必须修复）
- 🟡 建议优化（可以改进）
- 🟢 代码亮点（做得好的地方）
- 📊 总体评分（1-10分，附简短理由）

如果没有问题，直接说"代码质量良好，无明显问题"。
用中文回复，简洁直接，不废话。

**PR Diff：**
\`\`\`
${diff}
\`\`\``
    }]
  });

  return message.content[0].text;
}

async function postComment(review) {
  const { REPO_OWNER, REPO_NAME, PR_NUMBER } = process.env;

  await octokit.issues.createComment({
    owner: REPO_OWNER,
    repo: REPO_NAME,
    issue_number: parseInt(PR_NUMBER),
    body: `## 🤖 AI Code Review\n\n${review}\n\n---\n*由 Claude AI 自动生成，仅供参考，请以人工审查为准*`
  });
}

async function main() {
  try {
    console.log('Getting diff...');
    const diff = await getDiff();

    if (!diff.trim()) {
      console.log('No JS/TS changes detected, skipping review.');
      return;
    }

    console.log('Sending to Claude for review...');
    const review = await reviewWithClaude(diff);

    console.log('Posting comment...');
    await postComment(review);

    console.log('Done!');
  } catch (error) {
    console.error('Error:', error);
    process.exit(1);
  }
}

main();

第四步：推一个 PR 测试

随便改一个文件，提个 PR，大约 15-20 秒后，你会看到 AI 自动在 PR 下面发了一条评论。

真实效果展示

我们团队用了两周后，AI 的评论长这样：

🔴 严重问题（必须修复）

第 47 行 userData.profile.avatar：未做空值检查，当 profile 为 null 时会抛出 TypeError。建议改为 userData.profile?.avatar。

第 83 行：useEffect 的依赖数组缺少 userId，可能导致使用过期的 userId 发请求，产生数据不一致。

🟡 建议优化

第 92-115 行：formatUserData 函数做了 3 件不同的事（格式化、过滤、排序），建议拆成 3 个函数，便于测试和复用。

🟢 代码亮点

错误处理写得很规范，catch 块没有直接吞掉错误，而是通过 errorReporter.capture 上报，赞。

📊 总体评分：7/10

整体结构清晰，主要问题集中在空值防护上，修复后可以直接合并。

看到这个，review 的人只需要：

确认 AI 找出的问题是否真实存在（通常是）
判断业务逻辑是否正确（这才是人工的价值所在）
approve 或 request changes

平均节省 70% 的初审时间。

进阶：按文件类型差异化 review

不是所有文件都需要一样的审查策略。可以在 prompt 里加文件类型判断：

function buildPrompt(diff, fileTypes) {
  const focusMap = {
    'api': '重点关注：参数校验、错误处理、幂等性、接口安全',
    'component': '重点关注：props 类型、副作用清理、渲染性能、无障碍属性',
    'util': '重点关注：边界条件、纯函数、测试覆盖',
    'store': '重点关注：状态更新的不可变性、selector 性能、副作用隔离'
  };

  const focus = fileTypes.map(t => focusMap[t]).filter(Boolean).join('\n');

  return `你是资深前端工程师，请审查以下代码：

${focus ? `**本次特别关注：**\n${focus}\n` : ''}

${diff}`;
}

踩坑记录

坑 1：diff 太大超出 token 限制

解决方案：只 review 修改行数 < 500 的文件，超过的给一个提示"文件变更过大，请人工重点审查"。

坑 2：AI 给出"误报"，降低信任度

解决方案：在 prompt 里加一句 "如果你不确定是否是问题，不要写出来"。比 "尽可能找出所有问题" 效果好很多。

现状

现在我们团队的 CR 流程是这样的：

开发提 PR
AI 10 秒内完成初审，发评论
reviewer 看 AI 评论 + diff，平均 8 分钟完成终审
merge

那个之前每天催我 review 的同事 A，现在每次 AI 评论发出来，他比我更认真地研究 AI 说了什么。

上周他跟我说：

"AI 给我找出了一个我自己写代码时没注意的空指针，这玩意儿比我认真。"

完整代码

完整的配置文件我放在下面，可以直接 copy 到你的项目里：

.github/workflows/ai-review.yml（上文已贴完整版）

.github/scripts/ai-review.js（上文已贴完整版）

需要的环境变量：

ANTHROPIC_API_KEY：从 Anthropic 控制台获取
GITHUB_TOKEN：GitHub Actions 自带，不用手动配置

配置完之后，去提一个测试 PR，看着 AI 自动开始 review，还挺有成就感的。

写在最后

这套方案不是为了让人偷懒的——而是让人的精力花在刀刃上。

机械的检查（空值、类型、格式）让 AI 做，业务逻辑、架构判断、团队规范这些需要上下文的判断，留给人。

如果你的团队也有 CR 堆积的问题，可以直接拿这套配置用。有什么问题评论区说，我看到了会回。

点赞收藏一下，下次出团队提效工具合集时方便你找回来。

为了上 telegram 对接海外客户，我被一个登录界面卡了三天，还好最后解决了

freemanbrent40 — Sat, 20 Jun 2026 11:43:03 +0800

上个月接了一个海外客户的单子，对方要求用某通讯工具沟通。我注册的时候，+86 手机号，验证码等了三天都没来，中间还交了两次 smsfee，钱花了，码还是没收到。

为什么必须上这个工具？

不是我想用，是客户在用。独立开发者接海外单，沟通工具绕不开。客户说"我们团队在这个上面"，你就得上去。

一个做跨境的朋友说，他之前也遇到过，最后换了个客户端解决。基于官方开源版本编译，核心协议兼容，但登录通道不同。

试了一下，直接登录成功，没有验证码，没有 smsfee，两分钟搞定。

用了一周的实际体验

登录方式绕过短信验证，直接设备授权。中文环境完整，连接稳定性不错，电信、联通、移动都试过，后台保活一周，消息推送没漏过。跟客户时差 12 小时，半夜来的消息，早上醒来能看到。

功能上和官方版一样，聊天、频道、搜索、多账号切换，没发现缩水。

官方路径：smsfee 交了几十块 + 三天时间 + 可能丢掉的客户

这个路径：两分钟 + 客户保住

给独立开发者的建议

接海外单前，先确认沟通工具能不能正常登录

遇到验证码问题，别死磕官方客户端，尝试替代方案

时间比钱贵，三天够写完一个功能模块

你们有没有因为某个工具的注册流程，差点丢掉客户或者机会？最后是怎么解决的？评论区聊聊，我帮你们避雷。

SerpBase 运营两个月后，终于把 Google 搜索接进 Agent 这件事做顺了

serpbase — Sat, 20 Jun 2026 11:40:22 +0800

两个月前，我在 W2solo 发过两篇文章：

正式运营 6 天，拿到第一笔 $200：SerpBase 从立项到上线的一个月 (https://w2solo.com/topics/7275)

做了个新站 SerpBase：想把 Google 搜索结果 API 做得便宜一点、稳一点 (https://w2solo.com/topics/7254)

当时项目正式运营第 6 天，拿到了第一笔 $200。两个月过去，产品还在继续迭代，最近花了不少时间解决一件很实际的事：让 AI Agent 更方便地用 Google 搜索。

很多 Agent 场景不需要自己搭浏览器自动化。折腾 Playwright、代理、验证码和页面结构，最后想要的往往只是标题、链接、摘要这些干净结果。

所以做了两个开源集成：

https://github.com/serpbase-dev/serpbase-skill

给支持 Skill 的 AI 编程助手和 Agent 用，装好后可以直接搜索并拿结构化结果。

https://github.com/serpbase-dev/serpbase-mcp

给支持 MCP 的客户端用，把 Google 搜索作为 Agent 的一个工具接进去。

我现在越来越觉得，Agent 的搜索能力不该是一个大工程。能稳定拿到实时信息，返回格式干净，价格别把小项目劝退，基本就够了。

也想问问大家：你们给 Agent 接实时搜索时，现在主要用什么方案？自己爬、SerpAPI/Serper，还是别的？

我们的官网是 (https://serpbase.dev)，欢迎各位大佬前来指导

分享最近 AI 做的儿童启蒙产品：拍照学拼音（附兑换码）

onling — Sat, 20 Jun 2026 10:15:51 +0800

📸 拍照学拼音｜从孩子身边开始的启蒙学习工具

最近儿子开始进入启蒙阶段。

老婆陆续买了不少识字卡、拼音卡和启蒙玩具，每天都会陪着孩子一起认字、学拼音。

陪孩子学习的过程中，我发现一个有意思的现象：

孩子对卡片上的字兴趣其实有限，但对身边真实的事物特别感兴趣。

看到小猫会问是什么，看到汽车会问怎么读，看到水果、玩具、绘本都会不停追问。

作为一名产品开发者，我就在想：

👉 能不能做一个让孩子从身边事物开始学习拼音和汉字的工具？

于是利用 AI 开发了这款小程序——拍照学拼音。

🏠 首页展示

👉 拍照学拼音 Loading Page 页面

🌱 为什么做它

相比传统的识字卡、拼音卡，我更希望孩子能够：

看到什么，认识什么；拍到什么，学习什么。

把现实世界和拼音、汉字自然关联起来。

学习不一定非要坐在桌前。

客厅里的玩具、路边的花草、公园里的小动物，都可以成为孩子的启蒙教材。

📷 核心功能：拍一拍，就会读

（这个功能目前还在打磨中，体验时可以多一点耐心）

孩子拍一张照片后：

AI 识别图片内容
自动生成汉字
自动生成拼音
支持语音朗读

示例：

🍎 苹果 → 苹果（píng guǒ）
🐱 小猫 → 猫（māo）
🚗 汽车 → 汽车（qì chē）

👉 让孩子从熟悉的事物开始认识汉字和拼音

🧩 产品截图

🏠 首页

)

🎮 启蒙小游戏专区

目前已包含：

猜数字
井字棋
识字测算
识字大闯关（持续开发中）

👉 用亲子互动的方式提升孩子兴趣

🚀 当前进展

产品上线一周多，目前已有 1000+ 用户体验。

仍然处于早期版本，正在持续优化：

拍照识别速度较慢（优化中）
拼音学习内容分阶段建设中
创意工具模块开发中
启蒙小游戏逐步增加
更多儿童启蒙内容规划中

如果遇到识别不准、响应较慢等问题，也欢迎反馈 🙏

🌈 未来想做什么

除了 “拍照学拼音”，更希望它成为一个：

👨‍👩‍👧 亲子启蒙互动工具

未来方向包括：

看图学拼音
看图学汉字
中英文启蒙
儿童认知训练
亲子共读工具

👉 让家长陪伴孩子成长的过程更轻松、更有趣

🎁 专属兑换码（限量）

使用方式：进入「个人中心 / 积分兑换」即可使用
（每人每天限用一个）

DY832QK9
DY4GSEJA
DYNJBDPM
DYLGXABK
DY2TD75Y
DYYEBVKL
DYDGYBFG

👉 用完可以在评论区说一声，方便其他朋友

![封面](https://pinyin.qibanai.cn/uploads/cards/nav/qrcode.jpg =600x800)

---

## 🤝 想听听大家的建议

如果你家里有学龄前儿童，或者做过教育产品，想请教几个问题：

- 这种“拍照学拼音”的方式是否有价值？
- 孩子是否愿意持续使用？
- 还有哪些启蒙功能值得加入？

---

第一次做儿童教育方向的产品，还有很多不足。

但希望可以持续打磨，做出一个真正帮助家长和孩子的工具。

欢迎体验、拍砖、提建议，也欢迎交流 👇

微信：Mianxinai

---

❤️ 感谢大家

w2solo - 独立开发者社区

我的 Chrome 插件月活从 0 到 8000，推广费为 0，分享我的五个野路子

三套方法论，10 个 AI 技能，我做了一个会自我进化的 Obsidian 知识库

三套方法论，各管一件事

知识库的四层结构

每个目录的职责

PARA：按行动性分类

Zettelkasten：卡片 + 链接

LLM Wiki：让 AI 帮你维护

10 个 AI 自动化技能

实际工作流

设计原则

适合谁？

总结

AI 生成的代码能跑就行？这 5 个坑迟早炸

第一坑：过度工程化——3 行能解决的事写了 30 行

第二坑：幽灵代码——大量函数从未被调用

第三坑：假注释——注释和代码说的不是同一件事

第四坑：万能 try-catch——出了 bug 永远定位不到

第五坑：data、data2、data3——变量名丢失业务语义

AI 代码验收 Checklist

Square face generator

纵马赴夏日，豪礼皆自达 影帝梁家辉实力背书 EZ-60 马年版上市 EZ-6 超级置换季开启

怎么做三角洲电竞代练护航陪玩小程序？全面介绍系统功能和搭建准备流程

做了个免费 AI 图片去字工具：PicTextRemover，也能顺手去水印和去杂物

KidoX, 一个开源的 macOS Launchpad 替代 App

Telegram 登录验证机制的技术观察：多通道容错设计与 +86 号码的实践记录

【限时福利 免费试用】动态住宅低至 0.5$/GB 静态 ISP 低至 3.8$/条

海外公司注册前，建议先想清楚这几个问题

如何快速制作高考班级毕业去向分布图

Codex App 接上微信，我开始在厕所里改 Bug 了

最简单的接入方式

扫码登录

成功后怎么测试

常用命令

几个注意点

适合什么场景

总结

2026 年了，这 6 个 npm 包可以卸载了——浏览器原生 API 已经能替代

为什么要清理依赖

1. 卸载 lodash.cloneDeep → 用 structuredClone()

2. 卸载 uuid → 用 crypto.randomUUID()

3. 卸载 dayjs / moment → 用 Intl.DateTimeFormat + Temporal

4. 卸载 classnames / clsx → 用模板字符串

5. 卸载 node-fetch → 用原生 fetch

6. 卸载 qs → 用 URLSearchParams

实操：怎么找出项目里可以卸载的包

第一步：找出未使用的依赖

第二步：分析打包体积

第三步：逐个替换

总结对照表

出海挣美元分享之：怎么购买域名？

我做了个局部重绘 AI 工具：涂抹一下，想改哪改哪

同事每天催我 Code Review，我写了个脚本让 AI 替我 review PR——现在他反过来催 AI 了

背景：CR 慢是前端团队的通病

解决思路：AI 做初审，人做终审

实现方案：GitHub Actions + Claude API

第一步：申请 Claude API Key

第二步：创建 workflow 文件

第三步：创建核心脚本

第四步：推一个 PR 测试

真实效果展示

进阶：按文件类型差异化 review

踩坑记录

现状

完整代码

写在最后

为了上 telegram 对接海外客户，我被一个登录界面卡了三天，还好最后解决了

SerpBase 运营两个月后，终于把 Google 搜索接进 Agent 这件事做顺了

分享最近 AI 做的儿童启蒙产品：拍照学拼音（附兑换码）

📸 拍照学拼音｜从孩子身边开始的启蒙学习工具

🏠 首页展示

🌱 为什么做它

📷 核心功能：拍一拍，就会读

示例：

🧩 产品截图

🏠 首页

🎮 启蒙小游戏专区

🚀 当前进展

🌈 未来想做什么

纵马赴夏日，豪礼皆自达影帝梁家辉实力背书 EZ-60 马年版上市 EZ-6 超级置换季开启

【限时福利免费试用】动态住宅低至 0.5$/GB 静态 ISP 低至 3.8$/条

1. 卸载 `lodash.cloneDeep` → 用 `structuredClone()`

2. 卸载 `uuid` → 用 `crypto.randomUUID()`

3. 卸载 `dayjs` / `moment` → 用 `Intl.DateTimeFormat` + `Temporal`

4. 卸载 `classnames` / `clsx` → 用模板字符串

5. 卸载 `node-fetch` → 用原生 `fetch`

6. 卸载 `qs` → 用 `URLSearchParams`