婚礼人 Codex 入门：先跑通一个真实项目，不要从命令大全开始

课程现场的作业不是抄程序，而是准备自己的个人介绍、项目思路和真实业务素材。原因很简单：没有真实需求，学员只能跟着老师生成一份演示；有真实需求，才会遇到资料缺失、结果不符合使用场景、文件需要继续修改这些真正的问题。

婚礼人可以从小任务开始：整理一份谈单问卷，建立供应商档案，做一个场地勘察检查页，或者把一次复盘变成可检索笔记。任务要有使用者、输入材料和完成标准。我的判断是，Codex 入门不是“今天学了什么功能”，而是“今天交付了什么可以继续用的东西”。

若第一天就喊“帮我做一个全国婚庆管理系统”，范围太大，需求也没有被验证，AI 只能替你猜。先完成一个能在本周真实使用的小项目，判断力会比命令数量长得更快。

AI 开发课里，刘坚伟反复要求学员把项目分开：与当前项目无关的内容不要放进来；两个项目同时讨论，规则和数据会互相干扰。这个课堂场景很像婚礼项目管理。A 新人的预算、场地和禁忌不能混进 B 新人的方案，AI 项目也一样。

新建项目时写清名称、目标、资料位置和禁止触碰的范围。做“婚礼报价复盘”，就不要顺手让同一个项目改个人主页；做“供应商档案”，就不要混入短视频选题。临时想到另一件事，先记录到待办，等当前任务形成可验收结果再切换。

项目隔离不是技术洁癖。上下文越混，Codex 越可能调用错误资料；错误资料进入方案或客户文件，后果就不只是界面不好看，而是业务判断被污染。

课程把两个 Markdown 文件讲成项目底座：AGENTS.md 规定智能体在这个项目里怎样工作、哪些事情不能做；MEMORY.md 保存已经确认的事实、决策和踩过的坑。名字不重要，作用要理解：一个管边界，一个管连续性。

对婚庆公司来说，规则文件可以写“客户原图不得外传、报价未经负责人确认不得发送、课程数据不得凭记忆补写”；记忆文件则记录已经确定的场地限制、供应商分工、客户修改意见和历史问题。下一次打开项目，Codex 先读这两份文件，才不会从零猜起。

刘坚伟在个人知识库录音里还讲到，简介并不等于这个人完整的判断方式。日常录音、课堂原话和复盘持续进入知识库，AI 才逐渐理解作者怎样取舍。我的第二个判断是，想让 AI 像长期员工，先给它稳定的工作制度和可回查的业务记忆。

课程给出的实际顺序是，先讨论项目目标和需求，让 AI 形成一份可执行的 Markdown 计划，再交给 Codex 开发。这里的重点不是换一个聊天窗口，而是把模糊想法变成可以验收的任务。

一份婚礼业务计划至少说明：谁使用；输入资料是什么；最终要生成什么文件或页面；哪些字段必须保留；怎样算完成；哪些外部动作需要负责人批准。比如“做供应商表”太模糊，改成“读取现有联系人，按服务类型、城市、价格有效期、合作记录和备用状态整理，不删除原件，输出可筛选表格”，执行才不会靠猜。

计划写清后再动手，修改成本更低。中途发现目标变了，先改计划和记忆，再改实践，不让旧规则和新做法同时存在。

课堂上出现过很典型的情况：Codex 认为网站已经改好，实际只是本地完成，还没有部署；刘坚伟让学员继续追问“为什么我看不到”，再让 AI 补上遗漏步骤。他也提醒，AI 有时不是故意欺骗，而是它以为自己已经完成。

所以每个任务都要把结果打开看。文件是否在约定位置，页面是否真的可访问，字段有没有漏，原始资料是否保留，手机端能不能用。发现问题时不要只说“不对”，要指出哪个结果与标准不一致，让 Codex 诊断原因、修复并重新验证。

我的第三个判断是，人负责目标和验收，AI 负责执行和修正。把验收也外包给同一句“你检查一下”，等于让做题的人自己决定答案是否及格。

AI 开发课把阶段收尾固定为两层：代码或项目文件提交到 GitHub，过程判断和可复用知识同步到个人知识库。前者保护版本，后者保护为什么这样做。账号、设备或对话发生变化时，项目仍有机会被恢复。

同时，课程对商用边界讲得很清楚：给自己公司内部使用，与对公众收费，是两个阶段。内部工具先验证稳定、数据和权限，再考虑公开产品需要承担的合规、服务与退款责任。婚礼人第一次用 Codex，先解决自己反复做的工作，不要一开始就把半成品卖给别人。

双重归档也不等于把所有聊天原样堆起来。代码仓库保存可恢复的版本，知识库保存经过确认的需求、决策、错误原因和复用方法；临时猜测与已经验证的事实要分开。下一次继续项目时，先读规则与记忆，再查看最近版本，才能知道当前结果从哪里来、哪些边界仍然有效。

用“真实项目六步表”收尾：选真实任务、项目隔离、规则与记忆、计划先行、打开验收、双重归档。项目能被使用、复查和继续迭代，才算真正入门。