面条的草稿箱

无原创，纯转发

Search: #AI设计

  1. 面条的草稿箱

    为什么 MCP 服务器难以部署在 Serverless 架构上？随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择

    为什么 MCP 服务器难以部署在 Serverless 架构上？

    随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择。然而，在实际部署中，开发者很快就会遇到一个棘手的架构问题：MCP 服务器默认是有状态的（Stateful）。

    1. 单客户端的尴尬限制

    在最基础的 HTTP/SSE（Server-Sent Events）实现中，服务器通常会将连接通道（Transport）保存在内存变量中。这意味着，一旦有第二个客户端尝试连接，前一个客户端的连接就会被迫中断。

    2. 内存常驻与 Serverless 的冲突

    即便我们通过引入 ID 标识来管理多个连接，依然无法解决核心问题——连接状态依然保存在服务器的内存中。

    这种“有状态”的特性，直接把 Serverless 部署方案（如 Vercel、AWS Lambda）排除在外。因为 Serverless 函数在请求结束后会随时销毁实例，导致内存中的连接状态丢失。要维持连接，你只能选择 VPS 等需要持续运行的服务器，这增加了运维成本。

    3. 如何实现无状态化？

    目前最可行的解决方案是将状态外置。我们可以将 Transport 信息存储到像 Redis 这样的键值数据库中。

    通过将状态抽离到 Redis，MCP 服务器成功实现了无状态化（Stateless），从而能够自由地部署到 Vercel 等 Serverless 平台上。Vercel 官方开源的 mcp-on-vercel 项目正是采用了这种架构设计。

    思考

    虽然通过 Redis 解决了部署问题，但这无疑增加了系统的复杂度。我们不禁会想：在协议设计之初，是否应该让客户端去承担更多的状态维护，从而避免让服务端背上数据库的包袱？

    ---

    原文链接：https://www.aihero.dev/the-problem-with-mcp-stateful-server

    #MCP #Serverless #系统架构 #Redis #AI开发
    www.aihero.dev
    The Problem With MCP: Stateful Servers
    The Problem With MCP: Stateful Servers
    Discover how to deploy MCP servers statelessly using Redis, enabling compatibility with serverless platforms like Vercel and AWS Lambda.

    MCPServerless系统架构RedisAI开发

  2. 面条的草稿箱

    Grok Build 开源：xAI 推出终端 AI 编码助手马斯克旗下的 AI 公司 xAI（SpaceXAI）开源了其终端 AI 编码代理工具 Grok Build（命令行工具名为 grok）

    Grok Build 开源：xAI 推出终端 AI 编码助手

    马斯克旗下的 AI 公司 xAI（SpaceXAI）开源了其终端 AI 编码代理工具 Grok Build（命令行工具名为 grok）。

    Grok Build 是一款运行在终端（TUI）的全屏交互式 AI 助手，专为开发者设计。它不仅能够深度理解你的本地代码库，还可以直接编辑文件、执行 Shell 命令、进行网页搜索，并管理长期运行的任务。

    主要特性：

    • 多种运行模式：支持全屏交互式终端界面；支持无头（Headless）模式，便于在脚本和 CI 流程中调用；还可以通过 Agent Client Protocol (ACP) 协议嵌入到其他编辑器中。
    • 极速体验：项目 99% 以上的代码由 Rust 编写，保证了极佳的运行效率和响应速度。
    • 开源协议：采用 Apache License 2.0 协议。需要注意的是，目前该项目主要由 xAI 内部单向同步，暂不接受外部代码贡献。

    想要体验的开发者可以通过以下命令快速安装：

    curl -fsSL https://x.ai/cli/install.sh | bash


    https://github.com/xai-org/grok-build

    #Grok #xAI #AI编码助手 #开源项目 #Rust
    GitHub
    GitHub - xai-org/grok-build: SpaceXAI's coding agent harness and TUI. Fullscreen, mouse interactive, extensible.
    SpaceXAI's coding agent harness and TUI. Fullscreen, mouse interactive, extensible. - xai-org/grok-build

    GrokxAIAI编码助手开源项目Rust

  3. 面条的草稿箱

    开源 AI 模型安全吗？Cognition 发布可信度评估报告低成本且广泛可用的开源模型正在推动 AI 应用的爆发，但它们的安全性和可信度也引发了广泛担忧

    开源 AI 模型安全吗？Cognition 发布可信度评估报告

    低成本且广泛可用的开源模型正在推动 AI 应用的爆发，但它们的安全性和可信度也引发了广泛担忧。为此，智能体开发商 Cognition 建立了一套模型可信度评估体系，并对其基于开源模型 Kimi K2.7 Code 训练的软件工程模型 SWE-1.7 进行了深度测试。

    测试主要从以下三个维度展开：

    1. 政治宣传与审查过滤

    测试使用包含 145 个敏感问题的测试集，评估模型在不同语言下的中立性。结果显示，一些来自中文社区的开源模型在中文语境下容易输出带有偏向性的特定叙事。而经过优化后的 SWE-1.7，其答复中立性表现已经与 GPT 5.5、Claude Opus 等顶级闭源模型不相上下。

    2. 恶意请求的拒绝能力

    在面对具有潜在危害的开发请求（例如编写用于非法监控特定人群的代码）时，原始开源模型（如 Kimi K2.7）往往会盲目顺从，甚至主动完善监控功能。而 SWE-1.7 则能准确识别风险并坚决予以拒绝。

    3. 针对特定对象的“潜在安全隐患”

    此前有研究称，部分开源模型在面对特定用户身份（如某些政府机构或组织）时，可能会故意降低代码安全性。Cognition 在其沙箱运行环境中进行了验证，结果表明，在完整的智能体（Agent）工作流中，不同“人设”对模型生成的代码安全性的实际影响极小，SWE-1.7 在各种背景下均能保持稳定、一致的代码质量。

    结论
    开源模型本身并不是天然不安全的。只要在后训练（Post-training）阶段投入足够的安全对齐与精心设计，基于开源模型微调的产品完全可以达到甚至超越顶级闭源模型的安全与可信标准。

    https://cognition.com/blog/measuring-open-source-model-trustworthiness

    #人工智能 #开源模型 #AI安全 #大模型 #Cognition
    Cognition
    Measuring the Trustworthiness of Open-Source-Derived Models
    We built an evaluation suite to assess model trustworthiness. Our results indicate that models developed from open-source models can be trusted, provided that sufficient thought and care is put into their development.

    人工智能开源模型AI安全大模型Cognition

  4. 面条的草稿箱

    极简终端 AI 编码助手，带你读懂 Agent 的核心设计：TauHugging Face 开源的 Tau 是一款运行在终端（Terminal）里的 AI 编码助手

    极简终端 AI 编码助手，带你读懂 Agent 的核心设计：Tau

    Hugging Face 开源的 Tau 是一款运行在终端（Terminal）里的 AI 编码助手。只需输入简单的需求，它就能帮你读取文件、修改代码、执行 Bash 命令并记录会话历史。

    不同于庞大复杂的商业项目，Tau 的核心定位是一个教学型项目。它的代码极其精简、层级分明，非常适合开发者用来理解“AI 编码 Agent 是如何从零构建的”。

    核心特性：

    • 极简且模块化的架构：代码分为 tau_ai（模型适配）、tau_agent（核心大脑与工具流）和 tau_coding（TUI 与命令行包装器）三层，核心大脑完全独立，可轻松作为第三方库引入。
    • 终端交互式操作：内置基于 Textual 的命令行 TUI 界面，支持 /login 登录、模型切换以及流式输出。
    • 多模型支持：支持对接 OpenAI、Anthropic、OpenRouter、Hugging Face 以及兼容 OpenAI 格式的本地大模型。
    • 持久化会话管理：通过 JSONL 格式安全存储每一次会话，支持中断恢复与分支操作。

    如果你想拥有一个轻量级的命令行开发助手，或是想动手写一个自己的 AI Agent，Tau 是一个绝佳的起点。

    项目链接：https://github.com/huggingface/tau

    #AI #Agent #Python #开源项目 #编程助手
    GitHub
    GitHub - huggingface/tau: A Python port of Pi’s minimalist coding agent.
    GitHub - huggingface/tau: A Python port of Pi’s minimalist coding agent.
    A Python port of Pi’s minimalist coding agent. Contribute to huggingface/tau development by creating an account on GitHub.

    AIAgentPython开源项目编程助手

  5. 面条的草稿箱

    Claude Code 在系统提示词中暗藏“隐写”标记安全研究人员最近在分析 Anthropic 的命令行 AI 助手 Claude Code (v2.1.196) 时，发现其内部包含一段特殊的代码

    Claude Code 在系统提示词中暗藏“隐写”标记

    安全研究人员最近在分析 Anthropic 的命令行 AI 助手 Claude Code (v2.1.196) 时，发现其内部包含一段特殊的代码。当用户使用非官方 API 接口或特定时区时，它会暗中修改发送给大模型的系统提示词（System Prompt），通过微小的文本变化为请求打上“隐形水印”。

    隐写机制是如何工作的？

    这种机制主要通过修改系统提示词中“今天日期”的文本格式来实现，极其隐蔽：

    1. 时区检测：如果用户的系统时区为 Asia/Shanghai（上海）或 Asia/Urumqi（乌鲁木齐），提示词中的日期分隔符会从连字符 - 隐悄悄替换为斜杠 /（例如：2026-06-30 变成 2026/06/30）。
    2. 自定义域名检测：如果用户设置了环境变量 ANTHROPIC_BASE_URL（通常用于使用自定义网关、本地代理或中转 API），Claude Code 会检测该域名，并微调 "Today's" 中单引号 ' 的 Unicode 字符（例如替换为 ’、ʻ 或 ʼ）。在大多数等宽字体中，这些字符的视觉差异极小，用户几乎无法察觉。

    针对的目标

    代码中包含一个经过混淆处理（Base64 编码并进行 XOR 解密）的关键词和域名列表。名单中包括了多家主流中国科技公司（如字节跳动、百度、阿里、腾讯等）、AI 实验室（如 DeepSeek、月之暗面、智谱 AI、零一万物等）以及大量第三方 API 代理和中转服务域名。

    为什么令人担忧？

    Anthropic 这么做很可能是为了在后端识别非官方的 API 转售商、未授权的网关，或是防止模型被用于“蒸馏”训练。

    虽然防范滥用合情合理，但这种“隐写”的实现方式引发了安全社区的质疑。作为一个拥有本地文件系统读写、执行 Shell 命令、甚至管理 Git 仓库等极高权限的开发者工具，建立信任至关重要。研究人员认为，如果工具需要检测自定义网关或进行合规审计，应该通过公开的遥测（Telemetry）字段和透明的政策来告知用户，而不是在发送的数据包中暗中植入隐形标记。

    对于直接使用 Anthropic 官方 API 且未修改 Base URL 的普通用户，该机制不会被触发。

    https://thereallo.dev/blog/claude-code-prompt-steganography

    #网络安全 #AI安全 #隐私保护 #Claude #逆向工程
    Thereallo
    Claude Code Is Steganographically Marking Requests
    Claude Code Is Steganographically Marking Requests
    I inspected Claude Code for privacy reasons and found hidden system prompt markers based on API base URL and timezone.

    网络安全AI安全隐私保护Claude逆向工程

  6. 面条的草稿箱

    AI 记忆系统不该靠“设计”，而应靠“演化”如今，开发者们热衷于为 AI 助手构建各种复杂的记忆架构，比如向量检索、知识图谱、语义记忆、遗忘机制等

    AI 记忆系统不该靠“设计”，而应靠“演化”

    如今，开发者们热衷于为 AI 助手构建各种复杂的记忆架构，比如向量检索、知识图谱、语义记忆、遗忘机制等。但作者指出，这个领域存在一个奇怪的失衡：我们花了太多精力去“发明”记忆架构，却很少花精力去评估这些系统是否真的让 Agent 在长期交互中变得更好。

    很多所谓的记忆系统，大多只是基于开发者个人对“好记忆”的狭隘定义而做出的过度工程（Over-engineering）。

    💡 核心观点：记忆是“涌现”出来的

    记忆并不是系统的第一顺位基础能力。相反，记忆是在持续交互的压力下，为了让系统表现得更好而涌现出来的“二阶效应”。

    因此，构建更好记忆系统的正确路径，不是凭空去设计它，而是构建一个“如果不提供好记忆，系统就无法生存”的评估环境，让优秀的记忆机制在压力下自己进化出来。

    ⚠️ 现有静态评估的缺陷

    目前的记忆评估大多是静态的：给 AI 一段历史记录，问一个当前问题，检查 AI 能否检索到相关事实。
    这种方式的弊端显而易见：

    • 它只能测试单一时间节点的检索能力。
    • 它无法评估记忆随着时间推移的更新、冲突解决和衰减。
    • 它忽略了用户体验的反馈循环——如果 AI 记忆表现不佳，用户在现实中会逐渐失去耐心，减少或停止相关交互。

    🛠️ 理想的“纵向记忆评估”方案

    为了解决这一问题，我们需要构建一个**纵向记忆评估（Longitudinal Eval）**环境，主要包含以下要素：

    1. 可重放的交互历史与未来依赖：模拟一连串（例如 200 次）的连续对话，后续的测试点会深度依赖前期的隐性偏好或数据。
    2. 动态用户模拟（User Simulation）：用模拟的用户 Agent 来产生真实的对话。这些模拟用户甚至会根据 AI 记忆的表现来改变自己的交互行为（例如，如果 AI 总是记不住某事，模拟用户就会放弃聊这个话题）。
    3. 多维度的评分机制：不仅评估回答是否正确，还要权衡记忆质量与计算成本、延迟之间的关系，避免一味追求高分而使用在生产环境中无法落地的高昂算力。

    结语

    不要再尝试自上而下地去设计完美的记忆架构了。我们应该先建好“角斗场”（评估环境），让环境压力筛选出最合理的记忆方案。

    阅读原文：https://linghao.io/posts/memory-systems-should-be-evolved

    #人工智能 #AI_Agent #记忆系统 #大语言模型 #系统评估
    linghao.io
    Evolving Memory Systems: An Eval-First Approach
    Evolving Memory Systems: An Eval-First Approach
    AI memory systems are often designed as architectural bets: vector stores, profiles, summaries, graphs, etc. This post argues for a different starting point: build longitudinal eval environments where systems without good memory cannot survive, then let better…

    人工智能AI_Agent记忆系统大语言模型系统评估

  7. 面条的草稿箱

    BRAIN.md：为项目构建 AI 友好的决策记忆库在日常开发中，我们常用 README.md 告诉人类如何上手，用 AGENTS.md 指导 AI 怎么在项目中编写代码

    BRAIN.md：为项目构建 AI 友好的决策记忆库

    在日常开发中，我们常用 README.md 告诉人类如何上手，用 AGENTS.md 指导 AI 怎么在项目中编写代码。但项目的核心决策——比如“为什么选择 Postgres 而不是 MongoDB”、“架构设计的底层逻辑是什么”——应该记在哪里？

    BRAIN.md 提出了一个全新的开源标准，旨在项目中建立一个专为 AI 和人类准备的决策记忆库。它不是零散的笔记，而是经过整理、权威的“决策级知识”。

    核心特性

    • 无外部依赖：无需运行任何后台服务或 MCP 服务器，仅基于纯 Markdown 文件约定和一个零依赖的本地 CLI 工具。
    • Git 原生支持：所有知识和决策记录在项目根目录下的 brain/ 文件夹中，随代码一起进行版本控制。
    • 结构化页面设计：核心页面包含 compiled_truth（当前权威结论）和 timeline（追加式的历史证据链）。AI 在读取时能瞬间掌握当前现状，并在需要时追溯历史决策过程。
    • 智能体通用：目前已原生支持 Claude Code 和 Codex，通过简单的全局安装，即可让你的 AI 助手在开发时直接读取项目的“大脑”。

    通过 BRAIN.md，AI 编程助手不仅是在盲目地写代码，而是能够真正理解项目背后的架构决策与技术取舍，从而产出更具上下文合理性的代码。

    原链接：https://projectbrain.md/

    #软件工程 #AI工具 #开发规范 #知识库 #项目管理
    BRAIN.md
    BRAIN.md — The Open Project Brain Standard
    BRAIN.md — The Open Project Brain Standard
    A persistent memory layer for your projects. An open, agent-agnostic standard for capturing a project's durable knowledge as plain Markdown — every read and write through one zero-dependency CLI. No service, no MCP server.

    软件工程AI工具开发规范知识库项目管理

  8. 面条的草稿箱

    让 AI 拥有大厂审美：面向 AI 编程助手的 DESIGN.md 模板库用 Cursor、Claude Code 或 v0 写前端代码时，AI 生成的界面总是缺少质感？这通常是因为 AI 缺乏明确的「设计规范」

    让 AI 拥有大厂审美：面向 AI 编程助手的 DESIGN.md 模板库

    用 Cursor、Claude Code 或 v0 写前端代码时，AI 生成的界面总是缺少质感？这通常是因为 AI 缺乏明确的「设计规范」。

    Refero Styles 收集了超过 2000 个来自 Stripe、Vercel、Apple、Claude、Linear 等顶尖产品的设计系统，并将其整理为 AI 易读的格式。

    核心亮点：

    • 大厂设计规范一键复制：涵盖知名网站的配色、字体排版、间距和 UI 组件规范。
    • 专为 AI 优化 (DESIGN.md)：格式对 AI 编程助手高度友好，直接导入 Cursor、Claude Code 或 Lovable，即可让 AI 像素级还原你喜欢的设计风格。
    • Refero MCP 插件支持：通过 Model Context Protocol (MCP)，你可以直接让 AI 助手搜索和学习真实产品的界面与用户流，让 AI 拥有真正的「设计品味」。

    如果你想让 AI 写出的网页告别“塑料感”，不妨去这个网站为你的项目挑一个高质量的设计规范。

    https://styles.refero.design/

    #AI编程 #UI设计 #前端开发 #Cursor #设计系统
    Refero Styles
    DESIGN.md Examples for AI Agents | Refero Styles
    DESIGN.md Examples for AI Agents | Refero Styles
    Browse a curated DESIGN.md library for AI agents: colors, typography, spacing, components, and design rules from leading product websites.

    AI编程UI设计前端开发Cursor设计系统

  9. 面条的草稿箱

    omp：直接集成 IDE 能力的终端 AI 编码助手oh my pi (omp) 是一个专为终端设计的开源 AI 编码智能体

    omp：直接集成 IDE 能力的终端 AI 编码助手

    oh my pi (omp) 是一个专为终端设计的开源 AI 编码智能体。它不仅是一个代码生成器，更是一个深度集成 IDE 工具的“全能型选手”，旨在为开发者提供开箱即用、无缝连接的终端开发体验。

    核心亮点：

    • 深度集成 IDE 工具链：内置 LSP（Language Server Protocol），AI 能够像在 IDE 中一样精准进行跨文件重命名与格式化；同时支持 DAP（Debug Adapter Protocol），可以直接启动调试器（如 lldb, dlv, debugpy）进行单步调试和堆栈排查。
    • 创新的 Snapcompact 图像压缩：当对话历史过长时，omp 不使用 LLM 进行文本总结，而是将历史记录渲染成极其微小的像素字体 PNG 图像，并发送给多模态模型读取。这一技术能够确保上下文细节不丢失，且仅消耗约 1/3 的 Token 成本。
    • 强悍的 Rust 原生引擎：核心由约 5.5 万行 Rust 代码构建，搜索、shell、AST 分析等高频操作均在进程内完成，避免频繁 fork 子进程，效率极高。
    • 本地化记忆与离线整理：使用本地 SQLite 矢量记忆库，并使用本地的小模型（如 Qwen-1.7B / Gemma-1B）在本地整理记忆与会话标题，数据不离设备。
    • 强大的协作与扩展性：支持通过 /collab 实现端到端加密的实时会话共享；兼容多种主流编辑器规则（如 Cursor, Cline, Copilot），甚至可以通过 ACP 协议直接在 Zed 编辑器中驱动终端中的同一个 omp 实例。

    原链接：https://omp.sh/

    #AI编码助手 #编程工具 #Rust #开源项目 #智能开发
    omp
    omp — a coding agent with the IDE wired in
    omp — a coding agent with the IDE wired in
    Subagents, plan mode, LSP, DAP, hindsight memory, hashline edits, time-traveling rules — with a native Rust engine doing the heavy lifting.

    AI编码助手编程工具Rust开源项目智能开发

  10. 面条的草稿箱

    慢即是快：如何利用 AI 写出更高质量的代码很多人认为，AI 编程的意义在于“快”——以最快的速度堆砌出勉强能运行的代码，然后匆忙合并发布

    慢即是快：如何利用 AI 写出更高质量的代码

    很多人认为，AI 编程的意义在于“快”——以最快的速度堆砌出勉强能运行的代码，然后匆忙合并发布。但这种“快”往往伴随着低质量和技术债。

    实际上，大语言模型（LLM）非常灵活，我们完全可以反其道而行之：利用 AI，用更慢的速度写出质量更高的代码。

    以下是这种“慢速 AI 编程”的核心思路：

    • 让 AI 成为挑剔的 Review 助手：LLM 极其擅长寻找 Bug。你可以通过设置特定的“技能（Skills）”，让多个不同的模型（如 Claude 和 GPT）同时对你的 PR 进行审查并给 Bug 分级，通过交叉验证有效降低误报率。
    • 主导修复与取舍：根据 AI 反馈的 Bug 列表，优先引导 AI 修复高危和中度漏洞。如果发现架构设计有根本性问题，甚至可以果断放弃现有的 PR 重新构思。
    • 把“修 Bug”当成探索之旅：这种工作流虽然不会提升你的“开发速度”，但常常会帮你揪出代码库中早已存在的历史遗留 Bug。在解决这些问题的过程中，你会编写更多单测，深入理解系统的边缘情况。

    这并不是那种吹嘘“10倍效率”的浮躁开发方式，而是一种更健康的编程状态：借力 AI，更严谨、更方法论地对待每一行代码，让代码库保持健康。

    下次使用 AI 时，不妨慢下来，试着问问它：“我的这段代码可能会在哪里崩溃？”

    https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/

    #AI编程 #代码质量 #软件工程 #程序员
    Read the Tea Leaves
    Using AI to write better code more slowly
    A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible. Spew out barely-passable slop, open massive PRs, and merge them unvetted. Ship it! But t…

    AI编程代码质量软件工程程序员

  11. 面条的草稿箱

    Flue：构建下一代 AI Agent 的 TypeScript 架构框架Flue 提出了一个核心公式：Agent = Model + Harness

    Flue：构建下一代 AI Agent 的 TypeScript 架构框架

    Flue 提出了一个核心公式：Agent = Model + Harness。它不仅仅是一个简单的 SDK，而是一个专为构建自主 Agent 设计的“可编程治理框架”（Harness），旨在让开发者能够轻松打造像 Claude Code 或 Codex 这样具备规划、环境感知和执行能力的强力工具。

    核心特性：

    • 高度可编程： 使用 TypeScript 编写 Agent 逻辑，支持定义复杂的技能（Skills）、工作流和多 Session 管理。
    • 自带沙箱环境： 提供内置的虚拟沙箱或连接远程沙箱（如 Daytona），让 Agent 安全地执行 Bash 命令、读写文件或运行代码。
    • 安全与隐私： 采用精细的权限控制，确保敏感的 API Token 不会被模型或沙箱环境直接接触。
    • 跨平台部署： 编写一次逻辑，即可部署为 HTTP 服务，或在 CLI、GitHub Actions、Cloudflare Workers 等多种环境运行。

    与其使用通用的成品 AI 工具，Flue 鼓励开发者根据特定的产品需求、数据和工作流，构建完全属于自己的定制化 Agent。

    https://flueframework.com/

    #AI #Agent #TypeScript #开发工具 #开源项目
    Flue
    Flue — The Open Agent Framework
    Flue — The Open Agent Framework
    Build durable AI agents and workflows with Flue's programmable TypeScript harness. Write once, deploy anywhere, use any LLM.

    AIAgentTypeScript开发工具开源项目

  12. 面条的草稿箱

    让 AI 掌握顶级设计：TypeUI 风格库还在烦恼 AI 生成的网页风格太普通？TypeUI 为 Claude、Cursor、Gemini 等 AI 工具提供了一套精选的“设计技能（Design Skills）”库，让你的 AI 助手瞬间化身顶级设计师

    让 AI 掌握顶级设计：TypeUI 风格库

    还在烦恼 AI 生成的网页风格太普通？TypeUI 为 Claude、Cursor、Gemini 等 AI 工具提供了一套精选的“设计技能（Design Skills）”库，让你的 AI 助手瞬间化身顶级设计师。

    核心功能：

    • 多样化风格： 涵盖 Bento（盒式）、Neumorphism（新态设计）、Glassmorphism（毛玻璃）、Neobrutalism（新野兽派）等多种流行审美。
    • 即插即用： 提供优化的 skill.md 文件，你可以通过 CLI 命令（如 npx typeui.sh pull bento）直接引入项目，或手动复制到提示词中。
    • 完美适配： 专门针对 Agentic AI 工具进行了优化，确保 AI 生成的代码能精准还原特定的视觉风格。

    使用场景：
    当你使用 AI 开发网页或应用时，只需喂入这些预设的“技能文件”，AI 就能跳出默认的 Bootstrap 或 Tailwind 风格，构建出极具辨识度的视觉界面。

    原文链接：https://www.typeui.sh/design-skills

    #AI设计 #前端开发 #TypeUI #UI设计 #AI工具

    AI设计前端开发TypeUIUI设计AI工具

  13. 面条的草稿箱

    让 AI 像顶级设计师一样编程：GetDesign.md 设计规范库如果你正在使用 AI 助手（如 Cursor、Claude 或 Bolt）进行前端开发，那么这个网站值得加入收藏夹

    让 AI 像顶级设计师一样编程：GetDesign.md 设计规范库

    如果你正在使用 AI 助手（如 Cursor、Claude 或 Bolt）进行前端开发，那么这个网站值得加入收藏夹。GetDesign.md 汇集了包括 Apple、Stripe、Linear、Notion 以及 SpaceX 在内的 60 多种知名品牌的设计系统灵感。

    它的核心价值在于“AI 友好”：你可以直接将这些精炼的 DESIGN.md 文件丢给 AI 编程助手，AI 就能迅速理解其设计语言、配色方案和排版逻辑，从而帮你构建出风格统一、质感高级的 UI 界面。

    无论你是想要打造极简的工具软件，还是具有视觉冲击力的官网，这里都是一个绝佳的 UI 风格武器库。

    https://getdesign.md/

    #设计系统 #AI工具 #前端开发 #UI设计 #生产力工具
    getdesign.md
    getdesign.md — DESIGN.md collection for AI coding agents
    getdesign.md — DESIGN.md collection for AI coding agents
    Browse independent design system analyses from popular websites. Drop one into your project as design reference for your coding agent.

    设计系统AI工具前端开发UI设计生产力工具

  14. 面条的草稿箱

    Linear 发布 Agent 交互指南（AIG）：定义人机协作的新契约AI Agent 正在重塑软件的规划、构建、审查和部署方式

    Linear 发布 Agent 交互指南（AIG）：定义人机协作的新契约

    AI Agent 正在重塑软件的规划、构建、审查和部署方式。当 Agent 大量产出工作成果时，人类的角色也随之转变——价值重心转移到编排输入、构建上下文和审查输出上。

    这种转变需要一套全新的人机交互契约。Linear 提出了 Agent Interaction Guidelines（AIG），为设计更自然融入人类工作流的 Agent 交互制定了基础原则。

    六大核心原则

    1. Agent 必须表明身份
    当人类与 Agent 协同工作时，Agent 必须清晰标识自己的身份，绝不能被误认为是真人。

    2. Agent 应原生融入平台
    Agent 应通过平台已有的 UI 模式和标准操作来工作，而非另起炉灶。

    3. Agent 应即时反馈
    沉默会带来不确定性。Agent 被调用后应立即提供反馈（如"思考中"指示器），让用户知道请求已被接收。

    4. Agent 应透明展示内部状态
    无论是思考、等待输入、执行还是完成，Agent 都应清晰展示当前状态。用户可以随时检视其推理过程、工具调用和决策逻辑。

    5. Agent 应尊重退出指令
    当被要求停止时，Agent 必须立即退出，且只有收到明确信号后才能重新介入。

    6. Agent 不能承担最终责任
    Agent 可以执行任务，但最终责任始终归属于人类。需要建立清晰的人机委托模型。

    ---

    AIG 是一份持续演进的开放文档，Linear 邀请社区共同参与完善。

    🔗 https://linear.app/developers/aig

    #AI_Agent #人机交互 #Linear #设计原则 #AIG
    linear.app
    Agent Interaction Guidelines (AIG) – Linear Developers
    Agent Interaction Guidelines (AIG) – Linear Developers
    Foundational principles and practices for designing agent interactions that integrate more naturally into human workflows.

    AI_Agent人机交互Linear设计原则AIG

  15. 面条的草稿箱

    AI 时代怎么招工程师：Augment 的「AI-native」人才标准当 AI agent 能写出大部分代码后，工程师的价值开始上移：不再以“写得快、写得多”为核心，而是以判断力、系统设计与协同能力决定产出质量

    AI 时代怎么招工程师：Augment 的「AI-native」人才标准

    当 AI agent 能写出大部分代码后，工程师的价值开始上移：不再以“写得快、写得多”为核心，而是以判断力、系统设计与协同能力决定产出质量。

    Augment 重新梳理了面向 AI-native（与 AI 共同工作）团队的招聘标准，核心变化可以概括为一句话：人从“作者”变成“架构师与编辑”——定义意图、做取舍、设护栏、把好质量关。

    工程师工作重心的迁移

    • 传统工程：写代码、实现方案、解决问题、看个人产出
    • AI-native 工程：明确意图与权衡、编排 agent、选择正确问题、看系统级结果

    他们认为最重要的 6 个能力维度

    1. 产品与结果品味（Product & Outcome Taste）：能否在代码变“更便宜”时，避免做出“最贵的错误”——把方向做错。
    2. 系统与架构判断（System & Architectural Judgment）：代码能跑不难，难的是“能在生产环境长期稳定地跑”。
    3. Agent 杠杆（Agent Leverage）：能否把 AI 变成真实吞吐量：拆解任务、引导偏航、验证结果（agent 很快，但也可能自信地出错）。
    4. 沟通与协作（Communication & Collaboration）：实现更快后，“达成清晰”更关键；要能把意图讲清楚、促成共识。
    5. 主人翁意识与领导力（Ownership & Leadership）：对结果负责而非只做任务；主动清除阻碍交付的障碍。
    6. 学习速度与实验心态（Learning Velocity & Experimental Mindset）：工具三个月就变一轮，持续实验与快速迭代成为工作常态。

    一个显著的信号是：“纯粹的编码能力”不再是最主要的区分项——依然重要，但不再决定上限。

    从理念到招聘：看“可观察信号”

    他们强调，框架必须能落到面试里，转成可评估的行为证据，例如：

    • 能否快速澄清模糊问题、定义清晰目标？
    • 能否提前识别架构风险，而不是上线后救火？
    • 能否有效指挥并验证 AI 生成的工作？

    未来重点招的 4 类画像

    • AI-native 系统工程师：基础设施与架构判断强，保证“地基”稳。
    • AI-native 产品工程师：产品品味与用户理解强，确保“做对事”。
    • AI-native 应用 AI 工程师：懂模型与应用构建，提升 agent 能力与工作流。
    • AI-native 早期工程师（Early Professional）：学习速度优先，快速适应工具与流程变化。

    这套标准也不只用于招聘，还会反向影响绩效、成长与职业发展：如果真正重视判断力、杠杆与学习速度，就应该在各个环节都体现出来。

    原文链接：https://www.augmentcode.com/blog/how-we-hire-ai-native-engineers-now

    #AI招聘 #工程师能力 #AI代理 #架构设计 #学习型组织
    Augmentcode
    How we hire AI-native engineers now: our criteria
    How we hire AI-native engineers now: our criteria
    The most powerful AI software development platform with the industry-leading context engine.

    AI招聘工程师能力AI代理架构设计学习型组织

  16. 面条的草稿箱

    OpenClaw 正式亮相：把 AI 助手带到你常用的聊天软件里OpenClaw 宣布品牌更名，并明确了项目定位：一个运行在你自己的机器上的开源 Agent 平台，可从你日常使用的聊天应用直接调用（WhatsApp、Telegram、Discord、Slack、Teams 等），让 AI 助手“跟着你走”

    OpenClaw 正式亮相：把 AI 助手带到你常用的聊天软件里

    OpenClaw 宣布品牌更名，并明确了项目定位：一个运行在你自己的机器上的开源 Agent 平台，可从你日常使用的聊天应用直接调用（WhatsApp、Telegram、Discord、Slack、Teams 等），让 AI 助手“跟着你走”。

    为什么改名：从 Clawd / Moltbot 到 OpenClaw

    团队经历了多次命名迭代：

    • Clawd：好记但涉及商标/法务问题，被建议更换
    • Moltbot：寓意“蜕壳成长”，但不够顺口
    • OpenClaw：已完成商标检索、域名与迁移准备，强调两点：
    • Open：开源、开放、社区驱动
    • Claw：延续“龙虾”项目起源与文化

    OpenClaw 是什么：你的助手，你的规则

    核心主张很直接：Your assistant. Your machine. Your rules.
    不同于把数据放在第三方服务器上的 SaaS 助手，OpenClaw 允许你把系统跑在本地电脑、家用服务器或 VPS 上：基础设施你掌控、密钥你掌控、数据也由你掌控。

    本次发布更新亮点

    随更名一起上线的更新包括：

    • 新渠道：新增 Twitch、Google Chat 插件
    • 模型支持：新增 KIMI K2.5、Xiaomi MiMo-V2-Flash
    • Web Chat：支持像聊天软件一样发送图片
    • 安全加固：累计 34 个与安全相关的提交，并发布可机器验证的安全模型；同时提醒 prompt injection 仍是行业难题，建议参考安全最佳实践

    接下来：安全优先 + 维护体系建设

    团队表示下一阶段会继续把安全作为最高优先级，同时提升网关稳定性、体验打磨，并扩展更多模型与提供商支持。由于项目增长迅猛，也在引入更多维护者并建立流程，鼓励社区参与贡献或赞助维护工作。

    原链接：https://openclaw.ai/blog/introducing-openclaw

    #开源 #AI代理 #隐私安全 #自托管 #聊天机器人
    openclaw.ai
    Introducing OpenClaw - OpenClaw Blog
    Introducing OpenClaw - OpenClaw Blog
    The journey from Clawd to Moltbot to OpenClaw—and why this name is here to stay.

    开源AI代理隐私安全自托管聊天机器人

  17. 面条的草稿箱

    AgentFS：为 AI Agent 设计的“可审计”文件系统AgentFS 是 Turso 团队开源的 面向 AI Agent 的文件系统：不仅能像传统文件系统一样读写文件/目录，还把 Agent 的状态与行为记录成可查询、可快照的结构化数据，便于调试与复盘

    AgentFS：为 AI Agent 设计的“可审计”文件系统

    AgentFS 是 Turso 团队开源的 面向 AI Agent 的文件系统：不仅能像传统文件系统一样读写文件/目录，还把 Agent 的状态与行为记录成可查询、可快照的结构化数据，便于调试与复盘。

    它解决什么问题？

    • 可审计：每一次文件操作、工具调用、状态变更都会写入同一个 SQLite 数据库，可直接用 SQL 追踪“发生了什么”。
    • 可复现：一个 .db 文件就是完整运行态，支持复制/快照/回滚，用来复现某次执行或做 what-if 实验。
    • 可迁移：所有内容都封装在单个 SQLite 文件里，易于移动、备份，甚至纳入版本管理。

    包含哪些组件？

    • SDK：TypeScript / Python / Rust（程序化访问文件系统、KV、工具调用记录）。
    • CLI：初始化与管理 AgentFS；在 Linux 用 FUSE、macOS 用 NFS 挂载到本机目录；也可在沙箱里把它挂载到 /agent。
    • 规范：提供基于 SQLite 的 Agent 文件系统规格（SPEC）。

    使用提醒

    • 官方标注为 ALPHA 阶段：更适合开发、测试与实验环境，关键数据请谨慎上生产。

    原链接：https://github.com/tursodatabase/agentfs
    #AI代理 #文件系统 #SQLite #可审计 #开发工具
    GitHub
    GitHub - tursodatabase/agentfs: The filesystem for agents.
    GitHub - tursodatabase/agentfs: The filesystem for agents.
    The filesystem for agents. Contribute to tursodatabase/agentfs development by creating an account on GitHub.

    AI代理文件系统SQLite可审计开发工具

  18. 面条的草稿箱

    CoreSpeed：为 AI Agent 打造的容器运行时基础设施CoreSpeed 主打把「Agent 运行」这件事做成开箱即用的基础设施：你可以像部署普通容器一样部署 AI Agent，并获得更快启动、更强隔离和更易扩展的体验

    CoreSpeed：为 AI Agent 打造的容器运行时基础设施

    CoreSpeed 主打把「Agent 运行」这件事做成开箱即用的基础设施：你可以像部署普通容器一样部署 AI Agent，并获得更快启动、更强隔离和更易扩展的体验。

    它解决的核心问题：把 Agent 从 Demo 变成可上线的系统。

    关键能力一览

    • 127ms 级别快速启动：通过内置 Warm Pool，让容器接近“秒开/毫秒开”，减少冷启动等待。
    • 按用户隔离的安全沙箱：一人一容器，降低数据串扰与安全风险。
    • 无限水平扩展 + 可缩到 0：按需分配资源，空闲可降到零成本运行。
    • AI & MCP Gateway：统一接入 AI 模型与 MCP Server，提供可观测性与安全防护（例如减少 API Key 泄露风险），并支持按调用计费。

    配套：Zypher（TypeScript Agent Runtime）

    同时他们提供 Zypher SDK，强调：

    • 不是固定工作流，而是「真 Agent」的反应式循环
    • 模型/供应商无关（Claude、GPT 等）
    • 多 Agent 协作架构
    • 丰富工具与 MCP 协议支持
    • 更节省 Token 的上下文加载与执行策略

    原文链接：https://www.corespeed.io/

    #AI代理 #容器基础设施 #MCP #AgentRuntime #开发者工具
    www.corespeed.io
    CoreSpeed — Your AI agent is smart. Now give it access.
    CoreSpeed — Your AI agent is smart. Now give it access.
    CoreSpeed connects your AI agent to the apps you use, adds built-in tools and memory, and lets you control what it can do — in one setup, with any agent. No per-service API applications.

    AI代理容器基础设施MCPAgentRuntime开发者工具

  19. 面条的草稿箱

    以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策

    以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型

    这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策。

    作者回顾了今年的变化：从最初“有些提示能一次跑通就很惊喜”，到现在“默认就该一次跑通”。在这种前提下，他甚至不再逐行读代码，而是看执行/修改流，关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

    文章也给了不少可复用的工作方法：

    • 先从 CLI 做起：任何产品先做命令行版本，方便代理直接运行验证，形成闭环；核心逻辑稳了再上 UI（比如扩展、App）。
    • 关键决策是生态与依赖：语言/框架/依赖选对了，代理更容易一次完成；作者常用 TypeScript（Web）、Go（CLI）、Swift（macOS/iOS）。
    • 更偏向“对话式协作”，而不是复杂流程：先和模型聊清楚、让它探索代码、共创方案，满意后再让它开干；他认为“Plan mode”更像旧时代不得已的手段。
    • 对比 codex 与 Opus：codex 常会先长时间读代码再动手，虽然更慢但更稳，尤其适合大型功能和重构；Opus 更“急”，适合小改动但更容易漏上下文。
    • 迭代式构建，不依赖回滚：不喜欢 checkpoint/频繁 revert，更多是让模型继续改、继续朝更好的方向“绕山而上”。
    • 自动化与多项目并行：同时推进多个项目，用队列把想法排进去；瓶颈往往是人而不是编排系统。
    • 配置思路：提高工具输出 token 上限、合理设置自动压缩阈值，让模型能一次读更多文件；作者强调新压缩机制更可靠，甚至像一次“复查”。

    如果用一句话总结：当“写代码”越来越像可并行外包给代理的体力活，工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上；而真正影响交付速度的，往往是推理等待时间和你是否想清楚要做什么。

    原链接：https://steipete.me/posts/2025/shipping-at-inference-speed
    #AI编程 #Codex #开发工作流 #效率工具 #软件工程
    steipete.me
    Shipping at Inference-Speed | Peter Steinberger
    Shipping at Inference-Speed | Peter Steinberger
    Why I stopped reading code and started watching it stream by.

    AI编程Codex开发工作流效率工具软件工程

  20. 面条的草稿箱

    Agent-native 应用：把“功能”变成“结果”这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”

    Agent-native 应用：把“功能”变成“结果”

    这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”。核心在于：让代理拥有与用户同等的操作能力（UI 能做的，代理也能通过工具做到），并把工具设计成足够原子化的“积木”。这样，新功能往往不再是写代码，而是写一段描述结果的提示词；同时，用户提出的意外需求会推动系统“涌现”出新用法，并反过来指导你补齐工具与能力缺口。

    五个核心原则

    • 对等（Parity）：任何 UI 动作，代理都应能通过工具实现同样的结果；否则代理会卡死。
    • 粒度（Granularity）：工具是原子能力；“功能”是代理在循环中用工具达成的结果。改行为优先改提示词，而不是重构代码。
    • 可组合（Composability）：有了原子工具 + 对等能力，就能通过新提示词快速拼出新“功能”（开发者/用户都能做）。
    • 涌现能力（Emergent capability）：用户会提你没设计过的需求；代理若能组合工具完成，就是新机会；若失败，则暴露工具缺口。
    • 持续变好（Improvement over time）：通过沉淀上下文（context 文件）与迭代提示词，应用可在不发版的情况下持续变强。

    落地方法（把原则变成工程实践）

    • 先做“能力地图”：列出用户能做的事，逐项确认代理具备创建/读取/更新/删除（CRUD）能力，避免“能新建不能修改/删除”的断腿体验。
    • 先原语、后领域工具：先用文件、bash、读写等基础工具跑通；再为高频模式加领域工具，用于效率、校验、术语锚定，但不要把“判断”写进工具里。
    • 文件作为通用接口：文件天然可读、可审计、可迁移，代理也最擅长操作；内容放文件、结构化高频数据放数据库（或混合：文件作可读真相，DB 做索引与性能）。
    • 明确完成信号：不要靠“看起来差不多了”判断结束；让工具/编排层返回明确的 complete 信号，避免无限循环或半成品。
    • 透明的代理行为：工具调用、进度、状态变化要让 UI 可见；“沉默的代理”会让用户觉得坏了。
    • 把“授权”做成产品能力：根据风险与可逆性决定自动执行还是强确认；尤其是发送邮件、发布内容等高风险动作。

    对移动端的启示

    • 移动应用容易被后台杀死，代理任务却可能很长：需要checkpoint/恢复机制，尽可能在每次工具结果后存档。
    • iCloud 之类的文件同步能让多设备共享“同一工作区”，但要处理冲突与未下载文件等边界。

    原链接：https://every.to/guides/agent-native

    #AgentNative #软件代理 #AI产品 #工具调用 #产品架构
    every.to
    Agent-native Architectures
    Agent-native Architectures
    A technical guide for building applications where agents are first-class citizens

    AgentNative软件代理AI产品工具调用产品架构

1px