Crucible Code：基于第一性原理做架构决策的Claude Code 插件

谁说程序员不能“系统性思考”？这个小工具让AI陪你做架构决策，还留下完整证据链

一个系统设计问题摆在面前，脑子里闪过好几个方案，但谁都说服不了谁。团队里有人力推微服务，有人坚持单体优先，有人说用 Redis 做队列，有人坚持 Kafka 更稳。吵到最后，往往不是谁逻辑最严密赢了，而是谁声音最大，或者谁资历最老拍板。

更惨的是，三个月后线上出事，没人记得当初为啥这么干，连 debug 都无从下手。这根本不是技术问题，而是“决策基础设施”的缺失。

工程师们缺的不是聪明才智，而是一套能帮他们结构化思考、系统性验证、可追溯复盘的决策流程。

而今天要介绍的这个开源项目——Crucible Code（熔炉代码），就是为了解决这个问题而生的。

灵感来自“第一性原理框架”：不只是 AI 工具，而是一套工程决策操作系统

Crucible Code 的作者 Ivan Zakutnii 是一位深度系统思维爱好者。他参加了由著名系统工程师 Anatoly Levenchuk 主讲的“工程师-管理者工作坊”。会上，Levenchuk 详细介绍了他创立的“第一性原理框架”（First Principles Framework, FPF）。这套框架极其庞大，全文高达 330 万字符（约 83 万 token），连最强的 LLM 都塞不下。

但它却凝聚了系统工程、认知科学与决策理论的精华——不是教你怎么写代码，而是教你怎么“做对事”。

Levenchuk 明确表示，他不想把 FPF 简化成一个工具，因为它的受众远不止程序员。
但 Ivan 却心想：“我是程序员啊！为什么不把它变成我们能用的东西？”
于是，Crucible Code 应运而生。

不是“智能自动补全”，而是你的“系统架构陪练”

很多人用 Claude、Copilot 这类 AI 工具，还停留在“写个函数”“修个 bug”的层面。

但真正高阶的用法，是把它当作一个能陪你深度思考的“思考伙伴”。Crucible Code 正是基于这一理念，为 Claude Code CLI 打造了一套 slash commands（斜杠指令），强制 AI 与你一起走完一个完整的“假设-验证-决策”闭环。

它不直接给你答案，而是逼你：先想出至少三个方案（保守型、创新型、激进型），再逐个逻辑推演，接着找证据测试，最后审计盲点，生成一份带完整理由的“设计决策记录”（Decision Rationale Record, DRR）。

整个过程，AI 是你的“方法论执行者”，而你，是那个不可替代的“外部决策者”——因为系统无法自我改造，必须由外部智能介入。

ADI 循环：Abduction（假设）、Deduction（演绎）、Induction（归纳）——工程师的科学决策三部曲

Crucible Code 的核心是 ADI 循环。

第一步，/fpf-1-hypothesize：别急着写代码！先让 AI 帮你头脑风暴 3-5 个方案，必须覆盖保守（比如用成熟技术栈）、新颖（比如引入新范式）、激进（比如彻底重构）三种类型。这一步就能避免“锚定效应”——人很容易被第一个想到的方案绑架。

第二步，/fpf-2-check：在动一行代码前，先做逻辑一致性检查。比如你打算上微服务，但团队只有两个初级开发，没 DevOps 支持——AI 会立刻指出：这逻辑上就行不通，会死在运维阶段。

第三步，/fpf-3-test 和 /fpf-3-research：光说不练假把式。要么跑个本地基准测试，要么去网上搜权威文档、案例。证据不足？那就别往下走。这三步环环相扣，缺一不可，命令行会强制你按顺序执行。

最怕“最弱一环”：审计阶段揪出你忽略的致命漏洞

很多人走到测试阶段就觉得稳了。

但 Crucible Code 还有一道“灵魂拷问”——/fpf-4-audit（审计）。
它基于 FPF 中的“最弱链接原则”（Weakest Link, WLNK）：整个方案的可信度，不取决于你最强的证据，而取决于最弱的那一环。比如你有个超快的内部压测（L2 证据，可信度 1.0），但引用的第三方文档却写着“此为实验性 API，切勿用于生产”（博客 L1 证据，可信度 0.65）——那整体可信度就被拉到 0.65。审计阶段还会检查：你有没有认知偏见？外部证据和你的技术栈/规模是否匹配（“一致性评估”）？会不会因为团队熟悉某技术就盲目选择？

这一步虽然可跳过，但作者强烈建议别省——因为 90% 的架构事故，都源于那个被忽视的“小瑕疵”。

决策不是终点，而是可追溯、可复盘、可演化的知识资产

当你运行 /fpf-5-decide，AI 会汇总所有上下文、假设、证据、风险，交由你拍板。

一旦选定，它会自动生成一份 DRR 文档，比如 decisions/DRR-001-order-fulfillment-coordination.md。这份文档不仅写明“我们选了啥”，更关键的是记录了“为啥不选其他方案”“触发重评的条件是什么”（例如：“当订单量超过每日 1 万单时，需重新评估”）。

这意味着，三个月后新同事接手，或系统出现瓶颈，你不需要靠记忆或翻聊天记录，直接查 DRR 就能理解当年的决策逻辑。

更妙的是，所有中间产物——假设、测试脚本、研究笔记——都按层级（L0/L1/L2/Invalid）存入 .fpf 目录，形成一个可搜索、可关联的知识库。这已经不是工具，而是一个团队的“集体决策记忆体”。

真实案例：25 分钟搞定技术债优先级，从“我觉得”到“证据确凿”

作者拿自己正在维护的一个遗留单体项目做实验。

项目有典型的技术债：测试缺失、代码混乱、团队疲于奔命。他本已“直觉”该先修测试，但用 Crucible Code 走了一轮 ADI 循环后，结果更扎实。

/fpf-1-hypothesize 给出三个方案：
H1（保守）修复测试并接入 CI；
H2（激进）全量重构为领域驱动设计（DDD）；
H3（新颖）引入强静态分析。

/fpf-2-check 立刻毙掉 H2——团队缺乏 DDD 经验，强行上只会拖垮开发节奏。
/fpf-3-test 显示：现有测试 2 秒跑完但大量失败；静态分析一跑就爆出 350+ 错误。

最终决策是 H1+H3 组合：修测试 + 设定静态检查基线。整个过程仅 25 分钟，但产出了一份带完整证据链的 DRR，直接转成 Jira 任务。作者感慨：以前这种决策可能要开三次会，现在一次结构化对话就搞定。

为什么不是“超级 AI 代理”？因为工程需要“可解释性”，不是“黑箱魔法”

市面上很多 AI 工具追求“全自动”：堆砌提示词、创建十几个子代理、一键生成整套系统。

但作者认为，这叫“氛围编程”（vibe coding），离真正的工程实践很远。

Crucible Code 的定位是“外骨骼”，不是“自动驾驶”。
它不替你思考，而是强化你的思考；
不隐藏过程，而是暴露每一步的逻辑与证据。
你始终清楚：方案 A 被淘汰是因为逻辑漏洞，方案 B 没选是因为缺乏团队经验——所有判断都有迹可循。

这种“透明性”才是工程可靠性的基石。正如作者所说：“你看到每一个步骤，你和 Claude Code 一起思考。” 这才是人机协作的正确姿势。

超实用辅助命令：状态追踪、知识搜索、证据保鲜，告别“断片式”开发

除了核心 ADI 循环，Crucible Code 还内置几个神级辅助命令。

/fpf-status 能告诉你当前处在哪个阶段、有哪些假设待处理、下一步该干啥——特别适合周一早上回到工位时快速找回状态。

/fpf-query 可全文搜索历史决策，比如“上个月关于缓存的所有验证证据”或“任务 XXX-123 被否掉的假设”。而 /fpf-decay 更是前瞻性设计：它会检查证据是否过期——一年前的压测数据、旧版文档、已弃用 API 的链接，都会被标记为“可能失效”。毕竟，基于过时信息的决策，无异于蒙眼开车。

这些功能共同构建了一个“活的”决策知识库，让团队经验真正沉淀下来，而非散落在 Slack 或个人笔记里。

用还是不用？先问这四个问题——别拿大炮打蚊子

当然，Crucible Code 并非万能。

作者明确划出使用边界：它专为“高成本、难逆转、影响大”的决策而设计。

在动手前，先自问：这个决策是否难以回滚？是否会影响超过几天的工作量？是否涉及多个未知变量？是否未来可能被质疑？只要有一个答案是“是”，就值得跑一遍 FPF 循环。

反之，如果是“把按钮改成红色”“写个排序函数”这种明确、可逆、低风险的任务，请直接动手——别用大炮打蚊子。工具的价值，在于用在刀刃上。

Crucible Code 的哲学是：对简单事保持敏捷，对复杂事保持严谨。

快速上手：三步开启你的结构化决策之旅

想试试？非常简单。

首先，克隆仓库：git clone https://github.com/m0n0x41d/crucible-code.git。然后，安装到你的项目目录（或全局）：./install.sh /path/to/your/project。

进入你的项目，启动 Claude Code，输入 /fpf-0-init —— AI 会扫描你的代码库，询问关键约束（比如技术栈、预期负载、预算），并生成 .fpf/context.md。

最后，抛出你的问题：/fpf-1-hypothesize "我们该如何处理跨服务事务一致性？"

接下来，就跟着提示一步步走吧。整个过程像有个严谨的架构师坐在你旁边，不断追问“为什么”“证据呢”“有没有反例”。

你会发现，思考的质量，远比编码的速度更重要。

超越代码：这套方法论可迁移到产品、运营甚至人生决策

虽然 Crucible Code 以程序员为首要用户，但作者在文末调皮地暗示：它的潜力远不止于此。

FPF 的本质是一套通用决策框架。产品经理可以用它评估功能优先级，运营可以用它设计增长策略，甚至个人可以用它做职业选择——先列出选项，再逻辑推演，接着找数据/案例验证，最后审计盲点。

只要你的决策涉及不确定性、高成本或长期影响，这套“假设-验证-记录”的流程就值得借鉴。而 Crucible Code，正是把这个抽象框架，变成了可执行、可协作、可留存的数字工具。

它让我们看到：思考，也可以被工程化。

开源、免费、MIT 协议——站在巨人的肩膀上构建决策力

最后值得一提，Crucible Code 采用宽松的 MIT 开源协议，完全免费。作者也特别注明：FPF 方法论的知识产权归 Anatoly Levenchuk 所有，本项目仅为其实现。这种对原创思想的尊重，也体现了工程社区的优良传统。

如果你认同“系统性思考”的价值，不妨给项目点个 Star，甚至贡献自己的命令扩展。毕竟，在 AI 时代，真正的护城河，不是谁会调用 API，而是谁拥有更严谨、更可追溯的决策能力。而 Crucible Code，正是帮你锻造这种能力的一把利器。