为什么代码有可视化编程,而提示词却没有?
摘要
文章提出使用可视化的节点和逻辑门将AI提示视为可执行逻辑,类似于可视化编程语言,并介绍了一个名为Prompt Logic Gates(PLG)的原型。
[Prompt Logic Gates (PLG) GitHub仓库](https://github.com/WithSJ/Prompt-Logic-Gates-PLG/tree/main?utm_source=chatgpt.com) 这是我最近一直在思考的问题。在软件开发中,我们花费了几十年的时间构建抽象层,以便让复杂的系统变得可控:* 函数取代重复代码 * 类与模块取代巨型文件 * 可视化系统,例如虚幻引擎蓝图(Unreal Blueprints)、Node-RED和LabVIEW。* 编译器在执行前验证并转换输入 然而,在AI提示词方面,许多人仍在编写大量的文本块。一个复杂的提示词很容易变得长达数百词,并承担多个职责:* 上下文 * 约束条件 * 风格指令 * 排除项 * 决策逻辑 * 后备行为 此时,它开始变得更像程序而非文本。这让我想到:为什么我们不把提示词当作可执行逻辑来对待呢?想象一下,使用逻辑门构建提示词:* AND → 合并指令 * OR → 在备选方案中选择 * NOT → 去除不想要的概念 * 问题节点 → 识别缺失的需求 * 编译器 → 在执行前检测矛盾 无需编辑庞大的字符串,你可以构建一个图并将其编译为最终的提示词。我一直在尝试一个名为**Prompt Logic Gates (PLG)**的原型。它将提示词当作可编译程序,使用依赖图、执行顺序、语义冲突检测、可视化节点和编译流水线等概念。例如虚幻引擎蓝图、Node-RED和LabVIEW。仓库:[Prompt Logic Gates (PLG) GitHub仓库](https://github.com/WithSJ/Prompt-Logic-Gates-PLG/tree/main?utm_source=chatgpt.com) 我发布这个并非作为产品发布或其他——我更感兴趣的是,从软件工程的角度来看,这个方向是否合理。你认为提示词最终会成为它们自己的编程层吗?还是自然语言永远是更好的抽象?好奇其他开发者的看法。
相似文章
🚀 提示逻辑门(PLG):提示正在成为系统吗?
提示逻辑门(PLG)是一个可视化提示工程实验,它使用语义逻辑门(AND、OR、NOT、提问)来组织提示,以管理类似系统的复杂提示,旨在提高可维护性和一致性。
智能体需要控制流,而非更多提示词
文章认为,可靠的 AI 智能体需要在软件中具备确定性的控制流和程序化验证机制,而不能仅仅依赖复杂的提示词链。
@mvanhorn: https://x.com/mvanhorn/status/2063865685558903149
本文解释了AI编程中'循环'的概念,即开发者编写程序来提示编码代理,而不是手动提示,这一概念由Peter Steinberger和Boris Cherny推广开来,并讨论了这种转变如何代表了AI辅助开发中的新抽象层。
@Av1dlive: Garry Tan (Y-Combinator CEO): “当有人问我如何‘提示’我的 AI 时,答案是:我不提示。技能即提示…"
Garry Tan 主张从手动 AI 提示转向基于技能的自动化,展示了 GBrain 和 GStack 等开源工具,用于永久捕获和复用工作流。
How to Write an AI Prompt
The article provides tips for writing effective AI prompts in Google AI Studio's Vibe Coding feature, emphasizing specificity, using keywords like Three.js, image references, and iterative refinement.