AI 课程 04｜升级为 AI Architect：构建生产级个人 AI 系统

这篇先讲什么

• 核心问题：当 Prompt 和单次调用不够用时，怎样进入系统设计层，构建真正可靠的 AI 应用。
• 适合谁：已经理解 Builder 工作流，准备继续做产品、做系统、做生产级 AI 应用的人。
• 读完你会得到：SuperMind 的三大能力、Phase A 到 Phase B 的学习路径，以及生产级 AI 系统的关键架构选择。
• 在系列中的位置：这是第 4 篇，也是这一组课程的收束篇，从工具使用正式进入架构设计。

课程定位：37节进阶课，围绕生产级项目展开。从"会用AI写代码"到"能设计并构建生产级AI系统"。项目名称：SuperMind——一个你自己构建的、市场上买不到的个人AI系统。

第一部分：Introduction——从 Builder 到 Architect

为什么需要"架构师"思维？

你可能已经能用AI做很多事情了，但你可能也遇到了这些天花板：

四大局限（Builder的困境）

局限1：Prompt的脆弱性（Brittleness of Prompts）

• 昨天完美运行的Prompt，今天模型升级后开始输出错误
• 每次重新"调教"AI，没有可持续的解决方案
• 本质：Prompt是手工艺品，不是工程产品

局限2：上下文墙（The Context Wall）

• 通用AI对你一无所知——不知道你的项目历史、个人偏好、内部规则
• 每次对话都要重新解释背景，效率极低
• 本质：AI没有"记住你"的机制

局限3：单次限制（One-Shot Limitation）

• 复杂任务需要：研究→分析→综合→执行，多个步骤
• 简单的单次AI调用无法完成
• 本质：缺乏多步骤编排能力

局限4：单模型孤岛（Single-Model Silo）

• 被锁定在一个提供商的能力边界内
• 不同任务需要不同模型的特长
• 本质：缺乏多模型协同能力

AI Architect的使命：系统性地解决这四个局限。

SuperMind：你买不到的系统

为什么叫"买不到"：

世界上最大的科技公司会给你强大的通用工具。但他们不会、也做不到为你构建一个深度个性化的系统，因为：

• 你的数据是独特的
• 你的工作流是独特的
• 你的目标是独特的

SuperMind的三大超能力：

超能力1：无摩擦交互（Frictionless Interaction）

问题：现在和AI交互需要"打断"你正在做的事——掏手机、打开App、打字——这种摩擦阻止了AI真正融入生活。

愿景：AI应该像空气一样无处不在，在你需要的时候自然地介入，不需要你主动去找它。

三个未来场景：

场景1：社交增强器 你在和朋友聊天，朋友推荐了一部没听说过的电影。你不想打断对话去查手机。一个不被察觉的手势——AI在后台开始深度搜索这部电影。你继续聊天。稍后，你的手表轻振一下，关键信息已经整理好了。

场景2：实时表现辅导 你在一个重要的面试中。面试官问了一个你没准备到的问题。你的耳机里，AI用简洁的语言给了你思路提示。你保持镇定，对答如流。

场景3：个人成长镜子 你每天口述5分钟的工作感悟。一年后，你的AI伴侣可以回答：“从你过去一年的记录来看，你在决策时最常见的思维模式是什么？”

核心设计原则：最好的AI交互，是用户几乎感觉不到的那种。

超能力2：上下文智能/数字孪生（Contextual Intelligence）

问题：每次和AI对话都要从零开始解释背景。通用AI是"知识渊博的陌生人"，不是"真正了解你的伙伴"。

愿景：构建一个AI，它能阅读、理解、推理你的整个数字历史。

可以问的问题（实现后）：

• “回顾我过去三年的所有笔记，我对AI安全的看法是如何演变的？”
• “根据所有会议记录，项目延期最常见的原因是什么？”
• “基于我所有的博客文章，用我的写作风格写一篇关于’如何学习’的总结”

核心技术：RAG（检索增强生成）的Agentic版本

关键区别：

• 普通RAG：上传文件 → 搜索 → 回答（线性的、一次性的）
• Agentic RAG：AI理解你的问题 → 设计多个查询策略 → 综合多个来源 → 推理和综合 → 深度答案

超能力3：主动智能/战略顾问（Proactive Intelligence）

问题：所有现有AI都是被动的——等你问了才回答。真正有价值的助手是主动的。

愿景：构建一个AI，它24/7监控外部世界，理解什么信息对你的战略目标有价值，主动推送真正重要的内容。

一个具体的未来画面：

你是一个做AI视频生成产品的产品经理。某天早上，你收到SuperMind发来的邮件：

战略告警：你的主要竞争对手刚刚发布了实时唇形同步功能。我们当前的产品路线图没有涵盖这一能力。这可能代表一个显著的竞争劣势。技术摘要和相关链接已附上。

这不是普通的新闻聚合。这是意图的自动化——AI真正理解你的战略目标，并从外部噪音中提取对你真正重要的信号。

结构化学习路径：三个阶段

Phase A：揭开核心——构建你的第一个Agentic引擎

• 目标：获得对Agentic系统如何工作的深刻直觉
• 不是为了做出精美产品，而是为了"透视黑盒"
• 你会构建：FastAPI后端 → 连接LLM → 添加工具 → 全栈应用

Phase B：应用与创新——构建你的旗舰项目

• 目标：基于Phase A的理解，创造真实有价值的产品
• 选择三个项目之一深入实现
• 使用生产级引擎，体验真实系统的力量

Phase A’（高级）：打磨生产级系统

• 目标：理解官方引擎背后的"秘密武器"
• 多模型编排、Context Debugger、生产工程
• 可选，适合追求精通的学习者

第二部分：Phase A——构建核心 Agentic 引擎

为什么选择 FastAPI？

AI时代的工具选型原则：不只看性能，更看"对AI是否友好"。

FastAPI的三大AI优势：

优势1：自动生成交互式文档（Swagger UI）

from fastapi import FastAPI

app = FastAPI()

@app.post("/chat")
async def chat(message: str):
    """与AI对话的主接口"""
    return {"response": "..."}

FastAPI自动在 http://localhost:8000/docs 生成可以直接交互的文档界面。

优势2：为AI提供完美上下文

• AI需要理解你的API才能帮你写客户端代码
• Swagger文档精确描述每个端点、参数、返回结构
• AI读这个文档 = 完全理解你的API = 精准生成代码

优势3：戏剧性加速开发

• 你告诉AI"按照这个Swagger文档，写调用/chat接口的Python客户端"
• AI生成的代码质量远高于没有文档的情况

对比没有文档的情况：你说"帮我写调用我的聊天API的代码" → AI凭猜测生成 → 大概率要改好几轮。

构建你的第一个Agentic引擎

步骤1：FastAPI后端骨架

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class ChatRequest(BaseModel):
    message: str
    history: list[dict] = []

@app.post("/chat")
async def chat(request: ChatRequest):
    # 这里接入LLM
    response = await call_llm(request.message, request.history)
    return {"response": response}

步骤2：接入核心LLM

import openai

async def call_llm(message: str, history: list) -> str:
    messages = history + [{"role": "user", "content": message}]

    response = await openai.chat.completions.create(
        model="claude-sonnet-4-6",  # 或其他模型
        messages=messages
    )

    return response.choices[0].message.content

步骤3：添加Agentic工具（网页搜索）

# 定义工具
tools = [{
    "type": "function",
    "function": {
        "name": "web_search",
        "description": "搜索互联网获取最新信息",
        "parameters": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "搜索关键词"}
            },
            "required": ["query"]
        }
    }
}]

# 执行工具调用
async def call_llm_with_tools(message: str) -> str:
    response = await openai.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": message}],
        tools=tools
    )

    # 如果AI决定调用工具
    if response.choices[0].message.tool_calls:
        tool_call = response.choices[0].message.tool_calls[0]
        if tool_call.function.name == "web_search":
            search_result = await do_web_search(tool_call.function.arguments)
            # 把结果返回给AI继续生成
            ...

关键认知：添加了工具调用，你的AI就从"聊天机器人"变成了"真正的Agent"。

核心技能：调试Agent的"思维过程"

问题：Agent系统像黑盒，你不知道AI为什么做出某个决定。

解决方案：成为"日志侦探"（Log Detective）

@app.post("/chat")
async def chat(request: ChatRequest):
    messages = request.history + [{"role": "user", "content": request.message}]

    response = await openai.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=tools
    )

    # 🔍 打印Agent的"思维过程"
    print("=== Agent思维链 ===")
    print(f"用户输入: {request.message}")
    print(f"AI决定调用工具: {response.choices[0].message.tool_calls}")

    if response.choices[0].message.tool_calls:
        tool_result = await execute_tool(response.choices[0].message.tool_calls[0])
        print(f"工具返回结果: {tool_result}")

    final_response = await get_final_response(messages, tool_result)
    print(f"最终回答: {final_response}")

    return {"response": final_response}

这个练习的价值：让你看到AI"读到什么信息"→“做出什么决定"的完整链条。这种直觉是所有高级调试的基础，无法从书本上学到，只能通过构建获得。

比喻：就像你从头组装了一辆汽车，你知道每一个零件、每一根线的位置。这种"机械同理心"是区分真正的Builder和只会用App的人的根本差距。

Phase A 总结

完成Phase A，你拥有了：

• 一个运行在本地的Agentic AI应用
• 对Agentic系统工作原理的深层直觉
• “日志侦探"调试技能
• FastAPI + LLM + 工具调用的完整实现经验

下一步的比喻：你从零组装了一辆汽车，深刻理解了每个零件。现在，我们给你一辆F1赛车（生产级引擎），让你体验它的极限性能，然后带着这些灵感回来升级你自己的汽车。

第三部分：Phase B——三个旗舰项目

核心方法论：Manage-and-Create工作流

在开始任何项目之前，必须掌握这个核心方法论。

把AI当做你的直接下属（不是工具，是团队成员）：

一个好的管理者不会告诉下属每一行代码怎么写。他们掌握三个核心技能：

技能1：先定义成功标准（OKR）

在让AI做任何事之前，先写一份产品简报：

• 核心问题是什么？
• 用户和使用场景是谁/什么？
• MVP（最小可行产品）是什么样的？
• OKR：用什么指标衡量成功？

为什么是最重要的步骤：强迫你在开始之前就想清楚"什么叫做好了”。没有这一步，你和AI都会在模糊中摸索。

技能2：清晰委托（Assignment Brief）

不是告诉AI"帮我实现这个功能”，而是：

• 给出明确的输入/输出规格
• 提供技术约束（用什么库，不用什么库）
• 说明质量标准
• 分解成可验证的子任务

技能3：评估结果（Assessment）

• 不接受"看起来能跑"的结果
• 运行你预先定义的测试用例
• 用指标衡量，不用感觉

项目1：无摩擦交互——对话式副驾驶

核心问题：聪明的想法总在不合时宜的时候出现（开车时、洗澡时、和人聊天时），但捕捉它的摩擦太高，大多数都丢失了。

案例：Aha! Catcher（灵感捕手）

产品简报：

OKR（成功标准）：

• 目标1：零摩擦捕捉
  • KR1：捕捉动作必须是一个简单手势
  • KR2：整个过程对旁观者完全不可见
• 目标2：有用的后续信息
  • KR1：AI必须准确转录音频
  • KR2：AI必须提炼核心想法并进行相关搜索
  • KR3：从手势到笔记可查阅，延迟必须在2分钟以内

技术实现（Apple Watch示例，展示方法论）：

AI架构师不懂Swift也没关系！关键是提问的方式，不是代码本身。

委托Prompt 1（研究阶段）：
我想在Apple Watch上构建一个通过手势触发的应用。
研究watchOS上可用的手势检测API。
有没有内置的系统级手势可以使用？如果有，提供最小代码片段。

委托Prompt 2（实现阶段）：
基于上述研究结果，实现以下功能：
- 检测双击手腕手势
- 手势触发后，开始录制30秒音频
- 录制完成后，将音频发送到 POST /process-audio 接口
- 显示"已捕捉"确认动画

核心洞察：技术（Swift/watchOS）只是变量，提问方法论才是常量。无论什么技术栈，同样的方法都有效。

系统架构：

Apple Watch（手势触发）
    ↓ 音频数据
后端API（FastAPI）
    ↓
Whisper（语音转文字）
    ↓ 文字
GPT（提炼想法 + 决定是否搜索）
    ↓
搜索工具（如果需要）
    ↓
结构化笔记（发送到手机/邮件）

项目2：上下文智能——数字孪生问答系统

核心问题：每次和AI对话都要重新解释背景。你的私有数据（笔记、会议记录、文章）比公共知识更有价值，但AI无法访问它。

案例：个人笔记历史学家

产品简报：

OKR（带指标的成功标准）：

• 目标：确保答案准确且忠实于原始资料
  • KR1：在10个测试问题上，幻觉率 < 10%
  • KR2：创建3个"大海捞针"测试——在大量无关文档中埋入特定事实，系统必须100%找到

为什么是Agentic RAG而不是普通RAG：

技术决策委托：

委托Prompt（研究阶段）：
我需要为本地Markdown文件构建RAG流水线（Python）。
比较LlamaIndex和LangChain的优缺点：
- 开发速度
- 自定义能力
- Agentic功能支持
- 维护成本
给出你的建议和理由。

系统架构：

本地Markdown文件
    ↓ 文档加载器
文本分块（Chunking）
    ↓
Embedding模型（生成向量）
    ↓
向量数据库（FAISS/ChromaDB）
    ↓
[查询时]
用户问题 → LLM理解和分解问题
    ↓ 多次检索
相关文档块
    ↓
LLM综合推理
    ↓
带引用来源的答案

“大海捞针"测试：在1000个文档中埋入一条特定信息，系统必须准确找到它。这是评估RAG系统精度最严格的测试。

项目3：主动智能——战略信息雷达

核心问题：每天有海量信息，你不知道哪些真正与你的战略目标相关。AI应该主动帮你过滤噪音，只呈现真正重要的信号。

愿景：自主Agent的"竞争情报官”

产品简报：

你是AI视频生成领域的产品经理。创建一个agent：

• 24/7监控网络上的竞争动态
• 理解什么信息与你的战略相关
• 主动推送真正重要的警报（不是所有新闻）

AI架构师的关键决策：如何设计"判断力"？

Builder的想法：只要监控包含竞争对手名字的新闻就行了。

AI Architect的问题：这样会淹没在噪音里。真正的价值在于"过滤"。如何让系统判断一条新闻是否真正重要？

解决方案：连接内部上下文

创建一个 background.md 文件，清晰定义你的战略：

# 我的战略背景

我们是一个专注于AI视频生成的产品团队。

## 我们关心的事
- 实时/流式视频生成技术突破
- 唇形同步精度提升
- 竞争对手的新产品发布（重点：Runway、Pika、Kling）
- 关键API或基础模型更新

## 我们不关心的事
- 一般性AI新闻
- 竞争对手的营销活动和PR
- 不影响技术路线的商业融资新闻

两阶段扫描架构（模仿人类分析师的工作方式）：

阶段1：广度扫描（快速+便宜的模型）
    ↓ 从100条新闻中找出10条可能相关的
阶段2：深度分析（强推理模型）
    ↓ 对这10条，对照background.md深度分析
    ↓ 判断是否真正重要、为什么重要
    ↓
生成战略告警（含分析和推荐行动）

OKR：

• 精度（Precision）：被标记为"高重要性"的告警中，真正相关的比例 > 80%
• 召回率（Recall）：在监控期间，没有遗漏任何关键公告

实现框架：

import asyncio
from datetime import datetime

async def strategic_monitor():
    while True:
        # 1. 广度扫描
        news_items = await search_news(queries=[
            "AI video generation",
            "Runway Pika Kling",
            "lip sync AI"
        ])

        # 2. 初步过滤（快速模型）
        potentially_relevant = await quick_filter(
            news_items,
            threshold="any relation to AI video"
        )

        # 3. 深度分析（强推理模型）
        for item in potentially_relevant:
            importance = await deep_analyze(
                item,
                background=load_background_md(),
                model="gemini-2.5-pro"  # 推理能力强的模型
            )

            if importance.level == "HIGH":
                await send_alert(importance.report)

        # 每小时运行一次
        await asyncio.sleep(3600)

第四部分：Phase A’——高级架构

The Context Debugger：你最强大的新武器

背景：Agentic系统强大，但不透明。Phase A里你用的是原始方法——加print语句、盯着终端日志，就像"只靠听声音来诊断发动机故障"，慢且不精确。

Context Debugger是为这个问题专门构建的可视化调试台，也是课程团队在内部答疑时用来拆解复杂AI行为的工具。

它能精确回答的问题

调试时真正需要知道的不是"出错了"，而是哪一步出错了：

• 我的初始Prompt表达不清楚吗？
• 网络搜索工具返回的结果太嘈杂或不相关吗？
• AI误解了搜索结果的含义吗？
• AI在最后一步变懒了或者幻觉了吗？

过去这些问题只能靠猜。Context Debugger让它们变成可以实验验证的假设。

界面结构：卡片序列

将Agent一次完整推理拆解成水平排列的交互卡片：

[用户输入] → [tool_call: web_search("关键词")] → [tool_result: "搜索内容"] → [最终回答]

每张卡片代表推理链中的一个步骤，完整呈现AI的"思维过程"。

三大核心能力

1. 可视化（Visualization） 把终端里混乱的日志流，变成清晰的横向工作流图。一眼看出推理链有几步、每步做了什么。

2. 可操作性（Manipulation）——这是最强大的功能

你可以直接修改任意一张卡片：

• 改tool_call参数：AI搜索词选错了？直接改成你认为更好的关键词
• 替换tool_result：手动输入一个不同的搜索结果，看AI会如何反应
• 禁用某张卡片：把某一步从上下文中完全移除，排查它是否是错误来源

实验示例：“如果我把这条嘈杂的搜索结果从上下文里删掉，AI的最终摘要会变好吗？"——点一下禁用，再生成，立刻知道答案。

3. 可重放（Replayability） 修改完任意卡片后，点一个 Regenerate 按钮，系统用修改后的上下文重新运行最后的推理步骤，立即看到结果变化。

从猜测到科学

这是Context Debugger最根本的价值：把调试从猜测游戏变成受控实验。

你可以像科学家一样提出精确假设并验证：

• “删掉这条嘈杂结果 → AI摘要是否变准？”
• “手动插入一条矛盾信息 → AI是否能识别出来？”
• “修改System Prompt中的某一句话 → 行为如何变化？”

Context Debugger也是学习Prompt Injection攻击和防御的实验台——你可以主动构造注入攻击，然后在Debugger里测试更强健的System Prompt能否防住。

实际调试案例

AI对一个竞品分析问题给出了奇怪的答案。

打开Context Debugger：

• 第1步（用户输入）：问题本身没问题
• 第2步（tool_call）：AI搜索的关键词是"competitor news”（太宽泛）← 问题在这里
• 第3步（tool_result）：返回了大量无关的行业通稿
• 第4步（最终回答）：AI基于噪音内容生成了废话

操作：直接编辑第2步，把搜索词改为"[竞品名] product launch 2025"，点Regenerate。

结果：答案完全不同，这次击中要害。

与手动日志的对比：

多模型编排——AI有"个性"

核心洞察：没有一个模型是所有任务的最优选择。每个模型都有自己的"个性"（AI Personality）。

不同模型的特长（根据实际使用经验）：

这种直觉是Builder的核心竞争力：只有通过大量实际构建，才能真正体会到不同模型的差异。这是一种"内行知识"，文档里学不到。

多Agent系统设计：

async def research_and_analyze(topic: str) -> str:
    # 第1步：用搜索型模型做广度信息收集
    raw_info = await call_model(
        model="deepseek-r1",
        prompt=f"搜索并整理关于 {topic} 的最新信息"
    )

    # 第2步：用分析型模型做深度综合
    analysis = await call_model(
        model="gemini-2.5-pro",
        prompt=f"基于以下信息进行深度分析：\n{raw_info}"
    )

    return analysis

现实类比：在Cursor中，你可能已经习惯了用Gemini写文档、用GPT写代码。这就是多模型编排的最简单形式。将它系统化，就是生产级多Agent系统。

生产级工程——从"我用"到"大家用"

问题：你的数字孪生系统是为"你"构建的。如果再加一个用户，会发生什么？

核心挑战：

• 用户A的笔记和用户B的笔记必须完全隔离
• 系统必须知道"这个请求是谁发的"
• 不能让A查到B的数据

这揭示了一个根本真相：AI要真正成为个人助手，必须首先解决"身份认证"问题。

解决方案：Firebase Authentication

AI架构师的做法（不是传统工程师的做法）：

不是先读几十页官方文档，而是这样委托AI：

委托Prompt：
我需要给我的FastAPI应用添加生产级用户认证。
我想使用Firebase Authentication。

请：
1. 解释Firebase Auth的核心工作原理（3-5句话）
2. 列出需要安装的依赖
3. 提供最小化的集成代码，实现：
   - 验证Bearer Token
   - 从Token中提取用户ID
   - 作为FastAPI依赖项注入到每个需要保护的路由
4. 展示如何在路由中使用这个依赖项隔离用户数据

核心代码模式：

from firebase_admin import auth
from fastapi import Depends, HTTPException, Header

async def get_current_user(authorization: str = Header(None)):
    if not authorization or not authorization.startswith("Bearer "):
        raise HTTPException(status_code=401)

    token = authorization.split(" ")[1]

    try:
        decoded_token = auth.verify_id_token(token)
        return decoded_token["uid"]  # 用户唯一ID
    except:
        raise HTTPException(status_code=401)

# 在路由中使用
@app.get("/my-notes")
async def get_notes(user_id: str = Depends(get_current_user)):
    # 只返回这个用户的笔记
    return db.query(Notes).filter(Notes.user_id == user_id).all()

生产级工程的其他维度：

• 成本优化：监控token使用，自动选择最便宜的满足要求的模型
• 错误处理：网络超时重试、降级策略
• 监控告警：知道什么时候系统出错了
• 性能扩展：缓存、异步处理、连接池

课程结语：你已锻造未来

完成整个AI Architect课程，你拥有：

一、强大的个人工具 SuperMind是一个你会持续使用和进化的系统，不是一次性学习项目。

二、可复用的工程脚手架 下次有新想法，你不从零开始，从你理解、信任的基础出发。

三、有价值的作品集项目 展示你能做系统设计、管理AI项目复杂度、从概念到完成的全流程能力。

四、Builder的直觉 对AI系统的权衡、失败模式、协作动态有直觉理解。这种直觉是这个时代最宝贵的职业资产。

AI Architect要持续追问的三个问题：

1. 我日常生活中还有什么高摩擦的交互，可以变得无摩擦？
2. 还有什么个人或职业数据，可以被集成让我的AI更有上下文？
3. 我有什么长期目标，可以让AI从被动回答变成主动监控？

第八部分：Case and Analysis——学员实战案例

这是课程中最有说服力的部分：真实学员在复杂约束下完成项目，并将踩坑经历整理成了对所有人都有价值的案例。

案例1：何时不该用AI——儿童识字助手的三次架构演进

案例标题：《当5岁女儿说"它坏了"：一个父亲将AI应用延迟从40秒杀到3秒的架构救赎》

核心问题：为什么在AI应用中，找回"确定性"比提升"模型智商"更重要？

背景：一位父亲为5岁女儿开发识字助手App，需要语音交互（说出汉字→AI解释→语音回答），但经历了三次架构迭代：

三次架构对比

❌ V1 积木式堆叠（The Integration Trap）

• 思维：“我有ASR、LLM、TTS三个API，串起来就是AI应用。”
• 实现：HTTP串行调用
• 结果：40秒延迟。用户（女儿）在第3秒就走神了。
• 教训：即时通讯场景，HTTP串行是死路。

⚠️ V2 代理式迷信（The Agent Trap）

• 思维：“LLM很聪明，用Function Call让它自己决定翻牌还是说话。”
• 结果：9.8秒延迟，70%成功率。AI因为上下文过长开始"幻觉"，把函数名读了出来。
• 教训：不要用概率模型去赌确定性的业务流程。

✅ V3 状态机回归（The Architectural Awakening）

• 思维：“翻牌是死逻辑，对话是活逻辑。用WebSocket打通感官，用状态机控制骨架，用AI填充血肉。”
• 结果：<3秒感知的流式体验，100%可靠。
• 教训：架构不仅仅是连接，更是控制权的分配。

讲师点评（核心洞见）

你做出的最关键决策，不是换了Realtime API，而是你敢于承认"AI不是全能的"。

AI架构师的核心工作是控制权分配：

• 创造性任务（鼓励孩子、解释字义）→ 交给LLM（概率模型）
• 流程性任务（翻页、计分、状态流转）→ 交给代码（确定性模型）

把上帝的归上帝（创造性生成），把凯撒的归凯撒（确定性流程）。

你的女儿是你最好的QA，在商业软件中，95%的准确率往往意味着"不可用"。真正的AI架构师不是写更复杂的Prompt——而是拷问目的，围绕目的进行设计和技术选型。

关键概念对比：

• f(x)=y：确定性函数，用代码实现
• P(y|x)：概率性函数，用LLM实现
• TTFB（Time to First Byte）vs Total Time：对用户尤其是孩子，感知到的延迟是首字节延迟，而非总时长

案例2：无摩擦交互的约束探索——为三星手表实现Aha! Catcher

案例背景：三星用户（Galaxy Phone + Watch），非程序员，0 Android开发经验，用半天时间实现了一个想法捕捉App。

痛点：走路、开车时脑子冒出灵感，想用手表录音后自动整理成笔记。

原始手动流程：手表录音 → 手机Voice Recorder App查看 → 点开Transcript → 长按Home键唤醒Google → 圈选文字 → 提问/总结 → 手动留存

设计思路（遵循AI Architect核心思想：先问what and why，写code前先想清楚）：

分析后发现：

• 三星语音转文字识别中英夹杂有待提高，但勉强可用
• 全靠手动只需两三步，不用造轮子
• 最快路径：利用现有生态，在同步后自动AI增强

设想的最佳流程： 手表录音自动同步手机 → App检测手表同步过来的录音文件 → 自动抓取转好的文字 → 丢给Gemini模型做笔记增强 → 存储搞定

四个踩坑经历

坑1：消失的Transcript

• 设想：三星转好的文字在音频文件(.m4a)的metadata里，直接抓取就行
• 真相：三星把Transcript存在Root路径下，只有打开手机App浏览过音频后，才会把文字"写入"metadata
• 对策：放弃"借力"，改为直接把.m4a音频传给Gemini多模态模型，让AI自己听、自己总结

坑2：迟钝的文件同步

• 问题：用FileObserver监听文件夹，时常检测不到手表同步过来的新文件
• 对策：回想课程核心——压根不需要Real-time的笔记！加入Periodic（大时间间隔）和手动scan，既稳妥又省电

坑3：光靠Cursor"瞎猜"

• 问题：Cursor对Gemini model版本瞎试，Free Tier还没跑通就超限了；切回AI Builder Space后，Cursor又乱试API URL（什么www.ai-builders.com都来了）
• 教训：别光信AI，一定要自己看文档！ 告诉AI正确的Base URL后，一改就通

坑4：玄学的Android缓存

• 问题：改了代码跑起来没变化，改了配置还是错
• 真相：Android Studio缓存问题，每次改完都要重启Studio、重新编译、手机端卸载重装App
• 感受：非程序员第一次遭受Android编译的毒打

最终跑通的完整流程

手表一键录音（三星原生App）
    ↓
自动同步：录音文件传到手机 Recordings/Sounds/Watch/
    ↓
后台检测：App监听新来文件或定期扫描
    ↓
AI接管：读取音频 → AI Builder Space语音转文字 → Chat端做笔记增强
    ↓
自动归档：生成 idea_时间戳.txt 存入 Documents/IdeaCapture/
    ↓
通知提醒：手机弹出"💡 New idea captured: [摘要]"，点一下Share到Notion/三星Note

讲师点评

纸上得来终觉浅，绝知此事要躬行，自己得出来的教训跟课堂上学到的又非常不一样。

这个案例完美印证了课程设计理念：只有在复杂和现实的项目中做trade-off、犯错，才能建立起系统直觉。

两个案例的共同教训

附：Phase B 三个项目对比一览