文章总结： 文章分享了使用opencode工具与AI协作开发微信小程序会议系统的完整过程，核心经验包括：先让AI参与思路梳理而非直接写代码，建立计划书和进度文档以保持上下文，采用小步迭代方式开发，代码与文档同步更新，遇到问题先排查环境而非盲目重写，UI优化时维护版本记录以支持回退。这种协作方式使项目更像持续迭代的真实工程而非零散代码片段，展示了AI在整理思路、维护文档、排查问题等方面的价值。 综合评分： 82 文章分类： 实战经验,安全开发,应用安全,AI安全

使用 opencode 开发微信小程序会议系统

原创

湘岚实验室 湘岚实验室

湘岚实验室

2026年3月26日 20:52 湖南

使用opencode

开发微信小程序

会议系统

PART 01

使用 opencode 开发微信小程序会议系统

最开始，我没有让 AI 直接写代码

我一开始给 opencode 的第一类提示词，并不是“帮我把系统写出来”，而是先让它给我几个思路。我当时输入的大意是：我要开发一个基于微信小程序的智能会议预约系统，你先不要写代码，先把你的想法和方案给我看，我再来选。

现在回头看，这一步其实特别重要。因为如果一开始就让 AI 直接落代码，很容易出现一个问题：写着写着才发现产品方向没想清楚，后面就只能不断返工。相反，先让 AI 参与项目方向的梳理，会更像是在正式开发前做一次轻量的产品讨论。

当时 AI 给我的帮助，主要不在技术细节，而在于把整个项目的大方向先铺开。它会从用户端、管理员端、首版功能范围、后续扩展空间这些角度帮我把事情想得更完整一些。也是在这一轮之后，我基本确定了这个项目应该是一套标准版的会议室预约系统：功能不用一开始就做得太重，但主要链路要清楚，后面要有继续扩展的空间。

然后，我让 AI 先把文档搭起来

方向确定以后，我并没有马上切到“开始写页面、开始写接口”这种节奏，而是先让 AI 帮我把项目文档建起来。这里最核心的两份文档，就是 project-plan.md 和 development-progress.md。

我这样做的原因很简单：真实项目不是一次就做完的，中间一定会暂停、恢复、调整。如果没有一份计划书和一份持续更新的进度文档，后面每次重新开始都要把上下文再说一遍，既浪费时间，也很容易出现断层。

所以这一阶段我更像是在把“长期协作的地基”先打好。计划书负责把项目目标、角色、功能范围、页面结构这些内容讲清楚；进度文档则专门记录开发做到哪里了、这轮改了什么、下轮准备接着做什么。后面我和 AI 的很多轮协作，实际上都建立在这两份文档之上。

再往后，才是正式搭项目骨架

PART 02

等文档先立住以后，我才让 AI 进入真正的开发阶段。不过这里我还是没有让它“一步到位把系统写完”，而是先从项目骨架开始。

也就是说，先把目录结构、前后端位置、数据文件、文档目录这些东西安排好，让整个仓库看起来像一个可以持续迭代的项目，而不是一次性拼出来的几个代码片段。最终形成的结构也就是现在的样子：backend/ 放接口服务，miniapp/ 放微信小程序前端，data/ 放 JSON 数据，docs/ 放接口、测试和各种说明文档。

这种做法对我来说有一个很明显的好处，就是 AI 不是在“生成一段代码”，而是在“接手一个工程”。从那之后，后面每一次继续开发，其实都是在这个骨架上往前走，而不是每次都重新开始。

第一阶段，我优先让 AI 打通用户端主流程

真正开始写功能时，我没有先做管理后台，也没有先做那些看起来比较“高级”的部分，而是先让 AI 把用户端主流程跑通。因为会议室预约系统最重要的，始终是用户能不能完成预约这件事。

所以我最先推进的是首页、会议室列表页、会议室详情页、预约填写页、我的预约页和通知页，以及它们背后对应的基础接口。说白了，我希望先把“能看会议室、能发起预约、能看到自己的预约、能取消预约”这条链路做完整。

这一阶段也让我感觉到，AI 很适合拿来做这种“先把主流程搭起来”的工作。它不一定一开始就能把所有边界都处理得特别细，但它很适合快速把主干搭起来，让项目尽快从“想法”变成“已经有个能跑的东西”。

AI 在这个项目里，不只是负责写代码

这个项目做下来，我最大的体会之一就是，AI 真正有价值的地方，不只是生成页面和接口，还有一个很重要的作用，是帮我排查问题。

比如有一轮开发时，我遇到了“预约日期不在允许范围内”的报错。当时如果只盯着表面，很容易以为是预约逻辑有 bug，然后让 AI 重新改一遍日期校验。但我没有这么做，而是先让它去检查当前代码和联调环境。

结果最后定位下来，问题并不完全来自代码本身，而是本地旧进程干扰了联调。也就是说，我当时看到的返回结果，未必来自眼前最新这份代码，而有可能是打到了旧服务。

这件事对后面影响很大。因为它让我意识到，如果环境都没有收敛好，再怎么改业务逻辑都可能是在白费力气。从那之后，这个项目的联调口径就统一了：固定走 3001 端口，小程序接口统一使用 http://127.0.0.1:3001/api。这一轮其实很能说明 AI 的另一个作用，就是它能帮我做工程层面的排查和收口，而不只是闷头继续写新功能。

后来我慢慢确定了一种更稳的协作方式：小步迭代

项目往后推进时，由于网络问题会出现超时问题，所以我明确地要求 AI 不要一次改太多，而是按小步迭代来。也就是每次只做一个步骤或者一个方向，做完先停下来汇报，等我确认后再继续下一步。

这种方式刚开始看起来会慢一点，但实际效果特别好。因为项目一旦进入中后期，页面、接口、数据、文档都是联动的，如果一次改太多，最后很容易说不清到底是哪一步出了问题。相反，小步推进的好处是每一轮都很清楚，改动范围小，回退方便，断点也容易保存。

在这种节奏下，AI 帮我修了很多不算“新功能”、但很影响真实使用体验的问题。比如会议室详情页在某些状态下仍显示预约入口，预约页切换日期后没有及时刷新详情，预约前缺少基础表单校验，取消预约容易误触，我的预约展示不够清楚，通知页的信息不够直观。这些问题单看都不大，但处理完以后，系统的整体顺滑度会明显提升。

用户端稳定以后，我才继续补管理员端

等用户端基础闭环相对稳定以后，我才开始让 AI 往管理员端推进。这里我也没有一上来就让它做一个很重的后台，而是先做最基础的管理入口和几个关键页面，比如管理员首页、会议室管理页、预约管理页、规则管理页。

有了这些基础页以后，后面的推进就比较自然了。我让 AI 继续补会议室的新增、编辑、删除，补管理员取消预约，补规则修改，补筛选、查询和处理中反馈。这种开发节奏其实很像真实项目：不是一下子宣布“管理端完成了”，而是先有骨架，再一轮轮把操作能力和体验补上去。

需求变化的时候，我没有让 AI 推倒重来

项目中途有一个比较关键的转折，就是我拿到了 会议系统需求分析.txt。这份文档等于重新明确了业务基准。如果处理不好，就很容易出现一种混乱局面：旧文档是一套，现有代码是一套，新需求又是一套，最后谁都说不清到底该按哪个走。

所以那一轮我没有直接让 AI 继续写，而是先让它做代码和文档断点核对。先读需求文档，再看当前代码，再核对现有文档，找出差距在哪里。这个步骤非常关键，因为只有先把现状看清楚，后面的继续开发才不会乱。

AI 在这一轮里帮我梳理得很清楚：会议室要固定成 4 个，状态要细分为空闲、使用中、已预约，要支持按参会人数推荐最合适会议室，0号会议室 周五下午必须锁定，还要补周视图、月视图、特殊时段管理、设备故障标记和使用率统计。可以说，这一轮 AI 更像是在帮我做需求对齐和技术梳理，而不是单纯写代码。(由于vscode中无法阅读.docx文件所以我将内容转换为.txt文件后再加入开发的文件夹)

PART 03

真正落地时，我要求它严格沿着现有代码继续收敛

确定差距以后，我没有让 AI 重新做一个新系统，而是明确告诉它，必须严格延续当前代码状态继续开发，不要从头推翻。

现实项目里，大多数情况下也都是这样：你手里已经有一个跑起来的系统了，后面更多是在上面修正、补齐和收敛，而不是一有新需求就全部重做。这个项目后面几轮也是按这个思路推进的。

在那之后，AI 就开始在现有基础上逐步把系统往目标需求上收。会议室配置对齐成固定 4 个，实时状态进一步细分，背靠背预约支持补齐，0号会议室 周五下午锁定规则落地，周视图和月视图补上，管理端的特殊时段、故障标记和使用率统计也逐步补全。对我来说，这一段很能说明 AI 的一个优点：它并不只是适合“从零搭项目”，在已有代码上做增量开发，其实同样有用。

登录体系的升级，是后面比较重要的一轮

功能逐渐稳定之后，我开始继续往真实使用场景靠近，其中一个重点就是登录系统升级。

项目早期的身份切换方式偏演示型，方便开发验证，但不够接近真实使用。所以我后面让 AI 一步步把它往正式形态收。先是改成独立登录页，再补 /api/auth/config 和 /api/auth/login，然后让小程序前端统一走 wx.login。

为了兼顾开发联调和真实形态，后端又保留了一个很实用的机制：如果本地没有配置真实微信凭据，就自动回退成 openid 模拟模式，这样开发者工具里仍然能继续跑通登录流程。再往后，又补了 ADMIN_OPEN_IDS、ADMIN_PHONES 和 applyAutoAdminRole 这些管理员自动识别相关的逻辑。

除了代码本身，AI 还顺手帮我把配套内容一起做了出来，比如最小用户管理页、个人资料页，以及微信登录配置和真机落地说明文档。这样整个登录体系就不是“只能跑起来”，而是从页面、接口、角色、配置到文档说明，都慢慢变完整了。

做 UI 优化的时候，我更在意“可回退”

项目后期开始做界面收敛时，我和 AI 的协作方式又有一点变化。我不太希望它一上来就把页面改得面目全非，而是要求它每次只改一个方向，而且必须保留回退能力。

这个要求后来非常有用。首页优化时，AI 不只是改了代码，还专门维护了一份 docs/homepage-ui-versions.md，把不同版本的首页记录下来。这样如果我对某个版本不满意，就可以直接让它回到第一版、第二版或者第三版，而不是只能凭印象去找之前的代码状态。

后来继续优化登录页时，我也沿用了同样的思路，又增加了 docs/login-ui-versions.md。这件事让我挺有感触，因为它说明了一点：AI 做 UI 并不一定适合一次出最终稿，更实用的方式其实是版本化迭代、边做边记、随时能回退。

图为第一版ui和第三版ui的对比。(但是我个人认为最后做出的第三版ui相较于第一版过于杂乱故最终没有采用)

这个项目里，我常用的一些提示词

如果只说“我用了 AI 开发项目”，其实还是太空了。真正有用的，还是我怎么和它说话。

项目最开始，我会用偏方向型的提示词。比如我会先说，我要开发一个基于微信小程序的智能会议预约系统，你先不要写代码，先把思路和方案给我看。这种提示词的重点不是让 AI 立刻实现，而是先参与思路整理。

等方向确定以后，我会把提示词切到文档型。比如让它先生成计划书和开发进度文档，要求后续方便中断后继续开发。这样做的作用，是先把整个项目的协作基础搭起来。

等项目做到中途，需要恢复上下文时，我最常用的提示词就会带上明确的断点信息。我通常会让它先读 README.md、development-progress.md、project-plan.md 和接口设计文档，然后明确告诉它，严格延续当前开发状态，不要重复从头规划。这样的提示词很有用，因为真实开发不可能总是连续进行，很多时候都是隔一段时间再接着做。

如果我想控制它的节奏，就会直接写得更明确一点，比如每完成一个步骤或一个方向后先暂停，先汇报，再继续下一步。这类提示词看起来很普通，但对控制改动范围特别有效。

还有一类提示词看起来更像工程约束，但实际上非常关键。比如我会明确写清楚当前统一使用 3001 端口联调，小程序接口地址固定为 http://127.0.0.1:3001/api。如果文档和代码不一致，就以当前代码实际状态为准，并同步更新文档断点。像这种约束，能明显减少后面越做越乱的情况。

为了避免误处理本地联调数据，我也会提前说明 data/db.json 当前有本地调试改动，不要在这轮处理中把它当成功能代码重点。等到需求变化那一轮，我又会强调必须按 会议系统需求分析.txt 和当前代码状态继续开发，不要重新规划。到了页面优化阶段，我还会把“页面必须可回退、每做完一步先暂停”这类要求提前写进提示词里。

说到底，我后来越来越觉得，提示词好不好，不在于写得多么花，而在于是不是把上下文、目标和约束交代清楚了。

如果要总结我在这个项目里的 AI 使用方法

这个项目做下来，我自己总结出的协作方式其实很朴素。

第一步，不要一上来就让 AI 写代码，先让它帮我把方向和结构想清楚。第二步，先把文档立起来，这样后面每轮开发都有上下文可接。第三步，真正开发时坚持小步推进，不要一次改太多。第四步，代码和文档同步更新，别让文档很快失效。第五步，遇到问题先排查，不要本能地让 AI 直接重写。

我觉得正是因为一直按这套方式在推进，这个项目才会越来越像一个真实在持续开发的工程，而不是一堆零散的 AI 生成结果拼在一起。

当前项目状态

到现在为止，这个微信小程序会议系统已经经历了从规划、搭建、联调、修复、需求对齐、登录升级到 UI 收敛的一整轮迭代。当前主要还是在 3.1 分支上继续推进，联调端口固定使用 3001，小程序接口地址保持为 http://127.0.0.1:3001/api。首页已经完成 3.1 版本优化，登录页也开始进入版本化优化阶段。本地的 data/db.json 还保留着联调用的数据改动，所以目前并不把它作为本轮提交重点。

结语

如果只把 AI 当成一个“帮我自动生成代码”的工具，那其实有点低估它了。至少在这个项目里，我真正感受到的价值，并不只是它帮我写了多少页面和接口，而是它帮我一起做了很多开发中同样重要、但往往很耗精力的事情，比如整理思路、维护文档、恢复上下文、检查断点、排查问题、控制节奏、记录版本。

所以这个项目对我来说，并不只是“我用 AI 写了一个微信小程序”，而更像是我和 AI 一起完成了一次比较完整的软件开发过程

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：湘岚实验室 湘岚实验室 湘岚实验室《使用 opencode 开发微信小程序会议系统》