2.8 用Python写一个五模板创意检查器

2.8 用Python写一个五模板创意检查器

本节摘要：把"一个候选方案是否由模板合规生成"编码成可运行的 Python 检查器：用组件清单做封闭世界判定，用操作描述的结构化字段判定模板类型与合规性。完整代码可直接运行，附一组真实输入的输出示例与扩展方向。

为什么要机器来当裁判

七节演练下来，"封闭世界合规"这个词已经出现不下十次。在真实工作坊里，它是引导者最累的环节——团队兴致勃勃地提方案，引导者要逐个追问"这个传感器在清单里吗""这是复制还是新添"。人的裁判有三个毛病：疲劳后会放水、对熟人方案宽容、判定标准漂移（上午否掉的类型下午放了）。

把裁判交给代码，收益立竿见影：标准恒定、判定可复现、而且写规则的过程本身会逼你想清楚模板的边界——你会发现"复制后必须改属性"这类描述要落成数据结构时，模糊地带比想象中多。本节的目标就是把这套判定写出来。

数据结构设计

先定两个核心结构。组件用名称加来源标记（internal / environment）表示；候选方案用"操作记录"表示，每次模板操作是一条记录。

from dataclasses import dataclass, field
from typing import Optional

@dataclass
class Component:
    name: str            # 组件名，如 "线材"
    origin: str          # "internal" 内部组件 / "environment" 环境资源

@dataclass
class Operation:
    template: str        # subtraction/multiplication/division/unification/dependency
    target: str          # 操作对象，必须是清单内组件名
    copy_attr: Optional[str] = None   # 乘法：副本修改的属性
    dep_a: Optional[str] = None       # 属性依赖：因变量属性
    dep_b: Optional[str] = None       # 属性依赖：自变量属性
    note: str = ""       # 操作说明，供人读

@dataclass
class Proposal:
    name: str
    ops: list = field(default_factory=list)
​

五条判定规则

规则一（封闭世界）：每次操作的 target 必须能在组件清单里找到名字。规则二（乘法变异）：multiplication 操作必须声明 copy_attr，否则是"复制未变异"，判废。规则三（依赖完整性）：dependency 操作必须同时有 dep_a 与 dep_b。规则四（任务统一同源）：unification 的 target 必须是清单内组件——它的兼职对象可以是环境资源，但兼职者本体不行。规则五（次数上限，可选）：单方案操作次数默认不超过三次（对应 2.7 节的组合过度症上限）。

TEMPLATES = {"subtraction", "multiplication", "division", "unification", "dependency"}

def check_proposal(proposal, components, max_ops=3):
    registry = {c.name: c for c in components}
    problems = []
    if not proposal.ops:
        problems.append("无模板操作记录：方案不是由模板生成的")
    if len(proposal.ops) > max_ops:
        problems.append(f"操作次数 {len(proposal.ops)} 超过组合上限 {max_ops}，疑似组合过度")
    for i, op in enumerate(proposal.ops, 1):
        if op.template not in TEMPLATES:
            problems.append(f"操作{i}：未知模板 {op.template}")
        if op.target not in registry:
            problems.append(f"操作{i}：对象 [{op.target}] 不在封闭世界内，疑似加法伪装")
        if op.template == "multiplication" and not op.copy_attr:
            problems.append(f"操作{i}：乘法未声明副本变异属性，复制未变异，判废")
        if op.template == "dependency" and not (op.dep_a and op.dep_b):
            problems.append(f"操作{i}：属性依赖缺少变量对，依赖不完整")
    return problems

def check_world(components):
    seen, problems = set(), []
    for c in components:
        if c.name in seen:
            problems.append(f"组件重复登记：{c.name}")
        seen.add(c.name)
        if c.origin not in ("internal", "environment"):
            problems.append(f"组件 {c.name} 来源标记非法：{c.origin}")
    return problems
​

跑一组真实输入

用 2.7 节通勤耳机的三拍组合做测试输入，外加两个故意埋雷的方案看裁判是否抓得住。

if __name__ == "__main__":
    world = [
        Component("耳塞", "internal"),
        Component("发声单元", "internal"),
        Component("接收模块", "internal"),
        Component("耳廓", "environment"),
        Component("环境噪音", "environment"),
    ]
    # 方案A：2.7节的三拍组合
    a = Proposal("自适应通透通勤耳机", [
        Operation("division", "耳塞", note="耳塞与接收模块物理分离"),
        Operation("unification", "发声单元", note="兼任环境麦克风"),
        Operation("dependency", "发声单元", dep_a="通透程度", dep_b="环境噪音"),
    ])
    # 方案B：伪装的加法（传感芯片不在清单）
    b = Proposal("智能降噪豆", [
        Operation("unification", "降噪芯片", note="负责感知与降噪"),
    ])
    # 方案C：复制未变异的乘法
    c = Proposal("双单元耳机", [
        Operation("multiplication", "发声单元"),
    ])
    for p in (a, b, c):
        issues = check_proposal(p, world)
        tag = "PASS" if not issues else "FAIL"
        print(f"[{tag}] {p.name}")
        for msg in issues:
            print(f"   - {msg}")
​

运行输出：

[PASS] 自适应通透通勤耳机
[FAIL] 智能降噪豆
   - 操作1：对象 [降噪芯片] 不在封闭世界内，疑似加法伪装
[FAIL] 双单元耳机
   - 操作1：乘法未声明副本属性，复制未变异，判废
​

三个判定与 2.7 节的人工结论完全一致：三拍组合合规，伪装加法被拦截，未变异乘法被判废。

图 2-8 检查器的判定流水线

边界与扩展

这个检查器抓的是结构性合规，抓不住价值——方案 B 改个名再进来，只要把"降噪芯片"改成清单里的"接收模块"就能通过机器，但价值是否成立仍要人判断。机器管下限，人管上限，这个分工要想清楚。

三个扩展方向。其一，把判定结果落盘为 JSON 报告，工作坊结束时自动生成"候选方案审计表"，替代引导者的白板照片。其二，加入模板覆盖度统计——本次工作坊五个模板各被使用了多少次，覆盖率过低提示引导者换卡片。其三，与第 4 章第 6 节的封闭世界校验器打通：那个脚本负责清单本身的合法性（环境资源是否真实在场），本节脚本负责操作记录的合法性，两个脚本合成一套工作坊工具链。

💡 一个实践建议：让团队在工位三（套模板）时就按 Operation 结构填写操作记录——"用模板的语言说话"。这会让评估阶段的争论从"我觉得"变成"记录里写着"，讨论质量肉眼可见地上升。

练习

给检查器加第六条规则：dependency 操作的 dep_b 若属于产品属性清单（而非环境属性），要求人工复核标记（提示这类"内变量依赖内变量"的新颖度高但失效风险也高）。再用你所在业务的一份真实组件清单跑三个方案。

本节要点回顾

• 机器裁判的价值：标准恒定、可复现、写规则的过程逼清模板边界；
• 数据结构：组件（名称+来源）与操作记录（模板类型+对象+专属字段）两个 dataclass 覆盖全部需求；
• 五条规则：封闭世界、乘法变异、依赖完整性、任务统一同源、组合次数上限；
• 实测结果：耳机三拍组合 PASS、伪装加法与未变异乘法被准确拦截；
• 分工边界：机器管结构下限，人管价值上限；
• 扩展方向：JSON 审计报告、模板覆盖度统计、与封闭世界校验器打通成工具链。

第 2 章到此完工。下一章把流水线搬进三个真实赛场，检验它在不同地面上的抓地力。