Taku Think 没有提供具体的文本内容，只有两个英文单词。如果需要完整的文本翻译，请提供完整的内容。假设 “Taku Think” 是一个特定的名称或品牌，那么它的翻译可能取决于其具体含义或背景。然而，如果按照字面意思，“Taku” 和 “Think” 分别可以翻译为 “拓” 和 “思考” 或 “思考者” 等，但这可能不是准确的翻译，因为缺乏上下文。

Taku Think - 最小必要设计 Think 可以防止错误的工作从开始。它应该尽可能简短，并且风险要求明确。 规则标签： [IRON LAW] 表示不可商量的正确性约束。 [GUIDANCE] 表示强烈的默认值，可以在上下文合理时进行调整。 [IRON LAW] 在选定的设计路径可见并获得用户批准之前，不得实施。 模式选择 根据请求的成熟度选择，而不是关键词。 快速：一个明确的变化，明显的实现位置，无需架构决策，成功标准已经明确或强烈暗示。 设计：正常的功能工作，其中数据模型、集成点、组件结构或行为边界是开放的。 探索：想法阶段的工作，其中成功标准是未知的，或者真正的问题是是否/什么要构建。 如果有疑问，使用设计模式。 快速模式 当重型文档会浪费时，使用快速模式。 提出一个对齐问题：我理解这是：[变化]，涉及 [文件/区域]，通过 [检查] 验证。是这样吗？ 如果被纠正，重新陈述一次。 呈现一个聊天可见的迷你设计： 迷你设计 - 变化：- 为什么：- 接触点：- 风险：- 完成时： 批准后，直接路由到 /taku-build 进行单一明显的变化，或者路由到 /taku-plan 当任务分解很重要时。 不要仅仅为了满足流程而创建 DESIGN.md 或 PLAN.md。 迷你设计足够包含范围、风险和验证。 设计模式 当实现选择很重要时，使用设计模式。 在提出设计之前： 阅读直接相关的项目文档/配置/文件 检查附近的模式 提出最多两个澄清问题，每次一个 跳过用户已经回答的问题 提出 2-3 个不同的方法： 一个最小可行路径 一个更强的长期架构 一个横向选项，只有当它真正不同时 推荐一个并解释权衡。 用户选择后，使用 references/design-doc.md 作为本地脚手架写 DESIGN.md。 设计深度根据风险进行缩放： 轻量级：问题、方法、接触点、风险、完成时 标准/深度：添加架构、数据流、错误处理、测试策略和开放问题 在请求批准之前，删除占位符，如 TBD、TODO、"适当" 或 "稍后处理"。 带有占位符的设计不是合同。 探索模式 当请求还没有准备好成为构建合同时，使用探索模式。 提出最小的强制问题集，以确定是否有真正的任务： 什么证据表明这是必要的？ 谁是第一个用户或维护者？ 什么是最小的有用版本？ 如果我们什么都不做，会发生什么？ 现有的代码或工作流程已经解决了部分问题吗？ 如果用户要求继续尽管有未回答的问题，提出两个最重要的剩余问题，然后尊重答案。 在 .taku/explore-{date}.md 中记录有用的探索笔记，只有当会话产生值得保留的决定时。 否则，在聊天中总结。 交接合同 在路由到 /taku-plan 或 /taku-build 之前，验证： 批准的设计或批准的迷你设计存在 一个方法被选中 成功标准是具体的和可测试的 范围边界是明确的 开放问题被回答或被接受为已知风险 如果任何项目缺失，解决它之前交接。 计划和构建不得发明设计决策。 范围守护 如果请求包含多个独立的子系统，分割它。 在第一个连贯的切片上运行 Think，并列出什么不在范围内。 设计系统模式 仅在显式设计系统或视觉身份请求时激活。 加载 references/design-system.md 时触发。 后端、CLI 和 API 项目跳过此模式。 已知的陷阱 快速模式用于非快速任务。 "添加设置"通常隐藏存储、权限、审计、迁移和 UI 决策。 预防：快速模式需要一个明显的实现路径。 如果有两个合理的方法，使用设计模式。 三个假的方法。 "React"、"React with hooks" 和 "React with hooks 和 TypeScript" 不是不同的选项。 预防：提出两个真正的选项，而不是三个美观的选项。 带有 TBD 的设计文档。 构建将 TBD 视为发明行为的许可。 预防：批准之前进行占位符扫描。