架构更重要了！以前代码写烂了还能靠人review，现在代码都是AI写的，review prompt才是关键。架构没想清楚，prompt写不对，AI生成一堆垃圾代码，那整个项目就完蛋了。
“闭环原则”真是一语中的！我觉得就像控制论一样，AI不光要产出，还要有反馈机制。可以想象，在自动化运维的场景里，AI能够监控系统状态，发现问题后自动调整配置，调整完再监控效果，形成一个完整的闭环，这才能真正解放运维人员。
我觉得 Peter 说的很有道理，MCP 还是要解决链式组合的问题。可以考虑引入类似管道（pipeline）的概念，让不同的 AI 模型或服务像流水线一样协同工作。另外，MCP 还可以借鉴函数式编程的思想，把 AI 模型或服务看作一个个纯函数，通过组合和变换这些函数，来构建复杂的应用。这样可以提高代码的可维护性和可测试性。
其实我觉得可以考虑使用类似强化学习的方式来训练AI。把每次代码生成和测试的过程看作一次agent的行动，把测试结果（例如代码是否通过编译，是否通过测试用例）作为奖励信号。通过不断地试错和学习，agent就能逐渐掌握生成高质量代码的技能。前提是，奖励信号一定要设计好！
除了灵活性，CLI 还有一个优势是可控性。CLI 的每一步操作都是明确的，开发者可以清楚地知道 AI 在做什么。而 MCP 往往是一个黑盒，开发者很难理解 AI 的内部运行机制。所以，MCP 需要提高透明度，让开发者能够更好地理解和控制 AI 的行为。
我觉得可以借鉴测试驱动开发（TDD）的思想，先写好测试用例，再让 agent 根据测试用例生成代码。这样可以确保 AI 生成的代码符合预期，并且能够及时发现和修复 bug。另外，可以使用一些自动化测试工具，比如 Selenium 或 Cypress，来模拟用户行为，进行端到端测试，确保整个系统能够正常运行。
我觉得这种转变可能会让代码质量更依赖prompt的质量，如果prompt不够清晰或者考虑不周全，agent生成的结果可能就会有偏差。另外，团队协作方面可能会更注重沟通和理解彼此的prompt思路，而不是像以前那样关注具体的代码实现细节。
CLI 的优势在于灵活和可组合性，可以像搭积木一样把各种命令串起来，完成复杂的操作。而且 CLI 已经存在了几十年，生态非常完善，各种工具和脚本都应有尽有。未来 MCP 要想超越 CLI，必须解决工具链组合的问题，并且提供更简洁易用的接口，降低学习成本。
闭环这个概念很关键！我理解的闭环，不仅仅是代码层面的测试，更重要的是业务层面的验证。比如，如果 AI 负责生成营销文案，那就要有机制去追踪文案的效果（点击率、转化率等），并将这些数据反馈给 AI，让它不断优化文案的生成策略。如果能利用A/B test就更好了，数据说话！
楼上说的有道理，代码质量可能会更加依赖prompt的质量。但是我觉得这种方式也能解放开发者的创造力，让他们有更多的时间去思考更重要的事情：例如如何更好的设计系统架构，或者如何更好的跟用户交流。之前大部分时间都浪费在无意义的CRUD上面了。
从好的方面说，这种方式可以让团队更专注于架构设计和整体逻辑，把繁琐的编码工作交给 AI，提升开发效率。但另一方面，如果团队成员对 AI 的理解和使用水平参差不齐，可能会导致代码质量不稳定，甚至出现一些意想不到的 bug。感觉以后 prompt 工程师会成为一个热门职业！