Back to articles

Don't Just Hand Out AI as a Tool: Four AI-Native Org Plays from the Shenzhen Developer Day

Feishu CLI Community··Source

The most-quoted idea at the Feishu CLI Developer Day in Shenzhen wasn't a feature — it was an analogy. When electricity first arrived, factories that simply swapped their steam engine for an electric motor saw almost no efficiency gain. Only the factories that rebuilt their entire workflow around the motor saw productivity jump. AI is at the same moment. Bolting an agent onto each employee's desk won't move the number; reorganizing around what AI can actually do will. This post unpacks the four concrete recommendations from the talk, and what each means in practice with lark-cli.

The core logic: rebuild, don't just replace

The conclusion on stage was blunt: AI-driven efficiency can't stop at "every employee uses an agent on their own." You have to rebuild the org structure, the workflows, and the division of labor around AI capability. Everything below is a concrete way to do that.

Recommendation 1 — Context management first

Stop hand-curating a knowledge base. Treat meeting minutes (妙记) as the agent's core context source and let the agent organize and settle the unstructured information itself. This is the cheapest, highest-leverage shift: the raw material for decisions is already being recorded every day.

# Turn yesterday's meetings into searchable context for the agent

lark minutes +search --keyword "项目复盘" --as user

lark minutes +detail --minute-tokens <token> --summary --todo --as user

The point isn't the command — it's that you stop maintaining a separate "source of truth" doc by hand and instead point the agent at where truth is already generated.

Recommendation 2 — Build a shared team agent

Deploy the agent in a public group chat, not just in employees' private DMs. The talk cited Shopify's approach: only open group-chat interaction, so the whole team learns how to use AI by watching each other in a work setting. Private use stays invisible; group use compounds.

# Create a shared group and add the bot

lark im +chat-create --name "AI 助手-运营组" --chat-mode group

# The agent reads the group's messages as working context

lark im +chat-messages-list --chat-id <chat_id> --as user

Recommendation 3 — Build skills for your downstream

For high-frequency cross-department work, the upstream team should build a standardized AI skill for the downstream team, so hand-offs stop waiting on people. The goal is a self-closing process: downstream triggers the skill, gets a finished result, no back-and-forth.

Concretely: a "skill" is a saved lark-cli command sequence plus a fixed prompt, owned by the upstream team, callable by anyone downstream. Sales doesn't wait for a data analyst — they run the analyst's packaged query-and-report skill themselves.

Recommendation 4 — Bridge the talent gap

The recurring failure mode: people who know the business don't know AI; people who know AI don't know the business. Two fixes from the talk:

  • Young employees pilot first — they pick up the tooling fastest and surface the real use cases.
  • Embed technical people inside business teams — so the person building the agent actually understands the workflow it's replacing.

Why a team agent is worth it

The talk closed with three reasons a shared team agent beats everyone running their own:

  • Unified cost — the company carries the token bill, so employees stop paying out of pocket for AI tools; cost becomes centrally manageable.
  • Asset accumulation — every interaction with the agent settles as a company asset: observable, auditable, and compliant.
  • Continuous improvement — the agent learns from users' corrections right in the group chat, no manual retraining, and adapts to the company's own needs over time.

The through-line: treat AI as infrastructure to reorganize around, not a tool to hand out. The motor only paid off once the factory was rebuilt around it.