- 博客面向公开网络，脱敏以去掉明显的公司信息为准：公司标识、部门、人员隐私、内网域名和链接、凭证、账号以及可定位内部系统的专有标识必须处理。作者已有公开署名可以保留。
- 可以讲真实项目、项目名称、业务问题、技术架构、实现细节、失败案例和协作过程。不要为了脱敏把文章改成空泛的方法论；有助于理解的通用技术名词、字段语义和链路结构应保留。
- 业务指标（商品或用户规模、准召、覆盖率、业务实验收益等）用 XX 或局部打码处理；保持指标口径和问题成因可读。提效指标可以公开，包括团队人数、交付周期、对话轮次、Token、代码量、工具成本、吞吐、耗时、内存及系统错误率。区分实际记录、个人估算、概念示意和方案目标，不把推测写成测量结果。
- 原图没有明显公司信息时可以直接复用。需要处理时基于原图做局部编辑或重绘，尽量保留原来的画风、完整结构、信息密度和技术细节，不重新生成精简概念图来替代。检查图片、图注、替代文本、文件名、元数据和提交信息。
- 同一篇文章的配图风格应统一，业务架构图也需与正文配图协调。本文沿用原分享的纸张底色、深蓝线稿和少量砖红强调；调整画风时保留原图的层级、节点、连线、标签和技术细节，不能以统一风格为由精简内容。
- 结合材料的最新版本梳理；无法证实的外部数字及宣传性判断不直接转述为事实。
- 参考作者已有实践文章：用第一人称从实际场景和交付结果展开，按经历、问题、追查、修复、判断串起内容，允许自然的口语表达。
- 先把项目和技术问题讲清楚，再解释概念；保留有证据的数字、具体对话和关键代码示例，避免反复堆砌抽象结论或宣传口号。新增教学示例需明确标注，不虚构作者经历。
.cache/<任务名>/存放草稿、脚本、预览、图片生成过程、来源记录、上传映射等中间产物，已加入 Git 忽略规则，不得提交。uploads/专用于准备上传 OSS 的素材，不得作为通用缓存目录。assets/存放受版本控制的站点 SCSS 和 JavaScript，不得当作图片暂存区或批量清理。- 发布内容放在
content/post/<年份>/，使用既有 front matter、分类、作者署名和稳定 slug。
- 参考
img_upload_and_replace.sh的手工工作流：上传图片、取得永久公开链接、替换文章引用。现有桶为fliaping-blog，公开前缀为https://fliaping-blog.oss-rg-china-mainland.aliyuncs.com/storage/，按日期和时间组织对象。 - 旧脚本目前会上传并清空整个
assets/，不可直接执行。上传须限定本次素材，链接替换须限定本次文章，不得修改历史文章。 - 公共文章使用无签名、不会过期的 HTTPS 图片 URL。上传后通过匿名访问验证图片可读取，并检查内容类型。
- 凭证使用环境变量或仓库之外的本地配置，不打印、不写入文章、脚本常量、日志或 Git。缺少权限或鉴权时请用户配置，不得伪称完成。
- 开工检查工作区并拉取远端最新代码，保留用户未提交改动。正式发布分支为
master，推送后由.github/workflows/cloudflare-pages.yml构建和部署。 - 用户明确要求发布即授权完成相关提交、推送和验证；未授权发布时只准备可审阅产物。
- 推送前构建站点，核对正文、图片引用、脱敏和提交文件清单；缓存和原始内部材料不得进入提交。
- 推送后检查部署及公开文章 URL，只在部署成功且页面可访问后报告已发布；失败时如实说明阻碍。