Dt think

技术方案头脑风暴

通过自然对话帮用户把模糊的想法变成清晰的技术设计，然后调用 dt-tech-doc 输出符合规范的技术文档。

<HARD-GATE> 在用户确认设计之前，不得调用任何实现 skill、修改生产行为或做实现动作。不管任务看起来多简单，都必须走完思考流程。Bug 或性能任务只允许为复现和定位问题新增测试、临时诊断脚本和诊断埋点。 </HARD-GATE>

反模式："这个太简单了不用想"

一旦进入本流程，不因任务看起来简单而跳过设计确认。配置改动、小功能、工具脚本——进来了就走完。设计可以很短（真正简单的几句话就行），但必须呈现给用户确认。"简单"的事情最容易因为没想清楚而返工。（任务要不要进流程由用户判级；本节管的是进来之后不偷工。）

流程

分三个阶段，严格按顺序执行：

阶段一：思考

1. 了解项目上下文 — 项目有 .dt/ 时先读 spec.md 和 progress.md 近期条目，方案与已有规则冲突时先指出；再看当前项目的文件、文档、最近的提交；已在上下文里的内容不重复读
2. Bug / 性能任务先复现再分析
   • 建立一个能稳定出现用户所述问题的测试、命令或脚本；必须实际运行并记录命令、问题表现或性能基线
   • 逐步删减输入、配置和操作，缩小到仍能复现问题的最小场景
   • 提出必要的、能被验证或推翻的根因假设；有多个时按可能性排序，每次只验证一个变量，拿到根因证据后再设计修复方案
   • 无法复现时停下，说明已经尝试的方式，并向用户索要可复现环境、日志、HAR 等材料或临时诊断权限，不凭代码表象猜根因
3. 一个一个问问题 — 每条消息只问一个问题，搞清楚目的、约束、成功标准
   • 优先用选择题，开放式问题也行
   • 问之前先判断范围：如果需求涉及多个独立子系统，先指出来让用户拆分，不要在大范围上细化
   • 如果项目太大一份文档搞不定，帮用户拆成子项目，先对第一个子项目走完整个流程
4. 提出 2-3 种方案 — 列出各自的优缺点，给出你的推荐和理由，推荐的排第一个
5. 呈现设计 — 按章节逐步讲，每个章节的篇幅根据复杂度调整（简单的几句话，复杂的展开讲）
   • 覆盖：架构、模块、数据流、错误处理、测试
   • 每讲完一个章节问用户是否 OK
   • 随时可以回头改

设计的隔离与清晰性：

• 把系统拆成小单元，每个单元只做一件事，通过明确的接口通信，能独立理解和测试
• 每个单元要能回答三个问题：它做什么、怎么用它、它依赖什么
• 不看内部实现能不能理解它？改内部实现会不会影响使用方？如果不能，说明边界有问题
• 小而聚焦的单元也更适合 AI 处理——上下文放得下，编辑更可靠；文件变大通常意味着它做的事太多了

已有代码库中的工作原则：

• 先看现有结构，跟着已有模式走
• 如果现有代码的问题影响到当前工作（比如文件太大、职责不清），在设计中一并处理
• 不做无关的重构

阶段二：落盘与输出文档

用户确认设计后，先确定落盘位置：

• 被 dt-dev 调用 → 写入任务目录 <任务目录>/design.md（目录不存在则按 dt-dev 的命名规则 .dt/tasks/<YYMMDD>-<英文slug>/ 创建）
• 单独使用本 skill → 问用户文档存到哪

只写一个文件 design.md，调用 dt-tech-doc 生成（dt-tech-doc 未安装时不中断：按「一句话结论 / 背景 / 方案（含权衡）/ 影响范围 / 风险 / 验收标准」结构自行生成）：

• 把阶段一确认的设计内容作为输入，走 dt-tech-doc 的「A. 生成文档」流程
• dt-tech-doc 需要的信息（文档类型、要解决的问题、方案、影响范围、风险）在阶段一已经全部聊清楚了，直接跳过 dt-tech-doc 的提问步骤，进入生成
• 在 dt-tech-doc 决策层结构的基础上，对内容有三点要求：
  • 「背景」节并入需求结论：要解决的问题、边界、约束（简短写，写结论不写对话过程）
  • Bug 或性能任务在「背景」节写明复现命令、实际问题表现或性能基线、最小复现场景和根因证据
  • 「方案」节保留方案对比与选择理由（权衡：为什么不选另一条路）
  • 新增「验收标准」节——它是确认门和后续 Review 的依据；每条附验证方式（命令、可观察行为或检查方法），不写"更流畅"这类没法检查的描述
• 简单需求各节可以很短（几句话），但章节不缺

阶段三：文档自审

文档生成后，按下方维度内联自查一遍，确认文档能直接拿去用（不派子代理，独立审查留给代码 Review 阶段）。设计只有几句话的简单文档可跳过自审，直接结束。

审查维度：

类别	检查什么
完整性	有没有 TODO、占位符、"待定"、空章节
一致性	前后有没有自相矛盾的地方
清晰度	有没有模糊到让人理解出两种意思的描述
范围	有没有跑题、覆盖了不该管的东西
YAGNI	有没有塞进去没人要的功能或过度设计

校准标准： 只报会导致实际问题的毛病。缺了关键章节、前后矛盾、描述模糊到会做错——这些算问题。措辞风格、"这段可以再详细点"——这些不算。没严重问题就直接通过。

审查结果处理：

• 通过 → 直接交付
• 表述问题（错别字、占位符、含糊句）→ 直接修正，交付时说明
• 涉及设计内容的问题（矛盾、缺章节、范围偏差）→ 列给用户确认后再改

结束

文档交付后本 skill 的工作结束：

• 被 dt-dev 调用时 → 把控制权交还 dt-dev，由它继续后续阶段（确认 → 编码）
• 单独使用时 → 停止。不调用任何其他 skill，不写代码，不做实现计划

关键原则

• 一次只问一个问题 — 不要一口气问一堆
• 优先选择题 — 比开放题更容易回答
• YAGNI — 用不上的功能砍掉
• 探索替代方案 — 至少提 2-3 种方案再定
• 逐步确认 — 讲完一块确认一块，再往下走
• 灵活回退 — 哪里不对随时回头改