约束满足引擎（CSE）
代码库里最危险的不是 bug，是没写进文件的规矩——"这个 map 的 key 不能重复"、"凡是改 schema 都要加迁移"、"HTTP handler 返回前必须记审计日志"。这些规矩活在人的脑子里，新人不知道，AI 更不知道。
CSE（Constraint Satisfaction Engine）把隐式规矩变成可机械验证的谓词。
工作原理
CSE 维护一组约束（Constraint），每条约束是一个可执行的断言：
约束: "所有 HTTP handler 返回前必须调用 auditLog()"
谓词: 对 handler 函数的 AST 检查 → 是否存在 auditLog 调用
当 Agent 修改代码时，CSE 自动检查被影响的约束是否仍然满足。违反时直接反馈到 Agent 上下文，而不是等人 review 时才发现。
约束类型
CSE 内置 13 种检查器（Checker），覆盖五个维度：
| 维度 | 优先级 | 典型约束 |
|---|---|---|
| 安全（security） | 最高 | 密钥不入代码、SQL 参数化、权限校验 |
| 数据（data） | 高 | Schema 变更配迁移、外键一致性 |
| 架构（architecture） | 中 | 层依赖方向、禁止循环引用 |
| 质量（quality） | 中 | 函数长度、圈复杂度、命名规范 |
| 一致性（consistency） | 标准 | 错误处理模式、日志格式、import 顺序 |
优先级决定冲突时的裁决顺序——安全约束不会被质量约束覆盖。
约束从哪来
三条注册路径，各有不同的生命周期：
1. 种子（Seed）
项目初始化时，CSE 扫描项目结构和配置文件，自动推断基础约束：
- 检测到
go.mod→ 注册 Go 编译约束 - 检测到
.eslintrc→ 注册对应的 lint 规则映射 - 检测到
AGENTS.md→ 提取其中的架构约束
2. 项目推断（CKG）
CKG 构建调用图后，CSE 从代码结构中发现模式：
- 所有
repository包的函数都接收context.Context参数 → 注册为架构约束 internal/目录的包不被cmd/之外的代码引用 → 注册为层依赖约束
3. 学习（L2.5）
当 QualityGate 检测到验证失败并被修复后，修复模式可被提炼为新约束：
- Agent 改了函数签名但忘了改调用者 → CSE 学到"签名变更必须级联"
- 删除了一个常量但有配置文件引用它 → CSE 学到"常量删除前检查配置引用"
学习到的约束带衰减机制：长期未被触发的约束会自动降级或归档，不会无限膨胀。
飞轮效应
CSE 不是静态的规则引擎，它是一个正反馈循环：
项目用得越久，约束越精确。新加入的开发者（或 AI Agent）不需要读完所有文档就能遵守团队的隐式规矩——CSE 会在他违反时立即告诉他。
与其他能力的关系
| 能力 | 与 CSE 的交互 |
|---|---|
| CKG | 提供调用图和依赖关系，CSE 基于此发现架构约束 |
| 渐进验证 | QualityGate 执行 CSE 注册的约束检查 |
| 上下文管理 | CSE 的违反信息作为 overlay 注入模型上下文 |
| 记忆 | Correction 类记忆可转化为 CSE 约束 |
当前状态
CSE 在 wescode 中已实装核心框架（Seed + CKG 推断路径）。L2.5 学习路径和完整的衰减机制为实验性功能，随产品迭代逐步增强。
下一步
- 渐进验证 — CSE 约束如何被验证执行
- 代码知识图谱（CKG） — 约束发现的基础设施
- 跨会话记忆 — Correction 与约束的转化