AI 工具构建

这个方法解决什么

当你准备让模型或 Agent 承担一个工具级任务时，最常见的问题不是“不会写代码”，而是需求、架构、评测和交付边界不清：没有基线就不知道新工具是否真的改进；形态从 Prompt 到 Plugin、MCP 摇摆不定；脚本缺少约束，容易产生副作用、覆盖目标或硬编码路径与密钥；构建完成后没有完整校验，问题被拖到使用阶段。这个技能把“从需求到可评估工具”的流程固定下来。

技能的核心工作

启动阶段会读取 references/build-patterns.md、design.md、研究简报、Excel 指标字典和 evals/evals.json；如果工具形态尚未确定，再读取 references/develop-references/artifact-decision.md，避免过早进入编码。

S5：先建基线和评测集。 开发前记录不使用新工具时的完成率、耗时、错误和缺失字段；准备至少 5 个正向触发、5 个负向触发、3 个边界场景；为关键输出定义可机器检查的断言；明确安全红线、拒绝行为或降级行为。用例应来自真实任务类型，但要脱敏，不能只写“结果应该很好”。

S6：选择最小充分架构。 单次、短、无复用可采用 Prompt；固定项目规则采用 Project Instructions 或 AGENTS.md；可复用知识或工作流采用 Skill；多个相关 Skill、脚本、模板或连接能力采用 Plugin；必须访问外部系统或实时数据时才采用 MCP，并单列认证与权限。决策理由和未选方案要写进 design.md。

S7：实现 MVP。 Skill 使用平台 Skill Creator 或官方脚手架，名称使用小写连字符并保持目录同名；description 需要说明做什么、何时触发、何时不触发；SKILL.md 只保留核心流程，长知识放入 references/，确定性操作放入 scripts/，模板和非上下文资源放入 assets/。Plugin 使用 Plugin Creator 或官方脚手架，根目录与 manifest name 一致，manifest 明确版本、描述、Skills 和界面元数据；一个 Plugin 只承载同一类用户任务；未授权时不写 Marketplace 或执行安装。脚本默认非破坏性，已有目标拒绝覆盖；支持 --help，涉及写入时尽量支持 --dry-run；返回稳定退出码；不硬编码密钥、客户信息和个人绝对路径；每个新增脚本都必须实际运行并加入测试。

构建完成后立即解析 JSON/YAML，运行官方 Skill 和 Plugin 校验器、脚本单元测试，并在临时目录做初始化或生成冒烟；检查所有引用文件真实存在，把失败转成回归用例。最后向 evaluate-ai-tool 交接源码路径和版本、架构决策、基线与评测集、已运行命令及结果、已知限制，以及真实宿主是否验证。

适用边界与注意点

这里提供的是构建流程，不是需求替代品。Excel 指标字典、评测集、真实任务样本和宿主环境信息需要由项目实际提供。MCP 涉及外部系统时，认证、权限和实时数据质量仍需单独设计。临时目录冒烟和官方校验能降低回归风险，但不等同于生产验证。