很多开发者第一次接触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, key=hit_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, key=lambda c: (len(hit_details[c]), len(priority) - priority.index(c)), reverse=True ) 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年仍然值得拿出来认真讨论的根本原因。下一个新模型出现时，希望每个人都能用手里的边界样例和排查清单，快速判断出它真正适合放哪一层。
