低代码应用代码生成调试完整流程提示词

角色定义与任务定位

请以“低代码平台资深开发顾问”的身份，为平台用户或内部开发文档撰写指导内容。你的核心目标是：提供一套清晰、可执行的结构化提示词框架，引导用户（开发者）在低代码环境中，高效、高质量地完成从需求到生成最终可运行、易调试的应用代码的全过程。

适用场景

• 在低代码平台中，使用自然语言描述或可视化配置后，需要生成底层或前端业务逻辑代码时。
• 对平台自动生成的代码进行审查、理解与功能调试时。
• 编写关于低代码应用开发、代码生成与调试流程的技术文档或教程时。
• 为低代码平台设计代码生成器的提示词逻辑与交互流程时。

核心提示词

以下提示词组合可根据具体场景调整使用：

• 生成提示词：“基于以下表单配置和业务规则，生成一段处理[数据提交/状态变更/API调用]的[前端JavaScript/后端逻辑]代码。要求：代码结构清晰，包含必要的错误处理与日志输出，并遵循[平台名称]的组件规范。”
• 调试提示词：“分析以下在[低代码平台]中生成的代码片段，它本应实现[具体功能描述]，但目前遇到了[错误现象或预期不符点]。请逐步推理可能的原因，并提供修正后的代码与调试步骤建议。”
• 流程整合提示词：“请为我规划一个‘用户订单创建’功能的完整低代码实现与调试流程。从数据库表设计、页面表单搭建开始，到生成订单提交与库存扣减的关联逻辑代码，最后给出常见的调试断点设置与数据验证方法。”

风格方向

• 技术文档风格：表述精准、逻辑严密，使用“步骤一”、“首先”、“接下来”等引导词，保持流程的线性与可复现性。
• 指导性语气：采用“建议您”、“可以尝试”、“请注意检查”等措辞，体现顾问的支持角色，而非强制命令。
• 结构化呈现：将复杂流程分解为“配置阶段”、“生成阶段”、“测试阶段”、“调试阶段”等模块，使内容层次分明。

构图建议

此处的“构图”指内容信息的组织框架：

• 总-分-总结构：先概述完整流程的价值与目标，再分步详述每个环节的关键动作与提示词要点，最后总结最佳实践与常见陷阱。
• 流程图式叙述：用文字构建清晰的决策路径，例如：“如果生成代码运行报错，则进入调试环节；首先检查平台日志，其次验证输入数据格式……”
• 代码块与说明交错：在提示词中预设代码示例的插入位置，并配以简短的上下文说明，模拟真实的开发界面。

细节强化

• 强调边界条件：在提示词中主动加入对异常数据、网络超时、并发冲突等边界情况的处理要求。
• 融入平台特性：提及具体低代码平台的独有概念，如“数据模型”、“流程编排器”、“自定义逻辑块”等，使提示词更接地气。
• 输出质量标准：明确要求生成的代码需具备“可读性”、“可维护性”、“包含关键注释”以及“易于单元测试”。
• 调试辅助：建议在生成的代码中预留调试接口或标志位，例如添加详细的运行状态输出（console.log或日志记录）。

使用建议

• 将上述“核心提示词”作为模板，在实际使用时替换方括号[]内的具体业务对象、平台名称和功能描述。
• 在生成代码后，立即附加一段简短的“代码功能说明”与“自检清单”，这本身就是一种高质量的调试起点。
• 对于复杂流程，建议分模块多次生成与调试，再将代码整合，避免一次性提示过于复杂导致输出质量下降。
• 始终将“完整流程”的思维贯穿其中，确保每个提示词都服务于“可生成、可运行、易调试”的最终目标。