系列四意图路由、闸门与状态管理——让 AI 能自驱问题v1 为什么沦为补全工具回顾第一个版本的核心失败用户得自己决定该激活哪个 Skill、按什么顺序跑、什么时候该停。这本质上还是人在驱动AI 只是被动执行。要让 AI 真正参与进来它需要三个能力知道该做多少意图识别知道什么时候该停闸门知道上次做到哪状态管理意图路由让 AI 知道该做多少和怎么做用户说帮我看看这个指标AI 该做什么如果指标已经存在 → 告诉他在哪、怎么取如果指标还没有 → 需要从头建走全流程如果不确定 →问而不是猜这就是 skill-router 的第一层职责——意图分类从选哪个 Skill到怎么编排 Skill但 skill-router 的职责不止于分类——它还要规划执行路径。传统做法是让用户自己决定该激活哪个 Skill、按什么顺序跑。但真实场景下用户说帮我做一个良率指标他不想管流程——他只知道他要结果。skill-router 根据意图自动规划 Skill 执行链用户帮我做一个工单良率指标 │ ▼ 意图分类 → 完整需求新指标 │ ▼ 执行规划 ├─ Step 1: prd-collector → 明确口径、粒度、验收标准 ├─ Step 2:>闸门不是审批流是质量关卡PRD ──G0──▶ 探查 ──G1──▶ 设计 ──G2──▶ SQL ──G3──▶ 上线传统数据平台的审批流是上线前的最后一道关卡。问题是发现设计有问题时SQL 都写完了改起来成本巨大。Ware-Smith 的闸门分散在每个 Phase 之间越早的闸门越关键G0 错了后面全白做。每道闸门分两类检查否决项blocking不通过就回退任何使用方式都强制建议项advisory提示但不阻断只在完整流程下展示闸门强度自适应不是所有需求都需要最严格的闸门。骨架在 Phase 2 完成后自动判定复杂度条件闸门强度效果全部新建无风险minimal快捷路径批量确认一次通过含加字段低风险standard正常确认含改口径/改粒度/删字段strict逐一确认 安全评估强制简单的事快速通过危险的事严格把关。不一刀切。状态管理让 AI 能接着上次做数仓需求开发不是一次对话能做完的。一个中等复杂度的需求从 PRD 到上线可能跨 3-5 天。传统 AI 工具关掉对话就忘了。Ware-Smith每个项目都会记录当前进度下次打开激活 pipeline 说继续——AI 读状态知道Phase 3 做了一半第二张表还没设计完接着做。这个设计看起来简单但解决了一个 v1 的致命问题跨会话的连续性。不再需要每次都重新交代上下文。三者协同意图路由、闸门、状态管理不是独立的——它们形成一个闭环这个闭环让 AI 从被动补全变成了主动驱动它知道该做多少、知道什么时候该停、知道上次做到哪。用户从驾驶员变成了审批者——AI 执行人确认。