通用 Skill 开发实战教程：从需求到落地

文章目录 通用 Skill 开发实战教程从需求到落地第一阶段需求分析翻译官思维1.1 拆解“隐形”参数1.2 确立规则优先级第二阶段数据策略设计架构师思维2.1 明确数据源2.2 规避工具陷阱关键2.3 查询模式选择第三阶段与大模型协作开发提效核心3.1 让大模型写第一版草稿3.2 代码审查与逻辑优化3.3 生成测试用例第四阶段接口实现与规范工程师思维4.1 查询前的“三问”4.2 查询语句的“铁律”第五阶段结果呈现与异常处理产品思维5.1 输出标准化5.2 异常分支处理表附录新人自检清单 (Checklist) 通用 Skill 开发实战教程从需求到落地适用对象AI 技能开发新人核心目标掌握将模糊的自然语言需求转化为结构化、可执行代码逻辑的全过程并学会利用大模型LLM提效。第一阶段需求分析翻译官思维用户的一句话需求通常是模糊的开发者的第一步是将其“翻译”成系统能理解的精确参数。1.1 拆解“隐形”参数用户只会说核心诉求如“帮我查昨天的数据”但系统执行需要 4 个维度的明确指令。你需要建立一个**“参数补全机制”**维度用户没说清楚的模糊系统必须确定的精确解决方案策略时间“昨天”、“上个月”具体日期范围 (YYYY-MM-DD)基于当前时间进行相对计算主体“我们供电所”、“那个台区”具体的组织/对象编码读取用户上下文或默认配置标准“异常的”、“有问题的”具体的数学判定公式加载业务规则库阈值/逻辑范围未指定查询粒度按日/按月设定默认值允许用户覆盖1.2 确立规则优先级业务规则往往不是单一的新人必须理解**“规则的层级”**。在代码中你需要按以下优先级加载配置会话级规则最高用户本次对话中临时指定的如“这次按 5% 算”。用户级规则中用户个人偏好中保存的长期设置。系统级规则兜底全系统通用的默认标准。 教学提示告诉新人永远不要写死阈值要设计成可配置的逻辑链。第二阶段数据策略设计架构师思维在写代码前先设计数据怎么拿。这是新人最容易犯错的地方重点在于**“查询策略”与“工具限制”**的博弈。2.1 明确数据源列出所有涉及的“表”或“对象”主表存放核心指标必须查。维表/配置表存放辅助判定信息按需查。2.2 规避工具陷阱关键大多数底层查询工具如 MCP、SQL对逻辑操作符的支持是有限的。陷阱试图在一个查询中同时满足互斥条件例如A 10或A 0。策略分治法。如果工具不支持OR逻辑必须拆分为多次查询。查询 A获取满足条件 1 的数据集。查询 B获取满足条件 2 的数据集。代码层在内存中合并结果。2.3 查询模式选择模式 A数据库过滤如果阈值是固定的直接在查询条件Conditions中写死让数据库返回结果效率高。模式 B本地计算如果判定逻辑复杂涉及多表关联或动态计算先查出全量数据再在代码中进行遍历判定灵活但慢。第三阶段与大模型协作开发提效核心不要从零开始写代码。将大模型LLM视为你的“结对编程伙伴”让它帮你完成从草稿到优化的全过程。3.1 让大模型写第一版草稿当你明确了需求和数据结构后不要急于动手。将你的分析结果整理成清晰的提示词Prompt让大模型生成初始代码。提示词结构建议角色设定“你是一名资深的 Skill 开发工程师。”任务描述“请帮我编写一个用于查询[具体业务]的 Skill。”输入输出定义“输入参数包括 A、B、C输出为一个 JSON 格式的查询列表。”业务规则“核心判定逻辑是如果 X 大于 Y则为异常。”技术约束“请使用 MCP 查询协议属性名必须用中文。”示例“请帮我写一个查询技能。需求是找出线损异常的台区。输入是日期和供电所编码。异常分为两种1. 负损线损率 02. 高损线损率 阈值。请生成两个独立的 MCP 查询 JSON分别对应高损和负损。”3.2 代码审查与逻辑优化大模型生成的代码是“草稿”可能存在逻辑漏洞。你需要扮演“审查者”的角色重点检查以下几点边界条件问大模型“如果查询结果为空怎么办如果阈值是动态的你的代码能处理吗”性能陷阱问大模型“这个查询如果数据量达到 10 万条会不会很慢有没有优化方案”安全性问大模型“这段代码是否存在注入风险用户输入的参数是否都经过了校验”优化技巧将大模型的输出复制到你的编辑器中然后反过来问它“请解释一下你生成的这段代码的逻辑特别是第 X 行。” 这能帮你快速理解并发现潜在问题。3.3 生成测试用例让大模型帮你思考你没想到的场景。提示词示例“针对刚才编写的查询技能请列出 5 个必须测试的边界场景并给出每个场景的输入数据和预期输出。”大模型可能会给出场景查询未来日期。预期提示“数据未生成”。场景供电所编码不存在。预期提示“单位不存在”。场景高损和负损阈值为 0。预期正确返回所有非零线损的台区。第四阶段接口实现与规范工程师思维编写具体的查询语句如 JSON 格式的 MCP 调用时必须遵守严格的工程规范。4.1 查询前的“三问”每次发起请求前代码逻辑必须自检属性名对吗严禁臆造字段必须调用元数据接口如ontology_list_attributes确认真实属性名。编码有了吗用户输入的是“名称”数据库需要的是“ID/编码”必须做转换。权限够吗是否通过了身份鉴权4.2 查询语句的“铁律”在编写查询 JSON 时强制遵守以下规范语言统一属性名必须使用系统定义的语言如全中文严禁混用英文或数据库物理字段名。结构严谨条件字段Conditions即使为空也必须是数组[]绝不能传null或字符串防止解析报错。防御性编程时间格式严格校验YYYY-MM-DD月份查询必须补全为YYYY-MM-01。分页限制必须显式传递limit参数如 500防止默认值过小导致数据截断。第五阶段结果呈现与异常处理产品思维代码跑通只是第一步如何优雅地展示结果和处理错误才是区分新手和熟手的标准。5.1 输出标准化不要直接打印原始数据要进行格式化数值格式金额/电量保留 2 位小数比率带%状态码转为人类可读文本。结构化展示摘要一句话总结共发现 X 个其中 Y 个严重。列表关键信息表格化。5.2 异常分支处理表新人必须预设以下场景并编写对应的提示语场景处理逻辑用户提示语示例无数据检查时间是否太早T1延迟“数据通常次日生成建议查询昨天及以前的数据。”查无此对象名称匹配失败“未找到该单位是否指[候选列表]”结果截断返回数量达到 Limit 上限“结果较多仅展示前 500 条请缩小查询范围。”查询失败接口报错“系统繁忙正在重试… 若仍失败请联系管理员。”附录新人自检清单 (Checklist)在提交代码前请对照此表打钩参数解析是否处理了相对时间如“昨天”规则加载是否实现了“会话-用户-系统”三级优先级查询拆分互斥条件是否拆分成了多次查询AI 协作是否让大模型生成了初稿并进行了逻辑审查测试用例是否让大模型生成了边界测试场景并已通过属性验证是否通过元数据接口确认了字段名格式规范Conditions 是否为数组Limit 是否显式指定边界测试是否测试了“无数据”和“数据量巨大”的情况总结开发一个 Skill本质上是在做**“翻译”需求转参数、“拆解”复杂逻辑转多次查询和“兜底”**异常处理。而学会与大模型协作则是为你的开发过程装上了“涡轮增压”。掌握这套流程你就能高效、高质量地开发任何领域的技能。