技能介绍

在 AI 工具开发中，最常见的问题不是「能不能写代码」，而是如何把模糊的需求推进到一个真正可用的产品。很多团队意识到「生成了一段代码」和「交付了一个可用工具」之间还有巨大的鸿沟，却缺乏系统化的方法来跨越。

具体来说：

这个技能将开发过程划分为 S0-S11 的 12 个阶段门（Stage Gates），每个阶段都有明确的交付物和进入下一阶段的门槛。

启动时先确认五项最小信息：

缺少会改变产品形态或授权边界的信息时，一次性问完，而不是在开发过程中不断追问。

如果工作区已存在，技能会先读取 design.md、plan.md 和 stage-status.json，从当前闸门继续，不重复已完成的工作。

这个阶段转入 research-ai-tool 流程：

研究未完成时不得进入正式架构定稿，低成本原型必须标明「探索性」。

转入 build-ai-tool 流程：

转入 evaluate-ai-tool 流程：

技能会分开报告：

这个技能明确不做什么：

这些边界确保工具开发过程中的合规性和安全性，避免在自动化流程中引入风险。

截图预览

{'zh': '已有工作区但没有设计文档，需要补齐 S0-S1 的风格与权限边界后再继续开发 AI 工具', 'en': 'Workspace exists but lacks design docs; need to define style and permission boundaries for S0-S1 before continuing AI tool development.'}
{'zh': '已经生成脚本但未真实运行，需要建立正反向用例并做行为闸门验证后才能打包', 'en': 'Scripts are generated but must still run actual positive/negative queries to reach behavioral correctness before packaging.'}
{'zh': '研究阶段还没有完成，需要先收集官方规范和同类产品，再填写指标模板以决定架构是否定稿', 'en': 'Before finalizing architecture, collect standards and comparable tools, then fill the metrics sheet to decide the path.'}
{'zh': '评测时发现静态检查通过但宿主上的用户不会实际触发，需要补充真实触发路径而不是用平均分掩盖', 'en': 'Static pass shows up in review but real host-trigger fails; add raw-output checks instead of averaging across metrics.'}

{'zh': 'AI 产品工程师：要把业务需求推进成可测试、可交接的工具，而不是只生成一堆文件', 'en': 'AI product engineer: needs to turn business requirements into testable, handoff-worthy tools rather than just generate files.'}
{'zh': '内部工具项目负责人：需要向评审方分别报告已实测、待验证、未执行项，证明没有把静态通过当运行时通过', 'en': 'Internal tool lead: needs to report verified, pending, and unexecuted items separately to demonstrate that static passing is not runtime passing.'}
{'zh': '技术交付 PM：需要在测试阶段前建立研究简报、信源台账和指标字典，这样才能判断 go/no-go', 'en': 'Technical PM: needs research briefs, source ledgers, and metric dictionaries before test phases, only then can decide go/no-go.'}
{'zh': '平台团队的架构评审人：需要检查工具是否遵守数据与权限边界、是否使用官方脚手架并保留校验报告', 'en': 'Platform reviewer: needs to check whether tools respect data and permission boundaries, use official scaffolds, and retain verification reports.'}