wingtao

@liu731 然后他自杀了，自杀时负债大于资产

@lihui4305 写的很棒，实践出真知

@chtcrack 之前也是上手这种 0-1 的 Demo 项目，但在实际生产中，它就是一直不敢用，因为生产项目中主流程功能的实现是一部分还有很大一部分是要在一个已知的巨大项目中去集成而且还要考虑各种边界情况，这些在 0-1 的玩具项目中都是不需要考虑的

@ArrayBuffer 类似 spec-kit 这种个人不认为它现在是一个理想的实现方式，因为它整个流程其实还是太固化了。这种死板的流程，它不应该 Agent 的一个最终形态。

关于 Plan 的话，我认为它跟 Spec 还不太一样。
总体上，这种一次性生成的 Plan ，其实我理解它能达到的效果可能跟 todo 是一样的，即：
1. 保证执行过程不偏离预定轨道
2. 但它并不会提高模型解决任务的复杂度

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

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

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

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

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