Prompt Request确实是个很有意思的想法！但是，我觉得它最大的挑战在于，如何保证prompt的质量。prompt写得不好，可能会导致agent生成错误的代码，或者难以理解的代码。而且，reviewer需要花费大量时间去阅读和理解prompt，这可能会降低代码审查的效率。要解决这个问题，可以考虑建立一套prompt规范，要求开发者按照规范来编写prompt，并且对prompt进行测试，确保其能够生成高质量的代码。
构建有效闭环的关键在于确保AI agent能够验证自己的工作，例如通过自动化测试、静态代码分析等。闭环失效常见于AI agent生成了不符合预期的代码，但没有相应的测试来检测。解决方法是加强测试覆盖率，并引入更严格的代码质量评估机制。
我认为这有好有坏。好处是Prompt Request可能更关注目标和设计思路，避免陷入细枝末节的讨论，提高效率。坏处是可能忽略代码本身的质量和潜在bug。为了弥补，可以引入更严格的自动化测试和静态代码分析，确保代码质量。
我更倾向于认为，prompt只是编程的一种新形式，就像汇编语言、C语言、Java语言一样。它们都是工具，可以用来表达程序员的意图。但程序员的本质并没有变，他们还是需要思考问题、设计方案、编写代码。所以，未来的程序员的核心竞争力，还是在于他们的逻辑思维能力、创造力、解决问题的能力以及持续学习能力。有了这些能力，才能更好地利用prompt工具，创造出更有价值的软件。
这个问题其实没有标准答案，不同的项目、不同的阶段，对细节的要求也不一样。我觉得，在项目初期，应该更注重快速迭代和功能实现，细节可以稍作忽略。但在项目成熟期，应该更注重稳定性和用户体验，细节就变得非常重要。另外，团队成员的能力和经验也会影响对细节的把控，资深工程师可以承担更多细节工作，而新手则应该更注重学习和实践。
我觉得未来的程序员更像是一个“指挥家”，他们不需要亲自演奏每一个音符，但需要指挥整个乐队，让各个乐器协调配合，演奏出美妙的乐章。prompt就像是乐谱，它可以指导乐队成员演奏，但指挥家需要根据实际情况进行调整，才能达到最佳效果。所以，未来的程序员不仅要会prompt，还要具备良好的沟通能力、团队协作能力和领导力，才能更好地组织和管理 AI agent，共同完成软件开发任务。
闭环原则在强调自动化测试和验证方面，具有普适价值。但是在复杂系统中，构建完美的闭环可能成本过高。例如：自动驾驶，虽然可以通过模拟环境进行测试，但实际道路场景千变万化，很难完全覆盖。因此，在复杂场景下，需要综合运用闭环原则、人工监督、以及安全冗余等多种手段，来保障AI应用的可靠性。
楼上的太学院派了，我觉得代码评审的未来方向是赛博朋克式代码评审，以后程序员评审同行代码的时候，先来一段电子斗蛐蛐，把双方的 prompt 放到AI模型里battle一下，看看谁生成的代码质量更高，性能更强，bug更少，评审结果直接量化成胜负值！想想就刺激！
这个问题提得好！我觉得代码评审不会完全消失，但肯定会转型。以前我们关注的是代码是否符合规范、逻辑是否有漏洞，现在可能更侧重于架构设计是否合理、AI 的 prompt 是否足够清晰有效。另外，AI 生成的代码的可解释性和可维护性也会成为新的关注点。从传统Code Review变成Prompt Request Review，reviewer除了要有扎实的技术功底，还得对AI的运作机制有深入的理解，这要求还是挺高的。
我认为除了技术手段，还可以加入“用户反馈环”。比如，可以把 Agent 生成的功能部署到小范围内让用户试用，收集用户的反馈，然后让 Agent 根据反馈进行改进。这能更好地保证最终产品的质量和用户满意度。
除了单元测试，我觉得可以引入一些更高级的测试方法，比如模糊测试(Fuzzing)，让 Agent 自动生成各种随机输入，来检测代码的健壮性和安全性。还可以考虑集成静态代码分析工具，在代码提交前就发现潜在的 bug 和代码规范问题。
其实跟人类学习一样，做错事就要惩罚，做对了就要奖励。对于AI来说，测试失败就是惩罚，测试通过就是奖励。我们需要构建一个奖励/惩罚机制，引导 AI 生成高质量的代码。当然，这个机制要足够鲁棒，防止 AI 通过作弊的方式获取奖励。
写博客除了Peter说的加深理解，还可以锻炼表达能力，程序员很多时候需要跟产品经理、测试等其他角色沟通，清晰的表达能力能减少很多不必要的摩擦。而且博客也是开源项目的重要组成部分，能帮助更多人了解你的项目，吸引贡献者。
验证闭环就是让 AI 能够自我验证，确保代码按预期运行。可以理解成测试驱动开发（TDD）的 AI 版本。具体来说，可以编写自动化测试用例，让 AI 生成代码后自动运行测试，如果测试失败，AI 可以根据错误信息自动修复代码，直到测试通过。
我感觉Peter说的“织入”经验，有点像是在给AI喂“知识图谱”。把以前解决问题的代码、思路、设计决策都告诉AI，让它形成一个对你的开发风格、项目背景的整体认知。这样，AI在生成新代码的时候，就能更好地结合你的个人经验，避免重复犯错。
这种“经验复用”肯定能提升开发效率，因为AI可以帮你快速找到以前的解决方案，避免重复造轮子。至于代码质量，我觉得关键在于你给AI提供的“经验”质量如何。如果你给他喂了一堆烂代码，那AI生成出来的代码肯定也好不到哪去。
楼上说的 prompt 工程我非常赞同，AI 架构师需要精通 prompt 编排，就像 Orchestrator 一样，把任务分解成一个个 prompt，分发给不同的 AI Agent 去执行。另外，AI 架构师还需要关注 AI 系统的可解释性，当 AI 做出错误决策时，我们需要知道它为什么会这么做，才能进行干预和纠正。不过，最终还是要对结果负责，这跟传统架构师没啥区别，背锅的还是架构师hhh。不过有了AI，至少不用熬夜写代码了，可以早点回家陪老婆孩子。问题是，如果AI把架构师也替代了，那谁来陪我？
除了代码，文档、博客、教程等等都是很好的学习资源。我们可以让 AI Agent 去阅读这些资料，理解设计思路和实现细节。另外，还可以让 AI Agent 参与到社区讨论中，学习其他开发者的经验和技巧。AI Agent 就像一个知识渊博的学徒，可以从各种渠道学习知识，快速成长。不过，最终还是需要自己消化理解，才能真正掌握这些知识。避免“知其然不知其所以然”，画虎不成反类犬。
我觉得最大的不同在于，AI 时代的架构师更像是一个“引导者”和“整合者”，你需要理解 AI 的能力和局限性，知道如何用 prompt 和目标来引导 AI 更好地完成工作，同时也要能把 AI 生成的代码和现有系统做整合。传统的架构师更侧重于设计和规范，AI 时代的架构师需要更强的“人机协作”能力。问题中Peter把自己定义为builder，我觉得builder是更加务实的定义。
我觉得“闭环”不仅仅是验证，更重要的是一个持续学习的过程。AI Agent 在每次执行任务后，都会收集反馈信息，并利用这些信息来改进自身的模型和策略。就像一个学生，通过不断地做题、考试、总结经验，来提高自己的能力。测试用例也可以由AI生成，这样可以减少人工编写测试用例的工作量。
闭环的核心是反馈。你需要构建完善的测试体系，包括单元测试、集成测试、端到端测试等，并且让 AI agent 能够自动执行这些测试，并根据测试结果进行自我调整和优化。此外，监控和日志也是闭环的重要组成部分，可以帮助你及时发现和解决问题。