做过对话类前端的应该都有体会：同样一个回答，"转圈三秒一次性蹦出来"和"像打字机一样一个字一个字冒出来"，用户的感知体验差一大截。后者哪怕总耗时更长，也显得快、显得它在"思考"。这就是流式输出（streaming）的价值。我给一个产品里的咨询助手接前端时纠结过：到底要不要做流式。结论是——只要交互稍微正经一点，就该做。

成员上传的头像大小差很多，列表滚动有点卡，后来做了压缩。把中文需求写成可操作的小程序：成员申请、资料编辑、按城市筛选、联系方式授权、管理员审核。我验收时用了四个测试账号：普通成员、隐藏联系方式的成员、管理员、已冻结成员。我先给答案：校友通讯录适合用 AI 快速生成，但姓名、公司、手机号一股脑公开，肯定会出问题。我最近帮一个 60 多人的行业校友小组整理通讯录，页面两小时就能看，真正花时间的是四条权

很多人治"大模型瞎编"，是头痛医头——这答错了改一下、那答错了再补一句。治标。想真正解决，得先明白它会编。

正经做法是把长文档拆开,分段处理,再汇总。分段(map):把七万字按章节切成十几段,每段单独总结成一小段要点。汇总(reduce):把这十几段小要点拼起来,再让模型基于这堆要点,提炼成最终一页纸。这样每一步喂给模型的内容都在窗口范围内,谁也不会被截断。

挂 MCP Server 这事，配通了很爽，配不通能折腾你一下午。我前阵子接了七八个第三方 MCP，总结下来真正坑人的就两块：鉴权和超时。其它的报错都好查，这俩特别容易让你怀疑人生。先把坑摆出来。

很多人治"大模型瞎编"，是头痛医头——这答错了改一下、那答错了再补一句。治标。想真正解决，得先明白它会编。

单个 Agent 有个老毛病：它对自己的错误没有感知，瞎编了也一脸自信。我做一个要求比较严的问答场景时，被它一本正经的错误答案坑过几次。后来试了个法子：让两个 Agent 分工，一个负责答、一个专门挑错，准确率明显上来了。记一下。

单个 Agent 有个老毛病：它对自己的错误没有感知，瞎编了也一脸自信。我做一个要求比较严的问答场景时，被它一本正经的错误答案坑过几次。后来试了个法子：让两个 Agent 分工，一个负责答、一个专门挑错，准确率明显上来了。记一下。

组里有个老需求：大家总在飞书群里问"上次那个发布流程文档在哪""测试环境账号是啥"，每次都得有人捞一遍。我想干脆搭个能回答这些的机器人挂群里，谁问它答。动手前我以为得起个服务、写 webhook、维护一套会话状态。后来发现没必要那么重。我先用一个能零代码配智能体的平台（）把问答这块搭出来，再走它自带的发布渠道直接接到飞书，省掉了自己搭服务那一层。