1. 项目缘起当“AI全栈”的念头撞上现实大概一个月前我刷到一条视频讲的是有人用AI工具在极短时间内“组装”出了一个可用的应用。当时心里就咯噔一下作为一个有点技术底子但早已远离一线编码的“前程序员”我是不是也能试试这个念头一旦冒出来就有点收不住了。正好手头有个一直想做但没时间或者说懒得动手的小需求一个能帮我管理个人阅读清单并且能根据我的阅读偏好偶尔推荐点冷门好书的小工具。它不需要多复杂但得是我自己能用、爱用的。传统的开发路径我很清楚前端、后端、数据库、部署、运维……一套组合拳下来没个把月根本见不到成品热情早耗光了。但这次我决定做个极端实验在10个晚上的业余时间里完全依赖AI工具从零到一做出一个能上线的微信小程序。不写一行“传统意义上”的代码把AI当作我的产品经理、架构师、前端、后端、测试而我只做那个最终的决策者和“拼接”工程师。我知道这听起来有点疯狂也充满了不确定性。市面上鼓吹“AI取代程序员”的声音很多但真实的一线体验到底如何AI是“银弹”还是“玩具”它真能理解复杂的业务逻辑并输出可运行、可维护的产物吗这10个晚上就是我的寻找答案之旅。最终这个名为“阅栈”的小程序真的上架了。我想和你分享的不是又一个“AI神话”而是这10天里我如何与AI协作、博弈并最终将它落地为产品的完整过程、踩过的坑以及那些出乎意料的惊喜。2. 战前准备定义边界与选择“武器库”在开始第一个晚上的工作前我花了些时间进行战略规划。盲目开始只会让AI带我走进死胡同。核心是明确两件事项目的边界和AI工具的选型。2.1 明确项目范围与MVP最小可行产品这是最关键的一步直接决定了后续所有提示词Prompt的质量和AI输出的方向。我必须给AI一个清晰、无歧义的“设计稿”。我给我的“阅栈”小程序定义了如下MVP功能用户体系基于微信开放能力一键登录无需额外注册。核心功能-书架添加书籍通过手动输入ISBN、书名或扫描书籍条形码添加。书籍信息自动获取封面、作者、出版社、简介等。状态管理标记为“想读”、“在读”、“已读”。简单记录为每本书记录开始阅读和结束阅读的日期。核心功能-发现基于我已读的书籍标签Genre推荐类似风格的书籍。推荐源来自一个开源的图书数据库API。数据存储所有用户数据需要云端存储且不同用户数据隔离。技术栈约束必须使用微信小程序原生开发框架或Uni-App等跨端框架以确保最终能顺利发布到微信平台。这个功能列表非常克制没有任何锦上添花的东西如社交、笔记、复杂统计。记住我们的目标是“快速验证AI全栈开发的可能性”而不是做一个完美的产品。这个清晰的MVP定义将成为我与所有AI对话的基石。2.2 构建我的“AI武器库”我不可能只用一个AI工具完成所有事。根据开发流程我组建了以下工具链核心架构与代码生成Claude 3 Opus / ChatGPT-4角色首席架构师、全栈工程师。选用理由在复杂逻辑推理、长上下文理解和代码生成质量上它们目前是顶尖的。我需要它能理解我从产品描述到技术实现的完整链条并生成结构良好、可运行的代码片段。我会交替使用它们以对比不同模型在具体任务上的表现。UI/UX设计与原型生成Midjourney / 结合 ChatGPT 的提示词工程角色UI设计师。选用理由Midjourney虽然不直接生成代码但能根据描述Prompt产出高质量、具有视觉吸引力的界面截图。我用它来获取设计灵感和确定整体视觉风格如一个干净、有书卷气的移动端界面。然后我会将这种风格描述给Claude/ChatGPT让它生成对应的WXSS微信小程序样式文件代码。代码审查与调试辅助Cursor / GitHub Copilot Chat角色高级工程师、调试伙伴。选用理由当Claude生成了大段代码后我需要一个能深度集成在IDE环境中的AI来帮助我理解、审查和修改。Cursor内置了Claude和GPT-4或VSCode中的Copilot Chat可以直接针对项目中的具体文件提问比如“这个函数为什么报错”、“如何优化这段数据库查询”效率极高。数据与API模拟Airtable ChatGPT角色后端API与数据库模拟器。选用理由在开发初期真正的后端服务器和数据库还没搭建甚至可能不需要。Airtable是一个在线表格工具但它的API功能非常强大。我可以让ChatGPT根据我的数据模型生成Airtable的Base结构并编写出对应的REST API接口说明。前端小程序在开发阶段就直接调用Airtable的API实现数据的增删改查。这让我能完全专注于前端逻辑和用户体验。文档与流程梳理Notion AI角色项目助理。选用理由用来整理每天的工作日志、汇总AI对话中的关键决策、编写最终部署的检查清单。它能帮我从杂乱的对话中提炼出结构化的信息。这个工具链覆盖了从创意到上线的关键环节。我的角色就是这条链子的“总调度”负责在正确的环节向正确的AI发出正确的指令。3. 实战推演十个夜晚的协作流水账接下来我将以时间线的方式还原这10个晚上核心的协作过程。你会发现过程绝非“输入想法输出程序”那么简单。3.1 第1-2晚从想法到可运行的原型骨架目标创建微信小程序项目实现基础框架和登录功能。第一晚项目初始化与AI的“第一课”我的操作我在微信开发者工具中创建了一个新的小程序项目。然后打开Claude给出了第一个“史诗级”Prompt“我将开发一个微信小程序名为‘阅栈’。它是一个个人书籍管理工具。现在请为我生成这个小程序最基础的框架代码1. 包含app.js,app.json,app.wxss的全局配置。2. 创建三个主要页面index首页/发现bookshelf我的书架profile个人中心。3. 在app.json中配置这些页面和底部tabBar。请使用微信小程序原生语法。”AI的回应与我的调整Claude流畅地输出了所有文件代码。但我立刻发现了问题它生成的tabBar图标路径是/images/icon1.png而我项目里根本没有这个目录和图片。这是AI生成代码的典型“幻觉”——它会假设某些资源存在。我的第一个实操心得永远不要直接复制粘贴AI生成的、涉及具体资源路径的代码。我需要要么让AI生成一个创建目录和占位图片的命令要么自己修改为正确的路径。我选择了后者并手动创建了/images/目录放入了几个简单的图标。关键收获AI是强大的代码“起草者”但你是最终的“校对者”和“资源管理员”。它不负责项目的物理结构。第二晚集成微信登录我的操作这是与平台强相关的功能我必须提供精确的上下文。我的Prompt变得更具体“在‘阅栈’小程序的profile页面我需要集成微信一键登录功能。请参考微信官方文档为我生成以下代码1. 在profile.wxml中放置一个登录按钮按钮文字在未登录时显示‘一键登录’登录后显示用户昵称和头像。2. 在profile.js中编写login函数。流程是调用wx.getUserProfile获取用户信息然后将nickName和avatarUrl显示在页面上。同时为了后续使用请将openid或unionid通过wx.login获取code并假设我有一个后端API‘https://myapi.com/login’来交换openid存储在微信小程序的本地存储wx.setStorageSync中。请写出完整的JS逻辑并包含基本的错误处理。”AI的回应与我的调整Claude生成的代码基本正确但关于openid的部分它注释掉了并说明需要我自己的后端服务。这正是时候引入我的“模拟后端”——Airtable。我暂时将登录逻辑简化为只在前端保存昵称和头像用户唯一标识先用一个临时生成的UUID。我告诉AI“暂时不需要openid登录成功后生成一个随机UUID作为本地用户ID存储。” AI很快修改了代码。关键收获对于依赖外部服务微信登录、真实后端的功能在MVP阶段要学会做“减法”和“模拟”。先让核心流程跑通复杂集成后续迭代。AI能很好地理解并执行这种策略调整。3.2 第3-5晚构建核心功能——书架目标实现书籍的添加、展示和管理。第三晚设计数据模型与Airtable Base我的操作我不再直接要代码而是先和AI设计数据结构。我问Claude“为了‘阅栈’小程序的书籍管理功能请帮我设计一个数据模型。一本书Book需要哪些字段一个用户User需要哪些字段用户和书籍之间是什么关系多对多请用一个中间表UserBook来记录用户对书籍的状态想读、在读、已读和阅读日期。请用表格形式列出每个表的字段名、类型和说明。”AI的回应Claude给出了一个非常专业的三表结构设计。基于这个设计我登录Airtable手动创建了三个TableBooks,Users,UserBooks。然后我让ChatGPT根据这个结构生成一套完整的、针对Airtable REST API的CRUD操作示例代码包括API Key的放置位置、请求头设置等。关键收获“设计先行”在与AI协作中至关重要。清晰的数据结构是后续所有功能代码的蓝图。让AI参与设计它能保证后续生成的代码与模型高度一致。第四晚实现扫码添加与手动输入我的操作这是功能密集的一晚。我拆解成两个任务。扫码Prompt是“在bookshelf页面添加一个浮动按钮点击后调用wx.scanCodeAPI扫描书籍ISBN条形码。扫码成功后将获取到的ISBN号码调用一个公共图书API例如‘https://api.example.com/book?isbn’来获取书籍详情。请生成完整的WXML、WXSS和JS代码包含加载状态和网络请求错误提示。”手动输入Prompt是“如果扫码失败或没有条形码用户需要能手动输入书名搜索。请在上面的页面中增加一个搜索框用户输入书名后调用另一个搜索接口例如‘https://api.example.com/search?q’获取书籍列表点击列表项即可添加。”AI的回应与我的调整AI生成的代码逻辑清晰。但最大的坑出现了它提供的公共图书API是虚构的。我不得不自己去寻找真实可用的、免费的图书数据API。我最终找到了“Open Library API”和“豆瓣图书API非官方”。我需要根据真实API的响应数据结构大幅修改AI生成的代码中解析数据的部分。例如AI假设返回的字段是book.title但真实API可能是data.title或works[0].title。关键收获AI不负责外部数据源的可用性和真实性。它生成的网络请求代码是“模板”你必须用真实API的文档去“填充”和“修正”这个模板。这是AI编程中最需要人工介入的环节之一。第五晚书籍列表展示与状态管理我的操作现在数据能添加了需要展示出来。我问AI“在bookshelf页面我需要一个书籍列表。每本书显示封面、书名、作者和当前阅读状态想读/在读/已读。用户可以下拉刷新上拉加载更多。点击某本书进入详情页详情页里可以修改阅读状态和记录阅读日期。请生成bookshelf页面的列表渲染代码和bookDetail页面的表单代码。数据从Airtable中获取Airtable的API地址是https://api.airtable.com/v0/{baseId}/{tableName}。”AI的回应与我的调整AI出色地生成了使用wx.request调用Airtable API、使用wx:for渲染列表、以及实现下拉刷新onPullDownRefresh的代码。我几乎可以直接使用。但在详情页修改状态后更新列表时出现了数据不同步的问题。AI最初的方案是返回上一页并重新加载数据但体验不流畅。我利用Cursor选中相关代码块提问“如何在不刷新整个页面的情况下更新上一页的某个列表项数据” Cursor建议我使用微信小程序的getCurrentPages()方法获取页面栈并直接修改上一页的data中的数据。我采纳了这个方案。关键收获对于常规的UI和交互逻辑AI的生成质量非常高。但对于涉及页面间通信、状态管理等稍微复杂的前端模式需要你具备一定的知识来引导AI或使用Cursor这样的工具进行“精准外科手术式”的调试和优化。3.3 第6-7晚“发现”功能与UI美化目标实现简单的推荐逻辑并让界面看起来像个“产品”。第六晚基于标签的推荐逻辑我的操作推荐算法可以很复杂但MVP要简单。我设计了一个规则从用户已读的书籍中提取所有标签如“科幻”、“历史”找出出现频率最高的两个标签然后用这两个标签去搜索推荐书籍。我把这个逻辑描述给Claude“请编写一个函数getRecommendations(userId)。它首先调用Airtable API获取该用户所有状态为‘已读’的书籍。从这些书籍的‘tags’字段假设是一个用逗号分隔的字符串中统计所有标签的出现频率。选出频率最高的前两个标签。然后用这两个标签作为关键词去调用图书搜索API返回一个书籍列表作为推荐结果。请考虑标签可能为空或重复的情况。”AI的回应Claude完美地实现了这个逻辑代码结构清晰包含了必要的数组操作和统计逻辑。我将这段函数放在了一个独立的utils/recommend.js文件中。这里的一个技巧我让AI将Airtable API的调用封装成了独立的service函数使得主逻辑非常干净。关键收获将业务逻辑推荐算法与页面渲染逻辑分离是保持代码可维护性的关键。AI能很好地理解并实践这种模块化思想只要你明确要求。第七晚用AI辅助进行UI设计我的操作之前的界面非常“开发者预览”。我打开Midjourney输入提示词“A clean, minimalist mobile app interface for a book tracking application, showing a list of books with covers, in a light cozy style, –ar 9:16”。它生成了几张很有质感的图片。我选取了其中一张的配色米白背景、深蓝文字、浅灰分割线和卡片阴影效果。接着我回到Claude将Midjourney的图片描述和我的选择告诉它“请根据以下风格描述优化bookshelf页面的WXSS背景色为#faf8f5主要文字颜色为#2c3e50卡片有轻微的阴影box-shadow: 0 2px 8px rgba(0,0,0,0.08)圆角为12rpx。书籍封面图片固定宽高比标题字体加粗。” AI迅速输出了符合要求的样式代码。我还让它为按钮、加载状态等元素生成了统一的样式。关键收获AI在视觉设计上是“灵感加速器”而非“自动完成器”。你需要用文字精准地描述你想要的风格或者用图片作为参考。AI特别是ChatGPT/Claude能很好地将视觉描述转化为具体的CSS/WXSS代码极大地提升了UI开发效率。3.4 第8-9晚调试、优化与云开发迁移目标解决遗留问题提升体验并为上线做准备。第八晚集中调试与性能优化我的操作我开始在真机上全面测试。发现了几个问题1. 列表图片加载慢且可能变形。2. 首次进入书架页面如果书籍很多感觉有卡顿。3. 网络请求失败时提示不友好。我逐一用Cursor解决图片我问“微信小程序中如何实现图片的懒加载和适应不同比例的裁剪” Cursor给出了使用image标签的lazy-load属性和mode属性如aspectFill的方案。卡顿我问“微信小程序长列表渲染优化有哪些常见手段” Cursor提到了使用wx:for的wx:key、避免在wxml中执行复杂计算、以及考虑使用官方recycle-view组件对于更复杂的列表。我首先确保了wx:key的正确使用。错误处理我让Claude为所有wx.request调用包裹一个统一的错误处理函数并在UI上显示友好的Toast提示。关键收获调试阶段AI是你的“超级搜索引擎”和“代码医生”。你能用自然语言描述问题它往往能直接定位到相关API或最佳实践比传统搜索更快。第九晚从Airtable迁移到微信云开发我的操作Airtable很好但它不是微信生态内的服务存在跨域和配额限制问题。为了正式上线我需要将数据层迁移到微信小程序云开发。这是一个较大的改动。我向Claude描述了整体迁移计划“我将把数据存储从Airtable迁移到微信小程序云开发。请帮我完成以下工作1. 在app.js中初始化云环境。2. 将原有的Books,Users,UserBooks三个Airtable表转换为云开发的三个集合Collection。3. 重写所有数据操作函数将之前调用Airtable API的wx.request改为调用wx.cloud.database()的增删改查方法。请特别注意云开发数据库的权限设置我需要所有用户只能读写自己的数据请生成对应的安全规则示例。”AI的回应Claude给出了详尽的迁移指南和代码对比。例如将Airtable.get()改为db.collection(‘Books’).get()并加入了where条件来实现用户数据隔离。它还生成了基本的数据库安全规则// 云开发安全规则示例 { “read”: “auth.openid doc._openid”, “write”: “auth.openid doc._openid” }关键收获AI擅长进行“模式转换”。只要你清晰地定义了“从A模式Airtable REST到B模式云开发DB的映射规则”AI就能高效地完成代码的重构。这大大降低了更换技术栈的成本。3.5 第10晚提交审核与发布目标走通小程序上线的最后一步。我的操作这晚的工作更偏向于流程和配置。配置小程序信息填写小程序名称、简介、类目等。这些无法由AI代劳。生成隐私协议我让Claude根据小程序的功-能收集微信昵称、头像、书籍信息生成一份简单的用户隐私保护指引。准备审核材料我让Midjourney生成了几张不同尺寸的应用截图和封面图。最终代码检查我用Cursor对主要页面进行了一次“代码审查”提问“请检查以下页面的JS文件是否有明显的性能问题或潜在bug” AI指出了一些未使用的变量和可能为空的属性访问我逐一修复。提交审核在微信公众平台提交代码。第一次审核因为“类目选择不当”被拒。我根据驳回理由重新选择了“工具-效率”类目并在Claude的帮助下修改了部分文案描述第二次提交后顺利通过。4. 复盘与思考AI作为开发伙伴的“能”与“不能”10个晚上一个功能完整的小程序成功上线。这个过程让我对AI编程有了非常立体和真实的认识。4.1 AI的“超能力”它究竟擅长什么从零到一的“脚手架”生成对于创建标准化的项目结构、基础页面、通用CRUD逻辑AI的速度无与伦比。它能把你从重复的体力劳动中彻底解放出来。“翻译官”与“转换器”它能将你的自然语言需求“我要一个带下拉刷新的列表”精准地翻译成某种框架或语言的代码。也能在不同技术栈如从Airtable到云开发之间进行模式转换。永不疲倦的“代码审查员”与“搜索引擎”你可以随时向它提问任何语法、API用法、最佳实践的问题它能立刻给出解释和示例上下文关联能力远超传统搜索。灵感的激发者在UI设计、命名、甚至简单的算法逻辑上它能提供多种选择打破你的思维定式。4.2 AI的“边界”与“陷阱”你必须亲自把关的地方“幻觉”与真实性这是最大的风险。AI会自信地编造不存在的API、库、或方法。你必须对它所使用的技术生态有基本的了解能够验证其输出的真实性。永远不要盲目相信AI提供的任何外部依赖信息。业务逻辑的深度理解AI能实现你描述的逻辑但它无法理解你业务背后的“为什么”。如果最初的逻辑设计有漏洞AI生成的代码只会完美地执行这个有漏洞的逻辑。产品设计与系统架构的核心决策必须由人类完成。复杂状态与交互对于涉及多个组件、页面间复杂通信、非标准交互模式的情况AI容易生成出臃肿或低效的代码。它缺乏对整体应用状态的宏观设计能力。这时需要你进行人工重构和优化。项目管理与集成AI不会帮你管项目。它不知道哪些文件被修改了不知道如何解决版本冲突不知道如何配置CI/CD流水线。这些工程化能力依然是开发者的核心价值。4.3 给想尝试AI开发者的建议从“副驾驶”开始而非“自动驾驶”不要期望AI替你完成所有工作。把它当作一个能力超强但有时会胡言乱语的新手搭档。你负责把握方向、制定规则、审核输出。Prompt工程是核心技能清晰、具体、结构化的Prompt是成功的关键。学会将大任务拆解成原子任务并给AI提供足够的上下文技术栈、已有代码、约束条件。保持一个可运行的状态频繁地运行和测试AI生成的代码。不要等所有代码都生成完再测试那样调试将是灾难。采用小步快跑的方式每完成一个微功能就验证一次。不要放弃学习AI降低了编码的门槛但抬高了设计和架构的门槛。你需要更深刻地理解问题本质、系统原理和用户体验才能给AI发出正确的指令。你的技术判断力决定了AI输出的天花板。这10个晚上的实验与其说是我用AI做了一个小程序不如说是我与AI进行了一场密集的、关于如何将想法转化为产品的对话。AI不是取代者它是一个前所未有的“杠杆”和“放大器”。它放大了我作为“定义者”和“整合者”的价值而将那些重复的、模式化的“实现”工作极大地简化了。未来善于定义问题、拆解任务、并与AI协作的开发者将会获得巨大的效率红利。我的“阅栈”小程序只是一个开始而如何与这位强大的伙伴共舞是我们所有人都需要持续学习的课题。
1. 项目缘起当“AI全栈”的念头撞上现实大概一个月前我刷到一条视频讲的是有人用AI工具在极短时间内“组装”出了一个可用的应用。当时心里就咯噔一下作为一个有点技术底子但早已远离一线编码的“前程序员”我是不是也能试试这个念头一旦冒出来就有点收不住了。正好手头有个一直想做但没时间或者说懒得动手的小需求一个能帮我管理个人阅读清单并且能根据我的阅读偏好偶尔推荐点冷门好书的小工具。它不需要多复杂但得是我自己能用、爱用的。传统的开发路径我很清楚前端、后端、数据库、部署、运维……一套组合拳下来没个把月根本见不到成品热情早耗光了。但这次我决定做个极端实验在10个晚上的业余时间里完全依赖AI工具从零到一做出一个能上线的微信小程序。不写一行“传统意义上”的代码把AI当作我的产品经理、架构师、前端、后端、测试而我只做那个最终的决策者和“拼接”工程师。我知道这听起来有点疯狂也充满了不确定性。市面上鼓吹“AI取代程序员”的声音很多但真实的一线体验到底如何AI是“银弹”还是“玩具”它真能理解复杂的业务逻辑并输出可运行、可维护的产物吗这10个晚上就是我的寻找答案之旅。最终这个名为“阅栈”的小程序真的上架了。我想和你分享的不是又一个“AI神话”而是这10天里我如何与AI协作、博弈并最终将它落地为产品的完整过程、踩过的坑以及那些出乎意料的惊喜。2. 战前准备定义边界与选择“武器库”在开始第一个晚上的工作前我花了些时间进行战略规划。盲目开始只会让AI带我走进死胡同。核心是明确两件事项目的边界和AI工具的选型。2.1 明确项目范围与MVP最小可行产品这是最关键的一步直接决定了后续所有提示词Prompt的质量和AI输出的方向。我必须给AI一个清晰、无歧义的“设计稿”。我给我的“阅栈”小程序定义了如下MVP功能用户体系基于微信开放能力一键登录无需额外注册。核心功能-书架添加书籍通过手动输入ISBN、书名或扫描书籍条形码添加。书籍信息自动获取封面、作者、出版社、简介等。状态管理标记为“想读”、“在读”、“已读”。简单记录为每本书记录开始阅读和结束阅读的日期。核心功能-发现基于我已读的书籍标签Genre推荐类似风格的书籍。推荐源来自一个开源的图书数据库API。数据存储所有用户数据需要云端存储且不同用户数据隔离。技术栈约束必须使用微信小程序原生开发框架或Uni-App等跨端框架以确保最终能顺利发布到微信平台。这个功能列表非常克制没有任何锦上添花的东西如社交、笔记、复杂统计。记住我们的目标是“快速验证AI全栈开发的可能性”而不是做一个完美的产品。这个清晰的MVP定义将成为我与所有AI对话的基石。2.2 构建我的“AI武器库”我不可能只用一个AI工具完成所有事。根据开发流程我组建了以下工具链核心架构与代码生成Claude 3 Opus / ChatGPT-4角色首席架构师、全栈工程师。选用理由在复杂逻辑推理、长上下文理解和代码生成质量上它们目前是顶尖的。我需要它能理解我从产品描述到技术实现的完整链条并生成结构良好、可运行的代码片段。我会交替使用它们以对比不同模型在具体任务上的表现。UI/UX设计与原型生成Midjourney / 结合 ChatGPT 的提示词工程角色UI设计师。选用理由Midjourney虽然不直接生成代码但能根据描述Prompt产出高质量、具有视觉吸引力的界面截图。我用它来获取设计灵感和确定整体视觉风格如一个干净、有书卷气的移动端界面。然后我会将这种风格描述给Claude/ChatGPT让它生成对应的WXSS微信小程序样式文件代码。代码审查与调试辅助Cursor / GitHub Copilot Chat角色高级工程师、调试伙伴。选用理由当Claude生成了大段代码后我需要一个能深度集成在IDE环境中的AI来帮助我理解、审查和修改。Cursor内置了Claude和GPT-4或VSCode中的Copilot Chat可以直接针对项目中的具体文件提问比如“这个函数为什么报错”、“如何优化这段数据库查询”效率极高。数据与API模拟Airtable ChatGPT角色后端API与数据库模拟器。选用理由在开发初期真正的后端服务器和数据库还没搭建甚至可能不需要。Airtable是一个在线表格工具但它的API功能非常强大。我可以让ChatGPT根据我的数据模型生成Airtable的Base结构并编写出对应的REST API接口说明。前端小程序在开发阶段就直接调用Airtable的API实现数据的增删改查。这让我能完全专注于前端逻辑和用户体验。文档与流程梳理Notion AI角色项目助理。选用理由用来整理每天的工作日志、汇总AI对话中的关键决策、编写最终部署的检查清单。它能帮我从杂乱的对话中提炼出结构化的信息。这个工具链覆盖了从创意到上线的关键环节。我的角色就是这条链子的“总调度”负责在正确的环节向正确的AI发出正确的指令。3. 实战推演十个夜晚的协作流水账接下来我将以时间线的方式还原这10个晚上核心的协作过程。你会发现过程绝非“输入想法输出程序”那么简单。3.1 第1-2晚从想法到可运行的原型骨架目标创建微信小程序项目实现基础框架和登录功能。第一晚项目初始化与AI的“第一课”我的操作我在微信开发者工具中创建了一个新的小程序项目。然后打开Claude给出了第一个“史诗级”Prompt“我将开发一个微信小程序名为‘阅栈’。它是一个个人书籍管理工具。现在请为我生成这个小程序最基础的框架代码1. 包含app.js,app.json,app.wxss的全局配置。2. 创建三个主要页面index首页/发现bookshelf我的书架profile个人中心。3. 在app.json中配置这些页面和底部tabBar。请使用微信小程序原生语法。”AI的回应与我的调整Claude流畅地输出了所有文件代码。但我立刻发现了问题它生成的tabBar图标路径是/images/icon1.png而我项目里根本没有这个目录和图片。这是AI生成代码的典型“幻觉”——它会假设某些资源存在。我的第一个实操心得永远不要直接复制粘贴AI生成的、涉及具体资源路径的代码。我需要要么让AI生成一个创建目录和占位图片的命令要么自己修改为正确的路径。我选择了后者并手动创建了/images/目录放入了几个简单的图标。关键收获AI是强大的代码“起草者”但你是最终的“校对者”和“资源管理员”。它不负责项目的物理结构。第二晚集成微信登录我的操作这是与平台强相关的功能我必须提供精确的上下文。我的Prompt变得更具体“在‘阅栈’小程序的profile页面我需要集成微信一键登录功能。请参考微信官方文档为我生成以下代码1. 在profile.wxml中放置一个登录按钮按钮文字在未登录时显示‘一键登录’登录后显示用户昵称和头像。2. 在profile.js中编写login函数。流程是调用wx.getUserProfile获取用户信息然后将nickName和avatarUrl显示在页面上。同时为了后续使用请将openid或unionid通过wx.login获取code并假设我有一个后端API‘https://myapi.com/login’来交换openid存储在微信小程序的本地存储wx.setStorageSync中。请写出完整的JS逻辑并包含基本的错误处理。”AI的回应与我的调整Claude生成的代码基本正确但关于openid的部分它注释掉了并说明需要我自己的后端服务。这正是时候引入我的“模拟后端”——Airtable。我暂时将登录逻辑简化为只在前端保存昵称和头像用户唯一标识先用一个临时生成的UUID。我告诉AI“暂时不需要openid登录成功后生成一个随机UUID作为本地用户ID存储。” AI很快修改了代码。关键收获对于依赖外部服务微信登录、真实后端的功能在MVP阶段要学会做“减法”和“模拟”。先让核心流程跑通复杂集成后续迭代。AI能很好地理解并执行这种策略调整。3.2 第3-5晚构建核心功能——书架目标实现书籍的添加、展示和管理。第三晚设计数据模型与Airtable Base我的操作我不再直接要代码而是先和AI设计数据结构。我问Claude“为了‘阅栈’小程序的书籍管理功能请帮我设计一个数据模型。一本书Book需要哪些字段一个用户User需要哪些字段用户和书籍之间是什么关系多对多请用一个中间表UserBook来记录用户对书籍的状态想读、在读、已读和阅读日期。请用表格形式列出每个表的字段名、类型和说明。”AI的回应Claude给出了一个非常专业的三表结构设计。基于这个设计我登录Airtable手动创建了三个TableBooks,Users,UserBooks。然后我让ChatGPT根据这个结构生成一套完整的、针对Airtable REST API的CRUD操作示例代码包括API Key的放置位置、请求头设置等。关键收获“设计先行”在与AI协作中至关重要。清晰的数据结构是后续所有功能代码的蓝图。让AI参与设计它能保证后续生成的代码与模型高度一致。第四晚实现扫码添加与手动输入我的操作这是功能密集的一晚。我拆解成两个任务。扫码Prompt是“在bookshelf页面添加一个浮动按钮点击后调用wx.scanCodeAPI扫描书籍ISBN条形码。扫码成功后将获取到的ISBN号码调用一个公共图书API例如‘https://api.example.com/book?isbn’来获取书籍详情。请生成完整的WXML、WXSS和JS代码包含加载状态和网络请求错误提示。”手动输入Prompt是“如果扫码失败或没有条形码用户需要能手动输入书名搜索。请在上面的页面中增加一个搜索框用户输入书名后调用另一个搜索接口例如‘https://api.example.com/search?q’获取书籍列表点击列表项即可添加。”AI的回应与我的调整AI生成的代码逻辑清晰。但最大的坑出现了它提供的公共图书API是虚构的。我不得不自己去寻找真实可用的、免费的图书数据API。我最终找到了“Open Library API”和“豆瓣图书API非官方”。我需要根据真实API的响应数据结构大幅修改AI生成的代码中解析数据的部分。例如AI假设返回的字段是book.title但真实API可能是data.title或works[0].title。关键收获AI不负责外部数据源的可用性和真实性。它生成的网络请求代码是“模板”你必须用真实API的文档去“填充”和“修正”这个模板。这是AI编程中最需要人工介入的环节之一。第五晚书籍列表展示与状态管理我的操作现在数据能添加了需要展示出来。我问AI“在bookshelf页面我需要一个书籍列表。每本书显示封面、书名、作者和当前阅读状态想读/在读/已读。用户可以下拉刷新上拉加载更多。点击某本书进入详情页详情页里可以修改阅读状态和记录阅读日期。请生成bookshelf页面的列表渲染代码和bookDetail页面的表单代码。数据从Airtable中获取Airtable的API地址是https://api.airtable.com/v0/{baseId}/{tableName}。”AI的回应与我的调整AI出色地生成了使用wx.request调用Airtable API、使用wx:for渲染列表、以及实现下拉刷新onPullDownRefresh的代码。我几乎可以直接使用。但在详情页修改状态后更新列表时出现了数据不同步的问题。AI最初的方案是返回上一页并重新加载数据但体验不流畅。我利用Cursor选中相关代码块提问“如何在不刷新整个页面的情况下更新上一页的某个列表项数据” Cursor建议我使用微信小程序的getCurrentPages()方法获取页面栈并直接修改上一页的data中的数据。我采纳了这个方案。关键收获对于常规的UI和交互逻辑AI的生成质量非常高。但对于涉及页面间通信、状态管理等稍微复杂的前端模式需要你具备一定的知识来引导AI或使用Cursor这样的工具进行“精准外科手术式”的调试和优化。3.3 第6-7晚“发现”功能与UI美化目标实现简单的推荐逻辑并让界面看起来像个“产品”。第六晚基于标签的推荐逻辑我的操作推荐算法可以很复杂但MVP要简单。我设计了一个规则从用户已读的书籍中提取所有标签如“科幻”、“历史”找出出现频率最高的两个标签然后用这两个标签去搜索推荐书籍。我把这个逻辑描述给Claude“请编写一个函数getRecommendations(userId)。它首先调用Airtable API获取该用户所有状态为‘已读’的书籍。从这些书籍的‘tags’字段假设是一个用逗号分隔的字符串中统计所有标签的出现频率。选出频率最高的前两个标签。然后用这两个标签作为关键词去调用图书搜索API返回一个书籍列表作为推荐结果。请考虑标签可能为空或重复的情况。”AI的回应Claude完美地实现了这个逻辑代码结构清晰包含了必要的数组操作和统计逻辑。我将这段函数放在了一个独立的utils/recommend.js文件中。这里的一个技巧我让AI将Airtable API的调用封装成了独立的service函数使得主逻辑非常干净。关键收获将业务逻辑推荐算法与页面渲染逻辑分离是保持代码可维护性的关键。AI能很好地理解并实践这种模块化思想只要你明确要求。第七晚用AI辅助进行UI设计我的操作之前的界面非常“开发者预览”。我打开Midjourney输入提示词“A clean, minimalist mobile app interface for a book tracking application, showing a list of books with covers, in a light cozy style, –ar 9:16”。它生成了几张很有质感的图片。我选取了其中一张的配色米白背景、深蓝文字、浅灰分割线和卡片阴影效果。接着我回到Claude将Midjourney的图片描述和我的选择告诉它“请根据以下风格描述优化bookshelf页面的WXSS背景色为#faf8f5主要文字颜色为#2c3e50卡片有轻微的阴影box-shadow: 0 2px 8px rgba(0,0,0,0.08)圆角为12rpx。书籍封面图片固定宽高比标题字体加粗。” AI迅速输出了符合要求的样式代码。我还让它为按钮、加载状态等元素生成了统一的样式。关键收获AI在视觉设计上是“灵感加速器”而非“自动完成器”。你需要用文字精准地描述你想要的风格或者用图片作为参考。AI特别是ChatGPT/Claude能很好地将视觉描述转化为具体的CSS/WXSS代码极大地提升了UI开发效率。3.4 第8-9晚调试、优化与云开发迁移目标解决遗留问题提升体验并为上线做准备。第八晚集中调试与性能优化我的操作我开始在真机上全面测试。发现了几个问题1. 列表图片加载慢且可能变形。2. 首次进入书架页面如果书籍很多感觉有卡顿。3. 网络请求失败时提示不友好。我逐一用Cursor解决图片我问“微信小程序中如何实现图片的懒加载和适应不同比例的裁剪” Cursor给出了使用image标签的lazy-load属性和mode属性如aspectFill的方案。卡顿我问“微信小程序长列表渲染优化有哪些常见手段” Cursor提到了使用wx:for的wx:key、避免在wxml中执行复杂计算、以及考虑使用官方recycle-view组件对于更复杂的列表。我首先确保了wx:key的正确使用。错误处理我让Claude为所有wx.request调用包裹一个统一的错误处理函数并在UI上显示友好的Toast提示。关键收获调试阶段AI是你的“超级搜索引擎”和“代码医生”。你能用自然语言描述问题它往往能直接定位到相关API或最佳实践比传统搜索更快。第九晚从Airtable迁移到微信云开发我的操作Airtable很好但它不是微信生态内的服务存在跨域和配额限制问题。为了正式上线我需要将数据层迁移到微信小程序云开发。这是一个较大的改动。我向Claude描述了整体迁移计划“我将把数据存储从Airtable迁移到微信小程序云开发。请帮我完成以下工作1. 在app.js中初始化云环境。2. 将原有的Books,Users,UserBooks三个Airtable表转换为云开发的三个集合Collection。3. 重写所有数据操作函数将之前调用Airtable API的wx.request改为调用wx.cloud.database()的增删改查方法。请特别注意云开发数据库的权限设置我需要所有用户只能读写自己的数据请生成对应的安全规则示例。”AI的回应Claude给出了详尽的迁移指南和代码对比。例如将Airtable.get()改为db.collection(‘Books’).get()并加入了where条件来实现用户数据隔离。它还生成了基本的数据库安全规则// 云开发安全规则示例 { “read”: “auth.openid doc._openid”, “write”: “auth.openid doc._openid” }关键收获AI擅长进行“模式转换”。只要你清晰地定义了“从A模式Airtable REST到B模式云开发DB的映射规则”AI就能高效地完成代码的重构。这大大降低了更换技术栈的成本。3.5 第10晚提交审核与发布目标走通小程序上线的最后一步。我的操作这晚的工作更偏向于流程和配置。配置小程序信息填写小程序名称、简介、类目等。这些无法由AI代劳。生成隐私协议我让Claude根据小程序的功-能收集微信昵称、头像、书籍信息生成一份简单的用户隐私保护指引。准备审核材料我让Midjourney生成了几张不同尺寸的应用截图和封面图。最终代码检查我用Cursor对主要页面进行了一次“代码审查”提问“请检查以下页面的JS文件是否有明显的性能问题或潜在bug” AI指出了一些未使用的变量和可能为空的属性访问我逐一修复。提交审核在微信公众平台提交代码。第一次审核因为“类目选择不当”被拒。我根据驳回理由重新选择了“工具-效率”类目并在Claude的帮助下修改了部分文案描述第二次提交后顺利通过。4. 复盘与思考AI作为开发伙伴的“能”与“不能”10个晚上一个功能完整的小程序成功上线。这个过程让我对AI编程有了非常立体和真实的认识。4.1 AI的“超能力”它究竟擅长什么从零到一的“脚手架”生成对于创建标准化的项目结构、基础页面、通用CRUD逻辑AI的速度无与伦比。它能把你从重复的体力劳动中彻底解放出来。“翻译官”与“转换器”它能将你的自然语言需求“我要一个带下拉刷新的列表”精准地翻译成某种框架或语言的代码。也能在不同技术栈如从Airtable到云开发之间进行模式转换。永不疲倦的“代码审查员”与“搜索引擎”你可以随时向它提问任何语法、API用法、最佳实践的问题它能立刻给出解释和示例上下文关联能力远超传统搜索。灵感的激发者在UI设计、命名、甚至简单的算法逻辑上它能提供多种选择打破你的思维定式。4.2 AI的“边界”与“陷阱”你必须亲自把关的地方“幻觉”与真实性这是最大的风险。AI会自信地编造不存在的API、库、或方法。你必须对它所使用的技术生态有基本的了解能够验证其输出的真实性。永远不要盲目相信AI提供的任何外部依赖信息。业务逻辑的深度理解AI能实现你描述的逻辑但它无法理解你业务背后的“为什么”。如果最初的逻辑设计有漏洞AI生成的代码只会完美地执行这个有漏洞的逻辑。产品设计与系统架构的核心决策必须由人类完成。复杂状态与交互对于涉及多个组件、页面间复杂通信、非标准交互模式的情况AI容易生成出臃肿或低效的代码。它缺乏对整体应用状态的宏观设计能力。这时需要你进行人工重构和优化。项目管理与集成AI不会帮你管项目。它不知道哪些文件被修改了不知道如何解决版本冲突不知道如何配置CI/CD流水线。这些工程化能力依然是开发者的核心价值。4.3 给想尝试AI开发者的建议从“副驾驶”开始而非“自动驾驶”不要期望AI替你完成所有工作。把它当作一个能力超强但有时会胡言乱语的新手搭档。你负责把握方向、制定规则、审核输出。Prompt工程是核心技能清晰、具体、结构化的Prompt是成功的关键。学会将大任务拆解成原子任务并给AI提供足够的上下文技术栈、已有代码、约束条件。保持一个可运行的状态频繁地运行和测试AI生成的代码。不要等所有代码都生成完再测试那样调试将是灾难。采用小步快跑的方式每完成一个微功能就验证一次。不要放弃学习AI降低了编码的门槛但抬高了设计和架构的门槛。你需要更深刻地理解问题本质、系统原理和用户体验才能给AI发出正确的指令。你的技术判断力决定了AI输出的天花板。这10个晚上的实验与其说是我用AI做了一个小程序不如说是我与AI进行了一场密集的、关于如何将想法转化为产品的对话。AI不是取代者它是一个前所未有的“杠杆”和“放大器”。它放大了我作为“定义者”和“整合者”的价值而将那些重复的、模式化的“实现”工作极大地简化了。未来善于定义问题、拆解任务、并与AI协作的开发者将会获得巨大的效率红利。我的“阅栈”小程序只是一个开始而如何与这位强大的伙伴共舞是我们所有人都需要持续学习的课题。
)
