即刻App年轻人的同好社区
下载
置顶Hi~你好！我是 Xinran，欢迎来到我的个人说明书～ 这里是 Tongji 和 Cornell校友一枚，目前常驻上海。本人属性：“热爱折腾” ٩(ˊᗜˋ )œ 。对未知的天生好奇和对新挑战的跃跃欲试，就是我生活的驱动力。
秉承着这股劲，architectue毕业之后我先去了全球顶级建筑公司的旧金山办公室“搬砖”。身处硅谷，浓厚的科技氛围和创新浪潮，让我开始认真思考设计与技术的更多可能性。于是，在当地同学和校友的启发下，我开始转向Product Design和HCI领域，期待有朝一日能用技术改变设计、甚至是创造的范式。
回到上海办公室后，继续负责了几个有分量和社会意义的城市设计项目（张江科学之门 & 城隍庙老城厢城市更新的主创设计就是我٩(•̤̀ᵕ•̤́๑)ᵒᵏᵎᵎᵎᵎ）。后来一次与director的对谈中，他所坚信的“以后人工智能就算来了，也不会改变建筑设计的方法，大家还是会用老办法来做设计”促使了我最终的转型。乘着国内B端产品“火热的”东风，我顺势“跑路”去当了B端产品设计师👩🎨
时间快进到22年底，那时 ChatGPT还没有出圈，B端AI产品怎么玩就更加扑朔迷离，但这种“广阔天地大有可为”的情景早就吸引了我的关注。随后一个机会出现-—-和硅谷的朋友远程组队，帮一个当地某大厂出来的 AI新秀团队，从0到1搭建产品逻辑和交互框架。就这样我一头扎进了AI产品设计和交互的世界。👀 BTW，这个团队后来还登上了Wing的Enterprise Tech 30 List，也算是一份迟来的惊喜。
此后，为了更深入地理解和实践AI产品的打造，我开启了AI产品经理+设计+前端开发（偶尔客串）的“全栈”打怪升级模式，带了个独立小分队，主攻帮研究机构和初创团队从0到1落地有价值的AI/SaaS产品。
🥳🥳🥳从 24 年底开始，“爱折腾”的故事有了新篇章：我开始了创业项目！从运营独立Studio 到创业，是一个很大的转变，创业小学生正边打怪边升级 ing。 正在做的事：
1. 用心建设研究者社区。
作为半个HCI研究者（研究辅助实践居多），我发起了非营利研究者社区Research AI+，这里已经汇集了一群来自 Global 的AI 4 Science/Engineering 的青年研究者们。我们在尝试帮助 Researcher 们打破地域和学科壁垒、希望能够碰撞出Industry 和 Academia 的合作火花。最近我们正和长三角的其他机构/社区密集联动搞分享和交流活动（比如沙龙或者读论文这种 Researcher 专属活动），欢迎感兴趣的小伙伴戳我～
2. 孵化 Researcher for Researcher的产品。
社区里还有一票超有创造力的独立开发者小伙伴，热衷于开发AI for Researcher 的产品（感谢 Vibe Coding 赋能超级个体(๑˃̵ᴗ˂̵)让设计师和算法后端同学也有机会launch 产品）。目前正在孵化专属于NextGen Researcher 的职业社交产品，欢迎大家关注我们！
🔑🔑🔑除了跟小伙伴建设社区、开发产品，个人日常也一直“在折腾”，保持“在路上”的感觉：
📚撰写Heuristics for AI Product Design（AI 产品的启发式设计方法）专栏：
即刻中文版地址： m.okjike.com
📬跟前鹅厂算法@Liz_Li 一起做了一个 free 的Substack newsletter，包含Heuristics for AI Product Design 专栏全部内容，还包含 Liz 主笔的一些硬核的技术文章。open.substack.com
📻正在筹划制作一款面向Researcher 的播客，欢迎各位即友来分享研究方向和研究趣事～
👩💻正在构建 Figma+V0+Cursor 的设计前端一条龙 workflow（根据Figma 的更新，也许以后就是 Figma Make+Cursor+Vercel/Replit）
📌沉淀基于 Nextjs+tailwindcss+shadcn 的 SaaS 产品组件库，让之前的咨询服务能持续发挥价值，帮助中小团队快速 launch 产品。
🧬研究 workflow 与 agent 的产品结合点，目前在玩 n8n
💡💡💡专业之外的隐藏身份
一个不热爱生活的设计师，不会是一个好的产品人，因此我：
🌿是一位户外爱好者但人菜瘾大，速徒、桨板、溯溪、露营还请叫着我～
☕️吃货本货，爱吃也爱做，热爱全球美食和咖啡探店，对自己的手冲咖啡水平有些小自信😎；
🌆建筑的老本行变成了纯爱好，日常溜达 City Walk/Bike/Hike 探索城市秘境；
🪄业余热爱创作文字，已写过武侠/科幻小说超过 25w字；
🐱兼职铲屎官，家有恶猫又皮又黏人；
🫴打了很多年咏春拳总算要学到木人桩了！
多元的身份让我的生活永远不止一个“锚点”，也是我多年专业上持续“折腾”探索的心灵保障和精神源泉😜😜欢迎各位同好们(⁎⁍̴̛ᴗ⁍̴̛⁎)各种约约约！
附图是大学时候去丽水写生的画作，许愿有一天能恢复画画的功力 finger cross～
秉承着这股劲，architectue毕业之后我先去了全球顶级建筑公司的旧金山办公室“搬砖”。身处硅谷，浓厚的科技氛围和创新浪潮，让我开始认真思考设计与技术的更多可能性。于是，在当地同学和校友的启发下，我开始转向Product Design和HCI领域，期待有朝一日能用技术改变设计、甚至是创造的范式。
回到上海办公室后，继续负责了几个有分量和社会意义的城市设计项目（张江科学之门 & 城隍庙老城厢城市更新的主创设计就是我٩(•̤̀ᵕ•̤́๑)ᵒᵏᵎᵎᵎᵎ）。后来一次与director的对谈中，他所坚信的“以后人工智能就算来了，也不会改变建筑设计的方法，大家还是会用老办法来做设计”促使了我最终的转型。乘着国内B端产品“火热的”东风，我顺势“跑路”去当了B端产品设计师👩🎨
时间快进到22年底，那时 ChatGPT还没有出圈，B端AI产品怎么玩就更加扑朔迷离，但这种“广阔天地大有可为”的情景早就吸引了我的关注。随后一个机会出现-—-和硅谷的朋友远程组队，帮一个当地某大厂出来的 AI新秀团队，从0到1搭建产品逻辑和交互框架。就这样我一头扎进了AI产品设计和交互的世界。👀 BTW，这个团队后来还登上了Wing的Enterprise Tech 30 List，也算是一份迟来的惊喜。
此后，为了更深入地理解和实践AI产品的打造，我开启了AI产品经理+设计+前端开发（偶尔客串）的“全栈”打怪升级模式，带了个独立小分队，主攻帮研究机构和初创团队从0到1落地有价值的AI/SaaS产品。
🥳🥳🥳从 24 年底开始，“爱折腾”的故事有了新篇章：我开始了创业项目！从运营独立Studio 到创业，是一个很大的转变，创业小学生正边打怪边升级 ing。 正在做的事：
1. 用心建设研究者社区。
作为半个HCI研究者（研究辅助实践居多），我发起了非营利研究者社区Research AI+，这里已经汇集了一群来自 Global 的AI 4 Science/Engineering 的青年研究者们。我们在尝试帮助 Researcher 们打破地域和学科壁垒、希望能够碰撞出Industry 和 Academia 的合作火花。最近我们正和长三角的其他机构/社区密集联动搞分享和交流活动（比如沙龙或者读论文这种 Researcher 专属活动），欢迎感兴趣的小伙伴戳我～
2. 孵化 Researcher for Researcher的产品。
社区里还有一票超有创造力的独立开发者小伙伴，热衷于开发AI for Researcher 的产品（感谢 Vibe Coding 赋能超级个体(๑˃̵ᴗ˂̵)让设计师和算法后端同学也有机会launch 产品）。目前正在孵化专属于NextGen Researcher 的职业社交产品，欢迎大家关注我们！
🔑🔑🔑除了跟小伙伴建设社区、开发产品，个人日常也一直“在折腾”，保持“在路上”的感觉：
📚撰写Heuristics for AI Product Design（AI 产品的启发式设计方法）专栏：
即刻中文版地址： m.okjike.com
📬跟前鹅厂算法@Liz_Li 一起做了一个 free 的Substack newsletter，包含Heuristics for AI Product Design 专栏全部内容，还包含 Liz 主笔的一些硬核的技术文章。open.substack.com
📻正在筹划制作一款面向Researcher 的播客，欢迎各位即友来分享研究方向和研究趣事～
👩💻正在构建 Figma+V0+Cursor 的设计前端一条龙 workflow（根据Figma 的更新，也许以后就是 Figma Make+Cursor+Vercel/Replit）
📌沉淀基于 Nextjs+tailwindcss+shadcn 的 SaaS 产品组件库，让之前的咨询服务能持续发挥价值，帮助中小团队快速 launch 产品。
🧬研究 workflow 与 agent 的产品结合点，目前在玩 n8n
💡💡💡专业之外的隐藏身份
一个不热爱生活的设计师，不会是一个好的产品人，因此我：
🌿是一位户外爱好者但人菜瘾大，速徒、桨板、溯溪、露营还请叫着我～
☕️吃货本货，爱吃也爱做，热爱全球美食和咖啡探店，对自己的手冲咖啡水平有些小自信😎；
🌆建筑的老本行变成了纯爱好，日常溜达 City Walk/Bike/Hike 探索城市秘境；
🪄业余热爱创作文字，已写过武侠/科幻小说超过 25w字；
🐱兼职铲屎官，家有恶猫又皮又黏人；
🫴打了很多年咏春拳总算要学到木人桩了！
多元的身份让我的生活永远不止一个“锚点”，也是我多年专业上持续“折腾”探索的心灵保障和精神源泉😜😜欢迎各位同好们(⁎⁍̴̛ᴗ⁍̴̛⁎)各种约约约！
附图是大学时候去丽水写生的画作，许愿有一天能恢复画画的功力 finger cross～
36 194
用 Linear 做项目管理的小伙伴，如果还有人没试过它的 MCP功能，赶快去试一下！！(｢･ω･)｢视频会议--文字转录--直接 MCP 设issue 同时设定优先级，circle，负责人和标签…幸福指数飙升！
7 00
如果是有设计师，想要尽量还原设计稿，肯定是 Figma make， 但是代码生成比较慢，对设计稿的规范程度有一定要求（auto layout 一定要够好），动效听说也能做，但我没试过。v0 的话，推荐跟 shadcn 这个组件库（效果最好，vercel 全家桶原生）一起用，或者用某些知名组件库，比如 magic ui（现在都有 open in v0 功能），可以直接 call 某个库的某个组件。 //@吴豪Neo: Hey 所以你现在的最佳实践是谁呢？v0 or figma make; （要考滤动效
Xinran.Z: 今天对比了一下 同一个设计稿， Figma make 和Figma mcp （cursor 里）的产出效果，make 完胜，还原度极高。是Figma 故意留了一手，不把 mcp 功效发挥出来，还是 cursor 过于灵活了？🤔不得不说，Figma 里面的设计相关context 太多了，迁移到任何 IDE 都不如它自己直接转 code 来的效果好
5 00
感谢小🍠邀请 Research AI+社区来Founder Park 的 AGI 大会现场玩耍🥳🥳🥳这周末两天都会在北京 798 附近，期待跟各位小伙伴面基👻🎃👀🤪😎🤩🥳
9 30
你这篇文章说的就是我ಥ_ಥ，简直一毛一样，看泪目了。大厂不是唯一的解，生活和设计一样，不应该被设限，加油(ง•̀_•́)ง 祝你能做自己热爱的事情，掌控自己的人生，按自己的想法去生活！各位首页大佬们欢迎康康我们tongji 设计毕业的校友～
菠萝的胃: 似乎是个很好的时机回顾过去一年以来找工作的这段经历。 毕业进大厂好像成了下一件你不知道为什么但是好像就是必须要做的事情。你已经十年寒窗苦读进了一所看起来不错学校读本科，以不错的成绩毕业又进了一所似乎更棒一点的学校读研究生，于是你理所应当要接着走那条已经被无数人验证过的看起来安全舒适光鲜亮丽的道路继续走下去。 你不知道这个世界上还有什么别的选择。 从24年春天开始找暑期实习开始，你终于认真写了人生中的第一份简历。一张薄薄的A4纸上密密麻麻的挤满了你东拼西凑出来的可以被视作「有用」的东西。可是你知道这张纸无法说明哪怕1%的真实的你。 大部分的面试都很糟糕，你也讲不清楚究竟是为什么。可能是你并不buy in 那套学来的可以让你通过面试的套话和法则，也或者你真的思考不够复盘不够逻辑不通没有产品sense就像他们告诉你的那样。 但你还是很幸运地遇到了赏识你的老师，得到了很好的机会进了大厂实习。在那里你认识的都是特别棒的朋友和老师，你从他们身上学到好多，受到很多帮助。可不知为什么你就是感到自己像是棵硬拧成了螺丝钉形状的野草，在钢筋混凝土的密闭大楼里日益枯萎。 你躺在逼仄的出租屋床上呆呆的望着天花板逼问自己这一切究竟有什么意义。 这痛苦的一切最终以千辛万苦拿到那一纸offer收尾。而你只是松了一口气，甚至不知道自己应该是开心这一切终于结束了，还是为自己拿到新一轮痛苦生活的门票而感到难过。 开始做NoFeed之后，你才终于感到自己一点点活了过来。 漫天的思绪终于像云一样重新飘回了你的脑袋上空。 如果可能的话，继续做野草吧，继续在大雨中被冲刷，继续在烈日下被暴晒。
3 10
👀之前陆续写的 HCI 话题合集：m.okjike.com
Xinran.Z: Heuristics for AI Product Design 之 【Multi-agent 协作的HCI视角思考】-1 构建一个高效、可靠的multi-agent系统，远比想象中要困难得多。自古人类的协作就有"三个和尚没水喝"的"美谈"，agent 之间的协作也有类似的问题。 这两天来自 Cognition（Devin）和 Anthropic（Claude）两家AI 公司就"是否/如何构建多智能体"发表了看似"针锋相对"观点的两篇文章，非常有意思，在这里尝试做一个 HCI 视角的解读。 附图有原文标题，大家感兴趣的可以搜一下看看。 ------以下是正文---- 「Part 1 多智能体协作的难点与问题」 一、复合错误与不可靠的输出： 1. 上下文的丢失与误解 Cognition 认为多智能体（multi-agent）架构天生"脆弱"。当一个复杂任务被拆解后，每个子智能体拿到的只是任务碎片。如果它们无法共享完整的context，比如初始目标和决策过程，误解便会产生。即使复制原始任务作为context，在多轮对话的生产系统中，细节的微妙之处仍可能导致任务解读偏差。 1. 决策的冲突 Cognition 认为更糟糕的是，不同子智能体可能基于各自的（错误）理解做出相互冲突的决策。这种不一致性直接体现在最终呈现给用户的产品或信息中，严重损害了用户对系统生成结果的信任和满意度。 2. 失控的沟通与资源浪费 Anthropic 在早期研发中也遇到了类似的窘境。多个智能体的团队可能会陷入混乱的"内卷"：智能体之间为了同步信息，可能进行大量不必要的"对话"，甚至陷入死循环。一个任务可能被过度分解，催生出大量冗余的子智能体，它们互相干扰，反复执行同样的工作。这些失控行为不仅疯狂消耗着token，更让用户在漫长的等待后，得到一个毫无意义的结果，甚至系统直接崩溃。 二、AI 协作与人类直觉之间差距巨大： 1. AI 内部协作的现实 人类工程师可以通过高效的沟通解决冲突，但目前的 AI 还做不到。Cognition 认为，AI 之间还无法进行"比单个智能体可靠性高得多的long context交流"。我们人类凭直觉认为 AI 团队应该像人类一样默契配合，但现实是，它们缺乏那种提炼关键信息、达成共识的"非凡智能"。这种期望与现实的巨大落差，是用户感到挫败的根本原因。 2. prompt engineering 的挑战 Anthropic 指出，由于多代理系统不遵循固定路径且具有"涌现行为"，传统的评估方法难以适用。人类需要深入理解AI的mental model才能有效地指导它们，通过prompt engineering来校准代理的行为。然而，如果提示不够细致，代理可能"误解任务"或"重复工作"，导致效率低下和结果不佳。 三、效率和成本的权衡： 1. 高资源消耗 Anthropic 明确指出，多代理系统虽然能够扩展性能，但其缺点是"实践中会迅速消耗token"。agent 模式通常比聊天交互使用多4倍的token，而multi-agent系统更是聊天交互的15倍。这使得multi-agent系统在经济上需要任务本身具有足够高的价值才能支撑其高昂的运行成本。 2. 同步执行的瓶颈 Anthropic 当前的multi-agent系统采用"同步执行"，即主代理等待每个子代理完成任务后再进行下一步。这种模式虽然简化了协调，但会在信息流中造成瓶颈，导致系统无法并行工作，限制了用户的体验速度。 四、可靠性与工程方面的挑战： 1. 错误也会传递 Anthropic指出agent系统的错误会积累。这意味着即使是微小的系统故障也可能对代理造成灾难性影响，并且错误会沿着执行路径传播，导致不可预测的结果。对于用户而言，这意味着任务可能中断，无法从中断处恢复，或者最终结果完全偏离预期。 2. 调试与部署的挑战 Anthropic还指出，agent的非确定性行为使得调试变得困难，因为即使输入相同，代理也可能采取不同的路径。部署更新也充满挑战，因为需要确保运行中的代理不受中断。这些工程上的复杂性间接影响了用户，可能导致修复周期长、系统不稳定。 「Part 2 解决方案（未完待续）」
1 00
Heuristics for AI Product Design 之
【Multi-agent 协作的HCI视角思考】-1
构建一个高效、可靠的multi-agent系统，远比想象中要困难得多。自古人类的协作就有"三个和尚没水喝"的"美谈"，agent 之间的协作也有类似的问题。
这两天来自 Cognition（Devin）和 Anthropic（Claude）两家AI 公司就"是否/如何构建多智能体"发表了看似"针锋相对"观点的两篇文章，非常有意思，在这里尝试做一个 HCI 视角的解读。
附图有原文标题，大家感兴趣的可以搜一下看看。
------以下是正文----
「Part 1 多智能体协作的难点与问题」
一、复合错误与不可靠的输出：
1. 上下文的丢失与误解
Cognition 认为多智能体（multi-agent）架构天生"脆弱"。当一个复杂任务被拆解后，每个子智能体拿到的只是任务碎片。如果它们无法共享完整的context，比如初始目标和决策过程，误解便会产生。即使复制原始任务作为context，在多轮对话的生产系统中，细节的微妙之处仍可能导致任务解读偏差。
1. 决策的冲突
Cognition 认为更糟糕的是，不同子智能体可能基于各自的（错误）理解做出相互冲突的决策。这种不一致性直接体现在最终呈现给用户的产品或信息中，严重损害了用户对系统生成结果的信任和满意度。
2. 失控的沟通与资源浪费
Anthropic 在早期研发中也遇到了类似的窘境。多个智能体的团队可能会陷入混乱的"内卷"：智能体之间为了同步信息，可能进行大量不必要的"对话"，甚至陷入死循环。一个任务可能被过度分解，催生出大量冗余的子智能体，它们互相干扰，反复执行同样的工作。这些失控行为不仅疯狂消耗着token，更让用户在漫长的等待后，得到一个毫无意义的结果，甚至系统直接崩溃。
二、AI 协作与人类直觉之间差距巨大：
1. AI 内部协作的现实
人类工程师可以通过高效的沟通解决冲突，但目前的 AI 还做不到。Cognition 认为，AI 之间还无法进行"比单个智能体可靠性高得多的long context交流"。我们人类凭直觉认为 AI 团队应该像人类一样默契配合，但现实是，它们缺乏那种提炼关键信息、达成共识的"非凡智能"。这种期望与现实的巨大落差，是用户感到挫败的根本原因。
2. prompt engineering 的挑战
Anthropic 指出，由于多代理系统不遵循固定路径且具有"涌现行为"，传统的评估方法难以适用。人类需要深入理解AI的mental model才能有效地指导它们，通过prompt engineering来校准代理的行为。然而，如果提示不够细致，代理可能"误解任务"或"重复工作"，导致效率低下和结果不佳。
三、效率和成本的权衡：
1. 高资源消耗
Anthropic 明确指出，多代理系统虽然能够扩展性能，但其缺点是"实践中会迅速消耗token"。agent 模式通常比聊天交互使用多4倍的token，而multi-agent系统更是聊天交互的15倍。这使得multi-agent系统在经济上需要任务本身具有足够高的价值才能支撑其高昂的运行成本。
2. 同步执行的瓶颈
Anthropic 当前的multi-agent系统采用"同步执行"，即主代理等待每个子代理完成任务后再进行下一步。这种模式虽然简化了协调，但会在信息流中造成瓶颈，导致系统无法并行工作，限制了用户的体验速度。
四、可靠性与工程方面的挑战：
1. 错误也会传递
Anthropic指出agent系统的错误会积累。这意味着即使是微小的系统故障也可能对代理造成灾难性影响，并且错误会沿着执行路径传播，导致不可预测的结果。对于用户而言，这意味着任务可能中断，无法从中断处恢复，或者最终结果完全偏离预期。
2. 调试与部署的挑战
Anthropic还指出，agent的非确定性行为使得调试变得困难，因为即使输入相同，代理也可能采取不同的路径。部署更新也充满挑战，因为需要确保运行中的代理不受中断。这些工程上的复杂性间接影响了用户，可能导致修复周期长、系统不稳定。
「Part 2 解决方案（未完待续）」
【Multi-agent 协作的HCI视角思考】-1
构建一个高效、可靠的multi-agent系统，远比想象中要困难得多。自古人类的协作就有"三个和尚没水喝"的"美谈"，agent 之间的协作也有类似的问题。
这两天来自 Cognition（Devin）和 Anthropic（Claude）两家AI 公司就"是否/如何构建多智能体"发表了看似"针锋相对"观点的两篇文章，非常有意思，在这里尝试做一个 HCI 视角的解读。
附图有原文标题，大家感兴趣的可以搜一下看看。
------以下是正文----
「Part 1 多智能体协作的难点与问题」
一、复合错误与不可靠的输出：
1. 上下文的丢失与误解
Cognition 认为多智能体（multi-agent）架构天生"脆弱"。当一个复杂任务被拆解后，每个子智能体拿到的只是任务碎片。如果它们无法共享完整的context，比如初始目标和决策过程，误解便会产生。即使复制原始任务作为context，在多轮对话的生产系统中，细节的微妙之处仍可能导致任务解读偏差。
1. 决策的冲突
Cognition 认为更糟糕的是，不同子智能体可能基于各自的（错误）理解做出相互冲突的决策。这种不一致性直接体现在最终呈现给用户的产品或信息中，严重损害了用户对系统生成结果的信任和满意度。
2. 失控的沟通与资源浪费
Anthropic 在早期研发中也遇到了类似的窘境。多个智能体的团队可能会陷入混乱的"内卷"：智能体之间为了同步信息，可能进行大量不必要的"对话"，甚至陷入死循环。一个任务可能被过度分解，催生出大量冗余的子智能体，它们互相干扰，反复执行同样的工作。这些失控行为不仅疯狂消耗着token，更让用户在漫长的等待后，得到一个毫无意义的结果，甚至系统直接崩溃。
二、AI 协作与人类直觉之间差距巨大：
1. AI 内部协作的现实
人类工程师可以通过高效的沟通解决冲突，但目前的 AI 还做不到。Cognition 认为，AI 之间还无法进行"比单个智能体可靠性高得多的long context交流"。我们人类凭直觉认为 AI 团队应该像人类一样默契配合，但现实是，它们缺乏那种提炼关键信息、达成共识的"非凡智能"。这种期望与现实的巨大落差，是用户感到挫败的根本原因。
2. prompt engineering 的挑战
Anthropic 指出，由于多代理系统不遵循固定路径且具有"涌现行为"，传统的评估方法难以适用。人类需要深入理解AI的mental model才能有效地指导它们，通过prompt engineering来校准代理的行为。然而，如果提示不够细致，代理可能"误解任务"或"重复工作"，导致效率低下和结果不佳。
三、效率和成本的权衡：
1. 高资源消耗
Anthropic 明确指出，多代理系统虽然能够扩展性能，但其缺点是"实践中会迅速消耗token"。agent 模式通常比聊天交互使用多4倍的token，而multi-agent系统更是聊天交互的15倍。这使得multi-agent系统在经济上需要任务本身具有足够高的价值才能支撑其高昂的运行成本。
2. 同步执行的瓶颈
Anthropic 当前的multi-agent系统采用"同步执行"，即主代理等待每个子代理完成任务后再进行下一步。这种模式虽然简化了协调，但会在信息流中造成瓶颈，导致系统无法并行工作，限制了用户的体验速度。
四、可靠性与工程方面的挑战：
1. 错误也会传递
Anthropic指出agent系统的错误会积累。这意味着即使是微小的系统故障也可能对代理造成灾难性影响，并且错误会沿着执行路径传播，导致不可预测的结果。对于用户而言，这意味着任务可能中断，无法从中断处恢复，或者最终结果完全偏离预期。
2. 调试与部署的挑战
Anthropic还指出，agent的非确定性行为使得调试变得困难，因为即使输入相同，代理也可能采取不同的路径。部署更新也充满挑战，因为需要确保运行中的代理不受中断。这些工程上的复杂性间接影响了用户，可能导致修复周期长、系统不稳定。
「Part 2 解决方案（未完待续）」
10 12
今天对比了一下 同一个设计稿， Figma make 和Figma mcp （cursor 里）的产出效果，make 完胜，还原度极高。是Figma 故意留了一手，不把 mcp 功效发挥出来，还是 cursor 过于灵活了？🤔不得不说，Figma 里面的设计相关context 太多了，迁移到任何 IDE 都不如它自己直接转 code 来的效果好
Xinran.Z: Figma 官方 Dev mode MCP 来了！！！之前试过最新推出的Figma Make，只要设计稿（尤其是 auto layout ）做得规范，转前端代码还原度还是非常高的。不知道这次推出官方 MCP 来配合 AI IDE 们效果如何，迫不及待要回家试验一下了！利好各位懂产品的designer和懂设计的pm 们😎
0 31
Figma 官方 Dev mode MCP 来了！！！之前试过最新推出的Figma Make，只要设计稿（尤其是 auto layout ）做得规范，转前端代码还原度还是非常高的。不知道这次推出官方 MCP 来配合 AI IDE 们效果如何，迫不及待要回家试验一下了！利好各位懂产品的designer和懂设计的pm 们😎
6 04
