AI 编程火了这么久，无论是开发者还是我们普通人，都能让 AI 来帮忙做个小游戏、捣鼓点小工具。

有时候还真别说，那些 AI 做的小玩意，的确能起到点作用。很多读者也经常在留言区评论，现在最好的编程模型是什么？

Claude 4.5 + Cursor 自一直是很多开发者的首选，但它们由于种种原因对中国用户都不太友好，结果是花同样的钱开会员，有可能很多模型都用不了。

好消息，这次我们不会被「卡脖子」了。

昨天，字节发布了他们的编程工具，TRAE 3.0，我们体验了一下，在某种程度上，TRAE 可以说就是一个国产版 Cursor，甚至部分功能做得比 Cursor 还要好。

其中，最核心的功能 SOLO 模式，是之前所有同类产品，没有探索过的 AI 编程工具形态。它提供了 SOLO Coder 和 SOLO Builder 两个智能体，一个针对专业的开发者用户，处理复杂的项目开发问题；一个针对个人和小团队，真正做到一句话做个产品，能上线发布的产品。

这两个 SOLO 智能体，把过去传统软件开发，涉及到的全部工作基本都包揽了。目前 SOLO 模式正在限免期，前往 trae.ai 下载安装，登录之后就能免费体验到 15 号。

限免期之后，TRAE 的会员计划也比 Cursor 更良心，首月是 3 美元，次月开始 10 美元。和免费用户的区别就是在模型调用、快速响应上的额度分配不同。

SOLO 模式，让编程更加 Vibe

SOLO 模式其实最早是在 TRAE 2.0 的时候推出的，当时只是用来快速生成一个应用。而更新的 TRAE 3.0 版本中，是把快速生成的应用，能做得更复杂，还给专业开发者带来了更高效的功能。

之前，我们使用大多数的编程产品，或者就是要 ChatGPT、Gemini 这些通用助手，来进行 vibe coding。

本质上还是，我们单纯地跟模型进行对话，解决某一个具体的问题，最后的产出也比较有限，一般就是一个我们看都看不懂的代码文件，点个预览就够了。

但现在，TRAE SOLO 模式改变了过去传统的开发工具、或者 AI 聊天编程产品的形态。它整体的布局更像一个大模型助手的智能体界面，没有了中间的代码编辑器，最左边也不是文件管理器，而变成了任务列表。

SOLO Coder：面向复杂项目开发

TRAE 提供了 Coder 和 Builder 两个选项，SOLO Coder 主要是针对复杂的项目开发，更专业的应用场景。一般是我们有现成的项目，可以通过 Coder 来完成一些项目迭代、Bug 修复和架构重构等。

我们选择了一个 GitHub 上的开源项目，动辄上千上万行的代码，根本看不懂。然后直接问他有没有什么更好的网络结构等组件，可以让这个方法的效果更好。

前几天我刷社交媒体，看到有人在问，大家在 vibe coding 等结果的过程中一般做什么。

有人说真正的 Vibe 是应该打开手机开始刷视频，也有人说会盯着 AI 的每一步操作，防止它莫名其妙删库跑路，还有说再开一个 Agent 来执行其他任务。

SOLO 模式似乎也考虑到了这一点，在任务处理过程中，是可以多任务并行的，意思是我们可以同时执行多个项目。同时，SOLO 智能体在调用不同的工具过程中，会可视化全部的工具调用流程、自动切换不同的工具面板，TRAE 把这一点叫做「实时跟随」。

和 TRAE 2.0 会显示当前使用的模型不同，在 Claude 彻底断供之后，TRAE 3.0 在 SOLO 模式下，只会显示 Max 模型，且不能自定义选择模型。

SOLO Builder：从零构建一个应用

SOLO Coder 还是有点太专业了。另一个智能体，SOLO Builder 在某种程度上，则是一款很典型的 vibe coding 产品，和我们之前分享过的 Lovable 一样，它主打的是从零开始，一句话构建一个产品。

但不同的是，SOLO Builder 能凭借 TRAE 自身强大的开发环境，真正做出一个大规模可用的产品，不会停留在做一个小玩意路线上。

一款应用从构思到最后真正上架到 App Store，中间要完成的需求分析、UI 设计、系统环境等等，都可以在 SOLO Builder 中，通过 AI 来完成。TRAE 提供了包括编辑器、文档、终端、浏览器、Figma、智能体、MCP在内的多个工具。

通过调用不同的工具，仿佛真的有一个助手在操作我们的电脑：在写清楚产品需求文档后，默默地又开始写代码来实现，最后再自己测试代码、部署整个项目；把产品经理、程序员、测试、运维的活全干了。

我们输入了一个需求，是让它做一个摸鱼 APP。得到了对应的文档之后，SOLO Builder 不会立刻执行，而是让我们先确认这个计划是否可行。此刻我们就是项目经理，告诉 AI 来 Align（对齐）一下颗粒度，不行就要 AI 再回去修改文档。

在 SOLO Coder 智能体，同样有「Plan 计划」的开关，先让模型规划怎么做，我们再确认。

一切顺利，我们得到了最后的摸鱼 App，TRAE 还贴心的提供了一个推荐操作，让我们把项目部署到 Vercel（托管网站的平台）上，而不仅仅是本地访问。

不过，SOLO 模式目前还只在国际版推出，国内版本可以通过加入候补名单，等待上线。

豆包编程模型，TRAE 的国产版核心

虽然国内版本还没有 SOLO 模式，但是字节最新的豆包编程模型，已经在 TRAE 国内版上线了。

Doubao-Seed-Code 是字节这周二发布的一款全新模型，它专门在 Agentic 智能方面，进行了深度优化；在多个编程相关的基准测试中，表现结果全面领先国产的同类模型；此外，它的输入输出还做到了国产模型的最低价。

用直观的例子说明，在相同 Tokens 数量的任务下（0-32k 输入区间），Claude Sonnet 4.5 完成需要约 4.05 元，GLM-4.6 要 0.77 元，而 Doubao-Seed-Code 的成本是 0.34 元。

Doubao-Seed-Code 的亮点还包括，它支持最高 256K 的上下文长度，能应付一般的长代码文件。它也是国内第一个支持视觉理解能力的编程模型；通俗点讲，就是不用自己口头描述做什么，一张设计稿、截图，就能自动生成对应的内容。

模型提供的 API 调用，支持在 Claude Code 中使用，也对字节跳动自家的编程开发工具 TRAE，Cursor、Codex CLI、Cline 等主流的开发生态，实现了全面的兼容。

目前，Doubao-Seed-Code 可以在火山方舟大模型体验中心、TRAE 中国版直接使用，也可以透过平台的 API 调用。

在 TRAE 中国版，还提供了 Kimi K2，GLM 4.6，以及 DeepSeek、Qwen 等常见国产编程模型。

我们也在火山引擎官网、TRAE 、以及 API 调用几种方式里，体验了这款全新的编程模型，不能说吊打 Claude，但是配合自身的编程开发环境、和超低的费用，很难不让人心动。

模型能力实测，一张草图生成一个项目

视觉理解是 Doubao-Seed-Code 的一大亮点，但其实从图片复制网页，甚至是在 AI 大语言模型流行之前，就已经有类似的应用。而多模态的能力，现在也基本上成为了每个模型的标配。

我们从网上找了一张手绘的网页布局图片，直接让它根据这张草图，生成对应的前端页面。

还原度还是很高的，复制代码拿过来直接用作自己的项目，或者再要它添加一些处理的逻辑，神笔马良的即视感。

除了这种照搬图片的内容，我们还找了一张大家熟知的游戏截图，Flappy Bird，但是截图里面就是几根柱子。上传截图并提问，你认识这个游戏吗？用一个单页的 HTML 实现它。

虽然简陋了一点，但是 Douban-Seed-Code 在深度思考的过程，一眼就看出来这是 Flappy Bird 的游戏。最后的实现，把小鸟直接换成了一个原点，但确实是一张图就能生成游戏。

火山方舟的模型体验中心更多是一种 Playground 的存在；Doubao-Seed-Code 的发布，直指当下火热的 AI 编程赛道。

字节也专门为 Doubao-Seed-Code 在 TRAE 中的表现进行过优化，与 TRAE 深度结合的豆包编程模型，在对应的编程基准测试中，甚至拿到了超过 Claude 4.5 Sonnet 的成绩。

和网页版处理不同，在本地使用，意味着我们的主动权更大。我们直接把过去几篇 APPSO 的文章放到项目文件夹，然后在 TRAE 里和模型对话，要它根据这些文件，帮我制作个人作品集。

在豆包编程模型的介绍资料里，我们看到字节用了一套大规模的 AI 强化学习系统，来完成智能体的学习训练。

• 覆盖十万个不同环境的数据集，让 AI 见识各种复杂任务。
• 不需要老师手把手的教，而是完全依靠端到端的强化学习，模型自己总结经验。

在 TRAE 中运行了一会儿了，就得到了最后的个人作品集网页，说实话总结得很不错，在精选文章那一部分，都是 AI 自动帮我配的图片。

除了直接使用，豆包编程模型还提供了 API 的方式，能够配置到 Claude Code 之类的工具中。

我们之前在介绍 Google 全家桶时，分享过 Gemini CLI（和 Claude Code 类似的命令行终端工具）的使用体验，基本上能减去我们找各种第三方工具的繁琐。

在火山引擎的官网，字节更是直接给出了完整的将 Doubao-Seed-Code 配置到 Claude Code 的详细步骤，我们只需要照着教程走，就能得到一个不会被断供的 Claude Code。

简单配置之后，我们就可以进入到 Claude Code 的页面，并且显示当前的模型时 doubao-sseed-code-preview-251028。

字节这波发 Cursor 平替 SOLO 模式，又发 Claude 4.5 平替 Doubao-Seed-Code，能看出来是真的很想把 AI 编程做到极致，毕竟这是现在的大热门。

有多热，代表性产品 Cursor 在最新一轮融资后，估值来到了 300 亿美元，并且它几乎可以确认，将是历史上最快达到 10 亿美元 ARR 的公司。

而前些天，柯林斯词典也宣布，把 Vibe Coding 作为 2025 年度词汇；这一年来，无论是不是学计算机专业的，多多少少都已经接触到了 AI 编程。

简单的「帮我生成一个贪吃蛇的游戏」、到复杂的大型项目管理，代码完全变成了向 AI，而更少面向开发者的语言。

这种趋势也在大多数的基础模型，把编程能力作为主要卖点的背景下，变得越来越流行。如果在去年问一个 AI 编程的用户，他会选择什么模型，毫不犹豫地说，一定是 Claude 3.5。

到了今年这个时候，Claude 断供看起来反而是倒逼了我们一把。国产的编程模型有了智谱的 GLM 4.6、阿里的 Qwen Coder、Minimax M2、月之暗面的 Kimi K2 Thinking，个个都榜上有名；今天又多了一个选择，Doubao-Seed-Code。

模型之外，工具的演变也没停下来，从只是生成代码然后预览，到现在 TRAE 要把软件开发一条龙全面服务到位。即便现在说 AI 编程，要全面取代程序员还不太可能，但让 AI 手搓一个微信，未来三五年说不定真的能做到。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

😄 AI无敌，花了两天，只写Prompt，不写一行的代码，利用两个AI工具：Cursor + Holopix，开发了一款完成度很高的原创——"🐦坤坤自走棋" 单机小游戏。赶紧来试试吧 ❗️

一、背景

Apex以vscode插件为主要载体，接入SSO认证、打通CursorRules知识库、Webview远程UI、实现无感安装MCP、创建智能体、使用智能体等能力，帮助实现提示词撰写效率的提升，降低了使用过程的费力度。通过知识库、智能体等可实现在保障代码质量同时，进一步提升AI代码生成占比。

除了功能层面的能力，想必大家对Apex内部实现原理应该也很感兴趣，如何打通知识库、智能体使用时，MCP为什么自动安装了，下面将从技术实现角度，剖析Apex 如何将“AI 能力”工程化落地到 Cursor 开发流程中。了解Apex是如何激活装配、打通SSO认证，同步 Cursor Rules 知识库、通过远程dist包实现webview UI渲染，并提供智能体能力，实现无感更新，消息如何编排，如何识别大仓还是独立应用等。

二、架构设计总览

Apex 以插件为主控，Webview 承载 UI 与业务交互，服务层聚合认证、工程上下文、CursorRules知识库、埋点等能力，MCP 以“配置即工具”的方式进行边界的扩展。实现三端（插件-前端-服务端）通过版本编排解耦vscode插件的迭代周期，在安全（鉴权）、可观测（日志与活跃情况）、工程落地（规则知识库与智能体模板）之间取得平衡。

三、功能设计&落地

3.1 激活与装配流程

为实现插件的稳定启动，在插件注册过程中，出现异常失败也不污染后续状态，通过事件注册按需加载，避免了冷启动插件带来的抖动问题。

要点流程介绍：

• 版本检查先行：防止低版本 Cursor 带来功能不兼容。
• 早期守卫 workspaceRoot，避免在无工作区时继续初始化产生隐式 NPE。
• 服务单例初始化顺序：ProjectService（工程上下文）→RuleSyncService（规则聚合/监听）→ StorageService（持久能力）→ AuthService.initialize()（异步认证获取 token 与 userInfo）。
• 鉴权失败直接中断，避免后续埋点与 webview 的脏状态。
• 命令注册分散在此处，MessageHandler负责Webview 指令编排。

// ...
VersionChecker.checkVersion();
const root = workspaceRoot(); 
if (!root) return;  // 早期守卫
ProjectService.getInstance();   // 工程上下文
const auth = AuthService.getInstance();
const logger = LoggerService.getInstance(context);
const user = await auth.initialize(); 
if (!user) return;  // 认证失败即止损
logger.watch();   // 可观测
// 注册 Webview/命令/规则监听 ...

3.2 认证与安全

（AuthService+Storage）

通过接入SSO实现可以单点登录闭环 + 本地仅存最少信息，降低泄漏面、失败可针对进行快速反馈。后期记录用户维度智能体的使用、记录用户的关键行为埋点，从而进一步实现及时私聊沟通解决告警出现的问题，另外，针对用户的使用习惯和使用情况可进行针对性的分析和需求收集。

令牌获取流程（嵌入端口监听 + 浏览器回调）：

async initialize(){
  const saved = await storage.getAuthToken();
  const token = saved?.trim()? saved : await login();
  return await validateToken(token) ?? await login();
}

令牌回调服务器（端口探测 + CORS + 路由校验）：

import http from 'http';
import * as vscode from 'vscode';
const LOWCODE_PLATFORM_API = 'https://xxx.yyy.zzz/ddd';
const PORT = 9527;


const findAvailablePort = (startPort: number, endPort: number = startPort + 10): Promise<number> => {
 //  端口监听逻辑
};


export const requestToken = async () => {
  // 验证token有效性
}

• 数据结构与算法设计：
• • 端口探测算法：线性递增（最多 10 次），失败上抛；简单可靠，代价可接受。
  • CORS 与 OPTIONS 预检处理；路由严格校验zzz/ddd，仅取请求头 accesstoken。
  • 超时控制（5 分钟）避免悬挂。

• 持久化：

// ... 省略若干
export class StorageService {
    // ...
    public async saveAuthToken(token: string): Promise<void> {
        await this.secureStorage.saveSecret(
            StorageService.CACHE_KEYS.AUTH_TOKEN,
            token
        );
    }
    public async getAuthToken(): Promise<string | undefined> {
        return await this.secureStorage.getSecret(
            StorageService.CACHE_KEYS.AUTH_TOKEN
        );
    }
    public async deleteAuthToken(): Promise<void> {
        await this.secureStorage.deleteSecret(
            StorageService.CACHE_KEYS.AUTH_TOKEN
        );
    }
    public async clearAll(): Promise<void> {
        for (const key of Object.values(StorageService.CACHE_KEYS)) {
           // 遍历清除key值
        }
    }
}

• 在 secrets 中存敏感数据，安全性较高；clearAll() 同时清理多个状态缓存值，防止残留。

3.3 规则知识库工程化

（RuleSyncService）

通过Gtlab维护远程知识库文档，实现知识库聚合，模板/规则“一键对齐”，多包仓不会出现杂乱和上下文丢失等情况。大仓模式下实现批量并发拉取，非大仓模式下实现兜底向上拉取能力。

知识库规则拉取至各应用逻辑

模板拉取过程：GitLab 分批并发，chunk 化

export async function fetchTemplateFiles(
    projectId: number,
    templatePath: string,
    branch: string
): Promise<Array<{ path: string; content: string }>> {
    // git接口获取文件并进行分发同步
}

• 数据结构：数组分块 + Promise.all 并发，有效权衡吞吐与限流风险（每批 5 个）。
• 模板写入（按类型路由到 .cursor/rules/basic.mdc、notepads 或工程根）：

export async function writeTemplatesToDisk(files, templatePath, targetRoot, type?) {
    for (const file of files) {
        // 处理模板写入
    }
    return true;
}

• .gitignore 同步策略（追加不重复的规则）：

export const syncGitIgnoreToPath = async (targetPath: string, ignoreRules: string[]) => {
    // 追加ignore逻辑
};

子应用规则同步至逻辑

监听与同步策略：

public startWatcher() {
  const pattern = new vscode.RelativePattern(this.workspaceRoot, '*/**/.cursor/rules/*.mdc');
  this.watcher = vscode.workspace.createFileSystemWatcher(pattern);
  
  this.watcher.onDidCreate(uri => {
    // 同步变更mdc
  });
  
  this.watcher.onDidChange(uri => {
    // 同步变更mdc
  });
  
  this.watcher.onDidDelete(uri => {
    // 移除指定mdc
  });
}

规则改写：

export function writeRelativePathToContent(content: string, relativePath: string) {
    // 相对路径注入 + 目标文件聚合为 .sync.mdc
}

• 算法说明：
• • 提取 mdc 头中的 globs，对不含路径分隔符的 glob 自动加 /**/，再拼接相对路径前缀，确保规则定位到子包内。
  • 默认兜底 **/.，覆盖子目录所有文件，提升易用性。

• 目标文件命名：

private getTargetPath(fsPath: string) {
  // 针对同步过来的所有mdc文件进行重命名
}

• 将子仓的规则扁平化同步到根目录 .cursor/rules/*.sync.mdc，避免分散规则导致的遗漏。

3.4 远程 webview 与版本编排

（Webview+VersionChecker+Trace）

由于Apex插件的更新需要手动通过dx vs更新，修复问题或有新功能无法实时进行更新，新版本有问题无法回滚及时止损。

Apex通过DNF接口获取当前远程版本webVersion、coreVersion，对比当前local加载版本，实现无感更新或回退。

• 重新加载方式：直接拉取最新版本。
• Tab重新点开，实时检测最新版本，点击更新按钮实现更新。

远程加载逻辑（支持本地调试、回退远端 CDN）：

const v = await fetchWebVersion() || 'latest';
const local = useLocal() && await ping('http://localhost:9527/...');
const js = local ? mapToExternal(local) : cdn(`@apex-plugin/web@${v}`);
return htmlWith(js, csp());

• 关键要点：
• • 从DNF后端接口获取webVersion，优先 USE_LOCAL且本地可访问则映射本地端口。
  • 动态 CSP（当前较宽松，含'unsafe-eval'），满足构建产物运行，未来会按资源域名白名单收紧。
  • 版本编排：Web UI 可独立灰度；插件端仅负责加载版本号对应的资源。

Cursor 版本下限拦截：

export class VersionChecker {
  private static readonly MIN_VERSION = "0.46.0";
  
  public static async checkVersion() {
    const isCursor = vscode.env.appName.toLowerCase().includes("cursor");
    if (!isCursor) {
      return;
    }
    // ... 读取本机 Cursor 安装目录，比较版本，小于阈值弹升级引导
  }
  // compareVersions(v1, v2) 三段位点比较
}

版本注入的位置（可用于埋点/展示）：TraceService.setPluginVersion(v)+ getPluginVersion() 默认读取core package.json。建议在宿主（packages/plugin）激活时注入真实发布版本，确保埋点准确。

3.5 项目服务（ProjectService）：

Monorepo识别、模板拉取与写入

通过识别应用是否是大仓应用，便于后期进行不同类型应用的业务逻辑处理，如知识库同步在大仓下和单仓下的不同分支逻辑是不同的。大仓下子仓的规则会被自动聚合到顶层.cursor/rules下，实现规则命中率显著提升。

Monorepo 识别与项目列表收集方式：

public isMonorepo(): boolean {
    try {
        // 通过判断是否有`pnpm-workspace`判断是否是大仓
        // 获取 package.json 中 workspaces 进行判断是否大仓
    } catch (error) {
        console.error('判断monorepo失败:', error);
        return false;
    }
}

3.6 埋点与活跃情况记录

（LoggerService+UsageRecorder）

通过组合心跳与焦点事件，确保用户离开窗口也能形成完整闭环记录，便于后期进行用户行为画像等分析。

事件监听与活跃态判定：

start() {
  // 开启事件监听记录
  this.eventList = [
    // 多个事件记录绑定...
  ];
}
startInterval() {
  if (!this.walkClocker) {
    this.walkClocker = setInterval(() => { this.reportUsage(); }, this.walkInterval);
  }
}

• walkInterval=30s 的心跳，配合窗口焦点事件强制上报一次，确保离开窗口时记录“单次活跃时长”。

埋点上报示例：

const reportTimenote = async () => {
  // 记录用户活跃情况、包含分支、版本、仓库等等信息
}

性能与可靠性：

• 事件监听广泛但回调轻量（更新时间 + 定时器驱动），无重 IO。
• 远端上报失败未中断主流程，可再考虑指数退避与采样策略。

3.7 Webview 消息编排

（MessageHandler）

MessageHandler 作为 Webview 与服务层的协调者，不承载复杂业务逻辑，单一职责，实现路由 Webview 消息到服务层，支持失败统一回发，前后端协作清晰，便于后期扩展和灰度，有良好的可维护性。

• 获取插件/核心版本：handleGetPluginVersion（从 TraceService.getPluginVersion() + package.json.version）。
• 生成规则：handleGenerateRule→.gitignore 同步 + 模板拉取写入+ AI 角色写入 + README 打开。
• MCP 相关：handleHandleServerConfig、checkMcpList、fetchInstalledMcpList、initRuleMcpConfig。
• 导入提示词：handleImportPrompt写入 .cursor/notepads/note-*.private.md 并辅助插入到 Composer。

四、总结&展望

Apex通过 RuleSync 与 ProjectService 实现CursorRules规则模板一键同步，依托配置化 MCP 加速工具集成和能力提升，以安全令牌与白名单机制强化治理，并借助 UsageRecorder 与 TraceService 提供可观测性，全面支持高效、安全、可控的使用交付与版本去迭代化管理。

Apex 的核心在于“把 AI 真正落在工程实践之中”，以插件为载体打通认证、上下文、CursorRules规则和Cursor；以 MCP 为能力边界实现“配置即扩展”；以可观测为保障推动插件能力持续演进。通过“单例化、配置化、远程化、工程化”的设计原则，让团队在享受 AI 编码效率的同时，最大限度保持工程可控与可治理。

但是受限于智能体执行需要手动触发，开发者可能会存在遗忘执行的情况等，下一步计划智能体执行支持命令行触发，预期试行添加到 git hook中commit提交代码后自动执行，避免遗忘，提升Apex更多可玩性。

#Agent #MCP #智能体

往期回顾

1. 从 JSON 字符串到 Java 对象：Fastjson 1.2.83 全程解析｜得物技术

2. 用好 TTL Agent 不踩雷：避开内存泄露与CPU 100%两大核心坑｜得物技术

3. 线程池ThreadPoolExecutor源码深度解析｜得物技术

4. 基于浏览器扩展 API Mock 工具开发探索｜得物技术

5. 破解gh-ost变更导致MySQL表膨胀之谜｜得物技术

文 /凯

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

XunDoc开发之旅：当AI医生遇上家庭健康管家

当我在生活中目睹家人为管理复杂的健康数据、用药提醒而手忙脚乱时，一个想法冒了出来：我能否打造一个App，像一位贴心的家庭健康管家，把全家人的健康都管起来？它不仅要能记录数据，还要够聪明，能解答健康疑惑，能主动提醒。这就是 XunDoc App。

1. 搭建家庭的健康数据中枢

起初，我转向AI助手寻求架构指导。我的构想很明确：一个以家庭为单位，能管理成员信息、记录多种健康指标（血压、血糖等）的系统。AI很快给出了基于SwiftUI和MVVM模式的代码框架，并建议用UserDefaults来存储数据。

但对于一个完整的应用而言，我马上遇到了第一个问题：数据如何在不同视图间高效、准确地共享？ 一开始我简单地使用@State，但随着功能增多，数据流变得一团糟，经常出现视图数据不同步的情况。

接着在Claude解决不了的时候我去询问Deepseek，它一针见血地指出：“你的数据管理太分散了，应该使用EnvironmentObject配合单例模式，建立一个统一的数据源。” 这个建议成了项目的转折点。我创建了FamilyShareManager和HealthDataManager这两个核心管家。当我把家庭成员的增删改查、健康数据的录入与读取都交给它们统一调度后，整个应用的数据就像被接通了任督二脉，立刻流畅稳定了起来。

2. 请来AI医生：集成Moonshot API

基础框架搭好，接下来就是实现核心的“智能”部分了。我想让用户能通过文字和图片，向AI咨询健康问题。我再次找到AI助手，描述了皮肤分析、报告解读等四种咨询场景，它很快帮我写出了调用Moonshot多模态API的代码。

然而，每件事都不能事事如意的。文字咨询很顺利，但一到图片上传就频繁失败。AI给出的代码在处理稍大一点的图片时就会崩溃，日志里满是编码错误。我一度怀疑是网络问题，但反复排查后，我询问Deepseek，他告诉我：“多模态API对图片的Base64编码和大小有严格限制，你需要在前端进行压缩和校验。”

我把他给我的建议给到了Claude。claude帮我编写了一个“图片预处理”函数，自动将图片压缩到4MB以内并确保编码格式正确。当这个“关卡”被设立后，之前桀骜不驯的图片上传功能终于变得温顺听话。看着App里拍张照就能得到专业的皮肤分析建议，那种将前沿AI技术握在手中的感觉，实在令人兴奋。

3. 打造永不遗忘的智能提醒系统

健康管理，贵在坚持，难在记忆。我决心打造一个强大的医疗提醒模块。我的想法是：它不能是普通的闹钟，而要像一位专业的护士，能区分用药、复查、预约等不同类型，并能灵活设置重复。

AI助手根据我的描述，生成了利用UserNotifications框架的初始代码。但很快，我发现了一个新问题：对于“每周一次”的重复提醒，当用户点击“完成”后，系统并不会自动创建下一周的通知。这完全违背了“提醒”的初衷。

“这需要你自己实现一个智能调度的逻辑，在用户完成一个提醒时，计算出下一次触发的时间，并重新提交一个本地通知。” 这是deepseek告诉我的，我把这个需求告诉给了Claude。于是，在MedicalNotificationManager中， claude加入了一个“重新调度”的函数。当您标记一个每周的用药提醒为“已完成”时，App会悄无声息地为您安排好下一周的同一时刻的提醒。这个功能的实现，让XunDoc从一个被动的记录工具，真正蜕变为一个主动的健康守护者。

4. 临门一脚：App Store上架“渡劫”指南

当XunDoc终于在模拟器和我的测试机上稳定运行后，我感觉胜利在望。但很快我就意识到，从“本地能跑”到“商店能下”，中间隔着一道巨大的鸿沟——苹果的审核。证书、描述文件、权限声明、截图尺寸……这些繁琐的流程让我一头雾水。

这次，我直接找到了DeepSeek：“我的App开发完了，现在需要上传到App Store，请给我一个最详细、针对新手的小白教程。”

DeepSeek给出的回复堪称保姆级，它把整个过程拆解成了“配置App ID和证书”、“在App Store Connect中创建应用”、“在Xcode中进行归档打包”三大步。我就像拿着攻略打游戏，一步步跟着操作：

• 创建App ID：在苹果开发者后台，我按照说明创建了唯一的App ID com.[我的ID].XunDoc。
• 搞定证书：最让我头疼的证书环节，DeepSeek指导我分别创建了“Development”和“Distribution”证书，并耐心解释了二者的区别。
• 设置权限：因为App需要用到相机（拍照诊断）、相册（上传图片）和通知（医疗提醒），我根据指南，在Info.plist文件中一一添加了对应的权限描述，确保审核员能清楚知道我们为什么需要这些权限。

一切准备就绪，我在Xcode中点击了“Product” -> “Archive”。看着进度条缓缓填满，我的心也提到了嗓子眼。打包成功！随后通过“Distribute App”流程，我将我这两天的汗水上传到了App Store Connect。当然不是一次就通过上传的。

5. 从“能用”到“好用”：三次UI大迭代的觉醒

应用上架最初的兴奋感过去后，我陆续收到了一些早期用户的反馈：“功能很多，但不知道从哪里开始用”、“界面有点拥挤，找东西费劲”。这让我意识到，我的产品在工程师思维里是“功能完备”，但在用户眼里可能却是“复杂难用”。

我决定重新设计UI。第一站，我找到了国产的Mastergo。我将XunDoc的核心界面截图喂给它，并提示：“请为这款家庭健康管理应用生成几套更现代、更友好的UI设计方案。”

Mastergo给出的方案让我大开眼界。它弱化了我之前强调的“卡片”边界，采用了更大的留白和更清晰的视觉层级。它建议将底部的标签栏导航做得更精致，并引入了一个全局的“+”浮动按钮，用于快速记录健康数据。这是我第一套迭代方案的灵感来源：从“功能堆砌”转向“简洁现代” 。

然而，Mastergo的方案虽然美观，但有些交互逻辑不太符合iOS的规范。于是，第二站，我请来了Stitch。我将完整的产品介绍、所有功能模块的说明，以及第一版的设计图都给了它，并下达指令：“请基于这些材料，完全重现XunDoc的完整UI，但要遵循iOS Human Interface Guidelines，并确保信息架构清晰，新用户能快速上手。”等到他设计好了后 我将我的设计图UI截图给Claude，让他尽可能的帮我生成。

（以上是我的Stitch构建出来的页面） Claude展现出了惊人的理解力。它不仅仅是在画界面，而是在重构产品的信息架构。它建议将“AI咨询”的四种模式（皮肤、症状、报告、用药）从并列排列，改为一个主导航入口，进去后再通过图标和简短说明让用户选择。同时，它将“首页”重新定义为真正的“健康概览”，只显示最关键的数据和今日提醒，其他所有功能都规整地收纳入标签栏。这形成了我的第二套迭代方案：从“简洁现代”深化为“结构清晰” 。

拿着Claude的输出，我结合Mastergo和Stitch的视觉灵感，再让Cluade一步一步的微调。我意识到，颜色不仅是美观，更是传达情绪和功能的重要工具。我将原本统一的蓝色系，根据功能模块进行了区分：健康数据用沉稳的蓝色，AI咨询用代表智慧的紫色，医疗提醒用醒目的橙色。图标也设计得更加线性轻量，减少了视觉负担。（其实这是Deepseek给我的建议）这就是最终的第三套迭代方案：在清晰的结构上，注入温暖与亲和力。

这次从Stitch到Claude的UI重塑之旅，让我深刻意识到，一个成功的产品不仅仅是代码的堆砌。它是一次与用户的对话，而设计，就是这门对话的语言。通过让不同的AI助手在我的引导下“协同创作”，我成功地让XunDoc从一個工程师的作品，蜕变成一个真正为用户着想的产品。

现在这款app已经成功上架到了我的App store上 大家可以直接搜索下来进行使用和体验，我希望大家可以在未来可以一起解决问题！