面试官追问 Team AI 时怎么答
维护说明
- 这页作为 Team AI 高频追问的统一口径。
Team AI 项目整体怎么讲统一引用本页，不再重复维护同一套答法。
项目定性
Team AI 最稳妥的讲法，不是普通 AI 聊天工具，也不是纯多智能体编排平台，而是一个面向软件交付场景的 AI 上下文建模平台 / 交付工作台。它的重点不在单次生成能力，而在于把 goal、intake、spec、task、card、conversation、trace 和 resource 这些对象组织成稳定上下文，让 AI 在不同阶段都能基于同一套事实继续工作。
你具体负责什么
我一般会把自己的工作拆成三块。第一块是前端上下文工作台，也就是项目页、看板页、会话页、trace 视图和建模工作面这些交互界面；第二块是后端资源契约和状态回流链路，包括 intake、策略校验、事件回写；第三块是把这两层串成闭环，让前端上的操作不只是改状态，而是真的能更新上下文、触发执行和承接治理逻辑。
如果岗位更偏平台前端，会怎么补一句
如果按 Agent 平台前端岗位来讲，我会再补一句：我负责的不只是页面实现，而是整个平台前端上下文工作台的设计开发，包括项目页、Kanban、会话页、trace / workflow run 可视化，以及项目级上下文下的数据隔离、状态回流和证据展示。
最难的地方
我会说最难的不是页面数量，也不是接几个 agent，而是把“对象、上下文、执行、证据”这四件事做成一套完整闭环。因为只要其中任何一段断掉，这个系统就会退化成一个看起来很热闹、实际上不太可控的 AI demo。
为什么适合讲全栈
因为这个项目的价值不是单独落在前端界面或后端接口上，而是落在一条完整闭环上：前端负责把上下文工作面稳定表达出来，后端负责资源契约、策略校验、上下文装配和 SSE 事件流，最后还要让状态、证据和结果稳定回流到同一套界面。这个链路天然就是全栈问题。
核心亮点
- 上下文建模：不是先接 agent，而是先把 goal、spec、task、card、trace 这些对象建稳，让 AI 不只靠临时 prompt 工作。
- 上下文型 Kanban：看板不只是状态展示，而是在表达当前阶段、缺失 evidence、准入规则和下一步动作。
- 实时可观测：通过 SSE 事件流把任务迁移、会话启动、执行完成和异常信息持续回流前端。
- 流程治理：通过 WIP、entry policy、artifact gate 和人工审批，让 AI 执行不是“能跑就行”，而是可控、可追踪、可复盘。
- 全栈统一模型：前后端围绕 project、task、session、board、trace 这些对象做统一表达，避免页面逻辑和后端脚本各自为战。
如果继续扩充
我不会先从“再加几个 agent”开始，而会先补三类能力。第一类是输入端的 intake 和 spec 质量，让目标进入系统时就更结构化。第二类是资源契约和上下文装配，让不同工作面和不同执行阶段都能拿到最小充分上下文。第三类是 evidence、review 和 trace 这套治理闭环，让系统不仅能执行，还能更稳定地校验、审计和复盘。
一句收口
我会把 Team AI 定义成一个以项目上下文为骨架、以 Kanban 和会话为工作面、以策略治理和实时回流为边界的 AI 原生软件交付工作台，而不是一个聊天窗口或者简单任务板。