个人博客（八）

个人博客八一、本周完成内容1.1 起点:一次产品定位的自我复盘本周我们对项目做了一次复盘,发现了一个之前没有正视的问题:我们定位的是情绪陪伴机器人,它理应像猫狗一样对主人的状态做出回应,但当前系统实际上是把一段文本(故事)交给机器人去演绎。这两件事本质上不是一回事。进一步分析后确认,我们的产品定义里其实混进了两条路线:叙事表演机器人:输入一段故事,机器人按情节生成并执行动作;面向主人的情绪陪伴机器人:主人表达一种状态,机器人识别情绪并做出回应。当前系统更准确的定位,其实是文本情绪到机器人动作的可行性验证原型:输入一段故事文本,经过分段、情绪识别、动作编排,最后通过/emotion → action_sequence → DuoS 轮询执行形成闭环。故事在这里不应该是最终交互形态,而应该只是验证管道的测试载体。基于这个判断,本周完成了三步演进,把系统从只会演故事推进到能自主判断该演故事还是该陪伴主人。1.2 第一步:新增 companion(陪伴)模式保留原有的故事演绎(story模式)作为动作编排的验证场景,同时新增companion模式。当输入来自主人的表达时,系统不再把文本当故事表演,而是:主人输入 → 识别主人情绪 → 选择陪伴意图 → 生成动作回应 → DuoS 执行接口层通过在/emotion请求中增加一个mode字段实现模式切换,默认story,不影响任何既有调用:{content:我今天好累什么都不想做,mode:companion}1.3 第二步:让陪伴回应活起来companion 模式的第一版用的是固定映射表——8 种情绪各对应一套预设动作。但很快发现,这种情绪识别 → 罐头动作的方式仍然偏死板,不像真正的陪伴:无论主人说什么,只要情绪相同,机器人的回应就完全一样。我们注意到,项目里其实已经有一个很有价值的组件:故事模式用的动作编导 LLM(ACTION_SYSTEM_PROMPT)。它理解每个动作的语义、懂物理连贯性、懂编排约束。故事模式生成的动作之所以比固定映射自然,正是因为走了这个 LLM。于是我们做了一次关键重构:让 companion 模式复用这个动作编导能力。新增了一个面向陪伴场景的COMPANION_ACTION_PROMPT(复用同一份动作清单,只替换任务描述),让 LLM 针对主人说的具体那句话生成有针对性的动作回应;而原来的固定映射表COMPANION_RESPONSE则降级为兜底——只在 LLM 调用失败、超时或返回非法时启用,保证演示稳定不崩。重构后的流程:detect_emotion 识别情绪 → LLM 针对主人原话生成陪伴动作 → 校验动作合法性(编号范围、长度、结尾归位) → 合法用 LLM 结果,否则回退固定映射表返回结构里增加了一个source字段(llm或fallback),让我们能直观看到这次回应到底是 LLM 实时生成的,还是走了兜底。这对调试和演示都很有用。1.4 第三步:modeauto,让系统自己判断交互意图前两步都还需要调用方显式指定mode。第三步把这层决策也交给系统:新增modeauto,让系统自己判断主人是在讲故事还是在对机器人倾诉。实现上,在两个模式前面加了一个轻量的意图判断层:输入 → [modeauto] → LLM 判断 story / companion → 交给对应链路判断同样用 LLM 完成(而非脆弱的关键词匹配),因为区分一段叙事和一个人在对你说话正是 LLM 擅长的。判断失败时默认兜底到 companion——这是一个有意的产品决策:既然定位是陪伴机器人,在不确定时就应该倾向于把用户当主人来回应,而不是当成故事来表演。返回里透出auto_resolved_mode和auto_reason两个字段,让评委和我们都能看到系统是怎么想的、为什么这么判断。1.5 验证结果真实 DashScope 环境下的关键验证:输入auto 判定结果“我今天好累什么都不想做”companion符合预期,生成针对性安慰回应“从前有一只小熊走进了森林深处……”story符合预期,走故事演绎链路companion 模式在真实环境下能针对不同话语生成有区别的动作序列,source为llm;断网/超时场景下正确回退到固定映射表,接口不崩。二、对用到的技术的理解2.1 稳定兜底 LLM 增强是这次最重要的工程取舍这次迭代里反复出现同一个模式:用 LLM 提供活的能力,用固定规则保证不崩的底线。companion 动作:LLM 生成针对性回应,固定映射表兜底;auto 判断:LLM 判断交互意图,失败时默认 companion。机器人只有 0–14 共 15 个物理动作。如果让 LLM 完全自由发挥,容易生成物理上不连贯、或与情绪不符的序列,演示时显得混乱。所以活不等于随机,而是针对性 合理 可控。我们通过一道动作合法性校验(编号必须在允许范围、长度 2–5、结尾必须归位到站立)把 LLM 的自由度约束在一个安全区间内,既保留了针对性,又避免了失控。这是这次最有价值的工程认知之一。2.2 复用已有能力比新造一套更划算第二步重构的核心不是扔掉旧逻辑重写,而是发现项目里已经存在一个训练有素的动作编导 LLM,把它接到新场景上。同一份动作清单,只替换任务描述(从把情节转成表演换成如何回应主人),就让陪伴回应的质量上了一个台阶。这让我意识到:在一个已经跑通的系统上做扩展,先盘点现有能力能否复用,往往比新增一套机制更稳、更省。2.3 模式分层带来的架构清晰度最终系统形成了清晰的三层:入口层(auto 判断):决定走哪条链路;模式层(story / companion):各自独立,互不干扰;执行层(动作编排 校验 DuoS):被两个模式共享。auto 作为纯入口层,判断完就交给现有链路,完全不触碰下游逻辑。这种分层让每一步改动的影响范围都很小,也让我们复盘时发现的定位问题,从一个缺陷变成了一条可以清晰讲述的产品演进路径。三、用 AI 的过程与提示词工程这次开发本身就是一次密集的人 AI 协作实践,主要体现在两个层面:用 AI 写代码,和在产品里用 AI 做决策。3.1 用 AI 辅助开发的工作流整个过程不是把需求丢给 AI 然后接受结果,而是一个人定方向、AI 执行、人审查边界的循环:先和 AI 一起厘清产品逻辑(故事 vs 陪伴的本质区别),再决定技术方案;把方案拆成边界清晰的指令交给编码 AI,指令里明确写清不要做什么(如:不要动 story 模式、不要用关键词判断、空输入不触发判断);每一轮改动后让 AI 给出 diff,再逐项审查关键风险点。这个过程里学到的一点是:给 AI 的指令越是明确边界,产出越可控。比如在写 auto 指令前,我们先核对了call_dashscope_json的真实返回结构({ok: True, data: ...})、空输入的拦截位置、字段透出的依赖条件,把这些真实细节写进指令,AI 出错的空间就被大幅压缩了。我们也踩到一个典型的坑:第一版 companion 里 AI 自作主张加了一段关键词补丁(在 LLM 判断完情绪后又用关键词覆盖),这其实是两套逻辑互相干扰。识别并移除它,靠的是人对这段逻辑为什么存在的判断,而不是 AI 自己。这说明AI 的产出仍然需要人来把关语义合理性。3.2 提示词工程:三个面向不同任务的 prompt这次在产品内部设计了多个各司其职的 system prompt,提示词工程的体会主要有三点:(1) 角色 任务 输出格式三段式。每个 prompt 都明确你是谁、要做什么、只输出什么格式的 JSON。例如情绪分类器只让它输出{emotion:...},模式判断器只让它输出{mode:...,reason:...}。严格约束输出格式,是让 LLM 结果能被程序稳定解析的前提。(2) 用特征描述代替规则枚举。在模式判断 prompt 里,我们没有给 LLM 列关键词,而是描述两种模式的特征:story 是有情节、有角色、第三人称叙述,companion 是第一人称、在倾诉、像在跟机器人对话。让 LLM 基于语义理解去判断,比硬规则鲁棒得多。(3) 同一份知识,换任务描述复用。companion 动作 prompt 和故事动作 prompt 共用同一份动作语义清单,只替换最上层的任务目标。这既保证了两个场景对动作的理解一致,又避免了维护两份会逐渐不同步的文档。3.3 关于 mock 与真实环境的认知开发中所有 mock 测试只能证明代码不崩,证明不了LLM 的判断和生成是对的——因为 mock 根本不调用 LLM,所有结果都走兜底。这个区别很容易被忽视。最终我们坚持在真实 DashScope 环境下验证了 auto 的模式判断和 companion 的动作生成,才确认核心能力真正可用。对依赖 LLM 的功能,真实环境验证是不可省略的一步。四、计划下一步扩充 auto 判断的边界场景。当前在典型输入上判断准确,但混合型输入(比如我给你讲个我自己的故事)可能介于两者之间,下一步收集更多边界 case,持续打磨模式判断 prompt。引入情绪强度。目前一句话只识别一个主情绪。后续考虑加入强度维度(轻微难过 vs 强烈崩溃),让陪伴回应的动作长度和力度也随之变化,更接近真实宠物的反应。会话记忆(多轮陪伴)。接口里已有session_id字段但尚未真正用于上下文记忆。下一步让机器人能记住同一次对话里主人之前的状态,形成连续的陪伴感,而非每句话都独立回应。真实环境的稳定性与延迟优化。auto 模式比单一模式多了一次 LLM 调用(意图判断),会增加响应延迟。后续评估是否需要对判断层做缓存或更轻量的处理,平衡自主性和响应速度。五、小结这次复盘没有否定我们已有的工作,而是帮我们厘清了一条更清晰的演进方向。这一周,我们把系统从文本情绪到动作的可行性原型,一步步推进到:能基于主人情绪做出针对性陪伴回应、并能自主判断交互意图的机器人。更重要的是,这次迭代让陪伴感从一句口号,变成了代码里可以指着说清楚的具体机制——它现在能分辨主人是在讲故事还是在倾诉,并切换到对应的回应方式。这比单纯说我们有情绪识别要扎实得多。