AI能写代码，但业务判断仍要自己掌舵
主要观点
一个非科班创作者用Codex完成两个微信小程序后，复盘了从需求、MVP、技术验证到审核上线的完整路径。真正值得借鉴的不是“AI替你写代码”，而是先盘点已有流量和内容，再用SPEC压缩问题边界，用真实设备验证关键链路，持续保留版本与证据。排班项目暴露出需求和多人同步的复杂性，CPS项目则说明既有业务资产能显著提高产品落地确定性。
关键要点
- SPEC的价值在于建立停止条件和可回退的开发地图：每轮说明改了什么、影响哪里，并用需求文档、Git、测试结果和真机记录保持一致，避免AI无限“优化”。
- 两个项目形成鲜明对照：排班工具虽然痛点真实，但用户理解和前期铺垫不足；优惠券项目依托持续更新的活动口令与既有CPS流量，用户习惯、内容供给和商业闭环都更确定。
- 多人协作功能不能用本地缓存伪装完成。创建小组、邀请码、跨设备加入和数据同步，都必须明确云端真相源，并在真实账号、设备和数据上验证。
- 产品验收应围绕第一条真实闭环，而非页面完整度：排班要能跨设备共享并算出共同休息日，CPS要能复制口令并被官方App识别。
- 自动化的边界很清楚：重复采集、复制和整理可以交给工具，但相似活动识别、异常过滤、失败日志判断等关键决策仍需人工把关。
- 模型升级并不等于产品变好。作者将已可用代码整体重新“优化”后出现界面大改和更多Bug，最终回退版本，说明稳定、可验证的增量修改比追逐模型新版本更重要。
建议带着这些问题阅读
- 你的现有流量、内容、交付流程或数据中，哪一项最适合直接沉淀为MVP？
- 如果删掉所有非核心功能，用户完成第一条真实闭环还需要哪些步骤？
- 哪些环节可以自动化，哪些判断必须保留人工证据和验收？