阿哲_Design手记

说实话你这问题大概率不是chunk或embedding的锅，是生成环节压根没给模型发挥空间。我试过把检索结果拆成“事实+建议”两段塞prompt里，让模型必须基于事实补一句人话，效果立竿见影。另外gpt-3.5-turbo本身就不太擅长自由发挥，换个带温度调节的推理模型试试，或者干脆在系统层加个规则，检测到纯数据类答案就自动追加一句场景化提示，比如天气就随机挑个“记得带伞”或“适合穿外套”。产品经

把项目里封装的组件路径和props直接贴进prompt，再指定“不准用antd”，基本能少改一半。 先给AI一个“你是我们组前端”的角色，然后丢一段现有代码当参照，比光说技术栈管用。

说白了就是你把AI当外包使，没当结对搭档，关键设计还得自己拿主意。 CR那关其实是人过的，AI背不了这锅，代码得自己嚼碎了再咽。

说实话你这情况我太熟了，之前搞数据清洗Agent也踩过同样的坑。核心问题在于大模型天生是概率推理，你越用自然语言强调顺序，它越容易把步骤当成“建议”而非“硬约束”。我后来试了个土办法，把每一步的输入输出都定义成严格的JSON格式，比如让它在第一步只输出schema分析结果，第二步必须基于这个schema字段去操作，这样中间任何一步跑偏，下一步的输入校验就会直接报错，它想编规则都编不出来。另外你提到

这俩根本不冲突，检索喂料是上限，提示词决定你榨出多少，先调chunk_size把底子打好再谈优化。

这问题我前两天刚踩过坑，RAG和长期记忆本质是两种东西，一个管知识检索，一个管状态更新。我现在的做法是拆两个collection，一个放知识文档，一个放用户偏好，偏好那边单独加个userId字段做过滤，召回时只查对应用户的条目，不然确实容易串味。你全塞一起的话，建议至少按对话session或者用户ID做partition，元数据里把场景标签（比如偏好、事实、事件）也加上，查询时用where条件先筛

这问题我太熟了，前段时间自己搭的Agent从三个工具加到五个，直接崩成筛子，一度也怀疑是prompt写得菜。后来踩了一圈坑，发现几个关键点： 第一，工具描述的组织顺序确实有影响，但不是玄学。LangChain底层调LLM时，工具列表是拼接进system prompt的，如果你的描述里参数名、返回值格式写得太啰嗦，或者把关键信息（比如工具适用场景）藏在后面，模型就容易混淆。我自己的经验是给每个工具