通过查看以上2份代码，可以看出基本都实现了我描述的需求，那是不是说，只要我的需求描述足够全面，足够细致，那AI就能帮我写出我想要的代码？既然我对我想要的代码是有清晰要求的，那么是否可以通过写一个示例模块，让AI根据该模块代码，反向生成可以让AI自动生成该代码的提示词呢？在编码前，还要维护一份结构化提示词会是一个负担，因为在本来的开发流程中是没有该步骤的，加入这个流程会让人有抵触，明明AI是减轻负担

为有很多全局量的代码增加测试是很有挑战的，一个测试可能会因为另一个测试留在全局量里的状态信息而遭到破坏，另一件同样的坏事是其他测试开始依赖于这种状态。测试是代码职责的文档,并确保任何将来Time函数的错误都能直接被它自己的测试所捕获，而不是其他测试的副产品。一旦感知到了代码中的不对的地方，接下来就要利用我们对代码和设计的知识来预想到一个更好的解决方案。从Lightscheduler的角度来看，Ti

测试驱动开发(TDD)是一种增量式软件开发技术。简单地说，就是在没有失败的单元测试的前提下不可以写产品代码。这些测试要很小,而且要自动化。用测试来驱动其实很合理。相对于直接写产品代码，TDD的实践者们会先用测试来表达他们希望产品代码会有什么样的行为。然后这个测试显然会失败。只有在这时，他们才开始写产品代码;以便让测试通过。在测试驱动开发LightScheduler时，测试夹具通过截获对TimeSe

最近修复的一个bug让我对AI在软件质量测试及BUG修复上的应用有了新的期待。