先说个真实感受Day01装完环境、跑通第一个大模型接口的时候整个人是兴奋的但那股兴奋劲儿退得也快。因为装OpenAI SDK也好调通一个你好世界也好距离我能做出个有用东西还隔着很大一段。很多自学AI应用开发的人就卡在这个位置——环境不是问题问题是下一步干嘛。我给自己定的Day02目标很朴素不碰那些花里胡哨的算法原理先做一个别人真能用的、带交互的、有实际输出价值的AI应用。这篇就记录我第二天踩过的路、做的选择以及最后搭出来的那个小东西的全过程。如果你也处于装完环境但不知道从哪下手的阶段这篇应该能帮你省不少时间。1. Day01之后为啥要停一下先想清楚第二天到底学什么1.1 别急着写代码先定义可见的成果我见过太多自学AI开发的人第一天装环境、拉仓库、看文档第二天就开始啃Transformer论文第三天就放弃了。原因很简单没有阶段性反馈。人不是机器不能靠为未来打基础这种空头支票撑三个月。Day01结束时我的状态是OpenAI的API能调通了本地Python环境能跑了也搞明白了给模型一段文本、模型返回一段文本这个基本链路。但我很清楚这点东西离应用还远得很。所以Day02我做的第一件事不是打开某个教程而是给自己写了一条任务卡我要做一个带聊天界面的小应用不要求代码多高级但用户能通过它和AI对话它必须能解决一个具体场景的问题而不是随便聊聊它要能发布出去让不在我电脑上的人也能访问这条任务卡的价值不在于目标多宏大而在于它把学习变成了做一个能验收的东西。人一旦有了验收标准注意力就自然聚焦了。1.2 为什么Day02我从智能体工作流切入而不是继续写代码这是个值得展开说的选择。主流的学习路线通常有两种一种是纯粹从代码入手学LangChain、学LlamaIndex、学各种框架另一种是先用可视化平台把整体概念建立起来。Day02我选的是后者——先接触平台型工具用工作流的方式搭一个AI Agent。原因其实很实际。纯代码路线在一个新手那里最大的问题是你根本不知道哪些代码是必要的。一个简单的对话应用用LangChain写可能要几百行中间涉及记忆管理、工具调用、回调机制等概念。你花一周时间写完了但脑子里的地图还是碎的。而可视化平台的每个节点都对应一个明确的概念输入、大模型处理、条件判断、知识库检索、工具调用你拖一遍流程整个架构就长在脑子里了——之后再去写代码你知道每一行是在干什么。另外一个现实的理由现在是2025年了智能体应用AI Agent已经是AI应用开发的核心形态而平台型工具是目前门槛最低的Agent落地方式。我用的是Coze扣子平台来做的这次实践同类平台还有Dify、百度智能体平台、阿里百炼等思路大致相通。先把Agent能做什么、有哪些组件搞清楚比第一天就钻进代码里要高效得多。1.3 今天结束前要能回答四个问题给自己定可验收目标之后我又列了四个理解性问题——都是今天必须能用自己的话回答上来的一个智能体应用由哪些基本部分组成提示词、模型、工作流、知识库、工具、记忆我写的提示词Prompt到底是怎么影响模型输出的工作流里的节点是什么概念多节点串联解决什么问题一个应用从做出来到发布出去中间要过哪些关这四个问题看着基础但回答不上来后面的所有进阶内容都会是空中楼阁。我的习惯是每天的学习必须能产出你能讲给别人听的知识讲不出来就是没学会。2. 平台选型与准备把时间花在刀刃上2.1 主流AI应用开发平台横向对比市面上的AI应用开发平台本质上都在做同一件事把接大模型、写提示词、串流程、搞知识库、接工具这些重复劳动封装好让你专注于应用逻辑本身。但每个平台的侧重不太一样我对比了这么几个平台特点适合谁我的印象Coze扣子国内版可直接用插件生态丰富有独立的Bots商店发布渠道多支持小程序、API、WebApp等字节跳动出品新手从零到一、想做C端应用上手快节点类型覆盖全国内外双版本Dify开源友好本地部署能力强面向ToB/私有化场景有技术基础、重视数据私有化更适合团队协作自己部署有一定门槛百度智能体平台百度系模型驱动文心一言生态国内用户、想借百度分发渠道模型绑定较紧灵活性一般阿里云百炼阿里云体系企业级服务成熟企业客户、已用阿里云偏B端个人玩稍重我没在这里花太多时间纠结。一个判断原则新手阶段选平台第一看上手成本第二看能不能平滑过渡到下一步。Coze对新手最友好的点在于——拖拽式工作流、内置调试工具、发布成一键链接这三个特性直接把从想法到可分享的作品的路径压缩到了最短。我身边不少搞产品、运营出身的朋友都是从这个平台跑的第一次Agent实践。2.2 注册与基础配置有哪些容易忽略的细节注册账号这种事就不赘述了说几个实操中容易忽略的点。第一模型选择别默认走推荐的第一个。Coze里创建Bot的时候会让你选模型默认推荐的往往不是最优解。我的做法如果应用偏中文场景优先用国内模型比如豆包、Kimi、通义千问响应速度和中文语感通常更好如果是做需要强推理、长文本的任务再加Claude或GPT系列。Day02我选的是豆包系列模型因为我的测试场景是中文生活类问题实测中文指令理解度和生成自然度都够用。第二工作区概念要提前搞清楚。Coze分为个人空间和团队空间个人玩的话不用纠结直接个人空间就行。但资源的组织方式会影响后期维护——我建议从第一天就按应用类型建Bot而不是把所有实验塞在一个Bot里反复改。我一开始就是在一个Bot里改来改去结果Prompt调乱了都不知道是哪个版本改坏的。第三调试台Preview/Debug是你最该常驻的地方。每个平台上都有一个预览/调试入口在这里可以直接模拟用户输入、看完整执行日志。很多人做完应用就顺手关了调试台完全浪费了这个最重要的学习工具——它能让你看到每个节点实际收到了什么、输出了什么比任何文档都直观。2.3 免费额度和模型消耗的心算逻辑做实验型应用的时候成本心态要摆正。大模型API是按token计费的1token大约相当于0.75个英文单词或0.4-0.5个中文字符。平台一般会送免费体验额度我查了一下Coze国内版的免费策略个人开发者在额度范围内基本够用但要注意每次对话都会消耗 tokens包括你的输入用户问题历史记录提示词和模型的输出如果应用里接了知识库和多个模型节点一次用户请求可能触发多个模型的调用消耗会叠加调试阶段产生的消耗可能比正式运行时更大——因为你会不停试错我的经验是调试时如果想控制成本可以在交互时把对话历史长度调小或者在提示词里明确不要输出多余的解释。还有一个小技巧——把能一次算完的步骤合并不要把一个任务拆成三四个模型节点串行调用。串行调用不仅是消耗问题还会让错误在节点间累积和放大这是初学者最容易犯的架构级错误。3. Prompt工程第一课让AI的输出从像样到可控3.1 从废话输出到结构输出写Prompt的四步法如果说Day02我只能带走一样东西那一定是怎么写Prompt。原因很简单模型的能力是固定的在选型确定后你的应用好不好用80%取决于提示词的质量。你可以把Prompt理解成给一个新来的实习生写开工说明——说得越清楚活干得越靠谱。我自己总结的四步法到现在还在用定角色明确告诉模型你是什么、你在什么场景下服务谁派任务用一句话说明用户这次要达成什么目标立规矩列出必须遵守的约束条件输出格式、长度、语气、不能做什么给示例提供一组输入输出的样例告诉模型照着这个标准来这四步缺一不可。我见过太多人写Prompt就是一句话帮我推荐杭州好吃的——这种Prompt拿到的结果本质上是模型在猜你想要什么输出飘忽不定是必然的。你需要的不是让模型自由发挥而是让它在你的框架里发挥。3.2 一次对照实验同一需求两种写法我说个当天的实际对照实验非常能说明问题。需求是做一个城市美食推荐助手。第一种写法我管它叫随缘版帮我推荐杭州的美食。模型输出一段四平八稳的文字列举了西湖醋鱼、龙井虾仁、叫花鸡末尾又问你想了解更多吗——完全不可控也没有任何可交互的结构。第二种写法四步法你是杭州本地生活专家熟悉杭州大小馆子和街头小吃擅长根据游客的口味偏好和行程安排给出个性化推荐。 用户会告诉你ta在杭州哪个区域、想吃什么口味、预算大概多少、同行几个人。 你的任务是推荐3个合适的餐厅或小吃摊要求口味地道、位置合理。 输出必须严格按以下格式 - 推荐名称 - 推荐理由50字以内说清楚为什么适合这位用户 - 人均消费 - 温馨提示营业时间/排队/隐藏菜单等 语气轻松友好不要用过于书面的表达。如果用户给的信息不够主动追问最多两轮不要直接假设。同样的模型输出完全是另一回事——结构清晰、针对性强、信息密度高而且因为允许主动追问对话的体验就立起来了。这个对照实验给我的冲击很大。它证明了一个关键认知AI应用开发本质上很大一部分工作量在定义清楚问题而不是实现功能。你把Prompt写清楚的过程就是你在替AI把用户的问题想清楚。3.3 温度参数与输出格式模型参数里的小学问除了Prompt内容本身模型参数也会显著影响输出质量。平台里最常调的参数是温度Temperature它控制模型输出的随机性。温度低0-0.3输出稳定、保守、更贴近事实适合做客服、知识问答、结构化输出温度中等0.3-0.7平衡创造力和稳定适合大部分日常应用温度高0.7-1.5输出更有想象力、更发散适合写文案、故事、头脑风暴我做美食推荐助手用的是0.3-0.5这个区间因为推荐类任务需要逻辑稳定但我在Day02还顺手做了一个一句话生成小红书标题的实验那个我把温度调到了1.2出来效果明显更跳、更有网感。同一个模型参数一变风格天差地别——这个知识点不实操一次很难记住。还有一个容易被忽略的输出格式约束尽量放在Prompt里面不要只依赖模型自觉。如果你要JSON格式、要固定字段直接在提示词里给模板并加上只输出JSON不要解释这种强约束。在Day02的工作流实践中输出格式的设计直接决定了后面条件分支能不能有效工作这个后面细说。4. 亲手搭一个能回答问题的智能体Day02主项目全流程4.1 需求拆解从想要的功能翻译成节点前面做的都是准备功夫Day02的核心项目是在Coze里搭一个城市漫游助手——用户输入我在XX城市有X天时间喜欢人文/美食/自然应用输出一份完整的行程建议。为什么选这个题目因为它天然有层次感需要处理用户输入、需要基于城市信息做推理、需要给出结构化输出、甚至可以做条件分支不同兴趣推荐不同路线。刚好能把工作流的常用节点全部覆盖。刚开始用平台的时候最关键的思维转换是不要想我要写什么功能而要想数据是怎么流经我的应用。我把这个需求拆成了四个节点开始节点接收用户的原始输入城市、时间、兴趣偏好大模型处理节点把用户的零散输入整理成一个标准化的需求解析结果条件分支节点根据兴趣类型走不同的推荐逻辑美食线/人文线/自然线结束节点把最终结果按固定模板输出你看这个过程其实是在画一张数据流程图。这也是为什么我前面强调——如果一上来就写代码你很容易陷入调用API、处理返回的细节里反而看不清全局。平台的工作流就是帮你把架构先画出来。4.2 开始节点与输入变量别让用户对着空气说话工作流的第一步是开始节点它定义了应用接收哪些输入。这里我踩了一个典型的新手坑一开始我只设置了一个整体输入字段想着反正用户会打字AI自己理解。结果用户说的话五花八门——有人直接说成都3天2晚有人说我想去有海的地方预算5000还有人说杭州两人带老人小孩。这时候一个大模型处理节点根本忙不过来因为它要从乱七八糟的文本里猜哪些信息是必须的、哪些是次要的。正确做法是在开始节点里定义结构化字段比如城市天数兴趣类型预算然后在界面上生成对应的表单或分组引导。这也是我第一次理解产品思维在AI应用里的价值——你给用户的输入结构越清晰模型理解得越准输出就越可控。换句话说AI的智能是要靠产品设计来托底的。所以我的开始节点最终设了四个变量city城市、days游玩天数、interests兴趣标签多选美食/人文/自然/购物、budget预算档位经济/舒适/奢华。每个变量都写了提示说明用户填的时候就知道该给什么。4.3 大模型处理节点把理解需求这步单独做成一个环节工作流里最核心的就是大模型节点也就是LLM节点。我在Day02里跑了两个大模型节点第一个负责需求解析第二个负责生成行程。先说第一个节点。它的输入是开始节点传来的四个变量任务是输出一段格式化的需求理解比如用户计划成都4天3晚偏好美食人文预算舒适档。 分析美食推荐可侧重川菜、火锅、小吃人文路线可覆盖杜甫草堂、武侯祠、宽窄巷子等考虑到预算舒适档住宿推荐定位在300-600元/晚的精品酒店或特色民宿。这个节点本身不直接给用户看它的价值在于把用户的零散信息转换为一个标准化的中间结果后面的逻辑节点才有依据去判断。这一步很多人会跳过觉得直接生成行程不就完了——但实践下来我发现拆一步理解需求再生成答案模型的准确率明显更高。原因也不复杂模型先思考整理一轮再进入方案设计状态比一步到位更接近人的工作方式。第二个节点才是正式的行程生成。它的Prompt我用了前面说的四步法并且把第一个节点的输出作为输入变量引用进来格式模板也提前在提示词里给好。输出结构大概是Day1 抵达城市初体验 Day2 主题深度游美食/人文线 Day3 周边半日/一日游 Day4 返程前采购总结每个部分下面固定带推荐地点理由交通建议预算参考四要素。我特别要求它每天最多推荐3个地点避免列一堆看起来丰富、实际上根本走不完的假行程。4.4 条件分支与结束节点让应用学会按情况说话接下来是条件分支节点。这是让我觉得哦Agent真的有点智能了的关键节点。条件分支的逻辑读取第一个大模型节点输出的兴趣类型字段如果包含美食走美食深度推荐分支如果包含人文走人文路线分支如果两个都有走组合路线。我问过自己为什么不直接在第二个大模型节点的提示词里让模型自己判断非要单独设一个分支节点答案是用逻辑节点做分流比让模型自己判断更稳定。模型自己判断本质上是概率事件同样的输入可能有几次就漏了条件而条件节点的规则是确定的只要输入字段里匹配到关键词就必然走对应分支。在生产环境里AI偶尔抽风是不可接受的所以凡是能用规则解决的问题都应该用规则来解决——这算是我Day02学到的一个架构原则。最后是结束节点。有些平台叫输出节点作用是把前面节点产生的最终结果返回给用户。这里有个细节不是所有节点都要接到结束节点上只需要把用户真正关心的最终结果显示出来。你可以把结束节点的输出格式定义成Markdown文本或富文本我在里面放了加粗标题、小标题和列表实测在Web端展示效果不错。到这里第一个能验收的智能体应用就完整了。整个过程不写代码但你会清晰地看到输入怎么进、文本怎么被处理、规则怎么分流、结果怎么出——这个看见数据流动的感觉比看十篇教程都值。5. 跑通只是起点调试、验证与迭代5.1 边界测试清单把用户可能输入的歪情况都试一遍第一次跑通的时候我很兴奋但马上意识到一个问题我只测试了用户规规矩矩给足信息的情况。真实用户不会这么乖。如果你打算把应用发出去让别人玩你至少要测下面这些边界场景用户只给了城市没给天数应用要怎么追问用户给了超出预期的信息比如不相关的闲聊应用是忽略还是要处理用户输入的城市比较冷门比如一个县城模型会不会一本正经地编造景点用户兴趣类型不在预设选项里比如我想去钓鱼用户一次性输入了很长一段话超过了模型上下文限制我建议把这些场景提前写成一条测试用例清单逐个跑一遍。每跑一条就做一次Prompt微调。我在这个环节花了一个多小时成果非常值得——后来朋友试用的时候明显感觉到这个应用比我想象的懂事因为边界情况都被提前处理过了。5.2 最常踩的四个坑与排查思路实操中肯定会遇到问题我Day02就撞上了几个典型的这里把排查思路也一并写出来。坑一多个大模型节点之间输出格式脱节。第一个节点输出的需求理解我没有规定格式导致第二个节点拿到的输入五花八门偶尔还带上模型的废话。排查思路在第一个节点的Prompt里明确要求只输出JSON格式字段定死为{city, days, interests, budget, analysis}第二节点解析就稳定了。核心教训节点之间传输的数据要有契约Schema不能靠模型自由发挥。坑二条件分支永远走不进去。我最初在条件分支里判断关键词美食时发现怎么匹配都进不了对应分支。查日志后发现问题出在前置节点输出的是想吃的东西包括火锅和串串根本没有美食这个字。这是个语义标签和字面匹配的矛盾。解决方案让第一个节点在输出时增加一个标签化字段明确打上classification: food / culture / nature条件分支匹配这个字段而不是匹配原文。坑三模型幻觉地点。用户输入一个冷门城市时模型为了显得专业会编造景点。排查后发现因为我们的应用里没有挂任何知识库模型完全依赖训练记忆。要想回答准确要么选用对地域知识有专门优化的模型要么给它接入搜索工具或知识库这一步我留到Day03再深入。至少当场我可以做的是在提示词里明确写如果不确定的景点信息请明确回答该地点信息未核实不要编造这能减少大部分幻觉。坑四对话历史导致越聊越乱。做智能体的时候平台默认会保留上下文记忆但记忆不总是好事。用户在聊行程安排时顺便问了一句今天杭州天气怎么样模型会把天气话题也记进上下文影响下一步推荐。排查结论这个应用的核心任务其实不需要长期记忆我在配置里把记忆策略调成了只保留当前对话轮的上下文会话一旦结束就清空。如何设计记忆策略是AI应用开发里很值得单独研究的一节课Day02先知道这件事存在就够了。5.3 发布与数据观察让应用开始被真实使用调试通过之后我做的最后一件事是发布。Coze平台发布成WebApp非常快生成一个链接就可以发到群里让朋友试。虽然只是一个小应用但当第一个人真的通过链接试用它的时候那种我做的东西被用起来了的感觉确实很不一样。发布后我还做了一件事观察使用数据。平台后台能看到对话量、用户分布、甚至每次对话的具体内容。我重点看两类信息一是用户真实问法和我预设的问法差多远这决定我要不要在开始节点补充更多示例引导二是哪些对话让用户中途离开了通常意味着输出没满足预期。这算是用用户反馈驱动迭代的启蒙一课。Day02结束时这个应用大概迭代了五轮第一轮是能跑第二轮是输出格式美观第三轮是边界问题修复第四轮是加记忆策略第五轮是发布后根据朋友意见做的小调整。你会发现开发一个AI应用跟产品迭代的逻辑是完全相通的——先做出来再改到能用再改到好用。这个节奏本身就很重要。6. 第二天的学习复盘与下一步6.1 今天学到的东西放在AI应用开发地图的哪个位置很多人学习AI开发会陷入知识点焦虑觉得要会的太多了。为了不被信息淹没我自己建了一个简化版的AI应用开发能力地图基础层大模型API的调用与参数理解Day01已摸到编排层Prompt工程、工作流设计、多节点串联Day02核心记忆层上下文管理、会话策略、向量数据库后续能力层工具调用让AI去查天气/订机票、知识库RAG让AI回答私有/实时知识产品层界面设计、发布渠道、数据分析、迭代机制这么一梳理Day02的工作就清清楚楚了编排层是主战场Prompt工程是辅助技能产品层算是初体验。这样安排的好处是以后每学一个东西我都知道该把它挂在地图的哪个分支上不会学了后面忘了前面。6.2 Day03我准备怎么继续走对我来说Day02最大的遗憾也是最好的下一步线索是这个城市漫游助手不能获取实时信息也不能调用外部服务。模型告诉用户建议坐地铁去灵隐寺但它不知道今天灵隐寺是不是闭馆、地铁是否正常运营。所以Day03的方向我已经定了给Agent接上工具和知识库。具体想做两件事一是通过API工具接口让Agent具备搜索实时信息的能力二是把一份城市游玩知识库接入应用让回答不再依赖模型的通用记忆。如果你也在走类似的路线可以参考这个推进节奏工作流能力 → 工具调用能力 → 知识库能力一层层往上接每个阶段都有清晰成果不会摸黑。6.3 一点过来人的心里话学AI应用开发这件事最大的敌人不是难度而是没有反馈的枯燥感。Day02我最大的体会就是一定要把学习任务设计成可验收的项目——哪怕它很小哪怕它很多地方不完美但当你把一个链接甩给朋友、朋友说哎这个挺好用的时候你就有动力继续学下去了。而且我越来越觉得AI应用开发并不是纯粹的编程问题。它一半是怎么把需求定义清楚另一半是怎么把AI的能力约束在可靠范围内。这两件事Day02里都有实打实的体会——从写Prompt到设计工作流的每一步本质都是在替AI划清边界、指明路径。最后分享一个我的小习惯每天学习结束后花10分钟把当天的探索过程包括踩坑写成一段简短记录不用很长但要写到如果重新来一遍我会怎么做得更快。这个习惯帮我省了很多重复踩坑的时间。Day02的这篇复盘就是这个习惯的产物。你如果也在学AI应用开发建议也试试——写下来的过程本身就是一个把知识内化的过程。