AI

照着 Anthropic 工程师的 unknowns 方法论实践了两周，最大的变化是心态：以前 Agent 产出不对，我怪它没理解；现在我先问自己的地图哪里漏了。附两周里最好用的几招和一次被 quiz 抓住的真实漏网。

我们自己的用例生成工具卡在「正确但没用」很久了，直到对照快手 KATE 的四阶演进（8% 生成率做到 70%）才看明白卡在哪。生成型 Agent 产品的瓶颈迁移路径其实高度可预测，这篇把地图画出来。

我们的模型选型评测得出过一个尴尬结论：聊天体验最好的那个模型，在真实 Agent 负载上垫底。锯齿智能这个概念解释了为什么，也解释了为什么「哪个模型最强」是个没有营养的问题。

重写一个八年老系统时我们发现：最值钱的业务逻辑只存在于代码里，而且没人说得清为什么。AI 把写代码的成本打到趋近于零之后，真正稀缺的东西显形了。聊聊「代码是负债」这个暴论，和它推出来的工程结论。

把 RPI 教给一个刚上手 AI Coding 的同事之后，他的返工率一周内降了一半。三步，三条铁律，一张便签能写下的方法，专治「一个窗口从头聊到尾」。

「AI 写的代码我看不过来了」——团队里被问得最多的问题。我的答案是别看代码，看证据。这篇把我们摸了半年的控盘打法写下来：水流理论、漫溢与溃堤的分辨、最小混沌单元，和一次删掉两千行错误 diff 的教训。

我们把一个分类 Agent 的准确率优化交给了另一个 Agent，它跑了一个周末，迭代了十几轮，交回一个比我手工调了两周更好的版本——中间也差点被它的 reward hacking 摆了一道。记录这次实践和 Loop Engineering 的几个关键机制。

用 goal 模式治好了一个折磨我们三周的 flaky test，也烧过一整晚 token 一无所获。两次经历的差别不在模型，在于我有没有把「完成」定义清楚。聊聊 goal 类功能的机制设计和写好一份完成合同的六要素。

模型明明「想」对了，改文件却改错了——自己搭 harness 的人都在这摔过跤。对比三种编辑格式的设计取舍，附上我自己在内部任务集上复测的结果，和一个关于 harness 设计的普遍规律。

一场持续两周的存储选型之争，和一次用 YAML 管任务状态翻车的亲身经历。Agent 时代的存储分工，我现在的答案是一句话：工作区可以是文件，账本必须是数据库。

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

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

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

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

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

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

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

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

背景 Agent 今年开始真正可用。但「把任务扔进后台」这件事，工程上的问题远比看起来多：任务怎么描述、进度怎么跟踪、失败了怎么办、多人协作怎么共享上下文。记录一些实际经历。

MCP 把「模型如何接入外部世界」从 N×M 的集成噩梦变成 N+M 的标准化问题。本文从协议设计、消息模型到生产实践，完整拆解 MCP 的工程价值与落地陷阱。

Hermes（爱马仕）今年在 Agent 圈很热，各种 demo 看着挺酷。花了一个周末把它跑起来，记录一下真实落地和网上教程的差距，以及几个文档里没写清楚的地方。

以为 CLAUDE.md 只有「用户级 + 项目级」两份？我也这么以为，直到在一个子模块里跑出了薛定谔的输出格式。把踩坑过程和加载机制拆清楚，记录一下。

Harness 这个词最近很热，但大多数介绍要么太虚要么太碎。结合自己搭过几个 Agent 系统的经历，聊聊 Harness 到底是什么、为什么单靠 Prompt 和 Context 不够，以及几个我认为被低估的工程细节。

AI 能做 100 件事，但挑不出哪件值得做的，是人。AI 时代的竞争力，不在于你用 AI 做了什么，而在于你怎么判断什么值得让 AI 做。

用 AI 的人分两种：一种每天重复同样的上下文，30天后效率跟第一天一模一样；另一种让 AI 自动用他的语气写作、按他的格式输出。本文分享三个让 AI 能力持续复利的认知框架。

系统梳理全球 AI 领域优质信息源：从学术前沿到工程落地，从模型研究到产品应用，构建个人 AI 信息体系

90%的人写 Skill 只是在写操作步骤清单。真正的 Skill 写的是判断标准——什么是对的，什么是错的，什么宁可不做。而这，恰恰是 AI 最缺的东西。

Prompt Engineering 解决表达问题，Context Engineering 解决信息量问题，而真正让 AI Agent 可用、可靠、可持续的，是 Harness Engineering。

AI时代最危险的不是'不会用AI的人'，是'用AI用得太顺的人'——他们没有意识到建立的是对工具的依赖，而不是自己的能力。

本文深度探讨AI辅助编程与智能体的技术演进、分布式系统架构的现代实现，分析三者如何共同塑造下一代软件开发范式，为开发者提供从理论到实践的全面指南。

真正的工程演进不在于对“感觉”的盲从，而在于如何建立一套驾驭 AI 产出的硬核纪律 Vibe Engineering

Vibe Coding的时间效应

从企业落地、成本与安全、个人效率与生产力的差异、方法论与清单化实践切入，讨论 AI 与 IA 共创的路径与边界，并给出待解决问题库与已验证问题库的实操建议。

按开发全流程拆分选型：架构/开发/测试/审查阶段如何选择 LLM，成本控制与模型搭配策略，并给出可执行的实用建议与工具清单。