Posts on LinyingBlog

Tongue 舌象分析管理系统

Mon, 22 Jun 2026 16:48:22 +0800

访问在线演示

系统概览

该系统专注于舌象数据的结构化管理，现阶段重点是稳定沉淀结构化训练资产，为后续算法训练与模型接入做准备。

核心模块

1. 主页

主页展示舌象数据集工作流的全局状态：

图片总数：已上传的舌象图片数量
待处理：等待预处理的图片数量
已完成预处理：已预处理完成的图片数量
导出数据集数：已导出的训练数据集数量

数据概览包含训练资产沉淀的进度指标：

指标	说明
预处理完成率	标准图可用于后续标注和训练导出
待处理占比	用于判断当前图片预处理阻塞情况
已导出数据集	沉淀为后续模型训练的基础资产

2. 图片管理

图片管理模块提供完整的图片生命周期管理：

字段	说明
ID	图片唯一标识
图片名称	文件名
预处理状态	已完成 / 待处理
尺寸	图片分辨率
文件大小	图片文件体积
缩略图预览	预览图
上传时间	上传时间戳

操作功能：

预处理 - 对图片进行标准化处理
详情 - 查看图片详细信息
标注 - 进行人工标注
报告 - 生成分析报告
删除 - 移除图片

3. 数据导出

数据导出模块支持按多种维度筛选导出训练数据：

预处理状态
是否标注
是否复核
结构化标签

4. 任务中心

任务中心追踪所有图片预处理和数据集导出任务：

字段	说明
任务 ID	任务唯一标识
任务类型	如 preprocess
状态	任务执行状态
图片 ID	关联的图片
数据集 ID	关联的数据集
失败原因	任务失败时的错误信息
开始时间	任务开始时间
结束时间	任务结束时间

项目设计：wobushi041

Harness Engineering

Tue, 09 Jun 2026 20:30:00 +0800

从架构视角深入解读 Harness 的设计哲学，帮助工程师建立对现代 CI/CD 平台的认知框架

一、Harness 到底是什么

一句话：Harness 是一个构建在 Kubernetes 之上的、以 Delegate 为核心执行引擎的、SaaS 化的软件交付平台。

这句话里有三个关键词，每一个都值得展开。

1. 构建在 Kubernetes 之上

Harness 的控制平面（Control Plane）是一组微服务，运行在 Kubernetes 集群中。这意味着：

弹性伸缩是天然能力，不是事后补丁
多租户隔离通过 K8s 的 namespace 和资源配额实现
服务治理依赖 K8s 原生的服务发现和负载均衡

这不是什么了不起的事——几乎所有现代 SaaS 产品都跑在 K8s 上。但关键在于，Harness 把 K8s 的能力向下暴露给了用户：你的 Pipeline 可以直接操作 K8s 集群进行部署，而不是通过一层中间转换。

2. Delegate 是核心执行引擎（重点）

这是理解 Harness 最关键的一个概念。

Delegate 是一个运行在你基础设施中的进程，负责执行 Pipeline 中的所有任务。它不是 Harness 帮你跑的——它跑在你的环境里。

为什么要这样设计？因为软件交付涉及的操作，绝大多数都需要访问内网资源：代码仓库、制品库、K8s 集群、数据库、云账号。如果这些操作全部由 Harness 的 SaaS 控制平面来执行，就意味着你的内网资源必须对 Harness 开放——这在安全合规层面几乎不可接受。

Delegate 的架构解决了这个问题：

┌─────────────────────────────────────────────────────┐
│ Harness SaaS控制平面 │
│ (Pipeline 编排、状态管理、UI、API) │
└──────────────────────┬──────────────────────────────┘
 │ 出站连接（Delegate 主动拉取任务）
 │ ← 不需要入站端口暴露
┌──────────────────────▼──────────────────────────────┐
│ 你的基础设施 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Delegate │ │ Delegate │ │ Delegate │←可部署多个 │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌───▼───┐ ┌────▼───┐ ┌────▼───┐ │
│ │K8s集群 │ │代码仓库 │ │云账号 │ │
│ └───────┘ └────────┘ └────────┘ │
└─────────────────────────────────────────────────────┘

核心设计要点：

LLM Wiki：面向 Agent 工程的知识编译层

Mon, 01 Jun 2026 10:54:03 +0800

如果只先记住一个结论，那么可以记这句：

LLM wiki 不是“让 AI 帮你整理笔记”，而是把项目知识从原始资料提升为 Agent 可消费、可引用、可演化的知识中间层。

这个判断的关键在于，问题并不只是“资料有没有被存下来”，而是“资料是否已经被整理成 Agent 可以稳定工作的形状”。在这件事上，RAG 和 LLM wiki 处理的根本不是同一层问题。Andrej Karpathy 提出的 llm-wiki.md 范式给出的也不是一个笔记软件教程，而是一种把知识从原始材料编译成可维护工作上下文的思路。

本文想讨论的是三个问题：

LLM wiki 到底是什么
它和 RAG 的边界到底在哪里
如果要把它落到工程实践里，最小实现应该长什么样

1. Agent 真正缺的不是“更多文档”，而是知识编译层

很多仓库并不缺文档。

README、ADR、issue、PR、聊天记录、代码注释、发布记录，甚至临时会议纪要，往往已经足够多。问题在于，这些材料大多是围绕“人怎么理解系统”自然长出来的，而不是围绕“Agent 应该如何进入系统、命名概念、定位事实、拼装上下文”组织出来的。

这会带来几个很典型的摩擦：

资料很多，但没有稳定入口
术语存在，但定义分散甚至漂移
同一个问题需要每次重新检索和重新拼接上下文
原始资料适合追溯事实，不适合直接充当工作层

所以 LLM wiki 试图解决的，不是“把一堆东西再存一遍”，而是另一件更具体的事：

它的价值不在存储，而在预编译；不在收集，而在把知识变成可持续复用的中间表示。

Karpathy 在原始 gist 里把这件事描述得很清楚：系统并不直接依赖原始材料回答问题，而是先把原始材料经过整理，沉淀成持续更新的 wiki 层，并由 schema 约束其结构与工作流，再把它作为后续查询和工作的主上下文层。来源

2. 与 RAG 的绝对区分：一个是运行时召回，一个是离线知识编译

很多讨论会把 LLM wiki 和 RAG 混在一起，但这两者并不是同义替换。

RAG 的经典定义来自 Lewis 等人的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks：模型在生成前，先从外部知识源检索相关内容，再把检索结果并入生成过程。论文链接

Superpowers 使用指南

Sat, 30 May 2026 20:30:00 +0800

如果只先记住一个结论，那么可以记这句：

Superpowers 不是单纯的“代码增强插件”，而是一套把软件开发最佳实践内化为可执行工作流的方法论插件。

它的价值不在于“帮你多补几行代码”，而在于通过一组技能系统，把设计、计划、执行、测试、审查、调试和收尾这些环节串成一个更稳定的开发闭环。

本文会系统回答几个问题：

Superpowers 到底是什么
它和普通代码辅助工具有什么本质区别
它的完整工作流怎么跑
什么时候该自动触发，什么时候适合手动调用
使用中最容易踩的坑是什么

1. Superpowers 到底是什么

Superpowers 是一个面向 Claude Code 的开发流程插件。它不是把一堆零散命令简单打包，而是把软件工程中的一整套高质量实践，组织成可自动触发、可组合、可审查的工作流。

和常见“你提需求，我给代码”的工具相比，它有几个明显不同点：

它会优先帮助你澄清需求，而不是立刻开写
它强调计划拆解，而不是一次性生成大段实现
它默认引入 TDD、代码审查和系统化调试
它允许通过子代理并行处理任务
它把“验证是否真的完成”看得和“写出代码”同样重要

换句话说，Superpowers 关注的不只是产出代码，而是产出一个更可控、更可验证的开发过程。

2. 核心理念是什么

Superpowers 背后最重要的不是某个命令，而是它坚持的几条工程原则。

2.1 测试驱动开发优先

它默认推崇 TDD，也就是经典的 RED -> GREEN -> REFACTOR 循环：

先写一个失败的测试
再写最少的代码让测试通过
最后在测试保护下重构

这会强迫开发从“想当然实现”切换到“先定义预期行为，再补实现”。

2.2 系统化优于临时应对

遇到问题时，它更倾向于：

明确定位问题
收集证据
找根因
用流程和验证收束结果

而不是简单地“试一下这个改法能不能过”。

2.3 简单性优先于复杂炫技

Superpowers 的方法论倾向非常明确：复杂度不是能力的证明，能把问题拆到足够小、足够清楚，才是真正可维护的工程能力。

2.4 验证优先于宣称

“已经修好了”“应该可以了”“理论上没问题”这类表述，在它的工作流里都不算真正完成。必须通过测试、审查、验证或复现消除，结果才算站得住。

3. 它和普通代码辅助工具有什么不同

可以用下面这张表快速理解它的定位：

维度	普通代码辅助工具	Superpowers
主要目标	更快生成代码	更稳地完成完整开发流程
默认行为	直接根据需求写实现	先设计、再计划、再执行
测试态度	可有可无	默认强制引入 TDD
代码审查	往往依赖人工补充	工作流内建审查机制
调试方式	偏经验式试错	强调系统化根因分析
适用对象	单次编码任务	需要流程质量保证的开发任务

所以，Superpowers 更像是“开发过程的组织者”，而不只是“生成代码的助手”。

Docker 学习笔记

Fri, 19 Dec 2025 23:19:15 +0800

这篇文章是一份面向个人工程实践的 Docker 入门整理，重点记录 Docker、Dockerfile、Docker Compose，以及它们在 Windows + WSL2 环境下的实际工作方式。

文章定位

这不是一篇面向生产环境的完整 Docker 手册，而是一份偏向个人工程实践的入门梳理，目标是把几个最常见但最容易混淆的问题讲清楚：

Docker 到底是什么
Dockerfile 和 Docker Compose 分别解决什么问题
Windows + WSL2 下 Docker 到底运行在哪里
一个前后端项目如何通过 Compose 完成部署

参考资料

Docker 教程视频

Docker 是什么

Docker 是基于 Linux 内核能力实现的容器技术，核心依赖包括命名空间（Namespaces）和控制组（cgroups）。它的本质不是“轻量虚拟机”，而是运行在宿主机 Linux 内核之上的隔离用户态环境。

因此，Docker 容器具备这些特征：

有自己的文件系统视图，例如 /bin、/etc、/usr、/app
可以运行 Linux 用户态程序，例如 sh、java、ls
不拥有独立内核，而是共享宿主机内核
更适合描述为“进程级隔离环境”，而不是真正意义上的虚拟机

一句话理解：

容器负责隔离运行环境，镜像负责定义运行环境。

Windows + WSL2 下的 Docker 运行方式

在 Windows 环境中，Docker 并不是“直接跑在 Windows 内核上”。Docker Desktop 实际依赖的是 WSL2 提供的 Linux 内核环境。