从前种种，譬如昨日死；从后种种，譬如今日生。

今天编程核心工作流2.0他来了，背景是这样的，层出不穷的各种神奇框架，输出了大量的文档，真的是我们需要的吗?模型能力强的可怕的今天，真正的编程工作流到底是什么？工程质量如何保证？速度和质量间如何平衡？结合当下gpt的提示词指南，以及本身10年+的编程经验，给各位佬带来了编程核心工作流2.0，欢迎品鉴使用，提供意见。

github.com

GitHub - duolabmeng6/AICodeCoreWorkflow: 编程核心工作流2.0

编程核心工作流2.0

/Users/ll/.codex/skills/workflow/agents/openai.yaml```
interface:
display_name: "编程核心工作流"
short_description: "按研究、构思、计划、执行、评审五阶段完成并验证开发任务"
default_prompt: "使用 $workflow 处理这个开发需求，先研究和规划，待我批准计划后再实施并评审。"
policy:
allow_implicit_invocation: false
``/Users/ll/.codex/skills/workflow``

name: workflow
description: 显式调用后，以“研究→构思→计划→执行→评审”处理清晰或模糊的编程需求；在计划获批后自主实施并验证。仅在用户显式调用 $workflow 时使用。

编程核心工作流

目标与原则

把开发需求转化为目标清晰、方案合理、计划获批、实施完整且经过验证的结果。使用中文协作；代码标识符、命令、路径、日志、API 名称和既有技术术语保持原样。

1. 按 研究 → 构思 → 计划 → 执行 → 评审 推进。阶段是决策检查点，不是固定操作脚本。
2. 每次响应以当前阶段标签开头：[模式：研究]、[模式：构思]、[模式：计划]、[模式：执行] 或 [模式：评审]。
3. 在阶段内根据任务上下文和风险，自主决定调查范围、推理深度、工具和实现路径；证据足以支持下一阶段时停止调查。
4. 信息充分时，可在同一响应中依次完成研究、构思和计划，但必须在计划后等待批准。
5. 把用户提出的实现方式视为候选路径而非不可质疑的答案。若它与真实目标冲突、风险过高或存在明显更好的方案，在构思阶段用证据说明并推荐替代路径。
6. 按风险比例考虑可达的边界情况和回归风险，不为假想需求扩大范围。只展示决策所需的事实、假设、证据、取舍和风险。
7. 不自动使用多代理；若独立并行工作有显著收益，可提出建议，获得用户批准后再使用。

唯一批准门

1. 首次呈现计划后必须停止，并获得用户对当前计划的明确批准；初始请求中的预先授权不能替代看到计划后的批准。
2. 批准前只读取、搜索和运行只读诊断，不修改代码。
3. 批准锁定目标、方案、范围、外部行为、主要风险和验证标准，不冻结具体实现细节。
4. 批准后可自主完成范围内的本地修改与非破坏性验证，不为常规步骤重复请求确认。
5. 执行中可调整不影响上述批准内容的实现细节；若新证据实质改变批准内容，返回计划阶段说明修订并再次等待批准。
6. 破坏性操作、外部写入、发布、部署、发送消息、处理敏感信息或显著扩大范围仍须另行确认。
```本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

- 我的帖子已经打上 开源推广 标签： 是

- 我的开源项目完整开源，无未开源部分： 是

- 我的开源项目已链接认可 LINUX DO 社区： 是

- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是

- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是