先交付一个垃圾产品出来｜就业机会仍然是透心凉

最近算是比较深度地使用了 Dify & Cursor 去解决业务中的实际问题，有点体会。

1. Dify

实际使用过程中， Dify 的实际上手成本并不低，尤其是代码节点，你是依赖 Python 去做字符处理的，新手容易有畏惧心理，另外要不停试跑看代码节点之前的输入和之后的输出是否符合期望。如果这个代码节点可以通过 Chat 去完成代码的生成，会对 Dify 新手更友好。

Dify 流程搭建后，调试成本并不低，尤其 Dify 流程未在实际业务环节中跑过，各种未知的输出可能有不可控的情况。这注定 Dify 流这种方式适合那种输入情况不多变的情况，且对业务可靠性不是强要求的情况下去尝试，非常适合去解决实际业务中非核心链路的情况，快速验证自己的想法。

一旦 Dify 流程搭建后，后续持续迭代维护也是比较头疼的，理解一个复杂的 Dify 流程基本跟看代码差不多了，有时候你不知道当初的设计者为什么在某些环节让节点并行，用 Dify 你就别指望大家有好的注释和变量说明了，你只有自己拿实际业务数据跑了才知道某些流程的奇技淫巧是为了解决一些不可控的边界情况。

我不知道 Dify 流程复杂度上来后，如何在工程层面解决维护性、稳定性问题，前期业务探索 & idea 探索完全没问题。

判断一个 Dify 流程有没有价值就是看它消耗的 Token，有持续稳定的消耗就是一个好应用。

在 Dify 工具的加持下，idea 验证就都得产品运营自己来做了，前端开发做 Dify API 集成，后端开发包业务 RPC 接口。这种情况下组织人员数量配比就得变，产品运营 VS 开发差不多得 3:1 或者更多而不是传统开发模式的的 1:3。

2. Cursor

之前也了解过有人用 Cursor 用来写小作文，但现在产品原型直接通过 Cursor 来生成。本人在不懂 React、Vite、npm 包依赖关系的情况成功在本地环境跑通了 React 代码的渲染。

估计很快，后续产品运营类岗位都会要求此类能力，尤其是中小企业，对人员能力的要求更加全面和精英化。从职能来讲，产品、运营、前端、后端、设计、测试这几个来讲，设计和测试这两类工种的需求会大范围缩减。

想来时代变化也快的，刚入行一些前辈画原型都是直接用 Excel，后续才过渡到 Axure，后来才是Sketch、Figma 这些原型工具。以后产品跟前端开发对接估计很有可能就直接交付到代码层。产品也不用逼逼叨叨跟前端扣 UI 交互细节，你自己改满意了再给前端。

数据处理分析这些杂货就更不在话下，自己写 Python 脚步处理吧，Cursor 可以帮你改得更快。

3. MCP

Claude 的 Model Context Protocol (MCP) 协议出了，简单体验了一下：

这东西如果跟各种生产力工具结合会有更大的想象空间，比如 Photoshop，你不懂色彩原理图层这些都没关系，直接 chat，一直 chat 到有结果为止。只要配合 MCP 协议，各种生产力的上手门槛会大幅降低。

详细介绍可以看到官方文档： https://modelcontextprotocol.io/introduction

4. 凉透了

不像 2010 年开始的移动互联网浪潮，那波技术浪潮是行业对人才渴求的井喷。这波浪潮对大部分打工人就是满满的寒意，让你裤衩都凉透的那种，AI 时代的人才画像是技能多元化、想法跳跃灵活、敢于勇敢尝试新鲜工具的人。

后 Covid 时代企业关注的是 Cash flow，AI 赋能只是优化财务指标的一个手段而已，人的创造力和灵性是被忽略了，但讽刺的是 AI 工具需要人的这些特征，进而发现更大的世界。