Back to Details

lightweight-implementation-analysis-protocol

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Lightweight Implementation Analysis Protocol

轻量级实现分析协议

Quick understanding before implementation - just enough to guide TDD, no more.
实现前快速理解——仅需足够指导TDD即可，无需过多冗余。

When This Activates

触发时机

Before creating implementation plans, fix plans, or TDD cycles for bugs/features.
在为Bug或功能制定实现计划、修复计划或启动TDD循环之前。

The Protocol (3 Quick Steps)

协议步骤（3个快速步骤）

1. Trace the Flow

1. 追踪代码流程

Answer these:
  • Which event/request triggers this?
  • Which file:line handles it?
  • Where does the error occur (file:line)?
回答以下问题：
  • 该功能/问题由哪个事件/请求触发？
  • 由哪个文件:行号处理？
  • 错误发生在哪个位置（文件:行号）？

2. Quick Diagram

2. 快速绘制示意图

Simple class.method() flow with relevant data:
Event: EventName
  ↓ (contains: relevant fields)
Class.method() [file:line]
  ↓ (what it does)
Class.method() [file:line] ← 💥 Error here
  ↓
Result: What happens
Keep it short - 5-10 lines max.
展示包含相关数据的简单class.method()调用流程：
Event: EventName
  ↓ (contains: relevant fields)
Class.method() [file:line]
  ↓ (what it does)
Class.method() [file:line] ← 💥 Error here
  ↓
Result: What happens
保持简洁——最多5-10行。

3. Verify

3. 确认理解

Ask: "Here's the flow: [diagram]. Correct?"
Wait for confirmation, then proceed.
询问用户：“这是我梳理的流程：[示意图]。是否正确？”
等待用户确认后再继续。

Example

示例

Problem: Email validation failing

Event: user.email.updated
  ↓ (email: "invalid@")
UpdateUserEmailHandler.execute() [line 281]
  ↓ (validates email format)
EmailValidator.parse() [line 289] ← 💥 Throws ValidationError
  ↓
Result: Error response

Current: Throws
Should: Use safeParse(), return validation error
Problem: Email validation failing

Event: user.email.updated
  ↓ (email: "invalid@")
UpdateUserEmailHandler.execute() [line 281]
  ↓ (validates email format)
EmailValidator.parse() [line 289] ← 💥 Throws ValidationError
  ↓
Result: Error response

Current: Throws
Should: Use safeParse(), return validation error

Rules

规则

  • Keep it lightweight - This isn't detailed planning, just enough to know what to test
  • Be specific - File:line, not abstractions
  • Get confirmation - Don't proceed without it
  • Skip for trivial changes - Typos, formatting, docs
  • 保持轻量——这不是详细规划，仅需明确测试点即可
  • 具体明确——需标注文件:行号，而非抽象描述
  • 获取确认——未得到用户确认前不要继续
  • 简单修改可跳过——如拼写错误、格式调整、文档修改

Anti-Pattern

反模式

❌ WRONG: "I'll fix the validation. Here's my plan..." ✅ RIGHT: "Let me trace where the error occurs... [diagram]. Correct?"
❌ 错误做法：“我会修复这个验证问题。这是我的计划……” ✅ 正确做法：“让我先追踪错误发生的位置……[示意图]。是否正确？”