AI Native 系统构建 Skill

使用场景

• 试验展开已验证能力成立，需要转为可维护、可交付、可治理的产品系统
• 需要设计 AI Native 产品架构，而不是简单把模型 API 接入旧系统
• 需要判断实验代码中哪些可以继承，哪些必须重写

执行步骤

1. 实验证据输入：从试验展开阶段继承能力边界、产品形态建议、资料缺口、风险边界和失败案例。
2. 系统边界定义：定义能力范围、用户角色、权限分层，回答"这项能力如何被稳定调用"。
3. 能力模块设计：按 Agent → Skill → Tool → Model → Data 的分层结构设计 AI Native 架构。
4. 失败处理策略：为每种失败场景定义触发条件、处理策略和人工接管规则。
5. 治理与观测补齐：设计可观测性、可审计性、可回退性、可更新性四个治理维度。
6. 输出系统构建方案：整合系统边界、能力模块图、失败处理策略和治理方案，定义进入审计放行的条件。

核心概念

• 系统构建（Building）：把已验证能力改写为可维护、可治理、可观测系统的阶段
• 能力系统：由智能体、技能单元、工具、模型、数据、记忆系统、上下文等共同组成的产品能力底座
• 实验代码：用于快速验证假设的短周期代码
• 产品代码：用于长期承载能力、支持治理和迭代的系统代码

系统构建流程

实验证据输入
  → 系统边界定义
    → 能力模块设计
      → 治理与观测补齐
        → 进入审计放行

第一步：实验证据输入

从试验展开阶段继承：

• 能力边界：哪些场景能稳定成立
• 产品形态建议：问答、Copilot、工作流、智能体
• 资料缺口：已解决和未解决的
• 风险边界：必须人工接管的动作
• 失败案例：已沉淀的失败模式和人工修正

第二步：系统边界定义

系统构建不是补工程细节，而是重写系统形态。需要回答：

• 这项能力如何被稳定调用
• 它如何与产品交互、工作流、知识系统和权限体系协同
• 它在失败时如何退回、解释、降级或交还给人
• 它如何被监控、被审计、被持续优化

第三步：能力模块设计

AI Native 架构的核心结构

User
  → Agent
    → Skill
      → Tool
        → System
          → Model
            → Data

这是一个多层能力系统：

• 智能体（Agent）：负责理解目标与编排任务
• 技能单元（Skill）：封装可复用能力
• 工具（Tool）：连接外部系统
• 模型（Model）：提供推理能力
• 数据（Data）：提供知识与记忆基础

传统架构 vs AI Native 架构

维度	传统软件架构	AI Native 架构
稳定中心	功能执行链	能力执行链
抽象单元	模块/接口	智能体/技能/工具
输入组织	数据库/表单	上下文/记忆/知识
失败处理	异常捕获	回退/降级/人工接管
治理重心	权限/审计	边界/观测/放行

第四步：治理与观测补齐

系统构建的目标不是尽快交付一个可演示版本，而是形成一个可被审计、可被维护、可被持续优化的系统结构。

必须补齐的治理能力

• 可观测性：系统如何被监控，关键指标是什么
• 可审计性：如何追溯输入、上下文、模型版本、工具调用、人工接管、最终结果
• 可回退性：失败时如何降级、回滚、交还给人
• 可更新性：模型、提示词、知识、工具如何独立更新

实验代码 → 产品代码的转换原则

1. 实验代码证明的是"能力在某些条件下可以成立"
2. 产品代码要解决的是"能力如何被稳定调用、失败时如何处理、如何被治理"
3. 很多团队失败不是因为模型不行，而是因为没有完成这次系统形态转换

输出物：系统构建方案

1. 系统边界：能力范围、用户角色、权限分层
2. 能力模块图：Agent → Skill → Tool 的层级结构
3. 失败处理策略：回退、降级、人工接管的触发条件
4. 治理与观测方案：监控指标、审计记录、异常处理
5. 进入审计放行的条件：什么条件满足后可以进入审计放行

使用方式

当用户提供实验结论报告时，自动执行：

1. 检查实验证据是否充分
2. 定义系统边界（能力范围、用户角色、权限）
3. 设计能力模块图（Agent/Skill/Tool 分层）
4. 设计失败处理策略
5. 补齐治理与观测方案
6. 输出系统构建方案

示例

示例：AI 客服系统从实验到产品

场景描述： 基于已完成的实验结论，将 AI 客服原型系统转化为可维护、可治理的生产系统。

用户输入： 实验结论报告：AI 客服 Copilot 能力验证

Skill 执行流程：

1. 实验证据输入

从实验阶段继承的证据:
  
能力边界:
  - 订单查询: 92%准确率 ✅
  - 物流解释: 85%准确率 ✅
  - 售后政策: 78%准确率 ⚠️（需改进）
  - 投诉处理: 不适合AI ❌
  
产品形态建议:
  - 类型: Copilot（人工确认模式）
  - 界面: 侧边栏候选回复
  - 关键交互: 一键采纳、快速编辑
  
资料缺口:
  - 需补充200条售后政策边界案例
  - 需建立敏感承诺规则库
  
风险边界:
  - 退款、赔付相关: 必须人工确认
  - 价格相关: 必须引用最新数据源
  - 情感升级: 自动转人工

2. 系统边界定义

维度	实验阶段	系统构建后
用户范围	内部测试客服	全部一线客服
能力范围	订单+物流	订单+物流+售后（80%+准确率）
权限分层	单一角色	专员/主管/管理员
可用时间	工作日白天	7x24小时
失败处理	直接报错	优雅降级+人工接管

3. 能力模块设计

# AI Native 架构：AI 客服 Copilot

系统边界:
  
  用户层:
    - 客服专员（主要用户）
    - 客服主管（审核/管理）
    - 系统管理员（配置/监控）
    
  产品层:
    - 客服工作台界面
    - 浏览器插件 / Web端
    
  能力系统层:
    
    Agent层（CustomerServiceAgent）:
      - 目标理解: 识别用户意图、情绪
      - 任务规划: 选择Skill、编排执行顺序
      - 结果组织: 组装回复、标记风险
      
    Skill层:
      - UnderstandIntent: 意图识别（92%准确率）
      - QueryOrder: 订单查询
      - TrackLogistics: 物流追踪
      - GenerateResponse: 回复生成
      - CheckRisk: 风险检测
      
    Tool层:
      - OrderSystem.query: 订单系统查询
      - LogisticsAPI.track: 物流API
      - KnowledgeBase.search: 知识库检索
      - CRM.getUserProfile: 用户画像
      
    Model层:
      - GPT-4o: 主推理模型（意图理解+回复生成）
      - text-embedding-3: 向量化（知识检索）
      
    Data层:
      - 知识库: 政策文档、FAQ
      - 案例库: 成功案例、失败案例
      - 记忆系统: 用户偏好、会话状态
      
  治理层:
    - 可观测性: 指标监控、日志审计
    - 权限控制: RBAC
    - 失败处理: 降级+人工接管

4. 失败处理策略

失败场景	触发条件	处理策略	人工接管
意图识别失败	置信度<70%	提示"请重述问题"	连续2次 → 人工
订单查询失败	API超时	提供自助查询链接	用户要求 → 人工
高风险内容	涉及赔付	只生成候选，不发送	必须人工确认
模型服务异常	API不可用	关闭AI建议，纯人工	自动
多轮对话失控	超过10轮	建议转人工	自动转人工

5. 治理与观测方案

可观测性:
  
  监控指标:
    - 采纳率: >60%
    - 修改率: <40%
    - 响应延迟: P95<2s
    - 服务可用性: 99.9%
    
  审计日志:
    - 每次请求: 输入摘要、模型版本、上下文
    - 每次输出: 建议内容、置信度、风险标记
    - 每次人工操作: 采纳/修改/拒绝 + 原因
    
可回退性:
  - 功能开关: 可关闭AI建议（5分钟内）
  - 模型降级: 主模型异常时切换备用模型
  - 人工接管: 指定场景自动转人工
  
可更新性:
  - 模型: 支持A/B测试切换
  - 提示词: 独立配置，热更新
  - 知识库: 增量更新，无需重启
  - 规则: 实时生效

输出结果:

# 系统构建方案：AI 客服 Copilot

系统边界:
  用户: 300名一线客服 + 30名主管
  场景: 订单查询(92%)、物流解释(85%)、售后咨询(78%)
  边界: 投诉处理、高风险承诺不在范围内

能力模块:
  
  Agent层:
    - CustomerServiceAgent
    - 负责任务编排、边界控制
    
  Skill层（6个）:
    - UnderstandIntent / QueryOrder / TrackLogistics
    - GenerateResponse / CheckRisk / SummarizeSession
    
  Tool层:
    - 订单系统、物流API、知识库、用户画像
    
  Model层:
    - GPT-4o（主）、Claude-3.5（备）
    
  Data层:
    - 知识库、案例库、记忆系统

失败处理:
  - 12种失败场景定义
  - 分级处理策略
  - 自动转人工机制
  
治理方案:
  - 7大类监控指标
  - 完整审计日志
  - 5分钟热回退能力
  
进入审计放行条件:
  ✅ 实验证据完整
  ✅ 系统边界清晰
  ✅ 失败处理策略完备
  ✅ 治理方案就绪
  ✅ 团队准备就绪（已培训）

---

示例 2：AIOps 故障诊断系统

场景描述：

某互联网公司运维团队拥有 200+ 微服务，日常值班工程师面对的问题不是"没有监控"，而是监控信号过多——每次故障爆发时同时涌入几十条告警、不同服务的日志、业务侧反馈和群聊中的经验判断。团队已完成试验展开，验证了日志解释、告警聚类和相似案例召回三项核心能力，现需将实验原型转化为可治理的值班辅助系统。

用户输入：

实验结论报告：AIOps 故障分诊辅助系统

已验证能力：
- 单条日志解释：90% 可理解
- 告警聚类与去噪：告警量降低 65%
- 历史案例召回：Top-3 命中率 72%
- 初步归因建议：与专家判断一致率 68%

未验证能力：
- 自动执行修复动作（风险过高，暂不进入）
- 跨服务级联故障的完整链路推断

已知风险：
- 错误归因可能导致工程师沿错误方向排查 30 分钟+
- 错误扩容/重启建议可能放大故障
- 新型故障模式超出案例库覆盖范围

执行流程：

1. 实验证据输入

从实验阶段继承的证据:

  能力边界:
    - 日志解释: 90%可理解 ✅
    - 告警聚类: 告警量降65% ✅
    - 案例召回: Top-3命中72% ✅
    - 初步归因: 一致率68% ⚠️（需持续优化）
    - 自动修复: 风险过高 ❌（不纳入）

  产品形态建议:
    - 类型: 值班Copilot（建议+证据模式）
    - 界面: 告警面板 + 侧边栏分析面板
    - 关键交互: 一键查看证据链、采纳建议、标记误判

  资料缺口:
    - 需补充50+跨服务级联故障案例
    - 需建立"禁止自动执行"动作清单

  风险边界:
    - 所有修复建议: 仅展示，不执行
    - 扩容/重启/切流建议: 必须双人确认
    - 归因建议: 必须附带证据链

2. 系统边界定义

维度	实验阶段	系统构建后
用户范围	2名资深工程师试用	全部值班工程师（3班 x 5人）
能力范围	单服务日志解释	多服务告警聚类 + 案例召回 + 归因建议
权限分层	无	值班工程师 / 领域专家 / 服务负责人
动作边界	仅展示	仅建议，禁止直接执行生产操作
失败处理	人工兜底	证据缺失时明确标注 + 自动降级

3. 能力模块设计

# AI Native 架构：AIOps 故障分诊系统

能力系统层:

  Agent层（IncidentAgent）:
    - 目标理解: 解析告警信号、关联多源数据
    - 任务规划: 选择聚类→解释→召回→归因的执行链
    - 结果组织: 压缩混乱信号为结构化故障摘要

  Skill层:
    - ClusterAlerts: 告警聚类与去噪
    - ExplainLog: 单条/批量日志解释
    - RecallCases: 历史相似案例召回
    - SuggestRootCause: 初步归因建议
    - BuildEvidenceChain: 证据链组装
    - CheckEscalation: 升级判断（是否需领域专家介入）

  Tool层:
    - LogSearch.query: 日志检索
    - AlertManager.getActive: 告警系统
    - MetricsAPI.query: 监控指标
    - CaseBase.search: 历史案例库
    - TopologyGraph.getDependencies: 服务拓扑

  Model层:
    - GPT-4o: 主推理模型（归因+案例分析）
    - text-embedding-3: 日志/案例向量化

  Data层:
    - 案例库: 历史故障工单、复盘材料
    - 知识库: 运维手册、服务SLA、依赖拓扑
    - 记忆系统: 近期故障上下文、值班交接状态

4. 失败处理策略

失败场景	触发条件	处理策略	人工接管
日志格式未知	解析失败	标注"未识别格式"，展示原文	值班工程师手动分析
案例库无匹配	Top-3 相似度<50%	标注"无历史参考"	领域专家介入
归因置信度低	一致率<50%	仅展示候选，不排序	必须人工判断
多服务级联故障	涉及>3个服务	标注"复杂场景"	自动升级服务负责人
模型服务异常	API不可用	降级为纯告警面板	全部回归人工

5. 治理与观测方案

可观测性:
  监控指标:
    - 故障分诊时间: 目标缩短40%
    - 建议采纳率: >50%
    - 误判率: <15%
    - 证据链完整率: >80%
    - 系统可用性: 99.5%

  审计日志:
    - 每次分析: 输入告警集、模型版本、召回案例
    - 每次建议: 归因结论、证据链、置信度
    - 每次人工操作: 采纳/拒绝/标记误判 + 原因

可回退性:
  - 功能开关: 可按服务粒度关闭AI分析（1分钟内生效）
  - 证据缺失时: 自动降级为"仅展示原始信号"
  - 连续误判: 触发告警，建议关闭该服务的AI分析

可更新性:
  - 案例库: 每次故障复盘后增量更新
  - 规则: 升级路径、禁止动作清单可热更新
  - 模型: 支持灰度发布，按服务逐步放开

输出结果：

# 系统构建方案：AIOps 故障分诊辅助系统

系统边界:
  用户: 15名值班工程师 + 10名领域专家
  场景: 告警聚类(65%降噪)、日志解释(90%)、案例召回(72%)、归因建议(68%)
  边界: 仅建议，禁止自动执行任何生产操作

能力模块:
  Agent层:
    - IncidentAgent — 任务编排、边界控制、证据链组装
  Skill层（6个）:
    - ClusterAlerts / ExplainLog / RecallCases
    - SuggestRootCause / BuildEvidenceChain / CheckEscalation
  Tool层:
    - 日志检索、告警系统、监控指标、案例库、服务拓扑
  Model层:
    - GPT-4o（主推理）+ text-embedding-3（向量检索）
  Data层:
    - 案例库、运维知识库、值班记忆系统

失败处理:
  - 5种失败场景分级处理
  - 证据缺失自动降级
  - 复杂场景自动升级

治理方案:
  - 故障分诊时间、采纳率、误判率等7项指标
  - 完整审计日志（含证据链追溯）
  - 服务粒度功能开关（1分钟回退）

进入审计放行条件:
  ✅ 三项核心能力指标达到阈值
  ✅ "禁止自动执行"动作清单完备
  ✅ 升级链路定义清晰
  ✅ 误判反馈机制已建立
  ✅ 值班团队已培训

---

示例 3：智能研发知识助手系统

场景描述：

某 SaaS 产品研发团队规模快速增长，新人上手周期长（平均 4-6 周），技术文档分散在 Confluence、飞书文档、代码仓库 README 和 Slack 历史消息中。团队已完成试验展开，验证了 RAG 知识检索和上下文问答两项能力，现需将原型转化为覆盖"文档理解 → 知识检索 → 上下文问答 → 经验沉淀"全链路的研发知识助手系统。

用户输入：

实验结论报告：研发知识助手 RAG 系统

已验证能力：
- 文档问答（Confluence + 飞书）：相关性评分 4.1/5
- 代码上下文解释：开发者满意度 3.8/5
- 新人引导问答：首问解决率 75%

未验证能力：
- 跨文档推理（如"这个设计决策的背景是什么"）
- 自动生成技术文档

已知问题：
- 文档口径不一致，同一概念在不同文档中描述不同
- 代码注释质量参差不齐，影响检索效果
- 敏感信息（密钥、凭证）偶尔出现在文档中

执行流程：

1. 实验证据输入

从实验阶段继承的证据:

  能力边界:
    - 文档问答: 相关性4.1/5 ✅
    - 代码解释: 满意度3.8/5 ⚠️（需优化检索质量）
    - 新人引导: 首问解决率75% ✅
    - 跨文档推理: 未验证 ❌（纳入后续迭代）
    - 自动生文档: 未验证 ❌（不在本期范围）

  产品形态建议:
    - 类型: 研发Copilot（IDE插件 + Chat界面）
    - 界面: VS Code侧边栏 + 独立问答页
    - 关键交互: 选中代码右键解释、自然语言提问、来源追溯

  资料缺口:
    - 需统一500+核心概念的术语表
    - 需建立文档质量评分机制
    - 需增加敏感信息过滤规则

  风险边界:
    - 涉及安全凭证的回答: 必须过滤
    - 涉及架构决策的回答: 必须标注来源和时效
    - 代码修改建议: 仅展示，不自动应用

2. 系统边界定义

维度	实验阶段	系统构建后
用户范围	5名工程师试用	全部研发团队（80人）
能力范围	Confluence问答	文档+代码+PR+会议纪要全源检索
权限分层	无	按项目/团队/文档权限继承
数据源	静态文档快照	增量同步（每小时）
失败处理	返回空结果	优雅降级 + 来源标注 + 反馈入口

3. 能力模块设计

# AI Native 架构：研发知识助手

能力系统层:

  Agent层（KnowledgeAgent）:
    - 目标理解: 解析研发问题、判断信息类型
    - 任务规划: 选择检索策略（文档/代码/混合）
    - 结果组织: 综合多源结果、标注来源、过滤敏感信息

  Skill层:
    - ParseQuery: 问题解析与意图分类
    - SearchDocs: 文档检索（Confluence/飞书/README）
    - SearchCode: 代码检索（仓库/PR/Commit Message）
    - ExplainContext: 上下文解释与关联
    - FilterSensitive: 敏感信息过滤
    - CiteSource: 来源标注与时效提示

  Tool层:
    - VectorStore.search: 向量检索
    - ConfluenceAPI.query: Confluence查询
    - FeishuDocAPI.query: 飞书文档查询
    - CodeSearch.query: 代码仓库搜索
    - GitHubAPI.getPR: PR与评论查询
    - SensitivityFilter.scan: 敏感信息扫描

  Model层:
    - GPT-4o: 主推理模型（问答+解释）
    - text-embedding-3-large: 向量化（多源文档）

  Data层:
    - 知识库: 技术文档、API文档、设计文档
    - 术语表: 统一概念定义（500+词条）
    - 代码索引: 仓库代码 + PR + Commit
    - 记忆系统: 用户最近查询、项目上下文

4. 失败处理策略

失败场景	触发条件	处理策略	人工接管
文档未覆盖	检索结果相关度<0.5	提示"暂无相关文档"，引导反馈	提交文档需求工单
口径冲突	多文档描述不一致	并列展示，标注时间戳和来源	用户自行判断或提交术语修订
敏感信息泄露	命中过滤规则	自动替换为"[已过滤]"	安全团队审核
代码上下文不足	函数调用链过深	展示直接上下文 + 提供"展开更多"	开发者手动溯源
索引过期	文档更新>24小时	标注"数据可能过期"	触发增量索引

5. 治理与观测方案

可观测性:
  监控指标:
    - 问答相关性: >4.0/5
    - 首问解决率: >70%
    - 来源可追溯率: 100%
    - 敏感信息泄露: 0次
    - 索引新鲜度: <24小时

  审计日志:
    - 每次查询: 用户、问题、检索源、返回结果
    - 每次反馈: 有用/无用 + 原因
    - 敏感过滤: 触发次数、类型分布

可回退性:
  - 数据源降级: 单源异常时自动切换剩余源
  - 功能开关: 可按团队/项目关闭特定能力
  - 索引回滚: 支持回退到上一个健康索引版本

可更新性:
  - 知识源: 增量同步，无需重建全量索引
  - 术语表: 支持团队自主维护
  - 过滤规则: 安全团队实时更新

输出结果：

# 系统构建方案：研发知识助手

系统边界:
  用户: 80名研发人员（含新人引导场景）
  场景: 文档问答(4.1/5)、代码解释(3.8/5)、新人引导(75%首问解决)
  边界: 不自动生成文档、不自动修改代码

能力模块:
  Agent层:
    - KnowledgeAgent — 多源检索编排、敏感信息过滤、来源标注
  Skill层（6个）:
    - ParseQuery / SearchDocs / SearchCode
    - ExplainContext / FilterSensitive / CiteSource
  Tool层:
    - 向量检索、Confluence、飞书、代码搜索、GitHub、敏感过滤
  Model层:
    - GPT-4o（主推理）+ text-embedding-3-large（多源向量化）
  Data层:
    - 知识库、术语表(500+)、代码索引、用户记忆

失败处理:
  - 5种失败场景分级处理
  - 口径冲突并列展示
  - 敏感信息零泄露保障

治理方案:
  - 相关性、解决率、追溯率等5项指标
  - 完整查询审计日志
  - 数据源粒度功能开关

进入审计放行条件:
  ✅ 术语表覆盖核心概念
  ✅ 敏感信息过滤规则就绪
  ✅ 索引同步机制稳定运行
  ✅ 文档权限继承正确
  ✅ 研发团队已培训并完成试点