即刻App年轻人的同好社区
下载
昨天好像梦到小白生病了，我左手抱着小白，右手猛拧电动车车把，带着小白去找医生。
小白在我的怀里乱蹬，我只好用下巴抵住他的脑袋，一边安抚他一边漂移…
最后好不容易到医院了，医生说小白什么事都没有，只是他认为我对小黑比对他好，所以故意假装生病。
@赐我贵族圆环 严肃思考是不是最近一碗水没端平，小猫都托梦给赛博叔叔了！
…果然生病了容易被乘虚而入。
小白在我的怀里乱蹬，我只好用下巴抵住他的脑袋，一边安抚他一边漂移…
最后好不容易到医院了，医生说小白什么事都没有，只是他认为我对小黑比对他好，所以故意假装生病。
@赐我贵族圆环 严肃思考是不是最近一碗水没端平，小猫都托梦给赛博叔叔了！
…果然生病了容易被乘虚而入。
2 20
可爱哟
阿清和他的土豆: 泥豪
0 00
最近在重新梳理我的工作流。
之前在模型能力不够的情况下，框架和基础架构都是我自行搭建，所以还沿用着传统软件开发的习惯。即使和Agent多轮对话时，也是保持着先让Agent反复询问我每一个设计的细节，迫使我思考其中设计的取舍。
在Agent提交PR后，依然坚持人工Review代码，接着通过设计文档调整每一处细节，在合并PR的时候留下Devlogs，最终形成一整套的工作流。
这种方式虽然繁琐又降低效率，但好处在于通过这些迭代的文档/日志记录，极好地保证了项目的整体风格和设计目标，并且依靠这些凭据定期迭代Skill时也能发现很多不足之处，便于及时调整。
现在的模型能力变得更强了，人工Review已经跟不上整体的效率了，但不得不说，模型是有“手感”的。
在GPT-5时期，最大的问题在于/Goal 不能很好完成目标，就像一辆需要不断矫正的四驱车，放纵的后果在于开足马力奔向错误的方向。
GPT-6的解决方案是通过反复验证来提高准确性，以至于GPT-6-Astra在一次尝试中解决了88.0%的任务，四次尝试内解决了99.2%的任务。随即而来的是不断的Check和大量的测试用例编写，还有大量Token消耗和慢。
不确定这不是和Openai最近释出的大量数学论文有关，但很明显，在训练的过程中应该是涉及了大量数学的严谨证明，以至于训练出了一个没有安全感的学霸，最后拿着堆积如山的草稿纸给出一个“因此暂不能确认XX已视为完成”的伪证明。
至于GPT-6-Sol不遵从指令且容易做一些“它认为你需要做的事情”，这种失控感让我直接选择放弃，而且它的意图识别和上下文也没有理解得特别好。
Claude 是所有的模型中我认为“意图识别”最优秀的。能精确Get到用户想要的点，而且不需要太多的提示词。在GPT-6-Astra场景中则需要给出优质的上下文，它才能很好帮你干活。
于是我现在的工作流变成先通过Opus5.5先构建优质的上下文，再通过Claude Code 去fork Codex 进程。这样的好处在于可以直接屏蔽掉GPT-6的冗余，啰嗦的回复，直接和Claude 确认目标和实现方案(而且它很容易Get到你的目的)，而且Opus5.5的提示词写的非常精简优秀，能有效控制GPT-6做大量验证，似乎在这个模型训练的时候就为多Agent场景做了很多优化。
另外一方面GPT-6-Astra 在Review方面确实很详细，你可以说它是“鸡蛋里面挑骨头”，但它提出来的那些也确实是问题。这可以很好弥补Opus那些没察觉到的问题和细节。
我最近使用这种多Agent协作的方式，体验下来非常不错。可以用Opus5.5作为Agent的中枢，让它去做多Agent的调用，这样构建多条Work Piepline，人类通过宏观的角度来观察这些Agent的产出和目标的偏差，再纠正/调整以达成最终的目标。在这个过程中可以通过产出来反向Review目标是否设定的合理，通过快速试错来调整技术方案，消耗的是人类的判断能力。
我知道有些研究室已经开始“去中心化”构建Agent Piepline 但我认为最终还是得为自己的产出负责。交付物应该是完整的，事情尽量做干净点。
以上，全手打。
之前在模型能力不够的情况下，框架和基础架构都是我自行搭建，所以还沿用着传统软件开发的习惯。即使和Agent多轮对话时，也是保持着先让Agent反复询问我每一个设计的细节，迫使我思考其中设计的取舍。
在Agent提交PR后，依然坚持人工Review代码，接着通过设计文档调整每一处细节，在合并PR的时候留下Devlogs，最终形成一整套的工作流。
这种方式虽然繁琐又降低效率，但好处在于通过这些迭代的文档/日志记录，极好地保证了项目的整体风格和设计目标，并且依靠这些凭据定期迭代Skill时也能发现很多不足之处，便于及时调整。
现在的模型能力变得更强了，人工Review已经跟不上整体的效率了，但不得不说，模型是有“手感”的。
在GPT-5时期，最大的问题在于/Goal 不能很好完成目标，就像一辆需要不断矫正的四驱车，放纵的后果在于开足马力奔向错误的方向。
GPT-6的解决方案是通过反复验证来提高准确性，以至于GPT-6-Astra在一次尝试中解决了88.0%的任务，四次尝试内解决了99.2%的任务。随即而来的是不断的Check和大量的测试用例编写，还有大量Token消耗和慢。
不确定这不是和Openai最近释出的大量数学论文有关，但很明显，在训练的过程中应该是涉及了大量数学的严谨证明，以至于训练出了一个没有安全感的学霸，最后拿着堆积如山的草稿纸给出一个“因此暂不能确认XX已视为完成”的伪证明。
至于GPT-6-Sol不遵从指令且容易做一些“它认为你需要做的事情”，这种失控感让我直接选择放弃，而且它的意图识别和上下文也没有理解得特别好。
Claude 是所有的模型中我认为“意图识别”最优秀的。能精确Get到用户想要的点，而且不需要太多的提示词。在GPT-6-Astra场景中则需要给出优质的上下文，它才能很好帮你干活。
于是我现在的工作流变成先通过Opus5.5先构建优质的上下文，再通过Claude Code 去fork Codex 进程。这样的好处在于可以直接屏蔽掉GPT-6的冗余，啰嗦的回复，直接和Claude 确认目标和实现方案(而且它很容易Get到你的目的)，而且Opus5.5的提示词写的非常精简优秀，能有效控制GPT-6做大量验证，似乎在这个模型训练的时候就为多Agent场景做了很多优化。
另外一方面GPT-6-Astra 在Review方面确实很详细，你可以说它是“鸡蛋里面挑骨头”，但它提出来的那些也确实是问题。这可以很好弥补Opus那些没察觉到的问题和细节。
我最近使用这种多Agent协作的方式，体验下来非常不错。可以用Opus5.5作为Agent的中枢，让它去做多Agent的调用，这样构建多条Work Piepline，人类通过宏观的角度来观察这些Agent的产出和目标的偏差，再纠正/调整以达成最终的目标。在这个过程中可以通过产出来反向Review目标是否设定的合理，通过快速试错来调整技术方案，消耗的是人类的判断能力。
我知道有些研究室已经开始“去中心化”构建Agent Piepline 但我认为最终还是得为自己的产出负责。交付物应该是完整的，事情尽量做干净点。
以上，全手打。
1 11
