标题这个问题CSDN 的读者问得越来越多。这篇不聊概念、不贴架构图就用一份完整的生成记录做拆解一位不会写代码的灯具店老板怎么让 AI 生成了一整套安装派工管理系统。每个环节都带技术视角的注解——生成机制是什么、快在哪、边界在哪工程读者关心的点全覆盖。样本背景一家开在建材市场里的灯具店老板姓覃一个店面带一个小仓库两名安装师傅主营中高端灯具销售带安装。业务链是完整的「销售—仓储—派工—安装—售后」五环客户下单之后灯具从仓库出库安装师傅上门装灯装完拍照回单质保两年整。听起来线性管起来一团麻订单在收银系统里只记钱不记灯、库存靠手工台账卖掉的灯和仓库的灯对不上是常事、派工靠老板脑子记两个师傅的时间表全在覃老板脑子里排重了师傅就吵架、售后靠微信翻记录质保期内免费维修超没超期全凭记忆猜。四套工具四种口径数据从不互通。覃老板的技术成色会收银系统、会微信、Excel 会打开和关闭——关闭比打开熟练。就这个成色全程自助走完了生成当天上线没请一个技术顾问。一、需求输入一句话的信号学覃老板输入的一句话需求是「给灯具店做个安装派工系统」十二个字。技术注解从信号角度看这句话的有效信息是「域锚定」——灯具店行业域、安装派工业务域。它不携带实体清单、不带流程细节、没有数据结构但它的价值恰恰在于不含这些域一旦锚定后续所有交互都在同一上下文内进行通信成本趋近于零。对比传统需求工程需求文档试图在信道未建时传完所有信息结果是每传一次都要重新对焦。一句话需求是「先建信道、再传数据」——这个顺序上的差异是后面所有速度差异的源头。二、方案说明模型的首次交底与人工校准需求提交后AI 先给方案说明订单怎么接、库存怎么扣、派工怎么排、安装怎么回单、售后怎么算质保逐条列出。覃老板核出两处口径差。第一处方案默认派工「按单派、装完即结」实际灯具安装分「基础安装」和「造型安装」客厅多层吊灯要搭脚手架工时是普通的五倍——改派工单分安装类型工时系数各走各的。第二处方案默认库存「卖出即扣减」实际中高端灯具常有「陈列样机」——展示中的灯不算库存可卖量——改库存分「在库」和「陈列」两个状态陈列品转销售走调拨。两处改完确认。技术注解这一环是「模型交底—人工校准」协议。AI 基于行业常识给出默认模型按单派工、卖出即扣用户基于本地实情纠偏两种安装、陈列品。注意纠偏的方向AI 错的不是「不懂灯具」而是「不懂这家店」——通用模型和本地实情之间的差只有店主能填而且填的成本极低看出来、说出来两步。这个协议的效率远高于需求评审会评审会用会议对齐认知方案核对用文档对齐认知后者可回溯、可增量、还没有会议成本——工程团队值得把这套协议借鉴到需求管理里。三、引导问题业务规则的显式化① 系统中主要涉及哪些角色答店长 / 调度员负责任务分配、安装师傅接收并反馈任务② 您期望的任务分配方式是答人工指派由调度员手动分配③ 每个安装任务需要管理哪些核心信息答客户地址与联系方式、灯具型号、数量及安装要求、预约时间段与工期限制技术注解三问采的全是「规则」而非「数据」。数据哪张单、哪个师傅在运行中自然产生规则超时怎么赔、质保怎么认不显式声明就是歧义歧义就是纠纷。规则来自覃老板吃过的亏——「按单计赔」那条就是去年一次师傅放鸽子、客户等到半夜换成了差评换来的。问答环节的本质把教训显式化为守卫条件教训只有变成守卫才不会重演。四、生成展开确定性变换的舞台口径确认后系统当天生成完毕。生成总览角色①店长 / 调度员负责录入客户订单信息手动将安装任务指派给合适的安装师傅跟进整体进度与异常处理可操作客户订单、安装反馈单、灯具目录、安装任务单、派工总览②安装师傅接收被指派的安装任务按预约时间上门施工完成后填写现场情况并提交反馈可操作安装反馈单、物料领用单、安装任务单表单①客户订单存储客户购买灯具后的基础下单信息②灯具目录维护店内所有可安装灯具的基础资料③安装师傅档案记录安装师傅的基本信息与擅长领域④安装任务单依据客户订单生成具体派工单由店长确认⑤安装反馈单安装师傅完工填写的现场结果记录⑥物料领用单记录上门安装时领用的辅助材料⑦客户回访记录安装完成后对客户满意度回访登记工作流安装任务单流程店长 / 调度员发起安装任务提交店长确认审批通过流程结束审批拒绝退回重新编辑加看板、规则、智能体。一处小瑕疵订单单默认生成了「客户生日」字段——灯具是低频消费几年买一次生日营销无意义。覃老板说了一句「订单单去掉客户生日」当天撤掉不留痕迹。技术注解生成环节之所以快是因为它是确定性变换——实体到表单、流程到状态机、规则到守卫条件的映射全部无歧义歧义在前两个环节已消灭。确定性变换是机器的舒适区快是架构的自然产出不是加班赶出来的。传统开发慢恰恰慢在用人力做非确定性的事理解需求、对齐口径把确定性的部分编码也串进了人的时间线里。生成路径的分工很清楚人做非确定性的前段说清、校准、立规机器做确定性的后段展开、组装、部署——各守一段互不越界。五、验收真实业务的回归测试验收拿当天真实订单走一单水晶灯销售造型安装派工、一单筒灯补购基础安装、一次质保期内的维修回单查询验质保认定。三单走通手工台账当晚退役。技术注解验收的工程学身份是「真实业务回归测试」——测试用例不是造的是当天的生意。真实业务自带边界情况造型安装的工时系数、陈列品调拨、质保认定的日期边界模拟数据永远想不全。这种测试的覆盖率天然高于验收演示演示测的是「给你看的路径」真实业务测的是「实际会走的路径」。六、运行与迭代对话式修改的通道一个月运行记录派工冲突为零两个师傅的时间表系统排排重拦截库存账实相符率从七成到百分之百出库扫码扣减质保纠纷四起全部秒判回单日期一键可查。三处对话式修改造型安装增加「高空作业备注」师傅要带梯子的单子提前提示质保查询增加「客户自助入口」客户自己扫码查质保不用打电话出库增加「整箱拆零登记」筒灯射灯常拆零卖。三处都是一句话发起当天生效。技术注解对话式修改让系统从「交付即固化」变成「持续对话的产物」。修改成本趋近于零带来一个深刻变化需求变更不再走变更流程而是走使用流程——系统跟着业务长过时速度被对话迭代抵消。传统系统上线即开始贬值业务在变、系统不变生成系统的贬值曲线被修改通道拉平了。七、边界生成能力的硬边界负责任的拆解必须给边界灯具店的安装派工是标准业务边界内。边界外三样接收银系统厂商的开放接口数据打通要走厂商、对接物流公司的发货系统、做门店的客流动线分析要摄像头硬件——这些是集成工程和定制开发找软件公司以月计。覃老板的边界观很清醒「接口的事俺不掺和俺的生意在边界内够用。」八、结论不会写代码的人为什么能生成系统回到标题。答案分两层。表层生成路径把「写代码」从用户的必备技能变成了系统的内部实现——覃老板全程没见一行代码正如开车的人不需要见过发动机图纸。深层生成路径把系统工程的复杂度重新分配了——非确定性的部分理解、对齐、立规交给人用自然语言完成确定性的部分展开、组装、部署交给机器自动完成。人只做判断机器只做执行各守一段。这个分工对工程读者的启示不要问「AI 会不会写代码」要问「AI 把编码这个环节变成了什么」。答案变成了确定性变换——而确定性从来就是机器的领地。常见问题Q1一句话需求会不会漏关键信息会漏但漏不掉方案说明会把打算逐条列出漏的显形引导问题会问关键规则漏的被问。覃老板的「陈列品」口径就是方案核对时他自己纠出来的方案没提他看到了说了一句就改了。Q2两种安装类型的工时系数系统怎么处理派工单带安装类型字段基础和造型各自的工时系数独立配置派工时自动按类型折算。师傅的绩效和客户的报价都从同一个系数取数——一数一源不打架。Q3安装师傅要装应用吗不用轻入口扫码接单、导航、拍照回单三步走。师傅平均年龄四十五岁上手零障碍——外部角色的操作步数越少配合度越高这条交互原则生成的系统同样遵守。Q4质保期内的维修怎么防扯皮回单照片带安装日期质保期从回单起算扫码即查——四起质保咨询全部秒判无一扯皮。过去靠记忆和微信翻记录现在靠时间戳证据链完整。Q5库存账对不上一直是老毛病真能治能机制变了出库扫码实时扣减、陈列品单独状态、整箱拆零有登记——每个环节都有账目可查账实不符失去了生存空间。上线一个月账实相符率百分之百。Q6别的店适用吗适用。口诀不变说得清「什么东西、经过哪几步、谁经手」就适合。灯具店是「灯具、销售到安装售后、店员师傅客户」窗帘安装、家电配送安装、卫浴施工同一套「销售带派工」逻辑。要接厂商开放接口的找软件公司——边界就是说明书。