“这里的’巨婴’不是指人格，而是指一种危险的技能空心化状态：AI 替你解决了 100 个问题，但你获得的经验值为 0…”

项目信息

MirrorForge
Turn vibe coding sessions into structured engineering growth.

GitHub: https://github.com/hqy2435662352/mirror-forge

在 AI 编程越来越普及的今天，很多开发者已经进入了一种新的工作状态：

报错了，用 AI。
要重构，用 AI。
逻辑乱了，用 AI。
接口对不上，还是用 AI。

效率确实提高了，很多过去要花几个小时解决的问题，现在几分钟就能推进。

但这里有一个很少被正面讨论的问题：

代码修好了，可你自己真的变强了吗？

这正是我做 MirrorForge 的原因。

它不是一个普通的 code review skill，也不是一个“夸 AI 改得多漂亮”的总结器。
它更像一面镜子：当你在 AI 协作编程中暴露出工程和代码水平上的薄弱环节时，它会尽量把这些信号抓出来，整理成可复用的成长线索。

一句话说：

MirrorForge 想做的，不是继续优化代码，而是帮助开发者看见：这次 AI 帮你修复的东西，背后暴露了你什么样的工程能力缺口和代码水平问题，以及如何提升。

---

为什么我觉得这件事值得做

现在很多 AI coding workflow，最大的问题不是“不够强”，而是AI强得太容易让人跳过反思。

你把问题往编程Agent软件里一输。
AI 帮你补上边界判断。
AI 帮你拆模块。
AI 帮你修掉空指针。
AI 帮你把一个危险分支改成更稳妥的实现。

结果当然是好的。
但坏消息是：

你很可能只看到了**“它修好了”，却没看到“你原来写成这样为什么不对”**。

于是就会出现一种非常常见的状态：

• 这次 bug 修掉了
• 这次 refactor 也过了
• 这次代码确实比原来更好了
• 但下一次遇到类似问题，你大概率还是会在相似的地方摔倒

因为真正没被解决的，不是这段代码本身，而是你在写这段代码时暴露出来的工程模式。

比如：

• 你是不是总是先把主流程写通，再补验证？
• 你是不是默认输入“应该没问题”，所以边界判断总是后补？
• 你是不是习惯把实现逻辑和领域假设揉在一起？
• 你是不是在重构时容易高估“这个分支应该没风险”？
• 你是不是每次都在修不同的问题，但底层模式其实是同一个？

这些，才是真正有复利价值的东西。

AI 已经很擅长帮你“修代码”了。
但我更感兴趣的是：

能不能把一次 AI 协作编程，顺手变成一次对开发者自身工程习惯的诊断？

这就是 MirrorForge 想做的事。

---

MirrorForge 到底是什么

MirrorForge 是一个面向 AI 协作编程场景的 reflective skill。

它的核心不是评价最终代码写得好不好，而是分析：

• 用户原始实现里暴露了什么问题
• 这些问题更像是一次性失误，还是某种持续出现的工程模式
• 它们可能映射到什么能力缺口
• 下一步最值得建立的防御性习惯是什么
• 哪些内容值得沉淀进长期 playbook

所以它关注的不是：

• “AI 这次重构得真优雅”
• “最终代码更简洁了”
• “这里可以用某某设计模式”

它真正关注的是：

这次 task 暴露了开发者什么问题。

这也是 MirrorForge 最核心的一条原则：

Analyze the user, not the agent.

不是分析 AI 多聪明。
不是分析最终代码有多漂亮。
而是分析：开发者通过这次 AI 协作，暴露了什么工程信号。

---

我为什么觉得现有很多“反思型 prompt”还不够

现在也有一些看起来像“反思”的 prompt，但大多数会滑向两个方向：

第一种，是总结最终代码。
比如告诉你“这次重构提升了可维护性”“这次修复增强了健壮性”。

这些话不一定错，但它们更多是在评价结果，而不是诊断开发者。

第二种，是给抽象标签。
比如“你缺乏防御性编程意识”“你模块化能力较弱”“你容易实现先行”。

这些标签看起来很对，但如果没有严格证据，很容易变成一种“说得好像有道理，但其实无法追问”的空话。

我不希望 MirrorForge 变成这种东西。

所以我在设计它的时候，刻意把它做成了一套更偏证据驱动的 有严格workflow的skill，而不是一个只会输出高情商总结的 prompt。

---

MirrorForge 的关键不是“会反思”，而是“反思要有证据链”

MirrorForge 最重要的设计，不是文案，而是约束。

它会尽量优先使用最强的证据：

1. Diff-backed code evidence
   如果有用户原始代码和修改后代码的对比，这是最强证据。

2. Single code snapshot
   如果没有 diff，但至少有代码快照，也可以做分析。

3. Dialogue / decision evidence
   如果连代码都没有，才退化到只分析对话和决策模式。

这个顺序很重要，因为它决定了 MirrorForge 不会轻易滑向“纯感觉反思”。

尤其是当存在有意义的 diff 时，我希望它不能偷懒。
不能只做一些抽象总结，不能只讲用户“似乎比较急”，也不能只夸 AI 改得好。

它必须回答更硬的问题：

• 原始代码哪里错了？
• 这个错为什么不是单纯风格问题？
• 它为什么构成真实工程风险？
• 这个风险更像映射到哪个 gap，而不是别的 gap？
• 结论的把握有多高？边界在哪里？
• 下一步应该建立什么最小防御动作？

也就是说，一条完整分析不该只是一个判断，而应该是一条链：

raw evidence → what was wrong → why problematic → why this gap → confidence / limitation → concrete fix pattern

这是我最在意的地方。

因为我不想做一个“看起来很懂你”的 skill。
我想做一个尽量说得清楚、追得下去、站得住的 reflective workflow。

---

从“修复一次问题”到“沉淀一条成长线索”

MirrorForge 还有一个我很看重的点：

它不应该只在当前会话或任务里有用。

很多 AI 编程里的深刻修复，其实都死在会话关闭之后。
你当下觉得“这次讲得很透”，过两天就忘了。
过一周之后，再遇到相似问题，还是重新掉进去。

所以我给 MirrorForge 设计了一个 playbook 方向。

它的目标不是把每次分析都变成长篇大论存档，而是把真正值得保留的内容，沉淀成一种最低必要的长期记忆。

比如一条 playbook entry 可能会记录：

• 这个 gap 目前是一次观察，还是已经被多次确认
• 代表性证据是什么
• 哪些触发条件下它最容易再次出现
• 下一步最小行动是什么
• 未来写类似代码时，应该先检查什么

这样做的意义在于：

把 AI 帮你修过的坑，变成你以后更少掉进去的坑。

这里我也特意保留了一个边界：

MirrorForge 可以完成分析，但不应该擅自假设所有分析都必须被持久化。
所以分析和写入 playbook 是分开的。
它更合理的行为是：先完成分析，再问用户要不要把这次结果整理成 playbook draft。

这个边界很重要。
因为“我能分析”不等于“我可以替你定义长期成长档案”。

---

这东西最适合谁

我觉得 MirrorForge 最适合下面几类人：

第一类，是已经重度使用 AI 编程的人。
你已经离不开 Claude、ChatGPT、Copilot、各种 agent 了。你不是不用 AI，而是已经开始担心：

我是不是越来越依赖它修问题，却没建立起自己的工程内功？

第二类，是对**“开发者成长”**这件事有要求的人。
你不满足于让 AI 只是帮你快一点，你希望它还能帮助你发现自己在工程习惯、边界意识、重构判断、抽象能力上的真实短板。

---

我希望 MirrorForge 代表一种新的 AI 编程关系

我越来越觉得，AI 编程真正有意思的地方，不只是“它替你写了多少代码”。

而是它提供了一个以前没有过的机会：

过去很多工程短板，其实很难被稳定看见。
因为没有人会在你每一次小失误后，都认真地帮你抽出模式。
而现在，AI 恰好参与了大量你真实的编码过程，也恰好看到了你从第一版实现到最终修复之间的完整轨迹。

这就意味着：

AI 不只是一个帮你写东西的助手。
它也可能成为一个帮助你识别自己工程模式和代码水平认知的镜子。

MirrorForge 想抓住的，就是这个机会。

不是为了制造焦虑。
不是为了把开发者“诊断化”。
而是为了让 AI 协作编程不只留下产出，也留下成长。

---

最后

如果你也对这件事感兴趣，或者你也在思考：

• AI coding 之后，开发者到底获得了什么？
• 如何把一次次会话变成技术复利？
• 如何让 reflection 不沦为空话？

那也许你会对 MirrorForge 感兴趣。

它不是一个万能答案。
但我希望它至少提出了一个值得认真对待的问题：

在 vibe coding 的时代，我们能不能不只让 AI 帮我们写得更快，也让它帮我们成长得更快更踏实？

---