Team AI STAR 回答模板
使用方式
适合回答这类问题：
- 讲一个你主导设计的项目
- 讲一个复杂项目中你如何推进落地
- 讲一个你解决高复杂度问题的例子
- 讲一个你体现 owner 意识的案例
使用建议
- 如果题目偏“主导设计”，优先用模板一。
- 如果题目偏“解决复杂问题”，优先用模板二。
- 如果题目偏“owner 意识 / 推进能力”，优先用模板三。
- 回答时尽量把
S/T/A/R压到 2 到 3 分钟，不要念成流程图。 - 这页统一按“上下文建模优先，执行推进次级”来讲。
STAR 模板一：主导复杂系统设计
S，Situation
当时我们面临的问题是，市面上很多 AI 产品更像聊天助手，能回答问题，但很难真正融入研发交付流程。需求怎么被结构化、任务怎么进入协作、过程怎么追踪、结果怎么回写，这些关键链路都缺少一套稳定上下文。
T，Task
我的任务是基于 Team AI 现有架构，设计并落地一个面向软件交付场景的 AI 上下文工作台。这个系统不仅要支持 AI 参与执行，还要先把 goal、spec、task、card、conversation、trace 这些对象建稳，让人和 AI 基于同一套上下文持续协作。
A，Action
我先把系统核心对象抽象出来，包括 project、goal、spec、task、board、card、session、trace、logical entity、diagram 和 knowledge graph，避免一开始就陷入页面和接口堆砌。 然后我围绕这些对象设计前端工作台，让项目页、看板页、会话页和 trace 视图都围绕统一资源关系组织。 在后端，我参与资源契约、策略校验、状态回流和 SSE 事件流这些关键能力建设，确保前端工作面和后端执行链能闭环。 同时我也补了治理机制，比如 WIP、准入规则、Artifact Gate 和人工审批，确保这个系统不是只会自动化，而是可以被工程团队接受。
R，Result
最终我们把 Team AI 从偏单点 AI 能力的系统，推进成了一个更完整的 AI 上下文工作台原型。它已经能够支持需求 intake、任务结构化、看板推进、执行回写和过程追踪的完整闭环。对我来说，这个结果最重要的不是“做了几个功能”，而是完成了从产品抽象、全栈落地到平台治理的一整套体系设计。
STAR 模板二：解决高复杂度技术问题
S，Situation
这个项目里最复杂的问题之一，是我们不想把 Kanban 只做成状态展示页，而是要让它承载真实的上下文推进。但一旦这么做，卡片移动背后就不只是改状态，而会牵扯策略校验、会话启动、trace 回写和 evidence 补齐。
T，Task
我的目标是把“前端上的状态操作”收敛成“后端上可控的上下文推进动作”，同时保证流程可观测、可追踪，并且不会因为自动化引入更大的失控风险。
A，Action
我先把列本身设计成带阶段语义的对象，而不是简单字符串状态。每一列都可以配置 specialist、provider、准入规则和人工审批要求。 然后在后端实现统一的策略评估逻辑，判断是否超过 WIP 限制、是否允许从某列进入、是否缺少必要 artifact。 对于可以继续推进的任务，再去准备 session 上下文、执行条件和后续回写链路。 同时我补了 SSE 实时事件和 trace / evidence 视图，让前端能持续看到任务迁移、会话启动、执行完成和异常信息。
R，Result
最后我们实现了上下文型 Kanban 的核心闭环。看板不再只是项目管理工具，而是变成了 AI 协同交付工作台里的一个推进面。这个设计也为后续扩展更多 specialist、workflow 和 provider 打下了基础。
STAR 模板三：体现 owner 意识和推进能力
S，Situation
这个项目不是单一模块开发，而是同时涉及前端工作台、后端资源契约、状态回流、协议接入和工程治理。如果只站在某一个子模块视角推进，最后很容易出现链路断裂。
T，Task
我承担的是把这条链路从用户输入目标，一直到任务推进、执行回写和证据沉淀打通，确保系统不是局部可用，而是整体可用。
A，Action
我在推进时不是先做页面或者先做接口，而是先定义核心对象和上下文边界，然后按链路拆解。 先确保 intake 能生成 spec 和 task，再确保 task 能同步到看板，再确保卡片推进能触发执行，再确保执行状态和 trace 能实时回流前端。 如果中间任何一段断掉，整个系统价值都会大打折扣，所以我在推进时一直盯的是闭环，而不是单点功能完成度。 同时我也会提前补治理机制，因为我认为如果一个 AI 流程只能 demo、不能控，那它不算真正可落地。
R，Result
最后项目形成了比较完整的原型能力，也让我在这个过程中积累了比较强的全局视角。我在这个项目里最大的收获，是能从产品、建模、资源、流程和交付五个维度同时看问题，而不只是从单个技术点出发。