Insights·2026-06-13

决定 AI 编程生产力的是模型还是工作流?

AI 辅助编程的成果质量,更多由工作流而非模型选择决定。真正的瓶颈很少是模型不够强,而是规格模糊和工作未收尾。oh-my-claudecode(OMC)是在 Claude Code 之上把三个习惯固化为工具的编排层:deep-interview 厘清要做什么,ralplan 验证怎么做,ralph 保证真正做完。关键在于把"做什么、怎么做、做到底"变成被强制执行的流水线。

AI 编程的真正瓶颈在哪里?

"让 AI 做,却做出了错的东西"通常不是模型质量问题。因为一开始就没说清要做什么,模型只能用自己的猜测填补空白。规格上的模糊,会原封不动地变成成果的偏差。

因此,设计一套减少模糊、强制收尾的工作流,比换一个更好的模型在实务中带来更大差别。oh-my-claudecode(OMC)就是在 Claude Code 上叠加多个专业智能体、把这套工作流固化为工具的编排层。

deep-interview 如何剔除模糊?

deep-interview 不会直接冲向代码。它以苏格拉底式方式一次只问一个问题,每一轮都挑最薄弱的环节追问,逼出隐藏的假设。

关键在于它按加权维度给模糊度打分。在该分数降到设定阈值以下之前,它根本拒绝执行。它把"我要的不是这个"的事后修改成本,提前挪到提问阶段并在此拦截。

ralplan 如何验证计划?

一旦要做什么变得清晰,就进入 ralplan。规划者起草方案,架构师反驳其设计,评审者再以质量标准重新审视。

这个共识循环会一直重复,直到评审者给出通过判定。独自制定的计划必然有盲区,而视角不同的智能体会在执行开始前补上这些缺口。

ralph 如何保证完成?

最后是 ralph。它的原则不是"尽力而为",而是"直到做完"。它把工作拆成可验证的单元,在每个单元都通过、评审者签字之前绝不停下。

这种结构能阻止 AI 工作中常见的自欺:只做了一部分就宣布完成,或为了通过而删掉测试。一旦把验证设为完成的条件,"做好了"这句话就变得可信。

把三个阶段串起来会有什么不同?

用 deep-interview 厘清做什么,用 ralplan 确定怎么做,用 ralph 做到底。当三个阶段连成一条流水线,同样的请求带来的成果偏差会大幅减小。

企业的 AX 也是同一个道理。与其等待更聪明的模型,不如先建立一套流程——去除模糊、强制收尾——这才真正提升产出质量。工具替你强制执行好习惯。