守株阁

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 ...

JVM 的内存模型与线程 Java 内存模型（Java Memory Model, JMM）定义了多线程环境下共享变量的访问规则，是理解并发编程的基石。本文从硬件架构出发，逐步深入到 JMM 的核心机制与实践模式。 mindmap root((JMM)) 硬件基础 CPU缓存层次 缓存一致性协议 JMM 抽象 主内存 vs 工作内存 八种内存操作 happens-before 关系 关键保证 原子性 可见性 有序性 实践工具 volatile synchronized final 模式总览 # 模式名称 一句话口诀 适用场景 1 写刷读清 写入即刷盘，读取先清空 volatile / unlock 后的可见性 2 顺序锁 同把锁内，串行执行 synchronized 临界区保护 3 偏序传递 A先于B，B先于C，则A先于C happens-before 链式推理 4 不可变安全 构造完成前...

本文整合了 Maven 构建生命周期、插件配置、依赖管理、全局配置 settings.xml、FatJar 打包、测试与覆盖率等全部知识点，是一份系统性的 Maven 参考指南。 maven-生命周期.xmind 构建生命周期 构建生命周期的基础知识 Maven 基于一个"构建生命周期"的中心概念，也就意味着构建和发布一个特定的工件（也就是工程）的过程已经被清晰地定义了。 有三种内置的生命周期：default，clean 和 site。default 生命周期处理项目部署，clean 生命周期处理项目清理，site 生命周期处理项目的站点（site）文档的创建。 graph TD subgraph Clean生命周期 A1[pre-clean] --> A2[clean] A2 --> A3[post-clean] end subgraph Default生命周期 B1[validate] --> B2[initialize] B2 -->...

第1章：Docker 核心架构 Docker 是一种操作系统级别的虚拟化技术，它通过 Linux 内核的多项特性实现进程间的软隔离，而非传统虚拟机的硬件级虚拟化。理解 Docker 的核心架构，是掌握容器技术的第一步。 Docker 的四根柱子 Docker 的核心技术基于 Linux 内核的三大特性，加上一个标准化的容器格式： 1. Namespace（命名空间）—— 隔离 Namespace 是 Linux 内核提供的资源隔离机制，Docker 利用它为每个容器创建独立的运行环境。Docker 使用的 Namespace 包括： Namespace 隔离内容 说明 PID 进程 ID 容器内的进程有独立的 PID 空间 NET 网络 独立的网络栈、IP 地址、端口 MNT 文件系统挂载点 独立的文件系统视图 UTS 主机名和域名 容器可以有自己的主机名 IPC 进程间通信 独立的信号量、消息队列 USER 用户和用户组 容器内的 root 可以映射为宿主机的普通用户 2. Control Group（cgroup）—— 资源限制 cgr...