产品经理 / 独立开发者 / 协作团队
适合已经开始用 AI 生成 HTML 原型，但仍需要把原型推进到需求评审和研发交付的人群。
🎯 独立设计 · Vibe Coding 落地 · 已上线可体验
H2M
HTML 原型标注与 PRD 评审工具。把 AI 生成的 HTML 原型，从“可看的页面”维护成可标注、可评审、可协作、可交付的产品需求文档。
面向产品经理、独立开发者和协作团队，解决 HTML 原型进入正式产品流程后的需求说明、页面评审、版本迭代和 PRD 交付问题。
HTML to Mark · htmltomark.xyz · Next.js / TypeScript / Supabase
HTML 导入智能标注评论评审PRD 导出
产品总览
H2M 的核心不是生成 HTML，而是承接 AI 生成 HTML 之后的产品协作与交付链路。
AI 可以快速生成网页原型，但原型之后还需要写需求、做评审、收评论、迭代页面并沉淀 PRD。H2M 解决的是这条后半段链路：让 HTML 原型成为可持续维护的产品需求资产。
核心价值：把“页面、需求、评论、PRD”收敛到同一个上下文里，降低原型和文档之间的信息损耗。已上线公网
产品已可访问、可注册、可创建项目、可导入 HTML、可标注需求、可评论协作并导出文档。
完整 SaaS 化产品实践
覆盖编辑器、工作台、账号权限、会员体系、支付账单和官网介绍，具备真实产品闭环。
我观察到的问题
问题不是“AI 能不能生成页面”，而是生成出来之后怎么进入产品流程。
HTML 原型和 PRD 脱节
页面可以直接看，但需求说明、业务规则、验收标准往往还散落在文档、截图和聊天记录里。
评审反馈难以定位
团队经常需要截图、圈红框、口头解释“这个按钮”“那个卡片”，反馈很难和具体元素稳定绑定。
页面迭代后标注容易丢
AI 修改 HTML 很方便，但如果每次都整页重写，之前的需求锚点、评论和 PRD 关联就会变脆弱。
产品定位
H2M 不是 AI 原型生成器，而是 HTML 原型进入团队评审和产品交付的中间层。
HTML to Mark
把 HTML 页面转化为可标注、可评论、可沉淀、可导出的产品需求载体。
从 AI 原型到 PRD
先用 ChatGPT、Claude、Gemini 等工具生成 HTML 原型，再用 H2M 组织标注、评审、协作和交付。
围绕页面元素组织需求
不是从空白文档写 PRD，而是从真实 HTML 页面出发，让需求先与元素绑定，再沉淀为文档。
当前版本核心能力
当前版本优先打通“导入 → 标注 → 评审 → 更新 → PRD → 分享”的完整闭环。
HTML导入、标准化、隔离渲染、多页面管理
Mark元素锚点、需求节点、评论定位
PRD需求树、文档编辑、Markdown 导出
SaaS账号、项目、成员、会员、支付
编辑器能力
- 导入 HTML 原型，在独立画布中保留页面视觉和交互。
- 点选页面元素生成需求锚点，绑定需求描述、业务规则和验收标准。
- 支持评论、回复、状态处理，让评审反馈围绕具体元素沉淀。
- 支持重新导入更新后的 HTML，并尽量保留已有标注关系。
产品化能力
- 工作台、项目创建、项目搜索、页面管理和示例项目。
- 成员邀请、分享协作、角色权限和团队评审入口。
- 会员权益、支付接入、账单记录和使用限制。
- PRD 预览、Markdown 导出、项目数据导出。
产品设计思考
这个项目的关键不是堆功能，而是围绕“HTML 原型如何变成可交付需求”做取舍。
先绑定页面，再生成文档
PRD 不应该脱离原型凭空写。先把需求绑定到具体元素，再把需求树和说明沉淀为文档。
需求锚点和评论锚点分开
需求用于产品说明和 PRD 结构，评论用于评审反馈。二者都指向元素，但职责不同。
保留 HTML 原型真实状态
用户导入的是可交互页面，不是截图。画布需要尽量保留原页面样式、滚动和交互上下文。
版本更新不能破坏历史标注
AI 修改页面是高频场景，所以 H2M 需要关注元素 ID、语义兜底和标注关系保留。
协作闭环优先于纯生成能力
当前重点不是让 AI 自动写完整 PRD，而是先把页面、需求、评论、成员和导出流程跑通。
从工具雏形走向产品化
除了编辑器本身，还补齐登录、项目、权限、会员、支付和介绍页，验证真实 SaaS 产品闭环。
一次典型使用流程
用流程说明 H2M 如何把 AI 生成的 HTML 原型推进到可交付 PRD。
AI 生成 HTML用任意 AI 工具生成网页原型
导入 H2M创建项目并导入 HTML 页面
浏览原型保留页面视觉和交互上下文
添加锚点点选按钮、表单、卡片等元素
编辑需求写描述、规则和验收标准
团队评审围绕元素评论、回复、处理
更新页面AI 修改后重新导入并保留关联
导出 PRD沉淀为 Markdown 文档
技术方案概览
以公开视角展示产品分层，重点说明编辑器、结构化数据和 SaaS 能力如何连接。
前端体验层 Next.js
项目工作台、编辑器、PRD 工作区、分享与会员页面。
HTML 画布隔离渲染，避免原型样式污染产品界面。
左右面板和浮动窗口承接需求树、评论和 PRD 内容。
深浅色主题、响应式布局、导入导出和键盘操作。
编辑器状态层 结构化快照
把页面、版本、需求节点、元素锚点和评论组织为项目快照。
支持多页面管理、版本切换、重导入更新和关系恢复。
需求树与 PRD 文档互相关联，便于后续生成和导出。
为 AI PRD、变更总结和评审摘要预留上下文结构。
云端产品层 Supabase
账号登录、用户资料、项目空间和成员权限。
项目数据持久化、分享链接、成员协作与权限隔离。
会员权益、支付账单和额度控制。
部署到公网域名，支持真实用户访问和体验。
项目落地过程
从场景判断到线上产品，完整覆盖产品定义、体验设计、工程实现和商业化闭环。
从趋势判断到产品机会
判断 AI 时代产品经理会更多使用 AI 生成 HTML 原型，但这些原型仍需要进入需求评审和 PRD 交付流程。
从功能想法到核心流程
确定导入 HTML、点选元素、绑定需求、评论评审、更新页面、导出 PRD 的主链路。
从编辑器到 SaaS 产品
不只做本地工具，而是补齐工作台、账号体系、成员协作、权限、会员和支付能力。
从演示到可访问产品
部署到独立域名，设计官网和产品说明页，让产品可以被真实访问、体验和介绍。
体现的产品能力
趋势判断、场景拆解、MVP 边界、产品定位、协作流程和商业化路径。
体现的 AI 产品能力
理解 AI 生成 HTML 之后的后处理流程，设计与 AI 迭代相容的标注和版本机制。
体现的工程能力
复杂前端编辑器、状态管理、云端存储、账号权限、部署和支付接入。
迭代规划
后续重点不是扩大功能清单，而是增强协作稳定性、上下文质量和 PRD 自动化能力。
近期
编辑器云端同步
完善自动保存、版本恢复、冲突提示和跨设备使用体验。
目标
让项目数据更稳定，减少手动保存和误覆盖风险。
中期
AI PRD 生成
基于页面结构、需求树、锚点和评论生成 PRD 初稿、变更说明和评审摘要。
目标
让 AI 生成不再凭空写，而是基于真实页面上下文。
长期
团队空间与模板
支持团队项目空间、行业模板、评审状态流转和更多导出格式。
目标
从个人工具升级为面向小团队的原型评审工作台。
常见问题
帮助快速理解 H2M 的定位、边界和后续价值。
1. H2M 和普通 PRD 工具有什么区别？
普通 PRD 工具通常从空白文档开始，H2M 从 HTML 原型开始，让需求、评论和验收标准都能指向具体页面元素。
2. 为什么强调 HTML，而不是截图或设计稿？
HTML 原型已经接近研发可理解的页面形态，具备结构、样式和交互。围绕 HTML 标注，能减少从视觉稿到需求说明之间的信息损耗。
3. AI 在这个产品里怎么发挥价值？
当前 H2M 先解决 AI 生成 HTML 后的整理和协作问题。后续 AI 可以基于页面结构、需求树、评论和版本变化生成更可靠的 PRD 与变更说明。
4. 这个项目当前是否已经上线？
已经上线到 htmltomark.xyz，当前版本具备账号、项目、编辑器、分享协作、会员支付和文档导出等能力。