拓冰网站定制 
1. 从对话日志里挖出可复用场景Skill 落地的第一步Agent 开发做到一定阶段你会发现一个尴尬的事实模型每次都能跑通任务但每次跑的方式都不一样。同一个「生成周报」的需求今天它先读数据库再写模板明天它先写模板再回头找数据后天干脆自己编了一组数字。你盯着对话日志感觉像在看一个聪明但没纪律的实习生干活。这时候大多数人第一反应是「把提示词写详细点」。但提示词写到两千字以后维护成本已经超过收益而且模型对长提示词的注意力衰减是客观存在的。真正能解决问题的路径是把重复出现的流程从对话里「抽」出来固化成一个文件化的能力单元——也就是 Skill。这篇内容聚焦一件事怎么从你手头的对话日志里识别出哪些场景值得封装成 Skill以及怎么把重复流程写成一份可被 Agent 稳定加载的 Skill.md。我会给出场景识别的判断清单、Skill.md 的骨架结构、以及用 TaoToken 统一 Key 通道完成一次可复制接入的完整演示。适合已经在做 Agent 应用、手里攒了一堆对话记录但不知道怎么沉淀的开发者。Skill 不是提示词的高级写法。它是存放在 Agent 可访问路径下的一组文件Skill.md 负责核心指令和元数据References/ 放参考资料和模板Scripts/ 放可执行脚本。Agent 启动时读取 Skill.md 前端的 name 和 description 注入系统提示词任务需要时再通过文件读取工具加载完整内容和执行脚本。理解这一点后面的设计才有落脚点。2. TaoToken 前置统一 Key 与 API 通道在动手写 Skill 之前先把模型调用通道理顺。Skill 本身是文件但 Agent 执行 Skill 里的脚本、调用模型做判断时需要一个稳定的 API 入口。我试过在多个项目里分别维护不同的 Key结果就是环境变量到处散落换一个 Agent 平台就要重新配一遍。TaoToken 在这里的角色是统一通道一个 Key 覆盖模型对话、编码类任务和 Agent 调用API 地址固定为https://taotoken.net/api。你不需要在 Skill 里硬编码任何厂商信息脚本通过环境变量读取 Key 和 Base URL 即可。需要提前准备的东西一个 TaoToken 账号在控制台生成 API Key本地或服务器上设置好环境变量TAOTOKEN_API_KEY确认 Agent 运行环境能访问https://taotoken.net/api控制台入口在https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteAPI Key 管理页在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。生成 Key 之后先别急着写 Skill用一条 curl 确认通道是通的这一步能省掉后面大量「到底是 Skill 写错了还是 Key 没配对」的排查时间。注意Key 只放在环境变量或密钥管理服务里不要写进 Skill.md也不要提交到 Git。Skill 文件是会被 Agent 读取的把密钥写进去等于公开。3. 场景识别清单哪些对话值得封装成 Skill不是所有重复对话都值得做成 Skill。判断标准很简单这个场景是否同时满足「高频」「步骤稳定」「有明确交付物」三个条件。下面是我实际用下来比较顺手的一份识别清单你可以直接拿去对照自己的对话日志。3.1 从日志里提取候选场景打开你的对话记录按任务类型分组统计每个类型出现的次数。出现三次以上、且每次执行步骤大致相同的就是候选。具体看这几个信号用户输入结构相似比如每次都是「帮我分析这份 CSV 的 XX 指标」只是文件名和指标名不同Agent 执行路径重复读文件 → 清洗 → 计算 → 输出表格四步固定交付物格式固定每次都要生成同样表头的 Excel 或同样结构的 Markdown 报告存在明确的「翻车点」模型偶尔会跳过清洗步骤或者把指标算错反过来如果每次任务的目标、输入、输出差异都很大那它更适合留在对话里硬封装成 Skill 反而会增加约束成本。3.2 场景分级表场景特征是否封装理由每天出现步骤固定输出格式统一强烈建议收益最高一次封装长期复用每周出现步骤基本固定输出有模板建议收益明显维护成本低偶尔出现步骤每次不同不建议约束成本高于收益高频但每次目标差异大拆分为多个 Skill一个 Skill 只解决一类问题涉及敏感数据或生产库直连谨慎需要额外做权限隔离和审计3.3 识别重复流程的三个动作第一把同一场景的三次对话并排放在一起标出每次的步骤序列。第二找出三次都出现的步骤这些是必须固化的核心流程。第三找出只出现一两次的步骤这些是可选分支在 Skill.md 里写成条件判断而不是主流程。做完这三步你手里应该有一张「核心步骤 可选分支 翻车点」的清单。这张清单就是 Skill.md 的写作大纲。4. Skill.md 骨架与可复制配置Skill.md 的结构不需要复杂但必须让 Agent 在只读前几行的情况下就知道「这个 Skill 是干什么的、什么时候该用」。下面是一份可以直接改的骨架。4.1 Skill.md 骨架--- name: csv-metric-report description: 读取指定 CSV 文件按配置的指标列完成清洗、聚合与格式化输出标准 Markdown 报告。当用户要求分析 CSV 并出报告时使用。 --- # CSV 指标报告 Skill ## 适用场景 用户提供 CSV 路径和指标列名需要生成结构化分析报告。 ## 输入要求 - csv_path: CSV 文件绝对路径必填 - metric_cols: 需要分析的指标列逗号分隔必填 - group_col: 分组列可选默认不分组 ## 执行流程 1. 读取 CSV检查文件是否存在、编码是否为 UTF-8 2. 对 metric_cols 中的每一列做缺失值检查缺失率超过 30% 时停止并报告 3. 按 group_col 分组若提供计算 sum / mean / count 4. 调用 Scripts/render_report.py 生成 Markdown 报告 5. 输出报告路径并附上前 5 行预览 ## 边界约束 - 不修改原始 CSV 文件 - 不对缺失值做自动填充只报告 - 单次处理行数上限 100000超过则提示用户分批 ## 自检清单 - [ ] 报告表头与 metric_cols 一致 - [ ] 分组数量与 group_col 唯一值数量一致 - [ ] 缺失率超过阈值的列已在报告中标注4.2 配套脚本与目录结构skills/ csv-metric-report/ Skill.md References/ report_template.md Scripts/ render_report.pyrender_report.py只做确定性的事读数据、算指标、套模板。所有需要「判断」的环节留在 Skill.md 的流程描述里由 Agent 决策。这样脚本输出 100% 稳定Agent 的随机性被限制在可控范围内。4.3 脚本里读取 TaoToken 通道如果 Skill 流程中需要调用模型做字段映射或异常判断脚本通过环境变量读取通道import os import requests API_BASE os.environ.get(TAOTOKEN_API_BASE, https://taotoken.net/api) API_KEY os.environ[TAOTOKEN_API_KEY] def ask_model(prompt: str) - str: resp requests.post( f{API_BASE}/v1/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: claude-sonnet-4-20250514, messages: [{role: user, content: prompt}], temperature: 0 }, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content]把temperature设为 0 是为了让判断类调用尽量稳定。Skill 里的模型调用应该服务于确定性目标而不是让模型自由发挥。5. 验证请求与成功结果Skill 写完之后必须做一次端到端验证。验证分两层先验证 API 通道再验证 Skill 执行。5.1 验证 API 通道curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 只回复 OK}], temperature: 0 }返回里choices[0].message.content是OK说明通道正常。如果返回 401检查 Key 是否带上了Bearer前缀返回 404检查 Base URL 是否写成了https://taotoken.net/api而不是带/v1的完整路径。5.2 验证 Skill 执行准备一份测试 CSVdate,region,revenue,orders 2024-01-01,east,1200,30 2024-01-01,west,800,20 2024-01-02,east,1500,35 2024-01-02,west,,18在 Agent 里触发 Skill输入「用 csv-metric-report 分析 /tmp/test.csv 的 revenue 和 orders按 region 分组」。预期结果Agent 读取 Skill.md确认输入完整执行脚本输出 Markdown 报告报告中 west 组的 orders 缺失率被标注报告表头为 region / revenue_sum / revenue_mean / orders_sum / orders_mean / orders_count如果 Agent 跳过了缺失值检查直接出报告说明 Skill.md 里的流程描述不够强制。把「缺失率超过 30% 时停止并报告」改成「必须先执行缺失值检查检查未通过不得进入下一步」用明确的禁止性语言约束。5.3 验证清单验证项通过标准API 通道curl 返回 200 且内容正确Skill 加载Agent 能说出 Skill 的 name 和适用场景输入校验缺少必填参数时 Agent 主动追问流程执行步骤顺序与 Skill.md 一致边界约束不修改原始文件超限时提示自检清单报告生成后逐项核对通过6. 本篇常见错排查6.1 Skill 不生效Agent 完全没读先确认 Skill 目录是否在 Agent 的扫描路径下。不同平台的扫描路径不同常见的是项目根目录的skills/或用户目录的.agent/skills/。其次检查 Skill.md 的 frontmatter 是否合法name和description必须存在且不能有语法错误。YAML 里冒号后面少一个空格都会导致解析失败。6.2 Agent 读了 Skill 但不按流程走这是最常见的问题。原因通常是流程描述太抽象比如写「对数据进行清洗」模型不知道清洗什么。改成具体动作「删除 revenue 列中值为空的行将 orders 列转为整数转换失败的行记录到 errors 列表」。动作越具体执行越稳定。另一个原因是流程步骤之间没有依赖声明。如果第 3 步依赖第 2 步的输出要在 Skill.md 里写明「第 3 步的输入必须是第 2 步的输出不得跳过第 2 步」。6.3 脚本执行报错但 Agent 不报告脚本里的异常必须显式抛出并让 Agent 捕获。如果脚本用try/except吞掉了异常Agent 会以为执行成功。正确做法是让异常向上传播或者在 Skill.md 里要求 Agent 检查脚本退出码非 0 时停止并报告 stderr。6.4 模型调用返回 429 或超时Skill 里如果包含批量模型调用容易触发限流。处理方式在脚本里加指数退避重试单次任务并发不超过 3超时设为 60 秒。如果任务本身需要大量调用考虑拆分成多个子任务而不是在一个 Skill 执行里硬扛。6.5 换了 Agent 平台后 Skill 失效Skill 的文件结构是通用的但加载机制各平台不同。迁移时重点检查三处Skill 目录路径、frontmatter 字段名、脚本执行权限。脚本文件记得加可执行权限否则 Agent 调用时会报 permission denied。7. 把 Skill 接入你的 Agent 工作流Skill 写完之后下一步是让它真正跑在日常工作里。如果你主要做编码类任务可以把 Skill 和 Coding Plan 结合让 Agent 在写代码时自动加载项目规范类的 Skill。Coding Plan 入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。如果你还在验证阶段想先手动测试 Skill 里的模型调用逻辑可以直接在模型对话页面试。入口在https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite把 Skill.md 里的判断逻辑贴进去跑几轮确认输出稳定后再写进脚本。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite里面有完整的 API 参数说明和错误码对照。Claude Code 相关的 Skill 接入示例在https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。最后说一个实际踩过的坑Skill 不是一次写完就完事的。业务规则变了、数据源换了、模型升级了Skill.md 都要跟着更新。建议给每个 Skill 加一个版本号写在 frontmatter 里每次修改记录变更原因。这样当 Agent 行为出现异常时你能快速定位是哪次修改引入的。Skill 的价值不在于写得多漂亮而在于它能不能在半年后依然稳定地产出可预期的结果。 TaoToken 实战：Skills 设计开发精讲——场景识别与重复流程封装
1. 从对话日志里挖出可复用场景Skill 落地的第一步Agent 开发做到一定阶段你会发现一个尴尬的事实模型每次都能跑通任务但每次跑的方式都不一样。同一个「生成周报」的需求今天它先读数据库再写模板明天它先写模板再回头找数据后天干脆自己编了一组数字。你盯着对话日志感觉像在看一个聪明但没纪律的实习生干活。这时候大多数人第一反应是「把提示词写详细点」。但提示词写到两千字以后维护成本已经超过收益而且模型对长提示词的注意力衰减是客观存在的。真正能解决问题的路径是把重复出现的流程从对话里「抽」出来固化成一个文件化的能力单元——也就是 Skill。这篇内容聚焦一件事怎么从你手头的对话日志里识别出哪些场景值得封装成 Skill以及怎么把重复流程写成一份可被 Agent 稳定加载的 Skill.md。我会给出场景识别的判断清单、Skill.md 的骨架结构、以及用 TaoToken 统一 Key 通道完成一次可复制接入的完整演示。适合已经在做 Agent 应用、手里攒了一堆对话记录但不知道怎么沉淀的开发者。Skill 不是提示词的高级写法。它是存放在 Agent 可访问路径下的一组文件Skill.md 负责核心指令和元数据References/ 放参考资料和模板Scripts/ 放可执行脚本。Agent 启动时读取 Skill.md 前端的 name 和 description 注入系统提示词任务需要时再通过文件读取工具加载完整内容和执行脚本。理解这一点后面的设计才有落脚点。2. TaoToken 前置统一 Key 与 API 通道在动手写 Skill 之前先把模型调用通道理顺。Skill 本身是文件但 Agent 执行 Skill 里的脚本、调用模型做判断时需要一个稳定的 API 入口。我试过在多个项目里分别维护不同的 Key结果就是环境变量到处散落换一个 Agent 平台就要重新配一遍。TaoToken 在这里的角色是统一通道一个 Key 覆盖模型对话、编码类任务和 Agent 调用API 地址固定为https://taotoken.net/api。你不需要在 Skill 里硬编码任何厂商信息脚本通过环境变量读取 Key 和 Base URL 即可。需要提前准备的东西一个 TaoToken 账号在控制台生成 API Key本地或服务器上设置好环境变量TAOTOKEN_API_KEY确认 Agent 运行环境能访问https://taotoken.net/api控制台入口在https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteAPI Key 管理页在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。生成 Key 之后先别急着写 Skill用一条 curl 确认通道是通的这一步能省掉后面大量「到底是 Skill 写错了还是 Key 没配对」的排查时间。注意Key 只放在环境变量或密钥管理服务里不要写进 Skill.md也不要提交到 Git。Skill 文件是会被 Agent 读取的把密钥写进去等于公开。3. 场景识别清单哪些对话值得封装成 Skill不是所有重复对话都值得做成 Skill。判断标准很简单这个场景是否同时满足「高频」「步骤稳定」「有明确交付物」三个条件。下面是我实际用下来比较顺手的一份识别清单你可以直接拿去对照自己的对话日志。3.1 从日志里提取候选场景打开你的对话记录按任务类型分组统计每个类型出现的次数。出现三次以上、且每次执行步骤大致相同的就是候选。具体看这几个信号用户输入结构相似比如每次都是「帮我分析这份 CSV 的 XX 指标」只是文件名和指标名不同Agent 执行路径重复读文件 → 清洗 → 计算 → 输出表格四步固定交付物格式固定每次都要生成同样表头的 Excel 或同样结构的 Markdown 报告存在明确的「翻车点」模型偶尔会跳过清洗步骤或者把指标算错反过来如果每次任务的目标、输入、输出差异都很大那它更适合留在对话里硬封装成 Skill 反而会增加约束成本。3.2 场景分级表场景特征是否封装理由每天出现步骤固定输出格式统一强烈建议收益最高一次封装长期复用每周出现步骤基本固定输出有模板建议收益明显维护成本低偶尔出现步骤每次不同不建议约束成本高于收益高频但每次目标差异大拆分为多个 Skill一个 Skill 只解决一类问题涉及敏感数据或生产库直连谨慎需要额外做权限隔离和审计3.3 识别重复流程的三个动作第一把同一场景的三次对话并排放在一起标出每次的步骤序列。第二找出三次都出现的步骤这些是必须固化的核心流程。第三找出只出现一两次的步骤这些是可选分支在 Skill.md 里写成条件判断而不是主流程。做完这三步你手里应该有一张「核心步骤 可选分支 翻车点」的清单。这张清单就是 Skill.md 的写作大纲。4. Skill.md 骨架与可复制配置Skill.md 的结构不需要复杂但必须让 Agent 在只读前几行的情况下就知道「这个 Skill 是干什么的、什么时候该用」。下面是一份可以直接改的骨架。4.1 Skill.md 骨架--- name: csv-metric-report description: 读取指定 CSV 文件按配置的指标列完成清洗、聚合与格式化输出标准 Markdown 报告。当用户要求分析 CSV 并出报告时使用。 --- # CSV 指标报告 Skill ## 适用场景 用户提供 CSV 路径和指标列名需要生成结构化分析报告。 ## 输入要求 - csv_path: CSV 文件绝对路径必填 - metric_cols: 需要分析的指标列逗号分隔必填 - group_col: 分组列可选默认不分组 ## 执行流程 1. 读取 CSV检查文件是否存在、编码是否为 UTF-8 2. 对 metric_cols 中的每一列做缺失值检查缺失率超过 30% 时停止并报告 3. 按 group_col 分组若提供计算 sum / mean / count 4. 调用 Scripts/render_report.py 生成 Markdown 报告 5. 输出报告路径并附上前 5 行预览 ## 边界约束 - 不修改原始 CSV 文件 - 不对缺失值做自动填充只报告 - 单次处理行数上限 100000超过则提示用户分批 ## 自检清单 - [ ] 报告表头与 metric_cols 一致 - [ ] 分组数量与 group_col 唯一值数量一致 - [ ] 缺失率超过阈值的列已在报告中标注4.2 配套脚本与目录结构skills/ csv-metric-report/ Skill.md References/ report_template.md Scripts/ render_report.pyrender_report.py只做确定性的事读数据、算指标、套模板。所有需要「判断」的环节留在 Skill.md 的流程描述里由 Agent 决策。这样脚本输出 100% 稳定Agent 的随机性被限制在可控范围内。4.3 脚本里读取 TaoToken 通道如果 Skill 流程中需要调用模型做字段映射或异常判断脚本通过环境变量读取通道import os import requests API_BASE os.environ.get(TAOTOKEN_API_BASE, https://taotoken.net/api) API_KEY os.environ[TAOTOKEN_API_KEY] def ask_model(prompt: str) - str: resp requests.post( f{API_BASE}/v1/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: claude-sonnet-4-20250514, messages: [{role: user, content: prompt}], temperature: 0 }, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content]把temperature设为 0 是为了让判断类调用尽量稳定。Skill 里的模型调用应该服务于确定性目标而不是让模型自由发挥。5. 验证请求与成功结果Skill 写完之后必须做一次端到端验证。验证分两层先验证 API 通道再验证 Skill 执行。5.1 验证 API 通道curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 只回复 OK}], temperature: 0 }返回里choices[0].message.content是OK说明通道正常。如果返回 401检查 Key 是否带上了Bearer前缀返回 404检查 Base URL 是否写成了https://taotoken.net/api而不是带/v1的完整路径。5.2 验证 Skill 执行准备一份测试 CSVdate,region,revenue,orders 2024-01-01,east,1200,30 2024-01-01,west,800,20 2024-01-02,east,1500,35 2024-01-02,west,,18在 Agent 里触发 Skill输入「用 csv-metric-report 分析 /tmp/test.csv 的 revenue 和 orders按 region 分组」。预期结果Agent 读取 Skill.md确认输入完整执行脚本输出 Markdown 报告报告中 west 组的 orders 缺失率被标注报告表头为 region / revenue_sum / revenue_mean / orders_sum / orders_mean / orders_count如果 Agent 跳过了缺失值检查直接出报告说明 Skill.md 里的流程描述不够强制。把「缺失率超过 30% 时停止并报告」改成「必须先执行缺失值检查检查未通过不得进入下一步」用明确的禁止性语言约束。5.3 验证清单验证项通过标准API 通道curl 返回 200 且内容正确Skill 加载Agent 能说出 Skill 的 name 和适用场景输入校验缺少必填参数时 Agent 主动追问流程执行步骤顺序与 Skill.md 一致边界约束不修改原始文件超限时提示自检清单报告生成后逐项核对通过6. 本篇常见错排查6.1 Skill 不生效Agent 完全没读先确认 Skill 目录是否在 Agent 的扫描路径下。不同平台的扫描路径不同常见的是项目根目录的skills/或用户目录的.agent/skills/。其次检查 Skill.md 的 frontmatter 是否合法name和description必须存在且不能有语法错误。YAML 里冒号后面少一个空格都会导致解析失败。6.2 Agent 读了 Skill 但不按流程走这是最常见的问题。原因通常是流程描述太抽象比如写「对数据进行清洗」模型不知道清洗什么。改成具体动作「删除 revenue 列中值为空的行将 orders 列转为整数转换失败的行记录到 errors 列表」。动作越具体执行越稳定。另一个原因是流程步骤之间没有依赖声明。如果第 3 步依赖第 2 步的输出要在 Skill.md 里写明「第 3 步的输入必须是第 2 步的输出不得跳过第 2 步」。6.3 脚本执行报错但 Agent 不报告脚本里的异常必须显式抛出并让 Agent 捕获。如果脚本用try/except吞掉了异常Agent 会以为执行成功。正确做法是让异常向上传播或者在 Skill.md 里要求 Agent 检查脚本退出码非 0 时停止并报告 stderr。6.4 模型调用返回 429 或超时Skill 里如果包含批量模型调用容易触发限流。处理方式在脚本里加指数退避重试单次任务并发不超过 3超时设为 60 秒。如果任务本身需要大量调用考虑拆分成多个子任务而不是在一个 Skill 执行里硬扛。6.5 换了 Agent 平台后 Skill 失效Skill 的文件结构是通用的但加载机制各平台不同。迁移时重点检查三处Skill 目录路径、frontmatter 字段名、脚本执行权限。脚本文件记得加可执行权限否则 Agent 调用时会报 permission denied。7. 把 Skill 接入你的 Agent 工作流Skill 写完之后下一步是让它真正跑在日常工作里。如果你主要做编码类任务可以把 Skill 和 Coding Plan 结合让 Agent 在写代码时自动加载项目规范类的 Skill。Coding Plan 入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。如果你还在验证阶段想先手动测试 Skill 里的模型调用逻辑可以直接在模型对话页面试。入口在https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite把 Skill.md 里的判断逻辑贴进去跑几轮确认输出稳定后再写进脚本。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite里面有完整的 API 参数说明和错误码对照。Claude Code 相关的 Skill 接入示例在https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite。最后说一个实际踩过的坑Skill 不是一次写完就完事的。业务规则变了、数据源换了、模型升级了Skill.md 都要跟着更新。建议给每个 Skill 加一个版本号写在 frontmatter 里每次修改记录变更原因。这样当 Agent 行为出现异常时你能快速定位是哪次修改引入的。Skill 的价值不在于写得多漂亮而在于它能不能在半年后依然稳定地产出可预期的结果。