我们希望将设计分享从“一次性内容”升级为“长期可复用资产”。
一次完整的设计分享，需要同时满足两类能力，并统一上传至 GitHub 设计团队仓库：
- 展示层：保证现场表达、视觉展现与线上托管的阅读体验，对人友好。
- 结构层：保留分享的知识结构、方法模型与行动建议，对系统和 AI 友好。
这样做的目标是让分享内容具备以下长期价值：
- 可 diff（版本可追踪）
- 可检索（结构化搜索）
- 可复用（方法论沉淀）
- 可接入 AI（未来支持语义检索与训练）
这份规范管理的是“内容能力”，判断标准是展示层和结构层有没有被保留下来。
每次分享请在 design-sharing/ 下建立独立文件夹。
- 文件夹命名默认使用
分享主题，中文或英文均可，但同一文件夹内保持一致。 - 如需区分同名主题、系列内容或多人同题分享，可使用
分享主题_日期或分享主题_作者_日期。
然后只需要判断一件事：你当前的原始产物属于哪种场景。
- 场景 A：已经有包含完整正文、可阅读、可检索、可维护的 HTML 页面。
- 场景 B：暂时只有 Keynote / PPT，最终只能导出 PDF。
判断完成后，对应采用下面的一套结构即可，不需要把两套流程混用。
适用情况：已经有高质量 HTML，且 HTML 本身就能同时承担展示层和结构层。
这意味着它包含完整正文，核心观点可以被阅读、搜索和维护。
如果当前还没有现成 HTML，也可以先整理分享内容的文字框架或大纲，再交给 Codex 或其他 AI 生成初版 HTML，然后在此基础上继续补充和调整。
design-sharing/
└── product-design（分享主题名称）/
├── index.html（固定命名）
└── README.md （固定命名）
index.html：核心资产，承担展示层和结构层。README.md：薄版入口，只负责摘要、作者、日期、预览地址，以及补充资源链接。
- HTML 文件产出：
- 先整理分享内容的文字框架或大纲，至少包括背景、核心观点、方法模型、结论和行动建议。
- 将这份文字框架喂给 Codex 或其他 AI，生成一个可阅读、可维护的 HTML 初版。
- 检查并完善生成结果，确保正文完整、结构清晰、样式可读，且核心观点可以被搜索和维护。
- 放置文件：
- 在
design-sharing/下创建独立文件夹，默认命名为分享主题。 - 将 HTML 文件命名为
index.html放入该文件夹。 - 在同级目录下创建
README.md，简要记录分享摘要、作者、日期和拼接的预览地址。 - 如有设计源文件或补充资源，上传至内部 Kodo，并将链接记录在
README.md末尾。
- 如果
index.html已经包含完整正文，就不要再额外导出slides.pdf。 - AI 生成的 HTML 只是初版，提交前仍需人工检查内容准确性、结构完整性和阅读体验。
Pages 根地址 + 文件在仓库里的相对路径
例如，design-sharing/产品设计工程化工作流/index.html 对应：
https://qiniu-ued.github.io/UED_Assets/design-sharing/产品设计工程化工作流/index.html
浏览器地址栏可以直接粘贴中文路径；如需对外分享，也可以使用转码后的地址。
团队仓库的 GitHub Pages 正式预览目前从 main 分支根目录发布。仅进入 ui 的内容不会立即出现在正式预览地址中，需要由管理员通过 ui → main Pull Request 合入 main 后才会更新。
适用情况：暂时没有 HTML，只能产出 Keynote / PPT 演示文稿。
这个场景里，slides.pdf 只能承担展示层，不能保留结构层。所以必须通过 README.md 把被扁平化的知识结构补回来。
design-sharing/
└── product-design（分享主题名称）/
├── slides.pdf（固定命名）
└── README.md （固定命名）
slides.pdf：展示层，用于预览、演示和下载。README.md：结构层，用于转写和提炼 PDF 中的知识内容。
- 在
design-sharing/下创建独立文件夹，默认命名为分享主题。 - 将演示文稿导出为
slides.pdf放入文件夹，保证内容可在线预览与下载。 - 在同级目录下创建
README.md，除基础摘要外，必须将 PDF 内的知识结构提炼并转写为文本。 - 如有 PPT / Keynote 原始文件或补充资源，上传至内部 Kodo，并将链接记录在
README.md末尾。
- 分享背景
- 核心观点
- 方法模型
- 框架结构
- 可复用结论
- 行动建议
目标是：即使不下载 PDF，团队成员、搜索系统和 AI 也能通过这份 README.md 理解分享中的核心内容。
- 只要产物已经同时具备展示、阅读、检索、版本追踪和复用能力，目录就应尽量保持简洁。
- HTML 场景下，
README.md只写薄版入口，不要在已有完整 HTML 正文的情况下再重复转写一份复杂 Markdown。 - 不要把大型设计源文件直接上传到仓库。超过 GitHub 推荐大小的大文件，如
.key、.psd、.fig，统一走内部 Kodo，并在README.md中留底链接。
这样做的意义，不是单纯把分享“归档一下”，而是把它逐步沉淀为团队可以持续积累的知识系统：
- 今天能展示和交付
- 明天能回看和复用
- 以后能检索、对比版本，并接入 AI 能力
ui：团队日常集成分支。禁止直接提交，所有改动必须通过 Pull Request 合入。main：团队稳定分支。禁止直接提交，只能由管理员通过ui→mainPull Request 统一合入。ui和main均禁止删除和强制推送。- 团队主仓库长期只保留
main、ui；仓库已开启 PR 合并后自动删除源分支，团队仓库中的普通临时开发分支会在合并后自动删除。
origin：自己的 GitHub Fork 仓库。upstream：团队主仓库qiniu-ued/UED_Assets。
git fetch upstream
git switch -c feature/修改说明 upstream/ui开发分支必须基于团队远端最新的 upstream/ui 创建，不要基于 main 或过期的本地分支创建。
完成修改后，只暂存本次涉及的文件，提交并推送到个人 Fork：
git add <本次修改的文件路径>
git commit -m "本次提交说明"
git push -u origin feature/修改说明然后在 GitHub 创建 Pull Request，并确认比较方向：
- 源分支：个人 Fork 中的开发分支；拥有 Write 权限的成员也可以使用团队仓库中的独立开发分支。
- 目标分支：团队仓库的
ui。 - 至少需要 1 个 Approve，通过审核后才能合并。
Files changed应只包含本次修改；如果出现无关文件，先检查开发分支是否确实基于最新upstream/ui创建。- 个人 Fork 中的临时开发分支不会被团队仓库自动删除，需要成员在 PR 合并后自行清理。
开发分支的历史中包含其他成员已经进入 ui 的 commit 是正常的；PR 只比较开发分支相对于 ui 新增的改动。
ui 是受保护分支。在 GitHub 网页中编辑或上传文件后，提交窗口会提示无法直接提交到 ui。这不是权限故障，请选择：
Create a new branch for this commit and start a pull request
填写临时开发分支名并点击 Propose changes，然后确认 PR 的目标分支是团队仓库的 ui。不要选择 main，也不要尝试绕过规则直接提交 ui。
管理员在一个阶段的分享资料完成后，创建 ui → main Pull Request，将 ui 中累计的多个 commit 统一合入 main。
- PR 源分支必须是团队仓库的
ui。 - PR 目标分支必须是团队仓库的
main。 main-pr-source-policy必须通过。- 合并方式使用 Create a merge commit，不要使用 Squash 或 Rebase。
- 不要直接向
main提交或推送。
合并完成后，验证 main 与 ui 的文件树是否一致：
git fetch upstream
git diff --stat upstream/main upstream/ui命令没有输出，表示两个分支的文件内容一致。由于 main 上会产生合并提交，两个分支的 commit 哈希可以不同。