技术平台演进方案（Technical Platform Evolution - TND-E）¶

文档编号：DOC-D00-E / TND-E 版本：V1.1 创建日期：2026-08-07 维护人：TL / SPO / DT 决策角色：SPO / BO / TL 关联文档：MVP-FS实施方案、技术规划、RQD-O 执行级需求、RQD-B 业务级需求、PJM 项目管理、CPT-D、QSV-D、MDS-D、OPS-D

一、方案总述¶

1.1 背景与定位¶

MVP-FS V1.1 解决了"业务已启动、系统未就绪"的极速可上手问题，但其设计视野仅覆盖启动期 4-8 周。本方案在 MVP V1.0 基础上向前延伸，规划6 个月（M1-M6）技术平台演进路径，目标是：

在 AI 能力加持下，3 个月实现满足一线操作需求的全定制开发系统上线，6 个月完成全部干系方操作需求的全定制开发技术平台上线。

本方案与 MVP V1.0 的关系：

flowchart LR
    A["MVP V1.0<br/>启动期 1 月<br/>飞书+AI 40 字段"] -->|"子方案纳入"| B["TND-E V1.0<br/>6 个月演进<br/>本方案"]
    B --> C["阶段 0 启动期<br/>W1-W4<br/>= MVP V1.0"]
    B --> D["阶段 1 一线操作系统<br/>M2-M3<br/>全定制开发"]
    B --> E["阶段 2 全干系方平台<br/>M4-M6<br/>全端覆盖"]

    style B fill:#D4AF78,stroke:#004046,color:#004046;
    style A fill:#F2F0EB,stroke:#004046,color:#004046;
    style C fill:#F2F0EB,stroke:#004046,color:#004046;
    style D fill:#2a9d8f,stroke:#004046,color:#fff;
    style E fill:#457b9d,stroke:#004046,color:#fff;

1.2 三阶段目标¶

阶段	时间	核心目标	干系方覆盖	单量预期	团队规模
阶段 0 启动期	W1-W4 （第 1 月）	用飞书多维表格 + AI 听写助手跑通 CPT 8 阶段，沉淀结构化数据	OPR + WKR （2 类）	日均 5-10 单	2-3 人（TL+OL+DT）
阶段 1 一线操作系统	M2-M3 （第 2-3 月）	全定制开发系统上线：QSV 报价 + CPT 跟踪 + MDS 主数据 + OPR 后台 + WKR App	OPR + WKR （2 类完整）	日均 30-50 单	5-8 人（含开发/运维/运营）
阶段 2 全干系方平台	M4-M6 （第 4-6 月）	全干系方技术平台上线：新增 CST 客户端 + DLV 配送端 + PRT 合作方端 + OPS 运营前端 + PAY 结算	CST + WKR + DLV + OPR + PRT （5 类完整）	日均 80-150 单	8-12 人（含运营/客服/AI）

1.3 双轮迭代模型¶

业务拓展与技术平台相互驱动、双轮迭代，避免"先做完系统再上业务"或"业务跑起来系统跟不上"两种失败模式：

flowchart LR
    subgraph BIZ["业务轮（业务拓展执行）"]
        B1["获客场景落地<br/>OPS 6 场景"] --> B2["单量增长<br/>数据沉淀"] --> B3["场景反馈<br/>新需求输入"]
    end

    subgraph TECH["技术轮（技术平台演进）"]
        T1["架构演进<br/>模块化→服务化"] --> T2["能力释放<br/>新功能上线"] --> T3["效率提升<br/>支撑更大单量"]
    end

    B3 -->|"需求驱动开发"| T1
    T3 -->|"能力释放新场景"| B1

    style BIZ fill:#004046,stroke:#004046,color:#fff;
    style TECH fill:#457b9d,stroke:#004046,color:#fff;

双轮节奏： - 业务轮：每两周一个获客场景落地（OPS S01-S06），单量增长驱动数据沉淀 - 技术轮：每两周一个 Sprint 发布，能力上线释放新业务场景 - 对齐机制：每月一次业务×技术联合复盘，调整下月迭代计划

1.4 核心策略¶

策略	含义	实现方式
AI 加持	AI 全程参与设计/开发/运营/运维，替代部分人力	AI 编码助手（Cursor/Trae）+ AI 听写助手 + AI 客服 + AI 质检
灵活架构	技术平台尽可能灵活适应，避免重写	模块化单体（DDD 领域分层）起步，按需服务化演进
数据驱动	数据沉淀贯穿全程，反哺报价/画像/质检	snake_case 字段名兼容、CSV→DB 零成本迁移、AI 数据分析
双轮迭代	业务与技术相互驱动，避免单轮空转	双周 Sprint + 月度联合复盘
人员为本	执行力是项目成功最大动力和风险	明确岗位职责、能力要求、执行力考核（详见 §三）

1.5 与现有规划的关系¶

文档	关系
MVP-FS实施方案.md V1.1	本方案阶段 0 子方案，原文档保留不动
RQD-O §一阶段规划	本方案更激进（RQD-O 试运营期对应本方案阶段 2 末段）
TND-P D01-D10	本方案为 D01-D10 提供 6 个月实施时间表
PJM §3 RACI	本方案 §三与 PJM 角色体系对齐，新增开发/运维角色

二、阶段总览¶

2.1 6 个月里程碑甘特图¶

gantt
    title 技术平台 6 个月演进甘特图
    dateFormat  YYYY-MM-DD
    axisFormat  %m/%d

    section 阶段0 启动期
    飞书配置+培训       :p0a, 2026-08-08, 4d
    首批订单跑通         :p0b, after p0a, 7d
    Phase0 数据沉淀      :p0c, after p0b, 14d
    Phase0 退出复盘      :p0m, 2026-09-04, 1d

    section 阶段1 一线操作系统
    架构设计+DDD建模     :p1a, 2026-09-05, 10d
    后端核心服务开发     :p1b, after p1a, 25d
    OPR后台+WKR App开发  :p1c, after p1a, 25d
    数据迁移(CSV→DB)     :p1d, after p1b, 5d
    内测+灰度            :p1e, after p1c, 7d
    阶段1上线            :p1m, 2026-11-10, 1d

    section 阶段2 全干系方平台
    服务化重构+扩展      :p2a, 2026-11-11, 14d
    CST客户端开发        :p2b, after p2a, 30d
    DLV+PRT端开发        :p2c, after p2a, 30d
    OPS运营前端+PAY结算  :p2d, after p2a, 30d
    AI深度化集成         :p2e, after p2b, 20d
    全平台联调压测        :p2f, after p2d, 10d
    阶段2上线            :p2m, 2027-01-20, 1d

2.2 里程碑表¶

里程碑	日期	交付物	验收标准
M0 阶段 0 退出	2026-09-04	飞书 WEAVELY-MVP 数据沉淀 50+ 单	累计 50+ 订单、表单 V1.3+、字段缺口收敛
M1 阶段 1 上线	2026-11-10	一线操作系统 v1.0	OPR+WKR 完整功能、日均 30-50 单支撑、数据零丢失迁移
M2 阶段 2 上线	2027-01-20	全干系方平台 v2.0	5 类干系方全端覆盖、日均 80-150 单支撑、AI 深度化上线

2.3 单量与团队演进曲线¶

flowchart TD
    subgraph 单量演进
        P0["阶段0<br/>5-10单/天<br/>2-3人"] --> P1["阶段1<br/>30-50单/天<br/>5-8人"]
        P1 --> P2["阶段2<br/>80-150单/天<br/>8-12人"]
    end

    subgraph 技术演进
        T0["飞书多维表格<br/>40字段"] --> T1["模块化单体<br/>FastAPI+Next.js"]
        T1 --> T2["服务化平台<br/>+CST/DLV/PRT端"]
    end

    P0 -.->|"数据驱动"| T1
    P1 -.->|"需求驱动"| T2

    style P0 fill:#D4AF78,stroke:#004046,color:#004046;
    style P1 fill:#2a9d8f,stroke:#004046,color:#fff;
    style P2 fill:#457b9d,stroke:#004046,color:#fff;

三、干系方与团队治理¶

核心原则：在 AI 加持背景下，人员的执行力依然是项目成功最大的动力和风险。本章明确各干系方与项目角色的岗位职责、能力要求、执行力要求，作为招聘、考核、风险防控的依据。

3.1 业务干系方完整矩阵¶

业务干系方（来自 RQD-O §2.1）共 5 类，每类在不同阶段有不同介入深度：

干系方	简称	角色	阶段 0 介入	阶段 1 介入	阶段 2 介入	总需求条数
客户	CST	服务接收者	不直接（OL 代录）	不直接（OL 代录）	直接（CST 客户端）	6
师傅	WKR	服务执行者	直接（飞书表单）	直接（WKR App）	直接（WKR App 升级）	6
配送人员	DLV	物流执行者	不直接（OL 代录）	不直接（OL 代录）	直接（DLV 端）	3
平台运营	OPR	流程管控者	直接（飞书后台）	直接（OPR 后台）	直接（OPR 升级）	4
合作方	PRT	B 端订单来源	不直接	不直接	直接（PRT 对接 API）	4

干系方需求详情见 RQD-O §2.2，本方案在各阶段章节中给出覆盖矩阵。

3.2 项目角色与岗位职责¶

项目角色（来自 PJM §3 RACI）在本方案 6 个月演进中需扩展，新增开发与运维角色。现任人员（来自 PJM §3.1，按规范直接使用简称称呼）：

角色	简称	现任人员	RACI 定位
项目发起人	SPO	广	A（决策审批）
业务负责人	BO	洪	R（负责执行）
产品负责人	PO	郭	R（产品设计）
技术负责人	TL	司徒	R（技术架构）
运营负责人	OL	成文 + 黄	R（运营执行，双人分工）
市场负责人	ML	洪（兼 BO）	R（市场推广）
财务/法务	FL	（待定）	R（合规财务）

3.2.1 管理与决策层¶

角色	简称	现任人员	核心职责	能力要求	执行力要求
项目发起人	SPO	广	项目方向、资源调配、对外合作、关键决策审批	行业认知、决策力、资源整合、风险觉察	① 每周参与复盘、关键决策 24h 内拍板；② 对里程碑目标即时确认、复盘和调整；③ 对业务风险和其他角色人员执行力保持觉察并及时修补；④ 阶段评审亲自主持
业务负责人	BO	洪	业务模式、报价策略、合作拓展、报价校准	业务洞察、定价能力、谈判力、香港市场认知	报价策略月度复盘、合作条款亲自谈、获客场景落地节奏把控
产品负责人	PO	郭	平台设计、需求管理、产品路线图、用户体验	产品思维、用户洞察、需求管理、设计审美	每周需求评审、产品文档维护、双周 Sprint 优先级拍板
技术负责人	TL	司徒	架构决策、技术选型、代码审查、技术风险把控	全栈能力、架构思维、AI 协作、团队带领	代码审查每周≥3次、架构决策 48h 内出方案、技术风险 24h 内响应

3.2.2 业务执行层¶

角色	简称	现任人员	核心职责	能力要求	执行力要求
运营负责人（客户运营）	OL	成文	客户运营、订单协调、异常处理、客户跟进、信息同步	客户服务、流程执行、数据分析、沟通协调	订单 2h 内响应、每日数据复核、客户反馈 24h 内闭环
运营负责人（落地执行）	OL	黄	风险把控、作业规范 SOP、师傅管理、关键节点把控	香港本地经验、师傅沟通、SOP 制定、现场判断	师傅培训每月≥1 次、SOP 季度更新、现场异常 1h 内介入
市场负责人	ML	洪（兼 BO）	获客渠道、品牌推广、内容矩阵、数据收集	香港市场、内容营销、渠道拓展、数据敏感	获客场景双周落地、单量月度达标、内容矩阵周更
财务/法务	FL	（待定）	商业登记、保险、合同、对账、PDPO 合规	财务、法务、香港法规、合规	合同评审 48h 内、月度对账准时、合规风险 24h 内响应

3.2.3 技术执行层（本方案新增）¶

角色	简称	人数（阶段 1/2）	核心职责	能力要求	执行力要求
后端开发	BE	2/3 人	API 开发、数据库、业务逻辑	Python FastAPI、PostgreSQL、DDD	每日代码提交、单元测试覆盖率≥70%
前端开发	FE	1/2 人	Web/移动端界面、用户体验	React/Next.js、TypeScript、移动适配	每周 UI 评审、移动端兼容性测试
全栈开发	FS	1/1 人	跨端开发、AI 集成、自动化	前后端 + AI API、运维基础	AI 编码助手使用率≥80%、双周交付
运维工程师	OP	0.5/1 人	部署、监控、CI/CD、安全	Docker、Cloudflare、Linux、监控	部署事故 1h 内响应、SLA 99.5%
AI 工程师	AI	0.5/1 人（兼）	AI 集成、Prompt 工程、数据科学	LLM API、Prompt、数据分析	AI 模型月度评估、Prompt 库维护
听写助手	DT	全程	文档、AI 编码协作、数据分析	项目上下文、代码生成、文档撰写	7×24 可用、需求 2h 内响应

3.2.4 各阶段团队配置¶

阶段	管理层	业务层	技术层	总人数
阶段 0（W1-W4）	广 + 洪 + 郭 + 司徒	成文 + 黄 + 洪 + FL（待定）	司徒兼开发 + DT	7-8 人
阶段 1（M2-M3）	广 + 洪 + 郭 + 司徒	成文 + 黄 + 洪 + FL	BE×2 + FE + FS + OP×0.5 + DT	11-12 人
阶段 2（M4-M6）	广 + 洪 + 郭 + 司徒	成文 + 黄 + 洪 + FL + 客服×2	BE×3 + FE×2 + FS + OP + AI×0.5 + DT	16-18 人

说明：阶段 0 业务层与技术层主要由现任核心团队承担（广/洪/郭/司徒/成文/黄），开发由司徒主导、DT 协助，全职开发人员（BE/FE/FS）从阶段 1 启动前 1 月开始招聘（W3 启动）。

3.3 能力要求与培训计划¶

3.3.1 AI 协作能力（全员必备）¶

能力项	要求	培训方式	考核标准
AI 工具使用	熟练使用 Cursor/Trae/听写等 AI 助手	内部培训 2h + 实战	AI 协作时长占工作时长≥50%
Prompt 工程	能编写结构化 Prompt 获取高质量产出	工作坊 4h	每周提交≥3 个有效 Prompt
数据素养	能读懂数据看板、提出数据驱动假设	数据分析培训 8h	月度复盘提出≥1 个数据假设并验证
AI 边界认知	知道 AI 能做什么、不能做什么	案例分享会	关键决策人工确认、不盲信 AI

3.3.2 技术能力（技术层）¶

角色	必备技能	加分技能	培训资源
BE	Python、FastAPI、PostgreSQL、DDD、Git	Redis、消息队列、Docker	FastAPI 官方教程、DDD 实战
FE	React、Next.js、TypeScript、Tailwind	移动端适配、PWA、状态管理	Next.js 文档、Tailwind 实战
FS	上述全部 + 跨端协作	AI API 集成、CI/CD	全栈项目实战
OP	Docker、Cloudflare、Linux、Nginx	K8s、监控告警、安全	Cloudflare 文档、Docker 实战
AI	LLM API、Prompt、RAG、数据分析	模型微调、MLOps	LangChain 文档、Kaggle

3.3.3 业务能力（业务层）¶

能力项	OL	FL	ML	培训方式
香港家具配送安装市场	必备	必备	必备	行业调研报告 + 实地走访
CPT 8 阶段流程	必备	必备	熟悉	流程培训 + 角色扮演
报价模型理解	熟悉	必备	熟悉	报价案例研讨
师傅沟通管理	熟悉	必备	—	师傅培训实战
数据看板解读	必备	熟悉	必备	数据分析培训
异常处理 SOP	必备	必备	熟悉	案例库学习

3.4 执行力要求与风险防控¶

核心认知：AI 能力可以放大个体产出 3-10 倍，但无法替代人的执行力。在 AI 加持下，人员执行力差异会被进一步放大——强者更强，弱者更弱。

3.4.1 执行力考核维度¶

维度	指标	权重	阶段 0 目标	阶段 1 目标	阶段 2 目标
响应时效	关键事件响应时间	25%	4h 内	2h 内	1h 内
交付准时率	任务按时完成率	25%	≥85%	≥90%	≥95%
AI 协作度	AI 工具使用占比	20%	≥30%	≥50%	≥70%
数据合规	数据填写规范率	15%	≥90%	≥95%	≥98%
团队协作	跨角色配合评分	15%	≥4.0/5	≥4.2/5	≥4.5/5

3.4.2 执行力风险与防控¶

风险	概率	影响	防控措施	触发条件与应对
关键人员流失	中	高	知识沉淀、文档化、双备份	单一责任人：TL 7 日内补位；OL 14 日内补位
AI 依赖过度	高	中	关键决策人工确认、AI 输出审查	月度 AI 依赖度审计、关键路径人工兜底
执行力不达预期	高	高	月度考核、绩效挂钩、及时调整	连续 2 月不达标：调岗/培训/换人
沟通不畅	中	高	双周站会、月度复盘、文档化沟通	跨角色 SLA：评审 48h、决策 24h
能力跟不上	中	中	培训计划、师徒制、AI 辅助	月度能力评估、季度培训复盘
招聘不到位	高	高	提前 1 月启动、多渠道、AI 协助筛选	阶段 1 启动前 BE/FE 必须到岗

3.4.3 决策与升级机制¶

flowchart TD
    A["日常决策<br/>TL/OL 范围内"] -->|48h未决| B["管理决策<br/>SPO/BO 范围"]
    B -->|24h未决| C["紧急决策会<br/>SPO+BO+TL"]
    C -->|2h未决| D["SPO 最终决策权"]

    E["技术决策<br/>TL 范围内"] -->|影响架构| F["架构评审会<br/>TL+BE+FS"]
    F -->|影响业务| G["业务×技术联合评审<br/>+SPO+BO"]

    H["业务决策<br/>BO 范围内"] -->|影响报价/合作条款| I["BO 亲自决策"]
    I -->|影响产品方向| J["SPO+BO+PO 联合"]

    style D fill:#D4AF78,stroke:#004046,color:#004046;
    style C fill:#D4AF78,stroke:#004046,color:#004046;

3.5 跨角色协作要求¶

核心认知：AI 加持下，单兵产出会提升，但跨角色协作的质量仍是项目成败的关键。本章明确各角色之间如何相互提供信息、反馈问题、保持高度协作，作为日常工作的行为规范。

3.5.1 协作总则¶

原则	含义	反例（禁止）
信息同源	所有业务/技术决策落入文档（PJM/TND/RQD），口头讨论须 24h 内沉淀	微信群讨论后无文档记录，下次复盘各执一词
闭环反馈	任何角色提出的问题/需求，接收方须在 SLA 内响应并闭环	OL 反馈 bug 后无追踪，TL 默默修复但不通知验证
主动暴露	风险/延期/能力不足须第一时间暴露，不掩盖	BE 发现延期但隐瞒，到里程碑才暴露
AI 透明	AI 参与的工作须标注，AI 产出须经人工审查	DT 生成代码直接合并，无人审查
决策留痕	所有决策记入 WLG 对话记录或会议纪要	SPO 口头拍板无记录，后续追溯困难

3.5.2 角色间信息流矩阵¶

下表定义各角色"向谁提供什么信息、向谁反馈什么信息"：

提供方 → 接收方	提供的信息	频率	形式	SLA
OL → PO	一线痛点/字段缺口/用户体验问题/异常案例	每周	飞书表单+口头	周一复盘前提交
OL → TL	系统bug/数据异常/流程阻塞	实时	GitHub Issue	严重 1h/一般 24h
OL → BO	单量/转化率/客诉/师傅反馈	每周	周报	周五前
OL → ML	客户来源/转化数据/口碑线索	每周	周报	周一复盘
ML → OL	获客场景落地计划/物料/线索分配	每周	周会	周一前
ML → BO	获客成本/渠道效果/竞品动态	每周	周报	周五前
BO → PO	业务模式调整/报价策略变化/新合作需求	按需	评审会	24h 内安排
BO → TL	报价参数调整/合作方对接需求	按需	评审会+文档	48h 内出方案
PO → TL	需求文档/优先级/原型/验收标准	双周	Sprint 规划	Sprint 启动前 2 天
PO → OL	新功能预告/操作手册/培训材料	双周	文档+培训	上线前 3 天
PO → BO	产品路线图/版本计划/竞品分析	每月	月报	月底前
TL → PO	技术可行性/工作量评估/技术约束	每需求	评审回复	48h 内
TL → OL	系统上线计划/维护窗口/故障通知	按需	飞书公告	故障 30min 内
TL → BO	技术风险/架构变更/资源需求	每月	月报	月底前
TL → SPO	里程碑进度/技术风险/团队状态	每周	周报	周五前
SPO → 全员	战略调整/资源调配/里程碑确认	按需	全员会	决策 24h 内传达
DT → 全员	文档更新/AI 产出/数据分析	实时	文档+飞书	需求 2h 内
FL → BO/TL	合规要求/合同条款/对账数据	按需	文档	评审 48h 内

3.5.3 关键协作场景¶

场景 1：新需求从提出到上线

flowchart LR
    A["OL/ML/BO<br/>提出痛点"] -->|周报/口头| B["PO<br/>需求池整理"]
    B -->|双周 Sprint 规划| C["PO+TL<br/>优先级+可行性评审"]
    C -->|Sprint 立项| D["TL+BE/FE/FS<br/>开发"]
    D -->|内部联调| E["OL+PO<br/>UAT 验收"]
    E -->|灰度发布| F["OL+部分用户<br/>灰度运行"]
    F -->|全量发布| G["全员<br/>正式上线"]
    G -->|效果跟踪| H["OL+PO+TL<br/>数据复盘"]
    H -.->|新痛点| A

    style B fill:#D4AF78,stroke:#004046,color:#004046;
    style D fill:#457b9d,stroke:#004046,color:#fff;
    style H fill:#2a9d8f,stroke:#004046,color:#fff;

协作要点： - OL/ML/BO 是需求的源头，每周通过周报或口头提出痛点，禁止跳过 PO 直接找 TL - PO 是需求唯一的过滤与优先级判断者，避免开发资源被零散需求消耗 - TL 对可行性负责，48h 内回复，禁止"先做着看" - UAT 验收必须有 OL 参与（一线代表），避免开发自嗨 - 灰度发布后 OL 负责收集一线反馈，PO 负责产品决策，TL 负责技术修复

场景 2：线上故障处理

步骤	角色	动作	SLA
1	OL/ML	发现异常，飞书群@TL+OP	立即
2	TL/OP	初步判断严重级别（P0/P1/P2）	15min
3	TL	P0 须通知 SPO+BO，组织应急	30min
4	OP	修复或回滚	P0 1h / P1 4h / P2 24h
5	TL	故障报告（根因+影响+改进）	24h
6	PO	改进措施纳入需求池	48h
7	SPO	重大故障亲自复盘	1 周内

场景 3：报价参数调整

步骤	角色	动作
1	OL	月报提出报价偏差（实际工时 vs 基础工时）
2	BO	评审报价调整建议，决策是否调整
3	BO → TL	调整需求传递给 TL（更新 QMD 参数）
4	TL	系统参数调整，TL 审查后上线
5	OL	新参数生效后跟踪 1 周，反馈效果
6	BO	月度复盘确认调整效果，记入 WLG

场景 4：师傅异常事件处理

步骤	角色	动作	SLA
1	师傅/OL	现场异常（超能力/物业阻拦/客诉）上报	立即
2	成文	客户沟通+情绪安抚	30min
3	黄	师傅调度+现场判断	1h
4	OL → BO	重大异常（客诉/退款）上报	2h
5	OL → TL	系统记录异常+派单调整	2h
6	黄	SOP 修订（如属流程问题）	1 周
7	SPO	重大客诉亲自复盘	1 周内

3.5.4 协作工具与规范¶

场景	工具	规范
日常沟通	飞书群	重要决策须 @相关人 + 24h 内沉淀文档
需求管理	GitHub Issues + Projects	每需求一个 Issue，标 assignee/label/milestone
代码协作	GitHub PR	必须≥1 人审查，TL 把关架构相关 PR
文档协作	飞书云文档 + Git docs/	业务文档进 docs/，临时讨论进飞书
故障应急	飞书群 + 电话	P0 故障电话通知 TL+OP，飞书群同步进展
知识沉淀	docs/工作日志/对话记录/	每次重要决策记入 DLG
AI 协作	听写助手 + Cursor/Trae	AI 产出标注，关键路径人工审查

3.5.5 协作考核¶

每月对协作质量进行评估，纳入 §3.4.1 执行力考核的"团队协作"维度（权重 15%）：

协作指标	评估方式	目标
信息闭环率	提出问题→文档记录→解决→反馈，全链路占比	≥90%
SLA 达标率	各类信息流的 SLA 达标情况	≥85%
跨角色满意度	季度匿名互评	≥4.2/5
文档沉淀率	重要决策记入文档的比例	≥95%
主动暴露率	风险/延期主动上报的比例（vs 被动发现）	≥80%

四、阶段 0：启动期（W1-W4，第 1 月）¶

4.1 范围定义¶

阶段 0 即 MVP-FS V1.1 的完整内容，本方案将其作为子方案纳入，不重复展开。

子方案引用： - 数据模型：CPT-Lite 40 字段 + QSV-Lite 15 字段 + MDS-Lite 四库台账（共 33 字段） - 操作手册：8 阶段极简操作手册 - AI 协同：听写助手对话式协作 - 工具栈：飞书多维表格 + WhatsApp + 听写助手 - 第 1 周实施计划：见 MVP V1.0 §七

4.2 业务目标¶

指标	W1	W2	W3	W4	退出标准
累计订单数	5	15	30	50+	≥50
表单版本	V1.0	V1.1	V1.2	V1.3+	V1.3+
字段缺口	—	10+	5+	收敛	收敛趋势
OL 响应时效	4h	4h	2h	2h	≤2h
数据完整率	80%	85%	90%	95%	≥95%

4.3 业务拓展执行（阶段 0）¶

阶段 0 业务重点是跑通流程、沉淀数据，不追求单量爆发。获客场景选择 1-2 个低门槛场景先行：

场景	OPS 编号	阶段 0 目标	触发条件
SCENE02 随箱卡	OPS-S02	触达 100 户、转化 5 单	与品牌方合作落地
SCENE06 菜鸟驿站	OPS-S06	触达 50 户、转化 3 单	与 2 个驿站合作
推荐口碑	—	转化 2 单	NPS 9-10 客户触发邀请

4.4 退出条件与阶段 1 衔接¶

退出条件	验证方式	责任人
累计 50+ 订单数据	飞书表格统计	OL
表单迭代至 V1.3+	版本记录	TL
字段缺口收敛	AI 缺口分析报告	DT
团队形成填写习惯	数据完整率≥95%	OL
阶段 1 团队到岗	BE×2 + FE + FS 到岗	SPO
阶段 1 架构设计完成	DDD 领域模型评审通过	TL

衔接机制：阶段 0 退出前 1 周（W4 第 5-7 天），TL 主导阶段 1 架构设计，DT 协助生成 DDD 领域模型初稿，BE/FS 到岗后立即进入开发。

五、阶段 1：一线操作系统（M2-M3，第 2-3 月）¶

5.1 范围定义¶

阶段 1 目标：3 个月内全定制开发系统上线，满足一线操作需求。

范围界定： - ✅ 包含：OPR 运营后台 + WKR 师傅 App + QSV/CPT/MDS 核心服务 + 数据迁移 + AI 集成 - ❌ 不含：CST 客户端、DLV 配送端、PRT 合作方端（留至阶段 2） - ❌ 不含：OPS 运营前端完整版、PAY 结算完整版（阶段 1 仅基础版）

5.2 干系方×功能组覆盖矩阵（阶段 1）¶

功能组干系方	OPR 运营	WKR 师傅	阶段 1 完成度
QTE 报价	✅ 后台报价配置	—	70%（QTE-01~03/07 P0）
ORD 订单	✅ 后台订单管理	✅ App 接单	75%（ORD-01/03 P0）
DSP 派单	✅ 后台派单	✅ App 接单/拒单	75%（DSP-01/02 P0）
TRK 跟踪	✅ 后台全流程看板	✅ App 阶段填报	75%（TRK-01/02 P0）
ACC 验收	✅ 后台验收审核	✅ App 验收记录	67%（ACC-01 P0）
FUP 回访	✅ 后台回访管理	—	75%（FUP-01/02 P0）
PAY 结算	✅ 后台基础对账	✅ App 收入查看	25%（PAY-01 P0）

干系方覆盖：2/5 类（OPR + WKR），完整覆盖 功能组覆盖：7/7 组，但 PAY 仅基础版

5.3 技术架构（模块化单体 + DDD）¶

5.3.1 架构总览¶

flowchart TD
    subgraph FE["前端层"]
        OPR["OPR 运营后台<br/>Next.js Web"]
        WKR["WKR 师傅 App<br/>Next.js PWA"]
    end

    subgraph BE["后端层（模块化单体 FastAPI）"]
        API["API Gateway<br/>统一入口+鉴权"]

        subgraph DOMAINS["DDD 领域模块"]
            QSV_M["QSV 报价领域<br/>报价引擎+参数配置"]
            CPT_M["CPT 跟踪领域<br/>8 阶段生命周期"]
            MDS_M["MDS 主数据领域<br/>四库管理"]
            DSP_M["DSP 派单领域<br/>师傅匹配"]
            PAY_M["PAY 结算领域<br/>基础对账"]
        end

        API --> QSV_M
        API --> CPT_M
        API --> MDS_M
        API --> DSP_M
        API --> PAY_M
    end

    subgraph INFRA["基础设施层"]
        DB[("PostgreSQL<br/>主库")]
        REDIS[("Redis<br/>缓存+队列")]
        OSS["对象存储<br/>照片/视频"]
        AI["AI 服务<br/>听写+LLM"]
    end

    FE --> API
    QSV_M --> DB
    CPT_M --> DB
    MDS_M --> DB
    DSP_M --> DB
    PAY_M --> DB
    CPT_M --> OSS
    QSV_M --> REDIS
    CPT_M --> AI

    style BE fill:#2a9d8f,stroke:#004046,color:#fff;
    style FE fill:#457b9d,stroke:#004046,color:#fff;

5.3.2 DDD 领域划分¶

领域	限界上下文	核心实体	聚合根	阶段 1 范围
报价	QSV 上下文	Quote / QuoteParam / PriceFactor	Quote	报价计算 + 参数配置 + 明细展示
跟踪	CPT 上下文	Order / Stage / Collection / Photo	Order	8 阶段流转 + 信息采集 + 异常分支
主数据	MDS 上下文	Worker / Customer / Category / Building	各库独立	四库 CRUD + 关联管理
派单	DSP 上下文	Dispatch / Assignment / Notification	Dispatch	师傅匹配 + 派单 + 接单
结算	PAY 上下文	Settlement / Invoice / Account	Settlement	基础对账 + 师傅收入

模块化原则： - 单一代码库，模块间通过接口调用，禁止跨模块直接访问数据库 - 每个模块独立目录、独立测试、独立文档 - 模块间依赖通过依赖注入容器管理 - 阶段 2 可按需拆分为独立服务

5.3.3 技术栈（阶段 1）¶

层级	技术	版本	选型理由
前端框架	Next.js	14+	React 全栈、SSR、PWA 支持、AI 工具链成熟
前端语言	TypeScript	5+	类型安全、AI 编码助手加持好
UI 组件	Tailwind + shadcn/ui	最新	极速开发、移动适配、设计系统统一
后端框架	FastAPI	0.110+	Python 异步、自动 OpenAPI、AI 集成原生
后端语言	Python	3.11+	AI 工具链最成熟、生态丰富
ORM	SQLAlchemy 2.0 + Alembic	最新	类型安全、迁移管理
数据库	PostgreSQL	16	关系型、JSON 支持、扩展性好
缓存队列	Redis	7+	缓存 + 异步任务 + 会话
对象存储	Cloudflare R2	—	与现有 Cloudflare 对齐、零出口费
部署	Cloudflare Pages + Workers + 自建 API	—	前端 Pages、后端 Workers/容器
CI/CD	GitHub Actions	—	自动测试 + 部署
监控	Sentry + Logfire	—	错误追踪 + 性能监控
AI 集成	OpenAI/Anthropic API + 听写助手	—	LLM + 项目上下文 AI

5.4 数据迁移（飞书 CSV → PostgreSQL）¶

5.4.1 迁移策略¶

flowchart LR
    A["飞书多维表格<br/>CPT-Lite 40字段<br/>QSV-Lite 15字段<br/>MDS-Lite 33字段"] --> B["CSV 导出<br/>每周自动备份"]
    B --> C["AI 数据校验<br/>空值/格式/枚举"]
    C --> D["ETL 脚本<br/>Python"]
    D --> E["PostgreSQL<br/>snake_case 列名<br/>零改造成本"]
    E --> F["双轨运行 1 周<br/>飞书+系统并行"]
    F --> G["系统切换<br/>飞书仅备份"]

    style A fill:#D4AF78,stroke:#004046,color:#004046;
    style E fill:#2a9d8f,stroke:#004046,color:#fff;

5.4.2 字段映射保证¶

阶段 0 已采用 snake_case 英文字段名，与数据库列名完全一致，迁移时直接映射：

MVP 数据表	数据库表	字段数	迁移方式
CPT-Lite	`orders`	40	CSV → COPY 命令
QSV-Lite	`quotes`	15	CSV → COPY 命令
WPL-Lite	`workers`	8	CSV → COPY 命令
CPL-Lite	`customers`	10	CSV → COPY 命令
SCL-Lite	`categories`	7	CSV → COPY 命令
BPL-Lite	`buildings`	8	CSV → COPY 命令

5.4.3 双轨运行与切换¶

阶段	时长	操作	风险防控
数据迁移	1 天	CSV 导出 → AI 校验 → DB 导入	校验失败回滚
双轨运行	1 周	飞书录入 + 系统录入并行	每日数据对比
系统切换	1 天	飞书停录、仅系统	飞书保留 1 月只读备份
切换后	持续	飞书仅作备份	系统每日 DB 备份

5.5 AI 融合点（阶段 1）¶

AI 融合点	应用场景	技术实现	价值
AI 编码助手	BE/FE 开发全程	Cursor/Trae + 听写	开发效率提升 3-5 倍
AI 听写录入	OPR 录入辅助	听写 API + 飞书导出	录入效率提升 50%
AI 报价建议	QSV 复杂度系数	LLM + 历史数据	报价准确率提升 20%
AI 师傅推荐	DSP 派单	LLM + 师傅画像	派单匹配度提升 30%
AI 异常识别	CPT 照片质检	LLM 视觉 + 规则	异常检出率提升 40%
AI 周报月报	OPR 数据分析	听写 + 数据 API	报告生成 0 人力
AI 客服辅助	OPR 客户沟通	LLM + 话术库	响应时效提升 60%

5.6 业务拓展配合（阶段 1）¶

阶段 1 业务目标：单量从日均 5-10 单提升至 30-50 单，业务×技术双轮驱动。

月份	业务目标	获客场景	技术配合
M2	日均 15-20 单	SCENE02 + SCENE06 + 推荐口碑 + SCENE01 线上	系统开发中，飞书继续支撑
M3 上旬	日均 25-30 单	SCENE03 电商 + SCENE04 物流	系统内测，OL 试用
M3 中下旬	日均 30-50 单	全场景铺开 + SCENE05 品牌	系统上线，AI 加持

业务×技术对齐点： - M2 第 1 周：业务方提交 M3 详细需求（场景化报价、师傅评级），技术方纳入 Sprint - M3 第 1 周：业务方试用系统，反馈用户体验问题，技术方紧急修复 - M3 第 4 周：系统正式上线 + 业务全量切换

5.7 退出条件（阶段 1）¶

退出条件	验证方式	责任人
OPR 后台 + WKR App 上线	灰度发布 1 周稳定运行	TL
日均 30-50 单支撑	实际跑通 7 天	OL
数据零丢失迁移	飞书 vs 系统数据对比	TL + OL
7 功能组 P0 需求全覆盖	需求覆盖矩阵验收	PO
AI 融合 4+ 点上线	AI 融合点列表核对	TL + AI
SLA 99.5%	监控数据	OP
用户满意度 ≥4.0/5	OPR+WKR 问卷	PO

六、阶段 2：全干系方平台（M4-M6，第 4-6 月）¶

6.1 范围定义¶

阶段 2 目标：6 个月内全干系方技术平台上线，满足全部干系方操作需求。

范围界定： - ✅ 新增：CST 客户端 + DLV 配送端 + PRT 合作方端 - ✅ 升级：OPS 运营前端完整版 + PAY 结算完整版 - ✅ 深度化：AI 智能派单/质检/客服/流失预测 - ✅ 架构演进：模块化单体 → 服务化（按需拆分） - ✅ 全港扩展：港岛/九龙 → 新界/离岛

6.2 干系方×功能组全覆盖矩阵（阶段 2）¶

功能组干系方	CST 客户	WKR 师傅	DLV 配送	OPR 运营	PRT 合作方	阶段 2 完成度
QTE 报价	✅ 透明报价查看	—	—	✅ 报价配置	✅ 批量报价	100%
ORD 订单	✅ 自助下单	✅ 接单	—	✅ 订单管理	✅ 批量导入	100%
DSP 派单	—	✅ 接单	—	✅ 智能派单	—	100%
TRK 跟踪	✅ 进度查看	✅ 阶段填报	✅ 配送打卡	✅ 全流程看板	✅ 状态同步	100%
ACC 验收	✅ 自助验收	✅ 验收记录	—	✅ 验收审核	—	100%
FUP 回访	✅ 评价回访	—	—	✅ 回访管理	—	100%
PAY 结算	✅ 在线支付	✅ 收入查看	✅ 配送费	✅ 完整对账	✅ 月度对账	100%

干系方覆盖：5/5 类（CST + WKR + DLV + OPR + PRT），完整覆盖 功能组覆盖：7/7 组，全部 100%

6.3 技术架构演进（模块化单体 → 服务化）¶

6.3.1 阶段 2 架构总览¶

flowchart TD
    subgraph FE["前端层（多端）"]
        CST["CST 客户端<br/>Web+小程序"]
        WKR["WKR App<br/>PWA 升级"]
        DLV["DLV 配送端<br/>小程序"]
        OPR["OPR 后台<br/>完整版"]
        PRT["PRT 合作方端<br/>API+Webhook"]
    end

    subgraph GW["API 网关层"]
        BFF["BFF 层<br/>按端定制"]
        AUTH["鉴权+限流"]
    end

    subgraph SVC["服务层（按需服务化）"]
        QSV_S["QSV 报价服务<br/>独立部署"]
        CPT_S["CPT 跟踪服务<br/>独立部署"]
        MDS_S["MDS 主数据服务<br/>独立部署"]
        OPS_S["OPS 运营服务<br/>独立部署"]
        PAY_S["PAY 结算服务<br/>独立部署"]
        AI_S["AI 服务<br/>独立部署"]
    end

    subgraph INFRA["基础设施层"]
        DB[("PostgreSQL<br/>主库+读副本")]
        REDIS[("Redis 集群")]
        OSS["R2 对象存储"]
        MQ["消息队列<br/>异步解耦"]
        ML["ML 模型<br/>派单/质检/预测"]
    end

    FE --> BFF
    BFF --> AUTH
    AUTH --> QSV_S
    AUTH --> CPT_S
    AUTH --> MDS_S
    AUTH --> OPS_S
    AUTH --> PAY_S
    AUTH --> AI_S

    QSV_S --> DB
    CPT_S --> DB
    MDS_S --> DB
    OPS_S --> DB
    PAY_S --> DB
    AI_S --> ML

    CPT_S --> MQ
    QSV_S --> REDIS
    CPT_S --> OSS

    style SVC fill:#457b9d,stroke:#004046,color:#fff;
    style FE fill:#2a9d8f,stroke:#004046,color:#fff;

6.3.2 服务化拆分原则¶

不强制拆分，按需演进： - 阶段 1 模块化单体运行稳定 - 阶段 2 根据以下信号决定是否拆分： - 单一模块开发冲突频繁 → 拆分独立部署 - 单一模块负载突出 → 拆分独立扩容 - 团队规模 >10 人 → 按康威定律拆分

优先拆分顺序： 1. AI 服务（独立部署，便于模型迭代） 2. PAY 结算服务（金融级别，独立安全域） 3. MDS 主数据服务（共享度高，独立扩容） 4. QSV/CPT/OPS 视情况拆分

6.4 新增端与服务（阶段 2）¶

6.4.1 CST 客户端¶

功能	技术形态	关键需求
透明报价查看	Web + 微信小程序	CST-01 全参数分解展示
自助下单	Web + 小程序	ORD-01 C 端下单
订单进度查看	Web + 小程序	CST-02 实时进度
自助验收	Web + 小程序	CST-03 逐项确认
评价回访	Web + 小程序	CST-04 结构化问卷
在线支付	Web + 小程序	PAY 集成
历史订单	Web + 小程序	CST-06 复购入口

6.4.2 DLV 配送端¶

功能	技术形态	关键需求
配送节点扫码打卡	微信小程序	DLV-01
异常即时上报	微信小程序	DLV-02
签收状态同步	微信小程序	DLV-03
配送费结算	后台	PAY 集成

6.4.3 PRT 合作方端¶

功能	技术形态	关键需求
B 端订单批量导入	API + Webhook	PRT-01
订单状态批量同步	API + Webhook	PRT-02
产品参数批量导入	API	PRT-03
月度对账报表	API + Web	PRT-04

6.4.4 OPS 运营前端（完整版）¶

阶段 1 OPR 后台基础版升级为完整版，新增： - 获客场景管理（OPS-S01~S06 落地工具） - 销售物料管理（OPS-M 7 组 32 项物料） - 口碑营销自动化（NPS 触发推荐邀请） - B 端合作管理（PRT 对接） - 数据看板完整版（转化漏斗/师傅负载/楼宇分布/NPS 趋势）

6.4.5 PAY 结算服务（完整版）¶

模块	阶段 1	阶段 2
平台对账	✅ 基础	✅ 完整（多维度）
师傅结算	✅ 收入查看	✅ 自动结算 + 提现
合作方对账	—	✅ 月度自动
发票管理	—	✅ 电子发票
在线支付	—	✅ 多渠道（FPS/信用卡/微信）

6.5 AI 深度化（阶段 2）¶

AI 能力	应用场景	技术实现	价值
AI 智能派单	DSP 自动派单	ML 模型 + 师傅画像 + 实时负载	派单效率提升 50%、匹配度提升 40%
AI 质检	CPT 照片自动质检	CV 模型 + 规则引擎	质检覆盖率 100%、漏检率<2%
AI 客服	CST 自助客服	LLM + 知识库 + 话术	70% 问题 AI 解决、人工减负
AI 流失预测	CST/WKR 流失预警	ML 模型 + 行为数据	流失率降低 30%
AI 报价优化	QSV 报价校准	ML + 历史成交数据	报价偏差率<5%
AI 推荐引擎	口碑营销	ML + 客户画像	推荐转化率提升 25%
AI 调度优化	配送路线优化	ML + 地图 API	配送效率提升 20%

6.6 业务拓展配合（阶段 2）¶

阶段 2 业务目标：单量从日均 30-50 单提升至 80-150 单，全港覆盖。

月份	业务目标	拓展重点	技术配合
M4	日均 50-70 单	新界扩展 + SCENE05 品牌 + B 端合作	CST/DLV/PRT 端开发
M5	日均 70-100 单	离岛扩展 + 品类增至 15+ + 用户补贴获客	AI 深度化 + 服务化拆分
M6	日均 100-150 单	全港覆盖 + 全场景 + 复购率>30%	全平台联调 + 上线

6.7 退出条件（阶段 2）¶

退出条件	验证方式	责任人
5 类干系方全端上线	全端灰度发布稳定	TL
日均 80-150 单支撑	实际跑通 14 天	OL
7 功能组 100% 覆盖	全需求覆盖矩阵验收	PO
AI 深度化 5+ 点上线	AI 能力列表核对	TL + AI
SLA 99.9%	监控数据	OP
全港覆盖	港岛/九龙/新界/离岛均有订单	ML
用户满意度 ≥4.3/5	全干系方问卷	PO

七、技术架构与栈选型¶

7.1 架构原则¶

原则	含义	实现方式
灵活适应	技术平台尽可能灵活适应业务变化	DDD 领域驱动、模块化、配置化、低耦合
API 优先	所有功能通过 API 暴露，前端按端定制	BFF 层 + RESTful/GraphQL
AI 内嵌	AI 不是外挂，而是系统内生能力	AI 服务化、Prompt 库、模型治理
移动优先	一线操作以移动端为主	PWA + 小程序、响应式设计
数据驱动	数据是核心资产，贯穿全程	snake_case 兼容、ETL 自动化、数据治理
渐进演进	架构随业务演进，避免过度设计	模块化单体 → 服务化，按需拆分
安全合规	PDPO 合规、数据安全	香港法规、权限分级、审计日志

7.2 推荐技术栈（完整）¶

flowchart TD
    subgraph 前端
        NEXT["Next.js 14+<br/>TypeScript"]
        TAIL["Tailwind CSS"]
        SHAD["shadcn/ui"]
        PWA["PWA"]
        MINI["微信小程序<br/>Taro/原生"]
    end

    subgraph 后端
        FAST["FastAPI<br/>Python 3.11+"]
        SQLA["SQLAlchemy 2.0"]
        ALEB["Alembic 迁移"]
        PYD["Pydantic v2"]
        CEL["Celery 异步"]
    end

    subgraph 数据
        PG["PostgreSQL 16"]
        REDIS2["Redis 7+"]
        R2["Cloudflare R2"]
    end

    subgraph AI
        LLM["OpenAI/Anthropic<br/>LLM API"]
        DT2["听写助手<br/>项目上下文"]
        ML2["ML 模型<br/>scikit-learn"]
        VEC["向量库<br/>pgvector"]
    end

    subgraph 部署
        CF["Cloudflare<br/>Pages/Workers/R2"]
        GH["GitHub Actions<br/>CI/CD"]
        SENTRY["Sentry<br/>错误监控"]
        LOGFIRE["Logfire<br/>性能监控"]
    end

    NEXT --> FAST
    MINI --> FAST
    FAST --> PG
    FAST --> REDIS2
    FAST --> R2
    FAST --> LLM
    FAST --> DT2
    FAST --> ML2
    PG --> VEC

    style 前端 fill:#2a9d8f,stroke:#004046,color:#fff;
    style 后端 fill:#457b9d,stroke:#004046,color:#fff;
    style AI fill:#D4AF78,stroke:#004046,color:#004046;

7.3 模块化设计（DDD 领域驱动）¶

7.3.1 项目结构（阶段 1 模块化单体）¶

hk2026-platform/
├── frontend/                  # 前端
│   ├── opr-console/          # OPR 运营后台
│   ├── wkr-app/              # WKR 师傅 App
│   └── shared/               # 共享组件
├── backend/                   # 后端模块化单体
│   ├── app/
│   │   ├── domains/          # DDD 领域模块
│   │   │   ├── qsv/         # 报价领域
│   │   │   │   ├── models/        # 实体
│   │   │   │   ├── repositories/  # 仓储
│   │   │   │   ├── services/      # 领域服务
│   │   │   │   ├── api/           # API 路由
│   │   │   │   └── tests/
│   │   │   ├── cpt/         # 跟踪领域
│   │   │   ├── mds/         # 主数据领域
│   │   │   ├── dsp/         # 派单领域
│   │   │   └── pay/         # 结算领域
│   │   ├── shared/          # 共享内核
│   │   │   ├── kernel/      # 通用值对象
│   │   │   ├── infra/       # 基础设施
│   │   │   └── ai/          # AI 集成
│   │   └── main.py          # 应用入口
│   ├── migrations/          # Alembic 迁移
│   └── tests/
├── infra/                    # 基础设施配置
│   ├── docker/
│   ├── cloudflare/
│   └── github-actions/
├── docs/                    # 技术文档
└── scripts/                 # 运维脚本

7.3.2 模块间通信规则¶

通信类型	阶段 1	阶段 2
同模块内	直接调用	直接调用
跨模块（查询）	接口调用 + 依赖注入	API 调用 / 事件
跨模块（命令）	接口调用 + 依赖注入	消息队列异步
跨服务（阶段 2）	—	RESTful / gRPC / 消息

7.4 数据迁移路径（全程零成本）¶

flowchart LR
    A["阶段0<br/>飞书多维表格<br/>snake_case 40字段"] -->|CSV→COPY| B["阶段1<br/>PostgreSQL<br/>同名字段"]
    B -->|DDL 兼容| C["阶段2<br/>PostgreSQL<br/>+ 读副本+分库"]

    A -->|"零改造"| B
    B -->|"零改造"| C

    style A fill:#D4AF78,stroke:#004046,color:#004046;
    style B fill:#2a9d8f,stroke:#004046,color:#fff;
    style C fill:#457b9d,stroke:#004046,color:#fff;

7.5 部署架构（与现有 Cloudflare 对齐）¶

组件	部署位置	理由
前端（OPR/WKR/CST/DLV/PRT）	Cloudflare Pages	与现有文档站对齐、全球 CDN、自动部署
后端 API	Cloudflare Workers / 自建容器	Workers 轻量、容器灵活
数据库	自建 PostgreSQL（香港机房）	数据主权、PDPO 合规
对象存储	Cloudflare R2	零出口费、与现有对齐
AI 服务	多云（OpenAI/Anthropic/自建）	模型多样性、成本优化
监控	Sentry + Logfire	错误+性能全覆盖

八、双轮迭代机制¶

8.1 业务→技术：需求驱动¶

flowchart LR
    A["业务场景落地<br/>OPS S01-S06"] --> B["单量增长<br/>数据沉淀"]
    B --> C["场景反馈<br/>新需求/痛点"]
    C --> D["需求池<br/>PO 维护"]
    D --> E["Sprint 规划<br/>TL+PO 优先级"]
    E --> F["技术开发<br/>BE/FE/FS"]
    F --> G["能力上线<br/>释放新场景"]

    style D fill:#D4AF78,stroke:#004046,color:#004046;
    style F fill:#457b9d,stroke:#004046,color:#fff;

8.2 技术→业务：能力释放¶

技术能力上线	释放的业务场景
透明报价 API	CST 自助下单、PRT 批量报价
实时订单跟踪	CST 进度查看、OPR 全流程监控
AI 智能派单	单量翻倍、师傅效率提升
在线支付	CST 转化率提升、资金回笼加速
AI 客服	7×24 客户支持、人工减负
AI 质检	服务质量提升、客诉率降低
推荐引擎	口碑营销自动化、获客成本降低

8.3 迭代节奏¶

节奏	频率	参与者	产出
每日站会	每日 15min	技术层	阻塞点同步
双周 Sprint	双周 2h	全技术层+PO	可发布增量
业务×技术对齐	双周 1h	TL+PO+OL+ML	需求-产能对齐
月度复盘	每月 2h	全团队	复盘报告+下月计划
季度战略复盘	每季 4h	SPO+BO+TL+PO	战略调整+资源调配

8.4 AI 持续参与¶

AI 角色	参与环节	产出
听写 DT	全程	文档、需求分析、报告、AI 编码协作
AI 编码助手	开发全程	代码生成、审查、重构（占代码量 60%+）
AI 测试	测试阶段	单元测试生成、用例覆盖
AI 运维	运维全程	日志分析、异常预警、根因定位
AI 数据分析	复盘阶段	周报月报、流失预警、画像更新

九、组织与资源配置¶

9.1 团队配置演进¶

flowchart LR
    subgraph P0["阶段0 团队（6-7人）"]
        P0M["管理层: SPO+BO+TL"]
        P0B["业务层: OL+FL+ML"]
        P0T["技术层: TL兼+DT"]
    end

    subgraph P1["阶段1 团队（11-12人）"]
        P1M["管理层: +PO"]
        P1B["业务层: 同P0"]
        P1T["技术层: BE×2+FE+FS+OP×0.5+DT"]
    end

    subgraph P2["阶段2 团队（16-18人）"]
        P2M["管理层: 同P1"]
        P2B["业务层: +客服×2"]
        P2T["技术层: BE×3+FE×2+FS+OP+AI×0.5+DT"]
    end

    P0 --> P1 --> P2

    style P0 fill:#D4AF78,stroke:#004046,color:#004046;
    style P1 fill:#2a9d8f,stroke:#004046,color:#fff;
    style P2 fill:#457b9d,stroke:#004046,color:#fff;

9.2 协作机制¶

机制	频率	参与者	工具
每日站会	每日	技术层	飞书会议
双周 Sprint 评审	双周	全技术层+PO	飞书+GitHub
月度业务×技术复盘	每月	全团队	线下+飞书
季度战略复盘	每季	SPO+BO+TL+PO	线下
文档协作	持续	全员	飞书+Git
AI 协作	持续	全员	听写+Cursor

9.3 培训计划¶

培训项	时长	频率	参与者
AI 协作能力	4h	入职+季度	全员
DDD 实战	8h	阶段 1 启动前	技术层
香港市场认知	4h	入职	新人
CPT 8 阶段流程	4h	入职	新人
数据素养	8h	季度	全员
安全合规	4h	年度	全员

十、风险与应对¶

10.1 业务风险¶

风险	概率	影响	应对措施
单量不达预期	中	高	多场景并行获客、用户补贴、推荐激励
客诉率过高	中	高	AI 质检+人工兜底、SOP 严格执行
师傅供给不足	高	高	提前招募、师傅评级激励、AI 派单优化
合作方流失	中	中	多元化合作、API 体验优化、对账自动化
竞品压力	中	中	口碑壁垒、数据壁垒、AI 加持差异化

10.2 技术风险¶

风险	概率	影响	应对措施
开发延期	高	高	AI 加持、模块化、Sprint 严格、双轨并行
架构选型错误	中	高	模块化单体起步、按需演进、避免过度设计
数据迁移丢失	低	极高	双轨运行、AI 校验、备份保障
性能不达标	中	中	压测、读写分离、缓存、CDN
安全漏洞	中	极高	权限分级、审计日志、PDPO 合规、安全培训
AI 依赖过度	高	中	关键决策人工确认、AI 输出审查、人工兜底

10.3 人员与执行力风险（核心风险）¶

风险	概率	影响	应对措施
关键人员流失	中	极高	知识沉淀、文档化、双备份、股权激励
招聘不到位	高	高	提前 1 月启动、AI 协助筛选、多渠道
执行力不达预期	高	高	月度考核、绩效挂钩、及时调整、AI 减负
能力跟不上	中	中	培训计划、师徒制、AI 辅助
团队沟通不畅	中	高	双周站会、月度复盘、文档化沟通
AI 协作度低	中	中	培训、考核、工具选型、最佳实践分享

10.4 外部环境风险¶

风险	概率	影响	应对措施
PDPO 合规变化	低	高	持续关注法规、合规顾问、数据最小化
香港经济波动	中	中	多品类、多场景、灵活定价
物流中断	低	中	多物流合作方、自送能力、应急预案
Cloudflare 服务中断	低	中	多云备份、本地缓存、降级方案

十一、里程碑与交付物清单¶

11.1 里程碑总览¶

里程碑	日期	阶段	核心交付物	验收人
M0	2026-09-04	阶段 0 退出	飞书数据 50+ 单、表单 V1.3+	SPO+TL
M1-架构	2026-09-14	阶段 1 启动	DDD 架构设计 + 数据库 schema	TL+SPO
M1-α	2026-10-15	阶段 1 中期	α 版本（核心功能可跑）	TL+OL
M1	2026-11-10	阶段 1 上线	一线操作系统 v1.0	SPO+BO+TL
M2-β	2026-12-20	阶段 2 中期	β 版本（CST/DLV/PRT 端可跑）	TL+PO
M2	2027-01-20	阶段 2 上线	全干系方平台 v2.0	SPO+BO+TL

11.2 交付物清单¶

序号	交付物	阶段	形式	责任人
1	飞书 WEAVELY-MVP 多维表格	阶段 0	飞书在线	TL
2	CPT-Lite 跟踪表 Excel 模板	阶段 0	Excel	DT
3	阶段 0 数据沉淀报告	阶段 0	Markdown	DT
4	DDD 架构设计文档	阶段 1	Markdown	TL
5	数据库 Schema 设计	阶段 1	DDL+ER 图	BE
6	API 文档（OpenAPI）	阶段 1	YAML	BE
7	OPR 运营后台 v1.0	阶段 1	Web 应用	FE
8	WKR 师傅 App v1.0	阶段 1	PWA	FE
9	后端服务 v1.0	阶段 1	Docker 镜像	BE
10	数据迁移脚本	阶段 1	Python	BE
11	AI 集成模块 v1.0	阶段 1	Python	AI
12	阶段 1 上线报告	阶段 1	Markdown	TL+DT
13	CST 客户端 v2.0	阶段 2	Web+小程序	FE
14	DLV 配送端 v2.0	阶段 2	小程序	FE
15	PRT 合作方端 v2.0	阶段 2	API+Webhook	BE
16	OPS 运营前端完整版	阶段 2	Web	FE
17	PAY 结算服务完整版	阶段 2	服务	BE
18	AI 深度化模块	阶段 2	Python+ML	AI
19	服务化拆分方案	阶段 2	Markdown	TL
20	阶段 2 上线报告	阶段 2	Markdown	TL+DT
21	全平台运维手册	阶段 2	Markdown	OP
22	6 个月复盘报告	阶段 2	Markdown	SPO+TL+DT

修订记录¶

版本	日期	修订人	修订内容
V1.0	2026-08-07	DT	首版创建：基于用户预期（3 月一线系统、6 月全平台），在 MVP V1.0 基础上扩展为 6 个月技术平台演进方案；含三阶段目标（启动期/一线操作系统/全干系方平台）、双轮迭代模型、5 类干系方完整矩阵、项目角色岗位职责与执行力要求、模块化单体（DDD）+ Python FastAPI + React Next.js 技术栈、AI 加持策略、风险防控（突出人员执行力风险）
V1.1	2026-08-07	DT	§3.2 修正人员对应（与 PJM §3.1 RACI 对齐）：BO=洪、PO=郭、TL=司徒、OL=成文+黄双人分工、ML=洪兼BO、FL=待定；按 PJM §3.1 规范全文直接使用人员简称称呼（广/洪/郭/司徒/成文/黄），移除简称对照列与人员称呼对照说明；§3.2.1 SPO 执行力要求强化（里程碑即时确认+复盘调整+业务风险觉察+人员执行力修补）；§3.2.4 阶段团队配置人员对应修正；新增 §3.5 跨角色协作要求专章（协作总则/角色间信息流矩阵/4 个关键协作场景/协作工具规范/协作考核）

本方案为 6 个月技术平台演进规划文档，启动期子方案见 MVP实施方案 V1.0，业务需求见 RQD-O，项目管理见 PJM。