AI 编程笔试的七阶段实战方法论

3 阅读

为什么需要结构化流程？

很多人在 AI 编程笔试中容易陷入两种极端：要么一上来就让 AI 写代码，结果越写越偏；要么反复修改同一个 bug，却忘了最初要交付什么。问题不在于 AI 能力不足，而在于缺乏一个能约束协作节奏的框架。

这套七阶段方法的核心思想是：用文档代替记忆，用证据代替感觉。每一步都产出明确的中间产物（如 01_问题定义.md），既作为后续步骤的输入，也作为上下文失稳时的回滚锚点。

阶段 1：先别写代码，搞清到底要做什么

很多笔试题描述模糊，比如“实现一个视频处理工具”，但没说清楚输入格式、输出要求或性能限制。这时候直接写代码等于赌博。

正确做法是让 AI 先输出一份《问题定义》，强制它回答五个关键问题：

  • 交付物清单：最终要交哪些文件？是命令行工具还是 Web 服务？要不要测试报告？
  • 硬约束：是否限定 Python 3.9？能否用第三方库？输入是本地文件还是 URL？
  • 隐含要求：题目说“高效处理”，可能暗示不能全量加载到内存；说“用户友好”，可能要求有进度条或错误提示。
  • 验收标准：比如“能处理 1GB 的 MP4 文件”“错误输入不崩溃”“输出文件可被 VLC 播放”。
  • 风险点：比如依赖 FFmpeg 但环境不一定有，或者并发处理可能引发资源竞争。

这一步花 5 分钟，能避免后面 30 分钟白干。如果 AI 回答里有【待确认】，要么追问，要么根据常识做合理假设并记录下来。

阶段 2：选最稳的路，不是最炫的

确定目标后，下一步是选技术路线。AI 往往会推荐“用 LangChain + FastAPI + Celery”的豪华组合，但在限时笔试中，稳定比先进更重要。

让 AI 对比 2~3 个方案，重点看三点：

  1. 实现复杂度：是否依赖外部服务？是否需要处理多线程？
  2. 可测试性：能不能用几行命令快速验证核心逻辑？
  3. 风险可控性：如果某个环节失败，会不会导致整个流程卡住？

例如处理视频转码，方案 A 是调用 FFmpeg 命令行，方案 B 是用 OpenCV 逐帧处理。前者虽然“不够优雅”，但只要系统装了 FFmpeg 就能跑，后者则要处理编解码、帧率同步等细节，容易翻车。在笔试场景下，选 A 更稳妥。

阶段 3：搭好骨架再填肉

选定方案后，不要急着写函数体。先让 AI 输出系统骨架，包括：

  • 模块划分：比如 video_parser.py 负责解析输入，transcoder.py 负责调用 FFmpeg，cli.py 处理命令行参数。
  • 目录结构：建议用树形图，比如 src/ 下放核心代码，tests/ 放测试脚本。
  • 核心接口：比如 transcode(input_path: str, output_format: str) -> str，只写签名不写实现。
  • 主链路时序：用户输入 → 解析参数 → 验证文件 → 调用转码 → 输出结果。

这个骨架相当于施工图纸。后续每次让 AI 写代码，都要求它“按 03_系统骨架.md 的结构生成”，能有效防止它擅自新增模块或改变接口。

阶段 4：先跑通最短路径

很多人一上来就想把所有功能写全，结果主流程还没跑通，时间就耗完了。正确的做法是先实现最小可运行闭环（MVP）。

例如视频处理工具的 MVP 可能是：

  1. 接收一个本地 MP4 文件路径
  2. 调用 FFmpeg 转成 AVI
  3. 输出新文件路径

其他功能——比如支持 URL 输入、批量处理、进度显示——全部先不做。让 AI 明确列出“现在必须做”和“现在明确不做”的事项，避免它偷偷加功能。

每生成一个文件，立刻手动运行验证。比如写完 cli.py 后，执行 python cli.py input.mp4 avi 看是否真能生成 output.avi。如果失败，用“急救 1”提示词进入调试模式，先复现问题再修复。

阶段 5：补上异常和边界

主链路跑通后，花 15 分钟专门处理异常情况。这时候让 AI 切换身份，扮演“安全审查员”，重点检查：

  • 输入校验：文件不存在、格式不支持、路径含空格或中文
  • 权限边界：临时文件是否清理？能否读取系统敏感目录？
  • 失败兜底：FFmpeg 崩溃时是否返回错误码？磁盘满时会不会无限重试？

优先修复高风险项，比如“输入非法路径导致程序崩溃”，低风险项如“未处理超长文件名”可以记入 KNOWN_LIMITS.md。

阶段 6：用证据说话，别凭感觉

很多考生觉得“差不多能跑了”就交卷，结果漏掉关键验收点。阶段 6 要求 AI 输出《验收自检报告》，逐项验证：

  • 环境检查：python --version 是否符合要求？
  • 依赖检查：import ffmpeg 是否成功？
  • 端到端测试：用三个不同视频文件测试转码是否成功
  • 异常测试：传入 txt 文件是否报错而不崩溃

报告里必须明确结论：“现在能不能交？如果不能，卡在哪里？” 如果卡在某个点，就针对该点修复，然后重新自检。

阶段 6.5：让 AI 自己当评委

自检是“自己查自己”，容易有盲区。所以增加一步“独立评审”：让 AI 换身份，假装没参与过开发，只根据 requirements.md 和当前代码打分。

评审维度包括：

  • 功能完成度：必做项是否全覆盖？
  • 代码质量：结构是否清晰？有没有重复代码？
  • 测试充分度：每个功能是否有验证证据？

目标是综合评分 ≥90 分。如果分数不够，优先修复“阻断级”问题。时间不够时，把剩余问题写入 KNOWN_LIMITS.md，而不是硬凑。

阶段 7：写能让别人跑起来的文档

最后 10 分钟专门写交付文档。重点不是文采，而是可复现性。README.md 必须包含：

  • 精确的环境依赖：比如 “Python 3.9+，FFmpeg 4.4+”
  • 一行安装命令：pip install -r requirements.txt
  • 运行示例：python main.py input.mp4 avi
  • 验证方法：预期输出文件大小范围、MD5 校验值等

写完后，自己按文档操作一遍，确保真能跑通。很多笔试挂掉，就是因为文档写的和实际代码对不上。

卡住时怎么办？先诊断再急救

如果过程中出现混乱，先用“五类失稳诊断”定位问题：

  • 认知失稳：忘了最初要交付什么 → 回到阶段 1
  • 路径失稳：反复修同一个 bug → 用急救 1，先复现再修复
  • 上下文失稳：AI 开始胡说八道 → 用急救 2，输出交接文档后清空上下文
  • 协作失稳：模块之间接口对不上 → 回到阶段 3，重新对齐骨架
  • 验收失稳：不知道能不能交 → 回到阶段 6，用证据说话

这套方法的本质是把 AI 当成一个需要明确指令的实习生：你给它清晰的阶段性目标、验收标准和回滚机制，它才能稳定输出。否则，它很容易在开放式对话中迷失方向。

时间不够怎么办？

如果笔试只有 1 小时，可以用“一次性全流程交付”提示词作为备选。但它风险较高——一旦中间出错，很难定位。所以建议：

  • 前 10 分钟仍做问题定义和骨架设计
  • 中间 40 分钟专注 MVP + 异常处理
  • 最后 10 分钟只写 README.md 和关键测试命令

宁可少做功能，也要保证主链路可验证。毕竟笔试的核心是证明你能交付一个完整、可运行、有证据支撑的解决方案，而不是堆砌代码量。