把一份装柜文档做成 Skill：8 组测试抓出 3 个真缺陷，还推翻了原文的答案
行业：外贸供应链 / 制造业 AI 应用 岗位：AI 应用开发（FDE） 工具：WorkBuddy · 专家「技能匠人」+ Skill「skill-crafting」· Python 标准库（零第三方依赖） 制作：2026-09-27，一天完成并装机 成文：2026-10-25 话题：#WorkBuddy #Skill开发 #外贸装柜
先说结论
起点是一份 78 行的桌面文档《装柜计算.md》：柜型参数表、两种算法、四大修正因素、一个实例演算。文档是内行写的，点到了「切勿用理论容积算」这类关键坑，但它是说明书，每次报价业务还得拿计算器按一遍。
做成 Skill 的过程走完了五阶段：场景挖掘 → 双确认闸口 → 生成与静态预检 → 8 组实测 → 打包装机。三件事超出预期：
- 原文档那个 920 箱的答案，是六种摆放朝向里最差的一个。 同一组参数（40HQ / 50×40×30 / 15 kg），正立换朝向是 928 箱，允许侧放 1015 箱，组合摆法上限 1073 箱——最大差距 9.3%，按单柜运费摊算就是真金白银。
- 实测抓出 3 个脚本自己写的 bug，其中「堆码层数上限能被绕过」这种错，输出看起来完全正常，数字悄悄超了 33%，不跑一遍永远发现不了。
- 原文有一处数据在几何上对不上（20GP 装美标托盘的数量），Skill 没有照抄，而是标注了差异来源。工具能指出原始文档哪里不对，才有存在价值。
一、为什么是这份文档
判断一份材料值不值得做成 Skill，标准有三条：高频重复（每月五次以上）、有明确对错（做错有实际代价）、有内行坑（外行照字面做会踩雷）。
装柜计算三条全中：报价、订舱、试单、排产都要算柜；算错的代价是现场爆仓、超重甩柜，一次几千块运费；而「门边余量」「胀箱余量」这类坑，外行根本看不见。
二、制作：不靠模型自由发挥
用的专家与 Skill
专家是「技能匠人」（skill-smith），预载 Skill skill-crafting：8 份规范（制作标准、五阶段审查、依赖配置、触发词挖掘、安全执行规范）+ 一个 1200 行的确定性脚本 skill_ops.py（生成、校验、静态预检、打包、备份、安装）。
关键设计：全程不靠自由发挥。 目录生成、校验、打包、安装全部走确定性脚本，参数里必须显式带 --requirements-confirmed 和 --write-confirmed 才会落盘。想跳过确认直接写文件，脚本拒绝执行。
没有配 MCP、没有连接器、不联网、没有 prompt 工程，产出只用 Python 标准库——复用成本几乎为零。
第一道闸口：场景挖掘补了 3 处信息增量
我的原话只有一句「把桌面这份装柜计算.md 做成 WorkBuddy 可安装的 skill」。开工前它先回答了三个问题：值不值得做成 Skill、文档里哪些是内行坑、哪里能补增量。补出来的三处，是后来 Skill 比原文值钱的地方：
| 补充点 | 为什么重要 |
|---|---|
| 柜门尺寸与门边余量 | 40HQ 门高比内部矮 11 cm，堆到顶的箱子可能卡在门口进不去 |
| 40 尺柜并排摆托盘放不下 | 内宽 235 cm，两个 1.2 m 美标托盘并排要 240 cm，差 5 cm——「理论 22 托、现场 20 托」的真实原因 |
| 泡货/重货判定公式 | 有阈值才能一眼看出这票货卡体积还是卡重量 |
第二道闸口：需求确认 + 写入计划
需求确认卡两个问题：算到多深（选了「精算 + 打托」）、结果什么形式（选了「方案报告 + 计算脚本」）。确认后才给写入计划：目标目录、文件清单、影响范围、回滚方式，二次确认才生成。
后面生成的是 7 个文件加一个 ZIP——如果第一步就闷头生成，方向偏了就是白干。
生成包结构（7 文件 / 28 KB）
container-load-calc/
├── SKILL.md # 适用判断 + 7 步流程 + 输出模板 + 停止条件
├── skill-dependencies.json # 运行时依赖 + 功能级降级矩阵
├── scripts/
│ ├── container_load.py # 核心计算（纯计算）
│ └── check_environment.py # 环境检查
└── references/
├── container-specs.md # 柜型参数、柜门净空、托盘规格
├── practice-rules.md # 胀箱、承压、熏蒸、10 条常见误算
└── setup-guide.md
一个刻意的设计决策：纯计算脚本
计算脚本做成只读命令行参数、结果打印到屏幕，不写文件、不联网、不调子进程。原因：这类 Skill 一旦要写文件，就得给一堆权限，将来谁都不敢装。SKILL.md 里对应写死了一条核心纪律：「所有排布取整、重量截断、托盘网格一律以脚本输出为准，不自行心算。」
静态预检：0 高危，但修了一个误判
生成完立刻做只读的脚本能力扫描：0 项高风险。顺手抓出一个扫描器误判——它把 Python 字符串方法 str.replace 认成了文件写入。这类噪音会让后来人不敢用这个包，把 str.replace 换成 re.split，预检就干净了。
三、实测：8 组输入，3 个真缺陷
技能匠人的规矩是「未实际执行的验证不得声明通过」。8 组测试覆盖：原文实例复现、朝向约束、打托与多柜、柜型切换、重货限重截断、堆码上限、3 类错误输入、JSON 输出模式。
跑出来的三个缺陷，每个都是典型：
缺陷一：堆码层数上限能被绕过。 传 --max-layers 6，算出 8 层。层数上限只约束了主体那块，顶部补装部分没受约束。输出完全正常，数字悄悄超 33%——不跑一遍绝对发现不了。
缺陷二：并列最高箱数时推荐了要侧放的朝向。 20GP 那组参数，正立摆和侧放摆都是 392 箱，脚本推荐了侧放。同样箱数没有理由增加码放风险，改成并列时优先正立。
缺陷三：体积利用率算出 103.8%。 「建议装载容积 66~68 CBM」这个经验值本身已含纸箱间隙，脚本算的箱规又加了胀箱余量——同一个间隙被扣了两次。改成说明两个口径的差异，而不是当超标告警。
修完重新校验（0 问题）、重新打包，先出安装预览（目标位置、覆盖对象、备份位置、回滚方式），确认后落盘用户级 Skill 目录，再从安装位置跑一次冒烟确认可用。
四、产出：不止「能用」
- 可安装的 Skill：装好后说人话就能用——「这批货 40HQ 能装多少箱？外箱 50×40×30，15 公斤一箱」「打托出运的话能装多少，美标托盘」「这个订单 5000 箱，需要几个柜」。
- 一个反常识的正确答案：原文 920 箱是六朝向最低档；正立换朝向 928、允许侧放 1015、组合摆法 1073，差距最大 9.3%。
- 一处对原文数据的修正：原文写「20GP 通常装 10~11 个美标托盘」，按内长 589 cm ÷ 120 cm 几何精算，规则网格 4 排共 8 个、尾段补 1 个共 9 个。处理方式是标注差异来源（托盘实际规格、是否允许超出边沿、现场错位手法），以现场试装为准。
- 一份按需命中的现场风险清单：输出带的是「本次实际命中的风险」，不是套话。重货测试组自动命中：「推荐朝向堆放高度 231 cm 超过柜门净高 228 cm，顶层箱过门时受挤压，须留出门口过渡层」——这正是人工做方案最容易漏的对比。
五、五条方法论
1. 别让大模型算算术，让它把算术写成脚本。 多步向下取整看起来简单，但模型是在生成下一个 token，不是在执行运算。模型知道自己会算错，所以把计算下沉成脚本；SKILL.md 再用一条纪律把「自行心算」这条路焊死。
2. 方向对了再写文件。 双确认闸口（需求确认 + 写入计划）是流程里最有价值的设计，7 个文件的方向成本远低于返工成本。
3. 「跑过了」和「没跑过」是两回事。 8 组实测抓出的 3 个缺陷，全部是「输出看起来正常」的类型：悄悄超限 33% 的堆码、无理由的侧放推荐、103.8% 的利用率。静态检查一个都抓不到。
4. 工具要能纠正素材，而不是复述素材。 原文档的 920 箱和「10~11 托」都是内行写的，照样有错。处理方式不是硬改，而是给出几何依据和差异来源，把判断权留给现场。
5. 预检噪音也要清。 str.replace 被误判成文件写入，看似小事，但一个带噪音的安全报告会让整个包的可信度打折。宁可改写代码迁就扫描器，也不留一份「看着吓人」的预检结果。
遗留项：触发测试在制作会话内无法独立复现宿主匹配，按「未实际执行不得声明通过」的规矩，安装后需在独立会话里验证「这批货 40HQ 能装多少箱」这类口语说法能否正常唤起。
在workbuddy里搜 “container-load-calc”，开始尽情使用吧
2026-09-27 制作完成，2026-10-25 成文。