1. 为什么我要给自己画一张 AI 产品路线图去年这个时候我手里只有一个跑在本地的小脚本功能很单一就是帮我把一堆杂乱的文本素材做初步归类。那时候我根本没想过“产品”这两个字觉得能跑通、能省点力气就不错了。但一年下来我陆续做出了三个能拿得出手的作品覆盖了内容处理、交互问答和自动化流程三个方向。这个过程里踩过的坑、推翻过的方案、半夜改参数改到怀疑人生的时刻远比最后呈现出来的三个成品要多得多。这篇文章不是教你某个具体框架怎么用而是把我这一年从零散想法到三个落地作品的完整路线图拆开来讲。我会说清楚每个阶段为什么选那个方向、技术栈怎么定、遇到瓶颈时怎么换思路以及哪些经验是只有真正动手做过才会知道的。如果你也在琢磨用 AI 做点自己的东西或者已经有一个模糊的想法但不知道怎么推进那这篇内容应该能帮你少走一些弯路。核心关键词我先摆出来AI 产品路线图、个人项目迭代、技术选型、落地实操、避坑经验。整篇内容会围绕这四个字展开——“一年”是时间跨度“三个作品”是具体产出“路线图”是背后的规划逻辑。我不会只讲成功的那部分失败和返工的地方同样值得说因为那才是真实的产品迭代过程。2. 第一阶段从“能用”到“好用”的内容处理工具2.1 为什么第一个作品选内容处理方向第一个作品我定位成“内容处理工具”原因很直接我自己每天要处理大量文本素材手动整理效率太低。市面上的工具要么太重要么不够灵活没法按我的习惯来。所以最初的动机就是自用解决自己的痛点。这个选择背后有一个很朴素的逻辑——第一个作品最好从自己最熟悉的场景切入因为你知道痛点在哪也知道什么样的结果算“好用”。技术选型上我一开始就排除了从零训练模型这条路。原因很简单个人开发者没有那个算力也没有那个数据量。我选择的是调用现成的能力接口把精力放在流程编排和结果后处理上。这个决策后来被证明是对的因为第一个作品的核心价值不在于模型本身而在于怎么把模型能力嵌入到一个顺手的操作流程里。具体来说这个工具要完成三件事批量读取不同格式的文本、按规则做初步分类、输出结构化的结果。听起来不复杂但真正做起来光是格式兼容就花了我将近两周时间。这里给一个很实在的建议不要一开始就追求支持所有格式先把最常用的两三种做扎实剩下的边用边加。2.2 核心功能拆解与参数调优这个工具的核心功能我拆成了四个模块输入解析、预处理、分类处理、结果输出。每个模块都有对应的参数需要调我拿分类处理这个模块举例说明。分类处理我采用的是“规则加模型”的混合策略。纯规则的话遇到边界情况容易误判纯模型的话又不够稳定同样的输入两次结果可能不一样。混合策略的逻辑是先用规则做一轮粗筛把明显属于某一类的直接分走剩下的模糊样本再交给模型判断。这样既保证了速度又保证了准确率。参数调优这块我踩过一个很大的坑。最开始我把模型的“置信度阈值”设得很高想着宁可漏判也不要误判。结果实际跑下来超过六成的样本都落到了“待定”区间等于没分类。后来我把阈值从0.85降到0.65同时增加了一轮人工复核的环节整体效率反而提升了。这个经验告诉我阈值不是越高越好要看你的下游流程能不能消化“待定”结果。如果你的流程里有人工复核那阈值可以适当放低如果是全自动流水线那阈值就得调高同时接受一定的漏判率。下面这张表是我当时测试不同阈值下的实际表现数据是跑了五百条样本得出的置信度阈值自动分类占比准确率待定占比0.8538%96%62%0.7561%93%39%0.6579%89%21%0.5591%82%9%从表里能看出来阈值降到0.65的时候自动分类占比接近八成准确率还有89%这个平衡点对我来说是最合适的。当然这个数字不是通用的你得根据自己的场景去测。但思路是一样的先跑一批样本画出这条曲线再决定阈值定在哪。2.3 第一个作品的实操心得这个工具从想法到能用大概花了两个半月。其中真正写核心逻辑的时间不到一个月剩下的时间都在做兼容、调参数、改交互。有几点心得我觉得挺重要的。第一日志一定要做细。我一开始图省事只记录了最终结果没记录中间过程。后来发现分类不准的时候根本不知道是哪一步出了问题。补上详细日志之后排查效率至少提升了一倍。日志里至少要包含输入原文、预处理后的文本、规则命中的情况、模型返回的原始结果、最终输出。这五样东西缺一不可。第二配置文件要独立出来。我最初把参数写死在代码里每次调整都要改代码、重新运行。后来把所有可调参数抽到一个配置文件里改参数不用动代码效率高了很多。配置文件用最简单的键值对格式就行不用搞太复杂。第三先做命令行版本再做界面。我见过不少人一上来就折腾界面结果核心逻辑还没跑通界面改来改去浪费了大量时间。我的做法是先用命令行跑通全流程确认逻辑没问题了再套一个简单的界面。这样即使界面做得不好看至少功能是完整的。3. 第二阶段交互问答系统的设计与取舍3.1 从内容处理到交互问答的跨越第一个作品做完之后我休息了大概两周然后开始琢磨第二个方向。当时有几个选择做数据可视化、做自动化流程、做交互问答。最后选交互问答是因为我发现第一个作品虽然能处理内容但处理完之后我想快速找到某个具体信息还是很麻烦。换句话说内容处理解决了“整理”的问题但没解决“检索和交互”的问题。交互问答系统的核心目标很明确让我能用自然语言问问题系统从已有的内容库里找到答案并返回。这个方向听起来比第一个作品高级但实际做起来难点完全不一样。第一个作品的难点在流程编排第二个作品的难点在检索质量和回答准确性。技术方案上我采用的是“检索加生成”的两段式架构。先根据问题去内容库里检索相关片段再把检索结果和问题一起交给生成模块让它组织成一段通顺的回答。这个架构的好处是回答有据可依不会凭空编造坏处是如果检索没找到相关内容生成模块就容易胡编。所以检索环节的质量直接决定了整个系统的上限。3.2 检索环节的关键参数与优化过程检索环节我试过三种方案关键词匹配、向量检索、混合检索。关键词匹配速度快但不够灵活换个说法就找不到向量检索灵活但有时候会召回不相关的内容混合检索是把两者结合起来用关键词做粗筛用向量做精排。实测下来混合检索的效果最好但配置也最复杂。向量检索里有一个关键参数叫“召回数量”就是每次检索返回多少个候选片段。这个参数设得太少可能漏掉关键信息设得太多又会引入噪声影响生成质量。我一开始设的是3后来发现经常漏信息调到了8。但调到8之后生成模块有时候会被无关片段带偏。最后的方案是召回数量设成6同时加一个相关性过滤的步骤把明显不相关的片段先剔除掉再交给生成模块。相关性过滤我用的是一个简单的打分机制综合了向量相似度和关键词命中率两个指标。具体公式不复杂就是加权求和权重根据实际效果调。我试过几组权重最后定下来的是向量相似度占七成关键词命中率占三成。这个比例不是理论最优但在我这个场景下表现最稳定。还有一个容易被忽略的参数是“片段长度”。内容库里的文本如果切得太碎检索出来的片段可能缺少上下文切得太长又会引入无关信息。我试过按段落切、按固定字数切、按语义切三种方式。按语义切效果最好但实现起来最麻烦。最后我采用的是折中方案先按段落切如果段落太长再按句子边界切保证每个片段在两百到五百字之间。3.3 生成环节的提示词设计与稳定性控制生成环节我踩的坑比检索环节还多。最开始我写的提示词很随意就是“根据以下内容回答问题”这种。结果生成模块经常自由发挥要么答非所问要么把检索到的内容原封不动抄一遍。后来我花了整整一周时间专门打磨提示词才把稳定性提上来。提示词的核心结构我定成了四段角色设定、任务说明、约束条件、输出格式。角色设定是告诉生成模块“你是一个严谨的问答助手”任务说明是“根据提供的参考资料回答问题”约束条件是“如果参考资料里没有相关信息就明确说不知道不要编造”输出格式是“先给结论再给依据”。这四段缺一不可尤其是约束条件没有它的话生成模块几乎一定会胡编。还有一个很实用的技巧是在提示词里加示例。我放了两三个“问题加理想回答”的示例进去生成模块的输出质量明显提升。示例不用多两三个就够但一定要选有代表性的覆盖“能找到答案”和“找不到答案”两种情况。稳定性控制方面我把生成模块的“随机性参数”调得很低。这个参数控制输出的多样性调高的话每次回答都不一样调低的话回答更稳定但可能有点死板。对于问答系统来说稳定性比多样性重要所以我把它设在了接近最低的值。实测下来同样的输入基本能得到一致的回答这对用户体验很重要。4. 第三阶段自动化流程的搭建与串联4.1 为什么第三个作品转向自动化前两个作品做完之后我发现一个问题它们都是独立的需要我手动去触发。内容处理工具要手动运行问答系统要手动提问。虽然每个工具都能解决问题但工具之间的衔接还是靠人。第三个作品的目标就是把前两个作品串联起来再加上一些定时触发和条件判断形成一个自动化流程。这个转向其实挺自然的。当你有了几个能用的模块之后自然会想把它们组合起来让它们自己跑。自动化的核心价值不在于单个环节有多强而在于减少人工干预的次数。哪怕每个环节只省一分钟串起来之后省的时间就很可观了。技术方案上我选的是一个轻量的流程编排框架。没有用那种很重的企业级方案因为我的场景没那么复杂用重方案反而是负担。这个框架的核心概念是“节点”和“连线”每个节点是一个操作连线定义操作的顺序和条件。我把内容处理封装成一个节点把问答封装成另一个节点中间加上判断和循环整个流程就串起来了。4.2 流程编排中的条件判断与异常处理自动化流程里最容易出问题的地方是条件判断和异常处理。条件判断是“什么情况下走哪条路”异常处理是“出错了怎么办”。这两块如果没做好流程跑起来就是灾难。条件判断我用的是一套简单的规则引擎。比如“如果内容处理的结果里待定比例超过三成就触发人工复核节点否则直接进入问答节点”。规则本身不复杂但规则的优先级要理清楚。我一开始没注意优先级导致两条规则同时命中时行为不确定。后来我给每条规则加了优先级编号冲突时按编号小的执行问题就解决了。异常处理我分了三个层级节点级、流程级、系统级。节点级是单个操作失败时的重试和降级流程级是整个流程失败时的回滚和通知系统级是底层服务不可用时的排队和告警。这三个层级里节点级的重试最重要因为大部分失败都是暂时的重试一次就能成功。我设置的是最多重试三次每次间隔递增第一次等五秒第二次等十五秒第三次等四十五秒。这个间隔不是随便定的是根据实际观察到的故障恢复时间调的。还有一个很实用的设计是断点续跑。流程跑到一半失败了不要从头再来而是从失败的那个节点继续。实现方式是在每个节点完成后记录状态重启时读取状态跳过已完成的节点。这个功能在调试阶段特别有用能省大量时间。4.3 三个作品的串联效果与整体复盘三个作品串起来之后整个流程是这样的定时触发内容处理处理完的结果自动进入问答系统的内容库然后根据预设的问题列表自动提问把回答整理成报告输出。整个过程不需要人工干预我只需要最后看一眼报告就行。从时间投入上看第一个作品花了两个半月第二个作品花了三个多月第三个作品花了一个半月。加起来差不多七个月剩下的五个月都在修修补补和优化。这个时间分布挺有代表性的真正从零到一的时间其实不长大部分时间都花在从一到一点五的优化上。从效果上看三个作品单独拿出来都不算惊艳但串起来之后整体效率提升很明显。以前需要半天才能完成的素材整理和检索现在一个小时以内就能搞定。这个提升不是某个环节的突破带来的而是流程串联减少了等待和切换的成本。5. 一年三个作品背后的选型逻辑与避坑指南5.1 技术选型的三个核心原则回顾这一年我在技术选型上遵循了三个原则现在看下来还是挺管用的。第一个原则是用成熟方案不追新。AI 领域新技术层出不穷但大部分新东西还不稳定文档也不全。我选的框架和工具都是出来至少一年以上的社区活跃遇到问题能搜到答案。追新看起来酷但实际做项目的时候稳定比酷重要得多。第二个原则是先跑通再优化。我见过不少人包括我自己早期在方案设计阶段纠结太久总想找一个“最优解”。但实际上很多问题只有跑起来才会暴露光靠想是想不出来的。我的做法是先用一个能跑通的简单方案跑起来之后再根据实际表现去优化。这个原则帮我省了很多纠结的时间。第三个原则是模块之间松耦合。三个作品之间虽然有串联但每个作品都是独立可运行的。这样即使某个环节出了问题其他环节还能正常工作。松耦合的代价是接口设计要多花点心思但收益是系统的健壮性大幅提升。5.2 常见问题速查表下面这张表是我这一年遇到的高频问题汇总按出现频率排序附上排查思路和解决方法问题现象可能原因排查思路解决方法处理结果不稳定随机性参数过高检查生成模块的随机性参数调低参数增加示例检索召回率低召回数量太少或切分太碎检查召回数量和片段长度增加召回数量调整切分策略流程中途卡住某个节点超时或死循环查看节点日志定位卡住的位置加超时限制加循环次数上限输出格式错乱提示词约束不够明确检查提示词的输出格式部分在提示词里明确格式要求资源占用过高并发数太大或缓存没清理监控资源使用情况限制并发数定期清理缓存结果与预期偏差大阈值设置不合理跑样本测试不同阈值根据测试曲线调整阈值这张表里的每一条都是我实际遇到过的不是理论推演。尤其是“流程中途卡住”这一条我遇到过好几次每次都是因为某个节点没有设超时限制导致整个流程挂在那里。后来我给每个节点都加了超时限制问题就没再出现过。5.3 给后来者的实操建议如果你也想用一年时间做出几个 AI 相关的作品我有几条很实在的建议。第一条从自己的痛点出发不要从技术出发。我见过太多人因为某个技术很火就去做相关的东西结果做出来发现没人用包括自己也不用。从痛点出发的好处是你知道要解决什么问题也知道什么样的结果算解决了。技术只是手段不是目的。第二条第一个作品一定要小。小到什么程度小到你觉得“这么简单的东西也能算作品”的程度。因为第一个作品的主要目的是跑通全流程建立信心而不是做出一个多厉害的东西。我第一个作品的核心功能其实就一个但正是这个简单的作品让我摸清了从想法到落地的完整路径。第三条留出足够的优化时间。从零到一可能只占三成时间从一到一点五要占七成。这个比例听起来不合理但实际就是这样。优化包括调参数、改交互、处理边界情况、写文档每一项都很花时间。如果你只给从零到一留时间那做出来的东西大概率是半成品。第四条记录每一次决策的理由。我在做第二个作品的时候回头去看第一个作品的一些参数设置完全想不起来当时为什么那么设。后来我养成了写决策日志的习惯每次做一个重要选择就记下来选了什么、为什么选、备选方案是什么。这个习惯在后期优化的时候帮了大忙。第五条不要追求完美追求完成。完美主义是个人项目最大的敌人。我见过不少人一个作品做了半年还在改最后不了了之。我的做法是给每个作品设一个“完成线”达到这条线就算完成剩下的优化放到后续迭代里。完成比完美重要因为只有完成了你才有机会去优化。6. 后续可以继续扩展的方向三个作品跑通之后我其实还有一些想继续做的方向。一个是把交互问答系统做得更智能一些比如支持多轮对话能记住上下文。另一个是把自动化流程做得更灵活支持更复杂的条件分支和并行处理。还有一个方向是把三个作品打包成一个统一的入口不用分别启动一个命令就能跑全流程。不过这些都是后话了。眼下我更想做的是把这一年积累的经验整理出来看看能不能帮到也在做类似事情的人。毕竟一个人摸索的时候最缺的不是技术资料而是别人踩过坑之后的真实反馈。技术资料告诉你“怎么做”但只有真实经验才能告诉你“哪里容易出错”和“出错了怎么办”。如果你正在做自己的第一个 AI 作品我的建议是别想太多先动手。哪怕只是调用一个现成的接口做一个最简单的功能也比停留在规划阶段强。因为只有动手了你才会遇到真实的问题而解决真实问题的过程才是真正让你进步的地方。 
长河君 · 2026/10/24 6:38:53 · 阅读 1.2k 一年三个AI作品：从零到落地的产品路线图与避坑指南
1. 为什么我要给自己画一张 AI 产品路线图去年这个时候我手里只有一个跑在本地的小脚本功能很单一就是帮我把一堆杂乱的文本素材做初步归类。那时候我根本没想过“产品”这两个字觉得能跑通、能省点力气就不错了。但一年下来我陆续做出了三个能拿得出手的作品覆盖了内容处理、交互问答和自动化流程三个方向。这个过程里踩过的坑、推翻过的方案、半夜改参数改到怀疑人生的时刻远比最后呈现出来的三个成品要多得多。这篇文章不是教你某个具体框架怎么用而是把我这一年从零散想法到三个落地作品的完整路线图拆开来讲。我会说清楚每个阶段为什么选那个方向、技术栈怎么定、遇到瓶颈时怎么换思路以及哪些经验是只有真正动手做过才会知道的。如果你也在琢磨用 AI 做点自己的东西或者已经有一个模糊的想法但不知道怎么推进那这篇内容应该能帮你少走一些弯路。核心关键词我先摆出来AI 产品路线图、个人项目迭代、技术选型、落地实操、避坑经验。整篇内容会围绕这四个字展开——“一年”是时间跨度“三个作品”是具体产出“路线图”是背后的规划逻辑。我不会只讲成功的那部分失败和返工的地方同样值得说因为那才是真实的产品迭代过程。2. 第一阶段从“能用”到“好用”的内容处理工具2.1 为什么第一个作品选内容处理方向第一个作品我定位成“内容处理工具”原因很直接我自己每天要处理大量文本素材手动整理效率太低。市面上的工具要么太重要么不够灵活没法按我的习惯来。所以最初的动机就是自用解决自己的痛点。这个选择背后有一个很朴素的逻辑——第一个作品最好从自己最熟悉的场景切入因为你知道痛点在哪也知道什么样的结果算“好用”。技术选型上我一开始就排除了从零训练模型这条路。原因很简单个人开发者没有那个算力也没有那个数据量。我选择的是调用现成的能力接口把精力放在流程编排和结果后处理上。这个决策后来被证明是对的因为第一个作品的核心价值不在于模型本身而在于怎么把模型能力嵌入到一个顺手的操作流程里。具体来说这个工具要完成三件事批量读取不同格式的文本、按规则做初步分类、输出结构化的结果。听起来不复杂但真正做起来光是格式兼容就花了我将近两周时间。这里给一个很实在的建议不要一开始就追求支持所有格式先把最常用的两三种做扎实剩下的边用边加。2.2 核心功能拆解与参数调优这个工具的核心功能我拆成了四个模块输入解析、预处理、分类处理、结果输出。每个模块都有对应的参数需要调我拿分类处理这个模块举例说明。分类处理我采用的是“规则加模型”的混合策略。纯规则的话遇到边界情况容易误判纯模型的话又不够稳定同样的输入两次结果可能不一样。混合策略的逻辑是先用规则做一轮粗筛把明显属于某一类的直接分走剩下的模糊样本再交给模型判断。这样既保证了速度又保证了准确率。参数调优这块我踩过一个很大的坑。最开始我把模型的“置信度阈值”设得很高想着宁可漏判也不要误判。结果实际跑下来超过六成的样本都落到了“待定”区间等于没分类。后来我把阈值从0.85降到0.65同时增加了一轮人工复核的环节整体效率反而提升了。这个经验告诉我阈值不是越高越好要看你的下游流程能不能消化“待定”结果。如果你的流程里有人工复核那阈值可以适当放低如果是全自动流水线那阈值就得调高同时接受一定的漏判率。下面这张表是我当时测试不同阈值下的实际表现数据是跑了五百条样本得出的置信度阈值自动分类占比准确率待定占比0.8538%96%62%0.7561%93%39%0.6579%89%21%0.5591%82%9%从表里能看出来阈值降到0.65的时候自动分类占比接近八成准确率还有89%这个平衡点对我来说是最合适的。当然这个数字不是通用的你得根据自己的场景去测。但思路是一样的先跑一批样本画出这条曲线再决定阈值定在哪。2.3 第一个作品的实操心得这个工具从想法到能用大概花了两个半月。其中真正写核心逻辑的时间不到一个月剩下的时间都在做兼容、调参数、改交互。有几点心得我觉得挺重要的。第一日志一定要做细。我一开始图省事只记录了最终结果没记录中间过程。后来发现分类不准的时候根本不知道是哪一步出了问题。补上详细日志之后排查效率至少提升了一倍。日志里至少要包含输入原文、预处理后的文本、规则命中的情况、模型返回的原始结果、最终输出。这五样东西缺一不可。第二配置文件要独立出来。我最初把参数写死在代码里每次调整都要改代码、重新运行。后来把所有可调参数抽到一个配置文件里改参数不用动代码效率高了很多。配置文件用最简单的键值对格式就行不用搞太复杂。第三先做命令行版本再做界面。我见过不少人一上来就折腾界面结果核心逻辑还没跑通界面改来改去浪费了大量时间。我的做法是先用命令行跑通全流程确认逻辑没问题了再套一个简单的界面。这样即使界面做得不好看至少功能是完整的。3. 第二阶段交互问答系统的设计与取舍3.1 从内容处理到交互问答的跨越第一个作品做完之后我休息了大概两周然后开始琢磨第二个方向。当时有几个选择做数据可视化、做自动化流程、做交互问答。最后选交互问答是因为我发现第一个作品虽然能处理内容但处理完之后我想快速找到某个具体信息还是很麻烦。换句话说内容处理解决了“整理”的问题但没解决“检索和交互”的问题。交互问答系统的核心目标很明确让我能用自然语言问问题系统从已有的内容库里找到答案并返回。这个方向听起来比第一个作品高级但实际做起来难点完全不一样。第一个作品的难点在流程编排第二个作品的难点在检索质量和回答准确性。技术方案上我采用的是“检索加生成”的两段式架构。先根据问题去内容库里检索相关片段再把检索结果和问题一起交给生成模块让它组织成一段通顺的回答。这个架构的好处是回答有据可依不会凭空编造坏处是如果检索没找到相关内容生成模块就容易胡编。所以检索环节的质量直接决定了整个系统的上限。3.2 检索环节的关键参数与优化过程检索环节我试过三种方案关键词匹配、向量检索、混合检索。关键词匹配速度快但不够灵活换个说法就找不到向量检索灵活但有时候会召回不相关的内容混合检索是把两者结合起来用关键词做粗筛用向量做精排。实测下来混合检索的效果最好但配置也最复杂。向量检索里有一个关键参数叫“召回数量”就是每次检索返回多少个候选片段。这个参数设得太少可能漏掉关键信息设得太多又会引入噪声影响生成质量。我一开始设的是3后来发现经常漏信息调到了8。但调到8之后生成模块有时候会被无关片段带偏。最后的方案是召回数量设成6同时加一个相关性过滤的步骤把明显不相关的片段先剔除掉再交给生成模块。相关性过滤我用的是一个简单的打分机制综合了向量相似度和关键词命中率两个指标。具体公式不复杂就是加权求和权重根据实际效果调。我试过几组权重最后定下来的是向量相似度占七成关键词命中率占三成。这个比例不是理论最优但在我这个场景下表现最稳定。还有一个容易被忽略的参数是“片段长度”。内容库里的文本如果切得太碎检索出来的片段可能缺少上下文切得太长又会引入无关信息。我试过按段落切、按固定字数切、按语义切三种方式。按语义切效果最好但实现起来最麻烦。最后我采用的是折中方案先按段落切如果段落太长再按句子边界切保证每个片段在两百到五百字之间。3.3 生成环节的提示词设计与稳定性控制生成环节我踩的坑比检索环节还多。最开始我写的提示词很随意就是“根据以下内容回答问题”这种。结果生成模块经常自由发挥要么答非所问要么把检索到的内容原封不动抄一遍。后来我花了整整一周时间专门打磨提示词才把稳定性提上来。提示词的核心结构我定成了四段角色设定、任务说明、约束条件、输出格式。角色设定是告诉生成模块“你是一个严谨的问答助手”任务说明是“根据提供的参考资料回答问题”约束条件是“如果参考资料里没有相关信息就明确说不知道不要编造”输出格式是“先给结论再给依据”。这四段缺一不可尤其是约束条件没有它的话生成模块几乎一定会胡编。还有一个很实用的技巧是在提示词里加示例。我放了两三个“问题加理想回答”的示例进去生成模块的输出质量明显提升。示例不用多两三个就够但一定要选有代表性的覆盖“能找到答案”和“找不到答案”两种情况。稳定性控制方面我把生成模块的“随机性参数”调得很低。这个参数控制输出的多样性调高的话每次回答都不一样调低的话回答更稳定但可能有点死板。对于问答系统来说稳定性比多样性重要所以我把它设在了接近最低的值。实测下来同样的输入基本能得到一致的回答这对用户体验很重要。4. 第三阶段自动化流程的搭建与串联4.1 为什么第三个作品转向自动化前两个作品做完之后我发现一个问题它们都是独立的需要我手动去触发。内容处理工具要手动运行问答系统要手动提问。虽然每个工具都能解决问题但工具之间的衔接还是靠人。第三个作品的目标就是把前两个作品串联起来再加上一些定时触发和条件判断形成一个自动化流程。这个转向其实挺自然的。当你有了几个能用的模块之后自然会想把它们组合起来让它们自己跑。自动化的核心价值不在于单个环节有多强而在于减少人工干预的次数。哪怕每个环节只省一分钟串起来之后省的时间就很可观了。技术方案上我选的是一个轻量的流程编排框架。没有用那种很重的企业级方案因为我的场景没那么复杂用重方案反而是负担。这个框架的核心概念是“节点”和“连线”每个节点是一个操作连线定义操作的顺序和条件。我把内容处理封装成一个节点把问答封装成另一个节点中间加上判断和循环整个流程就串起来了。4.2 流程编排中的条件判断与异常处理自动化流程里最容易出问题的地方是条件判断和异常处理。条件判断是“什么情况下走哪条路”异常处理是“出错了怎么办”。这两块如果没做好流程跑起来就是灾难。条件判断我用的是一套简单的规则引擎。比如“如果内容处理的结果里待定比例超过三成就触发人工复核节点否则直接进入问答节点”。规则本身不复杂但规则的优先级要理清楚。我一开始没注意优先级导致两条规则同时命中时行为不确定。后来我给每条规则加了优先级编号冲突时按编号小的执行问题就解决了。异常处理我分了三个层级节点级、流程级、系统级。节点级是单个操作失败时的重试和降级流程级是整个流程失败时的回滚和通知系统级是底层服务不可用时的排队和告警。这三个层级里节点级的重试最重要因为大部分失败都是暂时的重试一次就能成功。我设置的是最多重试三次每次间隔递增第一次等五秒第二次等十五秒第三次等四十五秒。这个间隔不是随便定的是根据实际观察到的故障恢复时间调的。还有一个很实用的设计是断点续跑。流程跑到一半失败了不要从头再来而是从失败的那个节点继续。实现方式是在每个节点完成后记录状态重启时读取状态跳过已完成的节点。这个功能在调试阶段特别有用能省大量时间。4.3 三个作品的串联效果与整体复盘三个作品串起来之后整个流程是这样的定时触发内容处理处理完的结果自动进入问答系统的内容库然后根据预设的问题列表自动提问把回答整理成报告输出。整个过程不需要人工干预我只需要最后看一眼报告就行。从时间投入上看第一个作品花了两个半月第二个作品花了三个多月第三个作品花了一个半月。加起来差不多七个月剩下的五个月都在修修补补和优化。这个时间分布挺有代表性的真正从零到一的时间其实不长大部分时间都花在从一到一点五的优化上。从效果上看三个作品单独拿出来都不算惊艳但串起来之后整体效率提升很明显。以前需要半天才能完成的素材整理和检索现在一个小时以内就能搞定。这个提升不是某个环节的突破带来的而是流程串联减少了等待和切换的成本。5. 一年三个作品背后的选型逻辑与避坑指南5.1 技术选型的三个核心原则回顾这一年我在技术选型上遵循了三个原则现在看下来还是挺管用的。第一个原则是用成熟方案不追新。AI 领域新技术层出不穷但大部分新东西还不稳定文档也不全。我选的框架和工具都是出来至少一年以上的社区活跃遇到问题能搜到答案。追新看起来酷但实际做项目的时候稳定比酷重要得多。第二个原则是先跑通再优化。我见过不少人包括我自己早期在方案设计阶段纠结太久总想找一个“最优解”。但实际上很多问题只有跑起来才会暴露光靠想是想不出来的。我的做法是先用一个能跑通的简单方案跑起来之后再根据实际表现去优化。这个原则帮我省了很多纠结的时间。第三个原则是模块之间松耦合。三个作品之间虽然有串联但每个作品都是独立可运行的。这样即使某个环节出了问题其他环节还能正常工作。松耦合的代价是接口设计要多花点心思但收益是系统的健壮性大幅提升。5.2 常见问题速查表下面这张表是我这一年遇到的高频问题汇总按出现频率排序附上排查思路和解决方法问题现象可能原因排查思路解决方法处理结果不稳定随机性参数过高检查生成模块的随机性参数调低参数增加示例检索召回率低召回数量太少或切分太碎检查召回数量和片段长度增加召回数量调整切分策略流程中途卡住某个节点超时或死循环查看节点日志定位卡住的位置加超时限制加循环次数上限输出格式错乱提示词约束不够明确检查提示词的输出格式部分在提示词里明确格式要求资源占用过高并发数太大或缓存没清理监控资源使用情况限制并发数定期清理缓存结果与预期偏差大阈值设置不合理跑样本测试不同阈值根据测试曲线调整阈值这张表里的每一条都是我实际遇到过的不是理论推演。尤其是“流程中途卡住”这一条我遇到过好几次每次都是因为某个节点没有设超时限制导致整个流程挂在那里。后来我给每个节点都加了超时限制问题就没再出现过。5.3 给后来者的实操建议如果你也想用一年时间做出几个 AI 相关的作品我有几条很实在的建议。第一条从自己的痛点出发不要从技术出发。我见过太多人因为某个技术很火就去做相关的东西结果做出来发现没人用包括自己也不用。从痛点出发的好处是你知道要解决什么问题也知道什么样的结果算解决了。技术只是手段不是目的。第二条第一个作品一定要小。小到什么程度小到你觉得“这么简单的东西也能算作品”的程度。因为第一个作品的主要目的是跑通全流程建立信心而不是做出一个多厉害的东西。我第一个作品的核心功能其实就一个但正是这个简单的作品让我摸清了从想法到落地的完整路径。第三条留出足够的优化时间。从零到一可能只占三成时间从一到一点五要占七成。这个比例听起来不合理但实际就是这样。优化包括调参数、改交互、处理边界情况、写文档每一项都很花时间。如果你只给从零到一留时间那做出来的东西大概率是半成品。第四条记录每一次决策的理由。我在做第二个作品的时候回头去看第一个作品的一些参数设置完全想不起来当时为什么那么设。后来我养成了写决策日志的习惯每次做一个重要选择就记下来选了什么、为什么选、备选方案是什么。这个习惯在后期优化的时候帮了大忙。第五条不要追求完美追求完成。完美主义是个人项目最大的敌人。我见过不少人一个作品做了半年还在改最后不了了之。我的做法是给每个作品设一个“完成线”达到这条线就算完成剩下的优化放到后续迭代里。完成比完美重要因为只有完成了你才有机会去优化。6. 后续可以继续扩展的方向三个作品跑通之后我其实还有一些想继续做的方向。一个是把交互问答系统做得更智能一些比如支持多轮对话能记住上下文。另一个是把自动化流程做得更灵活支持更复杂的条件分支和并行处理。还有一个方向是把三个作品打包成一个统一的入口不用分别启动一个命令就能跑全流程。不过这些都是后话了。眼下我更想做的是把这一年积累的经验整理出来看看能不能帮到也在做类似事情的人。毕竟一个人摸索的时候最缺的不是技术资料而是别人踩过坑之后的真实反馈。技术资料告诉你“怎么做”但只有真实经验才能告诉你“哪里容易出错”和“出错了怎么办”。如果你正在做自己的第一个 AI 作品我的建议是别想太多先动手。哪怕只是调用一个现成的接口做一个最简单的功能也比停留在规划阶段强。因为只有动手了你才会遇到真实的问题而解决真实问题的过程才是真正让你进步的地方。