为什么要有CodeStable-LITE

业内有一个说法是大模型的进步会消减掉很多 Harness 工程，这一点我是认同的，但这不是构建LITE的主要原因，也不是LITE的真正意思，LITE存在的原因有如下两点：

疲惫。让我们站在用户的视角来看 AI Agent，我们付了大笔的金钱（700元/月），因此我们希望获得甲方一样的体验。即委托一件事给AI，它在限定时间内帮我干好，没有大的纰漏，不需要我过多关注。然后事实情况是，每一件事都需要我来推动，AI 产生的东西需要我来审计，AI 经常记不住我的需求是什么，AI经常犯错导致我需要纠正，最重要的是，我需要一直坐在电脑旁导致整宿整宿地熬夜。这不是客户应该有的体验。
认知负荷。这条说的就是 CodeStable 本身了，我希望它不要有太多的技能，不要有太多的行数，不要有太多的依赖，导致用户理解困难。因为总是有这样一种趋势，这玩意太复杂了以至于我不想去了解，也就不想用了。技能必须把深层次的东西覆盖进去，让用户有客户一般的体验。

目标

LITE 的目标是减少用户的思维负担，让驱动 AI 去做一件事真正变成一件轻松😉的事情，而不是需要用户不断纠错纠错，直到深夜。希望每个人都能有更多时间去学习、去娱乐、去运动以及去陪陪家人。但这是目标，任重而道远呀。

LITE 的演化方式

所谓演化，就是先把一个事干成干好，干得不需要人干预，然后把它下沉到基座，再在此基础上构建更多的东西。因此 LITE 并不会在一开始就让用户有甩手掌柜的体验，而是从底层做起，先实验软件开发的流程，再一步步进行压缩，把不需要的步骤删掉，把已有的多个技能做整合，也就是技能的下沉，最后逐步降低用户的认知符合。

LITE 目前的体系

LITE 只向用户暴露一个 cs 技能。它不是把所有事情压成一条流水，而是先理解软件信息处于什么成熟度，再读取内部行动规则推进。

三个核心实体

Project Spec：项目当前稳定真相。说明项目是什么、为什么这样、有哪些能力、边界、统一语言和架构考量。
Epic Spec：有边界但仍在变化的大需求。隔离尚未毕业的未来，只用一个 spec.md 维护状态、方案、当前推进、issues、阻碍和关闭条件。
Issue：一项可实现、可验证、可关闭的改变。小变化可以独立存在，大变化从 epic spec 分批切出 issue。

三者解决的是不同成熟度的信息不能混写的问题。只有 issue 会让长期真相碎在任务里；所有变化都写 project spec 会污染当前真相；巨型 issue 又会把探索、规格和执行混成无法关闭的事项。

关闭是知识提升：独立 issue 回写 project spec，epic issue 先回写 epic spec，epic 经用户确认关闭后再把稳定结论毕业到 project spec。

辅助实体

talks：讨论收束稿，是正式进入 issue 或 epic 前的缓冲，不是规格真相。
notes：跨事项复用的知识、坑点和操作经验。
tools：已经跑通、稳定、重复且适合自动化的项目工具。

一个控制面

用户只调用 cs。接入、讨论规划、规格维护、探索、bug 诊断修复、issue 设计执行关闭、知识沉淀和未知流程学习都是同一技能内部的行动模式。代码设计、debug、文档组织和技能设计原则按场景加载，不要求用户记住额外名称。

Explore 回答的是 How it works：一次触发如何穿过系统并产生结果。普通改动只需在目标 issue 里渐进说明现状和影响；解释不清、跨越多个边界或理解值得复用时，才升级为独立探索 issue。它先建立现状因果模型，Design 再基于模型提出未来方案。

一个入口不代表一次自动跑完整个生命周期。设计不自动写代码，实现不自动关闭或提交，关闭 epic、初始化工作区和危险操作仍需要用户明确授权。

特别注意

LITE 中没有重构（refactor）。从设计看，单独的重构在任何情况下都不会被需要。LITE 遵守的原则是，模块随着演化而上浮与下沉，当需求演化到某个层次后，上浮下沉变得自然需要，那么在进行某项特性（feature）的设计时，必然需要对某些模块进行抽取下沉和包装，从而让结构变得优雅，这是一个实现feature时需要做的过程而非单独的过程。

LITE 中也没有审计（audit）。找错总是无穷无尽的，如果为了一个无用的极端的边界情况需要增加几百行代码，那么这个架构设计就是错误的。好的架构设计应当考虑到这点，通过合理设计用户故事来覆盖大部分常用情况。当软件没有按照预期运行时，通过投诉来补全对应的场景。

4.9 KiB Raw Permalink Blame History Unescape Escape