企业官网建设流程全解析

先说明一下这篇东西的来历。我自己手头一直维护着一套小型的商贸业务，商品种类不算多，但进货、出货、库存、客户欠款这几摊事全靠Excel和微信来回传，时间一长问题全出来了：库存数对不上、哪个客户还欠多少钱没人说得清、月底一对账能折腾好几天。中间也想过直接上市面现成的进销存软件，但要么功能冗余操作繁琐，要么数据在自己手里不踏实，定制一版又贵得离谱。后来咬咬牙，自己动手设计了一套进销存管理系统，并且把整个开发过程中用到的那套“可复用开发提示词”沉淀了下来。这篇就聊聊我是怎么从零梳理业务需求、拆解MVP边界、设计提示词结构，到最后让这套系统真正跑起来支撑日常业务的。文章不聊过于底层的语法细节，重点放在思路和可落地的方案上，尤其是那套提示词，拿走就能当作和AI协作开发的起点。

1. 为什么一个“小破系统”非要自己开发：从业务痛点反推MVP边界

先讲个扎心的事实：大部分小体量商家需要的根本不是功能大而全的ERP，而是一个“数据不再靠人肉记忆和Excel硬扛”的工具。如果我们一上来就想着把采购、销售、仓库、财务、报表、权限全部做齐，那这个项目大概率会烂尾，因为需求永远在膨胀，而投入的时间永远不够。

我自己的业务是这样的：每个月有几十个SKU在流转，供应商大概六七家，客户群体里有一部分是长期拿货的熟客，存在“先货后款”的结算方式。日常最痛的点就三个：

1. 每次进货之后库存数量靠手工改表格，卖出去了又要再改一次，稍微忙起来漏改一次，月底盘点就对不上。
2. 熟客拿货经常是“记一笔”，但记在微信聊天记录里，到底欠多少、什么时候该催款，全凭脑子。
3. 想看一眼某个商品的毛利、某个供应商一共进了多少货，得把几份表格翻来覆去地透视筛选，费时间。

所以当我决定开发这套“蓝动记·进销存管理系统”时，第一条原则就是：先框死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在“进货单保存”这个任务上的提示词差异，以及最终效果差别：

3.3 提示词不是一次写好的，版本管理同样重要

我自己把这套提示词当成一个会进化的“活文档”来管理，放在项目docs/prompts/目录下，命名类似01_系统总览.md、02_商品模块.md、03_进货模块.md。每次开发中如果发现AI理解偏差，或者我自己补充了新的业务规则，就回头更新对应模块的提示词，而不是只在对话里纠正一次。因为对话是易逝的，下次重建会话时，这些纠正如果没沉淀回文档，就等于丢掉了。

4. MVP落地实测：从代码生成到真正跑通的几个关键节点

理论说了那么多，回到实际操作。我利用那套提示词，大概花了四个周末的时间，把“蓝动记”的MVP做了出来。技术栈前面说了，FastAPI + SQLite + Vue3（CDN模式），部署在一台小云服务器上，日常我和店员通过浏览器访问。这里重点说说几个真正决定系统能不能“活下来”的关键节点。

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，技术能力不是最大瓶颈，结构化表达业务的习惯才是。把这套提示词文档当项目一等公民来维护，你会发现后续每一次开发、每一次需求变更、每一位新协作者进场，都能站在同一份“认知基座”上，不用反复解释，不用重复踩坑。