分类：AI动态 标签：Apple智能、大模型、ChatGPT、人工智能 过去一周，全球科技数码圈迎来了多项重磅进展。从苹果在国行版中正式推送 Apple 智能测试，到 ChatGPT 搜索量逼近谷歌体量的关键节点，再到字节跳动 Seedance 模型在海外市场的高歌猛进，各大巨头正在 AI 与硬件融合的赛道上展开新一轮激烈角逐。 1. 国行 Apple 智能开启首测，Siri 开放第三方 App 操作 苹果向开发者推送了 iOS 27.3 首个开发者 Beta 版，标志着国行 iPhone 用户正式开启首批 Apple 智能功能的测试。 本地化合作：国行 Apple 智能在部分体验中接入了阿里巴巴的千问大模型，用户可直接在 Siri、写作工具和视觉智能中调用千问，覆盖文本与图像理解相关能力。 生态深度打通：新版本进一步开放了 Siri 对第三方 App 的操作能力，引入「App Skills」机制，允许开发者将多个操作组合成可调用任务，让 Siri 能够结合上下文执行复杂的跨应用指令。 推送计划：首批测试覆盖 iPhone 15 Pro 系列、iPhone 16 及后续机型等，正式版计划于 12 月正式推出。 2. ChatGPT 搜索量达谷歌 20%，搜索与 AI 赛道持续升温 在 AI 搜索与应用层，OpenAI 迎来了重要的业务里程碑。 搜索体量激增：OpenAI 消费产品负责人 Adam Fry 透露，当前 ChatGPT 触发的网络搜索请求量已相当于谷歌搜索量的约 20%，显示出 AI 搜索正在分流传统搜索引擎的巨大流量。 产品形态收敛：为了优化用户体验，OpenAI 宣布将于 2027 年 1 月 30 日正式停用旧版 ChatGPT Classic 应用，并将聊天 (Chat) 和工作 (Work) 标签页合并为统一的交互界面。 国内应用竞争：与此同时，国内 AI 市场格局也在演变。根据 QuestMobile 报告，豆包与 DeepSeek 在用户人均使用频次和时长上处于领先地位，其中 DeepSeek 的用户活跃度环比持续稳步增长。 3. 字节跳动 Seedance 海外高歌猛进，腾讯多维布局深化 在底层大模型与互联网生态方面，头部企业的业务边界正在进一步拓展。 ...

分类：AI动态 标签：具身智能、大模型、机器人、人工智能 在大模型技术狂飙突进的当下，AI 的形态正从冷冰冰的屏幕对话，逐渐演变为走入现实物理世界的具身实体。2026 年 10 月 29 日，心言机器人正式发布了旗下首款具身家庭智能体「巴布（Bubbo 1）」。 这款售价 9499 元（首发优惠 7999 元）的毛绒外形机器人，搭载了心言自研的 Bubbo OS。与传统「等人发号施令」的智能家电不同，巴布主打「伙伴式交互」，它内置了 13 类、26 个传感器，通过 6 个自由度和两块表情屏来捕捉人类情感，试图在复杂的家庭场景中建立长期的陪伴关系。 围绕这款产品的诞生，心言机器人创始人兼首席设计师任永亮、极客公园创始人张鹏、全国政协常委兼国家统计局原副局长贾楠，以及哈尔滨工业大学计算学部长聘教授赵妍妍，展开了一场关于技术、情感与中国老龄化社会痛点的深度圆桌对话。 技术决定下限，交互决定上限 在产品设计之初，团队就确立了一个核心逻辑：技术解决的是体验的下限，而交互才决定了上限。过去的 AI 常常处于「你不开口、它便不在」的工具视角，而巴布则希望构建一个全新的 Family Agent（家庭智能体），去识别家里的每一个人，并敏锐捕捉家庭成员之间的关系。 从技术维度来看，哈工大计算学部教授赵妍妍指出，情感计算是一条清晰的阶梯式路径： 感知 -> 认知 -> 交互 情感感知：通过多模态信号实时捕捉用户的高兴与低落。 情感认知：深入挖掘情绪背后的事件语义，弄清楚用户为什么开心或不开心。 情感交互：在具备移动和跟随能力的基础上，结合实体形态给出实质性的帮扶与共情回应。 对于巴布而言，其强大的长期记忆功能和个性化对话建模，使其能够记住孩子的兴趣爱好、老人的生活习惯，从而提供带有呼吸感、延迟感与边界感的回应。 银发经济与居家养老的现实解法 放眼更宏观的中国社会背景，具身智能走进家庭不仅是科技极客的浪漫，更承载着沉重的现实需求。 根据国家统计局相关数据，截至 2025 年底，中国 60 岁以上人口已占常住人口的 23%，其中失能、独居老人将近 4000 万。贾楠指出，尽管社会各界都在推进养老机构建设，但绝大多数老人依然渴望居家养老。然而，传统家政护理人员严重短缺，独居带来的精神寂寞与记忆衰退更是不容忽视的社会痛点。 在这样的背景下，巴布切入的正是情感陪伴的核心赛道。对于老人而言，它不仅仅是一个听众，更是一个能够缓解孤独、减少精神疾病风险的家庭伙伴。通过陪伴聊天、追溯过去的故事，它在一定程度上弥补了快节奏现代生活中子女陪伴的缺位。 寻找机器人的「生命力」 当被问及最看重产品的哪一项功能时，创始人任永亮的回答十分独到：自动回充。 在许多人眼里，自动回充或许只是一个常规的工程设计，但在任永亮看来，这关乎机器人的底层逻辑。他选择用生物学的视角去看待这个品类：机器人作为一个全新的物种，进入家庭的首要任务是「适应环境并生存下去」，实现真正意义上的「永不关机」。 而衡量这一产品未来是否成功的标准，正如团队所期待的那样：当有一天，它学会了人类并没有教给它过的新技能，那才是真正的自进化与成长。 总结 作为具身智能迈向 C 端家庭的勇敢尝试，巴布也许无法在第一代就解决所有的家务难题，正如圆桌嘉宾所言，这仅仅是漫长征途中的第一步。 从主动感知到深度共情，从缓解老龄化社会的陪伴焦虑到构建全新的家庭智能关系，科技与人文的交织正在赋予冷冰冰的硬件以「家人」的温度。随着大模型与机器人技术的持续融合，未来的家庭智能体，或许真的会成为我们生活中不可或缺的温暖同行者。

分类：科技 标签：客户端开发、人工智能、大模型、跨端技术 在 AI 辅助编程普及的今天，客户端开发的技术边界正在被重新定义。如何打破“研发效率、体验与性能”的不可能三角？如何在一台 Mac 上丝滑搞定 Windows 原生软件开发？本文将结合实际项目经验，聊聊多端技术选择的思考、AI 时代的架构设计，以及多语言混血调用的奇妙解法。 一、 Web、跨端还是原生：技术选型的不可能三角 做客户端开发多年，面对的无非是三条技术路径： Web 技术栈：如早期 PhoneGap、Cordova，以及现代的 Electron。其优势是开发极快、多端一致性好（统御于 Chromium 引擎），但代价是体积庞大、内存占用高。 跨端开发：包括早期的 React Native、Weex，到后来的 Flutter（自研渲染引擎），再到如今用 Rust 写的 Tauri 或 Go 写的 Wails（借助系统 WebView）。跨端在研发效率和性能之间取了一个平衡，但往往需要处理不同平台的兼容细节。 原生开发：如 Swift + SwiftUI、Kotlin + Jetpack Compose、C# + WinUI 3。前期投入大、学习成本高，但能深度调用系统底层，带来极致的性能与流畅体验。 在 AI 时代，一个人编写多套原生代码的成本大幅下降，效率瓶颈被显著补齐。如果是重度依赖系统底层能力的工具类应用，原生依然是首选；而如果追求极致的发布速度，跨端技术依然能发挥奇效。 二、 Windows 原生开发实战：C# 与 WinUI 3 的抉择 在开发 Mac 软件（如 Mole）时坚持使用了原生的 Swift + SwiftUI。因此，在推出 Windows 版本时，同样倾向于选择最贴合 Windows 平台的原生方案：C# 结合 WinUI 3，运行在 .NET 10 之上。 框架优势：相较于老旧的 WinForms 或 WPF，微软主推的 WinUI 3 将界面框架独立发版，完美支持 Windows 11 的 Fluent 设计风格，且对高分屏缩放与 ARM64 提供了原生支持。 打包与更新：通过 .NET 10 的长期支持版本，将运行时直接打包，避免用户额外折腾；同时利用开源的 Velopack 框架实现增量更新，推出 x64 与 ARM64 各自的原生安装包。 1. 规则抽象大于代码复用 虽然两端视觉和交互需要保持高度一致，但底层的逻辑代码由于系统差异（如 macOS 的 ~/Library 路径规则），很难直接复用 Swift 代码。因此，Windows 版几乎是从零开始。 ...

分类：科技 标签：客户端开发、人工智能、跨端开发、大模型 在日常开发中，许多开发者常常好奇：如何用 Mac 顺畅地开发 Windows 软件？当下的 Windows 软件又普遍采用什么技术栈？结合近期的多端开发实践，我们可以从技术选型、AI 辅助编程以及多语言混用等维度，聊聊客户端开发在 AI 时代的全新思考。 Web、跨端还是原生：不可忽视的不可能三角 回顾客户端开发的演进，长期以来存在一条清晰的「不可能三角」：研发效率、体验与性能三者难以兼得。 Web 技术栈：以早期 PhoneGap、Cordova 为代表，直接将网页塞入原生壳中。优点是研发效率极高、跨端一致性好，代价是性能与底层系统调用能力较弱。 跨端开发：包括主打移动端的 React Native、Flutter，以及桌面端大名鼎鼎的 Electron。Electron 凭借 Chromium 渲染引擎提供了极佳的多端一致性，但代价是安装包动辄上百兆、内存占用偏高。近几年虽然涌现出 Tauri、Wails 等基于系统 WebView 且体积小巧的新秀，但由于各平台系统 WebView 表现不一，多端一致性往往需要额外的兼容代码来维护。 原生开发：如苹果系的 Swift、Android 的 Kotlin，以及 Windows 的 C# + WinUI 3。原生开发前期学习曲线陡峭、投入较大，但能够深度调用系统底层能力，带来极致的性能与交互体验。 在 AI 辅助编程普及的今天，原生开发的效率短板被大幅补齐。如果是重内容的浏览型应用，Web 技术依然最省心；但对于追求深度系统集成与低内存占用的应用，原生技术依然是首选。 Windows 版原生开发：为什么选择 C# 与 WinUI 3 在打造跨平台软件的 Windows 版本时，为了不将就体验，直接选择了微软主推的原生方案：C# 结合 WinUI 3，并运行在 .NET 10 之上。 Windows 上的原生界面框架历经演进（从 Win32、WPF 到 UWP），目前微软主推的 WinUI 3 独立于系统发版，不仅能被普通 Win32 程序调用，还原生支持 Windows 11 的 Fluent 设计风格、高分屏缩放以及 ARM64 架构。通过将 .NET 运行时打包进安装包，并借助开源的 Velopack 框架实现增量更新，可以尽量让普通用户做到开箱即用、无感升级。 ...

分类：AI动态 标签：豆包大模型、人工智能、效率工具、抖音 在企业日常运营中，跨平台数据搬运、多后台反复切换以及繁琐的报表整理，一直是消耗团队精力的痛点。近日，豆包工作台迎来了重要功能更新，通过接入多款官方核心插件，试图用自然语言彻底改变这一现状。 核心更新：打通多端经营链路 11月4日，豆包工作宣布正式接入三款官方重磅插件： 抖音生活服务经营插件 巨量本地推插件 TikTok for Business插件 此次接入意味着大模型能力与企业实际商业运营场景进行了深度绑定，打通了以往割裂的数据孤岛。 体验升级：告别报表搬运，实现效率跃升 过去，运营人员想要获取门店数据或做一次完整的经营复盘，往往需要登录不同的后台，导出数据、复制粘贴、再进行人工整理。 而在完成相应账户授权后，豆包工作台将带来全新的交互体验： 自然语言查询：用户只需直接向AI提问（例如：“查询上周各门店的核销数据”），即可实时获取结构化结果。 一键经营复盘：大模型能够快速对多维数据进行分析，自动生成复盘总结。 智能决策建议：基于数据表现，系统能够直接输出优化建议，辅助团队快速响应市场变化。 这一变革让整个工作流简化为：自然语言输入 -> 数据智能检索 -> 复盘与建议输出，大幅减少了重复性劳动。 编辑点评 豆包此次接入生活服务与出海营销插件，是AI助手向“生产力工具”深度演进的一个缩影。当大模型不再仅仅停留在文本创作和代码编写，而是深入到具体的商业经营与数据分析场景中，AI才真正开始为企业创造可感知的降本增效价值。对于广大商家和运营团队而言，如何善用这类AI工具重塑工作流，将成为提升竞争力的关键。

分类：科技 标签：客户端开发、AI辅助编程、跨端技术、架构设计 在过去的前端与客户端开发中，“Web、跨端还是原生”一直是横亘在开发者面前的不可能三角：研发效率、体验与性能往往难以兼得。而随着 AI 编程工具的大规模普及，这一平衡正在被悄然打破。本文以开发者将 Mac 软件移植到 Windows 的实际经历为例，探讨 AI 时代下的技术选型、原生与跨端的博弈，以及如何巧用多语言混血架构打造极致体验。 一、 Web、跨端还是原生的博弈 做客户端开发多年，主流的技术路线大致可以分为三类： Web 技术栈：以网页形式打包，通过 Shell 或 Bridge 调用原生能力。开发简单、跨端便捷，但性能和底层交互上限受限。 跨端开发：包括早期的 React Native、Weex，桌面端的 Electron，以及自研渲染引擎的 Flutter。 Electron 凭借 Chromium 保证了多端展示的一致性，但内存占用高、安装包臃肿的代价明显。新兴的 Tauri 和 Wails 虽改用系统自带 WebView 缩小了体积，但多端一致性却有所妥协。 原生开发：如 Swift、Kotlin 或 C#。前期投入大、学习成本高，但能提供最佳的性能、更低的内存占用和深度的系统底层调用。 过去，由于原生开发成本高昂，国内市场大面积倒向了跨端方案。但在 AI 辅助开发的今天，一人编写双端原生代码的成本大幅下降。如果应用需要深度调用系统底层能力或追求极致流畅，原生开发的优势正在重新凸显。 二、 Windows 版原生选型：为什么选择 C# 与 WinUI 3 在将 Mac 端的应用（如 Mole）移植到 Windows 时，开发者并没有盲目追求跨端，而是坚持了原生路线，最终选择了 C# 结合 WinUI 3，并运行在 .NET 10 之上。 UI 框架演进：微软主推的 WinUI 3 摆脱了传统 WPF 时代的陈旧感，全面引入了 Fluent Design 风格，对高分屏缩放和 ARM64 提供了原生支持。 分层架构设计：为了实现 Mac 代码的最大化复用与解耦，架构被拆分为四个层次： Core 层：纯 .NET 实现，不碰任何 Windows 接口，可在 Mac 的内存文件系统中直接运行测试。 Platform 层：封装注册表、文件系统和 Win32 调用。 ViewModel 层：处理应用界面状态，与 Mac 版本一一对应。 WinUI 界面层：仅负责 Windows 下的视图呈现。 这种架构配合 AI 辅助，使得开发者在 Mac 主力机上通过 Parallels 虚拟机与脚本自动化测试，便能高效搞定海量的 Windows 代码编写与验证。 ...

分类：科技 标签：客户端开发、AI编程、跨端技术、架构设计 在客户端开发领域，开发者们常常面临一个经典的“不可能三角”：研发效率、体验与性能。如何在这三者之间找到平衡？随着 AI 编程工具的爆发，这一传统的技术博弈正在被彻底重塑。本文将结合实际项目的开发经验，探讨在 AI 时代如何进行客户端选型、Windows 与 Mac 多端架构设计，以及如何通过多语言混血编程破局。 一、 技术选型：Web、跨端还是原生？ 做端侧开发的小伙伴都知道，常规的技术路径大致分为三条： Web 技术：直接写网页塞进原生壳（如早期的 PhoneGap，或桌面的 Electron）。优势是研发极快、多端一致性好；代价是安装包庞大、内存占用高。 跨端开发：主打一码多端（如 React Native、Flutter）。它在效率和性能之间取了一个折中，但往往容易陷入“两头不讨好”的尴尬境地。 原生开发：前期投入大、学习成本高，但能带来极致的性能与体验。 在 AI 辅助编程普及的今天，选型的逻辑发生了变化。 如果产品是重内容的浏览型轻应用，Web 技术依然最省心；但如果需要深度调用系统底层、追求低内存和流畅交互，原生技术无疑是最佳选择。有了 AI 的加持，一个人编写并维护两套原生代码的成本大幅下降，“研发效率”这一短板被显著补齐。 二、 Windows 原生开发实践：C# 与 WinUI 3 的抉择 以开发 Windows 软件为例，市面上有 WinForms、WPF、UWP 等多种框架，而微软目前主推的是基于 Windows App SDK 的 WinUI 3。 拥抱现代 Fluent 风格：WinUI 3 的界面直接采用 Windows 11 的 Fluent 设计语言，原生支持高分屏缩放与 ARM64 架构。 分层架构与规则抽象：为了实现 Mac 与 Windows 双端功能对齐，项目采用了清晰的四层架构设计： Core 层：纯业务逻辑，只依赖 .NET，不碰任何系统接口，甚至能在内存文件系统中进行测试。 Platform 层：封装注册表、文件系统等真正的系统接口。 ViewModel 层：处理界面状态。 UI 层：具体的界面实现（如 WinUI 或 SwiftUI）。 AI 时代的协同：通过架构解耦，绝大部分核心逻辑和测试都可以在 Mac 虚拟机中跑通，真正需要进入 Windows 真机验证的场景被压缩到最低。 三、 语言无界：如何在一个应用里混用多种语言？ 作为优秀的开发者，不应被单一语言束缚，而应根据场景选择最合适的工具，并通过通信中间层实现多语言的有机互补。 ...

分类：游戏 标签：单机游戏、贝塞斯达、上古卷轴、RPG 在经历漫长的等待与无数次玩家的调侃后，贝塞斯达（Bethesda）终于在工作室40周年纪念视频的结尾，为全球玩家带来了《上古卷轴6》的最新重磅消息——这部自2018年首次亮相以来就备受瞩目的RPG巨作，正式公布了完整副标题与全新概念预告。 正式定名与舞台揭秘 游戏官方完整名称确定为《The Elder Scrolls VI: Sentinel》，暂译为《上古卷轴6：哨兵》。 回顾距离2018年首曝过去的八年多时间，加上《上古卷轴5：天际》发售即将满十五年的节点，这次公布的预告片虽然依旧没有实机演示，但透露出的关键信息终于让多年来的猜测有了定论。 副标题中的“Sentinel”（哨兵城）作为系列世界观中落锤省的首府，直接印证了此前关于下一段冒险将前往红卫人故乡的推测。预告片中显现的大量沙漠画面，也为落锤省的地理地貌提供了直观的视觉支撑。不过，仅凭目前的名字还无法完全确定地图边界，与哨兵城隔海相望、文化紧密相连的高岩省未来是否会一同加入，仍有待官方后续揭晓。 具体的时间线索 除了地点明确外，预告片末尾展示的一段来自圣蛾祭司雅扎尔的引文，也为玩家勾勒出了故事发生的时间背景： “卷轴只向我显露了一线微光，仿佛眼前的帷幕被稍稍掀起。一个失落的未来。一场被逆转的胜利。时间之沙，被命运打散。” ——第四纪元206年（4E 206） 鉴于《上古卷轴5：天际》的故事始于第四纪元201年，这意味着本作的时间线仅比前作开场晚了五年。这条清晰的时间线索，无疑为背景考据党们提供了极大的讨论空间。 结语 除上述内容外，贝塞斯达并未透露更多实质性开发进展，官方仅表示开发工作仍在继续，玩家们还需要再耐心地等待一些时间。 正如贝塞斯达官方评论区一条高赞评论所调侃的那样：“这些沙砾，象征着我们等这游戏等到身上积的灰。”既然副标题与时间线已经浮出水面，属于老滚迷们的下一场宏大冒险，终究在前方等待着我们。保持期待，继续同行吧。

分类：数码 标签：iOS、独立开发、大模型、开源项目 十年前，我在一家互联网公司担任移动端开发，利用业余时间开发了一款名为「微诗」的小工具，将全唐诗和全宋词的数据库装进手机，支持离线搜索。在那时，它承载了我对古诗词的热爱与分享欲。 然而，随着后续的创业失败、职业转型，这款 App 最终在 2017 年前后被搁置。生活推着人向前，那本装在手机里的诗集离我越来越远，但它始终是我心头的一桩未了心愿。 今年，借助大模型带来的强大 AI 编程能力，我终于下定决心将微诗彻底重写。不留一行旧代码，从零开始，只为把它做成自己心里的样子。 从零重写：现代技术栈与 AI 助力的碰撞 十年间，iOS 开发生态发生了翻天覆地的变化。与其在旧代码上修修补补，不如彻底推倒重来。 在技术选型上，我选择了 SwiftUI 结合 WidgetKit。主 App 与小组件共用一套视图和数据层，对于一个单人维护的独立项目而言，这无疑是最轻量、省心的选择。 而在这场重构中，AI Agent 扮演了至关重要的角色： 快速搭建骨架：AI 能够迅速建立 SwiftUI 工程，并理顺数据层、主 App 与小组件扩展之间的依赖关系。 填补技术盲区：面对中间几年错过的 iOS 新 API（如 WidgetKit 的时间线规划、锁屏小组件的尺寸与限制），AI 能够快速给出可运行的起点。 打磨交互细节：帮我省去了大量繁琐的样板代码编写工作，让我能把精力集中在真正核心的体验上。 当然，AI 并非万能。在重构过程中，真正消耗精力的并非技术实现，而是审美的抉择与功能的取舍。据统计，这一次重做，我在 token 上投入了近 2 万美元，大部分成本都花在了反复推翻、打磨界面细节和排版呼吸感上。AI 可以告诉你什么是「合理」，但「好看」与「诗意」只能由开发者自己的品味来决定。 全新微诗：把诗装进生活的方时刻刻 重新归来的微诗，被赋予了三个核心关键词：美观、简洁、诗意。它不再仅仅是一个冷冰冰的文字检索工具，而是真正融入了日常生活： 节气与诗：首页推荐的诗词与二十四节气紧密结合，用古人的诗意来标记每一个日子。 锁屏诗笺：充分利用 WidgetKit，将诗句放进锁屏小组件。每次抬手看时间时，便能与诗句不期而遇。 动态山水与音画共赏：引入了山水动态壁纸，一笔一画勾勒出水墨意境；同时支持 TTS 朗读，甚至通过 Suno 将诗词谱曲吟唱，让古诗词真正“活”了起来。 注释与拼音：补全了当年用户呼声最高的功能，每首诗均可查看详细注释、赏析以及生僻字拼音。 更重要的是，微诗依然坚持完全免费、无广告、无商业计划。 结语 近 2 万美元的 token 消耗，换算成任何商业回报或许都不算划算。但正如作者所说：人这一辈子，总该为自己喜欢的东西，认真地花一次力气。 如果你也热爱古诗词，或者对这款历经十年回归的独立 App 感兴趣，不妨前往 App Store 搜索下载体验。 ...

分类：[科技] 标签：[独立开发者]、[人工智能]、[iOS开发]、[大模型] 十年前，我还在一家互联网大厂做移动端开发，出于对古诗词的热爱，利用业余时间开发了一款名为「微诗」的小 App，把全唐诗和全宋词装进了手机里。经历了多年搁置、创业失败与职业转型，今年我决定借助大模型的力量，用 SwiftUI 将这款产品从零彻底重写。 回看这次重构，我烧掉了近 2 万美元的 token，没有融资也没有商业计划。这不仅是一次技术上的推倒重来，更是一个独立开发者对抗时间与实现情怀的故事。 从零重构：推倒重来的抉择 十年间，iOS 生态与 Swift 语言发生了翻天覆地的变化。面对旧代码，修修补补已无意义，我最终决定将代码全部清空，重新出发。 新版微诗的技术栈选择了 SwiftUI x WidgetKit 的组合。对单兵作战的开发者而言，主 App 与小组件共享视图和数据层，是最省心且高效的选择。 在产品设计上，我为它定下了三个关键词：美观、简洁、诗意。 节气与首页：打开 App，首页的每日一首诗会随着二十四节气流转，用诗歌标记日子，比冰冷的数字更有生活气息。 诗笺小组件：锁屏小组件是我个人使用频率最高的功能。在极其有限的单色空间里，通过精心调校的字形、字号与留白，让一两句诗在抬手间自然呈现。 视听融合：新版不仅加入了动态山水壁纸（一笔一画勾勒出水墨意境），还通过 Suno 将古诗词谱曲唱出，配合 TTS 朗读功能，让诗词真正“活”了起来。 补全遗憾：当年用户呼声最高的注释、赏析与拼音功能，这次也全部完整加入。 独立开发新体验：和 AI 一起写代码 离开客户端开发多年后，如果仅凭个人业余时间重构这样一款 App，过去是难以想象的。而这一次，AI Agent 彻底改变了开发流程： 快速搭建骨架：AI 可以又快又稳地完成建工程、理顺数据层与小组件扩展关系等繁琐工作。 弥补技术断层：面对不熟悉的现代 iOS API（如 WidgetKit 的时间线规划），AI 能够迅速提供可运行的起点，极大地降低了学习成本。 但在实际开发中，我发现最艰难的部分并非实现功能，而是品味与取舍。 AI 可以高效率地生成代码、帮你加上各种功能，但“合理”与“好看”之间隔着无数次的推翻重来。字号该多大、行距留多少、哪些功能该砍掉，这些关于审美和克制的决定，依然需要开发者自己一遍遍打磨。正如我耗费的大量 token，其实大多花在了追求极致体验的反复调试上。 写在最后 近 2 万美元的 token 成本，换算成任何商业回报或许都不划算，但它让我把心里的一个遗憾画上了句号。 AI 让“把东西做出来”的门槛变低了，从而让“做成什么样”变得格外重要。人这一辈子，总该为自己喜欢的东西，认真地花一次力气。目前「微诗」已经全新上线 App Store，依然坚持免费。如果你也喜欢这份诗意，不妨下载体验并留下你的宝贵建议。