用AI做成了一个项目,不知道怎样做出来的——复盘提示词让你清醒
有一次,我把一个项目做出来了。
能跑,能用,看起来也像那么回事。但当别人问我:“你是怎么做出来的?”我一下子愣住了。
我讲不清。
不是完全不知道,而是那种感觉——好像每一步都参与了,但串不起来。
那一刻我才意识到一个问题:我做出了结果,但没有形成能力。
我当时是怎么走到这一步的
回头看,其实整个过程挺典型的。
一开始只是有个模糊的想法,然后我就去问AI。AI给了一点方向,我跟着做;中间卡住了,再问;哪一步不通,就换个问法。
一步一步往前推,最后竟然真的做出来了。
当时的感觉是兴奋的,甚至有点膨胀——觉得自己“会了”。
但冷静下来之后,我发现一个很尴尬的事实:
👉 如果现在让我再做一遍,我不确定还能不能做出来。
问题出在哪里
我后来慢慢想明白了,不是我不会,而是:
我没有记录路径。
整个过程其实是有逻辑的:
• 我遇到了什么问题 • 我是怎么问的 • AI给了什么答案 • 哪一步是关键
但这些都没有被留下来。
于是就变成了一种“黑箱”:
结果在,过程丢了。
我是怎么把它一点点拉回来的
我开始做一件很简单,但改变很大的事:
👉 把过程拆成一问一答
不再用“我大概是这样做的”这种模糊描述,而是逼自己写清楚:
• 我当时卡在哪 • 我具体问了什么 • AI是怎么回应的 • 为什么这个回答能让我继续往下走
一开始写得很慢,也有点烦,但写着写着就发现——原来很多东西是可以被复现的。
一个很关键的变化
当我开始这么做之后,感觉发生了变化。
以前做项目,是这样:
👉 想法 → 问AI → 试 → 成了(但不知道为什么)
现在变成:
👉 问题 → 提问 → 结果 → 记录 → 下次复用
多了一个“记录”,但本质上多了一层能力。
慢慢地,我开始有一种感觉:
有些路径,我已经走过一次了。下一次再遇到类似问题,我不再是从0开始。
我踩过的一个坑
这里有个很容易忽略的问题。
我以前会觉得:“先做出来再说,复盘以后再补。”
但现实是——如果当下不记录,后面基本补不回来。
因为很多关键细节:
• 当时为什么这么问 • 为什么这个回答有用 • 哪一步是转折点
过一段时间就忘了。
所以我后来改成:
👉 边做边记,哪怕只记一句关键问题
不求完整,但一定留下线索。
我现在怎么看这件事
这件事让我看清一个很现实的分水岭:
有的人,用AI能做出结果;有的人,用AI能复现结果。
前者靠运气,后者靠能力。
差别不在工具,而在有没有“把过程留下来”。
接下来我会怎么做
我不会再满足于“做出来”。
以后每做一个项目,我都会多做一件事:
把它拆开。
• 哪个问题是起点 • 哪一步最关键 • 哪些提示词是有效的
慢慢把这些东西攒下来。
不需要一开始就很系统,但一定要真实、可回看。
时间一长,这些碎片会连成一条路径。
给自己的一个提醒
如果哪天我又遇到这种情况:
做出来了,但说不清;能跑,但不知道为什么;有结果,但无法复现;
那就说明一件事——
👉 这不是能力,是运气。
这时候最该做的,不是继续往下做,而是停下来,把这件事讲清楚。、
====================================
今日格言
“得其形者众,得其法者寡;能复其法,方为己有。”
====================================
于是,我自己根据这个需求写出了一个提示词:
请根据当前对话,帮我做一份「问题与解决」纪要:
1. 用一问一答形式,列出我在对话中遇到的问题,以及你是如何解决的;每个问题用两句话概括(一问一答各一句即可)。
2. 为每个问题标注解决时间(若无法精确到分钟,可写会话日期或「本对话内」)。
3. 将全文保存到项目根目录,文件命名严格为:GetWhat【内容标题】.md
- 其中「内容标题」用简短中文概括本次对话主题(例如:后台启动应用、访问统计与筛选等),不要加 `+` 号。
- 文件名示例:GetWhat后台启动应用.md
4. 在文档开头用一两句话说明命名规则(GetWhat + 内容标题),并说明:若之后在同一项目/同一会话脉络下继续对话,应同步更新该文件(追加问答与更新记录),而不是新建散乱文件。
若根目录已有同名 GetWhat*.md,则优先打开并追加内容,更新文末「更新记录」表。
同时我有延申了一下:
根据项目文件,分析一下应用功能,使用方法,用什么提示词可以精确生成类似应用,结果保存为(APP + 应用名称 + 生成日期).md,位置为根目录。
夜雨聆风