约束满足引擎 (CSE)

CSE（Constraint Satisfaction Engine）是 wescode 的核心差异化能力之一，将项目中未写进文件的隐式规矩转化为可机械验证的约束。

问题：隐式规矩

每个项目都有大量"没人写下来但所有人都知道"的规矩：

"handler 不能直接操作数据库"
"所有公开 API 必须有认证中间件"
"测试文件不能 import internal 包"
"错误码必须在 errors/ 目录集中定义"

传统工具发现不了这些违规——代码能编译、测试能通过、但架构在腐化。

CSE 是什么

CSE 将隐式规矩转化为 Checker——每个 Checker 是一个可执行的谓词：

Checker: "handler 不直接 import database"

输入：文件 handler/user.go 的 import 列表
谓词：import 路径中不包含 "database/sql" 或 "gorm" 或 "sqlx"
输出：PASS / VIOLATION(位置, 原因)

Checker 类型

13 个标准 Checker

Checker检测目标
LayerViolation层间依赖方向
CircularDep循环依赖
NamingConvention命名约定
TestIsolation测试隔离性
ErrorHandling错误处理模式
ImportRestriction导入限制
InterfaceCompliance接口实现完整性
ConfigConsistency配置一致性
SecurityBoundary安全边界
ResourceLifecycle资源生命周期
ConcurrencyPattern并发模式
APIContractAPI 契约
MigrationSafety迁移安全性

四种推断路径

CSE 通过四种方式发现约束：

1. 代码模式推断

分析现有代码中的一致性模式：

发现：所有 handler/ 下的文件都不直接 import database 包
推断：这是一个架构约束
生成：LayerViolation Checker

2. 项目结构推断

从目录结构推断分层关系：

发现：handler/ → service/ → repository/ 三层结构
推断：依赖方向为 handler → service → repository
生成：LayerViolation Checker（禁止反向依赖）

3. 显式声明

从项目文档、AGENTS.md、注释中提取：

AGENTS.md 中写着：
"handler 不能直接操作数据库"

生成：ImportRestriction Checker

4. 用户反馈

从用户的代码审查反馈中学习：

用户拒绝了 AI 的修改："这里不应该直接调 DB"

学习：handler → database 是违规
更新：LayerViolation Checker

与 CKG 协作

CSE 依赖 CKG 提供代码结构数据：

CKG 提供：
  - 文件间的 import 关系
  - 函数调用图
  - 类型继承关系
  - 符号可见性

CSE 消费：
  - 验证 import 方向是否合规
  - 检查调用路径是否越层
  - 确认接口实现完整性

实际效果

编辑时检查

AI 修改代码时，CSE 自动检查约束：

AI 尝试在 handler/order.go 中直接写 SQL
  ↓
CSE LayerViolation 触发
  ↓
AI 自动改为通过 repository 层访问

审查辅助

代码审查时提供约束视角：

PR 中新增了 handler/ 直接 import "gorm"
  ↓
CSE 标记为 LayerViolation
  ↓
审查者可以据此要求修改

约束管理

查看约束

在 Chat 中："列出当前项目的约束规则"

AI 返回从 CSE 推断的约束清单

调整约束

"handler/ 下允许直接使用 redis"
→ AI 更新 ImportRestriction Checker 的白名单

约束存储

约束数据存储在 CKG 索引数据库中：

~/Library/Application Support/wescode/
  cells/ws-{hash}/
    index/        ← CKG + CSE 约束数据

与竞品对比

维度wescode CSECursor .cursorrulesClaude Code
约束来源代码模式推断 + 显式声明静态文件无
验证方式机械化谓词无验证无
学习能力从反馈中学习手动更新无
集成深度CKG + 编辑时提示词注入无

注意事项