厌倦了 OpenSpec 的草台、Oh-My-OpenAgent 的过度设计、superpowers 的散装，我从 0 写了一套简单轻巧的 AI Harness。

安装

npx skills add https://github.com/liuzhengdongfortest/CodeStable

缘起

我在开发一套新的 Harness Agent，源码在这 https://github.com/liuzhengdongfortest/MA 一开始当然是 VibeCoding，我只写我的设计和需求，代码和问题都由 AI 来修改，这样一开始是非常 OK 的，也支撑我开发除了大部分的特性。直到有一天 Codex 反复解决不了一个我认为比较简单的问题，以及反复在同一个地方掉链子。我就知道项目需要一套工作流来维持它继续进行了。

我调研了 OpenSpec、SuperPowers、Oh-My-OpenAgent 这一类的工具。答案就是它们没有一个用着我觉得顺手的，原因很简单。OpenSpec 太简单了，没有 Compound 工程，而且生成的 Spec 很抽象，人类根本没法读。SuperPowers 没有流程来约束，我不知道该用哪个。Oh-My-OpenAgent 也太重。

设计目标

我们需要一套稳定轻松的工作流，不吹不黑，不胡乱吹捧，脚踏实地把效果提上来。钻研进取，把 AI 的能力用到位，让 AI 在工作中真正地提效而不是留下一堆烂摊子。CodeStable 的目标是解决严肃工程的软件实现和编码问题，不是造一个新名词、追求热点。

设计思路

CodeStable 在设计思路上是顺着软件编码的流程和实际会遇到的问题来设计的。下面列举一些各位码农经常遇见的问题：

编码中的隐知识

我们知道，在编码过程中，coding 的时间其实占比也就 20%。我们花费更多的时间去了解需求、磋商需求、设计架构.... 很多时候会发现一段代码中也有很多奇怪的逻辑，我们也不知道它有没有用或者是干嘛用的。如果换 AI 过来，可能就自信重构掉了，但是事后会发现其实这段是用来应对某个较为极端的场景或者需求的。

需求的迭代

需求的迭代会造成一个很严重的后果，软件的复杂度会膨胀直到撑破 AI 的上下文。也许你觉得 Codex 做一个小工具会非常好用，但是当你尝试把这个工具迭代成一个大工具时，你会发现 Codex 出现的错误越来越多，越来越不得心应手。当你尝试用各种各样的框架的时候，会发现它们一开始能解决问题，但是后来发现它们工作的时间越来越长。我认为这些框架的作者，也许驱动 AI 的能力很强，但是绝对不是严肃软件的开发者。 因为这些框架缺少对软件开发中需求和设计的基础组织能力，缺乏对代码实现地尊重，而这些东西对软件开发来说必不可少。

设计详述

仙子啊，那让我们回到地面上，脚踏实地得看一看，软件开发应该如何进行。

CodeStable 整体设计有6实体、3流程：

6 个实体： 需求、架构、路线图、特性、问题、知识。
3 个流程： 特性引入 、问题修改、代码重构。

下面逐个介绍：

---

5 个实体

1. 需求 requirements：即原始需求，当时的用户故事是什么？如何讨论的，如何权衡的，放这里。原始需求集合归档带来的顶级好处是提供了最终的逃生通道。你可以摒弃所有代码，重写设计并生成。 如果你的代码通过什么奇妙的手段已经烂成一坨屎了，那你还是可以跟它们说再见，让 AI 重写给你生成一份基本满足需求的代码。
2. 架构 architecture：为了实现上面的需求，系统的软件架构或者说编排层是怎样的。架构内的文档要尽可能得精简，统一。为的就是人可以阅读。OpenSpec 的规格写得太抽象了根本没法看，没法维护。
3. 特性 feature：如果把架构是简述，那么特性就是实际落地的工程执行过程，这个过程需要人与 AI 共同协作，对每一份 design 进行审核，对执行和验收负责。
4. 问题 issue：开发完成以后，即使是强如 gpt，肯定还是有不少 BUG。这一块就类似于问题单，有一个问题就报一个单子上去，AI 和人一同解决。
5. 知识 compound：其实 compound 的意思是复利，这里英文名叫 compound 其实是复用了如今很火的复利工程。但是说白了，这一块就是知识库，没什么特别的。
6. 路线图 Roadmap：有时候我们想说的就是“我想要一个权限校验系统”。但是我们对如何实现一无所知。直接放到一个 feature 中 AI 接不住，那就需要先拆成路线图，然后逐步解决，想法很简单。

好，这 5 个实体看起来很美好，但是人也可以写需求文档、架构文档、特性文档、issue 文档呀，为什么以前没有呢？因为这些文档需要的字数实在是太多了，任何一个人都不会想写的。但是今天，通过以下设计的 3 个流程，可以将 5 个实体串联在一起。

---

3 个流程

需求实现：面对一个需求，你是否需要先把他想清楚、然后综合架构将其设计出来、然后逐步去编写、最后验收测试。OK，现在 AI 可以完全替代这个流程，并且你只需要看着它，然后指出不太好的点，然后让它继续跑。这个流程我认为很顺其自然，各位程序员怎么顺手怎么来。

问题修改：也是遵循业界通用的流程，/cs-issue-report 用来跟 AI 说哪里有问题，/cs-issue-analyze 让 AI 分析问题原因，/cs-issue-fix 让 AI 去解决。

代码重构：很多 AI Agent 的大牛缺乏对软件演进的基本理解。软件架构的腐化并不是一蹴而就的。一开始你让 AI 编码也许非常非常快，质量很好。但是随着未知的需求不断叠加，软件架构不再适应需求，代码里就会出现各种权衡 ifelse，导致项目复杂度巨量上升，直到不可维护。使用 AI 辅助代码重构，终归到底还是人类进行重构，这对人的技能要求很高。这个技能可以做很多表面上的重构任务，但是实际上有效的重构动作其实还需要人去筛选。我还没想好这个技能怎么做，beta 中，有想法的大佬们还请不吝赐教，教一教我重构的技巧。

---

面向真实开发场景

从 6 个实体，3 个流程可以看到，CodeStable 面向的是真实的开发场景和开发困境，并且对此进行了建模，期望通过这样一个闭环的系统来处理开发中常见的问题。无论是需求的接受与编写，还是出现问题如何解决，都是我们非常常见的工作环节，但是现有的大部分框架大部分都是围绕着 AI 进行建模而不是围绕人。

CodeStable 的哲学

CodeStable 与 OMO 做的是完全相反的哲学。OMO 认为人只要干预就是失败的信号，CodeStable 认为程序员是软件编码中的在环对象，程序员可以对黑盒实现不了解，但对整体实现必须有所把控，必要时也可深入。软件架构必须要可演进，可观测，可控制。也许这一点在 AI 发展强大以后会变得不再重要，但是这样做能让各位程序员在现状下舒服，我认为这就是价值所在。

---

Roadmap

这里是 CodeStable 的路线演进图，CodeStable 会根据模型能力的发展进行调整。假如未来模型的能力足够强了，或者某个模型做到某个模块的稳定产出，那么这个模块就可以删除。而在使用 AI 进行严肃软件工程时出现各种场景和各种问题，就是 CodeStable 需要解决的目标。

• [ ] 代码重构流程需要强化
• [ ]