Vulcan - 项目

Lava 之后的下一步

Lava → Vulcan · 同一条副业探索链路

Lava 解决的是“哪些需求值得看”，Vulcan 解决的是“如何把值得看的需求做成可试的东西”。关键词只是起点；还需要判断用户要计算、比较、生成还是自查，再组织即时价值、内容和反馈入口。这个项目把需求探索与产品生产连接起来。

Lava筛选需求、Vulcan生产页面、后续观察反馈的三段链路。 — 让发现需求与动手验证之间的交接成为一套流程。

页面规格与组件

从人工选组件，到结构化页面契约

我最初用 YAML 的方式描述网站：AI 深入理解关键词，把页面需要的内容、组件和样式组织进一份详细配置。当前代码把这个思路落实为 PageSchemaV2 JSON 契约。内容、布局、组件参数、按钮、主题与 SEO 可以分别配置，由共享渲染器读取；标准页面的变化可以优先发生在规格层。

PageSchemaV2的sections、layout、content、props和cta字段分别对应页面结构与交互。 — 结构化规格连接产品判断与组件执行。

先明确页面上的任务

产品原型先行 · 同一组件体系容纳不同任务

不同关键词背后的任务不同。工资计算需要输入和结果，广告自查需要问题与发现，报价比较需要并排判断。项目用页面原型计划约束首屏、即时价值、必需模块和禁止承诺，再组合对应模块；差异化检查也限制不同原型无解释地复用同一段落顺序。复用的是生产能力，具体页面仍要服从需求。

计算器、自查页、比较页分别使用输入结果、问题发现、并排矩阵结构。 — 先确定产品任务，组件组合才有依据。

一个可以试用的入口

Google Ads 自查原型 · 产品价值与承诺边界

广告自查示例明确选择 self_report：用户回答控制项后得到规则评分和待核查的风险提示。它不能据此声称已检查广告账户，更不能推算精确浪费金额。原型计划把这些边界与“先提供诊断价值，再提出人工复核入口”写在一起。Vulcan 要生产的是可用的需求验证入口；页面数量只是过程指标。

广告自查示例通过是、否、不确定的选择组织发现，并在完成价值体验后提供人工复核入口。 — 自查只解释回答所支持的发现，账户级结论需要更多数据。

发布前的检查

规格存在 · 检查通过 · 人工复核 · 实验发布

生成结果要留下可检查的产物。当前中游链路保存规格与 QA 记录：普通生成任务即使报告成功，缺少页面规格也不能推进候选状态。AI 修复循环设置轮次上限，停滞时保留较好版本；人工复核后才进入实验发布，默认 noindex。质量检查仍有实现边界，需要继续核验渲染、事实和工具结果。

生成任务经规格检查和QA进入复核，失败分支保留记录，实验发布默认不索引。 — 产物、质量与发布状态分开，保留可检查的交接点。

复用已有的建站经验

本地可见产物 · 持续演进中的网站工厂

仓库中可见 10 份本地生成页面规格，以及 10 份页面示例规格；页面原型契约定义了 9 类任务。这些证据展示了从单页实现走向规格、组件与检查复用的工程积累。Signal、Forge、Yield 进一步表达发现、生产与反馈的方向。真正需要持续验证的是：产出的页面能否帮助用户完成任务，以及观察到的使用信号是否值得继续投入。

10份本地生成规格、10份示例规格、9类页面原型，并指向任务完成和反馈验证。 — 工厂的意义，是让需求探索能够进入反复检验。

我的工作

我为自己的副业构建 Vulcan，承接 Lava 筛出的关键词，将反复建站的工作组织成“需求判断—页面规格—组件组合—检查与发布”的生产方式。提前打磨的组件承担复用，AI 负责围绕关键词形成详细规格；当前仓库以结构化 JSON 页面规格实现这一思路。

画面为机制解释或界面重建，示例规格、状态与问题用于说明设计。本地文件盘点不代表线上网站规模或商业成果。