kai/knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e61baf7e4e3032fd805d4497117f53d6ca042ae9
knowledge-base/6 - Zettelkasten/20260320100200 目标回溯验证vs正向任务检查.md
Yaojia Wang e61baf7e4e vault: add GSD methodology deep-dive with examples and zettelkasten insights 
Comprehensive GSD analysis: 15 sections covering core philosophy (fresh
context per agent), 5 methodologies (dream extraction, goal-backward
verification, nyquist validation, wave execution, checkpoints), full
command reference (37+), agent system (16 agents with model routing),
config system, git integration, state management, session continuity,
community best practices, pitfalls, framework comparison (GSD vs ECC vs
BMAD vs SpecKit), and 4 detailed practical examples (new project, brownfield,
debugging, quick tasks).

Three zettelkasten notes: context rot vs window isolation tradeoffs,
goal-backward vs forward verification, plans-as-prompts design pattern.
2026-03-20 00:19:23 +01:00

1.1 KiB
Raw Blame History

created, type, tags, source
created type tags source
2026-03-20 10:02 zettel
verification
methodology
ai-quality
gsd
https://github.com/gsd-build/get-shit-done

目标回溯验证 vs 正向任务检查

传统软件验证是正向的: "任务 1 完成了吗？任务 2 完成了吗？全部完成 = 目标达成。" 这隐含假设任务列表是完备的。

GSD 的目标回溯验证(Goal-Backward Verification)反转方向: "用户应该能做什么？这个能力在代码中存在吗？不仅存在，还是真实实现（非桩代码）？不仅实现了，还与系统连接了？"

四级验证层次:

  1. Exists — 文件在预期路径
  2. Substantive — 真实实现，非 TODO/placeholder
  3. Wired — 与系统其他部分连接（import 被使用，API 被调用）
  4. Functional — 实际调用时能工作

这对 AI 生成代码尤其重要: LLM 擅长生成"看起来正确"的代码（通过 Level 1-2），但经常遗漏连接（Level 3）。GSD 的桩代码检测模式专门针对这一弱点。

Related