需求与验证入口

当前阶段：按当前页面的数据与操作收敛设计，并修复已复现问题。 用户在同日进一步纠正：不要查看有多少文档，而要从前端实际展示多少数据、有哪些需求、怎样设计数据库出发，替换历史冗余设计与实现。以页面PRD和收敛方案为当前依据；任务状态只在BACKLOG。先前关于云收藏、批次、四档相关性等未实施扩展已撤出当前实施建议。

下方保存阶段原话作为来源证据，不把历史的“当前”“本轮”当作现在的派发指令。

2026-10-08 全站页面需求整理

来源：当前项目聊天，本人原话：

先将代码提交到main并推送，然后我需要你根据我们的页面进行每个页面中需要哪些功能列入表格中，进行详细的需求的分析，并使用 @pm-execution 将我们的需求整理，以及详细的数据库设计，接口设计，需求分析，功能性分析，非功能分析等，这些都是我们需要的，并且每一个页面中的需求都需要持久化到我们的项目中

沿用上一轮明确要求的 Figma 桌面稿、shadcn 与 Vercel 规范，覆盖现有52个页面入口。需求产物放在现有 workspace/content；不在父工作区、App 或其他位置新建第三份产品需求。4489b400 是本轮盘点的代码基线，提交/推送与检查结果只记 BACKLOG/验证记录。

先前云收藏、公开聚合、情感阈值、拟新增表/接口属于AI提案；本轮已用页面需求收敛并替换这些方案。下方保留历史阶段原话，不把较早的“暂不实现”误用为禁止已获准的前端重建，也不把过去的 POC 授权扩为当前所有增量功能实施。

用户已经明确的要求

来源：2026-10-07 本轮项目聊天，需求提出者原话。

现在先不要做任何的代码的实现，最重要的一点我需要你真实的搭建一个workspace，为了很好的阅读和让ai理解我们的需求

是我们文档产出和真实的任务的执行存在很大的理解上的问题和真实实现上的问题，我们总喜欢做的又大又全，实际上一个真实的验证应该做poc和demo的跑通

以上是较早的阶段约束：先完善阅读与核对，再做最小 POC/demo；本轮继续整理需求，没有开始业务编码。下方的新指令已澄清业务方向，不能再把方向写成尚未选定。

同日新增的产品要求

来源：2026-10-07 当前聊天，用户原话（节选）。

我想要做一个AI热点事件监控平台，poc阶段需要做的事情时根据我们设计的关键词，可以通过爬虫等获取到我们设置的关键词相关的帖子信息，评论信息，并且需要做相似度匹配机制获取最相关，以及时效性等

用户随后补充：

AI试试举一个例子，跟我们设置的关键词相关，至少国内的所有的主流平台都需要支持，还有x，ins等国外的主流媒体的，但是poc阶段只需要验证国内的主流的平台

已确认：产品围绕配置关键词获取帖子和评论，判断相关性/相似度并考虑时效性；最终覆盖国内主流与 X、Instagram 等海外平台，POC 先验证国内主流平台；本轮用 PM 方法整理现有知识体系。用户请 AI 举例，因此总 PRD 使用 AI 行业主题演示，未把监控范围限定为 AI 行业。

AI 提案：国内平台枚举、逐个平台验证的顺序、DeepSeek 示例、排序规则、样本数量和质量阈值。单个平台是最小执行切片，不是全部国内 POC 的替代。具体名单和执行参数仍待核对；本轮不进行业务代码实现或真实采集。

随后用户进一步要求使用 pm-market-research 进行详细调研，其他产品分析也使用 PM 技能。对应市场、用户与方案分析需提供来源、假设和验证方式，仍整理在当前 workspace；不把“进行调研”理解为开始业务采集或购买商业服务。

当前调研重心：GitHub 与免费取数

用户在同日进一步明确：

我认为我们当前的重心应该放在 GitHub 的调研上，重新详细的调研我们类似的功能的项目，有什么通用的我们可以采用的功能，关键词是实时获取热点信息，评论爬虫等，star，都是我们需要关心的内容，最重要的是free，我们获取信息的手段一定是免费的，没有api的价格

已确认：优先研究 GitHub 项目，关注热点与评论、可复用功能、star 和维护情况；取数必须免费，不能引入付费 API。新产物见GitHub 免费热点与评论采集调研：15 个主要候选、2 个覆盖缺口排除样本，按固定源码核对费用路径与能力。商业竞品调研保留为背景，不再作为当前选型重心。免费试用、赠送额度、广告赞助商及公共免费实例分别识别；尚未证明持续免费的路径不得写成已支持。

MediaCrawler、WeiboSpider、NewsNow 等的采用顺序为 AI 提案；star 是观察快照，非质量评分。本轮仍为研究与文档整理，没有真实爬虫结果，不因“免费”改变既有账号、许可、凭据和风控边界。

当前工程设计要求

用户在上述调研后提出（原话）：

集合了这些时候我们需要根据这些开源的项目对我们的整个需求分析进行再次明确，从整个软件工程的需求分析，架构设计，数据库表设计，功能性需求非功能性需求角度出发进行全面的优化，并且使用 pm-execution 来整理我们的设计

本轮据此采用 pm-execution 的 create-prd、prioritization-frameworks、pre-mortem、test-scenarios 和 outcome-roadmap，统一设计而不新增一套产品需求。功能/非功能条款在总 PRD；架构在技术架构；字段、键、索引、删除/恢复及最小增量在数据库设计；交付阶段、需求追踪、风险与验收在验证与交付设计。

已确认目标与费用边界继续生效；四档相关性、统一 UTC 半开窗、候选表及性能负载等是设计提案，未变成运行结果。没有修改业务代码、建表脚本或现有数据库，没有据此启动采集、部署或解除冻结。方案与现状逐项标注，实际派发仍只在 BACKLOG。

总 PRD维护目标与规则，需求核对保存源码差距、假设及验收场景，国内平台 POC 验证卡承接下一步执行。Instagram 已进入长期目标，本次国内 POC 不自动启动其接入或解除其他冻结项。

需求、方案和证据怎样区分

内容	在哪里读	怎样使用
用户本轮原话	本页上方	作为当前阶段和验证方式的依据
已有产品需求	总 PRD、对应能力	保留现有原文；逐项核对，不能因为文档写了就推断用户认可本次全部实现
已有边界	决策	保留生效规则；本轮没有废弃旧决策
实施方案和计划	架构、执行计划	是实现建议和原计划，不能反过来定义需求，也不能当作当前派发授权
当前实现	对应源码、配置及运行记录	源码说明能怎么做；只有实际运行证据才能说明这次跑成了什么
验证结果	同一张 POC 验证卡的结果部分	记录真实输入、输出、复跑步骤和局限，结果回来后再决定下一步

发现冲突时，写出“用户原话 / 现有文档 / 当前行为”的差异；保持待核对状态，不自动选一方、不把 AI 建议写成用户已确认需求。

一次只验证一个场景


一个具体问题 → 一张验证卡 → 最小 POC → 用户能操作的 demo
                                              ↓
                          根据真实结果：继续 / 缩小 / 换方案 / 停止

这是对本轮反馈的工作方式整理。POC 和 demo 可以共用一份最小实现，不必分成两个项目。

POC：回答一个风险或假设，例如“这个来源能否拿到可核对的真实内容”。记录失败同样有价值。
demo：让用户从输入走到可见结果，例如“输入一个主题，读到来源和时间明确的命中”。页面截图只证明外观，操作录屏或复跑步骤才说明交互经过。
正式实现：在前述结果支持需求后，再讨论自动调度、多来源、长期运行、架构调整。POC 通过不等于整项能力可用。

验证卡先写清：谁在什么场景下需要什么、唯一假设、最少输入和输出、成功与失败条件、本次明确排除的范围。卡里没有的扩展只列为后续候选，不在执行时顺手补齐。

当前核对项

核对项	已有依据	当前结论
文档与任务理解脱节、范围越做越大	用户本轮原话	已确认存在问题；逐项偏差仍需具体场景核对
首个业务验证要选什么	用户当前原话及补充	已明确关键词 → 帖子与评论 → 相关性和时效性；先验证国内主流平台
当前优先研究什么、可否购买数据 API	用户最新 GitHub 调研要求	优先免费取数项目；费用为零是准入条件，star 和维护是辅助比较维度
调研后要产出什么设计	用户最新 pm-execution 要求	统一功能/非功能需求、现有架构与数据库差量、结果阶段及验收追踪；尚未派发实现
平台热榜与事件归并是否必做	当前指令要求关键词相关内容	本次以主题监控为主线，热榜只是线索，事件自动聚类不作为 POC 前置
国内主流具体包含哪些、先跑哪一个	PRD 的国内平台工作清单	已有候选枚举；完整清单与首平台待核对，不能默认为只有一个平台
用什么关键词、如何判断好坏	PRD 示例与验收初值	AI 举例已提供；具体主题、窗口、限额和指标待执行卡冻结
workspace 阅读是否可用	本轮文件、构建和实际页面检查	结果写入 workspace 的 VERIFICATION；不作为业务验证结果

分析与验收方法见热点事件需求核对。业务方向已明确；技术方案和数值仍是待验证提案，没有业务运行结果。

每轮怎样开始和结束

开始时，用一句话复述本轮要解决的用户问题，指向来源；列出这次唯一验证项和范围。结束时，给出能打开或操作的产物、复跑步骤、实际结果、还不能证明什么。执行状态更新在进度原文中。

文档只服务于这次理解和验证。没有被当前问题使用的章节、平台清单、长期排期和复杂流程，本轮无需继续扩写。