运行环境的指定

在开发中会报错什么依赖没有，实际是主机上有多个环境环境不对，然后实际选择的环境不对，可以声明默认环境，或者在项目直接新建虚拟环境。

AI开发无法确认项目预期

项目开发中，可能涉及各种各样的细节，纯依靠文字的话很难知道当前的开发进度。ai在开发中很容易忽视其实现方式，并偏向面向功能开发，这回存在一个问题，各种各样的功能并没有走公共的组件，导致功能点是非常固化的，链条可能是点对点的，无法预期某个地方的改动会影响到其他的什么部分，所以设计是很重要的
那么首先需要做到，让其设计并知道其是怎么设计的
1、怎么设计呢？可以考虑画出逻辑框图，从而知道各个组件以及连接关系。在这个层级我们可以抽象出各个组件，让后续的开发基于这样的组件设计来实现。
2、考虑画出时序图，来真正展现出业务流程的完整过程
3、考虑使用设计模式，抽象出可共用的部分，这样可以真实确认数据对象以及业务逻辑是怎么
4、画这些图的目的是为了告诉ai遵循预期的开发方式，面向对象开发而不是面向功能开发，同时也帮助我们理解项目的架构和预期

AI开发中不知道项目的进度

在开发中我们虽然让ai做了功能的开发，但是不知道项目的实际进展，同时也不知道是否有按照设计来实现。
个人认为在开发前就需要让ai记录一个项目开发进展文档，进行阶段测试目标制定，并在每个阶段都需要有可评估的交付件，这样在其每个阶段开发完成后都可以看到其进度，并能实际看到数据对象来确认其进展是否符合预期

无法确认ai的开发是否按照我们预期的设计实现

可能存在这样一个困局，完整功能开发还没完成，ai提示已经完成了一部分功能开发并进行验证，那存在几个思考
1、当前实现是否按照我们的预期进行
2、我们是否应该停下来，让其检查其当前的实现方式是否按照设计？反复自查可能导致一直卡在实现阶段，而无法达成我们需要的功能
3、是否应该拆分模块或者阶段来验证，主动给项目拆分阶段。在每个阶段进行系统性检查，当该阶段完成后，进行验收再进行下一阶段的开发。如果是这样，那可能就可以并行按照项目阶段进行实现。那么就会存在一个问题，某个阶段就是无法实现，或者我们设计与实际无法适配，可能存在设计需要调整的问题，那怎么处理？

如何破除ai开发中那种虚无的感觉？

在ai开发中，因为代码不用自己写，而且只需要给ai指令让其继续就能继续完成开发， 其实作为人是很没有参与感的，如果自己不想着主动去了解项目进展，很容易只追求结果而忽视过程。但问题在于只给确认，生成的结果往往并不那么美好，生成的结果也总是自己去适配居多，这违背了初衷，同时也让人攫夺做什么都毫无意义。
个人认为需要多思考，主要是要建立一套反馈机制，让自己能参与其中，同时避免做苦力活，变成自己给ai打工了。前面提到的先设计再实现可以控制方向，另一方面就是自己也要记录，就如当前的文档，将自己的思考都记录下来，我们只关注成果，而不是人为去修正。

ai开发总是会存在过度设计的问题

在和ai进行设计讨论后，ai却未按照我们的预期来实现，或者做了修改，或者引入新的设计来解决问题，或者考虑兼容已有的实现来做兼容。
其实问题在于，是ai自行决定却未对告知进行说明，或者说明了，但是影响不明确，误以为是开发中的某个小逻辑。
尝试可以要求限制其对设计的改动，当遇到原有设计无法覆盖实现，或者已有实现与设计冲突时，需给出分析结论，由用户同意实施，而不是越过用户直接执行。

ai测试看似很多很耗时，但不知道测了什么， 也没达到想要的效果。

分层测试，改动只在模块内部时仅触发模块内部测试或仅进行该单点功能测试，当改动设计上下游时，将涉及的上下游一起测试，当涉及多个模块的时候，进行多模块的测试。
还有个问题就是如何构建测试集，我们文字性的描述，怎么对应到实际的测试项，其又如何判断测试是通过的？

有些时候感觉很少的改动，但耗时很久。

是否可以考虑将agent职责分离下，不同的模块不对整体负责，仅对内部实现负责，表现为给输入以及给输出。

业务检查业务功能
架构检查架构实现
产品检查产品功能
考虑claudecode的多层漏斗形态来实现？

为什么感觉别人的ai生成跟自己不一样。

别人的更顺还是怎么的，自己生成的总是不符合预期，明明自己的要求并不复杂，架构应该很简单，只是补充细节的问题，为什么耗时久，还没解决，效果也不好。
而且在交互中存在一个问题，投入了时间，但无法判断完整完成还有多久，现在看似做了，但不知道从整个进度来看做了多少。无法把控项目进度。
一方面让ai解析下别人使用ai生成的项目，别人是怎么构造的，看是否可以提取出可复用的范式，另一方面搭好骨架，走完一个最小完整流程。后续在此基础上扩充。

ai总是自说自话如何解决？

在设计阶段还不算明显，但当遇到问题且需要需改实现的时候经常会出现这样的问题：经过沟通后ai和你沟通确认了几个项，然后就进行实施了，然后最后的完成反馈让人无法和最初的问题进行关联，一般会引入一些未提到的实现，一些新的概念或者设计，其默认我知道所有的细节，而自己很难理解其具体是怎么实现的，也不知道解决了什么问题。
当前的想法是告诉ai答复策略：你后面注意，在答复业务细节的时候，不要自顾自说自己的实现细节，而是要考虑和我们的源头源头问题的衔接，你是怎么做的，你做的事情和我们的问题有什么关系，你为什么要这么做，你做了之后解决了我们的什么问题

关于如何设计的问题？

个人认为需要明确三点：
1、数据对象是什么，采用设计模式和UML图来明确输入和输出，从而知道数据是怎么变化的
2、系统架构如何，这里可以看出系统的组件组成，从而对产品有个比较清洗的认知。
3、流程图以及时序图是如何，通过流程和时许，来约束其实现。

如何实现或验证呢？
用最短全路径走完完整流程，给定明确的功能看下整个流程会怎么走。

如何确保实现是符合预期设计的？

首先是需要设计清晰，将模块内聚呈现，有个总体概览，然后是架构，流程，UML图，并制定workflow，要求按照工作流完成。
另外需要引入ai复核，检查实现的设计是否复合预期。
开发阶段，避免单个session被持续使用，导致上下文摘要被压缩而出现信息丢失。

如何通过测试保证功能达成？

采用明确的测试分层，利用UT,IT，E2E，Acceptance 完成全量的测试。

前后端的分离实现

前端页面如何设计

性能问题

感觉就是SDD的思想，在一开始设计好，完成约束的制定，而不是简单面向功能开发。
软件架构设计，测试规范，workflow，agent倾向 都可以提炼出来到其他的项目进行复用