试过 spec-kit 和 openspec, 简单的任务没必要用(因为用它太慢了), 复杂的任务它会描述的更复杂, 而且还要审阅它生成的文档, 进一步增加上下文长度, 而且我感觉 claude code 的 plan mode 已经够用了

写了好多个 AI 玩具,简单说,就是把大的任务拆分成 1 个个小任务. 别一次性搞那么多的功能让 AI 写,基本上没啥问题..

写代码知道没有银弹，用 AI 写代码就忘记了？没有最优，只有相对更优。

试过一次，好像不太行

@billzhuang 是的，我们假设现在模型现在只能完成 0.5-1pd 的事情，那么我们就需要一个工程方法能够把 10pd 的事情拆解到 0.5-1pd

@iorilu 是的，所以一次性攒出来的 spec/plan 是一个伪命题，”讨论“是一个可行的方向，原文里也写了，只是太长我懒得粘过来了

@sillydaddy 上下文压缩一般都不是主 Agent 中的模型做的压缩，一般是专门做的压缩，这里的压缩的确是有一定技巧的。 ”很难期望 AI 在复杂业务上，能抽象出合理的上下文。“这句话也是我们遇到的痛点，这篇文章也是说了解决这个痛点的一种方式

@nightlight9 感官上是这样的，”复杂“这个词的背后可能就以为这需要的上下文时海量的，所以模型写不好，不一定是模型的智能程度不够

@maolon 恩恩，这是通过工程实践上得到的一些结论，不一定完全正确，期待大家的讨论。模型之间的确有一定差异性，但是工程实践中有一个现象是加入有一个总结性的文档让模型读到了，那么这里面涉及到的知识很大可能性模型就不会再去读源文件了，就会导致最后得到的结论浮于表面非常不理想，实际上强制它读取应读的文件后给出的结论是理想的。

@ArrayBuffer 类似 spec-kit 这种个人不认为它现在是一个理想的实现方式，因为它整个流程其实还是太固化了。这种死板的流程，它不应该 Agent 的一个最终形态。 关于 Plan 的话，我认为它跟 Spec 还不太一样。 总体上，这种一次性生成的 Plan ，其实我理解它能达到的效果可能跟 todo 是一样的，即： 1. 保证执行过程不偏离预定轨道 2. 但它并不会提高模型解决任务的复杂度