编程核心工作流2.0，他来了

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

今天编程核心工作流2.0他来了，背景是这样的，层出不穷的各种神奇框架，输出了大量的文档，真的是我们需要的吗?模型能力强的可怕的今天，真正的编程工作流到底是什么？工程质量如何保证？速度和质量间如何平衡？结合当下gpt的提示词指南，以及本身10年+的编程经验，给各位佬带来了编程核心工作流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生成、润色内容部分已截图发出： 是


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