crm-visit-sync

name	crm-visit-sync
description	搬运式跟进记录同步工具。将 iWiki 文档 / 腾讯文档 / 企微文档 / 用户直接粘贴文本（结构化纪要/对话流/纯文本）/ 企微聊天合并转发 / 图片（拜访纪要截图、聊天记录截图、手写纪要照片等） 中已写好的或描述的跟进记录（拜访纪要、跟进进展）内容，搬运录入到腾讯云磐石 CRM 的跟进数据中。当用户提供 iWiki / 腾讯文档 / 企微文档 链接（或粘贴文本、直接描述、把与客户的聊天合并转发给企微号助手、发送跟进记录截图/照片）并要求「把跟进记录传到磐石」「同步到磐石跟进数据」「录入磐石跟进记录」「搬运拜访纪要到磐石」「把聊天记录/这段描述/这张截图整理成跟进记录」时，应使用本技能。本期仅支持销售（Sales）和售前架构师（Owner）两种角色，仅允许同步 15 天内的跟进记录。分支 A（文档类）字段值须来自源文档原文（原文摘取，禁 AI 加工）；分支 B（对话流/纯文本/图片）允许对沟通进展/下一步计划做忠于输入的总结提炼（图片先多模态识别再清洗），其余字段仍须取自输入，读不到即留空，严禁编造。写入时无法从输入确认的必填字段逐一向用户确认（必填优先，跟进人/创建时间自动生成）。全流程仅两次强制确认：① 跟进对象实体；② 拜访对象职位 + 关联打卡 + 全字段预览（一次性确认并提交）。
agent_created	true
disable	true

CRM 跟进记录搬运同步（crm-visit-sync）

Overview（定位）

本技能把 iWiki 文档 / 腾讯文档 / 企微文档 / 用户直接粘贴的文本（结构化纪要/对话流/纯文本）/ 企微聊天合并转发 / 图片（截图/照片） 中已写好的或描述的跟进记录（拜访纪要、跟进进展）， 搬运录入到腾讯云磐石 CRM 的跟进数据库（customer_visit 主表及其子表）。分支 A（文档类）字段值须来自源文档原文（原文摘取）；分支 B（对话流/纯文本/图片）允许对沟通进展/下一步计划做忠于输入的总结提炼（图片先多模态识别再清洗），其余字段仍须取自输入，读不到即留空，严禁编造。

企微聊天合并转发（chat_forward）/ 纯文本（分支 B）场景：用户把与客户的企微聊天合并转发给企微号助手，或直接输入一段自由叙述的纯文本（如"今天去 XX 客户聊了方案"），skill 从中识别/总结对象、时间、方式、拜访对象、沟通内容，生成跟进记录。此类输入无结构化字段，解析/总结规则见 shared/STEPS.md 1.3 分支 B（沟通内容/下一步计划在分支 B 允许总结提炼，区别于分支 A 的原文摘取）。

保底机制（必填字段兜底）：写入时，凡是无法仅从用户输入确认的字段，都在提交前逐一向用户确认、优先确认表单必填字段；跟进人（=当前用户）与创建时间（=系统时间）由系统自动生成、不询问。详见 shared/STEPS.md「必填字段保底确认」。

与「crm-create-visit-skill（AI 对话式创建）」的本质区别：

维度	crm-create-visit-skill（对话式）	本技能 crm-visit-sync（搬运式）
内容来源	用户口述、AI 提取润色	iWiki/腾讯文档已有纪要，分支A原文摘取；分支B对话流/图片总结提炼
AI 是否加工内容	会提取、归纳、润色	分支A严禁总结/生成/补写/改写；分支B仅对沟通进展/计划允许忠于输入的总结提炼
字段缺失处理	AI 追问、引导补齐	留空并如实提示，绝不编造
典型触发	「帮我记一条今天拜访 XX 的跟进」	「把这个 iWiki 链接里的跟进记录传到磐石」

底层接口、角色鉴权、字段矩阵、枚举口径 复用 磐石现网规则（见 shared/）。

⛔ 八条铁律（最高优先级，任何步骤不得违反）

1. 禁止幻觉：所有写入磐石的字段值，必须能在源文档中逐字对应到出处。读不到就留空，绝不凭印象、常识或上下文推测编造任何人名、时间、地点、结论、进展、计划。

2. 分支加工限定：分支 A（文档类）禁止 AI 加工，只做结构化抽取 + 原文摘取；分支 B（对话流/纯文本）仅允许对沟通进展/下一步计划做忠于输入的总结提炼，其余字段仍须取自输入、不得生成。

3. 角色限定：本期只处理 Sales（销售） 和 Owner（国内售前架构师）。角色经 get_user_info(showDetail=true) 读 detail.roles[] 判定（销售族 sales*→Sales / 售前架构师族 architect*→Owner，一步直映射）。判定结果非 Sales/Owner 时按两种场景终止：roles 非空但不含 sales*/architect*（产研架构师、分包、POC、VP、海外角色等）→ 输出「本次版本仅支持销售和售前架构师，您的角色为 {finalRole}，暂不支持」；roles 为空（rare 兜底）→ 输出「当前用户为 {rtx}（{中文名}），但系统返回的角色标签为空（roles: []），无法判定您属于销售 (Sales) 还是售前架构师 (Owner)。本次版本仅支持销售和售前架构师使用。」并终止。

4. 15 天时间闸：跟进时间（visit_time）距今 超过 15 天 的记录，一律拒绝同步，明确提示原因。无法从源文确定跟进时间时，必须让用户补充确认，不得默认当前时间。

5. 仅两次强制确认（其余全自动）：全程用户只需确认两次——① 跟进对象实体（类型 + 客户全称+CID / 商机全称+项目编号，含候选改选）；② 关联打卡 + 全字段预览，在最后一步一次性确认并据此提交（拜访(10000) 额外在此步补全拜访对象真实姓名 + 职位枚举；跟进进展(10002) 无拜访对象字段）。时间、地点、跟进方式均不单独确认，由 AI 从源文提取/判定后在最后预览中整体展示供核对。

6. 对象名必须走磐石搜索：源文里的对象名不一定等于磐石对象名。必须用源文对象名 模糊搜索磐石，把候选列给用户选，严禁直接把源文对象名当作磐石对象提交。

7. 对象必须在当前用户名下（权限一致性校验）：识别并定位到的客户/商机，必须经过"是否在你名下"的校验——客户用 GetCustomerListForVisitForMcp，type:[1]（我相关）或 type:[2]（长尾）命中均可落定（方案B：长尾直接允许，不额外校验权限）；商机用 ltc.project/list 校验返回的 businessManager(主销售)/architect(架构师)/projectMembers[].rtx(项目成员)三处之一是你即算在名下。校验不通过一律不提交，先提示"该对象不在您名下"，再列出你名下相近对象让你重选。

8. 打卡只能关联、不能伪造：跟进记录的签到打卡，只能通过 csm/GetVisitCheckInsListForMcp 查询用户名下已有打卡记录后关联；严禁调用 AddCustomerVisitCheckIns 创建打卡，严禁自行编造、推断或留空 visit_check_ins_id 冒充打卡。无可用打卡时，按 shouldShowSignIn 引导用户去磐石小程序补打卡或改判为「跟进进展」，绝不提交空值或假值打卡。

⛔ Anti-patterns（常见跑偏，必须避免）

• ❌ 跳过 Step 0 身份/权限自检直接拉数据（违反权限自检要求）
• ❌ 把正文「客户：西瓜」当跟进对象去搜索（应是拜访对象，公司名/项目名才是跟进对象）
• ❌ 直接把源文对象名当磐石对象提交（必须先搜 cid 校验名下，长尾 type:[2] 命中也可落定）
• ❌ 没拿到 cid 就把客户名当 cid 传给 AddCustomerVisitForMcp
• ❌ 调用 AddCustomerVisitCheckIns 伪造打卡（=幻觉，违反铁律 #8）
• ❌ 提交体传 null 或无关字段（触发伪权限错 2022；去 null 重试，仍报才走 ask_user_authority）
• ❌ Permission Denied 时只说"无权限"不给申请路径（违反友好引导，必须调 ask_user_authority）
• ❌ 在 SKILL.md / shared 写 panshi URL / token / api_key（安全约束）
• ❌ 把聊天里的群昵称/微信昵称直接当真实姓名落库（拜访方式下拜访对象强制真实姓名，禁占位；进展不收集拜访对象）
• ❌ 把对话里出现的"人名"当跟进对象实体（人名是拜访对象，公司名/项目名才是对象）
• ❌ 凭聊天相对时间（今天/昨天/上周/上午/下午）不二次确认就直接填 visit_time（模糊时间必须追问精确到天/时/分）
• ❌ 分支 A（文档类）对沟通内容/下一步计划做总结生成（分支 A 应原文摘取，禁 AI 加工）
• ❌ 分支 B（对话流/纯文本/图片）不敢总结、只摘单句导致沟通内容残缺（应基于输入归纳核心要点，但忠于事实、禁编造）
• ❌ 把"无法从输入确认的必填字段"留空提交或 AI 擅自填值（须走「必填字段保底确认」逐一问用户；自动字段仅跟进人/创建时间）
• ❌ 把职位菜单序号数字（如 19/20）直接写进 contact_info[].position（序号仅为交互，入库必须还原成枚举文字如「市场负责人」；实测后台已出现 position=「19」「20」）

门控流程总览（Gate 0 → Gate 5）

对用户只呈现 2 次确认（跟进对象实体 / 职位+打卡+预览），其余步骤静默自动完成。

Gate 0  静默加载规则          读取本 SKILL.md + shared，初始化 SYNC_STATE
Gate 1  静默读取来源          解析 iWiki/腾讯文档/企微文档链接、粘贴文本（结构化纪要/对话流/纯文本）、企微聊天合并转发（chat_forward）或图片（截图/照片，多模态识别）→ 抽取/总结每条原始字段（含标题供对象识别），回显识别结果但不阻塞
Gate 2  静默角色鉴权          get_user_info(showDetail=true) → 读 detail.roles[] 直映射 finalRole → 校验 Sales/Owner
Gate 3  静默抽取（核心）      对每条记录依次：
                              ① 15 天时间闸校验
                              ② 对象类型+实体名（**标题优先判定**客户/商机；正文"客户：XXX"是拜访对象不是跟进对象）不单独确认
                              ③ 对象定位 + 名下一致性校验（客户 type:[1] 或 type:[2] 命中均可落定 / 商机搜负责人），候选暂存不阻塞
                              ④ 时间提取（YYYY-MM-DD HH:mm:ss 单一时刻；**模糊时间须二次确认精确到天/时/分**）
                              ⑤ 地点提取
                              ⑥ 跟进方式（AI 按是否有线下会面信号自动判定 拜访10000/进展10002，不单独确认）
                              ⑦ 拜访对象提取 + 职位自动映射（**仅 type=10000 拜访执行；进展 10002 跳过不收集**；源文有职位直接映射；无则标记 pending 留待确认2给菜单；姓名禁占位）
                              ⑦-C 腾讯参与人/协同跟进人：从正文提取我方（腾讯）参与人，拆分为「当前用户=跟进人（不重复入协同）」与「其他腾讯人员→collaborators[]（协同跟进人）」；tx_participants 原文照搬全部腾讯参与人
                              3.5 静默查询可关联打卡（GetVisitCheckInsListForMcp，最近15天；⚠️后端不过滤已关联，skill 须客户端过滤 is_bind_visit=0；**拜访10000无论角色必填、进展10002无论角色显示但非必填**），候选暂存
=========== 确认 1（唯一组装前闸门）：跟进对象实体 ===========
        回显「类型 + 全称 + CID/项目编号」，并列出候选（文档名搜 + 用户名下模糊搜合并）供**回复序号**改选；用户回复选中后才继续
=========== 确认 2（最终预览+提交，职位与打卡一次确认）===========
        回显全字段预览 + 拜访对象职位（**仅 type=10000 拜访显示**；pending 项给编号菜单，回复序号选，🔴 序号选后须还原成枚举文字再入库、严禁写序号数字；姓名禁占位）+ 协同跟进人（其他腾讯人员，可核对/改 RTX）+ 关联打卡候选（或"无匹配"）；
        用户在此一步**回复**补全职位、选择打卡、确认无误 → 回复"提交"落库

概念约定：本技能里「商机」即「项目」，二者同义；识别为商机时定位到的是「项目编号」（商机 id）。「线索」类跟进对象本期不支持。

SYNC_STATE（执行状态对象，全程维护）

每条待搬运记录维护一个状态，多条时用数组。禁止跳步。

{
  "user": { "rtx": "", "name": "" },
  "role": { "finalRole": "", "checked": false },
  "records": [
    {
      "source": { "type": "iwiki|tencent_doc|wecom_doc|text|chat_forward|image", "ref": "链接或原文位置", "title": "文件名/文档标题（用于对象类型识别；chat_forward/纯文本/图片无标题）", "raw": "抽取到的原始纪要文本或对话流或图片识别文字" },
      "extracted": { "对象名原文": "", "时间原文":              
       
           

             

           
               
         
                    
         

           
           
           
           
         
           
                    
        
      
       
                  
       
         
    
  

object_type ∈ {customer(客户), opportunity(商机=项目)}；from_type：客户=1、商机=2。 owner_check.in_scope：该对象是否在当前用户名下（一致性校验结果）；hit_by：命中依据（客户=list_hit / 商机=owner|sales|architect）。

关键接口（详见 shared/API_REFERENCE.md）

全部经 omp-service MCP 转发，request_api 的 apiPath + data：

用途	apiPath
读取当前用户信息 + 拿角色（showDetail=true 读 detail.roles[]）	get_user_info（omp-service 通用工具，非 request_api）
客户模糊搜索 + cid 名下校验（带权限过滤）	csm/GetCustomerListForVisitForMcp
商机（项目）搜索(name模糊/code编号) + 负责人字段	ltc.project/list
查询签到打卡记录（仅查询）	csm/GetVisitCheckInsListForMcp
提交跟进记录（MCP 专用）	csm/AddCustomerVisitForMcp

⚠️ 严禁调用 GetAssociationCustomerList（无权限过滤，会选到无权限客户）。 ⚠️ 严禁调用 AddCustomerVisitCheckIns 创建签到（PC 端只能关联已有打卡，凭空造打卡=幻觉，违反铁律 #8）。 💡 客户详情 csm/GetCustomerInfoByFields 拿不到架构师字段（仅有主销售 business_manager），因此客户侧一致性校验走 GetCustomerListForVisitForMcp 命中判定，不依赖客户详情。

参考资料（shared/）

• API_REFERENCE.md — 三个核心接口的完整入参/出参、finalRole 计算规则、对象搜索策略、提交参数组装
• FIELDS_MAPPING.md — 【本技能核心】源文档字段 → 磐石新字段（重构后）的映射表，含 Sales / Owner 各自的必填字段矩阵
• ENUMS.md — type / source / summary_type / time_section / position(拜访对象职位) 等枚举值
• STEPS.md — Gate 0~5 的详细执行步骤与话术模板、异常处理、降级链路

执行入口

收到搬运请求后：

1. 读取 shared/STEPS.md，按 Gate 0 初始化。
2. 严格逐 Gate 推进，每条记录静默完成 Gate 0~3 的抽取；仅触发 2 次确认（跟进对象实体 / 职位+打卡+预览）。
3. 全过程遵守上方「八条铁律」。