这是一次委托实测的完整记录。实测由一位零基础用户——某公司行政专员小周完成目标是验证一个命题完全不懂技术的人能不能在当天用搭贝生成一套可用的管理系统。业务是她自己挑的公司内部 IT 支持工单系统。这个场景每个公司都有员工电脑坏了、账号锁了、打印机不动了报给 ITIT 排队处理处理完销单。先说结论当天生成完毕九个环节全部走完系统可用过程中出现了一处表单字段冗余和一处口径偏差都由小周用对话式修改当场解决。零基础这个前提没有成为障碍。本文是她的操作记录整理稿关键节点保留了她的原话。一、实测背景为什么选工单系统小周选这个场景有三个考虑。第一通用性工单是跨行业的标准业务域读者容易对照自己的场景。第二痛点真实公司内部报修之前走的是微信群——员工把「打印机又双叒叕卡纸了」发到大群里IT 在消息海洋里捞单子漏单是常态统计是奢望。第三复杂度适中有明确的实体工单、角色员工、IT、主管、流程提交—受理—处理—销单和规则超时提醒足以检验生成管线的完整性。作为对比基线公司之前也评估过另外两条路找软件公司定制报价周期三个月起用开源工单系统自部署需要有人维护服务器和配置学习成本以周计。这两条路都只是评估没有走——实测的主角是 AI 自动生成。二、填写需求十二个字开始实测从填写需求开始。小周输入的一句话需求是「给公司建 IT 工单支持系统」十二个字。她刻意没有写得更详细——零基础用户的第一句话往往就是这么短。详细的口径对齐是下一步的事这个设计让「说人话」成为唯一的使用门槛。补充一个测试细节小周另外准备了一句更啰嗦的版本包含分类、分级、超时口径的一长句话做了对照输入。结果是两句话生成的系统骨架一致啰嗦版的引导问题少了一问——口径已经在句子里说清了。可见需求写得越具体对齐越快但写得笼统也不会出错只是多答几个问题。零基础用户不必纠结怎么写需求这是实测给的一个定心丸。三、引导问题问题对齐业务口径AI 没有直接生成而是先给出方案说明准备生成的工单系统包含哪些部分、工单按什么状态流转、谁在什么环节干什么。方案里列了表单、工作流的框架以及状态机的大致走向。1、方案说明里看到了什么方案说明把系统的骨架讲清楚了工单从提交到关闭的状态流转、IT 与主管各自的职责边界、超时提醒的触发逻辑。这一步小周核对了一个关键口径——工单要不要分类。方案默认分了硬件、软件、账号、其他四类符合实际确认通过。2、引导问题方案确认后是四个引导问题① 第一问贵公司的组织架构是怎样的小周答单一办公地点集中管理。② 第二问IT支持团队主要包含哪些角色答二线专业工程师负责网络、硬件、软件等深度处理、IT主管/经理负责审批、监控SLA和数据报表、一线服务台负责接单、初筛和简单解答。③ 第三问日常IT工单主要涉及哪些业务类型答故障报修如电脑死机、网络中断、打印机故障、权限与账号申请如开通邮箱、系统权限变更。④第四问是否需要对不同类型的工单设置响应和处理时效要求SLA答需要按紧急程度设定不同的超时预警规则。四个问题答完工单系统的行为口径就定了。整个过程没有出现一个技术术语问题全是业务语言——这是零基础用户能顺利走完的关键。小周事后回忆「跟我想的填表不一样它是在问规矩。」四、生成总览当天拿到系统与清单口径确认后系统当天生成完毕。打开先看到生成总览整套系统的构成列成清单四种角色员工、一线服务台、二线专业工程师、IT 主管 / 经理九张表单新建工单、我的工单、工单评价表、待办工单池、我的待处理工单、工单处理记录、审批中心、知识库、SLA规则配置两条工作流新建工单流程、审批中心流程业务规则权限申请类工单自动生成审批单据、新工单提交后自动写入待办池等待接单、工单结单后自动生成待填写的评价记录、临近SLA时限时触发超时预警通知处理人、处理记录结单时同步更新原工单状态、审批被驳回时自动关闭原工单并通知申请人AI 智能体IT工单智能助手小周按清单逐项点开核对每项都能打开看到实际内容不是占位符。这个「生成总览即验收清单」的设计让验收有据可查。五、角色与表单四种人、三张单1、角色权限四种角色的权限边界。①普通员工提交各类 IT 故障报修或权限账号申请查看个人工单处理进度并进行服务评价②一线服务台负责接收新工单进行初步排查解答简单问题直接关闭复杂问题分类转派给对应工程师③二线专业工程师处理网络、硬件、软件等深度技术问题填写详细处理过程并结单④IT主管/经理审批特殊权限申请监控整体工单响应时效与处理质量查看统计报表过去微信群里人人都能看到所有报修消息的状态现在各看各的边界清晰。2、九张表单①新建工单员工发起 IT 故障报修或权限账号申请的入口表单②我的工单员工查看自己已提交的所有工单列表及处理进度③工单评价表员工对已结单工单的服务满意度反馈记录④待办工单池汇总所有待分配或待处理的 IT 工单供服务台接单⑤我的待处理工单二线专业工程师查看分配给自己的待处理工单⑥工单处理记录记录每次工单处理的具体动作、结果与耗时⑦审批中心IT 主管处理权限类申请的审批单据⑧知识库沉淀常见 IT 问题的标准解决办法供工程师参考⑨SLA 规则配置定义不同紧急程度的响应和处理时限要求发现一处冗余工单提交表单默认生成了「期望完成时间」字段——实测里没人填这个字段大家都嫌填起来要想。小周对话式修改说了一句「去掉期望完成时间」字段当天移除。生成物不完美但修正成本低到可以忽略。六、看板与流程数字实时流转自动1、看板看板给 IT 主管看四组数今日新增工单、待受理工单、处理中工单、平均处理时长。以前这些数要翻聊天记录手工数现在打开就在。数字随工单状态实时联动月底统计从一个下午变成一次导出。2、四条工作流①新建工单流程普通员工发起 IT 需求故障报修或权限申请的工单流转与审批流程②审批中心流程IT 主管处理权限类申请的审批单据流程每条流程的触发条件显式声明不依赖谁记得催谁。实测第三天有个紧急工单财务经理的账号锁了月底关账要用从提交到受理的流转没有卡顿——流程自己会走。销单环节的设计单独说说提交人确认后才关单不确认则退回处理。实测第五天退回过一单——打印机换了耗材仍旧卡提交人点了不通过工单退回处理人续处理整个过程在系统里留了完整记录。要在微信群里这单多半变成群里又一遍从头描述问题。七、业务规则与 AI 智能体规矩与助手1、业务规则两条关键规则超过一个工作日未受理的工单自动提醒 IT 主管紧急工单未在四小时内受理升级提醒。实测期间触发过一次超时提醒一个普通工单赶上周五下午没人认领提醒推送给了主管周一早上被优先处理——规则在真实场景里起作用了。2、AI 智能体AI 智能体做两件事关键环节主动辅助——工单描述只写了「电脑坏了」三个字时它会追问具体症状处理记录的措施栏空着时它会提醒补全。AI 工作流智能对话——主管在流程节点上直接问「今天有多少紧急单」对话里得到答案不用翻看板。八、对话式修改两处当场修正除了去掉「期望完成时间」字段实测中还改了一处口径知识库条目原来所有员工可见实测反馈是有些条目涉及内部操作细节不适合全员开放。小周对话式修改把可见范围改成「IT 处理人及以上」当天生效。两处修改合计花费的时间比写一封变更申请邮件还短。这是实测里体感最强的部分系统不对没关系改起来不疼。用满一周后补一个观察知识库开始自我供血。处理人每销一单AI 智能体会提示把有共性的处理记录沉淀为知识库条目一周下来存了十几条。员工报修前先搜知识库「重置密码」「共享打印机连接」这类高频问题自助解决工单量比微信群时代明显少了——系统不只是把旧流程搬了家还慢慢长出了减负的能力。九、两条路的实测对照实测结束后把这次生成与评估过的传统路线做了对照。维度软件公司定制开源自部署AI 自动生成前期投入需求文档与评审服务器与部署一句话需求上手周期三个月起以周计当天维护要求依赖供应商需要专人维护平台托管修改成本变更单以周计自己改代码或配置对话式修改当天生效适合场景深度定制有技术团队的公司零基础快速上线零基础团队能走的路只有最后一条而这条路的产出质量并不因为门槛低而缩水——这是实测最大的发现。常见问题Q1零基础真的能当天生成可用系统吗能这是本次实测的核心结论。实测执行者是一位行政专员从一句话需求到系统可用全程当天完成九个环节没有出现需要技术知识才能通过的关卡。引导问题全是业务语言生成后的调整靠对话式修改完成。Q2生成的工单系统和微信报修比好在哪核心是留痕与流转。微信群里消息会被淹没、无法统计、没有状态工单系统里每张单有状态、有处理人、有时效超时自动提醒月底可以导出统计。对 IT 主管来说看板代替了翻聊天记录。Q3生成过程中出现的问题怎么办实测出现了一处字段冗余和一处权限口径问题都由实测用户用对话式修改当场解决说一句改一处当天生效。生成物允许有毛边因为修正成本接近零这是与传统交付最大的体验差异。Q4员工使用需要培训吗几乎不需要。提交工单就是填一张表单字段语义直白查进度看自己的工单列表。实测中全体员工直接上手没有组织培训只有一条群公告说明了入口。Q5系统能支撑多大的使用规模工单系统运行在平台上性能由平台架构保证与使用者是否懂技术无关。实测规模是几十人的日常报修同类场景几百人规模的内部支持工单在平台的设计范围内。Q6除了工单还能生成什么系统同一套管线适合「实体加流程」型的标准业务进销存、客户管理、报修、报销审批、任务管理。判断标准是业务能不能被描述成清晰的实体、角色和流程——能就适合生成。