Zui近因为工作经常被同事拉去帮忙排查各种软件难题，我萌生了把「AI 软件顾问」Zuo成一个自助工具的想法。趁着年底项目相对清闲，我用了 Claude Code 搞了个原型，边写边记录下踩过的坑。下面把整个过程从需求出发，一路走到代码实现，再到真实使用感受，完整地摆出来让大家一起评估它的可行性。

技术团队在面对新需求时总会出现三类痛点：

信息不完整：需求方往往只说「想Zuo一个电商系统」，细节缺失导致方案走弯路。

时间碎片化：开发者忙于写代码，抽不出整块时间来思考整体架构。

知识分散：每个人掌握的技术栈不同，想找对口的参考资料成本高。

Ru果把这些碎片化的信息交给一个Neng够主动提问、快速生成结构化文档的 AI 助手，就Neng把「思考」和「产出」压缩在几分钟之内，从而提升效率。

SSE让服务器Ke以持续向浏览器推送数据，而不是等用户一次性提交完毕再返回。这种方式在生成长篇文档时尤为重要，因为我们需要实时展示「骨架Yi出」「章节正在 」等进度提示。

💡 小技巧：在 SSE 数据流里插入形如 : heartbeat 的注释行，可防止云平台因长时间空闲而强制关闭连接。

async def heartbeat_sender:
    """后台心跳发送器 - 防止云服务断连"""
    while not stop_event.is_set:
        await asyncio.sleep
        yield ": heartbeat

"

上面这段代码几乎是所有流式方案的必备，它把「我还活着」的信号每隔几秒抛给前端，让用户kan到进度条不停跳动，安心感瞬间提升。

Zui初，我让 Claude 按照经典的「五个独立 Agent 各司其职」来搭建系统：需求收集、架构设计、代码生成、测试验证以及文档输出。理论上每个模块douKe以独立升级，但实际运行时出现了两个大问题：

日志分散：一次错误可Neng跨越三个 Agent，需要翻阅五份日志才Neng定位根源。

协作成本：消息队列或 HTTP 调用层层叠加，网络抖动直接导致整体卡顿。

于是我把目标聚焦到「单 Agent 多人格」——即通过不同 System Prompt 切换角色，让同一个模型在同一轮调用里完成所有任务。

SYSTEM PROMPT 切换：根据对话阶段加载对应的人格描述，如「资深架构师」「经验丰富的前端工程师」等。

统一推理循环：每轮只向模型发一次请求，模型自行决定是继续追问还是直接输出结果，从而避免无休止的提问循环。

状态驱动：后端维护一个轻量级状态对象，当置信度达到阈值或轮数上限时自动进入方案生成阶段。

class UnifiedConsultantAgent:
    async def process_turn:
        persona = PERSONAS                # 根据阶段挑选 System Prompt
        result = await self.client.messages.create(
            model=self.model,
            messages=
        )
        if result.decision == "ask":
            return result.question                     # 继续追问
        else:
            return result.solution                     # 输出方案

SSE 的超时限制让我们不得不把大体方案拆成两步走：

Skeleton Phase: 在 30 秒内产出标题列表、功Neng概览、技术栈概要以及预算区间。这一步用简短 Prompt 完成，确保用户马上kan到可视化进度。

Expansion Phase: 对每个大纲项单独调用模型进行深度展开，包括系统图、数据流图以及设计原则等。每次调用dou有独立超时设置与重试策略，保证即便网络抖动也不会导致整体卡死。

⚙️ 配置示例： { "section_timeout_seconds": 120, "total_timeout_seconds": 300, "max_retry_per_section": 3, "heartbeat_interval_seconds": 10 }

SECTION_EXPANSION_PROMPTS = {
    SectionType.ARCHITECTURE: '''
你是一名资深系统架构师，请对“系统架构”章节进行详细补充。
要求提供：
- 架构类型与说明
- 完整 mermaid 图
- 部署拓扑图
- 数据流向示意
- 设计原则列表
- 可
性说明
'''
}

通过上述模板，每个章节dou会得到结构化输出，后端直接写入数据库，实现断点续传功Neng，即使中途掉线也Neng继续恢复生成。

The first prototype adopted a ChatGPT‑style free‑talk UI—用户随意输入，AI 连续提问。「我想Zuo电商 APP」→「目标用户是谁？」→「预算多少？」→……当用户Yi经回答了三四个问题仍被追问时体验急速下降。于是我们改为卡片式选项，引导用户在预设的问题库中挑选答案，同时提供简短解释，让打字负担降至Zui低。

// OptionCard 示例

🔎 小技巧：在卡片上标记推荐项并附上成本/工期影响，可帮助决策者快速判断利弊，而不是盲目填空。

A/B 实验显示，当 AI 自己评估信息收集完整度后再决定是否继续提问，比硬编码固定轮数gengNeng提升满意度。我们给每轮对话打分，累计置信度超过阈值或轮数触达上限，就立即切换到「方案输出」阶段。

MAX_ROUNDS = 7               # 防止死循环
CONFIDENCE_THRESHOLD = 0.85   # 达到此值即认为信息足够
class ConversationState:
    confidence: float = 0.0
    round_count: int = 0
# 每次 AI 回答后geng新 confidence；若满足任一条件则结束提问。

📊 前端通过进度条实时展示置信度，让用户直观kan到当前对话距离Zui终方案还有多远，从而产生期待感和控制感。

{/* Consultation.tsx */}

  #Round:{roundCount}
  #Confidence:{Math.round}%


  

从技术角度kan，“SSE + 心跳 + Persona‑based Pipeline”Yi经Ke以支撑一个完整的端到端咨询流程；从产品体验来kan，引导式卡片和置信度进度条显著降低了用户疲劳感，使得即使是非专业人士也Neng顺畅完成需求采集并得到可执行方案。因此，从原型验证到 MVP 阶段，这套系统具备了上线运营所需的关键要素——稳定性、可观测性和业务价值。

不过仍有几点值得警惕：

模型本身仍会产生错误代码或不合理设计，需要人工审校后才Neng投入生产；

Ru果要支持geng复杂的大型项目，需要进一步细化 Persona 并增加专业领域知识库；

费用控制不可忽视——频繁调用大型语言模型会迅速累积成本，建议配合缓存与结果复用策略。

综上所述，这款 AI 软件咨询工具在技术实现层面Yi基本可行，在产品体验层面也Yi达到了 MVP 水平。Ru果团队Neng够接受一定程度的人审校，并Zuo好成本监控，那么它完全值得投入进一步研发与市场验证。期待各位同行一起玩耍，一起迭代，让「说完需求 → 拿到方案」真的只剩几分钟！ 🚀