Augment Code 实测 Karpathy 风格规则:编码智能体没写出更好的代码,但更省更快
Augment Code 在 AGENTS.md 中前置约 2.5k 字符的 Karpathy 风格编码规则,用 Auggie、Claude Code、Codex 跑 OpenClaw 的 40 个 PR 做对照。
推荐理由:同一批 PR 上三种编码智能体的对照实测,说明提示词约束主要省成本而非提质量,并给出各 harness 差异。
CLAUDE.md、AGENTS.md、上下文压缩、记忆管理,让 Agent 知道该知道的。
Augment Code 在 AGENTS.md 中前置约 2.5k 字符的 Karpathy 风格编码规则,用 Auggie、Claude Code、Codex 跑 OpenClaw 的 40 个 PR 做对照。
推荐理由:同一批 PR 上三种编码智能体的对照实测,说明提示词约束主要省成本而非提质量,并给出各 harness 差异。
Augment Code 从自家 monorepo 抽取数十个 AGENTS.md,用内部评测集 AuggieBench 对比同一任务在有、无该文件时的表现,发现最好的文件带来的质量提升相当于从 Haiku 升级到 Opus,最差的则让输出比完全没有 AGENTS.md 更糟。
推荐理由:Augment Code 用内部评测量化了 AGENTS.md 各写法的效果差异,读者可据此调整自己仓库的文档结构。
作者分析 Claude Code 源码泄露后流出的架构,认为其核心并非秘密算法,而是一个不到 30 行 Python 的 while 循环加工具字典,由 stop_reason !
推荐理由:作者从泄露源码中提炼出 12 个可组合的智能体工程模式,并给出四周上手路径,适合对照自己的实现查漏。
Ryan Lopopolo 认为,AI 让验证问题变得明显,因为每个真实任务都依赖一个我们几乎从不写下来的问题,即怎样才算把活干好。产出和评审都涉及语气、品味、风险容忍度、打磨程度、可接受的捷径和完成标准等大量非功能性决策,过去团队靠组织设计、社交规范、招聘和入职把这些隐含规则传递给人,而模型无法走招聘流程,因此交给它的任务基本都欠规范。
推荐理由:作者以在 OpenAI 做代码智能体的经历说明,非功能性需求不写下来,评审智能体就会陷入无休止的拉扯。
宝玉结合 Claude Code 的提示缓存机制,解释配额为何烧得快,并给出省 Token 的操作规则。他指出缓存只对前缀有效、主智能体缓存窗口 1 小时、子智能体 5 分钟,读取缓存成本约为重新计算的十分之一,因此频繁 /clear 反而会触发全价上下文重建;判断标准是缓存还热、任务没换就继续聊,缓存过期、任务切换或上下文噪音过多才开新会话。
推荐理由:从提示缓存机制出发解释 Claude Code 配额消耗,给出继续会话还是重开的判断条件和可复制的配置。
Drew Breunig 根据上周意外泄露的 Claude Code 源码,梳理出系统提示词的拼装结构:各组件分为始终包含和条件包含两类,并随 output_style、repl_mode、user_type_ant、skills_enabled、mcp_connected 等开关变化。
推荐理由:作者梳理 Claude Code 系统提示词的动态拼装逻辑,展示条件化上下文工程的实际做法。
Anthropic 的 Claude Code 团队工程师 Thariq Shihipar 总结了内部几百个活跃 Skills 的使用经验,把 Skills 归为库与 API 参考、产品验证、数据获取与分析、业务流程自动化、代码脚手架、代码质量与审查、CI/CD 与部署、运维手册、基础设施运维九类。
推荐理由:Anthropic 内部几百个 Skills 的分类体系与编写技巧,可迁移到团队自己的 Skill 设计。
作者让智能体在 stereOS 虚拟机里用 PyBoy 无头运行宝可梦红,速度约为实时的 100 倍,智能体自己输出 NAV、BATTLE、BACKTRACK 等日志前缀,这些日志经 tapes 代理流入 Kafka,再由 Flink SQL 做 STUCK_LOOP、TOKEN_SPIKE 异常检测,JSONL 与 DuckDB 负责跨会话查询。
推荐理由:作者用终端里跑宝可梦的智能体做实验,展示日志如何变成跨会话的观测记忆并反哺下一轮运行。
Bassim Eledath 把 AI 辅助编程的实践路径划分为 8 个等级,从 Tab 补全、智能体 IDE,到上下文工程、复合工程、MCP 与技能、Harness Engineering、后台智能体,最后到自主智能体团队。
推荐理由:作者把 AI 辅助编程从 Tab 补全到自主智能体团队划成 8 个等级,读者可据此定位自己团队所处阶段。
作者构建的宝可梦红版自主 Agent 跑了 1000 回合仍停在卧室,原因是它把背景瓦片图地址 0xC4F2 当成文本框状态标志,一直按 A 键却不知道卡住。
推荐理由:作者用 1000 回合卡在卧室的失败复盘,说明记录并回放 Agent 会话状态比改提示词更能定位静默故障。
OpenAI 用 GPT-5.3-Codex 在 Extra High 推理档下从空仓库连续运行约 25 小时、消耗约 13M token、生成约 3 万行代码,做出一个可测试的设计工具。
推荐理由:作者用 25 小时、13M token 的实测展示长时程智能体如何靠持久化项目记忆和逐里程碑验证保持不跑偏。
作者提出用智能体会话日志来改进 CLAUDE.md 或 AGENTS.md 文件:Claude Code 的会话存在 ~/.claude/projects,Codex 存在 ~/.codex/sessions,都是 JSONL 格式但 schema 不同。
推荐理由:作者用智能体会话日志反推 CLAUDE.md 的改进点,并开源了一个 CLI 把搜索从几分钟压到几秒。
Martin Fowler 团队的文章梳理了编码智能体的上下文工程,把上下文配置分为可复用提示词(指令与指导两类)、上下文接口(工具、MCP Server、Skills)和工作区文件,并按“谁决定加载”分为 LLM、人类和智能体软件三类。
推荐理由:以 Claude Code 为例梳理编码智能体的上下文配置手段,并给出按需加载与逐步构建的取舍思路。
Jesse Vincent 提出 Latent Space Engineering,即通过提示词把模型推入更有利于完成任务的潜在空间,而非只往上下文窗口塞事实信息。
推荐理由:作者提出用情绪化提示词把模型推入更佳状态,并给出多个可迁移的实操例子。
Claude Code 通过把 Skill 名称和描述注入系统提示词来让模型知道有哪些 Skill,当 Skill 太多或描述字段太长时,系统提示词就不会列出它们,模型也就无法使用,而且提示词还要求模型不要使用未列出的 Skill。
推荐理由:作者解释了 Claude Code 不触发已安装 Skill 的原因,并给出可直接使用的环境变量临时解法。
作者在让智能体开发 Web 应用时,常遇到客户端 JavaScript 的 bug,智能体靠读代码解决不了就会启动浏览器 MCP 交互调试,只为看浏览器控制台日志,既费 token 又慢。
推荐理由:作者给出一个可复用的前后端日志桥接做法,让编码智能体不用浏览器 MCP 也能看到前端日志。
Dagster Labs 分享了用 OpenAI Codex 加速技术文档写作、跨媒介内容转换和文档覆盖度评估的实践。他们重写了 CONTRIBUTING.md,明确文档层级、结构和最佳实践,让 Codex 能据此生成符合规范的文档;还借助 gh 命令让 Codex 解读 PR 的 diff 和描述,并让 Codex 把教程改写成 YouTube 视频脚本。
推荐理由:Dagster 团队把 Codex 用于文档写作、PR 解读和内容跨媒介转换,其中用文档生成代码来反向衡量文档覆盖度的做法可以迁移。
作者为 Claude Code 构建了 episodic-memory 插件,让它能检索过去的会话记录。Claude Code 默认把 ~/.claude/projects 下的 .jsonl 会话日志在一个月后删除,可通过 ~/.claude/settings.json 的 cleanupPeriodDays 延长保留。
推荐理由:作者把 Claude Code 的会话日志做成可语义检索的情景记忆,读者可据此判断长期上下文如何跨会话保留。
作者为 Claude Code 自建了轻量 Chrome MCP 与 Skill,名为 superpowers-chrome,启动时 MCP 配置仅占 947 token,而微软 Playwright MCP 仅可用状态就要 13678 token(约占上下文窗口 7%)。
推荐理由:作者用自建 Chrome MCP 对比 Playwright MCP 的 token 开销,给出面向 LLM 设计工具接口的具体取舍。
Martin Fowler 试用 Kiro、spec-kit 和 Tessl 三款自称实现 spec-driven development(SDD)的工具,把 SDD 归纳为 spec-first、spec-anchored、spec-as-source 三个层次,并指出目前所有方案都停留在 spec-first。
推荐理由:作者亲手试用 Kiro、spec-kit 和 Tessl 三款 SDD 工具,给出 spec-first、spec-anchored、spec-as-source 三层划分,并指出小任务被过度规格化的问题。