项目管理制度（Project Management - PJM）¶

文档编号：DOC-A05 / PJM 版本：V1.8 创建日期：2026-08-04 最近更新：2026-08-06 维护人：SPO / DT 关联文档：PMG、RQD、GLY、WLG

一、项目概述¶

1.1 基本信息¶

项	内容
项目名称	香港配送+安装互联网平台 (HKDIP)
运营主体	织布鸟智居科技有限公司（WEAVELY TECHNOLOGIES LIMITED）
品牌	织布鸟 WEAVELY
Slogan	用心编织你的理想家居
当前阶段	筹备期前期

1.2 平台服务架构¶

服务	编号	定位	状态
QSV 报价服务	DOC-P31	定价引擎，多维动态报价	设计完成
CPT 客户项目跟踪服务	DOC-P41	全生命周期信息采集	设计完成

服务关系：CPT 为数据主线，采集全过程数据反哺 QSV 校准，形成闭环。

详细服务设计见各服务子目录，业务需求见 RQD。

1.3 品牌视觉规范¶

品牌色	色值	用途
深墨绿	HEX #004046	主色
浅沙金	HEX #D4AF78	辅色
米白浅灰	HEX #F2F0EB	背景色

二、管理制度¶

2.1 目标管理¶

项目遵循「战略目标 → 阶段里程碑 → 月度目标 → 周任务」的逐级分解：

层级	周期	制定人	示例
战略目标	全周期	SPO	市场份额 >15%
阶段里程碑	每阶段	BO	MVP 报价引擎上线
月度目标	每月	各角色	完成报价模型设计
周任务	每周	各成员	完成基础费率表

2.2 任务管理¶

「分配 → 跟踪 → 闭环」三步法：明确负责人、截止时间、验收标准；阻塞项 24 小时内上报；闭环后记入 WLG。

2.3 进度管理¶

周报：每周五 BO 汇总
里程碑评审：每个阶段前召开
进度偏差：延期超 1 周须提交说明

2.4 风险管理¶

风险	应对策略	负责角色
数据安全（客户/师傅信息泄露）	权限管控，AI 不外泄敏感数据	TL
法规风险（行业监管趋严）	主动合规，合同规范，保险完备	FL
交付风险（服务质量不达标）	师傅分层、质检体系、客户评价	OL

完整业务风险见 RQD §3.4。

2.5 变更管理¶

变更类型	审批人	记录要求
报价模型参数调整	SPO + BO	更新 QMD，记入 WLG
跟踪流程调整	SPO + OL	更新 CPT，记入 WLG
业务模式调整	SPO	评审会决议，更新 RQD
技术架构变更	TL + SPO	更新 TND
文档规范变更	DT	更新本文件

变更流程：提出 → 评估影响 → 审批 → 执行 → 验证 → 归档。

2.6 质量管理¶

文档质量：正式文档须经评审；DT 负责质量把关
流程图规范：所有流程图统一使用 Mermaid 语法，中文节点名采用 id["中文标签"] 格式（见 §5）
服务质量：师傅分层系统、客户评价机制、神秘客抽检
质检指标：成交率、客诉率、按时完成率、好评率

2.7 决策机制¶

决策层级	决策内容	决策人
战略级	方向、预算、核心合作	SPO
业务级	报价参数、合作条款	BO（重大报 SPO）
执行级	日常任务、技术实现	对应角色

2.8 汇报机制¶

汇报	频率	对象
每日站会	每日	核心角色
周报	每周	全体
月度复盘	每月	SPO + 核心角色
阶段评审	每阶段	SPO + 相关角色

三、团队角色与权责（RACI）¶

3.1 角色缩写速查¶

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

现任人员对应基于 2026-08-05 核心运营团队内部讨论确认，详见 WLG 线下讨论。BO/FL 待后续确认。

3.2 RACI 矩阵¶

职责	SPO	BO	PO	TL	OL	ML	FL
战略方向	A/R	C	C	C	C	C	C
业务模式与报价	A	R	C	C	C	I	C
平台产品设计	I	C	R	C	C	I	I
系统架构与开发	I	I	C	R	I	I	I
师傅招募与培训	I	C	I	I	R	I	C
合作方拓展	A	R	I	I	C	C	C
内容与推广	I	C	I	I	C	R	I
合同/合规	A	C	I	I	C	I	R
文档与工作日志	I	C	C	C	C	C	C

3.3 角色核心职责¶

角色	核心职责
SPO	战略决策、资源投入、关键合作拍板
BO	业务模式、场景落地、合作拓展、报价校准
PO	平台设计、需求管理、产品路线图
TL	架构选型、技术实现、API 对接
OL	师傅招募培训、SOP、质检、售后。双人分工：成文负责客户运营（前端业务执行、客户跟进、信息同步）；黄总负责落地执行（风险把控、关键节点、作业规范 SOP）
ML	内容矩阵、社交媒体、推广、品牌合作
FL	商业登记、保险、合同、对账、合规

四、协作机制¶

4.1 沟通渠道¶

渠道	用途	记录要求
线下会议	战略决策、方案评审	24h 内整理至 WLG
微信	日常沟通、即时协调	重要决策当日整理至 WLG
AI 助手对话	文档撰写、方案起草	整理至 WLG

4.2 会议机制¶

会议	频率	参与人
项目周会	每周	全体核心角色
方案评审会	按需	相关角色 + SPO
每日站会	试运营起每日	BO/PO/TL/OL

4.3 版本管理与 Git¶

本项目所有代码与文档的版本管理、分支协作、仓库发布与公开同步规则，统一由本节维护，是团队 Git 操作的唯一权威依据。

4.3.1 仓库清单¶

所有仓库统一托管于 Gitee 码云（中国境内，国内访问稳定），按职能划分为两个仓库：

仓库	地址	可见性	定位	维护人
主仓库 hk2026	`https://gitee.com/atonio/hk2026`	私有	项目主仓库：docs/ 源文件、ref/ 参考资料、scripts/ 运维工具、AGENTS.md、发布/ 成品	TL / DT
公开文档镜像 hk2026-docs	`https://gitee.com/atonio/hk2026-docs`	公开（开源）	主仓库 docs/ + 发布/ 的只读镜像，供互联网任意访问阅读	TL / DT

职能划分：主仓库 = 私有工作区（含敏感内容与原始资料）；公开文档仓 = 只读对外窗口，不接受直接提交。所有修改在主仓库完成后，由同步脚本单向推送至公开文档仓（见 §4.3.6）。

4.3.2 分支策略（轻量 Git Flow）¶

采用轻量级 Git Flow 模型，仅保留三类分支：

分支类型	命名规范	来源	合并目标	说明
main	固定 `main`	—	—	稳定主干：仅接受来自 dev 的合并，每笔提交必须可部署、可归档
dev	固定 `dev`	main	main	开发集成主分支：日常文档编辑、脚本修改、功能迭代均在此提交
feature/	`feature/<简述>`	dev	dev	较大变更的隔离分支（如重构需求文档体系、新增 OPS 运营服务），完成后 PR 合并回 dev

工作流：

feature/<任务>  →  开发与验证
       ↓ 合并（PR / fast-forward）
     dev    →  日常集成分支（默认工作分支）
       ↓ 合并（PR，里程碑节点）
    main   →  稳定归档分支

合并规则： - 禁止直接向 main 提交，必须从 dev 合并 - 里程碑/归档节点合并 dev → main - feature 分支命名示例：feature/mds-masterdata、feature/ops-marketing

4.3.3 提交规范¶

格式：<类型>: <简述>

类型（type）	适用场景	示例
`docs`	文档新增/修改/重构	`docs: 完善报价模型品类费率表`
`chore`	脚本/配置/工具类变更（非业务文档）	`chore: 新增公开文档同步脚本`
`fix`	Bug 修复（含文档错误）	`fix: 修正 V1.1 归档递归问题`
`refactor`	结构重构（不改变文档核心含义）	`refactor: agents.md 解耦为 PMG + PJM`
`feat`	新增独立服务/模块/工具	`feat: 新增 MDS 主数据服务设计`

附加要求： - 单行 commit message 过长时，用多个 -m 参数追加段落说明 - 涉及跨文档变更（如新增 OPS 同步修改 12 份文档）须在附加段落中逐份列出 - 提交变更须与 WLG 工作日志双向可追溯：日志中记录对应 commit 短哈希

4.3.4 版本控制范围（纳入 / 排除）¶

类型	是否纳入 Git	说明
`docs/`（源 Markdown）	✅ 强制	全部正式文档，归档子目录见下
`docs/归档/`	❌ 排除	本地备份快照，远程不纳入（防止仓库体积膨胀与重复）
`ref/`（参考资料）	✅ 建议	只读参考资料；大文件 (>50MB) 建议改用 Git LFS
`发布/`（PDF/HTML 成品）	✅ 强制	面向不同受众的成品输出，与源文件同步版本
`scripts/`（运维脚本）	✅ 强制	含同步脚本、文档生成脚本等
`AGENTS.md`（根）	✅ 强制	AI 协作指南，为项目入口文档
`mkdocs.yml`（根）	✅ 强制	MkDocs 站点源配置（见 §4.3.7）
`.gitignore` / `.gitattributes`	✅ 强制	忽略与属性配置
操作系统文件（Thumbs.db / .DS_Store / Desktop.ini 等）	❌ 排除	由 `.gitignore` 全局屏蔽
IDE 配置（`.vscode/` `.idea/` `.trae/`）	❌ 排除	本地个人配置，不共享
Python 缓存（`__pycache__/`、`*.pyc`）	❌ 排除	构建产物
临时生成文件（`.tmp`、`.log`、`.bak`、模板 `_temp_`）	❌ 排除	一次性产物
虚拟环境（`venv/`、`.venv/`、`env/`）	❌ 排除	本地开发环境
旧版本残留文件（如 `AGENTSv6.1.pdf`）	❌ 排除	历史遗留，保留旧版本归档
MkDocs 站点产物（`site/`、`.build/`）	❌ 排除	构建产物，由 `build-site.py` 生成（见 §4.3.7）

.gitignore 为最终排除依据；如需新增例外，同步修改根目录 .gitignore 并记入 WLG。

4.3.5 发布目录机制¶

根目录 发布/ 为文档成品发布区，区别于代码发布（后者由后续 CI/CD 流程另行管理）。

维度	文档发布（`发布/`）	代码发布（未来）
内容	PDF / HTML 文档成品	可执行代码 / 部署包
受众	团队内部 / 投资方 / 客户 / 合作方	开发 / 运维
来源	由 `docs/` 源文件经 AI 特定行为（汇总 / 汇报输出）生成	开发编码产出
版本	文件名含版本号，跟随源文件版本	Git tag / release

AI 特定行为输出目标（与 PMG §特定行为条款同步）：

AI 行为	输出格式	输出目录
文档汇总输出	单一 PDF，按"篇"分隔，Mermaid 转图片	`发布/`
文档汇报输出	单一 PPT（HTML 格式）	`发布/`

目录管理： - 新增发布文档须同步更新 发布/README.md 内容清单 - 每次主仓库新增发布文档后，执行公开同步脚本同步镜像（见 §4.3.6）

4.3.6 公开文档同步（主仓库 → 公开文档仓）¶

目标：保持 docs/ 只读开放互联网访问，同时私有工作内容不外泄。

同步范围：仅同步主仓库 docs/ + 发布/（排除 docs/归档/，后者在 .gitignore 中已屏蔽，不会出现在 git ls-tree 列表内）。

自动同步脚本：

项	内容
位置	`scripts/sync-docs-repo.ps1`（编排层）+ `scripts/sync-docs-helper.py`（文件处理层）
执行时机	主仓库 docs/ 或发布/ 有重要变更后手动执行
原理	以 `git ls-tree -r -z --name-only HEAD -- docs 发布` 获取原始路径（NUL 分隔，无转义编码问题），Python 逐文件复制；首次生成落地页 README.md；最后 git commit + push 到公开仓
Commit message	`docs: sync from main <主仓短哈希> (docs/ + 发布/)`，可追溯每笔同步对应的主仓库快照

执行步骤（PowerShell）：

# 1. 克隆公开文档仓库（仅首次）
git clone https://gitee.com/atonio/hk2026-docs.git d:\AC\TF\hk2026-docs

# 2. 每次同步执行
d:\AC\TF\hk2026\scripts\sync-docs-repo.ps1

公开仓规则： - 公开文档仓的 docs/ 与 发布/ 结构与主仓库完全一致，确保 Markdown 相对链接（../xxx.md）在 Gitee 渲染器中有效 - 公开仓根 README.md 为落地页索引（首同步自动生成），含核心文档 / 服务设计 / 技术文档 / 发布成品四大导航区块 - 公开仓 不接受直接提交；任何修改须在主仓库完成后重新同步 - 主仓根目录的 AGENTS.md、ref/ 等不对外公开内容，不会被同步

4.3.7 文档站点发布（MkDocs Material + Cloudflare Pages）¶

目标：在公开文档镜像仓（§4.3.6）之外，新增可交互的在线文档站点作为第二条对外发布路径，提供全文搜索、侧边栏导航、Mermaid 原生渲染、深色模式等增强阅读体验。公开文档镜像仓保持不变，两条路径并行。

背景：公开文档镜像仓直接复制 Markdown 源文件，Gitee 的 MD 渲染较基础（Mermaid 图表不渲染、无全文搜索、无侧栏导航），且 Gitee Pages 服务已停服，无法托管静态站点。MkDocs Material 方案弥补这一短板。

技术栈：

项	内容
站点框架	MkDocs Material（Python，`pip install mkdocs-material`）
图表渲染	内置 SuperFences（原生 Mermaid，无需额外插件），覆盖项目 65+ 张 Mermaid 图
托管平台	Cloudflare Pages（全球 CDN，免费额度充足）
部署工具	wrangler CLI（`wrangler pages deploy`）
品牌主题	深墨绿 #004046（主色）、浅沙金 #D4AF78（辅色）、米白浅灰 #F2F0EB（背景），经 `assets/css/brand.css` 注入
默认域名	`hk2026-docs.pages.dev`，可绑定自定义域名

文件清单：

文件	作用
`mkdocs.yml`（根）	站点源配置（主题/扩展/nav/品牌色）；直接 `mkdocs serve` 会断链，须经 `build-site.py` 构建
`scripts/build-site.py`	构建编排：复制 docs/+AGENTS.md+发布/ → `.build/docs-src/`，重写跨边界链接，生成桩页面，执行 `mkdocs build`
`scripts/deploy-site.ps1`	部署编排：调用 build-site.py 构建后，经 wrangler 上传至 Cloudflare Pages
`site/`（产物）	构建产物，已 `.gitignore` 排除
`.build/`（临时）	构建临时工作区，已 `.gitignore` 排除

源文件零修改原则：所有链接重写仅作用于 .build/docs-src/ 临时副本，主仓 docs/、AGENTS.md、发布/ 源文件不动。构建完成后 .build/ 自动清理（--serve 模式保留供热重载）。

AGENTS.md 与跨边界链接处理：

源链接	重写为	说明
`AGENTS.md` → `docs-src/PMG.md`	`](docs/xxx.md` → `](xxx.md`	剥离 `docs/` 前缀；`docs/归档/README.md` 指向归档桩页面
`发布/README.md` 的 `../agents.md`	`../PMG.md`	发布目录指向 PMG
`发布/README.md` 的 `../docs/工作日志/...`	`../工作日志/...`	剥离 `../docs/` 中的 `docs/`
docs/ 副本的 `../agents.md`、`../../agents.md`	深度感知的 `PMG.md`	按文件实际深度统一修正（顺带修正工作日志源中错误的链接深度）
docs/ 副本的 `../../ref/...`、`../../../ref/...`	深度感知的 `参考资料.md`	ref/ 不公开，跳转桩页面

排除项： - docs/归档/（gitignored，不进构建） - ref/（外部参考资料，不公开，链接指向桩页面） - 工作日志的对话记录/微信/线下/附件页面仍构建（可直达 URL 访问），仅 not_in_nav 不显示在侧栏，避免侧栏过深

构建模式： - 默认非 strict：因工作日志存在历史链接债务（不应改动历史记录），--strict 会在断链处失败。源链接经一次性审计清理后可启用 --strict - --strict：strict 模式，断链即失败（供未来源链接审计） - --serve：本地预览 http://127.0.0.1:8000 - --no-publish：排除 发布/ 目录（PDF 不进站点）

部署流程（PowerShell，需一次性环境配置）：

# 一次性环境配置
pip install mkdocs-material
npm i -g wrangler
$env:CLOUDFLARE_ACCOUNT_ID = "<账号 ID>"
$env:CLOUDFLARE_API_TOKEN  = "<API Token>"
wrangler pages project create hk2026-docs --production-branch=main

# 每次部署
d:\AC\TF\hk2026\scripts\deploy-site.ps1
# 或仅构建不部署
python d:\AC\TF\hk2026\scripts\build-site.py

与 §4.3.6 公开文档镜像仓的关系：

维度	§4.3.6 公开文档镜像仓	§4.3.7 文档站点
形态	Gitee 仓库（MD 源码镜像）	Cloudflare Pages 静态站点
阅读体验	Gitee 基础 MD 渲染	搜索/导航/Mermaid 原生渲染/深色模式
更新方式	`sync-docs-repo.ps1` 同步	`deploy-site.ps1` 构建部署
是否并行	✅ 保留，两条路径并行	✅ 新增，增强阅读体验
受众	需查看源码/二次加工者	非专业技术人员阅读者

两条发布路径独立维护，文档变更后分别执行同步脚本与部署脚本。

4.4 文档版本与归档机制¶

4.4.1 文档版本规范¶

项	规范
版本号格式	`V<主版本>.<次版本>`，如 V1.0、V1.1、V2.0
主版本升级	重大重构、方向调整、结构变更（V1.0 → V2.0）
次版本升级	内容增补、修订优化、局部调整（V1.0 → V1.1）
版本记录	每份文档末尾须附「修订记录」表，记录版本、日期、修订人、修订内容
版本标注	文档头部须标注当前版本号与最近更新日期

4.4.2 归档触发条件¶

触发条件	归档时机	执行人
里程碑归档	每个阶段里程碑评审通过后	DT
版本归档	主版本升级（V1.0 → V2.0）时	DT
定期归档	每月末进行一次定期归档	DT
临时归档	SPO 指定或重大变更前	DT

4.4.3 归档目录结构¶

docs/归档/
├── README.md                    归档说明与索引
├── 20260804_V1.0_筹备期前期/     首次归档（日期_版本_阶段）
│   ├── agents.md
│   ├── docs/                    完整 docs 目录快照
│   ├── *.html                   PPT 等产出物
│   ├── *.pdf
│   └── 归档清单.md              本批次归档文件清单
├── YYYYMMDD_VX.X_阶段名/        后续归档
└── ...

4.4.4 归档命名规范¶

项	规范	示例
归档目录名	`YYYYMMDD_V<版本>_<阶段>`	`20260804_V1.0_筹备期前期`
归档清单	每批次归档须含 `归档清单.md`，记录归档时间、文件清单、版本快照	—
归档索引	`docs/归档/README.md` 维护全部归档批次索引	—

4.4.5 归档操作规范¶

完整性：归档须包含当前全部文档与产出物（含 HTML/PDF 等）
只读性：归档目录为只读快照，归档后不得修改
可追溯：归档清单须记录每份文件的版本号与文件大小
独立性：归档目录自包含，不依赖外部文件
非递归性：归档时必须排除 docs/归档 目录自身，避免无限递归复制
Git 双备份：归档同时提交至 Git 仓库，确保版本可追溯

递归防护（强制要求）：复制 docs/ 目录时必须使用 robocopy /XD "归档" 排除归档目录自身。归档完成后须执行递归校验：确认归档目录内不存在 docs/归档 子目录。

4.4.6 归档类型与策略¶

归档类型	适用场景	范围	操作要点
全量归档	里程碑、主版本升级、首次归档	全部文档与产出物	复制 docs/ 时用 `/XD "归档"` 排除归档目录
增量归档	月末定期、小版本更新	仅上次归档后变更的文件	用 `/XO /XL` 增量参数，仍需 `/XD "docs\归档"`
指定部分归档	临时需求、敏感文档单独归档	明确指定的文件/目录列表	按文件列表复制，若涉及 docs/ 仍需排除归档目录

全量归档命令示例（PowerShell）：

$dest = "d:\AC\TF\hk2026\docs\归档\YYYYMMDD_VX.X_阶段名"
New-Item -ItemType Directory -Path $dest -Force
Copy-Item "d:\AC\TF\hk2026\agents.md" $dest
Copy-Item "d:\AC\TF\hk2026\*.html" $dest
Copy-Item "d:\AC\TF\hk2026\*.pdf" $dest
# 关键：/XD "归档" 排除归档目录自身，避免递归
robocopy "d:\AC\TF\hk2026\docs" "$dest\docs" /E /XD "归档"
# ref/ 为外部参考资料，不纳入归档（见 ARC §3.5）
# 递归与排除校验
if (Test-Path "$dest\docs\归档") { Remove-Item "$dest\docs\归档" -Force -Recurse }
if (Test-Path "$dest\ref") { Remove-Item "$dest\ref" -Force -Recurse }

归档排除范围：docs/归档/（避免递归）、ref/（外部参考资料）、*.tmp/*.log（临时文件）、.git/、.vscode/。详见 ARC §3.5。

五、关键约束与原则¶

数据准确：参数与数据须标注来源，不确定信息须标注
保密合规：客户/师傅信息、商业机密不得外泄
格式一致：跨文档术语统一（见 GLY）；遵循品牌视觉规范
相对路径：所有文档引用一律相对路径，确保项目迁移有效
效率优先：减少不必要交互；明确指令直接执行
流程图规范：所有流程图统一使用 Mermaid 语法，禁止 ASCII 字符画流程图

六、修订记录¶

版本	日期	修订人	修订内容
V1.0	2026-08-04	DT	首版创建，从 PMG 迁移项目管理制度内容
V1.1	2026-08-04	DT	§5 新增第6条：流程图统一使用 Mermaid 语法
V1.2	2026-08-04	DT	§2.6 新增流程图规范，与 §5 形成呼应
V1.3	2026-08-04	DT	§4.4 新增文档版本与归档机制（版本规范/触发条件/目录结构/命名规范/操作规范）
V1.4	2026-08-05	DT	§4.4.5 新增「非递归性」原则与递归防护要求；新增 §4.4.6 归档类型与策略（全量/增量/指定部分）；修复 V1.0 归档递归问题
V1.5	2026-08-05	DT	§4.4.6 全量归档命令移除 ref 复制；新增归档排除范围说明（ref/、临时文件、.git/、IDE 配置）；校验脚本新增 ref 排除检查
V1.6	2026-08-05	DT	§3.1 角色缩写速查表新增「现任人员」列（曾总/郭总/司徒总/成文/黄总/洪哥）；§3.3 OL 角色补充双人分工说明（成文客户运营/黄总落地执行）；基于 2026-08-05 核心运营团队内部讨论
V1.7	2026-08-06	DT	§4.3 版本管理与 Git 系统化扩展（原 3 行扩展为 6 小节）：仓库清单（私有主仓 + 公开文档镜像仓）、轻量 Git Flow 分支策略（main/dev/feature）、提交规范（5 类型 + 示例）、版本控制范围（纳入/排除对照表 + .gitignore）、发布目录机制（与 PMG AI 特定行为同步）、公开文档同步（脚本原理 + 执行步骤）；成为团队 Git 操作唯一权威依据
V1.8	2026-08-06	DT	§4.3 新增 §4.3.7 文档站点发布（MkDocs Material + Cloudflare Pages）：可交互在线文档站点作为第二条对外发布路径（搜索/导航/Mermaid 原生渲染/深色模式）；新增 `mkdocs.yml`+`build-site.py`+`deploy-site.ps1`；源文件零修改原则（链接重写仅作用于 `.build/` 临时副本）；§4.3.4 版本控制范围表新增 `mkdocs.yml`（纳入）与 `site/`、`.build/`（排除）；与 §4.3.6 公开镜像仓并行

本文件为 PJM（项目管理制度），详细业务需求见 RQD，AI 协作规则见 PMG（agents.md）。