守株阁

JSONC 是什么？ JSONC（JSON with Comments）是 JSON 的一个扩展格式，允许在 JSON 数据中添加注释。这个规范由 jsonc.org 定义，旨在形式化一种在实践中广泛使用但缺乏正式标准的格式。 起源与背景 JSONC 格式最初由微软非正式地引入，用于 VS Code 的配置文件，包括： settings.json - 编辑器设置 launch.json - 调试配置 tasks.json - 任务配置 伴随着这种非正式格式，微软发布了一个公开可用的解析器 jsonc-parser。JSONC 规范的目标是将 JSONC 格式形式化，定义 jsonc-parser 在默认配置下认为有效的内容。 语法规则 JSONC 遵循与 JSON 相同的语法规则，并额外支持 JavaScript 风格的注释。 单行注释 单行注释以 // 开始，延伸到行尾： 12345{ // 这是单行注释 "name": "John Doe", "age": 30} 多行注释 多行注释以 ...

QMD：本地智能文档搜索引擎完全指南 引言：你的知识库需要一把钥匙 作为程序员、写作者或知识工作者，我们每天都在产生大量的 Markdown 文档——技术笔记、会议记录、项目文档、博客草稿……这些文档散落在不同的文件夹中，随着时间推移，它们变成了"数字废墟"：你知道某篇笔记一定存在，却怎么也找不到。 传统的文件搜索工具（如 Spotlight、grep）只能基于文件名或关键词匹配，无法理解语义。而云端笔记工具（如 Notion、Obsidian）虽然提供了搜索功能，却存在数据隐私和访问限制的问题。 QMD（Query Markup Documents） 正是为了解决这个痛点而生的——一个完全本地运行的智能文档搜索引擎，它结合了 BM25 全文检索、向量语义搜索和 LLM 重排序，让你能够用自然语言快速找到任何文档中的任何内容。 一、QMD 是什么 QMD 是一个开源的 CLI 工具 + 库，由 @tobi 开发，专为 Markdown 文档设计。它的核心特性包括： 特性 说明 完全本地 所有数据和模型都在本地运行，无需联网 混合搜索 BM2...

在实践 SDD（语义驱动开发）的过程中，一个常见的困惑是：AGENTS.md、CLAUDE.md 和 rules/ 目录三者之间的边界和协作关系为何？ 这些配置文件均为 AI 服务的项目级配置，但承担着截然不同的职责。本文通过一个实际案例，阐述这三者的核心区别与适用场景。 这三者并非递进的"高低层次"，而是三个不同维度的配置：从宏观的多 Agent 协作框架（AGENTS.md），到单个 Agent 的个体行为规范（CLAUDE.md），再到细粒度的场景应对规则（rules/）。理解它们各自解决的问题，是正确使用 SDD 工具链的前提。 一、问题的由来：配置文件的"命名困惑" 在使用 OhMyOpenCode（OMO）时，执行 /init 命令后会生成一个 AGENTS.md 文件。这引发了以下问题： “AGENTS.md 与 Claude Code 的 CLAUDE.md 有何区别？” “项目级的 rules/ 目录承担什么职责？” “这三者是互斥关系还是互补关系？” 这些问题的核心在于：AI 编程工具的配置体系缺乏统一的标准，不同...

AI 编程工具的演进，正在经历一次根本性的范式转变：从"补全光标处的代码"，到"自主完成端到端工程任务"。这种转变有一个专有名词——Agentic Coding。 理解这个转变，需要从三个层面展开：工具层（OpenCode 的能力边界）、框架层（多 Agent 协作编排）、方法论层（如何让 Agent 真正服务于工程流程）。 什么是 Agentic Coding 传统 AI 编程助手的工作模式是响应式的：开发者提问，AI 回答；开发者选中代码，AI 补全。人始终是执行者，AI 是辅助工具。 Agentic Coding 的工作模式是自主式的：开发者描述目标，Agent 自主规划步骤、调用工具、执行操作、验证结果，直到任务完成。人退出执行循环，成为目标定义者和结果审查者。 这不是量变，是质变。一个能够自主编码的 Agent，需要具备： 代码理解能力：不只是文本匹配，而是理解代码的语义结构、类型关系、调用链路 工具调用能力：读写文件、执行命令、调用外部 API 规划与反馈能力：将大任务分解为步骤，根据执行结果调整计划 上下文管理能力：在有限的...

LSP：语言服务协议与AI编程助手的代码理解能力 早期的 AI 编程工具，本质上是在做文本替换：把代码当作字符串，在字符串层面做补全、修改、搜索。这种方式有一个根本缺陷——它不理解代码的结构。 一段 Java 代码里，UserService 是一个类，findById 是它的方法，返回类型是 Optional<User>。文本替换工具看到的只是这些字符；而一个真正理解代码的工具，能够知道： findById 的参数类型是 Long，不是 String 调用这个方法的地方有 12 处，分布在 5 个文件里 如果修改了方法签名，哪些调用点会编译失败 这种理解能力，来自 LSP（Language Server Protocol）。 LSP 是什么 LSP 是微软在 2016 年提出的协议（Language Server Protocol 官方规范），目的是把"语言智能"从编辑器中解耦出来。 在 LSP 出现之前，每个编辑器都要为每种语言单独实现代码补全、跳转定义、查找引用等功能。VS Code 要实现一套，Vim 要实现一套，Emacs 要实现一套—...

最近在思考一个问题：AI 编程工具的真正价值是什么？不是"让机器替代人"，而是让人工作在更高的抽象层次上。这个认知转变，带出了一系列关于人机协作、Agent 架构设计的思考。 一、从 Vibe Coding 到 SDD：一个被误解的问题 2024-2025 年，AI 编程助手的爆发带来了一个新词汇——Vibe Coding（基于感觉的编程）。开发者与 AI 对话，AI 即时生成代码，看起来效率惊人。 但这里有一个被普遍忽视的根本矛盾： Vibe Coding 优化的是"个人编码效率"，但工程的真正瓶颈是"团队协作效率"。 一个人写代码快 10 倍，但团队沟通成本不变，整体效率提升极为有限。更糟的是，Vibe Coding 在协作层面制造了新的麻烦： PM ↔ 研发：对话历史无法作为契约，验收时各执一词，“这不是我要的” 前端 ↔ 后端：各自 vibe，联调时才发现接口格式对不上，浪费 1-2 天 后端 ↔ 后端：订单服务调用 POST /inventory/deduct，库存服务只有 PUT /stock/red...

AI 编程助手 Quest 1.0：把执行交给 AI，把选择留给人类 核心理念：人类“品味”是人机协作的终极壁垒 “品味” ≠ 审美，而是决策力：在众多可行方案中判断“哪个是对的选择”，尤其体现为“选择不做”（如舍弃文件树导航，拒绝向下兼容）。 AI 擅长执行与优化，但缺乏责任意识与经验直觉；人类凭借踩坑记忆、业务理解与后果承担能力，守住质量、边界与必要性底线。 “品味”是未来人类区别于 AI 的核心差异，也是 AI Coding 中 human-in-the-loop 不可替代的价值。 Quest 1.0 的关键升级：为 SOTA 而生，专注"自主编程" 架构定位：专为当前最优（SOTA）大模型（如 Claude Opus/Codex/Gemini）深度优化，不兼容旧模型、不提供模型切换选项，追求 Token 效率与产物质量极致。 交互范式革新： ✅ 舍弃代码导航 → 转向“阅读意图”（Spec/测试/结果），代码降级为“中间产物”； ✅ 对话窗口为主视图 → 降低非专业开发者门槛，同时打破研发者技术栈认知边界（如后端工程师无需懂前端即可驱动前端开发...

Git基础.xmind 初始化命令 配置用户、remote 和 branch 123456789101112131415161718192021222324252627282930313233343536git config --global user.name "magicliang" # 请换成你自己的名字git config --global user.email "magicliang@qq.com" # 请换成你自己的邮箱git config --global push.default simple # 我们要求 Git 版本 1.9.5 以上git config --global core.autocrlf false # 让Git不要管 Windows/Unix 换行符转换的事git config --global --listssh git@gitlab.abcgit initgit add .git commit -m "First commit&qu...

Gradle 完全指南 全景导图 mindmap root((Gradle)) 核心概念 Project模型 Task系统 生命周期 插件机制 依赖管理 Configuration 依赖解析 版本冲突 传递依赖 构建脚本 Groovy DSL Kotlin DSL 多项目构建 插件生态 Java插件 Spring Boot插件 自定义插件 性能优化 构建缓存 并行构建 增量构建 测试管理 单元测试 集成测试 覆盖率 什么是 Gradle Gradle 是新一代的自动化构建工具，基于 Apache Ant 和 Apache Maven 的概念发展而来。与 Maven 使用 XML 配置不同，Gradle 采用基于 Groovy 或 Kotlin 的领域特定语言（DSL）来声明项目配置，大幅简化了...

当智能体变成一份 Markdown 文档 在传统的软件工程中，构建一个"智能体"（Agent）意味着编写大量代码：状态机、决策树、API 集成、错误处理、权限管理。而在 LLM（Large Language Model，大语言模型）时代，定义一个功能完备的 AI 智能体，可能只需要一份结构良好的 Markdown 文档。 这不是夸张。以 Claude Code 的配置体系为例，一个 .md 文件可以定义 Agent 的身份、行为约束、工具权限、专业知识、工作流程，甚至跨会话的持久记忆（Persistent Memory）。但要真正理解"为什么 Markdown 就够了"，以及"如何写出高效的 Agent 定义"，需要先回到第一性原理——理解 LLM 的本质、Agent 的运行机制，以及上下文窗口（Context Window）的物理约束。 本文将从底层原理出发，逐层构建对 Agentic Coding 的完整认知：先理解 LLM 是什么、Agent Loop 如何运转、上下文窗口为何是核心瓶颈；再拆解 Markdown ...