不会代码,我用AI开发了一个微信小程序!(附教程)
- 2026-09-25 11:26:48
作为一个HR，我不会写代码。
实际用了一周多，上线了一个小程序。做内容2-3天，开发1天。审核3-4天。 但我和Codex一起，把“吕行测评”从一个想法，做成了正式上线的微信小程序。
我把整个过程整理成一套SOP：怎么把需求说清楚，怎么准备测评内容，怎么推进产品开发，怎么测试，怎么备案和发布。
如果你也不会开发，照着这个流程，至少知道每一步该做什么、该让Codex或者WorkBuddy做什么，以及做到什么程度才能进入下一步。
先看完整流程
整个项目分成五个阶段：
为了简化，以下没做： 1.小程序没有做管理后台 2.还没有开通支付功能 3.测评内容不采用AI生成，直接做成静态内容
4.没做版本管理
第一阶段：先把测评内容做出来
第一步：把模糊想法交给Codex，不急着开发
我最早只有一句话：想做一个HRBP能力等级测评，类似MBTI的性格测试。 先把想法和AI沟通，变成正式的思路。 所以，我加了一个限制：先不要设计，我先看思路。
第一次提需求，至少说清三件事：
- 想做什么： 例如HR胜任力测评、离职补偿测算或面试提问工具。
- 手里有什么： 文章、案例、模型、题库、知识库。
- 这轮不做什么： 先不开发，只分析产品是否成立。
可以直接这样告诉Codex：
我想做一个面向【目标用户】的【工具类型】。现有资料包括【资料名称或文件路径】。先不要写代码，请先判断这个产品要解决什么问题、需要哪些内容、还缺哪些关键决策。
这轮的产出不是答案。答案需要通过后续对话，进行完善。
第二步：把测评需要确定的内容逐项补齐
最初，它根据我的文章搭了一个HRBP成长模型。我认为还不够，就补充了戴维·尤里奇的HR胜任力模型，要求它重新融合。后面又根据AI时代的变化，对能力域继续调整。
最终，一套测评需要确定十项内容：
测评目的； 测评主题和边界； 测评对象； 能力模型； 能力维度和定义； 等级和行为标准； 题目与作答方式； 评分与分级规则； 结果和成长建议； 试测与校准。
内容教多时，不要让Codex一次问完。
我的做法是：一次只问一个关键问题。我负责选择、否定和补充，Codex负责记录已经确认的内容，再继续问下一题。
这里有一条基本原则：专业判断不能外包给AI。Codex可以帮我查资料、拆结构、找冲突，但哪种能力重要、哪个行为算成熟、哪道题符合真实工作，最终要由我判断。
第三步：把后台规则和用户文案分开
测评内容逐渐完善后，我把它拆成两份文件。
一份是用户看到的：开场说明、答题提示、题目、选项和完成提示。
另一份是系统后台规则：能力域、能力因子、题目映射、选项分值、汇总方式、等级和报告解释。
为什么要分开？
因为用户需要简单，系统需要完整。如果所有内容混在一份文档里，后面改一道题，很容易只改页面，忘了同步评分规则。
以下整个系统文件，都是由AI生成。
第四步：不要凭感觉定稿，要模拟答题
题目写完，不代表题目有效。
我先让Codex从两个角度审题：
用户能不能看懂； 是否符合HR真实工作。
适合场景化的题目，再改成“最近一年，你是否实际做过什么”，避免只测用户懂不懂正确答案。
之后，我让Codex分别模拟四类角色作答：零经验、初级、中级和资深HR。再看分数、等级和雷达图能不能形成合理差异。
这一步发现问题，就回到题目继续改。
首版最终形成39道行为自评题。但是需要说明：它是一套成长参考工具，不是经过大样本信效度验证的职业资格考试或心理量表。它，不是专业测评工具。
第一阶段验收标准
进入产品开发前，至少要有：
用户端完整题目和选项； 后台题目与能力维度映射； 每个选项的分值； 能力域、总分和等级算法； 结果解释规则； 模拟答题结果； 测评用途和边界说明。
这些没定，不进入开发。
第二阶段：把测评内容变成产品
第五步：先写需求文档，明确首版做什么
测评内容完成后，我问Codex：是不是应该按正式产品流程推进？
答案是需要，但不需要把简单项目做成一堆复杂文档。
产品需求文档重点写清：
谁使用； 用户从哪里进入； 要经过哪些页面； 首版必须有哪些功能； 哪些功能暂时不做； 数据保存在哪里； 失败了怎么办； 什么状态算完成。
“吕行测评”首版保留的核心功能包括：
首页和测评说明； 39题逐题作答； 中途退出和进度恢复； 分数、等级和五维雷达图； 测评报告； 最近历史记录； 删除历史结果； 分享测评入口。
对小白来说，需求文档最大的价值，不是显得专业，而是防止Codex边做边加功能。
第六步：先做低保真原型，只检查流程
需求确认后，我要求：低保真，简化处理。
低保真原型不解决“好不好看”。原型设计帮助我还原真实场景，我能站在用户视角看到产品。
它，解决四个问题：
用户从哪里开始； 每一步点什么； 成功后去哪里； 失败后怎么处理。
我重点检查：首页能否开始测评，题目能否切换，提交后能否看到结果，失败后能否重试，历史记录能否查看和删除。
流程确认后，再做正式视觉。
如果顺序反过来，页面可能做得很好看，但流程一改，视觉稿和代码都要重来。
第七步：确认技术方案，但不需要自己写代码
不会开发，不代表完全不用理解技术结构。
如果熟悉技术架构，一开始开发前，就可以让AI按你要求的技术架构执行，会少走非常多弯路。奈何，我是一点不懂，只能让AI自行选择最优解。
你至少要知道，小程序通常包含：
用户看到的前端页面； 处理规则的云函数或后端； 保存结果的数据库； 微信小程序账号和开发者工具； 如果调用大模型，还要有后端AI接口。
API Key不能写在小程序前端。评分也不能交给大模型临场判断。固定题目的评分、等级和雷达图，应该由代码按规则计算；AI最多负责把结果解释成人话。
实际操作中，Codex可以写代码、配置项目和告诉你点击哪里。你仍要完成几项人工操作：
注册或准备微信小程序账号； 安装微信开发者工具； 开通云开发环境； 提供环境ID； 扫码、授权和管理员确认。
第二阶段验收标准
产品需求已经确认； 低保真流程可以完整走通； 正式页面和组件规则已经确定； 数据结构、云环境和异常处理已经说明； 首版不做的功能已经明确。
第三阶段：让Codex开发，但按模块验收
第八步：不要一次做完，先跑通最小闭环
开发顺序建议从核心到外围：
题目能正常显示； 用户可以完成作答； 分数和等级计算正确； 雷达图与报告正常； 结果能够保存； 历史记录能够读取和删除； 最后再加分享、统计或AI能力。
每完成一块，就测试一块。
我不懂代码，所以不需要看懂每一行代码，但要看懂功能是否符合需求。如果出现按钮重叠、文字被遮挡、历史记录不一致，我只要把页面、操作步骤和实际现象告诉Codex，它再定位和修改。
提问题时，尽量使用这个格式：
页面：答题页。操作：选择答案后点击下一题。实际结果：上一题和下一题按钮重叠。预期结果：两个按钮分开，手机端可以正常点击。
不要只说“有问题”“不太好看”。Codex需要可以复现的事实。
第四阶段：测试不是打开看看
第九步：自动测试和真机测试都要做
代码测试可以交给Codex，但真机体验必须有人操作。
至少检查以下场景：
正常流程
从首页进入； 完成全部题目； 分数、等级、雷达图和报告正常； 历史记录与当前结果一致； 可以删除记录； 分享入口可以打开。
中断与恢复
答到一半退出； 再进入时能否恢复进度； 重复提交会不会产生异常记录。
设备与显示
iPhone和安卓真机； 长题目和多个选项； 系统大字体； 不同屏幕尺寸； 上一题、下一题和提交按钮能否点击。
网络和服务异常
断网提交； 网络恢复后重新保存； 历史记录读取失败； 云服务异常时是否有明确提示； 失败后能否重试。
能打开首页，只能证明入口没坏，不能证明产品可用。
第十步：遇到卡点，先调整方案，不要死磕技术
最初我准备接入DeepSeek生成个性化报告。开发到后面，我发现AI报告会带来的隐私和审核的不确定性。
我觉得太麻烦，所以干脆首版删了。做了取舍。
于是，我让Codex先判断：能不能取消AI，改成标准报告？
最终方案是：
分数、等级和雷达图由固定算法生成； 能力域分数决定整体解读； 能力因子和每道题的回答细化行为判断； “没有相关经历”和“很少这样做”分别处理； 报告文案提前审核后写入系统。
第四阶段验收标准
自动测试通过； 主要手机完成全流程测试； 大字体和长内容不影响操作； 断网、失败、恢复和重试有明确处理； 体验版交给非开发者测试过； 所有上线功能与隐私说明一致。
第五阶段：备案、审核和发布
第十一步：先核对认证、备案和隐私
功能完成，不等于可以发布。
微信小程序还涉及账号认证、服务类目、备案、隐私保护指引和代码审核。具体页面可能调整，以微信公众平台当时的要求为准。
其中最容易填错的是隐私说明。
我当时取消了外部AI调用，以为可以选择“没有处理用户信息”。但小程序仍然会：
使用微信用户标识关联历史记录； 处理测评回答； 计算并保存测评结果； 展示历史报告。
所以，仍然要如实填写处理了哪些信息、用来做什么、保存多久、用户如何联系开发者。
判断方法很简单：
不要只看有没有收集昵称和手机号。只要系统读取、关联、计算或保存了能够对应用户的数据，就要继续核对隐私要求。
隐私说明必须和真实功能一致。不能为了容易过审而少填，也不能把没有使用的第三方服务写进去。
第十二步：分清体验版、代码审核和正式发布
常见流程是：
开发工具本地调试； 上传开发版本； 设置体验版； 真机和体验账号验收； 上传正式候选版本； 提交代码审核； 审核通过后提交发布； 正式版验收。
代码审核通过，只代表可以发布，不代表已经上线。
发布后，再使用非体验账号检查：
能否搜索或扫码进入； 能否完成一次测评； 结果和历史记录是否正常； 分享给朋友后，对方能否打开； 正式小程序码是否可用。
到这里，才算真正上线。
不会代码的人，究竟负责什么
在整个产品的开发、上线过程中，我没写过一行代码，也不是把需求扔给Codex以后等结果。
我负责：
说清楚要解决的问题； 提供真实专业资料； 审核模型、题目和报告； 决定首版做什么、不做什么； 检查原型和页面； 进行真机测试； 完成账号、扫码、备案和发布确认； 对最终产品负责。
Codex负责：
整理资料和提出问题； 生成需求文档、原型和技术方案； 编写和修改代码； 配置数据结构与云函数； 编写自动测试； 根据测试结果定位问题； 准备隐私说明和上线清单； 指导审核与发布流程。
分工说白了就是：
我负责判断什么是对的，Codex负责把判断变成可以运行的产品。
最后，把流程压缩成一句话
想法 → 测评模型 → 题库与评分 → 模拟试测 → 产品需求 → 低保真原型 → 视觉与技术方案 → 分模块开发 → 自动测试 → 真机测试 → 隐私与备案 → 代码审核 → 发布 → 正式版验收。
不会代码，根本不是问题。
所有不会的，不懂的环节，看不懂的开发工具，你可以全部丢给AI，截图给AI，它会一步步教你。
真正的问题是：需求没想清楚，就急着让AI写代码；结果没验证，就急着上线。
把每一步的判断做完，再让Codex或者WorkBuddy继续。小白也能把一个想法，推进成真正可以使用的产品。
