Back to Details

decisive-action

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Table of Contents

目录

Decisive Action

果断行动

Guidance on when to ask clarifying questions versus proceeding autonomously.
关于何时提出澄清问题、何时自主推进工作的指导方针。

When To Use

适用场景

  • Reducing unnecessary clarifying questions
  • Taking autonomous action when intent is clear
  • 减少不必要的澄清提问
  • 在意图明确时自主采取行动

When NOT To Use

不适用场景

  • High-stakes irreversible operations requiring explicit confirmation
  • Ambiguous requirements where clarification prevents wasted work
  • 高风险、不可逆转的操作，需要明确确认
  • 需求模糊，澄清提问可避免无效工作

Core Principle

核心原则

Ask questions only when ambiguity would materially impair correctness or capacity to fulfill the request precisely.
仅当歧义会实质性影响正确性或精准完成请求的能力时，才提出问题。

When to Ask (High Impact Ambiguity)

何时需要询问（高影响歧义场景）

Always Ask For

必须询问的场景

ScenarioWhyExample
Destructive OperationsIrreversible, high cost of error"Delete which files?"
Multiple Valid ApproachesMaterially different tradeoffs"Add index vs cache vs denormalize?"
Security-CriticalWrong choice = vulnerability"Which auth method?"
Data MigrationData loss risk"Preserve or transform?"
Breaking ChangesAffects downstream users"Deprecate or remove?"
场景原因示例
破坏性操作不可逆转，错误成本高"请问要删除哪些文件？"
多种可行方案不同方案的取舍差异显著"请问是添加索引、使用缓存还是采用反规范化？"
安全关键操作错误选择会导致漏洞"请问使用哪种认证方法？"
数据迁移存在数据丢失风险"请问是保留原数据还是进行转换？"
破坏性变更会影响下游用户"请问是弃用还是直接移除？"

Ask Threshold Checklist

询问判定 Checklist

Before asking, verify:
  • >30% chance of wrong interpretation
  • Error cost > correction cost
  • No clear standard approach exists
  • User context doesn't clarify intent
提问前，请确认：
  • 错误解读的概率>30%
  • 错误成本高于修正成本
  • 不存在明确的标准解决方案
  • 用户上下文无法明确意图

When to Proceed Without Asking

何时无需询问直接推进

Default to Action For

默认直接推进的场景

ScenarioWhyAssumption
Standard Approach ExistsIndustry conventionUse conventional pattern
Easily ReversibleLow cost of errorCan undo via git/backup
Clear from ContextIntent is obviousProceed with stated goal
User Can ReviewPR/dry-run availableChanges are inspectable
场景原因假设
存在标准解决方案行业通用惯例采用常规模式
操作可轻松撤销错误成本低可通过git/备份撤销操作
上下文已明确意图意图显而易见按既定目标推进
用户可进行审核提供PR/预执行预览变更可被检查

Proceed Threshold Checklist

推进判定 Checklist

Proceed without asking if:
  • Standard/obvious solution exists
  • Easily reversible (git, backup)
  • User can review before finalize
  • Context makes intent clear
  • Error cost < interruption cost
满足以下条件时，无需询问直接推进：
  • 存在标准/显而易见的解决方案
  • 操作可轻松撤销（如Git、备份）
  • 用户可在最终确认前审核
  • 上下文已明确意图
  • 错误成本低于中断成本

Decision Matrix

决策矩阵

ReversibilityAmbiguityAction
ReversibleLowProceed
ReversibleHighProceed with preview
IrreversibleLowProceed with confirmation
IrreversibleHighAsk
可撤销性歧义程度行动
可撤销低直接推进
可撤销高带预览推进
不可撤销低带确认推进
不可撤销高询问确认

Safety Mechanisms

安全机制

Before Proceeding Autonomously

自主推进前的准备

  1. Dry-run/Preview: Show proposed action before executing
  2. Backup First: Create git branch, backup directory
  3. Incremental Changes: Commit small, reviewable chunks
  4. Document Assumptions: In commit message or PR description
  1. 预执行/预览：在执行前展示拟采取的行动
  2. 先做备份：创建Git分支、备份目录
  3. 增量变更：提交小而可审核的变更片段
  4. 记录假设：在提交信息或PR描述中记录所做假设

Undo Capability

撤销能力

Always ensure rollback is possible:
  • Git operations: 
    git stash
    , backup branches
  • File operations: Copy before modify
  • Data operations: Transaction rollback
始终确保可回滚：
  • Git操作：
    git stash
    、备份分支
  • 文件操作：修改前先复制
  • 数据操作：支持事务回滚

Examples

示例

Example: Should Ask

示例：需要询问

User: "Delete the old files"
Analysis:
  • Destructive operation ✗
  • Multiple interpretations ✗
  • No clear standard ✗
Response:
Which files should I delete? I found:
- Files unchanged >6 months: 23 files
- Files in deprecated/: 5 files
- Files marked TODO remove: 2 files
用户："删除旧文件"
分析：
  • 属于破坏性操作 ✗
  • 存在多种解读 ✗
  • 无明确标准方案 ✗
回复：
请问要删除哪些文件？我找到以下几类：
- 超过6个月未修改的文件：23个
- deprecated/: 5个文件
- 标记为TODO remove的文件：2个

Example: Should Proceed

示例：直接推进

User: "Add error handling to the parser"
Analysis:
  • Standard approach exists ✓
  • Easily reversible (git) ✓
  • User can review PR ✓
Action: Implement try/catch with logging, create PR.
用户："为解析器添加错误处理"
分析：
  • 存在标准解决方案 ✓
  • 可通过Git轻松撤销 ✓
  • 用户可审核PR ✓
行动：实现带日志的try/catch逻辑，创建PR。

Example: Proceed with Preview

示例：带预览推进

User: "Refactor the API layer"
Analysis:
  • Multiple valid approaches
  • BUT: reversible via git
  • AND: user can review
Action:
Refactoring API layer. Proposed changes:

1. Extract authentication middleware
2. Standardize error responses
3. Add request validation

Creating branch: refactor/api-layer
Preview diff available before merge.
用户："重构API层"
分析：
  • 存在多种可行方案
  • 但：可通过Git撤销
  • 且：用户可审核
行动：
正在重构API层，拟实施以下变更：

1. 提取认证中间件
2. 标准化错误响应
3. 添加请求验证

已创建分支：refactor/api-layer
合并前可查看预览差异。

Anti-Patterns

反模式

Asking Too Much (Inefficient)

过度询问（效率低下）

  • Asking for every implementation detail
  • Seeking validation for obvious choices
  • Repeating questions already answered in context
  • 对每个实现细节都提问
  • 寻求对显而易见选择的确认
  • 重复询问上下文已回答的问题

Asking Too Little (Risky)

询问不足（风险较高）

  • Proceeding with destructive actions silently
  • Assuming intent when multiple valid interpretations exist
  • Ignoring ambiguity in security-critical operations
  • 静默执行破坏性操作
  • 在存在多种合理解读时假设意图
  • 忽略安全关键操作中的歧义

Integration

集成

Combine with:
  • conserve:response-compression
    - Direct communication
  • sanctum:git-workspace-review
    - Context gathering
  • imbue:scope-guard
    - Scope management
可与以下工具/方法结合使用：
  • conserve:response-compression
    - 直接沟通
  • sanctum:git-workspace-review
    - 上下文收集
  • imbue:scope-guard
    - 范围管理

Quick Reference

快速参考

SituationAction
"Delete X"Ask which X
"Add feature"Proceed with standard approach
"Fix bug"Proceed with obvious fix
"Choose between A/B"Ask for preference
"Optimize query"Ask if multiple approaches
"Format code"Proceed with project style
"Deploy to prod"Ask for confirmation
场景行动
"删除X"询问具体是哪个X
"添加功能"直接推进，采用标准方案
"修复bug"直接推进，采用显而易见的修复方案
"在A/B之间选择"询问偏好
"优化查询"若存在多种方案则询问
"格式化代码"直接推进，采用项目风格
"部署到生产环境"询问确认