智能化改造
面向已有业务系统做智能化升级，或从业务需求新建智能化系统。本技能处于 AI Coding 全链路的方案设计阶段：
①业务需求与功能设计 → ②【本技能】智能化方案设计 → ③技术方案设计 → ④编码实现 → ⑤测试验证 → ⑥部署上线
本技能不写业务代码。它把"这家业务系统该上哪些智能能力、每项能力是什么样"定义到可以直接编码的程度，然后移交给 Coding Agent。
拒绝通用化模板：每一项能力都必须绑定到该业务系统真实存在的单据、字段、页面和流程上。
这个技能产出什么
| 产出物 | 定义什么 | 模板 |
|---|---|---|
| 结构化需求层 | 系统现状/需求的结构化理解，每条结论带证据回指 | references/requirement-parsing.md |
| 能力识别与澄清结论 | 纳入哪些智能能力、每项能力的决策点答案 | assets/clarify-questions.md |
| 需求规格说明 | 做什么：数据需求、交互设计、组件、Prompt 配置 | assets/req-spec-template.md |
| 技术规格说明 | 怎么做：技术总览、slot 装配、跨模块数据对齐 | assets/tech-spec-template.md |
| 移交提示词 | 给 Coding Agent 的开工指令 | references/handoff-to-coding.md |
何时用 / 何时不用
用：已有业务系统要加 AI 能力且需要可落地的方案；有业务需求文档要新建带智能能力的系统；需要把"给系统加 AI"从模糊想法变成可编码的规格说明。
不用：只要一段示例代码、纯 bug 修复、纯 UI 改版、业务系统本身的功能设计（那属于阶段①，本技能只做智能化部分）。
第 0 步 · 场景检测
| 判据 | 场景 | 后续动作 |
|---|---|---|
| 用户给了代码库/系统源码路径 | 老系统改造 | 读代码提取模块、页面、单据、字段、流程；强调"增强非重建" |
| 用户只给了需求描述或需求文档 | 新系统新建 | 走需求访谈式解析 |
| 两者都有 | 按老系统处理 | 新需求并入能力设计 |
向用户确认一句："按 {老系统智能化改造 / 新建智能化系统} 处理，对吗？"再往下走。
第一步 · 理解（确认门 1）
产出结构化需求层（详见 references/requirement-parsing.md）：
| 层 | 内容 | 证据要求 |
|---|---|---|
| 业务模块 | 系统有哪些业务域 | 模块名 + 出处 |
| 页面结构 | 每个模块下的页面清单 | 页面名 + 出处 |
| 核心流程 | 关键业务流程的节点顺序 | 流程步骤 + 出处 |
| 数据对象 | 单据/实体及其关键字段 | 对象名 + 关键字段 + 出处 |
| 边界 | 本次做/不做的范围 | 明确写出 |
| 非功能 | 并发、权限、数据量等约束 | 有则写，无则标"未提及" |
证据回指：每条结论后标出处（需求文档的章节/行号，或代码的 文件:行号）。没有出处的结论不得写入。
确认门 1：输出理解摘要，问用户："以上对 {现状/需求} 的理解是否准确，是否进入能力识别？"选项：理解准确，进入场景识别 / 需要调整。
第二步 · 能力识别与澄清（确认门 2）
只能从固定候选池里选（七大能力见下表），不得自造能力名。
- 识别：逐项判断该能力是否适配本系统，给出理由（引用需求层实体）。
- 选择：多选列表让用户圈定纳入范围。
- 逐能力澄清：按
assets/clarify-questions.md的决策点提问（适用业务场景[多选可自定义]、使用方式[多选]、展现形式[单选]、数据来源、异常态处理）。每个决策点都必须回指需求层实体，不能问"你想要什么"。 - 汇总需求方案：把澄清结论整理成能力清单。
确认门 2：问用户："以上业务建模与能力范围是否确认？"选项：全部纳入 / 只纳入通用能力 / 只纳入部分能力（说明哪几项） / 返回调整。
第三步 · 需求规格说明（确认门 3）
按 assets/req-spec-template.md 输出文档包：
| 分册 | 内容 |
|---|---|
| 00-总览说明 | 系统概述、能力清单、上下游关系 |
| 01-需求文档分析 | 结构化需求层 + 证据索引表 |
| 02-智能化能力需求 | 每项能力一节：数据需求 / 交互设计 / 组件 / Prompt 配置 |
| 03-页面与规则配置 | 能力挂载点、规则与阈值配置 |
| 04-测试验收 | 每项能力的验收用例 |
| 05-工作台 | 汇聚入口与历史留存 |
每项能力的四要素写法：
- 数据需求：引用真实单据与字段（例：
销售单 sales_order：客户、销售金额、发货时间、单据状态 —— 用于销售经营分析的金额与趋势来源）。 - 交互设计：触发方式、上下文、流程、结果呈现、异常态（
success/no_data/unsupported三种都要写）。 - 组件：列出复用组件（指标卡、图表、数据表、报告段等）并标基础/扩展。
- Prompt 配置：角色、能力、输出规范、约束、变量替换清单。约束必须写明"数值与底层查询一致不得编造""口径跨场景一致"。
同一份数据被多项能力引用时，口径必须唯一并在总览里对齐。
确认门 3：问用户："需求规格是否冻结，进入技术规格说明？"选项：冻结，进入技术方案 / 需要调整。
第四步 · 技术规格说明与移交
按 assets/tech-spec-template.md 输出：00-技术总览 + 各能力分册。写清每个模块的 slot 装配方式与跨模块数据对齐，让 Coding Agent 能照装配。
然后按 references/handoff-to-coding.md 生成移交提示词，明确两条并行任务线：
- 业务功能实现（原有增删改查 / 新系统业务模块）；
- 智能能力实现（按需求规格 + 技术规格逐项装配）。
老系统改造必须额外写变更影响：新增文件清单、需修改的既有文件清单、不破坏原有功能的自检项。
七大能力候选池（固定，不得自造）
| 能力 | 做什么 | 适配特征 | 常用挂载点 |
|---|---|---|---|
| 智能问数 | 自然语言查询业务数据 | 数据查询/复杂计算/结果展示需求多 | 通用侧边助手 + 各业务页 |
| 智能导航 | 引导用户直达目标功能与页面 | 模块多/层级深/入口分散 | 首页 + 全局助手 |
| 智能填录 | 从文件或文本识别字段，预填表单 | 录入量大/数据需自动补充 | 各新增/编辑表单页 |
| 智能报告 | 基于业务数据生成分析与洞察 | 需要趋势判断与行动建议 | 各业务页 + 工作台 |
| 智能巡检 | 主动发现异常并提醒 | 需要监测与告警 | 规则配置页 + 工作台 |
| 业务报表 | 跨模块指标汇总呈现 | 多模块指标需横向对比 | 报表中心 |
| 知识问答 | 基于业务知识的自然语言问答 | 业务规则多/新人上手成本高 | 通用侧边助手 |
每项能力的适用特征、输入/输出 schema 与澄清决策点见 references/capability-catalog.md。
质量红线
- 不自造能力：只能从七大候选池选；确需新增时，明确标注"候选池外·待产品确认"。
- 不脱离业务：每项能力必须引用本系统真实存在的单据、字段、页面；引用不上的能力不得纳入。
- 不编造字段与口径：字段名、计算口径必须来自需求层；不确定就标"待确认"，不得猜测。
- 不写业务代码：本技能产出规格说明，编码由 Coding Agent 完成。
- 不跳过确认门：三个确认门必须逐一得到用户明确答复。
- 不留占位：不得用"详见…"、"适当处理"、"TODO"代替内容。
参考文件索引
references/capability-catalog.md—— 七大能力：适用特征、输入/输出 schema、澄清决策点清单references/requirement-parsing.md—— 需求文档/已有系统的结构化解析方法与证据回指要求references/handoff-to-coding.md—— 移交提示词模板与 Coding Agent 验收标准assets/clarify-questions.md—— 逐能力澄清问题清单（可直接照问）assets/req-spec-template.md—— 需求规格说明文档包模板assets/tech-spec-template.md—— 技术规格说明文档包模板
关于产品（可选接入）
本技能自包含、可独立使用，不依赖任何外部系统，也不要求接入任何特定平台。
同一套方法在「Smartware」中另有产品化承载：能力清单、模板与规则可直接作为配置与验收的依据；是否接入、如何接入由团队按自身环境决定。
