analyze-nuedc-task

name	analyze-nuedc-task
description	将全国大学生电子设计竞赛（电赛/NUEDC）及类似嵌入式、机器人、测控、电源、信号赛题编译成可执行工程任务：拆解得分路径，识别系统闭环和一至两个主矛盾，生成基础方案骨架、第一版 MVP、Codex 工程任务书、观测变量、验证门槛、非代码问题和停止条件。用于用户提供赛题 PDF、图片、文字或评分规则，要求分析赛题、规划实现、确定先做什么，或在生成代码前形成任务书时。

赛题到工程任务编译器

把任意赛题稳定压缩成：“先做什么、为什么先做、做到什么算过、下一步交给谁做”。

本 Skill 不直接替用户实现完整赛题，也不输出泛泛的风险文章。默认交付一份可以继续交给 Codex、硬件、机械和测试人员执行的工程任务包。

核心原则

• 先拆得分路径，再讨论技术方案。
• 先识别闭环，再映射代码模块。
• 主矛盾只能保留一至两个：若不解决，后续写再多代码也无法让项目成立。
• 第一版必须验证主矛盾，不追求完整比赛流程。
• 日志、验证门槛和停止条件必须与方案同时设计。
• 明确区分代码问题、硬件问题、机械问题、标定问题和测试方法问题。
• 区分 赛题事实、用户已确认条件、合理推断、待确认项，不得把推断写成事实。
• 对非赛题规定的次数、容差和成功率标注为“建议验证门槛”，不得伪装成评分要求。

固定分析流程

严格按以下顺序执行。不要用长篇风险枚举替代这些动作。

1. 编译评分路径

从评分规则反推工程优先级，输出：

层级	要回答的问题
共享必做闭环	被多个目标得分项共同依赖、没有它主要得分链不成立的能力是什么？
基础得分闭环	最快能稳定展示并拿到基础分的完整闭环是什么？
提高得分闭环	在基础闭环上增加哪些能力才能继续得分？
炫技但低优先级	哪些功能看起来高级，但目前不直接增加得分或稳定性？
AI 易误解点	哪些表述容易让通用智能体过度实现、漏掉限制或错误理解？

不要按赛题条目机械排序。找出得分项共享的前置能力和单点失败。最低分项目、共享必做闭环和推荐的首个原型可能是三件不同的事，必须分别判断。

2. 翻译为工程语言

把题目翻译成：

• 输入：传感器、测量对象、用户设定、比赛环境。
• 状态：系统必须知道或估计的量。
• 输出：执行器动作、测量结果、显示、通信或保护动作。
• 约束：尺寸、时间、精度、器件、操作和直接失败条件。
• 未知量：会改变系统方案或 MVP 的信息。

3. 识别五类闭环

对每类闭环说明目标、反馈量和闭环失败时的表现：

1. 感知闭环：是否可靠获得外界或对象信息。
2. 估计闭环：是否知道当前内部状态。
3. 控制闭环：是否能让系统状态或输出跟随目标。
4. 决策闭环：是否知道何时切换任务阶段。
5. 验证闭环：是否知道动作已正确完成。

某类闭环不适用于题目时，明确写“不需要”及原因。不要为了填表虚构闭环。

4. 判断一至两个主矛盾

主矛盾定义：

评分目标中最依赖现实物理耦合、最难靠纯代码补救，并且不解决就无法继续构建得分链的环节。

主矛盾优先出现在两个闭环、两个物理域或两个任务阶段的交接处，例如感知到控制、运动到瞄准、无标记导航到路径跟踪、功率级到采样闭环。不要把“直线控制”“圆弧循迹”“云台 PID”“电源效率”等独立模块能力直接命名为主矛盾，除非该模块本身的物理可行性尚未成立且确实阻断主要得分链。

每个主矛盾只回答：

• 它阻断哪条得分路径？
• 为什么现有信息不足以证明它可行？
• 最便宜、最快的否定性实验是什么？
• 实验失败后，应改代码、硬件、机械、标定还是方案？

不要把普通模块工作、通用风险或“需要调 PID”列为主矛盾。最多保留两个。

5. 生成基础方案骨架

先生成系统结构，再谈文件和代码：

层	内容
输入层	传感器、测量对象、用户输入
估计层	从输入得到的系统状态
控制层	根据目标和状态产生控制量
执行层	电机、云台、继电器、PWM、DAC、通信等
决策层	任务阶段、状态切换、异常降级
记录层	为调试和验收记录的关键数据

说明子系统之间的数据流，并标出第一版启用哪些部分、暂缓哪些部分。

6. 定义第一版 MVP

区分两个原型，不得自动把最低分项目当作主矛盾原型：

• MVP-0 主矛盾验证原型：最便宜地证明或否定主矛盾，可以不直接得分。
• MVP-1 最小得分闭环：在 MVP-0 通过后，最快形成可展示、可得分的完整闭环。

MVP-0 必须同时满足：

1. 能实际运行或测量。
2. 能验证主矛盾。
3. 不追求完整得分。

两个原型都使用固定输出：

• 原型目标
• 暂时不做
• 需要完成的闭环
• 需要记录的数据
• 测试方法
• 建议验证门槛
• 失败后优先排查顺序

若一个 MVP 同时验证过多未知项，将它继续缩小。

7. 生成 Codex 工程任务书

默认将 MVP-0 翻译为可以直接交给编程智能体的任务，不直接实现代码。若 MVP-0 主要是机械、硬件或测试实验，则任务书只要求 Codex 实现必要的数据采集、控制和日志支撑，不强行把实验变成软件项目。

任务书必须包含：

项目目标：
第一版功能范围：
输入：
输出：
模块及职责：
模块接口：
最小状态机/执行流程：
必须打印或记录的日志：
验收测试：
禁止实现的功能：
停止并询问用户的条件：

模块应从闭环和职责导出，不要先从 motor.c、pid.c 等文件名出发。接口信息不足时写出接口需求，不编造型号、引脚、单位或参数。

8. 设计观测变量与阶段门槛

观测变量必须能定位“第一个失效环节”，至少覆盖：

• 当前目标和任务状态
• 关键传感器原始量与处理结果
• 关键估计状态
• 控制误差和控制输出
• 状态切换原因
• 完成、超时、保护和异常标志

阶段门槛遵循：

1. 基础硬件可控、数据可信。
2. 单个核心闭环稳定。
3. 两个闭环串联稳定。
4. 完整基础流程在保守条件下跑通。
5. 最后才优化速度、精度、效率或发挥项。

每个门槛写明测试条件、通过判据和未通过时不得继续的工作。

9. 分类非代码问题与停止条件

输出：

• 代码能直接解决的问题
• 必须通过硬件解决的问题
• 必须通过机械或传感器布局解决的问题
• 必须通过标定解决的问题
• 必须通过测试方法解决的问题

出现以下情况时停止生成完整代码，只输出待确认项或验证任务：

• 评分路径、路线或操作规则不清楚。
• 关键传感器、执行器、接口或器件能力不清楚。
• 主矛盾尚未通过 MVP 证明可控。
• 没有观测变量和日志方案。
• 没有实测数据却要求最终 PID、滤波器、阈值或保护参数。
• 机械、供电或信号完整性问题被错误地要求仅靠软件补救。

默认输出契约

默认使用 engineering-task-package.md 的九段结构，保持简洁、可执行：

1. 得分路径
2. 工程语言翻译
3. 五类闭环
4. 一至两个主矛盾
5. 基础方案骨架
6. 第一版 MVP
7. Codex 工程任务书
8. 观测变量与验证门槛
9. 非代码问题与停止条件

风险、失败模式和动态耦合用于支持主矛盾与 MVP 决策，不单独堆成长列表。需要发现候选耦合时读取 risk-checklist.md，只保留会改变得分路径、MVP 或任务书的内容。

用户明确要求完整分析文档时，可以展开解释；否则优先交付短而完整的工程任务包。

完成标准

只有以下条件全部满足才算完成：

• 已明确基础分与提高分的得分路径。
• 已识别适用的系统闭环。
• 已将主矛盾收敛为一至两个闭环交接或物理耦合问题。
• 已生成一套基础方案骨架，并区分 MVP-0 主矛盾原型与 MVP-1 最小得分闭环。
• 已生成可直接交给 Codex 的工程任务书。
• 已设计能够定位首个失效环节的观测变量。
• 已定义进入下一阶段的验证门槛。
• 已区分代码与非代码问题，并给出停止条件。