GPT-5.1 高效工作流：与 AI 协作的最佳实践
我遇到的问题
先说说为什么我会认真研究这个话题。去年年底，我负责一个遗留系统的重构项目——一个用了七年的 Python 后端，大概六万行代码，几乎没有文档。我一开始用 GPT-5.1 的方式很“原始”：遇到问题就复制一段代码过去，问“这有什么 bug？”或者“帮我优化一下”。
结果很典型：AI 给出的建议看起来都对，但放到真实项目里经常水土不服。它不知道我们的项目结构，不知道我们用的内部库，给出的方案往往要花更多时间返工。有一段时间我觉得“AI 编程就是个噱头”。
转折点是我意识到问题不在模型，而在我的用法。我把它当成一个搜索引擎，而不是一个同事。 你不会给新同事一句话就指望他写出符合规范的代码，你会给他上下文、给他流程、给他反馈。同样的道理适用于 GPT-5.1。
下面是我摸索出的工作流，经过三个月实际项目验证。
第一步：把上下文喂饱
这是最重要的一条，没有之一。GPT-5.1 的长上下文窗口是它的强项，浪费它就是浪费钱。
我现在的做法是，开始任何新任务前，先建一个“项目上下文”文档：
# 项目背景
- 技术栈：Python 3.11, FastAPI, SQLAlchemy 2.0, PostgreSQL
- 项目结构：src/core(业务逻辑), src/api(路由), src/models(ORM)
- 代码规范：ruff + black，类型注解必须完整
- 禁止事项：不要引入新依赖除非明确要求；不要用 print 调试
# 当前任务
重构 OrderService 中的支付逻辑，目标：拆分出 PaymentGateway 接口
把这段贴在对话开头，或者做成可复用的模板。效果立竿见影——AI 给出的代码第一次就能用上我们项目的导入路径和类型风格。
我犯过的错误：一开始我把整个文件贴过去，几千行。结果 AI 抓不住重点，回答泛泛。后来我学会了只贴相关的部分：要修改的函数 + 它调用的接口定义 + 相关的数据模型。上下文要精，不要堆。
第二步：先让 AI 做计划，再写代码
这是我踩坑最多的地方。以前我直接说“帮我写这个功能”，AI 会立刻吐出几百行代码。代码看着没问题，但架构思路可能和你想的不一样，改起来比重写还麻烦。
现在我的流程固定是两阶段：
阶段一：只要计划
先不要写代码。阅读我贴的 OrderService 代码，列出你建议的重构步骤，包括每一步会改动哪些文件、有什么风险。我会审核你的计划。
阶段二：逐步执行
计划的第 2 步可以，但第 3 步不要动 models/payment.py，那是共享模块。现在执行第 2 步。
这样改之后，我的返工率明显下降。尤其是大改动，两阶段流程几乎避免了所有“方向性错误”。GPT-5.1 在规划类任务上的表现比写代码更稳定，要利用这一点。
第三步：善用迭代式反馈
不要指望一次到位。我的经验是，第一版代码通常 70 分，你要做的是精准指出差距，而不是全盘接受或全盘拒绝。
差的反馈：“不对，重新写。”
好的反馈：“逻辑对，但有两个问题：1) _validate_amount 里没有处理负数；2) 你用了 try/except 吞掉异常，我们的规范是抛自定义的 PaymentError。只改这两处，其他保持不变。”
注意最后一句话——“只改这两处”。这句话很重要，不然 AI 会顺手“优化”一堆你没让它动的地方，diff 变得没法 review。
第四步：让它自己验证
一个我最近才养成习惯的技巧：让 GPT-5.1 在交付代码前自我检查。我在项目上下文里加了一条：
交付代码前，先检查：1) 是否符合上述规范；2) 列出你不确定的假设；3) 给出建议的测试用例。
第 2 点意外地有价值。AI 会主动说“我假设了 order.status 是字符串枚举，如果不是请告诉我”——这种假设正是 bug 的常见来源。让它显式列出假设，你花十秒确认，能省半小时调试。
第五步：处理长任务的会话管理
超过半小时的长对话会退化——AI 开始忘记开头的规范，回答变得平庸。我的做法：
- 每个任务开新对话，把上下文模板贴进去，别在一个对话里塞三个不相关的任务
- 任务完成时让它总结：“用 5 句话总结这次改动的要点和未完成事项”，把总结带到下一个对话里
- 需要引用之前的决策时，直接贴原文，不要说“如前面所说”
一个真实案例
上个月我用这套流程给那个遗留系统加了一个导出功能。全程不到两小时：
- 贴上下文模板 + 相关的三个文件
- 让 AI 出计划，我改了两处（它想新建一个 service，我要求放进现有的 export 模块）
- 分三步执行，每步我都跑一下现有测试
- 最后让它生成 pytest 用例，覆盖了边界情况（空数据集、超大文件分页）
换成以前的做法，这个任务我估计要折腾一天。
实用技巧汇总
- 建模板：把项目上下文做成代码片段，每次复用
- 要计划不要代码：大任务先审计划
- 精准反馈：指出具体问题和具体修改范围
- 让它列假设：交付前自我检查
- 控制会话长度：一个任务一个对话
- 用它的强项：解释遗留代码、写测试、生成样板代码，这些它做得最好；模糊的架构决策，它只能提供参考
诚实的局限
最后说说不好的方面。GPT-5.1 在处理我们项目里某个内部 DSL 时还是会一本正经地编造 API——语法看起来完全合理，跑起来直接报错。所以它写的所有代码都要测试，尤其是涉及你独有工具链的部分。另外，长上下文不是无限的，贴太多无关文件会让回答质量下降而不是上升。
AI 是放大器：你的工作流好，它放大你的效率；你的工作流乱，它放大你的混乱。先修流程，再谈工具。