先说明一下这篇东西的来历。我自己手头一直维护着一套小型的商贸业务商品种类不算多但进货、出货、库存、客户欠款这几摊事全靠Excel和微信来回传时间一长问题全出来了库存数对不上、哪个客户还欠多少钱没人说得清、月底一对账能折腾好几天。中间也想过直接上市面现成的进销存软件但要么功能冗余操作繁琐要么数据在自己手里不踏实定制一版又贵得离谱。后来咬咬牙自己动手设计了一套进销存管理系统并且把整个开发过程中用到的那套“可复用开发提示词”沉淀了下来。这篇就聊聊我是怎么从零梳理业务需求、拆解MVP边界、设计提示词结构到最后让这套系统真正跑起来支撑日常业务的。文章不聊过于底层的语法细节重点放在思路和可落地的方案上尤其是那套提示词拿走就能当作和AI协作开发的起点。1. 为什么一个“小破系统”非要自己开发从业务痛点反推MVP边界先讲个扎心的事实大部分小体量商家需要的根本不是功能大而全的ERP而是一个“数据不再靠人肉记忆和Excel硬扛”的工具。如果我们一上来就想着把采购、销售、仓库、财务、报表、权限全部做齐那这个项目大概率会烂尾因为需求永远在膨胀而投入的时间永远不够。我自己的业务是这样的每个月有几十个SKU在流转供应商大概六七家客户群体里有一部分是长期拿货的熟客存在“先货后款”的结算方式。日常最痛的点就三个每次进货之后库存数量靠手工改表格卖出去了又要再改一次稍微忙起来漏改一次月底盘点就对不上。熟客拿货经常是“记一笔”但记在微信聊天记录里到底欠多少、什么时候该催款全凭脑子。想看一眼某个商品的毛利、某个供应商一共进了多少货得把几份表格翻来覆去地透视筛选费时间。所以当我决定开发这套“蓝动记·进销存管理系统”时第一条原则就是先框死MVP的边界砍掉所有不是“刚需中的刚需”的功能点。整个MVP只需要做四件事——商品档案管理、进货入库、销售出库、客户欠款追踪。至于员工权限、多仓库、序列号追踪、复杂的财务报表全部放到V2再说。有人可能会问“那系统上线之后发现需要别的功能怎么办”这个问题我在设计之初就想清楚了MVP的架构和提示词都刻意留了扩展口后续加模块不需要推翻重来。这也是“MVP”真正的意义不是永远做一个小东西而是先用最小成本把核心链路跑通验证模式和习惯再逐步生长。2. 开发之前的业务梳理先把线下流程画成一张“数据流向图”很多第一次做管理系统的人容易犯一个错误上来就想数据库表结构想字段。但实际上数据库设计如果不基于业务流程做出来的表就是一堆孤立的格子连不起来。我在动手写开发提示词之前先花了大概两天时间把现有的线下业务完完整整梳理了一遍。2.1 从“进货”到“销售”一条链路的数据变化我画了一张极其朴素的流程草图核心就五条线商品从供应商那里到货我创建一个“进货单”记录进了哪些货、单价多少、数量多少、总共多少钱。仓库库存同步增加此时要区分“采购入库”带来的增加。客户来拿货我创建一个“销售单”记录卖了哪些商品、按什么价格卖、收了多少钱。库存同步减少并且系统要能判断库存够不够。如果不收全款系统自动记录一笔“客户欠款”后续收款时逐笔核销。这五条线听起来简单但落地到系统里就必须细化很多规则。比如进货单能不能在保存之后修改销售单保存之后库存扣减是同步发生还是可以异步退货的场景MVP到底做不做这些问题如果不提前定义清楚写提示词的时候AI就会问东问西或者按它自己的默认逻辑来最后和实际业务对不上。2.2 定义“商品”这个概念别把简单事情搞复杂业务梳理过程中最容易纠结的就是“商品”到底怎么建模。一箱矿泉水、一瓶矿泉水、一提卷纸这些算几个SKU我的建议是MVP阶段一律按最小包装单位建档案单位字段单独保留。比如卷纸就按“提”入档进货时供应商按“件”卖那就在进货单里做一个“折算换算”的手动输入件数乘以单件含提数算出最终入库的提数。这样设计的好处是简单直接不需要做双单位、多单位换算这种在ERP里常常费力不讨好的功能。代码层面对应的就是product表里加一个unit字段再用一个进货明细表里加一个conversion_quantity字段记录折算系数。全部逻辑摊开不超过十几行代码但业务上完全够用。2.3 把“欠款”作为显式实体而不是销售单的一个状态这是我这次设计里自认为最明智的一个决定。如果只是给销售单加一个“是否已收款”的布尔字段虽然也能知道客户欠没欠钱但“欠款总额”“客户历史还款记录”“分笔核销”这些事情全都做不灵活。所以我在MVP阶段就单独设计了一个receivable表每一笔“先货后款”的销售在保存后自动生成一条应收记录状态为“未核销”收到钱时生成一条收款记录去关联核销。这样一个简单的设计让“客户欠款追踪”这个需求变得特别清晰查一个客户的欠款就是查它的应收记录里状态为未核销的那些统计总欠款就是这些记录的sum。后来的实操证明这个小小的建模决策节省了大量返工时间。3. 这套“可复用开发提示词”是怎么写出来的结构、语法与踩坑经验标题里有个关键词是“可复用开发提示词”说实话这是整套项目里投入产出比最高的一部分资产。所谓“可复用开发提示词”不是说把一句魔法咒语复制到任何AI工具里就能生成整个系统而是一套结构化的需求描述框架让AI在每次协作时都能准确理解项目背景、当前任务、技术约束和验收标准避免每次从零开始解释。3.1 一份提示词该拆成哪几个固定区块我打磨了很多版之后把提示词固定成了下面这几个区块顺序基本不变项目定位与背景一句话说清楚“这是什么项目、给谁用、解决什么问题”大概2到3句话。技术栈约定明确语言、框架、数据库、部署方式。比如我的MVP用的是Python FastAPI SQLite Vue3前端用简单CDN方式引入不搞node构建这些信息写死AI就不会自由发挥选一个它熟悉但你不熟悉的技术组合。当前任务描述明确本轮要让AI做什么比如“新增一个进货单保存接口”“创建商品列表页面”。输入输出约定接口的入参、返回结构或者页面上需要展示哪些字段、按钮。业务规则这一块是最重要的凡是涉及状态变更、库存增减、权限校验的规则全部逐条写清楚。验收标准告诉AI“做成什么样算完成”。比如“在商品列表页输入关键词可以模糊搜索商品名称和编码展示结果应包含库存余量”。有人会问“直接把这么长的提示词每次都丢给AI不会浪费token吗”实际上大部分AI工具都支持多轮对话这套提示词只需要在每次新建会话时完整贴一次之后的增量开发就基于同一会话继续下去不需要反复整套重新贴。而对于会话可能丢失、需要开新会话的情况把提示词作为一个markdown文件放在项目根目录里随时可以复制。3.2 我踩过的提示词大坑与改进版本对照最早的V1版提示词我写得特别简略就写了句“帮我做一个进销存系统有进货、销售、库存、客户管理”。结果AI给了我一套典型的通用脚手架功能看起来都有但没有一个符合我的实际业务更重要的是它不理解“客户先货后款自动生成应收记录”这种隐含需求。返工成本极高。后来改成像上面那样的结构化版本问题大幅减少。但还有一个新坑提示词里如果不明说“MVP暂时不做退货功能”AI会在各种看似合理的地方自作主张加上退货入口导致界面和接口多出一堆没用的东西。经验就是边界规则必须反向列出不仅要写“系统要做什么”还要写清“本阶段明确不做什么”AI才不会乱发挥。下面用一个对比表格来说明V1和V2在“进货单保存”这个任务上的提示词差异以及最终效果差别对比项V1草率版V2结构化版任务描述做一个进货单保存接口新增POST /api/purchase/orders接口保存进货单主表和明细表同一个请求事务完成业务规则无保存时校验商品存在库存增加供应商不存在则报错主表状态为“已入库”数据字典无主表字段purchase_no, supplier_id, total_amount, created_at明细字段product_id, quantity, unit_price, subtotal验收标准能通用示例JSON调用接口数据库purchase_orders和purchase_order_items同时新增记录库存同步加实际效果返回的代码逻辑正确但缺库存联动且字段名和我的其他模块不统一一次通过接口和既有代码风格一致3.3 提示词不是一次写好的版本管理同样重要我自己把这套提示词当成一个会进化的“活文档”来管理放在项目docs/prompts/目录下命名类似01_系统总览.md、02_商品模块.md、03_进货模块.md。每次开发中如果发现AI理解偏差或者我自己补充了新的业务规则就回头更新对应模块的提示词而不是只在对话里纠正一次。因为对话是易逝的下次重建会话时这些纠正如果没沉淀回文档就等于丢掉了。4. MVP落地实测从代码生成到真正跑通的几个关键节点理论说了那么多回到实际操作。我利用那套提示词大概花了四个周末的时间把“蓝动记”的MVP做了出来。技术栈前面说了FastAPI SQLite Vue3CDN模式部署在一台小云服务器上日常我和店员通过浏览器访问。这里重点说说几个真正决定系统能不能“活下来”的关键节点。4.1 商品档案先于一切没有干净的档案后面的单据全是垃圾第一周我做的不是进货也不是销售而是先把“商品档案”这个模块做得足够扎实。依次包括商品编码、商品名称、规格型号、单位、默认进货价、默认销售价、当前库存、状态启用/停用、备注。其中商品编码我设计成手工录入而不是系统自动生成因为实际业务里不同供应商都有自己的货号我沿用自己熟悉的内部编码更顺手。这里有个经验MVP阶段的“商品档案”一定要给“停用”这个状态留位置。因为有些商品可能暂时不卖了但历史上有过交易记录如果直接删除会破坏历史单据的关联停用则既能避免再次被选择又保住了历史链路。这个字段在V1就加上是当时一个很有效的决策。4.2 进货入库库存联动的核心逻辑与事务边界进货模块的功能并不复杂页面就是一个主表单加一个明细表格提交时把整个JSON发送给后端。后端拿到之后先做几件事校验供应商存在、循环校验每个商品存在、计算总金额、写入主表、写入明细表、循环更新商品库存。这几步如果有一个失败必须整体回滚所以我把它们包在一个数据库事务里。实测中最容易出bug的位置反而是前端明细表里面如果用户新增了5行只填了3行提交时是否要把空行过滤掉提交按钮点击后怎么防止重复提交这些业务上极其琐碎但严重影响使用体验的点必须在提示词的“当前任务描述”里写明白不然生成的前端代码会在这些边角上反复出问题。4.3 销售出库与欠款一张单子同时触发两条数据链路销售模块是整个系统的核心也是提示词里最长的部分。销售单保存后要同时做三件事库存扣减、生成应收记录如果未收全款、记录收款记录如果收了一部分或全部。我预设了三种收款方式全部收款、部分收款、未收款分别对应不同的数据库写入策略。第一次实测就发现了一个边界bug客户拿货10件单价5元总共50元客户说先付20那我希望系统自动生成30元的应收金额。但AI生成的代码里“应收”和“已收”两个字段都被记录在了receivable表和收款表里逻辑上确实没有问题只不过界面上显示的“应收金额”需要动态计算而不能直接读某个字段。这也是一个典型的“逻辑正确但体验绕”的问题后来在提示词里加了一条说明“应收余额应收总额-累计已核销金额展示时动态计算”才彻底解决。4.4 报表先行还是靠查询MVP阶段别滥用报表模块很多进销存系统特别爱把“报表中心”当卖点但MVP阶段我故意没有做专门报表页面。日常需要的“某个商品库存是多少”“某个客户欠多少钱”靠列表页的筛选、搜索就能满足真正到月底汇总直接导出JSON转Excel处理。我宁可先省下做报表的时间去把单据新增、编辑、列表查询的体验打磨顺。后来我用了一个简单但实用的办法做了一个统一的“统计接口”接收日期范围、商品、客户几个可选参数返回销售总额、进货总额、毛利估算。前端就是一个带筛选条件的简单表格页面。这样虽然离“数据可视化大屏”差得远但对一个日单量不大的业务来说已经能解决90%的统计需求。5. 把系统推到生产环境时的细节数据备份、账号安全与日常习惯系统本地跑通是一回事真正被日常业务依赖是另一回事。MVP验证完之后我花了一个下午做生产化梳理这里面的坑也很有代表性值得单独说一说。5.1 数据库备份SQLite也可以有正经的备份策略我用的SQLite数据库本质上就是一个文件备份最简单直接的做法就是定期把那个文件复制走。我定义了一条crontab规则每天凌晨两点把数据库文件复制到另一个目录再同步一份到私有网盘保留最近30天。这个策略虽然原始但效果直接。后来我又增加了一个“导出归档数据”的后台功能可以一键把近三个月内的关键表数据导出成JSON文件下载。这样即使服务器出现不可恢复的故障我手里还有一份结构化的数据副本可以用来重建。5.2 登录权限MVP阶段的身份验证不必复杂但不能没有进销存数据是典型的商业敏感数据如果系统裸奔在公网上任何人知道地址都能打开看到库存、价格、客户信息那绝对不行。我在MVP阶段就加了一个最简单的账号密码登录后台管理员账号由配置文件中的环境变量初始化密码使用哈希存储。没有做角色分级所有人都用同一个管理员账号操作。当然这是MVP的权宜之计。真正常态化之后至少要拆成“管理员”和“店员”两个角色店员不能看进货价和毛利数据因为进货价属于商业机密看到容易引起不必要的内部矛盾。这个扩展点我在提示词里也写好了等V2时按模块添加。5.3 日常使用中的数据卫生习惯系统上线之后我发现真正让系统数据保持可用的反而不是代码质量而是使用习惯。比如进货单必须当天录不能攒一个星期再补销售单如果当时录错了不要直接在数据库改而是通过“红冲”的方式做一笔负数单据冲掉再录一笔正确的客户名称要统一同一个客户不能今天叫“张三”明天叫“张先生”否则应收统计就乱了。这些数据卫生规则我没有写进代码里而是写成了一份简短的操作规范贴在收银台旁边。有点土但确实有效。系统跑了一个月后月底盘点第一次做到了账面库存和实物库存完全一致那种感觉确实踏实。6. 这套提示词还可以怎样复用从进销存到其他管理系统的迁移思路最后回到“可复用”这三个字。我做这套东西时的另一个目的是想沉淀一套方法论如果以后要给朋友做一个“小型会员管理系统”或者给自家小区做一个“团购订单管理后台”不需要再从零梳理需求而是把同一套提示词框架套上去替换领域术语和业务规则AI就能在很短的时间内搭出新的MVP。6.1 提示词框架的迁移方法论其实所有“管理系统”的底层结构高度相似无非是“对象档案”加“单据流转”加“统计查询”。进销存里的商品档案迁移到会员系统就成了会员档案进货单、销售单迁移到其他领域可能变成充值单、消费单、预约单。但是“主表明细表”的结构、事务操作的思路、状态字段的运用几乎一模一样。所以我在提示词文档里专门写了一个“迁移指引”区块每当要做一个新系统时只需要完成三件事把“项目定位与背景”改成新系统的场景。把“业务规则”中与进销存强相关的部分替换成新系统规则比如从“库存增减”变成“余额增减”。把“当前任务描述”按新系统的页面和接口重新列一遍。6.2 让AI为你打工的正确姿势提示词不是用来“压榨”的是用来“对齐认知”的我见过很多人对AI生成代码的态度很极端要么完全不信要么把AI当成“只要描述够长就能直接交付”的神器。两者都不对。以我的经验AI写代码的正确协作方式是用提示词对齐认知用代码审查兜底用业务测试验证。AI最擅长的是把你已经想清楚的逻辑快速实现成代码而不是替你做产品经理和业务分析。这套提示词框架真正起作用的机制也不是它有多么神而是它强迫我在每个模块之前先把业务规则想得足够清楚。规则越清楚AI生成出来的东西就越接近可用反过来如果我自己都模棱两可AI就只能在云山雾罩的需求里自由发挥最终出来的东西自然不靠谱。最后一句话总结我的体会想做一个“AI辅助开发”的MVP技术能力不是最大瓶颈结构化表达业务的习惯才是。把这套提示词文档当项目一等公民来维护你会发现后续每一次开发、每一次需求变更、每一位新协作者进场都能站在同一份“认知基座”上不用反复解释不用重复踩坑。