用户交付的端到端冒烟测试

把练习或工具交给用户前，先站在用户入口做一次端到端冒烟测试：确认工作目录、跑通 --help/--demo、打开唯一要填写的模板，再把说明压成“今天只做什么”。这是在 路径基准点先确认原则 和 前置产物消费的 schema 优先原则 之上的交付验收，能避免把 人情世故 这类可训练材料变成不可执行的说明书。

社交练习执行卡的最小闭环

把人情世故这类软技能从手册转成当天执行卡时，最小闭环不是“读完原则”，而是：选 1-2 条真实或纸面低风险消息 → 给每条标注场合公私、关系远近、对方成本/面子风险、单一目标 → 写出低摩擦最终版 → 晚上用固定 4 问复盘。交付前仍要按本原则打开执行卡与日志模板，并跑通卡片中唯一可选命令，确保用户不用回到长手册找路径。

请求型社交练习的最小闭环

把求助、引荐、托资源这类人情世故练习转成执行卡时，不要只给礼貌句子；先用低风险筛选把真实发送限定在“预计 ≤10 分钟、有备用路径、不涉及背书/金钱/隐私/升迁”的小请求，再强制写五格：背景 → 具体请求 → 截止/预计成本 → 退出口 → 感谢/回报。交付前的冒烟测试除了打开卡片和日志模板，还要跑通对应场景题（如 S01/S11），并检查卡片显式包含“是否发送”的风险分流，避免用户为了练习去制造高成本人情债。

多日软技能训练的收束闭环

把 7 天一类的人情世故练习收束到最后一天时，不要继续扩理论；应让用户复测一次、只摘前几天日志中的关键行、用简单评分选出 1 个下周最需改进且低风险可练的场景，再压成“3 次 × 每次 5 分钟”的最小持续计划。这样收束日的产物从“总结感想”变成可执行节奏：单一场景、明确禁忌、触发条件、纸面替代方案和晚上总复盘。

命令冒烟必须验证真实解释器

端到端冒烟测试不能只看文档里写了某条命令；必须在用户实际工作目录里运行同一条命令，并记录解释器/运行时差异。若环境中 python 指向 Python 2、python3 版本较旧，交付物要么显式写 python3，要么把脚本降到当前解释器可执行的语法；否则 --help 和 --demo 都可能在用户入口处失败。