Android开发转AI Agent：第3天——同一行代码换一个system prompt，LLM能变成三个人

作者一位Android开发工程师 | 2026年5月29日系列第2天已掌握temperature/max_tokens本篇拆解system prompt前言前两天我学会了调temperature和max_tokens但它们控制的是LLM的输出行为——稳不稳、长不长。今天要学的system prompt控制的是LLM的人格——它是谁、该怎么说话、有什么规矩。这就好比同一个Android Activity通过Intent传入不同参数展示的UI完全不同。实验一同一问题三个人设问题我的 Android App 启动很慢怎么办三套system prompt# 人设1技术专家{role:system,content:你是资深Android性能优化专家给可执行的步骤和代码。不要泛泛而谈。}# 人设2产品经理{role:system,content:你是产品经理从用户体验角度分析。关注用户留存率和转化率用数据说话。}# 人设3新人导师{role:system,content:你是耐心的技术导师用通俗比喻解释。回答不超过100字。}回答对比技术专家节选//在 onCreate() 方法中避免耗时操作。延迟加载非必要资源newHandler().postDelayed(()-{// 加载非必要的资源});→ 给了具体步骤和Java代码技术方案清晰。产品经理节选启动速度影响用户留存率和转化率。 使用 Firebase Performance Monitoring 收集启动时间数据。 收集用户反馈了解用户对启动速度的感受。→ 谈数据、谈指标、谈用户感知一个字不提代码实现。新人导师完整回答把你的 App 想象成一个餐馆启动慢就像顾客进门后要等很久才能点菜。 减少开门时的准备工作比如提前准备菜单优化代码 或者减少顾客一进门就要做的事情延迟加载不必要的功能。 这样App启动就会更快→ 没有任何技术术语用餐馆点菜的比喻把问题讲清楚了。同一个API同一个问题只改了一行 system prompt。输出从代码变成指标报告再变成生活比喻。实验二控制输出格式如果把system prompt改成格式约束LLM会老老实实按要求输出{role:system,content:只返回JSON。格式{原因:[...],方案:[...]}。不要输出其他任何内容。}输出{原因:[应用资源加载过多,主线程阻塞,不必要的初始化操作],方案:[优化资源加载延迟加载,使用异步任务,减少启动时初始化]}这是标准合法JSON可以直接被json.loads()解析。同时用表格格式也能完美输出原因影响解决方案应用体积过大启动时间延长减少资源优化图片过多的初始化启动时阻塞延后非必要初始化主线程阻塞渲染时间增加使用异步任务后面Agent需要返回结构化数据时就靠这种system prompt控制。实验三约束行为加三条不同的约束观察LLM的服从程度system prompt回答行为你是Android开发助手正常推荐方案可能涉及第三方库绝对不要推荐任何第三方库或框架只给原生方案全部给原生Android方案一个库名都没出现回答任何问题之前必须先反问用户一个澄清问题只反问了一句根本没回答问题第三条最值得注意——约束太强LLM被不许回答问题直到反问这个规则卡死宁可什么都不答也不敢违反规则。这让我想到一个重要的教训写system prompt就像写代码规范太松没效果太紧反而不干活。后面写Agent行为准则时这一点会反复出现。动手练习换成真实工作问题把问题改成RecyclerView滑动卡顿怎么优化三种人设再跑一次技术专家setHasFixedSize(true)、ViewHolder重用、布局扁平化产品经理淡滑动体验影响留存的、建议禁用ItemAnimator减少绘制开销新人导师车太重就开得慢清理重物、选平坦的路三个答案各有价值——如果我要说服老板做性能优化PM那个版本的措辞比技术版有效得多。今天的一句话总结system prompt是LLM的角色设定——你是XXX专家控制人设只输出JSON控制格式绝对不要XXX控制行为。这是Agent行为准则的雏形。下一篇预告第4天多轮对话——LLM没有记忆它是怎么记住上下文的答案出奇简单。本系列记录一位Android开发者转行AI Agent的完整学习过程欢迎关注交流。