ai时代，使用claude code进行软件开发，几乎是程序员的标配了。但是大家在使用的过程中，会遇到很多问题，总之就是觉得大模型好像没有那么牛，那么就需要了解一下claude code的context window了，也就是上下文。大模型，它是无状态的，也就是说，每次你对它进行问答，它并不会将前后两次问答记录联系起来，对agent来说，如果要保持记忆，就是需要将聊天记录携带着，进行下一次的问答。

现在大家都在使用claude code进行ai coding，当大家觉得ai coding做的不太好的时候，首先想到的是模型能力不行，这合理吗？其实现在模型能力并没有那么重要了，或者说一般大模型都是能够满足coding的需求的，此时需要考虑的就是harness engineering。这里还有一个问题，就是在ai时代，ai输出了大量的代码，人无法逐行理解，如何保证代码的准确性，这也是需要harne

近两年，大模型（LLM）最重要的应用之一，就是“知识库”。企业希望让 AI 理解内部文档，研究者希望 AI 管理论文，开发者希望 Agent 能拥有长期记忆，于是：RAG（Retrieval-Augmented Generation）成为了当前最主流的知识库方案。但随着 Agent、多轮推理、长期记忆等需求出现，传统 RAG 的问题也越来越明显。2026 年，Andrej Karpathy 提出了

ai coding在日常的软件开发过程中，已经很普遍，但是在大项目中ai coding效果并不理想。于是人们开始想着引入知识图谱，将大项目知识图谱化，这样claude code等工具就不用在搜索上面花费大量时间寻找了。未来的AI coding很可能会形成三层结构，第一层：Repository Graph，例如GitNexus。负责：代码结构理解、调用链导航、架构理解。第二层：Change Grap

随着 Claude Code、Cursor、Codex 等 AI 编程助手的普及，一个新的问题逐渐暴露出来：AI 能写代码，但不一定理解整个代码库。当项目规模达到数十万行代码时，仅靠向量检索（RAG）或文件搜索（grep）已经难以让 AI 建立完整的上下文认知。因此，GitNexus 和 Graphify 这类基于知识图谱（Knowledge Graph）的工具开始受到关注。虽然两者都构建代码知识

随着大家使用ai coding的程度越来越深，通过ai聊天的方式进行ai coding，越来难以满足大家的开发需求，主要原因是：1、上下文爆炸2、prompt能力差异大3、模型切换麻烦4、自动化能力差于是，多agent模式协作ai coding就应用而生。ai协作范式，从聊天窗口到多agent编排，是一个大趋势。现在程序员手写代码的地方，不多了，所以尽可能地使用复用的agent，是拉齐大家ai c

现在人人都开始使用claude code进行ai coding，但是在大项目中，有时会觉得ai出码的效果没那么好，自己反复调试，也很难达到使用效果，最近claude code出了一个指南，可以参考下。npm test跑全量测试输出海量日志context 被污染让测试局部化。Claude Code 在大型项目中的核心思想可以总结为一句话：AI Coding 的关键，不是模型，而是工程化运行环境（Ha

大模型的发展日新月异，2026年说是ai agent元年，ai的发展对程序员的影响越来越大，如果不会ai coding感觉就会被慢慢淘汰掉。大模型的能力很强了，但是不意味着，随便写prompt就能有效地解决时间的编码问题，今天就来探讨一下。对于小需求而言，一般的prompt coding就能解决coding问题，对大多数需求而言，一般建议使用plan mode，针对大的项目需求，才建议使用spec

之前介绍了ai coding相关的skills和hooks，今天再介绍下rules，它们是三个不同的东西。Skills是已知的流程，告诉大模型遇到类似的问题，该怎么做。Hooks 是自动触发，告诉大模型遇到某些情况，需要自动触发一些操作。而Rules是约束（不能乱来），告诉大模型在生产code的时候，需要遵守的一些规范。在ai coding中，cursor和claude code是支持设置Rule

随着ai的发展，ai编程越来越成熟，每家软件公司都在进行ai编程方面的实践。2026年，如果一个程序员还不会使用ai编程，那么他肯定是要落后的。今天以claude code为例，讲解如何使用它进行ai编程。我认为在ai时代，在ai编程时代，如果想要根据需求文档就达到一个很好的编程效果，是比较难的，它需要对文档了解很深，对各方面都很了解，就像项目组里面的一个资深开发一样。它的一个风险就是可控性和安全