夜雨聆风专栏：闲琢观行｜AI实战第三篇
前言：从 Demo 到产品的跨越
在上一篇《两个晚上搓出差销工作台》中，我们完成了单机版的开发。虽然好用，但同事的一句“我这台电脑也能用吗？”点醒了问题所在——从单文件 HTML 到多人网络服务，是质的跨越。
如果纯手写，加后端、数据库、认证、API 至少需要一周。本文不讲枯燥的技术教程，而是复盘我如何用 AI（CodeBuddy）当副驾，在需求驱动下完成这次改造。
一、需求先行：用 SRS v2.0 锁定 AI 的发挥
改造的第一步不是写代码，而是升级需求。单机版（v1.0）仅是单文件 HTML，而网络版（v2.0）需要支持多用户、数据隔离和审计。
1. 需求升级策略我基于原有的 SRS v1.0，向 AI 追加了以下核心需求，让其输出 v2.0 版本：
·用户体系：增加管理员角色，支持多租户（组织）隔离。
·认证安全：邀请码注册 + 邮箱验证码，JWT 双 Token 认证。
·数据持久化：从 LocalStorage 转为 PostgreSQL，支持历史回溯。
·审计要求：所有写操作必须记录日志。
2. 补充工程约束（AI 不会主动提，但必须写进文档）
·数据标准：明确数据库用 snake_case，前端用 camelCase，API 传输层用 snake_case。这避免了后续字段对不齐的低级错误。
·架构红线：“不碰核心”。tripreceipt.html 中的 8000 行识别逻辑作为“稳定核心”不动，网络版功能通过 app.html 壳页面 + postMessage 通信实现。
二、架构与版本管理：AI 的盲区与人的决策
1. 架构演进
·单机版：单文件，双击即用。
·网络版：采用 Monorepo 分目录结构。
osingle/：保留单机版。
oserver/：存放 Node.js 后端与壳页面。
olegacy/：旧版存档。
2. 版本管理决策：为什么放弃“Git 分支”？我曾询问 AI 是否可用分支管理（master 存单机，network 存网络版），AI 给出了教科书式的肯定回答。但实测发现，在同一工作目录下切换分支，未提交的文件会残留或冲突，无法实现“两版并存对比”。
·最终方案：分目录 Monorepo。同一仓库下，不同目录独立演进，互不干扰，随时可对比。
💡AI 缺乏对你“物理工作环境”的感知。涉及文件组织、端口分配等工程决策，必须依赖人的实际体感，不能盲信 AI 的通用建议。
三、开发实战：AI 写代码，人做“守门员”
1. 数据库与认证
·AI 产出：一次性生成了 12 张表的 DDL 和 437 行的 auth.js（含 bcrypt、JWT、限流）。
·人工修正：
o软删除：AI 默认物理删除，我强制要求增加 deleted_at 字段，以满足财务审计要求。
o组织隔离：AI 漏了部分业务表的 org_id，我要求全表补全，确保 SQL 层面也能兜底数据隔离。
o开发模式：要求 AI 增加 DEV 模式，跳过邮件验证码，提升调试效率。
2. 调试中的四个典型 Bug（AI 的常见盲区）在联调过程中，我捕获了四个 AI 制造的典型 Bug，这展示了 AI 缺乏“全局运行时”视角：
Bug 现象 | 根因分析 | 人类修正思路 |
行程刷新后消失 | 前端传 trips (复数)，后端读 trip (单数)。 | 依据数据标准，快速定位字段名不一致。 |
恢复逻辑重算 | AI 沿用了旧的“临时方案”代码，未调用云端存储的 trip_items。 | 修正逻辑，优先使用云端数据而非重新归集。 |
ReferenceError | HTML 拼接字符串时，ID 漏了引号（onclick="f(id)" 应为 f('id')）。 | 纯字符串拼接需人工审查，框架可避免此类问题。 |
时序竞争 | saveReceipts 和 saveTrips 异步并发，导致 Trip 存入库时 Receipt ID 尚未生成。 | 强制串行化：await saveReceipts 后再存 Trip。 |
四、安全复盘：被忽视的“裸奔”风险
这是本次改造最大的教训。AI 写的静态服务器默认将 tripreceipt.html（含核心 OCR 正则和算法）直接暴露。
·风险：未登录用户只要知道 URL，就能下载核心源码。
·修正方案：
1.核心后端化：将识别引擎抽离为后端服务 recog-core.js，前端仅保留 UI 壳。
2.权限封锁：禁止直接 GET 核心 HTML 文件，所有请求必须经过 JWT 鉴权。
五、总结：人机协作的最佳实践
这次改造证明，AI 是优秀的执行者，人是卓越的指挥官。
·AI 负责：补全需求细节、生成 DDL、编写标准认证模块、设计基础路由。
·人负责：
1.定规矩：制定数据标准、架构红线、Git 策略。
2.补盲区：处理软删除、环境配置、异步时序、安全边界。
3.审结果：AI 容易在字段单复数、引号、临时代码腐烂等细节上出错，必须人工把关。
一句话总结：人可以指挥 AI 盖楼，但图纸的标高和地基的土质，得自己拿尺子量。
（下篇预告：PVE、AMD集成显卡、内网部署，AI能搞定吗？）
功能开发完毕，但新的挑战接踵而至：如何在一个由 PVE 容器、AMD APU 和隔离内网组成的复杂环境里，把这个服务部署上线？
是用 Docker 还是 LXC？Ollama 模型如何在内网搬运？AI 生成的部署脚本是“神助攻”还是“猪队友”？
第四篇，我们将深入部署实战，复盘 AI 在应对这些非标环境时的真实表现，以及我们踩过的坑和总结的血泪经验。