走一遍：Demo Company 的获客示例

第一步：找出手工动作

Demo Company 做工业泵与阀门。官网的询价表单会进来新线索。这个示例只用平台现有的构件搭成，不是 AIDC 的一个产品。

先看终点。一条新线索这样走：

再看起点。每天早上，一个 Loop 把昨天的新线索汇成一张表，发到销售群。销售看表，各自回邮件，再到自己的表格里记「已跟进」。看完这张表，人还要去别的系统里手工处理，所以该做应用了。

第一步，写下交付之后的手工动作：谁来做，在哪个系统里做，改什么。

• 判断先跟哪一条：销售，在群里的表里，不改数据。
• 写回复：销售，在自己的邮箱里，不改数据。
• 记「已跟进」：销售，在自己的表格里，改线索的状态。

只有第三件改数据，从它开始，先为它建动作。前两件是判断和写作，留给 Loop 和智能体，放到后面。

第二步：建对象，建动作

第二步，把线索建进语义层。线索是对象类型 Lead。官网表单的后台是数据源，只读。发布端把变化推进数据流，数据流接到 Lead 的 datasources 上。

• 来自表单，只读：company、need、receivedAt。
• 只在语义层维护（writeback）：intent、reason、draft、status。

第一个动作是 mark-followed-up，对应你找到的那件手工事。提交条件写成「只有人能执行」：「已跟进」记的是人的跟进，智能体不能替销售点。

{
  "kind": "actionType",
  "apiName": "mark-followed-up",
  "title": "标记已跟进",
  "schema": {
    "parameters": [
      { "name": "lead", "type": "object", "objectType": "Lead", "required": true }
    ],
    "rules": [{
      "type": "modifyObject", "objectType": "Lead", "object": "$lead",
      "values": { "status": "已跟进" }
    }],
    "submissionCriteria": [{
      "condition": {
        "type": "comparison",
        "left": { "user": "authorKind" }, "operator": "is", "right": { "literal": "human" }
      },
      "failureMessage": "已跟进记的是人的跟进，只能由人执行"
    }],
    "summary": "{lead} 已跟进",
    "actionLog": true
  }
}

同一份 Lead 有三个写入者。每个写入者一个动作，改数据只走动作：

第三步：做应用

第三步，做应用，给两类使用者。给人的是一个看板，给智能体的是一条 Skill 加动作。

看板用 Workshop 做，只写定义，不写界面代码。筛选器按状态过滤，指标卡数出待跟进的条数，对象表格列出线索，第一列链到线索页。

销售在线索页看判定依据和草稿。页头有「标记已跟进」按钮。点它打开动作的表单，线索已经填好，提交就执行。

看板按看的人的权限现算数据。没人打开，它什么也不做。

智能体用的是应用 lead-desk。它的清单登记了 Lead 和三个动作，它们自动成为应用的 API。再加一条 Skill：销售说一句「给这条线索起草回复」，智能体就照它做。

---
name: draft-lead-reply
description: "给线索起草回复，存成草稿，不发送。销售说「给这条线索起草回复」时使用。"
---

# 起草线索回复

## 输入
- 线索：公司名或线索号。不确定是哪一条，先列出来让人选。

## 步骤
1. 用 Ontology MCP 读线索（类型 `Lead`）：`search_objects` 或 `get_object`。
   要读公司、询价内容、意向和判定依据。
2. 起草一封回复。只用线索里有的信息，缺什么就问销售。
3. 先预演，把计划给销售看：
   ```bash
   aidc app call cell-demo/lead-desk save-reply-draft \
     --param lead=<线索号> --param draft="<草稿>" --preview --json
   ```
4. 销售说可以，再去掉 `--preview`，把草稿存进线索。

## 不要
- 把回复发给客户：发出是销售自己的事。
- 替销售点「标记已跟进」：这个动作只有人能执行。
- 编造报价、交期或库存：只用线索和销售给的信息。

智能体读线索用 Ontology MCP，这个接口只读。它写草稿走动作 save-reply-draft，先预演，把计划给销售看。

第四步：让 Loop 调用动作

第四步，做 Loop。它是一个只有工作流的应用，叫 lead-intake：新线索一进语义层就触发，判定、写回、通知。

{
  "input": {
    "lead_id": { "type": "text", "title": "线索", "required": true },
    "company": { "type": "text", "title": "公司" },
    "need": { "type": "text", "title": "询价内容" }
  },
  "trigger": {
    "change": {
      "type": "Lead",
      "when": "=object.intent == null",
      "input": {
        "lead_id": "=object.leadId", "company": "=object.company", "need": "=object.need"
      }
    }
  },
  "steps": [
    { "id": "judge", "kind": "model", "title": "判定意向", "model": "deepseek-flash",
      "prompt": "公司：{{ input.company }}\n询价：{{ input.need }}\n判断采购意向（高、中、低），写出依据。",
      "output": { "intent": "text", "reason": "text" } },
    { "id": "record", "kind": "use", "title": "写回判定", "use": "lead-desk/record-intent",
      "with": {
        "lead": "=input.lead_id", "intent": "=steps.judge.intent", "reason": "=steps.judge.reason"
      } },
    { "id": "alert", "kind": "notify", "title": "通知销售", "after": ["record"],
      "to": ["zhang.san@example.com", "li.si@example.com"],
      "im": [{ "platform": "wecom", "agent": "sales-assistant", "to": "group:wrSalesGroup" }],
      "subject": "新线索：{{ input.company }}，意向{{ steps.judge.intent }}",
      "body": "有一条新线索，意向{{ steps.judge.intent }}。\n\n- 依据：{{ steps.judge.reason }}",
      "links": [{
        "label": "打开线索",
        "url": "https://www.ai-dc.ai/semantic/cell-demo/objects/Lead/{{ input.lead_id }}"
      }],
      "dedupe": "=input.lead_id", "cooldown": "24h" }
  ]
}

• when：只收意向还没判定的线索。写回意向后，这条线索不再符合，Loop 不会对它重复开跑。Loop 自己写出的变化，也不会再触发它。
• use：调用应用 lead-desk 的动作 record-intent，权限不超过这个应用。留痕里的执行人是这个工作流。
• notify：排在写回之后，发给两位销售的邮箱和销售群的企业微信。企业微信用销售助理智能体的机器人发出。收件人写在清单里，邮件和企业微信各最多 5 个，邮件收件人必须是本公司的账号。每天有上限，缺省 20 条。

每一次通知都有记录：已发出、已拦下、未配置或失败，每条写明原因。预演只给出内容，不发送。

最后用第 1 课的判断法看一遍。没人用时，Loop 照样判定、写回、通知。看板和 Skill 没人用，就什么也不做。三者读写同一份 Lead，所以看到的数据一致。