Claude Code 最佳实践仓库拆解：一篇看懂 Agentic Engineering 落地方法

很多人开始用 Claude Code 时第一反应都是优化 prompt。但如果你已经在真实项目里用过一段时间大概率会发现一个更棘手的问题不是 prompt 不够好而是 Claude 每次进入项目时都像“重新认识你一次”。你得反复解释这些东西项目结构是什么哪些命令可以跑代码规范有哪些哪些目录是关键路径哪些模式必须遵守这类信息如果一直靠会话里现讲最终一定会出问题。上下文会越来越长重要规则会被淹没Claude 的行为也会越来越不稳定。这也是我看完 shanraisshan/claude-code-best-practice 之后最强烈的一个感受如果你想把 Claude Code 用稳最该先写好的不是一段万能 prompt而是一份清晰、克制、长期有效的CLAUDE.md。但只写好CLAUDE.md还不够。真正把 Claude Code 从“聊天工具”升级成“工程系统”至少还要再补四层Commands把高频任务固定成统一入口Subagents把不同职责拆成独立角色Skills把知识做成按需加载的模块.claude/settings.json把权限、hooks 和行为边界固化到配置层这篇我不只讲CLAUDE.md而是顺着这个仓库把这 5 个模块一起拆开。CLAUDE.md到底是什么可以把它理解成一句话它是写给 Claude 看的项目说明书。它不是面向人的 README也不是一次会话里的临时提示而是项目级记忆入口。这个仓库把CLAUDE.md放在非常核心的位置原因很简单Claude Code 会读取它它会持续影响 Claude 的行为它能让项目上下文从“临时描述”变成“长期记忆”很多人以为“项目背景讲一次就够了”但工程实践里真正稳定的方式往往不是讲一次而是把该记住的事情写成系统的一部分。为什么CLAUDE.md比你想象中更重要因为它解决的是 Claude Code 最常见的三个失控点。1. 反复解释项目背景如果没有CLAUDE.md每次开新会话都要重新说这个仓库是干什么的目录怎么组织前后端分别在哪测试命令是什么这不仅浪费时间还会让每次说明的口径都不完全一样。2. 规则越来越依赖会话上下文很多团队会把重要约束写进一长串 prompt比如不要改某个目录必须按某种模式写组件某个接口一定要走统一封装问题是这些规则一旦只存在于会话里就很容易在长上下文里被稀释掉。3. Claude 知道得太多反而不知道什么最重要这是很多人容易忽略的一点。Claude 不是“知道越多越好”而是“越知道什么最重要越好”。CLAUDE.md的作用本质上不是堆更多信息而是帮 Claude 建立优先级。一个好的CLAUDE.md应该写什么根据这个仓库的最佳实践CLAUDE.md最适合放那些稳定高频对决策有强影响的信息。最典型的内容包括下面几类。1. 项目架构概览Claude 第一次进项目时最需要的是地图而不是细节。所以你应该先告诉它这个项目是什么类型主要模块有哪些目录结构怎么分哪些目录分别承担什么职责比如## ProjectThis is a monorepo with:- apps/web: frontend app- apps/api: backend service- packages/ui: shared components- packages/config: shared configs这一段的意义不在于“介绍项目”而在于让 Claude 后续读文件时能快速建立定位。2. 常用命令这是CLAUDE.md里非常实用的一部分。你最好把下面这些命令明确写进去安装依赖启动开发环境运行测试构建产物类型检查lint比如## Commands- Install: pnpm install- Dev: pnpm dev- Test: pnpm test- Typecheck: pnpm typecheck- Lint: pnpm lint这能直接减少 Claude 在命令选择上的猜测成本。3. 关键约定这部分最有价值。不是把所有代码规范都搬进来而是只写那些“如果不遵守后果会明显变差”的规则。比如所有 API 请求必须走统一客户端不允许直接访问数据库连接前端组件优先复用某个目录下的模式测试文件必须跟实现同层如果规则只是“语法习惯”优先交给 linter 或 formatter。如果规则直接影响结构和行为才适合写进CLAUDE.md。4. 关键参考路径如果项目里已经有“标准答案”一定要告诉 Claude 去哪里看。比如组件参考实现在哪路由写法参考哪个文件状态管理参考哪个模块后端 handler 应该对齐哪种模式这比抽象地说“请遵循现有风格”有效得多。一个不好的CLAUDE.md通常长什么样这个仓库反复强调一件事CLAUDE.md一定要克制。推荐长度大致控制在 150 到 200 行以内。原因不是为了好看而是因为太长之后Claude 对它的遵循度会明显下降。下面这些内容通常都不适合直接塞进CLAUDE.md。1. 整份 API 文档这是最典型的误用。API 文档适合放在独立文档里被引用不适合整个内嵌进CLAUDE.md。2. 大段代码示例除非某段代码是绝对关键模式否则不要在这里贴很多实现细节。因为CLAUDE.md最重要的是建立约束和路径而不是充当知识库全文。3. 经常变化的信息比如临时分支说明本周开发安排迭代中的细节任务这些东西变化太快不适合作为长期记忆。4. 密钥、凭证和敏感信息这一点不用多说永远不要写进去。CLAUDE.md和 README、Rules、Skills 到底怎么分工这是最容易混淆的地方。我的理解是README面向人CLAUDE.md面向 Claude 的长期项目记忆Rules面向路径或主题的局部约束Skills面向按需加载的知识模块你可以用一个简单判断法什么该进CLAUDE.md几乎每次都相关稳定存在对 Claude 判断影响很大什么该进 Rules只在某个目录生效只对某种文件类型生效需要模块化拆分什么该进 Skills不是每次都需要一旦需要信息可能很多更像方法库、模式库、领域知识这也是为什么这个仓库一直在强调“渐进式暴露知识”。不是所有东西都该常驻上下文。在 monorepo 里CLAUDE.md应该怎么放这个仓库对 monorepo 的说明非常有价值因为它把加载规律讲清楚了。可以简单记成 3 句话向上找会加载祖先目录的CLAUDE.md向下看子目录的CLAUDE.md按需懒加载兄弟目录不会互相污染这意味着非常适合这样设计根目录CLAUDE.md写全局规则比如仓库结构通用命令提交和测试要求跨项目共享约定子项目CLAUDE.md写局部规则比如前端组件模式后端接口规范特定框架约束本模块的测试习惯这种分层的好处是Claude 在前端目录工作时不会被后端细节污染在后端目录工作时也不会一直带着前端上下文跑。一个实用的CLAUDE.md模板如果你准备开始写第一版可以直接从下面这个骨架开始。# Project OverviewThis project is a monorepo for X.## Structure- apps/web: frontend app- apps/api: backend service- packages/ui: shared components## Commands- Install: pnpm install- Dev: pnpm dev- Test: pnpm test- Lint: pnpm lint- Typecheck: pnpm typecheck## Conventions- All API calls go through lib/api.ts- Reuse components from packages/ui before creating new ones- Follow route patterns in apps/api/src/routes- Put tests next to implementation files## Key References- Frontend example: apps/web/src/components/TodoList.tsx- API example: apps/api/src/routes/todos.ts- Shared UI example: packages/ui/src/Button.tsx## Do / Dont- Do follow existing file patterns before introducing new abstractions- Do run tests for changed modules- Dont introduce new state management without checking existing patterns这份模板的重点不是“完整”而是“足够稳定、足够明确、足够短”。写CLAUDE.md时我建议你遵守 4 个原则1. 只写会长期成立的信息如果一条信息过两周就会过期它大概率不该进CLAUDE.md。2. 只写真正会改变 Claude 行为的信息不要把“可有可无的说明”塞进去。优先保留那些会直接影响判断和执行路径的内容。3. 少讲抽象原则多给路径和参照物“遵循现有风格”这种话帮助有限。“参考apps/web/src/components/TodoList.tsx的模式”才是真正可执行的指令。4. 超出长度就拆分不要硬塞当你发现CLAUDE.md已经越来越长时不要继续加。应该开始拆公共记忆留在CLAUDE.md目录差异放进 Rules大块知识移到 Skills这才是长期可维护的结构。只有CLAUDE.md还不够后面四层也得补上到这里你会发现CLAUDE.md解决的是“Claude 进入项目后先知道什么”。但真实工程里还会继续遇到另外四个问题高重复流程能不能不要每次都手写 prompt不同类型的任务要不要交给不同角色处理哪些知识应该按需加载而不是常驻上下文哪些权限和自动化不该靠 prompt 临时约束这四个问题分别对应CommandsSubagentsSkills.claude/settings.json这也是这个仓库最值得继续往下拆的地方。第二层Commands应该怎么设计如果说CLAUDE.md解决的是“Claude 先知道什么”那Commands解决的就是哪些高频任务应该从临时 prompt 升级成固定工作流入口。为什么很多团队明明在重复做同一件事却还是一直手写 prompt这是非常常见的低效点。比如下面这些事你可能已经让 Claude 做了很多次review 一个 PR写 release note生成某类技术文档按固定流程调试问题但很多团队的做法还是每次重新组织一遍提示词每次重新解释目标和顺序每次重新提醒 Claude 要遵循哪些步骤这不仅浪费时间也会导致执行口径越来越不一致。Command到底是什么按这个仓库的设计Command不是普通 prompt 别名而是一个带 frontmatter、带约束、带步骤编排的工作流入口。它通常放在.claude/commands/*.md用 Markdown 文件定义。比较关键的字段包括namedescriptionmodelargument-hintallowed-toolscontextagenthooks从职责上看command 最核心的价值不是“自己做完所有事”而是“把正确的事按正确顺序串起来”。Command和Subagent、Skill的区别到底是什么这是最容易混淆的地方。我的建议是直接记成一句话Command负责流程入口Subagent负责角色执行Skill负责知识加载也就是说command 决定“这件事怎么走”subagent 决定“谁来做这件事”skill 决定“做的时候要加载什么方法和规则”只要这个边界没分清后面所有设计都会开始打架。什么场景最适合做成 command我觉得最典型的是下面这三类1. 固定步骤的流程任务比如先收集输入再调用 agent最后生成产物2. 团队里会反复执行的标准动作比如发布前检查标准化 review固定格式的总结3. 希望统一入口的复杂任务比如你不希望每个人都用不同 prompt 去做同一件事那就应该抽成 command。这个仓库里的/weather-orchestrator为什么是个好示例这个 command 很适合入门因为它特别清楚地展示了编排职责。它做的事情大致是先问用户温度单位再通过Task/Agent工具调用weather-agent最后调用weather-svg-creator生成 SVG 和 markdown 输出这里最值得学的不是天气本身而是它的职责边界command 不直接去抓天气command 不自己负责天气知识command 负责组织整个工作流顺序这正是一个好 command 的样子。什么时候该把一个 prompt 升级成 command我很建议用一个很简单的标准同类 prompt 重复出现 3 次以上就该考虑抽成 command。因为这通常说明这个任务已经高频这个流程已经相对稳定继续临时手写的收益越来越低一个可直接照着写的 command 骨架---description: Review a pull request and summarize risks, regressions, and follow-up actionsmodel: sonnet---1. Ask the user for the PR link or changed files if not provided.2. Inspect the changed files and identify behavioral risks.3. Use the appropriate agent if the task needs specialized review.4. Summarize findings in priority order.Constraints:- Focus on bugs, regressions, and missing tests.- Do not rewrite unrelated code.- Keep the final summary concise and actionable.这类 command 最大的价值不是省几行字而是把工作流固化成团队资产。command 最容易写坏的地方我觉得最常见的是这 4 个1. 把 command 写成超长 prompt如果一个 command 只是把原来临时 prompt 原封不动存起来它的价值其实不大。2. command 自己承担了太多执行细节command 应该更多负责编排而不是吞掉所有执行职责。3. 没有明确输入输出好的 command 通常很清楚它需要用户提供什么它会调用什么角色最终输出什么结果4. 和 agent、skill 边界不清这几层一旦混了后面维护成本会非常高。第三层Subagents应该怎么设计很多人一听到 agent就会本能地多拆几个。但真实情况通常是agent 不是越多越好职责越清晰越好。为什么很多人拆了 agent 反而更乱常见问题基本就这几种把 agent 当成“更长一点的 prompt”command 和 agent 不分层谁都在做流程编排一个 agent 同时负责调研、改代码、写文档、跑测试给 agent 开了太多工具结果行为边界非常模糊这会导致一个很典型的问题你以为自己在做模块化实际上只是在复制一堆职责不清的提示词。Subagent到底是什么按这个仓库的思路Subagent更像一句话它是运行在独立上下文中的专职角色。它和 command、skill 的区别一定要分清Command是流程入口Subagent是执行角色Skill是知识模块也就是说command 决定流程怎么走subagent 决定谁来做这件事skill 决定做事时加载什么知识这个边界一旦清楚Claude Code 的结构就会稳定很多。什么时候该拆一个 subagent我建议至少满足下面两个条件再拆任务本身有稳定职责边界这个职责需要独立的工具、模型、权限或记忆典型适合拆 agent 的场景包括安全审查测试生成数据库分析文档整理前端实现只读调研如果一个任务只是偶尔出现或者没有稳定边界那大概率还不值得拆 agent。这个仓库里的weather-agent为什么写得干净它是一个很好的例子因为它只做一件事使用自己允许的工具读取预加载的weather-fetcher获取迪拜温度把结果返回给 command它没有做这些事不负责跟用户来回对话不负责编排完整流程不负责最终 SVG 输出这正是好的 subagent 该有的样子边界小、职责清、输出明确。设计 subagent 时frontmatter 里最值得关注哪些字段这个仓库里的 subagent 配置里有几个字段特别关键namedescriptiontoolsmodelpermissionModemaxTurnsskillsmemoryisolation如果只说最重要的几个我会优先看这 5 个1.description这不是介绍文案而是调用条件说明。它应该告诉 Claude这个 agent 在什么情况下被调用它擅长处理什么问题它不处理什么问题2.tools这是 agent 的能力边界。经验上非常实用的一条是只读 agent 就只给Read、Grep、Glob需要改文件再加Write、Edit需要查外部资料再给WebFetch、WebSearch不要因为省事就全部放开。工具越多漂移空间越大。3.permissionMode这个字段决定 agent 执行操作时的安全模式。常见模式包括defaultacceptEditsdontAskbypassPermissionsplan如果你还在起步阶段优先考虑改代码 agent 用acceptEdits调研 agent 用plan直接上bypassPermissions风险很高不建议当默认方案。4.skills这里决定 agent 启动时预加载哪些知识。这个设计很重要因为它直接决定agent 是不是带着领域知识启动主会话是不是需要为这些知识额外占上下文5.memory这个字段决定记忆范围userprojectlocal最实用的理解方式是跨项目可复用的知识用user团队共享的项目知识用project你自己本地偏好用local一个我建议照着抄的 subagent 骨架---name: api-review-agentdescription: Review backend API changes for route patterns, validation, and error handlingtools: Read, Grep, Glob, Edit, Writemodel: sonnetpermissionMode: acceptEditsmaxTurns: 12skills: - backend-api-rulesmemory: project---Review API-related changes only.Focus on:- route consistency- validation- error handling- existing project patternsDo not redesign unrelated modules.Return a concise summary of findings and edits.这个骨架里最重要的不是字段齐全而是你能看出它的职责边界。设计 subagent 时最容易犯的错我觉得最常见的是这 4 个1. 让 agent 同时承担流程和执行流程应该交给 command执行交给 agent。两者一混后面会越来越难维护。2. 一个 agent 做太多不相关事情“全能 agent” 听起来方便但长期看最不稳定。3. 工具给太多每多一个工具就多一层不必要的自由度。4. 没有明确 memory 范围如果你自己都不知道这份知识应该存在用户级、项目级还是本地级那 agent 的行为大概率也会混乱。第四层Skills到底适合存什么内容如果说CLAUDE.md是长期记忆Subagents是角色那么Skills就是按需加载的知识包。这一层特别容易被写坏。为什么很多 skill 最后都变成了杂物间因为大家太容易把 skill 当成“能存很多内容的地方”。于是结果往往是什么都往里塞和CLAUDE.md、rules 职责重叠skill 太大调用一次就塞爆上下文内容过于死板只剩 checklist没有真正的知识结构这个仓库里最有价值的一点是它强调了一个核心原则Skill 的本质不是“多存一点信息”而是“在需要的时候加载正确的信息”。Skill 到底是什么我更愿意把它理解成一段按需加载的领域知识、工作模式或模板说明。它适合做的事情不是替代所有记忆而是补充主上下文里不该常驻的知识。什么内容适合放进 skill按这个仓库的思路比较适合放进 skill 的通常有 4 类1. 领域知识比如前端约定数据库审查规则接口设计规范发布说明模板2. 可复用工作流不是那种死板到每一步都锁死的流程而是有明确目标和约束的工作方式。3. Gotchas这类内容特别有价值因为它正好是 Claude 默认知识里最容易缺的部分。比如这个项目里哪些坑最常见哪种做法在这里会出问题哪个目录必须先参考现有模式4. 模板和规则库只要这些模板不是所有会话都必须带着就很适合做成 skill。什么内容不适合放进 skill这个判断更重要。下面这些东西通常不该放 skill1. 所有会话都必须知道的信息这种内容应该放CLAUDE.md而不是 skill。2. 过于显然的通用常识skill 最应该存的是“Claude 默认不知道或者在这个项目里需要特殊处理”的东西。3. 经常变化的信息skill 不应该承担临时通知板的职责。4. 纯粹僵硬的一步一步命令如果它只是死板操作说明没有知识结构那往往更像脚本说明而不是 skill。这个仓库为什么要拆weather-fetcher和weather-svg-creator这是理解 skill 设计最好的例子之一。这两个 skill 虽然都属于同一个天气案例但它们承担的是完全不同的职责weather-fetcher它更像领域知识。它告诉 agent去哪里获取天气应该怎么理解这个数据返回结果的方式是什么它适合作为 agent 预加载 skill。weather-svg-creator它更像输出生成模块。它负责把温度结果转成 SVG 卡片生成 markdown 输出写入最终产物文件它更适合作为被单独调用的 skill。这两个 skill 一拆开职责就非常清楚了前者负责“知道怎么拿数据”后者负责“知道怎么生成结果”user-invocable和预加载 skill 怎么选这是 skill 设计里最容易忽略的点。适合直接给用户调用的 skill通常满足这些特征它本身就是一个完整动作用户明确知道自己要调用它输出相对独立比如生成文档模板输出报告格式生成某类总结适合只给 agent 预加载的 skill通常满足这些特征它更像背景知识用户不需要直接接触它主要是给 agent 执行任务时提供方法和约束这时候就可以像这个仓库一样把它设为user-invocable: false。一个实用的 skill 模板---name: backend-api-rulesdescription: Backend API review rules and implementation conventionsuser-invocable: false---# Backend API RulesUse this skill when reviewing or writing backend API handlers.## Focus Areas- route consistency- request validation- error handling- response shape## Gotchas- Do not bypass the shared validation layer- Reuse existing error helpers- Follow the route patterns in src/routes## Reference Files- src/routes/todos.ts- src/lib/validation.ts这类模板比“塞一大堆说明”更有用因为它本身就是围绕职责组织的。skill 的本质到底是什么如果只用一句话总结我会这么说Skill 不是知识仓库而是按需加载的知识模块。一旦你按这个思路设计skill 就不会再变成杂物间。第五层.claude/settings.json应该怎么配如果前面三层解决的是“Claude 知道什么、谁来做什么”那么settings.json解决的就是Claude 能做什么以及它应该在什么边界里做。这一层非常关键因为很多团队真正缺的不是 prompt而是行为边界。为什么很多团队会把 Claude 用得越来越不稳定因为他们只在会话里约束 Claude却没有把这些约束沉淀成配置。于是就会出现哪些命令能跑全靠临时确认哪些文件能改每个人理解都不一样hooks 有没有开全凭个人环境外部工具能不能用没有统一规则这就是为什么.claude/settings.json这么重要。先分清配置优先级这个仓库把优先级讲得很清楚从高到低大致是managed settings命令行参数.claude/settings.local.json.claude/settings.json~/.claude/settings.json这套层级对团队特别重要因为它允许你同时拥有团队共享的统一行为边界每个人本地的个性化覆盖最常见的实践就是共享规则放.claude/settings.json个人偏好放.claude/settings.local.jsonpermissions到底该怎么设计这是settings.json的核心。最常见的三类规则是allowaskdeny很实用的一条设计原则是1. 高频、低风险的操作放allow比如常规读写明确范围内的编辑团队认可的常用命令2. 高风险操作放ask比如rmgitnpmcurl这个仓库就很强调危险动作要显式收紧而不是默认放开。3. 明确不该碰的内容放deny比如.envsecrets 目录某些生成产物或私密路径这能让安全边界真正落到配置里而不是落在“希望 Claude 自己别碰”的幻想里。一个适合起步的settings.json骨架{ permissions: { allow: [ Read(*), Edit(*), Write(*), Agent(*), mcp__* ], ask: [ Bash(git *), Bash(rm *), Bash(curl *), Bash(npm *) ], deny: [ Read(.env), Read(./secrets/**) ], defaultMode: acceptEdits }}真正的关键不是字段本身而是你有没有把“什么能做、什么不能做、什么必须确认”说清楚。hooks 应该怎么接进来这个仓库把 hooks 也放进了 settings 体系里这是非常对的做法。因为 hooks 本质上是生命周期自动化比如SessionStartPreToolUsePostToolUsePreCompact你可以把它理解成那些不想每次手动提醒 Claude 的动作就应该考虑交给 hooks。适合上 hooks 的事情包括会话开始时做初始化提示工具执行前做简单校验操作结束后发通知压缩上下文前做收尾但也别一开始就把 hooks 铺满。最稳的策略永远是先自动化确定性最高的动作。env和 auto-compaction 为什么也值得重视这个仓库提到一个很重要的点上下文预算要前置管理。其中一个实用配置就是CLAUDE_AUTOCOMPACT_PCT_OVERRIDE它控制自动压缩上下文的触发阈值。这件事很容易被忽略但真实使用里非常重要。因为很多人不是不会用 Claude而是总在上下文已经过载之后才发现结果开始变差。团队里最推荐怎么分工我认为这个仓库给出的思路非常稳团队共享放进.claude/settings.json权限边界hooks 配置MCP 启用规则团队一致的默认行为个人差异放进.claude/settings.local.json个人偏好临时实验本地通知方式不想影响团队的自定义设置这个分层很重要因为它能避免“每个人都在自己电脑上养一套不同的 Claude”。settings.json的本质是什么如果说CLAUDE.md是长期记忆Subagents是角色边界Skills是知识模块那settings.json的本质就是把 Claude 的行为边界从口头约束变成显式配置。这是工程化里非常关键的一步。最后总结如果把这个仓库真正有价值的内容压缩成 5 层我会这么总结第一层CLAUDE.md解决的是Claude 进入项目时先知道什么哪些长期规则应该常驻第二层Commands解决的是哪些高频任务应该固定成统一入口哪些流程不该继续靠临时 prompt 维持第三层Subagents解决的是哪些任务应该拆成独立角色谁负责执行而不是谁负责流程第四层Skills解决的是哪些知识应该按需加载哪些规则适合沉淀成复用模块第五层.claude/settings.json解决的是哪些行为默认允许哪些操作必须确认hooks、MCP 和环境变量怎么系统化接入如果你现在的 Claude Code 使用状态是prompt 越写越长项目一复杂就开始飘团队里每个人的使用方式都不同那最值得补的通常不是“更会问问题”而是把这 4 层结构慢慢搭起来。我的建议顺序仍然是先写短小稳定的CLAUDE.md再把高频流程收束成Commands再拆高价值的Subagents再把知识模块化成Skills最后用.claude/settings.json固化行为边界当这 4 层开始协同之后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%免费】