Loong Gy

把自己的东西连成一张网

Mon, 09 Nov 2026 00:00:00 GMT

这个月折腾了不少东西：博客的文章全部推倒重写，名片站从一页扩成了几页，顺手还修了个藏了几个月的交互 bug。都不是大事，但连起来看，我发现它们其实是一件事——把自己散落的东西，连成一张网。

曾经的东西都是“点”

之前的状态大概是这样：三款插件躺在 uTools 市场里，用户下载、用着，但不知道作者是谁；代码在 GitHub 上，但仓库和“我这个人”之间没有可走的路；偶尔想写点什么，写完了就沉在时间线里。

每个点都不算差，但点与点之间没有线。别人看到的是孤岛，我自己回顾的时候，也说不清这些事到底构成了什么。

连网的过程，其实是自我澄清

真正有意思的是动手的过程。给名片站写 /uses 页时，我被迫回答“我的工具选型逻辑是什么”；给插件写案例研究时，被迫回答“每个取舍背后的理由”；重写博客时，被迫回答“我到底想在这里记什么”。

这些东西平时都含糊地待在脑子里，只有要给别人看的时候，才被逼着长清楚。

清完之后答案浮出来了：白天做项目管理、晚上做独立开发，不是我身上的两个标签，是同一套方法论在两个场景下的运行——价值排序、依赖分析、成本意识，白天用在项目上，晚上用在产品上。想明白这个，内容的骨架自然就有了：博客一半写管理、一半写动手，两边互相引用。

网效应：每加一个节点，其他节点都升值

连起来之后有个明显的感受：单个节点没变，但整个系统变值钱了。

博客写了一篇挣值分析的方法论，文章末尾自然的去向是“我把这套东西做成了工具”——插件有了故事；名片站首页自动显示博客的最新文章——名片是活的；插件案例页引用博客的深度文章——产品有了深度。没有人造流量的动作，只是路修好了，人自然就走通了。

这也是我建议每个独立开发者都搭一张自己的网的原因。作品会过时，但“能持续看到你这个人在想什么、做什么”的入口不会。

接下来

这张网目前的形态：名片站是入口，博客是思考的展开，插件是方法论的落地，GitHub 是源码的归处。网还在织——联系方式的位子留好了，履历时间线等着填真实素材。

写随笔的好处这时候显出来了：不用是“教程”，不用有“结论”，记下当时的状态就行。这篇就是——2026 年 11 月，网刚成形的时刻。

无 Cookie 的访客统计：我存了什么，没存什么

Sat, 07 Nov 2026 00:00:00 GMT

给博客配了个自建访客统计：一张 D1 表，一段 40 行量级的 Worker 代码，文章页上的“N 次阅读”和后台统计都从它来。这篇不写怎么实现（代码很短），写存了什么、没存什么、为什么——隐私设计才是这类小系统的主菜。

为什么不用现成的

现成方案不缺：CF Web Analytics 功能最全，但数据在别人面板里，和管理员令牌一样属于“平台替你保管”；Plausible、Umami 要么付费要么再养一个服务。对博客这个体量，数据主权和架构简单我都想要，那就自己写——反正也就一张表。

上报：Beacon + 最小字段

前端只在页面加载时发一次 navigator.sendBeacon('/api/track', ...)，字段就两个：

path：当前路径；
ref：document.referrer 的主机名，只用来回答“访客从哪来”（搜索引擎 / 友链 / 直接访问）。

没有用户 ID，没有 fingerprint，没有 localStorage 标记。同一个访客刷新十次就是十次 pageview——计数是诚实的粗，但我不想为了“去重”去生成一个能跟踪人的标识。

存储的三条纪律

第一，IP 只以天级轮换的哈希存在。sha256(ip + salt + 当天日期)，盐放在 Worker 的环境变量里，数据库里查不到原文。第二天盐值日期一变，同一访客的哈希完全不同——它能支撑“今天多少独立访客”这种粗统计，但没法跨天追踪任何人。

第二，referrer 只留主机名。https://www.google.com/search?q=很长的私人文案 进库时只剩 www.google.com。完整的 URL 里经常带着别人的搜索词，那些不该存在我的数据库里。

**第三，没有会话、没有行为链。**不记录“访客 A 先看了哪篇又看了哪篇”。我需要回答的问题只有三个：多少人来了、从哪来、看了哪些文章。答不了的问题干脆不收集——不收集是最彻底的隐私保护。

界面上有个小设计

自己的访问不该污染读者数据。统计页是令牌门禁的独立页面，管理访问不带 referer 上报的路径——访客统计里的数字，就是访客的数字。

复盘

这套统计的总成本：一张 D1 表、一个端点、几十行代码。换来的是：页面干净（无脚本横幅）、用户清爽（无 cookie 无追踪）、我自己清楚每一个字节是什么。

安全这件事，在小系统上的最优解往往不是“加”，是**“少存”**。

一个人的全链路：我的独立开发工作流

Fri, 06 Nov 2026 00:00:00 GMT

独立开发者最不缺的是“该用什么工具”的建议，最缺的是解释为什么这么选。这篇把我的完整工作流摊开，每个选择都说清楚背后的约束——因为约束才是真的，工具只是约束的产物。

先说约束，再说选择

我的约束有两条，先于一切技术选型：

时间只有下班后。所有环节的复杂度都要对“一个人、碎片时间”负责；
月费要接近 ¥0。副业产品在验证收入之前，不应该先欠基础设施一笔钱。

下面的一切都是这两条的推论。

产品层：uTools 作为载体

三款插件都做在 uTools 平台上。选它不是因为它热门，是因为呼出即得：用户在任意软件里按一下就到工具，用完消失。效率工具的最高境界是打断最少，这个场景比“再开一个网页”贴近真实工作流得多。而且插件市场自带分发，一个人不用操心获客。

技术层：TypeScript 一把梭

主力语言只有 TypeScript。理由朴素：前端、Node、Cloudflare Workers、uTools 插件全栈通用，一套语言吃下所有层。独立开发没有同事替你盯回归——类型系统就是那位免费且不睡觉的同事。

流程层：Git 是唯一的真相

所有东西先进仓库，部署是仓库的下游：

写代码 → push → GitHub Actions 构建 → wrangler deploy → 边缘上线

push 即部署，全程无人值守。GitHub 哪天不通，本地 wrangler deploy 是备用通道——两条链路通向同一个终点。这个纪律换来的东西很简单：半夜改完一行 CSS，不用在部署文档里找“下一步该干嘛”。

架构层：边缘 + 纯离线

博客跑在 Cloudflare Workers + 静态资产上：静态请求免费不限量，API 和页面同域，没有 CORS；
三款插件全部纯离线：用户数据不出本机；
数据库只有 D1 一个，免费额度对个人站绰绰有余。

这套架构最大的好处是心理上的：费用恒为零，就不用焦虑“这个月服务器钱赚回来没有”，可以纯按产品节奏做事。

方法论层：白天的那套，晚上照用

需求进 idea 池，不马上做；做的时候拆到“1~3 天”粒度；每周对着插件市场的反馈排一次优先级。挣值分析就不必了——一个人干活 EV 永远等于 AC（笑），但“价值优先级、依赖关系、投入产出”这套判断框架，白天晚上是同一套。

独立开发最需要的不是多学一门技术，是把已有知识连成一条流水线。

把博客搬到边缘

Fri, 06 Nov 2026 00:00:00 GMT

这个博客的托管方案动过一次手术：从纯静态托管搬到了 Cloudflare Workers。搬完之后顺了很多，把架构和账本都记下来。

为什么搬

最初是纯静态站，评论想自建就得另起一个 API 服务——跨域、两套部署、两份配置，个人项目背两套基础设施纯属自找麻烦。

搬到 Workers 之后一切归一：一个项目，前端是静态资产，后端是同一个 Worker 里的 /api/*。同域，没有 CORS；一次部署，前后端原子上线；一份配置文件说清所有事。

架构长什么样

visitor
  └─ blog.loonggy.workers.dev (Worker)
       ├─ /api/*    → Worker 代码（评论、统计、搜索日志、速率限制）
       └─ 其余全部  → 静态资产（Astro 构建产物，含 404 兜底）
数据 ── D1（评论 + 浏览量，SQLite）

几个关键点：

静态资产不走 Worker CPU。资产服务是平台层的，不占 CPU 配额也不计费，只有 /api/* 真正执行代码；
D1 是 SQLite 在边缘的展开：建表、迁移、查询都是熟面孔，免费额度 5GB + 每天 500 万行读，个人站用不到零头；
防灌水四层：蜜罐字段 → 平台速率限制 → 60 秒冷却 → Turnstile 人机验证。邮箱和 IP 只存加盐哈希，泄露了也对不上原文。

账本

免费档的真实边界（按官方 limits 页核过）：

Worker 调用 10 万次/天——只算动态请求，静态资产不限；超额是停服不是扣款，个人博客离这个数很远；
CPU 10ms/次——对“查个评论列表”这种活绰绰有余；
唯一确定支出：域名一年约 $10（还没买，workers.dev 先用着）。

也就是说，在“自建评论 + 自建统计 + 全文搜索”这个功能密度下，月费是 0。这个约束反过来塑造了架构——所有设计都在免费额度内做取舍，反而简单。

部署纪律

push master 触发 GitHub Actions：npm ci → build → wrangler deploy，两分钟上线。配一条硬规矩：部署前先 commit，保证仓库与线上零漂移。线上永远有源码对应，回滚就是 re-deploy 旧 commit。

搬完的感受

个人博客的最舒服形态，大概是：架构图一眼能画完，账单一眼能看完，故障时一眼能看出问题在哪一层。边缘这套全占了。工具链的尽头不是更复杂，是更省心。

Excel 是团队的通用语

Thu, 05 Nov 2026 00:00:00 GMT

做项目管家的时候，我在一个设计决策上纠结了很久，最后它成了我做工具以来最值钱的一条经验。写下来。

一次教训：优雅的方案，错误的产品

给插件设计数据入口时，工程上的最优解很诱人：让用户在我的界面里重建任务结构。数据模型干净、校验完整、字段规范——每个环节都赏心悦目。

但站在用户的位置想三秒就会发现不对：项目经理手里已经有计划表了。在 Excel 里养了好几年的 WBS，字段是按自家流程长的。让他“重建一遍”，等于告诉他：换工具的先决条件是先给旧工具收尸。

结果就是他不会换。不是产品不好，是搬家成本比收益先到。

所以规则很简单

**工具适应人，不是人适应工具。**具体到落地就是一条：你的工具必须能吃能吐 Excel。

能吃：用户现有的表直接导进来，脏数据你洗，格式差异你兜。工程上多写一堆解析和容错代码，但用户的迁移成本是零。
能吐：算完的结果导出去还是 Excel——不是因为好看，而是因为它的下游（汇报、评审、转发给领导）全是 Excel 驱动的。你工具的输出，是别人工作流的输入。

为什么 Excel 值得当成“协议”来看

把 Excel 当一个协议来理解会更清楚：它是这个星球上普及度最高的结构化数据交换格式，没有之一。团队成员会用，跨公司交流用它，领导验收看它。你可以不喜欢它（单元格合并是反人类的发明，我同意），但通用语的意义就是所有人都会说。

做项目管家的 Excel 导入功能时,真正的难点从来不是读写表格——是预测用户的表会长什么样：列名千奇百怪、日期格式五种起步、合并单元格满天飞。兼容它们的过程烦到怀疑人生，但每兼容一种，就多一类“可以直接用起来”的用户。

推广到一切工具设计

这条经验早就不限于表格了：

做的插件全部支持纯离线，因为用户的“已有工作流”里包括“断网”；
博客的 RSS 做全文输出，因为订阅器是别人的阅读工作流；
评论不强制登录，因为“注册”就是一道搬家门槛。

**用户搬家是要付成本的。你的工具要么足够好到让他付，要么先把成本降到零。**多数产品的正确答案是后者。

关键路径：改一个工期，看懂全盘

Wed, 04 Nov 2026 00:00:00 GMT

进度延了，谁的锅？开这种会之前，先看关键路径。CPM（Critical Path Method）是项目管理里最老的方法之一，但很多项目把它画完就挂墙上了，再没打开过。这篇讲它到底怎么用。

一分钟版原理

把项目拆成任务，标上工期和依赖（B 等 A 完工），就得到一张网络图。关键路径 = 从头到尾最长的那条依赖链——它的总工期就是项目最短完工时间。

为什么叫“关键”？因为这条链上任何一个任务晚一天，项目整体就晚一天，没有缓冲。不在关键路径上的任务晚几天，只要不把非关键链拖成关键链，项目就不受影响——这叫浮动时间（float）。

它真正的用法是“推演”

画图只是开始。关键路径的价值在改计划的那一刻：

“设计如果晚 3 天，上线受不受影响？”——看设计在不在这条链上。在，全盘顺延 3 天；不在，看它的浮动时间够不够 3 天。
想赶工，加资源加在哪？——加在关键路径上才有用。给非关键任务加人，项目一天都不会提前，白花钱。
砍范围砍哪个？——砍掉的任务如果不在这条链上，恭喜，工期不变；别被“砍了很多”的表象安慰。

我给项目管家做 CPM 功能时,把交互做成“改一个工期，整条链立刻重新标色”——就是因为这个动作才是日常：图是静态的，推演才是活的。

小项目的三个实用建议

任务粒度到“一个人 1~3 天”就停。太粗的粒度（“开发 20 天”）会把风险藏进黑盒，关键路径算出来也是假的。
依赖只记“硬依赖”。真要等上一个的产出才能开工的才算，“顺便”类的软依赖别进图，不然路径全是毛边。
每周重算一次。实际进度一动，关键路径可能换道——上周不重要的链这周可能成了瓶颈。图不更新等于没画。

最后一句实话

关键路径回答的是“谁在卡脖子”，不回答“为什么卡”。卡住的原因可能是一个拖延的接口人、一次没对齐的需求——图会把问题暴露在正确的位置，解决它还是靠人。

项目经理应该会的三个数字：PV、EV、AC

Tue, 03 Nov 2026 00:00:00 GMT

提到挣值分析（Earned Value Management），很多人的反应是“PMBOK 里的理论，用不上”。我把这套东西做成了插件之后反而更确定：它不是理论，是三个数字的算术。这篇用人话讲清楚。

三个数字

任何时刻，一个项目只需要回答三个问题：

PV（Planned Value）：按计划，此刻应该完成多少价值？——“应该干多少”
EV（Earned Value）：实际完成了多少价值？——“真干完了多少”
AC（Actual Cost）：为完成的部分花了多少成本？——“花了多少”

注意 EV 是唯一需要“完成度”定义的：任务按计划价值记账，做完了才算满，做一半可以按比例（或者干脆不算，看你的规则）。先定完成度规则，再谈挣值，不然三个数字从根上不可比。

两个衍生指标才是日常

三个数字两两相除，得到日常真正盯着的东西：

**SPI = EV / PV —— 进度是快是慢。**SPI = 0.8 的意思是：当前速度只达到了计划的 80%。低于 1 不一定是坏事，但要能说出为什么。

**CPI = EV / AC —— 钱花得值不值。**CPI = 0.9 的意思是：每花 1 块钱，只干出了 9 毛钱的活。

这两个指标最大的价值不是“算出来”，而是让进度和成本这两件事第一次可以放在一起看。只看进度百分比不看成本，会漏掉“进度赶上了但加班加爆了”的项目；只看花销不看完成度，会漏掉“省了钱但其实啥也没干”的项目。

一个必须说的反例

SPI 在项目后期会失真：临近收尾时 PV 趋向总额，哪怕你按期交付，SPI 也会被拖向 1，看起来“永远差一点”。所以实践中：

早期看 SPI（进度敏感），全程看 CPI（成本更诚实）；
CPI 连续三个周期下滑，比单次的数字更值得警惕；
WBS 粒度太粗（任务动辄几百人天）的项目，挣值算出来是自欺欺人——先把任务拆小。

为什么我把它做成了工具

道理不难，难的是每周算、每周画曲线、每次改工期重算。这正是工具该干的活：项目管家里录好计划和实际数，SPI/CPI 直接出来，健康度一屏可见。方法论的终点应该是工具，不是开会时的 PPT。

指标不改变项目，改变项目的是看到指标之后你做的决定。

管交付的人，晚上写代码

Sun, 01 Nov 2026 00:00:00 GMT

这个博客开了关、关了开，这是第 N 次。这次想清楚了它该是什么样子，先立此存照。

我是两份简历

白天，我是项目经理：拆需求、控风险、追节奏，让一群聪明人把事情真正做完。晚上，我是独立开发者：想法 → 设计 → 编码 → 上架，全链路一个人跑通。这两份身份不冲突，反而是彼此的补药——

**管理思维让我写代码少走弯路。**做一个产品之前先问需求优先级、投入产出、风险在哪，这些职业病在独立开发里全是优点。我给项目经理做了一款工具（项目管家），功能取舍全部来自真实的方法论，不是抄来的需求清单。

**工程思维让我做管理不说空话。**亲手写过评论系统的防灌水，才知道“加个验证码”这句话有多轻飘飘；亲手算过边缘部署的账，才会在选型会上拒绝拍脑袋的报价。

这个博客记什么

两件事，各占一半：

管理这条腿：挣值分析怎么看、关键路径怎么用、工具该怎么设计。不是教科书，是我自己用过后留在手里的那部分。
动手这条腿：这个博客本身就是素材——评论系统、访客统计、边缘部署，每一个功能从设计到踩坑的完整过程。

原则只有一条：**写我真正做过的，和真正想清楚的。**不追热点，不写没上手过的东西。

已有的东西

三款上架的 uTools 插件：Base64 编解码工具集、行政区划查询、项目管家，全部纯离线，2500+ 位用户；
这套博客：Astro 7 + Cloudflare Workers，评论 / 搜索 / 统计 / 分享图全自研；
一张名片：me.loonggy.workers.dev，所有入口都在那。

坑不会消失，但可以不再踩第二次。这里就是踩坑记录本。