为什么
为什么用它
AI 编码工具很快。但「把需求定下来」和「验证到底做完没有」这两件事，它没接手，还是你的。Ouroboros 把这两件事变成有步骤的流程。
1. 只用 AI 编码工具时会发生什么
「做个待办应用」这句话没说存哪、几个人用、勾完怎么处理。AI 会自己替你决定这些值——然后你在代码写完之后再返工。
| 问题 | 后果 |
|---|---|
| AI 自己补上你没做的决定 | 代码写完才发现方向不对，返工 |
| 只留下一句「做好了」 | 没办法核对到底做完没有 |
| 长对话把原始需求冲淡 | 结果和当初说好的不一样 |
| 会话断了，上下文就没了 | 找不到停在哪，只能从头再讲一遍 |
| 反复失败不留记录 | 修过的东西攒不下来 |
2. 加上 Ouroboros 之后变什么
| 变化 | 靠什么 |
|---|---|
| 决定在写代码之前定下来 | 访谈把没做的决定问出来（第 5 章） |
| 验收标准被写下来 | 存进 Seed（第 6 章） |
| 「做完了」要被验证 | 分层评估对着标准和测试查（第 8 章） |
| 中断的活能接着干 | 执行事件存在本地数据库里（第 11 章） |
| 失败喂给下一次 | 评估结果更新 Seed 再跑（第 9 章） |
第三行要按实情说：三层齐跑只在直接评估那条路径上成立，演化循环里只跑 Semantic 一层。细节在评估那一章。
3. 什么活适合用它
- 需求有好几条要理清楚的功能开发
- 「做完了」必须由测试证明的活
- 明摆着要改好几轮的活
- 时间长、中间可能被打断的活
4. 什么活不用它更快
这一节写在这里不是客套。用错地方，它只是让你多打几行命令。
- 改个错别字、调一行样式——直接让 AI 改，或者自己改。
- 你还在探索、根本不知道要什么的时候。访谈问的是「你还没决定的事」，不是「你还没想到的方向」；这种阶段先自己乱试更快。
- 没有可验证的完成标准的活。评估拿标准来比对，标准是「看着顺眼」的话，它比不了。
5. 它不解决什么
两条限制，先说在前面比让你自己撞上强：
- 模糊度分数衡量的是你把它的问题答得多完整，不是答案对不对。一个自信地答错的人一样能拿到好分数。
- 判分值不进契约块，但那不等于「agent 什么都看不到」。项目级的 lint/test 命令是故意给它的；契约块之外的脱敏是逐字的、只覆盖五种编码，换个形状的副本仍会漏。这个缺口挂着公开 issue。
这一页对着当前源码核过。第 2 节第三行和第 5 节的两条限制，英文版与韩文版目前没有这样写。有对不上的地方，欢迎到 GitHub Issues 说一声。