gpt-engineer 本地代码库迭代开发

要解决的问题

把一个 prompt 文件直接丢给大模型，得到的通常是一段能看但不能用的代码：文件结构缺失、依赖没落盘、生成结果和本地仓库完全脱节。工程师真正需要的是从自然语言规范出发，产出一个可运行的本地项目脚手架，然后在自己的代码库语境里反复修正，而不是反复重写整个提示词。

它如何工作

这个技能的核心是一条三阶段流水线，由 gpt-engineer 承担代码生成，由 Agent 承担监督与决策：

• 规范驱动生成：读取用户提供的 prompt 文件（例如 spec.md），把其中的需求拆解为文件级结构与实现计划，生成初始项目骨架与代码文件。
• 人工/Agent 检查：生成结果不会自动被采纳。Agent 需要审查代码结构、关键实现是否符合规范，并指出需要修正的点。
• 受控迭代循环：基于检查结果对本地代码库做增量修改，而非全量重生成。每一轮都有明确的反馈输入，循环结束后才谈采纳。

这条链路的价值在于把「生成」和「验收」解耦。你可以在迭代过程中随时介入，而不是把调试成本转嫁到下一次提示词工程里。

适用边界与注意点

• Python 环境限制：上游项目活跃支持 Python 3.10–3.12；如果需要 Python 3.8/3.9，只能用最后一个兼容版本 0.2.6，新功能不会回填。
• 模型访问是硬依赖：需要 OpenAI 兼容接口或受支持的模型 API Key，生成质量直接受模型能力影响。
• 迭代深度有限：监督循环依赖你（或 Agent）提供有效的审查反馈；反馈越模糊，收敛越慢。它不适合当作全自动无人值守的代码生成器使用。
• 规范质量决定起点：prompt 文件里的需求如果含糊，生成的脚手架可能需要更多轮次才能对齐预期。