
获得徽章 0
低代码 AI 工作流开发平台越来越多了,有开源的 n8n, dify , 还有大厂的 字节Coze, 蚂蚁百宝箱。
"低代码 AI 工作流开发平台" 这个领域的用户很多吗?
"低代码 AI 工作流开发平台" 这个领域的用户很多吗?
3
1
信息或知识有的像食物,有的像原料。
AI 可以将原料烹饪成食物,也可以将食物制作成更好吃,更易于消化的食物。
而“消化食物”,“吸收营养”只能自己来做,不需要也不愿意交给 AI
AI 可以将原料烹饪成食物,也可以将食物制作成更好吃,更易于消化的食物。
而“消化食物”,“吸收营养”只能自己来做,不需要也不愿意交给 AI
展开
评论
点赞
在与大模型协作进行 AI 编程时,有 3 点要注意:
1. AI 仍有局限,可能会钻牛角尖或查不到信息,这时你需要主动协助,查资料解决问题。
2. 有时不是 AI 不行,是你不行。掌握一定的行业知识和基础知识,是高效使用大模型的前提。
3. 有时不是 AI 不行,是你一开始表达不够清晰,很多问题需要在反复对话和实践中逐步梳理明确。
1. AI 仍有局限,可能会钻牛角尖或查不到信息,这时你需要主动协助,查资料解决问题。
2. 有时不是 AI 不行,是你不行。掌握一定的行业知识和基础知识,是高效使用大模型的前提。
3. 有时不是 AI 不行,是你一开始表达不够清晰,很多问题需要在反复对话和实践中逐步梳理明确。
展开
评论
点赞
能力 = 能量 × 效率
使用能量越多,使用能量的效率越高,获得的能力越大。
电是能量,用电量越大,用电效率越高的设备,能力越大。
计算是能量,需要CPU/显卡越多,对 CPU/显卡使用效率越高的软件,能力越大。
对于 AI 来说, token 也是能量,使用 token 越多,使用 token 效率越高的智能体,能力越大。
使用能量越多,使用能量的效率越高,获得的能力越大。
电是能量,用电量越大,用电效率越高的设备,能力越大。
计算是能量,需要CPU/显卡越多,对 CPU/显卡使用效率越高的软件,能力越大。
对于 AI 来说, token 也是能量,使用 token 越多,使用 token 效率越高的智能体,能力越大。
展开
2
点赞
我感觉豆包能满足我的日常生活中的大部分 ai 使用场景了,不需要特别高级的大模型。
豆包好像从一开始就是一个 “AI 智能体”,不是一个“大模型客户端”。
大模型客户端会把大模型放在第一位,用户是在和大模型对话。
AI 智能体中,第一位就是智能体本身,用户使用的是智能体,不是智能体背后的大模型。
面向专业用户的智能体会暴露大模型供用户选择,比如 cursor.
面向普通用户的智能体,的确没必要暴露大模型,对用户来说,知道智能体就够了,不需要知道大模型。
豆包好像从一开始就是一个 “AI 智能体”,不是一个“大模型客户端”。
大模型客户端会把大模型放在第一位,用户是在和大模型对话。
AI 智能体中,第一位就是智能体本身,用户使用的是智能体,不是智能体背后的大模型。
面向专业用户的智能体会暴露大模型供用户选择,比如 cursor.
面向普通用户的智能体,的确没必要暴露大模型,对用户来说,知道智能体就够了,不需要知道大模型。
展开
评论
点赞
#ai改变日常工作
需求:检查项目中的所有文件,哪些文件中包含中文注释
文件不多时,通常做法是人肉查找,也没觉得多费劲,但是毕竟浪费时间,而且不可持续。
自己写一个脚本,对于写脚本熟练的开发者,需要几分钟时间,但是如果不熟练,需要更长时间,而且会消耗脑力。
有了 AI 后,直接让 AI 实现,不到 1 分钟搞定。
需求:检查项目中的所有文件,哪些文件中包含中文注释
文件不多时,通常做法是人肉查找,也没觉得多费劲,但是毕竟浪费时间,而且不可持续。
自己写一个脚本,对于写脚本熟练的开发者,需要几分钟时间,但是如果不熟练,需要更长时间,而且会消耗脑力。
有了 AI 后,直接让 AI 实现,不到 1 分钟搞定。
展开
评论
点赞
AI 搜索出现后,使用 AI 搜索越来越多,使用 Google 搜索越来越少。最近使用 Google 搜索,发现 AI 回答改进了许多。很多场景(比如简单的问题)又可以回到 Google 搜索了。
评论
点赞
RAG 的基本流程
1 创建向量数据库(知识库):输入文本 - 使用 embedding 模型将文本转化成向量 - 存入向量数据库
2 提问:用户和 ai 说话提问
3 检索:将提问文本使用 embedding 模型转化成提问向量,并在数据库中检索,返回相关的文本段
4 拼接 prompt: 将提问文本和检索到的文本段拼接成最终 prompt 文本
5 调用大模型:使用 prompt 调用大模型,返回最终回答
1 创建向量数据库(知识库):输入文本 - 使用 embedding 模型将文本转化成向量 - 存入向量数据库
2 提问:用户和 ai 说话提问
3 检索:将提问文本使用 embedding 模型转化成提问向量,并在数据库中检索,返回相关的文本段
4 拼接 prompt: 将提问文本和检索到的文本段拼接成最终 prompt 文本
5 调用大模型:使用 prompt 调用大模型,返回最终回答
展开
2
2
通过 Web HTTP 来理解 MCP:
HTTP 之前,互联网APP 开发成本很高。
HTTP 出现后,有了统一协议,互联网APP 开发成本变低了。
随后,出现了 Web 浏览器,客户端和服务端实现了分离,APP 只需要开发“服务端“。
再后来,随着基础设施的不断完善,有些 APP 离开了浏览器,也做了自己的客户端。
MCP 出现之前,AI 应用开发成本很高。
MCP 出现后,有了统一协议,AI 应用开发成本变低了。
现有的各个 APP 会可能会支持 MCP, 变成 MCP 服务。
现在的各种 AI Chat 应用可能会进化成 AI 浏览器,用户通过 AI 浏览器访问这些 MCP 服务。
MCP 服务不仅在互联网,也可以在本地( 比如本地的 Blender 支持 MCP 后,可以被 Claude Desktop 使用 )。
如果未来使用大模型的成本变得很低(操作系统内置本地大模型,或是服务商独立部署自己的大模型),那么 APP 也可以不依赖 AI 浏览器,自己做AI 客户端。
HTTP 之前,互联网APP 开发成本很高。
HTTP 出现后,有了统一协议,互联网APP 开发成本变低了。
随后,出现了 Web 浏览器,客户端和服务端实现了分离,APP 只需要开发“服务端“。
再后来,随着基础设施的不断完善,有些 APP 离开了浏览器,也做了自己的客户端。
MCP 出现之前,AI 应用开发成本很高。
MCP 出现后,有了统一协议,AI 应用开发成本变低了。
现有的各个 APP 会可能会支持 MCP, 变成 MCP 服务。
现在的各种 AI Chat 应用可能会进化成 AI 浏览器,用户通过 AI 浏览器访问这些 MCP 服务。
MCP 服务不仅在互联网,也可以在本地( 比如本地的 Blender 支持 MCP 后,可以被 Claude Desktop 使用 )。
如果未来使用大模型的成本变得很低(操作系统内置本地大模型,或是服务商独立部署自己的大模型),那么 APP 也可以不依赖 AI 浏览器,自己做AI 客户端。
展开
评论
点赞
vercel, cloudflare, supabase, blocklet, 这些是更上层的云基础设置 (相对于 ec2, s3, lambda ),进一步简化开发者的开发和运维成本
评论
点赞