我的 AI 辅助编程工作流

背景

刚开始接触 AI 辅助编程时，我常常直接把需求抛给模型，然后复制粘贴生成的代码。结果虽然能跑，但很快就会发现边界条件没处理、错误提示不友好，甚至整体架构与现有代码风格不一致。经过几个月的实践，我逐渐形成了一套人与模型分工协作的工作流，让 AI 成为“副驾驶”，而不是替代我思考的黑箱。

这套工作流的核心原则是： me 负责决策与质量把控，模型负责快速生成与局部实现。下面按阶段展开说明。

工作流概览

整个流程可以分为五个环节：

1. 需求拆解：把用户故事或 Bug 拆成可验证的小任务。
2. 方案讨论：与模型讨论接口设计、数据流与异常处理。
3. 伪代码生成：先输出结构清晰的伪代码，而不是直接给实现。
4. 单元测试补全：让模型根据伪代码生成测试用例，再反向补全实现。
5. 代码重构：在功能跑通后，再做命名、抽函数、去重复等工作。

这五个环节并不是一次性完成的，而是在每个小任务里循环迭代。任务拆得越小，模型的输出越容易控制，我也越容易发现它是否偏离了目标。

关键环节实践

1. 需求拆解：用输入输出定义任务

我会先写出该任务的输入、输出和关键约束。例如，一个“解析 Markdown 标题”的任务，我会描述清楚：输入是字符串，输出是标题级别和标题文本的数组，约束是兼容 ATX 和 Setext 风格。把这些信息放进 Prompt 后，模型生成的代码往往更贴近预期。

2. 方案讨论：先对齐设计

在正式写代码前，我会让模型列出两到三种实现思路，并说明各自的优缺点。例如实现缓存时，是用内存字典还是 Redis？我会结合项目现状选择其中一种，避免模型默认采用最复杂或最简陋的方案。

3. 伪代码生成：降低返工率

直接让模型输出可执行代码，很容易陷入细节。我现在的做法是要求它先输出伪代码，包含函数名、参数、返回值和关键步骤。确认结构无误后，再让它把伪代码翻译成目标语言。

4. 单元测试补全：用测试约束行为

测试用例是最好的一致性契约。我会让模型先写正常路径和边界路径的测试，然后运行测试看是否通过。如果测试用例本身有漏洞，我会补充后再让模型修改实现。

5. 代码重构：最后做打磨

功能跑通后，我会要求模型只做一件事：在不改变行为的前提下优化可读性。包括重命名变量、抽取私有函数、统一异常处理等。这个步骤单独做，能显著降低重构引入 Bug 的概率。

踩过的坑

• 一次性给太多上下文：上下文超过模型的有效窗口后，它会“失忆”，导致中间步骤被忽略。拆任务比堆上下文更有效。
• 没有明确输出格式：如果不约束输出格式，模型容易在解释和代码之间反复横跳，增加提取成本。
• 完全相信生成的代码：模型擅长生成“看起来像对的代码”，但对业务边界、权限控制、性能瓶颈不一定敏感，必须人工审查。
• 忽略版本控制：在让模型做较大改动前，先提交一次代码，方便随时回滚。

结论

AI 辅助编程最大的收益不是“写得更快”，而是“把重复性思考外包给模型，把精力留在关键决策上”。当我把工作流拆成需求、方案、伪代码、测试、重构五个环节后，代码质量明显提升，返工次数也大幅减少。