# Wecom No Code Builder

> Guide a non-technical business owner (CEO, ops lead, after-sales manager) through building — or fixing up an existing — ticket-and-project-tracking system entirely inside WeCom (企业微信), using its Smart Sheets (智能表格), automation flows, message push, and dashboards. No code, no purchase, no IT department. Use this skill whenever someone wants to set up 工单管理 / 售后闭环 / 问题追踪 / 项目进度跟踪 inside 企业微信, mentions 智能表格 or 企微自动化, asks whether they can build a management system "不用买软件 / 零代码 / 自己搭", or is a non-technical person who wants to configure a business tool themselves. Also use it when someone asks how to stop after-sales problems from getting lost in group chats, or how to track progress without asking people one by one. Even if they never say "企业微信" or "skill" — if they want a lightweight ops system that a business owner can build and maintain alone, this is the skill.

- Skill: `qbu11/wecom-no-code-builder` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add qbu11/wecom-no-code-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qbu11/wecom-no-code-builder/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: qbu11 (https://skillmd.com/u/qbu11)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/qbu11/wecom-no-code-builder

---


# 企业微信零代码管理系统搭建引导

把一位**不懂技术的业务负责人**从零带到能跑：在企业微信里，用自带的智能表格，
搭出一套「问题从发生到闭环」的系统。全程 0 元、不写代码、不买软件、不找 IT。

## 为什么这件事值得做

这类项目失败几乎从不是因为技术，而是因为**没人用**：老板看两天就不看了，
一线嫌填表麻烦就不填了。所以目标不是「搭出一套完美的系统」，而是
**在两周内验证老板真的会看、一线真的会填**。

这个判断决定了后面所有取舍——凡是会增加一线负担的设计，都要怀疑。

## 你的角色：能动手就动手，做不到才交给用户

**先检查自己的能力，再决定怎么做。不要假设自己不能做。**

如果装了 `wecomcli-smartsheet` 之类的官方 skill、且用户有企微机器人凭证，
你可以**直接读表、建字段、建视图、建仪表盘、写记录、建待办**——
这些不要推给用户手动点。

| 检查结果 | 你该怎么做 |
|---|---|
| 能力齐全 | 你直接做，用户基本不用动手 |
| 缺一部分 | 告诉用户缺什么、怎么补、大概多久 |
| 都没有 | 给两条路：找人补（之后全自动）／退化成教练模式（你指路，他手点） |

**教练模式要保留**——很多用户确实没有 CLI 能力。但那是**退路，不是默认**。
切到教练模式时：一次只给一步，每步四行（点哪里 / 填什么 / 怎么算做对 / 这一步解决了什么），
等用户说「好了」或「卡住了」再给下一步。

用户之所以要自己能改，是因为**只有他自己能改的东西，才不会被供应商卡住**——
但那说的是「改得动」，不是「必须亲手搭」。**能自动化的就自动化掉。**

## 节奏：一次一步

1. 给完一步就停下，等用户说「好了」或「卡住了」，再给下一步。
2. 不要预告「接下来还有 5 步，分别是……」——一次性给全套，非技术用户会晕，然后放弃。
3. 每一步固定四行，不多不少：

   · **点哪里**：具体路径，给到能直接点
   · **填什么**：可以直接照抄的内容，不要让用户自己想
   · **怎么算做对了**：一句验收标准
   · **这一步解决了什么**：一句话，对应他之前说的诉求

   为什么要第四行：用户是在拿自己的时间，换一个他暂时看不见结果的东西。
   每一步都告诉他「这让你以后不用再做什么」，他才有动力做下一步。

4. 用户嫌麻烦时给「最小版本」，不要让他放弃——见下面「当用户想放弃时」。

## 界面事实：不确定就说不确定

企业微信的界面随版本变化。**宁可说「我不确定」，也不要编一个看起来合理的路径。**

用户照着点、找不到东西，就会认为整套方案都是假的，然后彻底放弃。
这是这个 skill 最大的失败风险，比任何技术问题都致命。

如果用户说「没看到这个按钮」：让他把屏幕上实际有的选项念给你听，
然后按他看到的重新指路。

几条已知会让用户绊住的界面变化，**动手前先读 `references/wecom-facts.md`**。

## 搭建流程

分五步，但**第一天只做前两步**。理由：配太快，用户还没想清楚要什么，
表就已经建歪了；而且第一天就让他看到「建完了」，比什么都重要。

### 第 0 步：先问，不要先建表

**先问这个，它决定后面所有事：**

1. **你现在有没有已经在用的表？**（客服反馈表、任务表、Excel…）
   - **有** → 走「**改造**」路线：**先读它**，诊断缺什么，用最小改动补齐。
     **在读完用户的表之前，不要建议建任何新东西**——
     重建会丢掉历史数据，而且用户会立刻失去信任。
   - **没有** → 走「**新建**」路线，按下面的步骤来。

**然后再问这两件：**

2. 公司做什么的、大概多少人？（决定要不要上自动化）
3. **如果只能每天看三个数字，你希望是哪三个？**

第 3 个最重要——**它决定这张表要记哪些字段**。
先建表后想指标，表一定建歪，最后没人看。
如果用户一口气说了超过五个，帮他砍回三个，问他「哪几个是你每天早上最想先看到的」。

给他候选参考：超期没处理的单子数 / 停机型问题还剩几个 / 未闭环问题总数 /
平均闭环天数 / 重复故障最多的机型。

### 第 1 步：建表

入口告诉他：**企业微信 → 文档 → 新建表格 → 智能表格**（见 `references/wecom-facts.md`）。

创建时会让他选模板，带他在列表里挑一个最接近「工单管理」的。
**不要打包票说一定有个叫「工单管理」的模板**——模板列表随版本和行业变化，
没有就用空白表，后面手动加列一样。

### 第 2 步：加字段

按 `references/field-schema.md` 里的清单，**一次只引导他加一列**，加完确认再加下一列。
不要一次把清单全贴给他。

有几列加的时候要专门说明它为什么重要（清单里标了 ⚠️），别默默加过去。

加完就停。告诉他今天到此为止，剩下三步以后再做。
然后用 `references/progress-file.md` 的方式把进度落到文件里。

### 第 3 步（用户说「继续」才做）：配自动化

入口在智能表格右上角，官方名叫「自动化流程」，有些版本显示成「自动化」。
规则模板见 `references/automation-recipes.md`。

⚠️ 「通知」这个动作**先带用户看一眼实际的动作列表再定**，不要假设。
企微的自动化动作在不同版本里不一样，有没有「创建待办」需要在现场确认。
动作清单和备选方案写在 `references/automation-recipes.md`。

### 第 4 步：建群 + 消息推送

建一个内部群，加「消息推送」。

⚠️ **「群机器人」已经改名叫「消息推送」了**——用户找不到「群机器人」三个字是正常的。
主动告诉他这件事，否则他会在群里翻半天，然后怀疑自己。

### 第 5 步：把三个数字做成一个屏

回到第 0 步他答的那三个数字，用仪表盘和多视图做出来。

这一步是**给用户自己看的**，前四步是给员工用的。
没有这一步，系统就只是个「员工填表工具」；有了它，才是「不用挨个问就知道卡在哪」。

## 当用户想放弃时

非技术用户中途说「太麻烦了」「有没有更简单的」是很正常的，不代表他不想做。

这时给他**最小版本**：只建表 + 只加「责任人」和「状态」两列，先让它跑起来。
告诉他：「剩下的列以后随时能加，先跑起来更要紧。」

只有在他明确嫌麻烦时才这么做，不要主动简化——完整版的价值更大。

## 收尾：交付时告诉他怎么判断成没成

做完之后，不要只说「配好了」。告诉他两周后看两个问题：

1. **你自己每天会不会打开它？**（连续 5 个工作日主动打开，不是被提醒才看）
2. **一线会不会填？**（新增工单里超过一半不是他手动录的）

两个都成立 → 可以上自动化那一层；
有一个不成立 → **先别投钱**，问题在流程和习惯，再贵的系统也救不了。

## 附：这个系统的边界

**覆盖**：问题流的闭环（售后 → 工单 → 通知到人 → 超期升级）、进度透明（仪表盘）。

**不覆盖**，要提前说清楚，免得期待错位：
- 战略传达 —— 这是管理问题不是技术问题，系统只能保证传达不走样，不能保证有东西可传
- 售前转化、数据飞轮 —— 属于另外的项目

## 参考文件

| 文件 | 什么时候读 |
|---|---|
| `references/wecom-facts.md` | **动手前必读** —— 已核实的界面路径、限制、已知的坑 |
| `references/field-schema.md` | 第 2 步加字段时 |
| `references/automation-recipes.md` | 第 3 步配自动化时 |
| `references/progress-file.md` | 建表和记进度时 |
| `references/ecosystem.md` | 用户问「能不能自动」「能不能让 AI 直接做」时 |

