这个项目自己是全程参与的，在参与过程中发现的问题一一列举以警示。
造成这些问题的根本原因是——角色问题。即这是第一次独立参与项目，在过程中分不清自己的角色而造成混乱。
1、合同
合同是负责人一手制定人，它不完善，对可能出现的细节未能考虑周全，而自己做为核实方，未从全局角度考虑，造成合同有很多处纰漏。
而这时的角色应该是项目经理，审核合同细则，避免不必要歧义。
2、时间
项目周期只有1个月时间，而在此之前需求调研用时较短，未达到推演可执行阶段。
3、需求文档
它本身是不合理的，未明确开发边界，有哪些功能，没有哪些功能。使用什么方案实现？
需求文档只考虑到了需求，未考虑实现方式，是否可行，有多大技术难度，客户需要提前配合等等内容，也就是上面说的“推演”。你必须在大脑中有一个清晰的“操作界面”、“业务流程图”。
4、界面
后端使用的框架，界面是统一的这个没什么好挑剔的。问题出在前端，对！前端，客户最初有一版功能，用 AI 生成的，因某些原因未开发完成。
而我们也是偷懒，直接借用了这个界面。而在项目完成第一阶段后，找客户演示，客户直接否了。而后的结果是，客户出界面，我们实现……
5、参考**
最怕就是“你参考**的界面”，还好这块给客户说明，只做微小调整。
这在需求文档阶段就需要标定参考的细则，到什么程度。
在某些情况下，一些效果很难实现，这时候先停止，退一步，忙点其他事情，那个插件已完备，你只是不知道而已。
6、变更说明
客户是心口不一的，需要文档记录变更说明，以证明修改的原因。避免功能频繁变动。
7、小步快跑
即在完成一项功能后，交客户验证，确定是否正确（这是在补前面需求文档不明确的坑）
8、交付文档
未考虑到使用者角度问题，写的是功能介绍文档（偏技术类），缺少的是系统使用文档，也就是说如何使用这个系统。
9、知其然，知其所以然
对于问题，总想像成为锤子，为解决问题而去解决问题，未考虑到出现的原因。
10、感谢 DeepSeek 和 TraeCN
没有他们，这是一个不可能完成的任务。
0、如果能从来
答案是：不能！以上做为反思，避免入坑。
原有的开发模式为多人负责，各司其职；而现行的开发模式为：需求 + AI。而人负责输入正确、过程最优、输出正确；另外，最重要的是——慢即是快！