小黄鸭

小黄鸭

这里是 小黄鸭 的个人博客,与你一起发现更大的世界 | 要做一个有 ikigai 的程序员

最新文章

  • ·

    一行看似无害的代码——往系统提示词里注入当前时间——让我们的推理账单翻了三倍。查这个问题的过程让我把前缀缓存彻底搞明白了,这篇把结论写下来。

  • ·

    我们的第一版 Agent 记忆系统失败得很彻底:三个月攒了两千多条「记忆」,检索命中率不到一成,捞回来的全是过期垃圾。第二版推倒重来,核心改动只有一个——从「记住更多」改成「坚决少记」。

  • ·

    Prompt 工程优化的是「怎么说」,上下文工程管理的是「模型在决策时刻能看到什么」。当任务从单轮问答变成长程 Agent,后者才是质量的决定因素。本文给出一套可落地的上下文预算管理方法。

  • ·

    一次线上性能退化的排查,让我彻底想明白了子代理该怎么用、什么时候不该用。顺便聊聊委派契约,和一个我们用血泪换来的硬规则:嵌套深度不超过二。

  • ·

    单 Agent 的能力上限是上下文窗口,多 Agent 的能力上限是协作设计。本文拆解 Orchestrator、流水线、辩论、群体投票四种主流协作模式的适用边界,以及多 Agent 系统最大的暗坑:上下文割裂。

  • ·

    给我们的系统提示词做了一次「考古」,挖出三个模型版本之前的老拐杖若干。删掉四成规则之后效果反而变好——这件事背后有一个值得认真对待的约束:模型的服从容量是有限的。

  • ·

    把我们仓库里那份自动生成的 CLAUDE.md 推倒重写之后,同样的模型、同样的任务,返工次数肉眼可见地降了。这篇记录重写过程中形成的判断,以及为什么我现在认为入口文件写得差比没有更糟。

  • ·

    当 AI 把执行成本压到接近于零,产出的瓶颈从「做得多快」变成「想得多清」。这篇文章讨论一个反直觉的结论:AI 越强,深度工作越值钱。

  • ·

    AI Coding 落地大型存量项目,遇到的最大问题不是模型能力,是规范缺失被 AI 放大了。聊一下我们团队在一个 Java 老项目上的踩坑经历,以及「人人对齐 → 人机对齐」这个顺序为什么重要。

  • ·

    MySQL 9 引入 VECTOR 类型后,「要不要为 RAG 单独养一个向量数据库」有了新答案。本文实测 MySQL 向量能力的边界,并给出一套务实的选型决策框架。