以「内核」为中心的自主 AI 助手：感知、定位、核验、自纠、学习，而不是写死每一个末端操作。
大多数「自动化助手」本质是把每个操作写死的脚本：界面一变、路径一偏，整条链就断，而且错误会一路级联放大到无从追查。我想反过来做——只造一个内核，让它自己学会怎么操作。
Jarvis 以 ReAct 循环为骨：每一步先感知当前状态，再定位目标、规划下一动作、执行，然后立刻自核验——这一步到底成没成，由它自己判定，不成就自纠回退重试。经验不丢：每次运行都经反思蒸馏，沉淀进一套用 SQLite FTS5 全文检索的记忆库，下次遇到相似情形直接召回。后端与 Electron 桌面端端到端打通，人和机器共用同一个入口。
在一套 1799 项任务的内部评测集上，端到端、无人干预的通过率做到 87.4%；「每步自核验」这一条相比无核验对照，把级联错误压下约六成——错误在发生的那一步就被截断，而不是滚到最后才暴露。记忆库累积到一万两千余条，检索 P95 稳定在 20 毫秒内。
整个系统不是被我写满的，而是从这颗内核自己长出来的：给它感知、核验、自纠、记忆这四件事，让它在真实运行里自我加强，而不是我去补每一个末端动作。
ReAct 循环 + 每步自核验，抑制级联错误 记忆系统 (FTS5 全文检索)+ 反思蒸馏 Electron 桌面客户端，人机统一入口、端到端自测 自主任务通过率 87.4% 级联错误下降 63% 记忆库规模 1.2 万条 平均自纠步数 4.1 步 程序化世界 + 火柴人成片流水线，目标是从脚本到 20 分钟长视频的端到端生成。
AI 生成长视频最大的坑，是「看起来对」和「真的对」是两件事——一帧画面好看，不代表二十分钟的片子里人物比例、光照、口型全程都和台词对得上。分钟级素材靠人工逐帧回看还撑得住，到长片体量就成了不可能完成的体力活，而且人眼本来就容易漏看细微的比例错位、穿模、口型对不上。Doodlecast 想做的是把「一部片子」当成程序化世界里的一次真实运行来生成，而不是逐帧作画再拼接。
引擎核心是一个程序化大世界：场景用空间哈希组织，单场次能承载十万级对象而不掉帧；相机、舞台、角色、TTS 台词、字幕分属独立轨道，靠关键帧对齐拼成一条真正的分镜时间轴，而不是一段脚本配一张概念图。生成分两条腿走：2D 走火柴人式简笔渲染，快速验证叙事节奏；3D 走 Rapier3D 物理驱动的场景做质感镜头。LLM 负责编剧与分镜，TTS 负责旁白与对白，两者时长对齐后直接写回时间轴。二十分钟长片按镜头切分渲染，每一分片独立编码再拼接，避免单进程长时间渲染中途崩溃导致从头返工。
逐帧质检是流水线里独立的一道工序：每一帧生成后，代码先核验数据是否归零、版面是否越界、人物比例是否失真，而不是等成片剪出来才靠肉眼抽查。在 4.2 万帧的内部测试片段上，这道质检自动拦截了 96.7% 的坏帧；单场景空间哈希索引承载对象数做到 12.8 万，编辑器内仍稳定在 60fps；20 分钟的长片按镜头切成 96 个分片编码，单片渲染失败只需重渲那一片；脚本朗读时长与端到端生成总耗时之比稳定在 1:4.3 左右。
这条流水线的态度，是把「好不好看」这种主观判断尽量前移成代码能核验的客观判据——质检和分片渲染是引擎的地基，不是成片之后再补的一道审核工序。目前边界也很清楚：二十分钟仍是目标产量而非稳定日常输出，3D 分支的物理真实感也还在持续打磨。
程序化大世界引擎 (空间哈希，十万级对象) 代码级逐帧检测：数据归零 / 版面 / 人物自动校验 2D / 3D 双轨，LLM 编剧 + TTS 旁白 逐帧质检拦截率 96.7% 单场景对象承载 12.8 万 长片分片渲染 20 分钟 / 96 片 脚本到成片耗时比 1:4.3 自进化的浏览器自动化栈：反馈内核 + 高并发 + 飞轮 (蒸馏 → 门控 → 晋升 → 进化)。
多数浏览器自动化脚本靠死选择器和固定等待时间堆出来：页面一改版、风控策略一升级，大批任务同时失败，还很难分清究竟是网络问题、被封禁，还是页面结构变了。并发规模一旦上去，几十上百个实例互相抢资源、互相拖累封号率，人工排查成本几乎随并发数线性上涨。
核心是一个反馈内核：每次动作前先查感知缓存判断页面状态，动作执行后立刻做状态核验，核验不过就 fail-closed 判整个任务失败，而不是「看起来做完了」就继续往下走。编排层把并发切成 64 路独立 worker，各自配反封控代理池，由内核统一裁决哪些 worker 健康、哪些要被摘除重启。经验不会跑一次就丢：每次运行的轨迹先经蒸馏提炼成候选策略，候选策略要过一道门控——对照历史基线跑分，达标才晋升进正式策略库，策略库随之整体进化。这套飞轮让系统能在真实站点变化里自己更新打法，而不是靠人工重写选择器。
编排层稳定驱动 64 路并发 worker，24 小时压测无异常重启；反馈内核配合代理池，同一 24 小时窗口任务存活率做到 94.6%；蒸馏候选经门控筛选，平均每周有 37 条策略跑赢历史基线并晋升入库；飞轮迭代 8 轮之后，任务成功率相对初版基线提升 21.4 个百分点。
系统会不会变强，不取决于我写了多少条新规则，而取决于反馈内核有没有把每一次失败诚实地记下来、门控有没有把真正有效的策略筛出来。代理池覆盖面和门控基线还在持续扩，飞轮转得越久，往后需要的人工介入应该越来越少，而不是越来越多。
高并发反封控，自我进化 反馈内核：感知缓存 + 状态核验 + fail-closed 飞轮闭环：把每次运行的经验沉淀成可复用策略 并发编排规模 64 路 反封控存活率 94.6% 策略晋升速度 37 条/周 对标胜率提升 +21.4 个百分点 浏览器 3D 装载模拟器，AABB 物理 + 多游戏变体，双轨：浏览器直开 + Electron 发布。
集装箱和卡车装载看起来是「能塞下就行」，但真实装载要同时满足体积利用率、承重限制和轴荷分布——货堆得再满，只要重心和轴荷分布不均，出库照样被判超载或侧翻风险。多数装载类游戏只做视觉堆叠，不做真实碰撞和承重校验，画面看着满，其实「装不上车」。
Cargo 3D 用 AABB（轴对齐包围盒）做碰撞与堆叠的核心判据：每件货物入位前先对全场景做 AABB 相交测试，通不过就拒绝摆放，保证任何一个画面状态都是物理自洽、零穿插的合法装载。在此之上叠了限时挑战、自由摆放、AI 对抗等多套变体，并把体积利用率、载重、轴荷分布做成实时量规——超重和偏载会当场触发告警，而不是等结算才发现。内置 AI 对手走同一套装载引擎评分，为了不在长局或边界状态卡死，配了三道防卡死闸门：超时强制落子、无解重排、异常回退。发布走双轨：源码 file:// 双击直接玩，Electron 只是同一套代码的打包发布形态，不额外分叉逻辑。
40 尺高柜标准测试箱型下，AABB 装箱算法的基准局平均体积利用率做到 87.3%；内部 500 局随机测试里，全场景 AABB 相交检测零漏判，没有出现一次穿插；三道防卡死闸门联测 1000 局长局压测，零超时卡死；货物入位到超载 / 偏载告警触发，轴荷校验做到同一渲染帧内完成。
利用率数字好看不难，难的是每一局都物理自洽——AABB 校验和轴荷量规不是结算画面上的装饰，是每一次摆放都要先过的硬闸门。三道防卡死闸门也是同一个原则的延伸：宁可让 AI 对手在边界情况下提前认输退出，也不让它卡死拖垮整局。
AABB 碰撞与堆叠物理 多种游戏模式与变体 内置 AI 对手，配三道防卡死闸门 体积利用率 87.3% 碰撞校验 0 次穿插 AI 对手防卡死 0 次卡死 轴荷告警延迟 0 帧 中英双语企业官网，深色「仪器」设计系统、自研生成式热流 Hero、代码级视觉自检流水线。
朗福是一家节能环保企业，它的官网要同时服务中文和英文两类客户，又不能沦为一套「模板套皮」的展示页——它得像公司交付的工程一样，经得起细看。
我把整站按「单一数据源」立骨：色彩、字体、文案、组件各自集中定义、统一引入，深浅主题只是一次 token 翻转；中英双语走成对路由，每一页两种语言严格对齐。首屏 Hero 不套现成库，自研了一套生成式热流，让它是「活的仪器」而不是一张静态大图。
站点上线在香港服务器，由 Caddy 自动签发并续期 HTTPS；桌面版 Lighthouse 的性能、无障碍、最佳实践、SEO 四项均为满分。更要紧的是把「好看」变成可回归的工程——一条 Playwright 视觉流水线在每次构建时自动拦截重叠、溢出、坏图、数字归零，肉眼会漏的版面事故，代码先一步拦下。
单一数据源架构：色彩 / 字体 / 文案 / 组件集中定义，AI 可无脑维护 Playwright 视觉守门：重叠、溢出、坏图、数字归零自动拦截 深浅主题 token 翻转，一处定义、全站适配 Lighthouse 四项 100×4 全站双语 2 语 深浅主题 1 处 视觉守门 4 类 这套纪律不是一次性的。你正在看的 Kikoman，正是这套设计内核的一次 fork 与再主题化——同一副骨架，换掉品牌色与内容，几处 token 就长成了另一个站。工程纪律在这里第一次证明了它是可迁移的资产，而不只是一个项目的收尾。
fork 全记录 · 把一套设计系统 fork 成另一个站
langfusave.com
用交互式终端统管多个 Claude Code 实例的 Electron 启动器，核心流程已端到端验证。
同时开着好几个 Claude Code 会话跑不同任务，是这套工作流里的日常——但原生方式就是开一堆独立终端窗口，谁在跑、跑了多久、有没有卡住，全靠人工切窗口去看。会话一多，管理成本比任务本身还高。
CC Launcher 用 node-pty 派生真正的 PTY 会话，而不是套壳假终端——每个实例都是完整的交互式终端，输入输出行为和直接开终端一致，不会因为「伪终端」丢功能，比如交互式确认、颜色、控制字符。Launcher 本体是 Electron 外壳，统一管理多路会话：实例表汇总 PID、状态、运行时长、CPU 占用，可一键新建 / 终止 / 重启；系统托盘常驻，支持开机自启，把「这堆终端还活着吗」变成一眼能看到的状态，而不是逐个切窗口确认。核心流程——启动、多实例并发、异常退出回收——走 e2e 测试闭环，改动先过测试再发布。
单机 e2e 压测下，同时存活的 PTY 会话数做到 16 路，CPU 和内存都没有异常增长；e2e 测试集覆盖的进程崩溃 / 信号中断场景，自动回收率做到 100%；启动、多开、终止、托盘、自启五项核心流程各有对应的端到端自动化测试；实例表从进程事件到 UI 刷新的状态延迟实测在 200 毫秒以内。
这类工具的价值不在界面好看，而在「我确实能信任这块状态面板」——所以核心流程全部锁进 e2e 测试，而不是靠人工点几下觉得没问题。下一步是把资源占用可视化和异常告警做得更细，而不是继续堆新功能。
基于 node-pty 的真实交互式终端 统管多实例 / 托盘 / 自启 端到端测试闭环 并发实例上限 16 路 异常退出回收率 100% 核心流程测试 5 项 e2e 会话状态刷新延迟 <200ms 你好，这里是 Kikoman 2026年6月20日 · 随笔
为什么我开了这个博客——以及一套反复验证的判断框架：新能力该买、该 fork，还是该自研。
我做全栈，工作里什么栈都碰：前端、后端、移动、桌面、AI。东西做多了，
最值钱的往往不是某个具体实现，而是一套能复用的判断 ——什么该买、什么该 fork、什么必须自研。
这个博客就用来记这些判断，而不是记流水账。
三个问题，不是三选一
拿到一个新需求，我很少直接打开编辑器。先问三件事：这个能力有没有现成、够成熟的方案？
如果有，改造它比重写它便宜多少？如果没有，缺的是「能力本身」，还是只缺「贴我这套系统的皮」？
三个问题对应三条路，但它们不是并列选项，是一个漏斗：
买 ：能力是通用的，别人已经把边界情况踩过一遍。字体子集工具、浏览器自动化框架、支付网关，
这些我都直接用现成的——自己写一个只是重新踩别人踩过的坑。fork ：内核已经在别处验证过，只是外壳 (品牌、内容、局部逻辑) 要换。这是最容易被低估的
一条路，因为它看起来不算「自己的工作」，但它是杠杆最大的一条。自研 ：没有现成方案能满足约束，或者这套东西本身就是我要交付的能力。这条路最贵，
只在前两条走不通时才该走。
一个真实例子：从朗福到 Kikoman
朗福是一家节能环保企业，官网的约束很具体：中英双语、深色「仪器」风格设计系统、首屏是一套
自研的生成式效果而不是套模板。这套约束在开源世界里找不到现成组件，所以那一次是彻头彻尾的
自研：色彩、字体、文案、组件全部按单一数据源立骨，深浅主题一次 token 翻转，视觉回归靠
Playwright 自动抓拦。
你现在看的这个站没有重复这个过程。Kikoman 是朗福那套内核的一次 fork ：内核该验证的都
验证过了 (单一源架构、双语路由、视觉守门流水线)，要换的只是品牌色和内容——霓虹紫替掉了
原来的橙色信号系统，文案换成我自己的东西。如果我把 Kikoman 当成一个新项目从零自研，多花的
时间不会换来更好的站，只会重新证明一遍朗福已经证明过的东西。
判断本身才是资产
具体实现会过时——框架会换、审美会变、需求会迭代。但「什么时候买、什么时候 fork、什么时候
自研」这套判断标准，换十个项目也还是同一套。这个博客记的就是这些判断，以及我在什么情况下
判断错了。
写得不一定勤，但尽量只写有信息量的。
Kikoman 这个站不是从零写的 —— 它是我另一个项目设计内核的一次 fork 加再主题化。
做 Kikoman 这个个人站时，我没有从空白页开始。我把朗福官网那套设计内核整个搬了过来，
只换了品牌色 和内容 ——这篇记录这次 fork 具体做了什么、哪里顺利、哪里不顺利。
fork 不是复制粘贴
复制一份代码库然后到处替换字符串，那是「复制」，不是「fork」。真正的 fork 是把内核当成
一个已经验证过的系统去搬运：架构决策不动，只换外壳。这也是为什么 fork 之前那套内核必须先
立在「单一数据源」上——颜色全在 CSS token 里、文案全在 i18n 表里、组件不写死任何字符串——
不然「只换外壳」就是一句空话，实际上要满仓库找哪里还藏着一个没被发现的硬编码。
三个文件，加一个例外
朗福内核的绝大部分换皮工作确实只落在三处：色彩 token、i18n 文案表、site 配置。原站是橙色的
「热」信号系统，Kikoman 换成霓虹紫：
--color-signal: #a855f7; /* 一处定义 */ 改完这一行，全站的链接、激活态、CTA、Hero 效果全部跟着变，因为它们都读同一个 token，
没有第二处硬编码需要手动追。
但 fork 过程也确实揪出了一个漏网之鱼：生成 OG 分享图的脚本 (scripts/make-og.mjs) 是一段
跑在 Node 里、直接拼 SVG 字符串再用 sharp 转成 JPEG 的独立脚本，它不 import 任何 token
文件，颜色是在字符串模板里手抄的十六进制。这一处没法靠改一个 token 联动，得手动把十六进制
值换成新色板。这恰恰是 fork 最有用的地方：它不会说谎——真的做一次搬迁，才知道「单一数据源」
哪里是真的、哪里只是看起来是。
收获
最大的体会：纪律不是负担，是杠杆，但杠杆有多长要靠 fork 一次才能量出来 。前期把单一数据源、
视觉自检做扎实，后期复用时一个完整的站几小时就能立起来；没做到位的那一小撮硬编码，也只有
真的 fork 一次才会浮出水面——留着继续记账，下次 fork 时先补上。
这次 fork 的源项目在本站有完整的 case study：朗福官网 ——
这套内核的真身外链也挂在那里。
我是 Kikoman，一个全栈开发者。技术栈跟着项目走——前端、后端、桌面、AI，什么能把事情做成就用什么。
比起记住某个框架的 API，我更在意一套能复用的判断：什么直接用现成的、什么改一改、什么必须自己写。
我喜欢把复杂的系统收敛成顺手好用的工具，并且把它们做得足够规整——规整到连 AI 都能接手维护。
2026 设计系统内核做了一套可迁移的双语设计内核 (单一数据源 + 视觉自检),并 fork 成了这个站。 2026 自主 AI 系统Jarvis 与 AI Browser Stack:以「内核」为中心，让系统自己感知、核验、进化。 2026 生成式视频Doodlecast:程序化世界 + 成片流水线，目标是脚本到长视频的端到端生成。 2025 3D 与桌面Cargo 3D 游戏与 CC Launcher 启动器：物理、Electron、交互式终端。 前端 React / Astro / Tailwind / TypeScript / GSAP 后端 Node / Python / REST / SQLite / Postgres AI LLM 应用 / Agent / RAG / 提示工程 桌面 & 3D Electron / Three.js / node-pty 工程化 设计系统 / 视觉自检 / CI / 部署 有项目想聊聊,或者只是想打个招呼,都可以找我。
l2539527429@gmail.com
