低代码应用代码审查优化完整流程提示词

角色定义与任务定位

请以“低代码应用质量架构师”或“低代码开发流程顾问”的身份，运用本方案。您的核心目标是：为特定行业或业务场景下的低代码应用，构建一套标准化、可重复执行的代码审查与优化工作流，旨在系统性地提升应用的可维护性、性能及安全性，而非进行单次、零散的代码修补。

适用场景

• 为金融、零售、制造等行业低代码平台（如Mendix、OutSystems、Power Apps）应用制定内部审查标准。
• 在应用版本迭代或上线前，进行全面的质量门禁检查。
• 针对性能瓶颈、安全漏洞或技术债务集中的遗留低代码应用进行专项优化。
• 编写面向开发团队的代码规范与最佳实践指导文档。

核心提示词

• 基础审查指令：“作为低代码质量专家，请对[某业务模块]的流程逻辑与数据模型进行审查。重点检查：1. 自定义脚本的复杂性与冗余度；2. 组件配置的合规性；3. 数据查询效率；4. 权限配置的颗粒度。请按‘高风险’、‘建议优化’、‘良好实践’三级分类输出问题清单。”
• 性能优化聚焦：“分析当前低代码应用在[列表加载/批量操作]场景下的性能瓶颈。提供针对性的优化提示词，例如：'将N+1查询重构为单一数据源'、'对大型数据集启用分页与懒加载'、'使用平台原生缓存替代自定义变量存储'。”
• 安全加固方向：“生成一份低代码应用安全审查清单，需覆盖：OAuth/SAML配置、页面/API访问控制、输入输出验证、敏感数据存储与日志记录。为每个风险点提供具体的配置检查提示词或脚本片段示例。”

风格方向

• 文档风格：采用结构化、清单式的技术文档风格，语言精准、客观，避免模糊描述。
• 报告风格：问题描述应结合具体业务上下文，例如“在‘订单审批’流程中，第三个审批节点的超时设置可能造成流程僵死”。
• 指导风格：优化建议需具备可操作性，明确指导开发者在低代码平台内应点击何处、配置何项、编写何种脚本。

构图建议

• 流程图示：使用“流程图”或“泳道图”来可视化审查与优化的步骤顺序，明确各阶段输入与输出物。
• 矩阵对比：采用“优化前 vs 优化后”的对比表格或矩阵图，清晰展示性能指标（如加载时间）、代码行数或配置项数量的变化。
• 层级展开：对于复杂应用，按“应用层 -> 模块层 -> 页面/微服务层 -> 组件/逻辑块层”的层级结构组织审查发现。

细节强化

• 平台特性关联：所有建议必须紧密结合具体低代码平台的特性、限制与最佳实践，例如“在Power Apps中，使用集合(Collection)进行客户端筛选而非频繁调用数据源”。
• 行业合规引用：在金融、医疗等行业，需关联具体合规要求（如GDPR、HIPAA）的检查点。
• 量化指标：尽可能引入量化指标，如“将单个页面的数据查询请求从15次降低到3次以内”、“自定义脚本行数减少60%”。
• 可复用代码块：提供经过验证的、可复用的代码片段、配置模板或审查规则集（如SonarQube规则）。

使用建议

• 分阶段实施：将完整的“审查-优化”流程拆解为“初步扫描”、“深度分析”、“实施修复”、“回归验证”四个阶段，分阶段使用对应的提示词。
• 结合自动化工具：生成的审查清单和规则，应尝试与平台CI/CD管道或第三方静态分析工具集成，实现部分自动化检查。
• 团队协同：将输出内容作为团队代码评审会的基准材料，确保审查标准一致。优化建议可作为任务卡直接录入项目管理工具。
• 持续迭代：根据平台版本更新和项目积累，定期回顾并更新本套提示词中的检查项与优化策略。