守株阁

引言：AI 编程的范式跃迁 过去一年，AI 编程工具从对话式代码生成器进化为能够自主执行复杂任务的智能代理。但真正的挑战不在于让 AI 写出代码，而在于如何让 AI 持续、可靠地完成工程任务。 Oh My OpenCode（简称 OmO）正是为了解决这一问题而生。它不是另一个聊天框，而是一套将 AI 从"对话工具"升级为"自动化工程系统"的编排框架。 OmO 的核心定位：工程化交付而非对话回答 从"会不会答"到"能不能交付" 传统 AI 编程工具的评判标准是"回答质量"，而 OmO 的核心目标是**“工程交付”**。 OmO 的工作流程遵循"输入 Markdown 描述，输出可运行代码"的心智模型： 12341. 输入任务 → 2. 判断意图 → 3. 组织执行 → 4. 工程输出 (任务描述、 (Intent Gate (并行搜索、 (回到 build/ repo 上下文、 分清提问/修复/ 资料、执行...

当 AI 智能体需要跨越多个上下文窗口工作时，外部记忆是让任务可接力的核心机制。但智能体记忆远不止"进度日志"那么简单——它正在成为一个涉及文件标准、框架实现、专用服务、模型架构和认知科学的完整工程领域。本文系统梳理记忆的文件标准现状、主流框架的实现策略、专用记忆服务的架构演进、参数化记忆增强的前沿探索，以及记忆压缩与遗忘的工程方法。 外部记忆的文件标准：现状与混沌 先说结论：目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准，但已经出现了若干事实标准（de facto standards），并且正在快速收敛。 为什么标准化很难 外部记忆文件的标准化面临一个根本性的困难：不同的 AI 工具、不同的任务类型、不同的团队规模，对"需要记住什么"的答案是不同的。 一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系；一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则；一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。 这种多样性使得"一个文件格式统治所有场景"几乎不可能。 ...

原文作者：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...

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

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