这是一次委托实测的完整记录。实测由一位零基础用户——某公司行政专员小周完成，目标是验证一个命题：完全不懂技术的人，能不能在当天用搭贝生成一套可用的管理系统。业务是她自己挑的：公司内部 IT 支持工单系统。
这个场景每个公司都有：员工电脑坏了、账号锁了、打印机不动了，报给 IT，IT 排队处理，处理完销单。

先说结论：当天生成完毕，九个环节全部走完，系统可用；过程中出现了一处表单字段冗余和一处口径偏差，都由小周用对话式修改当场解决。零基础这个前提没有成为障碍。本文是她的操作记录整理稿，关键节点保留了她的原话。

一、实测背景：为什么选工单系统

小周选这个场景有三个考虑。
第一，通用性：工单是跨行业的标准业务域，读者容易对照自己的场景。
第二，痛点真实：公司内部报修之前走的是微信群——员工把「打印机又双叒叕卡纸了」发到大群里，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：除了工单，还能生成什么系统？

同一套管线适合「实体加流程」型的标准业务：进销存、客户管理、报修、报销审批、任务管理。判断标准是业务能不能被描述成清晰的实体、角色和流程——能，就适合生成。