Back to Details

confront

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Confront

审查质疑

Goal

目标

  • Codebase alignment identified.
  • Each challenging question answered.
  • Concerns list covers every red-flag answer.
  • 明确代码库对齐情况。
  • 所有质疑问题均得到解答。
  • 疑虑清单涵盖所有标记为风险的回答。

Input

输入

  • Requirements: Structured document, should be itemized with 
    id
    attached to each item.
  • 需求：结构化文档，每个需求项需附带
    id
    。

Steps

步骤

If the input is itemized, repeat Steps 1-2 per item, keyed by 
id
.
若输入为分项式结构，则按
id
逐个重复步骤1-2。

Step 1: Review Codebase

步骤1：审查代码库

Inspect the existing implementation for related functionality to outline:
  • Similar patterns: Identify similar functionality and extract reuse candidates (models, components, utilities).
  • Tech debt blockers: Identify circumstances that block or complicate the task.
  • Regression risks: Spot regression risks in shared code or core paths.
  • Affected modules: Identify directories/files likely affected.
检查现有实现中的相关功能，梳理以下内容：
  • 相似模式：识别相似功能，提取可复用候选对象（模型、组件、工具类）。
  • 技术债务障碍：识别阻碍或使任务复杂化的情况。
  • 回归风险：发现共享代码或核心路径中的回归风险。
  • 受影响模块：确定可能受影响的目录/文件。

Step 2: Challenge Requirements

步骤2：质疑需求

Answer each topic's question below - a positive answer is a red flag.
markdown
1. **Topic**: Question
  1. Unworthy: Can we avoid implementing it in the first place?
  2. Preliminary solution: Does the task state preliminary solution instead of goal?
  3. Unnecessary complications: Is the solution over-engineered, implying unnecessary complexity?
  4. Alternative solution: Is there a simpler alternative solution to achieve the same business goal?
  5. Pitfalls: Are there hidden implementation implications, dependencies, constraints or edge cases not explicitly mentioned but important?
  6. Missing details: Are there missing, unclear or ambiguous items or context?
  7. Scope creep: Is the task trying to cover too many unrelated things?
  8. Vague: Are acceptance criteria unmeasurable or untestable?
  9. Contradictory statements: Are there contradictory statements?
  10. Business logic conflicts: Does it misuse existing architecture or patterns?
回答以下每个主题的问题——肯定回答即为风险信号。
markdown
1. **Topic**: Question
  1. 价值存疑：我们能否从一开始就避免实现该需求？
  2. 方案前置：任务描述中是否给出了初步解决方案而非目标？
  3. 过度复杂：解决方案是否过度设计，包含不必要的复杂度？
  4. 替代方案：是否存在更简单的替代方案可实现相同业务目标？
  5. 潜在陷阱：是否存在未明确提及但至关重要的隐藏实现影响、依赖关系、约束条件或边缘情况？
  6. 信息缺失：是否存在缺失、模糊或歧义的需求项或上下文？
  7. 范围蔓延：任务是否试图涵盖过多无关内容？
  8. 模糊不清：验收标准是否无法衡量或无法测试？
  9. 矛盾表述：是否存在相互矛盾的表述？
  10. 业务逻辑冲突：是否误用了现有架构或模式？

Step 3: Formulate Concerns

步骤3：梳理疑虑

Each positive answer from the previous step can raise multiple concerns, against one or several Items. For each concern outline:
  • ID: the concern's own identity - an ordered number, unique per concern.
  • Item: the originating entry's ID, from Items. One entry MAY raise several concerns, each a distinct concern ID sharing the same Item.
  • Summary: One sentence of what is unresolved.
  • Description: All details.
  • Suggestion: Filled for every verdict, verdict-specific - ticket creation or code 
    TODO
    for Defer, possible solution for Implement, direct answer or 
    clarify
    proxy for Explain, blank for Decline (Description already covers the rationale).
  • Severity:
    • Major: architectural changes, bugs, correctness issues.
    • Medium: code reuse, readability, UX.
    • Minor: nitpicks, code style, renaming, minor improvements.
  • Verdict:
    • Decline: Factually incorrect, missing full context, or not worth the effort. Rationalize why it shouldn't or can't be done the way it's defined.
    • Defer: Valid but out of scope right now - a separate issue, or would expand the diff significantly.
    • Explain: Only a question is raised, no change required.
    • Implement: Everything else. Proceed as usual.
If relevant, come up with additional concerns besides those coming from questions.
上一步中每个肯定回答都可能引发多个疑虑，对应一个或多个需求项。每个疑虑需包含以下内容：
  • ID：疑虑的唯一编号，按顺序排列。
  • Item：源需求项的ID。一个需求项可能引发多个疑虑，每个疑虑拥有独立ID但对应同一个Item。
  • 摘要：一句话说明未解决的问题。
  • 描述：所有细节信息。
  • 建议：针对每个结论填写——若结论为“推迟”，则建议创建工单或添加代码
    TODO
    ；若为“实施”，则给出可行方案；若为“解释”，则给出直接回答或使用
    clarify
    代理；若为“拒绝”，则留空（描述中已包含理由）。
  • 严重程度：
    • 重大：架构变更、缺陷、正确性问题。
    • 中等：代码复用、可读性、用户体验问题。
    • 轻微：细节挑剔、代码风格、重命名、小幅改进。
  • 结论：
    • 拒绝：需求存在事实错误、缺失完整上下文，或不值得投入精力。说明为何不应或无法按定义方式实现。
    • 推迟：需求有效但超出当前范围——需单独创建问题，或会大幅增加代码变更量。
    • 解释：仅提出问题，无需修改。
    • 实施：其他所有情况。按常规流程推进。
如有必要，除上述问题引发的疑虑外，可提出额外疑虑。

Output

输出

Markdown format, one top-level structure, entries tagged 
- Item: {Item X}
. When input was itemized, 
Codebase
and 
Challenge
each list one entry per item; 
Concerns
lists one entry per concern (an item may raise several, or none).
  • Codebase
    • Item: {Item X}
    • Similar patterns
    • Tech debt blockers
    • Regression risks
    • Affected modules
  • Challenge
    • Item: {Item X}
    • Topic
    • Question
    • Answer
  • Concerns
    • Item: {Item X}
    • Summary
    • Description
    • Suggestion
    • Severity
    • Verdict
Markdown格式，包含一个顶层结构，条目标记为
- Item: {Item X}
。若输入为分项式结构，
Codebase
和
Challenge
部分分别为每个需求项列出一条目；
Concerns
部分为每个疑虑列出一条目（一个需求项可能引发多个疑虑，或无疑虑）。
  • Codebase
    • Item: {Item X}
    • Similar patterns
    • Tech debt blockers
    • Regression risks
    • Affected modules
  • Challenge
    • Item: {Item X}
    • Topic
    • Question
    • Answer
  • Concerns
    • Item: {Item X}
    • Summary
    • Description
    • Suggestion
    • Severity
    • Verdict