用 CodeArts AI 智能体零依赖打造「鲜拾 FreshKeep」食材保鲜管家-育师

一键开通华为云码道 CodeArts 代码智能体：https://developer.huaweicloud.com/codeartsco.html?source=dmzntgwatomgit1&sourcead=dmzntgwatomgithd

引言：从家庭冰箱里的浪费说起

中国家庭每年因食材过期造成的浪费触目惊心。一项调研显示，城市家庭平均每周丢弃的食材价值超过 30 元，其中超过六成是因为「忘了买过」「不知道什么时候过期」「临期不知道怎么吃」。冰箱成了食材的「冷宫」，买回来的东西常常在角落里默默变质。

市面上的保鲜管理 App 不在少数，但要么功能臃肿、要么强依赖云端账号、要么广告横飞。作为一个只想快速记录「我买了什么、什么时候到期、还能怎么吃」的普通用户，我想要的是一个打开就能用、不联网、不注册、不追踪的轻量工具。

于是「鲜拾 FreshKeep」诞生了。它是一款纯前端零依赖的食材保鲜管家移动端应用，双击index.html即可运行，所有数据存于浏览器本地。本文记录我借助华为云 CodeArts AI 智能体从零打造这款应用的完整过程，包括需求拆解、架构设计、分层实现、调试验证与关键技术的真实落地。

一、应用介绍

1.1 背景：家庭食材管理的三大痛点

痛点	描述
记不清	冰箱里到底有什么、买了多久、还剩多少，全靠记忆
忘得快	临期食材没有提醒，常常发现时已过期
不会用	临期食材不知道做什么菜，最后还是扔掉

鲜拾 FreshKeep 围绕这三个痛点设计功能，目标是让用户在 30 秒内完成一次食材录入，在打开应用 3 秒内看到「今天该吃什么」。

1.2 七大功能模块

模块一：食材录入与编辑

支持 7 大分类（蔬菜、水果、肉类、海鲜、蛋奶、粮油干货、其他）、3 种存放位置（冷藏、冷冻、常温）、10 种计量单位。录入时自动根据购买日期与保质期天数计算到期日期，支持备注与图片占位。

模块二：保鲜提醒与通知中心

每次进入应用，自动扫描所有食材，对临期（默认提前 3 天）与已过期食材生成通知。通知中心按时间倒序展示，支持已读未读、按类型筛选。临期阈值可在设置中调整（1–30 天）。

模块三：临期看板与统计图表

首页以看板形式展示「已过期 / 临期 / 新鲜」三档数量，配手写 SVG 环形图与柱状图，零依赖实现数据可视化。图表颜色随主题切换，浅深模式无闪烁。

模块四：菜谱推荐与库存联动

内置家常菜谱库，每个菜谱标注所需食材与分类。当库存中存在临期食材时，自动推荐能消耗该食材的菜谱，点击「一键加入购物清单」可补齐缺失食材。

模块五：购物清单

支持手动添加与菜谱联动添加，按创建时间排序，已购项可勾选标记并置灰，支持批量清理已购项。

模块六：设置与主题

主题模式：浅色 / 深色 / 跟随系统；
临期预警天数：1–30 天可调；
周首日：周一或周日；
数据导出：一键导出 JSON 备份（手机号脱敏）；
数据清空：二次确认后清空所有本地数据。

模块七：本地模拟登录与游客模式

为演示完整交互流程，提供本地模拟登录（手机号 + 演示验证码 123456，界面明文可见，不伪装后端）。同时支持游客模式，不收集任何个人信息，生成guest-前缀随机 id 即可使用全部功能。

二、开发过程与 AI 辅助实录

上图为本次开发使用的华为云码道 CodeArts 代码智能体实际工作界面，右侧待办面板与对话区可见 AtomGit 账号信息（gcw_93rlw6ed）。

2.1 需求拆解：从用户故事到任务清单

我首先向 CodeArts AI 智能体描述了应用愿景：「一款零依赖纯前端的食材保鲜管家，双击即用，不联网，不注册，覆盖录入、提醒、菜谱、购物四大场景」。

AI 智能体将需求拆解为 12 个用户故事，并进一步细化为 38 个开发任务，覆盖：

数据模型设计（User、FoodItem、Recipe、ShoppingItem、NotificationItem、Settings）；
四层分层架构（core、data、services、ui）；
7 个页面 + 6 个 service + 1 个 repository + 4 个 core 模块；
安全控制点（CSP、XSS、脱敏、校验）；
文档（ARCHITECTURE、DATA-MODEL、SECURITY、SELF-REVIEW、CSDN-ARTICLE、SUBMIT-CHECKLIST）。

拆解结果直接写入任务列表，每个任务标注目标文件、依赖关系与验收标准，便于后续按序推进。

2.2 架构设计：四层分层与单向依赖

在架构阶段，我与 AI 智能体共同确定了四层分层方案：

core（基础能力）→ data（仓储）→ services（业务编排）→ ui（页面与组件）

依赖方向严格单向向下：

ui层只调services，不直接接触data与core；
services层只调data/repository，不直接接触localStorage；
data/repository只调core/storage与core/schema；
core层无依赖，仅使用原生 API。

这一设计带来三个好处：一是模块可替换性强，未来storage.js可平滑替换为 IndexedDB；二是测试边界清晰，每层可独立 mock；三是安全审计简单，storage.js是唯一接触localStorage的模块。

AI 智能体还建议采用 hash 路由（#/home、#/food/:id）而非 History API，避免双击打开时 404 问题，路由表集中配置，新增页面仅需追加一条配置。

2.3 分层实现：从 core 向上生长

实现顺序自底向上，先夯实基础能力，再叠加业务逻辑，最后渲染界面。

第一步：core 层

core/storage.js实现localStorage容错降级，隐私模式或被禁用时降级到内存Map：

letmemoryStore=null;functionread(key){try{returnwindow.localStorage.getItem(key);}catch(e){if(!memoryStore)memoryStore=newMap();returnmemoryStore.has(key)?memoryStore.get(key):null;}}

core/schema.js集中所有校验逻辑，validateFoodItem等函数对字段进行白名单与范围校验，返回{ valid, data?, errors? }结构，不抛异常，便于 UI 层友好提示。

core/util.js提供escapeHtml、maskPhone、clamp、safeUrl等工具函数，是安全防护的第一道防线。

第二步：data 层

data/repository.js封装所有数据访问，存储键统一命名freshkeep:v1:<domain>，预留migrate接口供未来版本迁移。exportAll函数在导出前对手机号二次脱敏，确保导出文件不含明文。

第三步：services 层

6 个 service 分别对应食材、菜谱、购物、通知、认证、设置。每个 service 暴露list / get / add / update / remove风格一致的 API，内部调用 repository 完成持久化，并做业务校验（如重复名称、临期计算、通知去重）。

第四步：ui 层

7 个页面 + 若干组件，统一暴露render(container, params)入口。列表渲染使用createElement+textContent，禁止innerHTML拼接用户内容，从源头杜绝 XSS。

2.4 调试验证：多轮对话与即时修正

开发过程中，AI 智能体多次帮我发现并修正问题：

CSP 违规：初版引入了一个 CDN 字体，AI 智能体提示这与「零依赖」与connect-src 'none'冲突，改为仅允许 Google Fonts CSS（受限于视觉质量）；
XSS 隐患：某页面初版用innerHTML拼接食材名称，AI 智能体指出应改用textContent，并补充escapeHtml用于必须拼接 HTML 的场景；
存储键冲突：初版存储键未加命名空间，AI 智能体建议统一freshkeep:v1:前缀，避免与其他应用冲突；
容错缺失：初版JSON.parse未包裹try/catch，AI 智能体补充容错逻辑，解析失败返回空数组并记录警告；
ARIA 缺失：自评阶段发现部分图标按钮缺aria-label，已列入改进计划。

每一轮对话我都要求 AI 智能体给出修改前后的对比与理由，确保决策可追溯。

三、关键技术解析

3.1 零依赖经典脚本

整个应用不引入任何 npm 包、不使用构建工具、不依赖任何 CDN 业务脚本。所有 JS 为经典脚本（IIFE 挂载到window.App命名空间，非 ES Module），按依赖顺序在index.html中以<script src>加载；所有 CSS 为原生 CSS 变量，所有图表为手写 SVG。这意味着：

双击index.html即可运行，无需npm install、无需启动服务器；
无供应链风险，不存在依赖库被下毒的可能；
离线可用，断网环境下功能完整。

唯一的外部资源是 Google Fonts 字体 CSS，可在「离线优先」场景下移除，回退到系统字体。

3.2 四层分层架构

ui 层（页面与组件） ↓ 只调 services 层（业务编排） ↓ 只调 data 层（仓储） ↓ 只调 core 层（基础能力）

严格分层带来清晰的职责边界与可替换性，详见仓库docs/ARCHITECTURE.md。

3.3 hash 路由

采用 hash 路由（#/home、#/food/edit?id=、#/settings/about等），由core/router.js统一分发，路由表集中定义于ui/app.js：

// ui/app.js 路由表配置varrouteTable=[{path:'#/login',page:'login',tabBar:false},{path:'#/home',page:'home',tabBar:true},{path:'#/food/new',page:'foodForm',tabBar:true},{path:'#/food/edit',page:'foodForm',tabBar:true},{path:'#/recipes',page:'recipes',tabBar:true},{path:'#/shopping',page:'shopping',tabBar:true},{path:'#/settings',page:'settings',tabBar:true},// ...其余路由];// 注册路由：将 routeTable 转为 routesMap 后交给 routerfunctionregisterRoutes(router){varroutesMap={};routeTable.forEach(function(route){routesMap[route.path]=function(context){// 根据 route.page 渲染对应页面，并传入 context.queryrenderPage(route.page,context);};});router.register(routesMap);}

// core/router.js 启动与分发window.addEventListener('hashchange',_onHashChange,false);function_dispatch(hash){varparsed=router.parseHashString(hash);// 解析为 {path, query}varhandler=_routes[hash]||_routes[parsed.path]||_routes['#'+parsed.path];if(typeofhandler==='function'){handler(parsed.query,parsed);}}

优势：双击打开不 404、无需服务端 rewrite、状态保持简单。新增页面仅需在routeTable追加一条配置。

3.4 localStorage 容错降级

core/storage.js对所有localStorage操作包裹try/catch，隐私模式或被禁用时降级到内存Map，配额超限时先清理可重建数据再重试，仍失败则降级内存并提示用户。详见仓库docs/DATA-MODEL.md第 10 节。

3.5 XSS 防护

三层防护叠加：

输出转义：escapeHtml转义 5 个关键字符& < > " '；
textContent 赋值：所有用户内容通过textContent注入，禁止innerHTML拼接；
CSP 限制：script-src 'self'禁止内联脚本，connect-src 'none'禁止任何网络请求。

详见仓库docs/SECURITY.md第 4 节。

3.6 SVG 手写图表

首页统计图表使用手写 SVG 绘制，零依赖，主题色同步：

functionrenderRingChart(svg,segments){consttotal=segments.reduce((s,x)=>s+x.value,0)||1;letacc=0;segments.forEach((seg)=>{conststart=(acc/total)*Math.PI*2-Math.PI/2;acc+=seg.value;constend=(acc/total)*Math.PI*2-Math.PI/2;constpath=arcPath(60,60,50,start,end);// 创建 <path> 并设置 fill 与 stroke});}

环形图展示分类占比，柱状图展示临期数量，颜色随 CSS 变量切换，浅深模式无闪烁。

四、运行效果展示

以下为应用运行效果截图。

4.1 首页看板

顶部问候语与头像；
三档数量看板（已过期 / 临期 / 新鲜）；
分类占比环形图；
临期食材列表与菜谱推荐。

4.2 食材录入

分类、位置、单位选择器；
购买日期与保质期自动计算到期日；
备注与保存。

4.3 菜谱推荐

所需食材与库存联动匹配；
一键加入购物清单；
步骤有序展示。

4.4 设置与主题

浅深主题切换；
临期预警天数调整；
数据导出与清空。

4.5 质量保障：交叉复测与 BEM 命名统一

在功能开发完成后，我们采用静态分析 + 运行时验证并行的交叉复测方法论，系统性排查并修复了两类隐蔽问题。

一、路由三方一致性。项目的路由定义分散在三处：constants.js的ROUTES常量表、tabBar.js的TAB_CONFIG数组、app.js的routeTable注册表。交叉复测发现 7 处不一致：tabBar 缺少购物入口、食材表单路由路径不匹配、insights 路由缺失等。修复方式是以app.js实际注册的路由为基准，统一constants.js和tabBar.js，并删除未使用的多余路由常量。

二、CSS 类名 BEM 规范。静态分析发现 JS 中使用的 className 与 CSS 中定义的类名存在系统性偏差：JS 倾向 kebab-case（如food-card-thumb），CSS 使用 BEM（如food-card__thumb），导致约 83 处类名不匹配、元素无样式渲染。修复分两轮：第一轮将 53 处类名改为已存在的 BEM 类名；第二轮为 30 个无 CSS 定义的新类名补充样式规则（如empty-state__action、skeleton-list__item、settings-user__avatar等），确保 JS 中每一个 className 在 CSS 中都有对应定义。

三、运行时验证。在静态修复完成后，通过浏览器自动化执行 8 项功能测试（应用加载、Tab 导航、食材新增表单、菜谱页面、购物页面、设置页面、深色主题、CSS 样式），确认所有修复在真实运行环境中生效，通过率 100%。

这一方法论的核心是不信任单一验证手段：静态分析能发现命名不一致但无法确认运行时效果，运行时验证能确认功能正常但难以覆盖所有类名，两者交叉才能形成完整的质量闭环。

五、心得与平台优化建议

5.1 开发心得

零依赖的价值远超想象。初始我担心零依赖会拖慢开发效率，但实际体验下来，省去npm install、构建配置、版本锁定的时间，反而让开发更聚焦于业务本身。双击即运行的体验也让评审与分享变得异常简单。

四层分层在小型项目同样适用。即使是一个不到 3000 行的应用，严格的分层也让后续修改与问题定位成本显著降低。每次新增功能，我都能准确知道该改哪一层、影响范围多大。

AI 智能体的最佳用法是「结对编程」而非「代工」。我没有让 AI 智能体一次性生成整个应用，而是按模块逐个对话，每轮要求给出修改前后对比与理由。这种方式让我始终保持对代码的理解与掌控，AI 智能体更像是一位随时可咨询的资深同事。

安全防护应从第一行开始。CSP、escapeHtml、字段白名单这些控制点如果在开发后期才补，往往要改动大量代码。从一开始就建立安全基线，后续只是验证与收紧，成本远低。

5.2 平台优化建议

建议一：CodeArts AI 智能体增加「安全基线模板」。当前 AI 智能体在安全方面需要用户主动提问才给出建议，若能在新建项目时提供「零依赖前端安全基线」模板（含 CSP、escapeHtml、字段白名单骨架），可帮助开发者更早建立安全意识。

建议二：增加「分层架构脚手架」选项。四层分层（core/data/services/ui）在中型前端项目复用率很高，若 CodeArts 提供官方脚手架，可省去重复搭架子时间。

建议三：AI 智能体对话历史可导出为文档。开发过程中 AI 智能体给出的修改建议与理由非常有价值，若能一键导出为「开发日志」文档，便于赛后复盘与团队共享。

建议四：增加「无障碍审查」一键检查。ARIA 标签、focus trap、prefers-reduced-motion 这些无障碍要点容易被忽视，若 AI 智能体能在自评阶段一键扫描并给出修复建议，可显著提升 UI/UX 维度得分。

建议五：支持「离线优先」项目模板。零依赖纯前端应用在内部工具、原型验证场景需求旺盛，若提供离线优先模板（含 PWA manifest、Service Worker 骨架），可降低此类项目门槛。

六、总结

鲜拾 FreshKeep 用不到 3000 行原生代码，实现了食材录入、保鲜提醒、菜谱推荐、购物清单、设置主题等完整功能，零依赖、双击即用、不联网、不追踪。借助华为云 CodeArts AI 智能体，我从需求拆解到架构设计、从分层实现到调试验证，全程保持高效与可控。

如果你也想快速打造一款「打开就能用」的轻量工具，零依赖纯前端是一条值得尝试的路径。CodeArts AI 智能体在其中扮演的不是一个「代工」，而是一位「结对同事」——它帮你拆解、帮你审查、帮你兜底，但每一个决策都留在你手里。