执行方法论 · Speed & Certainty

六个月解决
不要等十年

把模糊的问题，变成可拆解、可验收、可交付的东西。

// 彼得·蒂尔的速度感 ＋ 西蒙斯「一定有方法建模」的确定性

SPEC BEFORE CODE OUTCOME > PROCESS DESIGN → EXECUTE → AUDIT INDEPENDENT SESSIONS
0月
能解决就别留给十年
0页
Spec + 验收标准的篇幅上限
0段
设计 · 执行 · 验收
0+
验收必须换一个独立 session
SCROLL / 向下滚动
01
Method 01 · Spec Before Code

需求写清楚，验收说明白

Spec 不用复杂，但必须清晰到没有第二种理解方式。

写需求，落在哪个象限
概念框架 · 非统计数据
目标区 · 一页纸讲清楚 清晰但啰嗦：能接受 陷阱 · 写得多没讲清 危险 · 说得少还含糊 复杂度 → ↑ 清晰度 清晰的 Spec 含糊的需求 冗长的文档
● 一页纸也够，只要讲清楚 ▲ 写得少也没用 ■ 写得多也没用
02
Method 02 · Repeat The Outcome

不停强调结果，而不是过程设计

过程留给执行者自由发挥，但「要什么结果」必须被反复讲清楚。

结果先讲一遍OUTCOME FIRST 理解一致了吗 ALIGNMENT GATE 否 · 再讲一遍 是 · 放行 留在这一步NOT YET 路径自由PROCESS = OPEN 验收对照结果ACCEPTANCE

// 纠结过程细节，往往是怕执行者做错的心理补偿

03
Method 03 · Design → Execute → Audit

设计、执行、验收，交给不同 session

三段职责独立，换一双眼睛，别自己验收自己。

拆解问题
写 Spec
执行交付
独立验收
设计
Session
01找到可执行的最小单元
02一页 Spec + 验收标准
执行
Session
03按 Spec 动手，路径自选
审计
Session
04对照最初的验收标准复核

// 序号跨行跳 = 一次交接：02→03 设计交执行，03→04 执行交审计

「6 个月能解决的，不要等 10 年；价格这种东西，一定有办法能建模出来。」 —— Peter Thiel / Jim Simons