01 — 我的 AI 工作模型

提问之前先厘清背景，得到输出之后由我判断

我不会把每次使用 AI 都当作一场从零开始的对话。不同任务共享同一套产品背景，再依据具体问题调用可复用的 AI 工作流程。

AI 广泛探索 → 我筛选 → AI 深入检查 → 我做决定。

01 — My AI Working Model

Context before prompts. Judgment after output.

I do not treat every use of AI as a conversation starting from zero. Different tasks share the same product context, and I use a reusable AI workflow according to the question I need to answer.

AI explores broadly → I filter → AI goes deeper → I decide.

02 — 质疑

产品挑战

多被保险人购买流程

不同保险产品可能要求不同数量、不同角色的被保险人。我最初设想用一张卡片承载一个人的信息。

我的判断

我保留了卡片结构，但将单人信息与整份申请的校验职责分开。

A card holds one person’s information, but the application determines whether those people work together.

AI 带来的新视角：它指出了我原本没有明确表达的系统假设，而没有替我设计解决方案。

02 — Challenge

Product Challenger

Multi-insured purchase flow

Insurance products may require different numbers and roles of insured people. My initial direction was to give each person a card.

My Decision

I kept the card structure, but separated the responsibilities of person-level information and application-level validation.

A card holds one person’s information, but the application determines whether those people work together.

What AI added: It surfaced a hidden system assumption instead of designing the solution for me.

03 — 检查

设计检查

Contest：同一活动，两种视图

Contest 同时存在于 Admin 和 Agent 两端。单独看，每条流程都可能成立；但当发布状态、参与来源和不同角色的视图组合在一起时，同一条参与规则可能呈现出不一致的结果。现有参与规则要求，Manual sign-up 和 Auto enrollment 最终归一为同一个参与状态 JOINED。

AI 检查结果

我把这些关系整理成结构化输入，请 AI 检查现有参与规则能否贯穿不同入口和两端视图：Manual sign-up 与 Auto enrollment 是否都归一为 JOINED，Admin 是否避免重复计数，Agent 是否避免再次显示 Sign up。检查同时暴露出一个现有规则无法回答的问题：Admin 在 Agents 加入后取消发布，他们还能否查看进度和结果？

我的判断

我保留 JOINED 作为两端共同的参与状态，并分别约束 Admin 的计数和 Agent 的可用操作。

ADMIN
Count each Agent once, regardless of join source.

AGENT
Do not show Sign up again once the Agent has joined.

现有证据不足以回答取消发布后的可见性问题，因此将这条规则标为 NEEDS_CONFIRMATION，等待确认，而不让 AI 补出一条看似合理的业务规则。

AI 带来的新视角：它帮助我检验同一条产品规则在不同角色和使用端之间是否连贯，也让我明确标出证据尚未覆盖的边界。

03 — Check

Design Checker

Contest — one activity, two views

Contest exists across both Admin and Agent surfaces. Each flow may appear valid on its own, but inconsistencies can emerge when publication state, participation source and role-specific views interact. Under the existing participation rule, Manual sign-up and Auto enrollment resolve to the same state: JOINED.

AI Check Results

I structured these relationships as input for AI to check whether the existing participation rule remained coherent across entry points and surfaces: whether Manual sign-up and Auto enrollment both resolved to JOINED, whether Admin avoided double-counting Agents, and whether the Agent surface avoided showing Sign up again. The check also exposed a question the existing rules could not answer: if Admin unpublishes after Agents join, can they still see progress and results?

My Decision

I kept JOINED as the shared participation state for both surfaces, with corresponding rules for Admin counts and the Agent’s available actions.

ADMIN
Count each Agent once, regardless of join source.

AGENT
Do not show Sign up again once the Agent has joined.

The available evidence was insufficient to resolve visibility after unpublishing, so I marked the rule NEEDS_CONFIRMATION for follow-up rather than letting AI supply a plausible-sounding business rule.

What AI added: AI helped me test whether one product rule stayed coherent across roles and surfaces, while making the evidence boundary explicit when the rule was unknown.

04 — 衡量

证据检查

Google / Apple 登录上线后，可以追踪许多事件，包括 binding · login · registration · unbinding · password setup。但一个事件可以被统计，并不意味着它足以代表用户价值。因此，我把问题从“应该追踪什么？”改为“每个事件究竟证明了什么？”

这让我把衡量模型分成三个层级：先看用户能否完成连接，再看连接是否帮助他们进入正确且可用的 Ignite 账户，最后看他们是否会在下一次登录机会中再次选择它。

这里有一个重要边界：持续保持登录的用户还没有遇到下一次登录机会，不能因此被算作没有再次采用。

Users who stay signed in haven’t had another login opportunity — don’t count them as non-adopters.

AI 带来的新视角：它帮助我区分“我们能够统计什么”和“什么真正代表用户价值”。

04 — Measure

Evidence Checker

After Google / Apple authentication launched, we could track many events, including binding · login · registration · unbinding · password setup. But an event being countable does not mean it represents user value. I changed the question from “What should we track?” to “What does each event actually prove?”

This led me to organise the measurement model into three levels: whether users can connect an account, whether that connection gets them into the correct and usable Ignite account, and whether they choose it again at their next login opportunity.

There is an important boundary: users who remain signed in have not yet had another opportunity to log in, so they should not be treated as non-adopters.

Users who stay signed in haven’t had another login opportunity — don’t count them as non-adopters.

What AI added: It helped me separate what we could count from what actually represented user value.

05 — 一种实践，三个决策点

在另一种视角能够改善判断的地方使用 AI

确定方向之前，我用 AI 质疑假设；设计成形之后，用它检查体验在不同状态和角色之间是否连贯；评估效果之前，用它追问证据究竟能证明什么。

这三个决策点最终都回到同一条路径：

产品背景 → AI 视角 → 设计师判断

我不需要在每一个设计步骤里使用 AI。我更关心的是，在哪些决策点，多一个视角能够真正提高判断质量。

05 — One Practice, Three Decision Points

I use AI where another perspective can improve a decision.

Before committing to a direction, I use AI to challenge assumptions. Once a design has taken shape, I use it to check whether the experience remains coherent across roles and states. Before evaluating success, I use it to question what the evidence can actually prove.

All three decision points return to the same path:

Product Context → AI Perspective → Designer Judgment

I do not need AI at every step of the design process. I care more about identifying the decision points where another perspective can genuinely improve my judgment.