守株阁

引言 在使用 Git 的过程中，你可能会遇到 git worktree 这个命令。这个名字看起来有些特别——为什么叫 “worktree” 而不是 “workspace” 或其他更常见的词？这背后其实有一段有趣的技术历史。 核心答案 worktree 是 working tree（工作树）的缩写，来源于 Git 内部的核心概念。 这不是一个凭空创造的新词，而是直接引用了 Git 自诞生以来就存在的基础术语。 Git 的三大核心区域 要理解 worktree 的命名，首先需要了解 Git 的三大核心区域： 区域 英文名称 别名 作用 仓库 Repository - 存储所有版本历史和元数据（.git 目录） 工作树 Working Tree Working Directory 用户实际编辑文件的目录 暂存区 Index Staging Area 准备提交的文件快照 Working Tree 的含义 Working Tree（工作树）指的是检出（checkout）到文件系统中的文件集合。它是你能够直接看到、编辑的目录和文件。 12345my-project...

引言：AI 编程的范式跃迁 过去一年，AI 编程工具从"聊天框里的代码生成器"进化为能够自主执行复杂任务的智能代理。但真正的挑战不在于让 AI 写出代码，而在于如何让 AI 持续、可靠地完成工程任务。 Oh My OpenCode（简称 OmO）正是为了解决这一问题而生。它不是另一个聊天框，而是一套将 AI 从"对话工具"升级为"自动化工程系统"的编排框架。 OmO 的核心定位：工程化交付而非对话回答 从"会不会答"到"能不能交付" 传统 AI 编程工具的评判标准是"回答质量"，而 OmO 的核心目标是**“工程交付”**。 维度 传统 AI 工具 OmO 的 long-running 编排 人的角色 持续盯盘、补上下文、接管 定义目标、边界、验收标准 状态管理 当前会话上下文为主 plan + boulder + notes + 后台任务 失败处理 人手动改 prompt 倾向自纠偏，再决定是否升级 完成定义 看起来差不多 test...

上一篇文章讨论了 Harness Engineering 的本质——它依赖外部记忆让任务执行可接力。本文继续深入：外部记忆有没有标准的文件格式？它除了用在 Harness Engineering 里，还有哪些更广泛的用途？ 外部记忆的文件标准：现状与混沌 先说结论：目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准，但已经出现了若干事实标准（de facto standards），并且正在快速收敛。 为什么标准化很难 外部记忆文件的标准化面临一个根本性的困难：不同的 AI 工具、不同的任务类型、不同的团队规模，对"需要记住什么"的答案是不同的。 一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系；一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则；一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。 这种多样性使得"一个文件格式统治所有场景"几乎不可能。 当前的事实标准 尽管如此，业界已经形成了几个被广泛认可的文件约定： AGENTS.md / CLAUDE.md / CURSOR_RU...

本文尝试回答一个在智能体工程实践中反复出现的问题：Harness Engineering 到底是不是长任务的必备解法？它的本质是什么？它与外部记忆又是什么关系？ 从一个根本性的困境说起 想象一个场景：你让一个 AI 智能体去构建一个完整的 Web 应用。它开始工作，写了几个小时的代码，然后——上下文窗口满了。 新的一轮对话开始了。这个智能体对之前发生的一切一无所知。它看到了一堆代码，但不知道哪些功能已经完成、哪些还在半途、哪些已经被测试过。它只能猜测，然后继续——很可能在错误的方向上继续。 这就是长任务智能体面临的核心困境：上下文窗口是有限的，而复杂任务是无限的。 Anthropic 在 2025 年 11 月发布的工程博客 Effective harnesses for long-running agents 中，将这个问题描述得非常形象： 想象一个软件项目由轮班工程师负责，每个新工程师到来时对上一班发生的事情毫无记忆。 这不是比喻，这就是当前所有 AI 智能体在跨越上下文窗口时的真实处境。 Harness Engineering 是什么 “Harness"...

原文作者：Ryan Lopopolo，OpenAI 技术人员。本文记录了 OpenAI 内部一个工程团队历时五个月、以"零人工编码"方式构建并交付真实软件产品的完整经验。 在过去五个月里，我们的团队一直在进行一项实验：构建并交付一款软件产品的内部 beta 版，其中没有一行代码是人工编写的。 该产品有内部日常活跃用户和外部 Alpha 测试者。它经历了交付、部署、故障和修复的整个过程。与众不同的是，每一行代码 — 从应用逻辑、测试、CI 配置、文档、可观察性到内部工具 — 全都是由 Codex 编写的。据估计，我们只用了手工编写代码所需的大约 1/10 的时间就完成了这项工作。 人类掌舵。智能体执行。 我们有意选择这一限制，以便构建必要的内容，从而将工程速度提升数个数量级。我们用了几周的时间来交付最终达到一百万行代码的项目。为此，我们需要了解，当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路，从而使 Codex 智能体能够可靠地工作时，会发生哪些变化。 这篇文章要说的是，在我们与智能体团队一起从零开始打造一款全新产品的过程中，所...

为什么需要 CLI 抓包？ 在开发调试 AI 编程助手、API 客户端等命令行工具时，经常需要查看其 HTTPS 请求内容。浏览器有开发者工具，但 CLI 工具的流量对开发者是"不可见"的。本文介绍如何使用 mitmproxy 在 macOS 上实现 CLI 工具的 HTTPS 抓包。 工具选择 在 macOS 上对命令行工具进行 HTTPS 抓包，免费方案首选 mitmproxy。它提供三种使用形态： mitmproxy：终端交互式 UI，适合实时过滤和查看 mitmweb：浏览器 Web UI，JSON 自动格式化，适合内容分析 mitmdump：纯命令行，适合录制流量到文件或脚本处理 三者共享同一套证书和配置，按需选用即可。 安装 1brew install mitmproxy 第一步：生成 CA 证书 首次运行会自动生成证书文件： 12mitmproxy# 看到界面后直接 q 退出 证书默认生成在 ~/.mitmproxy/： 1234~/.mitmproxy/├── mitmproxy-ca-cert.pem # 需要信任这个├── mitm...

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} 多行注释 多行注释以 ...

AI 编程工具的普及带来了一个新问题：项目里到处都是 .md 文件。AGENTS.md、CLAUDE.md、rules/、openspec/……它们各自解决什么问题？边界在哪里？什么时候该用哪一个？ 这篇文章的核心洞察是：这些配置文件可以用"核心问题"和"时态属性"两个维度来区分——前者决定它们解决什么层面的问题，后者决定它们适合承载什么类型的信息。 理解这两个维度，就能在配置文件的迷宫中找到方向。 一、背景：为什么需要这么多配置文件？ 传统软件项目只需要一个 README.md——它是给人读的。但在 AI 编程时代，项目需要同时面向两类读者：人类和 AI Agent。 人类需要的是高层次的概览（“这个项目是做什么的？”），而 AI Agent 需要的是结构化的、可执行的上下文（“代码在哪里？怎么跑起来？有哪些约束？”）。这两类需求差异巨大，单一文件难以同时满足。 于是，项目配置文件开始分化。每一类配置文件都针对特定的问题域，服务于特定的 AI 工具或工作流。理解它们，就是理解 AI 编程工具的协作边界。 二、目录结构：一个典型 AI 项目...

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

AI 编程工具的演进，正在经历一次根本性的范式转变：从"补全光标处的代码"，到"自主完成端到端工程任务"。这种转变有一个专有名词——Agentic Coding。 理解这个转变，需要从三个层面展开：工具层（OpenCode 的能力边界）、框架层（多 Agent 协作编排）、方法论层（如何让 Agent 真正服务于工程流程）。 关于本文的模型名称：文中提及的 claude-sonnet-4-6、gemini-3-flash 等模型名称为配置示例，实际可用模型取决于 OpenCode 的当前版本和您的 API 配置。 什么是 Agentic Coding 传统 AI 编程助手的工作模式是响应式的：开发者提问，AI 回答；开发者选中代码，AI 补全。人始终是执行者，AI 是辅助工具。 Agentic Coding 的工作模式是自主式的：开发者描述目标，Agent 自主规划步骤、调用工具、执行操作、验证结果，直到任务完成。人退出执行循环，成为目标定义者和结果审查者。 这不是量变，是质变。一个能够自主编码的 Agent，需要具备： 代码理解能力...