2026 年 2 月
圆桌起名产品动态(2026 年 2 月)：多老师协同起名功能实现
2 月，我们把“多老师协同起名”从一个想法，逐步打磨成了真正可运行的起名流程。
圆桌起名最早打动我们的，并不是“再做一个起名工具”，而是想把起名这件事从单点回答，变成一次真正的集体讨论。
现实里，给孩子起名往往不会只听一个人的意见。有人重视音律，有人看重寓意，有人讲究诗词出处，也有人非常在意八字五行。如果这些视角只能混在一段回答里，用户其实很难感受到其中的推理过程。
所以 2 月我们的重点，是把“多老师协同起名”这件事一步步搭起来，让不同角色真的能参与进同一次起名。
本月重点
- 拆分起名流程，引入多位“老师”分别负责审题、检索、生成、评议与收敛。
- 让每个角色先完成自己的阶段性任务，再把结果交给下一位角色继续处理。
- 补上角色协同中的上下文组织、结果去重和质量校验逻辑。
- 把原本难以解释的生成过程，整理成用户最终能看懂的起名结论和推荐理由。
先想清楚：为什么一定要多老师协同
一开始我们也考虑过最直接的方案：让一个大模型一次性读完所有信息，然后直接给出一批名字。
这种做法当然更快，但问题也很明显。它容易把“信息很多”和“推理充分”混为一谈，最后给出的结果看似完整，实际很难知道每个名字到底是怎么来的，也很难稳定复现好的过程。
于是我们决定换一种思路，不追求一次生成全部答案，而是把起名拆成若干更清晰的阶段，让不同角色各自完成最擅长的部分。
把一个复杂问题拆成多段流程
真正开始开发后，我们首先做的不是写页面，而是先把起名流程拆开。只有流程清楚，后面的角色分工、上下文拼接和结果呈现才不会乱。
- 先由总控角色理解用户输入，明确姓氏、性别、出生信息、命名偏好和避讳条件；
- 再由检索型角色补充诗词、典故、字义、读音等基础素材，避免后续生成“无源之水”；
- 接着由生成型角色基于约束条件提出候选名字，而不是脱离上下文随意发挥；
- 然后由评议型角色逐一审视候选名，从音形义、出处、风格一致性等维度提出保留与淘汰意见；
- 最后再由汇总角色把多轮意见收敛成最终推荐结果，输出给用户阅读。
协同最难的，不是生成，而是交接
多角色流程听起来很自然，但真正实现时，最大的难点其实不是“让每个角色说话”，而是“让他们说的话能被下一个角色接住”。
如果前一位角色输出得太散，下一位角色就不得不重新理解问题；如果上下文堆得太满，又会把重点淹没掉，反而影响生成质量。
因此我们花了不少时间整理角色之间的交接格式：哪些信息必须保留，哪些结论需要结构化，哪些中间思路可以压缩。只有把这些边界收拾清楚，整个协同流程才真正跑得稳。
- 统一每个阶段的输入输出结构，减少角色之间“各说各话”；
- 把用户硬约束与风格偏好分开存放，避免后续步骤误伤关键条件；
- 增加候选结果去重与归并逻辑，避免不同角色反复推荐同类名字；
- 对中间结果做阶段性校验，尽早发现不合规、不好读或偏题的候选名。
把开发过程里的思路，变成用户能感知的体验
我们并不想把 agent 相关能力做成一种“技术炫耀”。对用户来说，真正重要的不是背后有多少个角色参与，而是结果是否更稳、更全面、更像经过认真讨论后得出的结论。
- 让最终结果保留足够清晰的推荐理由，而不是只给名字列表；
- 尽量体现不同视角的综合判断，让用户能理解名字为什么被选中；
- 减少单次生成中过于随机的发挥，把重点放在可解释、可比较的候选方案上；
- 为后续接入更多老师角色和更复杂的评审标准，预留出流程空间。
2 月对我们来说，是圆桌起名真正长出“产品灵魂”的一个月。多老师协同起名不只是一个功能点，它决定了我们之后会如何持续提升起名质量。
接下来，我们会继续把这些协同能力做得更扎实，让每位“老师”的参与都不是摆设，而是真的能把结果往前推一步。
如有任何问题，请发邮件至 support@yzqiming.com，我们随时响应您的诉求。