메뉴
强制执行'先想清楚、再动手'工作流程。当任务涉及设计/架构决策、新功能实现、重构或任何需要规划的代码变更时调用此技能。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
专精于 HTML5 Canvas 网页与动画交互开发。创建高性能、视觉丰富的 Canvas 应用，包括粒子系统、数据可视化、交互式动画、游戏渲染等。当用户需要创建、修改或优化 Canvas 网页时调用此技能。
分析 Git 提交记录并生成面向非技术用户的友好变更日志。当用户需要将技术性提交日志转换为易读的更新摘要、创建发布说明或向客户/利益相关者沟通产品变更时调用此技能。
数据库设计技能包，提供完整的数据库设计指导。适用于新建数据库、设计规范查询、数据库优化咨询等场景。
| name | design-first |
| description | 强制执行'先想清楚、再动手'工作流程。当任务涉及设计/架构决策、新功能实现、重构或任何需要规划的代码变更时调用此技能。 |
暂停。思考。批准。编码。
本技能强制执行结构化的决策流程，确保 AI 在设计方向获得用户明确批准之前，不会编写任何代码。该技能以聚焦、高效的方式取代零散的澄清、繁琐的文档要求和无限的反馈循环。
理论基础：本技能的设计理念源于软件工程方法论、决策科学和敏捷开发实践的融合。详见 参考资料目录。
本技能必须在以下场景激活：
┌─────────────────────────────────────────────────────────────┐
│ ⛔ 方向批准前禁止执行： │
│ - 编写任何代码 │
│ - 创建项目脚手架 │
│ - 生成文件 │
│ - 重构现有代码 │
│ - 进行结构性变更 │
│ │
│ ✅ 批准前允许执行： │
│ - 提出澄清性问题 │
│ - 提出设计方案 │
│ - 分析权衡利弊 │
│ - 阅读现有代码以获取上下文 │
└─────────────────────────────────────────────────────────────┘
参考：边界规则的设计基于认知负荷理论，避免在信息不充分时做出不可逆决策。详见 决策框架 - 决策类型分类。
目标：在单次交互中收集关键信息。
规则：
问题模板：
在提出方案之前，我需要了解以下信息：
1. [上下文问题]
a) 选项 A
b) 选项 B
c) 选项 C
2. [约束条件问题]
a) 选项 A
b) 选项 B
3. [优先级问题]
a) 选项 A
b) 选项 B
深度动态调整：
参考：批量提问的设计基于认知负荷理论，减少上下文切换带来的认知负担。详见 软件工程方法论 - 认知负荷理论。
目标：呈现恰好 2 个方案，并附带清晰的权衡分析。
规则：
提案模板：
## 方案 A：[名称]
**描述**：[该方案的具体内容]
**优势**：
- [优势 1]
- [优势 2]
**劣势**：
- [劣势 1]
- [劣势 2]
**风险**：[潜在问题及缓解方式]
**扩展性**：[如何应对未来需求]
---
## 方案 B：[名称]
[与方案 A 相同的结构]
---
## 我的推荐：方案 [A/B]
**理由**：[为什么偏好此方案]
**所做的权衡**：[我们获得什么 vs 放弃什么]
参考：方案数量限制基于决策科学中的对比效应和认知负荷限制。权衡分析方法详见 决策框架 - 权衡分析技术。
目标：在继续执行前获取用户的明确批准。
规则：
用户回应处理：
| 回应 | 行动 |
|---|---|
| "批准" / "继续" / "执行" | 进入第四阶段，然后开始编码 |
| "拒绝，因为 X" | 针对性修改提案 |
| "修改 Y" | 按 Y 的要求更新提案 |
| "方案 C：..." | 如果可行，接受用户的替代方案 |
迭代限制机制：
第 1 轮：初始提案 → 被拒绝
第 2 轮：修改提案 → 被拒绝
→ 停止并询问用户："我们已探索 2 轮方案，建议：
a) 您提供具体方向
b) 安排会议讨论
c) 由我基于最佳判断执行"
参考：迭代限制机制避免决策瘫痪，符合敏捷开发中的"速度优于完美"原则。详见 敏捷开发实践 - 反馈时效性原则。
目标：以最小开销记录决策。
规则：
记录格式（行内注释）：
// 设计决策：[日期]
// 选择：方案 [A/B] - [简要理由]
// 权衡：[我们接受的条件]
// 背景：[驱动此决策的关键约束]
记录格式（聊天消息）：
📝 **决策已记录**
- **选择**：方案 A
- **理由**：[为什么选择此方案]
- **接受的权衡**：[我们放弃了什么]
- **下一步**：[即将实施的内容]
参考：轻量级记录方式符合敏捷宣言中"工作的软件高于详尽的文档"原则。详见 敏捷开发实践 - 敏捷宣言与设计先行。
参考：这些原则源自极限编程(XP)、精益创业等方法论。详见 软件工程方法论 - YAGNI 原则 和 软件工程方法论 - MVP。
┌────────────────────────────────────────────────┐
│ 设计先行工作流程 │
├────────────────────────────────────────────────┤
│ 1. 发现：提出 2-3 个问题（单次批量） │
│ 2. 提案：2 个方案 + 推荐意见 │
│ 3. 收敛：获取明确批准 │
│ 4. 记录：行内记录决策 │
├────────────────────────────────────────────────┤
│ 然后且仅然后：编写代码 │
└────────────────────────────────────────────────┘
用户："为提交按钮添加加载动画"
AI 回应：
这是一个简单的 UI 添加。让我提出 2 种方案：
## 方案 A：纯 CSS 动画
- 优势：无依赖、轻量、快速
- 劣势：定制性有限
- 适合简单场景
## 方案 B：组件库动画
- 优势：与设计系统一致、动画丰富
- 劣势：增加依赖
**推荐**：方案 A - 遵循 YAGNI 原则，如有需要后续可升级。
是否批准执行？
用户："为应用添加用户认证功能"
AI 回应：
在提出方案之前，我需要了解以下信息：
1. 主要的认证方式是什么？
a) 邮箱/密码
b) 社交登录（Google、GitHub 等）
c) 两者都要
2. 后端架构是什么？
a) 自有后端 API
b) Firebase/Supabase
c) 尚未决定
3. 优先级是什么？
a) 快速实现（MVP）
b) 企业级安全
c) 两者平衡
[用户回答后，进入提案阶段...]
用户："重新设计我们的微服务架构"
AI 回应：
这是一个重大的架构变更。让我先了解背景：
1. 这次重新设计的驱动力是什么？
a) 扩展性问题
b) 团队结构调整
c) 技术迁移
d) 其他：___
2. 当前的痛点是什么？
a) 部署复杂
b) 服务通信
c) 数据一致性
d) 以上多项
3. 有哪些约束条件？
a) 必须保持零停机
b) 预算有限
c) 时间线：[具体日期]
d) 团队专长：[具体技术]
注：鉴于范围较大，在您初次回答后我可能需要进一步澄清，但会批量高效地进行。
参考：大型架构设计需要考虑渐进式架构原则。详见 软件工程方法论 - 渐进式架构。
| ❌ 错误模式 | ✅ 正确做法 |
|---|---|
| 一次只问一个问题 | 批量提出 2-3 个问题 |
| 呈现 5+ 个方案 | 呈现恰好 2 个方案 |
| "让我先开始编码看看" | 先获取批准 |
| 为每个变更创建 design.md | 除非被要求，否则行内记录 |
| 无限修改循环 | 最多 2 轮迭代，然后升级 |
| 为"某天可能需要"过度设计 | 只设计当前需要的 |
当本技能激活时，在任何代码变更前验证：
如果任何复选框未勾选：暂停。不要编写代码。
本技能的设计基于以下理论框架和实践方法：
| 文档 | 内容概述 |
|---|---|
| 软件工程方法论 | YAGNI、MVP、渐进式架构、技术债务、设计思维、认知负荷理论 |
| 决策框架 | 结构化决策流程、权衡分析技术、方案生成与收敛、决策质量评估 |
| 敏捷开发实践 | 敏捷宣言映射、迭代开发、持续交付、用户故事、看板方法、DevOps 集成 |