implement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implementation

代码实现流程

Verification-driven coding with tight feedback loops. Distilled from 21,321 tracked operations across 64+ projects, 612 debugging sessions, and 2,476 conversation histories. These are the patterns that consistently ship working code.

Core insight: 2-3 edits then verify. 73% of fixes go unverified — that's the #1 quality gap. The difference between a clean session and a debugging spiral is verification cadence.

基于紧密反馈循环的验证驱动编码方法。该方法提炼自64+个项目、612次调试会话、2476条对话历史中的21321次追踪操作，是能持续交付可运行代码的实践模式。

核心洞见： 进行2-3次编辑后立即验证。73%的修复未经过验证——这是头号的质量缺口。顺畅的编码会话和陷入调试螺旋的区别就在于验证的频率。

The Sequence

核心流程

Every implementation follows the same macro-sequence, regardless of scale:

dot

digraph implement {
    rankdir=LR;
    node [shape=box];

    "ORIENT" [style=filled, fillcolor="#e8e8ff"];
    "PLAN" [style=filled, fillcolor="#fff8e0"];
    "IMPLEMENT" [style=filled, fillcolor="#ffe8e8"];
    "VERIFY" [style=filled, fillcolor="#e8ffe8"];
    "COMMIT" [style=filled, fillcolor="#e8e8ff"];

    "ORIENT" -> "PLAN";
    "PLAN" -> "IMPLEMENT";
    "IMPLEMENT" -> "VERIFY";
    "VERIFY" -> "IMPLEMENT" [label="fix", style=dashed];
    "VERIFY" -> "COMMIT" [label="pass"];
}

ORIENT — Read existing code before touching anything.

Grep -> Read -> Read

is the dominant opening. Sessions that read 10+ files before the first edit require fewer fix iterations. Never start with blind changes.

PLAN — Scale-dependent (see below). Skip for trivial fixes, write a task list for features, run a research swarm for epics.

IMPLEMENT — Work in batches of 2-3 edits, then verify. Follow the dependency chain. Edit existing files 9:1 over creating new ones. Fix errors immediately — don't accumulate them.

VERIFY — Typecheck is the primary gate. Run it after every 2-3 edits. Run tests after feature-complete. Run the full suite before commit.

COMMIT — Tests are the final gate. Stage specific files only, never

git add -A

. HEREDOC commit messages with conventional commit format.

无论项目规模大小，所有实现工作都遵循相同的宏观流程：

dot

digraph implement {
    rankdir=LR;
    node [shape=box];

    "ORIENT" [style=filled, fillcolor="#e8e8ff"];
    "PLAN" [style=filled, fillcolor="#fff8e0"];
    "IMPLEMENT" [style=filled, fillcolor="#ffe8e8"];
    "VERIFY" [style=filled, fillcolor="#e8ffe8"];
    "COMMIT" [style=filled, fillcolor="#e8e8ff"];

    "ORIENT" -> "PLAN";
    "PLAN" -> "IMPLEMENT";
    "IMPLEMENT" -> "VERIFY";
    "VERIFY" -> "IMPLEMENT" [label="fix", style=dashed];
    "VERIFY" -> "COMMIT" [label="pass"];
}

ORIENT（熟悉代码） —— 在修改任何内容前先阅读现有代码。

Grep -> 阅读 -> 再阅读

是最常用的开场方式。在首次编辑前阅读10个以上文件的会话，所需的修复迭代次数更少。绝对不要盲目开始修改。

PLAN（制定计划） —— 计划的详细程度取决于项目规模（见下文）。微小修复可跳过计划；功能开发需编写任务列表；大型史诗级任务则需开展调研协作。

IMPLEMENT（编码实现） —— 以2-3次编辑为一批次，之后立即验证。遵循依赖链进行开发。修改现有文件和创建新文件的比例为9:1。立即修复错误——不要积累问题。

VERIFY（验证） —— 类型检查是首要验证关卡。每完成2-3次编辑后就运行一次。功能完成后运行测试。提交前运行完整测试套件。

COMMIT（提交） —— 测试是最终关卡。仅暂存特定文件，绝对不要使用

git add -A

。使用约定式提交格式的HEREDOC提交信息。

Scale Selection

规模适配策略

Strategy changes dramatically based on scope. Pick the right weight class:

Scale	Edits	Strategy
Trivial (config, typo)	1-5	Read -> Edit -> Verify -> Commit
Small fix	5-20	Grep error -> Read -> Fix -> Test -> Commit
Feature	50-200	Plan -> Layer-by-layer impl -> Verify per layer
Subsystem	300-500	Task planning -> Wave dispatch -> Layer-by-layer
Epic	1000+	Research swarm -> Spec -> Parallel agents -> Integration

Skip planning when: Scope is clear, single-file change, fix describable in one sentence.

Plan when: Multiple files, unfamiliar code, uncertain approach.

策略会根据项目范围发生显著变化，请选择合适的量级：

规模	编辑次数	策略
微小修改（配置、拼写错误）	1-5	阅读 -> 编辑 -> 验证 -> 提交
小型修复	5-20	搜索错误 -> 阅读 -> 修复 -> 测试 -> 提交
功能开发	50-200	计划 -> 分层实现 -> 逐层验证
子系统开发	300-500	任务规划 -> 分阶段推进 -> 分层实现
史诗级任务	1000+	调研协作 -> 规格定义 -> 多Agent并行开发 -> 集成

可跳过计划的场景： 范围明确、仅修改单个文件、修复内容可用一句话描述。

需要制定计划的场景： 涉及多个文件、代码不熟悉、实现方案不确定。

Dependency Chain

依赖链顺序

Build things in this order. Validated across fullstack, Rust, and monorepo projects:

Types/Models -> Backend Logic -> API Routes -> Frontend Types -> Hooks/Client -> UI Components -> Tests

Fullstack (Python + TypeScript):

Database model + migration
Service/business logic layer
API routes (FastAPI or tRPC)
Frontend API client
React hooks wrapping API calls
UI components consuming hooks
Lint -> typecheck -> test -> commit

Rust:

Error types (
```
thiserror
```
enum with
```
#[from]
```
)
Type definitions (structs, enums)
Core logic (
```
impl
```
blocks)
Module wiring (
```
mod.rs
```
re-exports)
```
cargo check
```
->
```
cargo clippy
```
->
```
cargo test
```

Key finding: Database migrations are written AFTER the code that needs them. Frontend drives backend changes as often as the reverse.

请按照以下顺序进行开发。该顺序已在全栈、Rust和单体仓库项目中验证有效：

Types/Models -> 后端逻辑 -> API路由 -> 前端类型 -> Hooks/客户端 -> UI组件 -> 测试

全栈（Python + TypeScript）：

数据库模型 + 迁移脚本
服务/业务逻辑层
API路由（FastAPI或tRPC）
前端API客户端
封装API调用的React hooks
消费hooks的UI组件
代码检查 -> 类型检查 -> 测试 -> 提交

Rust：

错误类型（使用
```
thiserror
```
枚举并添加
```
#[from]
```
属性）
类型定义（结构体、枚举）
核心逻辑（
```
impl
```
块）
模块关联（
```
mod.rs
```
重导出）
```
cargo check
```
->
```
cargo clippy
```
->
```
cargo test
```

关键发现： 数据库迁移脚本应在需要它的代码编写完成后再编写。前端驱动后端变更的频率与后端驱动前端变更的频率相当。

Verification Cadence

验证节奏

The single most impactful practice. Get this right and everything else follows.

Gate	When	Speed
Typecheck	After every 2-3 edits	Fast (primary gate)
Lint (autofix)	After implementation batch	Fast
Tests (specific)	After feature complete	Medium
Tests (full suite)	Before commit	Slow
Build	Before PR/deploy only	Slowest

这是影响最大的实践要点。做好这一点，其他工作都会随之顺畅。

验证关卡	执行时机	速度
类型检查	每完成2-3次编辑后	快速（首要验证关卡）
代码检查（自动修复）	完成一批次实现后	快速
（特定）测试	功能完成后	中等
（完整套件）测试	提交前	缓慢
构建	仅在PR/部署前	最慢

The Edit-Verify-Fix Cycle

编辑-验证-修复循环

The sweet spot: 3 changes -> verify -> 1 fix. This is the most common successful pattern.

The expensive pattern: 2 changes -> typecheck -> 15 fixes (type cascade). Prevent by grepping all consumers before modifying shared types.

Combined gates save time:

turbo lint:fix typecheck --filter=pkg

runs both in one shot. Scope verification to affected packages, never the full monorepo.

Practical tips:

Run
```
lint:fix
```
BEFORE
```
lint
```
check to reduce iterations
```
cargo check
```
over
```
cargo build
```
(2-3x faster, same error detection)
Truncate verbose output:
```
2>&1 | tail -20
```
Wrap tests with timeout:
```
timeout 120 uv run pytest
```

最优节奏：3次修改 -> 验证 -> 1次修复。这是最常见的成功模式。

低效模式：2次修改 -> 类型检查 -> 15次修复（类型级联错误）。可通过在修改共享类型前搜索所有使用方来避免这种情况。

组合验证关卡节省时间： 使用

turbo lint:fix typecheck --filter=pkg

可一次性运行代码检查自动修复和类型检查。将验证范围限定在受影响的包，不要针对整个单体仓库。

实用技巧：

在运行
```
lint
```
检查前先执行
```
lint:fix
```
，减少迭代次数
使用
```
cargo check
```
而非
```
cargo build
```
（速度快2-3倍，错误检测能力相同）
截断冗长输出：
```
2>&1 | tail -20
```
给测试添加超时限制：
```
timeout 120 uv run pytest
```

Decision Trees

决策树

Read vs Edit

阅读 vs 编辑

Familiar file you edited this session?
  Yes -> Edit directly (verify after)
  No  -> Read it this session?
    Yes -> Edit
    No  -> Read first (79% of quick fixes start with reading)

是否是你本次会话中编辑过的熟悉文件？
  是 -> 直接编辑（之后验证）
  否 -> 你本次会话中读过该文件吗？
    是 -> 编辑
    否 -> 先阅读（79%的快速修复从阅读开始）

Subagents vs Direct Work

子Agent处理 vs 直接处理

Self-contained with a clear deliverable?
  Yes -> Produces verbose output (tests, logs, research)?
    Yes -> Subagent (keeps context clean)
    No  -> Need frequent back-and-forth?
      Yes -> Direct
      No  -> Subagent
  No -> Direct (iterative refinement needs shared context)

任务独立且交付成果明确？
  是 -> 会产生冗长输出（测试、日志、调研结果）吗？
    是 -> 交给子Agent处理（保持上下文清晰）
    否 -> 需要频繁来回沟通吗？
      是 -> 直接处理
      否 -> 交给子Agent处理
  否 -> 直接处理（迭代优化需要共享上下文）

Refactoring Approach

代码重构方法

Can changes be made incrementally?
  Yes -> Move first, THEN consolidate (separate commits)
        New code alongside old, remove old only after tests pass
  No  -> Analysis phase first (parallel review agents)
        Gap analysis: old vs new function-by-function
        Implement gaps as focused tasks

能否进行增量式修改？
  是 -> 先迁移代码，再合并（分开提交）
        新代码与旧代码并存，仅在测试通过后移除旧代码
  否 -> 先进行分析阶段（多Agent并行评审）
        差距分析：逐函数对比新旧实现
        将差距作为聚焦任务逐一实现

Bug Fix vs Feature vs Refactor

Bug修复 vs 功能开发 vs 代码重构

Type	Cadence	Typical Cycles
Bug fix	Grep error -> Read 2-5 files -> Edit 1-3 files -> Test -> Commit	1-2
Feature	Plan -> Models -> API -> Frontend -> Test -> Commit	5-15
Refactor	Audit -> Gap analysis -> Incremental migration -> Verify parity	10-30+
Upgrade	Research changelog -> Identify breaking changes -> Bump -> Fix consumers	Variable

类型	流程	典型循环次数
Bug修复	搜索错误 -> 阅读2-5个文件 -> 编辑1-3个文件 -> 测试 -> 提交	1-2
功能开发	计划 -> 模型 -> API -> 前端 -> 测试 -> 提交	5-15
代码重构	审计 -> 差距分析 -> 增量迁移 -> 验证一致性	10-30+
版本升级	调研变更日志 -> 识别破坏性变更 -> 升级版本 -> 修复受影响的代码	不固定

Error Recovery

错误恢复

65% of debugging sessions resolve in 1-2 iterations. The remaining 35% risk spiraling into 6+ iterations.

65%的调试会话可在1-2次迭代内解决。 剩余35%的会话可能陷入6次以上的迭代螺旋。

Quick Resolution (Do This)

快速解决方法（推荐）

Read relevant code first (79% success correlation)
Form explicit hypothesis: "The issue is X because Y"
Make ONE targeted fix
Verify the fix worked

先阅读相关代码（与79%的成功案例相关）
形成明确假设：“问题是X，因为Y”
进行一次针对性修复
验证修复是否有效

Spiral Prevention (Avoid This)

避免陷入调试螺旋的方法

Separate error domains — fix ALL type errors first, THEN test failures. Never interleave.
3-strike rule — after 3 failed attempts on same error: change approach entirely, or escalate.
Cascade depth > 3 — pause, enumerate ALL remaining issues, fix in dependency order.
Context rot — after ~15-20 iterations,
```
/clear
```
and start fresh. A clean session with a better prompt beats accumulated corrections every time.

分离错误域 —— 先修复所有类型错误，再处理测试失败。绝不要交叉进行。
三次尝试规则 —— 针对同一错误尝试3次仍失败后：完全更换方法，或寻求协助。
级联错误深度>3 —— 暂停，列出所有剩余问题，按依赖顺序修复。
上下文混乱 —— 经过约15-20次迭代后，使用
```
/clear
```
命令重置并重新开始。一个带有更优提示的干净会话，永远比积累了大量修正的混乱会话效果更好。

The Two-Correction Rule

两次修正规则

If you've corrected the same issue twice,

/clear

and restart. Accumulated context noise defeats accuracy.

如果你已经两次修正了同一个问题，使用

/clear

命令重置并重新开始。积累的上下文噪音会降低准确性。

Anti-Patterns

反模式

Anti-Pattern	Fix
20+ edits without verification	Verify every 2-3 edits
Fix without verifying the fix (73% of fixes!)	One fix, one verify, repeat
`fix -> fix -> fix` chains without checking	Always verify between fixes
Editing without reading first	Read the file immediately before editing
Writing tests from memory	Read actual function signatures first
Changing shared types without grepping consumers	`Grep` all usages before modifying shared types
Mixing move and change in one commit	Move first commit, change second commit
Debugging spiral past 3 attempts	Change approach or escalate
Premature optimization	Correctness first, optimize after tests pass

反模式	修复方法
20次以上编辑未进行验证	每2-3次编辑后就进行验证
修复后未验证修复效果（73%的修复都存在这个问题！）	一次修复，一次验证，重复此流程
`修复 -> 修复 -> 修复` 链式操作而不进行验证	每次修复后都必须验证
未阅读代码就直接编辑	编辑前立即阅读文件
凭记忆编写测试	先阅读实际的函数签名
修改共享类型前未搜索所有使用方	修改共享类型前先用 `Grep` 搜索所有使用方
在一次提交中同时进行移动和修改操作	先提交移动操作，再提交修改操作
调试螺旋超过3次尝试	更换方法或寻求协助
过早优化	先保证正确性，测试通过后再进行优化

Cross-Model Review

跨模型评审

For high-stakes changes, use

/hyperskills:codex-review

after implementation. A fresh model context eliminates implementation bias and catches real bugs: migration idempotency, PII in debug logging, empty array edge cases, missing batch limits.

对于高风险变更，在实现完成后使用

/hyperskills:codex-review

。全新的模型上下文可消除实现偏见，发现真实的Bug：比如迁移的幂等性、调试日志中的PII、空数组边缘情况、缺失的批量处理限制等。

References

参考资料

For quantitative benchmarks and implementation archetype templates, consult

references/benchmarks.md

如需量化基准和实现原型模板，请查阅

references/benchmarks.md

。

What This Skill is NOT

该Skill不适用的场景

Not a gate. Don't follow all five phases for a typo fix. Scale selection exists for a reason.
Not a replacement for reading code. This skill tells you HOW to implement, not WHAT to implement.
Not a planning tool. Use
```
/hyperskills:plan
```
for task decomposition.
Not an excuse to skip tests. "Verify" means running actual checks, not eyeballing the diff.

不是强制流程。对于拼写错误修复这类微小任务，无需遵循全部五个阶段。规模适配策略的存在就是为了应对这种情况。
不能替代阅读代码。该Skill告诉你如何实现，但不会告诉你要实现什么。
不是规划工具。如需任务分解，请使用
```
/hyperskills:plan
```
。
不是跳过测试的借口。“验证”指的是运行实际的检查，而非仅凭肉眼查看代码差异。