本资料由清华大学沈阳教授团队博士后张诗瑶、武汉理工大学吴越基于实践经验并结合 AI 辅助撰写，致力于让文科生、非专业开发人员也能顺利开展氛围编程。欢迎交流探讨。
氛围编程不是随意地让 AI 写代码。规范化的工作流意味着：在每个阶段用最适合的工具，给 AI 最准确的上下文，以最小的沟通成本获得可用的输出。
工作流总览
需求描述 1 | →
|
架构设计 2 | →
|
代码生成 3 | →
|
调试优化 4 | →
|
持续迭代 5 |
这不是一条走完就结束的直线，而是一个持续运转的循环。第一次走完四个阶段，项目跑起来了；之后每次新增功能、做优化、调整逻辑，都从阶段 5 判断切入点，再走一遍对应的流程。核心原则是：
•AI 是执行者，你是决策者——每个阶段结束后必须有人工确认
•上下文与需求描述——给 AI 的信息越准确，输出质量越高
•阶段产物要留存——需求文档、架构图、调试日志都是资产，下次迭代时直接复用
•工具专项专用——对话型 AI 做设计，代码型 AI 做实现
| 阶段1 需求描述 从一句模糊想法，走到 AI 可执行的结构化指令 |
1.1 为什么需求描述是瓶颈
大多数氛围编程失败不是因为 AI 能力不足，而是需求本身不清晰。但"不清晰"有两种截然不同的情况：一种是你知道要做什么，只是没有表达清楚；另一种是你连要做什么都还没想清楚。这两种情况需要完全不同的处理方式。
错误的做法是在需求还模糊时就急着填模板——填出来的东西是假结构化，技术选型也是拍脑袋的。正确的做法是先用对话把需求想清楚，再用模板固化结论。
1.2 三步走：从模糊到可执行
阶段1 分三个步骤，每步有明确的进入条件和完成标志，不要合并跳过。
| Step 1 模糊需求澄清 |
目标：把一句话想法变成可以讨论技术方案的材料。此步不谈技术栈。 做法：把你的想法告诉 AI，让它主动追问。AI 应该问的方向： • 这个东西给谁用？解决什么具体痛点？ • 有没有你参考的类似产品或工具？ • 最不能接受的是什么——速度慢、数据不准、操作复杂？ • 你预期每天/每次用它做什么，大概的操作流程是什么？ 完成标志：能用 2-3 句话清晰描述「谁在什么场景下用它解决什么问题」，且 AI 没有新的追问。 |
示例对话（Step 1）
你 我想做一个自动监控技术博主更新的工具 |
AI 有意思！几个问题帮我理解一下：你说的"技术博主"主要在哪里发内容？GitHub、个人博客、还是 B 站、YouTube？ 你希望监控之后做什么——是自己看，还是要整理成报告、或者自动发出去？ 你现在是怎么跟踪这些人的更新的，哪里最让你头疼？ |
你 主要是 GitHub 上的项目更新，有时候也有 B 站视频。我现在是手动一个个点进去看，太麻烦了。我想每天早上看一个汇总，知道昨天谁更新了什么就行，不需要自动发布。 |
AI 清楚了。所以核心需求是：每日自动聚合你关注的博主在 GitHub 和 B 站的更新，以某种形式呈现给你，替代你现在的手动巡查。 最后一个问题：你关注的博主大概有多少人？是固定名单还是希望能动态新增？ |
| Step 2 技术选型 |
目标：在需求清晰的基础上，根据你的实际约束选出技术方案。 进入条件：Step 1 已完成，能清晰描述问题。 做法：把以下约束条件告诉 AI，让它给出 2-3 个方案并说明取舍： • 你熟悉哪些编程语言 / 框架 • 运行环境是什么（本机 / 服务器 / 云） • 是否需要其他人也能用（单人 vs 多人） • 对维护成本的容忍度（"能跑就行"还是"要长期维护"） AI 给出方案后，你来选。选完即冻结——技术栈一旦确定，后续步骤不再重新讨论。 完成标志：技术栈已选定，语言、运行方式、核心依赖已明确。 |
示例对话（Step 2）
你 我主要写 Python，工具跑在自己电脑上就行，只有我一个人用，不想搞太复杂的部署。 |
AI 那技术方向很清晰，我给你三个选项：方案 A：纯 Python 脚本 + 本地 JSON 文件存储。最简单，无依赖，适合"能跑就行"的场景。缺点是数据多了不好查。 方案 B：Python + SQLite。多一点复杂度，但数据结构化，去重和查询方便很多，长期维护更轻松。 方案 C：Python + 本地 Web 服务。可以做成网页展示，但要维护一个服务进程，稍微重一点。 根据你的需求（每日汇总、单人使用），我推荐方案 B。 |
你 选 B，Python + SQLite。 |
| Step 3 结构化确认 |
目标：把对话结论固化为标准需求文档，作为阶段2 的输入。 进入条件：Step 2 已完成，技术栈已选定。 做法：让 AI 根据前两步的对话内容自动填写以下模板，你来审查和修改。不要一开始就手动填这个模板。 |
# 需求描述模板（Step 3 填写，不要跳过 Step 1/2 直接来这里）
[系统背景] 这是一个______项目，目前已有______功能，技术栈是______。 [本次目标] 需要新增/修改______功能，核心目的是______。 [用户与使用场景] 使用者是______，典型使用场景是______。 [输入 / 输出] 输入：______ （数据来源、格式、频率） 输出：______ （展示形式、存储位置、格式要求） [边界与约束] - 不需要实现：______ - 技术限制：______ （语言、库、运行环境——来自 Step 2 的结论） - 性能要求：______ [异常处理] 当______时，应该______ [验收标准] 完成的标志是：能够______，且______ |
1.3 工具选择
| 工具 | 职责 | 使用要点 |
| Claude / ChatGPT | Step 1：需求澄清 | 主动追问，不要急着给方案；帮用户把想法说清楚 |
| Claude / ChatGPT | Step 2：技术选型 | 基于用户约束给出 2-3 个方案，说明取舍，不替用户做决定 |
| Claude / ChatGPT | Step 3：文档生成 | 根据对话历史自动填写模板，用户审查确认 |
| Notion / 飞书文档 | 需求存档 | 把最终需求文档保存，后续阶段直接引用 |
1.4 阶段输出物
需求描述完成检查 ☐ Step 1 完成：能用 2-3 句话描述"谁 / 场景 / 解决什么问题" ☐ Step 2 完成：技术栈已选定，语言、运行方式、核心依赖已明确 ☐ Step 3 完成：模板已由 AI 填写并经人工确认 ☐ 输入输出格式已明确（包括边界值） ☐ 明确写出"不做什么" ☐ 异常场景至少列出 3 种 ☐ 验收标准可被测试（非主观描述） ☐ 文档已保存，路径已记录 |
| 阶段2 架构设计 在写第一行代码前，确定系统结构和模块边界 |
2.1 为什么要先设计架构
直接让 AI 生成代码，它会做出能跑的东西，但不一定是你想要的结构。一旦代码量上去，重构的成本远高于事先设计的成本。架构阶段的目标不是画出完美的图，而是在动手前对齐：模块怎么分、数据怎么流、接口怎么定义。
2.2 工具选择
| 工具 | 职责 | 使用要点 |
| Claude | 架构方案讨论 | 把需求文档喂给 AI，让它给出 2-3 种方案并说明取舍，你来选 |
| Cursor | 项目结构生成 | 让 AI 在 IDE 中直接创建文件夹和空文件，确立目录骨架 |
| Mermaid/draw.io | 数据流图 | 让 AI 生成 Mermaid 代码，粘贴到 draw.io 或 VSCode 插件渲染 |
| Markdown 文档 | 接口约定存档 | 把模块接口、数据结构、字段说明写成 md 文件，放进项目仓库 |
2.3 架构设计的标准步骤
1.将阶段1 的需求文档完整粘贴给 AI，要求它给出项目结构和分层方案
2.让 AI 解释每一层的职责，确认没有职责混用的情况
3.让 AI 输出 Mermaid 数据流图，人工检查数据流向是否合理
4.让 AI 定义各模块的接口（函数签名/类定义），不写实现
5.人工审查并冻结架构——此后阶段3不得随意修改模块边界
2.4 架构提示词范式
架构设计 Prompt 以下是需求文档： [粘贴阶段1 的需求文档全文] 请基于这份需求，完成以下工作： 1. 给出推荐的项目目录结构（到文件级别） 2. 说明每个目录/文件的职责，不超过一句话 3. 用 Mermaid flowchart 画出数据流向 4. 列出模块间的接口约定（函数名、参数、返回类型） 5. 指出你认为设计中最脆弱的一个地方 约束： - 技术栈：Python 3.11 + SQLite（来自需求文档） - 禁止直接写任何实现代码 - 如有多种方案，列出最多 2 种并说明取舍 |
2.5 阶段输出物
架构设计完成检查 ☐ 项目目录结构已确定，文件级别 ☐ 每个模块职责单一，无跨层调用 ☐ 数据流图已生成并人工确认 ☐ 模块接口已定义（不含实现） ☐ config / 环境变量 / 存储路径已规划 ☐ 架构文档已提交到代码仓库 |
| 阶段3 代码生成 用 AI 逐模块填充实现，保持上下文精准 |
3.1 代码生成的核心陷阱
最常见的错误是把整个项目一次性丢给 AI 让它生成。上下文窗口有限，AI 会开始"脑补"，产生与架构不符的代码。正确做法是：每次只生成一个模块，给足该模块需要的上下文，验收后再进行下一个。
3.2 工具选择
| 工具 | 职责 | 使用要点 |
| Cursor | 主力编码工具 | 在 IDE 内直接生成、插入代码，支持引用具体文件作为上下文 |
| Claude | 复杂逻辑设计 | 对于算法复杂的部分，先在 Claude 中讨论方案再去 Cursor 实现 |
| GitHub Copilot | 行级补全 | 适合在已有代码基础上做小修改，而非从零生成 |
| Claude Code | 终端代码助手 | 适合多文件联动修改，命令行场景 |
3.3 逐模块生成规范
每个模块生成前，必须向 AI 提供以下上下文：
# 代码生成 Prompt 结构
[项目背景 - 一句话] 这是一个______项目，整体架构见附件。
[当前任务] 现在需要实现 [模块名]，文件路径是 [path/to/file.py]。
[该模块的职责] [从架构文档中复制该模块的职责描述]
[依赖的接口] 该模块会调用： - [other_module.function_name(params)] → 返回 [type]
[该模块对外暴露的接口] 需要提供： - [function_name(params)] → 返回 [type]
[数据结构] [粘贴相关的 model 定义或 JSON 结构]
[约束] - 不要修改其他模块 - 异常处理方式：______ - 日志格式：______ |
3.4 生成顺序原则
•先生成基础层（utils、models、storage），再生成业务层
•有依赖关系的模块，先生成被依赖的一方
•每个模块生成后立即做最小验收（import 不报错、关键函数可调用）
•验收通过后再让 AI 生成下一个模块
•中途如需修改已生成模块，重新触发该模块的验收流程
3.5 阶段输出物
代码生成完成检查 ☐ 所有模块按架构文档逐一生成 ☐ 每个模块独立 import 无报错 ☐ 关键函数有基础的单元测试或手动验证 ☐ 没有出现架构文档未定义的模块或跨层调用 ☐ config 参数均从配置文件读取，无硬编码 ☐ 代码已提交，commit message 写明实现的模块 |
| 阶段4 调试 出错不可怕，重要的是把问题说清楚，让 AI 帮你一步步解决 |
4.1 出错是正常的
代码出错不代表你做错了什么，也不代表 AI 不管用。调试本身就是开发的一部分。非专业人士最容易踩的坑，不是看不懂错误，而是把错误信息截图、或者只把最后一行粘给 AI。
AI 需要看到完整的错误内容才能帮你找到真正的原因。给的信息越完整，得到的解释和步骤越准确。
4.2 基本调试循环：四步走
遇到问题时，按这四步和 AI 配合，不要跳步骤：
| Step 1 把错误完整地告诉 AI |
把以下内容一次性粘给 AI，不要只粘最后一行： • 完整的红色报错信息（从头到尾，不要截断） • 你做了什么操作触发了这个错误 • 你期望发生什么，实际发生了什么 • 如果已经试过某些方法，一并告诉 AI ⚠️ 截图只能让 AI 看到文字图片，却无法精确定位错误内容。粘贴文本，不要截图。 |
| Step 2 让 AI 解释原因 |
收到错误后，让 AI 用你能理解的语言解释： • 这个错误是什么意思（用大白话） • 最可能是哪里出了问题 • 有几种可能的原因，最可能的是哪个 不要跳过这一步直接要解决方案。理解原因能帮你判断 AI 给的步骤是否合理，也能避免改了这里又坏了那里。 |
| Step 3 按步骤操作，反馈结果 |
AI 给出解决步骤后，逐步执行，每步完成后把结果告诉 AI： • 步骤成功了→ 告诉 AI，继续下一步 • 出现新的报错→ 把新报错完整粘给 AI • 问题解决了→ 告诉 AI 是哪一步起效的 不要一次性把所有步骤都做完再来反馈。一步一步来，出问题能立刻定位到是哪一步的问题。 |
| Step 4 问题解决后，记录一句话 |
每次解决完一个问题，在对话结尾让 AI 写一句总结： 「问题：______；原因：______；解决方法：______」 把这句话保存下来。下次遇到类似问题，直接把这条记录给 AI 看，能大幅缩短排查时间。 |
4.3 当 AI 反复解决不了同一个问题
这是氛围编程里最常见的困境。你把错误告诉 AI，它给方案，你试了没用，再问，它又给一个，还是没用……来回好几轮，问题还在。
为什么会这样？——AI 的上下文陷阱 AI 不是真的在「思考」你的问题，它在根据对话历史预测最可能有用的回答。当同一个问题被反复讨论，它会越来越倾向于在自己之前的方向上打转，而不是推倒重来。 更重要的是：AI 不会主动说「我没思路了」。它会持续输出看起来合理的建议，即使内部已经没有新的分析角度。 |
三轮没解决，换对话
同一个问题讨论超过 3 轮还没解决，立刻开一个全新对话，从头描述问题：
# 重开对话时的描述方式
我遇到一个问题，之前试了几种方法都没解决，需要从头分析。
[完整报错信息粘贴在这里]
我已经试过的方法（都没用）： 1. ______ 2. ______
请不要重复这些方向，从完全不同的角度分析可能的原因。 |
4.4 阶段输出物
调试完成检查 ☐ 报错信息已完整粘贴给 AI（不是截图，不是只粘最后一行） ☐ AI 的解释我基本看懂了，知道是哪里出了问题 ☐ 按步骤操作并逐步反馈，没有一次性跳过多步 ☐ 问题解决后记录了一句话总结 ☐ 如果反复没解决，开了新对话而不是继续追问 |
| 阶段5 持续迭代 项目上线不是终点，每次改动都是一次新的小循环 |
5.1 为什么需要 Phase 5
很多人第一次做完项目之后，发现要改点东西，就直接让 AI 改代码——跳过了需求澄清、没有考虑对现有架构的影响、改完出了新 bug 又不知道从哪排查。阶段5 的作用是：在每次改动前，先判断这次改动的性质，再选对应的切入点，避免乱改一气。
5.2 三种迭代场景，三个切入点
根据你想做的事情，从不同的阶段重新进入流程：
| Step A 新增功能 → 从 Phase 1 开始 |
适用：要加一个之前没有的功能，比如新增一个数据来源、加推文生成、加网页展示板块。 做法：把新功能当作一个独立的小项目，走完整的 阶段1→2→3→4。唯一的区别是：阶段 1 的系统背景部分，要把现有项目的情况说清楚，让 AI 知道是在已有基础上扩展而不是重新做。 给 AI 的上下文模板： 「现有项目是______，技术栈是______，目前已有______功能。现在想新增______，不影响现有功能。」 |
| Step B 性能问题 / 体验优化 → 从 Phase 4 开始 |
适用：功能本身没问题，但感觉太慢、用起来别扭、输出格式不好看，想改善体验。 做法：直接进入 阶段4 的调试循环。告诉 AI 现在的问题是什么感受（「每次运行要等很久」「输出的格式看着乱」），把相关代码粘上，让 AI 定位原因并给改进方案。 不需要重新走需求和架构，直接描述问题让 AI 改。改完感受一下是否有改善，再决定是否继续。 |
| Step C 代码结构混乱 / 难以维护 → 从 Phase 2 开始 |
适用：代码跑起来没问题，但越改越乱，加新功能时总是顾此失彼，感觉像一锅粥。 做法：回到 阶段2，重新梳理架构。把现有代码的问题告诉 AI（「现在所有逻辑都在一个文件里」「数据处理和展示混在一起」），让 AI 给出重构方案——先只改结构，不加新功能。方案确认后再走阶段 3 重新生成对应部分。 重构和加功能不要同时做。先重构让代码变整洁，再在整洁的基础上加功能。 |
5.3 迭代时最重要的一件事：带上历史文档
之前每个阶段存下来的需求文档、架构文档、问题记录，在迭代时都能直接复用。每次开新对话时，把相关的历史文档贴进去，AI 能立刻了解项目背景，不用重新解释一遍。
这就是「阶段产物要留存」这条原则的真正价值——不是为了归档，而是为了下次迭代时省去大量铺垫时间。
5.4 阶段输出物
迭代完成检查 ☐ 确认了这次改动的类型（新功能 / 优化 / 重构），选对了切入对应的阶段 ☐ 新功能：阶段 1 的系统背景中说明了现有项目情况 ☐ 性能优化：描述了具体的感受问题，不是泛泛说「想优化」 ☐ 重构：明确了哪里乱、想改成什么结构，未与新功能混在一起 ☐ 迭代完成后更新了需求文档或架构文档（如有变动） ☐ 改动已提交，描述中写明这次改动的目的 |
工作流速查
| 阶段 | 核心工具 | 输入 | 输出 |
Phase 1 需求描述 | Claude Notion | 一句话模糊想法 | 结构化需求文档 技术栈决策 验收标准 |
Phase 2 架构设计 | Claude Cursor Mermaid | 需求文档 技术栈 | 目录结构 数据流图 接口约定 |
Phase 3 代码生成 | Cursor Claude Code | 架构文档 接口约定 | 各模块实现代码 基础测试 |
Phase 4 调试 | Claude | 完整报错信息 操作描述 | 原因解释 逐步解决方案 问题记录 |
Phase 5 持续迭代 | Claude | 改动类型判断 | 切入 Phase 选择 历史文档复用 更新文档 |
关键原则
•每个阶段有明确的输出物，不输出不进入下一阶段
•阶段1 必须走完三步：澄清 → 选型 → 结构化，不要跳步骤
•AI 生成的每份内容都必须经过人工确认，不自动流转
•上下文比 prompt 技巧更重要——给 AI 准确的材料
•调试时给完整信息，不截图，不只粘最后一行
•同一问题超过 3 轮没解决，立刻开新对话重头说
规范化不是束缚，是让 AI 协作持续可靠的保障
<原文链接：https://mp.weixin.qq.com/s/Z4supEjCIQc85NsaYrKDLA
暂无评论内容