前言
我是一名大二软件工程学生。最近因课程相关要求，本来只计划在AI帮助下做个物品管理本地网页。但是偶然看到别人开发小程序，兴趣使然并在 AI 的帮助下，我开发了一个叫猫爪物账的微信小程序，用来整理自己的物品，也记录日常收支。（开始做一段时间才发现重复造轮子做记账软件了T_T，但已经确定选题并且做了就只好继续开发了）
做这个项目时，我经常经历同一个循环：提出一个想法，看到页面做出来，觉得还不错；真正点几下、换个屏幕、补一笔数据，又发现事情没有那么简单。
这篇文章想分享的，就是这段从想法、讨论、实现到反复修改的过程。我还在学习，下面是当前项目里的实践和体会，也希望有经验的大手子指出问题，万分感谢！
一、从「我有哪些东西」开始
最初的需求很具体：给拥有的物品建一份档案，知道它什么时候买的、花了多少钱、现在放在哪里，以及用了多久。
其中开发时我比较感兴趣的是物品陪伴。比如一台相机，除了购买价格，还可以记录维修、闲置和处置，再看看它的日均净成本。这里的相机只是举例，不代表我的真实购买记录。
后来，我自己搜索了发现小程序里已经有很多专门的物品管理小程序，为了做出差异化，需求逐渐延伸到日常记账。物品档案适合回答这件东西用了多久、成本怎样，流水则方便回答这个月的钱花到哪里了。把它们放在一个小程序里，可以从不同角度回看生活。
目前项目围绕物品、记账、统计和个人页展开。视觉上采用奶黄、暖白和小猫插画，希望让记录这件事轻松一点。具体页面大致如下：
二、我怎样和 AI 一起把想法落成页面
这个项目全程使用了Codex 作为AI辅助工具。小程序前端采用 WXML、WXSS 和 JavaScript，后端使用 Python／Flask，本地开发支持 SQLite，云端使用 CloudBase。这里只交代基本结构，暂时不展开环境搭建。
我的主要协作方式，是把需求写出来，让 AI 协助分析、实现和排查，再根据实际结果继续调整。反复使用的流程是：
描述需求 → 讨论规则 → 确认计划或草图 → 分步实现 → 检查结果 → 继续修正。
例如物品页的搜索，我最初只是觉得上半部分元素太多。讨论之后，需求逐步明确为：搜索在左侧同行展开，右侧筛选和排序保留独立空间，清空关键词不改变其他条件。
（物品页面中左边的搜索和右边的筛选排序）
这些位置和状态说清楚后，才容易比较预期和实际。随着功能增加，我还需要考虑完成顺序、已有流程和运行环境，这也是下面三个阶段里反复遇到的问题。
三、从能运行，到能给别人使用，我经历了什么
1. 先做通一个完整流程
整理最初的物品需求时，可以列出很多想做的东西：照片、分类、保修、收纳位置、使用天数、费用分析。每一项似乎都值得加，但如果同时展开，就很难判断哪一部分已经可以用了。
我逐渐把检查的起点收回到一个具体流程：新增一件物品，保存后在列表找到它，点进详情，再修改并返回。沿着这条路线，才能知道几个页面有没有真正接起来。
检查时，我会用虚构的物品信息去走这个流程：保存后列表有没有更新？点进去是不是刚才那一件？修改名称后，详情和列表是否一致？取消编辑后，原内容是否还在？这些问题比单独打开一张页面更接近日常使用。
遇到问题时，我会把入口、动作和结果一起反馈给 AI。比如，将问题描述整理成修改后返回列表，旧名称还没有更新，比只说刷新有问题更容易继续排查。这里是描述方式的示例，并非当时的逐字对话。
这一步让我开始用操作流程安排任务。先把最基本的记录、保存和查看接通，再加入筛选、统计和更多展示。每次增加一部分，都有一条原来的路线可以回头检查，修改范围也比较容易控制。
2. 在已有项目里加入记账
物品管理逐渐成形后，我又希望把日常收支记录进来。这时项目已经有列表、详情、登录和导航，新功能需要和已有结构接在一起。
最初增加记账时，先完成了导航入口和筹备页面。中间的新增按钮也变成记一笔／添物品两个选择。这样可以先检查入口位置、切换和返回，再逐步接入记账首页、表单、详情、统计以及服务端能力。
这段过程里，我需要先明确页面之间的关系：从哪里开始记一笔，保存后回到哪里，在哪里修改，以及统计读取哪一份账目。对于可选的关联物品，也要说明它承担什么作用，避免不同页面各自理解成另一种规则。
以前只检查新增物品，增加记账以后，就还要检查同一个新增菜单的两个选择。记账保存之后需要刷新流水；从详情修改后返回，统计也可能要更新。同时，原来从物品列表进入详情、再返回的位置，仍然需要保留。
我真的感受到，一个功能的工作量很难只按多了几个页面判断。页面之外，还有返回路径、数据归属、失败后的内容保留，以及切换账户时旧结果的处理。
后来讨论需求时，我会先确认哪些是本次必须完成的，再分步实现。每次修改后，除了试新功能，也重新走一下原来的物品流程。记账与物品怎样关联、哪些记录需要明确确认，也尽量在实现之前讨论。
3. 准备给别人体验，才发现还有很多工作
当页面在本地能够打开，我开始希望别人也可以体验。接下来遇到的事情，已经不只是布局和按钮了。
其中一次很直观的情况是：记账和统计能够进入，却仍显示「功能正在准备中／同步新版服务端」。从页面看，入口和内容已经做了。沿着请求往后检查，才需要继续确认正在连接的服务、服务端版本，以及它是否提供了新的能力。
历史实现为这种情况保留了筹备提示：服务端还不支持，就不假装保存成功。这也让我更具体地理解了前后端同步——本地文件已经更新，并不代表手机连接到的服务也已经更新。
排查这类问题时，需要把几个位置分清：正在编辑哪份源码，开发者工具编译的是哪一份，客户端请求发到哪里，服务端返回了什么。先把这些事实对上，再决定修改代码、更新服务还是重新编译。盲目反复改页面，很容易偏离真正的问题。
另一组问题来自运行包和图片。小猫插画、物品图标越来越多以后，项目实际遇到过上传包体超限。处理过程涉及检查资源、压缩构建和分包，还要继续核对跨包页面是否能进入、图片路径是否正确。
图片格式也有过调整。登录插画曾尝试使用 WebP，后续兼容修正又改回同尺寸的透明 PNG，并核对实际编译资源。文件更小只是其中一个考虑，最终还需要看微信运行时能否正确加载。
走到这一步，我才更具体地接触到交付包含的内容：功能实现、环境同步、资源加载、检查记录，以及使用者真正能不能顺利完成操作。
四、目前对我有用的几个协作习惯
沿着这三个阶段回看，我逐渐形成了几条对自己有用的做法。
按完整流程拆任务。 先说清楚入口、保存和返回，再逐步补上扩展能力。这样每次修改后，都有一条明确的检查路线。
新增功能时，回查已有操作。 加入记账后，既试记一笔，也检查添物品和原来的列表返回。提前写下这些关联，比较容易发现遗漏。
反馈问题时带上上下文。 除了截图，还说明设备、版本、入口、操作和预期结果。有关保存的问题，也尽量说明内容是否已经提交，避免重复操作带来新的困惑。
把完成说明当成检查入口。 AI 给出总结后，我仍然需要自己操作核心流程。哪些只是本地通过，哪些已经在微信里确认，记录时分开写。
让记录跟着修改一起更新。 不只保留最后的代码，也留下选择这个方案的原因和待验项。项目继续扩展时，这些记录能帮助我重新理解之前的决定。
这些习惯还在调整中。我希望自己逐渐具备更明确地提出问题、理解修改并判断结果的能力，当然，以上也只是我作为大学生的见解，也欢迎大家补充更适合初学者的做法。
五、现在还有哪些不足
目前我最需要继续补的是对代码和整体结构的理解。能够借助 AI 做出功能之后，还需要逐步弄清楚数据从哪里来、修改会影响哪些页面，以及出现问题时该从哪里查起。
另一个问题是验证覆盖。不同手机、系统字体、键盘和底部安全区域，都会带来模拟环境里不明显的差异。对没有实际验证的部分，我需要继续补测，也欢迎大家提供复现信息。
后续我想先把已有流程打磨顺畅，把规则和测试补扎实，再考虑增加功能（不过个人目前感觉功能已经相对完善了）。
六、欢迎体验，也想请大家指点
如果你对这个方向感兴趣，可以在微信「搜一搜」搜索 猫爪物账。项目源码和文档放在 GitHub 仓库，也可以通过 Issues 提交建议。
对于有经验的开发者，我想请教一下，初学者应该优先理解哪些部分，才能更好地维护 AI 协助生成的项目？
对于愿意实际体验小程序的朋友，万分感谢，同时也想听听你们的使用体验，新增物品和记一笔是否顺手？统计能不能看明白？哪个细节最影响你继续使用？
这次实践让我更具体地接触到需求、规则、实现和验证之间的关系。文章里讲得不准确的地方，欢迎大家指出，也欢迎分享你在 AI 辅助开发中遇到过的类似问题。
