iterative-code-evolution

Iterative Code Evolution 是一种源自 ALMA（Automated meta-Learning of Memory designs for Agentic systems）学术研究框架的代码改进方法论，旨在通过结构化的六阶段循环（ANALYZE → PLAN → MUTATE → VERIFY → SCORE → ARCHIVE）替代传统的"试错式"调试。

核心用法方面，该技能要求用户严格遵循"分析-计划-变异-验证-评分-归档"的闭环流程。每次迭代开始前，必须基于观察进行结构化诊断（ANALYZE），标记代码组件状态（Working/Fragile/Broken/Redundant/Missing），并提炼出基于证据的改进建议，严禁"可能有用"的投机性修改。变更实施（MUTATE）阶段限制每轮最多 3 个改动，确保可准确归因效果。通过 .evolution/log.json 维护完整的进化日志，记录每个变体的父版本、变更内容、评分增量（delta vs parent）和学习总结（principles learned），形成可累积的组织记忆。

显著优点包括：首先，彻底改变了"随机尝试-失败-再尝试"的低效模式，强制要求每个变更必须链接到具体观察；其次，通过"visit penalty"机制（评分公式中的访问次数惩罚）防止在局部最优解上过度挖掘，鼓励探索不同组件；第三，3 次重试后强制回退（revert to parent）的机制有效避免调试死循环；第四，长期维护的 principles_learned 列表成为特定代码库的宝贵知识资产。

潜在缺点与局限性不容忽视：该方法论引入显著的过程 overhead，维护进化日志和版本分支需要额外工作量；对于简单的一次性代码生成或明确重构任务，此流程显得过度工程化；要求使用者具备高度自律，抵制"顺手多改一点"的冲动；此外，文件系统中残留的 .evolution 目录和多个变体文件可能造成项目管理混乱。

适合人群主要包括：处理顽固性或复发性 bug 的工程师、需要多轮优化性能或设计的系统架构师、迭代改进 Prompt 或 Agent 设计的 AI 应用开发者，以及已尝试 2 种以上方法仍无法满意、需要更严谨策略的复杂问题场景。不适用于简单代码生成或用户已明确指定修改内容的机械任务。

使用风险主要涉及过程风险：若未能严格执行"每轮最多 3 个变更"原则，可能导致改进效果无法归因；长期积累的变体文件若不及时清理，可能占用存储空间；依赖人工维护的日志若出现遗漏，将破坏知识累积的完整性；此外，该方法对使用者的根因分析能力要求较高，错误的诊断将导致后续迭代方向系统性偏差。