Shino

suki🥰

我们的 Syncless 今天终于发布了！ Syncless 是一个 Agent，它的愿景是：不再让人成为传话筒。 不要 AI 写文 AI 读，不要让人成为 AI 的附庸 欢迎大家加入我们的社区~ discord.com/invite/PBRjrhH…

@yetone 🩷🩷🩷

Alma 神，吹爆😭😭😭 @yetone

thanks🥰

Dify 2.0.0 の目玉機能、"ナレッジパイプライン" の紹介記事。 ナレッジの中身を、ワークフローみたいな感じで、いろいろなツールやら LLM やらを組み合わせて自由に作れるようになる感じのやつ。 RAG 2.0： Dify の新しいナレッジパイプラインを探る blog.kurokobo.com/archives/5422

支持她追寻梦想 又回到一个人了😭 感谢@dify_ai 送的周边

回过神来，怎么天亮了？ 九点还要上班呢🤣

@a602693793 恭喜！

像在做梦😭

耶！

coze 开源化后，低代码 agentic workflow 或许被证伪了。目前在卷 agentic workflow 赛道的产品太多了，但这个时候 coze 开源化无疑是字节为它宣布倒计时了。 coze 给我的印象是： - 平台强绑定，即应用必须运行在平台之上，用户既享受了平台的模块化工具、无需配置自己的模型/工具 token，又无法高度自定义自己的工具； - 不具备 mass-production 能力，大多数应用仅可作为原型验证，真正生产环境上线恐怕会欠下一大笔技术债。 基于以上两点，在大多数用例中，agentic workflow 只是作为开发者的玩具出现，不具备生产环境可用性，这也是 coze 只停留在 to C 业务的主要原因。 从以上两点延伸，扩展到全部的低代码 workflow 品类，依然逃不过以下两点： - 不具备边缘 runtime 能力：如果你想要在边缘设备运行应用，脱离 SaaS，本地 host 一个平台的性能成本比较高，因此你不太可能在一台树莓派驱动的 IoT 设备上运行一个 agentic workflow。 - 不具备迁移置换性：你可以做到把数据库从 AL云迁移到 TX 云，但是不太可能把你的 workflow 从 cxxx 迁移到 dxxx。你的 workflow 本质上仍然是平台的资产而不是你的资产。 所以，当前 AI-based 应用设计流程应该如下： 使用 agentic workflow 进行原型设计 -> 原型上线测试 -> 研发把 agentic workflow 通过硬代码将其与平台解耦 -> 生产环境上线。 Agentic Workflow 的未来：我们期待什么样的变革？ Coze 等产品的困境，并非 Agentic Workflow 思想的失败，而是当前平台中心化实现路径的失败。要让这个赛道真正走向成熟，就需要： - 标准化的工作流定义语言：我们需要一个类似“AI 界的 Terraform 或 Dockerfile”的标准化声明式语言。开发者可以用它来定义 Agent 的行为、工具、知识库和协作方式。这个定义文件应该是平台无关的，可以像代码一样被版本控制，并且可以在任何兼容的运行时环境中执行。 - 可导出的、可读的“中间代码”：未来的低代码平台，其核心价值不应是“锁定”，而是“加速”。它应该允许用户在图形化界面完成设计后，一键导出为人类可读、可维护、可独立部署的高级语言代码（例如 Python）。平台完成的是从“想法”到“代码草稿”的翻译工作，而不是直接生成一个无法脱离平台运行的黑箱应用。 - 开放的、可插拔、可共享的生态系统：一个健康的生态，应该允许开发者自由地接入自己的模型、工具和数据库，而不是被限制在平台提供的有限选择中。平台负责提供工作流的编排和调度核心，而将具体能力的实现交还给开发者。

Dify 是一家 Tech Startups 公司，像我们这样的公司基石应是工程师友好文化（Hacker-friendly），这是今天我们能成为 GitHub 全球 Top 50 项目，并且实现盈利的首要因素（尽管其它因素也很重要，但这点更重要，例如“贵人相助”、“广结善缘”）。 Hacker-friendly 不是无差别的把工程师放在首位，而是指一种尊重、激励、并尽可能减少干扰工程师创造力和效率的工作环境： - 以技术为第一生产力：技术和产品的优先级高于流程和官僚。 - 尊重代码与创造者：写出好代码、解决复杂问题的人受尊重，不论资排辈或头衔。 - 管理层理解工程复杂性：懂得 deadline 不应强压在架构重构、技术债清理上。 - 异步沟通优先：鼓励使用文档、issue、PR review 等异步方式沟通。 “工程师不友好”的典型特征： - 产品拍脑袋定 deadline，不能推 - 拒绝技术债重构，说“用户看不到” - 技术难题不被认可，简化成 KPI 问责 例如，在我们的公司价值观中提到的五条：上手折腾，知识驱动，立足前沿，开放协同，坦诚清晰。尽管当时在我写下这些的时候是带有一些羞耻感的（我也不清楚为什么要为此而羞耻）。 价值观就是区分什么重要，什么不重要。在众多重要的事情中，还需要区分什么更重要。 Hacker-friendly 不是仅适用于工程师，而应适用于所有知识型工作者。它是一种价值取向：鼓励价值创造，拒绝积累债务。鼓励事实讨论，拒绝情绪煽动。鼓励追求第一性，拒绝短期利益诱惑。鼓励激发善意，拒绝 PUA。 Hacker-friendly 需要同理心，需要相信有序和深度的思考下才能做出卓越的产品，需要相信最终这会指向一门好生意——从而给全员带来令人兴奋的回报。 说到这些容易，做到不容易。为了维系 Hacker-friendly，创始人就必须有一种清醒的人才观。在必要时候需要做到牺牲，可能放弃对增长的追逐，可能丢失一轮到了手边的融资，可能要被误解、羞辱、谩骂，但必须义无反顾的做这些事情，因为这是 Tech Founders 们创立一家公司的最大理由：选择和聪明的人，以聪明的互相尊重的方式工作。

@goocarlos 太羡慕这种公司文化了。 在我司，对于工程师们对于上层而言，是实现功能的工具人。 如果你有想法提出来，你觉得哪部分已经乱透了，他只会觉得你的需求不够饱和，是不是太闲了？ 他从来不问底层是如何实现的，有什么技术难点，他想要实现的功能你就必须给他按时实现。 每天都在还之前快速交付的技术债。

现在的工作是把几坨💩聚合成一坨大💩 每坨💩里还有为了满足他们无理需求塞的兼容💩 明明是同一个东西，里面却有各种各样的特殊情况 明明作为后端，作为最终实现人员却没有任何话语权 又想做的好又想功能多，又不给时间又不给足钱 甚至公司网络/代理也时不时抽风 好累🤣 写狗屎需求写到怀疑人生😇

@alterxyz4 cool😍

- [x] 苏州 - [x] 上海 - [x] 香港 - [ ] 加州 (休息) - [x] 东京 ========== - [x] Earth - [ ] Moon - [ ] Mars ========== - [ ] Matrix - [ ] Multiverse - [ ] Imaginary Number Space ========== - [ ] etc.

感谢 @dify_ai \(^o^)/ 开心 #dify

❤️ Behind every great open source project are the people who make it happen. In our latest blog, we spotlight 18 core contributors who've shaped Dify through 2 years of development - from fixing critical bugs to building features like the Loop node and MCP plugins. Read about the contributors shaping Dify's future: dify.ai/blog/100k-star… #OpenSource #DeveloperSpotlight #Community