manual save(2026-01-23 10:47)

This commit is contained in:
SiteAgent Bot
2026-01-23 10:47:24 +08:00
parent 56c3d66955
commit b638cf80a0

322
turingflow-website-ia-v1.md Normal file
View File

@@ -0,0 +1,322 @@
# 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`、基础 SEOtitle/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
- PSTELPolitical / 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
CTAContact弱化显示例如右侧按钮/链接,但视觉不抢主导航)
### 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 强耦合(除非是全站共享状态,如导航高亮)