cadau
Log inTry Cadau
ProductAppsSolutionsPlansDocsBlogForumAbout
Log inTry Cadau
← All docs

Quick help prompts

The three quick prompt buttons at the bottom of the action-assistant panel (tap to switch to the matching module and send a preset question) should not stay fixed forever. They sho

Source docs/en/site/mech-quick-prompt.md

Goal

The three quick prompt buttons at the bottom of the action-assistant panel (tap to switch to the matching module and send a preset question) should not stay fixed forever. They should change with which module the user is on, whether a workspace is selected, and recent conversation in the assistant, so the next likely entry is shown first.

What users feel: in the same product, the assistant “guesses what you might do next” follows the scene. Implementation is still local, explainable ranking — not a black-box model.

Signals and scoring (explainable)

Implementation lives in client/web/src/workspaceHelpQuickActions.ts, function pickWorkspaceHelpQuickActions(ctx, limit).

Input context WorkspaceHelpQuickContext:

FieldMeaning
activeModuleCurrent main-UI module (same as the left console)
hasWorkspaceWhether a workspace is selected
messagesRecent conversation inside the action assistant (last several messages participate in keyword match)

Each candidate in the pool accumulates a score, then is sorted; take the first limit (default 3), and the same nav appears only once.

Feature families in use now:

  1. Module complement

Look up MODULE_COMPLEMENT by activeModule and boost other modules that are “more likely next”; slightly down-rank candidates for the current module (the user is already on that screen; prefer neighboring tasks).

  1. Reachable with no workspace

Same as canWorkspaceHelpNavigate: with no workspace selected, only chat / workspace / im / me are allowed. Candidates are filtered before scoring so chips that cannot navigate do not appear.

  1. Keyword hits

Concatenate recent messages (lowercase) and match several regex groups for intents such as “workspace / skill / account / assistant / conversation”, then weight the matching nav.

  1. Conversation depth

When the user has spoken many rounds, slightly raise “continue the conversation” candidates so follow-up questions are easy.

  1. Business prior

For example: with no workspace, slightly raise candidates related to creating a workspace; with a workspace, slightly raise skill-related candidates (exact numbers are source constants).

On a tie, a fixed TIE_ORDER keeps ranking stable so the UI does not jitter.

Candidate pool and copy

Candidates are maintained in the source array CANDIDATES. Each has id, nav, and label / prompt (may be functions that switch on hasWorkspace and similar, e.g. “create a workspace first” copy when none is selected).

Current nav coverage: workspace, me, skills, agents, workflows, apps, im, chat (module types scheduled / cs participate in complement scoring; the pool itself does not include those two). With no workspace selected, only chat / workspace / im / me are allowed. How many are shown is decided by filter and sort.

Front-end hookup

  • Sort and filter: pickWorkspaceHelpQuickActions()
  • Consumer: client/web/src/WorkspaceHelpWidget.tsx

useMemo depends on activeModule, hasWorkspace, messages, and recomputes the three buttons when conversation in the panel changes.

  • Pass current module: client/web/src/App.tsx passes activeModule as props into WorkspaceHelpWidget.

Extension and replacement (predictive service)

If later you want server ranking or a small model:

  1. Keep WorkspaceHelpWidget depending only on a contract that “returns at most 3 { nav, label, prompt }”.
  2. Replace pickWorkspaceHelpQuickActions with an async source (e.g. fetchQuickActions(ctx)); until load finishes, keep local ranking as a placeholder or skeleton.
  3. Analytics suggestion: record chip id/nav impressions and clicks for weight tuning or training; can align with existing trackHelpActionEvent (see the extension notes in 帮助动作链接.md).

Related documents