# LLM Coding Workflow Guide：双模型协作的软件开发操作指南

> 一份系统性的操作指南，教导如何使用ChatGPT作为规划伙伴、Codex作为编码代理，通过分离规划和执行上下文来实现高效的LLM辅助软件开发。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-24T00:44:42.000Z
- 最近活动: 2026-05-24T00:51:56.446Z
- 热度: 163.9
- 关键词: LLM辅助开发, ChatGPT, Codex, 软件开发工作流, AI编程, 上下文分离, 规划-执行分离, 受控自主性, 文档策略, GitHub
- 页面链接: https://www.zingnex.cn/forum/thread/llm-coding-workflow-guide
- Canonical: https://www.zingnex.cn/forum/thread/llm-coding-workflow-guide
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：Jaksa576
- 来源平台：github
- 原始标题：llm-coding-workflow-guide
- 原始链接：https://github.com/Jaksa576/llm-coding-workflow-guide
- 来源发布时间/更新时间：2026-05-24T00:44:42Z

## 原作者与来源\n\n- **原作者/维护者**: Jaksa576\n- **来源平台**: GitHub\n- **原始标题**: llm-coding-workflow-guide\n- **原始链接**: https://github.com/Jaksa576/llm-coding-workflow-guide\n- **发布时间**: 2026年5月24日\n\n---\n\n## 背景：LLM辅助开发的痛点与机遇\n\n随着大语言模型能力的提升，越来越多的开发者开始尝试用AI辅助软件开发。然而，实践中很快暴露出一个核心问题：单一模型难以同时胜任高层次的规划思考和具体的代码实现。规划需要广泛的上下文、产品思维和决策权衡，而实现需要精确的代码知识、本地仓库感知和工具操作能力。\n\n这份指南的核心洞察是：将规划和执行分离到两个不同的模型上下文中，可以获得比单模型方法更好的效果。ChatGPT承担规划伙伴的角色，负责产品思考、架构决策、文档编写和质量保证；Codex作为编码代理，专注于仓库感知的实现、验证和提交。\n\n---\n\n## 核心设计：受控自主性\n\n指南提出的工作流核心理念是"受控自主性"。LLM承担重复性的规划、编码、文档和QA支持工作，而用户保持对产品方向、判断和最终批准的控制权。这种设计既利用了AI的能力，又避免了完全自动化带来的风险。\n\n责任分离的设计如下：\n\n- **用户**拥有想法、路线图判断、QA判断和合并决策\n- **ChatGPT**将粗略意图转化为计划、文档、QA分类和编码代理交接\n- **Codex**针对本地仓库实现、验证工作、更新文档、提交并报告\n- **GitHub仓库和项目文档**作为持久的真相来源\n\n这种分离 strongest 适用于希望借助LLM构建真实软件的业余爱好者和独立开发者，同时保持对项目的控制。对于一次性小脚本、纯无代码应用生成，或需要专业工程审查的高风险生产系统，这个工作流的价值会打折扣。\n\n---\n\n## 为什么上下文分离很重要\n\n指南详细解释了为什么要将规划上下文和执行上下文分开，这基于两个关键原因。\n\n**Token和工作流效率**：探索性规划、产品决策和QA推理保留在ChatGPT中，只向Codex发送实现所需的任务特定上下文。这避免了在每次实现运行中都推送所有规划上下文，节省了token成本，降低了延迟。\n\n**上下文卫生**：将策略、路线图和决策与仓库执行分离，使Codex能够从简洁的文档、清晰的范围和当前的真相来源文件工作。这防止了编码代理被过时或无关的讨论所淹没。\n\n即使规划LLM和编码代理具有相似的成本和上下文行为，对于小任务可以简化一些规划步骤，但工作流中持久的部分仍然有价值：真相来源仓库文档、明确的验收标准、可审查的切片、文档变更、QA决策和最终实施报告。\n\n---\n\n## 14阶段工作流概览\n\n指南将软件开发过程分解为14个明确的阶段，从仓库创建到持续实施循环。\n\n**阶段0**：创建GitHub仓库和本地工作空间。使用`main`作为默认分支，克隆到Windows机器，记录项目元数据。强调不要将机密信息提交到文档中。\n\n**阶段1**：创建ChatGPT项目。在深度规划之前为软件项目创建ChatGPT项目，添加启动指令块，使用附带的精简工作流入门作为通用工作流参考。\n\n**阶段1A**：添加入门文件。将精简工作流入门文件添加到每个ChatGPT项目作为源文件，保持ChatGPT对工作流的感知，而不使每个项目指令块变成庞大的通用手册。\n\n**阶段1B**：配置GitHub真相来源访问。连接或确认对项目GitHub仓库的访问，记录默认目标分支，当当前状态重要时，ChatGPT应在询问用户粘贴文档之前检查目标分支的仓库文档。\n\n**阶段2**：在交接之前配置Codex。将Codex指向本地仓库路径，确认它能看见仓库，分支正确，Git状态干净或有意为空，工作树和本地环境设置已配置。\n\n**阶段2A**：可选的Codex工作树。当需要隔离的实现分支、并行切片或更安全的实验时使用，将可重复的设置和清理逻辑保留在仓库辅助脚本或Codex项目设置中，而不是在每个交接提示中重复。\n\n**阶段3-4**：定义项目并生成项目特定指令。在ChatGPT项目中粘贴项目定义模板，填写项目想法、约束和验收标准，然后生成项目特定的ChatGPT指令来替换启动指令块。\n\n**阶段5-8**：生成核心仓库文档，包括产品文档、架构文档、路线图、当前任务文档和营销/活动文档。\n\n**阶段9-14**：将文档复制到本地仓库、引导项目、审查引导和首次部署、启动主要实施循环，然后重复规划-交接-实现-文档更新-QA-合并的流程。\n\n---\n\n## 文档策略：真相来源的层级\n\n指南建立了一个清晰的文档层级系统，确保信息的单一来源和一致性。\n\n**HTML指南**是日常操作手册和提示控制台，供人类开发者参考。\n\n**精简工作流入门**是轻量级可重用的工作流上下文，供ChatGPT项目使用。\n\n**项目指令**包含应用特定规则、真相来源路由和输出风格。\n\n**仓库文档**是实际的产品、架构、路线图和当前状态真相。\n\n这种分层设计使得不同角色（人类开发者、规划LLM、编码代理）都能获得适合其需求的信息，同时保持整体一致性。\n\n---\n\n## 交接设计：从规划到执行的桥梁\n\n指南对从ChatGPT到Codex的交接设计给予了特别关注。一个好的交接应该包含：\n\n- 当前仓库状态的理解\n- 明确的任务范围和验收标准\n- 验证期望和测试策略\n- 文档变更要求\n- 清晰的停止条件\n\n交接应该是"精简"的，只包含Codex完成任务所需的最小上下文，而不是完整的规划历史。这再次体现了上下文分离的原则。\n\n随着项目成熟，重复的设置、验证和分支验证命令应该移动到仓库拥有的脚本或包命令中。交接应该引用这些辅助程序，而不是重新教LLM代理相同的命令序列。\n\n---\n\n## 实施循环：可持续的开发节奏\n\n指南的核心价值在于建立了一个可持续的实施循环：规划工作、生成交接、实现、文档更新、QA、合并或修补。这个循环是开发者花费大部分时间的地方，因此设计得尽可能高效。\n\n关键实践包括：\n\n- 关闭活动并为一个新阶段开始新的聊天，避免上下文无限膨胀\n- 保持文档与代码同步更新，将文档变更作为实施的一部分\n- 明确的QA决策点，不自动假设实现正确\n- 可审查的切片，使变更易于理解和回滚\n\n---\n\n## 技术环境与工具假设\n\n指南默认的技术环境是Windows + PowerShell，除非明确改变。这不是因为WSL不好，而是因为Windows原生工作流对许多开发者来说更熟悉，减少了一个变量。\n\n工具假设包括：\n\n- ChatGPT用于规划（产品思考、架构决策、文档编写、QA决策）\n- Codex用于实现（仓库感知编码、验证、文档更新、提交）\n- GitHub作为真相来源和协作平台\n- 本地仓库作为开发环境\n\n这些工具可以替换，但指南的假设是规划和执行分离的模型架构。\n\n---\n\n## 局限性与适用边界\n\n指南诚实地讨论了工作流的局限性。\n\n主要权衡是设置开销。工作流增加了结构，使后续实施更容易恢复、更安全自动化、更少依赖聊天记忆。对于真正的一次性项目，这种开销可能不值得。\n\n工作流 strongest 适用于业余爱好者和独立构建者，他们希望借助LLM构建真实软件同时保持控制。对于以下场景价值较低：\n\n- 一次性小脚本\n- 纯无代码应用生成\n- 需要专业工程审查的高风险生产系统\n\n---\n\n## 实际意义与可迁移性\n\n即使不使用ChatGPT和Codex，这份指南的设计思想也具有普遍价值。\n\n**上下文分离原则**适用于任何AI辅助开发场景。将高层次规划与低层次实现分离，可以减少认知负荷，提高输出质量。\n\n**文档即代码**的理念强调了将文档视为一等公民，与代码同步维护，而不是事后补充。\n\n**受控自主性**的框架提供了一个实用的中间地带，介于完全手动和完全自动之间，既利用AI能力又保持人类监督。\n\n**交接设计模式**可以作为任何多代理或人机协作系统的参考，明确了信息传递的最小必要内容。\n\n---\n\n## 总结\n\nLLM Coding Workflow Guide是一份经过深思熟虑的软件开发操作手册，不仅提供了具体的技术指导，更重要的是建立了一套关于如何与AI协作开发软件的思维框架。\n\n其核心贡献不在于某个具体的提示模板或工具配置，而在于提出了"规划-执行分离"和"受控自主性"这两个关键概念，为LLM辅助软件开发提供了一个可持续、可扩展的范式。\n\n对于正在探索如何将AI集成到开发工作流中的团队和个人，这份指南提供了一个经过验证的参考实现，值得仔细研究并根据自身需求调整。