| name | analyze-nuedc-task |
| description | 将全国大学生电子设计竞赛（电赛/NUEDC）及类似嵌入式、机器人、测控、电源、信号赛题编译成可执行工程任务：拆解得分路径，识别系统闭环和一至两个主矛盾，生成基础方案骨架、第一版 MVP、Codex 工程任务书、观测变量、验证门槛、非代码问题和停止条件。用于用户提供赛题 PDF、图片、文字或评分规则，要求分析赛题、规划实现、确定先做什么，或在生成代码前形成任务书时。 |
赛题到工程任务编译器
把任意赛题稳定压缩成：“先做什么、为什么先做、做到什么算过、下一步交给谁做”。
本 Skill 不直接替用户实现完整赛题，也不输出泛泛的风险文章。默认交付一份可以继续交给 Codex、硬件、机械和测试人员执行的工程任务包。
核心原则
- 先拆得分路径，再讨论技术方案。
- 先识别闭环，再映射代码模块。
- 主矛盾只能保留一至两个：若不解决，后续写再多代码也无法让项目成立。
- 第一版必须验证主矛盾，不追求完整比赛流程。
- 日志、验证门槛和停止条件必须与方案同时设计。
- 明确区分代码问题、硬件问题、机械问题、标定问题和测试方法问题。
- 区分
赛题事实、用户已确认条件、合理推断、待确认项，不得把推断写成事实。
- 对非赛题规定的次数、容差和成功率标注为“建议验证门槛”，不得伪装成评分要求。
固定分析流程
严格按以下顺序执行。不要用长篇风险枚举替代这些动作。
1. 编译评分路径
从评分规则反推工程优先级，输出：
| 层级 | 要回答的问题 |
|---|
| 共享必做闭环 | 被多个目标得分项共同依赖、没有它主要得分链不成立的能力是什么？ |
| 基础得分闭环 | 最快能稳定展示并拿到基础分的完整闭环是什么？ |
| 提高得分闭环 | 在基础闭环上增加哪些能力才能继续得分？ |
| 炫技但低优先级 | 哪些功能看起来高级，但目前不直接增加得分或稳定性？ |
| AI 易误解点 | 哪些表述容易让通用智能体过度实现、漏掉限制或错误理解？ |
不要按赛题条目机械排序。找出得分项共享的前置能力和单点失败。最低分项目、共享必做闭环和推荐的首个原型可能是三件不同的事，必须分别判断。
2. 翻译为工程语言
把题目翻译成：
- 输入：传感器、测量对象、用户设定、比赛环境。
- 状态：系统必须知道或估计的量。
- 输出：执行器动作、测量结果、显示、通信或保护动作。
- 约束：尺寸、时间、精度、器件、操作和直接失败条件。
- 未知量：会改变系统方案或 MVP 的信息。
3. 识别五类闭环
对每类闭环说明目标、反馈量和闭环失败时的表现：
- 感知闭环：是否可靠获得外界或对象信息。
- 估计闭环：是否知道当前内部状态。
- 控制闭环：是否能让系统状态或输出跟随目标。
- 决策闭环：是否知道何时切换任务阶段。
- 验证闭环：是否知道动作已正确完成。
某类闭环不适用于题目时，明确写“不需要”及原因。不要为了填表虚构闭环。
4. 判断一至两个主矛盾
主矛盾定义：
评分目标中最依赖现实物理耦合、最难靠纯代码补救，并且不解决就无法继续构建得分链的环节。
主矛盾优先出现在两个闭环、两个物理域或两个任务阶段的交接处，例如感知到控制、运动到瞄准、无标记导航到路径跟踪、功率级到采样闭环。不要把“直线控制”“圆弧循迹”“云台 PID”“电源效率”等独立模块能力直接命名为主矛盾，除非该模块本身的物理可行性尚未成立且确实阻断主要得分链。
每个主矛盾只回答：
- 它阻断哪条得分路径？
- 为什么现有信息不足以证明它可行？
- 最便宜、最快的否定性实验是什么？
- 实验失败后，应改代码、硬件、机械、标定还是方案？
不要把普通模块工作、通用风险或“需要调 PID”列为主矛盾。最多保留两个。
5. 生成基础方案骨架
先生成系统结构，再谈文件和代码：
| 层 | 内容 |
|---|
| 输入层 | 传感器、测量对象、用户输入 |
| 估计层 | 从输入得到的系统状态 |
| 控制层 | 根据目标和状态产生控制量 |
| 执行层 | 电机、云台、继电器、PWM、DAC、通信等 |
| 决策层 | 任务阶段、状态切换、异常降级 |
| 记录层 | 为调试和验收记录的关键数据 |
说明子系统之间的数据流，并标出第一版启用哪些部分、暂缓哪些部分。
6. 定义第一版 MVP
区分两个原型，不得自动把最低分项目当作主矛盾原型：
MVP-0 主矛盾验证原型：最便宜地证明或否定主矛盾，可以不直接得分。MVP-1 最小得分闭环：在 MVP-0 通过后，最快形成可展示、可得分的完整闭环。
MVP-0 必须同时满足：
- 能实际运行或测量。
- 能验证主矛盾。
- 不追求完整得分。
两个原型都使用固定输出：
- 原型目标
- 暂时不做
- 需要完成的闭环
- 需要记录的数据
- 测试方法
- 建议验证门槛
- 失败后优先排查顺序
若一个 MVP 同时验证过多未知项，将它继续缩小。
7. 生成 Codex 工程任务书
默认将 MVP-0 翻译为可以直接交给编程智能体的任务，不直接实现代码。若 MVP-0 主要是机械、硬件或测试实验，则任务书只要求 Codex 实现必要的数据采集、控制和日志支撑，不强行把实验变成软件项目。
任务书必须包含：
项目目标：
第一版功能范围：
输入：
输出：
模块及职责：
模块接口：
最小状态机/执行流程：
必须打印或记录的日志：
验收测试：
禁止实现的功能：
停止并询问用户的条件：
模块应从闭环和职责导出，不要先从 motor.c、pid.c 等文件名出发。接口信息不足时写出接口需求，不编造型号、引脚、单位或参数。
8. 设计观测变量与阶段门槛
观测变量必须能定位“第一个失效环节”，至少覆盖：
- 当前目标和任务状态
- 关键传感器原始量与处理结果
- 关键估计状态
- 控制误差和控制输出
- 状态切换原因
- 完成、超时、保护和异常标志
阶段门槛遵循：
- 基础硬件可控、数据可信。
- 单个核心闭环稳定。
- 两个闭环串联稳定。
- 完整基础流程在保守条件下跑通。
- 最后才优化速度、精度、效率或发挥项。
每个门槛写明测试条件、通过判据和未通过时不得继续的工作。
9. 分类非代码问题与停止条件
输出：
- 代码能直接解决的问题
- 必须通过硬件解决的问题
- 必须通过机械或传感器布局解决的问题
- 必须通过标定解决的问题
- 必须通过测试方法解决的问题
出现以下情况时停止生成完整代码，只输出待确认项或验证任务：
- 评分路径、路线或操作规则不清楚。
- 关键传感器、执行器、接口或器件能力不清楚。
- 主矛盾尚未通过 MVP 证明可控。
- 没有观测变量和日志方案。
- 没有实测数据却要求最终 PID、滤波器、阈值或保护参数。
- 机械、供电或信号完整性问题被错误地要求仅靠软件补救。
默认输出契约
默认使用 engineering-task-package.md 的九段结构，保持简洁、可执行：
- 得分路径
- 工程语言翻译
- 五类闭环
- 一至两个主矛盾
- 基础方案骨架
- 第一版 MVP
- Codex 工程任务书
- 观测变量与验证门槛
- 非代码问题与停止条件
风险、失败模式和动态耦合用于支持主矛盾与 MVP 决策，不单独堆成长列表。需要发现候选耦合时读取 risk-checklist.md，只保留会改变得分路径、MVP 或任务书的内容。
用户明确要求完整分析文档时，可以展开解释；否则优先交付短而完整的工程任务包。
完成标准
只有以下条件全部满足才算完成：
- 已明确基础分与提高分的得分路径。
- 已识别适用的系统闭环。
- 已将主矛盾收敛为一至两个闭环交接或物理耦合问题。
- 已生成一套基础方案骨架，并区分 MVP-0 主矛盾原型与 MVP-1 最小得分闭环。
- 已生成可直接交给 Codex 的工程任务书。
- 已设计能够定位首个失效环节的观测变量。
- 已定义进入下一阶段的验证门槛。
- 已区分代码与非代码问题，并给出停止条件。
