学习过程藏在对话里
最终作业看不出中间经历了哪些困惑、尝试和绕路，导师很难给到恰当支持。
Internal project brief · 2026.07
让技术助教看得见过程，
让学员更能自己解决问题
WorkBuddy Copilot 是围绕学习过程的轻量支持系统：学员继续在 WorkBuddy 中学习，系统在旁边收集必要信号、给出恰当提醒；导师则在一个观察台里把握全局，并在关键时刻发出一条有针对性的提示。
40+ 学员需要被持续支持的真实学习现场
17–18 位导师每位都可观察整体，而非各守一段
一个中心服务把零散过程变成可用的共同视图
双向闭环不仅能看见，也能低打扰地回应
01 · WHY
问题不是“没有 AI”，而是支持发生得太晚
学员卡住、反复试错或描述不清时，导师往往只能在事后从结果猜原因。WorkBuddy Copilot 想把有价值的过程信号变得可观察、可回应，而不是再增加一个复杂系统。
重复问题挤占导师注意力
提示词怎么写、工具如何配置等基础问题，本可由上下文充分的 AI 先接住。
规模一上来，支持容易失焦
当几十位学员同时前进时，单靠走到身边、手动问询，很难保持一致的支持质量。
展开：项目到底要替技术助教接住什么
适合 AI 先接住
提示词如何改、工具怎样配置、已有上下文足够的基础追问。目标是减少重复解释。
仍需要人来支持
复杂操作、关键判断、需要现场陪伴或无法从上下文确定的实际问题。
AI 为什么需要过程
只有结合对话、当前任务状态和协作最佳实践，建议才不会变成脱离现场的泛泛回答。
02 · METHOD
不是监控面板，而是一条低打扰的支持闭环
系统只在已有学习流程旁边增加一条“信号 → 理解 → 提示 → 改进”的链路。学员不用切换工作方式，导师也不必盯住每一段对话。
01
旁路采集
学员照常使用 WorkBuddy；客户端把必要的对话事件送入支持链路。
02
集中理解
服务端统一整理上下文，识别卡点、提问和可改进的学习模式。
03
双端呈现
导师看全局与时间线；学员浮标只显示和自己当下有关的轻量信息。
04
精准回应
导师可向某位学员发提示；学员收到后继续推进，形成下一轮学习信号。
核心原则
AI 先承接重复、基础、上下文明确的问题；人把注意力留给复杂操作、判断和真正需要陪伴的节点。这既是导师效率工具，也是让学员更好地自主求助的学习工具。
展开：从学员提问到导师提示，原型里已经有什么
学员侧
Mac 原型以 WorkBuddy 旁的浮标为入口：看最近任务、主动提问、接收轻量建议。
导师侧
在中心观察台查看多位学员的会话与过程线索；AI 回复可按需展开，不用默认占满视线。
干预侧
导师可以生成学习诊断并向指定学员发送提示，避免把全员通知变成新的打扰。
03 · ARCHITECTURE
一张图看懂：信号如何进来，支持如何回去
当前目标架构不要求大家先理解代码。只需抓住三件事：学员端负责采集和接收，中心服务负责统一事实与判断，导师端负责观察与干预。
目标架构 · 从信号到回应
正向信号导师回应断线后补拉
← 左右滑动查看完整架构图 →
数据边界：服务端只处理学员端上报的内容，绝不去读取学员电脑上的 WorkBuddy 数据库或文件。
可靠送达：导师消息先保存，再实时推送；网络不稳时学员端会补拉，处理完成才回执。
历史原型 · 仅作背景
从单机原型和本地数据假设出发，适合快速验证，不适合多机协作。
当前目标 · 实施依据
把采集留在学员端，经公网进入中心服务；导师观察与学员浮标从同一份服务端事实获得更新。
展开：为什么现在要这样分层
为了多机协作
几十位学员和多位导师通过公网接入，不能再依赖某一台机器的本地数据库或局域网假设。
为了准确隔离
导师可观察整体；但每一条反向提示都必须按学员定向，其他浮标不应收到。
为了不静默丢消息
实时连接加快反馈，持久化与回执决定最终是否送达；断线后仍能恢复。
04 · PRODUCT
两端看到同一段学习过程，但各自只看到需要的部分
导师端的重点是全局观察和精准干预；学员端的重点是当下会话、轻量建议和不打扰的入口。
从左侧选定学员与会话，在右侧阅读过程线索、查看诊断，并在真正需要时写一条针对性的提示。
浮标留在 WorkBuddy 身边：看当前建议、查看导师提示、主动向技术助教提问，而不替换原本的工作流。
展开：两端界面各自解决什么问题
- 导师端：从“到处问、靠记忆找线索”变成在一个页面中定位会话、过程、诊断和要发送的提示。
- 学员端：不另起复杂工具，只在 WorkBuddy 当下的工作现场提供最近会话、建议、导师信息与主动求助入口。
- 共同约束：导师能看到全局不等于所有人收到同一条消息；界面只显示角色真正需要的信息。
05 · LATEST ALIGNMENT
最新团队共识：先在真实营地里把它打磨好
下面来自 2026-07-13 的 WorkBuddy 项目讨论笔记，已浓缩为可执行的共同认识，而非会议转写原文。
1
目标不变：帮助技术助教减少重复劳动，也让学员能基于上下文更自主地向 AI 求助。
2
协作方式：不只按前后端分工；鼓励每位参与者做可用的全闭环版本，在真实使用中赛马、择优、合并。
3
测试方式：可将不同版本分配给不同学员小组，持续收集体验，再把有效能力合回主线。
4
整合空间：已有的飞书问卷与任务卡雏形可补足营期任务上下文，作为后续协同方向。
展开：如何把“赛马式开发”变成可合并的成果
- 每位参与者先做一个闭环：不只是单独补一个页面或接口，而是能让真实学员走通一条支持路径。
- 按学员小组验证：不同版本可在小范围真实使用，收集体验和问题，不把选择建立在主观印象上。
- 把有效能力合回主线：复用地图和测试判据就是合并前的共同语言，避免把旧假设和不可验证的改动带回来。
06 · TECHNICAL
给开发同事：先知道分工，再按需展开实现细节
下面三块是参与开发时最先要守住的边界。卡片先用一句人话说明，展开后才进入实现层面的约束。
三个端，各做一件事
采集和接收留在学员端；整理和分析放在中心；观察和干预放在导师端。
中心服务只有一个事实源
服务器不碰学员电脑的本地文件；所有可用状态以服务端数据库为准。
“发出”不等于“送达”
导师消息先持久保存，实时推送只是加速；最终以学员处理后的回执为准。
展开：模块职责
- 学员端：Hook 只做轻量收集；共享核心处理暂存、传输、重连和回执；浮标负责呈现。
- 中心服务：负责鉴权、解析、学习分析、消息编排和统一数据存储。
- 导师端：浏览器静态页面，读取全局过程、发送定向提示并显示送达状态。
展开：数据边界
- 学员机：只从明确已知的位置读取本机信息，失败时不阻塞 WorkBuddy。
- 服务端：只接收上报内容并写入
copilot.db，这是唯一权威数据源。 - 公网：学员与导师走 HTTPS/WSS；两种角色使用不同身份令牌。
展开：消息可靠性
- 先落库：导师写下的消息先被保存，学员离线也不会直接丢失。
- 再推送：在线时通过实时通道快速抵达目标浮标，不广播给其他学员。
- 最后确认：学员端实际渲染后才回执；中断时用补拉继续完成。
07 · JOIN
现在可以怎样加入开发
先从真实使用路径切入：完善学员端体验、提升导师观察与干预、补齐跨平台证据，或把营期任务上下文接入到这条支持闭环。
服务端唯一事实源与反向消息链路已落地
macOS 学员端原型与导师端界面已有可见原型
Windows 真机数据与发布验证需要真实设备证据
营期任务卡 / 问卷上下文整合待评估协同方式