AI生图 | 面条的草稿箱

代码不再是瓶颈：Anthropic 发布的「AI 原生软件工程（SDLC）实战手册」随着 Claude Code 等 Agent 编码工具的普及，编写代码的时间被大幅压缩至数小时

Wed, 26 Aug 2026 12:22:24 GMT

代码不再是瓶颈：Anthropic 发布的「AI 原生软件工程（SDLC）实战手册」

随着 Claude Code 等 Agent 编码工具的普及，编写代码的时间被大幅压缩至数小时。然而，传统的软件开发生命周期（SDLC）仍按“人类速度”运行——繁复的需求对齐、人工逐行 Code Review 和层层审批，反而成为了团队新的生产力瓶颈。

Anthropic 官方近期梳理了一套完整的 AI-Native SDLC 转型框架，将传统的线性研发流程重构为以 Markdown 产物驱动的自治闭环：

---

🔄 六大阶段的关键演进

1. 规划（Plan）｜意图即代码
• 告别漫长繁琐的 PRD 编写，业务人员通过与 Claude 头脑风暴直接生成 intent.md（意图文件）。
• 机器可读、人类可审，提交至 Git 即可直接驱动下一阶段。

2. 设计（Design）｜需求与设计合二为一
• 结合团队沉淀的规范库（Skills），Claude 基于 intent.md 快速产出 spec.md。
• 安全、合规与 UX 约束在生成设计时即刻生效，而非等到几周后的评审会议才被发现。

3. 构建（Build）｜计划驱动与组织记忆
• Plan Mode：必须先生成并确认 plan.md 才能落代码，杜绝 Agent 盲目编码。
• 团队记忆库：通过 CLAUDE.md 和 Skills 固化团队规约；借助 Hooks 建立不可逾越的确定性防线。
• 并行作战：配合 Git Worktree 和专有子 Agent（Subagents），单名工程师可同时调度多个任务。

4. 测试（Test）｜让 AI 自查自纠
• 反馈闭环：为 Agent 配备自动化测试与 UI 视觉对比工具，要求“跑通测试才算 Done”，并禁止 AI 擅自修改测试用例以掩盖 Bug。
• Continuous Evals：在 CI 中引入 Agent 评估套件，像测代码一样回归测试提示词与配置。

5. 部署（Deploy）｜双向审查与严格卡点
• AI 参与 PR 自动化多维度评审，并支持直接根据 @claude 评论修复代码；人类工程师重点聚焦于“业务意图”与“系统风险”。
• 生产门禁：AI 的自主权终止于生产部署关卡，核心发布动作仍由 Hooks 拦截并等待人工最终授权。

6. 运维（Maintain）｜自主闭环的起点
• 当监控指标（如 CI 失败率、5xx 错误）出现统计学异常时，自动化脚本唤醒 Claude 进行故障诊断并生成修复 PR 或新的 intent.md。
• 结合即时通讯工具（Claude Tag），实现告警自动排查、知识沉淀与自主闭环。

---

核心总结：AI 原生 SDLC 的本质，是把研发流程从“人写代码、人走流程”，升级为“AI 负责闭环执行、人类把控关键治理与评判”的全新协作范式。

🔗 原文链接：https://claude.com/blog/the-ai-native-sdlc-playbook

#AI开发 #SDLC #ClaudeCode #软件工程 #人工智能

Claude

The AI-Native SDLC playbook | Claude by Anthropic

Anthropic's stage-by-stage playbook for the AI-native SDLC: how teams plan, design, build, test, deploy, and maintain software with Claude.

让 AI 也能做出极简可爱的吉祥物：IP as Logo Skill为产品设计一个辨识度高、圆润可爱的 IP Logo 往往需要多次打磨

Sat, 22 Aug 2026 05:55:27 GMT

让 AI 也能做出极简可爱的吉祥物：IP as Logo Skill

为产品设计一个辨识度高、圆润可爱的 IP Logo 往往需要多次打磨。开源项目 ip-as-logo-skill 为具备生图能力的 AI Agent 提供了一套结构化的设计规范，帮助你一键生成可以直接商用的极简 IP 角色。

🌟 核心亮点

• 严控设计复杂度：遵循极简与微拟物（Neo-skeuomorphism）美学，主体由 4~7 个基础圆形几何构成，默认采用「2 种 IP 主色 + 1 种纯色背景」的三色搭配。
• 精心调校的构图：角色默认从左下角或右下角探出并占据画面 85%~95%，避免传统居中构图的呆板感。
• 标准化的生图流程：Agent 会先梳理产品背景并提供 3 种设计方向，确认后一次性生成 6 张不同构图的独立高清候选图，无需繁琐调试提示词。
• 纯净的 Prompt 策略：提示词专注描述画面视觉元素，不包含 “logo/icon” 等干扰词，充分释放图像模型的生成质感。

🛠️ 兼容性与安装

支持 Codex、豆包、Coze、Manus、YouMind、Gemini Apps、Replit Agent 等支持图像资产输出的 Agent 环境。

通过 Agent Skills CLI 一键安装：

npx skills@latest add s1dashu/ip-as-logo-skill

项目采用 MIT 协议开源，生成内容均可免费商用。此外，作者还提供了免费的在线图库 ipaslogo.com，无需配置即可直接下载现成素材。

🔗 项目地址：https://github.com/s1dashu/ip-as-logo-skill

#开源项目 #AIAgent #Logo设计 #AI生图 #设计工具

Ipaslogo

IP as Logo Skill

Browse and download free mascot logos made with IP as Logo Skill.

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

Sun, 28 Jun 2026 07:23:27 GMT

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

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…

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

Mon, 15 Jun 2026 15:52:13 GMT

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

Subagents, plan mode, LSP, DAP, hindsight memory, hashline edits, time-traveling rules — with a native Rust engine doing the heavy lifting.

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

Fri, 13 Mar 2026 00:13:36 GMT

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

The most powerful AI software development platform with the industry-leading context engine.

Claude Opus 4.5：让“能做”突然变得很容易作者分享了一个明显的转折：三个月前他还不相信“AI 代理能替代开发者”，但在体验 Claude Opus 4.5 后，他开始认为这件事正在发生——至少在相当一部分软件开发场景里

Mon, 12 Jan 2026 09:21:00 GMT

Claude Opus 4.5：让“能做”突然变得很容易

作者分享了一个明显的转折：三个月前他还不相信“AI 代理能替代开发者”，但在体验 Claude Opus 4.5 后，他开始认为这件事正在发生——至少在相当一部分软件开发场景里。

他用几个真实项目说明差异不在“会写代码”，而在于一次成功率、能自我迭代、能把复杂系统拼起来：

• Windows 右键图片格式转换工具：从文件资源管理器菜单到打包、安装/卸载脚本、发布网站、GitHub Actions 自动发布，整体接近“一次成型”。遇到报错会自己用 dotnet 构建、读错误、再修复。
• 录屏与简单剪辑工具：从类似 LICEcap 的录制开始，持续加到视频/图片编辑、裁剪、模糊、标注等功能，作者感叹“几小时就推进到很远”。
• AI 发帖工具（给小生意用）：iOS 端批量上传照片→AI 生成文案→定时发到 Facebook。后端涉及认证、存储、云函数、日志排错等一堆“胶水活”，但模型能通过 CLI 自己创建资源、查日志并修问题，还顺手做了管理后台。
• 订单与路线追踪：解析 Gmail 订单、规划路线、统计行驶时间（用于税务），作者强调：这种“手写很痛苦”的 Google/Firebase 集成，Opus 4.5 反而很顺。

文章也没有回避争议点：
作者承认自己并不完全理解这些应用“内部怎么搭起来的”（比如 Swift 不熟），但他的焦虑在减轻——因为当问题出现时，模型往往能定位并修复自己的 bug。于是他提出一个更激进的想法：代码也许不必主要面向人类可读，而是面向 LLM 可推理、可重写、可调试。

他甚至分享了一份自用的“AI-first 编码”提示词要点（概念层面）：

• 追求可预测、可调试、低耦合、入口清晰、控制流线性
• 少炫技抽象，减少层级与间接性
• 该删就删；重构也要分高/中/低优先级
• 安全需要更谨慎：API key、登录流程、敏感数据存储等不能盲信

结尾的态度是复杂的：既兴奋于“几小时能做出过去要几周/月的东西”，也沮丧于技能壁垒被压平。但他给出的建议很朴素：别等“都懂了”再开始，继续做东西，只是更快了；同时一定盯紧安全与密钥。

原文链接：https://burkeholland.github.io/posts/opus-4-5-change-everything/

#AI编程 #开发者工具 #Claude #软件工程 #生产力

Burke Holland

Opus 4.5 is going to change everything

Three months ago I would have dismissed claims that AI could replace developers. Today, after using Claude Opus 4.5, I believe AI coding agents can absolutely replace developers.

Beyond Vibe Coding：AI 辅助开发完整指南Google 工程负责人 Addy Osmani 发布了一份全面的 AI 辅助开发指南，帮助开发者从"氛围编程"迈向生产级工程实践

Tue, 09 Dec 2025 15:10:26 GMT

Beyond Vibe Coding：AI 辅助开发完整指南

Google 工程负责人 Addy Osmani 发布了一份全面的 AI 辅助开发指南，帮助开发者从"氛围编程"迈向生产级工程实践。

核心观点

70% 问题：AI 能快速完成 70% 的功能原型，但剩余 30% 需要深厚的工程知识。修一个 bug 可能引入新问题，安全漏洞风险也不容忽视。

AI 开发光谱

• 自动补全：预测下一行代码
• 聊天机器人：自然语言问答
• 智能代理：自主处理多步骤任务

关键最佳实践

1️⃣ 先规划，后编码：让 AI 先提供架构方案，而非直接生成代码
2️⃣ 上下文为王：提供相关代码、设计文档、错误信息
3️⃣ 视觉辅助：截图胜过千言万语
4️⃣ 每次改动后测试：小步快跑，避免调试噩梦
5️⃣ 清晰描述意图：说明你想实现什么，而非仅描述表面症状

进阶技巧

• 提示工程：分解复杂任务、提供输入输出示例、善用角色扮演
• 上下文工程：像操作系统管理内存一样动态组装信息
• CLI 代理：Claude Code、Gemini CLI 等工具让终端成为强大的开发环境
• 多代理协作：不同专业代理并行处理任务

生产就绪原则

⚠️ 始终审查 AI 生成的代码——像审查初级开发者的代码一样
🔒 安全第一：输入验证、凭证管理、SQL 注入防护

未来的模型只会越来越强大。今天学会与 AI 协作，就是在为明天的工程实践做准备。

🔗 原文链接

#AI辅助开发 #VibeCoding #提示工程 #软件工程 #AddyOsmani

beyond.addy.ie

Beyond Vibe Coding - A Guide To AI-Assisted Development

Transform your development workflow with AI. Learn from Google Chrome's Engineering Leader how to master AI-assisted development and build better software.

规范驱动开发（SDD）的局限性随着 AI 编程的兴起，一种旧模式正在回归：编写详细的规范文档（Spec），然后期望 AI 能稳定地生成“正确”的代码

Thu, 04 Dec 2025 01:43:23 GMT

规范驱动开发（SDD）的局限性

随着 AI 编程的兴起，一种旧模式正在回归：编写详细的规范文档（Spec），然后期望 AI 能稳定地生成“正确”的代码。然而，这种规范驱动开发（Spec-Driven Development, SDD）在实践中往往会碰壁，原因与当年瀑布流开发模式失败类似——现实的变化总比规范文档快。

为什么规范驱动开发会失败？

1️⃣ 维护成本高昂

编写详尽的规范耗时巨大，而且在需求变更、约束调整时，保持规范与代码同步会产生巨大的维护成本，有时甚至会加倍工作量。

2️⃣ 规范无法反映所有上下文

规范描述了系统“做什么”，却无法解释“为什么”这么做。而“为什么”恰恰承载了关键背景信息，如技术权衡、团队在迭代中的学习、以及塑造解决方案的现实约束。

3️⃣ 过度规范化造成虚假的安全感

一份详细的规范会给人一种“一切尽在掌握”的错觉，但这往往是虚假的。软件开发是一个探索性过程，最重要的洞见往往在构建开始后才会出现。

4️⃣ 抽象层次错误

多数 SDD 工具关注的是实现的细节（“如何做”），比如字段定义、函数签名等，但更重要的是其背后的意图、约束和上下文（“为什么做”）。

什么才是真正重要的？—— 上下文工程

文章认为，AI 编程缺失的不是更详细的规范，而是更完善的上下文保留。AI 原生的开发流程应该：

• 从意图出发，明确要解决的问题和核心约束。
• 保持上下文的实时更新，让团队与 AI 保持同步。
• 让规范跟随代码库，成为动态演进的文档。
• 保留决策背后的“为什么”，而不仅仅是需求。

总而言之，对于需求稳定、边界清晰的领域，SDD 是有效的。但对于不断演化的探索性开发，上下文驱动的方法能更好地适应变化。

原文链接：https://isoform.ai/blog/the-limits-of-spec-driven-development

#AI #软件开发 #编程 #规范驱动开发

isoform.ai

The Limits of Spec-Driven Development - Isoform

We enable private equity firms and mid-market companies to build bespoke AI products 5x faster. Services include AI feature shipping, AI-led integration, data migration, and legacy system modernization.

PostHog AI: 开发 AI 智能体一年后总结的 8 个教训PostHog 团队在开发其内置 AI 智能体 PostHog AI 的一年中，积累了丰富的实践经验

Thu, 04 Dec 2025 00:33:30 GMT

PostHog AI: 开发 AI 智能体一年后总结的 8 个教训

PostHog 团队在开发其内置 AI 智能体 PostHog AI 的一年中，积累了丰富的实践经验。从一个简单的聊天原型到一个能处理复杂分析任务的智能助手，他们总结了以下 8 个核心教训：

1. 模型升级是推土机
AI 模型的持续进步是开发中最强大的变量。曾经复杂的问题，如多步推理和工具调用，随着模型能力的提升而变得简单。密切关注模型发展至关重要.

2. 循环智能体优于固定工作流
相较于图表式的固定工作流，单一的循环智能体（Agent）更为灵活和强大。它能在执行任务中自我纠正，避免了工作流中常见的上下文丢失问题.

3. 单一循环胜过子智能体架构
复杂的子智能体架构听起来很智能，但在实践中容易因层层抽象而丢失关键信息，导致性能下降。一个简单、扁平的 LLM 循环反而能涌现出惊人的能力.

4. “待办事项”是超能力
让 LLM 在每一步操作后都使用一个简单的 `todo_write` 工具来规划下一步，这种看似简单的机制能有效帮助模型在复杂任务中保持专注和连贯性.

5. 上下文是关键
用户输入往往是模糊的，AI 需要广泛的背景知识才能准确理解. PostHog AI 通过 `/init` 命令自动学习项目信息，为智能体提供核心上下文，从而显著提升任务成功率.

6. 展示每一步，建立信任
透明度是建立用户信任的基石. 与其隐藏过程，不如将智能体的思考、工具调用甚至失败的尝试全部展示给用户. 这比一个完美的“黑箱”更能赢得信赖.

7. 警惕 AI 框架的陷阱
在 AI 技术飞速发展的今天，LangChain 等高级框架可能会过早地锁定技术选型. 在生态系统稳定之前，坚持使用更底层的库可能是更明智的选择.

8. 评估(Evals)并非全部
自动化评估很有价值，但无法替代对真实用户行为的分析. 通过观察实际使用中的 LLM 轨迹 (Traces)，团队能发现评估中无法覆盖的、更深刻的问题.

总而言之，构建高效的 AI 智能体需要拥抱变化、简化架构、重视上下文和透明度，并始终立足于真实的用户场景.

原文链接: PostHog Blog

#AI #Agent #LLM #工程实践 #PostHog

Posthog

8 learnings from 1 year of agents – PostHog AI - PostHog

Today we launch PostHog AI, the AI agent built into PostHog . A year in the making, we've gone a long way from our first chat prototype made over a…

Mistral AI 发布新一代开源模型 Mistral 3Mistral AI 今日发布了其下一代 AI 模型系列 —— Mistral 3，包含一个前沿的大模型和一系列为边缘计算优化的小模型，全部在 Apache 2.0 许可下开源

Wed, 03 Dec 2025 02:29:55 GMT

Mistral AI 发布新一代开源模型 Mistral 3

Mistral AI 今日发布了其下一代 AI 模型系列 —— Mistral 3，包含一个前沿的大模型和一系列为边缘计算优化的小模型，全部在 Apache 2.0 许可下开源。

Mistral Large 3
一款顶级的稀疏混合专家（MoE）模型，拥有 41B 激活参数和 675B 总参数，性能可与最强的闭源模型相媲美。它在多语言对话和图像理解方面表现出色。

Ministral 3 系列
专为边缘和本地应用设计，提供 3B、8B 和 14B 三种尺寸，实现了卓越的性价比和效率。同样具备多模态和多语言能力。

核心亮点

完全开源：所有模型均采用 Apache 2.0 许可，开发者可自由使用和定制。
多模态与多语言：原生支持文本、图像理解以及超过 40 种语言。
强大生态合作：与 NVIDIA、vLLM 及 Red Hat 紧密合作，提供高效的推理和部署支持。
广泛可用：已登陆 Hugging Face、Amazon Bedrock、Azure 等多个平台。

Mistral 3 的发布进一步推动了开放、透明和可访问的 AI 发展，为开发者和企业提供了更强大的工具。

原文链接：https://mistral.ai/news/mistral-3

#MistralAI #AI #LLM #开源模型 #Mistral3

Mistral AI

Introducing Mistral 3 | Mistral AI

The most powerful AI platform for enterprises. Customize, fine-tune, and deploy AI assistants, autonomous agents, and multimodal AI with open models.

亚马逊发布全新 Nova AI 模型与服务，赋能企业构建专属 AI亚马逊近日扩展了其 Nova AI 产品线，推出了四个强大的 Nova 2 系列基础模型、一项名为 Nova Forge 的模型定制服务，以及一个用于构建可靠 AI 代理（Agent）的 Nova Act 服务. Nova 2 模型家族亮点 • Nova 2 Lite: 经济高效，适用于客户服务、文档处理等日常工作负载. • Nova 2 Pro: 亚马逊最智能的模型，专为高级数学、软件工程等复杂任务设计. • Nova 2 Sonic: 实时语音对话模型，支持多语言和自然交互. • Nova 2 Omni: 业界首创的统一多模态模型，可同时处理文本、图像、视频和语音输入，并生成文本与图像. 两大创新服务 • Nova Forge: 一项 “开放式训练” 服务，允许企业深度融合自有数据，构建专属优化的 Nova 模型. • Nova Act: 用于构建和管理 AI 代理的服务，能高效、可靠地自动执行网页端的操作流程.此次更新旨在为企业提供从高性能基础模型到深度定制和自动化工具的全方位支持，推动 AI 在各行业的规模化应用.原文链接:

Wed, 03 Dec 2025 02:29:42 GMT

亚马逊发布全新 Nova AI 模型与服务，赋能企业构建专属 AI

亚马逊近日扩展了其 Nova AI 产品线，推出了四个强大的 Nova 2 系列基础模型、一项名为 Nova Forge 的模型定制服务，以及一个用于构建可靠 AI 代理（Agent）的 Nova Act 服务.

Nova 2 模型家族亮点

• Nova 2 Lite: 经济高效，适用于客户服务、文档处理等日常工作负载.
• Nova 2 Pro: 亚马逊最智能的模型，专为高级数学、软件工程等复杂任务设计.
• Nova 2 Sonic: 实时语音对话模型，支持多语言和自然交互.
• Nova 2 Omni: 业界首创的统一多模态模型，可同时处理文本、图像、视频和语音输入，并生成文本与图像.

两大创新服务

• Nova Forge: 一项 “开放式训练” 服务，允许企业深度融合自有数据，构建专属优化的 Nova 模型.
• Nova Act: 用于构建和管理 AI 代理的服务，能高效、可靠地自动执行网页端的操作流程.

此次更新旨在为企业提供从高性能基础模型到深度定制和自动化工具的全方位支持，推动 AI 在各行业的规模化应用.

原文链接: https://www.aboutamazon.com/news/aws/aws-agentic-ai-amazon-bedrock-nova-models

#亚马逊 #AWS #AI #大模型 #Nova

Amazon News

Amazon introduces new frontier Nova models, a pioneering Nova Forge service for organizations to build their own models, and Nova…

Key takeaways

如何更好地使用 AI 进行 UI 设计？Lovable 的 Prompt 指南这是一篇关于如何在使用 AI UI 构建工具 Lovable 时，写出更有效 Prompt 的实用指南

Thu, 27 Nov 2025 10:32:54 GMT

如何更好地使用 AI 进行 UI 设计？Lovable 的 Prompt 指南

这是一篇关于如何在使用 AI UI 构建工具 Lovable 时，写出更有效 Prompt 的实用指南。核心思想是通过结构化、系统化的方式与 AI 沟通，从而获得高质量、可控的设计成果。

一个非常有效的技巧是让 AI 主动提问。在你的需求后面加上一句：“为了完全理解我的需求，请向我提问”，这样可以提前澄清细节，避免后期反复修改。

指南将整个过程分为四个阶段：

1. 奠定基础
在动手前先做好规划，明确产品功能、目标用户和核心操作。从一开始就确定好整体的设计风格，是后续所有工作的基础。

2. 系统化思考
不要一次性生成整个页面，而是像搭积木一样，按组件（如导航栏、卡片）进行构建。使用真实内容而非占位符，并使用具体的 UI 术语（按钮、模态框）和风格关键词（如“极简”、“电影感”）来精确传达你的意图。

3. 精确构建
为常用布局创建可复用的 Prompt 模式以提高效率。通过 URL 直接添加图片或视频素材，并善用“编辑”功能进行微调，而不是每次都从头开始。

4. 迭代与发布
在设计阶段就考虑后端逻辑（如用户登录状态），并有意识地对设计进行版本管理，让迭代过程清晰可控。

这套方法论不仅适用于 Lovable，对我们与其他 AI 工具进行高效协作也极具启发。

原文链接：https://docs.lovable.dev/prompting/prompting-one

#AI #提示工程 #UIDesign #Web开发 #Lovable

Lovable Documentation

Prompting best practices - Lovable Documentation

Plan before you prompt, build by component, use real content, and apply design buzzwords to get consistent, high-quality results.