EDC Radar 独立评审 by Astra

日期：2026-09-10。供 Skyler 与另一份独立审查对照。以下判断由我负责。

可以直接照着做的摘要

1. 先做“认出这是什么、分清版本、知道怎么买”的英文资料站，收藏紧随其后；一年内不做站内交易。
2. 第一件事是冻结现有编号、建立永久产品编号，拆开产品、版本、店铺报价和发售事件，再接收藏与提醒。
3. 不要照旧审计补 759 条：其中 720 条在当前库已有同名且同文章链接的记录，41% 不是当前覆盖率。
4. 先核对并发布 100 到 150 款重点产品，保留长尾草稿；图片授权不够就用文字页，不拿生成图冒充实拍。
5. 比价先限 3 家店、同一版本、近期查到的报价；查不到运费和税就不承诺“到手最便宜”。
6. 邮件先做自愿订阅的双周摘要，收藏先私密；新品、补货、降价提醒等数据稳定后再开。
7. 补库先查清已抓未解析、已解析未入库、已入库未关联，接着补两本汇总刊的缺期和西方主理人直营站。
8. 立即重审假精确日期、按店铺判仿品、旧热度分和“空白格等于市场机会”，这些会把内部决策带偏。
9. 现在就披露运营者正在筹备自己的手玩品牌；资料站与品牌分开，不把资料站订阅者默认转进品牌营销名单。
10. 按两人合计每周 8 到 10 小时安排，先跑稳 90 天；维护超出每周 3 小时就停扩源、停加功能。

审查口径

这是一份建议，不是建站成果。我只写本文件，没有运行抓取脚本、浏览器、部署、定时任务或付费接口，也没有修改数据库、内部站或公开站。外部核实使用公开网页搜索与文本读取，没有打开浏览器。站点当前状态以本地文件为准，没有验证线上部署是否与本地一致。

默认定位是面向英文用户的金属手玩资料站，重点是推牌、指尖陀螺、转币和复合机构。其他技巧玩具可以收录，但不在第一轮追求覆盖。用户是收藏者和买家，不是泛儿童玩具消费者。两人合计每周 8 到 10 小时是我的排期假设，不是已确认的投入。

文中的 CN 指中国资料，west 指海外销售资料；SQLite 是现有的单文件关系数据库，SQL 是查询它的语句，JSON 是脚本交换结构化资料的文本格式，HTML 是网页文件。其他英文表名、字段名和代码值保留原样，旁边说明用途，便于后续实施时找到对应位置。

必须先改正两个口径：“公告记录”不等于“独立产品”，“店里有一张商品页”不等于“当地有库存”。下文的完成标准都按实际能对用户负责的程度判断，不按能否画出一个按钮判断。

1. 他想要的功能，哪些能做，哪些差一点，哪些还很远

“现在可做”指可以用现有资料开始做一个诚实的有限版本，不表示公开站已经具备。“差一点”指数据基础已有，但还要补明确的连接或服务。“还很远”主要是运营责任远，不一定是代码多。

内部站可以先实现“所有已收集资料都能搜到”。内部详情页应同时列出未核对公告、冲突字段、匹配候选、原图与加工图、失效报价。公开详情页只展示通过检查的事实。两站共享产品身份和来源，不共享全部可见字段。

“所有品牌所有产品”不适合作为上线验收。一个未公开名称的群内小批次，数据库根本无从知道。内部应能回答：哪些来源看过、覆盖到什么时候、哪些内容没处理、哪里还有疑点。这个答案比一个不断上涨的总数更有用。

2. 还应该加什么

先解决买家真正卡住的地方

其中有六项值得明确立项。

第一，产品“身份证”。一个链接包含名称对应、代数、尺寸版本、机构、来源与修订记录。正式英文名未公布时，展示中文名加工作译名，并标注这是本站译名；不能让搜索引擎把猜的译名固化成官方命名。英文界面保留中文原名是功能，不是漏翻译。

第二，“这两个有什么区别”。选择两个版本并排看重量、尺寸、轨道、磁体或弹簧结构、表面处理、配件和已知适配。未知就留空。不要让外观相近变成相同手感，也不要让 Mini 的最低价出现在标准款购买按钮旁。

第三，可用性说明和数据日期。每个报价显示“何时查到、哪里发货、现货还是可预订、是否可寄到你的国家”。页面顶端可以显示资料最近核对日期，但不能用整站构建日期代替每个报价的观察日期。

第四，维护与配件档案。轨道、垫片、磁体、轴承、螺丝、替换面板、兼容版本、主理人公开维护说明和停售后的资料。此类内容更难被一般上新聚合器替代，也能让已经买完的人回来。尺寸与维修做法只引有依据的信息，不自动编教程。

第五，带证据的纠错和投稿。用户能报“同款没合并”“版本合错”“价格是定金”“图片不是这个版本”，并给链接。先由编辑处理，不直接开放全库编辑。主理人提供图片许可、玩家贡献自己拍的照片，是补资料与解决版权同时推进的方法。

第六，可导出的私人收藏。允许一款有多件、记录已出售、隐藏购买金额、导出通用表格；允许先存“型号待确认”，以后再对上目录。不要因为目录不完整而让收藏者无法记自己的东西，也不要逼他上传收据才可使用。

声音也值得加，但要区分“品牌称静音”“用户在办公室觉得可接受”“本站按一致条件录音”。不同麦克风和距离的音量不能拿来排分贝榜。第一版用有条件说明的原声视频链接和文字体验；标准录音后做。

其他收藏网站，有哪些值得借，哪些不能照搬

以下借的是产品组织方法，不是声称这些网站的每个功能都已证明适合手玩。能查到官方说明的地方附来源，未核实的现行功能不当事实使用。

对生意有用，但不能偷偷把网站变成品牌广告

我不同意旧计划把“邮件列表就是品牌上线的种子用户”当成自动成立的关系。关注很多品牌的新品，与愿意接收某一个新品牌的销售邮件，是两次不同的选择。资料站可以在合适位置清楚介绍运营者的新项目，再请读者单独订阅；不能直接搬邮箱，不能把私密收藏拿去做品牌定向推销。

也不必永远禁止所有商业收入。前 6 个月先验证有人反复使用；以后可以做清楚标注的赞助栏，或 affiliate，即读者通过链接购买后网站收取佣金。覆盖、数据更正、比价排序不能受付费影响。若显示自有品牌商品，同一页面披露关系，适用相同数据要求，编辑推荐交由无利益关系的人复核。没有独立复核就只列事实，不给自己颁奖。

给经销商的第一项利益应是准确的转出点击和减少重复问答，给主理人的第一项利益应是准确英文档案与来源链接。不能承诺流量规模，也不要急着收费卖商家后台。日后内部分析可看匿名汇总的搜索无结果、被关注但无可买渠道的产品、关注后多久买到；这些不是销量，也不能用来反推个人钱包或健康状况。

关于竞争，我接受 brief 中的三个聚合项目和社区连载作为背景，但本次没有逐家验证其完整数据源与收费现状。“他们都没有中国源”和“有人计划收 10 美元所以我们能收费”都不成立为证据。公开公众号也能被别人接入。更持久的优势是准确的名称对应、版本档案、来源授权、历史记录与被及时处理的纠错。

3. 现有东西哪些要完善或重做

3.1 先纠正覆盖率，再决定补多少

weekly/data/corpus_review_2026-09-09.json 的 matched 是 526 条，unmatched 是 759 条，合计 1,285 条。这个除法确实是 40.9%，但不是当前数据库覆盖率。

我逐条只读查询当前 products，结果如下。这里的“同名且同链接”只是严格文本存在检查，不是人工确认同款。

例如旧审计认为没收录的“查理王锆合金”“共振”“三体mini”，当前分别在 products.id 907、910、911，source_file='corpus'，文章链接也相同。当前另有 291 条小岛记录的 source_file='corpus'。所以小岛 1 到 5 月没做成独立期刊 JSON，不等于这一段内容完全没入库。

反过来，旧 matched 也不能视为正确答案：样本把 QD01 配到名为 01 的旧条目，把第三方配件配到本体。这是需要复核的错误候选，不是可靠的训练答案。1,020/1,285 的 79.4% 也只是当前库的“同名同来源记录存在率”，不能替换成全市场覆盖率。

我的结论：仍要补回刊，但先重算缺口和来源关系。不要把旧的 759 行整批视为新产品；那会把已经入库的内容再加一遍。

3.2 两套产品身份尚未真正连起来

radar_cards 中，1,117 张没有 product_id；120 张标 exact，即同款匹配，29 张标 series，即系列匹配，9 张标 weak，即弱匹配。也就是说总共只有 158 张关联中文记录，约 12.4%。exact 是脚本标签，不能默认是人工验证过的精确对应。

west_matches 的 1,136 行里有 670 行 exact、379 行 series、87 行 weak。后两种只能帮助编辑找候选，不能为自动比价、到货提醒或公开出口名背书。

products.key 当前 1,911 个值恰好都不同，但它是名称拼接出来的键，数据库只有普通索引，没有唯一约束。没有外键约束来阻止图片、别名、报价挂到不存在的产品。当前所查图片关联没有孤儿记录，这是现状正常，不是结构上能保证一直正常。

同一标准化品牌和完全相同中文名的分组没有重复，说明已有清洗有效。但名称不同、联名表示不同的重复仍有候选：933 的“机械奶盖3代-火鹏”与 1390 的“机械奶盖Gen3-火鹏(ACEdc×YOLO联名)”都指向 2026-01-16 发售，品牌分别写成联名与 ACEdc。应该核实是否同一型号的两个公告，不能仅凭这次查询直接合并。

要重做的是数据关系，不是把两个表取并集。每一条旧记录先留下，再分配它属于哪个产品、版本和公告。详细模型见第 4 节。

3.3 编号重排必须在任何账户功能前停止

clean_radar_data.py 最后按当前列表顺序执行 it['id']=i。删一张卡可能让后面全部变号；现在页面的图片举报用这个编号保存在 localStorage，即浏览器本机存储。下一轮清洗后，举报就可能落到另一款。将来收藏、评论、通知若照用这个编号，问题更大。

缩略图已经有一个值得保留的做法：radar-v3-a.html 通过 thumbs/index.json 的产品 URL 找图片，而非直接照当前卡编号取图。所以不能笼统地说每次重排都必然把缩略图全部配错。但 URL 改名、域名迁移、多店归并仍会破坏对应，应继续升级为永久产品和媒体编号。

人工合并表也不应长期靠两串标题定位；标题改了就失效，跨品牌同名还可能碰撞。改成永久编号加证据与操作记录。

3.4 卡片合并正在丢掉比价所需的信息

当前 1,275 张卡有 1,048 张带 shopvars，但仅 9 张的 shopvars 出现两个以上店铺。这和“很多卡写 +N 卖家”不是一回事。merge() 聚合文字卖家数、价格和部分 buy，没有把每个被合并成员的主 url 自动完整保留下来；后续又靠 URL 回找变体。结果是“知道好像有别的店”，却不一定有可点击、可对版本的报价。

另外，shopvars 跳过 Default Title，最多保留 24 行，并按“店铺 + 变体标题”去重，缺少源变体编号。单一默认款可能消失，同店不同型号的同名材质可能撞上，长变体清单会被截断。展示层可以分页，存储层不能为了卡片简洁丢报价。

radar_family.json 把 Mini、Nano、Lite、Pro 等归为一张卡，方便浏览可以保留；它不应该同时抹掉可购买版本的身份。清洗时取全组最低价、最高热度，再用于首页排序，也会把便宜小号和高价标准款混在一起。

名称归一代码会去掉材质、颜色及很多产品词；中文折叠步骤按归一名称寻找候选，没有始终以品牌和具体版本作最后约束。需要保存“确定同款”“同系列”“明确不是同款”三类关系，不能只剩合并结果。

3.5 数据字段看似齐了，含义并不齐

images 共 5,337 行，其中 ok=1 是 5,207 行，另 130 行未成功。把 5,337 都称“已缓存图片”不准确。缩略图目录 1,292 个条目实际是 1,291 张 JPG 加索引文件；索引 URL 能覆盖当前 1,259 张卡。

727 条产品没有 article_url，历史来源不能只保留一个期号字符串。parse_youbing_issue.py 已能提取 weight_raw、track_raw、size_raw、ship_raw、设计者、工艺，但 products 没有对应的结构化列。继续扩公众号之前，先把已经拿到的规格保住。

3.6 日期和库存需要重做语义

当前有 10 条 status='upcoming' 却带着早于审查日的 release_date。例如 924 的原文“1月中下旬”被存成 1 月 25 日，1066 的“近期”旁边却是上一年的 12 月 20 日。可能涉及推断或字段拼接，不能当确切开售日。

build_drop_calendar.py 仍固定 TODAY=datetime.date(2026,7,8)、YEAR=2026，展示月份虽参考最新期数，今天与过去的样式判断仍错，跨年也会错。这与项目技能里“月份已动态”的描述不完全一致。技能与计划是线索，代码才是这次判断的依据。

日历还只读顶层 cn_source/*.json，并从 7 月开始，不能代表数据库里的全年事件。对“近期”不能硬造一天；应显示待定或时间窗口。时间已经过去也不能自动认定已交付，应显示“原计划日期已过，未确认是否开售或发货”。

build_products_page.py 的“只看 Geeone 在售”实际筛的是有没有 geeone_price，没有检查库存，标签与行为不符。公共比价也必须分清“有历史报价”“接受预订”“最近查到有货”。

3.7 自动归档与自动入产品库是两件事

sync_articles.py 已有文章永久归档、逐源处理、运行记录和登录异常提示，这是应保留的基础。RSS 是订阅源提供更新内容的格式；当前只归档文章，不会自动把新公告变成经过匹配的产品。项目内的周报技能仍将正式建库脚本标成待固化，本次也没找到所述临时建库目录。

同步使用 INSERT OR IGNORE，同一 guid 已存在就跳过。因此主理人修改价格、删除错误说明或延期，旧文章不会因此自动更新。应保存内容摘要值和修订版本，区分首次发现与最近检查，不覆盖原始历史。

本次库有 1,831 篇文章、143 个不同 feed_id；最新运行记 125 个源、23 篇新增、0 错误。brief 的 124 订阅、141 个见过的号，以及审计的 141 个账号，是不同日期或不同口径；不能当成一种计数。没有调用容器去核实当前订阅列表，所以我不判定现有订阅数必然错误。

账号失效但接口还返回缓存，也可能“0 错误”。要监测每个来源最后成功检查、最后观察到新内容、授权或登录状态。一个月没发文不等于抓取故障，一个月每天拉到相同旧内容也不等于管线健康。

3.8 快照可靠性达不到公开提醒要求

refresh_west.py 只有 4 个日期目录。它最多取 8 页，中途失败就停，但只要前面抓到产品仍保存，没有完整性标志；缺币种、源变体编号、完整描述和全部图片。diff_snapshots.py 按 handle 和变体标题配对，标题变化会断开，还会把缺失页误认成商品移除。不要拿这些差分直接发邮件。

Geeone 版本保存源产品和变体编号，明显更适合继续发展。但它的保护只是数量不足 300 就停，抓到不完整的 500 个也可能通过；available 被压成真假，未知值无法保留；原始快照仅短期保留，事件只记录达到 5% 的调价，不能恢复完整价格史。周报差分又用 3% 门槛，两套口径不一致。

feed.jsonl 当前 246 条是事件数，包含 102 条售罄、81 条补货、48 条新变体、12 条新品、3 条调价。不是 246 款新品，也不是销量。第一次基线与后续事件应分开，漏抓期间的事件时间应记成观察窗口。

采集、构建、部署、推送私有数据仓目前串在一个 shell 脚本，部署输出还经过文本过滤。每段需要独立完成状态和可重试入口：采集成功而发布失败应只补发布，不能重发全部通知；仅仅输出里出现某个单词不能当部署确认。这里是静态阅读发现的风险，本次没有执行故障测试。

3.9 灰底图不能统称“真实照片版”

缩略图索引记录 1,183 张 codex-frontview、51 张 codex-fallback，合计 1,234/1,291，约 95.6%。脚本明确调用图像生成进行抠图、扶正或正视图处理。另有 39 张抠图流程图、18 张裁切图。它们来源可能是真实商品照片，成品却不全是只换背景的原始实拍。

这是流程证据，不是我逐张判定生成图有错。它能证明的结论是：细小雕刻、磁体排列、连接缝和比例不能靠这些加工图鉴定。公开详情默认用有授权的原图；内部可以继续用统一图检索外观。公开若保留加工图，明确标为处理后的示意缩略图，能一键看对应原图，禁止用于真伪或尺寸证明。

按源图片 URL 的摘要值缓存有助于复用，但最好另存图片内容摘要、处理方式、原始媒体编号和人工核对状态。原图换了内容而 URL 没变，也应能识别。

3.10 视觉标签和热度不应当事实发布

当前“形态”混着功能与造型：slider 是操作类型，sculptural 是雕塑造型，一个东西完全可能两者都是。应该拆为操作方式、多选机构、外形、主题、材料和主观风格。静态图片能辨外形，不能可靠识别隐藏轨道、磁力、噪音和手感；这些必须来自说明、演示或实测。

给每个标签保存依据、机器或人工、版本和置信度。用现有原图做首批 100 款分层人工核对，每种主要类型都抽，不只看高热度好图。机器建议没过检查就不进入严格筛选，未知不强塞到“其他”。

旧计划的热度公式把代理店数、Reddit、商店评论、售罄和上新混为 0 到 100 分。当前只见最终分数和合并时取最高分，未在本次检查范围找到可从原始信号重算全量分数的正式入口。许多 days、new 仍是静态数值，不能据其表示今天的新鲜度。

即使公式完整，代理多代表铺货范围，售罄可能代表只上了两件或停止进货，商店评论可能跨店重复，Reddit 样本有搜索词与圈层偏差。店铺彼此也不是独立市场调查。把它们加成一分，不会产生真实需求。

公开先撤综合热度榜。改成“最近新增”“当前在售店数”“最近 30 天站内关注人数”，各自附时间和口径，样本不足不排名。内部保留原热度仅作旧排序参考。reddit_signal_scan.py 实际统计第一页结果数，取少数高赞结果，reddit_corpus_fetch.py 又只取最多三个帖子；这既不是全站提及量，也不能把未搜到解释为玩家没兴趣。

3.11 空白格雷达现在不适合指导选品

build_gap_radar.py 读取的还是 radar_baseline_2026-06-25.json，不是清洗后的现库；未知价 0 被放进最低价格带；中文“陀螺”被映成 top，容易混淆指尖陀螺与桌面旋转陀螺。中文池只按形态计数，不能证明某个主题格子国内已有货。

页面却把红格称为“全市场空白”。这必须改成“当前样本未收录”。没有产品可能因为没需求、制造困难、抓漏或分类不当。更有价值的内部页面是：用户反复找什么、哪个价位买不到符合要求的东西、已有产品哪里让用户失望，以及这些判断来自多少个独立样本。

3.12 页面要整理，但静态站不是问题本身

公开目录、产品页、品牌页、过刊和指南都可以预先生成静态 HTML。数千条资料无需先改成复杂应用。需要动态服务的是登录、私人保存、投稿和提醒，不是每一次打开资料页。

公开导航先保留：浏览产品、最新动态、品牌、指南、我的收藏。首页放本期有用变化、搜索和几组使用场景。周报链接到稳定产品页，产品页保留相关文章；日历点击先到英文详情，再提供中文原文。内部则按待处理公告、待匹配、待核对报价、待授权媒体、来源健康来组织工作。

本地公开首页写每周更新，但 7 月 22 日到 9 月 2 日间隔 42 天。先把承诺改成能履行的双周或不定期精选，不靠排期文案制造可靠感。公开日历实际仍有中文按钮，html lang 也不是英文，publish_public.py 明确保留双语日历；“公开站英语唯一”还没有在所有页面落实。

当前图片举报只是本机列表，没有把报告发给运营者。公开版必须是真实可到达的纠错入口。build_products_page.py 把来源字段直接拼进 HTML 和脚本，需要输出转义、链接协议检查和安全的文本插入，防止一段来源文本变成可执行脚本。这里没有测试利用，也没有证据表明已被攻击。

为搜索引擎增加稳定产品 URL、标准页面地址、站点地图和真实版本信息；空白占位页先不收录，不为每个材质和搜索组合大量造页。保留原文摘要来源，避免全站只是经销商描述的重复副本。

内部页的 noindex 只是请求搜索引擎不收录，不是访问控制。没有核实线上访问策略，所以不能断言内部已公开，也不能因为另一个域名就视为私密。内部人员资料、原文全文与研究判断都应有登录保护，公开输出按允许字段单独生成。

4. 数据库怎么才能更全

4.1 不先增加抓取量，先把已有内容吃完整

先建立“来源台账”：来源是谁、对应哪个品牌、稳定账号标识、允许获取方式、计划频率、最后成功检查、覆盖起止、可公开哪些字段、是否取得图片许可、负责人。公众号按账号标识核对，不按一个普通中文名字猜。已经发生同名误订阅，扩源前必须防止再次混入无关账号。

然后建立“处理台账”：一篇文章处于已发现、已抓全文、已解析、待同款匹配、已审核、已公开中的哪一步。解析结果为零要写原因，不能直接当“没有产品”。断档、无关内容、格式变了、需要人工看图是不同情况。

历史补录优先顺序：最近 90 天的新增与更正，其次 2026 年各期完整公告，再补有病 2024 年 4 月到 2026 年 2 月的空洞，最后补更早长尾。现有库 2024 年仅 36 条，首先说明采集分布异常，不能证明那年新品突然很少。

小岛 2026 年 1 到 5 月的 15 期、8 月的 3 期，要做的是补足文章与条目结构、明确哪些已通过 corpus 入库、哪些还有漏项，不是宣告这些月份从零开始。有病历史目录有期刊文件，也有 _index、_state 等管理文件，不能拿目录文件数直接当期数。上下篇、合刊、同月重录也要有唯一文章标识。

4.2 具体扩哪些源，怎样取得，多久一次

下表频率是建议，均以来源许可、实际额度和维护能力为前提。API 指平台给程序读取数据的正式接口。当前没有逐个平台验证账户权限，不能把“存在 API”当成“本项目获准调用”。

西方直营候选有本次查到的实际目录作为依据：Magnus Fidgets、Modusworks、Umburry、BilletSPIN、Aroundsquare。这些链接证明相关目录存在，不表示批量抓取已经获准或已经接入。

Etsy 用途审批与额度见官方 API 条款。Reddit 商业接口用途需另行协议，见官方数据接口条款。群组权限与开发者约束还需按Discord 官方开发者规则逐项核对。没有权限的来源可以先记录链接并等供稿，不能把绕过限制当作排期依赖。

每个来源连续试 4 周，记录新增独立型号、补齐了多少重要字段、花了多少审核时间、失败次数。一个月没带来独有资料，却每周要修抓取的源，降到人工月查。反过来，一个月只有两篇、却提供唯一轨道规格的品牌号值得保留。源头多不是成绩，独有且可用的资料才是。

4.3 合并后的资料库应该长什么样

不要造一个几百列的“超级产品表”。最关键的是把六件事分清：产品是什么、具体哪个版本、谁在卖、什么时候观察到什么、证据在哪、用户手里是哪一件。

下面是逻辑模型。表名是建议名，不表示本次建了这些表。第一阶段用现有 SQLite 就够；它们可以在同一个数据库中，没必要拆服务。

第一轮只把身份、来源、版本、报价、发售日期和媒体权利跑通。事实陈述与审核队列可以先用简单表格管理，规格暂存结构化字段，不为每种属性建设独立后台。历史长尾留作待审，后续逐批迁移。下表是边界清楚的最终形状，不是要求第一个月完成所有表和界面。

用户数据等账户阶段再建，和可重建的目录数据分开。

这里刻意不列交易、聊天、支付和好友图谱表，避免为了未来设想把第一年拖成平台工程。

4.4 什么该合并，什么必须分开

以“机械奶盖”类记录为例：系列可汇总普通款、Nano、机械代数，但玩家拥有的是具体版本，报价也是具体版本。933 与 1390 若核实是同一“Gen3 火鹏”型号，应把两篇公告连到同一产品，再从原文拆出实际销售的材质组合。不能把更早的奶盖、Nano 与 Gen3 都改成一个低价商品。

尺寸不同但机构与型号定义不变，可以是同一产品下的尺寸版本；若 Mini 换了机构、接口或官方把它作为独立型号，则建兄弟产品，挂同一系列。规则看产品本身，不能见到 Mini 就一律合并，也不能见到一次新配色就新建产品。

一次普通补货只新建发售事件和报价观察。限量雕刻版若可辨认且影响收藏身份，建版本；同版本第二批补货不必再造版本。真实批次确有结构差异或玩家必须区分时，记录批次或修订。套装、本体、替换面板、弹射底座分别有身份，不能用配件价替本体比价。

一张店铺图被两家使用，只能证明图片相同；可能是正规代理，也可能盗图。图像相似可以产生待审候选，不可以证明同款，更不可以证明真伪。平台、卖家与具体商品三个层次也要分清。

4.5 永久编号与去重：怎样保证不再重排

1. 新产品首次入库时分配随机永久编号，例如 UUID。它是一串不含商品含义的唯一标识，不由名称、价格、抓取顺序或图片计算。版本、来源文档、事件和媒体各有自己的编号。现有整数也可以保留，关键是从此不重用、不重排，并标明属于哪个旧系统。
2. 来源身份另建唯一约束。Shopify 使用“店铺编号 + 源产品或变体编号”；公众号保存可解析的账号标识、文章 mid、idx 与原 guid；普通站用官方标识和经审核的链接映射。签名、追踪参数与名称不是永久身份。
3. 对同一来源的同一记录，先判断内容是否变化，再写新增观察或修订。重复跑一次应不增加产品、不增加同一观察事件。这叫幂等，即重复运行不会重复记账。
4. 跨来源只产生候选。先限品牌和代数，再看名称别名、材质尺寸、官方链接、结构图与时间。明确不同代数、不同尺寸、不同配件类型属于否定证据，不能被模糊名称相似分数抵消。
5. 自动关联只用于已批准的规则，如同一个源变体编号或经审核的对应表；新跨店候选先人工处理。至少分别核验“同型号”和“同版本”，通过前者不代表后者也通过。
6. 合并 A 到 B 时，A 留作跳转身份，保留原关系和来源；页面旧链接跳转到 B，收藏自动解析到 B。若规格未能确定，收藏版本仍显示待确认，不偷偷猜给用户。
7. 拆分时更谨慎：不能把所有旧收藏同时复制到两个新产品。保留旧记录，告诉相关用户需要确认；评论保留原上下文，待核实后再关联。
8. 合并日志必须可撤销。旧编号映射包含数据集版本，因为旧卡 id=50 在不同日期可能代表不同产品。无法还原的浏览器本机举报不能硬迁移，让用户重新确认。

页面地址可以是 /products/<永久编号>/<可读名字>；名字方便阅读，编号决定身份。改英文名时旧链接仍可解析。不要只靠名称生成网址，也不要仅对归一名称算一个摘要值冒充永久产品身份。

4.6 比价和价格史：最容易看似完成、实际误导的一段

一次报价观察至少保留：源商品和变体、原币、金额、金额性质、库存状态、观察时间、地区或市场、是否含税、运费是否已知、发货窗口和获取是否完整。金额用整数最小货币单位存，避免浮点计算误差；另有币种说明，不能把所有来源的 $ 自动当美元。

公开比较步骤固定为：确认同版本；剔除定金、积分、拍卖与非本体；确认用户目的地能买；筛出有效近期观察；按原币或有时间戳的汇率换算；最后再排序。默认比较新货全款，二手单独一栏。运费、税费、优惠资格未知，明确只比较商品价，未知不能按零元算。

中文原价与海外价差同样必须比较同版本、同付款阶段、尽量相近日期。比例算出来也叫“商品标价差”，不是代理利润。运费、税、售后和经营成本都未扣除，不能从一个百分比指责经销商暴利。

数据历史采用两层：每天保留成功快照用于证明“查过且没变”，变化记录用于画价格图和发通知。不得只保留超过 3% 或 5% 的价格变化；小变化也保留，提醒门槛再由规则决定。否则年内多次 2% 涨价会在历史里消失。

第一轮建议日更店铺 36 小时未成功观察即显示过期，并退出“当前最低”排序；周更长尾报价显示历史参考，不与日更报价竞争。36 小时是运营规则，可按站点节奏调整，不是天然正确的界限。抓取失败时保留最后成功值与日期，不新造一条“无货”。

某个版本从列表消失，先记“本次未见”；完整抓取连续两次仍未见或源页面明确下架，再更新停售或不可用状态。若检测到价格突降 90%、大量商品同时售罄等异常，先进人工队列，不批量通知读者抢购。

现有 4 次西方快照不能补出中间每天的走势。历史图只画实际观察点与不确定区间，不画成连续掌握的每日行情。首次查到商品是“最迟在这天已上架”，不是世界首发。比较中西时间差时，源站 published_at 也可能是迁站或重发日期，必须与真实公告分开。

4.7 迁移顺序：一个事实来源，两种视图，用户数据不跟着重建

第一步，登记现有 products.db、雷达 JSON、手动合并表、系列表、缩略图索引和来源文件的版本及摘要。之后迁移只读这些快照；新到数据进入增量队列。旧数据不删、不覆盖。

第二步，为所有旧产品记录和卡片建立旧编号映射，并保留未解析记录。统一的是身份，不是强行让每张西方卡都找到中文对应。没有中文公告的西方原创应直接成为正式产品，缺少英文资料的中国款也一样可以存在。

第三步，先选 100 到 150 个型号做人工确认，覆盖跨店同款、系列款、联名、配件、积分、尺寸变化、中文改出口名这些难例。将原公告拆成来源文档与事件，将商店数据拆成源商品、版本和报价，不用 series、weak 自动填用户可见事实。

第四步，生成一个带版本号的内部新视图，与旧页并排核对。相同查询的差异必须能解释：新增、合并、被判配件、版本拆分或原来查错。用固定样本检查，不能仅比较新库行数“差不多”。

第五步，公开只输出已批准字段与有权展示的媒体，保留未批准长尾的内部草稿。页面能从任何一条价格和日期追到证据。审查通过后再切公开目录，旧页和旧编号保留跳转。

第六步，先让采集连续跑稳，再接收藏与提醒。以后“重建目录”只替换可派生的公开数据，不碰 users、collection_items、同意记录和发送记录。用户提交的更正是请求，审核后才进入权威资料，避免本地库与云端编辑互相覆盖。

我建议初期本地 SQLite 仍是编辑审核后的事实主库；Cloudflare 上是经批准的公开副本，以及独立的用户保存数据库。数据只从编辑主库单向发布，用户贡献由待审队列回收。这样是一个事实来源，不是要求原文、私密收藏、公开目录物理塞进同一个数据库。

失败时可以退回上一个公开数据版本，账户库不回滚。若错误涉及合并，先撤销映射，再修公开版本；发错通知则做更正与抑制，不能通过回滚数据库让系统忘记已经发过邮件。

验收不是“脚本跑完”：要能重复导入不增行，断在任何一步可重跑，改名不丢收藏，合并可撤销，半截抓取不制造售罄，旧 URL 仍可打开。上述场景应在真正实施时测试；本次没有建库或运行测试。

4.8 怎样量化“更全”

按固定范围公布几种分母：已确认有效的重点来源、应有期刊、已发现的公告、人工抽样的独立型号、要发布的重点型号。不要用“所有手玩”当不可见分母。

每周内部看：应抓来源成功率、已抓文章待解析数、已解析待关联数、疑似重复数、缺来源的事实数、过期报价数、公开图片授权覆盖、重点产品必要字段覆盖。每月对两本刊各抽若干期、对若干品牌的完整目录独立抽样，核对解析是否漏条，不能拿解析器自己的输出当唯一答案。

对外可以说“本月核对了多少个来源、最近一次更新在哪天、哪些类别暂未覆盖”。如果一篇公告提到三种材质，它在公告覆盖率中是一条，在版本覆盖率中可能是三条，必须各自计数。要同时看误合并率和漏匹配率，否则扩大覆盖会偷偷以错误合并为代价。

5. 接下来 6 到 12 个月的顺序

5.1 先限制每周投入，才谈一年路线

以 2026 年 9 月为起点，两人每周总计 8 到 10 小时，一年约 400 到 500 小时，还要为品牌发布留出中断空间。Skyler 负责编辑判断、同款难例、主理人授权和用户反馈；合伙人负责来源运行、数据库迁移、发布与账户服务。若合伙人不承担技术，必须另买有限开发工时，不能把代码量藏在“AI 自动做”四个字里。

稳定运行后每周建议：2 小时审核资料，1.5 小时编辑摘要与回复，1 小时维护检查，0.5 小时来源及授权沟通，余下 3 到 5 小时改进功能或补历史。一次只做一个主要建设任务。下面是投入窗口，不是两个人能同时推进所有项目的保证。

建设合计约 185 到 260 小时，其余时间用于持续编辑、维护、授权、回刊和中断缓冲。不是把 500 小时全排成开发。若品牌进入发布前两个月，暂停扩源与新账户功能，保留三店监测和双周摘要就够。

5.2 用什么信号决定继续，不拿邮箱数自我安慰

第一阶段最重要的不是一口气有 1,000 个邮箱，而是 10 到 15 位符合目标的真实用户能否独立完成三件事：找到某款中文出口名、分清两个版本、找到能寄到自己国家的购买渠道。试用任务记录完成与卡住的位置，不只收“网站很好看”。这是未来验证建议，本次没有联系任何人。

第 3 个月可以设一个内部继续门槛：在一组愿意试用的约 30 人里，至少 10 人在两周内主动回来完成搜索、收藏或看报价，其中若干人明确说明它替代了什么麻烦。这个数字是小规模决策规则，不是行业基准，也不是统计上足以证明市场成立。未达到先改善资料与入口，不能靠加成就补活跃。

日常主指标用“每月有多少人两次以上通过产品页完成有用操作”，辅助看名称搜索无结果率、同版本报价点击、收藏更新、有效纠错。机器人流量、单次围观、邮件打开像素不算强证据。转出到店铺的点击只能证明兴趣，拿不到经销商反馈时不能算成交。

第 6 个月再讨论是否收费。基本名称档案、出处、更正与公开报价保持免费；可测试付费的是高频个性提醒、收藏高级管理或明确授权的数据服务。先让少数真实用户愿意付钱，不先造付费墙。别把每位订阅者乘以一个假定品牌购买转化率来推品牌销量。

5.3 最小技术组合

我的选择是保留现有 Cloudflare Pages 静态站，增加一个小的动态接口层、一个用户数据库和一个发信服务。不用为了“真网站”重写全部前端。

Pages Functions 可直接绑定 D1、R2 等资源，见Cloudflare 官方绑定说明。D1 兼容 SQLite 的查询语义并提供恢复机制，见官方 D1 说明。这支持继续使用关系数据库，不等于现有所有 SQLite 脚本可不改直接上云。

上述登录组合是根据Better Auth 的 Drizzle 适配、Drizzle 的 D1 驱动和邮箱链接登录插件作出的实现建议，本次没有部署验证。若半天试验发现兼容问题，直接选择成熟托管身份服务，用户资料仍留在自己的 D1；不要把数周耗在认证适配上。

邮件登录链接要短期、一次有效，发信限频，错误消息不暴露某个邮箱是否已注册；会话放安全 Cookie，即浏览器保存的登录凭据，写接口检查实际登录用户与记录归属。管理员启用多因素验证。账户功能最需要验证的不是页面能否登录，而是 A 用户不能读写 B 用户的私密收藏。

提醒先用 notification_jobs 表当小任务队列，记录待发、处理中、已发、失败。定时 Worker 分批领取，有超时重试，同一用户和事件有唯一约束。若发信超时但服务方实际已接收，靠服务方消息编号和幂等能力核对，不盲目重发；无法确认就留人工检查。规模确实需要时再加专门队列服务。

收到退信或投诉回调后停发，回调验签；收到退订立刻阻止尚未发出的任务。发送服务有“投递到收件服务器”的回调，也不能据此宣称读者看过邮件，见Resend 事件说明。每个订阅有暂停或降频入口，默认摘要优于每次微小变动都打扰。

Cloudflare 的定时 Worker 适合这类周期任务，调度按 UTC，必须换算公众号本地日期与买家时区，见官方定时任务说明。截至本次核查，Cloudflare 已有付费计划上的 Email Sending Beta，不能沿用“Cloudflare 完全不能发事务邮件”的旧判断；但公开资料仍把出站能力标为测试阶段，且免费收件转发不等于任意群发。为少维护，我先选成熟发信层，见官方邮件服务说明。

初期设每月 50 美元作为基础服务预算上限，再按实际套餐与用量核算。这是预算建议，不是服务商报价，不含人工、历史数据购买或图片生成。超过上限先看图片流量、邮件量和无效采集，不先增加基础设施。原图、报价历史、用户数据分开备份，每月至少实际恢复一次小样本。

5.4 明确砍掉什么

未来 12 个月砍掉站内交易、资金托管、自动私聊、一键达成交换、代购团购、原生手机应用、全量生成式商品图。暂停综合热度榜、自由评论、花钱型成就、好友动态流、无来源的 AI 评价摘要和大量商家自助后台。

group_buy_plan_2026-09-03.md 的“想要清单”可留下，但必须只是记录兴趣。去掉数量承诺、代抢暗示和先帮忙买一单的路线。代购会把中立媒体、采购、清关、退换货和资金混在一起，对兼职团队是一份新工作，不是给目录顺手加一个按钮。旧计划中的跨境免税或收费假设也不能直接作为今天的报价规则。

“所有店每日抓、所有旧刊一次补齐”也要砍成分层目标。先覆盖关注最多的版本和最能补独有资料的来源。用户今天找不到自己手里的老款，可以先记私密临时藏品并投稿，不必等全世界目录完成。

6. 风险，以及哪些底线必须随功能一起落地

6.1 图片、原文和抓取

最大即时风险是已有发布流程把“品牌官方物料”当成已获公共转载许可，还包含固定去水印步骤。来源署名是必要的，但不是许可。公开照片一般有著作权，权利人也不一定是发帖的经销商。美国版权局明确建议使用他人网上照片前取得许可，见图片使用说明。不能把小图、改背景、AI 扶正当成自动免责。

第一批请主理人授权两到三张指定图片及短说明，记录可用于目录、缩略图、邮件、社交宣传中的哪些用途，是否允许裁切、改背景、长期保留，以及署名方式。不要默认一个公众号编辑能授权所有参与品牌的图片。未获许可的原文素材先留内部；公开用事实摘要、原文链接，或者空图占位。

立即取消默认去水印。若权利人允许移除，保存许可并给出替代署名；不以视觉统一优先于权利。被投诉的图片先暂停公开，找到来源和许可再处理，同时清除对应公开缓存；保留必要的内部处理记录，不继续散发争议副本。

抓取许可、账号许可、版权许可、个人数据使用是不同层次。products.json 可以访问不代表你获得无限抓取与转售权；Wechat2RSS 有许可证不代表可把全部文章公开。来源限速、缓存和失败退避需要做，但低速也不能替代许可。遇到验证码、封锁、明确拒绝，就暂停该源并改谈供稿，不把账号轮换当常规方案。

价格是资料字段，整页介绍、照片与数据库组织另有权利。公共比价只保留必要事实、时间和原链接，按来源条款审查缓存与保留期限，不复制整店描述，也不出售从受限来源抓来的全文。实际经营实体及主要受众所在地尚未确认，不能凭 .ca 域名断言只有加拿大法律适用；公开目录批量扩张、商业数据销售或交易功能启动前，应针对实际来源和业务做一次法律核查。

6.2 社区关系与利益披露

旧计划设想品牌上线时才正式披露，现在应提前。公开关于页和投稿说明可以直说：运营者同时在筹备自己的手玩品牌，网站资料按统一规则收录，商业关系会在相关内容处注明。品牌尚未命名不影响披露这个事实。不能一边收潜在竞争者的非公开资料，一边让他们以为运营者没有产品业务。

对自有产品、免费样品、赞助和佣金，都在相关内容附近说明，不只藏在总条款里。关系披露与评价真实性可参考FTC 关于推荐与评价的官方说明。公开资料的准确性不能因主理人是否合作而变化，也不能因读者批评自有品牌而删负面内容。

本次尝试读取 r/fidgettoys 规则页，返回登录或管理入口，没有取得完整现行规则。因此 brief 所说反自推规范应作为保守边界，但我不会编造当前准确条文或声称已获版主许可。Reddit 官方也说明社区可采用各自不同的推广限制，见社区反垃圾信息说明。

执行上继续以本身有用的内容参与；站点推广、调查、团购或商业链接按该版现行规则处理，需要时由 Skyler 明确身份与版主沟通。零正文外链、链接放评论、攒足发帖比例都不是当然许可。不要把账号历史当作规避规则的技术工作。

不应从个别匿名投诉推断一家店必然骗人，也不能把一位新玩家 3/8 的二手购买经历当成全行业 37.5% 的份额。内部旧研究可以保留作访谈线索，公开店铺评价必须有更多证据、日期和对方回应机会。自有品牌更不能靠未经核实的竞争对手负面标签获益。

6.3 邮箱、收藏与个人数据

用户订阅摘要、关注补货和订阅未来品牌消息分别取得选择，默认都不互相勾选。确认邮件与一次点击退订要真正可用，保留同意记录、发送者身份和联系办法。加拿大反垃圾邮件规则的基本要求包括同意、身份说明和退订，见CRTC 官方指引。其他地区按实际覆盖核实，不能用一套模糊条款替代所有要求。

收藏默认私密，公开分享由用户主动开，并可随时撤销。购入价、序列号、存放位置和收据不默认公开，不做“全站谁最有钱”。第一版不需要详细地址，也不需要收集注意力障碍、焦虑或其他健康标签来推荐玩具。

提供数据导出、账户删除和保留期限。备份也按期限轮换，删除过的用户不能因为恢复数据库就重新收到邮件。可为履行退订保留最小抑制记录，但不能借此保留一套完整用户画像。

6.4 兼职网站的日常故障

电脑离线、登录失效、接口改版、RSS 窗口滚动、邮件服务拒发、编辑没时间，这些一定会发生。要设计“失效时仍然诚实”的行为：目录还能看，报价显示上次日期，提醒暂停，来源显示未更新，不把静默失败变成假库存。

合伙人有一页可操作的恢复说明：哪个源停了、最后成功版本、从哪一步补跑、怎样暂停所有外发。每个功能都必须能单独停，例如关闭提醒不影响收藏。别让重新抓一次数据顺手触发全站部署、所有事件重发和所有用户邮件。

重要原始快照需要保留可追溯历史，文件存储可以按月压缩；不是把所有全文和每帧视频永远留着。数据库、媒体许可、旧编号映射、订阅和发送记录要分别有备份。机器在本地可以接受，但只有一个人懂如何恢复不可以。

出现两周连续维护超过每周 3 小时、待审积压超过两周、主来源持续无数据，触发缩小范围：停新源、停低置信通知、降低摘要频率。不是靠继续投入夜间时间维持一个虚假的每日承诺。

6.5 评论、评分与交易带来的责任

自由评论会带来推广、刷分、争吵、盗图、诽谤和售后纠纷。按钮做出来的当天，举报、删除理由、复核、申诉、屏蔽和敏感信息处理也必须有负责人。机器可以分流，不能替运营者判断一条真假争议。没有固定审核时间就不开。

将来体验评分先按具体版本收结构化意见，显示样本数、使用条件与分布；同用户同版本一份可修改的当前评价，历史留存。少量评分只展示个体记录，不出榜；“拥有”是用户声明，不伪称已验证购买。品牌员工、免费样品与付费合作单独标记，不能为好评给奖。

交换比买卖还难匹配：双方恰好想要彼此的版本、愿意接受成色、地区可寄、估值接近、同意补差价，条件同时成立才有意义。上千产品页和几百收藏用户不等于有足够交换机会。若以后研究，先在明确自愿的用户间统计能匹配的意愿，不开放陌生人群发请求。

外部转让索引也有责任：标清原帖时间、状态未验证、是否允许转载；不提供担保，不储存付款信息，接到诈骗报告要能下架链接。若未来想接支付、托管、运费、身份验证与争议处理，那是单独的业务决定，必须重新算人力与法律成本。

尚未验证的事项及本报告采用的默认决定

尚未验证：现有图片逐项授权、两个域名线上访问保护、订阅服务资格、各来源商业访问许可、合伙人实际技术时间、当前真实回访与付费意愿。上述都不妨碍先做来源台账和精选文字目录。

默认决定：公开图片必须有依据；内部先按敏感资料保护；账户用成熟组件；每周投入按 8 到 10 小时；社交与交易不进入第一年承诺；“中国首发一定领先西方”不再作为品牌定位。Geeone 提前上架反而说明应把两边拼起来，帮助读者认出同一件东西。

本次核查记录与证据

代码检查是只读静态检查，未运行项目构建脚本。SQL 使用 Python 内置 sqlite3，以 mode=ro 打开。本次按规划与完成前验证技能组织核查，但遵照本任务只产出 NOTES.md，不另建规划、代码或数据文件。

以下是实际执行的关键核查命令及输出。文中对特定脚本的判断来自读取相应代码，不是由这组统计推断全部实现。

sed -n '1,260p' weekly/tools/clean_radar_data.py
cat weekly/tools/refresh_west.py
cat weekly/tools/diff_snapshots.py
sed -n '1,220p' ops/wechat2rss/sync_articles.py
sed -n '1,180p' weekly/tools/build_products_page.py
sed -n '1,160p' weekly/tools/build_gap_radar.py
sed -n '1,150p' weekly/tools/build_drop_calendar.py
sed -n '1,85p' weekly/tools/publish_public.py
cat research/imgpick/apply_frontview.py
cat research/imgpick/apply_cutouts.py

核对结果：清洗末尾重排 id；普通店快照未保存源变体编号；日历固定今天和年份；公开日历保留双语；产品页在售筛选只检查价格；空白格来自 6 月基线；生成式缩略图覆盖原缩略图。没有运行这些命令所读取的脚本。

import sqlite3
c = sqlite3.connect('file:weekly/data/products.db?mode=ro', uri=True)

实际执行的查询与返回值摘录：

select source_type,count(*) from products group by 1;
-- brand 681; xiaodao 445; youbing 785

select link_kind,count(*),count(distinct product_id) from radar_cards group by 1;
-- NULL 1117 0; exact 120 116; series 29 29; weak 9 9

select match,count(*) from west_matches group by match;
-- exact 670; series 379; weak 87

select shop,snapshot,count(*) from west_listings group by 1,2;
-- geeone.com 2026-09-09 5119

select count(*),count(distinct key),sum(key is null) from products;
-- 1911 1911 0

select ok,count(*),count(distinct product_id) from images group by 1;
-- 0 130 61; 1 5207 1137

select count(*) from products where status='upcoming' and release_date<'2026-09-10';
-- 10

select count(*) from products where article_url is null or article_url='';
-- 727

pragma foreign_key_list(products);
-- []

字段填充、重复名称、品牌归一、别名、多表关联、日期样本、现有索引、源文件分布也按同一只读连接查询。覆盖率复核的实际核心判断如下：

import json, pathlib
r = json.loads(pathlib.Path('weekly/data/corpus_review_2026-09-09.json').read_text())
for subset in ['products', 'matched', 'unmatched']:
    a = r[subset]
    nname = nurl = nboth = 0
    for x in a:
        n = x.get('name_cn')
        u = x.get('url')
        nname += bool(c.execute('select 1 from products where name_cn=?', (n,)).fetchone())
        nurl += bool(c.execute('select 1 from products where article_url=?', (u,)).fetchone())
        nboth += bool(c.execute('select 1 from products where name_cn=? and article_url=?', (n,u)).fetchone())
    print(subset, len(a), 'exact_name', nname, 'article_url_exists', nurl, 'exact_name_url', nboth)

products 1285 exact_name 1241 article_url_exists 1142 exact_name_url 1020
matched 526 exact_name 493 article_url_exists 398 exact_name_url 300
unmatched 759 exact_name 748 article_url_exists 744 exact_name_url 720

雷达与媒体的 Python JSON 只读统计输出：

radar 1275 meta 1485 bytes 1501119
shopvars 1048
variants 14
radar multi stores 9
thumb index 1291
modes codex-frontview 1183; codex-fallback 51; rembg 35; crop 18; rembg-chosen 4
cards matched urls 1259
jpg 1291
geeone events 246
sellout 102; restock 81; new_variant 48; new_product 12; price 3

meta.count=1485 与真实卡数 1275 不一致，清洗只改 items 和 cleaned 日期，应纳入发布一致性检查。公开数字不能直接信这个旧元信息。

核查中一次泛目录列表输出过多，之后收窄为脚本与定点读取；项目内临时建库目录搜索返回不存在，未去项目外找；BoardGameGeek 页面返回 403；Reddit 规则页未取得规则正文。这些未成功的读取没有被当作已验证事实。未渲染任何图片或三维文件，本任务无渲染机器选择。

交付验证

验证命令：

python3 - <<'VERIFY'
from pathlib import Path
import re
p = Path('ad-assets/astra/radar-roadmap-2026-09-10/NOTES.md')
s = p.read_text(encoding='utf-8')
assert p.is_file()
bad = [c for c in s if ord(c) in (0x2013, 0x2014, 0xFE0F)
       or 0x1F300 <= ord(c) <= 0x1FAFF or 0x2600 <= ord(c) <= 0x27BF]
assert not bad
paths = re.findall(r'^- `([^`]+)`$', s.split('## 我查看了什么\n', 1)[1], re.M)
assert all(Path(x).exists() for x in paths)
assert all(re.search(r'^## ' + str(n) + r'\.', s, re.M) for n in range(1, 7))
print('exists', p.is_file())
print('bytes', p.stat().st_size)
print('lines', len(s.splitlines()))
print('restricted_characters', len(bad))
print('inspected_paths', len(paths))
print('required_sections', 6)
VERIFY

输出：

exists True
bytes 84405
lines 712
restricted_characters 0
inspected_paths 45
required_sections 6

最后执行：

test -f ad-assets/astra/radar-roadmap-2026-09-10/NOTES.md && wc -l ad-assets/astra/radar-roadmap-2026-09-10/NOTES.md

输出：

712 ad-assets/astra/radar-roadmap-2026-09-10/NOTES.md

我查看了什么

• AGENTS.md
• .claude/skills/weekly-radar/SKILL.md
• weekly/data/products.db
• ops/wechat2rss/data/corpus.db
• ops/wechat2rss/sync_articles.py
• weekly/data/corpus_review_2026-09-09.json
• weekly/data/radar_merge_manual.json
• weekly/data/radar_family.json
• weekly/data/cn_source/
• weekly/data/cn_source/youbing_history/
• weekly/data/west_snapshots/
• weekly/data/geeone/feed.jsonl
• weekly/notes/group_buy_plan_2026-09-03.md
• weekly/tools/pdb.py
• weekly/tools/clean_radar_data.py
• weekly/tools/refresh_west.py
• weekly/tools/diff_snapshots.py
• weekly/tools/geeone_monitor.py
• weekly/tools/geeone_monitor.sh
• weekly/tools/parse_wechat_issue.py
• weekly/tools/parse_youbing_issue.py
• weekly/tools/reddit_signal_scan.py
• weekly/tools/reddit_corpus_fetch.py
• weekly/tools/build_products_page.py
• weekly/tools/build_gap_radar.py
• weekly/tools/build_drop_calendar.py
• weekly/tools/publish_public.py
• deploy/edc-radar-plan.html
• deploy/edc-weekly-plan.html
• deploy/edc-radar.html
• deploy/radar-v3-a.html
• deploy/radar-data.json
• deploy/radar-status.json
• deploy/thumbs/
• deploy/thumbs/index.json
• edcradar-site/
• edcradar-site/index.html
• edcradar-site/drop-calendar.html
• research/imgpick/apply_frontview.py
• research/imgpick/apply_cutouts.py
• research/imgpick/fv_runner.py
• research/imgpick/codex_batch.py
• knowledge_base/themes/western_reseller_landscape.md
• knowledge_base/themes/resale_market.md
• knowledge_base/tastemakers.md