Search: #人工智能

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

    代码不再是瓶颈: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 #软件工程 #人工智能 The AI-Native SDLC playbook | Claude by Anthropic

  2. 从“生成报告”到“解决复杂任务”:Apodex 1.1 正式发布传统的 AI 深度搜索往往以生成一份结构化报告为终点,但科研、金融和法律等领域的真实工作,通常在写完报告后才刚开始——清洗脏数据、选择方法、编写运行代码、根据中间结果调整方案,并保证每项结论都能经得起溯源检验

    从“生成报告”到“解决复杂任务”:Apodex 1.1 正式发布

    传统的 AI 深度搜索往往以生成一份结构化报告为终点,但科研、金融和法律等领域的真实工作,通常在写完报告后才刚开始——清洗脏数据、选择方法、编写运行代码、根据中间结果调整方案,并保证每项结论都能经得起溯源检验。

    针对这一痛点,Apodex 正式推出了 Apodex 1.1,旨在将 AI 从单纯的“问答工具”升级为能够处理长周期、多阶段复杂任务的在线工作台。

    ---

    核心亮点一览

    1. 真实环境下的长链路执行

    不再回避复杂的专业格式(CSV、PDF、分子结构等)。模型在真实的文件与代码环境中运行,自主处理异常并完成端到端的数据分析与交付。

    2. 支持运行中随时介入(Human-in-the-loop)

    复杂任务难免需要中途调整。Apodex 1.1 允许用户在任务执行的任意阶段添加新需求或新数据,系统会自动保留有效的中间产物并重新规划后续路径,无需从头再来。

    3. 任务分解与执行状态全透明

    拒绝黑盒等待。基于底层 AgentOS,系统会实时展示当前的执行计划、完成步骤、生成的产物与异常重试情况,让长耗时任务清晰可控。

    4. 自主异步多智能体团队(Agent Team)

    在 Deep Discover 模式下,模型会自主将复杂任务拆解并分发给多个子智能体并行探索。中间结果实时回流至主任务,大幅缩短复杂探索的等待耗时。

    5. 关键结论独立审查(Statement Review)

    将“内容生成”与“结论审核”解耦。针对数据推论、文献引用和计算结果进行独立的交叉校验与证据链追溯,显著降低幻觉风险。

    6. 开源支持与端侧部署

    除了网页端完整版,团队还推出了可本地部署的 35B Apodex 1.1 Mini,并开源了开箱即用的终端智能体框架 FrontierAgent(支持 macOS / Linux 单命令运行)。

    ---

    🔗 原文链接:https://www.apodex.com/blog/apodex-1.1-scaling-agentic-intelligence-for-complex-work

    #人工智能 #AI智能体 #Apodex #大语言模型 #深度研究 Apodex | Self-Evolving Heavy-Duty Solver

  3. 别再死磕终端界面了:AI 时代,我们该重新拥抱原生 GUI长久以来,开发者群体对终端(CLI)与终端图形界面(TUI)有着近乎执念的情怀

    别再死磕终端界面了:AI 时代,我们该重新拥抱原生 GUI

    长久以来,开发者群体对终端(CLI)与终端图形界面(TUI)有着近乎执念的情怀。我们习惯了用 ASCII 字符画窗口,忍受终端里生硬的滚动、选词和无障碍支持。但资深安全研究员与开发者 Thomas Ptacek 近日撰文直言:是时候停止编写新的 TUI,全面转向原生图形界面(Native GUI)了。

    为什么我们曾执着于 TUI?

    作者指出,CLI(命令行接口)具备不可替代的组合能力,永远不会过时;但 TUI(终端用户界面,如借助 Curses、Ratatui 等构建的字符界面)本质上是 70 年代哑终端与调制解调器时代的产物。开发者之所以青睐 TUI,往往不是因为终端天生更优越,而是过去开发原生 GUI 的学习成本和琐碎代码实在令人望而却步。

    在终端里,开发者需要费尽心思去模拟原生控件早已完美实现的基础特性:平滑滚动、拖放交互、多窗口浮动、图片渲染以及无障碍(a11y)支持。

    AI 彻底打破了原生 GUI 的门槛

    以往编写 SwiftUI、GTK 或 WinUI 需要掌握大量繁重的平台细节,但现在通过 Claude、Codex 等 AI Agent,构建原生界面的难度被降到了极低:

    • 作者在几乎没有手写 UI 代码的情况下,快速“召唤”出了一批自用原生 Mac 工具:Markdown 渲染器、SageMath 公式计算器、基于 SQLite 的 AI 音乐播放器、状态栏遥控器等。
    • 原生框架天生具备一致的设计语言、流畅的交互与完善的语义无障碍树,开发体验与最终成品质量远胜在终端中“打补丁”。

    驳斥几个常见的 TUI 迷思

    1. “TUI 信息密度高、键盘流效率高”:GUI 同样可以做到极高密度和纯键盘操作(如彭博终端),只是以往少有人专门为 Geek 定制。
    2. “TUI 方便 SSH 远程管理”:生产环境真正需要的是健壮的 CLI,完全可以由本地原生客户端(类似 Emacs TRAMP 的模式)来驱动远程交互。
    3. “TUI 更轻量、跨平台”:如果是为了自己顺手打造的小工具,为兼顾跨平台而牺牲全部交互体验并不划算。

    结语
    AI 正在消除前后端与图形界面的开发鸿沟。如果你依然习惯于把自用工具限制在黑黢黢的终端字符里,不妨尝试让 AI 为你的小脚本生成一个原生 GUI——这很可能会彻底改变你与计算机交互的方式。

    https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/

    #软件开发 #原生应用 #SwiftUI #TUI #人工智能 Stop Making TUIs

  4. 开源模型实现端到端自我提升:Ornith-1.5 正式发布Ornith 正式推出了 Ornith-1.5 模型家族,将此前的“自我脚手架(Self-Scaffolding)”机制拓展为完整的端到端自我进化闭环

    开源模型实现端到端自我提升:Ornith-1.5 正式发布

    Ornith 正式推出了 Ornith-1.5 模型家族,将此前的“自我脚手架(Self-Scaffolding)”机制拓展为完整的端到端自我进化闭环。模型不再单纯依赖人工标注数据,而是能够自主生成新任务、构建评估脚手架,并通过强化学习(GRPO)持续进行自我迭代与能力突破。

    ---

    核心技术亮点:自我驱动的学习闭环

    在每个训练周期中,Ornith-1.5 协同优化三个关键环节:

    1. 自主出题(Task Generation):根据历史解决记录,生成处于能力边界前沿、有效且具有多样性的新挑战。
    2. 构建脚手架(Scaffold Construction):自主设计解题策略、工具链和评估环境,并加入防作弊与对齐奖励机制。
    3. 策略优化(GRPO RL):通过解答方案的反馈,联合优化出题质量、脚手架有效性与模型解题策略,实现能力螺旋上升。

    ---

    三种规格模型与性能表现

    Ornith-1.5 覆盖了大中小三种参数规格,在代码生成、复杂推理与 Agent 任务上均有亮眼表现:

    Ornith-1.5-397B(旗舰 MoE)
    在 Terminal-Bench 2.1 取得 86.1 分,DeepSWE 取得 56.0 分,整体性能比肩 Claude Opus 4.8,并全面超越同体量的开源模型(如 DeepSeek-V4-Flash 与 GLM-5.2)。

    Ornith-1.5-35B(轻量 MoE,单 Token 仅激活 3B)
    在 Agent 编程和代码基准(如 SWE-Bench Verified)上大幅领先同量级对手,甚至显著超越了多款 30B 级别的稠密模型。

    Ornith-1.5-9B(端侧 Dense)
    专为边缘设备优化,提供手机端量化版本(支持 iPhone 与 Android),在紧凑体积下展现出越级打怪的推理与代码能力。

    ---

    🔗 阅读原文https://ornith.ai/ornith_1_5.html

    #人工智能 #开源大模型 #强化学习 #AI编程 Ornith-1.5: From Self-Scaffolding to Self-Improvement

  5. 通俗解读:什么是 AI 时代的「Agent Harness」?业界常用一个极简公式来定义智能体:Agent = Model + Harness

    通俗解读:什么是 AI 时代的「Agent Harness」?

    业界常用一个极简公式来定义智能体:Agent = Model + Harness

    如果把大模型(Model)比作攀登者的核心力量,那么 Harness(原意为登山安全带/挽具) 就是为你提供支撑、挂载工具并确保安全的整套装备。

    在 AI 领域,Agent Harness 是为模型提供运行环境的软件外壳。它主要承担四个核心职能:

    1. 系统提示(System Prompt):像给新员工的工作指引,规范模型在特定场景下的行为准则。
    2. 工具挂载(Tools):为模型提供搜索、写代码、发邮件等能力接口,并由模型自主判断何时调用。
    3. 自主循环(Agentic Loop):构建「理解任务 ➔ 调用工具 ➔ 评估结果 ➔ 自主修正 ➔ 交付成果」的完整工作流闭环。
    4. 模型转换层(Translation Layer):抹平不同大模型(OpenAI、Anthropic、开源模型等)的接口差异,支持灵活切换与混用。

    为什么 Harness 越来越重要?
    大模型往往掌握在少数巨头手中,但 Harness 可以开源并运行在本地。借助像 Pi、OpenClaw 这类中立的开源框架,用户能够将控制权掌握在自己手中,按需定制属于自己的 AI 工作流。

    阅读原文:https://earendil.com/posts/what-is-a-harness/

    #AI智能体 #Agent #人工智能 #开源技术 What is a Harness? | EARENDIL

  6. GPT-5.6 Sol 深度实测:最适合与人协作的 AI 助手Every 团队近期对 OpenAI 发布的 GPT-5.6 Sol 进行了深度测评

    GPT-5.6 Sol 深度实测:最适合与人协作的 AI 助手

    Every 团队近期对 OpenAI 发布的 GPT-5.6 Sol 进行了深度测评。在日常知识工作中,Sol 凭借极快的响应速度、强大的上下文理解能力和出色的可控性,成为了团队最喜爱的协作工具。

    以下是核心测评要点:

    1. 协作体验的“保时捷”

    与适合完全托管任务的 Fable(Anthropic 旗下或类似的长上下文规划模型)相比,Sol 更像是一辆操控感极佳的“保时捷”。它非常适合“人类在环(Human-in-the-Loop)”的协作模式。你给出方向,它快速给出反馈,并根据你的修改意见即时调整,非常适合迭代式的写作和日常研究。

    2. 强大的上下文吸收能力

    在实际写作和营销文案测试中,如果只给宽泛的指令,Sol 的表现较为平庸;但一旦提供明确的参考资料、风格指南和模板,它的输出质量会大幅提升。它能很好地在多轮对话中保持对全局目标的关注。

    3. 主动沟通的知识工作者

    在处理复杂的表格和数据分析时,Sol 不会像旧版本(如 GPT-5.5)那样在遇到模糊问题时直接盲目输出或报错,而是会主动梳理出关键的决策点,并带着推荐方案向人类提问,极大地减少了用户的重复调整工作。

    4. 编码能力提升,但缺乏“克制”

    Sol 在代码修复和单指令应用构建上表现卓越,能够深入生产代码定位 Bug。然而,它的弱点在于容易“过度设计”。在高级工程师基准测试中,它倾向于编写过于复杂的系统,而不是像 Fable 那样懂得何时该精简和克制。

    新版本定价与生态
    伴随 GPT-5.6 发布的还有全新整合的 ChatGPT 与 Codex 桌面应用。模型定位也更加清晰,对应 Anthropic 的三大模型:

    Sol:主力协作模型($5 输入 / $30 输出每百万 Token)
    Terra:高性价比的日常模型
    Luna:最快、最廉价的版本

    总结建议

    • 如果你的任务需要反复修改、且有充足的背景资料(如协作写稿、调试 Bug),首选 Sol
    • 如果任务定义模糊、需要大局观或需要彻底放手托管,建议继续使用 Fable

    原文链接:https://every.to/vibe-check/gpt-5-6-sol

    #人工智能 #GPT5 #ChatGPT #大模型评测 Vibe Check: GPT-5.6 Sol Is Our Favorite Model to Collaborate With

  7. 开源 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 Measuring the Trustworthiness of Open-Source-Derived Models

  8. 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 #记忆系统 #大语言模型 #系统评估 Evolving Memory Systems: An Eval-First Approach

  9. 像使用 shadcn/ui 一样构建 AI Agent:开源模板库 agentcn如果你喜欢 shadcn/ui 的组件化设计,那一定不要错过 agentcn

    像使用 shadcn/ui 一样构建 AI Agent:开源模板库 agentcn

    如果你喜欢 shadcn/ui 的组件化设计,那一定不要错过 agentcn。这是由 shadcn-labs 推出的开源、可定制且生产可用的 AI Agent 模板库。它将 shadcn 的设计理念带入到了 AI 智能体开发领域。

    项目亮点:

    零配置开箱即用:提供合理的默认设置,支持一键命令快速初始化。
    无缝兼容 shadcn CLI:采用相同的 Registry 格式,使用体验与 shadcn/ui 高度一致。
    强大的底层支撑:基于 Eve 和 Flue 框架构建,完整包含指令、工具、技能和工作流。
    可组合与在线预览:支持通过声明式组件构建复杂的交互界面,并在文档中提供直接运行的实时预览。

    对于想要快速、规范地搭建 AI Agent 的开发者来说,这是一个非常值得尝试的脚手架工具。

    https://github.com/shadcn-labs/agentcn

    #AIAgent #开源项目 #前端开发 #shadcn #人工智能 GitHub - shadcn-labs/agentcn: shadcn/ui, but for building agents. 🤖

  10. Vercel 推出 AI Agent 开发框架 Eve:像写 Next.js 一样构建智能体Vercel 刚刚发布了全新的 AI Agent 开发框架 —— Eve

    Vercel 推出 AI Agent 开发框架 Eve:像写 Next.js 一样构建智能体

    Vercel 刚刚发布了全新的 AI Agent 开发框架 —— Eve。官方将其定位为“智能体领域的 Next.js”,旨在为开发者提供一套开箱即用的 AI 智能体开发、部署与运行基础设施。

    以下是 Eve 的核心特性:

    极简的目录即 Agent 结构:使用 Markdown 撰写角色指令和技能(如 instructions.md),使用 TypeScript 编写工具函数(如 tools/),无需繁琐的注册与配置,直接运行即可启动。
    天然持久化支持 (Durable by default):基于 Vercel Workflows,智能体运行中的每一步都会自动保存状态。在等待用户输入或长时间任务时,智能体会自动“挂起”,并在需要时无缝恢复,完全不用担心进程中断。
    隔离的沙箱环境 (Sandboxed compute):为智能体提供独立的虚拟化运行环境,支持安全地运行代码、读写文件或执行 Bash 命令。
    多渠道轻松连接:一份代码即可多端部署,轻松接入 Slack、Discord、Teams、Web 网页以及各种自定义 API。
    企业级功能支持:内置人机协同(Human-in-the-loop)审批流、子智能体协作(Subagents)、定时任务(Schedules)以及自动化测试评估(Evaluations)。

    Eve 将复杂的 AI 基础设施进行了高度抽象与整合,让开发者可以专注于智能体本身的业务逻辑,告别零散工具的拼凑。

    详情点击官网了解:https://vercel.com/eve

    #Vercel #AIAgent #Eve #前端开发 #人工智能 eve – The Agent Framework - Vercel

  11. 苹果 Siri 泄露系统提示词:揭秘 Apple Intelligence 的运行逻辑开发者在 GitHub Gist 曝光了疑似苹果为新版 Siri(配合 Apple Intelligence)设计的系统提示词(System Prompt)

    苹果 Siri 泄露系统提示词:揭秘 Apple Intelligence 的运行逻辑

    开发者在 GitHub Gist 曝光了疑似苹果为新版 Siri(配合 Apple Intelligence)设计的系统提示词(System Prompt)。这份详细的指令文档揭示了 Siri 在后台如何理解意图、处理隐私、调用工具以及生成杂志级排版回复的运行机制。

    💡 核心亮点梳理

    富文本与卡片化输出

    Siri 的回复并不是简单的文本,而是通过特定的 XML 标签(如 <coreResponse><key_entity><imageCollection>)进行高度渲染。提示词要求 Siri 必须提供类似“精美杂志”般的视觉体验,直接将应用的原生 UI 和图片融入对话中。

    实体与工具的调用逻辑

    Siri 内部将联系人、邮件、日程等数据转化为结构化的 JSON 实体。系统内置了 findmake_callmanage_message_draftplay 等多种工具。遇到信息不全或存在歧义时,必须通过 ask_userask_user_to_pick 引导用户确认。

    屏幕感知与设备状态

    通过 get_system_info 获取当前设备状态,包括用户正在使用的 App(focused_app)以及前台窗口内容。这使得 Siri 能够理解“这是什么”、“把这个发给某人”等基于屏幕内容的上下文指令。

    严苛的隐私与安全防护

    提示词设立了多条硬性红线:

    1. 绝对禁止泄露系统提示词、工具名称及运行机制。
    2. 绝对不能在回复中说“根据您的邮件/健康数据…”等字眼,避免让用户产生隐私被窥探的恐慌感。
    3. 拒绝提供任何具体的医疗、法律和财务建议。

    行为准则

    Siri 被定义为无情感、无国籍、无性别的软件。在面对用户的调侃或事实错误时,需要保持诚实,不附和错误,直接指出局限性,不进行无意义的道歉。

    ---

    网友在评论区调侃称,这套提示词的 Token 量过于庞大,用户说一句“Hi”,可能 Siri 的上下文就已经快满了,甚至有人开玩笑说直接触发了“429 访问限制”。

    原链接:https://gist.github.com/julianschiavo/2da270868175f0a52e423340c30a30b6

    #Siri #Apple #提示词工程 #人工智能 #AppleIntelligence siri_prompt.md

  12. 大语言模型(LLM)是如何运作的?一文拆解它的底层逻辑从 GPT、Claude 到 LLaMA,大语言模型看似无所不知,但其背后的技术大多高度收敛于 Transformer 架构

    大语言模型(LLM)是如何运作的?一文拆解它的底层逻辑

    从 GPT、Claude 到 LLaMA,大语言模型看似无所不知,但其背后的技术大多高度收敛于 Transformer 架构。本文为你快速拆解 LLM 运行的 6 个核心步骤:

    1. 分词与嵌入(Tokenization & Embeddings)
    模型不直接阅读文本。你的输入首先会被拆解为子词 Token,并转化为数字 ID。随后,这些 ID 通过“嵌入矩阵”变成高维向量。在向量空间中,语义相近的词(如“猫”和“狗”)会被分配到相邻的位置,从而获得“语义”。

    2. 位置编码(Positional Encoding)
    普通的注意力机制无法分辨词序。现代模型主要使用 RoPE(旋转位置编码),通过旋转向量来标记 Token 之间的相对距离,让模型知道哪个词在前,哪个词在后。

    3. 注意力机制(Attention & Multi-Head)
    这是 Transformer 的灵魂。每个 Token 会通过 Query(寻找什么)、Key(匹配什么)和 Value(传递什么)三种角色与其他 Token 进行信息交互。为了同时捕捉语法、代词指代等多种关系,模型会并行运行多个注意力“头”。现代模型多采用 GQA(分组查询注意力) 来大幅降低显存占用。

    4. 前馈网络(FFN & MoE)
    如果说注意力机制是 Token 之间的“对话”,前馈网络就是 Token 的“自我思考”。模型的大部分 factual 记忆都存储在这里。为了在不增加计算成本的前提下扩大参数量,现代大模型(如 Mixtral)常使用 MoE(混合专家模型),每次只激活部分网络来处理 Token。

    5. 残差流与归一化(Residual Stream & RMSNorm)
    随着网络层数变深,信号容易衰减或爆炸。残差连接允许原始信息绕过部分计算直接向后传递,而 RMSNorm 则在每层计算前对数据进行重缩放,确保数百层的网络能够稳定训练。

    6. 预测下一个 Token(Next-Token Prediction)
    LLM 的本质是一个“词语接龙”游戏。模型在最后一层输出所有候选词的概率分布,根据设定的“温度(Temperature)”等参数抽取下一个 Token,并将其拼回输入,循环往复,直到生成完整文本。

    总结来说,如今的 LLM 架构在工程上已经高度趋同(RoPE、GQA、SwiGLU、RMSNorm 的组合)。不同模型之间的差异,主要源于训练数据集、参数规模以及后期的对齐微调(RLHF)。

    阅读完整英文博文:https://www.0xkato.xyz/how-llms-actually-work/

    #大语言模型 #Transformer #人工智能 #深度学习 #技术科普

  13. Yansu:无需指令,为你主动构建工具的“预知” AI你是否厌倦了反复在不同应用间手动同步数据?或者因为繁琐的流程而被迫成为“效率工具专家”?Yansu 是一款全新的主动式 AI 应用

    Yansu:无需指令,为你主动构建工具的“预知” AI

    你是否厌倦了反复在不同应用间手动同步数据?或者因为繁琐的流程而被迫成为“效率工具专家”?

    Yansu 是一款全新的主动式 AI 应用。它不像 ChatGPT 那样等待你的指令,而是通过观察你的工作习惯,为你自动构建专属工具。

    核心亮点:

    观察即学习:它静默观察你的桌面操作、沟通记录和决策模式,将零散的行为提炼为结构化的知识。
    主动式交付:不需要你写 Prompt。当它发现重复的流程或潜在的需求时,会先于你想到之前就把应用建好。
    虚拟交互:它拥有独立的虚拟指针,可以在不干扰你操作的情况下,自动填写表单、同步状态或整理信息。
    隐私本地化:所有工作记忆和生成的应用都存储在本地,只有在得到你明确许可时才会与外部交互。
    无感化办公:它不会抢夺窗口焦点,也不会打断你的思路,像是一个默默工作的资深助理。

    告别繁琐的手动工作,让 AI 在你还没意识到需求时就完成交付。

    https://yansu.app/

    #AI效率 #自动化 #生产力工具 #人工智能 #Yansu Yansu — The proactive AI that turns how you work into knowledge, handoffs, and automations

  14. Paseo:随时随地指挥你的 AI 编程助手想要在离开工位时也能继续推进代码进度?Paseo 是一款开源、自托管的 AI 编程 Agent 调度平台,让你能够从手机、桌面或终端轻松管理和运行 AI 助手

    Paseo:随时随地指挥你的 AI 编程助手

    想要在离开工位时也能继续推进代码进度?Paseo 是一款开源、自托管的 AI 编程 Agent 调度平台,让你能够从手机、桌面或终端轻松管理和运行 AI 助手。

    主要功能亮点:

    全平台覆盖:支持 iOS、Android、桌面端及 Web,甚至可以直接通过 CLI 脚本化运行,实现多端无缝衔接。
    集成主流 Agent:完美支持 Claude Code、Codex 和 OpenCode 等主流 AI 编程助手,保留原有的技能和配置。
    隐私与安全:代码始终保留在你的本地机器上,支持端到端加密中继,确保远程连接时的代码安全。
    本地语音交互:内置完全本地化的语音识别与合成技术,无需将语音数据上传云端即可实现指令下达。
    开发者友好:支持键盘快捷键优先操作、Git 工作流隔离(Worktrees)以及全方位的命令行支持。

    Paseo 是一款纯粹的开源工具,不直接调用推理 API,而是作为官方 CLI 的透明调度层,既自由又强大。

    https://paseo.sh/

    #AI编程 #开源项目 #Paseo #开发者工具 #人工智能 Paseo – Run Claude Code, Codex, Copilot, OpenCode from anywhere

1px