编写程序项目失败后，程序拆解失败全部数据，提炼经验因子，生成下一次项目的避坑创新方案。

🔥 FailForge — 失败项目拆解与经验因子提炼工具

把每一次失败，锻造成下一次成功的基石

一、实际应用场景描述

场景：技术 Leader 老张的"项目坟场"

老张，35岁，技术总监。过去两年，他手上倒了三个项目：

- 智能客服系统：投入80万，准确率卡在78%，客户退货

- 内部数据平台：做了一年，没人用，被公司工具替代

- 移动端重构：换了三个架构，性能反而更差

每次复盘会，大家都低着头。有人写几句"下次注意"就过去了。三个月后开新项目，同样的坑照踩不误。

老张的困境不是"能力不行"，而是"经验流失"：

- 失败的事实记在脑子里，但细节随时间模糊

- 复盘的教训是"感想"，不是"可执行的规则"

- 新人加入，没有人告诉他"这里有个坑"

- 公司层面的知识管理是 Word 文档，写完就没人看

FailForge 要解决的，是把老张的"项目坟场"变成"经验金矿"——用结构化的方式拆解失败，提炼出可检索、可复用、可验证的经验因子，并为下一个项目生成具体的避坑方案。

二、引入痛点

痛点 表现 后果 FailForge 的对策

"白干了"心态 项目失败了 = 一切归零 自我否定，团队士气低落 资产化：失败事实 → 经验因子 → 知识库

复盘流于形式 "下次注意""吸取教训" 无法指导具体行动 结构化：6维拆解 + 引导问题

教训不可检索 写在 Word 里，锁在网盘里 下次遇到同样问题想不起来 因子化：去上下文、可搜索、可引用

新人踩老坑 前人的教训没有传递 团队学习曲线重复支付 知识库：标签化 + 验证 + 引用计数

创新无处下手 "我们要创新"但不知道从哪 创新变成口号 从失败中孵化：创新因子专门捕获新方向

根因停留在表面 "沟通不够""时间太紧" 治标不治本 多层穿透：决策→假设→心理，逐层深挖

无法量化进步 "我们是不是在变好？" 缺乏反馈，难以坚持改进 验证机制：因子有效性评分 + 引用统计

三、核心逻辑讲解

数据流总览

失败发生

↓

【记录层】FailureRecorder

├── 项目基本事实（类型/根因/影响/决策/时间线）

└── → projects.json

↓

【拆解层】FailureDeconstructor (6维)

├── 决策层 → 我们做了什么选择？依据是什么？

├── 假设层 → 我们默认了什么"理所当然"？

├── 信息层 → 坏消息怎么流动的？

├── 执行层 → 哪里偏了？何时失控？

├── 外部层 → 环境怎么变了？

└── 心理层 → 我们被什么认知偏差蒙蔽了？

↓

【提炼层】FactorExtractor

├── 预置因子匹配（按失败类型）

├── 自动因子生成（高严重度维度 → 避坑因子）

├── 心理因子转化（认知偏差 → 启发式检查项）

└── 自定义因子（用户的个人洞察）

↓

【入库层】KnowledgeBase

├── 标签化索引

├── 有效性验证（validated/invalidated）

└── 引用计数 + 评分

↓

【锻造层】NextProjectForge

├── CheckList 生成（启动前/进行中/里程碑）

├── 创新提案（探索步骤 + 成功标准）

├── 风险预警（信号 → 行动映射）

├── 决策指南（原则 + 违规响应）

└── 4阶段执行计划 + 量化成功指标

↓

【导出层】ReportExporter

├── 项目级复盘报告（Markdown）

└── 团队级摘要报告

核心算法

1. 严重程度评估（_assess_severity）

文本长度 < 10 字符 → low（没深入反思）

文本含高信号词（"严重""完全""从未""崩溃"）→ high

文本含中信号词（"不足""偏差""延迟"）→ medium

纯长度判断（>100字符）→ medium

2. 经验因子提炼（extract_factors）

Step 1: 按 failure_type 匹配 PRESET_FACTORS → 生成 preset 因子

Step 2: 遍历拆解维度，severity=high → 生成 auto_generated 避坑因子

Step 3: 心理认知层内容 → 每个认知偏差 → 生成 heuristic 因子

Step 4: 用户自定义因子 → 直接入库

Step 5: 去重（title 标准化后比对）

3. 方案生成（forge_next_project）

获取因子 → 按类型分配到 CheckList 阶段

├── principle → pre_start + in_progress

├── pitfall → pre_start + milestone

├── heuristic → in_progress

├── pattern → in_progress + milestone

└── innovation → milestone

生成创新提案（从 innovation 因子 → 探索步骤）

生成风险预警（从 pattern 因子 → 信号+行动）

生成4阶段计划（启动→验证→交付→沉淀）

定义量化成功指标

四、代码模块化讲解

项目共 6 个核心模块，1640 行主代码，零第三方依赖。

模块一：FailureRecorder（行 1-260）

class FailureRecorder:

"""记录失败项目的基本事实"""

FAILURE_TYPES = {

"technical": "技术决策失误",

"scope_creep": "范围蔓延",

# ... 共10种类型

}

def record_project(self, name, failure_type, root_cause, ...):

"""

核心操作：将模糊的"项目黄了"转化为结构化数据。

强制字段：name, failure_type, root_cause, impact_level

可选字段：key_decisions, timeline_events, stakeholders

自动计算：duration_days = end_date - start_date

"""

设计要点：

"key_decisions" 字段记录了"我们当时为什么这么选"，这是后续拆解的原材料。

"post_mortem_notes" 保留原始感受，不被结构化字段过滤掉。

模块二：FailureDeconstructor（行 264-478）

class FailureDeconstructor:

"""6维拆解引擎"""

DECONSTRUCTION_DIMENSIONS = {

"decision_layer": {"label": "决策层", "questions": [...]},

"assumption_layer": {"label": "假设层", "questions": [...]},

# ... 6个维度，每个5个引导问题

}

def deconstruct(self, project_id, decision_notes, assumptions, ...):

"""

核心操作：对每个维度赋值 severity (low/medium/high)

自动识别 critical_failure_points（severity=high 的维度 + 负面时间线事件）

"""

def get_deconstruction_guide(self) -> str:

"""生成交互式引导文本（26个引导问题）"""

设计要点：引导问题覆盖认知偏差检测（"有没有'皇帝的新装'时刻？"）。

"_identify_critical_points()" 自动从 severity + 时间线中识别关键失败点。

模块三：FactorExtractor（行 481-820）

class FactorExtractor:

"""经验因子提炼器"""

PRESET_FACTORS = {

"technical": [

{"type": "principle", "title": "技术选型需经过 PoC 验证", ...},

{"type": "heuristic", "title": "架构复杂度检查清单", ...},

],

"scope_creep": [...],

# ... 覆盖8种失败类型

}

def extract_factors(self, project_id, custom_factors=None):

"""

核心算法：

1. 匹配预置因子模板（按 failure_type）

2. high severity 维度 → 自动生成避坑因子

3. 心理认知层 → 每个偏差 → 启发式因子

4. 用户自定义因子 → 直接入库

5. 去重

"""

设计要点：

"PRESET_FACTORS" 是工具的"智慧内核"——它编码了来自失败模式研究的通用经验。

"custom_factors" 允许用户输入个人洞察，保证工具不被预设限制。

模块四：NextProjectForge（行 823-1100）

class NextProjectForge:

"""避坑创新方案生成器"""

def forge_next_project(self, project_name, target_failure_types=None, ...):

"""

核心操作：将因子转化为可执行方案

├── _build_checklist() → 按因子类型分配到3个阶段

├── _build_innovation_proposals() → 创新提案 + 探索步骤

├── _build_risk_warnings() → 预警信号 + 响应动作

├── _build_decision_guidelines() → 原则 + 违规响应

├── _generate_phased_plan() → 4阶段执行计划

└── _define_success_metrics() → 量化指标

"""

设计要点：方案不是"建议"，是"可勾选的清单 + 可执行的步骤 + 可量化的指标"。每个 CheckList 项都标注了来源因子 ID，可追溯。

模块五：KnowledgeBase（行 1168-1300）

class KnowledgeBase:

"""经验因子知识库"""

def add_to_kb(self, factor_id, tags=None):

"""因子入库 + 分类索引"""

def validate_factor(self, factor_id, status, rating):

"""验证有效性 → 更新统计"""

def cite_factor(self, factor_id):

"""引用计数 +1"""

def search_kb(self, keyword, factor_type, min_rating):

"""多维度搜索"""

def export_kb_markdown(self) -> str:

"""导出为可读的知识库文档"""

设计要点：

"validation_status" 让团队可以标记"这条因子在后续项目中验证有效/无效"。

"times_cited" 自然浮现高频因子（最有价值的）。

模块六：ReportExporter（行 1330-1480）

class ReportExporter:

"""复盘报告导出器"""

def export_full_report(self, project_id) -> str:

"""生成5节完整 Markdown 报告"""

# 一、项目基本信息（表格）

# 二、多维失败拆解（6维度 + 关键失败点）

# 三、提炼的经验因子（按类型分组）

# 四、避坑创新方案（CheckList + 提案 + 预警 + 指标）

# 五、全局知识库状态

def export_enterprise_summary(self) -> str:

"""生成面向团队管理层的摘要"""

# 统计 + 失败类型分布 + 高频因子 Top10 + 行动建议

五、README 文件

完整的 README.md（198行）已包含在项目中，涵盖：项目简介、快速开始、项目结构、六大模块说明、设计原则、数据存储、适用人群、中立声明、MIT 许可。

六、使用说明

最快上手（5分钟）

from main import create_forge

forge = create_forge() # 使用默认 data/ 目录

r = forge["recorder"]

d = forge["deconstructor"]

e = forge["factor_extractor"]

f = forge["forge"]

kb = forge["kb"]

x = forge["exporter"]

# 1. 记录（项目失败后）

pid = r.record_project(

name="我的失败项目",

failure_type="technical", # 见 README 速查表

root_cause="一句话说清楚为什么失败了",

impact_level=3,

)

# 2. 拆解（隔1-2天，情绪平复后）

d.deconstruct(

project_id=pid,

decision_notes="逐条回顾关键决策，写详细一点...",

assumptions=["我们默认了XXX是对的"],

psychological_factors=["沉没成本", "团体迷思"],

)

# 3. 提炼

factors = e.extract_factors(project_id=pid)

# 4. 入库

for factor in factors:

kb.add_to_kb(factor["id"])

# 5. 生成下一个项目的方案

plan = f.forge_next_project(project_name="我的下一个项目")

# 6. 导出报告

report = x.export_full_report(pid)

print(report)

推荐节奏

时机 动作 耗时

项目终止当天

"record_project()" 记录事实 15 min

1-2天后

"deconstruct()" 多维拆解 30 min

拆解后立刻

"extract_factors()" 提炼因子 5 min

每周

"kb.validate_factor()" 回验 5 min

每月

"export_enterprise_summary()" 团队复盘 10 min

新项目启动前

"forge_next_project()" 生成方案 10 min

七、核心知识点卡片

项目中包含完整的

"knowledge_cards.md"（12张卡片），涵盖：

编号 理论 提出者 与工具的关联

1 预验尸法 (Pre-Mortem) Gary Klein (2007) Deconstructor 的时间线重建

2 归因理论 Heider/Weiner root_cause 字段设计

3 沉没成本谬误 Arkes & Blumer (1985) 心理层检测 + 止损因子

4 计划谬误 Kahneman & Tversky (1979) "预估×1.5"启发式因子

5 团体迷思 Irving Janis (1972) 决策层"反对声音"检查

6 双环学习 Chris Argyris (1977) 工具整体设计哲学

7 SECI 知识管理模型 野中郁次郎 (1995) Record→Extract→Forge 映射

8 FMEA 失效模式分析 美国军方 (1949) severity 评估 + 风险预警

9 成长型思维 Carol Dweck (2006) 工具命名与哲学

10 从失败中学习 Amy Edmondson (2011) 心理安全 + 失败分类 + 反思

11 反脆弱 Nassim Taleb (2012) 因子验证进化机制

12 事后回顾 AAR 美国陆军 (1970s) ReportExporter 设计模板

八、总结

FailForge 不是"失败归因器"，是"经验萃取器"。

它做的最重要的一件事，是把"我搞砸了"这种笼统的挫败感，翻译成"我在决策层犯了3个可识别的错误，其中2个有对应的可验证避坑规则"这种精确的、可行动的认知。

三个核心信念

1. 失败不是终点，是原材料

钢铁需要高温锻造才能成形。你的经验因子就是从失败的火焰中锻造出来的——没有高温，就没有好钢。

2. 教训不结构化 = 没有教训

"下次注意"四个字是世界上最没用的复盘结论。FailForge 强迫你把"注意"翻译成具体的、可检查的、可验证的规则。

3. 创新可能藏在废墟里

工具专门设了

"innovation" 类型的因子，目的就是捕捉那些"项目虽然失败了，但这个想法本身没错，只是时机/执行错了"的珍贵洞察。

给技术人的建议

1. 快记慢拆：项目刚结束时只记事实（防止记忆美化），1-2天后再做深度拆解（防止情绪干扰）

2. 因子要验证：提炼出来的因子不是真理，是假设。用 2-3 个项目验证后，才知道哪些是真金

3. 分享不是丢人：把因子库做成团队共享资源，新人入职第一周就看到"我们踩过这些坑"，比任何培训都有效

4. 定期清理：invalidated 的因子不要删，标记为"已证伪"——证伪本身也是知识

给团队 Leader 的建议

- 把 FailForge 的报告纳入 retrospection 流程

- 每月团队会议花 10 分钟回顾知识库增长

- 鼓励"分享失败"的文化——工具的数据透明性天然支持这一点

- 用知识库的统计数字（验证率、引用数）来量化团队的"学习能力"

中立声明：本项目为个人技术实践与学习成果，不含任何商业推广内容。代码逻辑透明，数据完全本地化存储。它不能让项目不失败，但能让每次失败的"学费"花得值——因为经验被留下来了。真正的成长源于持续的行动和反思，工具仅作辅助。

利用AI解决实际问题，如果你觉得这个工具好用，欢迎关注长安牧笛！