但它能做到网页版 Claude 做不到的事：记住每一个来找它聊天的人、理解东亚家庭里的孝道压力、在合适的时机用"压力水杯"的比喻解释焦虑、识别到危机信号时递上心理援助热线。

网上随便一刷，今天 A 模型封神，明天 B 工具屠榜，后天 C 应用卖爆。Cursor、Claude Code、Codex 轮番上场，你方唱罢我登场。卖课的一轮一轮抛出概念，prompt 工程、Agent、workflow、MCP 协议，推攘着圈内人的焦虑，裹挟着大家闷头往前跑。

有一天在打字的时候，我突然想到一件很小的事情：我每天敲这么多键盘，那我到底更常用的是哪些键？这个问题本身其实没什么用，但它有一点点“可能和直觉不一样”的感觉。比如我一直觉得自己主要在用字母区，但如果真的统计出来，会不会空格才是第一？或者回车？这种事情，如果只是靠感觉，其实永远不会有答案。但一旦把它...

做多了后台项目之后，其实会有一种很明显的感觉：很多东西在反复做。一开始接需求的时候，通常节奏都比较赶，很少有时间去慢慢设计架构。登录、权限、菜单这些东西，基本都是一边写一边补，能跑就行。短期看其实没什么问题，甚至很多项目也确实是这么交付的。但只要你自己维护过一段时间，就会发现问题慢慢开始出现了。...

前段时间我把自己的网站整理了一下，做了一个“番剧墙 / 影视墙”的页面。每个作品有封面、标题、评分、简介，看起来很清爽，也算是给自己这些年的观看记录做一个归档。一开始我也想过，这些信息要不要手动整理。理论上当然可以，但当数量慢慢多起来之后，问题就变得很现实：封面图从哪里来？简介要不要自己维护？某个平台...

理解一个概念并不难，但要把多个能力组合起来，形成一个可以长期运行的系统，往往需要真实项目去反复打磨。很多看似基础的东西，只有亲手做过，理解才会真正扎实。

平时其实很少会专门写数据库导出的事情。这种活本身并不复杂，零零散散也做过很多次，大多数时候也不会留下什么记录。这一次之所以单独记下来，主要还是因为当时遇到了一些​比较具体、也比较现实的限制条件：我需要在比较短的时间里接手一个并不熟悉的 MySQL 实例，把里面的数据整理出来，而且这些数据最终并不是只给工...

前阵子我做了一个小工具：一个完全离线的手机号归属地查询桌面应用功能本身其实并不复杂，但在这个过程中，我反而重新认识了一次用 Go 做桌面应用，其实可以非常像在写一个 Web 项目。这篇文章不打算讲手机号归属地怎么查（那真的很简单，如果你需要直接到文章底部仓库下载我做好的工具就好），而是想分享一下： 为什么...

前阵子做的一个直播弹幕的机器人，其中有一部分上游数据是通过 Protobuf 返回的。几个朋友问我怎么处理，但我发现大家对「PHP 解析 Protobuf」这件事多少有点迷糊。确实，PHP 处理 Protobuf 的资料不多，而且踩坑成本不算低。

为什么要先规划目录结构刚开始写 Go 项目的时候，我对目录结构这件事格外重视。对于刚入门的人来说，开发过程中几乎每件事情都是第一次：全局配置怎么放？数据库连接怎么初始化？Model 怎么设计？路由怎么组织？每一个点都能让人迷茫。相比之下，像 Java 的 Spring Boot 或 PHP 的 Laravel 都会给你一套“默认结构”，至少...

我现在一天基本离不开 AI 了。 不是那种“把提示词写得像炼丹”式的依赖，而是很平常的那种：我写代码，它在旁边检查。 我整理逻辑，它帮我捋一遍。 我写文档，它补补关键字、给点建议。整个过程更像是 我在人前台写，它在后台兜底。 它不是替我工作，它是把我的工作做得更圆滑、更完整。但说实话，我过去对“AI 助理”的期...

前阵子，我看到有人在吐槽自己写博客很麻烦——写麻烦、托管麻烦，推完 GitHub 之后还得去服务器上手动拉代码部署。虽然我以前在做类似的东西，但他这么一提让我想起这件事，我就想着，不如把自己一直随便用的小玩意整理一下，顺便分享给大家。

友链这东西，说出来有点浪漫。2025 年了，个人博客基本没有什么流量，更多像是一座座散落在海上的小岛。 偶尔有海风吹过，但大多数时候，就是悄悄发光、自娱自乐。而友链……就像是在这些小岛之间铺上一条条细细的桥。 你看不到桥的尽头，但知道那里至少还有一个同样孤独、同样固执的人。为什么拖了这么久才开放友链申请？...

最近我把自己常用的一套错误上报逻辑封装成了一个 Composer 包，叫 ​hejunjie/lazylog​。 功能很简单也很实用：安全地写本地日志 + 把异常信息上报到远端（支持同步/异步） 。本文讲讲为什么我要做这个库、实现思路、在不同运行环境下如何选择（以及我推荐的优化方案）。

很多博主都有这样的困扰：一些文章不希望所有人都能直接看到，而是想设置一个“问题验证”，答对才能解锁。但如果你用的是纯静态博客，想实现这个功能却发现困难重重——文章内容在 HTML 里早就暴露了，CSS 或 JS 根本藏不住。

以为 Web3 已经没动静了，结果最近刷小红书的时候，我又碰到了那些所谓的“Web3 大师”。 你懂吧，就是那种典型的人设，大厂导师，一坐上去就开始散发“老子站在时代最前沿”的气场。

最近在维护老项目时，又一次用到了 Phinx。这个工具我已经用了很多年，几乎每个项目都会用上它。它属于那种平时不常用，但每个项目都离不开 的工具。

在各种平台上，初始注册的用户通常都会被分配一个默认头像。 但如果你的平台有互动功能，比如评论、留言、排行榜，一堆一模一样的默认头像排在一起就会显得很单调，甚至有些奇怪。

作为老牌网站流量统计服务商，51.la 提供每月高达 1000 万次的免费统计额度，非常适合个人博客或小型网站使用。不过，51.la 默认的统计展示是通过嵌入 JS 文件自动渲染的，这种展示方式对美观性和自定义性有限，对于追求页面整洁或者想要自己设计展示风格的博主来说不太方便。

写博客这件事，老实说，现在可能不太流行了，流量也未必多，但对我来说，有没有博客是两回事。过去几年，我一直用 Hexo 搭建和维护我的博客，主题丰富、社区活跃，用得也很开心。老博客：不过，随着我对博客的需求越来越多，我发现 Hexo 在一些定制化操作上有些局限。于是，我决定尝试用 Astro 来重构我的博客。新博客：...

最近整理了一个自己做的小项目——PHP Trade Splitter ，是一个交易/利润分账组件。今天想分享一下，也算是记录自己的小成果，也顺便展示一下技术思路。为什么会做这个包说白了，就是因为工作/项目里老是碰到分账逻辑：平台抽成作者收益代理或渠道分润阶梯奖励多级递归计算以前都是直接写死在业务里，每次改需求都得重构，...

维护多个项目的人，大概都明白那种感觉。 平时一切都很平静，直到某天，甲方的一句“系统是不是出问题了？” 这时候才发现，问题早就埋在那里了。你登录服务器，开始翻日志、看 trace，一边调试一边回想昨天是不是又改了什么。问题最终解决了，但那种被动的感觉始终在心里。我后来想： 这种被动，其实是可以被解决的。 有...

我平时是做 PHP 的，工作里基本上都是在写 Web 应用。说实话，写久了难免有点惯性思维：服务器、框架、数据库、API、浏览器。 而这次，我做了点不一样的东西 —— 一个用 Go 写的财务管理桌面应用。

在项目里写接口的时候，我有时候会希望再多一层保护。 虽然 HTTPS 已经能保证传输安全，但它解决的更多是「传输过程中不被窃听/篡改」的问题。 而我还想顺带做到几点：

写 PHP 第 7 年了，我发现有些功能简直像韭菜——项目一换就得重新割一遍。手机号归属地、参数校验、唯一 ID、地址解析……是不是你也写过不止一次？有些功能不难，但就是麻烦：做个小商城，要写个 促销规则引擎做个 API，就得来一遍 参数验证器做用户注册登录，要写个 TOTP 动态口令做支付结算，要造个 唯一 ID 生成器这些...

在日常开发里，我们经常会遇到这种情况：需要给订单生成唯一编号；想给日志或者资源加个标识；或者需要一个不会重复的 ID，用作数据库主键。一开始，我也用过 time() 拼接随机数、或者 uniqid()。 这些方案在小项目里够用，但一旦放到并发稍微高点的业务里，就会出现各种问题：​time() 很容易撞车（同一毫秒可能生成多个...

为什么要做这件事？老实说，我平时不太在意自己到底写了多少行代码。一方面是因为这东西真没啥太大参考价值，想刷行数的话，复制粘贴个几千行都不是事；另一方面也是因为谁都知道：代码质量和行数没什么关系。但有时候，好奇心就是挡不住。 就像你听到别人讲“十万小时定律”的时候，会突然想：“哎，那我到底练习了多久？”...

在日常开发中，参数校验是绕不过的一道坎。我们常常需要确保用户传入的数据符合预期格式，比如必填字段、数据类型、最大长度、邮箱格式等等。虽然许多 PHP 框架都内置了验证器，但在开发轻量服务、非框架项目，或需要在业务中后端进行结构化数据校验时，我总觉得现有方案不够灵活、冗余较多。

做电商项目时，经常要处理各种各样的优惠活动：满减、打折、VIP 专属优惠、第二件特价、阶梯优惠…… 这些单独实现起来都不复杂，但当你把它们放在一起，就变得混乱起来了。

想着要不玩个私服吧，结果一圈找下来——不是太卡就是太坑，不是要冲钱开会员就是干脆跑路关服。关键是我不是真的图啥竞技氛围，我就想一个人刷刷图，体验一下当年那个60版本的感觉。