企业官网建设流程全解析

• CLI
• 开发工具
• AI Agent
• 人工智能
• 包管理器

在 x-cmd 的 skill0 技能体系中，score（加权维度评分）与rule（规则合规检查）是两套互补的评估框架，分别解决"找出问题、守住质量底线"与"评估优劣、选出最佳方案"两类截然不同的任务。本文以 rule-vs-score.md 为核心脉络，结合 compute.py 的实现细节与仓库内真实模板/规则预设，系统讲解二者的本质差异、底层计算原理、典型应用场景与组合使用策略，帮助你为手头的问题选对框架、用对命令。

一图看懂：Rule 与 Score 的本质区别

一句话概括：Rule 管"能不能用"，Score 管"哪个更好"。两者在 skill0 中分别由 score/SKILL.md（加权维度评分框架，口号 "Don't guess. Score."）与 rule/SKILL.md（规则合规检查）承载，并在文档层面互为 companion（伴侣）——score 的 SKILL.md 将 rule 列为 related，rule 的 SKILL.md 同样回链 score。

Score 如何工作：因子加权，自动归一化到 0–100

Score 框架的核心理念是"按维度打分、按因子加权、自动归一化"。其计算公式为：

total = Σ(factor × score) ÷ Σ(factor) × 10 → 0–100

• score（维度分）：每个维度给 0–10 分；
• factor（因子/权重）：整数 1–10，基线 = 2，用于表达该维度的重要程度；
• total（加权总分）：0–100，公式自动归一化，因子不需要加起来等于任何值。

因子是相对放大倍数：因子 8 的维度影响力是因子 2 的 4 倍。维度列头会直接标注权重占比（factor ÷ Σ(factor) × 100），让你一眼看清"哪一维度在主导总分"。

源码验证：compute.py 如何实现公式

这段逻辑在 compute.py 中有精确实现：

factor_sum = sum(factors) dim_pcts = [f / factor_sum * 100 for f in factors] # 维度权重占比 total = sum(f * s for f, s in zip(factors, scores)) / factor_sum * 10 dim_headers = [f"{name} ({pct:.0f}%)" for name, pct in zip(dim_names, dim_pcts)]

其中关键行为包括：

• 校验先行：标准文件（score.yml）必须含维度，TSV 首列必须是target，每个维度列都必须存在于 TSV 中（compute.py）；
• 目标唯一性：TSV 中target不允许重复或为空，重复即报错退出（compute.py）；
• 输出列结构：固定列target, total, rank, block, reason+ 带权重标注的维度列 +evidence等尾随列（compute.py）；
• block 硬过滤：block列非空的行被判定为"淘汰"，强制沉底、rank 显示X（compute.py）。

分数刻度：0–10 怎么给

score/SKILL.md 给出了明确的评分锚点：

配套的评分铁律（SKILL.md）：① 每个分数必须有 evidence 证据锚定（事实而非感觉）；② 用满全范围——5 是中间点而非默认分，0 和 10 少见但可以给；③ 因子是相对放大器，自动归一化；④ 目标唯一且非空；⑤ Agent 读结果、汇报、决策——排名是对话的开始而非结束。

Rule 如何工作：逐条计数，无加权、无聚合

与 Score 的"聚合求总分"不同，Rule 按规则逐条计数：

• 一个对象被 N 条规则检查 → 产生N 个相互独立的结果；
• 每条规则各自给出 0–100 分：100 = 通过，低于 100 = 违规；
• 结果不做平均——10 条规则中失败 3 条，就是 3 个需要修复的问题。

pass_count = number of rules with score = 100 fail_count = number of rules with score < 100

规则文件的"硬过滤"语义由level字段承担：rule 预设 中明确 error/must 级规则阻断 CI，warn/info 仅作建议。例如 ssh/config.rule.yml 中：

ssh-root-login: name: SSH Root Login apply: "sshd_config" level: error # error = 必须通过，否则视为违规 desc: - Root login via SSH should be disabled or set to prohibit-password. tldr: - wrong: "PermitRootLogin yes" right: "PermitRootLogin no or prohibit-password"

每个规则文件还支持testcase字段（如 ror.rule.yml 中的x rule lint用例），用于对规则本身做可判定测试，这与文档中"Violations are actionable——你知道确切要修什么"的特质一脉相承。

典型场景：问题导向 vs 择优导向

Rule 场景 —— "这里有没有问题？"

这类场景的回答永远是二元的："是（score < 100，这里是违规点）"或"否（score = 100）"。仓库里的真实案例有 os/general.rule.yml（磁盘使用率 >90% 告警、僵尸进程检查）与 ror.rule.yml（对 .rule.yml 自身做 lint 的元规则）。

Score 场景 —— "我应该选哪个？"

这类场景的回答永远是带分数的排名列表——且用户可能不同意，进而调整因子重新计算。以 tech-stack.score.yml 为例，它定义了 project-fit（factor 8）、team-capability（6）、ecosystem-maturity（6）、performance-scale（4）、maintenance（6）、integration-cost（4）六个维度，每个维度都附有 0–10 的锚点描述，Agent 可直接照此打分。

组合场景 —— 先 Rule 后 Score

有些决策需要两阶段流水线：

1. Rule 淘汰不可行候选（"这株植物有毒 → 出局"）；
2. Score 给幸存者排名（"在安全植物里，哪个最好养、最好看？"）。

更多例子：

• 求职：Rule 过滤掉不提供签证担保的公司 → Score 按薪资、成长、文化给 offer 排名；
• 租房：Rule 过滤掉超预算/禁宠物的楼 → Score 按通勤、空间、街区排名；
• 选库：Rule 过滤掉不再维护的库 → Score 按 API 设计、性能、社区排名。

但边界是软的：本质是意图，不是对象数量

• 一条 Rule 可以检查多个文件；一个 Score 也可以只评估单个候选；
• 区分二者的关键是intent（意图），而非对象数量；
• 问题是"通过了吗？" → 用 Rule；
• 问题是"和别的比，它有多好？" → 用 Score。

score-template-writer.md 对这条"软边界"给出了更细的判定准则：二元的门禁（deal-breaker）用 block 硬过滤，程度性的偏好（preference）用低分维度——"这株植物对猫有毒" → 用 block（二元门禁，不是偏好）；"这株植物难养" → 在养护难度维度上给低分（程度问题，不是一票否决）。

何时用哪个：一套可复用的选择标准

用 Rule 当：

• 有明确的通过/不通过标准（字段必须存在、值必须在范围内）；
• 要在整个代码库强制统一标准；
• 违规项可操作——你知道确切该修什么；
• 例："每个 .rule.yml 都必须有desc字段"。

用 Score 当：

• 在多个选项间比较、需要一个决策；
• 标准是偏好而非绝对（需要权衡取舍）；
• 答案取决于用户的优先级（因子可调）；
• 例："这个项目该用哪个框架？"。

两者都用当：

• 先用 Rule 过滤掉不可行候选（硬门禁）；
• 再用 Score 给幸存者排名（加权比较）；
• 例：Rule 拦截有毒植物 → Score 按养护难度与观赏性给安全植物排名。

落地实操：两文件模型与核心流程

两文件模型

• *.score.yml—— 可复用的评分标准：维度（dimensions）、因子（factors）、描述（desc）；
• **.score.tsv—— 目标 + 各维度分数 + 证据；第一列 = 目标名。

命令入口：x score compute <yml> <tsv>与python compute.py等价（见 SKILL.cn.md）。

核心流程

① 了解需求 → ② 定义 score.yml → ③ 打分 score.tsv → ④ x score compute → ⑤ 汇报与迭代

score/SKILL.md 强调三条方法论：先问够再定标准（维度错了，分数再精确也没用）；先草稿再迭代（需求不清时先打一版给用户看，用户对具体排名的反应——"这个因子该调高""你漏了 X"——就是最好的信号）；Agent 是分析师（compute 后要解释为什么 A 赢了 B、指出意外、建议调整）。

模板库：开箱即用的决策标准

仓库 score/template 目录下内置 35+ 个评分模板，涵盖技术选型、求职、购房、租车、养宠、送礼、旅行、命名等场景，x score ls可列出、x score init -t <name>可复制。模板遵循<category>-<topic>.score.yml命名规范（score-template-writer.md），首行注释被x score ls解析为 desc 列。以 job.score.yml 为例，它预留了block列用法说明（"visa not sponsored" 或 "non-negotiable red flag"），并在维度注释中提示"AI 替代风险"等可调因子——模板不是死标准，而是引导 Agent 适配用户需求的起点。

一个可复现的最小示例

参考 EXAMPLE.md 的 feature-priority 案例：

feature-priority.score.yml：

title: "Feature Priority" dimensions: - name: D1 label: "User Impact" factor: 3 desc: "Users affected and request frequency. Higher is better." - name: D2 label: "Dev Cost" factor: 2 desc: "Engineering effort. Lower cost = higher score."

score.tsv（AI 打分后、compute 前）：

target D1 D1_evidence D2 D2_evidence share-feature 8 Covers 60% of active users 6 Estimated 4 person-weeks dark-mode 5 Covers 30% of active users 8 Estimated 2 person-weeks

运行python compute.py feature-priority.score.yml score.tsv后得到：

target total rank D1 D1_evidence D2 D2_evidence share-feature 7.20 1 8 Covers 60% of active users 6 Estimated 4 person-weeks dark-mode 6.20 2 5 Covers 30% of active users 8 Estimated 2 person-weeks

总结

Rule 与 Score 并非竞争关系，而是同一决策问题的两个阶段：Rule 用硬门禁守住底线、产出可执行的修复清单；Score 用因子加权在幸存者中排出名次、产出可解释的决策依据。在 x-cmd skill0 中，你可以通过 rule 预设 快速落地合规检查，通过 score 模板库 一键初始化评分标准，再配合x score compute/x rule命令形成"先过滤、再排序、后决策"的完整工作流。相关的延伸阅读包括 score/SKILL.md、rule/SKILL.md、EXAMPLE.md 与 score-template-writer.md。

• CLI
• 开发工具
• AI Agent
• 人工智能
• 包管理器