如何用状态机约束AI编程流程，提升代码质量

一、问题不在“写代码”，而在“流程失控”

过去一段时间，团队在推进智能编程工具落地时遇到一个非常典型的矛盾：AI 确实能显著提升编码速度，但当任务复杂度上升以后，生成结果的质量方差也随之变大。更棘手的是，不少问题并不是模型“不会写”，而是它“不按流程走”。

你要求先做需求澄清，它可能跳过分析直接给出实现；你规划了五步任务，它执行到第三步就忘记了前两步的约束；你开一个新会话继续昨天的任务，它却无法稳定恢复此前的上下文和决策依据。这种流程漂移带来的后果不是某一行代码写错，而是整个实现方向逐渐偏离原始设计。

因此，核心挑战并不是“如何让AI写出更多代码”，而是“如何让AI在正确的时间、只做正确的事”。

二、把开发流程抽象成状态机

针对上述问题，我们采用了一个相对轻量的工程化手段：将一次编程任务的生命周期建模为有限状态机。状态机并不直接约束模型输出，而是作为外层控制器，决定当前应该进入哪个阶段、允许执行哪些动作、如何判断阶段是否完成。

一个典型的状态集合可以包括：

• REQUIREMENT：需求澄清与任务边界确认
• DESIGN：方案设计与关键接口定义
• IMPLEMENT：编码实现
• TEST：测试用例生成与执行验证
• REVIEW：代码评审与质量检查
• DONE：任务完成

状态之间的迁移不是自由跳转，而是必须满足明确条件。例如，只有在需求澄清产物通过校验后，才允许进入设计阶段；只有设计文档中的关键约束被确认后，才允许开始编码。

这种做法的本质，是让流程从“模型自行决定下一步”转变为“由状态机决定下一步”。

三、用脚本充当“流程导航员”

在实践中，我们并没有引入复杂的工作流平台，而是使用一个自研脚本作为状态机的执行载体。该脚本负责三件事：

第一，维护当前状态。每一次与智能编程工具的交互，都携带明确的状态标识和阶段目标。

第二，校验阶段产物。每个阶段结束后，脚本会检查是否生成了必要内容。例如，需求阶段是否包含验收标准，设计阶段是否包含模块边界，编码阶段是否包含对应的测试入口。

第三，控制状态迁移。只有校验通过，才允许进入下一状态；否则会生成反馈信息，要求模型修复当前阶段的问题。

脚本本身逻辑并不复杂，核心是一个状态字典、一组校验规则和一个迁移函数。示例结构如下：

class WorkflowStateMachine:
    def __init__(self):
        self.state = "REQUIREMENT"
        self.artifacts = {}
    def allowed_actions(self):
        return {
            "REQUIREMENT": ["clarify", "define_acceptance"],
            "DESIGN": ["define_interface", "identify_risks"],
            "IMPLEMENT": ["write_code", "add_tests"],
            "TEST": ["run_tests", "fix_failures"],
            "REVIEW": ["check_quality", "refactor"],
        }.get(self.state, [])
    def validate_artifact(self, output):
        if self.state == "REQUIREMENT":
            return "acceptance_criteria" in output
        if self.state == "DESIGN":
            return "interface_spec" in output and "module_boundary" in output
        if self.state == "IMPLEMENT":
            return "source_code" in output and "test_entry" in output
        return True
    def transition(self, output):
        if self.validate_artifact(output):
            self.artifacts[self.state] = output
            next_state = {
                "REQUIREMENT": "DESIGN",
                "DESIGN": "IMPLEMENT",
                "IMPLEMENT": "TEST",
                "TEST": "REVIEW",
                "REVIEW": "DONE",
            }.get(self.state)
            if next_state:
                self.state = next_state
                return f"进入状态: {next_state}"
        return f"当前状态 {self.state} 产物校验未通过，请补齐必要内容"

这只是一个示意实现，但它清楚展示了状态机如何约束任务推进。真正的价值并不在代码复杂度，而在于它强制引入“阶段门禁”。

四、让提示词、产物与状态保持一致

状态机要真正生效，必须与每次请求的提示词结构深度绑定。否则模型仍然可能在某个状态下越界行动。

我们要求每个阶段的提示词必须包含三部分信息：

1. 当前状态说明：明确告知当前阶段名称与目标。
2. 允许动作列表：列出本阶段可以执行的操作，避免模型自行扩展任务。
3. 产物格式要求：规定输出内容必须包含哪些字段或段落，便于脚本校验。

例如，在需求澄清状态，提示词会明确要求输出“问题描述、目标用户、核心场景、验收标准、非目标范围”。如果模型提前给出实现方案，脚本会识别到产物缺少必要字段，从而阻止迁移。

这种方式将“不要跳步”从口头约束变成了可执行的工程约束。

五、会话切换与上下文恢复

智能编程工具在长任务中容易出现上下文遗忘。即使生成了大量代码，如果它忘记了此前定义的接口约束、命名规则或异常处理策略，后续修改就会反复破坏既有逻辑。

我们把每个阶段的产物持久化为任务档案。当新会话开始时，不要求模型“回忆历史”，而是把之前阶段的摘要与关键决策重新注入上下文。状态机在这里承担了记忆锚点的作用：它知道任务进行到哪个状态，知道哪些产物已经校验通过，知道下一步应该引用哪些信息。

这样做之后，跨会话继续任务不再依赖模型自身的长时记忆，而是依赖外部状态与产物恢复。

六、质量门禁从“事后审查”前移到“过程约束”

传统代码质量管控大多发生在提交或合并阶段，属于事后审查。智能编程引入之后，代码生成速度加快，如果仍然只依赖事后审查，问题会被迅速放大。

状态机的优势在于，它把部分质量检查前移到了每一个阶段。例如：

• 需求阶段强制产出验收标准，避免实现完成后才发现理解偏差；
• 设计阶段强制明确模块边界，减少后期大规模重构；
• 编码阶段强制要求测试入口，推动生成代码具备可验证性；
• 测试阶段强制记录失败与修复过程，保证问题可追溯；
• 评审阶段强制检查命名、复杂度与重复逻辑，形成质量闭环。

这种“过程约束 + 结果校验”的组合，比单纯依赖人工审查更适应高频生成场景。

七、实践收益与边界

使用该方案一段时间后，团队中智能编程工具“跑偏”的情况明显减少。任务执行路径变得可预期，需求与实现之间的偏差更容易被发现，跨会话协作也更稳定。更重要的是，开发人员不再需要耗费大量精力去纠正模型跳步行为，而是可以把注意力集中在方案判断与代码审查上。

当然，该方案也有边界。它适合任务边界相对清晰、阶段可拆分的开发工作，例如接口实现、模块重构、测试补齐、缺陷修复等。对于探索性极强、目标本身尚不明确的调研类任务，严格状态机可能限制模型发挥，需要采用更宽松的流程模式。

八、总结

智能编程带来的代码量增长，并不是质量问题本身，真正的风险在于流程失控。把开发任务抽象为状态机，通过脚本控制阶段迁移、校验阶段产物、管理上下文恢复，是一种成本较低且可落地的质量管控手段。

它不依赖特定模型能力，也不绑定某一家云厂商或工具平台，而是用经典软件工程方法约束新的生产方式。对于希望规模化使用AI编程的团队来说，这种“先管住流程，再谈生成质量”的思路，或许比单纯追求提示词技巧更值得投入。