| name | engineering-problem-gate |
| description | 企业内项目级问题门禁与 AI 交付入口 skill。工程师使用 Cursor 或 agent 处理任务时，先用第一性原理看透问题本质，再按最小必填字段完成问题定义，随后做结构化分解并判断是否进入闭环、是否满足 AutoResearch 启动条件。适用于数字、模拟、layout、软件、算法、测试、市场产品、现场支持等角色；提供轻量版与完整版两条路径，通用字段加角色扩展字段，贯穿需求、设计、实现、验证、交付全流程，并在关键节点保留 human-in-the-loop。目标是让工程师在借助 AI 前先想清楚问题，把任务送到“可设计、可拆分、可判断是否适合进入 AutoResearch”的状态。 |
Engineering Problem Gate
Purpose
本 skill 是企业内统一的问题门禁，也是 AI 交付链路的入口。
它不负责直接给方案或代码，而是负责：
- 先用第一性原理看透问题本质
- 再用最小必填字段把问题定义清楚
- 然后做结构化分解，把任务拆到 AI 易实现的颗粒度
- 最后判断是否进入闭环，以及是否达到
AutoResearch 的启动条件
- 全过程保留必要的 human-in-the-loop 节点
gate 的终点是“任务已可设计、可拆分、可判断是否适合进入闭环或 AutoResearch”，
而不是替代后续的方案设计、实现、验证或交付。
Positioning in AI Delivery Loop
本 skill 属于 AI Delivery Loop 的前两步入口：
See Through：把问题看透 —— 本 skill 主执行Structure：结构化分解 —— 本 skill 收尾Close the Loop：闭环迭代 / AutoResearch —— 本 skill 只做前置判断Accept and Deliver：人审验收 —— 本 skill 不替代
完整框架见 ai-delivery-loop.md；
阶段切换规则见 stage-transition-rules.md；
AutoResearch 定位见 autoresearch-positioning.md。
Language Support
- 当用户使用中文时，默认用中文执行这套流程并输出结果。
- When the user writes in English, apply the same workflow and respond in English.
- 当用户中英混合时，优先使用用户的主语言；必要时保留关键术语的中英文对应。
- 不因为语言不同而改变门禁标准、分解标准或验收标准。
Default Assumptions
- 这是项目流程中的强制门禁
- 关键字段缺失时，不允许跳到下一阶段
- 所有角色都先走通用字段，再补角色扩展字段
- 问题清楚后必须继续做结构化分解，不能把大任务整体丢给 AI
- 输出不仅服务当前任务，也服务后续
skill / harness 的沉淀判断
Use This Skill When
- 项目启动、需求进入、任务立项
- 新任务、模糊任务、需求澄清
- 方案前置讨论
- 实施前任务定义
- 验证前范围确认
- 交付前边界确认
- 讨论 agent 工作流、harness、skill、门禁、流程规范
Project Intake First
如果是新项目、新模块、新客户方向，或首次把本 skill 引入某个项目，先做项目背景采集，再进入具体任务门禁。
模板见 project-intake.md。
没有最基本的项目背景时，不要直接开始：
- 写方案
- 设计 skill / harness
- 拆实现任务
- 让 AI 直接执行
至少先拿到：项目目标、产品/技术背景、目标客户、当前阶段、可用资源、已有资料、关键约束、成功标准、AI 当前可访问的材料范围。
Phase Model
所有任务都必须先判断当前所处阶段：
需求/问题定义方案设计实现验证交付/支持
如果阶段未明确，默认停留在 需求/问题定义。
Gate Rules
- 先看透问题本质，再填写字段。
- 字段缺项时，先追问缺口，不直接推进。
- 不替用户脑补关键前提。
- 不把“问题定义、解决方案、实现细节”混为一谈。
- 只有字段足够完整且通过门禁，才允许进入下一阶段。
- 通过门禁后的默认下一步是结构化分解，不是实现。
- 闭环条件不满足时，不启动
AutoResearch。
- 关键节点保留 human-in-the-loop，不跳过人审。
- 讨论
skill / harness 时，先判断是否值得沉淀，不默认创建。
Two Paths: Lightweight or Full
根据任务规模选择路径：
轻量版（Lightweight）
适用场景：
- 新收到的模糊任务
- 还没正式立项的小问题
- 局部工作项
- 想先快速判断“这个问题值不值得展开”
4 步闭环：
- 用一句话重述问题
- 填最小必填字段（5 项）
- 判断门禁是否通过
- 决定下一步（继续澄清 / 进入分解 / 升级到完整版）
完整版（Full）
触发条件（出现任意一条即升级）：
- 涉及多个角色
- 涉及项目背景或客户背景
- 任务准备进入方案设计
- 任务准备交给 AI 批量推进
- 用户已经明确提到
skill / harness
完整版走下面的 Full Workflow。
Minimum Required Fields
不管轻量版还是完整版，第一次放行前必须补齐这 5 项：
任务目标当前现状已知约束成功标准未知项
缺一项，门禁一律不通过。
Full Workflow
按顺序执行，不跳步：
Step 0: 判断是否缺少项目背景
如果任务依赖项目背景但背景未建立，先暂停任务分析，转为采集项目背景（见 project-intake.md）。
Step 1: 第一性原理前置判断
在填任何字段前，先回答：
- 问题本质是什么
- 不可绕过的约束是什么
- 最小正确方向是什么
这三个问题答不上来，门禁一律不通过，转回继续澄清。
Step 2: 一句话定义当前任务
输出一句话，包含：
Step 3: 标记当前阶段
从五阶段模型中选一个，并说明理由。
Step 4: 填写最小必填字段
见上面的 Minimum Required Fields，5 项全部必填。
Step 5: 补充建议字段
当任务开始变复杂时，继续补：
这两项加最小必填 5 项，构成完整版的 7 个通用字段。
Step 6: 填写角色扩展字段
只有在任务进入具体角色语境时再补。
角色字段清单见 role-fields.md。
Step 7: 做三层拆分
把当前内容明确归类为：
三者若混在一起，必须重新归类后再继续。
Step 8: 判断门禁是否通过
见下面的 Gate Pass / Fail Conditions。
未通过时，下一步只能是 继续澄清。
Step 9: 做结构化分解
门禁通过后的默认下一步。
入口判断（必须都能回答，才开始拆）：
- 这个任务真正要交付的最小结果是什么？
- 当前最主要的限制条件是什么？
- 哪一部分最适合先交给 AI？
拆分原则：
- 每个子问题只解决一个核心目标
- 每个子问题都有清晰输入、输出和完成标准
- 每个子问题尽量减少隐含依赖
- 每个子问题应能由 AI 在单轮或少量轮次内稳定推进
- 仍然过大，继续拆
输出至少包含：问题本质、最小子问题集合、每个子问题的输入/输出、哪些子问题适合直接交给 AI。
更多分解方法见 decomposition-patterns.md。
Step 10: 闭环空间与 AutoResearch 判断
对每个子问题做两层判断：
- 是否已进入闭环空间（可以做局部收敛）
- 是否满足 AutoResearch 启动条件（更高门槛）
闭环 vs AutoResearch 的详细条件见 stage-transition-rules.md 与 autoresearch-positioning.md。
要点：
- 不是所有通过分解的任务都能进入闭环
- 不是所有闭环都应升级为
AutoResearch
AutoResearch 需要同时具备：明确修改对象、不可修改边界、可运行真实实验、固定评估指标、保留/丢弃/回退规则、结果记录方式
Step 11: 给出下一步
只允许输出一个主建议：
- 继续澄清
- 进入方案设计
- 进入结构化分解（尚未完成时）
- 进入实现
- 进入闭环迭代
- 启动 AutoResearch
- 进入验证
- 进入交付/支持
- 沉淀为 skill / harness
门禁未通过时，主建议只能是 继续澄清。
Step 12: 若涉及 skill / harness，做沉淀判断
当用户明确提到 skill、harness、流程固化、方法沉淀、规范化执行时，额外判断：
- 这是一次性上下文，还是稳定可复用模式
- 更适合做
skill、harness，还是两者组合
- 为什么这样设计是合理的
- 是否真的有助于加快项目推进，而不是增加流程负担
输出时明确回答：是否值得沉淀、建议沉淀形态、理由。
Gate Pass Conditions
只有同时满足下面 7 条，才算通过门禁：
- 第一性原理前置三问都有答案（问题本质、不可绕过的约束、最小正确方向）
任务目标 不是空话（不能只是“优化一下”“更智能一点”）当前现状 能说清问题发生在哪里（场景、对象或卡点）已知约束 至少有一条真实约束（时间、资源、技术、流程、客户、质量都算）成功标准 可检验（能回答“什么结果算完成”）未知项 被显式写出（不能假装没有未知）- 下一步动作不越级（问题没清楚时不能直接进入实现）
Gate Fail Conditions
只要出现下面任意一种，默认不通过：
- 问题本质回答不上来
- 任务目标过于空泛
- 成功标准无法验证
- 当前现状过于抽象
- 关键约束完全缺失
- 把问题定义、解决方案、实现细节混在一起
- 希望直接让 AI 开做，但上下文明显不足
Human-in-the-loop Checkpoints
以下节点必须人工确认，不允许纯 AI 通过：
- 问题本质是否成立
- 结构化分解是否合理
- 子问题是否真的进入闭环空间
- 某个闭环问题是否真的满足
AutoResearch 启动条件
- 候选方案是否满足关键约束
- 输出是否达到交付标准
Output Format
轻量版输出
## 第一性原理
- 问题本质：
- 不可绕过的约束：
- 最小正确方向：
## 当前判断
- 一句话定义：
## 最小必填字段
- 任务目标：
- 当前现状：
- 已知约束：
- 成功标准：
- 未知项：
## 门禁结论
- 是否通过：
- 缺口：
## 下一步
- 建议动作：
- 理由：
完整版输出
## 项目上下文
- 是否已完成项目背景采集：[是 / 否]
- 项目名称或代号：
- 项目当前阶段：
- 可用资料与资源：
- AI 可访问范围：
## 第一性原理
- 问题本质：
- 不可绕过的约束：
- 最小正确方向：
## 当前判断
- 角色：
- 当前阶段：[需求/问题定义 | 方案设计 | 实现 | 验证 | 交付/支持]
- 一句话定义：
## 通用字段
- 任务目标：
- 当前现状：
- 已知约束：
- 成功标准：
- 未知项：
- 影响范围：
- 下一步允许动作：
## 角色扩展字段
- [字段 1]：
- [字段 2]：
- [字段 3]：
## 三层拆分
- 问题定义：
- 解决方案：
- 实现细节：
## 门禁结论
- 是否通过：[通过 / 不通过]
- 缺口：
## 结构化分解
- 问题本质：
- 子问题 1：[目标 + 输入 + 输出]
- 子问题 2：[目标 + 输入 + 输出]
- 子问题 3：[目标 + 输入 + 输出]
- 适合直接交给 AI 的部分：
## 闭环与 AutoResearch 判断
- 哪些子问题已进入闭环空间：
- 哪些子问题满足 AutoResearch 启动条件：
- 哪些子问题还不适合：
## 人审点
- 本轮需要人工确认的节点：
## 下一步
- 建议动作：
- 理由：
## 沉淀判断（仅当涉及 skill / harness 时）
- 是否值得沉淀：
- 建议形态：
- 理由：
Asking Rules
追问时遵循以下顺序：
- 先补第一性原理三问
- 再补
任务目标
- 再补
成功标准
- 再补
已知约束
- 再补
当前现状 与 未知项
- 再补角色字段
- 最后确认
下一步允许动作
- 如果用户提到
skill / harness，补问“为什么要沉淀、复用对象是谁、希望约束哪一层”
一次只追最关键的 1 到 3 个缺口。
字段未齐时，不要直接开始设计实现方案。
看起来“任务说得清，但项目背景不清”时，优先追问项目维度：所属项目/客户、已有项目资料、可复用历史案例、AI 当前可用资源。
Harness vs Skill Split
用户讨论流程落地时，使用以下分工：
Harness
- 项目背景采集门禁
- 强制模板
- 强制回答
- 阶段记录
- 放行校验
- 分解后再放行
- 不通过时阻止越级
- 人审节点强制挂点
Skill
- 项目背景采集模板
- 字段解释
- 填写方法
- 第一性原理检查点
- 追问规则
- 示例模板
- 角色字段参考
- 结构化分解方法
- 闭环与 AutoResearch 判断方法
当目标是帮助工程师减少盲目性时，优先用本 skill 先证明“问题和方法已经稳定”；只有稳定后，再把规则下沉到 harness，或把方法沉淀成 skill。
Full-Lifecycle Usage
本 skill 贯穿全流程使用，但每一阶段关注点不同：
项目启动：先采集项目背景、资源、约束、成功标准、AI 可用资料需求/问题定义：先看透问题本质，再明确目标、边界、约束、成功标准方案设计：明确候选方案、取舍依据、接口边界，并完成结构化分解实现：明确输入输出、依赖、完成条件；必要时进入闭环或 AutoResearch验证：明确验证范围、通过标准、风险点交付/支持：明确交付物、影响范围、现场限制、回退方式
每次阶段切换，都应重新填一轮与当前阶段相关的字段。
如果某个模式在多个项目、多个角色、多个阶段中都重复出现，再考虑升级为正式 skill 或 harness。
如果问题还没被拆到 AI 易实现的颗粒度，不要急着进入实现或沉淀。
Example
Input
“我们要让所有工程师用 Cursor 时先按统一模板把问题说清楚，不分任务类型，必须回答完才能继续。角色很多，包括数字、模拟、layout、软件、算法、测试、市场产品和现场支持。最终希望通过这个模式，让工程师做出合理的 skill 或 harness，少走弯路。问题清楚后，还要帮他们把任务拆成 AI 容易完成的子问题。”
Output（完整版）
## 项目上下文
- 是否已完成项目背景采集：否
- 项目名称或代号：待确认
- 项目当前阶段：项目启动
- 可用资料与资源：待确认
- AI 可访问范围：待确认
## 第一性原理
- 问题本质：让工程师在借助 AI 前先想清楚问题，再把任务拆到 AI 可稳定执行的颗粒度。
- 不可绕过的约束：覆盖所有角色；必须强制模板与强制回答；必须贯穿项目全流程。
- 最小正确方向:先建立统一问题定义门禁，再做角色字段扩展和流程挂点。
## 当前判断
- 角色：项目流程设计者
- 当前阶段：需求/问题定义
- 一句话定义：需要建立面向全员工程师的 Cursor 问题定义门禁，统一模板、强制回答、贯穿项目全流程。
## 通用字段
- 任务目标：让工程师在进入方案或执行前，先完成结构化问题定义。
- 当前现状：全员配备 Cursor，但缺少统一入口，常在问题未定义清楚时直接推进执行。
- 已知约束：不区分任务类型；所有角色都要适用；必须强制模板和强制回答。
- 成功标准：所有角色都能用统一骨架完成任务定义；字段不完整时被拦下。
- 未知项：各角色最小扩展字段集；嵌入现有流程的具体节点。
- 影响范围：公司内多角色工程师及其项目协作流程。
- 下一步允许动作：进入方案设计。
## 角色扩展字段
- 目标岗位集合：数字、模拟、layout、软件、算法、测试、市场产品、现场支持
- 门禁强度：强制模板，强制回答
- 生命周期要求：贯穿需求、方案、实现、验证、交付
## 三层拆分
- 问题定义：如何建立统一的 Cursor 问题定义门禁
- 解决方案：通用字段加角色扩展字段的企业级 skill 与 harness 组合
- 实现细节：字段设计、校验逻辑、阶段切换规则
## 门禁结论
- 是否通过：通过
- 缺口：需要继续细化各角色扩展字段
## 结构化分解
- 问题本质：如何让工程师在使用 Cursor 时先想清楚问题，再把任务拆到 AI 可稳定执行的颗粒度。
- 子问题 1：设计全员通用字段
- 子问题 2：设计角色扩展字段
- 子问题 3：设计通过/不通过门禁规则
- 适合直接交给 AI 的部分：模板生成、字段整理、角色字段草案、流程文档初稿
## 闭环与 AutoResearch 判断
- 哪些子问题已进入闭环空间：子问题 1、2、3 在文档层面可收敛
- 哪些子问题满足 AutoResearch 启动条件：暂无（没有固定评估指标与自动回退机制）
- 哪些子问题还不适合：真实项目试点仍需人工验收
## 人审点
- 本轮需要人工确认的节点：角色字段最终版本、门禁规则是否真的能拦下越级推进
## 下一步
- 建议动作：进入方案设计
- 理由：目标、范围、门禁强度和适用对象已清楚，可以开始设计字段结构与流程挂点。
## 沉淀判断
- 是否值得沉淀：是
- 建议形态：skill + harness
- 理由：既需要统一方法模板，也需要流程级强制门禁，单独使用 skill 或 harness 都不够完整。
Self-Check
