第一步把零散的想法丢给 CodeX换回一份可落地的需求文档做「邻里速联」这个小程序的念头其实起源于很细碎的日常。住在建成十几年的老小区里总会遇到各种临时的小需求家里装家具缺个六角扳手想找邻居借一下上班赶不上快递派送想找同单元的人帮忙代收孩子闲置的绘本和玩具扔了可惜想转给同小区的家庭物业发的停水停电通知总是淹没在微信群几百条聊天记录里等看到的时候早就晚了。这些需求说大不大但解决起来都很麻烦发业主群大概率石沉大海专门下一个社区 APP 又太重绝大多数人用两次就会卸载。我就想做一款极致轻量化的微信小程序只服务同一个小区的住户主打邻里互助和信息互通不用下载、不用复杂注册打开就能用用完就走。最开始这些想法全是碎片化的今天想到要加闲置转让明天觉得得有代取快递后天又想加上报修和通知功能越想越乱既分不清哪些是核心功能也不知道该从哪里下手。放在以前我可能要对着空白文档磨两三天才能勉强理出一个粗糙的框架还很容易漏细节。这次我直接换了个思路把脑子里所有零散的想法、痛点、预期一股脑扔给 CodeX让它帮我梳理成一份结构化的产品需求文档。我没有刻意整理成规范的产品话术就像和搭档聊想法一样把所有诉求直白地说了出去我想做一款叫「邻里速联」的微信小程序面向同一个小区的住户。 核心解决四个痛点邻里临时互助比如借工具、代收快递、临时照看宠物发布后能快速被同小区的人看到小区内闲置物品流转都是邻居自提方便不用走快递物业 / 社区官方通知集中展示不用在微信群翻聊天记录必须有小区认证只有同小区住户才能进入保证隐私和安全 不要做社交论坛、不要积分体系、不要复杂活动主打高效、即时、用完即走。 帮我输出一份完整的产品需求文档包含产品定位、目标用户、核心功能模块、用户使用流程和非功能需求。没过多久CodeX 就输出了一份结构完整的 PRD把我一团乱麻的想法梳理成了清晰可执行的体系。它不仅把我提到的需求全部落地成了具体模块还补全了很多我一开始完全没考虑到的细节明确了产品定位小区邻里即时互助与轻量化信息互通工具拆分出四大核心模块邻里互助、闲置流转、社区通知、个人中心定义了三类用户角色普通住户、物业管理员、平台管理员各自对应不同的权限梳理了每个功能的完整闭环流程从发布、响应、沟通到完结补充了小区认证机制、内容审核规则、隐私保护规则、异常场景兜底等边界逻辑当然第一版也不是完美的。比如它默认加入了邻里话题、积分奖励、社区活动报名这类我明确说过不要的功能整体功能颗粒度也偏粗很多字段和规则没有细化没法直接用来开发。于是我又补了几轮约束一步步收窄边界砍掉所有非核心功能明确每个模块的发布字段、展示规则、有效期设置细化小区认证的校验逻辑限定小程序只做微信原生开发、不引入多余框架。前后打磨了三版最终得到了一份逻辑清晰、边界明确、完全符合预期的需求文档。第二步把 PRD 丢给 CodeX 生成开发计划我揪出了 3 个关键认知偏差敲定「邻里速联」最终版 PRD 的时候我没有像以前做项目那样直接上手写代码。踩过太多次 “边想边写、越写越偏” 的坑一开始只想做个简单的发布功能写着写着忍不住加评价、加积分、加私信系统到最后架构兜不住、工期越拖越长干脆烂尾搁置。个人项目死掉的原因往往不是技术太难而是从一开始就没画清路线图。所以这一次我选择先慢后快把完整的需求文档扔给 CodeX让它先输出一份可执行的开发计划。等路线完全对齐、确认没有认知偏差了再正式动工。我给 CodeX 提了什么要求我直接把整份 PRD 文档作为上下文发给了 CodeX同时补充了几个非常现实的个人项目约束基于这份「邻里速联」小程序 PRD输出完整的开发执行计划。 约束条件单人独立开发、目标 4 周内上线核心版本、技术栈限定微信小程序原生 Node.js 后端、遵循最小可用原则、不做冗余功能、尽量降低初期运维成本。 计划需要包含技术架构选型、前后端目录结构、功能模块优先级、分阶段开发排期、潜在风险与应对方案。我的想法很明确不要给我 “教科书式的完美方案”要给我 “一个人能落地的现实方案”。很快 CodeX 就返回了第一版计划结构非常规整从顶层架构到文件目录都给得明明白白。整份计划核心分为五部分技术架构选型包含前端、后端、数据库、部署方案、鉴权体系的完整建议目录结构规划前后端各层拆分精确到文件夹页面、组件、中间件、数据模型各司其职功能优先级分级按 P0 核心、P1 重要、P2 优化拆分所有功能标注依赖关系五阶段开发排期从项目初始化到上线发布每个阶段有明确的交付物风险与应对预案列了性能、并发、数据一致性等常见技术风险第一眼看过去的直观感受是全真的全。很多我打算 “到时候再说” 的边角逻辑比如操作日志、数据统计、异常重试机制它都默认排进了计划里。但仔细往下捋就会发现这份计划更像给一个小团队做的标准方案放在 “单人开发、快速上线” 的现实里有不少地方和我的想法存在偏差。逐条审查三处核心的认知分歧我对着计划逐行过了一遍把所有和预期不符的地方都标了出来。核心分歧集中在三个地方也非常典型地反映了 AI 做计划的天然倾向。1. 功能边界AI 追求 “完整闭环”我要 “最小可用”这是最明显的一处差异。 CodeX 的计划里不仅把邻里互助、闲置流转、社区通知放进了核心阶段还顺带把用户评价体系、积分奖励、实时私信、完整物业管理后台都排进了 P1 阶段理由是 “形成完整业务闭环提升用户体验”。但我的判断非常明确这些一期全都不要。 对一个从 0 到 1 的小区工具来说核心闭环只有四个动作认证小区 → 发布信息 → 浏览信息 → 联系对方。多一个功能都是负担。评价和积分是用户量起来之后才需要考虑的增长工具管理后台初期我直接操作数据库就能搞定完全没必要花一周时间去做一套界面。个人开发最珍贵的资源是时间。什么都想做的结果就是什么都做不完。2. 开发顺序AI 先做业务功能我坚持先搭身份防线CodeX 默认的开发顺序是先搭项目骨架 → 开发互助、闲置两大核心业务模块 → 最后补小区认证与权限体系。 在它的逻辑里认证是辅助功能业务功能才是主体应该先把主流程跑通。而我认为小区认证是整个产品的信任基石必须前置。 这款小程序的核心价值就是 “同小区邻里”如果谁都能进来发信息、看内容邻里属性会直接消失很快就会被广告、无关信息填满。哪怕认证流程做得简单粗糙一点也必须放在第一阶段 —— 用户打开小程序必须先选小区、提交认证审核通过才能进入主页这是不能让步的产品底线。所以我直接把小区认证、微信登录、权限校验全部提到了第一阶段作为整个项目的第一道关卡。3. 技术路线AI 推荐云开发降本我选择自建服务控权技术选型上也出现了分歧。 CodeX 首推的方案是微信云开发不用买服务器、不用搭数据库、不用管运维前端直连云函数个人开发上线速度最快成本也极低。但我最终还是选了轻量服务器 自建 Node.js 服务 MySQL的方案。 原因有两个一是我做这个项目本身就有完整走一遍全栈流程的目的云开发会屏蔽掉太多后端细节二是自建服务灵活性更高后续想对接第三方服务、扩展复杂功能限制会少很多。云开发虽然上手快但越到后期越容易被平台能力绑定想做深度定制反而麻烦。我把理由反馈给 CodeX 之后它也很快调整了整套方案同步输出了自建服务的目录结构、接口规范和部署建议。额外的偏差风险认知的错位还有一个很有意思的细节CodeX 列的风险点大多是并发量过高、接口性能瓶颈、数据一致性这类 “规模化之后的问题”。 但对一个刚上线的个人项目来说这些风险根本不存在。真正需要担心的是小程序类目审核不通过、内容合规踩红线、个人精力不够导致烂尾。 这些和人、规则、时间相关的风险是 AI 很难预判到的必须自己补进去。三轮对齐敲定最终开发路线我把这些调整一条条反馈给 CodeX说明我的判断和理由让它基于新的约束重新生成计划。前后打磨了三轮砍掉了所有非核心功能调整了开发顺序敲定了技术路线最终得到了一份四阶段的开发计划。第一阶段基础架构与身份体系优先级最高搭前后端项目骨架、全局工具层、数据库表结构完成微信登录、小区选择与认证申请、权限校验。验收标准用户必须认证通过才能进入主页。第二阶段三大核心业务模块依次开发邻里互助、闲置流转、社区通知三个模块每个模块单独开发、单独自测保证单个功能闭环可用。第三阶段体验补全与合规建设补全加载态、空状态、错误提示等体验细节加入敏感词过滤、内容举报机制满足小程序平台合规要求。第四阶段测试部署与上线准备全流程测试、兼容性测试、服务器部署、域名配置、小程序资质与类目提交。第三步敲定最终开发计划我把编码执行全交给了 CodeX前后三轮对齐最终版开发计划落定的那一刻我没有像往常一样打开编辑器从零开始建目录、写配置、敲样板代码。这一次我换了个角色从一线编码者变成了任务派发者和结果验收者。整份开发计划被我拆成了一个个边界清晰的小任务依次丢给 CodeX由它来完成绝大多数的代码编写与落地执行。1. 给 AI 派活的正确姿势分层拆解逐次交付最开始我踩过一个小坑直接把整份 PRD 和开发计划扔过去说 “帮我把这个小程序开发出来”。结果输出的代码逻辑混乱、结构松散很多地方和预期不符改起来反而更费时间。几次试错后我总结出一个规律给 AI 派活颗粒度越细结果越可控。不能让它一次性做完整个项目要按照开发阶段分层交付做完一阶段验收一阶段再进入下一阶段。我按照最终的四阶段计划把任务拆成了四个批次每一批都有明确的输入、约束和验收标准第一批次基础架构搭建。只做项目初始化、目录结构、全局配置、基础工具封装不碰任何业务逻辑第二批次身份体系开发。只做微信登录、小区认证、权限校验保证第一道防线先跑通第三批次核心业务模块。逐个开发邻里互助、闲置流转、社区通知一个模块做完验收完再做下一个第四批次体验与合规补全。加载态、空状态、错误提示、敏感词过滤、举报功能等边角内容每个任务派发时我都会同步给出三条硬约束严格遵循之前约定的目录结构和命名规范只做当前任务范围内的事不主动新增额外功能所有代码必须加必要的注释关键逻辑写明作用这样一来CodeX 的输出就被牢牢限定在预期范围内很少出现 “自作主张加功能” 的情况。2. 搭完整套项目骨架只用了一个下午第一阶段的基础架构是整个项目里最繁琐、最重复、也最没技术含量的部分。放在以前我自己从零搭完前后端骨架、写完通用工具、跑通基础接口少说也要一两天。而交给 CodeX 之后整个过程几乎是全自动的。它会先按规划好的结构自动创建项目目录从小程序端的 pages、components、utils、config 分层到后端的 routes、controllers、middlewares、models 划分每一层该放什么文件全部一次性建好。接着依次写入全局配置、路由管理、统一请求封装、响应格式中间件、错误处理机制这些通用能力。整个执行过程在界面上清晰可见顶部会实时显示执行进度已运行 3 条命令、已创建 1 个文件已删除 1 个文件、已创建 2 个文件已删除 2 个文件每完成一个子任务都会同步一句进展说明比如 “全局入口已经接管登录态、网络状态和 Socket 连接”“路由和全局样式已完成”文件变更行数实时统计比如抽离全局配置config.js时明确显示10 -0也就是新增 10 行代码无删除内容我印象很深当天下午两点多开始派发任务喝杯茶的功夫小程序端的路由、全局样式、工具层就全部搭完了到傍晚的时候后端的基础服务、数据库连接、鉴权中间件、统一响应也全部跑通了。前后不到半天整个项目的骨架就立起来了放在以前根本不敢想。更省心的是细节。比如网络状态监听、登录态失效自动跳转、接口请求超时重试、空数据占位页这些很细碎但又必须有的东西CodeX 都会默认补上不用我一个个去提醒。3. 业务模块开发一套需求前后端同时落地骨架验收通过之后就进入了核心业务模块的开发。这也是人机协作效率最高的阶段。以前做一个功能流程往往是先设计数据库表 → 写后端接口 → 写前端页面 → 前后端联调 → 改 bug一套下来快则大半天慢则一两天。而用 CodeX 开发流程变成了我描述清楚这个功能的完整规则 → 它同时输出前端页面、后端接口、数据模型、交互逻辑 → 我验收测试 → 有问题微调。比如开发「邻里互助发布」功能时我只给了一段清晰的规则描述开发邻里互助发布功能。 发布字段标题必填20 字内、详情描述必填200 字内、互助类型借东西 / 帮忙跑腿 / 代收快递 / 其他、联系方式选填默认显示微信昵称、有效期1 天 / 3 天 / 7 天。 前端校验必填项后端二次校验只有认证通过的用户才能发布发布成功后返回列表页并刷新。 列表页按发布时间倒序显示标题、类型、发布时间、所在楼栋点击进入详情页。没过多久整套代码就全部生成好了前端发布页表单 校验 提交逻辑、列表页渲染 下拉刷新、详情页展示连样式都按之前定的克制工具风写好了后端对应的数据表模型、发布接口、列表查询接口、详情查询接口、权限校验、参数校验额外补上了发布频率限制、内容长度截断、异常错误提示这些边界处理我要做的就是把代码放进项目里跑一遍看看逻辑对不对、交互顺不顺有不符合预期的地方再告诉它调整。绝大多数时候两三轮微调就能达到可用状态。三个核心业务模块前后只用了一天多就全部开发完成。放在纯手写的时代这至少是一周的工作量。4. 执行不是甩手不管三次关键的方向修正当然全程也不是完全 “躺平” 等输出。开发过程中我做了三次比较关键的修正本质上都是把 AI 从 “完美主义” 拉回 “最小可用”。第一次是砍掉冗余字段。CodeX 默认给互助发布加了很多可选字段比如物品分类、期望回报、发布者楼栋门牌甚至加了图片上传。我直接砍掉了图片和大部分选填项只保留最核心的四个字段。对初期产品来说发布成本越低越好字段越少用户越愿意发。第二次是简化异常处理。CodeX 写的接口异常处理非常完善分级错误码、详细日志记录、失败重试机制、数据回滚方案一套下来非常 “正规”。但对一个初期的个人项目来说完全没必要反而增加了代码复杂度。我让它简化成统一错误提示 基础日志记录够用就行后续有需要再扩展。第三次是收紧权限边界。最开始生成的代码里未认证用户也能浏览部分内容。我直接改成了全域权限拦截除了登录和认证页面其他所有页面和接口必须小区认证通过才能访问。这是产品底线没有商量的余地。5. 这一步我到底在做什么很多人会觉得用 AI 写代码就是自己什么都不用干了。其实完全不是。整个开发执行阶段我写的代码可能不到总量的 10%但我的工作量并没有减少只是从 “体力编码” 转向了 “决策验收”。我不用再写重复的 CRUD、样板代码、通用工具函数但我要想清楚每个功能的规则、边界、交互逻辑我不用再一个个查 API 文档、调样式细节但我要验收每一部分的输出结果修正和预期不符的地方我不用再花大量时间搭骨架、建目录但我要把控整体架构不跑偏不让功能越做越臃肿简单说就是CodeX 负责 “怎么做”我负责 “做成什么样”。它把我从大量机械重复的劳动里解放出来让我可以把精力全部放在产品逻辑和业务规则上。第四步逐环节验收开发结果我揪出了 4 类 AI 编码的典型漏洞所有模块代码生成完毕并不等于开发完成。很多人第一次用 AI 写代码容易踩一个大坑看见文件批量生成、代码整整齐齐就默认功能已经做好了直接拿去上线。实际跑起来才发现主流程看似顺畅一到边界场景就处处出问题。这也是 AI 生成代码的典型特点正常路径近乎完美边缘场景漏洞百出。走完第三步的全量开发后我没有急着部署而是沉下心做了一轮完整的验收测试。对照最初的 PRD 和开发计划从架构到业务、从边界到合规逐层校验也踩中了好几个 AI 编码的共性陷阱。我的验收逻辑四层递进从能跑到好用验收不是随便点两下看看能不能跑通。我把整个检查过程拆成了四层从底层到上层从核心到边缘逐层验证确保不遗漏关键问题。第一层架构与规范校验最先检查的不是功能而是 “项目有没有长歪”。 我会先核对整体目录结构、命名规范、技术栈选型确认 CodeX 没有私自引入额外的依赖、没有偏离约定的分层架构也没有偷偷加进我明确说过不要的功能。 比如我会核对变更文件清单7 个文件更改、新增 329 行、删除 44 行是不是都在预期的模块范围内有没有多出意料之外的文件。这一步看似简单却能提前把很多 “功能越界” 的问题掐死在萌芽里。第二层核心主流程全链路跑通这是最基础的验收完整走一遍用户核心路径确保主业务闭环是通的。 对「邻里速联」来说就是完整走通这条主线微信授权登录 → 选择所在小区 → 提交认证申请 → 审核通过进入主页 → 发布一条邻里互助 → 列表页刷新看到内容 → 点击进入详情页 这条链路只要有一个节点断了整个产品就不可用。好在 AI 生成的主流程代码质量很高这一遍走下来非常顺畅核心逻辑几乎没有大问题。第三层边界与异常场景压测这是最容易出问题、也是 AI 最容易遗漏的部分。 正常输入、正常操作下的表现AI 基本都能处理好但一旦遇到异常操作、极端输入、非常规路径bug 就全出来了。我专门针对每个功能设计了边界测试用例专门测那些 “用户不按常理出牌” 的场景表单什么都不填直接点提交输入远超长度限制的文本未认证用户直接访问内部页面快速连续点击提交按钮断网状态下操作功能分享卡片给未认证用户打开事实证明这一层查出的 bug占了总问题数的 80%。第四层体验与合规细节检查最后一轮补全体验和合规的细节。 体验上检查有没有加载态、空状态有没有占位页、报错提示是不是友好、按钮点击有没有反馈。 合规上检查有没有敏感词过滤、有没有举报入口、用户隐私信息是不是做了脱敏、有没有符合小程序平台的规则要求。 这些东西不影响功能跑通但直接决定了产品能不能上线、用户体验好不好。实测踩坑AI 生成代码最典型的 4 类问题整个验收过程我前后查出了 11 个大小问题其中绝大多数都属于 AI 编码的共性漏洞非常有代表性。1. 前后端字段不一致主流程静默失败这是第一个踩的坑也最典型。 测试邻里互助发布功能时前端填完信息点提交接口返回成功但列表里始终看不到新发布的内容。控制台看请求也没报错状态码 200一切看起来都很正常。 翻了后端日志才发现问题前端传的字段名是helpType后端接口接收的字段是type参数名对不上后端拿到空值就默认存了 “其他” 类型前端筛选又按类型过滤导致内容直接被过滤掉了。本质原因是前后端代码是分批生成的上下文出现了断层两边命名没有对齐。放在以前我要前后端翻代码、对比字段、查日志定位这个问题少说要十几分钟而我把报错现象和两边的代码片段扔给 CodeX它 30 秒就指出了字段名不一致的问题同时同步修正了前后端两端的代码。2. 权限边界有漏洞可绕过小区认证这是产品底线级别的问题。 我之前明确要求除了登录和认证页所有页面和接口必须小区认证通过才能访问。但实测发现如果把详情页直接分享给未认证的用户对方点开链接就能直接看到内容甚至直接调用接口也能拿到列表数据。 CodeX 只在首页加了权限跳转判断既没有做全局路由前置守卫后端接口也只做了登录校验没有加小区认证的统一中间件。相当于大门上了锁但侧门和窗户全是开的。发现问题后我让它补了两层防护前端加全局路由拦截所有非公开页面进入前统一校验认证状态后端加鉴权中间件所有业务接口统一校验小区认证权限从接口层彻底堵死越权访问的可能。3. 边界场景处理缺失异常操作直接出问题这类 bug 数量最多也最细碎。 比如发布表单前端做了 20 字的标题长度限制但后端没有二次校验我用工具直接调用接口传入超长字符串直接触发了数据库字段长度报错 再比如提交按钮没有做提交中状态锁快速连续点击两次就会重复发布两条完全一样的内容 还有空数据的情况小区列表为空、互助列表为空的时候页面直接一片空白没有任何占位提示。这些都是非常典型的 “AI 盲区”它默认用户会按正常流程操作、输入合法内容不会主动去考虑极端输入和异常操作。而这些边界问题恰恰是线上最容易出故障的地方。4. 平台 API 使用过时上线就会失效这是很隐蔽的一类问题。 CodeX 生成的获取用户信息的代码用了旧版本的微信 API而这套接口早在几个版本前就被微信废弃了现在只能通过按钮触发授权。本地开发的时候看着没问题真上线了就会直接失效。 类似的还有域名校验、请求限制、用户隐私协议相关的逻辑AI 的训练数据往往滞后于平台最新规则很容易给出已经过时的实现方案。第五步给功能穿上合身的 “外衣”我和 CodeX 协作完成 UI 质感升级核心功能全部跑通、bug 也修得差不多的时候整个项目已经处在 “能用” 的状态了。但打开页面总觉得少了点什么CodeX 生成的初始 UI 规范、工整所有按钮、列表、表单都能正常工作可就是一股浓重的 “默认组件风”冰冷、生硬没有邻里产品该有的温度感也完全没有产品辨识度。对工具类小程序来说UI 不需要花哨但一定要 “对味”。它得让用户打开就觉得舒服、可信符合 “邻里互助” 的温和定位同时保持轻量化不能为了好看加一堆冗余元素拖慢速度。所以我专门留出了第五步做一轮完整的 UI 优化。目标很明确不推翻原有功能结构只在现有骨架上做质感升级让产品从 “能用” 变成 “好用且舒服”。优化前的现状功能完备但缺少灵魂CodeX 生成的初始界面是非常典型的 “工程师审美”优点是高度统一所有页面的按钮、列表、表单样式一致没有错乱的排版信息完整度很高缺点也很明显信息平铺所有文字权重差不多用户扫一眼抓不住重点全是默认组件的直角、硬分割线视觉生硬空状态、错误页只有一句 “暂无数据”完全没有情绪价值整体就是纯工具的冰冷感和 “邻里互助” 的定位完全不搭。最开始我试过让它 “随便优化一下 UI”结果踩了个大坑它加了渐变背景、装饰插画、花哨的标签动效整个页面瞬间臃肿起来完全违背了 “轻量化、用完即走” 的产品原则。几次调整后我摸透了规律让 AI 做 UI绝对不能说 “做得好看点” 这种模糊的话。必须先给它划死边界、定死规则再让它落地执行。先定规则再动手给 AI 划好审美边界在正式优化前我先定下了三条不可动摇的设计原则同时给出了一套具体的设计参数作为所有页面的统一基准。三条核心原则克制优先绝不冗余所有视觉元素都必须服务于信息传递不加任何无意义的装饰、渐变、插画温和邻里感用低饱和色调、圆角、柔影弱化工具的生硬感传递信任、亲近的邻里氛围效率第一核心操作要醒目信息层级要清晰不能为了视觉效果增加用户的认知成本具体设计参数我直接把一套可落地的设计规范扔给了 CodeX主色低饱和暖蓝色#5B8FF9代表信任与温和仅用于核心按钮、重点标签辅助色暖橙色#FF9D4D仅用于强调、提示类信息圆角所有卡片、按钮、输入框统一8px圆角弱化尖锐感卡片轻量阴影0 2rpx 12rpx rgba(0,0,0,0.06)用阴影替代硬分割线字号层级标题 32rpx 加粗、正文 28rpx、辅助信息 24rpx 弱化间距页面左右统一边距 32rpx卡片间距 24rpx用留白替代分割线有了这套明确的规则CodeX 的输出就再也没有跑偏过所有优化都在既定框架内进行。五个核心优化方向批量落地整个优化过程我没有让它一次性改完所有页面而是按模块分批推进先改公共组件和全局样式再逐个优化核心页面确保每一部分都符合预期。1. 统一全局视觉基调从生硬到柔和第一步先改底层把全局的视觉基调拉到位。 我让 CodeX 基于上面的设计规范批量修改全局样式文件和公共组件替换默认的色阶变量把纯黑纯白换成更柔和的灰阶所有按钮、输入框、卡片统一圆角移除页面里多余的硬分割线改用留白和卡片阴影做区块区分。这一步最能体现 AI 的效率优势。如果是我自己改要翻遍十几个页面文件逐个调整样式少说也要大半天。而 CodeX 只用了几分钟就完成了全局样式的批量替换7 个文件同步修改新增 329 行、调整 44 行样式代码整个产品的视觉气质瞬间就柔和了下来。2. 强化列表信息层级让重点一眼可见初始版本的列表页有个很典型的问题所有信息平铺标题、类型、时间、楼栋号字号差不多用户要扫完整行才能找到自己关心的内容。 优化的核心就是做 “权重分级”让信息有主次之分标题加粗放大作为第一视觉重心互助类型做成小巧的标签样式用主色轻量填充放在标题前发布时间、楼栋号缩小字号、降低透明度放在卡片右下角作为辅助信息我只描述了一遍信息优先级的排序CodeX 很快就调整好了列表卡片的样式同时同步优化了闲置列表、通知列表的样式保证三个模块的视觉逻辑完全统一。 改完之后再看列表页扫一眼就能快速抓到 “是什么事、什么类型、哪个楼栋的”信息效率提升非常明显。3. 核心操作显性化降低发布门槛对这类工具型产品来说发布入口的醒目程度直接决定了用户的参与意愿。 初始版本的发布按钮放在页面顶部导航栏旁边又小又不显眼。优化后改成了右下角固定悬浮的主色圆形按钮FAB不随页面滚动消失无论用户滑到列表哪个位置都能一眼看到、一键点到发布页。同时同步优化了发布表单的体验输入框从生硬的线框样式改成浅底填充样式减少视觉压迫感必填项做轻量标记错误提示柔和不突兀提交按钮固定在页面底部不用滑到底部才能点整个发布流程的操作成本降了很多也更符合移动端用户的使用习惯。4. 空状态与反馈升级告别冷冰冰的 “暂无数据”第四步验收的时候就发现所有空列表、空页面都是一片空白加一句 “暂无数据”体验非常粗糙。这一轮优化专门补全了所有场景的空状态。 我没有让它加复杂的插画只配了简单的线性图标再给每个场景写了贴合产品调性的文案邻里互助空页“暂时还没有邻居求助来发布第一条互助吧”闲置列表空页“还没有闲置物品发布家里有闲置可以分享给邻居”通知空页“暂无最新通知有消息会第一时间更新”除此之外还补全了加载态、提交成功提示、错误提示的动效反馈不再是生硬的弹窗而是轻量的 toast 提示和过渡效果整体体验顺滑了很多。5. 细节质感打磨体验藏在看不见的地方剩下的都是很细碎但能明显提升质感的细节统一所有页面的左右边距、元素间距避免有的页面宽、有的页面窄按钮增加点击反馈态按下时有轻微的缩放和透明度变化小区认证页的引导文案从干巴巴的表单说明改成更有邻里感的引导语个人中心的功能入口改成图标加文字的网格布局比纯列表更清晰直观这些东西单拎出来都不起眼但全部加起来整个产品的精致感就上去了。优化过程中踩的两个典型坑整个过程也不是一帆风顺踩了两个很有代表性的坑基本都是 AI 做 UI 的共性问题。第一AI 天生倾向于 “过度设计”。只要约束稍微松一点它就会主动加渐变、加背景装饰、加动效试图让页面 “更丰富”。每次我都要往回拉反复强调 “克制、极简、不要多余元素”。对工具类产品来说做减法永远比做加法难。第二小程序样式兼容性问题。CodeX 偶尔会写出一些微信小程序不支持的 CSS 属性比如某些高级选择器、复杂动画属性本地看着没问题真机上就失效。这部分没有捷径必须靠人来做真机校验和修正毕竟 AI 不知道平台的具体限制边界。这一步的真实心得