share-doc-pipeline
Skill1 starsChanged 49 days agoMITView on GitHub
把做完的项目整理成可以对外发布的总结文档——用脚本生成 Word、截图前先自动脱敏、再转成 PDF 逐页看图验证排版。当内部成果要拿到外部平台分享、且材料里含有单位名、地名、编号、密钥这类不能外泄的信息时使用。
- Installs packages
In this repository3 other files it gives its agents.
- excel-data-pipelineSkill
- html-slide-reportSkill
- single-file-dashboardSkill
The file
Files
总结文档与对外分享流水线
脱敏前后对照与整条流水线(示例数据):
Image: 效果示例
这套流程解决什么
把已经做完的项目变成别人看得懂、自己以后还用得上的总结材料。真正的难点不在写文案,在两件事:
- 脱敏不能漏。 项目材料里到处是单位全称、地名、小区名、水表编号、地图坐标、接口密钥。手工一张张图去涂,一定会漏,而漏一个就等于全部白做。
- 排版不能崩。 手工排版的东西改一次文案就要重排一次,而且表格溢出、图片变形这类问题只有渲染出来才看得见。
所以这套流程的设计取向是:能变成代码的都变成代码,剩下的只保留一件必须靠眼睛的事——看图。
一次产出两类东西
| 产出 | 面向谁 | 作用 |
| N 份总结文档 | 外部读者 | 讲清每个项目「为什么做、怎么做、做成了什么、要注意什么」 |
| 本流水线本身 | 自己 | 下次有新项目,照着走一遍就能再产出一套 |
工作流
第 1 步:先读文档,再读数据
每个项目里都已经有说明文档(README / 项目指引 / 项目笔记)。先把它们读完再去看原始数据——文档里有结论、有踩坑记录、有当时为什么这么选,这些都比从数据里反推快得多。
同时留意文档与实现是否已经不一致。一个真实的例子:某项目的说明文档里写的默认密码与代码里的实际值不同,文档写的入口文件名也和实际文件名对不上。这种不一致本身就是总结里最值得写的一条「注意事项」——它提醒后来的人「文档会过期,以代码为准」。
第 2 步:先定标题,再写正文
标题定不下来,正文一定会跑题。
原则:动词前置、去掉修饰、一眼知道是什么。
| 要避免的写法 | 为什么 |
项目V2_最终版_0713 | 带版本号和时间戳,对外没有意义 |
数据可视化实践 | 只有领域,没有对象,读者不知道具体是什么 |
| 标题里出现单位名、地名、人名 | 违反脱敏红线 |
每个标题配一句副标题,一句话说清定位:
降低产销差专项工作汇报 从台账数据到可讲、可打印、可分发的一整套汇报材料
第 3 步:列脱敏范围(红线,不能跳)
打开 references/anonymization-checklist.md,逐项过一遍,把这个项目里所有可识别主体列出来:
- 单位全称、下属机构名 → 「某水务公司」「某供水所」
- 市名、区名、街道名 → 「某地」「某经济开发区」
- 小区 / 村庄 / 企业名 → 「片区A」「片区B」…(按出现顺序编号)
- 水表编号 / 用户编号 → 「编号隐去」或直接隐藏整列
- 地图坐标、底图 → 模糊化
- 接口密钥、访问密码 → 一律不写进文档
- 个人隐私(姓名、生日、籍贯、测评结果)→ 这类项目只讲方法,不讲内容
写进 scripts/sanitize_shot.py 顶部的替换表。
可以保留的:经营数据的数值本身(万吨、比率、百分点)、行业标准与阈值、技术方案与实现细节。数值是成果的说服力的来源,也是行业通用量级,不构成识别风险。
第 4 步:出图,然后逐张看图
python scripts/sanitize_shot.py # 截图(截图前在浏览器里完成脱敏)
python make_charts.py # 数据图表(用脱敏后的标签重绘)⚠️ 改完脱敏规则,必须重新逐张看图确认,不能只看脚本跑通。 这一步跳过是整个流程里代价最高的失误。实际发生过三类问题,全都是看图才发现的:
- 地名漏替换——某条地名藏在表格的辅助列里,不在脚本收集的字段清单里;
- 编号没盖住——编号规则漏了一种格式;
- 月份被人名规则误伤——把
1月2月这类替换规则写得太宽,正文里的月份被换掉了。
第 5 步:按骨架写文案
四段式,每份 1500—2500 字为宜。详见 references/doc-skeleton.md:
起因 —— 当时遇到了什么具体麻烦
开展思路 —— 怎么想的、为什么这么选(配 2—4 张图)
成果 —— 交付了什么、算出了什么、前后对比(配 1—3 张图)
注意事项 —— 踩过的坑、口径问题、脱敏要求「注意事项」是最有价值的一章。 读者最想看的就是"你踩过什么坑"。分两类写:数据/口径类、实现/技术类,条件允许再加一条「对外分享的脱敏要求」。
第 6 步:脚本生成 Word
cd 总结目录
npm install docx
node build_docs.js从 assets/docx_template.js 起步——样式、页眉页脚、表格工具函数都已写好,只需要改内容块。
第 7 步:渲染校验
# Word 批量转 PDF(本机装了 Word,不需要 LibreOffice)
# 注意 -ExecutionPolicy Bypass:默认策略会拒绝运行 .ps1
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/word_to_pdf.ps1 -Dir . -Pattern "0*.docx"
# PDF 逐页转图片,然后看图
python scripts/pdf_to_images.py 输出目录 --dpi 95逐页看图确认三件事:表格有没有溢页、图片有没有变形、分页位置合不合理。
第 8 步:交付前最后一遍
通读全部文档,只盯一件事:还有没有漏掉的可识别信息。
把文档文字抽出来搜一遍敏感词是最有效的兜底:
python scripts/scan_leaks.py *.docx --terms 单位名 地名 项目代号目录内容
share-doc-pipeline/
├── SKILL.md
├── scripts/
│ ├── sanitize_shot.py 截图 + 三层自动脱敏(第 4 步)
│ ├── word_to_pdf.ps1 Word COM 批量转 PDF(第 7 步)
│ ├── pdf_to_images.py PDF 逐页转图片,供看图(第 7 步)
│ └── scan_leaks.py 交付前扫敏感词(第 8 步)
├── references/
│ ├── doc-skeleton.md 四段式骨架 + 标题定法 + 各章写作要点
│ └── anonymization-checklist.md 脱敏清单与三层实现原理
└── assets/
└── docx_template.js 生成 Word 的脚本骨架(样式 / 表格 / 页眉页脚)三个必须知道的实现细节
① 脱敏要在截图前做,不能在截图后涂。 截完再涂要处理每一张图、每一个位置,而且图片一旦生成,信息就已经落盘了。在浏览器里替换文本则是一次性的、可复用的。
② 图表要单独处理。 ECharts 把文字画在 <canvas> 上,DOM 文本替换够不着。要读图表实例的配置、把里面的字符串过一遍替换规则、再 setOption 重渲染一遍。
③ 地图要模糊底图。 地图直接暴露地理位置,替换文字没用。对瓦片层加模糊滤镜——保留管线与标记的形状,但地名不可辨认。
完整原理见 references/anonymization-checklist.md。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

