企业官网建设流程全解析

第一步：把零散的想法丢给 CodeX，换回一份可落地的需求文档

做「邻里速联」这个小程序的念头，其实起源于很细碎的日常。

住在建成十几年的老小区里，总会遇到各种临时的小需求：家里装家具缺个六角扳手，想找邻居借一下；上班赶不上快递派送，想找同单元的人帮忙代收；孩子闲置的绘本和玩具扔了可惜，想转给同小区的家庭；物业发的停水停电通知，总是淹没在微信群几百条聊天记录里，等看到的时候早就晚了。

这些需求说大不大，但解决起来都很麻烦：发业主群大概率石沉大海，专门下一个社区 APP 又太重，绝大多数人用两次就会卸载。我就想做一款极致轻量化的微信小程序，只服务同一个小区的住户，主打邻里互助和信息互通，不用下载、不用复杂注册，打开就能用，用完就走。

最开始这些想法全是碎片化的，今天想到要加闲置转让，明天觉得得有代取快递，后天又想加上报修和通知功能，越想越乱，既分不清哪些是核心功能，也不知道该从哪里下手。放在以前，我可能要对着空白文档磨两三天，才能勉强理出一个粗糙的框架，还很容易漏细节。

这次我直接换了个思路：把脑子里所有零散的想法、痛点、预期，一股脑扔给 CodeX，让它帮我梳理成一份结构化的产品需求文档。

我没有刻意整理成规范的产品话术，就像和搭档聊想法一样，把所有诉求直白地说了出去：

我想做一款叫「邻里速联」的微信小程序，面向同一个小区的住户。 核心解决四个痛点：

1. 邻里临时互助，比如借工具、代收快递、临时照看宠物，发布后能快速被同小区的人看到
2. 小区内闲置物品流转，都是邻居自提方便，不用走快递
3. 物业 / 社区官方通知集中展示，不用在微信群翻聊天记录
4. 必须有小区认证，只有同小区住户才能进入，保证隐私和安全 不要做社交论坛、不要积分体系、不要复杂活动，主打高效、即时、用完即走。 帮我输出一份完整的产品需求文档，包含产品定位、目标用户、核心功能模块、用户使用流程和非功能需求。

没过多久，CodeX 就输出了一份结构完整的 PRD，把我一团乱麻的想法，梳理成了清晰可执行的体系。它不仅把我提到的需求全部落地成了具体模块，还补全了很多我一开始完全没考虑到的细节：

• 明确了产品定位：小区邻里即时互助与轻量化信息互通工具
• 拆分出四大核心模块：邻里互助、闲置流转、社区通知、个人中心
• 定义了三类用户角色：普通住户、物业管理员、平台管理员，各自对应不同的权限
• 梳理了每个功能的完整闭环流程，从发布、响应、沟通到完结
• 补充了小区认证机制、内容审核规则、隐私保护规则、异常场景兜底等边界逻辑

当然第一版也不是完美的。比如它默认加入了邻里话题、积分奖励、社区活动报名这类我明确说过不要的功能，整体功能颗粒度也偏粗，很多字段和规则没有细化，没法直接用来开发。

于是我又补了几轮约束，一步步收窄边界：砍掉所有非核心功能，明确每个模块的发布字段、展示规则、有效期设置，细化小区认证的校验逻辑，限定小程序只做微信原生开发、不引入多余框架。前后打磨了三版，最终得到了一份逻辑清晰、边界明确、完全符合预期的需求文档。

第二步：把 PRD 丢给 CodeX 生成开发计划，我揪出了 3 个关键认知偏差

敲定「邻里速联」最终版 PRD 的时候，我没有像以前做项目那样直接上手写代码。

踩过太多次 “边想边写、越写越偏” 的坑：一开始只想做个简单的发布功能，写着写着忍不住加评价、加积分、加私信系统，到最后架构兜不住、工期越拖越长，干脆烂尾搁置。个人项目死掉的原因，往往不是技术太难，而是从一开始就没画清路线图。

所以这一次我选择先慢后快：把完整的需求文档扔给 CodeX，让它先输出一份可执行的开发计划。等路线完全对齐、确认没有认知偏差了，再正式动工。

我给 CodeX 提了什么要求

我直接把整份 PRD 文档作为上下文发给了 CodeX，同时补充了几个非常现实的个人项目约束：

基于这份「邻里速联」小程序 PRD，输出完整的开发执行计划。 约束条件：单人独立开发、目标 4 周内上线核心版本、技术栈限定微信小程序原生 + Node.js 后端、遵循最小可用原则、不做冗余功能、尽量降低初期运维成本。 计划需要包含：技术架构选型、前后端目录结构、功能模块优先级、分阶段开发排期、潜在风险与应对方案。

我的想法很明确：不要给我 “教科书式的完美方案”，要给我 “一个人能落地的现实方案”。

很快 CodeX 就返回了第一版计划，结构非常规整，从顶层架构到文件目录都给得明明白白。整份计划核心分为五部分：

1. 技术架构选型：包含前端、后端、数据库、部署方案、鉴权体系的完整建议
2. 目录结构规划：前后端各层拆分精确到文件夹，页面、组件、中间件、数据模型各司其职
3. 功能优先级分级：按 P0 核心、P1 重要、P2 优化拆分所有功能，标注依赖关系
4. 五阶段开发排期：从项目初始化到上线发布，每个阶段有明确的交付物
5. 风险与应对预案：列了性能、并发、数据一致性等常见技术风险

第一眼看过去的直观感受是：全，真的全。很多我打算 “到时候再说” 的边角逻辑，比如操作日志、数据统计、异常重试机制，它都默认排进了计划里。但仔细往下捋就会发现，这份计划更像给一个小团队做的标准方案，放在 “单人开发、快速上线” 的现实里，有不少地方和我的想法存在偏差。

逐条审查：三处核心的认知分歧

我对着计划逐行过了一遍，把所有和预期不符的地方都标了出来。核心分歧集中在三个地方，也非常典型地反映了 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 派活，颗粒度越细，结果越可控。不能让它一次性做完整个项目，要按照开发阶段分层交付，做完一阶段，验收一阶段，再进入下一阶段。

我按照最终的四阶段计划，把任务拆成了四个批次，每一批都有明确的输入、约束和验收标准：

1. 第一批次：基础架构搭建。只做项目初始化、目录结构、全局配置、基础工具封装，不碰任何业务逻辑
2. 第二批次：身份体系开发。只做微信登录、小区认证、权限校验，保证第一道防线先跑通
3. 第三批次：核心业务模块。逐个开发邻里互助、闲置流转、社区通知，一个模块做完验收完，再做下一个
4. 第四批次：体验与合规补全。加载态、空状态、错误提示、敏感词过滤、举报功能等边角内容

每个任务派发时，我都会同步给出三条硬约束：

• 严格遵循之前约定的目录结构和命名规范
• 只做当前任务范围内的事，不主动新增额外功能
• 所有代码必须加必要的注释，关键逻辑写明作用

这样一来，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 划好审美边界

在正式优化前，我先定下了三条不可动摇的设计原则，同时给出了一套具体的设计参数，作为所有页面的统一基准。

三条核心原则

1. 克制优先，绝不冗余：所有视觉元素都必须服务于信息传递，不加任何无意义的装饰、渐变、插画
2. 温和邻里感：用低饱和色调、圆角、柔影弱化工具的生硬感，传递信任、亲近的邻里氛围
3. 效率第一：核心操作要醒目，信息层级要清晰，不能为了视觉效果增加用户的认知成本

具体设计参数

我直接把一套可落地的设计规范扔给了 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 不知道平台的具体限制边界。

这一步的真实心得