（2220期）iterative-code-evolution – 结构化代码进化方法论

结构化代码进化方法论 改编自 ALMA 学术研究框架的结构化代码改进方法论，通过 disciplined 的变异-评估循环系统提升代码质量，将盲目试错转化为可追溯的进化过程。 使用说明 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 个变更"原则，可能导致改进效果无法归因；长期积累的变体文件若不及时清理，可能占用存储空间；依赖人工维护的日志若出现遗漏，将破坏知识累积的完整性；此外，该方法对使用者的根因分析能力要求较高，错误的诊断将导致后续迭代方向系统性偏差。 原始说明 Systematically improve code through structured analysis-mutation-evaluation loops. Adapted from ALMA (Automated meta-Learning of Memory designs for Agentic systems). Use when iterating on code quality, optimizing implementations, debugging persistent issues, or evolving a design through multiple improvement cycles. Replaces ad-hoc "try and fix" with disciplined reflection, variant tracking, and principled selection of what to change next.