用途：把一个想法或功能点转化为可测试的概念验证（POC）。它回答三个问题：这件事能不能做？证明它所需的最小实验是什么？在真正开发之前需要哪些证据？
主要能力：委托给以研究为导向的工程代理，产出可行性结论（继续／迭代／停止及理由）、最小实验步骤、可观察的成功标准或通过／失败判据、主要风险与假设、必要的代码草图或配置等最小工件，以及实验成功、失败或无结论时的后续动作。
使用方式：需要提供问题陈述或想法、约束条件（截止时间、平台、预算、依赖、合规）、已有代码或 API 与竞争方案、成功标准，以及文件、依赖或命令方面的限制；信息不足时只询问定义实验所需的最少信息。可参考的提示模式包括“设计一个 1-2 天的 POC 验证某方案是否满足某约束”“对比 A、B、C 三种方案并给出最小实验建议”“制定轻量基准计划并给出通过／失败标准”“为某服务／API 画一个最小集成验证草图”。
适用场景：想法模糊需要验证、需要比较多种方案、需要快速原型／基准／集成验证，或希望基于时间、成本、平台、风险等约束得到建议。
限制：不适用于需要生产级代码或完整加固的任务、问题常规且已被充分理解的情况，以及需要大范围重构而非狭窄实验的任务。该技能始终把调查委托给研究型工程代理，定位为研究与原型而非生产，偏好最小可行实验，工件保持精简易丢弃，并会标注 POC 相对生产环境省略了哪些环节；它不会把 POC 代码当作生产可用代码，不索要或存储密钥，避免大范围改动仓库，倾向使用模拟或样例数据而非敏感数据，并会指出缺失的验证、加固、测试与运维工作。