100天前我给自己定了一个不大不小的目标从一个只会用AI聊天的萌新变成能独立开发、部署AI应用的人。当时我的日常工作主要围绕Oracle数据库展开写SQL、调存储过程、处理夜维任务。说实话模型、参数、微调这些词我听过很多但从来没认真上手过。真正刺激到我的一次是看到一个平时话很少的同事用一款AI编程工具在半小时内把一个纠缠了我一整天的数据处理脚本改成了结构清晰的版本。他并没有用什么高深技巧只是会描述问题、知道验证结果、敢让AI改代码。那一刻我突然意识到AI能力已经不再是“锦上添花”它会直接改变程序员的工作方式。于是我用100天做了一场实验。这篇文章是实验结束之后的复盘包括每个阶段该练什么、最容易放弃的点在哪里、哪些被高估、哪些被低估以及如果你想复刻应该从哪一步开始。1. 先搞清楚这100天到底要练什么很多新手学AI的第一个动作是收藏一份深度学习路线图然后从线性代数开始看。这个路径对科班学生也许成立但对一个白天还要写业务代码、只能靠晚上和周末学习的人来说几乎注定失败。原因不是内容太难而是反馈周期太长。你花了两周推导梯度下降仍然看不出这和“做一个问答应用”有什么关系动力就会在被业务需求切割的碎片时间里迅速消耗光。我的做法是反过来先定义100天结束后我手里要有什么作品再反向拆解需要练什么。这跟做项目一样先定验收标准再定开发计划。1.1 第一步不是推导公式而是定义一批看得见摸得着的终点我给自己定的终点是三个递进的小项目能用一个大模型API完成一个真实业务场景的文本分类或信息提取任务结果要能被程序读取比如输出JSON或结构化文本。能在本地完成一个“文档检索—召回—问答”的RAG应用并以HTTP接口的方式暴露出来让另一个程序或页面能调用。能把这个RAG应用部署到服务器设计一组评测问题记录答案质量并处理常见的超时、空回复、答非所问问题。这三个项目都不要求推导模型公式但都会逼着你接触Prompt、API、上下文窗口、向量检索、部署、日志、异常处理这些真实工程问题。等这些坑趟过一遍之后再回头去看Transformer、注意力机制这些概念我的实际体感是理解成本会低很多因为你已经知道每个模块在解决哪个环节的问题。1.2 用三张清单管住学习范围我强烈建议新手给自己建立三张清单避免陷入教程沼泽必懂清单必须能用一句话说清的工具或概念比如“Cursor是AI编程助手我用它辅助写代码”“RAG是先检索再生成的问答框架”。必跑通清单必须亲手完成的动作比如“调用一次模型API”“把回复解析成JSON”“部署一次模型服务”。暂缓清单当前阶段不用碰的深水区比如“自己训练一个大模型”“微调开源模型”“写自定义算子”。这个划分的价值在于它会不断提醒你AI开发本质上还是软件开发先能在已有模型和工具上做出可靠产品再考虑更底层的事情。对多数应用开发者能把一个开源或云端模型稳定地用起来并管住它的边界已经比纯调API的高谈阔论有价值得多。1.3 心态上需要提前接受三个事实第一个事实你会频繁遇到“昨天能跑今天突然不行”的情况。这不是你笨而是模型服务、依赖版本、网络环境都在变化。第二个事实AI生成的代码不是标准答案它可能很自信地错。你必须建立起“所有输出都需验证”的反射。第三个事实100天能让你入门应用开发但不会让你成为算法专家。设定这个边界反而能让你更快做出东西。2. 前30天先建立工具感而不是急着学框架前30天我几乎没碰任何框架注意力只放在一件事上让AI参与到我每天的写代码流程里并且形成肌肉记忆。这个阶段的目标不是做出完整应用而是改变“人怎么和AI协作”。2.1 选一个AI编程工具把它用到顺手我当时用的是Cursor同时在PyCharm里开了AI插件。如果你主力IDE是VS Code、JetBrains或其他选同类的AI编程工具就行。这里我的首要建议是只选一个主力把它用透不要同时开四五个AI工具否则连哪个片段来自哪个工具都容易搞混。刚开始我犯过一个很典型的错误把AI编程工具当成高级搜索引擎让它直接生成一整个模块然后几乎不审查就粘进项目。结果代码看起来合理一运行就报错。后来我调整成一套固定流程先让AI解释当前代码的作用确认它读懂了上下文再让它提方案。方案确认后再让它生成代码而不是直接让它动手。生成之后必须自己读一遍重点检查依赖引入、函数签名、异常处理。把AI写的代码当作同事的代码来评审而不是当作标准答案。这套流程会慢一点但能避免大量“看不懂代码怎么坏掉”的时间。2.2 学会给AI搭上下文而不是只提需求很多新手抱怨AI生成代码质量差但我观察下来大部分问题不是模型不行而是“上下文”没给够。你可以做个实验在同一项目里只说一句“帮我写一个文件解析函数”和写明“文件是CSV格式、字段有5列、第3列可能含英文逗号、期望返回字典列表、遇到空行直接跳过”生成质量是完全不同的。我给AI提需求时会按一个固定结构来写目标我想完成什么任务期望结果是什么。输入数据从哪里来格式如何有哪些边界情况。输出需要什么结构错误时该怎么处理。约束不能用哪些库必须兼容哪个环境性能有没有要求。这个结构不仅对AI有效对跟同事协作同样有效。当你养成了“把问题讲清楚”的习惯之后AI的生成结果会明显更可改、更可维护你的沟通能力也会被同步逼着提升。2.3 第30天的里程碑跑通一次完整的API调用链第30天左右我完成了第一个最小闭环用Python调用一个大模型文本接口输入一段报错日志让它判断属于哪个模块然后把结果打印出来并写入文件。代码结构大概是这样import requests resp requests.post( YOUR_MODEL_ENDPOINT, headers{Authorization: Bearer YOUR_API_KEY}, json{ messages: [ {role: user, content: 请把下面的报错日志分类为网络、数据库、业务、未知只输出分类名称\n log_text} ], max_tokens: 32 } ) print(resp.json())如果你刚接触不用纠结这段代码能不能直接跑它只是示意。你真正要理解的是这条链路输入文本准备 → 组装请求 → 发送到模型 → 解析响应 → 记录日志。很多新手卡在中间往往不是模型能力问题而是API Key配置不对、返回JSON解析错误、输出编码混乱、没有打日志导致根本不知道问题出在哪一步。注意不要一上来就把批量数和并发数拉满先用一条样例确认输入、输出和日志都正常。除了跑通还可以顺手做一个小实验把temperature参数分别调到0和1.2看同一句话的返回有什么不同。你会直观理解“降低随机性”是什么意思这在后面做需要稳定输出的任务时非常关键。3. 中间40天从对话应用走到工程化前30天结束的时候我能稳定调用API了。但我很快发现“能调API”和“能交付一个AI应用”之间隔着一整条工程化链路的距离。这40天是整个100天里最耗时、最枯燥、也最值得的部分。3.1 先处理输入和输出再谈模型效果AI应用开发中最容易翻车的不是模型本身而是两端的数据处理。输入侧要注意文本编码是否一致尤其是中文和特殊字符场景。上游数据有没有脏数据比如空值、重复、截断、混入非目标内容。上下文窗口有限超长文本怎么切分是截断还是先做摘要。输出侧要注意模型返回的JSON结构可能会变要做好容错解析。是否会出现空回复、多余标签、把标签和理由混在一起的情况。输出结果是否需要规则兜底比如“模型说是数据库问题但日志里没有任何连接字样”这时候不能直接信任。我见过不少新人把问题归结为“模型效果差”最后定位却发现是数据清洗和输出解析没做好。这些问题不解决你连一个稳定的最小演示都做不出来更不用说放给真实用户试。在参数上也可以做一些基础设置比如参数经验值影响temperature0到0.3需要稳定输出时尽量低决定生成随机性max_tokens根据任务设置合理上限防止长回复浪费成本和延迟top_p常与temperature配合默认或0.9控制采样范围并发数先1再逐步增加到2、5避免依赖方限流当然具体值要结合你的模型和使用场景调但思路是先保守再放宽。3.2 当任务出现多步流程Agent就会自然出现单次调用只能回答“一句话到一个任务”的问题。当任务变成“先理解用户问题再判断意图再检索资料再组装回答”时你需要把多步流程串起来。这就是我理解的Agent它不是一个神奇的黑盒而是把复杂任务拆解成多步让每一步都能调用工具、观察结果、决定下一步。我第一个真正意义上的Agent是给内部做个简单答疑机器人。流程长这样用户提问 → 意图识别 → 检索相关文档 → 组装上下文 → 生成回答 → 输出每一步单独看都很简单但真正跑起来后麻烦集中在“某一步失败之后怎么办”。比如检索不到文档时Agent是应该直接说不知道还是换一种说法再检索一次回答超时了是返回兜底文案还是重试这些策略不写清楚演示时会频繁出现“卡住不动”或“反复循环”的情况。3.3 遇到Spring AI这类框架先看它解决了什么问题因为我的后端工作主要在Java生态中间一度被Spring AI这类框架吸引。它的核心价值是帮我省掉了在不同模型厂商SDK之间反复切换的麻烦把请求封装、Prompt管理、输出解析、对话历史这些重复工作做了统一抽象。但以我的实际体验来说这类框架仍在快速演进版本之间不一定兼容。落地时要注意几件事必须锁定依赖版本避免今天能跑、明天升级后行为变化。要确认框架封装的模型能力和模型厂商原生能力是否一致有些高级参数不一定透传。如果框架的抽象反而限制了你的自定义逻辑可以直接用原生API补一段不要为了框架而框架。技术方案不是越高级越好而是越可控越好。如果你的团队很小用脚本加日志可能比引入一整套框架更合适。3.4 做一个完整的RAG问答应用作为阶段成果第60天我完成了一个文档问答应用也就是常见的RAG流程。这个项目我强烈建议不要跳过因为它覆盖了AI应用开发的大部分核心环节。基本步骤是读取文档按章节或逻辑切分注意保留标题和层级信息。对切分后的文本做向量化存入向量库。用户提问时把问题也向量化检索最相关的片段。把检索到的片段和用户问题组装成提示词发送给大模型。返回答案同时把来源文档一并输出方便人工核对。这个项目里的坑也不少切分太大会让检索不精准太小又会丢上下文向量化模型如果换过必须重新索引检索到的最相关内容未必能直接回答用户问题有时还需要做一轮重排。你不需要一开始就优化到极致但至少要把链路完整走通记录每个环节的输入输出再逐步调整。到这个阶段你会发现AI应用不再是一次“对话”而是一套可改、可测、可迭代的流程。4. 最后30天部署出去并看住模型的幻觉前两个阶段结束后我一度觉得自己已经入门了。直到我把应用部署到服务器让同事用了一下午才发现自己离“可用”还差得很远。这一阶段主要解决两件事一是让应用跑在真实环境里二是学会和模型的不确定性打交道。4.1 本地部署AI模型先确认资源和目标是匹配的“本地部署AI”对很多人有天然的吸引力好像只要自己的GPU能跑模型就代表安全、可控、免费。但我的体感是本地部署会引入新的工程问题显卡驱动、CUDA版本、显存占用、并发能力、模型量化、依赖冲突每一样都可能让部署日变成排查日。我建议按你的场景选场景更合适的方案学习验证、快速原型先用云端API或在线演示成本低见效快数据敏感、必须私有化部署选开源模型本地部署但先确认显存和运维资源高频调用、需要低延迟对比云端API和本地部署的延迟、成本、维护成本需要长期稳定、交给团队维护优先选择有成熟运维方案的模型服务对萌新来说第一次部署不要尝试最大参数版本。先选一个小体积模型把流程跑通再考虑换更大的版本这样才能把“模型能力不够”和“部署配置有问题”分开判断。如果你只是学习验证本地部署并不必要如果你真的要进入生产就要提前接受一个事实本地部署
100天从AI新手到独立开发应用：我的实战复盘
100天前我给自己定了一个不大不小的目标从一个只会用AI聊天的萌新变成能独立开发、部署AI应用的人。当时我的日常工作主要围绕Oracle数据库展开写SQL、调存储过程、处理夜维任务。说实话模型、参数、微调这些词我听过很多但从来没认真上手过。真正刺激到我的一次是看到一个平时话很少的同事用一款AI编程工具在半小时内把一个纠缠了我一整天的数据处理脚本改成了结构清晰的版本。他并没有用什么高深技巧只是会描述问题、知道验证结果、敢让AI改代码。那一刻我突然意识到AI能力已经不再是“锦上添花”它会直接改变程序员的工作方式。于是我用100天做了一场实验。这篇文章是实验结束之后的复盘包括每个阶段该练什么、最容易放弃的点在哪里、哪些被高估、哪些被低估以及如果你想复刻应该从哪一步开始。1. 先搞清楚这100天到底要练什么很多新手学AI的第一个动作是收藏一份深度学习路线图然后从线性代数开始看。这个路径对科班学生也许成立但对一个白天还要写业务代码、只能靠晚上和周末学习的人来说几乎注定失败。原因不是内容太难而是反馈周期太长。你花了两周推导梯度下降仍然看不出这和“做一个问答应用”有什么关系动力就会在被业务需求切割的碎片时间里迅速消耗光。我的做法是反过来先定义100天结束后我手里要有什么作品再反向拆解需要练什么。这跟做项目一样先定验收标准再定开发计划。1.1 第一步不是推导公式而是定义一批看得见摸得着的终点我给自己定的终点是三个递进的小项目能用一个大模型API完成一个真实业务场景的文本分类或信息提取任务结果要能被程序读取比如输出JSON或结构化文本。能在本地完成一个“文档检索—召回—问答”的RAG应用并以HTTP接口的方式暴露出来让另一个程序或页面能调用。能把这个RAG应用部署到服务器设计一组评测问题记录答案质量并处理常见的超时、空回复、答非所问问题。这三个项目都不要求推导模型公式但都会逼着你接触Prompt、API、上下文窗口、向量检索、部署、日志、异常处理这些真实工程问题。等这些坑趟过一遍之后再回头去看Transformer、注意力机制这些概念我的实际体感是理解成本会低很多因为你已经知道每个模块在解决哪个环节的问题。1.2 用三张清单管住学习范围我强烈建议新手给自己建立三张清单避免陷入教程沼泽必懂清单必须能用一句话说清的工具或概念比如“Cursor是AI编程助手我用它辅助写代码”“RAG是先检索再生成的问答框架”。必跑通清单必须亲手完成的动作比如“调用一次模型API”“把回复解析成JSON”“部署一次模型服务”。暂缓清单当前阶段不用碰的深水区比如“自己训练一个大模型”“微调开源模型”“写自定义算子”。这个划分的价值在于它会不断提醒你AI开发本质上还是软件开发先能在已有模型和工具上做出可靠产品再考虑更底层的事情。对多数应用开发者能把一个开源或云端模型稳定地用起来并管住它的边界已经比纯调API的高谈阔论有价值得多。1.3 心态上需要提前接受三个事实第一个事实你会频繁遇到“昨天能跑今天突然不行”的情况。这不是你笨而是模型服务、依赖版本、网络环境都在变化。第二个事实AI生成的代码不是标准答案它可能很自信地错。你必须建立起“所有输出都需验证”的反射。第三个事实100天能让你入门应用开发但不会让你成为算法专家。设定这个边界反而能让你更快做出东西。2. 前30天先建立工具感而不是急着学框架前30天我几乎没碰任何框架注意力只放在一件事上让AI参与到我每天的写代码流程里并且形成肌肉记忆。这个阶段的目标不是做出完整应用而是改变“人怎么和AI协作”。2.1 选一个AI编程工具把它用到顺手我当时用的是Cursor同时在PyCharm里开了AI插件。如果你主力IDE是VS Code、JetBrains或其他选同类的AI编程工具就行。这里我的首要建议是只选一个主力把它用透不要同时开四五个AI工具否则连哪个片段来自哪个工具都容易搞混。刚开始我犯过一个很典型的错误把AI编程工具当成高级搜索引擎让它直接生成一整个模块然后几乎不审查就粘进项目。结果代码看起来合理一运行就报错。后来我调整成一套固定流程先让AI解释当前代码的作用确认它读懂了上下文再让它提方案。方案确认后再让它生成代码而不是直接让它动手。生成之后必须自己读一遍重点检查依赖引入、函数签名、异常处理。把AI写的代码当作同事的代码来评审而不是当作标准答案。这套流程会慢一点但能避免大量“看不懂代码怎么坏掉”的时间。2.2 学会给AI搭上下文而不是只提需求很多新手抱怨AI生成代码质量差但我观察下来大部分问题不是模型不行而是“上下文”没给够。你可以做个实验在同一项目里只说一句“帮我写一个文件解析函数”和写明“文件是CSV格式、字段有5列、第3列可能含英文逗号、期望返回字典列表、遇到空行直接跳过”生成质量是完全不同的。我给AI提需求时会按一个固定结构来写目标我想完成什么任务期望结果是什么。输入数据从哪里来格式如何有哪些边界情况。输出需要什么结构错误时该怎么处理。约束不能用哪些库必须兼容哪个环境性能有没有要求。这个结构不仅对AI有效对跟同事协作同样有效。当你养成了“把问题讲清楚”的习惯之后AI的生成结果会明显更可改、更可维护你的沟通能力也会被同步逼着提升。2.3 第30天的里程碑跑通一次完整的API调用链第30天左右我完成了第一个最小闭环用Python调用一个大模型文本接口输入一段报错日志让它判断属于哪个模块然后把结果打印出来并写入文件。代码结构大概是这样import requests resp requests.post( YOUR_MODEL_ENDPOINT, headers{Authorization: Bearer YOUR_API_KEY}, json{ messages: [ {role: user, content: 请把下面的报错日志分类为网络、数据库、业务、未知只输出分类名称\n log_text} ], max_tokens: 32 } ) print(resp.json())如果你刚接触不用纠结这段代码能不能直接跑它只是示意。你真正要理解的是这条链路输入文本准备 → 组装请求 → 发送到模型 → 解析响应 → 记录日志。很多新手卡在中间往往不是模型能力问题而是API Key配置不对、返回JSON解析错误、输出编码混乱、没有打日志导致根本不知道问题出在哪一步。注意不要一上来就把批量数和并发数拉满先用一条样例确认输入、输出和日志都正常。除了跑通还可以顺手做一个小实验把temperature参数分别调到0和1.2看同一句话的返回有什么不同。你会直观理解“降低随机性”是什么意思这在后面做需要稳定输出的任务时非常关键。3. 中间40天从对话应用走到工程化前30天结束的时候我能稳定调用API了。但我很快发现“能调API”和“能交付一个AI应用”之间隔着一整条工程化链路的距离。这40天是整个100天里最耗时、最枯燥、也最值得的部分。3.1 先处理输入和输出再谈模型效果AI应用开发中最容易翻车的不是模型本身而是两端的数据处理。输入侧要注意文本编码是否一致尤其是中文和特殊字符场景。上游数据有没有脏数据比如空值、重复、截断、混入非目标内容。上下文窗口有限超长文本怎么切分是截断还是先做摘要。输出侧要注意模型返回的JSON结构可能会变要做好容错解析。是否会出现空回复、多余标签、把标签和理由混在一起的情况。输出结果是否需要规则兜底比如“模型说是数据库问题但日志里没有任何连接字样”这时候不能直接信任。我见过不少新人把问题归结为“模型效果差”最后定位却发现是数据清洗和输出解析没做好。这些问题不解决你连一个稳定的最小演示都做不出来更不用说放给真实用户试。在参数上也可以做一些基础设置比如参数经验值影响temperature0到0.3需要稳定输出时尽量低决定生成随机性max_tokens根据任务设置合理上限防止长回复浪费成本和延迟top_p常与temperature配合默认或0.9控制采样范围并发数先1再逐步增加到2、5避免依赖方限流当然具体值要结合你的模型和使用场景调但思路是先保守再放宽。3.2 当任务出现多步流程Agent就会自然出现单次调用只能回答“一句话到一个任务”的问题。当任务变成“先理解用户问题再判断意图再检索资料再组装回答”时你需要把多步流程串起来。这就是我理解的Agent它不是一个神奇的黑盒而是把复杂任务拆解成多步让每一步都能调用工具、观察结果、决定下一步。我第一个真正意义上的Agent是给内部做个简单答疑机器人。流程长这样用户提问 → 意图识别 → 检索相关文档 → 组装上下文 → 生成回答 → 输出每一步单独看都很简单但真正跑起来后麻烦集中在“某一步失败之后怎么办”。比如检索不到文档时Agent是应该直接说不知道还是换一种说法再检索一次回答超时了是返回兜底文案还是重试这些策略不写清楚演示时会频繁出现“卡住不动”或“反复循环”的情况。3.3 遇到Spring AI这类框架先看它解决了什么问题因为我的后端工作主要在Java生态中间一度被Spring AI这类框架吸引。它的核心价值是帮我省掉了在不同模型厂商SDK之间反复切换的麻烦把请求封装、Prompt管理、输出解析、对话历史这些重复工作做了统一抽象。但以我的实际体验来说这类框架仍在快速演进版本之间不一定兼容。落地时要注意几件事必须锁定依赖版本避免今天能跑、明天升级后行为变化。要确认框架封装的模型能力和模型厂商原生能力是否一致有些高级参数不一定透传。如果框架的抽象反而限制了你的自定义逻辑可以直接用原生API补一段不要为了框架而框架。技术方案不是越高级越好而是越可控越好。如果你的团队很小用脚本加日志可能比引入一整套框架更合适。3.4 做一个完整的RAG问答应用作为阶段成果第60天我完成了一个文档问答应用也就是常见的RAG流程。这个项目我强烈建议不要跳过因为它覆盖了AI应用开发的大部分核心环节。基本步骤是读取文档按章节或逻辑切分注意保留标题和层级信息。对切分后的文本做向量化存入向量库。用户提问时把问题也向量化检索最相关的片段。把检索到的片段和用户问题组装成提示词发送给大模型。返回答案同时把来源文档一并输出方便人工核对。这个项目里的坑也不少切分太大会让检索不精准太小又会丢上下文向量化模型如果换过必须重新索引检索到的最相关内容未必能直接回答用户问题有时还需要做一轮重排。你不需要一开始就优化到极致但至少要把链路完整走通记录每个环节的输入输出再逐步调整。到这个阶段你会发现AI应用不再是一次“对话”而是一套可改、可测、可迭代的流程。4. 最后30天部署出去并看住模型的幻觉前两个阶段结束后我一度觉得自己已经入门了。直到我把应用部署到服务器让同事用了一下午才发现自己离“可用”还差得很远。这一阶段主要解决两件事一是让应用跑在真实环境里二是学会和模型的不确定性打交道。4.1 本地部署AI模型先确认资源和目标是匹配的“本地部署AI”对很多人有天然的吸引力好像只要自己的GPU能跑模型就代表安全、可控、免费。但我的体感是本地部署会引入新的工程问题显卡驱动、CUDA版本、显存占用、并发能力、模型量化、依赖冲突每一样都可能让部署日变成排查日。我建议按你的场景选场景更合适的方案学习验证、快速原型先用云端API或在线演示成本低见效快数据敏感、必须私有化部署选开源模型本地部署但先确认显存和运维资源高频调用、需要低延迟对比云端API和本地部署的延迟、成本、维护成本需要长期稳定、交给团队维护优先选择有成熟运维方案的模型服务对萌新来说第一次部署不要尝试最大参数版本。先选一个小体积模型把流程跑通再考虑换更大的版本这样才能把“模型能力不够”和“部署配置有问题”分开判断。如果你只是学习验证本地部署并不必要如果你真的要进入生产就要提前接受一个事实本地部署
