AI 编程工作流：从规则到实践

AI 编程工具的价值不仅在于生成代码的速度，更在于它能否被信任来完成关键任务。一套成熟的工作流应该包含明确的选择框架、可靠的验证机制、以及持续改进的自我反思能力。

Skill 选择框架：让专业工具做专业事

面对一个编程任务，AI 需要决定是自己直接处理还是调用专门的 Skill。这个决策框架基于两个维度：任务复杂度和协作需求。低复杂度、明确边界的任务（如修复一个已知的 bug）可以直接处理；高复杂度、多步骤流程（如实现一个完整功能）应该调用对应的 Skill；需要外部视角审查的场景（如代码 review）必须委派给专门的 agent。

常见的 Skill 类型包括：build-error-resolver 用于诊断构建错误，它比通用推理更擅长定位编译问题的根因；code-reviewer 用于代码审查，提供外部视角避免 tunnel vision；tdd-guide 用于测试驱动开发，强制先写测试再实现；performance-optimizer 用于性能分析，基于实际测量而非猜测选择优化方向。每个 Skill 都封装了特定领域的最佳实践和工作流程，调用 Skill 不仅是调用工具，更是调用一种经过验证的方法论。

选择 Skill 时需要避免「肌肉记忆」式的误用——看到一个类似场景就调用，而不评估当前任务的实际需求。正确的做法是先问自己：这个任务的核心挑战是什么？现有的 Skill 是否有专门针对这个挑战的版本？如果不确定，宁可先用通用方式处理一段，识别出具体难点后再寻找匹配的 Skill。

证据驱动的验证方法

AI 编程中最常见的失败模式是置信度幻觉：模型说「我认为这应该工作」然后直接声称完成，但实际没有验证过。证据驱动的验证方法要求每个声明都必须有对应的证据支撑，而不是依赖信心声明。

技术层的验证（build 成功、类型检查通过）是必要的，但不够充分。症状层的验证同样重要：如果修复的是一个 UI 问题，需要确认用户实际看到的症状消失了，而不是技术层指标正常就声称完成。例如，Astro 项目的 Tailwind CSS 两层结构问题可能导致 FOUC（无样式内容闪烁），技术层 build 成功不等于实际渲染正常，需要用 Playwright 或 DevTools 实际检查 computed style。

证据门控协议的强制执行顺序是：先收集证据，再对比症状，最后才是声称完成。这个顺序不能颠倒，因为验证证据和验证症状是两回事——「Build 成功」是技术层证据，「用户不再看到 FOUC」是症状层证据，两者必须在同一因果链上才算有效验证。

元认知机制：自我监测与进化

元认知机制的核心是为失败模式命名。人类有认知偏见命名（确认偏见、锚定效应），AI agent 也需要相同的词汇表来描述自己的失败模式。常见的命名失败模式包括：Confidence Mirage（信心幻象）——当模型说「我认为没问题」时触发，强制要求实际验证；Diagnostic Loop（诊断循环）——当同一个问题尝试了多种方案都失败时触发，强制进入诊断重启协议；Deja Vu Fix（似曾相识的修复）——当发现同一文件在短期内第二次出现同类修复时触发，必须先读取上次的 case 记录对比根因。

三修复断路器是元认知机制的重要组成部分：如果同一个问题尝试了 3 次修复都失败，就不再尝试第 4 次同类方案。前 3 次修复在当前心智模型内操作，第 4 次必须切换心智模型才能突破。这个断路器防止了在错误方向上的无效迭代，把精力转向重新审视问题本身。

规则进化：从个案到通用模式

AI 编程工作流应该具备从个案中提取通用模式的能力。当一个问题的解决经过多次尝试、失败、调整后最终成功时，这个过程应该被记录和提炼。记录不是简单的操作日志，而是结构化的经验总结：一个典型的 case 记录应该包含症状描述、原始上下文、解决路径（包括失败尝试和思维转变）、最终产物、验证方式、以及从个案中提炼的通用启发式。

进化触发信号包括：同一个问题被纠正 ≥2 次、同一文件在 30 天内第二次出现同类 bug、或者执行中发现规则之间相互冲突。这些信号都会触发强制性的规则审计，从个案中识别出可泛化的模式，然后更新到 Skill 或规则库中。这种机制保证了个人的经验教训可以被积累和复用，而不是每次遇到类似问题都从头开始。