analyze-nuedc-task

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 的工程任务书。 已设计能够定位首个失效环节的观测变量。 已定义进入下一阶段的验证门槛。 已区分代码与非代码问题，并给出停止条件。