DOCSEARCHbyAlgolia
Submit Docs

Junki Technical Blog

website·Indexed 31 days ago

https://junki.cn

A technical blog featuring deep dives into AI agents, LLM architectures, and software engineering. Content covers Claude Code, Model Context Protocol (MCP), Spring AI Alibaba, DeepSeek, and practical guides on Kubernetes, Nginx, and Java development.

Tokens
79.2K
Snippets
320
Records
515
Agent score
60%

What's inside Junki

  1. Overview of Redis persistence strategies

    Redis provides four primary persistence strategies to recover data after a crash:

    1. RDB (Redis Database): Performs point-in-time snapshots of the dataset at specified intervals.
    2. AOF (Append Only File): Records every write operation received by the server, which can be replayed on startup to reconstruct the original dataset.
    3. RDB + AOF: A combination of both strategies in a single instance.
    4. No Persistence: Persistence is completely disabled.

  2. Overview of ESLint MCP

    The ESLint MCP (Model Context Protocol) server allows Large Language Models (LLMs) in AI-integrated editors to directly call ESLint's code analysis capabilities. This enables AI agents to automate code specification checks, fix errors, and explain linting rules, reducing the manual effort required for maintaining code quality.

  3. Overview of DeepScaleR-1.5B-Preview

    DeepScaleR-1.5B-Preview is a model developed by a research team from UC Berkeley. It was created by applying simple reinforcement learning (RL) fine-tuning to the Deepseek-R1-Distilled-Qwen-1.5B base model. The project's dataset, code, and training logs are open-sourced.
    GitHub Repository: https://github.com/agentica-project/deepscaler

  4. Overview of CC Switch AI CLI Management Tool

    CC Switch is an open-source, cross-platform management tool designed for AI CLI tools like Claude Code, Codex, and Gemini CLI. It eliminates the need to manually edit configuration files by providing a unified interface for switching providers, managing MCP servers, handling system prompts, and managing skills extensions.

  5. Overview of Firecrawl for Web Search

    Firecrawl is an API service that crawls URLs and converts webpage content into standardized Markdown or structured data. It can crawl all accessible sub-pages without requiring a sitemap. Because it uses Playwright under the hood, it can be used to implement web search capabilities by crawling search engine result pages (e.g., Baidu).

  6. Overview of Node.js Docker Automation Deployment Architecture

    This deployment solution uses Node.js to automate the lifecycle of Docker containers on remote servers via SSH. The architecture consists of a local development machine running Node.js scripts that connect to a remote server's Docker runtime and pull images from a Docker Registry.
    ┌─────────────┐         SSH           ┌──────────────┐
│  本地开发机   │ ─────────────────────→│  远程服务器   │
│             │                       │              │
│ Node.js     │                       │  Docker      │
│ 部署脚本      │                       │  容器运行时   │
└─────────────┘                       └──────────────┘
       │                                      ↑
       │                                      │
       ↓                                      │
┌─────────────┐         Pull Image            │
│ Docker      │ ------------------------------┘
│ Registry    │
└─────────────┘

  7. Overview of Kev Decision Model

    Kev is an open-source decision model based on Qwen. Unlike standard LLMs that generate text token-by-token, Kev replaces the language output head with a 'PointerHead' decision head. This allows the model to directly output probabilities for a set of candidate options based on the input state, bypassing the computationally expensive text generation loop while still utilizing the Transformer backbone.

  8. Overview of Cache-to-Cache (C2C) for LLM Collaboration

    Cache-to-Cache (C2C) is a framework for direct semantic communication between two Large Language Models (LLMs). Instead of the traditional workflow where a 'source' model generates a text summary for a 'receiver' model to process, C2C allows the receiver model to directly utilize the internal computational state (KV Cache) of the source model. This is achieved through trainable conversion and fusion modules that adapt the tensor representations of one model to be compatible with another, reducing the overhead of generating and re-processing intermediate text.

  9. Overview of Sing-song encoding

    Sing-song is a reversible encoding scheme that converts arbitrary byte strings (such as hexadecimal keys) into speakable, easy-to-remember strings composed of "consonant-vowel" (CV) syllables. It is specifically designed for values that must be read aloud, spoken, or memorized by humans. Each syllable encodes exactly 6 bits using a 64-syllable alphabet, providing a balance between oral density and simplicity. Unlike Base58 or Hex, Sing-song prioritizes "oral density" (ease of speaking) over "writing density" (string length).

  10. Overview of Sing-song encoding

    Sing-song is a reversible encoding that transforms arbitrary byte strings into pronounceable 'Consonant-Vowel' (CV) syllables. It maps 6-bit values to a 64-syllable alphabet. The encoding is deterministic, reversible, and prefix-stable (identical input prefixes produce identical syllable prefixes). It preserves byte length and leading zero bytes without requiring external length metadata.

  11. Qwen2ForCausalLM Model Architecture Reference

    The Qwen2ForCausalLM architecture consists of an embedding layer, 28 decoder layers (each containing a self-attention mechanism with q, k, v, and o projections and an MLP with gate, up, and down projections), and a final linear language modeling head. It utilizes RMSNorm for normalization and LlamaRotaryEmbedding for positional encoding.
    Qwen2ForCausalLM(
  (model): Qwen2Model(
    (embed_tokens): Embedding(152064, 3584, padding_idx=151654)
    (layers): ModuleList(
      (0-27): 28 x Qwen2DecoderLayer(
        (self_attn): Qwen2Attention(
          (q_proj): Linear(in_features=3584, out_features=3584, bias=True)
          (k_proj): Linear(in_features=3584, out_features=512, bias=True)
          (v_proj): Linear(in_features=3584, out_features=512, bias=True)
          (o_proj): Linear(in_features=3584, out_features=3584, bias=False)
          (rotary_emb): LlamaRotaryEmbedding()
        )
        (mlp): Qwen2MLP(
          (gate_proj): Linear(in_features=3584, out_features=18944, bias=False)
          (up_proj): Linear(in_features=3584, out_features=18944, bias=False)
          (down_proj): Linear(in_features=18944, out_features=3584, bias=False)
          (act_fn): SiLU()
        )
        (input_layernorm): Qwen2RMSNorm((3584,), eps=1e-06)
        (post_attention_layernorm): Qwen2RMSNorm((3584,), eps=1e-06)
      )
    )
    (norm): Qwen2RMSNorm((3584,), eps=1e-06)
    (rotary_emb): LlamaRotaryEmbedding()
  )
  (lm_head): Linear(in_features=3584, out_features=152064, bias=False)
)

  12. Understand the Codex Skill concept

    A Skill is a persistent directory that acts as a 'job operation manual + toolbox' for Codex. Unlike standard prompts that only last for one conversation, a Skill is automatically loaded by Codex when a matching request is encountered. It is ideal for repetitive tasks, fixed operational sequences, internal company knowledge, stable script executions, and tasks requiring reusable templates or code skeletons.