让软件工程成为 AI Agent 可理解、可约束、可度量的一体化实践体系

第一章：问题与动机

1.1 AI Agent 的工程困境

当 AI Agent 进入软件项目时，它面对三重困境：

困境 表现 根因
不可读 Agent 不理解模块边界、职责约束、依赖方向，凭需求描述直接编码 项目规则散落在人脑、注释、口头约定中，没有 Agent 可消费的结构化表达
不可约束 Agent 违反边界、跨层污染、静默修改配置后无人阻止 项目没有可执行的硬性规则，所有约束都是软性的、事后才发现的
不可度量 Agent 完成任务后，无法判定"完成"的边界和"健康"的阈值 项目缺乏自动化的健康度量体系，依赖人工 review 发现问题

三重困境形成恶性循环：不可读 → 约束缺失 → 违规不可度量 → 度量结果无法反馈到文档 → 文档持续退化 → 更加不可读。

1.2 Harness Engineering 的回答

Harness Engineering 是一种将软件项目的工程规则结构化、可执行化、可度量化的方法论，使 AI Agent 成为受项目约束的工程决策者 + 实现者，而非不可控的代码生成器。

核心命题：

代码服从架构，架构服从路径文档，实现质量必须达到严格工程评审标准。

第二章：理论框架 — 三能力模型

2.1 三能力定义

Harness Engineering 建立在三个相互增强的能力之上：

能力 定义 关键问题
可读性 (Readability) AI Agent 能理解项目的规则、边界和约束 Agent 在编码前是否知道"这里不能改"、“这个模块只能做什么”？
防御性 (Defense) 项目的规则可以被强制执行，违规会被阻断 Agent 违反边界时，系统是否能自动阻止而非事后发现？
反馈性 (Feedback) 项目的健康状态可以被自动化度量 Agent 完成任务后，系统能否自动判定"完成度"和"健康度"？

2.2 能力增强环

三能力不是独立存在的，而是形成一个增强循环：

在这里插入图片描述

  • 可读性 → 防御性：只有规则被清晰表达（ai.json + AI.md），才能被转化为可执行的 Hard Gate
  • 防御性 → 反馈性：只有规则被 Gate 执行，才能产生 PASS/FAIL 的度量信号
  • 反馈性 → 可读性：Fitness 报告揭示哪些维度失败，驱动文档和规则的持续改进

缺失任何一个能力，循环断链：

  • 无可读性 → Gate 无内容可执行 → 反馈信号无意义
  • 无防御性 → 规则仅是建议 → 违规静默通过 → 反馈失真
  • 无反馈性 → 完成标准模糊 → Agent 不知道何时停止 → 文档无改进驱动力

2.3 能力缺失诊断

诊断信号 缺失能力 典型原因
Agent 反复违反同一边界规则 可读性 规则只写在人脑中，未结构化到 ai.json/AI.md
Agent 绕过约束后无人阻止 防御性 没有 Hard Gate 或 Gate 不是 blocking
Agent 不知道任务何时"完成" 反馈性 没有 fitness score 或 score threshold 未定义
Fitness 一直 FAIL 但无人修复 可读性 + 反馈性 FAIL 信号未转化为文档/规则改进动作
Agent 修改共享契约后下游崩溃 防御性 缺少依赖方向 purity Gate
多个 Agent 产出互相矛盾 反馈性 缺少四文档同步 Gate

第三章：文档架构 — 四文档同步协议

3.1 四文档体系

Harness Engineering 使用四种文档载体，覆盖不同受众和用途：

文档 受众 载体格式 内容职责 修改触发
AGENTS.md 人+AI Markdown 全局开发方法论、执行流程、编码原则、禁止事项、决策原则 方法论或全局规则变更时
AI.md 人 Markdown 模块定位、主要内容、可修改范围、禁止事项、依赖边界、验证建议 模块职责或边界变更时
ai.json 机 JSON (v2 schema) 机器规则权威源：inherits 链、global.must/forbid、fitness 维度、gates 定义、paths 约束、module_map 任何约束、维度或路径变更时
docs/fitness/*.md 双读 Markdown+YAML frontmatter 维度定义（frontmatter 供 fitness.py 解析）+ 人类可读的 metric 文档 维度或 metric 变更时

3.2 优先级链

当多层文档提供不同约束时，按以下优先级执行：

优先级规则的三条推论：

  1. 就近原则：模块级规则覆盖全局规则。模块 ai.json 中的 forbid 优先于根 ai.json 中的 allow
  2. 机器优先原则：同层级中，机器可读 (ai.json) 优先于人可读 (AI.md)。当 ai.json 和 AI.md 矛盾时，以 ai.json 为准，但必须立即修复 AI.md
  3. 全局兜底原则：AGENTS.md 只在没有任何更近层文档时生效。它是方法论入口，不是具体约束

3.3 四文档同步规则

强制规则：四种文档不得出现矛盾，修改一处必须同步其余。

具体同步矩阵：

修改了 必须同步检查
AGENTS.md 的开发流程/模块边界/禁止事项 → 根 AI.md + 根 ai.json
任意 AI.md 的职责/边界/验证 → 对应 ai.json + 根 ai.json
ai.json 的已有规则 → 对应 AGENTS.md/AI.md
ai.json 的 Fitness 维度或 Gates → docs/fitness/*.md frontmatter
docs/fitness/*.md frontmatter → ai.json fitness.dimensions

交付前检查：四种文档格式出现冲突时，不允许只改其中一处后结束任务，必须在交付前消除不一致。

3.4 Per-Module 文档继承

每个模块目录拥有自己的 ai.json 和 AI.md，通过 inherits 机制回溯根规则：

{
  "inherits": {"root_ai_json": "../../ai.json"},
  "paths": {
    ".": {
      "role": "模块职责描述",
      "allow": ["允许的修改范围"],
      "forbid": ["禁止的行为"],
      "deps": {"upstream": [], "downstream": []}
    }
  }
}

模块 AI.md 采用六节结构：

节 内容 必填性
模块定位 该模块在架构中的角色 必须
主要内容 关键包、目录、文件 必须
可修改范围 允许的修改类型 必须
禁止事项 绝不能做的事 必须
依赖边界 上游/下游/内部依赖 必须
验证建议 如何验证该模块变更 推荐

第四章：运营框架

4.1 强制开发流程

所有开发（包括 AI Agent）必须遵循五步流程：
在这里插入图片描述

步骤 动作 输入 输出
READ 读取目标路径的 ai.json + AI.md + 父级 ai.json + AGENTS.md 文档体系 约束集合
ANALYZE 识别模块边界、依赖方向、受影响的配置/SQL/模板/生成器 约束集合 + 现有代码 影响范围评估
PLAN 分类任务（新功能/行为修改/缺陷修复/重构/配置调整），回答四个决策问题 影响范围 设计方案
EXECUTE 最小必要修改，不夹带无关重构 设计方案 代码变更
REVIEW 检查边界完整性、重复能力、配置兼容性、文档同步、测试覆盖、Fitness 检查 代码变更 交付确认

四个决策问题（PLAN 步骤必须回答）：

  1. 方案是否符合当前模块边界？
  2. 是否已有可复用抽象？
  3. 是否会引入重复实现？
  4. 是否影响多个启动应用或共享契约？

跳过任何步骤视为错误行为。特别是：未经 READ+ANALYZE 直接编码，是 Harness Engineering 明确禁止的。

4.2 Hard Gate — 完成定义

Hard Gate 是 Harness Engineering 的核心约束机制：

定义：Hard Gate 是一个 Fitness Metric，其失败意味着真实运行时风险，必须阻断流程。

属性 值
失败行为 Agent 必须停止并报告，不允许继续
退出码 2 (阻断)
循环终止条件 all_gates_pass AND fitness_score >= 90%
合并前条件 所有 blocking Gate 必须通过

Hard Gate 选择原则：

原则 说明
真实风险原则 只有失败意味着真实运行时损害（编译失败、接口断链、安全漏洞）的 metric 才应设为 Hard Gate
少而精原则 不要把所有 metric 都设为 Hard Gate。过多的 Hard Gate 使系统过于刚性，Agent 频繁被阻断
分层防御原则 架构层 Gate（build_pass、dependency_purity）保护全局稳定性；业务层 Gate（enum_code_unique、contract_alignment）保护领域完整性

典型 Hard Gate 组合：

维度 Gate 保护对象
architecture build_pass 全仓库可编译
architecture agents_entry_exists 文档入口存在
architecture dependency_purity 核心层不反向依赖业务层
security no_dangerous_perm 无危险权限配置
code_quality mapper_alignment 持久层 Java/XML 一一对应
business_integrity enum_code_unique 业务枚举码值唯一

Non-Hard Gate metric 服务于质量预警：它们 FAIL 时发出警告但不阻断流程。

4.3 分层执行模型

Fitness Metric 按执行代价分三层：

层级 超时 触发时机 典型 Metric 类型
fast 60s 每次提交前 (pre-commit) 文件存在性检查、grep 模式、Python 脚本扫描
normal 300s 例行 CI Maven 编译、中等构建步骤
deep 600s 推送前 (pre-push) / 全量 CI 完整测试套件、依赖树分析

执行方式：

# 提交前快速检查
python3 docs/fitness/scripts/fitness.py --tier fast --source ai.json

# 推送前全量检查
python3 docs/fitness/scripts/fitness.py --source ai.json

# 仅列出 metric 不执行
python3 docs/fitness/scripts/fitness.py --source ai.json --dry-run

4.4 评分与退出码

评分公式：

维度得分 = (该维度通过的 metric 数 / 总 metric 数) × 100
最终得分 = Σ(维度得分 × 维度权重) / Σ(维度权重)

阈值体系：

得分范围 状态 退出码 行为
≥ 90% PASS 0 正常交付
80%-89% WARN 0 建议改进但不阻断
< 80% BLOCK 1 得分过低，需要修复
Hard Gate FAIL BLOCK 2 阻断，必须修复 Gate

维度权重必须总和为 100，反映项目对各维度的优先级判断。

第五章：Fitness 系统设计

5.1 维度设计

维度是 Fitness 系统的第一层组织单位。每个维度覆盖一个工程健康面。

推荐维度组合（权重总和 = 100）：

维度 典型权重 覆盖面 适用项目
architecture 25 模块边界、依赖方向、入口完整性 所有分层项目
testability 15 测试通过率、增量覆盖率、下游影响测试 有测试要求的项目
code_quality 15 编译通过、代码对齐、命名规范 所有项目
security 15 无危险权限、无硬编码密钥 所有项目
config_compat 10 配置文件完整性、命名约定 有配置管理的项目
business_integrity 20 领域特定的完整性（契约对齐、模板覆盖、枚举唯一） 有特定业务域的项目

维度设计决策：

  1. 不需要全部 6 个维度：简单项目可以只保留 3-4 个。纯文档项目可能只需要 docs_quality + entry_integrity
  2. 权重反映优先级：高风险维度给更高权重。业务域完整性通常比配置兼容性更重要
  3. 业务完整性维度是项目特定的：architecture/code_quality/security 的 metric 模式跨项目通用，但 business_integrity 的 metric 完全取决于业务域

5.2 Metric 设计

Metric 是维度的第二层，每个 Metric 是一个可执行的检查项。

Metric 定义字段：

字段 必填 说明
name 是 Metric 标识名
command 是 Shell 命令（fitness.py 通过 /bin/bash -lc 执行）
pattern 否 正则表达式，匹配 stdout+stderr 组合输出。为 null 时检查退出码 == 0
hard_gate 是 boolean，是否为 Hard Gate
tier 是 fast / normal / deep
description 是 一行说明

Metric 的两种实现方式：

方式一：Shell 命令（适合简单检查）

{
  "name": "common_biz_leakage",
  "command": "grep -rn '@Service\\|@Component' app/common/service/src/main/java/ || echo '0'",
  "pattern": "0",
  "hard_gate": false,
  "tier": "fast"
}

方式二：Python 脚本（适合复杂检查）

{
  "name": "mapper_resultmap_alignment",
  "command": "python3 docs/fitness/scripts/field_check.py mapper_resultmap_alignment 0",
  "pattern": "PASS",
  "hard_gate": false,
  "tier": "fast"
}

Python Fitness 脚本的 CLI 契约：

输入: python3 <script>.py <metric_name> [threshold]
输出(stdout): PASS <metric>=<value> <extras>
               FAIL <metric>=<value> (threshold=<threshold>) <extras> detail=...
输出(stderr): 逐项诊断详情
退出码: 0 = 通过阈值, 1 = 未通过阈值

5.3 可复用的 Metric 模式

以下模式跨项目可复用，只需填入项目特定的常量：

模式一：接口-实现对齐

要素 描述
问题 一层定义的接口在另一层必须有实现类。缺失实现 = 运行时找不到方法
步骤 扫描接口层 → 找实现声明 → 比对缺失 → 报告对齐数
需参数化 API_DIR, IMPL_DIRS, interface_pattern, impl_pattern
适用 Dubbo RPC、Spring Service、GraphQL resolver 等任何接口-实现分层架构

模式二：模板变量覆盖

要素 描述
问题 模板引用的变量必须由生成器/上下文提供。缺失提供 = 渲染空值/残缺输出
步骤 提取模板变量引用 → 提取上下文提供 keys → 排除本地变量 → 比对覆盖度
需参数化 TEMPLATE_DIR, GENERATOR_DIR, template_pairs, 引用语法正则, 上下文 put 正则, 工具变量集
适用 Velocity、Jinja2、Freemarker 等任何模板-生成器架构

模式三：持久映射对齐 (MyBatis)

要素 描述
问题 resultMap 属性必须与 Java 模型 DB 字段对应。缺失字段 = 静默丢数据
步骤 解析 XML resultMap → 解析 Java 模型字段+注解 → 解析继承链 → 排除非 DB 字段 → 比对缺失
需参数化 DAL_XML_DIR, MODEL_DIRS, BASEMODEL_FIELDS, 包名前缀, 注解正则
适用 MyBatis/MyBatis Plus 项目的 Mapper XML 对齐检查

模式四：增量测试覆盖

要素 描述
问题 变更的源文件应有对应测试覆盖。无覆盖 = 回归风险
步骤 git diff 变更文件 → 映射源文件到测试文件 → 扫描活跃测试注解 → 计算覆盖率
需参数化 base_ref, source_to_test_mapping, test_annotation, threshold
适用 所有有测试要求的项目

模式五：依赖影响靶向测试

要素 描述
问题 变更文件影响下游依赖模块，需靶向重测。遗漏 = 回归不发现
步骤 git diff → 模块映射 → 下游依赖图遍历 → 收集受影响模块 → 靶向执行测试
需参数化 DOWNSTREAM_GRAPH (pom.xml/package.json 分析结果), TESTABLE_MODULES, 测试命令模板
适用 所有有模块依赖图的项目

5.4 维度设计工作簿

为新项目设计维度时，回答以下问题：

问题 你的回答 对应维度
项目中前 3 个运行时风险是什么？ __________ → Hard Gate 候选
哪些模块边界绝不能被违反？ __________ → architecture
什么配置变更会破坏多个应用？ __________ → config_compat
什么领域特定完整性检查是必要的？ __________ → business_integrity
最低可接受的测试覆盖率是多少？ __________ → testability
项目中是否有接口-实现分层？ __________ → architecture 或 business_integrity
项目中是否有模板-生成器架构？ __________ → business_integrity
项目中是否有 ORM 映射层？ __________ → code_quality

根据回答调整维度权重和 Metric 选择。

第六章：接入路线图

6.1 成熟度模型

项目接入 Harness Engineering 分为三个成熟度级别：

级别 名称 标志 典型产出
L1 文档化 项目规则被结构化表达，Agent 可读 AGENTS.md + AI.md + ai.json 根级文件
L2 可约束 关键规则有 Hard Gate 执行，违规被阻断 fitness.py 运行器 + 至少 2 个维度 + Hard Gates
L3 可度量 所有工程健康面被 Fitness 维度覆盖，有持续反馈 6 维度完整 + 项目特定 Fitness 脚本 + CI 集成

每级必须满足的前置条件：

  • L1 → L2：ai.json 中 global.must 和 paths.forbid 已填充项目实际规则
  • L2 → L3：至少 2 个维度有 PASS 的 Metric，Hard Gate 组合覆盖编译+入口+安全

6.2 接入步骤

L1：文档化（约 1-2 小时）

# Step 1: 初始化
python3 harness-kit/harness-init.py --interactive

# Step 2: 填写根文档
# AGENTS.md: 第 2,3,7,8,9,10 节填入项目实际内容
# AI.md: 填写仓库定位、模块地图、跨模块边界
# CLAUDE.md: 填写项目概览、构建命令、模块架构

# Step 3: 填写 ai.json paths 和 module_map
# root paths "." 填入项目角色描述
# module_map 填入模块目录 -> ai.json 路径映射

L2：可约束（约 2-4 小时）

# Step 4: 为关键模块创建 ai.json + AI.md
# 每个重要模块目录: ai.json (inherits + paths) + AI.md (六节结构)

# Step 5: 定义 Hard Gates
# ai.json gates.items 中加入:
# - build_pass (blocking: true)
# - agents_entry_exists (blocking: true)
# - no_dangerous_perm (blocking: true)
# 其他根据项目风险选择

# Step 6: 验证
python3 docs/fitness/scripts/fitness.py --dry-run --source ai.json
python3 docs/fitness/scripts/fitness.py --tier fast --source ai.json --verbose

L3：可度量（持续迭代）

# Step 7: 完善所有维度
# 每个维度加入项目特定 Metric（shell 命令或 Python 脚本）
# 编写 business_integrity 维度的领域特定检查

# Step 8: 编写 Python Fitness 脚本
# 参照 SCRIPT-PATTERNS.md 中的模式
# 契约对齐、模板覆盖、字段对齐、增量覆盖、影响测试

# Step 9: CI 集成
# pre-commit: fitness.py --tier fast
# pre-push: fitness.py (full)
# CI pipeline: fitness.py --verbose

6.3 常见误区

误区 正确做法
把所有 Metric 都设为 Hard Gate 只选真实运行时风险的 Metric。Non-Hard Gate 预警但不阻断
维度权重随意分配 权重总和 = 100，高风险维度给更高权重
文档写完就不管了 四文档必须持续同步。每次边界变更都要同步检查
Fitness 跑出 FAIL 就调阈值让它 PASS FAIL 暴露真实问题。应修复问题，不应降低标准
只建根级文档不建模块级 模块级 ai.json/AI.md 提供就近约束，是优先级链的关键节点
用 ai.json 替代所有人类文档 ai.json 是机器权威源，但 AI.md 是人可读理解的关键。两者不能替代彼此

第七章：参考实现 — DroolsCMS

DroolsCMS 项目是 Harness Engineering 的参考实现，展示了方法论在真实项目中的完整落地。

7.1 项目概况

属性 值
技术栈 Java 8 + Maven 多模块 + Spring Boot + Dubbo RPC + Drools Engine + MyBatis Plus
模块数 24+ Maven 子模块
入口应用 4 个 Spring Boot 应用
Fitness 维度 6 维度、24 Metric
Hard Gate 7 个（build_pass, agents_entry_exists, core_no_biz_dep, impl_test_pass, no_dangerous_perm, mapper_xml_alignment, enum_code_unique, dubbo_interface_impl_alignment）
Fitness 脚本 5 个 Python 脚本（fitness.py, coverage.py, impact_test.py, contract_check.py, template_check.py, field_check.py）
模块级文档 27 个 per-module ai.json + 25+ per-module AI.md

7.2 方法论收益

Harness Engineering 在 DroolsCMS 中发现的真实 Bug：

Bug 发现方式 严重性
FundsTemplateRule 缺 4 个 BaseModel 字段 template_variable_coverage 高（渲染残缺 DRL）
borrower.drl.vm 复制粘贴变量名错误 template_variable_coverage 高（运行时取空值）
fundsRouteRule.drl.vm date-expires 用了 ${dateEffective} template_variable_coverage 中（语义混淆）
RuleGroupApplyHistory resultMap 缺 5 列 mapper_resultmap_alignment 高（静默丢数据）
PkgFlowConfig resultMap 缺 7 列 mapper_resultmap_alignment 高（静默丢数据）
40 个 resultMap 存在字段缺失 mapper_resultmap_alignment 系统性风险
86 个 Dubbo 接口全部有实现 dubbo_interface_impl_alignment 预防性（目前 0 gap，未来新增接口时 Gate 阻断缺失）

7.3 跨技术栈验证

子项目 技术栈 Fitness 维度 证明
strategy-admin Vue 2 + Node.js + npm build_pass, lint_pass, architecture, entry_integrity 框架结构 100% 可跨技术栈复用
examples/harness-engineering Markdown + markdownlint docs_quality, entry_integrity 框架可缩至最简项目

第八章：工具与 Kit

8.1 Harness Kit

harness-kit/ 目录提供一键接入工具：

# 自动检测项目类型并初始化
python3 harness-kit/harness-init.py --interactive

# 强制指定 profile
python3 harness-kit/harness-init.py --profile java-maven --project-name myproject

# 先预览再执行
python3 harness-kit/harness-init.py --dry-run --profile node-npm

支持的项目 Profile：

Profile 检测文件 构建命令 测试命令
java-maven pom.xml mvn clean install -DskipTests mvn test
node-npm package.json npm run build npm test
go-mod go.mod go build ./… go test ./…
python requirements.txt / setup.py / pyproject.toml pip install -e . pytest
docs-only (无) (无) markdownlint

Kit 目录结构：

harness-kit/
├── README.md                    # Kit 总览
├── harness-init.py              # 初始化 CLI
├── templates/                   # 模板文件
│   ├── root/                    # AGENTS.md, AI.md, CLAUDE.md, ai.json
│   ├── per-module/              # 模块级 ai.json, AI.md
│   ├── fitness/                 # fitness.py, requirements.txt, dimension.md, README.md
│   └── scripts/                 # 半通用脚本模板 + 模式文档
├── profiles/                    # 5 种项目类型预设
├── guide/                       # 方法论指南
└── schemas/                     # ai-rules-v2.schema.json

8.2 Fitness 运行器

fitness.py 是 Fitness 系统的通用执行引擎：

  • 从 ai.json 或 docs/fitness/*.md frontmatter 加载维度定义
  • 按 tier 超时执行 shell 命令
  • 正则匹配输出判断 PASS/FAIL
  • Hard Gate FAIL 触发退出码 2
  • 加权维度得分计算最终分数

参数化改进（vs DroolsCMS 原版）：

  • 项目名不再硬编码，通过 --project-name 参数或目录名推导
  • 输出格式纯文本（PASS/FAIL/WARN/BLOCK），无 emoji
  • tier 超时默认值可配置

附录 A：术语表

术语 英文 定义
Harness Engineering Harness Engineering 让软件项目对 AI Agent 可读、可约束、可度量的方法论体系
可读性 Readability AI Agent 能理解项目规则、边界和约束的能力
防御性 Defense 项目规则可被强制执行、违规可被自动阻断的能力
反馈性 Feedback 项目健康状态可被自动化度量、持续反馈的能力
三能力环 Capability Cycle 可读性→防御性→反馈性→可读性的增强循环
四文档同步 Four-Document Sync AGENTS.md、AI.md、ai.json、fitness/*.md 四种文档不得矛盾、修改一处必须同步其余
优先级链 Precedence Chain 最近 ai.json > 最近 AI.md > 父 ai.json > 根 ai.json > AGENTS.md
Hard Gate Hard Gate 失败必须阻断流程的 Fitness Metric，是完成定义(Definition of Done)
Fitness 维度 Fitness Dimension 覆盖一个工程健康面的 Metric 集合，有名称、权重、阈值
Fitness Metric Fitness Metric 一个可执行的检查项，有命令、模式、层级、Hard Gate 标记
路径文档驱动开发 Path Document-Driven Development 先读文档理解约束，再分析、规划、执行、审查的开发流程
Per-Module 继承 Per-Module Inheritance 模块级 ai.json 通过 inherits.root_ai_json 回溯根规则
增强循环 Enhancement Cycle 可读性→防御性→反馈性→可读性的自我增强循环
成熟度级别 Maturity Level L1 文档化、L2 可约束、L3 可度量，渐进接入

附录 B：退出码语义

退出码 含义 触发条件
0 全部通过 fitness_score >= 90% 且所有 Hard Gate PASS
1 得分不足 fitness_score < 80%
2 Hard Gate 失败 任何 Hard Gate FAIL

附录 C：文件职责矩阵

文件 何时创建 由谁维护 修改频率
AGENTS.md L1 初始化 架构负责人 低（方法论级变更）
AI.md (根级) L1 初始化 架构负责人 中（模块地图变更）
ai.json (根级) L1 初始化 架构负责人 + AI Agent 中（维度/Gate/规则变更）
CLAUDE.md L1 初始化 项目负责人 中（构建命令/模块架构变更）
AI.md (模块级) L2 模块化 模块负责人 低（职责/边界变更）
ai.json (模块级) L2 模块化 模块负责人 + AI Agent 低（模块规则变更）
fitness.py L2 可约束 平台团队 极低（引擎逻辑稳定）
docs/fitness/*.md L2 可约束 架构负责人 中（维度/Metric 变更）
Fitness Python 脚本 L3 可度量 业务/质量团队 中（新检查需求）
ai-rules-v2.schema.json Kit 内置 平台团队 极低（格式规范稳定）

代码服从架构。架构服从路径文档。实现质量必须达到严格工程评审标准。

本方法论由 DroolsCMS 项目实践提炼，经 24+ Maven 子模块、6 维度 24 Metric、7 Hard Gate、5 Python Fitness 脚本验证，并跨 Vue+Node.js 技术栈验证可移植性。

# 人工智能 # 大数据 # 算法
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

手机 deepseek 怎么导出？用 AI 导出鸭一键规整文档，轻松搞定各类内容导出难题

avatar AI Agent技术社区
cover

深度拆解 Headroom：AI Agent 的「上下文压缩层」，Token 暴降 60-95% 的背后原理

avatar AI Agent技术社区
cover

接手项目后，我对 Claude Code 说的第一句话（附 Prompt 模板）

avatar AI Agent技术社区