网硕互联帮助中心写在前面
先交代背景：这个作品从第一行代码到全部功能、测试、部署手册，全程在码道 IDE 里由智能体完成。我做的事情说出来可能不信——提需求、选方案、纠错、验收。对，就这么"省事"。
但"省事"的前提是：你得让智能体知道你要什么。所以这篇手记的重点，不在于展示我做出了一个多完美的学习网站，而在于复盘我是如何用工程化的思维，驾驭这些"数字员工"的。案例只是壳，方法论才是魂。
一、架构透视：为什么它不仅仅是一个"工具"？
功能截图先快速过一遍，不展开：
成品速览
仪表盘把"今天有几个番茄、打卡几个计划、几道错题到期、最高连签多少天"浓缩成四个数字，并按优先级生成"今日安排"行动清单——学习最怕的不是不努力，是不知道该先干哪件事。
计划：不止是安排，是"会跟着你变"的安排
打卡、履约率、连续天数只是基本功。它会根据你的计划完成情况推荐下一步——哪科错题堆积多就推荐哪科专项巩固，每周再塞一个"复盘 30 分钟"。计划死了就死了，这个安排是活的。 
错题本按艾宾浩斯记忆曲线自动排期：间隔 1、2、4、7、15、30、60 天逐级拉开；答"全忘"就重置、答"模糊"就收紧、答"秒答"就放宽——复习的不是题目，是你的遗忘速度。 
统计页有一条橙红色的遗忘曲线：根据复习记录预测"此刻这批错题还剩多少记忆留存"，温故而知新第一次变成看得见摸得着的东西。
课表、日历这些日常安排也不落下。 
这个案例真正的价值：面向 Agent 的架构设计
功能只是表象。这个案例真正的核心价值，在于它的底层架构是 “面向 Agent（智能体）设计” 的：
1. 双轨制驱动：填一个 OpenAI 兼容 API 地址（默认 DeepSeek 格式），AI 教练立刻接管计划推荐、错题分类、学习总结；不填也能用——内置规则引擎兜底，并且界面上永远诚实标注当前是"大模型驱动"还是"智能引擎"。
2. 开放的生态契约：全站 48 条接口自动生成 OpenAPI 契约，一个 Agent Key + HMAC 签名，就能让外部智能体（我的是 Hermes 高考智能体）直接读写、动态微调一个学生的全部学习数据；学习行为自动生成事件，签名推送出去。
它不是一个封闭的工具，而是一个随时准备被更强大 AI 大脑接管的"引擎"。 学习平台自己不造第二个大脑，但随时准备好被更聪明的大脑接管——这种"留接口、做生态"的架构思维，正是我在后续开发中要求智能体必须遵循的系统边界。
你的学习，不再是机械、无味，而是有温度的、智能的。
二、核心方法论：驾驭"数字员工"的六个工程原则
这一部分才是这篇文章的重点。每个原则我都保留了大白话的说法作为引子，但真正的分量在后面的"理论"与"案例印证"——下面每一条，都能在本案例中找到真实的操作对应。
原则一：需求工程——目标导向，消除歧义
大白话：把需求说人话，一次说全。
理论：不要迷信提示词咒语，核心是把模糊意图转化为精确契约。用最少的话砍掉冗余分支，让 AI 做选择题而不是填空题。
案例印证：很多人的问题是把"帮我做个网站"丢给 AI 就等着收货，出来的东西不行再骂 AI 菜。先想想：你到底有没有说清楚自己要什么？
我的第一条需求是这么说的（原话）：
我想开发一个学习网站，要求有专注模式（番茄钟）、自律计划、课程表、日历视图的日程安排、学习错题统计（艾宾斯记忆法）、数据统计（番茄钟、自律计划完成情况、错题统计的艾宾浩斯遗忘曲线）。你给我几个方案参考，并给出各方案的区别。
就这一条，没有任何术语技巧。注意三个信息点：功能清单全、要求"多方案 + 区别"、交付方式是"参考"而不是"执行"。不懂、没有自己的方案，就让智能体提供方案你来选；不懂装懂骂 AI 菜之前，先想想自己有没有把需求表达清楚。
原则二：架构决策——守住边界，抓主要矛盾
大白话：让智能体给方案，自己做决策，别急着动手。
理论：科技如烈马，人文如缰绳。AI 负责穷举技术栈方案，人类负责基于业务边界拍板——把技术细节交给 AI，把架构方向握在自己手里。
案例印证：智能体给了四个方案：纯前端本地存储、前后端分离、一体化框架（Next.js/Nuxt）、BaaS。它列了对比表，还反手问我三个问题：给谁用？要不要接你已有的题库？技术栈偏好？
我按实际情况答：手机电脑都要用 → 必须有服务端；这个只是案例给别人看、可以加个智能体接入接口 → 直接排除 BaaS 和纯前端；技术栈没偏好 → 你来定。就这么几轮问答，方案定了。
这里有个反直觉的经验：提示词不在字数多少，在于用最少的废话表达自己想要的结果。“手机+电脑多设备，要留接智能体的接口”——这一句顶十句漂亮话，因为它替智能体砍掉了三个方向。
原则三：风控机制——先立后破，保持系统稳态
大白话：先备份，再开发（这一步被很多人忽略）。
理论：面对 AI 的不确定性，必须给系统建立回滚能力。Git 版本控制就是复杂系统中的"定海神针"——先立后破，确保系统在任何异常下都能回到上一个稳态。
案例印证：定案动工前，我让智能体先在 GitHub 建了个私人仓库：
先建个私人仓库用来备份回滚，搞好后开始下一阶段。
从此每个里程碑一个 commit、一次 push。这不是洁癖，是给智能体开发上保险。后来果然兑现——有一次它的编辑被外部工具干扰导致文件状态混乱，直接回退到上一个 commit 重来，一点没伤到；还有本机到 GitHub 的 https 抽风，它翻出既有档案改用 SSH over 443 走通，连绕行方案都是自动的。
原则四：敏捷迭代——化整为零，持续验收
大白话：分阶段实施 + 每阶段汇报验收。
理论：避免半成品堆砌导致的系统熵增。把大系统拆解成小里程碑，坚持"AI 自测 → 人类验收"的闭环，小步快跑。
案例印证：开发指令同样一句话：
可以开始开发，分阶段完成，每完成一个阶段给我汇总情况。
智能体把项目拆成 M1~M8 八个里程碑（脚手架 → 番茄钟+计划 → 错题+艾宾浩斯 → 统计图表 → 四大接管引擎 → AI 教练层 → 课表/日历+钩子 → 部署），每个阶段结束：自测 → 汇总 commit SHA、验证结果、下一步 → 交我真人点一遍。我全程不需要看代码，只需要在浏览器里当用户。
节奏是：**先让它自测，测干净了再给我真人测试，没问题再进下一阶段。**别让它把半成品交到你手上再返工。
原则五：客观纠偏——将主观感受转化为工程标准
大白话：纠正是常态，但纠正要"纠得准"。
理论：纠正 AI 不能靠"我觉得"，必须给出明确的参考系。这是将业务逻辑准确映射到代码实现的关键。
案例印证：这一路我有两次重要纠正，都很能说明问题。
纠正一：agent 权限不该是"只读"。 智能体最初把智能体接口设计成只读，我直接怼回去：后期 AI 要根据学习情况帮忙写计划、动态微调，只读等于只能"窥屏"，权限必须完全开放。它当场把权限模型改成"默认全开的读写 + scope 可白名单收紧"，还顺手把我原本写死在 API 文档里的"只读"全部修正。同一个需求，我多说这一句话，作品从"记录工具"变成了"可接管的引擎"。
纠正二：UI 不要"我觉得好看"。 设置页第一次被做成深色玻璃拟态，和全局格格不入，我一句"太丑"退回；第二次我说得具体：参考某个赛璐璐卡通风格网站，主要协调就行，别再在 UI 上花太多时间。它抓了参考站的规范，全站一次性统一成 3px 黑边 + 硬阴影 + 纯色块的风格，从此没再返工。
教训：对智能体不满时，先自查两件事——需求是不是说清楚了，验收标准是不是给具体了。 给不出具体就让它先列方案让你挑，永远比让它猜强。
原则六：知识沉淀——构建可复用的系统上下文
大白话：把经验沉淀进文档，让智能体"记住"。
理论：代码会过时，但架构文档、接口契约和踩坑记录是系统的灵魂。让文档成为连接不同 AI 会话、不同开发者的"统一记忆"。
案例印证：开发尾声，我让它把全部接口（48 条）、智能体对接方式、开发约定和踩过的坑写成项目内的 docs。后面不管是我继续提需求，还是换一个会话的模型来维护，读文档就能接手，不用重新口头交代一遍。
三、工具批判：在算力与交互的边界中前行
客观说，码道 IDE 在工程化支持上表现出了极高的成熟度：
- 从需求分析、方案对比、逐模块编码、起服务自测，到 git 备份、写部署手册、补接口文档，全程没离开码道 IDE；
- 智能体相关功能可能还不太完善，但 GitHub 相关开发功能很完善；
- 踩坑经验会沉淀（网络绕行方案、数据库兼容坑、UI 风格定案），同类问题第二次直接命中。
但我们也要清醒地看到这工具的边界：
- 智能体执行长任务时，人类无法引导插话，只能排队等待；
- 内置 AI 模型在某些复杂场景下仍显"落伍"（当然他们还有一个专门训练鸿蒙开发的 AI：GLM-5.2-ArkTS-SPARK，以及专属鸿蒙智能体设置，等有空我也测试下这智能体在鸿蒙开发的能力如何）。
- 缓存命中率低在长期任务来说划不来费钱
这提醒我们：在 AI 时代，既要善于利用工具的工程化长板，也要通过优秀的架构设计（如文档沉淀、模块化拆分）去弥补工具在交互和算力上的短板。 
结语：主体性的回归
“一天从零到一个能跑的智能学习伴侣”，这个案例足以证明一件事：在智能体开发中，代码实现正在被 AI 接管，但系统架构、业务洞察与边界划分，依然是人类不可替代的护城河。
人类最核心的能力，从来不是写出多么华丽的提示词，而是在复杂系统中抓住主要矛盾，知道自己要什么，并且能用工程化的语言说得出口。 工具再强大，也只是执行层的烈马；而清晰的逻辑与严谨的工程思维，才是驾驭它的缰绳。
项目开源地址：https://github.com/QinLuza/mnemoise
评论前必须登录！
注册