项目 3 到 5 分钟版本

使用方式

• 这页只保留四个项目的 3 到 5 分钟版本。
• 如果面试官继续追问，直接跳到对应项目的 深挖版本。
• 默认优先级：Team AI → SDK / 低代码平台 → HATEOAS。

Team 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 纳入一条可治理、可追踪、可回放的交付链路里。

指向原始笔记的链接

SDK

3 到 5 分钟版本

如果让我用 3 到 5 分钟讲 SDK 这条线，我通常会以埋点 SDK 为主，因为它最能体现我在模型设计、基础设施和平台治理上的能力。这个项目我不会讲成“封装一个 track() 方法”，而会讲成：怎么把业务里的用户行为稳定地翻译成一套可分析、可治理、可长期演进的事件语言。

这个项目最先要解决的不是 transport，而是事件模型。很多团队一开始做埋点，都是谁要分析数据，谁就在页面里补一个事件。短期接入很快，但长期会失控，因为事件名、字段口径和语义都会越来越散。所以我更倾向于把事件分层：底层保留 click、exposure、route-change 这类技术事件，但业务层尽量往“订单已提交”“任务已完成”这种稳定业务事件或领域事件靠。

在这个基础上，SDK 本身我一般会拆成四层。第一层是事件定义层，负责事件名规范、字段 schema、版本控制和分类。第二层是上下文层，自动补齐页面、来源、用户、设备、实验桶、会话这些公共字段。第三层是采集层，支持手动埋点和必要的自动采集。第四层是上报层，也就是队列、批量、重试、采样和 sendBeacon 兜底这些 transport 能力。

我觉得这个项目里最容易被低估的点，其实是数据质量治理。埋点最怕的不是少一点，而是看起来很多，实际上不能分析。所以我会补 schema 校验、必填校验、事件去重、调试面板和灰度抽样对账，让数据在进入分析平台之前就尽量可用。

所以如果总结这条线，我会说 SDK 的价值，不是把事件发出去，而是把业务行为稳定地表达、采集、校验和分析，让后面的分析平台、告警平台和业务决策真正建立在一套可信的数据语义上。

指向原始笔记的链接

低代码平台

3 到 5 分钟版本

如果让我用 3 到 5 分钟介绍低代码平台，我不会把它讲成一个拖拽编辑器，而会讲成一套把页面搭建能力、配置能力和业务联动能力工程化的系统。它要解决的核心问题是：企业里大量表单、表格、仪表盘和详情页都在重复开发，如果每次都从零做，交付慢、复用差，而且很多变化其实只是字段和规则不同。

所以我通常会把低代码平台拆成四层。第一层是协议层，也就是 schema / DSL，定义组件树、属性、事件和数据源。第二层是物料层，也就是组件注册中心，让每个组件除了渲染器，还有默认 schema、属性面板和校验规则。第三层是编排层，也就是编辑器和拖拽引擎，负责插入、移动、删除、撤销重做这些编辑行为。第四层是运行时层，负责把 schema 真正渲染出来，并跑通事件和数据联动。

这里最核心的不是拖拽本身，而是“编辑动作怎么稳定地落成 schema 变更”。所以我会把它理解成一个状态变更系统，而不是一个 DOM 交互系统。像精确插入、命中判断、撤销重做、版本管理、编辑态和运行态分离，这些都建立在底层协议稳定的前提上。

这条线另一个很有价值的点，是它天然会延伸到公式编辑器和表达式引擎。也就是说，低代码平台不只是让页面能搭出来，还要让变量、规则、联动和表达式真正跑起来。所以我会把公式编辑器看成平台里的深挖点，而不是另一个独立项目主轴。

所以如果总结低代码平台，我会说它最能体现能力的地方，不是拖拽做得多炫，而是有没有把 schema、编排引擎、运行时和扩展机制真正打通，沉淀成团队可以长期复用的平台能力。

指向原始笔记的链接

HATEOAS

3 到 5 分钟版本

如果让我用 3 到 5 分钟讲 HATEOAS，我不会把它讲成“后端多返回了几个 _links”，而会讲成：我在一个多消费端项目里，把前后端通信从“基于路径的接口调用”，升级成了“基于语义关系的资源导航和动作发现”。

这个项目要解决的核心问题，是前端大量手写 URL、手写动作、手写表单，导致接口一变，页面就很脆；同时不同客户端和 AI Agent 也很难共用一套 API 能力。后来我们让后端返回 HAL / HAL-FORMS 资源，除了数据本身，还提供关系链接和动作模板；前端则不再手工拼路径，而是通过 follow(rel) 做语义导航。

这里真正有价值的点，不只是后端改了响应格式，而是前端把这套模型真正消费起来了。我们抽出了独立的 TypeScript client 和 React hooks，让资源关系导航、分页关系消费、动作模板解析、请求去重和缓存都能围绕同一套资源语义工作。这样 breadcrumb、sidebar、动态表单这些 UI 能力，也可以随着资源关系一起长出来。

我觉得这条线特别适合 AI 和多消费端场景。因为普通 REST 更适合人类开发者对着文档手写调用，而 HATEOAS + HAL-FORMS 更适合客户端或 AI Agent 在运行时发现“当前这个资源还能做什么”。当然，这种设计也不是银弹，对简单后台系统可能偏重，所以我会把它讲成一个面向多消费端、动作可发现、接口演进频繁场景的工程化取舍。

所以如果总结 HATEOAS 这个项目，我会说我做的不是“用了一个 API 风格”，而是把前后端协作从路径耦合升级成了资源导航和动作发现，并且前端真正把这套契约消费成了可复用的工程能力。

指向原始笔记的链接