有 G 友在评论区留言这个文件既然这么重要能不能单独写一篇来讲非常可以而且真值得单独讲很多朋友第一次看到CLAUDE.md总会和 README 联系起来。其实两者根本不是一回事。README 主要是写给人看的重点是介绍项目信息CLAUDE.md则是专门写给 Claude 看的。你可以把它理解成在 Claude 开始干活之前先坐在旁边提醒它几句比如项目怎么启动、哪些文件别乱动、接口返回格式怎么定、团队以前踩过哪些坑。这些话你当然可以每次开新会话都重新说一遍但说多了真的烦而且还容易漏。CLAUDE.md要解决的问题很简单把那些长期有效、又容易被 Claude 猜错的规则提前写好。这样它每次进项目时不至于一上来就从零开始摸索。这篇我就结合 Claude Code 官方文档[1]和自己的使用经验把CLAUDE.md这件事从头捋一遍该写什么、不该写什么、项目变大后怎么拆、后面又该怎么维护。还有个小提醒Claude Code 迭代很快.claude/rules/和 Auto Memory 这两块尤其容易随版本变化。本文按 2026 年 6 月前后的官方文档和实测来写实际落地前最好先用claude --version、/memory看一下你本机版本和当前会话到底加载了哪些内容。什么是 CLAUDE.mdCLAUDE.md是 Claude Code 的项目/用户级指令文件是给 Claude Code 的持久指令和上下文用于告诉 AI 助手如何在这个项目中工作本质是一份AI 行为规范。我一般只往里面放几类东西Claude 容易猜错的规则代码里读不出来的约定团队必须遵守的规范技术栈版本、常用命令、架构取舍、项目坑点我自己判断一条内容该不该放进去时会用一个很土但好用的问题这行删掉后Claude 会不会更容易犯错如果会就保留如果不会它大概率只是在浪费上下文。CLAUDE.md 和其他规则文件有什么区别CLAUDE.md 与其他规则文件怎么分工CLAUDE.md vs AGENTS.mdCLAUDE.mdAGENTS.md谁读Claude Code 专属跨工具开放标准OpenAI Codex、Cursor、Google Jules 等也采用定位Claude Code 的项目规则文件跨工具通用的 Agent 指令文件CLAUDE.md 和 AGENTS.md简单说通常来看AGENTS.md是跨工具标准CLAUDE.md是 Claude Code 专属入口。两者可以复用同一份基础指令。在一些场景下AGENTS.md也可以作为 Agent 的错误笔记Agent 在犯错之后可以自动记录这次错误的原因下次就不会再犯。如果仓库已经用AGENTS.md给其他编码 Agent 提供指令可以创建一个导入AGENTS.md的CLAUDE.md让两个工具复用同一份基础指令不用重复维护。AGENTS.md## Claude Code 特定指令- 使用 plan mode 处理 src/billing/ 下的改动以及在我的 一文搞懂 Harness Engineering[2] 这篇文章也提到过OpenAI 的AGENTS.md大约只有 100 行作用更像目录指向 docs/ 目录下更深层的设计文档、架构图、执行计划和质量评级。这就是渐进式披露先给最关键的信息需要更多细节时再加载。CLAUDE.md vs .claude/rules/CLAUDE.md.claude/rules/加载方式根目录/项目级文件通常在会话启动时加载子目录文件在读取对应目录时按需加载不带paths的规则启动时加载带paths的规则在 Claude 读取匹配文件时加载适用场景全局通用规则只针对特定文件/目录的规则上下文消耗根目录/项目级规则会持续消耗上下文只有 path-scoped rules 按需消耗全局 rules 仍会持续消耗上下文规则只针对特定目录如后端 API 规范、测试配置时优先用 rules不要继续往CLAUDE.md里堆。要注意两点.claude/rules/不是 Claude Code 安装后默认一定会出现的目录需要时可以手动创建。.claude/rules/不是天然省上下文。只有带pathsfrontmatter 的路径规则才更接近按需加载没有paths的规则仍然会像全局规则一样进入上下文。CLAUDE.md vs SPEC.mdCLAUDE.mdSPEC.md用途项目规则怎么干活需求规格做什么内容编码规范、常用命令、踩坑记录、团队约定需求边界、功能定义、验收标准类似面向 AI 的 PRD谁用AI 编码助手日常编码Spec Coding 流程需求驱动开发SPEC.md来自Spec Coding流程Specify → Design → Implement → Test核心是先搞清楚做什么再动手。Spec Coding 规范驱动编程流水线上图中的requirements.md就是Specify阶段的产物也被称为SPEC.md。我在Spec Coding 规范驱动编程实战从 Vibe Coding 到 AI 代码规范[3]这篇文章中有详细介绍。一句话简单理解就是CLAUDE.md 管长期行为规范Spec 管当次任务约束。一句话总结CLAUDE.mdClaude Code 专属的行为规范根目录/用户级通常在会话开始时加载子目录规则按需生效。AGENTS.md跨工具通用的“怎么干”规则可被CLAUDE.md导入复用。.claude/rules/局部规则目录不带paths更像全局规则带paths才会在处理匹配文件时生效。SPEC.md需求规格文件定义这次做什么属于 Spec Coding 流程中的一环。CLAUDE.md 到底该写什么先看一个我经常见到的写法。很多人跑完/init看到 Claude 生成了一份CLAUDE.md觉得“有总比没有好”于是基本没改就提交了# 项目说明这是一个 Spring Boot 项目使用 Java 17 和 Maven。# 代码风格- 写干净的代码- 遵循最佳实践- 确保代码可读性# 工作流- 提交前运行测试- 保持良好的代码组织这份文件有没有错其实没有。问题在于它对 Claude 几乎没什么约束力。比如“写干净的代码”这句删掉以后 Claude 会少做什么吗大概率不会。这种正确废话留在文件里最后只会占上下文。Claude Code 的系统指令在会话开始前就已经占了一部分上下文。Anthropic 在官方文档中指出随着上下文窗口被填满Claude 的整体表现会下降。上下文为什么会失效这意味着CLAUDE.md如果过于臃肿重要规则更容易被忽略。CLAUDE.md的每一行都在消耗上下文窗口中的有限空间留给后续对话和文件读取的余量就更少所以必须精打细算。Anthropic 建议保持CLAUDE.md精简不超过 200 行只保留 Claude 无法轻易从代码中推断的信息。如果内容继续膨胀可以拆到带paths的.claude/rules/或者把不是每次会话都需要的参考内容放到 Skills 里。Claude Code 官方文档对 CLAUDE.md 的建议一句话判断标准逐行过一遍CLAUDE.md问自己“如果删掉这行Claude 最近是不是更容易犯同类错误”。如果答案是“会”留下如果答案是“好像不会”或者“不确定”先删掉。CLAUDE.md最怕的是正确废话太多把真正重要的规则淹掉。该写的东西小 G 的经验是值得写进CLAUDE.md的内容大概分五类1. 技术栈和版本信息。这不是给 Claude 做“项目介绍”——框架版本差异往往是 AI 犯错的源头。比如 Spring Boot 2 和 3 在配置方式上差别很大你不标注版本它会倾向于生成训练数据中更常见的版本用法可能与你的实际版本不一致。再比如你选了 MyBatis-Plus 而不是 JPA这种选型信息 Claude 从pom.xml里能读到但选择背后的原因它读不出来。2. 常用命令。构建、测试、lint、启动开发服务器——全部放在代码块里。我的经验是代码块里的命令 Claude 更倾向于照着跑写在自然语言里的命令它有时会根据自己的理解改写。想要减少偏差就用代码块。# Commands- 构建mvn clean package -DskipTests- 测试mvn test -pl module-name- 启动mvn spring-boot:run -pl bootstrap- 代码检查mvn checkstyle:check3. 架构决策和背后的理由。光写规则不够写清楚“为什么”能让 Claude 举一反三。举个例子之前我的项目里有条规则是“不要直接写 SQL用 QueryWrapper”。一开始只写了这句话Claude 还是时不时直接写 SQL。后来改成“不要直接写 SQL使用 MyBatis-Plus 的 QueryWrapper因为我们的 SQL 审计系统依赖 Wrapper 的解析来记录操作日志。”加上理由之后Claude 不只是不写裸 SQL 了在其他需要生成查询的地方也自觉用 Wrapper。4. 团队约定和项目特有的坑。提交信息格式如feat(scope): message、分支命名规范、环境变量依赖。这些信息 Claude 从代码里读不出来但一个新入职的工程师一定会问——把 CLAUDE.md 当成给新人写的 onboarding 文档来写就对了。5. 当前任务的关键信息。有时候 CLAUDE.md 不仅仅是“静态规范”也可以作为“动态工作台”来明确当前需要完成的任务和优先级这通常要和静态规范的文件分离开其实也不一定以 CLAUDE.md 命名你叫 AGENTS.md 还是其他的都可以。主要写任务描述、验收标准、优先级、截止时间、依赖关系、阻塞问题、技术实现要点等关键信息。你可以将其作为 Agent 的持久化任务手册这样即使跨会话也不会忘了该做什么。不该写的东西1. 代码风格规则。缩进用几个空格、import 怎么排序、要不要尾分号——这类事交给格式化工具。项目里没配 Checkstyle 或者 Prettier 的先配工具别用自然语言去干代码格式化的活。2. 语言或框架的默认行为。“Python 用 f-string 格式化字符串”这种在现代 Python 里理所当然的事写下来只是噪音。3. 大段参考文档。外部 API 文档、SDK 参数表这种内容不要整段塞进来。放链接就够了Claude 真用到时再读。好的 CLAUDE.md 示例用户级示例先管住通用坏习惯andrej-karpathy-skills[4] 是一个第三方整理的 Claude Code 规则/Skills 项目灵感来自 Andrej Karpathy 对 LLM 编码问题的公开观察。我不会把它当成项目规范看更愿意把它当成一组用户级提醒不绑定具体仓库只管 Claude 写代码时最容易跑偏的地方。下图是这个仓库里的CLAUDE.md示例andrej-karpathy-claudemd我读下来最值得借鉴的不是某一句具体措辞而是它的取舍只盯着几个高频问题打。比如先思考再编码主要是防止 Claude 带着错误假设一路写下去强调简洁是为了压住它过度抽象、越改越重的毛病要求精准修改是为了避免它顺手动一堆无关文件最后再用测试和验收标准把结果收住别写完就算完成。建议直接去 GitHub 读原文。这里就不整段贴了重点看它的写法规则不多但每条都很有指向性管的是 Claude 在不同项目里都可能犯的通用错误。项目级示例把仓库规矩写成速查卡另一个例子是我的 interview-guide[5]。它属于项目级CLAUDE.md重点是把 Claude 容易猜错、代码里又读不完整的信息放到一眼能扫到的位置技术栈版本、分层边界、命名后缀、异常处理、事务规则、禁止清单。下面是一个更适合放在根目录CLAUDE.md的精简版。主文件只保留技术栈、命令、核心边界和禁止清单更细的规范交给.claude/rules/按需加载。# AI Interview Platform RulesSpring Boot 4.0 Java 21 Spring AI 2.0 React 面试平台。## Tech Stack- Backend: Spring Boot 4.0 / Java 21 / Gradle / Spring AI 2.0- Database: PostgreSQL pgvector1024 维 COSINE- Cache MQ: Redis / Redisson / Redis Stream- Frontend: React 18 TypeScript Vite TailwindCSS 4frontend/- Mapping Docs: MapStruct / OpenAPI / iText 8 / Apache Tika## Commands- 构建./gradlew build- 测试./gradlew test- 后端启动./gradlew bootRun- 前端启动cd frontend npm run dev- 前端检查cd frontend npm run lint## Architecture- 单模块 Gradle 项目按功能分包。- 后端遵循 Controller - Service - Repository 分层。- 基础设施能力放在 common/包括限流、AI 调用、异步任务、配置、异常、统一响应。- 前端代码放在 frontend/。- 详细项目结构见 docs/architecture.md。## Must Follow- Controller 只做参数校验和响应包装不写业务逻辑。- Service 承担业务编排Transactional 只放 Service 层。- Repository 只负责数据访问不写业务逻辑。- 对外响应统一使用 ResultT。- 业务异常必须使用 BusinessException(ErrorCode.XXX, 描述信息)。- Entity 映射使用 MapStruct禁止手写重复转换逻辑。- LLM、S3、外部 HTTP 调用不得放在数据库事务内。- 统一通过 LlmProviderRegistry 获取 ChatClient。- 结构化输出统一使用 StructuredOutputInvoker 做重试包装。- Redis Stream 生产/消费使用 AbstractStreamProducer / AbstractStreamConsumer 模板。- 限流使用 RateLimit不要手写散落的 Redis 限流逻辑。- 数据库向量搜索使用 PostgreSQL pgvector维度为 1024距离类型为 COSINE。## Never Do- 不要 throw new RuntimeException(...)必须用 BusinessException。- 不要直接返回 Entity 给前端。- 不要把 Value 散落在 Service 中配置集中到 ConfigurationProperties。- 不要内联全限定类名使用 import。- 不要事务内调用 LLM、S3 或外部 HTTP。- 不要同类内部调用 Transactional 方法。- 不要 catch (Exception e) {} 静默忽略。- 不要循环调用 DB优先批量操作。- 不要硬编码密钥。- 不要使用 Executors.newXxxThreadPool()使用显式 ThreadPoolExecutor。## More Rules- 错误码规范.claude/rules/error-handling.md- 限流规范.claude/rules/rate-limit.md- Redis Stream 规范.claude/rules/redis-stream.md- AI 服务调用规范.claude/rules/ai-service.md- 数据库规范.claude/rules/database.md- 前端规范.claude/rules/frontend.md怎么写才能让 Claude 真正遵守内容选对了还不够写法也得让 Claude 看得懂、做得到。我这边最有用的经验就两条能验证能落地。规则要具体可验证“注意代码可读性”太虚了Claude 看了也不知道具体要改哪里。换成“函数名使用动词开头、单个函数不超过 40 行”就好很多。它能照着做你也能一眼看出来它到底有没有做到。禁令要搭配替代方案只写“不要做 X”Claude 很容易绕出另一种奇怪写法。更稳的方式是顺手把替代方案也写上不要做 X遇到这种情况应该做 Y。举个我自己项目里的例子。之前 Claude 经常写Autowired字段注入但团队规范是构造器注入。一开始我只写了“不要用Autowired字段注入”。效果很一般它确实不用字段注入了但有时改成手写构造器有时又绕到别的注入方式上。后来我把规则补完整# 依赖注入- 不要使用 Autowired 字段注入- 使用构造器注入配合 Lombok 的 RequiredArgsConstructor- 参考示例UserController.java 中的写法这就不是单纯说“不许做什么”了而是把正确写法直接摆出来。后面再遇到类似场景Claude 基本就会照这个模板走。善用标记词但别滥用如果某条规则 Claude 反复违反可以在前面加IMPORTANT:或YOU MUST:提醒它。但这招别用太勤。整篇文件到处都是“重要”最后就没有哪条真的重要了。工程提示如果 Claude 反复忽略某条规则不要急着加感叹号。更大的可能性是文件太长了这条规则被其他内容稀释了。解决方案是精简文件不是加强调。标题用常规名字用 Commands、Structure、Conventions、Testing 这类在 README 里常见的标题。Claude 训练数据里有大量标准结构的 README它对“这个标题下面通常写什么”有稳定的预期。取太花哨的名字反而增加理解成本。Hooks有时候即使你写了 Claude 也不会遵守文件的指令这个时候你就需要在重要的地方加上 Hook而不是仅仅靠指令约束比如 PreToolUse在 tool 执行前检查权限、风险评估等通过了再执行 tool。下面这张图展示了整个过程图源 Claude Code 官方文档对 Hooks 的介绍。Claude Code PreToolUse Hook这里有一个来自 OpenAI 的经验能用工具强制执行的规则不要写成自然语言。CLAUDE.md 是软约束Linter/Hook/CI 才是硬约束。一条规则如果没法机械化验证Agent 迟早会偏离。比如你想阻止 Claude 修改敏感文件写一百遍“不要改.env”都不如加一个 PreToolUse Hook。适合做 Hook 的事情编辑后自动格式化。会话结束前跑测试。禁止改migrations/或.github/workflows/。拦截curl | bash、rm -rf、向外部端点发送敏感内容。在 Sub-Agent 启动时注入额外上下文。判断标准很简单这件事如果漏掉一次会出问题就用 Hook如果只是希望 Claude 知道才写进CLAUDE.md。CLAUDE.md 放在哪里Claude Code 支持CLAUDE.md放在多个位置。按加载顺序和影响范围可以先这样看CLAUDE.md 层级与优先级位置路径用途组织级macOS:/Library/Application Support/ClaudeCode/CLAUDE.mdLinux/WSL:/etc/claude-code/CLAUDE.mdWindows:C:\Program Files\ClaudeCode\CLAUDE.mdIT/DevOps 统一下发的编码规范、合规要求和数据处理说明不能通过个人配置排除。用户级~/.claude/CLAUDE.md你的个人偏好对所有项目生效项目级./CLAUDE.md或./.claude/CLAUDE.md团队共享规范提交至 Git本地级./CLAUDE.local.md个人的项目特定配置加入.gitignore子目录./subdir/CLAUDE.mdClaude 访问该目录文件时按需加载不在会话开始时注入Claude Code 会把不同层级的CLAUDE.md一起加载不是后面的文件把前面的直接覆盖掉。不过越靠近当前项目、作用范围越具体的规则会排在更后面也更贴近当前任务。比如用户级规则写“统一用空格缩进”项目级规则写“这个仓库使用 Tab”那在这个项目里Claude 更可能按项目规则来。官方文档里的加载顺序也是从组织级、用户级一直到项目级和本地级。真遇到互相打架的规则最好直接删掉冲突项不要指望 Claude 每次都选对。我的做法比较简单项目级CLAUDE.md提交到 Git放团队都要遵守的规则只和自己有关的偏好比如当前项目里希望提交信息用中文就放进CLAUDE.local.md再加到.gitignore别把个人习惯混进团队文件。项目变大了CLAUDE.md 怎么管一个人的项目一份CLAUDE.md够用。但项目一变大、团队一介入单文件就撑不住了。这时候就可以从单文件过渡到分层了。CLAUDE.md 组织方式演进参照社区实践和我的观察CLAUDE.md的组织方式大致经历几个阶段起步一份文件几行核心规则。大部分中小项目停在这里就够了。关键是保持精简——我自己的 CLAUDE.md 很少超过 50 行。拆分主文件做路由规则分文件管理。根目录的 CLAUDE.md 只放项目概述和常用命令架构规范、API 约定、测试要求分别放在独立文件里用path/to/file引用## ProjectSpring Boot 3.2 MyBatis-Plus MySQL 8.0 的订单管理服务。## Commands- 构建mvn clean package- 测试mvn test## Rules- API 约定docs/api-conventions.md- 数据库规范docs/database-rules.md按工作区域加载不同规则。在.claude/rules/里用 frontmatter 做路径匹配---paths: - src/main/java/**/controller/**/*.java---# Controller 规范- 统一使用 ResultT 包装返回值- 所有接口必须添加 Swagger 注解这样编辑 Controller 时只加载 Controller 的规则编辑 Service 时只加载 Service 的规则——不用在每个会话里塞全套规则。不过这块有几个边界必须提前知道。第一path-scoped rules 是在 Claude读取匹配文件时注入的不是每次工具调用前都注入。也就是说如果你直接让 Claude 新建一个匹配路径的新文件创建期规则可能还没进入上下文。像“新建 Controller 必须带某个文件头”这类规则不适合只放在带paths的规则里应该放到无paths的全局 rules、根目录CLAUDE.md或者用 Hook 做硬约束。第二/compact之后根目录的CLAUDE.md会重新注入但子目录CLAUDE.md和路径规则需要等 Claude 再次读取匹配文件才会重新加载。如果压缩后直接继续写文件要先用/memory或/context看看规则是否还在。第三别凭感觉判断规则有没有生效。Claude Code 的/memory会列出当前会话加载的CLAUDE.md、CLAUDE.local.md和 rules 文件更细的排查可以用InstructionsLoadedHook 记录哪些指令文件在什么时候被加载。我目前在用的就是主文件 按路径匹配的规则文件这一层级。更高阶的玩法比如引入 Skills 和 MCP 做动态能力加载还在探索中。工程提示path/to/file会把整个文件内容嵌入到上下文中。如果被引用的文件很大几百行每个会话启动时都会把这些内容全部塞进去直接烧掉一大块指令预算。官方文档目前限制递归导入最多 4 层。大文件改为自然语言引用——“架构细节参见docs/architecture.md”Claude 需要时会自己读取。怎么维护CLAUDE.md写完之后别放着不管。项目一变里面的规则也会过期。这里先把CLAUDE.md和 Auto Memory 分开看。CLAUDE.md是你主动写给 Claude 的长期指令适合放“必须遵守的规则”和“每个会话都要知道的项目事实”Auto Memory 是 Claude Code v2.1.59 内置的自动记忆机制更适合记住协作过程中学到的调试结论、偏好和工作习惯。我的习惯是会影响团队协作、每次会话都应该遵守的写进CLAUDE.md只是在排查过程中学到的小经验就交给 Auto Memory。比如“所有接口返回ResultT”应该写进CLAUDE.md“这个项目的 Redis Stream 测试需要本地先启动 Redis”这种调试发现让 Auto Memory 记住就够了。Auto Memory 默认开启可以在/memory里查看、编辑、关闭它会为每个项目维护独立的 memory 目录但它不是团队共享规范不能替代提交到仓库里的CLAUDE.md。CLAUDE.md 维护决策流程添加规则要慢一条新规则只有在 Claude 确实犯了一个错误、且这条规则能防止同类错误再次发生时才值得写进去。为还没发生过的事预设规则往往是在浪费空间。删规则要果断如果某条规则已经存在很久了但删掉后 Claude 的行为没有变化说明这条规则从一开始就没起作用——Claude 本来就会这么做。果断移除把空间留给真正需要的规则。两个预警信号信号一Claude 为已经写在文件里的规则道歉。比如“抱歉我刚才忽略了 XX 规则”。这说明这条规则的措辞有问题——Claude 读到了但没当回事。换个更直接的表述。信号二同一条规则在不同会话中反复被违反。这通常不是措辞问题而是整份文件太长了这条规则在上下文中被稀释了。解决方案不是改措辞而是压缩整份文件。两个实用的维护习惯对话式审查。每隔几周找几个CLAUDE.md里的规则问 Claude“如果我删掉这条规则你会改变行为吗”如果它说不会那这条规则可能就可以删。这种审查方式比自己逐行过效率高很多但要注意Claude 对自身行为的预判并不完全可靠最终还是要以实际行为验证为准。对于拿不准的规则更靠谱的做法是在两个平行会话中分别使用含/不含该规则的CLAUDE.md给出相同 prompt观察输出差异。错误驱动的持续进化。以前我也喜欢一出错就让 Claude “更新CLAUDE.md下次别再犯”。现在会克制一点。先看这个错误值不值得变成团队规则。如果它是长期有效、多人都要遵守的东西再归纳成一句精炼指令写进CLAUDE.md。如果只是我本机的偏好、某次调试时发现的小坑交给 Auto Memory 就够了。更稳的节奏是同类错误出现几次后再把它收敛成一条规则。不要每次出错都加一条不然CLAUDE.md很快就会变成垃圾桶。常见踩坑下面这些坑我都遇到过社区里也经常有人反馈CLAUDE.md只进不出。文件越写越长Claude 反而开始漏规则。这个时候加粗、加叹号都没用真正有用的是删。导入巨型文件。会话还没开始就先烧掉一大块上下文。大文件最好改成自然语言引用让 Claude 需要时自己读。用 path-scoped rules 管新建文件。这个很容易踩坑因为新建文件时路径规则不一定会加载。创建期约束更适合放全局 rules、CLAUDE.md或者直接用 Hook。多个规则文件互相打架。Claude 往往不会告诉你它选了哪条执行所以要定期做全量审查把冲突的规则清掉。为偶发事故加永久规则。一次罕见事故就写一条长期规则后面每个会话都要为它付上下文成本通常不划算。总结CLAUDE.md说到底就是写给 Claude Code 的项目工作卡。别把它写成百科也别把它当许愿池。它最该记录的是 Claude 靠读代码不一定能猜准、但一旦猜错就会影响结果的东西。自己写也好让 AI 帮忙维护也好先盯住几个问题哪些信息 Claude 真的猜不准哪些规则删掉以后它会犯错哪些内容应该交给格式化工具、文档链接或按需读取哪些调试发现其实放 Auto Memory 就够了项目变大以后就别再把所有规则都塞进一个文件了。根目录CLAUDE.md放全局规则和路由细节拆到.claude/rules/或独立文档里再用/memory确认它们是不是真的进入了上下文。最后还是那句话你一定比 AI 更了解自己的项目。哪些约定 Claude 猜不到哪些边界是团队踩过坑才知道的把这些写清楚Claude Code 才更容易从正确的位置开始工作。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
