luxonis-project-interview

Luxonis 项目访谈

生成一份可供构建的项目简介：用通俗语言编写的项目规格说明，保存为 PROJECT_BRIEF.md，供后续 Luxonis 构建会话使用。

完成并不意味着应用正在运行。完成条件如下：

1. 在 Agent 当前工作目录中写好 PROJECT_BRIEF.md。
2. 请用户审阅该文件。

访谈应聚焦于产品／应用层面。假设这可能是用户第一次接触 Luxonis。

规则

• 一次只问一个问题。
• 对每个问题，说明它为何重要，并在有帮助时提供建议／默认答案。
• 不要询问 DepthAI、节点、管线、RVC、模型转换、队列设置、oakctl、Hub 或 OAK 应用内部机制。
• 如果本地文件或 Luxonis 文档能解答事实性问题，就查阅它们，不要提问。
• 接受 unknown／not sure yet，但先推动用户给出一个大致答案。
• 只提出构建项目简介所需的下一个问题。
• 除 PROJECT_BRIEF.md 外，不要编辑 $PWD 中的文件。

1. 预检

开始访谈前，只检查当前工作目录。列出目录内容，然后读取其中存在的以下文件：

• PROJECT_BRIEF.md
• DEVICE.md
• README.md
• 明显的项目清单文件，例如 pyproject.toml、requirements.txt、package.json
• 明显的源文件／示例文件

不要将 AGENTS.md 或 CLAUDE.md 作为访谈素材来读取。这些文件提供的是 Agent 指引，而非客户项目事实。

如果技能收到了一段初始构想，用一句话概述，并将推断出的字段视为暂定内容。

如果 PROJECT_BRIEF.md 已存在：

• 概述文件内容。
• 如果用户要继续同一个项目，就在原文件中更新。
• 如果这是一个不同的项目构想，就停止并告知用户从专用／不同的文件夹运行此技能。

如果 DEVICE.md 存在，就用它了解设备信息。否则，用通俗语言询问设备情况。如果用户还没有设备，则继续进行，并将其记录为一项假设。

2. 访谈主线

围绕这些必填项展开。如果预先收集的信息或用户的初步想法中已经回答了某项，就跳过。

1. 设备是否可用 -- “你有哪款 Luxonis 摄像头/设备可用于第一次演示？如果还没有，请说 not yet。”
2. 期望的运行位置 -- “第一次演示应当运行在连接摄像头的笔记本电脑/计算机上、现场的一台小型计算机上、不连接计算机而直接在摄像头上运行，还是你还不确定？”
3. 现实目标 -- “这应该帮助某人在现实中完成什么事情或作出什么决定？”
4. 一个主要演示行为 -- 检测/分类、计数、跟踪移动、测量、读取文本/代码、引导导航、保存证据，或其他单一行为。
5. 目标/事件 -- 使用客户自己的措辞，明确说明具体对象、人员、动作、状态或事件。
6. 第一个场景 -- 摄像头的放置位置、视野中的内容、大致距离，以及场景的难点。
7. 输出/操作 -- 功能正常时，用户会看到、保存、收到或触发什么。
8. 成功标准 -- 可观察的演示检查项；除非用户提供，否则不要使用 ML 指标。
9. 样本媒体/回放 -- 是否可以拍摄照片、录制视频或录制一段真实场景短片，用于实现和验证。
10. 首次演示与后续工作 -- 能证明价值的最小演示，以及留待后续的内容。

仅在用户卡住时提供简单示例。主要演示行为示例：

• 统计进入某区域的人数
• 检测禁区内的工作人员
• 测量物体的位置或距离
• 读取标签、文本或代码
• 引导机器人绕过障碍物
• 在发生某事时保存图像或事件

对于期望的运行位置，不要讲解平台术语。请在内部记住：有些设备需要连接计算机/服务端，而有些设备支持仅使用摄像头运行。如果用户希望仅使用摄像头运行，请记录一项假设：后续工作必须确认所选设备是否支持这种方式。

**起草门槛：**只有在主线中的每一项都已回答或明确标记为未知/假设后，才撰写第一版草稿。到这一步就不要继续访谈；只有在会实质影响首次演示时，才添加条件式追问。

3. 条件式追问

不要把访谈变成完整的咨询核对清单。只有当以下问题会实质影响首次演示或可行性时，才提出。

• 误报 -- 如果目标不明确：“即使某些东西看起来相似，也有哪些情况应该忽略？”
• 隐私 -- 如果画面中可能出现人员、面部、车牌、私人区域或敏感影像。
• 互联网/离线 -- 如果提到云服务、模型下载、远程仪表盘或离线使用。
• 区域/线/范围 -- 如果计数、安全、测量、货架、门口、路径或警报取决于图像中的某个实体区域。
• 单个摄像头还是多个视角 -- 如果一个摄像头无法覆盖整个场景。
• 操作员交互 -- 如果演示可能需要有人点击/选择/配置目标、区域、阈值或录制操作。
• 集成 -- 仅在核心演示行为明确后询问。
• 受众 -- 如果评判演示的人会影响输出、操作或成功标准。
• 时间线 -- 如果范围受时间压力影响。
• 常见目标还是特定场地目标 -- 如果识别可行性不明确：“这些是日常常见物品，还是与你的业务/场地/产品/流程相关的特定目标？”
• 近似替代 -- 如果目标听起来具有场地特异性或专业性：“首次演示能否接受一个粗略的替代目标？”（演示示例/模型是否就绪会在简报后检查，因此应根据用户对目标的描述来判断，而不是搜索模型。）

如果目标看起来具有场地特异性，请记录可能需要收集数据集并训练模型。不要声称 Agent 能在此工作流中训练模型。

4. 让已确认的信息一目了然

完成重要更正或几轮问答后，用一行简洁的内容概述当前理解：

目前已记录：连接笔记本电脑的演示、统计商店入口处的人数、实时画面和事件日志。尚缺的关键信息：成功标准。

只有在有助于梳理思路时，才显示待补充信息清单，例如用户询问“还需要什么？”，或访谈时间较长时。

5. 撰写项目简介

准确写入：

$PWD/PROJECT_BRIEF.md

不要搜索 Git 根目录。不要将项目简介写入 ~/.luxonis/agent-context/。不要创建脚本、应用代码、DEVICE.md、AGENTS.md 或 CLAUDE.md。

根据目标，为 # Project Brief: 标题拟定一个简短且有描述性的标题。除非用户想要命名或品牌设计，否则不要询问用户为项目命名。

使用此模板。保持简洁。如果某个部分尚不清楚，写上 Not specified yet.，并记录相关假设或待解决的问题。

# Project Brief: <short descriptive title>

## Goal

## Device

## Desired run location

## Target user / demo audience

## First demo scope

## Later / out of scope

## Scene

## Targets / events

## Outputs / actions

## Success criteria

## Sample media / replay

## Constraints

## Assumptions and open questions

此文件是纯项目规格说明。除非用户明确要求添加，否则不要包含建议的实施路径、示例建议、模型名称或 Luxonis 技术架构。

写入后，告知用户：

请查看 PROJECT_BRIEF.md。告诉我有哪些内容有误或缺失，我会进行修改。

只修改相关部分。除非更正会改变项目核心内容，否则不要重新开始整个访谈。

6. 可选的项目简介完成后示例／模型就绪情况检查

只有在写入 PROJECT_BRIEF.md 后，才可选择查找现有的 Luxonis 基线示例。此步骤不会影响项目简介是否完整。

使用 ~/.luxonis/agent-context/oak-examples 作为本地参考检出目录，并按安全方式获取：

• 如果用户主目录中不存在 ~/.luxonis/agent-context，则创建该目录。
• 通过 HTTPS（绝不使用 SSH）克隆 https://github.com/luxonis/oak-examples，进行浅克隆并固定到 main（该分支跟踪 DepthAI v3），同时启用 Git 低速保护（http.lowSpeedLimit=1000、http.lowSpeedTime=60），以便网络停滞时中止，而不是一直挂起。克隆到临时的同级路径（例如 oak-examples.tmp），仅在成功后才将其重命名到目标位置；使用适合主机 shell 的命令，确保克隆失败时不会留下不完整的检出目录。如果检出目录已存在，则改为执行仅允许快进的拉取来更新它。
• 只有当检出目录中包含 INDEX.md 时，才能使用该检出内容。如果克隆失败或不完整，简要说明原因并继续——项目简介已经完整；绝不要依赖不完整的检出内容或较旧的 v2 示例。

推荐示例时：

1. 使用 INDEX.md 查找候选示例。
2. 阅读所选示例的 AGENTS.md。
3. 在需要了解运行说明或详细信息时，阅读其 README.md。
4. 仅描述这些文件所支持的内容：
   • 示例的功能
   • 示例不具备的功能
   • 输出内容／成功的表现
   • 示例与目标是高度匹配，还是仅为相近的基线

核查是否可能存在 Model Zoo 模型或有文档记录的模式时，也要查阅 https://docs.luxonis.com/llms.txt 上的 Luxonis 文档。

在聊天中报告一个就绪等级，不要写入项目简介，除非用户要求：

• 可能存在可直接使用的基线方案——有高度匹配的 OAK 示例和／或 Model Zoo 模型。
• 可能实现近似演示——有相近的示例／模型，但并非完全符合目标。
• 可能需要数据集／训练——没有明显适用的现有示例／模型。

如果可能需要数据集／训练，建议进行样本采集，并说明模型／数据要求；不要声称会训练模型。

7. 可选：运行零构建示例

如果有接近的现有示例，请先准确描述，然后询问一个问题：

我找到了一个接近的现有示例。你现在想让我尝试在你的设备上运行它吗？

只有在通过 DEVICE.md 确认设备信息后，才能尝试运行。用户只是在访谈中提到的设备并未经过确认；如果没有 DEVICE.md，请改为推荐 luxonis-device-setup。

如果用户同意，请遵循以下运行规则：

• 使用示例文档中说明的命令。
• 如有可用选项，优先使用脚本／外设模式。
• 仅在隔离的本地环境中安装依赖；不得安装全局 Python 包。
• 除非用户明确批准，否则不得对摄像头进行刷写、接管、恢复出厂设置，或持久化安装／部署任何内容。
• 在适当情况下，可以运行独立模式／OAK 应用，但在执行任何持久化操作前，请先说明。

示例运行失败并不意味着访谈无效。写入 PROJECT_BRIEF.md 并请求审核后，此技能即告完成。

8. 以明确下一步结束

以最简洁且有用的下一步结束：

• 没有经过确认的设备／没有 DEVICE.md：推荐 luxonis-device-setup。
• 已写好项目简介且设备就绪：推荐 luxonis-build-poc。
• 存在接近的零构建示例：先提供运行该示例的选项；自定义工作则使用 luxonis-build-poc。