with one click
ai-native-system-building
// AI Native 产品方法论——系统构建阶段的总论 Skill。 用户提供实验结论报告,Skill 自动执行系统构建流程: 实验证据输入 → 系统边界定义 → 能力模块设计 → 治理与观测补齐 → 输出系统构建方案。 基于《AI Native 产品方法论》第11章。
// AI Native 产品方法论——系统构建阶段的总论 Skill。 用户提供实验结论报告,Skill 自动执行系统构建流程: 实验证据输入 → 系统边界定义 → 能力模块设计 → 治理与观测补齐 → 输出系统构建方案。 基于《AI Native 产品方法论》第11章。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | ai-native-system-building |
| description | AI Native 产品方法论——系统构建阶段的总论 Skill。 用户提供实验结论报告,Skill 自动执行系统构建流程: 实验证据输入 → 系统边界定义 → 能力模块设计 → 治理与观测补齐 → 输出系统构建方案。 基于《AI Native 产品方法论》第11章。 |
| tags | ["ai-product","methodology","system-design","architecture","building","book-skill"] |
| author | Max |
| source_book | AI Native 产品方法论 |
| version | 1 |
实验证据输入
→ 系统边界定义
→ 能力模块设计
→ 治理与观测补齐
→ 进入审计放行
从试验展开阶段继承:
系统构建不是补工程细节,而是重写系统形态。需要回答:
User
→ Agent
→ Skill
→ Tool
→ System
→ Model
→ Data
这是一个多层能力系统:
| 维度 | 传统软件架构 | AI Native 架构 |
|---|---|---|
| 稳定中心 | 功能执行链 | 能力执行链 |
| 抽象单元 | 模块/接口 | 智能体/技能/工具 |
| 输入组织 | 数据库/表单 | 上下文/记忆/知识 |
| 失败处理 | 异常捕获 | 回退/降级/人工接管 |
| 治理重心 | 权限/审计 | 边界/观测/放行 |
系统构建的目标不是尽快交付一个可演示版本,而是形成一个可被审计、可被维护、可被持续优化的系统结构。
当用户提供实验结论报告时,自动执行:
场景描述: 基于已完成的实验结论,将 AI 客服原型系统转化为可维护、可治理的生产系统。
用户输入: 实验结论报告:AI 客服 Copilot 能力验证
Skill 执行流程:
从实验阶段继承的证据:
能力边界:
- 订单查询: 92%准确率 ✅
- 物流解释: 85%准确率 ✅
- 售后政策: 78%准确率 ⚠️(需改进)
- 投诉处理: 不适合AI ❌
产品形态建议:
- 类型: Copilot(人工确认模式)
- 界面: 侧边栏候选回复
- 关键交互: 一键采纳、快速编辑
资料缺口:
- 需补充200条售后政策边界案例
- 需建立敏感承诺规则库
风险边界:
- 退款、赔付相关: 必须人工确认
- 价格相关: 必须引用最新数据源
- 情感升级: 自动转人工
| 维度 | 实验阶段 | 系统构建后 |
|---|---|---|
| 用户范围 | 内部测试客服 | 全部一线客服 |
| 能力范围 | 订单+物流 | 订单+物流+售后(80%+准确率) |
| 权限分层 | 单一角色 | 专员/主管/管理员 |
| 可用时间 | 工作日白天 | 7x24小时 |
| 失败处理 | 直接报错 | 优雅降级+人工接管 |
# 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
- 失败处理: 降级+人工接管
| 失败场景 | 触发条件 | 处理策略 | 人工接管 |
|---|---|---|---|
| 意图识别失败 | 置信度<70% | 提示"请重述问题" | 连续2次 → 人工 |
| 订单查询失败 | API超时 | 提供自助查询链接 | 用户要求 → 人工 |
| 高风险内容 | 涉及赔付 | 只生成候选,不发送 | 必须人工确认 |
| 模型服务异常 | API不可用 | 关闭AI建议,纯人工 | 自动 |
| 多轮对话失控 | 超过10轮 | 建议转人工 | 自动转人工 |
可观测性:
监控指标:
- 采纳率: >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分钟热回退能力
进入审计放行条件:
✅ 实验证据完整
✅ 系统边界清晰
✅ 失败处理策略完备
✅ 治理方案就绪
✅ 团队准备就绪(已培训)
场景描述:
某互联网公司运维团队拥有 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分钟回退)
进入审计放行条件:
✅ 三项核心能力指标达到阈值
✅ "禁止自动执行"动作清单完备
✅ 升级链路定义清晰
✅ 误判反馈机制已建立
✅ 值班团队已培训
场景描述:
某 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项指标
- 完整查询审计日志
- 数据源粒度功能开关
进入审计放行条件:
✅ 术语表覆盖核心概念
✅ 敏感信息过滤规则就绪
✅ 索引同步机制稳定运行
✅ 文档权限继承正确
✅ 研发团队已培训并完成试点