开发心得 (Development Reflection)

1. 选题思考

核心问题：为什么做这个？解决了谁的痛苦？

我选择做这个多Agent决策工作坊项目，是因为在日常学习和工作中，我深刻体会到团队决策的痛点。当一个团队面对复杂问题时，往往会陷入观点分歧、讨论效率低下、决策质量参差不齐的困境。特别是在方案评审阶段，不同角色（如产品经理、技术专家、用户代表）往往从各自的专业角度出发，难以形成全面、平衡的决策。

这个项目主要解决了以下几个核心问题：

决策片面性：通过模拟多个专业角色的辩论，避免了单一视角的局限性，让决策更加全面。
讨论效率低：自动辩论流程大大缩短了传统会议的时间成本，提高了决策效率。
要点提取难：自动生成决策要点，避免了人工记录的遗漏和偏差。
知识共享不足：不同角色的观点碰撞，促进了团队成员之间的知识共享和相互理解。

这个项目的价值在于，它为团队决策提供了一个智能化的辅助工具，既能提高决策质量，又能提升决策效率，让团队能够更快速、更全面地做出理性决策。

2. AI 协作体验

2.1 初体验

核心问题：第一次用 AI 写代码的感觉？

第一次用 AI 写代码的感觉可以用"惊喜"和"震撼"来形容。我原本以为需要花费数小时甚至数天才能完成的项目框架，在 AI 的辅助下，只用了不到一个小时就搭建完成了。AI 不仅能理解我的需求，还能自动生成结构清晰、功能完整的代码，甚至还能提供一些我没有想到的优化建议。

最让我印象深刻的是，当我描述了多Agent决策工作坊的基本需求后，AI 不仅生成了核心的 Agent 类和辩论管理逻辑，还自动处理了 API 连接、环境变量配置、用户界面设计等细节问题。这种"描述意图，AI 实现"的开发方式，让我感受到了 AI 时代编程的全新范式。

当然，初体验也伴随着一些挑战。比如，AI 生成的代码有时会存在一些细微的错误，需要我仔细检查和调试。另外，如何准确描述需求，让 AI 能够理解我的真实意图，也是一个需要不断学习和实践的过程。

2.2 Prompt 交互

核心问题：哪个 Prompt 让你直呼"牛逼"？哪个让你想砸键盘？

最牛 Prompt：
```
请设计一个多Agent辩论系统，包含以下核心功能：
1. 支持多种角色（产品经理、技术专家、用户代表等）
2. 能够自动进行多轮辩论
3. 可以从辩论内容中提取决策要点
4. 使用Streamlit构建交互式界面
5. 配置文件管理API连接

请使用Python语言，按照模块化设计原则，创建清晰的项目结构。
```
这也是我觉得最神奇的地方：这个Prompt虽然简洁，但包含了项目的核心需求和设计原则。AI 不仅理解了我的需求，还按照模块化设计原则生成了完整的项目结构，包括agent.py、config.py、app.py等文件，甚至还自动创建了.env文件模板。这大大加快了项目的开发进度，让我能够专注于核心功能的优化和调试。
最坑 Prompt / 交互：在开发过程中，我遇到了一个比较棘手的问题：当我尝试使用硅基流动（SiliconFlow）作为API提供商时，AI 生成的代码中使用了错误的模型ID格式。我最初的Prompt是：
```
请配置DeepSeek API连接，使用硅基流动作为API提供商，模型ID为openai/deepseek-ai/DeepSeek-R1-Distill-Qwen-14B
```
然而，AI 生成的代码中直接将模型ID作为OpenAI的model参数传递，而没有考虑到硅基流动的特殊格式要求。这导致了API调用失败，我花费了不少时间来调试这个问题。最终，我通过查阅硅基流动的文档，发现需要将完整的model ID（包括前缀"openai/"）作为model参数，而不是像传统OpenAI API那样只使用模型名称。

这次经历让我意识到，虽然AI 很强大，但它有时会对特定平台的细节缺乏了解。在使用AI开发时，我需要对技术细节保持警惕，特别是当涉及到特定平台或服务的集成时，需要仔细检查和验证AI生成的代码。

2.3 Bug 解决

核心问题：AI 生成的 Bug 你是怎么解的？

在开发过程中，AI 生成的代码中出现了一个比较隐蔽的Bug：当辩论轮次为1时，辩论历史的处理逻辑出现了错误。具体来说，AI 生成的代码在生成决策要点时，会遍历从第1轮开始的所有辩论轮次，但当辩论轮次为1时，这个逻辑会导致索引错误。

我是通过以下步骤解决这个Bug的：

错误定位：当我测试辩论轮次为1的情况时，应用抛出了一个索引错误。通过查看错误堆栈，我定位到了错误发生在agent.py文件的generate_decision_points方法中。
问题分析：仔细检查代码后，我发现问题出在辩论历史的处理逻辑上。AI 生成的代码假设辩论历史中至少包含两个轮次（初始轮次和至少一个辩论轮次），但当辩论轮次为1时，辩论历史中只有两个轮次（初始轮次和一个辩论轮次），导致索引访问错误。
解决方案：我修改了generate_decision_points方法，添加了对辩论历史长度的检查，并调整了遍历逻辑，确保当辩论轮次为1时，代码也能正常工作。
验证修复：修改后，我再次测试了辩论轮次为1的情况，确认Bug已经修复，应用能够正常生成决策要点。

这次经历让我认识到，虽然AI 能够生成高质量的代码，但它有时会忽略一些边界情况。在使用AI开发时，我需要仔细测试各种边界情况，确保代码的鲁棒性和可靠性。

3. 自我反思

3.1 离开 AI

核心问题：离开 AI，我还能写出这个吗？

诚实地说，如果没有AI的帮助，我可能无法在这么短的时间内完成这个项目。这个项目涉及到多个技术领域，包括AI模型调用、Web界面设计、多线程处理等，需要掌握大量的专业知识和技能。

但是，如果给我足够的时间，我相信我还是能够写出这个项目的。因为AI 虽然提供了代码实现，但核心的设计思路和业务逻辑仍然是我自己思考和决策的。我需要理解项目的需求，设计系统架构，选择技术栈，验证代码质量。这些能力是AI 无法替代的。

更重要的是，通过与AI的协作，我学到了很多新的知识和技能。比如，我学会了如何使用Streamlit构建交互式Web应用，如何设计模块化的代码结构，如何处理API连接和错误情况。这些知识和技能将成为我自己的能力，即使离开AI，我也能够运用这些知识来开发类似的项目。

3.2 核心竞争力

核心问题：AI 时代，我作为程序员的核心竞争力到底是什么？

在AI时代，作为程序员，我的核心竞争力不在于编写代码的速度和数量，而在于以下几个方面：

需求理解和分析能力：AI 可以生成代码，但它无法理解真实世界的复杂需求。我需要能够深入理解用户需求，将模糊的业务需求转化为清晰的技术需求。
系统设计和架构能力：AI 可以生成模块级的代码，但它难以从整体上设计一个复杂系统的架构。我需要能够设计清晰、可扩展、可维护的系统架构，确保系统的长期稳定性和可扩展性。
代码质量和可靠性意识：AI 生成的代码可能存在错误和安全漏洞，我需要能够仔细检查和验证代码，确保代码的质量和可靠性。
问题解决和调试能力：当系统出现问题时，AI 可能无法快速定位和解决问题。我需要能够运用调试工具和方法，快速定位和解决问题。
创新思维和业务洞察力：AI 可以优化现有系统，但它难以提出全新的解决方案。我需要能够运用创新思维，结合业务洞察力，提出创造性的解决方案。
持续学习和适应能力：AI 技术发展迅速，我需要能够持续学习和适应新的技术和工具，保持自己的竞争力。

总之，在AI时代，程序员的核心竞争力在于"人的能力"，即理解需求、设计系统、解决问题、创新思维等能力。这些能力是AI 无法替代的，也是我在未来需要重点培养和提升的能力。

结语

通过这个项目，我深刻体会到了AI 时代编程的全新范式。AI 不仅是一个强大的工具，可以帮助我提高开发效率，还可以成为我的"学习伙伴"，帮助我学习新的知识和技能。

同时，我也认识到，在AI时代，我需要重新定位自己的角色和价值。我不再是一个纯粹的"代码编写者"，而是一个"系统设计者"和"问题解决者"。我需要将更多的精力放在需求理解、系统设计、问题解决等方面，而将代码实现等重复性工作交给AI 来完成。

最后，我想说的是，AI 不是程序员的替代品，而是程序员的增强工具。只要我们能够正确认识和使用AI，它将成为我们在AI时代的强大助力，帮助我们开发出更加优秀、更加创新的软件产品。

9.3 KiB Raw Blame History Unescape Escape