Engineering problem gate

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

所有任务都必须先判断当前所处阶段：

1. 需求/问题定义
2. 方案设计
3. 实现
4. 验证
5. 交付/支持

如果阶段未明确，默认停留在 需求/问题定义。

Gate Rules

1. 先看透问题本质，再填写字段。
2. 字段缺项时，先追问缺口，不直接推进。
3. 不替用户脑补关键前提。
4. 不把“问题定义、解决方案、实现细节”混为一谈。
5. 只有字段足够完整且通过门禁，才允许进入下一阶段。
6. 通过门禁后的默认下一步是结构化分解，不是实现。
7. 闭环条件不满足时，不启动 AutoResearch。
8. 关键节点保留 human-in-the-loop，不跳过人审。
9. 讨论 skill / harness 时，先判断是否值得沉淀，不默认创建。

Two Paths: Lightweight or Full

根据任务规模选择路径：

轻量版（Lightweight）

适用场景：

• 新收到的模糊任务
• 还没正式立项的小问题
• 局部工作项
• 想先快速判断“这个问题值不值得展开”

4 步闭环：

1. 用一句话重述问题
2. 填最小必填字段（5 项）
3. 判断门禁是否通过
4. 决定下一步（继续澄清 / 进入分解 / 升级到完整版）

完整版（Full）

触发条件（出现任意一条即升级）：

• 涉及多个角色
• 涉及项目背景或客户背景
• 任务准备进入方案设计
• 任务准备交给 AI 批量推进
• 用户已经明确提到 skill / harness

完整版走下面的 Full Workflow。

Minimum Required Fields

不管轻量版还是完整版，第一次放行前必须补齐这 5 项：

1. 任务目标
2. 当前现状
3. 已知约束
4. 成功标准
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: 做结构化分解

门禁通过后的默认下一步。
入口判断（必须都能回答，才开始拆）：

1. 这个任务真正要交付的最小结果是什么？
2. 当前最主要的限制条件是什么？
3. 哪一部分最适合先交给 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 条，才算通过门禁：

1. 第一性原理前置三问都有答案（问题本质、不可绕过的约束、最小正确方向）
2. 任务目标 不是空话（不能只是“优化一下”“更智能一点”）
3. 当前现状 能说清问题发生在哪里（场景、对象或卡点）
4. 已知约束 至少有一条真实约束（时间、资源、技术、流程、客户、质量都算）
5. 成功标准 可检验（能回答“什么结果算完成”）
6. 未知项 被显式写出（不能假装没有未知）
7. 下一步动作不越级（问题没清楚时不能直接进入实现）

Gate Fail Conditions

只要出现下面任意一种，默认不通过：

• 问题本质回答不上来
• 任务目标过于空泛
• 成功标准无法验证
• 当前现状过于抽象
• 关键约束完全缺失
• 把问题定义、解决方案、实现细节混在一起
• 希望直接让 AI 开做，但上下文明显不足

Human-in-the-loop Checkpoints

以下节点必须人工确认，不允许纯 AI 通过：

1. 问题本质是否成立
2. 结构化分解是否合理
3. 子问题是否真的进入闭环空间
4. 某个闭环问题是否真的满足 AutoResearch 启动条件
5. 候选方案是否满足关键约束
6. 输出是否达到交付标准

Output Format

轻量版输出

## 第一性原理
- 问题本质：
- 不可绕过的约束：
- 最小正确方向：

## 当前判断
- 一句话定义：

## 最小必填字段
- 任务目标：
- 当前现状：
- 已知约束：
- 成功标准：
- 未知项：

## 门禁结论
- 是否通过：
- 缺口：

## 下一步
- 建议动作：
- 理由：

完整版输出

## 项目上下文
- 是否已完成项目背景采集：[是 / 否]
- 项目名称或代号：
- 项目当前阶段：
- 可用资料与资源：
- AI 可访问范围：

## 第一性原理
- 问题本质：
- 不可绕过的约束：
- 最小正确方向：

## 当前判断
- 角色：
- 当前阶段：[需求/问题定义 | 方案设计 | 实现 | 验证 | 交付/支持]
- 一句话定义：

## 通用字段
- 任务目标：
- 当前现状：
- 已知约束：
- 成功标准：
- 未知项：
- 影响范围：
- 下一步允许动作：

## 角色扩展字段
- [字段 1]：
- [字段 2]：
- [字段 3]：

## 三层拆分
- 问题定义：
- 解决方案：
- 实现细节：

## 门禁结论
- 是否通过：[通过 / 不通过]
- 缺口：

## 结构化分解
- 问题本质：
- 子问题 1：[目标 + 输入 + 输出]
- 子问题 2：[目标 + 输入 + 输出]
- 子问题 3：[目标 + 输入 + 输出]
- 适合直接交给 AI 的部分：

## 闭环与 AutoResearch 判断
- 哪些子问题已进入闭环空间：
- 哪些子问题满足 AutoResearch 启动条件：
- 哪些子问题还不适合：

## 人审点
- 本轮需要人工确认的节点：

## 下一步
- 建议动作：
- 理由：

## 沉淀判断（仅当涉及 skill / harness 时）
- 是否值得沉淀：
- 建议形态：
- 理由：

Asking Rules

追问时遵循以下顺序：

1. 先补第一性原理三问
2. 再补 任务目标
3. 再补 成功标准
4. 再补 已知约束
5. 再补 当前现状 与 未知项
6. 再补角色字段
7. 最后确认 下一步允许动作
8. 如果用户提到 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

• 是否完成第一性原理三问
• 如果是新项目，是否先采集了项目背景与资源
• 是否判断了当前阶段
• 最小必填字段是否齐全
• 角色扩展字段是否在需要时补齐
• 是否显式列出未知项
• 是否拆开了问题定义、解决方案、实现细节
• 门禁通过/不通过的理由是否明确
• 是否完成结构化分解，并把颗粒度收敛到 AI 易执行
• 是否区分了“进入闭环”和“启动 AutoResearch”
• 是否标注了本轮必须的人审点
• 下一步是否没有越级
• 如果讨论了 skill / harness，是否给出了沉淀判断