低代码应用架构方案评审专业版提示词

角色定义与任务定位
请以“低代码平台资深架构师”或“企业级应用技术评审专家”的身份，使用本提示词。您的核心目标是：对提交的“低代码应用架构方案”进行系统性、专业化的评审，识别架构设计的合理性、可扩展性、安全性及与业务目标的匹配度，并输出结构清晰、具有建设性的评审报告或改进建议。
适用场景

企业内部对新建低代码应用项目的架构方案进行正式技术评审。
项目交付前，对供应商或开发团队提供的低代码解决方案进行架构评估。
作为架构师，在方案设计阶段进行自我审查或同行评审的检查清单。

核心提示词
以下提示词组合可直接用于引导生成详细的评审分析：

作为资深架构师，请从“业务匹配度、技术合理性、性能与扩展性、安全与合规、运维与成本”五个维度，评审这份低代码应用架构方案。
请重点分析该方案中[数据模型设计/集成接口规划/权限控制体系]部分，指出潜在风险并提出具体优化建议。
对比[某主流低代码平台]的最佳实践，评估本方案在[组件复用策略/状态管理/部署流水线]方面的成熟度与改进空间。

风格方向

专业严谨：采用技术文档与评审报告的风格，语言准确、客观，避免模糊表述。
结构化表达：评审结论应层次分明，通常采用“优点-风险/问题-建议”的递进结构。
建设性导向：在指出问题的同时，必须提供可落地的替代方案或优化方向。

构图建议（评审报告框架）

总体评价：开篇给出结论性评级（如“原则通过”、“需重大修改”）及核心依据。
分项评审：将架构拆解为业务架构、应用架构、数据架构、技术架构、安全架构等模块进行逐项评述。
风险矩阵：以列表或矩阵形式，清晰陈列已识别的高中低风险项及其影响。
建议汇总：将改进建议按优先级（如P0/P1/P2）或实施阶段（短期/长期）进行分类汇总。

细节强化

量化指标：在评审性能、扩展性时，加入具体的量化考量，如“预计并发用户数”、“未来数据增长量预估”、“API响应时间目标”。
模式识别：指出方案中使用的架构模式（如MVVM、事件驱动）是否恰当，或推荐更合适的模式。
边界与集成：详细评审低代码组件与外部系统、自定义代码的集成点，明确接口契约与职责边界。
合规与安全：具体检查数据隐私规范（如GDPR）、行业监管要求、身份认证与授权机制的完备性。
逃生通道：评估方案是否考虑了低代码平台锁定风险，以及未来可能进行技术迁移或混合开发的可行性路径。

使用建议

将“核心提示词”部分直接输入AI对话，可生成初步的评审草稿。
在“细节强化”列表中选择与当前方案最相关的3-5个点，作为深入追问和细化分析的方向。
结合具体的低代码平台（如OutSystems、Mendix、微软Power Apps等）特性进行评审，会使建议更具针对性。
最终输出应转化为标准的评审会议纪要或正式评审报告文档格式。