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