在不同的城市之间迁徙久了，我发现市面上几乎没有一份真正能帮旅居者做决策的指南。网络上充斥着“某某小城物价低到哭”、“神仙治愈旅居地”的营销笔记，却很少有人平实地讲清楚：冬天洗澡水压够不够、短租能不能按月签、去医院看病方不方便、夏天到底闷不闷热。
做「住下来-城市旅居指南」的初衷很简单：先服务我自己，再服务那些同样想换个城市生活的人。
但我完全不会写代码。
从最初的一个点子，到今天微信小程序正式发布、收录全国 80 座城市、上百项细分生活指标，整个项目由我负责产品定义与体验把关，指挥 AI （ Codex 及相关编程 Agent ）完成全部代码编写。
回看这一个多月的开发过程，我经历了三次推倒重来。这篇文章不讲空泛的 AI 奇迹，只记录一个不懂代码的普通人，在真实开发中踩过的坑、做过的决断，以及如何让 AI 听懂人话。
一、 三次推倒重来：产品逻辑永远先于开发省事
不懂代码的人做产品，最容易犯的错误是“按开发路径想问题，而不是按用户场景做决断”。在走向原生小程序之前，我把能跑通的版本推翻了三次。
1.承认入口错了：从 Web 工具站到小程序
最早我想做的是一个桌面端 Astro 工具站，后来又试了 Vite + React 的移动端网页。
当时我花了大量时间调整视觉排版，总觉得哪里不对劲，改了好几版依然不满意。直到有一天我在路上看房，站在烈日下用手机浏览器翻找旅居信息，我才突然惊醒：问题不在视觉好不好看，其实产品入口本身就选错了。
旅居者都在用手机，没人会天天背着电脑在咖啡馆查生活指数；而在手机浏览器里输入网址、翻找书签的链路太长了，用完一次很难留存。旅居决策虽然重，但查询动作必须轻。
刚好 7 月微信开发者工具面向编程 Agent 开放了一套可操作、可调试、可验证的开发 Skills 。我当即决定：不做独立网页了，改做微信小程序。
2.放弃“跨端便利”：推倒能跑的 Taro ，改写纯原生
为了兼顾以后的网页端和现在的小程序，我最初选择了 Taro ，想用一套 React 代码同时构建 H5 和小程序。
代码很快跑通了，但我拿真机一测，手感始终不对——页面切换有细微的掉帧，长列表滚动发涩，部分组件在小程序里的反馈总有一种“套壳感”。
那是整个开发过程中我最想放弃的时刻。明明已经有一套能跑的代码，要把它全部作废，改用我毫无概念的 WXML 、WXSS 和 JavaScript 原生语言重写，挫败感极大。
但我知道，如果连我自己都不想滑这个页面，用户更不会多看一眼。我咬牙把 Taro 代码全部推倒。当第一版纯原生页面在真机上跑起来、滑动和弹窗恢复成微信系统级的丝滑时，我知道这个决定做对了。（ 8 月 13 日，我正式将旧的 Web 和 Taro 代码全部移出项目库。）
3.从 4 座城到 80 座城：撞上微信的物理天花板
最初测试只有 4 座城市，体验很轻快。但当我把城市库扩展到 80 座、每座城市包含几十项指标、片区数据、白名单和真实消费区间时，工程现实给我上了一课：
微信小程序单个分包有 2MB 的严格上限；
第一次点开城市详情页时，内存瞬间飙升了约 50MB ，低端机直接发热卡顿。
不懂代码的我，起初根本不知道什么是内存溢出和主包体积。但使用体感是骗不了人的：点开卡顿、加载发白。最后我和 AI 磨了好几天，把原本一股脑塞进前端的巨型 JSON 全拆了，做成按需请求、片区配套离线派生、静态地图按需加载。
二、 不懂代码的人，到底该怎么指挥 AI ？
很多人问我：“你连一行代码都不会写，怎么让 AI 写出 80 座城市的小程序？”
我的体会是：AI 不是搜索引擎，也不是神仙，它是一个极度聪明但缺乏真实生活经验的初级程序员。
如果你只对它说“帮我写个旅居页面”，它只会给你一堆花里胡哨、堆满各种营销热词的模板垃圾。
在整个项目中，我最常用的提示词指令往往长这样：
“请脱离技术实现细节，先从成熟的产品逻辑、真实旅居用户的心智动机，以及本项目现有的设计规范（ tokens ）进行分析。告诉我用户的核心痛点是什么、当前方案有哪些违背常理的地方，先给我 2 套方案并列出利弊，由我评估修改后再动代码。”
指挥 AI 的本质，是把“人的常识与体验边界”变成“机器的约束条件”：
1.建立一套死磕到底的规范（ Design Tokens & Rules ）
AI 最容易产生“审美与文案的随机漂移”：今天写个深蓝按钮，明天给你整出个花哨的渐变大阴影；或者满屏堆砌像房地产广告一样的空话。
为了彻底治好 AI 的随性，我在项目一开始就给它立下了边界：
第一，用 Design Tokens （设计令牌）锁定视觉零件箱
整套小程序的视觉规范被抽离成唯一的事实源，AI 写代码只能从这个零件箱里取积木，严禁随手手写非标样式：
色彩体系：温润的纸质底色、卡片面色、主次文字层级，以及三种固定状态色（适合/注意/劝退）；
字号与排版阶梯：锁定微信官方标准的 24 / 28 / 30 / 34 / 44rpx 字号与固定行高；
间距与版式网格：严格按固定档位（ 8/16/24/32/48rpx ）对齐，不留随意空白；
圆角与边框：统一的卡片轻圆角与 1px 极细边框，拒绝浓厚的大阴影。
第二，在文案与逻辑上立下不可逾越的铁律
严禁营销大词，一律换成具体动线与事实：禁止在文案里出现“得天独厚、治愈感、松弛感、极佳、原生态、触手可及、无缝衔接”等虚词。只要 AI 敢写这些，立刻打回，必须换成生活常识——比如把“生态环境极佳”改成“下楼步行 5 分钟到公园与湿地”；把“交通极为高效”改成“高铁半小时直达省会、出站有直达公交”。
文案必须“说人话”，符合生活常识：AI 很喜欢用生硬的主谓搭配（比如“空间很好懂”、“交通随时走”）。我要求所有句子必须符合日常逻辑，写清楚“谁在什么地方做什么事、会有什么结果”，不玩文艺腔。
敢于真实劝退，拒绝幸存者偏差：每座城市不能只挑好听的说，必须包含明确的“劝退人群”、“生活摩擦点”和“避开月份”（比如夏天潮湿闷热、冬季取暖成本高、外卖选择少等真实痛点）。
数据驱动，严禁为单城手写特例：80 座城市必须跑在同一套数据校验与渲染规范里，绝不允许 AI 为了某座城市的排版“单独手写特例代码”。
有了这些铁律作为边界，AI 就不是在无序放飞，而是在严格的轨道上高效施工。它吐出来的每一行 WXML 和 WXSS ，都在这套约束范围内。
2.人定标准，AI 跑落地
比如做“城市评分模型”：
我负责定义人话：旅居看重的是短期租房容易度、淡旺季温差、生活物价与医疗便利，长住才看学位和就业；短租不能套用长租模型。
AI 负责翻译成算法：把这些体感转化为具体的维度权重、阈值校验和无障碍呈现。
3.善用微信开发者的 Agent Skills
7 月份微信开发者工具提供的 Agent 能力帮了大忙。AI 不仅是在聊天框里吐代码，它能直接通过命令行和技能接口操作开发者工具、编译代码、在模拟器上捕获报错，并自行验证修复。我负责在真机上划动、体验、挑刺，然后把“哪里不爽”告诉它。
三、 代码门槛消失后，什么才是壁垒？
现在，这个小程序已经正式上线。80 座城市的数据依然在持续校准，每天都有新的真实生活反馈被补充进去。
后续我依然会做网页版，但不是作为简单的手机搬家，而是把它做成一个“旅居决策证据看板”——大屏幕适合用来做严肃的多城数据交叉比对、查阅资质与历史气候图表，而小程序则负责在路上随时查阅。
回看这一路，最大的感受就是：在 AI 时代，“不会写代码”已经不再是把想法变成产品的阻碍。
代码只是一种表达媒介。真正的壁垒，是你是否在真实世界里生活过、是否真切地体会过某个群体的痛点、是否在面对劣质交互时有推倒重来的勇气，以及你能不能清晰、严密地把你的生活常识表达出来。
如果你也有一个想了很久的点子，别被代码吓退。去定义它、拆解它，找一个懂你的 Agent ，把它做出来。
