14 · 从内容原型到 SEO、GEO 与审核工作台：界面之外还有哪些契约

定位：两个 Web 原型的实现复盘。 食物内容站采用 Next.js/React/TypeScript；菇勇者审核工作台采用原生 HTML/CSS/JavaScript。没有本轮站点部署、搜索收录或增长实验，示例数据和界面数字不作为业务成绩。

一个项目往往需要两种内容工具：面向外部用户的阅读入口，以及面向生产者的审核工作台。claude-demo 恰好各有一个原型，它们比抽象的“AI 产品方案”更适合讨论工程边界。

但阅读原型时必须问清楚：页面从哪里来，数据能否证明，按钮背后执行了什么，以及哪个环节还只是展示。

一、把页面看作结构化数据的视图

食物热量站从本地 JSON 读取记录，生成食物详情、食物比较、页面元数据、结构化标记、站点地图和内链。配置使用静态导出，因此数据和路径集合直接决定发布范围。

这一结构的价值是让事实与模板分离：修改一条记录后，相关页面可以在重建时共同更新，而不是手工维护多份文章。

但规模必须按源码计算。当前数据有 15 条，比较函数从数组前 60 条取无序组合；因此当前应枚举 105 个比较路径、15 个详情路径及首页。这是文件与逻辑推导，不是成功构建后的页面计数。“前 60 条”也不等于按热度排序的 60 条。

二、批量生成之前，先统一页面集合

比较页只按数据顺序生成一种配对方向，详情页却按“当前食物—相关食物”直接拼接链接。于是相同两条记录可能产生正反两个 URL，而静态导出只有其中一个。

实际例子是凯撒沙拉与烤鸡胸：生成集合使用鸡胸在前的顺序，沙拉详情可以链接到沙拉在前的顺序。数据扩充后，相关条目还可能超出比较页的 60 条范围。

这不是 SEO 文案问题，而是页面协议问题。生成器、内链、规范地址和站点地图应该共享同一套配对规范与可发布集合。本文记录该既有缺口，没有修改原型代码，也没有把静态分析写成浏览器访问实测。

程序化内容越多，这类一致性错误的影响范围越大。扩数之前应该先验证链接图，而不是只计算可以生成多少页面。

图 14：A/B 是食品标识的抽象表示。105 是 15 条记录的组合计算，不是成功构建后的页面数量；统一页面集合是修复建议，本轮没有修改应用路由。

三、数据来源比页面模板更重要

原型中的页面和数据含有“真实样本”类叙述，但本次范围没有对应的原始记录、匿名化过程或聚合程序作为支撑。扩数脚本则明确按字符串哈希生成营养数值，并标注 source: 'placeholder'。

因此，这个原型能证明的是数据到页面的组织能力，不是一个已审计的营养数据库。把模拟数据扩成几千页，不会让它成为真实测量。

同样，JSON-LD 中写入食谱、营养与 FAQ 结构，不会自动让内容满足平台政策或具备事实权威。发布前需要核对标记与页面实际内容、数据来源和目标搜索平台要求是否一致。

四、SEO 与 GEO 应拆成四层验收

GEO 资料讨论生成式搜索中的检索、理解和引用；与 SEO 原型结合，可以形成更清楚的测量层次：

层次	核心问题	需要的证据
可抓取	页面能否被访问与解析？	渲染结果、链接、站点地图、爬虫规则
可理解	实体、结论和来源是否清楚？	内容结构、正确标记、出处
被引用	回答中是否引用该内容？	固定问题集下的重复采样与原始答案
有转化	是否带来有效用户行为？	归因、事件与业务结果

当前代码主要覆盖前两层的部分机制。没有运行中的引用监测、流量归因或转化采集。llms.txt 是内容说明材料，不能当作收录承诺，更不是被模型引用的保证。

原研究对采样次数存在不同建议。正式实验应固定问题、时间、引擎模式和重复次数，保留原始回答，不把一次出现品牌名称当作稳定增长。

五、审核工作台选择了更轻的技术

菇勇者工作台不使用 React 或 Vite。它把状态函数与 DOM 渲染分开，并让业务逻辑同时能在浏览器和 CommonJS 环境中使用，从而用 Node 的断言直接测试。

已实现的能力包括筛选、选择、预览、本地图片替换、内部检查和 JSON 导出。对于一个轻量审核原型，纯函数加原生界面是一种合理选择，不必为了使用框架增加构建层。

状态与界面分离还让测试可以检查选择是否唯一、筛选后是否仍有可见选中项、字号是否被限制，以及导出字段是否稳定。这些都比只检查页面截图更容易定位问题。

六、不要把按钮文案当成功能说明

工作台的“资产库、分镜、动效、发布”导航，当前主要改变选中样式和提示文本，没有切换独立业务模块。“重新上传”使用本地文件选择和对象 URL，不存在真实上传接口。

界面显示的初始审核进度来自种子状态；帧数和时长也由统一元数据赋值，而不是读取动画文件计算。它们适合演示信息布局，不能用于汇报真实审核产能。

JSON 导出证明可以导出当前状态，不等于素材二进制已经持久化，也不等于实现多人协作、权限或平台投稿。技术分享应依据事件处理代码，而不是依据按钮上的动词。

七、如何验证和继续演进

工作台可以先运行现有逻辑测试：

node demos/guyongzhe-studio/tests/studio-logic.test.cjs

它包含状态断言和部分 HTML/CSS 文本检查，不代替真实浏览器交互。继续演进时，需要补持久化策略、媒体信息解析、错误处理及真正的模块边界。

内容站应先补数据证据、运行时数据校验与统一路由集合，再验证构建和所有内部链接，最后才进行公开发布与增长采样。仓库的攀岩获客研究提出过复用这一模板，但目前没有因此生成攀岩版本的数据模型和页面系统。

结语

一个好原型应该尽快验证最关键的结构，而不是尽量看起来像完整产品。数据、路径、状态和副作用的契约清楚，才知道下一步该补什么，也才不会把漂亮界面当成业务闭环。