我在开发的时候经常遇到一个问题：有时突然冒出一个新需求，优先级一插队，之前记着“以后再修”的技术债就慢慢忘掉了。或者休假回来，一时想不起开发到哪了。
于是我想，有没有什么办法能让 agent 知道当前的开发状态——就做了这样一个 skill:通过维护一个 state 文档，记录当前的开发位置。
指令核心就两句：
STATE.md 是单文件状态页，分六节：
| 节 | 放什么 |
|---|---|
| GOAL | 大方向，一句话(可选——没定过就不写) |
| NOW | 现在在干嘛，卡在哪 |
| NEXT | 接下来做什么，每条带验收标准 |
| DEBT | 欠的债，每条带“为什么不修 + 什么情况该修” |
| LOG | 走过了什么，每行带一句为什么 |
| MAP | 相关的文件路径 |
GOAL 是大方向，NOW 是当前焦点——一个是去哪，一个是走到了哪。只记用户原话，agent 不自己发明目标。
DEBT 是技术债的挂账处。每条债写清“为什么不修”和“什么情况该修”之后，它就不再只活在“当时都知道”里了；每次收工同步会顺手反查一遍：这次干的事，碰没碰到哪条债的到期条件。比如有一条“权限模型未做，区县分级可见时该修”的债，等真要做区县分级那天，它是被翻出来的，不是被想起来的。
LOG 每行带一句为什么。做了什么，git log 里都有；六个月后还值钱的，是当时为什么这么选。
MAP 放相关文档的路径。细节都外放在别的文档里，用的时候按路径取，状态文件本身保持小。
条目的生命周期很简单：债 → 决定修 → 进 NEXT → 修完 → LOG 记一行 → 删除。完成即删，不留“✅ 已完成”的标记占地方。历史不会丢：每次收工，STATE 的变更和代码改动进同一个 commit ，所以删掉的条目在 git 历史里都翻得到——要看某条债是哪天修的、当时写了什么，翻旧版本的文件就行。
markdown 状态文件和 todo 列表这种东西一样会烂，所以每节有行数上限，另外配了一道物理的门：一个小脚本挂在 Claude Code 的 Stop hook 上，每次收工数一遍各节行数，超了就 exit 2 ，把超限信息喂回 agent——agent 得自己压完、给出各节行数，才算收工。
运转了一段时间，个人感觉能降低我的日常维护成本。我再加上一点点管控，可以让 agent 自己读 state 文档、自己挑当前最该做的任务、自己实现、再更新 state ，然后继续挑下一个——浅浅地跑起了一个 loop 。
从我的问题上来说，这个 skill 满足了我的需求，还能浅浅跑一下 loop 。我想知道的是：这个方案好吗🤔
Select Language