一，心理健康场景里的 AI
回应必须带危机识别分支，这个不能省，而它要做对需要时间。二，调用
AI
需要把内容发到服务器，而首版最硬的一句话正是「不收集任何数据」。三，在还不清楚用户到底卡在哪的时候上
AI，多半是在解决一个没被验证过的问题。
第一版因此做到了完全不联网。App Store
的隐私标签是「未收集数据」，这反过来成了产品定位里最有力的一条。
3
管住 AI
用确定性的机制约束不确定的系统
和 AI
协作的另一面是它会犯错，而且经常是无声地犯错。所以产品红线没写成给
AI
的叮嘱，而是写成了提交前的拦截：命中就阻止写入，并说明哪一条被碰了。
# 红线 3：用户可见文案不得含医疗承诺措辞if echo "$CONTENT" | grep -qiE '(cure your anxiety|treat your anxiety|diagnos|治愈焦虑|治疗焦虑|诊断)'; then
echo '{"block": true, "message": "RED LINE 3: Medical-claim wording detected.
This is a wellness tool, not a medical device."}' >&2
exit 2
fi
问题不在于没有信息，也不在于没有预警——那句「建议你去核实」就是预警。问题在于预警没有接到任何会自动触发的动作上。对一个概率性的系统，写一句「下次注意」没有用，因为下一个会话里那句话不存在了。所以后来把规则写成了可以当场判断的形式：当你正在写「建议你去核实」这类话、而这个事实又正被用来做决定时，那句话就是「现在自己去查」的信号。同时给所有涉及
AI 指导用户的改动加了人工审批门。
WorryBucket lets you drop a thought into a bucket in one line, and
come back to the whole bucket at a time you set. Sixteen weeks from
sketch to 196 testers. It goes on the App Store on October 15.
196beta testers
1,950sessions
0crashes
16weeks
11feedback items filed
As of 2026-09-24, from App Store Connect. Testers were recruited on
Xiaohongshu and Douyin.
What it looks like
8 screens · swipe
These eight screens are one full round: drop it in, wait, open it at
the set time, sort, clear, then see the number. Under each one is the
problem it exists to solve.
The bucket is empty
An empty state that doesn't push you to fill it. An empty bucket
is a good outcome — no to-do count, no red dot.
Drop it in
One question: what's on your mind. One line and it's in. No
follow-up, no intensity rating.
It waits
The number on the bucket tells you how much has gathered, not
how much you owe. Until the time you set, it does nothing.
The time arrives
The whole bucket at once, instead of being interrupted piece by
piece. Every "later" from the day gets honoured here.
One at a time
One worry per screen, one question: is there a step you can take
right now? Never a whole page at once.
Three boxes
Can take action, let it go, already over. Most worries land in
the last two — which is exactly what this is built to show you.
Cleared
The closing line is "you did well", not "daily goal complete".
What gets marked is letting go, not completion.
See the number
After a few weeks you see what share of the things you worried
about never happened at all.
Prototype, Figma v7. The shipping interface matches these.
Defining what to build
6 · 2026.05 — 07
A walkthrough of the product became the skeleton of a PRD, and every
feature in it was expanded into an engineering-level spec: interaction
detail, edge cases, data model, state definitions, free vs paid,
acceptance criteria, priority. That document is the main input to
working with AI — including a spec-before-implementation loop. A few
of the rules fixed before any code was written:
2026.05
Structure
Capture and processing are two different jobs
Nobody writes coherently in the middle of being anxious. Asking
someone to describe their feelings right then puts the barrier
exactly where they have the least strength for it.
Core mechanicInteraction trade-off
The thinking at the time
Problem
Tools in this category tend to ask you to "describe how
you feel in detail" and "rate the intensity" at the moment
the anxiety hits. The request is a burden in itself, and
the timing is the worst it could be.
Approach
Cut it in two. Capture takes one line, three
seconds, no questions asked. Processing is where
the structure lives, and it sits inside the window the
user picked.
Cost
Capture-side data is thin, so no deep analysis any time
soon. Accepted: people have to be able to use the thing
before there is anything to analyse.
2026.05
What to refuse
No streaks, no red dots, no comparison
The standard habit-app toolkit is almost entirely backwards in
an anxiety product. These three went into the design spec as
forbidden.
Product judgementCounterintuitive
The thinking at the time
Why
A broken streak produces guilt, and guilt is the one thing
this audience has no shortage of. A red dot is a nudge by
definition. Comparison makes people feel abnormal. All
three would lift daily actives, at the price of turning
the product into a new source of anxiety.
In practice
The design spec lists these as strings that must never
appear — not "avoid where possible":
You have 4 unprocessed worries
Your streak has ended
You are more anxious than average
Consequence
Gave up the most common retention machinery there is. What
it buys: on a day you don't open the app, the app doesn't
come poking at you.
2026.06
Core flow
Why these three boxes
Can take action, let it go, already over. Sorting isn't for
filing. It's so you can see which things never needed you in the
first place.
Flow designFraming
The thinking at the time
Axis
The sorting axis is controllability, not the
urgent/important grid. What drains people most is pushing
repeatedly at things they cannot move, so that's where the
first cut goes.
Basis
Not a cut I made up. Lazarus and Folkman's 1984
goodness-of-fit hypothesis says exactly this:
whether a coping strategy works depends on whether the
situation is appraised as controllable — controllable
things call for doing something, uncontrollable ones for
changing how you hold them. Mismatch the pair and the
effort is wasted.
Provenance
Worry Time itself comes from Borkovec et al.'s 1983
stimulus control work: confine worry to a fixed time and place so it stops
getting triggered all day. The third box maps onto
LaFreniere and Newman's 2020
Worry Outcome Journal
— write worries down, come back later and check what
happened. In that study 91.4% of worries did not come
true.
Limits
To be clear: those studies were run with people diagnosed
with generalised anxiety disorder, in clinical settings.
WorryBucket is a journaling tool for ordinary use, not a
clinical product, and it has never been tested for
efficacy. What I borrowed is the mechanism, not the
findings.
The boxes
Can take action: there's a next step, so take it.
Let it go: nothing to do, and admitting that is
itself a way of handling it. Already over: it
hadn't happened when you wrote it down, and now it has an
outcome.
The point
The third box is where the value of this product sits. It
turns "I worried about that for nothing" into a record
that accumulates, instead of a feeling that passes. That's
where the self-soothing rate comes from — which, put
plainly, is an automatic Worry Outcome Journal. One beta
tester was already doing the same thing by hand in his
notes app, having read nothing about the product (see
2026.08 below).
One at a time
Sorting shows one item per screen. A full page at once
means facing a field of your own anxiety at the moment you
are least equipped to judge it. The shorthand used
internally is "capture serves the limbic system,
processing serves the prefrontal cortex" — that's a
metaphor, not a neuroscience claim. What it means is
simple: when you're worked up, only writing it down fits;
anything that needs weighing waits until you've settled.
2026.06
Choosing a metric
Turning "it turned out fine" into a number
The signature metric is the self-soothing rate: the ones that
stopped bothering you plus the ones that faded on their own, as
a share of everything you wrote down.
Core metricLater validated
The thinking at the time
Why this one
Most apps put time spent, day streaks or completion rate
on the home screen — all measuring how diligently you use
them. This one measures how much of your worrying was for
nothing.
Mechanism
Every worry carries the time it was written. Weeks later
you see with your own eyes that the things that kept you
up mostly didn't happen. Being told that does nothing —
you have to see the proportion yourself.
Risk
The more a metric matters, the more it costs when it gets
polluted. Three months later a tester's question landed
right on this. See 2026.08 below.
2026.07
Interaction trade-off
Nudge, but don't lock people out of their own data
"You can only process at the set time" — enforced strictly, that
rule means locking someone out of their own records.
Interaction trade-offP0-29
The thinking at the time
Tension
The mechanism works because of the constraint: process any
time and it degrades into an ordinary to-do list. But a
hard lock creates two problems — you can't look back at
what you wrote, and you get shut out at the moment you
most need in.
Approach
Visual hierarchy instead of permissions. Inside the window
the pink primary button sits in the most prominent place.
Outside it, the entrance is still there, just no longer
emphasised.
Principle
Design can push someone toward a better choice. It
shouldn't confiscate their control over their own data.
2026.07
Notifications
A reminder may soothe; it may never chase
A "deal with it later" product has to tell you when later has
arrived, or the loop never closes. But what the reminder is
allowed to say is tightly bounded.
Notification policyScope change
The thinking at the time
A judgement I changed
Notifications were originally out of scope for v1, because
of system permissions and native builds. Then it turned
out they're part of the core loop: without a reminder the
user has to remember the time themselves, which is exactly
the burden the product promised to take off them. So it
moved into v1.
Content boundary
A notification can only be a calm invitation. It may not
mention how many items are unprocessed, and it may not
appear outside the window. If a reminder makes someone
remember on the commute home that they have six worries
pending, it has done the opposite of its job.
Technical choice
Local scheduled notifications only, no remote push. No
server, no account, nothing leaves the device.
What 196 people taught me
4 · 2026.08 — 09
Beta has been running since late July. What actually changed my mind
wasn't the dashboard — it was specific things testers said.
2026.08
Assumption overturned
A fixed clock time is itself the pressure, for some people
The whole product is built on "the same time every day". The
people who need it most are exactly the ones whose days aren't
regular.
User feedbackCore assumption
How it changed things
Setting a worry time is itself something that makes me
anxious, because with PTSD my sleep is sometimes all over
the place. My anxious stretch is roughly three or four hours
after I wake up, but the app assumes the same rhythm every
day.
Beta tester, August 2026 (anonymised)
What it exposed
I'd assumed a stable daily rhythm, which makes "pick a
time" a small thing. For someone whose rhythm is
disrupted, the act of setting it is a reminder of how
irregular they are.
The bigger layer
I'd thought the target user was an office worker trying to
be more productive. This said the real core user is
someone whose sleep and mood are both unstable — the
people who need this most, and the ones this design was
most likely to shut out. The audience picture changed
because of it.
Next
Building flexible scheduling: several windows in a day, or
relative times like "a few hours after I wake up", instead
of a hard clock time.
2026.08
Metric integrity
"Can I undo a wrong sort?" is really a question about the number
Sounds like a request for an undo button. Two layers down, it
pollutes the number on the home screen.
User feedbackPriority raised to top
How it changed things
If I sort something into the wrong box, can I put it back?
Beta tester, August 2026 (anonymised)
First layer
Fat-fingered it, wants to undo. An ordinary convenience
request, scheduled late.
Second layer
The state it landed in is one-way — the state machine has
no path back. So it isn't "inconvenient", it's data that's
wrong and can't be corrected.
Third layer
That state is exactly the numerator of the self-soothing
rate. One slip and the proportion on the home screen reads
high. And that proportion is what the product uses to show
its own worth — once it's untrustworthy, "most of what I
worried about never happened" is a lie.
Conclusion
This is a metric-integrity problem. It went from "when
there's time" to first in the next batch: a reclassify
event added to the state machine, the proportion
recomputed, with regression tests.
Side finding
Someone asking this carefully is treating the records
inside as something that matters. That judgement went
straight into how the data-migration warning was written
for launch.
2026.08
Assumption validated
Someone was already doing this by hand
A tester who had read nothing about the product described, in
his own words, the exact thing the product is trying to prove.
User feedbackDemand validation
Why this one matters
I was already keeping this in my notes app — how I felt
before something happened and how I felt after. Over time it
gave me confidence, because I could see that a lot of the
things I'd been anxious about had actually worked out.
Beta tester, August 2026 (anonymised)
What it means
He's describing exactly the experience the self-soothing
rate is meant to produce. The product didn't teach him
that — he invented the same method himself and was doing
it by hand.
Product implication
It means the product automates something people already do
on their own, rather than creating a new habit. The second
of those succeeds far less often.
Knock-on
It also shows how serious the previous entry is: if people
come here to see that proportion, a distorted proportion
means the product has failed.
2026.09
Before launch
Don't let people delete their own records at upgrade time
When the public version ships, the natural move is "delete the
beta, install the real one". That move erases everything they've
collected, permanently.
Migration designThe cost of privacy
How it was handled
Mechanism
The beta and the public build share an identifier, so
installing over the top keeps the data. Delete first, then
install, and it's gone for good.
Why worse than usual
No cloud, no account, and export hadn't shipped yet, so
there was no way back at all. What gets lost is exactly
the history the proportion is computed from. After a
reinstall you see an empty bucket and 0% — the strongest
thing the product has, gone.
The other side of the promise
"Your data never leaves your phone" makes a good line, but
the price is no cloud to fall back on. The right move is
to state the price alongside it, not just the good half.
Action
Spelled out in three places — the beta notes, the release
announcement, the changelog: don't delete, install over
the top. Data export shipped in the batch after.
Three roles AI played in this project
Build · Judge · Contain
There's no AI feature in version one. That's a decision, not an
unfinished item.
1
Building with AI
The whole app was written in collaboration with AI
From product docs to the state machine to the tests: 16 weeks, 68
commits, 60 test suites. This is my first iOS project, so what was
being tested wasn't only "can AI write code" but whether one
person, in an unfamiliar stack, can use AI to get something with
real users to the edge of shipping.
The working method that came out of it was written down as specs
and reusable process: a spec before each change, red-line checks,
and an archive of the debugging.
2
Judging when not to use AI
The AI feature was kept out of version one
AI suggestions on the processing screen are the most obvious
selling point this product has. It was put explicitly into a paid
tier and kept out of v1, for three reasons.
One: AI responses in a mental-health context have to carry a
crisis-detection branch, that can't be skipped, and getting it
right takes time. Two: calling an AI means sending the content to
a server, and the hardest line in v1 is "collects no data". Three:
shipping AI before you know where users actually get stuck is
usually solving a problem nobody validated.
So version one makes no network calls at all. The App Store
privacy label reads Data Not Collected, and that turned out to be
the strongest line in the positioning.
3
Containing AI
Constraining a probabilistic system with a deterministic one
The other side of working with AI is that it makes mistakes, often
silently. So the product's red lines weren't written as
instructions to the AI. They're written as a pre-commit block: hit
one and the write is refused, naming the line it touched.
# RED LINE 3: user-facing copy must not contain medical-claim wordingif echo "$CONTENT" | grep -qiE '(cure your anxiety|treat your anxiety|diagnos|…)'; then
echo '{"block": true, "message": "RED LINE 3: Medical-claim wording detected.
This is a wellness tool, not a medical device."}' >&2
exit 2
fi
The pre-commit hook actually running in this project. The same
file also blocks client-side key leaks, data access that bypasses
the repository layer, and any change that removes the
crisis-detection branch.
This came out of a real mistake. A project document carried an
inherited conclusion that a certain release path cost "roughly
nothing". The AI reused it, and in the same conversation wrote the
line "you should verify this yourself". In fact it was an annual
fee with a chain of prerequisites, all publicly documented.
The problem wasn't missing information, and it wasn't a missing
warning — "you should verify this" was the warning. The problem
was that the warning wasn't wired to anything that fires. For a
probabilistic system, writing "be careful next time" does nothing,
because in the next session that sentence doesn't exist. So the
rule got rewritten into something judgeable on the spot: when
you're writing "you should verify this" and that fact is being
used to make a decision, that sentence is the signal to go and
check it now. A human approval gate was added to every change that
touches AI guidance for users.
What's next
Roadmap
Next
Launch
Custom tags and data export are done and in TestFlight. Store
assets, then review.
Right after
Flexible Worry Time
Several windows in a day, or relative times. This decides whether
the people with irregular days can keep using it.
Paid tier
AI-assisted processing
On a single item, the smallest step available, or why something is
outside your control. Crisis detection and a backend proxy have to
land first.
Unsolved
Reaching users outside China
The obvious communities ban promotion, and sustained short-form
video costs too much. Evaluating paid user interviews and smaller
communities. No answer yet.
WorryBucket is a self-care and journaling tool. It is not a medical
product, it does not diagnose or treat anything, and it is not a
substitute for professional help. Its mechanism draws on worry
postponement, a technique with research behind it. Every tester quote
on this page is anonymised and contains no identifying information.
