Day 0｜L3 启航：从工作台到极简与元架构的 Harness 演进史
上一篇是 Day 16｜L2 完结！下一站 Harness：驾驭工程的演进与 L3 蓝图预告。 确认你已经了解或掌握了 Day 16 所讨论的所有技能后，让我们从这里开始 L3 的学习吧。 ...
Agent
96 条审稿意见，84 条是错的
被 AI 审稿折磨了三天，它给我的一篇英文博客提了 96 条修改意见，我采纳了 12 条。剩下 84 条里，一半是它没看原文就开炮，一半是它想把我的文章改成它自己的腔调。 ...
omo vs oms：Fallback 链深度解析
本文是《当你的 AI 编程工具需要三套配置》的下篇。上篇介绍了三套配置的方案设计、文件结构和编排理念，本文聚焦 fallback 链的机制差异和配置实践。 文中 omo = oh-my-openagent，oms = oh-my-opencode-slim。模型和 provider 名称已脱敏为 provider-a/model-x 等泛化名称。 ...
当你的 AI 编程工具需要三套配置
为什么我需要三套 OpenCode 配置 我的 ~/.config/opencode/ 目录下有三个 opencode.json。起因很简单：我想同时跑 oh-my-openagent（以下简称 omo）和 oh-my-opencode-slim（以下简称 oms），对比着用，搞清楚各自的边界在哪。 ...
维度实验：30多年前的奇书能搞定审查维度？
系列：用经典理论指导 Agent 实践（第三篇） 第一篇：双轮审查：召回和精确为什么不能兼得 · 第二篇：策略基因：借遗传算法思路精简审查 prompt TL;DR: 两组对照实验。代码审查维度从 8 个加到 11 个，已知问题的发现率从 1/6 升到 6/6。设计审查引入公理化设计维度，发现率同样从 1/6 升到 6/6。但加了数学公式的版本证明维度不是越多越好——计算过程挤掉了审查注意力，发现数掉 35%。做对照实验，用已知问题做参照，才知道哪个维度有效。 ...
策略基因：借遗传算法思路精简审查 prompt
系列：用经典理论指导 Agent 实践（第二篇） 上一篇：双轮审查：召回和精确为什么不能兼得 下一篇：维度实验：30多年前的奇书能搞定审查维度？ TL;DR: 审查 prompt 从 317 行砍到 135 行（-58%），审查质量反升 29%。删掉的不是流程步骤，是模型自己能推导出来的冗余内容。留下的才是策略基因——不可替代的约束、反面例子和语气锁。 ...
级联检索，借信息检索领域 15 年前的方法治审查 agent 的病
系列：用经典理论指导 Agent 实践（第一篇） TL;DR: 设计审查的 agent 既要找得全又要找得准，一个 agent 难以两全。借鉴信息检索 15 年前的级联检索思路，拆成两个 agent——一个只管找全（Recall Pass），一个只管找准（Precision Pass）。设计方案的缺陷更早暴露，开发阶段返工的风险降低了。 ...
上下文腐烂：AI编程中一个容易被忽视的问题
昨天某技术群里有朋友说 GPT-5.4 的表现还不如豆包，问问题常常不读题就瞎回复。追问了一下，得知对方喂了很多文档，对话轮次也很长了。这大概率不是模型的问题——是上下文腐烂（context rot）了。 ...
回顾与反思：Aristotle 项目中的七种人机协作模式
五篇文章之后，我想退一步，看看脚下的路。 Aristotle：让 AI 学会从错误中反思 讲了设计理念和初版实现。claude-code-reflect：同样的元认知，落在不同的土壤 讲了跨平台移植的坎坷。信任边界：同一个想法在开放系统和受限系统上的实现实验 提出了信任分层模型。从四道伤疤到一套铠甲：Aristotle 改造中的驾驭工程实践 用改造过程验证了理论。一份 Markdown 的三次生命：从静态规则到 Git 版本管理的 MCP Server 把反思规则从 append-only 推进到了 GEAR 协议。 ...
一份 Markdown 的三次生命：从静态规则到 Git 版本管理的 MCP Server
上一篇文章 从四道伤疤到一套铠甲：Aristotle 改造中的驾驭工程实践 的结尾处，Aristotle 有了一份精简的路由器（SKILL.md 从 371 行压缩到 84 行），一个按需加载的 Progressive Disclosure 架构，和一个还算能用的反思→审核→确认流程。 ...