守株阁

当 AI 智能体需要跨越多个上下文窗口工作时，外部记忆是让任务可接力的核心机制。但外部记忆远不止于此——它有没有标准的文件格式？除了用在 Harness Engineering 里，还有哪些更广泛的用途？本文系统梳理外部记忆的文件标准现状、腐烂与治理挑战，以及超越 Harness 的更广泛应用场景。 外部记忆的文件标准：现状与混沌 先说结论：目前没有一个被所有主流 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...

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/测试/结果），代码降级为“中间产物”； ✅ 对话窗口为主视图 → 降低非专业开发者门槛，同时打破研发者技术栈认知边界（如后端工程师无需懂前端即可驱动前端开发...