暑期实习一个多月终于沉淀出了自己的vibecoding工作流！

最近在使用自建的半自动化工作流进行vibecoding，写篇文章总结一下。

• 
  

  题主本身也是在摸索vibecoding阶段，抛砖引玉，欢迎佬友分享出自己的一些经验或者是对我当下工作流的建议。

  
  


• 
  

  这套工作流目前主要面向已有系统新增需求，接下来讲的主要是基于这个情景的。

  
  


• 
  

  工作流我是以一组skills的形式组织的，命名为Jflow。

  
  


• 
  

  目前在开发的一个Agent项目是从0到1的，正在尝试扩展成也支持从0到1的项目，目前已经能稳步向前开发了，就差总结沉淀一下流程了，下面有简单提了一句，后续打算扩展沉淀完再发一篇文章总结。

  
  

我面对一个新的需求是这样利用工作流开发的：

提示词：描述需求 + 补充信息 ，利用Jflow进行需求开发

codex：产出 一份prd。

新开一个会话让codex评审prd｜ 与此同时，我：评审prd，如果我觉得有问题，会直接让codex调整。

直到prd没问题了。告诉codex评审通过，它会去更新开发状态。

提示词：根据prd拆trd。

codex：产出 trd切片、trd_index文档（简要介绍每个trd聚焦什么）、progress文档（trd开发进度文档）。

新开一个会话让codex评审trd｜ 与此同时，我：评审trd，如果我觉得有问题，会直接让codex调整。

直到trd没问题了。告诉codex评审通过，它会去更新开发状态。

提示词：按照Jflow推进开发

codex：识别到当前需要开发的第一个trd切片，然后开始代码实现。

新开一个会话让codex评审代码 ｜于此同时，我：尽可能去读代码。

直到代码没问题了。告诉codex评审通过，它会更新开发状态，调整指针指向下一个要开发的trd。

提示词：继续按照Jflow推进开发。。。。。。。

基本上codex的每次产出我都会去自己评审，这对文档可读性要求很高。我在以下方面下功夫了。

• 
  

  skill中提供的prd、trd模版，我都是以“轻量”为目标设计的。

  
  


• 
  

  prd、trd都有一项是给人看的。设计prd、trd模版时，可以将文档拆成两部分，大部分是给codex看的，小部分是给人看的。prd中“需求范围”要求codex一个需求点翻译成一句人类友好的话。trd中“验证点”会描述当前这个trd切片代码实现完成能做到哪些功能点。

  
  


• 
  

  trd是一组“单一职责”切片形式存在。一次仅聚焦一个切片的审核。

  
  

工作流主要包含了Jflow-core、Jflow-start、Jflow-prd、Jflow-trd、Jflow-dev，下面简单介绍下。

Jflow-core：主要是声明如何维护执行状态的，以及一个用于切状态的脚本。

Jflow-start：用于启动整个Jflow，最开始用户带着需求来，Jflow-start会按照Jflow-core去初始化，并产出第一份prd。

Jflow-prd：用于评审prd。强调已有代码事实、强调轻量。我在这个skill里要求使用codegraph先探索已有代码情况，理清楚涉及需求的已有链路情况，在prd中必须写明“涉及的现有链路”。

Jflow-trd：用于写trd以及评审trd。强调已有代码事实、强调单一职责拆解。仍然是先用codegraph探索已有代码情况，写明“当前代码事实与上下游”。其次就是按照“单一职责”去把prd拆成一组trd切片。

Jflow-dev：具体到trd切片开发时的规则。包括到哪里去拿本次要开发的trd切片，这样我只需要说“按照flow继续开发”，codex自己就会去找到下一个要开发的trd切片。

补充： 关于trd、prd的skill，我都是注入了codegraph。出发点是：我认为，让codex写下“当前代码事实与上下游”，实际上与当初让ai写出“推理过程”以提升解决问题的准确率有异曲同工之妙。

关于从0到1的项目

我目前是先根据最初的idea产出一份产品级prd，然后根据这个prd去拆解模块，最终拆出的模块组织成DAG，并且会产出一份“DAG文档”。对于DAG中的每个节点，都按照flow工作流去组织开发。

一些个人观点

目前开源的大部分skill是专注解决某一领域特定问题，在我看来都有些“重”了。我对skill的看法以及用法很简单。

• 
  

  单纯把开发过程中可以固化的流程沉淀成skill，避免每次都要输入相同的提示词。例如：我把提交规范封装成一个/committing skill，那么每次我想提交推送时，就直接/committing 就行了。

  
  


• 
  

  skill一定要轻，不要寄希望于一个skill真的能解决多大的问题。

  
  


• 
  

  skill还是得自建，自己最清楚自己面临的痛点。

  
  


• 
  

  自建skill的时候我一直在给codex强调skill一定要轻，我认为现在的LLM都很强大，skill写的过重反而会让codex执行时“过度考虑”，实际上我觉得仅仅聚焦“我们真的有把握的东西”就是最好的harness。很多skill写的过于专业，反而导致产出的文档我们没有能力去评审。而我们自建的skill基本上就是聚焦我们能力范围内理解到的要把握住的东西，有些时候反而效果更好。

  
  

附：prd、trd模版