简介这份《钉钉使用手册(试运行)》以PDF形式呈现面向企业内部管理者、行政人事以及日常使用钉钉办公的全体员工帮助解决即时通讯工具在工作场景中的规范使用、考勤打卡与审批流程落地等问题。资源包仅含1个PDF文档大小约115KB轻量易读便于直接分发、打印或存档查阅目前已有410人浏览学习。手册围绕软件使用原则、考勤打卡、审批要求、日报功能及注意事项等模块展开明确了PC端安装、人脸识别300米范围内两次打卡、外出出差请假与用印审批、财务费用审批权限、日报填写要素等具体条款并对真实姓名账号、信息及时回复、DING提醒等细节作出规定。读者可据此快速建立企业内部钉钉使用规范减少沟通与考勤管理中的争议也可作为行政制度试运行阶段的参考模板与培训材料。1. 钉钉使用手册PDF落地真正难的不是装客户端一份 2018 年的内部规定把钉钉的使用拆成了五件事PC 端必须装、考勤一天两次人脸打卡、外出出差请假走审批、每天填日报、通知超时要 DING。看上去是行政文档实际是一份没有写成配置项的产品需求书。绝大多数公司拿到这种 PDF 后的做法是发群里让大家「自觉遵守」结果三个月后考勤组还是默认班次审批还是通用模板日报靠人催。真正的难点在于把「300 米范围内人脸打卡」翻译成考勤组的有效范围半径和识别方式把「抄送给集团人资」翻译成审批模板的抄送人节点把「1 小时未读用 DING」翻译成一条定时任务加一个已读查询接口。这套翻译做完规定才从纸面变成可校验的系统行为。下面按考勤、审批、消息触达、自动巡检四条线把手册逐条落到能跑起来的配置和脚本上。2. 考勤组配置与钉钉打卡接口把“300米内人脸打卡”拆成参数考勤是本手册条款最密的部分一天两次、人脸拍照、公司 300 米范围内、8:30 与 18:00、集团可查看分公司考勤。这五句话对应后台五个配置项少配一个就会出现「员工说打了卡、管理员说没记录」的扯皮。2.1 手册条款到后台配置项的映射先把条款写成表格再进管理后台逐项对齐。这样做的价值在于后续制度修订时能定位到具体字段而不是整组重配。手册条款后台配置项建议取值配置失误的后果一天打卡两次班次打卡次数与时段上班 1 次、下班 1 次员工多打或少打报表口径混乱人脸拍照打卡考勤方式中的识别方式强制人脸识别变成普通定位打卡代打风险上升公司 300 米范围内办公地点有效范围半径半径 300 米叠加 WIFI 校验范围过小导致定位漂移误判8:30 / 18:00班次上下班时间08:30–18:00按门店单独建组跨时区或跨门店共用班次迟到误报集团可查看分公司考勤管理范围与考勤报表权限集团管理员 只读子管理员权限过宽分公司数据被随意导出门店制度不一致时不要在一个考勤组里塞多个班次而是按「门店 班次」拆成独立考勤组员工按部门归属自动进组。人员调岗频繁的公司用「考勤组按部门自动同步」而不是手工加人否则每次调岗都要人工维护。2.2 人脸识别与定位校验的开启顺序顺序错了会返工。正确顺序是先建办公地点并录入经纬度、再建班次、再建考勤组把地点和班次绑定、最后把人员加进去。办公地点在地图上选点保存经纬度半径填 300同时把公司 WIFI 的 SSID 和 BSSID 一并录入作为辅助校验。班次设置上下班时间、允许迟到早退的弹性分钟数、是否需要外勤打卡。考勤组选择打卡方式为「人脸识别 定位」人脸识别要求员工首次使用时在客户端完成录入管理员可在后台查看未录入名单。人员按部门同步中高层单独建一个组方便差异化设置。注意人脸录入是客户端行为管理员无法代录。上线前一周发通知让全员先录入否则上线当天会出现大量「无法打卡」。2.3 用考勤接口核对打卡结果后台报表能看但当集团要跨分公司汇总、或者要把考勤接入自己的数据看板时就得直接调接口。企业内部应用拿到 AppKey 与 AppSecret 后先换 access_token再查打卡结果。import requests APP_KEY your_app_key APP_SECRET your_app_secret def get_token(): 换取企业内部应用的 access_token有效期两小时建议缓存复用 resp requests.get( https://oapi.dingtalk.com/gettoken, params{appkey: APP_KEY, appsecret: APP_SECRET}, timeout10, ) data resp.json() if data.get(errcode) ! 0: raise RuntimeError(f获取 token 失败: {data}) return data[access_token] def attendance_list(token, userids, work_date): 查询指定日期范围内的打卡记录 resp requests.post( https://oapi.dingtalk.com/attendance/list, params{access_token: token}, json{ workDateFrom: f{work_date} 00:00:00, workDateTo: f{work_date} 23:59:59, userIdList: userids, # 一次最多 50 个 userId offset: 0, limit: 50, }, timeout10, ) return resp.json().get(recordresult, [])userid_list单次上限 50人数多时按批切分workDateFrom与workDateTo的跨度通常限制在 7 天以内做月度汇总要按周循环。返回值里几个关键字段需要重点看checkType区分上班卡与下班卡userCheckTime是毫秒时间戳需要除以 1000 再转本地时间locationResult为Outside表示超出办公地点范围Normal表示正常deviceId可用于识别设备频繁更换的情况。考勤报表里 deviceId 一天内跳变多次、locationResult 反复异常的账号管理员按流程核实即可不必在脚本里做推断。2.4 最容易踩的三个坑第一个是时间戳。接口返回的是毫秒直接当秒用会得到 1970 年的日期格式化前先除以 1000。第二个是定位漂移300 米范围在写字楼密集区会误判建议同时开启 WIFI 校验只要连上公司 WIFI 就算有效打卡。第三个是跨天班次夜班下班卡落在次日凌晨时查询日期要往前多取一天否则夜班记录永远查不全。3. 审批流建模外出、用印、费用三类模板的字段与抄送设计手册里的审批条款写得很具体外出出差请假由谁发起、审批人是谁、抄送给谁用印要保留电子版截图费用审批按权限矩阵走审批人不确定可以拒绝并转交。这些内容直接对应审批模板的控件、审批人节点和抄送人节点。模板设计的第一原则是写角色不写人名。3.1 三类审批场景的字段设计场景核心控件审批人节点抄送人留档要求外出 / 出差 / 请假外出类型、起止时间、事由、附件直属主管 → 分公司负责人集团人资起止时间必填禁止当天事后补用印申请文件名称、用印类型、份数、电子件附件分公司负责人 → 集团行政集团行政负责人必须上传电子版截图费用报销费用类型、金额、发票附件、成本归属按金额走审批权限矩阵集团财务超权限自动加签审批人和抄送人一律绑角色如「直属主管」「集团人资」「集团财务」人员变动时只在通讯录里调整角色归属模板不用动。绑人名是审批流最常见的返工来源一个人离职就要重发几十个模板。3.2 模板里几个必须打开的开关条件分支用来处理费用审批的金额阈值低于 5000 走分公司负责人高于 5000 自动加签集团财务。审批人去重避免同一个人既是一级审批人又是二级审批人时重复审批。审批人空缺自动转交保证主管请假时流程不卡死。审批意见必填和手写签名用于追责场景手册里「未经审批先执行造成损失由当事人承担」这句靠的就是审批单上的意见与时间戳作为证据。抄送人可见范围要放开到全部抄送节点否则跨部门抄送看不到内容。另外建议加一个隐藏字段「是否事后补录」用于统计先执行后补单的比例。这类字段不会出现在审批页面上但能在数据里暴露管理漏洞。3.3 用接口批量发起与校验审批实例用印、出差这类重复性高的单据可以用接口批量发起也可以在测试环境验证模板是否配好。def create_process_instance(token, process_code, originator, dept_id, values): 按模板发起一条审批实例 resp requests.post( https://oapi.dingtalk.com/topapi/processinstance/create, params{access_token: token}, json{ process_code: process_code, # 审批模板的唯一编码 originator_user_id: originator, # 发起人 userId dept_id: dept_id, # 发起人所在部门 ID form_component_values: values, # 控件名必须与模板完全一致 }, timeout10, ) data resp.json() if data.get(errcode) ! 0: raise RuntimeError(f发起失败: {data}) return data[process_instance][id]values [ {name: 外出类型, value: 出差}, {name: 开始时间, value: 2024-05-06 09:00}, {name: 结束时间, value: 2024-05-08 18:00}, {name: 事由, value: 客户现场支持}, ]form_component_values里的name必须和模板控件名逐字一致多一个空格、改一个字都会报控件不存在这也是模板改名后接口批量失败的头号原因。时间类控件传字符串格式的时间不要传时间戳。dept_id影响审批流的条件分支判断传错部门会出现该加签的没加签。提示模板上线前先用测试账号跑通三条链路——金额低于阈值、金额高于阈值、审批人请假自动转交这三条走通再全量开放。3.4 审批流常见的四个问题抄送人不是审批人不参与流转很多人误以为抄送了就等于对方审批过结果单据积压在抄送人手里。审批人层级超过四级时卡单概率明显上升每多一级审批平均增加半天流转时间能用条件分支并行就不要串行。用印电子版截图的保存期限要提前确认附件随审批单一起存在系统里单据被删除时附件也会消失重要用印文件应另行归档。最后是时间边界出差审批的结束时间要覆盖返程日期否则会出现出差期间打卡不在范围内的判定冲突。4. 日报、DING 与已读追踪把“1小时未读就DING”写成定时任务消息触达是手册里最少被当回事、实际最容易出问题的一块。条款写得很清楚通知发布人备注无需回复、跟进阅读进度、工作时间内超过 1 小时、非工作时间超过 4 小时未读则 DING。这三句话拆开就是三件技术活消息类型要区分工作通知和 DING、已读状态要能查询、超时判断要落到定时任务。4.1 日报模板的字段与统计口径日报的价值不在填写在于字段结构固定后能统计。手册里提到的四个字段可以直接建成模板。字段类型校验规则统计用途今日完成工作多行文本必填不少于 20 字工作量趋势未完成工作多行文本选填阻塞项识别需协调工作多行文本选填可 同事跨部门协作统计备注次日计划多行文本必填计划完成率未提交名单不走人工催收用日报统计报表按周导出部门维度数据把「未提交天数」作为负激励的量化依据比口头提醒有说服力。4.2 工作通知与 DING 的差异工作通知是应用消息走到员工的消息列表里不打断当前操作。DING 是强提醒可以在应用内、短信、电话三种通道里选。手册里那条「以通知形式发布的信息备注无需回复」对应的就是工作通知而超时未读的升级动作才是 DING。把这两者搞混要么全员被 DING 打扰要么重要通知被淹没。发工作通知后返回一个task_id用它查已读状态。def send_work_notice(token, agent_id, userids, text): 发送工作通知返回 task_id 用于后续查询已读 resp requests.post( https://oapi.dingtalk.com/topapi/message/corpconversation/asyncsend_v2, params{access_token: token}, json{ agent_id: agent_id, # 企业内部应用的 AgentId userid_list: ,.join(userids), # 最多 100 个 userId msg: {msgtype: text, text: {content: text}}, }, timeout10, ) data resp.json() if data.get(errcode) ! 0: raise RuntimeError(f发送失败: {data}) return data[task_id] def read_status(token, agent_id, task_id): 查询已读、未读、失败人员数量 resp requests.post( https://oapi.dingtalk.com/topapi/message/corpconversation/getsendresult, params{access_token: token}, json{agent_id: agent_id, task_id: task_id}, timeout10, ) return resp.json()[send_result]send_result里三个字段决定后续动作read_count已读人数、unread_count未读人数、failed_user_id_list发送失败的人。发送失败通常是账号停用或不属于该应用可见范围这类人要单独处理不能算作未读。4.3 超时升级的定时任务骨架把每次工作通知的task_id、发送时间、接收人列表落到本地表里定时任务按间隔轮询。import sqlite3, time def poll_and_escalate(token, agent_id, work_hoursTrue): 每 10 分钟跑一次工作时间内超过 1 小时未读则触发 DING threshold 3600 if work_hours else 4 * 3600 now int(time.time()) conn sqlite3.connect(notice.db) rows conn.execute( SELECT task_id, agent_id, send_ts, userids FROM notices WHERE escalated 0 ).fetchall() for task_id, agent_id, send_ts, userids in rows: if now - send_ts threshold: continue result read_status(token, agent_id, task_id) if result.get(unread_count, 0) 0: print(ftask {task_id} 超时未读 {result[unread_count]} 人触发 DING) # 此处调用 DING 接口仅对未读人员发送 conn.execute(UPDATE notices SET escalated 1 WHERE task_id ?, (task_id,)) conn.commit()判断阈值按工作时间和非工作时间两套参数走用work_hours开关切换。注意只对未读人员发 DING不要把已读的人也拉进来否则通知的严肃性会迅速下降。4.4 参数与限制工作通知单次最多 100 人超过要分批。DING 的短信和电话通道有配额通常按组织规模分配用之前先确认余量配额耗尽后 DING 会静默降级为应用内提醒。已读查询只对工作通知有效群消息不返回已读明细这点和手册里「群成员收到指令后回复收到」的条款有冲突实操中要么改成工作通知下发、要么在群里用机器人统计回复。另外注意消息频率短时间内高频发送会被限流定时任务的轮询间隔不要低于 1 分钟。5. 手册巡检脚本pdfplumber 抽条款 考勤异常日检制度类 PDF 的共同问题是修订频繁、条款编号不统一人工核对配置项容易漏。把手册正文抽成结构化文本再和实际配置做比对能省掉大部分重复劳动。5.1 用 pdfplumber 抽取条款编号与正文import re, pdfplumber def extract_clauses(pdf_path): 按中文序号切分条款输出 {条款号: 正文} clauses {} pattern re.compile(r^[一二三四五六七八九十]、(.)$) with pdfplumber.open(pdf_path) as pdf: text \n.join((page.extract_text() or ) for page in pdf.pages) current None for line in text.splitlines(): line line.strip() m pattern.match(line) if m: current m.group(1) clauses[current] elif current: clauses[current] line return clausesextract_text()对纯文本型 PDF 效果好扫描件需要先做 OCR否则返回空字符串。条款号的正则只匹配「一、二、三」这种中文序号如果手册改用「1.1」阿拉伯数字编号正则要同步调整否则整篇抽不出结构。5.2 考勤异常日检清单抽出来的条款解决「制度写了什么」异常日检解决「执行成什么样」。把两者的核对项固化成一张表每天跑一次。异常类型判定条件处理动作缺卡当日 checkType 少于两次通知本人补卡申请范围外打卡locationResult 为 Outside核对出差审批单设备异常同日 deviceId 数量大于 2转人工核实未录人脸名单中存在未录入人员提醒客户端录入审批缺位有外出打卡无对应审批单通知补单并记录判定逻辑直接复用第 2 章的attendance_list把当天记录按userid分组逐条走上面的条件。跑通之后接一个机器人把异常摘要推到管理群比每天手工导报表省事得多。巡检脚本建议留一份运行日志一旦某天接口返回空列表先看是权限掉了还是日期格式写错这两类问题占了排查时间的大头。本文还有配套的精品资源点击获取 钉钉使用手册落地：考勤、审批、DING与巡检自动化
简介这份《钉钉使用手册(试运行)》以PDF形式呈现面向企业内部管理者、行政人事以及日常使用钉钉办公的全体员工帮助解决即时通讯工具在工作场景中的规范使用、考勤打卡与审批流程落地等问题。资源包仅含1个PDF文档大小约115KB轻量易读便于直接分发、打印或存档查阅目前已有410人浏览学习。手册围绕软件使用原则、考勤打卡、审批要求、日报功能及注意事项等模块展开明确了PC端安装、人脸识别300米范围内两次打卡、外出出差请假与用印审批、财务费用审批权限、日报填写要素等具体条款并对真实姓名账号、信息及时回复、DING提醒等细节作出规定。读者可据此快速建立企业内部钉钉使用规范减少沟通与考勤管理中的争议也可作为行政制度试运行阶段的参考模板与培训材料。1. 钉钉使用手册PDF落地真正难的不是装客户端一份 2018 年的内部规定把钉钉的使用拆成了五件事PC 端必须装、考勤一天两次人脸打卡、外出出差请假走审批、每天填日报、通知超时要 DING。看上去是行政文档实际是一份没有写成配置项的产品需求书。绝大多数公司拿到这种 PDF 后的做法是发群里让大家「自觉遵守」结果三个月后考勤组还是默认班次审批还是通用模板日报靠人催。真正的难点在于把「300 米范围内人脸打卡」翻译成考勤组的有效范围半径和识别方式把「抄送给集团人资」翻译成审批模板的抄送人节点把「1 小时未读用 DING」翻译成一条定时任务加一个已读查询接口。这套翻译做完规定才从纸面变成可校验的系统行为。下面按考勤、审批、消息触达、自动巡检四条线把手册逐条落到能跑起来的配置和脚本上。2. 考勤组配置与钉钉打卡接口把“300米内人脸打卡”拆成参数考勤是本手册条款最密的部分一天两次、人脸拍照、公司 300 米范围内、8:30 与 18:00、集团可查看分公司考勤。这五句话对应后台五个配置项少配一个就会出现「员工说打了卡、管理员说没记录」的扯皮。2.1 手册条款到后台配置项的映射先把条款写成表格再进管理后台逐项对齐。这样做的价值在于后续制度修订时能定位到具体字段而不是整组重配。手册条款后台配置项建议取值配置失误的后果一天打卡两次班次打卡次数与时段上班 1 次、下班 1 次员工多打或少打报表口径混乱人脸拍照打卡考勤方式中的识别方式强制人脸识别变成普通定位打卡代打风险上升公司 300 米范围内办公地点有效范围半径半径 300 米叠加 WIFI 校验范围过小导致定位漂移误判8:30 / 18:00班次上下班时间08:30–18:00按门店单独建组跨时区或跨门店共用班次迟到误报集团可查看分公司考勤管理范围与考勤报表权限集团管理员 只读子管理员权限过宽分公司数据被随意导出门店制度不一致时不要在一个考勤组里塞多个班次而是按「门店 班次」拆成独立考勤组员工按部门归属自动进组。人员调岗频繁的公司用「考勤组按部门自动同步」而不是手工加人否则每次调岗都要人工维护。2.2 人脸识别与定位校验的开启顺序顺序错了会返工。正确顺序是先建办公地点并录入经纬度、再建班次、再建考勤组把地点和班次绑定、最后把人员加进去。办公地点在地图上选点保存经纬度半径填 300同时把公司 WIFI 的 SSID 和 BSSID 一并录入作为辅助校验。班次设置上下班时间、允许迟到早退的弹性分钟数、是否需要外勤打卡。考勤组选择打卡方式为「人脸识别 定位」人脸识别要求员工首次使用时在客户端完成录入管理员可在后台查看未录入名单。人员按部门同步中高层单独建一个组方便差异化设置。注意人脸录入是客户端行为管理员无法代录。上线前一周发通知让全员先录入否则上线当天会出现大量「无法打卡」。2.3 用考勤接口核对打卡结果后台报表能看但当集团要跨分公司汇总、或者要把考勤接入自己的数据看板时就得直接调接口。企业内部应用拿到 AppKey 与 AppSecret 后先换 access_token再查打卡结果。import requests APP_KEY your_app_key APP_SECRET your_app_secret def get_token(): 换取企业内部应用的 access_token有效期两小时建议缓存复用 resp requests.get( https://oapi.dingtalk.com/gettoken, params{appkey: APP_KEY, appsecret: APP_SECRET}, timeout10, ) data resp.json() if data.get(errcode) ! 0: raise RuntimeError(f获取 token 失败: {data}) return data[access_token] def attendance_list(token, userids, work_date): 查询指定日期范围内的打卡记录 resp requests.post( https://oapi.dingtalk.com/attendance/list, params{access_token: token}, json{ workDateFrom: f{work_date} 00:00:00, workDateTo: f{work_date} 23:59:59, userIdList: userids, # 一次最多 50 个 userId offset: 0, limit: 50, }, timeout10, ) return resp.json().get(recordresult, [])userid_list单次上限 50人数多时按批切分workDateFrom与workDateTo的跨度通常限制在 7 天以内做月度汇总要按周循环。返回值里几个关键字段需要重点看checkType区分上班卡与下班卡userCheckTime是毫秒时间戳需要除以 1000 再转本地时间locationResult为Outside表示超出办公地点范围Normal表示正常deviceId可用于识别设备频繁更换的情况。考勤报表里 deviceId 一天内跳变多次、locationResult 反复异常的账号管理员按流程核实即可不必在脚本里做推断。2.4 最容易踩的三个坑第一个是时间戳。接口返回的是毫秒直接当秒用会得到 1970 年的日期格式化前先除以 1000。第二个是定位漂移300 米范围在写字楼密集区会误判建议同时开启 WIFI 校验只要连上公司 WIFI 就算有效打卡。第三个是跨天班次夜班下班卡落在次日凌晨时查询日期要往前多取一天否则夜班记录永远查不全。3. 审批流建模外出、用印、费用三类模板的字段与抄送设计手册里的审批条款写得很具体外出出差请假由谁发起、审批人是谁、抄送给谁用印要保留电子版截图费用审批按权限矩阵走审批人不确定可以拒绝并转交。这些内容直接对应审批模板的控件、审批人节点和抄送人节点。模板设计的第一原则是写角色不写人名。3.1 三类审批场景的字段设计场景核心控件审批人节点抄送人留档要求外出 / 出差 / 请假外出类型、起止时间、事由、附件直属主管 → 分公司负责人集团人资起止时间必填禁止当天事后补用印申请文件名称、用印类型、份数、电子件附件分公司负责人 → 集团行政集团行政负责人必须上传电子版截图费用报销费用类型、金额、发票附件、成本归属按金额走审批权限矩阵集团财务超权限自动加签审批人和抄送人一律绑角色如「直属主管」「集团人资」「集团财务」人员变动时只在通讯录里调整角色归属模板不用动。绑人名是审批流最常见的返工来源一个人离职就要重发几十个模板。3.2 模板里几个必须打开的开关条件分支用来处理费用审批的金额阈值低于 5000 走分公司负责人高于 5000 自动加签集团财务。审批人去重避免同一个人既是一级审批人又是二级审批人时重复审批。审批人空缺自动转交保证主管请假时流程不卡死。审批意见必填和手写签名用于追责场景手册里「未经审批先执行造成损失由当事人承担」这句靠的就是审批单上的意见与时间戳作为证据。抄送人可见范围要放开到全部抄送节点否则跨部门抄送看不到内容。另外建议加一个隐藏字段「是否事后补录」用于统计先执行后补单的比例。这类字段不会出现在审批页面上但能在数据里暴露管理漏洞。3.3 用接口批量发起与校验审批实例用印、出差这类重复性高的单据可以用接口批量发起也可以在测试环境验证模板是否配好。def create_process_instance(token, process_code, originator, dept_id, values): 按模板发起一条审批实例 resp requests.post( https://oapi.dingtalk.com/topapi/processinstance/create, params{access_token: token}, json{ process_code: process_code, # 审批模板的唯一编码 originator_user_id: originator, # 发起人 userId dept_id: dept_id, # 发起人所在部门 ID form_component_values: values, # 控件名必须与模板完全一致 }, timeout10, ) data resp.json() if data.get(errcode) ! 0: raise RuntimeError(f发起失败: {data}) return data[process_instance][id]values [ {name: 外出类型, value: 出差}, {name: 开始时间, value: 2024-05-06 09:00}, {name: 结束时间, value: 2024-05-08 18:00}, {name: 事由, value: 客户现场支持}, ]form_component_values里的name必须和模板控件名逐字一致多一个空格、改一个字都会报控件不存在这也是模板改名后接口批量失败的头号原因。时间类控件传字符串格式的时间不要传时间戳。dept_id影响审批流的条件分支判断传错部门会出现该加签的没加签。提示模板上线前先用测试账号跑通三条链路——金额低于阈值、金额高于阈值、审批人请假自动转交这三条走通再全量开放。3.4 审批流常见的四个问题抄送人不是审批人不参与流转很多人误以为抄送了就等于对方审批过结果单据积压在抄送人手里。审批人层级超过四级时卡单概率明显上升每多一级审批平均增加半天流转时间能用条件分支并行就不要串行。用印电子版截图的保存期限要提前确认附件随审批单一起存在系统里单据被删除时附件也会消失重要用印文件应另行归档。最后是时间边界出差审批的结束时间要覆盖返程日期否则会出现出差期间打卡不在范围内的判定冲突。4. 日报、DING 与已读追踪把“1小时未读就DING”写成定时任务消息触达是手册里最少被当回事、实际最容易出问题的一块。条款写得很清楚通知发布人备注无需回复、跟进阅读进度、工作时间内超过 1 小时、非工作时间超过 4 小时未读则 DING。这三句话拆开就是三件技术活消息类型要区分工作通知和 DING、已读状态要能查询、超时判断要落到定时任务。4.1 日报模板的字段与统计口径日报的价值不在填写在于字段结构固定后能统计。手册里提到的四个字段可以直接建成模板。字段类型校验规则统计用途今日完成工作多行文本必填不少于 20 字工作量趋势未完成工作多行文本选填阻塞项识别需协调工作多行文本选填可 同事跨部门协作统计备注次日计划多行文本必填计划完成率未提交名单不走人工催收用日报统计报表按周导出部门维度数据把「未提交天数」作为负激励的量化依据比口头提醒有说服力。4.2 工作通知与 DING 的差异工作通知是应用消息走到员工的消息列表里不打断当前操作。DING 是强提醒可以在应用内、短信、电话三种通道里选。手册里那条「以通知形式发布的信息备注无需回复」对应的就是工作通知而超时未读的升级动作才是 DING。把这两者搞混要么全员被 DING 打扰要么重要通知被淹没。发工作通知后返回一个task_id用它查已读状态。def send_work_notice(token, agent_id, userids, text): 发送工作通知返回 task_id 用于后续查询已读 resp requests.post( https://oapi.dingtalk.com/topapi/message/corpconversation/asyncsend_v2, params{access_token: token}, json{ agent_id: agent_id, # 企业内部应用的 AgentId userid_list: ,.join(userids), # 最多 100 个 userId msg: {msgtype: text, text: {content: text}}, }, timeout10, ) data resp.json() if data.get(errcode) ! 0: raise RuntimeError(f发送失败: {data}) return data[task_id] def read_status(token, agent_id, task_id): 查询已读、未读、失败人员数量 resp requests.post( https://oapi.dingtalk.com/topapi/message/corpconversation/getsendresult, params{access_token: token}, json{agent_id: agent_id, task_id: task_id}, timeout10, ) return resp.json()[send_result]send_result里三个字段决定后续动作read_count已读人数、unread_count未读人数、failed_user_id_list发送失败的人。发送失败通常是账号停用或不属于该应用可见范围这类人要单独处理不能算作未读。4.3 超时升级的定时任务骨架把每次工作通知的task_id、发送时间、接收人列表落到本地表里定时任务按间隔轮询。import sqlite3, time def poll_and_escalate(token, agent_id, work_hoursTrue): 每 10 分钟跑一次工作时间内超过 1 小时未读则触发 DING threshold 3600 if work_hours else 4 * 3600 now int(time.time()) conn sqlite3.connect(notice.db) rows conn.execute( SELECT task_id, agent_id, send_ts, userids FROM notices WHERE escalated 0 ).fetchall() for task_id, agent_id, send_ts, userids in rows: if now - send_ts threshold: continue result read_status(token, agent_id, task_id) if result.get(unread_count, 0) 0: print(ftask {task_id} 超时未读 {result[unread_count]} 人触发 DING) # 此处调用 DING 接口仅对未读人员发送 conn.execute(UPDATE notices SET escalated 1 WHERE task_id ?, (task_id,)) conn.commit()判断阈值按工作时间和非工作时间两套参数走用work_hours开关切换。注意只对未读人员发 DING不要把已读的人也拉进来否则通知的严肃性会迅速下降。4.4 参数与限制工作通知单次最多 100 人超过要分批。DING 的短信和电话通道有配额通常按组织规模分配用之前先确认余量配额耗尽后 DING 会静默降级为应用内提醒。已读查询只对工作通知有效群消息不返回已读明细这点和手册里「群成员收到指令后回复收到」的条款有冲突实操中要么改成工作通知下发、要么在群里用机器人统计回复。另外注意消息频率短时间内高频发送会被限流定时任务的轮询间隔不要低于 1 分钟。5. 手册巡检脚本pdfplumber 抽条款 考勤异常日检制度类 PDF 的共同问题是修订频繁、条款编号不统一人工核对配置项容易漏。把手册正文抽成结构化文本再和实际配置做比对能省掉大部分重复劳动。5.1 用 pdfplumber 抽取条款编号与正文import re, pdfplumber def extract_clauses(pdf_path): 按中文序号切分条款输出 {条款号: 正文} clauses {} pattern re.compile(r^[一二三四五六七八九十]、(.)$) with pdfplumber.open(pdf_path) as pdf: text \n.join((page.extract_text() or ) for page in pdf.pages) current None for line in text.splitlines(): line line.strip() m pattern.match(line) if m: current m.group(1) clauses[current] elif current: clauses[current] line return clausesextract_text()对纯文本型 PDF 效果好扫描件需要先做 OCR否则返回空字符串。条款号的正则只匹配「一、二、三」这种中文序号如果手册改用「1.1」阿拉伯数字编号正则要同步调整否则整篇抽不出结构。5.2 考勤异常日检清单抽出来的条款解决「制度写了什么」异常日检解决「执行成什么样」。把两者的核对项固化成一张表每天跑一次。异常类型判定条件处理动作缺卡当日 checkType 少于两次通知本人补卡申请范围外打卡locationResult 为 Outside核对出差审批单设备异常同日 deviceId 数量大于 2转人工核实未录人脸名单中存在未录入人员提醒客户端录入审批缺位有外出打卡无对应审批单通知补单并记录判定逻辑直接复用第 2 章的attendance_list把当天记录按userid分组逐条走上面的条件。跑通之后接一个机器人把异常摘要推到管理群比每天手工导报表省事得多。巡检脚本建议留一份运行日志一旦某天接口返回空列表先看是权限掉了还是日期格式写错这两类问题占了排查时间的大头。本文还有配套的精品资源点击获取