diff --git a/README.md b/README.md
index c971615..699f901 100644
--- a/README.md
+++ b/README.md
@@ -1,127 +1,149 @@
-# 随行案｜AI 方案设计工程化展示仓
+# 随行案｜AI 应用真实性偏差校准展示仓
 
-> **随行案不是“AI 一键写完方案”，而是让 AI 先生成可校准的方案草案，把真实需求、真实数据、版本留痕和回流复盘纳入同一套工作流。**
+> 本仓库不是可复刻的工作流架构仓，而是随行案的对外展示仓：用于说明随行案如何定义并解决 AI 应用落地中的核心问题——真实性偏差。
 
-<div align="center">
+## 让 AI 输出不只是漂亮，而是越来越接近真实业务
 
-## 快速出草案，长期沉淀方案能力，企业级重构方案设计流程
+**问题定义 · 产品定位 · 方法论展示 · 商业价值 · 平台合作 · 企业试点意向**
 
-**GitHub 母仓沉淀核心架构 · 云平台承载运行交付 · 人完成关键洞察与商业判断**
+`真实性偏差` · `方案设计工程化` · `AI 工作流落地` · `真实需求校准` · `版本留痕` · `反馈回流` · `平台合作`
 
-`方案草案` · `需求数据绑定` · `版本留痕` · `回流复盘` · `私人方案库` · `企业内控`
+---
+
+## 1. 展示仓定位
+
+本仓库用于对外展示随行案的：
+
+- 核心问题定义；
+- 产品定位与价值边界；
+- 方案设计工程化方法论；
+- 个人版 / VIP版 / 企业版商业价值；
+- 企业场景与试点方向；
+- AI 平台、云平台、大模型生态合作意向；
+- 版权、授权与商业合作边界。
 
-</div>
+本仓库不再承担试运行工作流展示功能，也不公开可直接复刻的核心架构、工作流细节、模板规则、部署代码、模型调用配置、客户数据和企业交付细节。
+
+一句话：
+
+> 展示仓不是技术交底书，而是随行案的合作邀请函。
 
 ---
 
-## 1. 产品定位
+## 2. 核心问题：真实性偏差
 
-**随行案是一套面向方案设计场景的 AI 工作流产品模型。**
+AI 应用落地最大的难题，不是 AI 不会生成内容，而是：
 
-它的核心不是替人完成最终商业方案，而是把方案设计中最容易消耗人的低价值流程工程化处理，让人把精力放回真实需求、真实数据和关键洞察。
+> AI 生成的内容往往逻辑漂亮、结构完整、表达专业，但不一定贴合真实数据、真实需求和真实执行条件。
 
-一句话：
+直接让 AI 生成方案，容易得到一份“看起来正确”的方案，但它可能并没有真正进入业务现场。
 
-> **AI 承载方案草案，人完成商业跃迁。**
+而传统人工方案设计也存在另一种偏差：方案会被甲方新需求、上层新想法、跨部门意见反复修改，最后越来越宏大、越来越完整，却越来越偏离最初的真实需求与真实数据。
+
+因此，随行案关注的不是“让 AI 更会写方案”，而是：
+
+> 如何让 AI 输出持续接近真实业务。
 
 ---
 
-## 2. 解决的问题
+## 3. 产品定位
 
-| 用户类型 | 真实问题 | 随行案提供的价值 |
-|---|---|---|
-| **普通用户** | 不知道怎么从空白文档开始，方案结构不完整 | 快速生成一版结构完整、可继续修改的方案草案 |
-| **VIP 用户** | 每次方案都从零开始，经验无法沉淀 | 私人方案模板库、私人方案仓库、API 套餐和回流记录 |
-| **企业用户** | 方案过程不可追踪，多轮修改后需求和数据容易漂移 | 需求数据绑定、版本留痕、部门协同、权限内控和组织资产沉淀 |
+随行案是一套面向方案设计场景的 AI 工作流产品模型。
+
+它不是普通的 AI 方案生成器，也不是一键替人完成最终商业方案的工具。
+
+随行案的核心定位是：
+
+> 面向真实业务场景的 AI 方案设计校准系统。
+
+它通过真实需求、真实数据、版本过程、人工判断、反馈回流与模板沉淀，让 AI 输出从“漂亮草案”逐步接近“可落地方案”。
+
+更短表达：
+
+> AI 生成方案草案，人完成关键判断，系统持续校准真实性偏差。
 
 ---
 
-## 3. 核心方法论：70 / 20 / 10
+## 4. 方法论：70 / 20 / 10
+
+随行案将方案设计这种复杂脑力劳动重新拆解为三类价值：
 
-| 结构 | 含义 | 产品承载方式 |
+| 结构 | 含义 | 产品价值 |
 |---|---|---|
-| **70% 真实输入** | 客户需求、业务数据、预算、资源、约束、执行条件 | 用结构化字段和方案草案稳定记录 |
-| **20% 关键洞察** | 商业判断、方案杠杆点、非模板化创意 | 由人完成，决定方案上限 |
-| **10% 工程化承载** | 模板、格式、版本、留痕、协同、回流 | 由工作流系统尽量吸收 |
+| 70% 真实输入 | 客户需求、业务数据、预算、资源、约束、执行条件 | 决定方案方向是否真实 |
+| 20% 关键洞察 | 商业判断、方案杠杆点、非模板化创意 | 决定方案上限 |
+| 10% 工程化承载 | 模板、格式、版本、留痕、协同、回流 | 降低流程摩擦，保护真实信息不丢失 |
 
-> **模板保下限，真实输入定方向，关键洞察定上限。**
+> 模板保下限，真实输入定方向，关键洞察定上限。
 
 ---
 
-## 4. 产品架构
+## 5. 本仓库公开与不公开的边界
 
-```text
-GitHub 母仓
-  ├─ 方法论与产品叙事
-  ├─ 工作流规则与模板结构
-  ├─ 版本记录与回流机制
-  └─ 展示仓 / 参赛文档 / 合作说明
+本展示仓公开的是：
 
-云平台运行层
-  ├─ 服务器与数据库
-  ├─ 前端页面与后端接口
-  ├─ 大模型 API 调用
-  ├─ 安全、防火墙、备份
-  └─ 企业部署与持续运维
+- 问题定义；
+- 产品定位；
+- 方法论价值；
+- 商业分层；
+- 企业场景；
+- 平台合作方向；
+- 版权与合作边界。
 
-用户资产层
-  ├─ 个人历史方案
-  ├─ VIP 私人模板库
-  └─ 企业子仓 / 权限 / 内控 / 复盘资产
-```
-
-一句话：
+本展示仓不公开的是：
 
-> **GitHub 保核心，云平台做运行；母仓保方法，子仓沉淀客户资产。**
+- 可直接复刻的核心工作流；
+- 深层模板结构与字段规则；
+- 需求、数据、方案之间的具体绑定机制；
+- 版本回流与复盘机制的可执行细节；
+- 网页端、后端、数据库、服务器与模型调用配置；
+- 用户数据、客户数据、企业内控与权限规则；
+- 商业交付代码、合同、报价与定制方案细节。
 
 ---
 
-## 5. 展示仓目录
+## 6. 文档目录
 
 | 文档 | 主要回答的问题 |
 |---|---|
-| [`docs/01-product-narrative.md`](docs/01-product-narrative.md) | 随行案到底是什么，为什么不是普通 AI 写方案工具 |
-| [`docs/02-architecture-logic.md`](docs/02-architecture-logic.md) | GitHub 母仓、云平台运行层、用户资产层如何分工 |
-| [`docs/03-business-value.md`](docs/03-business-value.md) | 普通版、VIP版、企业版分别如何产生商业价值 |
-| [`docs/04-enterprise-architecture.md`](docs/04-enterprise-architecture.md) | 企业版如何做需求数据绑定、版本留痕、内控和组织沉淀 |
-| [`docs/05-cooperation-and-roadmap.md`](docs/05-cooperation-and-roadmap.md) | 如何用于 AI 产品赛事、平台合作、半开源路线和商业边界 |
+| [`docs/01-product-narrative.md`](docs/01-product-narrative.md) | 随行案为什么不是普通 AI 写方案工具，而是真实性偏差校准样板 |
+| [`docs/02-positioning-and-boundary.md`](docs/02-positioning-and-boundary.md) | 展示仓公开什么、不公开什么，以及随行案的产品边界 |
+| [`docs/03-business-value.md`](docs/03-business-value.md) | 个人版、VIP版、企业版分别如何产生商业价值 |
+| [`docs/04-enterprise-scenarios.md`](docs/04-enterprise-scenarios.md) | 企业为什么需要随行案，以及适合哪些试点场景 |
+| [`docs/05-cooperation-and-roadmap.md`](docs/05-cooperation-and-roadmap.md) | 赛事、平台、云生态、企业试点与合作路线 |
 | [`COPYRIGHT.md`](COPYRIGHT.md) | 展示仓版权、授权与商业使用边界 |
 
 ---
 
-## 6. 当前展示仓状态
+## 7. 合作方向
 
-本仓库用于：
+随行案欢迎以下方向的沟通与合作：
 
-- 产品叙事展示；
-- AI 产品赛事材料沉淀；
-- 平台合作沟通；
-- 企业客户初步理解；
-- 半开源技术路线展示；
-- 从 GitHub 核心架构到云平台运行层的产品化说明。
+- AI 产品大赛 / 创新创业赛事投稿；
+- 云平台与大模型平台生态合作；
+- AI 工作流真实业务落地样板合作；
+- 个人版 / VIP版试运行反馈；
+- 企业方案设计流程试点；
+- 企业级方案设计工程化定制；
+- 围绕“真实性偏差校准”的联合探索。
 
-本仓库不是完整企业交付版，也不包含客户数据、企业内控细节、API 密钥、服务器配置和商业化部署代码。
+面向平台的合作价值：
 
----
+> 随行案可以作为一个真实业务场景入口，展示 AI 应用如何持续消耗云平台、大模型、存储、日志、权限与运维能力。
 
-## 7. 合作方向
+面向企业的合作价值：
 
-- AI 产品大赛 / 创新创业赛事投稿；
-- 阿里云等平台型 AI 生态合作；
-- 个人版 / VIP版试运行；
-- 企业方案设计流程试点；
-- GitHub 母仓 + 云平台部署的 AI 工作流样板；
-- 企业级方案设计工程化定制。
+> 随行案帮助企业把方案设计从个人经验劳动，升级为可追踪、可复盘、可协同、可沉淀的组织能力。
 
 ---
 
 ## 8. 版权与使用边界
 
-本展示仓用于产品展示、试运行、赛事投稿、合作沟通与客户评估。
+本展示仓用于产品展示、赛事投稿、合作沟通与客户评估。
 
-除明确标注来源的第三方内容外，仓库中的结构设计、工作流设计、模板字段、展示文案、产品叙事与试运行骨架，版权均归仓库维护方所有。
+除明确标注来源的第三方内容外，仓库中的产品叙事、方法论表达、商业定位、文档结构与展示内容，版权均归仓库维护方所有。
 
-- 允许查看、测试、评估；
+- 允许查看、评估与合作沟通；
 - 未经授权，不得复制后重新发布；
 - 未经授权，不得二次包装、商用部署或对外售卖；
 - 如需商业合作、企业接入、定制化改造或二次开发，请先联系仓库维护方。
@@ -130,13 +152,6 @@ GitHub 母仓
 
 ---
 
-## 联系方式
-
-- 微信：2254473740
-- 邮箱：2254473740@qq.com
-
----
-
 ## 相关仓库
 
 - 主仓库：https://github.com/yu5-520/Solution-Design-Engineering
diff --git a/docs/02-architecture-logic.md b/docs/02-architecture-logic.md
deleted file mode 100644
index ce16f7e..0000000
--- a/docs/02-architecture-logic.md
+++ /dev/null
@@ -1,182 +0,0 @@
-# 02｜产品架构：核心资产、运行交付与用户资产分层
-
-> 本文回答一个问题：随行案的技术与商业架构如何分层，为什么适合半开源与企业交付。
-
----
-
-## 1. 三层架构
-
-随行案不是把所有内容都放在一个平台里，而是拆成三层：
-
-| 层级 | 主要承载 | 是否开放 | 核心作用 |
-|---|---|---|---|
-| **核心资产层** | GitHub 母仓、展示仓、方法论、工作流、模板结构、版本记录 | 展示仓开放，母仓阶段性受控 | 保存随行案的产品骨架和可迭代能力 |
-| **运行交付层** | 服务器、数据库、网页、API、大模型调用、安全、运维 | 不开放 | 让产品真正运行、部署、交付和维护 |
-| **用户资产层** | 个人历史方案、VIP 私人模板库、企业子仓、客户数据、复盘记录 | 用户 / 企业私有 | 沉淀用户自己的方案资产和组织知识 |
-
-一句话：
-
-> **核心资产可展示，运行系统可交付，用户数据必须私有。**
-
----
-
-## 2. 核心资产层：GitHub 母仓与展示仓
-
-GitHub 在随行案中不是单纯代码仓库，而是产品核心资产的承载方式。
-
-### 2.1 母仓承载
-
-母仓适合保存：
-
-- 工作流主链路；
-- 输入 / 输出规则；
-- 模板结构；
-- 回流复盘机制；
-- 版本处理逻辑；
-- 需求—数据—方案模块绑定规则；
-- 可执行流程；
-- 技术实现；
-- 企业版可复用底层模块。
-
-母仓回答的是：
-
-> **随行案怎么运行。**
-
-### 2.2 展示仓承载
-
-展示仓适合保存：
-
-- 产品叙事；
-- 商业价值；
-- 架构说明；
-- 合作路线；
-- 参赛材料；
-- 半开源边界；
-- 对外信任背书。
-
-展示仓回答的是：
-
-> **随行案为什么值得相信。**
-
----
-
-## 3. 运行交付层：云平台与企业部署
-
-运行交付层负责把核心资产层的能力变成真实产品。
-
-可承载内容包括：
-
-- ECS / 云服务器；
-- 数据库；
-- 前端页面；
-- 后端接口；
-- 大模型 API 调用；
-- 用户登录与权限；
-- 文件存储；
-- 安全防护；
-- 防火墙；
-- 备份与运维；
-- 企业私有化部署。
-
-运行交付层回答的是：
-
-> **随行案如何被用户访问、被企业部署、被持续维护。**
-
----
-
-## 4. 用户资产层：个人库、VIP库、企业子仓
-
-用户资产层保存使用过程中产生的私有资产。
-
-### 4.1 个人资产
-
-- 历史方案；
-- 输入记录；
-- 常用需求字段；
-- 草案修改记录。
-
-### 4.2 VIP 资产
-
-- 私人方案模板库；
-- 私人方案仓库；
-- API / 模型偏好；
-- 客户记录；
-- 回流复盘记录；
-- 个人方案风格。
-
-### 4.3 企业资产
-
-- 企业内部模板；
-- 客户需求数据；
-- 部门流程；
-- 角色权限；
-- 审批记录；
-- 方案版本；
-- 成功案例；
-- 项目复盘。
-
-用户资产层回答的是：
-
-> **用户为什么越用越离不开，企业为什么愿意长期付费。**
-
----
-
-## 5. 产品模块视角
-
-| 模块 | 所属层级 | 主要价值 |
-|---|---|---|
-| 草案生成模块 | 运行交付层 | 将结构化输入转成可修改方案草案 |
-| 模板管理模块 | 核心资产层 / 用户资产层 | 提供通用模板，并支持私人或企业模板沉淀 |
-| 需求数据绑定模块 | 核心资产层 / 企业资产层 | 将方案模块与真实需求、数据依据建立对应关系 |
-| 版本留痕模块 | 运行交付层 / 用户资产层 | 记录修改原因、修改人、时间和影响范围 |
-| 回流复盘模块 | 用户资产层 | 将有效方案经验沉淀为下一次可复用资产 |
-| 权限内控模块 | 企业资产层 / 运行交付层 | 支持企业角色、审批、数据隔离和安全管理 |
-
----
-
-## 6. 半开源技术路线
-
-随行案适合采用半开源路线：
-
-| 内容 | 开放策略 |
-|---|---|
-| 展示仓 | 开放，用于产品叙事、合作沟通、赛事背书 |
-| 基础说明文档 | 开放，用于建立理解和信任 |
-| 通用模板示例 | 可部分开放，用于降低用户理解门槛 |
-| 母仓核心工作流 | 阶段性受控，成熟后可选择部分开放 |
-| 服务器、数据库、API密钥 | 不开放 |
-| 用户数据、企业数据 | 私有，不开放 |
-| 企业权限、内控、定制规则 | 商业交付，不开放或授权交付 |
-
-最短表达：
-
-> **展示开源，核心受控，数据私有，企业定制。**
-
----
-
-## 7. 平台合作边界
-
-随行案可以使用云平台做运行、部署和推广，但核心资产不应完全绑定在单一平台。
-
-推荐边界：
-
-- GitHub 保存核心架构、工作流、模板与版本记录；
-- 云平台承载服务器、数据库、API、安全和企业部署；
-- 用户资产进入私人库或企业子仓；
-- 商业深度能力通过 VIP 订阅和企业定制交付。
-
-一句话：
-
-> **借平台的运行能力，不交出产品的核心资产。**
-
----
-
-## 8. 架构总结
-
-随行案的架构价值是：
-
-> **把方案设计能力从个人经验和临时文档中抽离出来，拆成可展示、可运行、可沉淀、可商业化交付的产品系统。**
-
-最短表达：
-
-> **GitHub 建信任，云平台做交付，用户资产形成续费和企业价值。**
diff --git a/docs/02-positioning-and-boundary.md b/docs/02-positioning-and-boundary.md
new file mode 100644
index 0000000..07bd93b
--- /dev/null
+++ b/docs/02-positioning-and-boundary.md
@@ -0,0 +1,174 @@
+# 02｜定位与边界：展示仓公开什么，不公开什么
+
+> 本文回答一个问题：展示仓应该让外部理解什么，又应该保护哪些核心资产。
+
+---
+
+## 1. 展示仓的新定位
+
+展示仓不再是试运行工作流仓，也不是可复刻架构说明书。
+
+它的核心用途是：
+
+> 用公开文档说明随行案的核心问题、产品定位、方法论价值、商业边界与合作方向。
+
+因此，本仓库更接近：
+
+- 产品说明书；
+- 赛事与路演材料沉淀；
+- 合作沟通入口；
+- 企业试点理解材料；
+- 个人 IP 与项目可信度背书。
+
+它不承担：
+
+- 工作流执行；
+- 核心架构交底；
+- 模板规则开放；
+- 企业交付代码公开；
+- 客户数据或私有流程展示。
+
+---
+
+## 2. 为什么不再公开试运行工作流
+
+随行案已经具备网页端试运行入口后，展示仓不再需要承担“证明工作流能跑”的任务。
+
+继续公开过细的工作流结构，可能带来三个问题：
+
+| 问题 | 影响 |
+|---|---|
+| 可复制路径过清晰 | 外部可以模仿工作流和代码组织方式 |
+| 产品重心被误读 | 评审或合作方容易把随行案看成开源模板，而不是合作项目 |
+| 商业边界变模糊 | 核心资产、交付能力和合作价值被提前暴露 |
+
+因此，展示仓应该从“展示怎么做”转向“展示为什么值得合作”。
+
+最短表达：
+
+> 展示仓展示定位，不展示底层做法；展示合作价值，不展示可复刻路径。
+
+---
+
+## 3. 展示仓应该公开的内容
+
+展示仓应该公开这些内容：
+
+### 3.1 问题定义
+
+重点说明：
+
+- AI 应用落地为什么会遇到真实性偏差；
+- 直接让 AI 生成方案为什么容易脱离真实业务；
+- 传统人工方案为什么也会在反复修改中失真；
+- 为什么复杂脑力劳动不能只靠一次性生成解决。
+
+### 3.2 产品定位
+
+重点说明：
+
+- 随行案不是普通 AI 写方案工具；
+- 随行案不是替人完成最终商业方案；
+- 随行案是面向真实业务场景的 AI 方案设计校准系统；
+- 它用工程链承载真实输入、草案生成、人工判断、版本留痕和反馈回流。
+
+### 3.3 方法论价值
+
+重点说明：
+
+- 70% 真实输入；
+- 20% 关键洞察；
+- 10% 工程化承载；
+- 模板保下限，真实输入定方向，关键洞察定上限。
+
+### 3.4 商业价值
+
+重点说明：
+
+- 个人版解决从空白文档开始的问题；
+- VIP版沉淀个人方案资产；
+- 企业版重构组织方案能力；
+- 平台合作可以连接 AI 应用、云平台、大模型与真实业务场景。
+
+### 3.5 合作意愿
+
+重点说明：
+
+- AI 产品赛事合作；
+- 云平台和大模型生态合作；
+- 企业试点合作；
+- AI 工作流真实业务场景样板合作；
+- 围绕真实性偏差校准的联合探索。
+
+---
+
+## 4. 展示仓不应公开的内容
+
+展示仓不应公开以下内容：
+
+| 类型 | 不公开原因 |
+|---|---|
+| 核心工作流步骤 | 容易被直接复刻 |
+| 深层模板结构 | 属于产品沉淀与企业交付资产 |
+| 字段规则与绑定规则 | 属于真实性校准机制的核心组成 |
+| 版本回流具体机制 | 属于长期产品壁垒 |
+| 网页端和后端实现 | 属于运行交付能力 |
+| 数据库和服务器配置 | 属于部署与安全边界 |
+| 用户数据和客户数据 | 属于隐私与商业保护范围 |
+| 企业权限与内控细节 | 属于企业定制交付内容 |
+| 定价、合同和交付底线 | 属于商业谈判边界 |
+
+原则是：
+
+> 可以展示问题与价值，不展示可复制路径；可以展示合作方向，不展示商业底牌。
+
+---
+
+## 5. 展示仓、运行端、私有核心资产的分工
+
+随行案后续应形成三类资产分工：
+
+| 资产 | 主要作用 | 开放程度 |
+|---|---|---|
+| 展示仓 | 对外说明定位、问题、价值、合作方向 | 公开 |
+| 网页端 / 运行端 | 提供真实试运行和产品体验 | 可控开放 |
+| 私有核心资产 | 保存核心工作流、模板规则、交付细节和企业定制能力 | 受控或私有 |
+
+三者的关系是：
+
+> 展示仓负责建立信任，网页端负责验证体验，私有核心资产负责形成商业壁垒。
+
+---
+
+## 6. 对外表达边界
+
+对外沟通时，不建议说：
+
+> 这是一个可以照着搭建的开源 AI 工作流仓库。
+
+更适合说：
+
+> 这是随行案的对外展示仓，用于说明我们如何以方案设计为切口，解决 AI 应用落地中的真实性偏差问题，并探索与云平台、大模型平台和企业真实业务场景的合作可能。
+
+对外表达的关键词应是：
+
+- 真实性偏差；
+- 方案设计工程化；
+- AI 应用落地；
+- 真实需求校准；
+- 版本留痕；
+- 反馈回流；
+- 企业试点；
+- 平台合作。
+
+---
+
+## 7. 总结
+
+展示仓的新边界是：
+
+> 展示问题，不暴露底层；展示定位，不交出架构；展示合作价值，不公开商业核心。
+
+最短表达：
+
+> 展示仓不是技术交底书，而是合作邀请函。
diff --git a/docs/04-enterprise-architecture.md b/docs/04-enterprise-architecture.md
deleted file mode 100644
index 0b0235e..0000000
--- a/docs/04-enterprise-architecture.md
+++ /dev/null
@@ -1,243 +0,0 @@
-# 04｜企业版：方案设计流程重构系统
-
-> 本文回答一个问题：企业版随行案具体解决什么组织问题，需要哪些产品模块。
-
----
-
-## 1. 企业版定位
-
-企业版随行案不是普通会员升级，而是面向组织的方案设计流程系统。
-
-它服务的不是单个用户“写得快”，而是企业团队：
-
-> **让方案设计过程可追踪、可复盘、可协同、可沉淀。**
-
----
-
-## 2. 企业用户的采购理由
-
-企业采购随行案，不是因为员工不会写方案，而是因为方案过程存在管理问题。
-
-| 问题 | 影响 |
-|---|---|
-| 需求记录分散 | 方案依据不稳定，客户真实诉求容易丢失 |
-| 数据依据断裂 | 方案判断难解释，复盘时无法归因 |
-| 版本混乱 | 多轮修改后不知道为什么改、谁改的、改了哪里 |
-| 方向漂移 | 方案越改越大，逐渐偏离原始需求 |
-| 经验无法沉淀 | 成功方案不能复用，新人接不住老员工经验 |
-| 协同成本高 | 销售、运营、产品、技术、管理层沟通成本上升 |
-| 内控不足 | 客户数据、方案权限、审批记录缺乏统一管理 |
-
-企业版的采购理由是：
-
-> **降低方案过程失控，沉淀组织方案能力。**
-
----
-
-## 3. 企业版目标时间结构
-
-随行案企业版希望把部门方案设计时间调整为：
-
-| 时间结构 | 投入方向 | 系统支持 |
-|---|---|---|
-| **70%** | 真实客户需求、真实数据、业务约束、执行条件 | 结构化输入、需求数据绑定、客户记录 |
-| **20%** | 关键洞察、商业判断、方案杠杆点 | 人工评审节点、方向校准、关键判断记录 |
-| **10%** | 回流、复盘、留痕、模板更新、流程沉淀 | 版本留痕、复盘记录、模板回流 |
-
-目标不是让团队少思考，而是让团队把思考放在更高价值的位置。
-
----
-
-## 4. 企业版产品模块
-
-### 4.1 需求采集模块
-
-记录客户和项目的真实输入。
-
-字段示例：
-
-- 客户背景；
-- 项目目标；
-- 当前问题；
-- 预算范围；
-- 时间周期；
-- 资源条件；
-- 决策人关注点；
-- 已知约束；
-- 成功标准。
-
-### 4.2 数据依据模块
-
-将方案判断绑定到数据来源。
-
-能力包括：
-
-- 数据来源记录；
-- 数据更新时间；
-- 数据可信度说明；
-- 数据对应的方案模块；
-- 数据变化后的影响提示。
-
-### 4.3 草案生成模块
-
-基于结构化需求、数据和模板生成方案草案。
-
-定位：
-
-> **生成可校准草案，而不是最终方案。**
-
-### 4.4 人工校准模块
-
-让团队在关键节点进行人工判断。
-
-记录内容：
-
-- 核心洞察；
-- 方向选择；
-- 取舍理由；
-- 风险判断；
-- 是否进入下一版。
-
-### 4.5 版本留痕模块
-
-记录每次修改。
-
-建议记录：
-
-- 修改人；
-- 修改时间；
-- 修改原因；
-- 对应需求；
-- 对应数据；
-- 影响模块；
-- 是否需要复核。
-
-### 4.6 协同评审模块
-
-支持不同角色围绕同一套方案流程协作。
-
-角色示例：
-
-- 销售；
-- 运营；
-- 产品；
-- 技术；
-- 管理层；
-- 客户成功；
-- 法务 / 财务等支持角色。
-
-### 4.7 权限与内控模块
-
-满足企业管理和安全要求。
-
-能力包括：
-
-- 角色权限；
-- 部门权限；
-- 客户数据隔离；
-- 审批流程；
-- 操作记录；
-- 访问控制；
-- 安全防护；
-- 数据备份。
-
-### 4.8 回流复盘模块
-
-把完成后的项目经验转化为企业资产。
-
-回流内容包括：
-
-- 有效需求判断；
-- 有效数据依据；
-- 可复用方案模块；
-- 成功表达方式；
-- 失败原因；
-- 风险提示；
-- 新模板或旧模板更新建议。
-
----
-
-## 5. 企业版工作流
-
-```text
-客户 / 项目需求进入
-  ↓
-需求采集模块结构化记录
-  ↓
-数据依据模块补充真实数据与约束
-  ↓
-草案生成模块输出方案草案
-  ↓
-人工校准模块记录关键洞察与方向判断
-  ↓
-版本留痕模块记录修改过程
-  ↓
-协同评审模块完成跨角色确认
-  ↓
-权限与内控模块管理访问、审批与安全
-  ↓
-最终方案交付
-  ↓
-回流复盘模块沉淀为企业方案资产
-```
-
----
-
-## 6. 企业版防失真机制
-
-| 失真方向 | 风险 | 企业版校准方式 |
-|---|---|---|
-| **AI 幻觉型失真** | 草案看起来合理，但需求和数据不真实 | 真实需求输入、数据依据绑定、人工校准节点 |
-| **宏大叙事型失真** | 多轮修改后方案越来越大，偏离原始问题 | 版本留痕、修改原因记录、需求回溯、复盘机制 |
-
-企业版的目标是：
-
-> **让方案在每一次生成、修改和升级中，都能回到真实需求与真实数据。**
-
----
-
-## 7. 企业版交付方式
-
-企业版适合采用定制化交付。
-
-### 7.1 交付前调研
-
-- 企业方案类型；
-- 现有流程；
-- 参与部门；
-- 关键痛点；
-- 数据安全要求；
-- 权限结构；
-- 成功标准。
-
-### 7.2 一次性定制交付
-
-- 企业流程配置；
-- 模板体系搭建；
-- 权限与审批规则；
-- 部署与初始化；
-- 初始培训；
-- 试运行支持。
-
-### 7.3 年度运维服务
-
-- 系统运行；
-- 功能更新；
-- bug 修复；
-- API / 模型适配；
-- 数据备份；
-- 安全防护；
-- 技术支持；
-- 企业流程持续优化。
-
----
-
-## 8. 企业版总结
-
-企业版随行案的核心不是“让 AI 多写几份方案”，而是：
-
-> **把企业方案设计从个人经验劳动，升级成可追踪、可复盘、可协同、可沉淀的组织能力。**
-
-最短表达：
-
-> **企业版卖的是组织方案能力，不是生成次数。**
diff --git a/docs/04-enterprise-scenarios.md b/docs/04-enterprise-scenarios.md
new file mode 100644
index 0000000..e9a5bca
--- /dev/null
+++ b/docs/04-enterprise-scenarios.md
@@ -0,0 +1,161 @@
+# 04｜企业场景：为什么企业需要随行案
+
+> 本文回答一个问题：企业为什么不是缺一个“AI 写方案工具”，而是缺一套能校准真实性偏差的方案设计流程。
+
+---
+
+## 1. 企业场景定位
+
+企业版随行案不应被理解为普通会员升级，也不应被理解为单纯的 AI 文案工具。
+
+它面向的是企业方案生产中的真实问题：
+
+> 方案从需求收集、数据判断、草案生成、多轮修改、跨部门评审到最终交付，经常缺少一条可追踪、可校准、可复盘的工程链。
+
+企业不是不会写方案，而是方案生产过程容易失控：
+
+- 原始需求容易丢失；
+- 数据依据容易断裂；
+- 修改原因难以追踪；
+- 多轮反馈后方向漂移；
+- 成功经验难以复用；
+- 新人难以继承老员工经验；
+- 管理层只能看到最终稿，却看不到形成过程。
+
+随行案企业场景的核心价值是：
+
+> 帮助企业把方案设计从个人经验劳动，升级为可追踪、可复盘、可协同、可沉淀的组织能力。
+
+---
+
+## 2. 企业为什么需要真实性偏差校准
+
+企业方案一旦进入真实业务，就不能只看“写得是否完整”。
+
+真正重要的是：
+
+- 是否贴合客户真实需求；
+- 是否引用了可信数据；
+- 是否符合预算和资源条件；
+- 是否考虑执行周期；
+- 是否能被销售、运营、产品、技术、管理层共同理解；
+- 是否能在多轮修改后仍然回到真实问题。
+
+AI 直接生成方案的风险是：
+
+> 看起来专业，但可能没有真正进入业务现场。
+
+人工反复修改方案的风险是：
+
+> 看起来更完整，但可能在宏大化叙事中偏离原始需求。
+
+随行案的企业价值，不是让 AI 多写几份方案，而是帮助企业在方案生产过程中持续校准这种偏差。
+
+---
+
+## 3. 适合试点的企业场景
+
+随行案更适合从这些场景切入：
+
+| 场景 | 典型问题 | 随行案试点价值 |
+|---|---|---|
+| 销售方案团队 | 客户需求变化快，方案版本混乱 | 降低需求丢失和版本漂移 |
+| 企业服务团队 | 不同客户需要定制方案 | 沉淀可复用方案经验 |
+| 咨询 / 策划团队 | 方案高度依赖个人经验 | 降低新人接手难度 |
+| 运营 / 产品团队 | 数据、需求、方案之间容易断裂 | 强化方案依据与复盘能力 |
+| 解决方案型公司 | 多部门共同参与方案交付 | 降低跨部门沟通成本 |
+| AI 产品试点团队 | 想验证 AI 工作流真实落地 | 提供可展示的业务样板场景 |
+
+这些场景的共同特点是：
+
+> 方案不是一次性文本，而是一条不断吸收需求、数据、反馈和判断的业务链路。
+
+---
+
+## 4. 企业采购理由
+
+企业购买随行案，不是因为员工不会写方案，而是因为方案过程存在组织级成本。
+
+| 企业成本 | 表现 | 随行案价值 |
+|---|---|---|
+| 沟通成本 | 需求在销售、运营、产品、技术之间反复传递 | 让需求和方案过程更可追踪 |
+| 修改成本 | 方案反复改，但不知道为什么改 | 保留修改原因与过程依据 |
+| 复盘成本 | 成功或失败后难以归因 | 让项目经验能够沉淀 |
+| 培训成本 | 新人很难继承老员工经验 | 把方案经验转化为组织资产 |
+| 管理成本 | 管理层只能看最终稿 | 让过程更透明、更可管理 |
+| 失真成本 | 方案越改越大，偏离真实问题 | 持续校准真实性偏差 |
+
+因此，企业版的核心采购理由可以概括为：
+
+> 降低方案过程失控，沉淀组织方案能力。
+
+---
+
+## 5. 企业试点不公开交付细节
+
+本展示仓只说明企业试点价值，不公开具体交付细节。
+
+不公开内容包括：
+
+- 企业专属字段设计；
+- 企业模板体系；
+- 内部权限规则；
+- 审批流细节；
+- 客户数据结构；
+- 具体版本回流机制；
+- 企业私有化部署方式；
+- 行业定制交付方法；
+- 价格、合同和服务边界。
+
+原因是：
+
+> 企业版的深层价值来自定制化调研、流程适配和长期运维，不适合在展示仓中直接公开。
+
+---
+
+## 6. 企业试点建议
+
+企业试点可以从轻量场景开始，而不是一开始改造整个组织。
+
+建议优先选择：
+
+- 一个固定方案类型；
+- 一个小团队；
+- 一个真实客户场景；
+- 一个可对比的旧方案流程；
+- 一个可复盘的项目周期。
+
+试点重点不应只看“AI 生成得快不快”，而应看：
+
+- 需求是否记录得更完整；
+- 方案依据是否更清晰；
+- 修改原因是否更可追踪；
+- 反馈是否能回流；
+- 下一次方案是否更容易复用；
+- 团队是否减少了重复沟通和低价值改稿。
+
+---
+
+## 7. 企业合作表达
+
+面向企业客户，可以这样表达：
+
+> 随行案企业版不是让 AI 替员工写完方案，而是帮助企业把方案设计过程工程化：让真实需求、真实数据、方案草案、人工判断、版本修改和项目复盘进入同一条可追踪链路，从而降低多轮修改造成的真实性偏差。
+
+更短表达：
+
+> 企业版卖的不是生成次数，而是组织方案能力。
+
+---
+
+## 8. 总结
+
+企业场景下，随行案的价值不是“写得更快”这么简单。
+
+它真正解决的是：
+
+> 企业方案生产中的需求漂移、数据断裂、版本混乱、经验流失和真实性偏差。
+
+最终目标是：
+
+> 让方案设计成为企业可沉淀、可复盘、可复制、可持续优化的组织能力。
diff --git a/docs/05-cooperation-and-roadmap.md b/docs/05-cooperation-and-roadmap.md
index 75a45d8..a2f4f24 100644
--- a/docs/05-cooperation-and-roadmap.md
+++ b/docs/05-cooperation-and-roadmap.md
@@ -1,209 +1,202 @@
-# 05｜合作路线：赛事背书、平台合作与半开源边界
+# 05｜合作路线：赛事、平台与企业试点
 
-> 本文回答一个问题：随行案如何用展示仓建立信任，并逐步走向平台合作、用户验证和企业交付。
+> 本文回答一个问题：随行案如何用展示仓建立信任，并走向赛事背书、平台合作和企业试点。
 
 ---
 
-## 1. 展示仓的定位
+## 1. 合作路线的新定位
 
-展示仓不承载随行案的全部核心运行能力。
+随行案的对外合作，不再围绕“公开一套可复刻工作流”展开，而应围绕一个更高层的问题展开：
 
-它主要承载：
+> AI 应用进入真实业务后，如何系统性校准真实性偏差。
 
-- 产品叙事；
-- 架构说明；
-- 商业价值；
-- 企业版逻辑；
-- 合作路线；
-- 版权边界；
-- 参赛与平台沟通材料。
+因此，展示仓承担的合作功能是：
+
+- 让赛事评审理解项目问题意识；
+- 让平台方理解真实业务场景入口；
+- 让企业方理解试点价值；
+- 让合作方理解商业边界；
+- 让外部看到随行案不是普通 AI 写作工具，而是 AI 应用落地样板。
 
 展示仓回答的是：
 
-> **随行案为什么值得被理解、评审、合作和试点。**
+> 随行案为什么值得被理解、评审、合作和试点。
 
-母仓回答的是：
+网页端回答的是：
 
-> **随行案如何运行。**
+> 随行案如何被体验、验证和交付。
 
-运行层回答的是：
+私有核心资产回答的是：
 
-> **随行案如何被用户访问和企业交付。**
+> 随行案如何长期形成产品壁垒和商业交付能力。
 
 ---
 
 ## 2. 为什么需要赛事和平台背书
 
-随行案当前最需要补的是外部验证。
+随行案当前需要的不是单纯曝光，而是外部验证。
 
-AI 产品大赛和平台型赛事可以提供：
+AI 产品大赛、创新创业赛事和平台型活动可以提供：
 
 - 第三方评审；
 - 正式提交记录；
 - 项目文档沉淀；
 - 产品原型展示；
-- 技术方案训练；
 - 平台资源接触；
 - 潜在企业客户入口；
 - 对 HR、客户、合作方更容易理解的信用材料。
 
 参赛目标不是只拿奖，而是形成：
 
-> **公开项目履历 + 外部背书 + 产品可信度。**
+> 公开项目履历 + 外部背书 + 产品可信度。
 
 ---
 
 ## 3. 平台合作价值
 
-随行案适合阿里云等平台型 AI 生态，因为它不是单点功能，而是一套 AI 工作流应用模型。
+随行案适合与云平台、大模型平台、AI 应用生态平台沟通合作。
 
-对平台来说，随行案可以展示：
+原因不是它能生成几页方案，而是它可以作为一个真实业务场景入口，展示：
 
-- 大模型如何进入真实业务流程；
-- 云服务器、数据库、API、安全能力如何组合成 AI 应用；
-- 个人版、VIP版、企业版如何形成商业梯度；
-- 企业客户如何通过 AI 工作流做流程升级；
-- 平台如何支持一个 AI 应用从原型走向部署和商业化。
+- AI 应用如何进入复杂脑力劳动；
+- 大模型如何从聊天窗口进入业务流程；
+- 云平台如何承载 AI 应用运行、存储、权限、日志与维护；
+- 企业如何通过 AI 工作流改善方案生产过程；
+- 真实需求、真实数据、人工判断与反馈回流如何共同校准 AI 输出。
 
-面向平台的表达应聚焦：
+对平台来说，随行案的意义可以概括为：
 
-> **这是一个可运行、可展示、可试点、可迁移的 AI 工作流产品模型。**
+> 用方案设计这个高频脑力劳动场景，验证 AI 应用如何把真实业务需求转化为持续的模型与云资源调用。
 
 ---
 
-## 4. 合作边界
+## 4. 企业合作价值
 
-随行案可以积极借助平台资源，但需要保留核心资产和商业边界。
+企业合作不应从“大规模部署”开始，而应从具体方案场景试点开始。
 
-### 4.1 可以展示
+适合优先试点的场景包括：
 
-- 展示仓；
-- 产品叙事；
-- 方案设计工程化模型；
-- 70 / 20 / 10 方法论；
-- 双重失真校准；
-- 产品原型；
-- 场景价值；
-- 平台技术结合点；
-- 商业化路径。
-
-### 4.2 谨慎开放
-
-- 母仓核心工作流；
-- 深层模板结构；
-- 需求数据绑定规则；
-- 回流复盘细节；
-- 企业子仓设计；
-- 定制化交付方法。
-
-### 4.3 不应开放
-
-- API 密钥；
-- 服务器配置敏感信息；
-- 用户数据；
-- 企业客户数据；
-- 企业权限规则；
-- 内控细节；
-- 商业合同与定价底线。
+- 销售方案；
+- 客户提案；
+- 项目策划；
+- 产品方案；
+- 运营方案；
+- 咨询方案；
+- 企业服务解决方案。
 
-核心原则：
+企业试点重点不是看 AI 生成速度，而是验证：
+
+- 需求记录是否更完整；
+- 数据依据是否更清晰；
+- 修改过程是否更可追踪；
+- 多轮反馈后是否更少偏离原始问题；
+- 成功经验是否更容易复用；
+- 团队沟通成本是否降低。
+
+企业合作的核心表达是：
 
-> **借平台的势，不交出产品的根。**
+> 随行案帮助企业把方案设计从个人经验劳动，升级为可追踪、可复盘、可协同、可沉淀的组织能力。
 
 ---
 
-## 5. 半开源策略
+## 5. 合作边界
 
-随行案适合采用半开源技术路线。
+随行案欢迎合作，但需要明确边界。
 
-| 层级 | 开放策略 | 目的 |
-|---|---|---|
-| **展示仓** | 开放 | 建立外部理解、信任、赛事背书和合作入口 |
-| **基础文档 / 示例模板** | 可开放 | 降低理解门槛，形成传播素材 |
-| **母仓核心能力** | 阶段性受控，成熟后可部分开放 | 保留核心架构，避免过早暴露商业深度 |
-| **运行层代码 / 配置** | 不开放或授权交付 | 保护部署、安全、运维和商业交付能力 |
-| **用户资产 / 企业资产** | 私有 | 保护客户数据和长期续费价值 |
-| **企业级权限 / 内控 / 定制规则** | 商业交付 | 形成企业版高客单价能力 |
+### 5.1 可以展示
 
-最短表达：
+- 产品定位；
+- 问题定义；
+- 真实性偏差方法论；
+- 方案设计工程化逻辑；
+- 70 / 20 / 10 方法论；
+- 产品原型或网页端体验；
+- 典型场景价值；
+- 合作与试点方向。
+
+### 5.2 谨慎开放
+
+- 深层模板设计；
+- 行业定制规则；
+- 试点流程细节；
+- 企业版配置方法；
+- 商业交付方案；
+- 长期服务细节。
+
+### 5.3 不在展示仓公开
 
-> **展示开源，核心受控，数据私有，企业定制。**
+- 私有核心工作流；
+- 可直接复刻的实现路径；
+- 客户数据和用户数据；
+- 企业权限与内控细节；
+- 未公开合作方案。
+
+核心原则：
+
+> 借平台的势，不交出产品的根；展示合作价值，不公开商业底牌。
 
 ---
 
 ## 6. 阶段路线图
 
-### 阶段一：展示仓产品化
+### 阶段一：展示仓重定位
 
-目标：让评审、合作方、企业客户快速理解随行案。
+目标：让外部快速理解随行案不是开源工作流仓，而是 AI 应用真实性偏差校准样板。
 
-产出：
+重点产出：
 
 - README 首页；
 - 产品叙事文档；
-- 架构逻辑文档；
+- 定位与边界说明；
 - 商业价值文档；
-- 企业版说明；
+- 企业场景说明；
 - 合作路线文档。
 
-### 阶段二：赛事材料与原型验证
+### 阶段二：网页端试运行
 
-目标：把随行案从个人架构能力转成可提交、可评审、可展示的项目。
+目标：用网页端证明随行案不是纸面叙事，而是可体验、可验证的产品原型。
 
-产出：
+重点验证：
 
-- 技术方案文档；
-- 路演 PPT；
-- 产品原型；
-- 演示视频；
-- GitHub 展示链接；
-- 云平台运行入口。
+- 用户是否能理解产品定位；
+- 草案生成是否降低空白文档压力；
+- 用户是否愿意补充真实需求与数据；
+- 用户是否接受“草案 + 人工校准”的产品逻辑。
 
-### 阶段三：个人版 / VIP版试运行
+### 阶段三：赛事与平台沟通
 
-目标：验证真实用户是否愿意使用和续费。
+目标：形成外部背书与平台合作入口。
 
-重点验证：
+重点动作：
 
-- 草案生成速度；
-- 方案完整度；
-- 模板保存意愿；
-- 私人仓库价值；
-- API 套餐接受度；
-- 回流复盘是否能提高复用率。
+- 整理技术方案与路演材料；
+- 提交 AI 产品大赛或创新创业赛事；
+- 用展示仓和网页端作为项目证据；
+- 与云平台、大模型平台或 AI 生态平台沟通合作可能。
 
-### 阶段四：企业版试点
+### 阶段四：个人版 / VIP版验证
 
-目标：验证企业是否愿意为流程重构和组织资产沉淀付费。
+目标：验证普通用户与专业个体是否愿意长期使用。
 
 重点验证：
 
-- 需求数据绑定是否有效；
-- 版本留痕是否降低沟通成本；
-- 部门协同是否更清晰；
-- 企业模板库是否可持续更新；
-- 年度运维是否有付费理由。
+- 草案生成效率；
+- 个人模板沉淀价值；
+- 历史方案资产价值；
+- 反馈回流是否提升复用率；
+- 订阅或增值服务接受度。
 
-### 阶段五：部分开源 / 生态扩散
+### 阶段五：企业试点
 
-目标：在产品结构稳定后，开放适合传播和建立信任的部分，同时保留企业级商业能力。
+目标：验证企业是否愿意为方案流程重构和组织能力沉淀付费。
 
-可开放：
-
-- 展示层；
-- 通用说明；
-- 基础模板；
-- 示例流程；
-- 非企业级演示项目。
-
-继续保留：
+重点验证：
 
-- 企业权限；
-- 内控系统；
-- 客户数据绑定深层规则；
-- 高级回流机制；
-- 行业定制模板；
-- 私有化部署与运维。
+- 是否减少需求漂移；
+- 是否降低版本混乱；
+- 是否提升跨部门沟通效率；
+- 是否帮助企业沉淀成功方案经验；
+- 是否具备年度服务价值。
 
 ---
 
@@ -211,24 +204,28 @@ AI 产品大赛和平台型赛事可以提供：
 
 ### 面向赛事 / 平台
 
-> 随行案是一套基于大模型与云服务的方案设计工程化工作流系统。它用 AI 生成可校准方案草案，用真实需求与数据校准方向，用版本留痕和回流复盘防止方案失真，并通过个人版、VIP版和企业版分别服务效率提升、个人方案资产沉淀和企业方案流程重构。
+> 随行案是一套面向方案设计场景的 AI 工作流产品模型。它不追求让 AI 一次性写完最终方案，而是围绕真实需求、真实数据、人工判断、版本过程和反馈回流，持续校准 AI 输出中的真实性偏差。
+
+### 面向云平台 / 大模型平台
+
+> 随行案可以作为一个真实业务场景入口，展示 AI 应用如何把复杂脑力劳动转化为持续的模型调用、云资源消耗、数据沉淀和企业流程优化。
 
 ### 面向企业客户
 
-> 随行案企业版帮助企业把方案设计从个人经验劳动升级为可追踪、可复盘、可协同、可沉淀的组织能力，降低多轮修改带来的需求漂移和流程磨损。
+> 随行案帮助企业把方案设计从个人经验劳动升级为可追踪、可复盘、可协同、可沉淀的组织能力，降低多轮修改带来的需求漂移和真实性偏差。
 
 ### 面向普通用户
 
-> 随行案帮你快速生成结构完整、逻辑清晰、可继续修改的方案草案，让你不用从空白文档开始。
+> 随行案帮你从空白文档快速得到一版可继续修改的方案草案，并引导你用真实需求和数据不断校准它。
 
 ---
 
 ## 8. 总结
 
-随行案的合作路线是：
+随行案的合作路线不是把核心架构全部公开，而是：
 
-> **先用展示仓建立信任，再用云平台跑通产品，再用赛事拿背书，再用 VIP 和企业版验证商业化。**
+> 用展示仓建立信任，用网页端验证体验，用赛事获取背书，用平台连接生态，用企业试点验证商业价值。
 
 最短表达：
 
-> **GitHub 建信任，云平台做运行；赛事拿背书，VIP 做续费，企业版做高客单价。**
+> 展示仓建信任，网页端做验证；赛事拿背书，平台接生态，企业试点做商业化。