你好，这里是 Kikoman

我做全栈，工作里什么栈都碰：前端、后端、移动、桌面、AI。东西做多了， 最值钱的往往不是某个具体实现，而是一套能复用的判断——什么该买、什么该 fork、什么必须自研。 这个博客就用来记这些判断，而不是记流水账。

三个问题，不是三选一

拿到一个新需求，我很少直接打开编辑器。先问三件事：这个能力有没有现成、够成熟的方案？ 如果有，改造它比重写它便宜多少？如果没有，缺的是「能力本身」，还是只缺「贴我这套系统的皮」？

三个问题对应三条路，但它们不是并列选项，是一个漏斗：

• 买：能力是通用的，别人已经把边界情况踩过一遍。字体子集工具、浏览器自动化框架、支付网关， 这些我都直接用现成的——自己写一个只是重新踩别人踩过的坑。
• fork：内核已经在别处验证过，只是外壳 (品牌、内容、局部逻辑) 要换。这是最容易被低估的 一条路，因为它看起来不算「自己的工作」，但它是杠杆最大的一条。
• 自研：没有现成方案能满足约束，或者这套东西本身就是我要交付的能力。这条路最贵， 只在前两条走不通时才该走。

一个真实例子：从朗福到 Kikoman

朗福是一家节能环保企业，官网的约束很具体：中英双语、深色「仪器」风格设计系统、首屏是一套 自研的生成式效果而不是套模板。这套约束在开源世界里找不到现成组件，所以那一次是彻头彻尾的 自研：色彩、字体、文案、组件全部按单一数据源立骨，深浅主题一次 token 翻转，视觉回归靠 Playwright 自动抓拦。

你现在看的这个站没有重复这个过程。Kikoman 是朗福那套内核的一次 fork：内核该验证的都 验证过了 (单一源架构、双语路由、视觉守门流水线)，要换的只是品牌色和内容——霓虹紫替掉了 原来的橙色信号系统，文案换成我自己的东西。如果我把 Kikoman 当成一个新项目从零自研，多花的 时间不会换来更好的站，只会重新证明一遍朗福已经证明过的东西。

判断本身才是资产

具体实现会过时——框架会换、审美会变、需求会迭代。但「什么时候买、什么时候 fork、什么时候 自研」这套判断标准，换十个项目也还是同一套。这个博客记的就是这些判断，以及我在什么情况下 判断错了。

写得不一定勤，但尽量只写有信息量的。