第三篇｜学了那么多 AI，怎么做出第一个真正能用的项目？

作者：谯洪敏｜零一道

**导读：**你是不是做过很多AI小工具，但最后都没人用？从一张工单开始，弄清哪些环节用规则、哪些环节交给 AI，再把派工、测试和实际使用连起来。你的第一个 FDE 项目，就可以从这样一件小事起步。

你可能已经试过不少大模型，也做过几个好玩的 AI 小工具。但接下来，一个更实际、也更扎心的问题来了：

怎样做出一个别人愿意天天拿来干活的“真家伙”，而不是一个演示完就吃灰的 Demo？

前两篇我们聊了 FDE，以及如何用 Ontology（本体论）把业务里的对象和动作讲清楚。[1][2] 今天这篇，我们来点实操的：继续沿用前两篇文章的维修工单来练习，手把手教你把“帮调度员派工”这件小事，做成一个可交付的产品。

先定个小目标：第一版就做一个团队、一类工单、一次派工。

范围越小，才越容易看清哪里好用、哪里会翻车。至于什么跨团队排班、全面自动化，等有人实际用了，你再慢慢加。

第一步：别急着写代码，先画一张“作战地图”

动手之前，用一句话定下目标：“让调度员少花时间核对人员，同时保留对派工的确认权。”

把它写成一页纸的“作战计划”，你和业务人员都得签字画押，然后再开始干：

• 谁来用？（谁是你的核心用户）
• 现在怎么做？（痛点在哪）
• 第一版做到哪里？（砍掉一切不紧急的需求）
• 需要哪些数据？（巧妇难为无米之炊）
• 怎样算成功？（验收标准）

你可以按下面5步推进，每走完一步，都要留下一个能拿给别人看的“半成品”：

1. **看现场：**有条件的话你就坐在他旁边，看他怎么派工。问清楚并记录好，调度员到底卡在哪里。他每天要派多少张工单？时间花在找人、核对排班，还是反复补信息？先看他完整操作一遍，记下耗时和容易出错的地方，再一起决定第一版要改善什么。
2. **找数据：**工单从哪来？人员资质存在哪里？排班多久更新一次？每个字段是什么意思，谁能查看，都要问清楚。自学时可以自己编一组工单和人员数据；使用真实数据前，需要取得授权。缺了数据，界面也要让人看得出来。
3. **写规则：**把“能派”和“不能派”用大白话写下来。资质不够、时间冲突、工单已关闭时，系统该怎么拦？
4. **做测试：**做出能跑的第一版，故意试错——找不合格的人派工、搞个排班冲突，看他卡在哪一步。
5. **小步快跑：**找一两个关系好的调度员，让他们连续用一周。出了故障怎么切回原流程？对照最初的记录，看派工是不是真的快了。

第二步：规则、AI 还是 Agent？第一版到底怎么选？

很多新手一上来就喊着“我要做个 Agent 搞定一切”，结果不仅成本高，还经常胡说八道。

先拆开任务，看每个环节需要什么能力：

• 能用明确规则核对的，优先用规则，不必用 AI（AI 不是万能的，能 if else 搞定的就让 if else 搞定）
  资质是否有效？时间是否冲突？当前账号有没有派工权限？这些有明确条件的地方，直接写代码核对。即使 AI 给出了推荐，提交前也必须由服务端按规则再校验一遍。
• 文字不规整的，让 AI 帮忙：
  比如调度员收到一句“3楼空调不制冷，安排个人来看看”。AI 可以瞬间提取出“地点：3楼”、“问题：空调不制冷”、“缺失：设备编号”。程序检查必填项，调度员补充确认，信息齐了再往下走。
• 需要查资料的，上 RAG（知识库检索）：
  如果要参考维修手册，让 AI 先找出相关段落，再根据这些材料给出建议，并标明出处。找不到依据就老实说不知道。人员资质和当天排班，直接查询你现有的最新的业务系统即可。
• 步骤明确的，用固定流程（Workflow）；步骤经常变的，再评估 Agent：
  固定流程由程序安排下一步，AI 只负责干文字处理的脏活。Agent 虽然听起来高级，但往往耗时更长、成本更高。入门项目，先把固定流程做稳。[3]

Anthropic 的官方实践也建议从简单方案开始，根据需要再逐步增加复杂度。[3] 落到我们这个练习，先把一次派工做可靠，就是合适的起点。

第三步：把工单串起来，第一版可以这样搭

下面是一条可用于练习的流程，你可以根据自己的业务调整：

报修描述 → AI 整理信息 → 补齐必填项 → 查询工单、资质与排班 → 规则筛选 → 调度员确认 → 提交派工 → 回读工单状态。

实现时，准备四件套就够起步了：

1. 一个供调度员操作的页面。
2. 保存工单与人员信息的数据库（或表格）。
3. 整理文字的模型调用（API）。
4. 执行派工的后端接口。

如果没有现成工单系统，可以先在测试数据库里模拟（Mock）指派；这能验证流程，接入真实系统后还要继续验证权限、数据和接口。

页面上要给调度员看明白：哪些信息已经确认、哪些还缺失、推荐了谁、为什么符合条件。

“已推荐”、“已提交”、“结果待确认”、“已完成”要分别显示。 只有回读结果符合预期，才显示已完成；遇到超时，先查这次操作是否已经执行，再决定补救。这样，使用者才知道事情走到了哪一步。

第四步：交付验收“六连问”，别被 Demo 骗了

演示时，一张工单派出去，大家很容易觉得项目成功了。真正投入日常使用，还要多问几件事。你可以和业务人员一起检查下面灵魂六连问，每一项都要落到具体例子上：

1. 有没有帮上忙？ 同样难度的工单，处理时间有没有缩短？重复沟通有没有减少？（比较时写清看了多少张工单、用了多久，别把业务量变化算成工具的功劳）
2. 推荐的人对不对？ 资质是否合格？排班是否有空？“推荐得好”与“规则检查通过”要分别验证。
3. 该谁操作，管住了吗？ 普通员工能不能看到不该看的信息，或替调度员提交派工？（拿个没权限的账号试一次）
4. 显示成功，工单真的改了吗？ 回到工单系统确认负责人和状态。连续点两次提交，会不会重复派工？
5. 出错了，下一步怎么办？ 接口超时、信息缺失，或者工单刚被别人派走时，提示是否清楚？
6. 调度员第二天还愿意用吗？ 观察他在哪一步退出，为什么又打开原来的 Excel 表格。持续使用中的反馈，会告诉你这个工具是否真正适合他的工作。

自学项目也能这样检查。先准备一份小型测试案例集，写清输入条件和预期结果，再运行项目核对。可以参考下面这张表试试：

测试条件：工单可派，人员合格且有空

预期结果：人工确认后指派一次；回读负责人和状态与预期一致。

测试条件：报修描述缺少设备编号

预期结果：提示补齐信息；补齐前不执行派工。

测试条件：人员资质无效或排班冲突

预期结果：说明不符合哪条规则；不能把此人提交为负责人。

测试条件：当前账号无派工权限

预期结果：后端拒绝操作；工单保持原状态。

测试条件：重复点击同一次提交

预期结果：同一操作编号只生效一次；不会重复指派或重复通知。

测试条件：接口超时，执行结果未知

预期结果：先查询操作结果和工单状态；未确认前显示“结果待确认”，避免盲目重复提交。

涉及模型的描述整理和推荐解释，可以对同一案例多跑几次，观察是否稳定。[4] 保存输入、提取结果、规则检查、接口调用和最终状态，方便发现问题后复测。

第五步：留下你的可复用“数字资产”

Palantir 的官方架构介绍提到，FDE 团队会贴近业务问题，并与核心工程团队协作，把现场反馈带回产品。[1] 对自学者和小团队来说，最值得借鉴的就是这一点：把这次解决问题的过程留下来。

保存下面这几样就很有用：

• 问题是怎样定义的？
• 数据字段是什么意思？
• 工单与人员怎样关联？
• 测试用了哪些例子？
• 出故障时怎样处理？
• 这次踩了哪些坑？

这些记录会成为你下一个项目的起点。比如派工时用过的“先查当前状态，再提交变更，最后确认结果”，以后做退款审批、库存调拨都能复用——但换了业务，谁能批准、数据是什么意思、出错怎么补救，必须重新确认。复用这些记录，能让你少走很多重复的弯路。

跑通之后，把成功和失败的例子都记下来：哪次派工成功了？哪次被拒绝了？为什么拒绝？后来怎样改进？讲清这四条，别人一眼就能判断你的工具能做什么、适合用在哪里。

这里插一句最容易被忽略的：Anthropic 在评测指南里强调，结果要看任务结束后的实际状态。[4] 落到我们这个练习，就是回到工单系统核对负责人和状态；模型生成的那句“派工成功”，只是过程中的一条输出，不代表真实结果。所以核对状态这件事，必须由人来做。

第六步：算清三笔账，再决定做不做下去

• 第一笔：时间账。 上线前先记一笔原流程处理同类工单要多久、返工多少次。试用期间继续记：实际完成了多少张、用户从打开页面到确认结果花了多久、人工补救了多少次。

有个典型陷阱：模型很快给出推荐，但调度员还是要翻三张表去核对信息，整个任务可能依然很慢。Google SRE 的实践强调，要围绕用户真正关心的体验选指标。[5] 所以优先看完整派工过程的耗时和正确完成率，别只看模型响应快不快。

• 第二笔：成本账。 把试用期的模型调用费用除以实际完成的工单数，得出每张完成工单的平均模型费用——失败调用也要算进去（我们服务的客户对 AI 失败非常敏感，这块需要重点关注）。再单独核算接口、运行环境和人工维护投入，跟省下的时间放一起，判断值不值得继续做。目标值和观察周期，由你和业务方商定。
• 第三笔：交接账。 留一页维护说明：谁负责、哪里看运行记录、什么情况转人工、出了故障怎么恢复原流程。问题描述、缺项、规则检查、接口调用和最终状态这些记录要保留，并按权限控制访问，方便下次定位问题。

读完这篇，你可以动手做什么？

给自己一个小目标：写一页问题说明，列清工单与工程师的数据关系，做出包含规则检查和人工确认的派工流程，用前面的测试案例核对结果，再记录一次小范围试用的时间、费用和问题。

最后录一段演示、写下改进记录，就是一份可以继续讨论的作品。

介绍这个项目时，试着回答五个问题：

1. 我在帮谁？
2. 解决的是哪件事？
3. 系统怎样执行？
4. 我怎么知道它做对了？
5. 目前还有什么限制？

把这些讲清楚，就是一份别人能够理解、也能继续讨论的作品。可以按这样的顺序练习：先理解业务，再把规则写清楚、做出原型，经过测试，交给实际使用的人。

从你每天遇到的一个小问题开始，就能找到练习方向。

参考资料：

[1] Palantir Architecture Center：Forward Deployed Engineering；

[2] Palantir AIP architecture

[3] Anthropic：Building effective agents（方案复杂度、工作流与 Agent 的选择）

[4] Anthropic：Demystifying evals for AI agents（测试案例、运行记录与最终结果）

[5] Google SRE：Service Level Objectives（围绕用户体验选择指标）