iterative-code-evolution

核心用法

Iterative Code Evolution 是一套结构化的代码改进方法论，采用六阶段循环：ANALYZE（诊断）→ PLAN（规划）→ MUTATE（实施）→ VERIFY（验证）→ SCORE（评分）→ ARCHIVE（归档）。用户通过维护 .evolution/log.json 记录每次迭代的变更、评分和学习成果，形成可追踪的进化历史。每次循环限制最多3个变更，确保改进效果可归因，避免盲目试错。

显著优点

1. 系统化替代经验主义：将"试试再改"的随意做法转化为有纪律的科学实验，特别适合已尝试2种以上方案仍失败的顽固问题。
2. 知识沉淀机制：通过 principles_learned 字段积累针对特定代码库的有效模式，失败尝试同样被记录为避坑指南。
3. 探索-利用平衡：引入ALMA的"访问惩罚"机制，当同一组件连续迭代收益递减时自动转向其他组件，避免局部最优陷阱。
4. 失败价值化：3次重试失败后强制回退并记录失败模式，防止无效螺旋，将负面经验转化为决策资产。

潜在缺点与局限性

1. 认知开销较高：完整的六阶段流程对简单问题显得笨重，不适合一次性代码生成或机械性重构任务。
2. 评分主观性：缺乏自动化测试覆盖时，评分依赖人工判断，可能引入评估偏差。
3. 日志维护负担：.evolution/log.json 需要人工维护，在快速原型阶段可能成为阻力。
4. 学习曲线陡峭：用户需理解状态机标注、访问惩罚算法等概念才能发挥全部效能。

适合的目标群体

• 处理复杂系统设计的软件架构师
• 优化性能瓶颈或调试顽固缺陷的高级开发者
• 需要迭代改进AI提示词、Agent管道的AI工程师
• 追求代码质量持续改进的技术团队

使用风险

该Skill本身为纯文档指导，无代码执行能力，风险极低。主要潜在问题包括：用户可能因流程繁琐而放弃结构化方法回归随意修改；长期积累的 .evolution// 目录可能占用磁盘空间；评分标准不一致导致迭代方向偏离。建议配合自动化测试工具使用以提升评分客观性。

核心功能

iterative-code-evolution 是一套受 ALMA（自动化元学习记忆设计）研究启发的代码迭代方法论，将传统「尝试-修复」的随意模式转化为分析→计划→变异→验证→评分→归档的六步 disciplined 循环。它强制要求每一次代码变更都必须链接到具体观察，通过 .evolution/log.json 记录所有变体及其效果，实现可追踪、可学习的进化式开发。

显著优点

1. 科学归因机制：限制每轮最多3个变更，强制评分与父版本对比（而非仅与基线对比），使改进来源可精确追溯
2. 失败知识化：3次重试失败后强制回退并归档失败模式，将「此路不通」转化为可复用的组织知识
3. 探索-利用平衡：引入「访问惩罚」机制（visit penalty），避免在单一组件上陷入局部最优，确保设计空间的全局搜索
4. 零执行风险：纯 Markdown 文档型 Skill，无可执行代码、无外部依赖、无网络调用

潜在局限

• 认知负担：严格的日志归档和结构化分析对简单任务可能过度，适合2次以上迭代仍不达标的复杂场景
• 评分主观性：非测试场景（如代码可读性、LLM输出质量）依赖人工或启发式评分，可能引入偏差
• 工具链缺失：日志管理、变体切换需手动操作，未提供自动化 CLI 工具
• 社区维护风险：来源为个人开发者/社区项目（T3），长期维护稳定性依赖作者投入

适合人群

• 需要调试顽固缺陷或优化性能的资深开发者
• 设计 Agent、Prompt Pipeline 等需要多轮精调的 AI 系统工程师
• 研究团队进行算法或架构的系统性探索实验
• 不适用于：简单一次性代码生成、机械式重构任务

常规风险

• 过度工程化：对简单问题应用完整六步流程可能降低效率，需严格遵循「When NOT to Use」指引
• 评分标准漂移：多轮迭代中若评分方法不一致，可能导致优化方向偏离真实需求
• 变体管理复杂：分支策略（Modify in place vs. Branch）需团队达成共识，否则产生版本混乱