# IELTS Buddy：用可验证的学习闭环设计 AI 工作台

本文依据 2026 年 10 月本地检出的 IELTS Buddy `PRODUCT.md`、产品形态、Agent Runtime 与学习模型文档整理，提炼项目的设计理念。它描述的是项目在这一阶段选择的产品与系统边界，不保证每项能力都已完整上线，也不要求新项目复制 AI 工作台。需要多应用架构、BFF 与发布经验时，继续看[扩展工程经验](./development-experience.md)。

## 从学习结果倒推功能，而不是从功能列表倒推导航

IELTS Buddy 希望用户持续知道四件事：离目标还有多远、今天该学什么、练习暴露了什么问题、下一步怎样行动。因此，一个功能不能只提供入口和内容；它还要说清楚用户如何开始、完成后留下什么证据，以及这份证据如何进入复盘、足迹或后续安排。

例如，做题不止于“提交成功”。作答和结果要关联到稳定的练习记录，AI 才能根据真实错题与逐题证据解释问题，并建议下一次练习。课程进度、模考结果和生成的资料也应各有明确归属。**闭环的最小单位是一次可追溯的学习行动，而不是一张新页面。**

这对新项目的启发是：先写下用户完成任务后会发生什么，再决定需要哪些页面和数据表。若结果没有去向，新增导航项通常不能改善核心体验。

## AI 协调任务，业务界面承载操作

项目把登录后的普通业务能力放在同一个工作台：左侧对话理解目标、串联能力与解释结果；右侧面板承担筛选、输入、编辑、审阅等具体操作。AI 可以打开能力、读取其可观察状态、执行已注册的动作，但不要求用户在聊天气泡中完成复杂表单。技能工具箱提供可见入口，避免所有功能都依赖用户“会提问”。

普通能力使用稳定逻辑地址，以便直达和恢复；地址本身不必对应独立全屏页面。模考答题需要长时间连续专注，因此使用独立的专注流程。窄屏一次只呈现对话或当前任务，并保留返回与恢复任务的能力。这里的判断标准是任务是否需要上下文连续性、操作空间和低干扰环境，而不是技术上能否做成一个页面。

可借鉴的原则是让 AI 成为现有业务能力的协调者，同时保留用户能看懂、能检查、能直接操作的界面。只有一个简单任务的新产品，可以先用普通页面和少量 AI 辅助，不必先造完整工作台。

## 让建议依赖学习证据，而非聊天印象

项目区分三类容易混淆的信息：长期记忆保存用户明确表达且相对稳定的目标、偏好与约束；练习、模考、课程等业务记录保存实际发生的学习事实；能力画像与复盘从这些事实形成当前判断。AI 推荐内容时应读取相应事实，不能把一句鼓励、一次聊天猜测或目录里存在某道题，当成用户已经掌握某项能力的证据。

网页 Agent 与本地 Agent 可以使用不同运行时和学习策略，但共享受控的业务能力、稳定对象引用与学习事件。正式网页练习由服务端记录其提交事实；外部 Agent 只能记录自己产生的学习证据，不能冒充服务端完成事件。这样，“谁观察到事实、谁有权写入事实”始终清楚。

对于没有多端 Agent 的项目，不必照搬事件同步体系；至少应把用户陈述、实际行为和系统推断分开保存，并在推荐时标明依据。

## 模型负责理解，系统负责确定性边界

Agent Runtime 的取舍是让模型判断意图、是否追问、需要哪个能力以及如何解释工具结果；运行时负责会话顺序、工具注册、输入校验、权限、幂等、持久化和审计。业务数据仍由各自领域负责。服务端不靠关键词、按钮来源或隐藏状态机替模型决定对话路径，也不允许模型绕过业务写入规则。

能力按需加载进一步保持这个边界：Skill 提供“怎样完成任务”的方法，Domain 提供“能读取或改变哪些业务事实”，Tool 执行受类型约束的具体操作。用户问“结合我的薄弱项安排学习”时，需要先取得真实能力证据与可用内容，再选择具体任务并写入计划；不能从题目名称猜一个 ID，也不能凭空补默认目标。若用户给的信息已经足够，就直接推进；只有缺少会改变结果的关键信息时才追问。

这套划分适合能力多、需要长期对话的产品。小项目可以从少量清晰工具开始，等方法、数据权限和执行职责真的发生冲突再拆层。

## 每次交互只推动一个清楚的下一步

IELTS Buddy 的陪伴感来自连续理解、基于证据的认可和任务完成后的接续，而不是拟人文案或大量功能卡片。默认突出一个最明确的下一步；用户需要比较时再展开备选。卡片只是业务结果的简短投影，快捷按钮只是等价于用户输入的文字入口，不额外改变权限或执行规则。能用当前上下文判断的事，不再让用户重复填写。

界面层同样让内容和任务优先：学习空间、笔记本、Thread、Skill 等内部组织对象可以为资料和执行提供结构，但不必都升为一级导航。新增能力前先回答它从哪里进入、AI 能读写哪些状态、完成后结果去哪里。回答不清时，先补足任务闭环，再加入口。

## 给新项目和 Agent 的采纳顺序

1. 写出用户要完成的核心任务和完成后的可观察结果。
2. 指定业务事实的所有者，并区分用户陈述、行为证据与推断。
3. 先实现一条“进入 → 操作 → 记录 → 复盘 → 下一步”的最小链路。
4. 当跨功能衔接成为真实需求时，再让 AI 读取状态、调用受控动作。
5. 只有长时专注、多端同步或能力过多等问题实际出现时，再引入专注路由、事件协议或渐进式能力加载。

本篇主要核对 `IeltsBuddy/PRODUCT.md`、`docs/product/product-shape.md`、`docs/product/agent-learning-v1.md`、`docs/architecture/agent-runtime-principles.md`、`docs/architecture/progressive-agent-capability-loading.md` 和 `docs/architecture/workspace-routing.md`。其中产品原则与运行时规范表达了设计意图；目标项目采用前仍应以其当时的代码、数据契约和用户任务重新核对。