上一篇文章我讲了为什么个人提效不等于团队提效以及一套六步工程框架怎么把 AI 关进流程的笼子里。但那篇留了一个尾巴框架怎么落地这篇直接实战搞起。我在多个中型老项目的企业级前端项目上跑了这套体系8 个 Skill覆盖从需求到交付的完整链路多个团队目前反馈都是非常好用。先说一下在推全链路 AI 化的过程中我遇上了五个实打实的问题——非开发岗位跟不上。产品、测试日常也在用 AI但用得浅——产品拿它润色文档测试用它生成几个用例。开发侧已经把 AI 嵌入工作流了到了需求评审还是口头沟通加截图到了测试还是手工点点点。AI 出了编码边界就断电。环节之间衔接不上。产品写了一版 PRD开发用 AI 生成了代码测试又用另一套方式写用例。三个环节产出格式不一样、术语不一样出了事往回追溯——产品说写清楚了开发说按需求做的测试说按实际行为测的。扯皮成本比编码成本高。需求来回变返工停不下来。AI 写得再快架不住改三版。而且 AI 代码有个特点——第一版最工整改到第三版开始改不动了逻辑绕来绕去。AI 识别不了变更范围。改一个筛选条件列表页、详情页、导出功能全炸了。测试测到崩溃。经验跟着人走不跟着项目走。规范在老开发脑子里某个模块为什么那么写只有经手过的人知道。新人从头踩一遍坑。五个问题叠在一起我开始意识到光靠个人提效的方法论不够用。问题不是某个环节卡住了是环节之间的交接面全站在不一样的角度去表达。转折点发生在一个周五下午。测试同事拿着 Excel 找我你们这轮提测了 12 个功能点我手工点了半天覆盖率不到一半还有 2 个小的功能点你们是不是忘写了浪费我时间。我让开发同事给他沟通解释她听了十分钟放弃了。那一刻我知道了——解法不是更多文档是把每个环节的产出固定下来。需求评审的产出长什么样、接口对接的产出长什么样、测试用例的产出长什么样全部标准化。然后让这些产出自动流转到下个环节。所以我开始写 Skill。八个 Skill覆盖完整闭环我把需求、设计、开发、测试、验收、Bug 修复全部写成独立的Skill。我最开始只写了三个——product、ui、review。跑完第一个需求之后发现断档太多才陆续补上api、page、test、qa、bugfix。项目里实际在跑的八个Skill职责product需求评审 → 任务拆解api接口文档 → 类型定义 请求函数ui设计稿 → 组件代码page组件 API → 完整页面test单元测试qaQA 用例扫查reviewCode Review 规范回写bugfixBug Case → 根因定位 → 修复依赖顺序是固定的下游消费上游的产出product需求评审 任务拆解 │ ├──▶ api接口对接 ├──▶ ui设计稿转组件 │ │ └──────────┬───────────────────┘ ▼ page组件 API → 完整页面 │ ▼ test单元测试 │ ▼ qaQA 用例扫查 │ ▼ reviewCode Review 规范回写 │ ▼ bugfixBug 修复独立触发 │ ▼ review二次审查  qa 和 bugfix 是我最晚加进来的两个 Skill。加 qa 的原因很具体——测试同事的 Excel 用例跟代码实现之间有一个巨大的断层开发说做完了、测试说没覆盖。加 bugfix 是因为 qa 提出了个 BugAI 改了三次都没好每次都是看起来像这里的问题就下手改了没先定位根因。后来补上约束**根因说不清不许动手。**  实现原理所有产出收进一个目录spec 八个 Skill 的产物不能散落在项目各处——否则三个月后谁也找不到哪个需求对应哪些文档。这块我参考了 **OpenSpec**Fission-AI 开源的 spec-driven development 框架的思路核心就一条规矩**每个需求的全部 Skill 输出收进同一个目录。** 具体长这样 plaintext spec/changes/├── .spec.template.yaml # 新需求的模板复制即用├── user-management/ # 一个 feature 的完整产出│ ├── .spec.yaml # 进度追踪每个 skill 状态pending → completed│ ├── product.md # 需求评审六维评审报告 任务列表│ ├── api.md # 接口对接接口契约 类型定义│ ├── ui.md # 设计还原组件列表 还原说明│ ├── page.md # 页面组装数据流 状态说明│ ├── tests.md # 单元测试测试结果 覆盖率│ ├── qa.md # QA 扫查用例对照 通过率│ └── review.md # Code Review结构化审查报告└── archive/ # 已完成的按日期归档 └── 2026-07-15-user-management/每个 Skill 最后一步必须把产出写入对应文件并更新.spec.yaml中对应状态为completed。进度不用问人打开看一眼就知道卡在哪。Review 的时候所有上下文全在一个目录里不用追着问那个接口文档发哪了、“测试报告在哪”。实际产出如下每个 Skill 内部的三个共同设计八个 Skill 分工不同但内部有三条共同设计。这三条比具体步骤更重要——它们是为什么这套东西能稳定运行的底层逻辑。设计一先读 CLAUDE.md不可跳过。api上来先确认命名规范和响应体格式ui先确认封装了哪些组件、哪些已废弃、哪些禁止直接用 antd 导入bugfix先确认修复可能触碰哪些禁区。AI 不知道的事不会主动问。不喂约束它就按训练数据里的通用实践来出来的代码必然跟团队规范打架。最早版本的ui没加这条生成出来的组件用的全是 antd 原生组件但项目里全封装过了。设计二有明确的决策点停下来等人。不是全自动。全自动在企业场景里是灾难——AI 做错判断没人拦一路跑到线上才炸。product发现某个功能已经有人做过了——停下来确认是复用还是重做。api发现接口字段文档没说清楚——标[待确认]等人补不猜不推断。bugfix发现 Issue 信息不全没复现步骤、没预期行为——暂停等人补充。AI 不会补位的地方用决策点兜住。设计三末尾挂一张常见坑速查表。同一个模型在不同项目里犯不同的错。每个坑写成现象 → 原因 → 处理三列。这只表是活的——每交付一个需求review发现新坑就补进去。比如bugfix的表现象原因处理修完一个 Bug 引入另一个只看了 happy path回三步检查法里边界逐条过——空值、权限、并发顺手重构了无关代码忍不住顺便优化改前把不做什么念一遍多一行都不写改了好几个文件但根因没找到在症状层面修修补补退回定位一句话说清根因了吗说不清继续查下一个修 Bug 的人不需要重踩这些坑——AI 加载bugfixSkill 时这些坑自动变成约束。贯穿全流程的四个底座八个 Skill 跑起来之后我开始盯另一个问题——单个环节的产出稳了但整条流水线还是会翻车。于是我开始补底座。下面这四个机制不是设计出来的是修 bug 修出来的。SDD 闭环规范驱动开发。四步循环CLAUDE.md 定义规范 → AI 按规范生成 → Code Review 验证符合度 → 发现违规补规范举个真实例子AI 生成的 UI 没用CustomSkeleton封装组件直接用了原始组件库的 Skeleton。不是骂一句 AI 智障就完事了——回去翻 CLAUDE.md有没有写骨架屏必须用 CustomSkeleton没写 → 不是 AI 的错是规范缺失补进去。写了 → 代码错误修代码。每次 AI 跑偏都是发现规范漏洞的机会。不清晰就停。需求模糊、接口缺字段、设计稿不确定、Case 信息不全——任何环节遇到不确定就停下来问不许猜、不许脑补、不许替用户决策。文档驱动防幻觉。Tailwind / React / useRequest 等关键依赖强制先读 Context7 官方文档再回答每个 Skill 第一步必读项目 rule 文件。代码不是从模型训练数据里瞎编的是从真实文档锚定出来的。spec 单目录收拢。前面展开讲了——所有产出在一个目录下进度可追踪上下文不丢失Review 时一眼看清全貌。三条铁律是血泪堆出来的这些规则是踩了无数次坑之后焊死的每条背后都有一个真实翻车现场。Characterization Test行为基线。改造老模块之前别急着写应该返回什么的测试。先跑一遍现有代码把实际输出记录下来转成断言。测的是代码实际在做什么不是应该做什么。这一步跳过去直接改代码改完之后 AI 可能悄悄改了某个没测到的行为路径——测试全绿、diff 干净、上线炸了。这种情况最阴险了因为你不是没测你测错东西了。预期值必须是字面量。expect(price).toBe(1.00)不能写成expect(price).toBe((100/100).toFixed(2))。不能在断言里重算被测逻辑来拼 expected——万一被测的算法有 bug你的 expected 也跟着错测试永远绿。这条规则看着简单我见过至少三次因为违反它导致线上事故。每批只做 1-3 个。测试也好、组件也好AI 一次生成 20 个一半跑不通整批都不可信。每批做 1-3 个跑通、review 过、确认没问题再做下一批。慢就是快。不做什么这些规则是 AI 替我踩出来的。有一次它顺手改了一个不在需求范围内的导出逻辑review 没发现上线后导出的 Excel 列名全是错的。从那以后不做什么变成了强制约束写在每个 Skill 的禁区栏里。不在没有 PRD 的情况下凭空拆任务不引入项目技术栈以外的依赖不顺手重构不在任务范围内的代码不用 AI 自己说的没问题代替人手验证不为一次性操作创建 Skill——只有可复制、可参数化、可自动化的事才值得 Skill 化跨项目分发别让 Skill 分叉一套 Skill 打磨好了不能让每个项目手动拷。我们最早就是手动拷的两个月后发现 A 项目改了product加了防重复B 项目还在用旧版——同一个坑 B 项目月月踩。手动拷的致命问题不是麻烦是分叉。后来写了同步脚本一个sync.sh推到所有下游。源仓库改了什么所有项目统一更新。为什么是 OpenSpec不是 Spec-Kit 或 Superpowers现在市面上做规范驱动开发的主流方案有三个Spec-KitGitHub 官方、OpenSpecFission-AI 社区、Superpowers。三个我都研究过说说我为什么选了 OpenSpec。理念适合场景安装学习成本Spec-Kit七阶段门控流水线流程严谨新项目、大团队、企业级合规Python uv较重中等偏高OpenSpec三步迭代propose→apply→archive轻量灵活存量改造、小团队、敏捷迭代npm install -g30 秒低SuperpowersSkill 机制 harness 配置工具集成深已有 Claude Code 深度用户需 hooks 和权限管控配置式不依赖 CLI中等我的选择逻辑很简单——我的场景是在已有项目上做增量改造不是从零搭建新项目。团队不大流程不想太重。OpenSpec 的三步走提案→执行→归档刚好够用不绑 GitHub 生态装完就能跑而且对 Claude Code / Codex / Cursor 的兼容最好。Spec-Kit 太像瀑布流了——七个阶段一个一个过对存量项目来说太重。Superpowers 的思路很好但它更偏工具配置层不太适合作为团队协作的主流程引擎。我们这套 Skill 体系的灵感其实都参考了上面三个 SDD 工具 只是opensepc 理论作为基座选工具的核心不是谁功能多是谁刚好够用不多不少。对我来说OpenSpec 刚好卡在这个位置。Skill 是长出来的 从哪开始第一个版本的 Skill 很粗糙就三四步。跑第一个需求review发现 AI 生成已存在的组件——product补上第零步。跑第二个需求review发现没处理 loading 态——page补上四态覆盖。跑第三个需求线上 Bug 查三天找不到根因——bugfix补上根因确认铁律。跑第四个需求QA 说测试用例没覆盖——qa从零写出来。四个需求下来八个 Skill 被真实业务反复摩擦该补的坑都补上了。网上的现成 Skill 可以参考但骨架得自己搭——只有你们知道禁区在哪、习惯是什么。如果你现在就想动手先只做一个 Skill——挑最痛点。需求不清做productUI 还原差做uiBug 反复出做bugfix。一个跑稳再扩用 Markdown 写放.claude/skills/下。结构就三段触发条件、执行步骤标注决策点、常见坑建一个单目录收产出哪怕只收两三个文件也比到处散落强。进度用 yaml 标别靠脑子记第一个版本别追求完美跑起来review自然会告诉你漏了什么CLAUDE.md 是约束来源——Skill 管流程CLAUDE.md 管规范AI 跑偏了先判是哪个漏了单项目跑稳之后下一步是多 Agent 并行——这块上一篇文章已经展开聊了。顺序不能反Skill 是基础多 Agent 是加速器。先把八个 Skill 跑上三五个需求每个 Skill 的产出格式稳定了、决策点验证过了、常见坑表累计了至少五条了再拆并行。多 Agent 这块我目前自己也在试水阶段实践不到一个月预计一个月后深度分享企业级多 Agent 的AI Coding 团队协作的经验。学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%免费】
上一篇文章我讲了为什么个人提效不等于团队提效以及一套六步工程框架怎么把 AI 关进流程的笼子里。但那篇留了一个尾巴框架怎么落地这篇直接实战搞起。我在多个中型老项目的企业级前端项目上跑了这套体系8 个 Skill覆盖从需求到交付的完整链路多个团队目前反馈都是非常好用。先说一下在推全链路 AI 化的过程中我遇上了五个实打实的问题——非开发岗位跟不上。产品、测试日常也在用 AI但用得浅——产品拿它润色文档测试用它生成几个用例。开发侧已经把 AI 嵌入工作流了到了需求评审还是口头沟通加截图到了测试还是手工点点点。AI 出了编码边界就断电。环节之间衔接不上。产品写了一版 PRD开发用 AI 生成了代码测试又用另一套方式写用例。三个环节产出格式不一样、术语不一样出了事往回追溯——产品说写清楚了开发说按需求做的测试说按实际行为测的。扯皮成本比编码成本高。需求来回变返工停不下来。AI 写得再快架不住改三版。而且 AI 代码有个特点——第一版最工整改到第三版开始改不动了逻辑绕来绕去。AI 识别不了变更范围。改一个筛选条件列表页、详情页、导出功能全炸了。测试测到崩溃。经验跟着人走不跟着项目走。规范在老开发脑子里某个模块为什么那么写只有经手过的人知道。新人从头踩一遍坑。五个问题叠在一起我开始意识到光靠个人提效的方法论不够用。问题不是某个环节卡住了是环节之间的交接面全站在不一样的角度去表达。转折点发生在一个周五下午。测试同事拿着 Excel 找我你们这轮提测了 12 个功能点我手工点了半天覆盖率不到一半还有 2 个小的功能点你们是不是忘写了浪费我时间。我让开发同事给他沟通解释她听了十分钟放弃了。那一刻我知道了——解法不是更多文档是把每个环节的产出固定下来。需求评审的产出长什么样、接口对接的产出长什么样、测试用例的产出长什么样全部标准化。然后让这些产出自动流转到下个环节。所以我开始写 Skill。八个 Skill覆盖完整闭环我把需求、设计、开发、测试、验收、Bug 修复全部写成独立的Skill。我最开始只写了三个——product、ui、review。跑完第一个需求之后发现断档太多才陆续补上api、page、test、qa、bugfix。项目里实际在跑的八个Skill职责product需求评审 → 任务拆解api接口文档 → 类型定义 请求函数ui设计稿 → 组件代码page组件 API → 完整页面test单元测试qaQA 用例扫查reviewCode Review 规范回写bugfixBug Case → 根因定位 → 修复依赖顺序是固定的下游消费上游的产出product需求评审 任务拆解 │ ├──▶ api接口对接 ├──▶ ui设计稿转组件 │ │ └──────────┬───────────────────┘ ▼ page组件 API → 完整页面 │ ▼ test单元测试 │ ▼ qaQA 用例扫查 │ ▼ reviewCode Review 规范回写 │ ▼ bugfixBug 修复独立触发 │ ▼ review二次审查  qa 和 bugfix 是我最晚加进来的两个 Skill。加 qa 的原因很具体——测试同事的 Excel 用例跟代码实现之间有一个巨大的断层开发说做完了、测试说没覆盖。加 bugfix 是因为 qa 提出了个 BugAI 改了三次都没好每次都是看起来像这里的问题就下手改了没先定位根因。后来补上约束**根因说不清不许动手。**  实现原理所有产出收进一个目录spec 八个 Skill 的产物不能散落在项目各处——否则三个月后谁也找不到哪个需求对应哪些文档。这块我参考了 **OpenSpec**Fission-AI 开源的 spec-driven development 框架的思路核心就一条规矩**每个需求的全部 Skill 输出收进同一个目录。** 具体长这样 plaintext spec/changes/├── .spec.template.yaml # 新需求的模板复制即用├── user-management/ # 一个 feature 的完整产出│ ├── .spec.yaml # 进度追踪每个 skill 状态pending → completed│ ├── product.md # 需求评审六维评审报告 任务列表│ ├── api.md # 接口对接接口契约 类型定义│ ├── ui.md # 设计还原组件列表 还原说明│ ├── page.md # 页面组装数据流 状态说明│ ├── tests.md # 单元测试测试结果 覆盖率│ ├── qa.md # QA 扫查用例对照 通过率│ └── review.md # Code Review结构化审查报告└── archive/ # 已完成的按日期归档 └── 2026-07-15-user-management/每个 Skill 最后一步必须把产出写入对应文件并更新.spec.yaml中对应状态为completed。进度不用问人打开看一眼就知道卡在哪。Review 的时候所有上下文全在一个目录里不用追着问那个接口文档发哪了、“测试报告在哪”。实际产出如下每个 Skill 内部的三个共同设计八个 Skill 分工不同但内部有三条共同设计。这三条比具体步骤更重要——它们是为什么这套东西能稳定运行的底层逻辑。设计一先读 CLAUDE.md不可跳过。api上来先确认命名规范和响应体格式ui先确认封装了哪些组件、哪些已废弃、哪些禁止直接用 antd 导入bugfix先确认修复可能触碰哪些禁区。AI 不知道的事不会主动问。不喂约束它就按训练数据里的通用实践来出来的代码必然跟团队规范打架。最早版本的ui没加这条生成出来的组件用的全是 antd 原生组件但项目里全封装过了。设计二有明确的决策点停下来等人。不是全自动。全自动在企业场景里是灾难——AI 做错判断没人拦一路跑到线上才炸。product发现某个功能已经有人做过了——停下来确认是复用还是重做。api发现接口字段文档没说清楚——标[待确认]等人补不猜不推断。bugfix发现 Issue 信息不全没复现步骤、没预期行为——暂停等人补充。AI 不会补位的地方用决策点兜住。设计三末尾挂一张常见坑速查表。同一个模型在不同项目里犯不同的错。每个坑写成现象 → 原因 → 处理三列。这只表是活的——每交付一个需求review发现新坑就补进去。比如bugfix的表现象原因处理修完一个 Bug 引入另一个只看了 happy path回三步检查法里边界逐条过——空值、权限、并发顺手重构了无关代码忍不住顺便优化改前把不做什么念一遍多一行都不写改了好几个文件但根因没找到在症状层面修修补补退回定位一句话说清根因了吗说不清继续查下一个修 Bug 的人不需要重踩这些坑——AI 加载bugfixSkill 时这些坑自动变成约束。贯穿全流程的四个底座八个 Skill 跑起来之后我开始盯另一个问题——单个环节的产出稳了但整条流水线还是会翻车。于是我开始补底座。下面这四个机制不是设计出来的是修 bug 修出来的。SDD 闭环规范驱动开发。四步循环CLAUDE.md 定义规范 → AI 按规范生成 → Code Review 验证符合度 → 发现违规补规范举个真实例子AI 生成的 UI 没用CustomSkeleton封装组件直接用了原始组件库的 Skeleton。不是骂一句 AI 智障就完事了——回去翻 CLAUDE.md有没有写骨架屏必须用 CustomSkeleton没写 → 不是 AI 的错是规范缺失补进去。写了 → 代码错误修代码。每次 AI 跑偏都是发现规范漏洞的机会。不清晰就停。需求模糊、接口缺字段、设计稿不确定、Case 信息不全——任何环节遇到不确定就停下来问不许猜、不许脑补、不许替用户决策。文档驱动防幻觉。Tailwind / React / useRequest 等关键依赖强制先读 Context7 官方文档再回答每个 Skill 第一步必读项目 rule 文件。代码不是从模型训练数据里瞎编的是从真实文档锚定出来的。spec 单目录收拢。前面展开讲了——所有产出在一个目录下进度可追踪上下文不丢失Review 时一眼看清全貌。三条铁律是血泪堆出来的这些规则是踩了无数次坑之后焊死的每条背后都有一个真实翻车现场。Characterization Test行为基线。改造老模块之前别急着写应该返回什么的测试。先跑一遍现有代码把实际输出记录下来转成断言。测的是代码实际在做什么不是应该做什么。这一步跳过去直接改代码改完之后 AI 可能悄悄改了某个没测到的行为路径——测试全绿、diff 干净、上线炸了。这种情况最阴险了因为你不是没测你测错东西了。预期值必须是字面量。expect(price).toBe(1.00)不能写成expect(price).toBe((100/100).toFixed(2))。不能在断言里重算被测逻辑来拼 expected——万一被测的算法有 bug你的 expected 也跟着错测试永远绿。这条规则看着简单我见过至少三次因为违反它导致线上事故。每批只做 1-3 个。测试也好、组件也好AI 一次生成 20 个一半跑不通整批都不可信。每批做 1-3 个跑通、review 过、确认没问题再做下一批。慢就是快。不做什么这些规则是 AI 替我踩出来的。有一次它顺手改了一个不在需求范围内的导出逻辑review 没发现上线后导出的 Excel 列名全是错的。从那以后不做什么变成了强制约束写在每个 Skill 的禁区栏里。不在没有 PRD 的情况下凭空拆任务不引入项目技术栈以外的依赖不顺手重构不在任务范围内的代码不用 AI 自己说的没问题代替人手验证不为一次性操作创建 Skill——只有可复制、可参数化、可自动化的事才值得 Skill 化跨项目分发别让 Skill 分叉一套 Skill 打磨好了不能让每个项目手动拷。我们最早就是手动拷的两个月后发现 A 项目改了product加了防重复B 项目还在用旧版——同一个坑 B 项目月月踩。手动拷的致命问题不是麻烦是分叉。后来写了同步脚本一个sync.sh推到所有下游。源仓库改了什么所有项目统一更新。为什么是 OpenSpec不是 Spec-Kit 或 Superpowers现在市面上做规范驱动开发的主流方案有三个Spec-KitGitHub 官方、OpenSpecFission-AI 社区、Superpowers。三个我都研究过说说我为什么选了 OpenSpec。理念适合场景安装学习成本Spec-Kit七阶段门控流水线流程严谨新项目、大团队、企业级合规Python uv较重中等偏高OpenSpec三步迭代propose→apply→archive轻量灵活存量改造、小团队、敏捷迭代npm install -g30 秒低SuperpowersSkill 机制 harness 配置工具集成深已有 Claude Code 深度用户需 hooks 和权限管控配置式不依赖 CLI中等我的选择逻辑很简单——我的场景是在已有项目上做增量改造不是从零搭建新项目。团队不大流程不想太重。OpenSpec 的三步走提案→执行→归档刚好够用不绑 GitHub 生态装完就能跑而且对 Claude Code / Codex / Cursor 的兼容最好。Spec-Kit 太像瀑布流了——七个阶段一个一个过对存量项目来说太重。Superpowers 的思路很好但它更偏工具配置层不太适合作为团队协作的主流程引擎。我们这套 Skill 体系的灵感其实都参考了上面三个 SDD 工具 只是opensepc 理论作为基座选工具的核心不是谁功能多是谁刚好够用不多不少。对我来说OpenSpec 刚好卡在这个位置。Skill 是长出来的 从哪开始第一个版本的 Skill 很粗糙就三四步。跑第一个需求review发现 AI 生成已存在的组件——product补上第零步。跑第二个需求review发现没处理 loading 态——page补上四态覆盖。跑第三个需求线上 Bug 查三天找不到根因——bugfix补上根因确认铁律。跑第四个需求QA 说测试用例没覆盖——qa从零写出来。四个需求下来八个 Skill 被真实业务反复摩擦该补的坑都补上了。网上的现成 Skill 可以参考但骨架得自己搭——只有你们知道禁区在哪、习惯是什么。如果你现在就想动手先只做一个 Skill——挑最痛点。需求不清做productUI 还原差做uiBug 反复出做bugfix。一个跑稳再扩用 Markdown 写放.claude/skills/下。结构就三段触发条件、执行步骤标注决策点、常见坑建一个单目录收产出哪怕只收两三个文件也比到处散落强。进度用 yaml 标别靠脑子记第一个版本别追求完美跑起来review自然会告诉你漏了什么CLAUDE.md 是约束来源——Skill 管流程CLAUDE.md 管规范AI 跑偏了先判是哪个漏了单项目跑稳之后下一步是多 Agent 并行——这块上一篇文章已经展开聊了。顺序不能反Skill 是基础多 Agent 是加速器。先把八个 Skill 跑上三五个需求每个 Skill 的产出格式稳定了、决策点验证过了、常见坑表累计了至少五条了再拆并行。多 Agent 这块我目前自己也在试水阶段实践不到一个月预计一个月后深度分享企业级多 Agent 的AI Coding 团队协作的经验。学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%免费】
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
