🧠 图解记忆： 企业工作流要把规则、技能、子任务和质量门禁分层固化，让 Agent 能力可复制、可治理。

💡 答案要点

背景（面试高频）：

面试官问"你怎么做 AI 编程"，只答"我用 Cursor/Trae/Claude Code"是明显不够的——要能讲出如何把团队规范固化成 AI 可执行的约束。

为什么需要规范（痛点）：

痛点	表现
分层混乱	AI 生成代码跨层调用（Handler 直接操作数据库）
质量不可控	缺测试、注释不规范、错误处理缺失
计划执行脱节	AI 直接写代码，没计划评审，方向错发现太晚
上下文污染	检索/分析任务挤占主对话窗口，降低注意力
规范不统一	不同开发者用 AI 产出代码风格不一致

四类能力（核心答案；具体文件名和触发方式以所用工具当前文档为准）：

能力	作用	适合承载的内容	注意点
Rules（规则）	提供持续适用的仓库约束	架构边界、测试命令、禁止事项	保持简短，避免互相冲突
Skills（技能）	封装可复用任务流程	发布检查、迁移、审计、特定领域步骤	按需加载并提供明确输入输出
Subtasks / Subagents	隔离可并行或高噪声工作	搜索、日志分析、独立审查、验证	必须有边界、预算和汇总格式
Hooks / CI 门禁	在生命周期节点机械执行约束	格式化、测试、安全扫描、策略检查	确定性规则应由代码执行，不只靠模型提醒

核心原则：让 AI 在正确的时机自动执行正确的流程，而不是依赖人每次提醒。

分层依赖校验（layer-check，面试加分）：

核心 DDD 分层：handler → service → repository / milvus

硬门禁（BLOCK）：
  handler 禁止依赖 repository/model/milvus（用 DTO 隔离）
  service 禁止依赖 handler/response/milvus（不感知 HTTP）
  repository 禁止反向依赖 service/handler
  milvus 禁止依赖 handler/service/repository

校验逻辑：读取 layer_rules.json → 提取 diff 的 import → 映射层级 → 检查依赖方向
判定：allowed → 通过 / forbidden_cross → BLOCK 必须修复 / 其他 → needs-review

完整工作流（面试可讲）：

1. 开发者口述需求
2. /gen-plan 技能生成标准化开发计划（分层落点/接口契约/测试要求/验收清单）
3. plan-review 子代理自动审核（技术可行性/风险识别/测试补全）
4. 人工评审确认
5. AI 按 rules 规则编写代码（自动生效）
6. /layer-check 校验分层（BLOCK 违规必须修复）
7. test-compliance 子代理检测（编译/测试/合规/自动修复）
8. 全部通过提交 MR

设计原则（加分点）：

1. 先约束核心层，基础设施宽松：DDD 核心分层用硬门禁，边缘层 needs-review 软提醒，不过度约束
2. 文档与配置一致：rules/*.md 描述的约束必须与 layer_rules.json 的校验规则一致
3. 子代理独立上下文：检索/分析任务不污染主对话，让 AI 专注核心任务
4. 技术债显式标注：新代码不延续违规模式，存量问题标注逐步改造

跨工具迁移原则： 先识别规则、按需流程、隔离任务和确定性门禁四种职责，再映射到目标工具当前支持的配置面；不要假设不同产品的目录、触发语义和权限模型完全相同。

面试话术：

"企业级 AI 编程不是'会用工具'，而是'把团队规范固化成 AI 可执行的约束'。我做的方案是四类配置：Rules 每次对话自动注入分层约束，Skills 提供标准化流程（gen-plan 生成计划、layer-check 校验分层），Subagents 用独立上下文做质量门禁（plan-review 审核计划、test-compliance 检查测试），Hooks 提交前提醒。核心是让 AI 在正确时机自动执行正确流程。分层校验用硬门禁：handler 禁止碰 DB、service 不感知 HTTP，违反直接 BLOCK。这套规范让 AI 产出代码从'能跑'变成'符合团队标准'。"

📚 参考：Anthropic 工程博客：Claude Code Best Practices（规则/技能/子任务固化）

---