【免费下载链接】jinba-consulting-pptx-skillAIにまじなPPTXを作らせる Claude Code / Codex スキル项目地址https://gitcode.com/gh_mirrors/co/jinba-consulting-pptx-skill点击查看免费下载想让 AI 做出「董事会级别」的 PPT靠的不仅是提示词。开源项目 consulting-pptx-skill 用一套「三件套」把经验沉淀下来规则 1 行 机械检查 测试。本文带你理解这套机制并逐步学会如何为它贡献一条新的检查能力——哪怕你从未写过检查脚本也能照着做。一、为什么是「三件套」consulting-pptx-skill 是一个 Claude Code 技能AI 读设计规则 → 用 HTML 零件集拼出 16:9 幻灯片 → 跑机械检查 → 交给「没参与制作的另一个 AI」评审。其中最核心的文件是 references/slide-rules.md——一本幻灯片设计「规则正典」。但规则只写在纸上不会自动生效。项目约定每一条可测量的新规则都要同时做三件事步骤做什么对应文件① 规则 1 行在规则正典末尾追加一行写清「规则 理由 例外」references/slide-rules.md② 机械检查在检查脚本里加一条自动判定违反就 FAILscripts/check_deck.py / scripts/check_layout.mjs③ 成对测试写 2 个测试「没修好时 FAIL、修好后通过」tests/test_checks.py贡献指南 CONTRIBUTING.md 的原话是「在没修好的版本上不触发的检查等于没测」。这正是三件套的灵魂。二、规则 1 行怎么读、怎么写slide-rules.md 按主题分章§1 画布、§2 标题、§4 布局、§6 表格……。有两点新手必须注意只追加、不改号。章节编号如 §2.9被检查脚本和其他文档交叉引用所以新规则一律加在章节末尾绝不重排编号。能测就测测不了也要说。如果规则无法机测比如「措辞是否自然」只写规则 1 行即可但要在 PR 说明里用 1 行写清「为什么测不了」。一条好规则的模板是禁止/要求什么 读者会怎么受害 例外条件。例如「标题里写『3 阶段』正文却有 4 个箭头 → 读者第一眼就会注意到这种自相矛盾」。三、机械检查两大脚本分工这个仓库有四个检查脚本贡献前先搞清楚该改哪个scripts/check_deck.py核心规则检查同时支持 HTML 和 PPTX只用 Python 标准库是贡献的主战场。它输出 FAIL必须为 0和 WARN建议处理并打印标题列表供人工通读。scripts/check_layout.mjs用 Playwright 做真实渲染检查抓静态文本分析看不到的问题如页脚与正文重叠、内容超出右边界、版面空白超过 40%、空列网格等。scripts/check_deck_layout.pyPPTX 专用找被遮挡的文字、空框、溢出、被拉伸的图片。tests/fixtures/good_deck.html一份「全绿」的合规样例资料几乎所有测试都基于它做「注入破坏 → 验证被捕获」。添加判定的套路很统一在check_deck.py里找到对应检查函数加一条正则/数值比较违反时调用fail(...)必须修或warn(...)建议看并在消息里带上规则出处例如§2.9让使用者能跳回正典查原因。⚠️ 保持check_deck.py与 scripts/new_deck.py只用 Python 标准库。新依赖要封闭在具体场景里如 PPTX 检查并同步更新 README 的 Set 设置说明。四、测试一对用例缺一不可打开 tests/test_checks.py 就能看到标准写法。核心工具函数inject(old, new)会把合规样例中的某段替换成「违规版本」然后运行check_deck.py看结果。以「标题以连接词开头要 WARN」为例一对测试长这样简化描述def test_connector_start_warns(self): # 坏版本 → 必须 WARN out run_out(inject(T, h1首先是……/h1)) self.assertIn(以连接词开头, out) def test_word_starting_with_mata_does_not_warn(self): # 好版本 → 不误报 out run_out(inject(T, h1跨越两个部门……/h1)) self.assertNotIn(以连接词开头, out)可以看到测试文件里还刻意保留了「反向用例」比如またがる跨越虽然以「また」开头但不是连接词不能误报。你的新检查同样要证明两件事能抓住违规且不误伤合规内容。PPTX 侧的测试在 tests/test_house_pptx.py它用 python-pptx 在内存中现场构造测试用 .pptx不往仓库放真实文件再逐字节篡改 XML 制造「坏版本」来验证判定。五、实战走一遍完整贡献流程假设你发现AI 生成的资料里经常残留Text 1、ラベル 2这类占位符没人管。按三件套走规则 1 行在 slide-rules.md 对应章节末尾追加——「交付资料中不得残留零件集的占位符Text N/ラベル N/YYYY残留即 FAIL§2.8」。加判定在 check_deck.py 里增加对正文文本块扫描这些模式的检查命中即fail(...)。加测试在 test_checks.py 加两个用例——inject一段正常文本为Text 1后断言返回码为 1再确认原始good_deck.html依然全绿。本地验证全部通过再提交 PRpython3 -m unittest discover -s tests python3 scripts/check_deck.py tests/fixtures/good_deck.html六、PR 前必读的两条红线 CONTRIBUTING.md 对贡献内容有两道硬门槛新手最容易踩坑1. 一条 PR 只解决一个问题。修 bug 和加规则不要混在一起相关的多项改动按顺序拆成多个 PR 依次提交。2. 绝不带出敏感信息。仓库是公开的diff、提交信息、分支名、PR 标题和描述都会被外人读到。以下内容一律不能出现客户名、合作方、项目编号、金额、合同条款、负责人姓名真实客户资料.pptx / .potx、其截图以及measure_deck.py产出的skin.json用真实措辞写的测试数据应换成「平均 3 天」这类虚构示例另外只有「任何组织都适用」的规则才进本体。单一公司的品牌偏好、颜色字体规定应放在本地local/目录git 管理外而不是 PR 进去。七、提交前自检清单 ✅规则 1 行已追加到章节末尾编号未改动检查脚本已加判定FAIL/WARN 消息带 § 编号测试成对存在坏版本 FAIL、好版本通过python3 -m unittest discover -s tests全绿check_deck.py对 good_deck.html 输出0 FAILdiff、提交信息、PR 描述中无敏感词可用local/forbid.txt自查分支命名规范feat/…、fix/…、docs/…、chore/…写在最后这套「规则 1 行 机械检查 成对测试」的机制本质是把「人的经验教训」变成「机器可执行的资产」规则不会随 AI 会话重置而消失检查不会因疏忽而漏过测试保证检查本身真的在工作。无论你是想加一条新规则还是修一个误报照这三步走就能成为 consulting-pptx-skill 的贡献者。 延伸阅读技能本体与完整工作流SKILL.md贡献规范全文CONTRIBUTING.mdAI 味词汇自检清单references/ai-smell-lexicon.md62 型零件目录references/archetype-catalog.md合规样例资料tests/fixtures/good_deck.html赞分享【免费下载链接】jinba-consulting-pptx-skillAIにまじなPPTXを作らせる Claude Code / Codex スキル项目地址https://gitcode.com/gh_mirrors/co/jinba-consulting-pptx-skill点击查看免费下载相关推荐classnames 开发者指南node 测试套件、tsd 类型检查与贡献全流程classnames 开发者指南node 测试套件、tsd 类型检查与贡献全流程 classnames 是一个用于条件式拼接 CSS 类名的简单 JavaSc前端Flow Launcher 彻底卸载一次清干净残留让重装变回全新状态Flow Launcher 彻底卸载一次清干净残留让重装变回全新状态 Flow Launcher 是 Windows 上的快速文件搜索与启动器很多老用户都桌面应用插件系统打造高效.env文件检查工具dotenv-linter贡献指南与新规则开发全攻略打造高效.env文件检查工具dotenv linter贡献指南与新规则开发全攻略 你是否曾因.env文件中的重复键、错误分隔符或未加引号的值而浪费数小时调试开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考