很多开发者第一次接触AI工作流时都会陷入一个奇怪的循环先用现成工具跑一个Demo跑通了觉得很厉害然后换到真实任务发现问题一堆接着想调参、改提示词、换模型却发现不知道从哪里下手。整个系统像一个黑盒输入进去输出出来中间发生了什么完全看不清楚。一个人长期在“黑盒上叠黑盒”会慢慢丧失一种很重要的能力亲手验证一个任务、亲手判断一个结果、亲手把流程中的每一步拆开检查。“AI by Hand”字面上看很像是“手工做AI”但它并不是真的让你扔掉模型和框架用纸笔去搭建神经网络。它更像是一种工作方式在面对AI任务和AI工具的时候先尝试用最少的外部依赖在离数据最近的位置把流程跑通把每一步的输入和输出看清楚。这看起来比直接调用Model API或拖一个Agent框架慢得多但它的价值恰恰在于让人重新拿回对流程的理解和掌控感。这篇文章想聊的不是某一个工具的教程而是我理解的“AI by Hand”为什么它值得做怎么做做到什么程度就该停下来以及它和AI Agent、AI编程、模型部署这些工程概念之间到底是怎么连接的。1. 先想清楚“AI by Hand”说的不是“AI手写”1.1 它更像是一种保留“亲手验证感”的工作方式你可以把“AI by Hand”理解成一道基础功练习。就像数据结构的课程上老师会要求你手写一个链表而不是直接调用现成容器因为目的不是让你以后生产代码里也手写容器而是让你理解指针、内存和边界条件到底是怎么回事。AI也一样当你知道一个分类系统的每一层在做什么、一个提示词改动为什么会改变结果、一个召回过程为什么漏掉了那条记录你才真正开始使用AI而不只是调用AI。“AI by Hand”最常见的学习版本是手动计算一个极小的线性回归或逻辑回归步骤把损失函数、梯度下降、数据标准化都过一遍。这个方向的教程已经很多。但还有一个工程版本很少被认真讨论在不上模型、不调API的前提下把你工作的输入、目标、规则和错误处理显式地写下来用几个脚本或规则模块完成一个普通任务。你会发现这个“不用AI的AI流程”能帮你把所有问题暴露出来。我最早意识到这一点是在做一个内容分类需求的时候。团队一开始想直接接大模型API做零样本分类觉得这样省事。但一接入测试出现了两个问题一是接口返回不稳定同一个标题反复分类结果不一致二是成本完全不可控只要数据量一大费用就涨得很快。于是我们先不用模型整理了一批历史规则把标题、关键词、正则表达式和人工判断标准全部写下来做成一个本地脚本先跑。这个过程看起来是在“退步”但它让我们把业务边界、脏数据格式、命中条件的冲突全部摸清了。等规则版稳定之后再决定在哪些边界case上交给模型去兜底。这其实就是一个很有代表性的“AI by Hand”流程。1.2 它解决的不是算力问题而是理解问题很多人对“手工做AI”有一个天然的质疑费这么大劲做出来一个规则系统效果肯定不如大模型为什么还要做这个质疑成立但方向理解偏了。用它不是为了替代大模型而是为了把“任务本身”和“模型能力”先分开。任务本身是什么是数据进来以后先经过哪些清洗和转换关键字段如何提取输出结果要满足什么格式哪些情况允许模糊哪些情况必须精确。这些问题如果说不清楚模型换成哪个版本、参数调到什么程度都只是碰运气。模型能力强的时候即使这些问题没梳理清楚它也能给你一个“看起来合理的答案”这会掩盖任务定义上的所有缺陷。等到模型能力稍有波动或者数据批次发生变化整个流程就崩了。AI by Hand真正帮你解决的是这个问题先把任务本身的分析和沉淀做完再决定哪部分交给规则、哪部分交给统计方法、哪部分交给大模型。这也是我在这篇文章里想坚持的主判断不要把“AI by Hand”理解成一个怀旧的教学玩具把它理解成一套可执行的、面向真实问题的最小分析流程。它最有价值的地方不是更快而是让复杂任务变得可控、可验证、可复盘。2. 一个最小可执行的“手工AI”流程示例2.1 先定义一个足够小的真实任务为了让讨论不悬空我们用一个小例子来展开。假设你现在有一个需求根据用户提交的工单标题判断它属于“网络问题”“账号问题”“支付问题”还是“其他”。这看起来是一个最普通的文本分类任务也是很多AI编程、AI应用开发初学者会先练手的类型。常规做法是调用大模型API写一个类似这样的提示词你是一个工单分类助手请将下面的标题分类为 网络问题、账号问题、支付问题、其他。 只输出类别名称。 标题WiFi连接不稳定经常断网这个做法能跑通但它把太多东西隐藏起来了。模型具体是根据哪些词判断出来的如果标题里同时出现“网络”和“支付”它该怎么办如果用户写的是“连不上WiFi但支付也失败了”输出会是什么这些边界提示词里没有说清楚模型也只能靠“猜”。如果按“AI by Hand”的思路可以先把任务的第一个版本做成一个本地可运行的文本分类器不依赖任何外部模型服务。这既能验证任务定义是否清晰也能为后面接入模型准备好边界样例。2.2 用最原始的关键词规则建立基线先写一个很朴素的关键词分类脚本。用Python举例核心逻辑如下# 原始版本基于关键词的规则分类器 # 作用不是替代模型而是建立一个人人可以检查的基线 KEYWORDS { network: [wifi, 网络, 断网, 网速, 掉线, 连接不上, 无法上网], account: [账号, 登录, 密码, 验证码, 无法登录, 密保], payment: [支付, 扣款, 退款, 订单, 付款, 账单, 银行], } def classify(title): hit_scores {} for category, words in KEYWORDS.items(): score 0 for word in words: if word in title: score 1 hit_scores[category] score max_category max(hit_scores, keyhit_scores.get) if hit_scores[max_category] 0: return 其他 return max_category这个脚本没有任何机器学习成分但它马上帮我们把问题暴露了。比如标题“支付时页面打不开”同时命中了“支付”和“打开”但“打开”不在任何词表里标题“网络连接失败导致无法支付订单”会同时命中“network”和“payment”这时需要看哪个类别得分更高甚至需要定义优先级。真正的价值在这个环节出现了你会发现分类任务不只是“给一句话打标签”它还包括关键词权重、多标签冲突、否定表达、同义词处理、脏数据清洗。如果不亲手把这些样本过一遍你根本不知道调模型的时候应该给提示词哪些样例。2.3 加上可检查的数据格式和冲突规则在试用中发现问题后继续按最朴素的方式改进流程。这次不急着加更多词而是先把输出设计成结构化结果把命中的关键词也一起输出。def classify_with_evidence(title): # 返回结果和命中的关键词方便人工检查分类依据 hit_details {} for category, words in KEYWORDS.items(): matched [w for w in words if w in title] if matched: hit_details[category] matched if not hit_details: return {category: 其他, matched: {}} # 按命中数量排序如果并列则使用预先定义的优先级 priority [payment, account, network] sorted_categories sorted( hit_details, keylambda c: (len(hit_details[c]), len(priority) - priority.index(c)), reverseTrue ) top sorted_categories[0] return {category: top, matched: hit_details}这种“带着证据输出”的习惯是从手工流程开始就必须养成的。大模型API返回一个类别名称时它不会主动告诉你这是基于哪些关键信息判断出来的你只能猜。而如果前面先跑了一个可解释的规则版本你至少知道了哪些现象是规则可以覆盖的哪些必须交给模型。后面即使换成模型分类仍可以并行保留这个规则分类器作为校验线。这个阶段的结论是手工分类脚本不是你的最终方案而是你的任务说明书。3. 手工流程的真正强项可排查、可回退、可度量3.1 先从“现象”出发而不是从“模型版本”出发规则流程跑完以后自然会遇到几个问题准确率不够、召回率不高、某些case怎么调都不对。这时候有人会立刻把锅推给“规则写法太烂”然后决定直接换大模型。我先建议你按下面这个顺序排查一次看输入样例标题里的错别字、简称、长尾表达有没有在预处理阶段被漏掉。看关键词冲突一个标题同时命中多个类别时当前得分和优先级是否合理。看类别定义是不是有些类别天然叠在一起连人工都很难区分比如“网络问题”和“设备问题”。看输出评价你是按“准确率”评价还是按“是否影响下游处理”评价这两个标准会带来完全不同的优化方向。第一次做这个流程时我所在的团队调整了两个小时的关键词准确率只提升了一个多点。但后来发现大多数bad case根本不是关键词不全造成的而是样例本身太短人工也很难判断意图比如标题只有一个词“失败”。这种case换成大模型也一样无解因为它缺少上下文。如果当时直接跳进调模型提示词大概率是白费时间。这个排查顺序就是把模型从“黑盒”还原成一个普通模块先检查它的输入再检查内部规则最后才考虑把某个环节替换成更强的方法。3.2 本地优先、模型兜底的混合设计手工规则流程稳定后就可以考虑让模型来解决规则搞不定的部分但要以可回退的方式接入。常见的混合设计是规则流程优先运行如果能返回高置信度结果直接输出。当得分很低或多个类别得分接近再调用外部模型。模型输出仍然要经过后校验判断是否在合法类别集合内如果不在回退到“其他”。这个设计的好处是绝大多数常见case走本地规则速度最快、成本为零少部分困难case才走模型费用可控。由于规则版本始终保留一旦模型接口出问题整个流程可以降级到规则模式不影响主流程。这也是AI工程实践里经常被忽略的一点一个真正可用的系统不是一个准确率最高的模型而是一个在准确率、成本、稳定性和可维护性之间取得平衡的系统。3.3 建立一个稳定可复用的“先本地后模型”框架把上面的思路整理成一个可复用的框架我一般称为“三层降落式处理”第一层确定性规则。能通过关键词、正则、字典、硬编码判断的内容先用确定性方法解决。评价标准是输出可解释、边界可枚举。第二层统计或本地模型。规则覆盖不了但特征相对固定的内容可以用本地的、可离线部署的模型方案比如TF-IDF加简单分类器或者小型的嵌入式文本编码。评价标准是离线验证稳定、可批量重训。第三层大模型API或领域模型。少数高度开放、依赖常识或语义理解的case才调用云端模型。评价标准是效果明显优于前两层且成本与延迟可接受。判断什么时候该从第一层升到第三层标准不是“模型效果听起来更强”而是“当前层有哪些bad case是明确无法靠规则解决的”并且在真实样本上做小批量验证后再决定。4. “AI by Hand”不是目的边界感才是4.1 手工流程做多了也要知道及时收手前面讲了很多手工流程的优势但必须补上它的边界。如果一个任务涉及公开数据量很大的文本理解比如市场评论分析、开放式问答、对话摘要用手工规则去做就是灾难。你花一个星期维护关键词表可能还不如一个通用模型零样本的效果。这个矛盾不是方案错误而是任务类型不匹配。所以做“AI by Hand”的时候心里要有一条时间线先给手工规则流程2到3个小时用于梳理数据格式、分类边界和输出结构。如果这个过程中发现样例绝大多数都能被简单规则命中就继续完善规则。如果发现很多case依赖常识、语义或外部知识就应该停下来把精力转移到提示词样例和模型对齐上。换句话说“AI by Hand”的产出物不一定是“一套纯手工系统”也可以是“一批足够清晰的边界样例和一个结构化的输出协议”然后把这套基础设施交给模型去发挥。4.2 模型部署和AI Agent也需要这种基础能力再往工程方向看一层。这几年AI Agent和AI编程很火不少人开始搭Agent框架让模型自动写代码、自动调用工具、自动执行任务。这种场景比单次文本分类复杂得多模型需要跨多个步骤执行中间一旦出错错误会沿着链路被放大。这时候“AI by Hand”的思路就更重要了。你可以用最朴素的方式把Agent的每一步拆开先让模型输出结构化意图再打印出每一步的工具调用参数再检查执行结果判断是否需要继续下一步。很多Agent框架自带这些可视化面板但如果你在没有面板的情况下自己先写一个最小循环会更容易理解它的设计意图。# 手工Agent循环的简化示意重点是把每一步的输入输出暴露出来 def run_agent_step(intent, tool_result): # 在真实Agent框架中这一步会交给LLM做决策 # 手工版本用于调试把决策依据、可用工具、上下文都打印出来 print(intent:, intent) print(tool_result:, tool_result) # 避免进入循环限制最大步数 return finish这种“最小循环”看起来简陋但它让你明白Agent的每个环节分别依赖哪些上下文、工具参数有没有传对、异常分支谁负责处理。很多Agent demo只能跑通理想路径真实场景一出现临时报错就断了就是因为没有做好分层决策和异常兜底。而这些恰恰是手工调试时最容易发现的。4.3 从“手工做”中沉淀自己的判断清单结合上面的讨论我建议你把下面清单当作一个长线项目去持续更新任务边界清单哪些内容必须用模型哪些内容用规则更可控。边界样例集每积累十个bad case就往测试集里补充一条。输出协议定义最终结果的标准格式包括主结果、置信度、证据、失败标记。回退策略模型调用失败时的数据流向、缓存策略、是否需要人工审核。成本刻度记录每个调用的token消耗和计算耗时把它纳入方案对比标准。这份清单就是“AI by Hand”从一次练习变成日常工作习惯的沉淀。它不增加神秘感但能让你面对任何新推出的AI工具时都有一套自己的判断方法先看它改变了哪一层再看它是否带来了新的不可控点最后通过一小批真实数据来验证而不是只看宣传里的演示效果。5. 写在最后的经验5.1 亲手跑通一次最小流程比收藏十个教程有用我也见过很多开发者收藏了大量关于大模型、AI Agent、模型部署的资料但真正遇到问题时依然不知道该从哪儿查起。问题不是资料不够而是没有一次亲手把流程从头到尾跑通过的经验。跑通的意思是你知道输入从哪里来知道数据中间经历了哪些变化知道结果要到哪儿去并且能解释任何一个环节异常时该怎么回退。“AI by Hand”就是补上这段经验的最短路径。它不要求你手工推导反向传播更不要求你从头训练一个Transformer。它可以只是把一个最简单的文本分类任务先用规则手写一遍把一个最简单的Agent链路先手动拆成三个步骤调试一遍把一个模型调用先通过日志完整记录输入、输出和耗时。这些动作的核心是离开对黑盒的依赖回到对任务本身的分析。5.2 它的价值不是替代技术工具而是帮人用好技术工具每次看到新出的AI工具或新的模型版本我的第一反应不是问“它能实现什么”而是问“它把哪个环节变简单了”。如果答案只是“demo效果更惊艳”那它对我解决真实问题可能帮助有限如果答案是“它把模型调试的过程变得更可视化”那它才会真正改变工作流。用这样一套思路去看AI Agent、AI编程、模型部署你会发现很多话题其实是同一件事如何让复杂流程变得可理解、可控制、可迭代。工具可以越来越自动但你的判断力只能靠对自己任务的深度理解来积累。亲手完成一次最小流程是积累判断力最直接的方式。这大概就是“AI by Hand”在2025年仍然值得拿出来认真讨论的根本原因。下一个新模型出现时希望每个人都能用手里的边界样例和排查清单快速判断出它真正适合放哪一层。