回答更详细，也要有更多依据
放宽字数限制能改善过于简单的回复，却不能凭空增加信息。怎样让回答从一句概述变成有层次的解释，同时避免重复、模板与未经支持的细节。
向下阅读
“回复有点简单”是一条具体但没有直接参数的反馈。用户可能想看更多背景，也可能需要一个例子，或者希望知道从哪里继续阅读。把最大字数加倍，只改变了容器大小，并没有决定里面应该装什么。
Field Agent 早先把回答控制在约 200 个汉字，很多问题因此被压缩成一段概述。这个限制确实应该放宽，但放宽之后，还要确定更详细的回答如何保持有用。
先分清问题要哪种深度
“作者是谁”与“详细介绍作者的技术方向”是两种问题。前者需要尽快建立认识，后者需要展开能力之间的关系。如果两种问题都回答成同样长度，简单问题会显得啰嗦，复杂问题又可能仍然没有触及重点。
一个更合适的默认策略，是先给直接答案，再根据问题展开几个相关方面。介绍类问题可以解释定位、主要内容和阅读入口；技术说明可以交代过程、取舍与约束；推荐文章可以说明推荐原因，而不是只报标题。
这些方面应该由问题决定。每次都套用“背景、优势、场景、总结”的固定结构，会让一些本来很直接的问题显得像产品宣传。结构的价值是降低理解成本，不是证明回答足够完整。
字数是一条建议，不是一项成果
当前提示词允许介绍、解释和推荐在资料充分时展开到约 300–600 字，明确要求详细时可以更长。这个范围只是控制阅读负担的参考，不是要求模型每次凑到下限。
如果只有一段公开的项目简介，回答就应该承认资料能支持到哪里。把一句简介换成四种表达，再加几段通用意义，看起来更长，却没有多给用户任何可核对的信息。
真正增加信息的方式，是补足资料。作者介绍除了简短自述，还应收录公开的 Agent 工作流和全栈能力说明。这样，回答才能具体区分检索、工具调用、界面、服务端和交付等方向，而不是反复重复“关注 AI 与全栈”。
细节还需要保留归属
资料越丰富，越要分清一项描述属于谁。作者页面列出的技术能力，不等于每个项目都已经实现了这些功能。把“熟悉多 Agent 编排”写成“这个项目已经完成多 Agent 自动协作”，会让回答从整理资料滑向替项目补成果。
所以更详细的解释，也应该保留主体、范围和状态。是作者的能力，还是具体项目的实现？是本地验证，还是生产开放？是一个尝试方向，还是已经完成的功能？这些区别往往比再增加几个技术名词更有价值。
没有公开的个人信息同样不能从其他字段推断。网站名称不是作者真实姓名，技术角色也不说明性别或工作经历。用户没有询问这些缺失信息时，不必在结尾逐项列出不存在的资料；把已有依据讲清楚就够了。
用层次让长回答容易读
流式输出让文字提早出现，但段落仍然需要组织。开头先回答核心问题，后面用短段落或少量小标题展开，每一段只承担一个重点。用户可以在答案尚未结束时，就判断它是否正在回答自己的问题。
来源也应方便继续阅读。正文去掉编号标识后，下方仍保留文章标题卡片。读者不需要在句子之间寻找数字，就可以从回答转到对应的实际页面，查看更完整的内容。
更详细的回答不一定需要更热情的措辞，也不需要每次都附上一句追问。判断标准很朴素：相比原来的一句话，用户是否多理解了一层关系，多知道一个具体做法，或者更清楚下一步可以看什么。