低代码工作流，可能比 AI 写代码更适合我

现在比较火的有 n8n、Dify、Coze。 它们本质上都在做一件事：可视化编程。 以 Dify 为例，通过交互式地创建节点、连接节点，你可以像搭积木一样，把一条完整的数据流“摆”出来。 最后的产出并不是一段代码，而是一个可以直接使用的完整工作流，比如： 会议纪要自动整理 内容生成 简单的自动化工具 这让我想起小时候学的 Visual Basic，或者现在的少儿编程： 功能都已经被封装好了，你更多是在写模块之间的逻辑。 那它和 AI 辅助编程（比如 Cursor）有什么区别？ 如果是我以前做类似的东西，流程大概是： 用 Cursor 搭一个项目框架 一点点往里填功能 最后做成一个包含多个组件的小项目 但说实话，对我这种非计算机科班的人来说，这类项目大多停留在“课程项目 / 玩具”的阶段。 想真正封装、部署、落地，会发现要补的东西非常多。 而 Dify 给我的一个明显感受是： 它从一开始就是“面向使用”的。 每个模块都有明确的输入和输出 可以直接对接飞书、Outlook、GitHub 等 API 你更多关注的是：数据从哪来 → 怎么处理 → 到哪去 （当然，接口这块我也还在学） 对我来说，最大的区别其实在「参与感」 这是我觉得 Dify 明显优于 Cursor 的地方。 用 Cursor 做项目时，我经常感觉自己更像一个产品经理： 拆需求 跟 AI 反复对齐 验证它写的代码对不对 项目一复杂，就会出现两个问题： 1️⃣ 冗余代码越来越多 AI 很容易“多写”，于是你不断让它删代码、重构代码，慢慢对整个代码库失去信任。 2️⃣ 人逐渐失去对项目的整体理解 有些逻辑你已经说不清是为什么存在的， 就像没人治理的数据一样，不被理解的代码，最后只会变成角落里的灰尘。 我在毕设里就踩过这个坑。 尝试让 AI 重构代码，结果越改越乱，最后只能放弃。 为什么我觉得工作流工具反而更“工程化”？ 因为它的封装 + 可视化，强迫你始终站在“全局”看问题： 整个流程是不是通顺的 数据是怎么流转的 哪一步出了问题，一眼就能看到 对我这种还在建立工程直觉的人来说，这种体验反而更重要。 它让我先理解什么是一个真正可用的生产流程，而不是被困在某一个技术细节里。 至少在现阶段，我觉得： 这种低代码工作流，对工程能力的提升，可能并不比 AI 辅助编程差，甚至更适合我。 #learninpublic #实习记录 #低代码 #工作流 #非科班程序员 #AI工具