拓冰网站定制 
最近想自己动手做一个“商品库存管理系统”的人变多了。很多开网店、做小团队ERP选型、或者刚学Python的读者不是不想用系统而是被传统开发路径劝退了要装数据库要写后端接口要学前端页面还要考虑多人登录、权限、日志……一个简单需求硬是变成了三个月的大工程。现在我们看到了另一个选择用自然语言描述需求让 WorkBuddy 这类 Agent 工具帮你拆任务、生成代码再配合 Python 把系统跑起来。看起来门槛一下被拉低了。但我得先给一个判断WorkBuddy 降低的是“从一句话到系统骨架”的转换成本它不自动解决可靠性问题。一个库存管理系统能不能真正用起来核心不取决于 AI 生成了多少代码而取决于你有没有把“库存不能为负”“出库要有流水”“低库存要预警”这些业务规则梳理清楚。因为 AI 可以帮你写出代码但只有你能定义什么是“正确”。这篇文章会带你走完一条完整路线先理解 WorkBuddy 这类 AI 办公工作台适合做什么再把“帮我做一个库存管理系统”这句话拆成可落地的功能模块和数据库设计然后给出一套基于 Python 标准库 SQLite 的完整可运行代码最后告诉你生成代码之后怎样验证、审查、以及从 Demo 走向生产环境时要补哪些工程能力。就算你现在手边没有 WorkBuddy也可以直接拿文中代码手动跑通。整条路线对得上“AI 辅助开发”和“Python 练手实战”两个方向建议先收藏再阅读。1. WorkBuddy 加 Python 这个组合到底解决了什么问题1.1 不写库存系统的痛苦是需求不明确很多人第一次想开发库存系统脑子里的需求就一句话能增加商品、能登记入库出库、能看到还剩多少货。这句话看起来明白真动手却寸步难行。你打开数据库设计工具会不停反问自己“商品要不要分类同一件衣服有不同颜色怎么处理出库时用户填的数量超过了当前库存该怎么办要不要记录每次操作是谁做的”这些问题不是因为你不懂 Python而是业务规则没有建模。传统的做法是去学一套完整的技术体系MySQL、ORM、RESTful API、前端表格框架……你花大量时间学的技术其实只是为了解决一个“库存增删改查”的小问题。这种成本错配有很强的挫败感。现在WorkBuddy 这类 Agent 工具给了另一种方式你可以在对话里把模糊想法说出来它会把需求转成明确的功能清单、表结构和代码文件。这不等于你不用思考而是把你的思考变成一次“对话式澄清”比面对空白编辑器要轻松很多。1.2 WorkBuddy 加 Python 的关键价值WorkBuddy 不是传统意义上的在线编译器它更像个“办公工作台”。从网上常见的讨论来看它的玩法通常围绕这几件事展开用自然语言生成文档或代码、搭建个人工作台、配合各种“Skill”完成一站式任务执行甚至接 API 处理数据。和单纯帮你补全代码的编程助手相比它的侧重点更接近“把一个模糊任务跑出结果来”。Python 则是实现业务逻辑的好搭档。做库存管理系统这种中小型项目Python 的标准库就赢了一大半socket能写网络服务sqlite3能存数据argparse能处理命令行参数连图形界面也有tkinter可选。你不需要一开始就引入重型框架一个main.py就能把业务流程讲清楚。组合起来这个模式真正价值有三层需求层用自然语言描述AI 负责把它转成结构化任务。你不需要先把话“翻译”成技术术语才能开口。代码层Python 简洁、易读方便人类在 AI 生成结果后进行审查和修改。代码越简单审查成本越低越不容易被 AI 的“幻觉”带偏。验证层没有项目管理系统时你用命令行就能完成业务验证发现问题能立刻回到对话里继续修正。这个组合也适合另一种场景你不是要真的上线一套生产系统而是想验证一个业务流程是否走得通。比如你给自己的小卖部、工作室、社团物资管理做原型验证那用 WorkBuddy 拆需求用 Python 快速实现比动用低代码平台还轻不少。1.3 谁适合用这种方式做库存管理我个人建议按下面这个标准判断不要盲目跟风用户类型适合程度建议完全零基础且没有编程学习意愿不太适合可以先用成熟进销存软件AI 生成代码后你不会排错就没法用Python 刚入门想拿项目练手很适合用 AI 生成骨架再逐行阅读修改练习效果极好小团队、店铺需要内部原型很适合快速做出可交互 Demo确认业务流程后再决定是否正式开发有一定工程经验接外包或个人项目适合把 AI 当结对程序员关注点放在系统设计和代码审查上需要高并发、强事务的电商系统不适合应设计专业后端、分库分表甚至消息队列不在这篇文章范围你会发现WorkBuddy 加 Python 解决的最大问题是“从模糊想法到可运行系统”的跃迁成本。它不能替你做工程决策也不能让一台电脑瞬间变成高可用服务器。1.4 别用错场景它不是万能资料库网上搜索“WorkBuddy”时会有不少非官方流出的清单、所谓“大学推荐”内容看起来像是什么都能查的资料库。这里要提醒一句WorkBuddy 这类产品定位是办公和开发提效工具不是你人生的“万能查询机”。如果你把使用目标定义成“让它直接告诉我某门课程的结论”那可能用错了方向。尤其在生成代码时你要把它理解为“一个能快速起草的初级工程师”而不是“权威编译环境”。它写出来的代码可能有细节错误、可能有版本兼容问题、甚至可能在某个业务规则上自作聪明。能不能容忍这些错误取决于你有没有能力在关键位置做审查。读完下一章节你会更清楚 WorkBuddy 的核心能力和边界在哪里。2. WorkBuddy 能做什么一次理解它的核心概念2.1 WorkBuddy 不是 IDE而是“任务执行工作台”IDE 的核心是让你编写、调试、运行代码。WorkBuddy 的定位更宽它试图把 AI 能力组装成一个“能干活的工作台”。你可以在里面做任务规划、生成文档、编写代码借助 Skill 来增强它的专项能力也能把某一段 API 接进来让自动化流程跑起来。用库存管理系统举例在传统 IDE 里你需要自己创建main.py、自己建表、自己写循环。在 WorkBuddy 里你可以先让它生成一份“库存系统开发清单”再让它按清单逐项产出代码。你扮演的角色从“所有代码手写者”变成了“任务拆解者和结果验收者”。这与“自动补全代码”的编程助手有本质区别。CodeBuddy 类编程助手的重心在代码上下文它对当前文件、语法结构、编译错误更敏感而 WorkBuddy 类工作台的重心在任务链路它关心的是“下一步做什么做完要产出什么”。网上经常有人问 CodeBuddy 和 WorkBuddy 怎么选前者偏开发场景后者偏办公和任务自动化场景两者结合起来使用也很常见。2.2 Agent 类工具改变开发的三件事用 AI Agent 类工具做项目和过去“搜索代码、复制粘贴、再改改”完全不同。我认为真正的变化是这三件事第一从“搜资料”变成“查路径”。以前遇到库存管理你会搜“Python 库存管理系统源码”拿到一份看不懂的代码现在 WorkBuddy 会直接给你项目结构建议甚至会告诉你应该先建表再写业务函数最后做菜单。它引导的是一条完整路径不只是单个文件片段。第二从“复制代码”变成“修改代码”。AI 生成的代码必然不是一次到位你需要在理解的基础上修改。这会倒逼你养成读代码的习惯。对初学者来说这是好事因为“读别人代码”本来就是最快的学习方式之一。第三从“只管编码”变成“管完整交付”。工作台会把需求、进度、代码、使用说明串在一起。你把“商品库存管理系统”这句话扔进去它不会只给你零零散散函数它会尝试产出从数据库初始化到业务流程展示的一整套可运行成果。这三点变化意味着你的工作方式要从“让我想想代码怎么写”变成“让我想想需求怎么描述、结果怎么验收”。这正是 AI 时代最值得刻意练习的能力。2.3 必须理解的边界边界也很重要。第一WorkBuddy 生成代码是否真实可靠你需要在隔离环境中验证第二它对项目上下文的理解有限跨很多文件的大型系统它可能顾此失彼第三涉及敏感数据时你不能把生产库的连接信息直接暴露给任何 AI 工具也不能指望 AI 帮你做安全管理。所以下面几节先给你一套稳妥的实践路径环境上隔离、代码上审查、业务上小步验证。3. 用 WorkBuddy 搭建“一句话需求”的完整工作流3.1 环境准备无论你是打算主要用 WorkBuddy 生成代码还是手动敲代码本机环境都要先准备好。在 Windows 上推荐直接从 Python 官网下载安装包或使用 Microsoft Store 的 Python 安装入口安装时勾选“Add Python to PATH”把 Python 加入系统环境变量。在 macOS 上可以安装 Homebrew 后执行brew install python。在 Linux 上一般可以用系统自带的包管理器安装比如 Ubuntu/Debian 系统执行sudo apt update sudo apt install python3 python3-pip安装完成后在终端验证版本python3 --version注意Windows 上命令可能是python --version。如果你希望后续用虚拟环境管理项目依赖可以再执行python3 -m venv inventory_env source inventory_env/bin/activate # Linux / macOS # Windows PowerShell 下执行 inventory_env\Scripts\Activate.ps1WorkBuddy 的环境则要看产品当前版本的实际情况。常见做法是登录官方客户端或网页端在“工作台”或“项目”中新建一个专门项目后续对话、生成文件、业务梳理都放在同一个项目空间里。不同版本入口名称可能不一样不纠结细节核心是让整个开发过程有上下文连续性。3.2 需求描述模板不要直接输入“给我做一个库存系统”那样得到的东西大概率很空。更好的做法是给足业务上下文。下面这个模板可以套用请你扮演一个 Python 开发工程师帮我设计一个商品库存管理系统的 MVP 版本。 业务背景我经营一家小网店主要记录商品库存变化目前只需要单机命令行程序。 技术约束 1. 使用 Python 3数据库使用标准库 sqlite3尽量不依赖第三方库 2. 数据表要区分“商品资料表”和“库存变动流水表” 3. 出库操作必须先判断库存是否充足不足时禁止出库并给出明确提示 4. 入库、出库都要留下流水方便追溯 5. 系统要支持低库存预警低于阈值时在商品列表里提示。 交付要求 1. 先给数据库设计再给业务代码 2. 代码要能直接运行 3. 最后写三行最简使用说明。你会发现这个 Prompt 里除了功能需求还包含了业务规则和技术约束。AI 看到的信息越多产出才越贴近实际。3.3 分步提问而不是要求一次生成几十个文件和 AI 协作有个显著误区一次性要求它生成完整项目看起来省事实际排错时很痛苦。更稳妥的方式是分步进行第一步让它输出“数据库表结构和字段解释”。你确认字段是否满足业务比如有没有 SKU、分类、当前库存、低库存阈值。确认后进入下一步。第二步让它输出“数据库初始化和调用函数”。你要检查代码是否真的能建表。第三步让它输出“入库出库业务函数”。这里要重点人工审查库存判断逻辑。第四步让它输出“命令行主程序”。这样即使某个步骤出现错误你也能快速定位在哪一步。AI 不会觉得你烦它没有耐心问题但你过度压缩步骤只会把问题复杂度集中到自己身上。跑通 MVP 后再继续提出“增加盘点功能”“增加导出功能”“增加搜索功能”。一个功能一个功能地加比一次做完更能保证质量。这也是我把代码拆成几个小节来写的原因。4. 商品库存管理系统从自然语言到数据建模4.1 拆解一句话需求把“帮助我做一个库存系统”这句话拆开你会发现里面其实藏着以下模块功能模块自然语言里的依据需要做的事商品管理“能添加商品”新增、编辑、查询、删除商品资料入库管理“能登记进货”增加库存记录入库流水出库管理“能登记卖出”校验库存后减少库存记录出库流水库存查询“能知道现在还剩多少”按商品或分类查询当前库存低库存预警“快没货了提醒我”对比在库量与阈值输出预警清单流水追踪“以后能查历史记录”记录每次入库出库前后的库存量变化这个拆解最好让 WorkBuddy 先做一遍你在旁边对比是否合理。它列出的东西一般比较完整但可能缺“盘点调整”“删除保护”“日志记录”等细节。在 MVP 阶段我们可以先做好上面六件事后面扩展。4.2 业务规则比建表更先确定开发库存系统最核心的不是“建几张表”而是“定义什么操作是合法的”。我强烈建议你在写任何代码前把下面规则用文字写下来商品必须有唯一 SKU重复 SKU 不能再次插入。入库数量必须大于 0。出库数量必须大于 0且不能大于当前库存。每次库存变动都要记录变动前后的数量。删除商品时不建议物理删除数据可以采用“下架”或“停用”方式避免流水表失去关联。这些规则你是准备让 AI 猜还是一开始就写进 Prompt如果写进 PromptAI 的产出准确率高得多如果不写AI 的默认实现通常比较简单可能压根不校验出库库存是否足够到上线时才发现能卖出超过库存的商品。一个教训是库存系统是“账实一致”问题不是“增删改查”问题。你代码里每一条业务约束都对应现实中一次可能的盘亏或超卖事故。4.3 数据库设计MVP 阶段用 SQLite 足够。它能把整个数据库存在一个本地文件里比如inventory.db不用单独安装数据库服务适合学习和小规模单机使用。我建议设计两张表。商品表products字段名类型说明idINTEGER 主键自增内部主键skuTEXT 唯一商品编码如 KG001nameTEXT商品名称categoryTEXT分类如“食品”priceREAL单价quantityINTEGER当前库存数量low_stock_thresholdINTEGER低库存预警阈值默认 5created_atTEXT创建时间流水表stock_logs字段名类型说明idINTEGER 主键自增流水主键skuTEXT商品编码change_typeTEXT变动类型in / out / adjustquantityINTEGER变动数量before_quantityINTEGER变动前库存after_quantityINTEGER变动后库存noteTEXT备注记录原因created_atTEXT变动时间为什么流水表要记录before_quantity和after_quantity因为你做审计时经常需要知道“这次操作之后结果对不对”。如果只记录变动数量就很难在事后发现问题。这是很多库存 Demo 里缺失的关键细节。5. Python 完整代码实现一个可以直接运行的库存系统为了让代码结构清楚我拆分成了三个文件db.py负责数据库操作inventory.py负责业务函数main.py负责菜单交互。你完全可以手动创建这些文件也可以把这些代码作为审查基准去对比 WorkBuddy 生成的结果。如果你直接复制运行代码是完整的。我刻意保持了简单的 CLI 界面方便你专注业务逻辑。5.1 项目结构准备inventory_system/ ├── db.py ├── inventory.py ├── main.py └── inventory.db # 运行后自动生成在项目目录中创建db.py。5.2 数据库初始化模块# 文件路径inventory_system/db.py import sqlite3 DB_NAME inventory.db def get_connection(): conn sqlite3.connect(DB_NAME) conn.row_factory sqlite3.Row return conn def init_db(): conn get_connection() try: conn.executescript( CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY AUTOINCREMENT, sku TEXT UNIQUE NOT NULL, name TEXT NOT NULL, category TEXT DEFAULT , price REAL NOT NULL DEFAULT 0, quantity INTEGER NOT NULL DEFAULT 0, low_stock_threshold INTEGER NOT NULL DEFAULT 5, created_at TEXT DEFAULT (datetime(now, localtime)) ); CREATE TABLE IF NOT EXISTS stock_logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, sku TEXT NOT NULL, change_type TEXT NOT NULL, quantity INTEGER NOT NULL, before_quantity INTEGER NOT NULL, after_quantity INTEGER NOT NULL, note TEXT DEFAULT , created_at TEXT DEFAULT (datetime(now, localtime)) ); ) conn.commit() finally: conn.close() if __name__ __main__: init_db() print(数据库初始化完成)这里用row_factory sqlite3.Row让查询结果支持按字段名取值代码更可读。executescript可以一次执行多条建表语句但要注意 SQLite 的事务行为示例中是幂等建表没有风险。运行一次python db.py看到数据库初始化完成说明inventory.db已经创建。5.3 商品管理与库存事务模块业务层是所有规则最集中的位置。我建议把入库、出库、库存调整这类会修改库存的操作全部收敛到inventory.py不要让主程序自己写 SQL。这样后续加权限、加日志、换数据库都更轻松。# 文件路径inventory_system/inventory.py from db import get_connection def add_product(sku: str, name: str, category: str , price: float 0.0, low_stock_threshold: int 5): conn get_connection() try: conn.execute( INSERT INTO products (sku, name, category, price, low_stock_threshold) VALUES (?, ?, ?, ?, ?) , (sku, name, category, price, low_stock_threshold), ) conn.commit() except sqlite3.IntegrityError: raise ValueError(fSKU {sku} 已存在不能重复添加) finally: conn.close() def list_products(): conn get_connection() try: rows conn.execute( SELECT * FROM products ORDER BY sku ).fetchall() return [dict(row) for row in rows] finally: conn.close() def stock_in(sku: str, quantity: int, note: str ): if quantity 0: raise ValueError(入库数量必须大于 0) conn get_connection() try: row conn.execute( SELECT quantity FROM products WHERE sku ?, (sku,) ).fetchone() if row is None: raise ValueError(f商品 {sku} 不存在请先添加商品) before_qty row[quantity] after_qty before_qty quantity conn.execute( UPDATE products SET quantity ? WHERE sku ?, (after_qty, sku), ) conn.execute( INSERT INTO stock_logs (sku, change_type, quantity, before_quantity, after_quantity, note) VALUES (?, in, ?, ?, ?, ?) , (sku, quantity, before_qty, after_qty, note), ) conn.commit() finally: conn.close() def stock_out(sku: str, quantity: int, note: str ): if quantity 0: raise ValueError(出库数量必须大于 0) conn get_connection() try: row conn.execute( SELECT quantity FROM products WHERE sku ?, (sku,) ).fetchone() if row is None: raise ValueError(f商品 {sku} 不存在请先添加商品) before_qty row[quantity] if quantity before_qty: available before_qty raise ValueError(f库存不足当前库存 {available}无法出库 {quantity}) after_qty before_qty - quantity conn.execute( UPDATE products SET quantity ? WHERE sku ?, (after_qty, sku), ) conn.execute( INSERT INTO stock_logs (sku, change_type, quantity, before_quantity, after_quantity, note) VALUES (?, out, ?, ?, ?, ?) , (sku, quantity, before_qty, after_qty, note), ) conn.commit() finally: conn.close() def low_stock_list(threshold_override: int None): conn get_connection() try: if threshold_override is not None: rows conn.execute( SELECT * FROM products WHERE quantity ? ORDER BY quantity ASC, (threshold_override,), ).fetchall() else: rows conn.execute( SELECT * FROM products WHERE quantity low_stock_threshold ORDER BY quantity ASC ).fetchall() return [dict(row) for row in rows] finally: conn.close()这个模块里有三个非常关键的设计值得一一说明。第一个是入库逻辑中的“先查库存再更新库存”。表面看这个流程是“查询—计算—更新”。在单机 SQLite 场景下这个操作基本安全但在多人并发场景下你需要用事务锁或者条件更新防止超卖。文章后面会继续讲。第二个是出库逻辑的库存校验。第 35 行到第 38 行必须判断quantity before_qty。很多 AI 生成的简化代码会允许库存变成负数这是绝对不能接受的。库存系统中的“负库存”意味着账目失真也意味着超卖事故的隐患。第三个是每次库存变动都写入流水。写流水时把变动前、变动后都记下来这样你能复盘任意时刻的库存变化过程。5.4 命令行主程序模块接下来写main.py提供一个清晰的交互菜单让用户能直接体验整个库存管理流程。# 文件路径inventory_system/main.py from db import init_db from inventory import ( add_product, list_products, stock_in, stock_out, low_stock_list, ) from inventory import stock_logs # 如果扩展了流水函数 def print_products(products): if not products: print(当前没有商品数据) return print(\n * 100) print(f{SKU:12}{名称:20}{分类:12}{单价:10}{库存:8}{预警线:8}) print(- * 100) for p in products: flag if p[quantity] p[low_stock_threshold]: flag 低库存 print( f{p[sku]:12}{p[name]:20}{p[category]:12} f{p[price]:10.2f}{p[quantity]:8}{p[low_stock_threshold]:8}{flag} ) print( * 100) def main(): init_db() print(欢迎使用商品库存管理系统) print(输入对应数字进行操作) while True: print(\n请选择功能) print(1. 添加商品) print(2. 商品列表) print(3. 入库) print(4. 出库) print(5. 低库存预警) print(0. 退出) choice input(请输入编号).strip() try: if choice 0: print(系统已退出) break elif choice 1: sku input(请输入 SKU).strip() name input(请输入商品名称).strip() category input(请输入分类).strip() price float(input(请输入单价).strip()) threshold int(input(请输入低库存阈值默认5).strip() or 5) add_product(sku, name, category, price, threshold) print(f商品 {sku} 添加成功) elif choice 2: print_products(list_products()) elif choice 3: sku input(请输入 SKU).strip() qty int(input(请输入入库数量).strip()) note input(请输入备注可留空).strip() stock_in(sku, qty, note) print(f{sku} 入库 {qty} 件成功) elif choice 4: sku input(请输入 SKU).strip() qty int(input(请输入出库数量).strip()) note input(请输入备注可留空).strip() stock_out(sku, qty, note) print(f{sku} 出库 {qty} 件成功) elif choice 5: threshold input(请输入要按哪个阈值过滤留空则使用商品自身阈值).strip() if threshold: products low_stock_list(int(threshold)) else: products low_stock_list() print_products(products) else: print(无效编号请重新输入) except ValueError as e: print(f操作失败{e}) except Exception as e: print(f发生未知错误{e}) if __name__ __main__: main()这里from inventory import stock_logs是示例中的占位如果你没有在inventory.py中写过这个函数可以删掉这行。一个更稳妥的办法是把它改成导入流水查询函数并增加“查看流水”功能。为了缩短代码上面主体已经足够跑通库存管理的核心流程。主程序用try...except ValueError捕获业务规则异常这样库存不足、SKU 重复等提示会友好地展示给使用者而不是抛出难懂的堆栈信息。5.5 运行效果与验证在项目目录下执行python main.py系统会进入菜单交互。建议按下面顺序测试一遍核心流程选择“1”添加商品SKUKG001名称苹果分类水果单价5.5低库存阈值10。再次添加同一 SKU观察是否提示“SKU 已存在”。选择“2”查看商品列表确认苹果初始库存为 0并显示“低库存”标记。选择“3”入库 50 件再执行入库 0 件应提示“入库数量必须大于 0”。选择“4”出库 20 件再尝试出库 100 件应提示“库存不足”。选择“2”看到库存此时为 30 件。选择“5”输入阈值 10应看到苹果库存 30 不低于 10不再预警再尝试入库后把库存改成低于 10 的场景。预期输出大致是欢迎使用商品库存管理系统 输入对应数字进行操作 请选择功能 1. 添加商品 ... 请输入编号1 请输入 SKUKG001 请输入商品名称苹果 请输入分类水果 请输入单价5.5 请输入低库存阈值默认510 商品 KG001 添加成功如果哪一步失败优先看两处操作时输入的类型是否合法比如price不能填成字母inventory.py中抛出的ValueError是否被主程序的except正确捕获。6. WorkBuddy 如何生成高质量库存系统代码很多人认为把需求发给 AI然后复制代码就是全部。实际上用 WorkBuddy 做出靠谱库存系统的关键在于“如何组织对话”。6.1 给 WorkBuddy 的提示词模板如果你要用 WorkBuddy 开发同样系统可以参考下面这个更高阶的提示词我在做一个单机版商品库存管理系统使用 Python sqlite3。 请你先不要写代码。先问我不超过三个问题用来确认业务规则。可能的三个方向 1. 商品是否需要分类管理 2. 出库数量大于库存时程序应该直接拒绝还是先进行超卖登记 3. 是否需要记录每一次操作的时间、数量和操作人 在我回答之后按下面的目录生成代码 - db.py数据库初始化products 表和 stock_logs 表 - inventory.py商品添加、列表、入库、出库、低库存预警函数 - main.py命令行交互菜单 要求 - 所有 SQL 都使用参数化查询 - 出库必须判断库存足够 - 每次入库出库都写流水 - 不允许引入第三方库这个模板优先让 AI 澄清业务再生成代码。很多高手与 AI 协同时都采用“先澄清后生成”策略。这能显著减少返工次数。6.2 生成后的代码审查清单拿到 AI 生成的代码后不需要逐行审查但下面几个点必须检查顺序建议固定审查点怎么查为什么重要是否用参数化查询搜索execute(看有没有?占位符拼接防止 SQL 注入风险出库是否有库存校验定位出库函数找if quantity before_qty防止库存在逻辑上变负数库存变化是否写流水搜索INSERT INTO stock_logs没有流水等于失去了审计能力异常处理是否合理看main.py有没有 try/except出现异常时用户无法知道发生了什么数据库连接的打开和关闭搜索close()连接不关闭可能导致程序卡住或文件锁如果 AI 生成的代码不符合上面任何一条不用反驳直接在对话中追问一句“请修改为参数化查询”或“请补充出库库存校验”。6.3 迭代式开发技巧每次只加一个功能。比如先让 AI 完成添加商品和查询商品测试通过后再增量加入库、出库、流水。如果有 Bug把完整报错信息粘贴回对话。AI 对单条错误的修复效果通常不错但不会主动帮你发现隐藏的问题。可以询问“你认为这个系统还会有哪些边界情况”让它充当经验更丰富的开发者。这样你可能得到“重复 SKU 未处理”“float 浮点数会导致价格金额精度问题”“中文输入导致编码问题”等提醒。这些点单独靠新手自己想不出来。7. 常见问题与排查方法新手在运行类似库存系统时最容易遇到下面这些问题问题现象可能原因排查方式解决方案python命令找不到Python 未加入系统 PATH执行python3 --version或重新安装时勾选 PATHWindows 用py -3作为替代启动命令中文乱码终端编码不是 UTF-8在终端执行chcp 65001Windows将 Python 文件头部加# -*- coding: utf-8 -*-或改系统区域设置sqlite3.OperationalError: no such table没有先执行db.py或没有调用init_db()查看项目根目录是否有inventory.db执行一次python db.py初始化添加重复 SKU 报错表字段 UNIQUE 约束触发查看异常是否IntegrityError在调用层捕获并转成友好提示商品不存在时库存不足提示不准确查询商品返回 None 后没有抛出异常定位出库函数商品查询逻辑先判断商品是否存在再判断库存程序运行时无反应或卡住数据库连接没有关闭导致文件锁使用完成后关闭连接在业务函数中用finally: conn.close()出库可以变成负数业务函数缺少校验定位出库 SQL Update 前面的判断语句加上if quantity before_qty: raise ValueError(...)排错的关键顺序是先看异常类型再看报错所在文件行号最后再检查业务逻辑。不要一上来就怀疑 AI 能力不足很大程度上是你在调用方式上没给它完整业务约束。如果真的遇到 WorkBuddy 生成的代码与本地运行环境不一致建议把本机 Python 版本信息也告诉它例如“我本机是 Python 3.11Windows 系统”。这会减少一些版本层面的误差。8. 从 Demo 走向生产库存系统的工程化建议8.1 数据存储升级路径本系统默认使用 SQLite适合单机学习和小型原型。如果后续需要多人同时操作就要迁移到 MySQL 或 PostgreSQL。迁移时代码改动主要在db.py把sqlite3.connect换成数据库连接池把建表语句换成对应数据库类型。业务层里的入库、出库逻辑基本可以保留只要注意不同数据库对事务的支持差异。业务函数中“先查询再更新”的模式在多用户并发时存在超卖风险。一个常见的解决方案是“原子条件更新”UPDATE products SET quantity quantity - ? WHERE sku ? AND quantity ?;这条 SQL 在执行层面保证“只有当前库存足够时才更新”但如果想记录流水还需要在事务中完成。更高阶的方案是引入乐观锁版本号字段version每次更新时带上版本号更新失败就重试。作者建议先理解条件更新的含义再扩展事务和锁不要一上来就套分布式锁。8.2 审计、权限与备份生产环境里库存系统的每一次操作都必须可追溯。这意味着每条流水要增加operator字段记录当前登录用户。删除商品不推荐物理删除改用is_active字段做停用。对数据文件或数据库定期备份。SQLite 可以直接备份.db文件但更稳妥的是使用sqlite3 .backup命令或在你的 Python 代码里调用备份函数。不要让任何业务账号拥有数据库的管理员权限应用连库使用最小权限账号。如果这套系统是给公司内部或客户使用这些点都直接影响系统能否被信任。不要把 MVP 直接当生产系统这是一个很常见的坑。8.3 AI 生成代码的安全原则使用 WorkBuddy 或任何 AI 工具生成代码都要遵守几个原则第一不要让 AI 直接操作生产数据库。它可能理解不了你的配置也可能生成危险 DDL。所有 AI 给出的 SQL 和代码先在本地或测试环境跑。涉及删表、清库的命令务必人工审查后再执行。第二不要向 AI 对话工具提交过多敏感凭据比如数据库密码、内部 Token。把它当结对程序员可以但不等于它可以保管你的服务器密钥。第三AI 生成代码中的第三方依赖要谨慎评估。它可能为了满足功能随手建议一个不熟悉的开源库而你没有时间审查依赖的安全级别。尽量使用语言标准库或者团队已使用过的库。8.4 Python 进阶学习路线如果你用这套库存系统练手下一步的建议是按层级深入第一层把db.py、inventory.py、main.py逐行读明白用自己的话写注释。第二层给系统增加“查看流水”和“盘点调整”功能练习在约束下扩展代码。第三层把数据库切换到 MySQL修改连接方式和建表语法体会差异。第四层为入库、出库函数写单元测试使用unittest或pytest覆盖“库存不足”“SKU 不存在”等异常场景。第五层尝试用 Flask 或 FastAPI 写一版 REST API将命令行菜单改成 HTTP 接口理解前后端分离。当你完成第五层时你的 Python 已经不是入门水平而是真正理解了业务系统分层、事务和测试思维。9. 总结与下一阶段建议用一句话总结这套思路WorkBuddy 可以在几分钟内为你提供一套商品库存管理系统的雏形Python 是实现它的轻量工具但真正决定系统能不能用的是你有没有抓住库存管理的业务本质——将每一次操作变成可追溯、有约束、防超卖的数据流。如果你有 WorkBuddy建议现在新建一个项目空间按照第三小节的模板输入需求然后对照第五节代码审查每一个生成文件。如果你没有 WorkBuddy就更要动手敲一遍代码先在本地跑通再逐步往里面加功能。两条路线都能练到同一个核心把模糊需求拆成可执行任务的能力这比会背几个 API 重要得多。下一步不要急于换框架。先把这套系统跑上几天试着给家人或朋友用一用收集真实使用中遇到的问题。你会发现现实世界的“商品改名后流水怎么追溯”“库存数据怎么导出给财务”这类需求才是提升能力的最佳题库。库存系统虽小五脏俱全。无论你是准备学 Python、验证 AI 开发工具还是想给真实场景做原型这套 WorkBuddy 加 Python 的组合都很值得实操一次。建议先把代码跑通再按自己的业务规则改造它。改完以后你会有一种明显感受从“让 AI 写一个系统”到“和 AI 一起设计一个系统”只差了一次认真建模的距离。 WorkBuddy+Python实战：从零搭建商品库存管理系统
最近想自己动手做一个“商品库存管理系统”的人变多了。很多开网店、做小团队ERP选型、或者刚学Python的读者不是不想用系统而是被传统开发路径劝退了要装数据库要写后端接口要学前端页面还要考虑多人登录、权限、日志……一个简单需求硬是变成了三个月的大工程。现在我们看到了另一个选择用自然语言描述需求让 WorkBuddy 这类 Agent 工具帮你拆任务、生成代码再配合 Python 把系统跑起来。看起来门槛一下被拉低了。但我得先给一个判断WorkBuddy 降低的是“从一句话到系统骨架”的转换成本它不自动解决可靠性问题。一个库存管理系统能不能真正用起来核心不取决于 AI 生成了多少代码而取决于你有没有把“库存不能为负”“出库要有流水”“低库存要预警”这些业务规则梳理清楚。因为 AI 可以帮你写出代码但只有你能定义什么是“正确”。这篇文章会带你走完一条完整路线先理解 WorkBuddy 这类 AI 办公工作台适合做什么再把“帮我做一个库存管理系统”这句话拆成可落地的功能模块和数据库设计然后给出一套基于 Python 标准库 SQLite 的完整可运行代码最后告诉你生成代码之后怎样验证、审查、以及从 Demo 走向生产环境时要补哪些工程能力。就算你现在手边没有 WorkBuddy也可以直接拿文中代码手动跑通。整条路线对得上“AI 辅助开发”和“Python 练手实战”两个方向建议先收藏再阅读。1. WorkBuddy 加 Python 这个组合到底解决了什么问题1.1 不写库存系统的痛苦是需求不明确很多人第一次想开发库存系统脑子里的需求就一句话能增加商品、能登记入库出库、能看到还剩多少货。这句话看起来明白真动手却寸步难行。你打开数据库设计工具会不停反问自己“商品要不要分类同一件衣服有不同颜色怎么处理出库时用户填的数量超过了当前库存该怎么办要不要记录每次操作是谁做的”这些问题不是因为你不懂 Python而是业务规则没有建模。传统的做法是去学一套完整的技术体系MySQL、ORM、RESTful API、前端表格框架……你花大量时间学的技术其实只是为了解决一个“库存增删改查”的小问题。这种成本错配有很强的挫败感。现在WorkBuddy 这类 Agent 工具给了另一种方式你可以在对话里把模糊想法说出来它会把需求转成明确的功能清单、表结构和代码文件。这不等于你不用思考而是把你的思考变成一次“对话式澄清”比面对空白编辑器要轻松很多。1.2 WorkBuddy 加 Python 的关键价值WorkBuddy 不是传统意义上的在线编译器它更像个“办公工作台”。从网上常见的讨论来看它的玩法通常围绕这几件事展开用自然语言生成文档或代码、搭建个人工作台、配合各种“Skill”完成一站式任务执行甚至接 API 处理数据。和单纯帮你补全代码的编程助手相比它的侧重点更接近“把一个模糊任务跑出结果来”。Python 则是实现业务逻辑的好搭档。做库存管理系统这种中小型项目Python 的标准库就赢了一大半socket能写网络服务sqlite3能存数据argparse能处理命令行参数连图形界面也有tkinter可选。你不需要一开始就引入重型框架一个main.py就能把业务流程讲清楚。组合起来这个模式真正价值有三层需求层用自然语言描述AI 负责把它转成结构化任务。你不需要先把话“翻译”成技术术语才能开口。代码层Python 简洁、易读方便人类在 AI 生成结果后进行审查和修改。代码越简单审查成本越低越不容易被 AI 的“幻觉”带偏。验证层没有项目管理系统时你用命令行就能完成业务验证发现问题能立刻回到对话里继续修正。这个组合也适合另一种场景你不是要真的上线一套生产系统而是想验证一个业务流程是否走得通。比如你给自己的小卖部、工作室、社团物资管理做原型验证那用 WorkBuddy 拆需求用 Python 快速实现比动用低代码平台还轻不少。1.3 谁适合用这种方式做库存管理我个人建议按下面这个标准判断不要盲目跟风用户类型适合程度建议完全零基础且没有编程学习意愿不太适合可以先用成熟进销存软件AI 生成代码后你不会排错就没法用Python 刚入门想拿项目练手很适合用 AI 生成骨架再逐行阅读修改练习效果极好小团队、店铺需要内部原型很适合快速做出可交互 Demo确认业务流程后再决定是否正式开发有一定工程经验接外包或个人项目适合把 AI 当结对程序员关注点放在系统设计和代码审查上需要高并发、强事务的电商系统不适合应设计专业后端、分库分表甚至消息队列不在这篇文章范围你会发现WorkBuddy 加 Python 解决的最大问题是“从模糊想法到可运行系统”的跃迁成本。它不能替你做工程决策也不能让一台电脑瞬间变成高可用服务器。1.4 别用错场景它不是万能资料库网上搜索“WorkBuddy”时会有不少非官方流出的清单、所谓“大学推荐”内容看起来像是什么都能查的资料库。这里要提醒一句WorkBuddy 这类产品定位是办公和开发提效工具不是你人生的“万能查询机”。如果你把使用目标定义成“让它直接告诉我某门课程的结论”那可能用错了方向。尤其在生成代码时你要把它理解为“一个能快速起草的初级工程师”而不是“权威编译环境”。它写出来的代码可能有细节错误、可能有版本兼容问题、甚至可能在某个业务规则上自作聪明。能不能容忍这些错误取决于你有没有能力在关键位置做审查。读完下一章节你会更清楚 WorkBuddy 的核心能力和边界在哪里。2. WorkBuddy 能做什么一次理解它的核心概念2.1 WorkBuddy 不是 IDE而是“任务执行工作台”IDE 的核心是让你编写、调试、运行代码。WorkBuddy 的定位更宽它试图把 AI 能力组装成一个“能干活的工作台”。你可以在里面做任务规划、生成文档、编写代码借助 Skill 来增强它的专项能力也能把某一段 API 接进来让自动化流程跑起来。用库存管理系统举例在传统 IDE 里你需要自己创建main.py、自己建表、自己写循环。在 WorkBuddy 里你可以先让它生成一份“库存系统开发清单”再让它按清单逐项产出代码。你扮演的角色从“所有代码手写者”变成了“任务拆解者和结果验收者”。这与“自动补全代码”的编程助手有本质区别。CodeBuddy 类编程助手的重心在代码上下文它对当前文件、语法结构、编译错误更敏感而 WorkBuddy 类工作台的重心在任务链路它关心的是“下一步做什么做完要产出什么”。网上经常有人问 CodeBuddy 和 WorkBuddy 怎么选前者偏开发场景后者偏办公和任务自动化场景两者结合起来使用也很常见。2.2 Agent 类工具改变开发的三件事用 AI Agent 类工具做项目和过去“搜索代码、复制粘贴、再改改”完全不同。我认为真正的变化是这三件事第一从“搜资料”变成“查路径”。以前遇到库存管理你会搜“Python 库存管理系统源码”拿到一份看不懂的代码现在 WorkBuddy 会直接给你项目结构建议甚至会告诉你应该先建表再写业务函数最后做菜单。它引导的是一条完整路径不只是单个文件片段。第二从“复制代码”变成“修改代码”。AI 生成的代码必然不是一次到位你需要在理解的基础上修改。这会倒逼你养成读代码的习惯。对初学者来说这是好事因为“读别人代码”本来就是最快的学习方式之一。第三从“只管编码”变成“管完整交付”。工作台会把需求、进度、代码、使用说明串在一起。你把“商品库存管理系统”这句话扔进去它不会只给你零零散散函数它会尝试产出从数据库初始化到业务流程展示的一整套可运行成果。这三点变化意味着你的工作方式要从“让我想想代码怎么写”变成“让我想想需求怎么描述、结果怎么验收”。这正是 AI 时代最值得刻意练习的能力。2.3 必须理解的边界边界也很重要。第一WorkBuddy 生成代码是否真实可靠你需要在隔离环境中验证第二它对项目上下文的理解有限跨很多文件的大型系统它可能顾此失彼第三涉及敏感数据时你不能把生产库的连接信息直接暴露给任何 AI 工具也不能指望 AI 帮你做安全管理。所以下面几节先给你一套稳妥的实践路径环境上隔离、代码上审查、业务上小步验证。3. 用 WorkBuddy 搭建“一句话需求”的完整工作流3.1 环境准备无论你是打算主要用 WorkBuddy 生成代码还是手动敲代码本机环境都要先准备好。在 Windows 上推荐直接从 Python 官网下载安装包或使用 Microsoft Store 的 Python 安装入口安装时勾选“Add Python to PATH”把 Python 加入系统环境变量。在 macOS 上可以安装 Homebrew 后执行brew install python。在 Linux 上一般可以用系统自带的包管理器安装比如 Ubuntu/Debian 系统执行sudo apt update sudo apt install python3 python3-pip安装完成后在终端验证版本python3 --version注意Windows 上命令可能是python --version。如果你希望后续用虚拟环境管理项目依赖可以再执行python3 -m venv inventory_env source inventory_env/bin/activate # Linux / macOS # Windows PowerShell 下执行 inventory_env\Scripts\Activate.ps1WorkBuddy 的环境则要看产品当前版本的实际情况。常见做法是登录官方客户端或网页端在“工作台”或“项目”中新建一个专门项目后续对话、生成文件、业务梳理都放在同一个项目空间里。不同版本入口名称可能不一样不纠结细节核心是让整个开发过程有上下文连续性。3.2 需求描述模板不要直接输入“给我做一个库存系统”那样得到的东西大概率很空。更好的做法是给足业务上下文。下面这个模板可以套用请你扮演一个 Python 开发工程师帮我设计一个商品库存管理系统的 MVP 版本。 业务背景我经营一家小网店主要记录商品库存变化目前只需要单机命令行程序。 技术约束 1. 使用 Python 3数据库使用标准库 sqlite3尽量不依赖第三方库 2. 数据表要区分“商品资料表”和“库存变动流水表” 3. 出库操作必须先判断库存是否充足不足时禁止出库并给出明确提示 4. 入库、出库都要留下流水方便追溯 5. 系统要支持低库存预警低于阈值时在商品列表里提示。 交付要求 1. 先给数据库设计再给业务代码 2. 代码要能直接运行 3. 最后写三行最简使用说明。你会发现这个 Prompt 里除了功能需求还包含了业务规则和技术约束。AI 看到的信息越多产出才越贴近实际。3.3 分步提问而不是要求一次生成几十个文件和 AI 协作有个显著误区一次性要求它生成完整项目看起来省事实际排错时很痛苦。更稳妥的方式是分步进行第一步让它输出“数据库表结构和字段解释”。你确认字段是否满足业务比如有没有 SKU、分类、当前库存、低库存阈值。确认后进入下一步。第二步让它输出“数据库初始化和调用函数”。你要检查代码是否真的能建表。第三步让它输出“入库出库业务函数”。这里要重点人工审查库存判断逻辑。第四步让它输出“命令行主程序”。这样即使某个步骤出现错误你也能快速定位在哪一步。AI 不会觉得你烦它没有耐心问题但你过度压缩步骤只会把问题复杂度集中到自己身上。跑通 MVP 后再继续提出“增加盘点功能”“增加导出功能”“增加搜索功能”。一个功能一个功能地加比一次做完更能保证质量。这也是我把代码拆成几个小节来写的原因。4. 商品库存管理系统从自然语言到数据建模4.1 拆解一句话需求把“帮助我做一个库存系统”这句话拆开你会发现里面其实藏着以下模块功能模块自然语言里的依据需要做的事商品管理“能添加商品”新增、编辑、查询、删除商品资料入库管理“能登记进货”增加库存记录入库流水出库管理“能登记卖出”校验库存后减少库存记录出库流水库存查询“能知道现在还剩多少”按商品或分类查询当前库存低库存预警“快没货了提醒我”对比在库量与阈值输出预警清单流水追踪“以后能查历史记录”记录每次入库出库前后的库存量变化这个拆解最好让 WorkBuddy 先做一遍你在旁边对比是否合理。它列出的东西一般比较完整但可能缺“盘点调整”“删除保护”“日志记录”等细节。在 MVP 阶段我们可以先做好上面六件事后面扩展。4.2 业务规则比建表更先确定开发库存系统最核心的不是“建几张表”而是“定义什么操作是合法的”。我强烈建议你在写任何代码前把下面规则用文字写下来商品必须有唯一 SKU重复 SKU 不能再次插入。入库数量必须大于 0。出库数量必须大于 0且不能大于当前库存。每次库存变动都要记录变动前后的数量。删除商品时不建议物理删除数据可以采用“下架”或“停用”方式避免流水表失去关联。这些规则你是准备让 AI 猜还是一开始就写进 Prompt如果写进 PromptAI 的产出准确率高得多如果不写AI 的默认实现通常比较简单可能压根不校验出库库存是否足够到上线时才发现能卖出超过库存的商品。一个教训是库存系统是“账实一致”问题不是“增删改查”问题。你代码里每一条业务约束都对应现实中一次可能的盘亏或超卖事故。4.3 数据库设计MVP 阶段用 SQLite 足够。它能把整个数据库存在一个本地文件里比如inventory.db不用单独安装数据库服务适合学习和小规模单机使用。我建议设计两张表。商品表products字段名类型说明idINTEGER 主键自增内部主键skuTEXT 唯一商品编码如 KG001nameTEXT商品名称categoryTEXT分类如“食品”priceREAL单价quantityINTEGER当前库存数量low_stock_thresholdINTEGER低库存预警阈值默认 5created_atTEXT创建时间流水表stock_logs字段名类型说明idINTEGER 主键自增流水主键skuTEXT商品编码change_typeTEXT变动类型in / out / adjustquantityINTEGER变动数量before_quantityINTEGER变动前库存after_quantityINTEGER变动后库存noteTEXT备注记录原因created_atTEXT变动时间为什么流水表要记录before_quantity和after_quantity因为你做审计时经常需要知道“这次操作之后结果对不对”。如果只记录变动数量就很难在事后发现问题。这是很多库存 Demo 里缺失的关键细节。5. Python 完整代码实现一个可以直接运行的库存系统为了让代码结构清楚我拆分成了三个文件db.py负责数据库操作inventory.py负责业务函数main.py负责菜单交互。你完全可以手动创建这些文件也可以把这些代码作为审查基准去对比 WorkBuddy 生成的结果。如果你直接复制运行代码是完整的。我刻意保持了简单的 CLI 界面方便你专注业务逻辑。5.1 项目结构准备inventory_system/ ├── db.py ├── inventory.py ├── main.py └── inventory.db # 运行后自动生成在项目目录中创建db.py。5.2 数据库初始化模块# 文件路径inventory_system/db.py import sqlite3 DB_NAME inventory.db def get_connection(): conn sqlite3.connect(DB_NAME) conn.row_factory sqlite3.Row return conn def init_db(): conn get_connection() try: conn.executescript( CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY AUTOINCREMENT, sku TEXT UNIQUE NOT NULL, name TEXT NOT NULL, category TEXT DEFAULT , price REAL NOT NULL DEFAULT 0, quantity INTEGER NOT NULL DEFAULT 0, low_stock_threshold INTEGER NOT NULL DEFAULT 5, created_at TEXT DEFAULT (datetime(now, localtime)) ); CREATE TABLE IF NOT EXISTS stock_logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, sku TEXT NOT NULL, change_type TEXT NOT NULL, quantity INTEGER NOT NULL, before_quantity INTEGER NOT NULL, after_quantity INTEGER NOT NULL, note TEXT DEFAULT , created_at TEXT DEFAULT (datetime(now, localtime)) ); ) conn.commit() finally: conn.close() if __name__ __main__: init_db() print(数据库初始化完成)这里用row_factory sqlite3.Row让查询结果支持按字段名取值代码更可读。executescript可以一次执行多条建表语句但要注意 SQLite 的事务行为示例中是幂等建表没有风险。运行一次python db.py看到数据库初始化完成说明inventory.db已经创建。5.3 商品管理与库存事务模块业务层是所有规则最集中的位置。我建议把入库、出库、库存调整这类会修改库存的操作全部收敛到inventory.py不要让主程序自己写 SQL。这样后续加权限、加日志、换数据库都更轻松。# 文件路径inventory_system/inventory.py from db import get_connection def add_product(sku: str, name: str, category: str , price: float 0.0, low_stock_threshold: int 5): conn get_connection() try: conn.execute( INSERT INTO products (sku, name, category, price, low_stock_threshold) VALUES (?, ?, ?, ?, ?) , (sku, name, category, price, low_stock_threshold), ) conn.commit() except sqlite3.IntegrityError: raise ValueError(fSKU {sku} 已存在不能重复添加) finally: conn.close() def list_products(): conn get_connection() try: rows conn.execute( SELECT * FROM products ORDER BY sku ).fetchall() return [dict(row) for row in rows] finally: conn.close() def stock_in(sku: str, quantity: int, note: str ): if quantity 0: raise ValueError(入库数量必须大于 0) conn get_connection() try: row conn.execute( SELECT quantity FROM products WHERE sku ?, (sku,) ).fetchone() if row is None: raise ValueError(f商品 {sku} 不存在请先添加商品) before_qty row[quantity] after_qty before_qty quantity conn.execute( UPDATE products SET quantity ? WHERE sku ?, (after_qty, sku), ) conn.execute( INSERT INTO stock_logs (sku, change_type, quantity, before_quantity, after_quantity, note) VALUES (?, in, ?, ?, ?, ?) , (sku, quantity, before_qty, after_qty, note), ) conn.commit() finally: conn.close() def stock_out(sku: str, quantity: int, note: str ): if quantity 0: raise ValueError(出库数量必须大于 0) conn get_connection() try: row conn.execute( SELECT quantity FROM products WHERE sku ?, (sku,) ).fetchone() if row is None: raise ValueError(f商品 {sku} 不存在请先添加商品) before_qty row[quantity] if quantity before_qty: available before_qty raise ValueError(f库存不足当前库存 {available}无法出库 {quantity}) after_qty before_qty - quantity conn.execute( UPDATE products SET quantity ? WHERE sku ?, (after_qty, sku), ) conn.execute( INSERT INTO stock_logs (sku, change_type, quantity, before_quantity, after_quantity, note) VALUES (?, out, ?, ?, ?, ?) , (sku, quantity, before_qty, after_qty, note), ) conn.commit() finally: conn.close() def low_stock_list(threshold_override: int None): conn get_connection() try: if threshold_override is not None: rows conn.execute( SELECT * FROM products WHERE quantity ? ORDER BY quantity ASC, (threshold_override,), ).fetchall() else: rows conn.execute( SELECT * FROM products WHERE quantity low_stock_threshold ORDER BY quantity ASC ).fetchall() return [dict(row) for row in rows] finally: conn.close()这个模块里有三个非常关键的设计值得一一说明。第一个是入库逻辑中的“先查库存再更新库存”。表面看这个流程是“查询—计算—更新”。在单机 SQLite 场景下这个操作基本安全但在多人并发场景下你需要用事务锁或者条件更新防止超卖。文章后面会继续讲。第二个是出库逻辑的库存校验。第 35 行到第 38 行必须判断quantity before_qty。很多 AI 生成的简化代码会允许库存变成负数这是绝对不能接受的。库存系统中的“负库存”意味着账目失真也意味着超卖事故的隐患。第三个是每次库存变动都写入流水。写流水时把变动前、变动后都记下来这样你能复盘任意时刻的库存变化过程。5.4 命令行主程序模块接下来写main.py提供一个清晰的交互菜单让用户能直接体验整个库存管理流程。# 文件路径inventory_system/main.py from db import init_db from inventory import ( add_product, list_products, stock_in, stock_out, low_stock_list, ) from inventory import stock_logs # 如果扩展了流水函数 def print_products(products): if not products: print(当前没有商品数据) return print(\n * 100) print(f{SKU:12}{名称:20}{分类:12}{单价:10}{库存:8}{预警线:8}) print(- * 100) for p in products: flag if p[quantity] p[low_stock_threshold]: flag 低库存 print( f{p[sku]:12}{p[name]:20}{p[category]:12} f{p[price]:10.2f}{p[quantity]:8}{p[low_stock_threshold]:8}{flag} ) print( * 100) def main(): init_db() print(欢迎使用商品库存管理系统) print(输入对应数字进行操作) while True: print(\n请选择功能) print(1. 添加商品) print(2. 商品列表) print(3. 入库) print(4. 出库) print(5. 低库存预警) print(0. 退出) choice input(请输入编号).strip() try: if choice 0: print(系统已退出) break elif choice 1: sku input(请输入 SKU).strip() name input(请输入商品名称).strip() category input(请输入分类).strip() price float(input(请输入单价).strip()) threshold int(input(请输入低库存阈值默认5).strip() or 5) add_product(sku, name, category, price, threshold) print(f商品 {sku} 添加成功) elif choice 2: print_products(list_products()) elif choice 3: sku input(请输入 SKU).strip() qty int(input(请输入入库数量).strip()) note input(请输入备注可留空).strip() stock_in(sku, qty, note) print(f{sku} 入库 {qty} 件成功) elif choice 4: sku input(请输入 SKU).strip() qty int(input(请输入出库数量).strip()) note input(请输入备注可留空).strip() stock_out(sku, qty, note) print(f{sku} 出库 {qty} 件成功) elif choice 5: threshold input(请输入要按哪个阈值过滤留空则使用商品自身阈值).strip() if threshold: products low_stock_list(int(threshold)) else: products low_stock_list() print_products(products) else: print(无效编号请重新输入) except ValueError as e: print(f操作失败{e}) except Exception as e: print(f发生未知错误{e}) if __name__ __main__: main()这里from inventory import stock_logs是示例中的占位如果你没有在inventory.py中写过这个函数可以删掉这行。一个更稳妥的办法是把它改成导入流水查询函数并增加“查看流水”功能。为了缩短代码上面主体已经足够跑通库存管理的核心流程。主程序用try...except ValueError捕获业务规则异常这样库存不足、SKU 重复等提示会友好地展示给使用者而不是抛出难懂的堆栈信息。5.5 运行效果与验证在项目目录下执行python main.py系统会进入菜单交互。建议按下面顺序测试一遍核心流程选择“1”添加商品SKUKG001名称苹果分类水果单价5.5低库存阈值10。再次添加同一 SKU观察是否提示“SKU 已存在”。选择“2”查看商品列表确认苹果初始库存为 0并显示“低库存”标记。选择“3”入库 50 件再执行入库 0 件应提示“入库数量必须大于 0”。选择“4”出库 20 件再尝试出库 100 件应提示“库存不足”。选择“2”看到库存此时为 30 件。选择“5”输入阈值 10应看到苹果库存 30 不低于 10不再预警再尝试入库后把库存改成低于 10 的场景。预期输出大致是欢迎使用商品库存管理系统 输入对应数字进行操作 请选择功能 1. 添加商品 ... 请输入编号1 请输入 SKUKG001 请输入商品名称苹果 请输入分类水果 请输入单价5.5 请输入低库存阈值默认510 商品 KG001 添加成功如果哪一步失败优先看两处操作时输入的类型是否合法比如price不能填成字母inventory.py中抛出的ValueError是否被主程序的except正确捕获。6. WorkBuddy 如何生成高质量库存系统代码很多人认为把需求发给 AI然后复制代码就是全部。实际上用 WorkBuddy 做出靠谱库存系统的关键在于“如何组织对话”。6.1 给 WorkBuddy 的提示词模板如果你要用 WorkBuddy 开发同样系统可以参考下面这个更高阶的提示词我在做一个单机版商品库存管理系统使用 Python sqlite3。 请你先不要写代码。先问我不超过三个问题用来确认业务规则。可能的三个方向 1. 商品是否需要分类管理 2. 出库数量大于库存时程序应该直接拒绝还是先进行超卖登记 3. 是否需要记录每一次操作的时间、数量和操作人 在我回答之后按下面的目录生成代码 - db.py数据库初始化products 表和 stock_logs 表 - inventory.py商品添加、列表、入库、出库、低库存预警函数 - main.py命令行交互菜单 要求 - 所有 SQL 都使用参数化查询 - 出库必须判断库存足够 - 每次入库出库都写流水 - 不允许引入第三方库这个模板优先让 AI 澄清业务再生成代码。很多高手与 AI 协同时都采用“先澄清后生成”策略。这能显著减少返工次数。6.2 生成后的代码审查清单拿到 AI 生成的代码后不需要逐行审查但下面几个点必须检查顺序建议固定审查点怎么查为什么重要是否用参数化查询搜索execute(看有没有?占位符拼接防止 SQL 注入风险出库是否有库存校验定位出库函数找if quantity before_qty防止库存在逻辑上变负数库存变化是否写流水搜索INSERT INTO stock_logs没有流水等于失去了审计能力异常处理是否合理看main.py有没有 try/except出现异常时用户无法知道发生了什么数据库连接的打开和关闭搜索close()连接不关闭可能导致程序卡住或文件锁如果 AI 生成的代码不符合上面任何一条不用反驳直接在对话中追问一句“请修改为参数化查询”或“请补充出库库存校验”。6.3 迭代式开发技巧每次只加一个功能。比如先让 AI 完成添加商品和查询商品测试通过后再增量加入库、出库、流水。如果有 Bug把完整报错信息粘贴回对话。AI 对单条错误的修复效果通常不错但不会主动帮你发现隐藏的问题。可以询问“你认为这个系统还会有哪些边界情况”让它充当经验更丰富的开发者。这样你可能得到“重复 SKU 未处理”“float 浮点数会导致价格金额精度问题”“中文输入导致编码问题”等提醒。这些点单独靠新手自己想不出来。7. 常见问题与排查方法新手在运行类似库存系统时最容易遇到下面这些问题问题现象可能原因排查方式解决方案python命令找不到Python 未加入系统 PATH执行python3 --version或重新安装时勾选 PATHWindows 用py -3作为替代启动命令中文乱码终端编码不是 UTF-8在终端执行chcp 65001Windows将 Python 文件头部加# -*- coding: utf-8 -*-或改系统区域设置sqlite3.OperationalError: no such table没有先执行db.py或没有调用init_db()查看项目根目录是否有inventory.db执行一次python db.py初始化添加重复 SKU 报错表字段 UNIQUE 约束触发查看异常是否IntegrityError在调用层捕获并转成友好提示商品不存在时库存不足提示不准确查询商品返回 None 后没有抛出异常定位出库函数商品查询逻辑先判断商品是否存在再判断库存程序运行时无反应或卡住数据库连接没有关闭导致文件锁使用完成后关闭连接在业务函数中用finally: conn.close()出库可以变成负数业务函数缺少校验定位出库 SQL Update 前面的判断语句加上if quantity before_qty: raise ValueError(...)排错的关键顺序是先看异常类型再看报错所在文件行号最后再检查业务逻辑。不要一上来就怀疑 AI 能力不足很大程度上是你在调用方式上没给它完整业务约束。如果真的遇到 WorkBuddy 生成的代码与本地运行环境不一致建议把本机 Python 版本信息也告诉它例如“我本机是 Python 3.11Windows 系统”。这会减少一些版本层面的误差。8. 从 Demo 走向生产库存系统的工程化建议8.1 数据存储升级路径本系统默认使用 SQLite适合单机学习和小型原型。如果后续需要多人同时操作就要迁移到 MySQL 或 PostgreSQL。迁移时代码改动主要在db.py把sqlite3.connect换成数据库连接池把建表语句换成对应数据库类型。业务层里的入库、出库逻辑基本可以保留只要注意不同数据库对事务的支持差异。业务函数中“先查询再更新”的模式在多用户并发时存在超卖风险。一个常见的解决方案是“原子条件更新”UPDATE products SET quantity quantity - ? WHERE sku ? AND quantity ?;这条 SQL 在执行层面保证“只有当前库存足够时才更新”但如果想记录流水还需要在事务中完成。更高阶的方案是引入乐观锁版本号字段version每次更新时带上版本号更新失败就重试。作者建议先理解条件更新的含义再扩展事务和锁不要一上来就套分布式锁。8.2 审计、权限与备份生产环境里库存系统的每一次操作都必须可追溯。这意味着每条流水要增加operator字段记录当前登录用户。删除商品不推荐物理删除改用is_active字段做停用。对数据文件或数据库定期备份。SQLite 可以直接备份.db文件但更稳妥的是使用sqlite3 .backup命令或在你的 Python 代码里调用备份函数。不要让任何业务账号拥有数据库的管理员权限应用连库使用最小权限账号。如果这套系统是给公司内部或客户使用这些点都直接影响系统能否被信任。不要把 MVP 直接当生产系统这是一个很常见的坑。8.3 AI 生成代码的安全原则使用 WorkBuddy 或任何 AI 工具生成代码都要遵守几个原则第一不要让 AI 直接操作生产数据库。它可能理解不了你的配置也可能生成危险 DDL。所有 AI 给出的 SQL 和代码先在本地或测试环境跑。涉及删表、清库的命令务必人工审查后再执行。第二不要向 AI 对话工具提交过多敏感凭据比如数据库密码、内部 Token。把它当结对程序员可以但不等于它可以保管你的服务器密钥。第三AI 生成代码中的第三方依赖要谨慎评估。它可能为了满足功能随手建议一个不熟悉的开源库而你没有时间审查依赖的安全级别。尽量使用语言标准库或者团队已使用过的库。8.4 Python 进阶学习路线如果你用这套库存系统练手下一步的建议是按层级深入第一层把db.py、inventory.py、main.py逐行读明白用自己的话写注释。第二层给系统增加“查看流水”和“盘点调整”功能练习在约束下扩展代码。第三层把数据库切换到 MySQL修改连接方式和建表语法体会差异。第四层为入库、出库函数写单元测试使用unittest或pytest覆盖“库存不足”“SKU 不存在”等异常场景。第五层尝试用 Flask 或 FastAPI 写一版 REST API将命令行菜单改成 HTTP 接口理解前后端分离。当你完成第五层时你的 Python 已经不是入门水平而是真正理解了业务系统分层、事务和测试思维。9. 总结与下一阶段建议用一句话总结这套思路WorkBuddy 可以在几分钟内为你提供一套商品库存管理系统的雏形Python 是实现它的轻量工具但真正决定系统能不能用的是你有没有抓住库存管理的业务本质——将每一次操作变成可追溯、有约束、防超卖的数据流。如果你有 WorkBuddy建议现在新建一个项目空间按照第三小节的模板输入需求然后对照第五节代码审查每一个生成文件。如果你没有 WorkBuddy就更要动手敲一遍代码先在本地跑通再逐步往里面加功能。两条路线都能练到同一个核心把模糊需求拆成可执行任务的能力这比会背几个 API 重要得多。下一步不要急于换框架。先把这套系统跑上几天试着给家人或朋友用一用收集真实使用中遇到的问题。你会发现现实世界的“商品改名后流水怎么追溯”“库存数据怎么导出给财务”这类需求才是提升能力的最佳题库。库存系统虽小五脏俱全。无论你是准备学 Python、验证 AI 开发工具还是想给真实场景做原型这套 WorkBuddy 加 Python 的组合都很值得实操一次。建议先把代码跑通再按自己的业务规则改造它。改完以后你会有一种明显感受从“让 AI 写一个系统”到“和 AI 一起设计一个系统”只差了一次认真建模的距离。