夜雨聆风这不是一篇"AI 帮我几小时做完一个产品"的故事。更真实的过程是：我先弄清楚自己到底要什么，再和不同 AI 一起，把一个想法一步步推到可用。
我做三星堆看展小程序，来自我自己需要。
在准备去看「双星耀世：三星堆·金沙古蜀文明展」时，我发现展厅里的信息密度很高，文物也很精彩，回想以前我站在展柜前，经常会困扰于这么几个问题：
这是什么？为什么重要？我应该先看哪里？如果馆内网络不好，视频和资料还能不能用？而如果再针对本次看展内容，我的疑问还有更多：三星堆和金沙到底是什么关系？
所以我想做的不是替代官方讲解，也不是做一个百科库，而是一个真正能在现场使用的小工具。它要轻，要直接，要帮人看懂眼前的东西。
这也是这次和 AI 共创过程中，我感受最深的一点：AI 编程真正重要的，不是"让 AI 写代码"，而是你自己要知道你要什么，并且能在过程中不断判断：现在得到的东西，离真实场景还有多远。
先看效果
【小程序使用演示 GIF】
路径：首页导引 → 展品索引 → 展品详情 → 延伸阅读 → 问这件展品
做"现场可用"的小程序
如果一开始对 AI 说"帮我做一个三星堆小程序"，它很容易给出一个看起来完整、但其实很空的方案：主页、展品列表、详情页、收藏、搜索、分享。
这样的小程序功能齐全，但是问题也很明显：它不一定能解决我在展厅里的真实问题。所以我的第一步是先把边界划清。而这个工具的第一版，只解决现场观展的几个核心动作：
先知道这场展的主线是什么。 按实际看展顺序浏览重点展品。 每个展品只回答"看哪里、怎么理解、和前后有什么关系"。 网络不好时，视频和文字仍然尽量可用。 对神话、古蜀传说、《山海经》这类延伸内容保持吸引力，但不要把联想写成定论。
这一步看起来不像"编程"，但它其实决定了后面所有代码的方向。
AI 很擅长执行一个清楚的任务，但它并不能天然知道一个观众站在国博展厅里会怎么拿手机、会停多久、会不会有网络、会不会愿意读长文。这个判断必须由人来做。
明确核心价值：内容不是堆资料，而是帮助人"看见"
三星堆和金沙的资料很多。金面具、青铜大立人、纵目面具、太阳神鸟、青铜神树，每一件都可以展开很长。但展厅里的用户不会像读论文一样使用小程序。他可能只是在一件展品前停留一两分钟。他需要的不是"所有知识"，而是一个马上能用的观察入口。
于是我把内容结构定义成了更适合现场的方式：
比如讲金面具，不是先讲一大段古蜀文明背景，而是先提醒用户看眼眶、鼻梁和口部处理，再解释为什么"把脸做成金色"可能和祭祀、权力、神圣身份有关。
讲青铜大立人，也不是一上来堆年代和尺寸，而是先让用户看双手之间的空位：它原来可能握着什么？这个缺失为什么反而重要？
讲纵目面具，可以提《华阳国志》里"蚕丛其目纵"的联想，但必须同时说明：这是后世文献中的历史记忆，不能直接说这件面具就是蚕丛。
这个场景所需要的内容能力，不是把资料改写得更流畅，而是能不能把材料变成用户当下可执行的理解动作。我不是要一个"知识很多"的小程序，我要的是一个在展柜前能让人多看一眼、看出一点门道的工具。
第一个版本能跑，不代表它能用
开发过程中有一个很典型的阶段：本地版本先跑起来。
我把指挥AI找到初版的官方讲解视频，并把它切成35个短段，按看展顺序组织；用本地服务提供视频；把小程序里的35条视频地址批量指向本地；再做展品列表、详情页、延伸阅读、来源页、缓存中心。
从开发机角度看，这一步已经很像一个产品了。
但它只是"在我电脑上能跑"，还不是"在微信小程序环境里能发布、能真机使用"。
这中间差了一整层现实约束：
本地地址不能用于真机和审核。 视频和缩略图不能直接塞进主包。 微信小程序要考虑包体限制。 云存储资源并不能像普通Web链接一样直接使用。 原始文件的云端资源需要先换成临时HTTPS地址。 展厅网络不稳定时，用户看到空白或加载失败，大概率会直接认为产品坏了。
AI 可以很快帮你搭出一个"看起来像"的东西，但你必须亲自把它放进真实环境里，才知道它到底差在哪里。所谓"探索怎么得到"，不是在脑子里想方案，而是要有一边跑、一边撞墙、一边把问题从"好像可以"改到"真的可用"的切实准备。
容易忽略的基础：弱网和缓存不是补丁，是产品的一部分
这个小程序后来很重要的一个模块，是缓存中心。
视频和缩略图加载慢，看起来像性能问题。但如果只把它当成"优化一下加载速度"，就会低估它。
放回到真实使用场景，对看展工具来说，弱网不是异常情况，而是高概率场景。用户站在展厅里，网络可能不稳定，也不一定愿意等一个长视频加载。这个时候，缓存、失败提示、文字兜底都应该是产品主流程的一部分。
所以，我直接做了这几件事：
视频按35个短段组织，便于分段缓存和失败恢复。 缓存状态显式区分：未缓存、排队中、下载中、已缓存、网络失败、空间不足、使用在线播放。 缩略图的临时链接做本地缓存，避免每次进列表都重新向云端取。 列表页结合分页加载，减少首次进入时的压力。 播放失败时，不让用户只看到空白，而是保留文字导览。
这些东西不炫，但它们决定了工具是否真的可用。我也越来越觉得，做实用工具最重要的不是功能数量，而是你有没有认真处理那些"不好看但很真实"的部分：网络、缓存、失败、包体、发布目录、域名白名单、真机测试。AI 能帮你写很多代码，但它不会替你亲自感受"这个东西在现场到底顺不顺"。
坚持发布版和原型版分开
这来自我的现实经验：原型目录和发布目录要分开，易于保证持续可控。
原型阶段可以保留测试页、本地视频服务、临时脚本、本地资源占位。但发布阶段必须收敛成一个干净的包：只保留真正要上传和审核的代码，去掉本地大资源，配置好云开发、云函数、资源路径和项目配置。
这个过程听起来像工程细节，但它背后其实是一种工作方式。
AI 编程很容易诱导人不断往前加东西：再加一个页面，再加一个功能，再改一版文案。但一个工具要真正交付，就必须有一个收口动作：哪些是实验，哪些是发布；哪些是开发便利，哪些是用户可见；哪些可以临时跑，哪些必须长期稳定。这不是 AI 自动完成的部分，它需要人做判断。
接入 AI 问答不是拉一个模型进来这么简单
看展回来后，我又给小程序追加了"古蜀助手"：用户可以在首页提问，也可以在展品详情页问"这件展品"。
技术链路大致是：小程序调用云函数，云函数先检索 Mem0 里的公共导览记忆，再调用模型生成回答。第一期整理了155条导览记忆，覆盖展览总论、路线、重点展品、主题线索、FAQ、儿童讲法、风险边界和来源证据。
这听起来像是一切围绕模型和数据在跑，但我在这一步反而更关注约束。比如：
助手的人设不是"百科全书"，而是现场导览员。 从某件展品进入提问时，回答必须锚定当前展品。 至少要包含一个可见细节、一个重要性判断、一个与三星堆/金沙/古蜀文明的关联。 不能对不同展品复用同一套泛泛模板。 问路线和重点时，要给出可执行建议。 资料不足时，要说"当前资料不足以确认"，不能编造来源、年代和展品细节。
真正有用的 AI 工具，不是把模型接进来就结束了，而是要给它足够好的上下文、边界和反馈机制。AI 的回答能力很强，但如果没有记忆素材、来源约束和场景锚定，它很容易变成一种"很会说但不一定有用"的东西。
持续迭代里的人机协作
这个项目不复杂，但是依然需要提前考虑任务分层：有人负责代码，有人负责资料，有人负责服务器记忆服务，有人负责把材料整理成可导入的知识种子，还有人负责复盘和交接。
这里的"有人"，很多时候就是不同任务上下文里的 AI Agent。
我自己的角色不是把需求丢出去等结果，而是把任务拆清楚：哪个 Agent做代码，哪个 Agent 做素材挖掘，哪个 Agent 做运维验收，哪个 Agent 做记忆维护。每个任务都要有输入、输出、边界和检查标准。否则多个 AI Agent 一起工作，只会变成多个方向同时发散。
下面这张图，大致表示了这次的协作方式：
【多 AI 协作关系图】
AI 可以分别把局部任务做得很快，但如果没有人持续判断"它们合起来是不是一个可用工具"，项目就会变成一堆半成品。我的工作更像是把每个 AI 的输出重新拉回同一个目标：现场观众到底能不能用它看懂展品。
文档是多个 AI 之间的交接层
多 AI 协同还有一个很实际的问题：上下文会断，任务会换人，前一天做过的判断第二天可能没人记得。如果所有信息都只留在聊天记录里，后续协作质量会很差。
所以这个项目里沉淀了不少文档。它们不只是"写给人看的总结"，也是后续 AI 接手任务时的上下文入口。
【任务交接文档清单图】
这些文档解决的是交接质量问题。比如，开发 AI 不需要重新猜微信小程序为什么要区分开发目录和发布目录，因为发布复盘里已经写清楚；记忆维护 AI 不需要重新判断哪些内容可以导入，因为素材报告和 changelog 已经记录了来源、置信度和风险边界；运维相关任务也不靠口头描述，而是用任务书和接入信息固定下来。
这也是我在持续迭代里逐渐形成的工作方式：让AI做事，也让AI留下可被下一个AI读取和验证的痕迹。
我在这个过程里的角色
如果说这次开发有什么个人特点，我觉得不是"我会写代码"，也不是"我用了多少 AI 工具"，而是几个习惯。
第一，我会从一个具体场景开始，而不是从功能清单开始。
我关心的是：一个人站在展柜前，打开手机，他现在最需要什么？他是想快速看重点，还是想知道这件东西为什么重要？他有没有网络？他会不会被太多文字劝退？
第二，我会持续追问"这是真的吗"。
神话联想很有意思，但不能写成考古定论。讲解稿可以有故事感，但来源和边界要清楚。AI 可以给出很顺的表达，但顺不代表对。
第三，我愿意承认中间版本"不够好"。
本地能跑不等于真机能用，页面做出来不等于现场体验好，AI 能回答不等于回答有帮助。每一次发现问题，都不是证明前面白做了，而是在把工具往真实使用场景里推进。
第四，我对"持续进化"比对"一次完成"更感兴趣。
这个小程序不是做完页面就结束。后面还可以继续补充讲解员思路、修正记忆素材、优化问答约束、更新视频 CDN、持续集成使用过程中的便利性能力支持、根据用户问题调整导览知识。在 AI 时代，一个工具更像一个持续生长的系统。你不需要一开始就知道所有答案，但你要能建立一种机制，让它不断接近真实需求。
我对 AI 编程的几个判断
做完这个小程序，我对"普通人用 AI 编程"有几个更实际的感受。
> AI 降低了动手门槛，但没有取消判断门槛。
以前很多想法会卡在"我不会写代码"。现在 AI 可以帮你跨过这一步。但跨过去之后，真正的问题变成：你知不知道自己要解决什么？你能不能判断一个方案只是漂亮，还是确实有用？
> 更关键的不是 prompt，而是问题定义。
同样是做看展小程序，如果问题定义是"展示展品资料"，会得到一个资料库；如果问题定义是"帮人在现场看懂展品"，就会得到完全不同的信息结构、页面顺序和缓存策略。
> 要亲自使用，亲自感受。
很多问题只有在真机、弱网、现场、审核、发布这些环节里才会暴露。坐在电脑前让 AI 继续生成，不会自动得到这些反馈。
> AI 共创不是把工作外包，而是把探索速度提高。
它可以帮你快速生成原型、改代码、整理资料、抽取结构、写测试脚本、修复发布问题。但你仍然要像产品负责人、内容编辑、测试者和使用者一样，不断把方向拉回来。
> 持续进化比一次性惊艳更重要。
这次项目从小程序页面，到视频切片，到云存储，到缓存，再到 AI 问答和 Mem0 记忆库，本质上是一层层加深对场景的理解。它不是某个瞬间"做成了"，而是在每次反馈后变得更像一个工具。
结语
我现在越来越不把 AI 编程看成"让 AI 替我做一个东西"。
更准确地说，它像是一种新的协作方式：我负责提出真实问题、定义边界、判断价值、亲自试用；AI 负责加速执行、补足技术路径、帮助整理和迭代。
三星堆看展小程序对我来说，不只是一个小程序项目。它让我更具体地感受到，在 AI 时代，真正重要的能力不是会不会写某段代码，而是：
你是否知道自己要什么；你是否愿意探索怎么得到；你是否会亲自去感受结果；你是否有能力让一个东西持续进化。
这几个能力，可能比掌握某个工具本身更长期。
