摘要
一句话总结
赞同“先设计再借助AI开发”的模式，但建议放弃强推固定格式文档，转而激发组员的主观能动性，让其自主完成设计并探索最适合的AI编程交互方式。
核心要点
- 认可整体模式：高度认可“先设计再开发，辅助AI编程”的工作流。
- 激发主观能动性：建议组长只负责沟通需求和确定宏观设计方向，将具体设计任务下发给组员。
- Review与对齐：以组员自主设计为主，组长在过程中进行引导和辅助，最终通过Review达成一致。
- 灵活的AI交互：指出写固定格式文档未必是与AI沟通的最佳方式，有时简短的几句话配合代码效果更好。
- 自主探索结对方式：建议将与AI沟通的方式完全交给组员，让其自行找到与AI结对编程的最佳实践。
- 组织经验交流：组长的管理重心应放在组织团队交流，分享优秀的AI编程经验。
- 设计与解耦：在使用AI编程时，系统设计非常重要，需保持模块之间较低的耦合度。
- 重逻辑轻形式：不需要过度追求设计的形式，只要设计清晰、能在单次会话中为AI提供充足上下文，即可生成高质量代码。
风险/不足
- 积极性受挫风险：如果组长包揽了所有设计工作，组员会沦为“工具人”，导致工作积极性下降。
- 效率受限风险：强推固定格式的文档可能并非与AI沟通的最优解，可能会限制AI辅助编程的实际效果。
正文
问：宝玉老师，我在组里强推某种固定格式的开发设计文档，要求组员按格式补充写完，再借助o1或则别的模型实现代码细节，是否可行。等代码出来工程师再进行一定的修改或则调整。
答：
对于这种先设计再开发，辅助 AI 编程的方式，我觉得非常赞，如果我做的话，可能会做一点调整：
-
组员的主观能动性很重要，如果是组长把事情都想了都做了，他们的作用就成了工具人，积极性就没有那么高，所以我可能只是把需求沟通清楚，大的设计方向定下来，任务分下去，让组员各自设计，然后review，最终对齐，以组员自己设计为主，但是在过程中多引导多辅助，达成一致。
-
采用 AI 编程是很好的，但写文档的方式不见得是最佳方式，比如说有时候几句话辅助代码可能效果更佳，另外既然是要组员去用 AI 沟通，那不如完全交给组员自己去做，让他们去找到和 AI 结对的最佳方式，组长就是组织好经验的交流，让大家一起交流好的经验，但还是发挥组员自己的主观能动性。
我最近大量借助 AI 编程，经验就是用好 AI 编程，设计很重要，并且模块之间耦合度不要太高，不需要太过于追求设计的形式，只要设计清晰，能让 AI 理解你的设计，能在一次会话中获得足够的上下文，就容易让 AI 生成好的代码。