Inflight：给原型补上反馈层，让AI编码代理直接接需求

原型评审的痛点在于反馈的「最后一公里」：设计稿能评论，但跑起来的原型不能；视频能录屏，但说的和改的对不上。Product Hunt 上排名第 9 的 Inflight 想补的正是这一层——让评审者直接在运行中的应用上标注，再把反馈通过 MCP 交给 Cursor、Claude Code、Codex 这类编码代理去执行。

它解决的是哪一段断裂

传统原型反馈流程大致是：发送预览链接 → 评审者在群里口述或邮件描述问题 → 设计师/开发者自行定位元素 → 改完再发一轮。问题出在「描述」到「定位」之间：评审者看到的是「这个按钮点了没反应」，落到代码里是哪一行，全靠沟通弥补。

Inflight 的做法是把评论钉在真实 DOM 元素上。评审者打开预览链接或 HTML 原型，在运行中的应用里选中具体元素挂评论，或者直接录一段视频说明交互哪里不对。评论与元素、页面状态绑定，而不是飘在聊天记录里。

这一步并不新鲜——Figma 早已在静态设计稿上做了同样的事。Inflight 的差异在于对象是「跑起来的应用」，评论天然带有运行时上下文：哪个路由、什么状态、点击后发生了什么。

「真实 DOM 元素」指的是浏览器根据 HTML 文档解析生成的对象树，页面上每个可见元素（按钮、输入框、图片等）都对应树中一个节点，并携带 id、class、层级关系等属性。把评论钉在 DOM 元素而非截图像素上，意味着反馈天然带有可被程序解析的定位信息——是哪个节点、在哪个路由、处于什么状态。这正是后续交给编码代理时「知道哪里不对」的结构化基础，也是它与截图批注类工具的本质区别：截图批注定位到坐标，DOM 批注定位到节点。

MCP 是它真正的杠杆

如果只做到「原型上可评论」，Inflight 只是一个更细分的标注工具。它把反馈接进编码代理，才是产品定位里「缺失的一层」的含义。

据官方描述，Inflight 会把评审反馈整理成可执行的下一条任务，编码代理通过 MCP（Model Context Protocol）拉取这些内容。也就是说，反馈不再止步于一份待办清单，而是直接进入代理的工作上下文，由 Cursor、Claude Code、Codex 这类工具接手修改。

这个链路的价值在于减少人工转译。评审者的原话、所指向的元素、当时的页面状态，作为结构化输入交给代理，比「把评论复制到 prompt 里再解释一遍」的损耗更低。对已经在用编码代理的团队来说，这是把评审环节接进现有工作流的低成本方式。

需要说明的是，官方并未披露反馈如何映射到具体代码位置、代理侧需要多少人工确认。MCP 解决的是传输和上下文供给，从「知道哪里不对」到「正确改掉」之间，仍然需要人把关。

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年底提出并开源的开放协议，用于在 LLM 应用与外部工具、数据源之间建立标准化的连接方式。可以把它理解为「AI 版的 USB-C 接口」：编码代理（MCP 客户端）通过统一协议向外部服务（MCP 服务器）请求上下文或执行动作，无需为每个数据源单独写集成代码。在 Inflight 的场景中，评论、元素定位、页面状态等评审反馈被封装为 MCP 服务器上的资源或工具，Cursor、Claude Code 等代理即可在自身工作上下文中按需拉取，而不用人工把内容复制进 prompt。这一层标准化是「反馈直接进入代理工作流」得以成立的技术前提。

适用场景与边界

Inflight 的定位决定了它的适用面比较具体。适合的场景包括：需要多方确认的交互原型评审、远程团队对同一预览链接的异步走查、以及已经把编码代理纳入日常开发流程的团队。113 个投票和 11 条评论说明它切中了一部分人的真实需求，但还谈不上大众工具。

不太适合的情况同样明显。纯静态设计稿评审有成熟工具；如果团队还没用上编码代理，MCP 这条链路的价值会大打折扣，产品就退化为一个原型标注工具。此外，把评审反馈自动喂给代理修改代码，涉及谁来审核、改动范围如何控制的问题，流程上需要额外约定。

值得关注的信号

Inflight 代表的是一类正在成形的产品思路：AI 编码代理能力变强之后，瓶颈从「写代码」前移到「说清楚要写什么」。谁能把人类意图更无损地转成代理可消费的输入，谁就占住了一个新位置。反馈层是其中一个切口，评审、测试、监控反馈都可能沿着 MCP 这类协议接进代理。

对开发者而言，这类工具的实际价值取决于两点：反馈结构化的质量，以及代理执行的可靠度。前者 Inflight 已经给出了方案，后者还要看真实使用中的表现。