ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

使用 GitHub Copilot 插件 power-platform-architect:从业务需求到 Power Platform 架构设计

使用 GitHub Copilot 插件 power-platform-architect:从业务需求到 Power Platform 架构设计 使用 GitHub Copilot 插件 power-platform-architect从业务需求到 Power Platform 架构设计【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本篇文章围绕当前仓库中的 power-platform-architect 插件 及其背后的 power-platform-architect 技能 展开。该插件让 GitHub Copilot 化身为一名 Microsoft Power Platform 高级解决方案架构师你只需给出业务需求、用例描述甚至是原始会议记录它就能产出一套量身定制的技术架构包括组件推荐与可选的 Mermaid.js 架构图。读完本文你将掌握该插件的安装方式、内部五阶段工作流程、Power Platform 组件选型决策逻辑以及如何复现它输出的端到端架构示例。插件定位与核心能力power-platform-architect 是 awesome-copilot 插件市场中围绕Power Platform 架构设计场景封装的一套即装即用能力。根据 plugin.json 中的描述它被定义为Solution Architect for the Microsoft Power Platform, turning business requirements into functioning Power Platform solution architectures.它面向的输入非常宽泛业务需求文档、高层用例描述、需求澄清访谈甚至一段多人讨论问题的会议录音转写稿meeting transcript。对应的产出则是一份以业务流程为主线的架构建议书——说明数据如何流经系统、每一步由哪个组件处理、哪类用户群体在哪个环节参与并可进一步生成一张简明的 Mermaid.js 流程图。该插件由 Microsoft 高级 AI 解决方案工程师 Tim Hanewich 创建详见 插件 README以 MIT 协议开源。安装与启用通过 GitHub Copilot CLI 安装在插件清单 docs/README.plugins.md 中说明awesome-copilot 本身就是 GitHub Copilot 的默认插件市场无需额外配置。在 Copilot CLI 中执行copilot plugin install power-platform-architectawesome-copilot在 VS Code 中发现与安装打开扩展搜索视图输入agentPlugins浏览可用插件或打开命令面板运行Chat: Plugins进行管理。插件元数据速览从 plugin.json 可以确认该插件的清单信息字段值namepower-platform-architectversion1.0.0licenseMITauthorTim Hanewich关键词power-platform、power-apps、dataverse、power-automate、power-pages、power-bi挂载技能./skills/power-platform-architect/插件通过extensions.com.github.awesome-copilot.skills声明将 skills/power-platform-architect/ 目录下的技能挂载进 Copilot 会话。插件包含的内容插件只封装一个技能见下表Skill说明power-platform-architect根据业务需求生成可落地的 Power Platform 功能架构该技能的加载元信息SKILL.md 的 frontmatter写道当用户需要把业务需求、用例描述或会议转写稿转化为技术性的 Power Platform 解决方案架构含组件选型与 Mermaid.js 图时应触发该技能。工作原理结构化的五阶段流程虽然输出给用户的内容是无缝的但技能内部通过五个阶段引导 Agent 完成架构设计指令细节见 SKILL.md。阶段一需求分析Requirements AnalysisAgent 扫描提供的材料转写稿或描述提取四类要素干系人stakeholders谁是系统的参与者数据源data sources数据从哪里来、要落到哪里安全需求security requirements权限与隔离要求功能性诉求functional asks用户真正想达成什么。同时记录现状As-Is流程并定位摩擦点——例如一份审批签字要等 4 天这类可被自动化的痛点为后续目标To-Be设计提供依据。阶段二需求澄清提问Requirements Follow Up在形成初步判断后Agent 会主动提出澄清问题以补齐信息缺口例如审批人休假或拒绝请求时的异常路径是什么这个应用是给无办公桌的一线员工手机/平板用还是给后台重度用户桌面/多列用是什么触发了这个流程用于决定数据如何被录入、或 Power Automate 流应如何触发数据是首次采集的还是从别处拉取的这些问题只是示例Agent 可自由追问任何必要问题。如果用户无法回答或拒绝回答则基于已有信息做出合理假设。阶段三组件推荐Component Recommendation综合原始信息与澄清答案Agent 推荐将参与架构的 Power Platform 组件并说明每个组件的职责。技能特别强调目标不是堆砌尽可能多的组件而是交付一份功能架构——每个入选组件都必须扮演真实且不可替代的角色。不需要解释没选哪些组件、为什么除非这些组件被记录为后续阶段才需要。阶段四架构推荐Architecture Recommendation这是整个技能的产出核心一份**面向业务流程business-process oriented**的架构叙事——以故事的口吻描述数据如何在过程中流动、被哪些组件引用或加工、被哪些用户人查看或修改。技能明确要求架构中必须包含用户。要具体到用户群体例如标注为Jane Doe 的团队、Dan 的审计团队、德州居民、业主或供应商而不是笼统的内部用户。阶段五架构可视化Architecture Visualization可选在给出文字架构后Agent 会以简单的是/否问题询问用户是否需要 Mermaid.js 架构图。如需要则遵循以下约定图不应过于复杂只描绘业务流程/信息流经架构的路径以及人类用户交互的界面与组件将图保存为用户机器上当前目录即可的一个.md文件.md文件中只包含裸的 mermaid 定义不要用mermaid graph LR %% Entities Vendor((Vendor)) ChrissyTeam[Chrissys Team] HiringManagers[Hiring Managers]%% Main Components AzurePortal[Azure Container AppsPortal] Dataverse[(DataverseDatabase)] PowerApp[Power AppCandidate Hub]%% Automation AI PA_Val[Power AutomateValidation] PA_Eval[Power AutomateCandidate Evaluation] Foundry[FoundryAI Models]%% Communication Outlook[OutlookFollow Up Request]%% Connections Vendor -- AzurePortal AzurePortal -- Dataverse Dataverse -- PowerApp Dataverse -- PA_Val Dataverse -- PA_EvalPA_Val -- Outlook Outlook -.-|After quiet period| VendorPA_Eval -- FoundryPowerApp -- ChrissyTeam PowerApp -- HiringManagers%% Styling style Dataverse fill:#f9f9f9,stroke:#333,stroke-width:2px style Outlook stroke-dasharray: 5 5## 技能内置的 Power Platform 组件目录 [SKILL.md](https://link.gitcode.com/i/b84dd744154be260857f226978d6c9af#power-platform-component-catalog) 为 Agent 内置了一份组件目录这也是最终架构产出可选组件的全集。插件 README 总结其覆盖范围包括**Power AppsCanvas、Model-Driven、Code Apps、Power Pages、Copilot Studio、Power Automate云端与桌面流、AI Builder、Dataverse、Power BI、连接器与网关**。各组件要点如下 - **Power Apps**面向*内部*用户的自定义业务应用Canvas 或 Model-Driven。 - **Canvas Apps**通过交互式拖放工具快速搭建、对界面布局与行为有完全控制权。适合快速开发、连接多种异构数据源、或需要像素级精确的移动/平板体验且不想写代码的场景例如一线员工移动应用、现场巡检表单。 - **Model-Driven Apps**适合数据密集、流程繁重的后台办公应用由 Dataverse 架构自动生成。适合需要标准化响应式设计、复杂安全与关系管理的场景例如 CRM 或资产管理。 - **Code Apps**在 VS Code 等 IDE 中用 React 等代码优先框架获得完全控制权同时复用 Power Platform 的托管托管、Entra ID 认证、可从 JavaScript 调用的 1500 连接器以及治理能力DLP、条件访问、共享限制。适合 Canvas/Model-Driven 无法满足自定义前端、但仍需运行于托管平台的场景。 - **Power Pages**面向外部合作伙伴、客户或内部门户的安全低代码网站。 - **Copilot Studio**AI 驱动的对话式智能体支持自然语言交互可基于知识源给出有依据的回答、借助工具对系统采取行动并可后台自主运行。 - **Power Automate**覆盖云与桌面的自动化平台。 - **云端流Cloud FlowsDPA**三种触发方式——*计划Scheduled*定时运行如每晚数据同步、*即时Instant*由用户按钮或应用动作手动触发、*自动Automated*由事件触发如创建记录、收到邮件、提交表单。用于跨系统集成、审批流与业务流程编排。 - **桌面流Desktop FlowsRPA**模拟人类与桌面应用、遗留系统交互的 UI 自动化。当系统没有 API、需要自动化旧式或本地软件如大型机终端、遗留 ERP 客户端的点击、键盘与屏幕抓取时使用。 - **AI Builder**为流程注入智能的预构建 AI 模型包括Prompts自定义生成式 AI 指令、文档处理自定义从复杂/非结构化文档提取自定义信息、发票处理预构建、文本识别 OCR预构建、收据处理预构建、身份证件读取器预构建、名片读取器预构建、情绪分析预构建、类别分类预构建/自定义、实体提取预构建/自定义、关键短语提取预构建、语言检测预构建、文本翻译预构建90 语言、对象检测自定义、图像描述预构建预览、预测自定义基于历史 Dataverse 记录预测二分类或数值结果。 - **Dataverse**Power Platform 生态的**主数据平台**。支持结构化关系数据表、列、关系与非结构化数据富文本、JSON可在记录上直接存储文件/图片提供企业级 RBAC安全角色、业务部门、行级/列级安全、基于团队共享通过索引、弹性表支持大规模性能内置审计、版本控制与业务规则。 - **连接器与自定义连接器**开箱即用 1500 标准连接器如 SharePoint、SQL Server、Salesforce、SAP、ServiceNow。当系统不在标准连接器列表中时可用**自定义连接器**将任意 REST API 包装为可复用连接器。 - **Power BI**分析与报表引擎可构建交互式仪表板、分页报表与基于几乎任何数据源的实时可视化。 - **网关Gateways**连接云服务与本地数据源的安全隧道。 ## 组件选型速查表决策逻辑 技能内置了一条针对解决方案主要需求的决策速查表[SKILL.md](https://link.gitcode.com/i/b84dd744154be260857f226978d6c9af#cheat-sheet-decision-logic-for-architecting)。注意这只是经验法则而非铁律 | 主要需求 | 推荐组件 | | --- | --- | | 需要公共/外部访问 | → Power Pages门户网站 | | 需要数据存储 | → Dataverse | | 内部数据录入/审核/流程 | → Power Apps | | 有遗留本地数据 | → 数据网关Data Gateways | | 多系统编排 | → Power Automate | | 对话式界面/智能体自动化 | → Copilot Studio | | 报表/仪表板/分析 | → Power BI | ## 推荐使用的示例提示词 插件 README 给出了三个可直接使用的提示词范例 - *Review this transcript from our discovery session and tell me how to build it.*审阅我们的发现会议转写稿告诉我如何构建它 - *What Power Platform components should I use for this HR onboarding use case?*这个 HR 入职用例该用哪些 Power Platform 组件 - *Generate an architecture diagram for a Power Apps solution that connects to SQL and uses an approval flow.*为一个连接 SQL 并使用审批流的 Power Apps 解决方案生成架构图 用户只需**提供一个问题陈述**即可开始甚至可以丢给它一段描述了问题/需求的会议转写稿。 ## 实战示例Evergreen County 太阳能许可端到端架构 插件 README 展示了一个完整的示例输出——面向某县太阳能屋顶许可审批流程Evergreen County Solar Permit的架构摘要。它生动地示范了业务流程叙事 按角色界面分工 数据主干统一的产出风格 ### 1. 申请提交居民与承包商 → Power Pages 居民和太阳能承包商访问县太阳能许可门户Power Pages。门户提供引导式申请表单包含必填字段、文档上传槽位场地平面图、电气图、已签署清单与费用确认。内置表单校验会在必填项为空或缺少附件时阻止提交——这是抵御不完整申请的第一道防线。对于现场或邮寄申请Marcus 的团队直接在 Model-Driven App 中录入数据同样受必填规则约束。所有提交的申请以 Submitted 状态落入 Dataverse。 ### 2. 自动完整性检查Power Automate AI Builder 提交后一条 Power Automate 云流自动触发器新建记录立即执行程序化完整性检查——验证附件是否齐全、费用确认是否记录、申请信息是否完整。对上传的文档AI Builder 的文档处理模型扫描场地平面图与已签署表单确认签名字段非空、关键数据区已填充捕捉 Marcus 描述的那些隐蔽缺陷——被引用但未附带的附件、无法辨认或未签名的文件。 - 若完整许可状态推进到 Under Review流转给指定的规划审核员Jim 的团队 - 若不完整状态置为 IncompletePower Automate 通过 Outlook 连接器自动向申请人发送邮件详细列出缺失内容。申请人可重新登录 Power Pages 门户上传更正材料——全程零人工参与。 ### 3. 方案审核与批准Jim 的团队 → Model-Driven App 指定的审核员在 Model-Driven App 中打开许可单视图内呈现全部申请数据、文档与 AI 校验结果。审核员评估后 - **批准** → Power Automate 将状态推进到 Approved – Pending Inspection并邮件通知申请人许可已批准、将安排检查 - **要求修改** → 状态置为 Revisions Requested通过邮件向申请人反馈具体意见申请人经门户重新提交 - **拒绝** → 状态置为 Denied 并记录理由通知申请人。 ### 4. 检查排期与现场作业Sarah 的团队 → 移动 Canvas App 许可到达 Approved – Pending Inspection 后Marcus 的团队通过 Model-Driven App 安排检查日期并自动邮件告知申请人。出发前Sarah 在手机/平板上打开 Canvas App 查看当日检查队列每条许可显示实时状态——若出现费用问题或申请人请求改期Sarah 可立即看到并改道去已就绪的现场不再白跑 40 分钟车程。 现场Sarah 通过 Canvas App - 完成结构化检查清单屋顶支架、接线盒、导管、序列牌 - 直接通过应用拍照——每张照片在拍摄瞬间自动关联到 Dataverse 中的许可记录不再需要从存储卡手工匹配 - 记录通过/未通过结果与备注。 结果实时同步到 Dataverse。Sarah 一提交办公室立刻看到检查结果——不再是几天之后。 ### 5. 许可签发或整改Power Automate Sarah 提交检查结果后 - **通过** → Power Automate 将状态置为 Permit Issued生成确认并通知申请人其太阳能安装获批 - **未通过** → 状态置为 Inspection Failed – Corrections Required附带 Sarah 的备注与照片通知申请人所需整改项并可通过门户重新预约复检。 ### 6. 自助状态跟踪居民与承包商 → Power Pages 流程任意阶段居民与承包商都可登录门户查看许可当前状态、处于哪个环节、费用是否已入账、下一步是什么。这直接回应了 Marcus 提及的三大高频电话咨询 1. ✅ 你们收到我的支票了吗 → 门户可见支付状态 2. ✅ 我的许可进展如何 → 实时阶段跟踪 3. ✅ 检查员什么时候来 → 展示已排期日期 ### 7. 实时分析与审计就绪Elena 与 Jim → Power BI Power BI 仪表板直连 Dataverse提供 - 许可办理时长指标平均值、中位数、按阶段 - 积压热力图——当前每个阶段积压多少许可 - 检查吞吐量——每日/每周完成检查数、通过率 - 按季度统计的绿色能源许可数——县审计员要求的确切指标 - 不完整申请率趋势——追踪门户校验是否正在降低 40% 的缺陷率。 Elena 可随时用实时数据回答董事会与审计员的问题——无需抽调员工做人工统计。 ### 架构总结 该架构用单一集成数据主干Dataverse取代脱节的纸质流程每个干系人通过适合其角色的界面触达同一数据源 | 受众 | 界面 | 目的 | | --- | --- | --- | | 居民与承包商 | Power Pages 门户 | 提交、跟踪、重新提交 | | Marcus受理 | Model-Driven App | 审核、排期、管理 | | Jim规划/审核 | Model-Driven App | 批准/拒绝许可 | | Sarah现场检查员 | Canvas App移动端 | 检查、采集、提交 | | Elena 与 Jim领导层 | Power BI 仪表板 | 监控、汇报、审计 | 预期影响直接回应了 Elena 的四大战略需求与 Jim 的预测**在不新增一名员工的情况下将积压减半**。 ## 使用要点与注意事项 - **输出不要用阶段措辞**技能明确要求向用户交付成果时不要使用阶段一、阶段二这类措辞——阶段划分只是 Agent 内部的执行流程用户看到的是无缝的最终成果见 [SKILL.md](https://link.gitcode.com/i/b84dd744154be260857f226978d6c9af#other-things-to-note)。 - **组件选型克制**架构追求功能性与唯一职责而非组件数量最大化。 - **用户必须入图入文**无论是文字架构还是 Mermaid 图都必须标注具体用户群体及其交互界面。 - **可追溯的实现依据**本文所描述的五阶段指令、组件目录、决策速查表与 Mermaid 示例均可在 [skills/power-platform-architect/SKILL.md](https://link.gitcode.com/i/b84dd744154be260857f226978d6c9af) 中逐条核对插件安装方式与市场定位可参考 [docs/README.plugins.md](https://link.gitcode.com/i/cf8db4006d4b504041e66103dd6ce287) 与 [docs/README.skills.md](https://link.gitcode.com/i/e22b0b165229746d931fef60193d1c1f)插件清单见 [plugins/power-platform-architect/plugin.json](https://link.gitcode.com/i/818caf8bdea18efb0901e5727395ee31)。 ## 结语 power-platform-architect 插件把业务语言 → 技术架构这条鸿沟交给 Copilot 自动跨越从一份问题陈述或一段会议录音开始经由需求分析、澄清提问、组件推荐、架构叙事与可选的可视化五个环节产出一份既有组件选型依据、又含业务流程叙事与按角色界面分工的完整 Power Platform 架构。对于正在评估 Power Platform 落地、或需要快速将模糊业务诉求转化为可评审技术方案含 Dataverse 数据模型、Power Automate 流程编排与 Power BI 指标设计的架构师与开发团队而言它是一个可直接从 awesome-copilot 市场安装并上手使用的效率工具。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表