Snapshot
LarkDailyDigest is a single-user, local-first product that summarizes eligible Lark group chats into one morning brief. The goal was not to build a generic chat summarizer. The goal was to help a Product Operations reader begin the day with a clear view of what happened, why it matters, what changed, and where to click next.
Role-aware morning brief for a Product Operations reader covering multiple Lark groups.
Python, FastAPI, SQLite, Pydantic, Lark APIs, structured LLM calls, and a no-build reader.
Reduce morning uncertainty without creating another place the operator has to check.
The Problem
Product Operations work often lives in the space between systems. A launch update appears in one group, a support escalation appears in another, a policy clarification is buried in a reply thread, and a regional stakeholder asks for a follow-up somewhere else. If you are responsible for staying current across multiple groups, the problem is not just message volume. It is context switching.
The original idea was simple: every morning, produce one digest across the groups the bot can read. But the product challenge was more subtle. A useful digest could not be a transcript. It had to decide what mattered to the reader, explain why each item mattered, preserve links back to the original evidence, and admit when a group had no meaningful activity.
The digest should reduce morning uncertainty, not create another place to check.
What I Built
I built a Python 3.12 application that runs locally, fetches eligible Lark group activity, generates group-level context, produces per-group briefs, rolls them into a final digest, writes a Lark Doc, and serves a local dashboard for reading the result.
- Fetch Lark messages
- Build group dossiers
- Generate briefs
- Roll up digest
- Serve reader
The point was not only to produce a digest. The point was to make the digest inspectable. If a summary looked wrong, I wanted to know whether the issue came from the source messages, the dossier, the prompt, the model response, the rollup, or the document writer.
Product Decisions
Start with one real reader
The first version optimized for a real Product Operations workflow instead of abstract personas: what needs attention today, what changed, and what can be ignored.
Quality before platform polish
I avoided spending the first phase on scheduling, admin screens, or hosting because the core risk was whether the digest could be useful and trustworthy.
Avoid transcript dumps
The digest needed hierarchy: overview first, group activity next, then details, links, decisions, open questions, and action items.
Preserve source links
Source links are first-class outputs because a reader must be able to jump from summary back to original evidence when the issue matters.
Engineering Approach
The architecture is deliberately plain: Python backend, SQLite-backed persistence, Pydantic contracts, Lark adapters, OpenAI client wrappers, and static dashboard assets served by FastAPI. There is no front-end build system. The reader is HTML, CSS, and JavaScript.
The run pipeline is shaped like a production workflow even though it runs on a laptop: load config, authenticate with Lark, create a run directory, fetch group messages, build or reuse dossiers, generate per-group briefs, roll up the digest, write artifacts, create the Lark Doc, and serve the result.
The Dossier Layer
The group dossier layer is one of the most important design choices. Chat summarization fails when the model only sees a narrow time window and has no idea what a group is for. A message that looks minor in isolation can be important if it relates to an ongoing rollout, repeated incident, or unresolved dependency.
To solve that, the system builds a compact group dossier from a longer lookback window. The dossier captures group purpose, recurring topics, useful vocabulary, and durable context. Later digest runs can reuse that context instead of rediscovering the group from scratch every morning.
Artifact-First Debugging
LLM systems need observability. If all you save is the final answer, you cannot improve the system responsibly. LarkDailyDigest writes enough artifacts to reconstruct each run.
- Raw fetch output.
- Group dossier prompt, input, and response.
- Per-group brief prompt, input, and response.
- Rollup input and output.
- Final digest Markdown, Lark Doc URL, timings, and errors.
That artifact trail gave me a practical quality loop. When the digest missed an important item, I could inspect whether the fetch step missed the message, the group brief underweighted it, or the rollup buried it.
Reader Experience
The dashboard exists because a Lark Doc is good for delivery, but not always ideal for exploration. The reader gives the operator a fast way to scan the digest, compare group activity, expand or collapse details, and drill into a group when needed.
The UI intentionally follows the same philosophy as the backend: useful first, fancy later. It is a no-build static reader with dark and light modes, overview sections, group activity summaries, and expandable details.
Outcome
The result is a working morning-brief system with a credible path from manual run to scheduled daily usage. It turns scattered group activity into a structured digest, preserves source evidence, and gives the reader both a delivery artifact and a dashboard surface.
The bigger outcome is a repeatable pattern for AI-assisted internal tools: choose a narrow workflow, preserve evidence before summarizing, separate context building from final synthesis, save every artifact needed for debugging, and build the smallest reader experience that improves the user's day.
Interview Version
I built LarkDailyDigest as a local-first morning brief for Product Operations. It reads eligible Lark group activity, builds durable group context, generates per-group summaries, rolls them into one digest, writes a Lark Doc, and serves a lightweight dashboard for exploration. The key product decisions were to optimize for one real reader, avoid transcript dumps, preserve source links, and focus on digest quality before platform polish. The key engineering decisions were modular pipeline boundaries, structured LLM contracts, artifact-first debugging, and a no-build reader backed by FastAPI endpoints.