即刻App年轻人的同好社区
下载
App内打开
歪歪了
239关注11被关注0夸夸
程序猿🌚
歪歪了
24天前
mark

西里森森: 今天来跟大家分享一下我是如何用Pixso做UI设计的，从零上手到最后输出前端代码的完整流程。 分以下三部分给大家介绍：为什么我从Figma切换到了Pixso，如何快速生成UI设计稿，以及怎么把效率拉满。 Pixso这个工具其实是我一个设计师朋友前段时间推我的，我体验下来觉得这个工具完全可以作为Figma国产平替。 它基本上把Figma的核心功能都覆盖了，而且个人版完全免费，功能使用不受限制，对于个人设计师或者小团队来说性价比真的很香。 更重要的是，Pixso今年上线了AI生成设计稿的功能，还有最近刚推出的MCP协议支持，可以直接把设计稿转成代码。 下面进入正题，说说具体怎么操作👇 第一步：用AI生成初始设计稿 这是我现在最常用的起手方式，具体操作很简单，打开Pixso，在画布上找到AI助手，直接用自然语言描述你要做什么。 比如我想做一个外卖类App的设计，我可以这么输入： "Create a vibrant food delivery app with 3 pages: Home, Search and Product Detail, using a white base with orange and yellow accents." 等几分钟，AI就会给你生成一个完整的页面设计。 第二步：优化和调整设计稿 AI生成的初稿肯定不是完美的，接下来需要手动调整优化，你可以直接点击右上角edit按钮编辑。 这个阶段我主要关注三个方面： 首先是视觉层级，检查页面上的信息是否有清晰的主次关系，重要的内容是否足够突出。比如我加大标题的字号，调整元素之间的间距，确保用户浏览的时候能快速抓住重点。 其次是交互细节，补充一些AI可能遗漏的状态，比如按钮的悬停状态、点击反馈、加载状态等。 以这个页面为例，页面逻辑有些问题，我可以直接框住需要调整的元素，提出修改建议。 调整检查好没问题，就可以点击右上角，一键导入到pixso了。 稍等几分钟即可～ 第三步：建立变量系统 这一步是重点，也是我觉得Pixso最强大的地方。 通过变量系统，你可以让设计稿变得非常灵活，后期修改的时候能节省大量时间。 变量系统听起来有点复杂，但其实很简单，你可以把它想象成Excel里的公式，定义一次，多处引用，修改一个地方就能全局更新。 点击设计-本地变量-创建变量。 以我做的这个外卖App为例，我会创建这些变量： 1️⃣ 颜色变量：定义主色、辅助色、背景色、文字色等。 比如主色我设置为#FF6B35（活力橙），然后把所有需要用主色的地方（按钮、图标、强调文字等）都绑定这个变量。 以后如果要换主题色，只需要修改这一个变量，整个设计稿的颜色就会同步更新。 2️⃣ 数值变量：管理各种尺寸参数。 我一般会定义spacing-xs（4px）、spacing-sm（8px）、spacing-md（16px）、spacing-lg（24px）这样的间距变量，还有字号变量font-xs（12px）、font-sm（14px）、font-md（16px）等。 用了这些变量后，整个设计的间距和字号就会很规范，不会出现这里14px那里15px的混乱情况。 3️⃣ 文本变量：存储那些会重复出现的文案。 比如按钮上的"立即开始"、"查看详情"这些文字，定义成变量后，如果产品经理要改文案，你只需要改一次就行了。 这里要重点说一下变量的一个强大功能：模式切换。 比如我在做这个App的时候，希望同时设计深色和浅色两套主题。 传统做法需要复制一份设计稿，然后逐个修改颜色，工作量巨大，而且后期维护也很麻烦。 用变量系统就简单多了，我可以直接创建两个模式："浅色模式"和"深色模式"，然后给同一个颜色变量在不同模式下设置不同的值。 比如背景色变量，在浅色模式下设置为#FFFFFF，在深色模式下设置为#1A1A1A。 设置完成后，只需要在右侧面板切换模式，整个设计稿就会自动切换主题。 这个功能不仅可以节省时间，还能确保两套主题的设计一致性。 第四步：设计稿转代码 借助Pixso MCP，你可以直接把你的设计稿转成代码。 具体怎么操作呢？ 首先确保你安装了最新版的Pixso客户端，然后在文件菜单里启用Pixso MCP。 启用后，画布底部会出现一个提示，说明MCP服务已经开启。 接下来需要把Pixso MCP集成到你的代码编辑器里。 我用的是Cursor，配置过程很简单。 打开Cursor的设置，找到Tools & MCP，添加一个自定义MCP，粘贴配置代码，保存后启动就可以了。 配置完成后，回到Pixso，选中你要转换的设计稿（一个容器或者组件），右键复制链接。 然后切换到Cursor，打开Agent模式，粘贴链接，告诉它"生成HTML代码"或者"生成React组件"。 几分钟后，Cursor就会自动生成对应的前端代码。 这个功能对前端工程师来说也很友好，可以直接在Cursor里获取设计稿数据，包括样式、间距、颜色等，不用再手动去量尺寸了。而且因为代码是AI生成的，命名规范、代码结构都比较标准。 特别是当你用了变量系统后，MCP在转换代码的时候也能识别这些变量，生成的CSS会使用CSS变量，这样前端后续维护起来也很方便。 当然，对于设计师来说，最终还是要看你能不能做出好的设计。 如果你现在正在寻找合适的UI设计工具，可以试试Pixso，个人版免费，上手成本低，功能也足够强大。 当然，工具会不断迭代，方法也会持续优化，保持学习的热情、享受设计的过程，才是最重要的。

00
歪歪了
27天前
歪歪了
28天前
歪歪了
1月前
歪歪了
1月前

AI产品黄叔: Manus联创的“血泪”教训：为什么上下文工程，而非模型微调，才是护城河？ 一位拥有10年NLP（自然语言处理）经验的AI创业公司联创坦言：“对于创业公司，过早微调（Fine-tuning）模型是一个陷阱。” 这不是危言耸听。 Manus的联合创始人兼首席科学家Peak，在最近与LangChain创始人的对谈中，分享了他的“血泪教训”：他的上一个产品，迭代速度被长达1-2周的模型训练周期活活拖死。 这一次，他选择把所有赌注压在“上下文工程”（Context Engineering）上，并为此，他的团队在短短几个月内，将产品重构了整整5次。 为什么他如此笃定？ 1. “微调”的陷阱：被模型拖垮的“上一个”公司 在创立Manus之前，Peak已经在NLP领域摸爬滚打了10年。他的上一个创业项目，和现在许多AI团队一样，选择了“训练自有模型”的重度路线。 结果是灾难性的。 “我们的产品创新速度，完全被模型的迭代速度给限制了。”Peak回忆道。 在产品还没找到PMF（市场契合点）的阶段，他们却在花费大量时间“提升那些可能根本不重要的基准测试”。一个单一的“训练-评估”周期，就需要1到2周。 当团队在焦急地等待模型时，市场窗口早已关闭。 但最大的“陷阱”还不是时间，而是“僵化”。 “当你微调一个模型时，”Peak解释道，“你通常会固定一个‘行动空间’（Action Space）。” 这就像你花重金打造了一把精妙绝伦的“屠龙宝刀”。但如果第二天，巨头发布了（比如多模态MCP），市场不再需要“屠龙”，而是需要“飞天”，你这把刀就成了一堆废铁。 “Manus的设计就曾被MCP的发布彻底改变。”Peak坦言，如果他们当时死磕微调，唯一的下场就是被市场活活抛弃。 2. 划清界限：AI应用层的真正边界 经历了上一次的“痛苦”领悟，Peak这次为Manus找到了一个清晰无比的战略边界。 “你必须坚定地划清你的界限（Be firm about where you draw the line）。” 对于AI应用层创业，这条界限就是“上下文工程”。 Peak认为，这是目前应用和模型之间最清晰、最实用的边界。创业公司应该“尽可能久地”依赖通用大模型，而不是试图在模型层与巨头竞争。 巨头的护城河是“模型”，而应用层的护城河，就是你“使用”模型的能力——即“上下文工程”。 那么，这个听起来高深的“上下文工程”到底是什么？ 3. “上下文悖论”：Agent的阿喀琉斯之踵 2022年，我们谈论的是“提示词工程”（Prompt Engineering），它解决的是单次交互。 而2024年，我们面临的是“上下文工程”（Context Engineering），它要解决的是Agent（智能体）的长序列、多轮工具调用。 LangChain的创始人Lance指出了一个“上下文悖论”： Agent要完成复杂任务，必须大量调用工具（典型任务约50次）来获取上下文。 但上下文越长，Agent的性能就越差，成本也呈指数级上升。 更糟糕的是，Peak发现，即使是100万Token的上下文窗口，模型在处理到200K（约20万）时，性能就开始“腐烂”（Context Rot），出现重复、缓慢和质量下降。 “上下文腐烂”的阈值，大约就在128K到200K之间。 你的Agent又慢又笨，不是模型不行，是你的“上下文工程”没做好。 4. 破局：上下文工程的4大支柱 如何解决这个悖论？LangChain的Lance总结了业内顶尖团队（包括Manus）都在使用的4大工程支柱： 上下文卸载 (Offloading) 做法：不把所有信息都塞进上下文。比如，一个万字的网络搜索结果，只在上下文中返回一个文件路径（file.txt），Agent需要时自己去读。 场景：处理大文件、大输出。 上下文检索 (Retrieving) 做法：把信息（如记忆）存储在外部（如向量数据库），在需要时通过RAG或简单的grep命令检索回来。 场景：长时记忆、知识库。 上下文隔离 (Isolation) 做法：使用多智能体（Multi-Agent）架构，每个子Agent只处理自己的小上下文窗口，互不干扰。 场景：复杂任务拆解。 上下文缩减 (Reducing) 做法：这是最核心也最精妙的一步，即在上下文“腐烂”之前，主动对其进行“瘦身”。 而Manus团队，正是在“上下文缩减”上，做到了极致。 5. Manus实战：“压缩”与“摘要”的精妙艺术 Peak的团队将“缩减”分为了两种截然不同的操作： 1. 压缩 (Compaction)：可逆的“瘦身” 定义：删除那些可以从外部（如文件系统）重建的信息。 例子：一个工具调用，完整信息是{path: "file.txt", content: "..."}。在“压缩”后，只保留{path: "file.txt"}。 优势：信息“零”丢失，只是被“外置”了。 2. 摘要 (Summarization)：不可逆的“遗忘” 定义：对历史信息进行总结，彻底丢弃原文。 优势：大幅度释放上下文空间。 Manus的策略堪称精妙： 设置“腐烂”闹钟：首先，团队会设置一个“腐烂阈值”，比如128K。 先“压缩”，后“摘要”：当上下文达到128K时，系统首先触发“压缩”。只在“压缩”的收益也变小时，才万不得已触发“摘要”。 “压缩”的艺术：执行“压缩”时，只压缩最老的50%历史，并保留最新的50%工具调用的完整信息。这能确保模型有足够的新鲜“样例”来模仿，防止其行为错乱。 “摘要”的技巧：执行“摘要”时，会使用原始的、未经压缩的数据来总结，以保证信息保真度。并且，同样会保留最后几个工具调用的全量信息，防止模型“忘记自己刚刚在干什么”。 6. 在流沙上构建：5次重构与“更贵”的开源 这套复杂的“上下文工程”架构，就是Manus的护城河。它让Manus有能力在“流沙”（不断迭代的大模型）之上构建稳固的应用。 “从3月到现在，我们已经重构了5次。”Peak说。 这种“上下文工程”能力，也让他们在选择模型时有了更反直觉的洞察。 Peak甚至认为，对于Agent应用，使用开源模型可能“更贵”。 “这很有趣，关键在于成本。”他解释道，“Agent的输入（上下文）远大于输出，KV缓存至关重要。”而头部API厂商（如Anthropic）在分布式KV缓存上做了坚实的基建，使得在超长上下文中，API的成本甚至低于自托管的开源模型。 7. 结语：构建更少，理解更多 回顾Manus的历程，Peak给出了他最深刻的领悟： “我们最大的飞跃，不是来自添加了更花哨的上下文管理技巧，而是来自‘简化’和‘移除不必要的层’。” “我们最终的哲学是：构建更少，理解更多（Build less and understand more）。” 这位10年NLP老兵最后总结道： “上下文工程的真正目标，不是让你的系统更复杂，而是让模型的工作，变得更简单。” from Langchain Context Engineering for AI Agents with LangChain and Manus

00
歪歪了
1月前

apvia.bot: Github 每日趋势 2025-10-24 1. /minio/minio: MinIO 是一个高性能的 S3 兼容对象存储解决方案，专为 AI/ML 和大规模数据分析工作负载优化设计. https://github.com/minio/minio [⭐️ 56,648] 2. /guofei9987/blind_watermark: blind-watermark 是一个基于 DWT-DCT-SVD 的盲水印工具，可用于在图片中嵌入和提取水印，并抵抗多种攻击. https://github.com/guofei9987/blind_watermark [⭐️ 8,877] 3. /mountain-loop/yaak: Yaak 是一款隐私优先的桌面API客户端，支持REST、GraphQL等多种协议，具有离线优先、无遥测和高度可定制化特点. https://github.com/mountain-loop/yaak [⭐️ 13,276] 4. /LadybirdBrowser/ladybird: Ladybird 是一款基于现代网络标准的独立浏览器，采用多进程架构，目前处于预发布阶段，适合开发者使用. https://github.com/LadybirdBrowser/ladybird [⭐️ 50,460] 5. /paperless-ngx/paperless-ngx: Paperless-ngx 是一个文档管理系统，将物理文档转换为可搜索的在线存档，帮助减少纸张使用，并支持团队协作开发. https://github.com/paperless-ngx/paperless-ngx [⭐️ 33,183] 6. /dyad-sh/dyad: Dyad 是一个本地开源的 AI 应用构建工具，支持跨平台运行，无需注册，使用自己的 AI API 密钥，保证隐私和速度. https://github.com/dyad-sh/dyad [⭐️ 16,952] 7. /k2-fsa/sherpa-onnx: 该项目支持多种语音处理功能，如语音识别、合成和分离，并兼容多种平台和编程语言. https://github.com/k2-fsa/sherpa-onnx [⭐️ 8,187] 8. /rossant/awesome-math: Awesome Math 是一个精心整理的数学资源列表，涵盖多个数学分支和通用学习资源，大部分免费提供. https://github.com/rossant/awesome-math [⭐️ 11,149] 9. /louislam/uptime-kuma: Uptime Kuma 是一个易于使用的自托管监控工具，支持多种协议监控和丰富的通知服务，提供美观的UI界面和状态页面. https://github.com/louislam/uptime-kuma [⭐️ 76,980] 10. /harvard-edge/cs249r_book: 这是一个开源教材项目，专注于教授如何构建从边缘设备到云部署的机器学习系统，源自哈佛大学CS249r课程. https://github.com/harvard-edge/cs249r_book [⭐️ 4,688]

00
歪歪了
1月前
cc
00
歪歪了
2月前
歪歪了
2月前
00
歪歪了
7月前
输出驱动

————————
AI NOW!：强调「输出驱动」，具体如何设计这个机制？
玉伯：借鉴知识管理界的 PARA 方法论。

P 是project，就是你做任何事情，最好有一个时间节点，围绕 project去找资料，做产出；A是area，领域，比如一些没有时间节点的 project。我目前对AI感兴趣，但不知道什么时候能研究明白，就是area；R就是 resource，各种资料；最后的A是ARCHIVE，归档，这是非常重要的一环，不要越积越多，如果你发现某个 project完成不了，可以把它 ARCHIVE，或直接删除。

张卓: 和@玉伯 很真诚的一次聊天，印象最深的一句：大厂的好多高p，我也看不上呢，期待YouMind今年年中的大版本更新。@松岛兔 100 AI Ceators第二篇了。

00