AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载导读产品退市End-of-Life, EOL是产品经理最艰难、也最容易被搞砸的沟通场景一份与变更规模不成比例的通知要么让客户忽视你要么直接制造一场支持事故。本指南围绕 Product-Manager-Skills 仓库中的eol-message技能展开系统讲解如何把我们要停掉某个产品写成一份以客户为中心、按爆炸半径分级、可立即复制套用的 EOL 公告——读完你将掌握 Brief/Standard/Full 三档消息的选型逻辑、Replacement/Migration/Graceful exit 三条过渡路径的写法、八个生命周期门Lifecycle Gates的用法以及一整套可直接照抄的模板与质量检查清单。eol-message是仓库中 Lifecycle EOL Suite生命周期与退市技能套件的核心产出物之一属于eol-transition主题下的 Component 型技能定位在六阶段流程的第 5 阶段Announce公告当决策、利益相关方对齐、运营计划与内部赋能都已完成之后用它来撰写面向客户的退市公告。套件的总纲是lose the product without losing the customer失去产品但不能失去客户。一、技能定位它解决什么问题1.1 技能元数据与适用场景先看 skills/eol-message/SKILL.md 的 frontmatter 元数据name:eol-messageargument-hint:[product or feature being retired]要退市的产品或功能type:componenttheme:eol-transitionestimated_time: 20–40 分钟description / intent: 撰写一份大小恰到好处right-sized的 EOL 公告——从简短通知到完整的分阶段沟通——包含理由、客户影响与下一步行动用于在艰难过渡期维持客户信任、降低因客户感到被抛弃而产生的流失。其在 catalog/skills-index.yaml 中的登记信息与此一致注册路径为skills/eol-message/SKILL.md。技能的最佳适用场景best_for宣布产品、功能或套餐退市但不制造支持事故将公告规模与变更本身匹配——变更小就给通知而不是写一篇长篇大论处理最难的场景没有替代品的退市graceful exit。典型场景scenarios我们 12 月要停用遗留模块需要通知 800 个账户。我们要停产一条硬件产品线涉及服务合同和渠道合作伙伴——该发什么1.2 在 EOL 套件中的位置eol-message不是孤立的。在 Lifecycle EOL Suite Summary 中套件被组织为两个主题、八个技能上游product-lifecycle决策lifecycle-play-advisor、product-lifecycle-plays回答该扩展、替换还是退市执行eol-transition六阶段eol-readiness-advisorDecide→eol-stakeholder-sequenceAlign→eol-checklistPlan→eol-internal-enablementPrepare→eol-messageAnnounce→eol-processClose。套件内每个技能都独立可用、彼此不互为前置依赖详见共享词汇章节但若你已跑过eol-readiness-advisor的强度评估只需说一句Level 2即可让eol-message按对应强度来定消息规模。也就是说先在 upstream 确认退市是正确打法再到这里来写客户公告。1.3 这不是什么技能的目的明确强调这不是一份泛泛的 sunset 公告——而是一份承认损失、同时把变革框定为进步的、以客户为中心的沟通。 它还有明确的Anti-Patterns反模式清单不是一封简短的关停通知不能只写Were discontinuing Product X. Goodbye.不是以企业为中心的不要以这降低了我们的成本开头不能含糊Soon很快不是时间线不能有防御性不要责怪客户如低使用率迫使我们关停不能一刀切每个 sunset 都用同一套模板、同一长度就是比例失当。二、核心概念决定公告成败的五个框架2.1 按变更规模分级Size the Message to the Change技能中最核心的判断是EOL 沟通最常见的失败不是语气而是比例proportion。一个六段式公告去通知一个废弃的复选框会让客户养成忽略你通知的习惯而一条一行话的通知去通知承载真实工作流的产品则直接制造支持事故。Brief简短Standard标准Full完整适用场景功能、内部工具、无人使用的选项商业产品、活跃客户收入关键、硬件、受监管篇幅1–3 段1 页 阶段表phase table多部分、跨数月分阶段使用的章节公告、时间线、行动号召全部 9 节轻量使用全部 9 节 合规与义务提前量数周6–12 个月12–24 个月渠道应用内或 changelog邮件 应用内 文档邮件 客户成功团队 合作伙伴 媒体大多数公告属于 Standard。实践方式是推荐一个档位用一句话说明理由然后让使用者自行调整。如果对方为你会定为 Standard 的场景选择了 Brief要明确指出被丢弃的那个要素——通常是阶段表phase table而阶段表正是防止等等它到底什么时候停止工作这类工单的关键。2.2 三条过渡路径The Three Transition Paths你真正告诉客户的是他们最终落在哪里。答案有三种且会产出三种截然不同的消息Replacement替代——你的另一个产品接管。消息侧重连续性什么会延续、什么会改进。此时定位positioning最重要。Migration迁移——同一产品家族内的不同层级、配置或平台。消息侧重机制客户必须做什么、何时完成、工作量多大。必须诚实说明工作量低估它是通往不信任最快的路。Graceful exit优雅退出——没有替代品。消息侧重尊严诚实的理由、数据导出、充足的提前通知、以及真实可用的替代方案——包括竞争对手。点名一个竞争对手比让客户流离失所带来的声誉损失便宜得多。技能特别指出优雅退出是团队写得最烂的一种因为它让人感觉最糟——但恰恰也是客户评判你最严苛的一种。2.3 生命周期门Lifecycle Gates共享词汇EOL 不是某一个日期。把多个门压缩进一次公告正是我以为它还在工作那波支持工单的来源。套件在 Lifecycle EOL Suite Summary 中统一了八个门的定义GAGeneral Availability仍在积极销售、完全支持这是一个状态不是工作阶段NSCNotice of Status Change决策已传达规划开始EOSEnd of Sale新客户不能再购买EOEEnd of Expansion现有客户不能再增加容量或席位EOREnd of Renewal现有合同不再续签合同驱动的门仅在需要时使用EOMEnd of Maintenance缺陷修复与补丁停止EOLEnd of Life产品退市EOSRVEnd of Service所有支持与服务义务结束。Brief 消息点名两三个门Full 消息以表格列出全部八个。无论用哪几个门都必须用客户的语言定义它们——你可以继续使用但我们不再发布修复远胜于EOM: 3/2027。同时点名你不用的门与点名你在用的门同样有用而Not scheduled未排期加上何时可以排期的前置条件胜过凭空编一个日后必然当众食言的 EOL 日期。2.4 九段式 EOL 消息框架一份有效的 EOL 消息在对变更诚实与对客户影响共情之间保持平衡由九个部分组成Company context公司背景我们是谁我们对客户的承诺The announcement公告什么在结束、什么在替代它The rationale理由为什么这对客户有利而不只是对业务有利Current product context现有产品背景这个产品是什么、服务了谁Customer impact客户影响对用户的影响承认干扰Transition solution过渡方案落地点及其对比Support measures支持措施你将如何帮助他们到达那里Timeline时间线关键日期与门Call to action行动号召下一步与联系方式。为什么有效Why This Works共情优先先承认干扰再为决策辩护清晰变更什么、何时变更没有歧义支持导向表明你不会在过渡中途抛弃客户面向未来把变革框定为进步而非损失。2.5 便签规则The Sticky-Note Rule客户在读完一遍之后应该能在一张便签上写下自己必须做什么、以及何时做完。如果做不到这份消息就是装饰品。每条草稿在发出前都要用这条规则测试。与之配套的还有何时使用/何时不使用用停用产品/功能/服务把客户从遗留平台迁移到新平台停用收购来的产品弃用技术栈或 API。不用客户能做的事没有改变的微小调整不要过度沟通还没有过渡计划时要在你确定如何支持客户之后再沟通当你暗地里希望客户没注意到时要透明。三、实战步骤八步写出可发送的 EOL 消息技能正文skills/eol-message/SKILL.md 的 Application 章节提供了从定规模到后续跟进的可执行八步流程配合 skills/eol-message/template.md 的填空模板使用。下面按步骤展开并保留原文档的可运行模板片段。3.1 输入约定先回答再提问最佳输入要退市的是什么产品、功能或套餐以及大致时间。有用的附加输入理由、受影响的客户细分、迁移或替代路径、支持承诺以及任何约束你措辞的合同或监管语言。技能遵循仓库所有技能的通用输入约定与eol-readiness-advisor等一致凡是调用时已附带的信息——技能名后的文本、粘贴的上下文转储、或追加的ARGUMENTS:行——都算已给出的答案直接使用并跳过不要重复询问。空手而来也可以。技能会在动笔前先询问退市什么/何时/为何以及落地点然后推荐一个可覆盖的消息规模。无论何种情况理由和下一步行动这两项都会被追问——因为没有理由、没有下一步的 EOL 消息读起来就是被抛弃。示例调用Draft an EOL message: retiring our legacy reporting module Dec 31, replaced by the new analytics dashboard; 400 accounts affected.Were killing a feature nobody uses. Give me the brief version — no replacement, 3 weeks notice.3.2 Step 1确定规模与路径动笔前先敲定两件事规模SizeBrief / Standard / Full。依据爆炸半径客户数、收入、合同、是否涉及硬件或合作伙伴推荐一档然后允许用户覆盖。用一句话说明更小的档位会丢什么。路径PathReplacement / Migration / Graceful exit。这决定了消息强调什么以及 Transition Solution 一节是一份定位陈述还是一个退出计划。3.3 Step 2收集上下文技能列出的七项必收信息被停用的产品具体是什么在结束落地点什么在替代它如果有时间线哪些门适用、每个门落在哪一天客户影响多少用户哪些工作流被打断支持计划迁移帮助、培训、折扣、数据导出工具理由为什么发生这件事约束合同语言、监管要求、做过的终身承诺。缺上下文怎么办没有过渡计划就别发。客户一定会问What do I do now?——你必须已有答案。起草没问题发送不行。3.4 Step 3起草过渡叙事Transition Narrative这是消息的门面包含公司背景、公告、理由三块模板如下**We are:** [Company and its relationship to the product being phased out] - [Commitment to customers] - [How the product line evolves] - [Where youre headed]示例来自 skills/eol-message/examples/sample.md**We are:** Fieldlight, a field service management platform serving 4,000 service businesses - Were committed to getting your technicians to the right job with the right information - We continuously evolve the platform based on how crews actually work - Were building toward scheduling that adapts in real time to what happens in the field公告必须一句话讲清 EOL 事实并点名落地点**Announcing:** - [Single sentence stating the EOL clearly and naming the landing place]示例ReplacementWe are retiring Fieldlight Classic Dispatch on December 31, 2026, and moving all accounts to Fieldlight Next Scheduling.示例Graceful exit 变体We are retiring Fieldlight Route Optimizer on June 30, 2027. We do not have a replacement, and we want to be direct about that.理由必须站在客户受益角度模板与示例**Because:** - [Reason 1] - [Reason 2] - [Reason 3] **Which means for you:** - [Impact and benefits from the customers perspective]**Because:** - Classic Dispatch runs on infrastructure that cant support real-time schedule changes - Next Scheduling reoptimizes routes as jobs run long or get cancelled - Consolidating lets us put all engineering effort into one scheduler instead of two **Which means for you:** - Schedules that adjust when the day goes sideways, instead of at 6am only - Technician arrival windows you can actually promise customers - Every future scheduling improvement lands in the product youre on3.5 Step 4交代现有产品背景承认失去什么承认正在失去什么。Brief 消息可跳过本节。模板**Our product** [name] - **is a** [description and primary function] - **that has served** [customer type] for [duration] - **by providing** [key benefits it delivered]3.6 Step 5承认客户影响务必诚实对干扰诚实是整条消息中最重要的一环——低估工作量是整条消息里最具破坏性的捷径。模板**We understand that this may affect you by:** - [Impact 1 on operations or process] - [Impact 2] - [Impact 3]示例**We understand that this may affect you by:** - Requiring you to rebuild recurring dispatch rules (most accounts: 2-3 hours) - Retraining dispatchers on a different scheduling board - Updating any integrations that read the Classic dispatch API注意2–3 小时这类可证伪的工作量估算客户真去计时若发现准确就会信任你接下来说的每一句话。3.7 Step 6呈现过渡方案Transition SolutionReplacement / Migration 路径——采用定位陈述格式参见 skills/positioning-statement/SKILL.md**For** [affected customer] - **that currently use** [old product] - [replacement] - **is a** [category] - **that** [benefit, focused on continuity and improvement] ### Differentiation and Continuity - **Like** [old product], - [replacement] - **provides** [what carries forward] - **while also offering** [whats new]Graceful exit 路径——用一份诚实的退出计划替换上面的定位陈述### What Happens to Your Data - [Export format, how to get it, how long it stays available] ### Alternatives Wed Point You To - [Option 1, including competitors, with a note on fit] - [Option 2] ### What Were Doing to Help - [Extended access, export tooling, migration credits, refunds where owed]3.8 Step 7列出支持措施与时间线**To ensure a smooth transition, we will:** - [Support measure 1] - [Support measure 2] - [Support measure 3] ### Timeline | Gate | Date | What it means for you | |---|---|---| | [Gate] | [Date] | [Plain-language consequence] |时间线的三条质量检查足够的提前量Standard 通常 6–12 个月涉及合同和硬件则更长用客户语言写门停止接收修复而不是EOM明确写出数据导出截止日他们什么时候会失去对自己数据的访问权3.9 Step 8给出明确的下一步### Call to Action - [Specific first action, with the link or path] - [How to get help, with real contact info]3.10 收尾提供接下来的选项交付草稿后向使用者提供编号选项这是技能内置的 Agent 交互协议压力测试Pressure-test it——以怀疑客户的视角重读一遍标出不清楚的地方改规模Resize it——产出同一份消息的 Brief 或 Full 版本分客群Segment it——为企业客户、SMB、合作伙伴分别产出变体因为他们需要不同的内容检查就绪度Check the readiness case——如果退市决策本身还需要辩护参见 skills/eol-readiness-advisor/SKILL.md。四、配套模板与质量检查清单skills/eol-message/template.md 是可直接复制使用的填空模板开篇再次强调先选规模与路径规模大多数公告是 StandardBrief/Standard/Full 三档对照表同前路径决定 Transition Solution 一节的内容Replacement→ 定位陈述Migration→ 机制与工作量Graceful exit→ 数据、替代方案、尊严。4.1 Brief 模板## [Product/Feature] is being retired on [date] [One sentence: whats ending, when, and what replaces it — or that nothing does.] **What you need to do:** [The single action, with a link.] **What happens if you do nothing:** [Plain consequence on the date.] Questions: [real contact]注意 Brief 的三段式骨架——公告、单一行动、不作为的后果——正是便签规则能成立的形态。4.2 Standard / Full 模板Standard/Full 共用一套更长的骨架Product Transition Narrative → Current Product Context → Customer Impact → Transition Solution → Support and Next Steps → Timeline → Call to Action其中时间线表预置了五个常用门及其客户语言释义| Gate | Date | What it means for you | |---|---|---| | End of Sale | [date] | [No new purchases — plain language] | | End of Expansion | [date] | [No added seats/capacity] | | End of Maintenance | [date] | [Still works; no more fixes] | | End of Life | [date] | [Stops working] | | End of Service | [date] | [Support and service obligations end] |仅 Full 档附加Contractual and Regulatory Notes合同/SLA/认证语言、退款/授信/尾差结算条款。4.3 发出前的质量检查任何一项否都要重写模板末尾内置了五组检查项Proportion比例规模与爆炸半径匹配若选小了明确知道丢掉了哪个章节点名的门是实际会生效的门点名未用到的门只会添乱Clarity清晰通过便签测试每个门都用客户后果表述而非内部缩写数据导出截止日显眼且不可错过没有soon、in the coming months、at a future dateEmpathy共情先承认影响再推销好处工作量估算诚实客户计时验证时你敢于背书理由站在客户受益角度而非成本节省语气中没有暗示客户用得不够多所以活该Completeness完整落地点已点名——包括没有落地点也要直说支持措施具体且真实不是联系支持联系渠道确实有人值守优雅退出必须列出替代方案诚实时包含竞争对手Obligations义务合同、SLA、终身承诺语言已经过能读懂它的人审查消息中没有与客户被销售时承诺相矛盾的内容。五、两个完整示例从 SaaS 到工业硬件技能自带两个跨领域、相互衔接的完整示例演示同一套框架在两种极端场景下的应用。5.1 SaaS 示例Fieldlight Classic DispatchStandard / Replacementskills/eol-message/examples/sample.md 的场景设定约 800 个账户、240 万美元 ARR、年付合同、无监管约束由 Fieldlight Next Scheduling 替代其中约 30 个账户使用无法迁移的自定义派单规则。消息全文可在示例文件中查看其为什么有效部分总结了五个关键点先共情再推销影响一节在好处再次出现之前就点名了再培训成本和集成工作诚实的工作量估算2–3 小时可证伪客户验证为准则信任你接下来说的一切点名而非隐藏难点客群约 30 个自定义规则账户获得明确承诺我们知道你们是谁而不是在迁移中自己发现坑用客户后果写门Classic 仍可运行但停止发布修复——没人需要知道 EOM 是什么意思提前量与被要求的改变相称对需要再培训和重建工作的变更给出十个月。该示例还附赠了同一件事写得有多烂的对照版本Subject: Important changes to your Fieldlight account As part of our ongoing platform modernization, Fieldlight Classic Dispatch will be sunset later this year. Due to low adoption and rising maintenance costs... Customers will be migrated to Fieldlight Next. Please contact support with any questions.它逐条剖析了坏版本的五处致命伤later this year直接败给便签测试理由全是 Fieldlight 自己的问题low adoption在天天使用的 800 个账户读来就是你无足轻重被动语态Customers will be migrated隐藏了真正干活的人客户自己没有任何影响承认contact support没有为 30 个自定义规则账户指名出路——而他们恰恰是最可能因此流失的账户。结论一针见血同样的决策、同样的产品、同样的日期第一个版本产出迁移第二个版本产出一队支持工单和一次流失高峰。5.2 工业示例NFA-200 控制器Full / Replacement 渠道与监管义务skills/eol-message/examples/sample-industrial.md 的场景约 120 处安装、8 个渠道合作伙伴转售、服务合同持续到 2028 年、UL/CE 认证、现场有备件库存。后继平台 NFA-500不是即插即用替代——它需要不同的安装支架和逐站点改造。这个示例最大的教学点是它的前提这是一份 End-of-Sale 公告而不是 End-of-Life 公告。就绪度评估落在先停售、缓停用退役压力来自内部制造部门想要回产线服务义务持续到 2028且尚无即插即用的迁移路径。因此消息停止销售该产品、承诺继续服务而不是告诉 120 个站点他们的控制器要黑屏——在这里宣布完整 EOL等于宣布一个你守不住的日期。该示例的亮点做法标题先拆掉恐慌引信您的已装机 NFA-200 不受影响直接放在公告正文里而不是藏在第四节——工业场景的第一问题永远是我的产线会停吗不连续点直说不含混每次迁移都是一次经勘察的现场访问。把它当项目预算而不是一次更换。销售会恨这句话但它能避免一整年的纠纷义务是被兑现而非仅被提及服务协议、认证状态UL 508A / CE 保持有效、变更控制文档、最后购买last-time-buy各得一项具体承诺——这正是 Brief/Standard 没有、因而需要 Full 档的章节白纸黑字承诺我们永远不会远程禁用已装机设备有记录的 EOL 失败中最恶劣的就是厂商远程砖化客户已付款的硬件渠道伙伴有明确路径最后购买明确经由他们下单八个转售商不会从自己的客户那里才得知消息。它同时刻意不做三件事不为了显得果断而硬编一个 EOL 日期门表停在 End of Service 并说明原因不吹嘘 NFA-500连续性一节只列真实延续项把安装不兼容单独拆出来讲不以制造产能开头那是真实内部诱因但只以对客户真实成立的益处形式出现——对已装机客户备件可得性确实改善了。六、六个常见坑Common Pitfalls与对策技能正文SKILL.md 的 Common Pitfalls 章节汇总了六种高频失败模式每条都给出症状、后果与修复方法以企业为中心的理由Business-Centric Rationale症状我们停掉 X 以降低成本、精简产品组合。后果客户觉得自己是商业决策的连带损伤。修复把理由框定为客户受益——我们合并到 Y是为了把全部工程资源投入你们要求的特性。含糊的时间线Vague Timeline症状Product X 很快就会停用。后果客户无法规划焦虑与流失上升。修复针对具名门给出具体日期——3 月 1 日停止新购。12 月 31 日全面关停数据导出截止。没有支持计划No Support Plan症状你需要迁移到 Y。祝好运后果客户感到被抛弃流失风险高。修复提供真实帮助一对一协助、自动迁移工具、过渡期定价、培训。无视客户影响Ignoring Customer Impact症状消息从公告直接跳到这是新产品后果客户觉得自己的顾虑从未被承认。修复明确点名干扰包括他们要花多长时间。生硬或防御性的语气Terse or Defensive Tone症状由于低使用率我们关停 X。后果听起来像是在责怪真正在用的客户。修复共情且向前看。低使用率是你的业务背景不是他们的错。所有 sunset 一个尺码One Size For Every Sunset症状每次退市都用同一份长篇模板或每次都在 changelog 里写一行。后果鸡毛蒜皮的变更用长篇通知训练客户忽略你——真正重要的那次也被一起忽略真实退市只给 changelog 一行则变成支持事故。修复审慎选择 Brief / Standard / Full 并说明理由选小档时明确知道你丢了哪一节。七、与其他技能的协作与调用约定7.1 相关技能均独立可用互不前置skills/eol-readiness-advisor/SKILL.md——退市决策的 go/no-go 与强度档位intensity dial。它的交付物包含强度级别Level 1–3并且在其四个编号后续选项中第 4 项就是起草客户公告 → 见 eol-message反过来eol-message若遇到决策本身还需要辩护的情况会指向eol-readiness-advisor。两个技能互为上下游、无格式交接负担只靠一句Level 2传参skills/positioning-statement/SKILL.md——为 Transition Solution 的 Replacement/Migration 路径提供定位陈述格式skills/problem-statement/SKILL.md——辅助框定客户影响章节skills/proto-persona/SKILL.md——定义受影响客户用于产出分客群变体。7.2 技能文件的结构约定仓库通过 scripts/check-skill-metadata.py 对每个 SKILL.md 做元数据与章节结构校验要求合法的 YAML frontmatter、name/description/intent/type等字段齐全且正文中的##章节必须按Purpose → ... → References的既定顺序出现check_required_sections会检查缺失与乱序。eol-message的技能文件即遵循这一约定——这也是为什么每个技能的正文结构Purpose / Key Concepts / Application / Examples / Common Pitfalls / References都高度一致、便于 Agent 与 LLM 检索引用。7.3 与强度档位的映射从 docs/Lifecycle and EOL Suite Summary 的右侧量表right-sizing dial可以看到套件统一的映射Level 1Light→ Brief 通知Level 2Standard→ 带阶段表的标准消息Level 3Heavy→ 带合规章节的完整消息。因此eol-message的 Brief/Standard/Full 三档正是整个套件每个技能三档、推荐一档、允许覆盖这一通用约定的具体落地。技能自己也强调Level 2 是默认绝不默认 Level 3选更轻是合法的但技能会点名更轻档位漏掉什么让选择建立在知情之上。结语从发出去到不流失eol-message提供的不是一份更漂亮的关停公告而是一套防止流失的沟通机器先用爆炸半径定规模Brief/Standard/Full再用三条路径Replacement/Migration/Graceful exit定叙事重心用八个生命周期门和九段框架搭好消息骨架用便签规则与五组质量检查把守发出前的最后关口最后用两个跨领域完整示例告诉你写得好与写得烂之间那几行字的差别。把它放进仓库的 EOL 套件链条中——前面接eol-readiness-advisor的 go/no-go 与强度判定后面配合 skills/eol-process/SKILL.md 的收尾复盘——你就能真正做到套件的总纲失去产品但不失去客户。赞分享AI 技能AI 插件【免费下载链接】Product-Manager-SkillsProduct Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.项目地址https://gitcode.com/gh_mirrors/pr/Product-Manager-Skills点击查看免费下载相关推荐Product Manager Skills 实战指南用 eol-checklist 为工业硬件产品构建六级相位 EOL 检查清单Product Manager Skills 实战指南用 eol checklist 为工业硬件产品构建六级相位 EOL 检查清单 导读 本文以 ProduAI 技能AI 插件Product Manager Skills 实战用 eol-checklist 构建 Fieldlight Classic Dispatch 的阶段门控 EOL 清单Product Manager Skills 实战用 eol checklist 构建 Fieldlight Classic Dispatch 的阶段门控 EAI 技能AI 插件RT-Thread STM32 BSP README 模板完全指南从模板到可运行开发板的工程化写作与上手实践RT Thread STM32 BSP README 模板完全指南从模板到可运行开发板的工程化写作与上手实践 导读 本文围绕 RT Thread 仓库中 STAI 技能AI 插件上一篇终极指南3分钟为Windows 11 LTSC一键安装微软商店下一篇终极指南Windows 11 LTSC快速安装微软商店完整方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考