kiro 的所谓 spec 模型好像并没说的那么好

反正这几天也试了下 仅代表个人看法 实际操作就是, 如果不是那种司空见惯烂大街的需求, 慎用 spec, 因为 spec 又走了老模式, 框框设计一堆接口数据结构文档一堆啥活没干, 一大堆文件就出来了, 包括那种人人头疼的什么线程管理, 并发管理, 锁什么的, 就是老问题可能过度设计, 除非你知道这需求肯定靠这个设计能解决, 但只要是稍微少见的需求, 不是烂大街 crud, 不一定一次就设计正确, 这很正常把

任何新功能需求, 经常都要尝试几个方案的, 谁敢说一次就设计对了

但 spec 模式默认需求是对的, 设计是对的才一步步往下走的

如果设计不那么正确, 显然是走不下去的

我搞了一段时间, 交互很多次, 搞出几十个文件, 但问题没解决

后来还是换成 augment, 走简单对话模式, 先搞出最小化 demo 再说, 什么并发优化能跑通再说