评审一段缓存代码
读缓存、写数据库、删缓存 —— 这三行的顺序里藏着一小时的脏数据。
Copy the prompt, then pick a model. It plays the interviewer and asks you through it scene by scene instead of handing you the answer.
On a phone with the app installed, the system opens the app directly. Links cannot open external apps inside WeChat — open it in a browser first.
The copied text ends with the answer key the model grades you against. Don't read it yourself first — working it out on your own is the point.
三个函数：读商品、更新商品、取热榜。都是日常写法，也都是线上真出过事的写法。
这一份追一个别的地方很少追的问题：脏数据会在缓存里待多久。 一次不一致和「一小时都不一致」是两回事，而说不出后面那个数的人，改法通常也是错的。
第三幕的中心问题是：先删缓存再更新库有窗口，那反过来就没有了吗？ 两种顺序都有窗口，只是差几个数量级 —— 说得出这一句才算过。
Mostly planted here
This prompt in the repo (the answer key is at the end of that file — you'll see it)
Have you done this one?
Sign in to mark this one as practised — next time you come back you'll see when you did it.
Notes from people who did this one
How to use this
The material is ours: a few dozen lines that look like working code, with about ten defects planted in order of severity. So this series needs nothing from you — open one and start.
The stance is interrogation: no spoilers, no praise, and being unable to answer is a normal outcome. Say "there is a race here" and it will not let it go — it wants two columns of timeline and the size of the damage.
How to start
- Pick one, open it, copy the prompt.
- Paste it into a fresh, empty chat; it will paste the code back to you as-is.
- Read it yourself and name every problem you find — in the first scene it will not interrupt or hint. Say "that is all" when you are done.
Four commands you can call out any time
跳过Move on to the next scene提示Give me a direction, not the answer直说吧Give the full answer for this point, then keep pressing on the cost复盘Jump straight to the wrap-up card
The wrap-up is a number
A find rate: how many you caught, out of how many, and how many were false alarms. Plus one uglier number — how many of the ones you missed are in the top severity band (loses money, leaks data, takes the service down). That number is worth more than the score.
Three traps
- The answer key at the end is that list of defects. Do not read it first — once you have, this drill is spent.
- Do not report naming or style. What counts here is whether money is lost or data leaks; style reports are recorded as false alarms.
- The moment it praises you, point it back at the "do not praise me" rule. Feeling validated drowns out "what did I miss".
Start with the transfer one — it has the densest set of defects. If you write API endpoints all day, go straight to the list endpoint: its broken access control and sort-parameter injection are the easiest to find a twin of in your own code. Whichever you do, go grep your own repo afterwards — the real output is those three take-away checks.
Sign in to write a note.