القائمة
强制执行'先想清楚、再动手'工作流程。当任务涉及设计/架构决策、新功能实现、重构或任何需要规划的代码变更时调用此技能。
التثبيت باستخدام 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 集成 |