AI Native Dev - Claude Code Core Mode
Agent 通用语言 上下文注入 Shell 执行 结构化交互 清晰表达意图、更高效地提供上下文,并授权 AI Agent 采取行动 一个设计精良的 Agent,其目标是降低用户的认知负荷,并不要求用户成为提示词大师 提供一套简洁而强大的交互模型,能够轻松地表达复杂的工程意图 Claude Code 的核心交互模型,是建立在两个极其简单却异常强大的符号之上:@ 和 ! 深刻的人机协作哲学 - 所有高级 Coding Agent 对话的通用语言 符号 语义 @ 代表上下文 - Context - 精确的、可追溯的、结构化的指令 ! 代表行动 - Action - 无缝融入到对话流中 @ 用法 描述 引用单个文件 最精准的上下文 - 代码解释 + 生成单元测试 引用整个目录 开启上帝视角 让 Claude Code 看到引入一个目录时,并不会把所有文件的内容都无脑塞进上下文,而是非常智能 默认情况下,@ 指令是 Git 感知的 自动查找并读取项目根目录下的 .gitignore 文件 Claude Code 在遍历目录时,自动忽略所有匹配 .giti...
AI Native Dev - Claude Code
CLI Agent AI 原生开发的最佳载体 - 执行深度 + 集成自由度 能力边界 不同 AI 交互形态的能力边界 像 Cursor 和 GitHub Copilot 这样的 L2 工具也在快速进化,推出 Agent 模式 在 IDE 内部提供了更强的上下文感知和自动化能力 与 Claude Code 这类真正的命令行原生智能体相比 最核心的区别:执行环境的受限 Cursor 和 GitHub Copilot 的行动被绑定在了运行了 IDE 的本地开发环境中 而一个真正的 CLI Agent,则是可以被部署到任何目标环境中 包括但不限于:服务器、CI Runner、Docker 容器 原生工作流智能体 CLI AI Agent - L3/L4 成熟度,与开发者共享终端 一切皆文件、一切即可由命令驱动 拥有无与伦比的集成自由度和执行深度 优势 描述 完全的环境感知 可以使用 ls tree git 等命令,来全面地理解一个项目 无限制的行动能力 理论上,CLI Agent 在被授权后,可以执行任何 Shell 命令可以参与到开发、测试、构建、部署...
AI Native Dev - SDD
权力反转 代码服务于规范,前提是规范是可被机器精确理解和执行的 编译意图 由 AI 驱动,将高层级、模糊的、非结构化的人类意图,逐步转换、细化,并最终固化为低层架、精确的、结构化的机器可执行指令 Stage Desc 需求编译器 将用自然语言描述的模糊想法,编译成一份结构化的、无歧义的需求规范 spec.md 方案编译器 将需求规范与技术约束相结合,编译成一份详尽的技术实现蓝图 plan.md 任务编译器 将技术蓝图,编译成一份带依赖关系的,原子化的任务指令集 tasks.md 代码生成器 最终,根据任务指令集,生成最终的可执行代码 SDD - 为 AI 的多阶段编译过程提供高质量的源代码(规范),并监督每一步编译的结果 工作流阶段 1 - 意图定义 Key Value 目标 澄清并固化做什么(WHAT)和为什么做(WHY) 输入 开发者或产品经理提出的高层级、模糊的自然语言想法 核心活动 人机协作进行头脑风暴,挖掘边缘场景,澄清模糊地带,定义验收标准 输出产物 spec.md 需求规范与技术实现完全解耦,只关心用户故事、功能需求和成功标准...
Observability - Prometheus Server V1
OpenTelemetry vs Prometheus123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106关系概述:互补为主,渐趋融合OpenTelemetry 和 Prometheus 在指标领域主要是互补关系,而非冲突。两个项目都在积极合作以实现更好的互操作性。1. 定位差异Prometheus:- 完整的监控系统(采集、存储、查询、告警)- 专注于指标监控- 拉模型(Pull-based)为主- 拥有成熟的时序数据库和查询语言 PromQLOpenTelemetry:- 标准化的遥测数据收集框架- 支持三大信号:指标、追踪、日志- 推模型(Push-based)为主- 不提供存储和查询后端2. 技术模型对比| 特性 | Promet...
Observability - Prometheus Concepts
Data model Prometheus fundamentally stores all data as time series streams of timestamped values belonging to the same metric and the same set of labeled dimensions. Besides stored time series, Prometheus may generate temporary derived time series as the result of queries. Metric names and labelsEvery time series is uniquely identified by its metric name and optional key-value pairs called labels. Metric names Metric names SHOULD specify the general feature of a system that is measured e.g. http_req...
Observability - Prometheus Introduction
Summary Open source metrics and monitoring for your systems and services. Monitor your applications, systems, and services with the leading open source monitoring solution. Instrument, collect, store, and query your metrics for alerting, dashboarding, and other use cases. Feature Desc Dimensional data model Prometheus models time series in a flexible dimensional data model.Time series are identified by a metric name and a set of key-value pairs. Powerful queries The PromQL query language allow...
Observability - OpenTelemetry Java Zero Code
Java Agent Zero-code instrumentation with Java uses a Java agent JAR attached to any Java 8+ application. It dynamically injects bytecode to capture telemetry from many popular libraries and frameworks. It can be used to capture telemetry data at the “edges” of an app or service such as inbound requests, outbound HTTP calls, database calls, and so on. Getting startedSetup Download opentelemetry-javaagent.jar from Releases of the opentelemetry-java-instrumentation repository place the JAR in your pre...
Observability - OpenTelemetry Java
Intro to OpenTelemetry Java OpenTelemetry Java is the set of OpenTelemetry observability tools for the Java ecosystem. At a high level, it consists of the API, the SDK, and instrumentation. Overview The API is a set of classes and interfaces for recording telemetry across key observability signals. It supports multiple implementations, with a low-overhead minimalist Noop and SDK reference implementation provided out of the box. It is designed to be taken as a direct dependency by libraries, framewor...
AI Agent - MCP Overview
提示工程 + RAG LLM 可以开箱即用,通过提示工程和它直接对话并解决问题 随着 LLM 的能力越来越强,尤其是其推理模型的出现,LLM 的回答越来越准确 但 LLM 并非全知全能,预训练的数据有截止时间 - RAG RAG 是一种 LLM 应用开发范式 将 LLM 与外部数据源相结合来提高准确性和相关性 先通过向量之间的相似度,用检索系统从外部数据源搜索数据,以识别与用户查询相关的信息 LLM 随后利用检索到信息生成更精确,更及时的响应 RAG 过程 - 通过 RAG 增加 LLM 的知识,大大提高了 LLM 回答的准确性和相关性 Key Value 检索 通过向量数据库或者其它检索系统,找出与用户查询相关的信息 增强 将检索到的信息作为上下文提供给 LLM 生成 LLM 基于这些额外信息生成回答 Agent + Tool Call RAG 解决的是让 LLM 使用内部知识,同时减少幻觉的问题,但 RAG 本身并没有增强 LLM 的行动能力 - Agent Agent 本质上是赋予 LLM 使用工具并采取行动的开发范式 Agent 的工作流程 K...
AI Agent - Overview
技术更迭 LLM 应用工程化难题 模型与外部世界割裂 LLM 是基于概率计算的新范式,虽然很强大,但仍需要与传统的结构化计算范式相结合,即通过工具调用来完成精确任务 目前传统结构化工具与 LLM 之间是割裂的,LLM 难以直接动态地接入实时数据、数据库或企业工具 传统的 API 调用方式零散且不标准,导致开发效率低下 Agent 协作的孤岛效应 不同 Agent 框架(LangGraph、AutoGen、CrewAI)各自为政,缺乏统一的通信标准,跨平台协作很难实现 复杂场景的工程化瓶颈 从搜索助手到企业知识中台、RAG 与多 Agent 系统需要处理多源数据、多模态交互和长时任务,现有工具链难以提供统一的解决方案 MCP + A2A 标准化 + 可扩展 MCP 模型主控 + 客户端驱动 MCP 是一个为 LLM 更方便地利用外部资源(主要是工具)而设计的标准化接口,旨在打破 LLM 与外部数据、工具之间的壁垒 传统上,将 AI 系统连接到外部工具需要集成多个 API - 代码冗余 + 难以维护 + 扩展性差 MCP 将繁琐细节都隐藏到服务器端 - 开发者只需关心 LLM...










