Team AI 项目整体怎么讲
使用方式
- 这页只保留“怎么给项目定性”的最短口径。
- 主稿统一去 Team AI 项目逐字稿，高频追问统一去 面试官追问 Team AI 时怎么答。
推荐定性
项目定性
Team AI 最稳妥的讲法，不是普通 AI 聊天工具，也不是纯多智能体编排平台，而是一个面向软件交付场景的 AI 上下文建模平台 / 交付工作台。它的重点不在单次生成能力，而在于把 goal、intake、spec、task、card、conversation、trace 和 resource 这些对象组织成稳定上下文，让 AI 在不同阶段都能基于同一套事实继续工作。
指向原始笔记的链接
最稳妥的展开顺序
- 先讲项目定性
- 再讲你具体负责什么
- 再讲最难的地方
- 最后用一句收口把项目价值钉住
快速口径
3 到 5 分钟版本
如果让我用 3 到 5 分钟介绍 Team AI，我会把它定义成一个面向软件交付场景的 AI 上下文建模平台 / 交付工作台，而不是普通 AI 聊天工具，也不是单纯的编排平台。它想解决的核心问题是：AI 在真实研发流程里经常拿不到连续、稳定、结构化的上下文，所以很难持续参与需求、拆解、执行、review 和回写这整条链路。
所以我们一开始做的不是先接几个 agent，而是先把交付对象建稳。像 project、goal、spec、task、board、card、conversation、session、trace、resource 这些对象，都要先有清楚的边界和关系。这样 AI 拿到的就不只是一个 prompt，而是一套可以逐步展开、持续回写、能被人和系统共同消费的上下文。
我在这个项目里做的是全栈和平台化工作。前端这边，我负责项目工作台、Kanban、卡片详情、会话页、trace 视图这些上下文界面；后端这边，我也参与资源契约、策略校验、状态回流和 SSE 事件流，让前端上的动作不只是改个状态，而是真正更新上下文并稳定回写。
这个项目最难的点，不是接入 AI 本身，而是把“对象、上下文、执行、证据”这四件事做成一套闭环。比如看板不是简单状态板，而是在表达当前阶段、缺失 evidence、准入规则和下一步动作；会话、trace 和 artifact 也不是孤立页面，而是在持续补齐执行证据。
所以如果总结 Team AI，我会说它最有价值的地方，不是让 AI 多做一步生成，而是先把交付上下文稳定下来，再把 AI 纳入一条可治理、可追踪、可回放的交付链路里。
指向原始笔记的链接