# Turingflow 官网 V1：信息架构（IA）与页面骨架说明（工程交付稿） > 目标：交付给工程师 / 前端团队，作为官网 V1 的结构基线。 > > - 确保：页面不缺、不乱、不走偏 > - 确保：各一级页面存在理由与内容边界清晰 > - 确保：后续内容 / 设计 / 交互可在该结构稳定扩展 --- ## 0. V1 总体原则（不可偏离） - 官网是「思想驱动型官网」，不是「产品陈列型官网」。 - V1 基线不可随意增删一级页面；新增内容优先落在既有页面/Section 或 Discovery 内容系统内。 - 所有新内容必须回答：是否服务于「全球化决策」主线？ - 统一全站 Header / Footer；全站视觉与交互遵循同一套 Design Token。 - 不设传统 SaaS 页面：Blog、Pricing、Docs 等均不在 V1 范围。 - `Discovery` 是内容系统入口（思想与决策），不是博客（不以时间线叙事为唯一组织方式）。 --- ## 1. 站点结构与路由（V1） ### 1.1 路由树 ```txt / ├─ / 首页 Home ├─ /why 我们解决什么 Why ├─ /how 我们如何做到 How ├─ /system 产品与系统 What ├─ /discovery Discovery（思想与决策） ├─ /solutions 行业与方案 Solutions ├─ /proof 案例与信任 Proof └─ /contact 联系我们 Contact ``` ### 1.2 路由清单（工程落地） | Route | Page | 责任边界（必须清晰） | 非目标（不要做） | |---|---|---|---| | `/` | Home | 建立世界观 + 抛出方法论 + 建立信任 | 不做「功能列表」与「长文档堆砌」 | | `/why` | Why | 描述问题空间，与 CEO 认知共鸣 | 不介绍产品模块/功能细节 | | `/how` | How | 解释差异化方法论与护城河 | 不做「实现细节/技术文档」 | | `/system` | System | 展示系统全景与模块协同关系 | 不做「功能点清单」 | | `/discovery` | Discovery | 思想领导力入口 + 内容系统承载 | 不变成 blog；不引入 docs/pricing | | `/solutions` | Solutions | 帮用户判断是否适配（按行业） | 不做「销售型方案页」堆叠 | | `/proof` | Proof | 降低决策风险（信任与案例） | 不做「客户 logo 墙」替代证据 | | `/contact` | Contact | 低压力下一步：对话与入口 | 不做强压销售漏斗 | --- ## 2. 全站通用工程约束（建议） > 注：技术选型可由团队决定，但需支持 SSG/ISR（或等价能力）以保障 SEO 与内容扩展。 ### 2.1 技术层级（建议） - 前端：Next.js / Nuxt / Astro（支持 SSG + ISR） - 内容层：MDX / Headless CMS - 样式：Design Token（字体 / 间距 / 颜色）全站统一 ### 2.2 页面结构规范（必须执行） - 每个页面由若干 **Section（屏）** 组成。 - 每个 Section 必须满足： - 唯一主题（一个 Section 只回答一件事） - 独立容器（可独立渲染与独立样式） - 可复用（同类信息结构可跨页面复用） ### 2.3 全站 Layout 约束（必须执行） - 全站共用：`Header`、`Footer`、基础 SEO（title/description/OG）与主内容容器。 - 导航与 CTA 规则见「第 4 节」。 --- ## 3. 一级页面结构说明（工程视角） > 说明：以下为 **页面骨架（Section 划分）**。内容/设计/交互在不破坏 Section 语义边界的前提下自由扩展。 ### 3.1 首页 `/`（Home） **页面目标** - 建立世界观 - 抛出方法论 - 建立信任 **Section 结构（不可缺失）** ```txt HomePage ├─ HeroWorldView 世界观判断 ├─ DecisionProblem 决策不可控 ├─ CoreThesis 反常识观点 ├─ Methodology 方法论来源 ├─ SystemOverview 系统级解法 ├─ DiscoveryIntro 决策雷达 ├─ MeasurableOutcome 可度量结果 ├─ TrustProof 权威背书 └─ SoftCTA 行动入口 ``` **边界说明（重要）** - `SystemOverview` 只讲“系统级解法是什么”，不要展开到 system 页的模块细节。 - `DiscoveryIntro` 只作为入口引导，不替代 discovery 的内容体系。 --- ### 3.2 我们解决什么 `/why`（Why） **页面目标** - 与 CEO 认知共鸣 - 描述问题空间，而非产品 **Section 结构（不可缺失）** ```txt WhyPage ├─ GlobalContext 全球环境变化 ├─ RealDecisionFear 决策者真实焦虑 ├─ FalseSolutions 传统解法失效 └─ ProblemReframe 问题重定义 ``` **边界说明（重要）** - 禁止出现产品模块卡片/功能列表。 - 允许出现“反例/误区/传统解法”以形成对比，但不要引入竞品对比表。 --- ### 3.3 我们如何做到 `/how`（How） **页面目标** - 讲清楚“为什么你们不一样” - 构建方法论护城河 **Section 结构（不可缺失）** ```txt HowPage ├─ MethodologyOrigin 方法论来源 ├─ ComplianceAsGrowth 核心思想 ├─ WhyAgentSystem 为什么是 Agent ├─ ExecutionModel 执行模式（OaaS） └─ Boundary 适用边界说明 ``` **边界说明（重要）** - `WhyAgentSystem` 只解释必要性与系统逻辑，不落地到工程实现细节（避免变成技术博客）。 - `Boundary` 是强约束：必须明确适用/不适用，避免“万能叙事”。 --- ### 3.4 产品与系统 `/system`（What） **页面目标** - 展示系统全景，而非功能列表 **Section 结构（不可缺失）** ```txt SystemPage ├─ SystemMap 全局系统图 ├─ GComply 合规系统模块 ├─ GGrowth 增长系统模块 ├─ GBrain Agent 协同层 └─ DiscoveryModule 决策入口模块 ``` **边界说明（重要）** - `SystemMap` 必须存在，用于建立后续模块叙事的坐标系。 - 每个模块 Section 讲“模块是什么、输入输出、协同关系、价值”，不要做功能点罗列。 --- ### 3.5 `/discovery`（Discovery） **页面目标** - 展示思想领导力 - 承载内容系统 **Section 结构（不可缺失）** ```txt DiscoveryPage ├─ DiscoveryPositioning 定位说明 ├─ ContentTypes 内容类型入口 ├─ LatestInsights 最新内容流 └─ DecisionValue 内容如何用于决策 ``` **工程说明（必须支持）** - 内容标签（至少预留数据结构与筛选能力）： - 国家（Country） - 行业（Industry） - PSTEL（Political / Social / Technology / Economic / Legal） - 允许后续 A/B 样式实验： - 仅能替换呈现与排序逻辑，不改变信息架构与入口语义 **边界说明（重要）** - 不新增 `/blog`；若未来出现长内容，仍归属于 `/discovery` 的内容类型体系。 --- ### 3.6 `/solutions`（Solutions） **页面目标** - 帮用户判断“是否适合我” **Section 结构（不可缺失）** ```txt SolutionsPage ├─ IndustryLogic 为什么按行业拆 ├─ IndustryList 行业卡片列表 ├─ IndustryTemplate 单行业展开模板 └─ FitCriteria 适配与不适配说明 ``` **边界说明（重要）** - `IndustryTemplate` 是结构模板（信息架构），不等于“每个行业一篇独立一级页面”。 - 不允许出现按行业新增一级路由（例如 `/solutions/xxx`）作为 V1 既定要求外的扩张；若需要可先用页面内锚点或可展开区域实现。 --- ### 3.7 `/proof`（Proof） **页面目标** - 降低决策风险 **Section 结构（不可缺失）** ```txt ProofPage ├─ ProofPhilosophy 为什么强调复杂场景 ├─ GovernmentCases 政府级案例 ├─ EnterpriseCases 企业级案例 └─ CapabilitySummary 能力总结 ``` **边界说明（重要）** - `GovernmentCases` 与 `EnterpriseCases` 分开是结构要求；案例内容可先占位，但分组必须明确。 --- ### 3.8 `/contact`（Contact） **页面目标** - 提供低压力下一步 **Section 结构（不可缺失）** ```txt ContactPage ├─ ConversationInvite 邀请式文案 ├─ ContactForm 基础表单 └─ AlternativeCTA 其他沟通方式 ``` **边界说明（重要）** - 表单字段以“建立对话”为目标（少字段）；不要引入长问卷。 --- ## 4. 导航与路由建议（Header / Footer） ### 4.1 Header 导航（不超过 6 项） - 首页 - Why - How - System - Discovery - Solutions - Proof CTA：Contact（弱化显示；例如右侧按钮/链接，但视觉不抢主导航） ### 4.2 Footer（建议包含但不新增一级页面） - 复用 Header 的主要链接 - 基础信息：公司名 / 版权 / 可选的社媒入口（若有） - 合规/隐私类链接：如未来需要，优先用弹窗或外链，不在 V1 新增一级页面（需新增时必须重新评审 IA） --- ## 5. 工程交付检查清单（V1 验收基线） - 路由 8 个一级页面齐全且路径一致（见第 1 节）。 - 全站统一 Header / Footer；任一页面不允许独立导航体系。 - 每个一级页面的 Section 列表完整，不缺失、不合并到无法辨识。 - Discovery 支持标签筛选的数据结构预留：国家 / 行业 / PSTEL。 - 未新增 blog/pricing/docs 等传统 SaaS 一级页面。 - 新增任何页面/入口前，必须回答并记录：是否服务于「全球化决策」主线？ --- ## 6. 附录：页面与 Section 命名规范（建议） - 页面组件：`HomePage` / `WhyPage` / `HowPage` / `SystemPage` / `DiscoveryPage` / `SolutionsPage` / `ProofPage` / `ContactPage` - Section 组件：使用 UpperCamelCase，与本文件 Section 名称保持一致（便于沟通与排期）。 - Section 对外契约： - 入参（props）尽量只接收该 Section 的数据 - 避免跨 Section 强耦合（除非是全站共享状态，如导航高亮）