根据我的经验，如果要求模型创建小的PR或提交，它们的表现会明显变差。它们缺乏有效地排序工作和理解依赖关系的能力——不是它们不能做小的PR，而是这样做需要大量的资源，这会触及上下文限制等。如果你之后想要回去编辑一整套提交或PR，或者将工作重新基础到中间，那就更困难了。我认为所有这些都不随着代码量或提交数量呈线性增长。除此之外，模型通常在讲故事方面表现不佳，因为这需要对你要沟通的人有心智理论。为审查而编写就是讲故事，是通过某种方式让审查者建立信心。我认为当前的大型语言模型仍需要几年时间才能达到这个水平。在我看来，如果你不能做到这些，你只是在扮演软件工程师。氛围编程有它的用途，LLM编程也是如此，我经常做这个！…
源讨论别再给我发PR了；一次抱怨原帖 111 条评论 · 导入时统计把你的经验，加入这段讨论。
我的意思是，有时候我直到写完才知道自己想怎么写。大型重构通常都是这样。 所以，就像你所说的，先重写整个内容，然后再将其拆分成小块，讲述一个故事，然后以可接受和合理的上下文提供给他人。 这是工程师需要的一项技能，当你的同事也开始这样做的时候，这对团队中的每个人，包括你自己，都会带来好处，当你被要求审查他们的工作时也是如此。
完整原文同意。要求小的PR或提交可能会适得其反，除非从一开始就故意将工作划分为更小的部分。这需要人工的设计审查和计划，这也是我不将这一部分外包给代理的原因之一。
完整原文我从来没有在获取小PR方面遇到过问题。不知道是不是我做的事情和你不同，或者我要求的东西碰巧是小的。下次如果遇到大的PR，我会考虑让AI在完成后尝试将其拆分。
完整原文我认为LLM实际上擅长将工作拆分为工作流和任务。问题在于任务本身并不等于良好的PR堆栈。你需要使用功能切片（比如先做后端部分 -> 提交PR，等等）。LLM可以做到这一点，但你需要引导它们这样做。
完整原文这和人类是一样的。给我找一个喜欢维护代码的开发者，我会给你看10个喜欢重写或新项目的人。
完整原文大多数专业软件开发人员（可能包括你）从不会做任何可以被合理描述为工程的工作。这没关系，因为大多数软件并不重要。很少有软件需要真正的工程实践。例外情况是在航空电子和医疗设备等领域。
完整原文看到这么多帖子是关于AI让公关恐怖分子不开心，我感到非常高兴。他们不能再欺负自己的同事了，所以他们在这里发牢骚。
完整原文我和你的经历完全不同，但我也在这个问题上投入了相当大的努力。我同意，仅通过简单的提示而没有提醒的情况下，模型并不能很好地或一致地做到这一点。另一方面，我经常使用两项技能 `/atomic-commits` 和 `/split-branch`，它们正好是你所描述的那样。这是一次将你所描述的概念用语言表达出来的练习，这非常有趣，因为它迫使我把许多从未正式化的想法表达出来，而你是对的，这其中涉及很多心智理论和对他人的观点的考虑。 * 这一系列提交是否讲述了一个连贯的功能故事，每个提交都建立在前一个提交之上？令人惊讶的是，很容易出现一种提交顺序，每个提交都建立在前一个之上，但顺序本身可能并不清晰。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。