
crm-maintenance 技能 HubSpot 字段与活动类型指南contacts、deals、activities 的读写边界与关联规则【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins导读本文是crm-maintenance技能位于 small-business/skills/crm-maintenance/SKILL.md的核心字段规范文档它精确划定了该技能在 HubSpot 上只动哪些对象、属性与活动类型其余一切数据保持原样。读完本文你将掌握联系人Contacts的创建与查找字段、交易Deals在清理路径下只读 经批准后写入的字段清单、三类活动Email / Call / Note各自写入的标准属性以及活动与交易、联系人之间的强制关联规则并了解这些规则在真实工作流中的落地方式。一、文档定位为什么需要一份字段白名单crm-maintenance的设计初衷是让 HubSpot 保持最新而无需负责人亲自打开它它从邮件与日历上下文创建、更新联系人和交易记录 Notes 与 Calls并标记陈旧记录详见 SKILL.md。要安全地做到这一点就必须有一份严格的字段白名单。hubspot-fields.md 就是这份白名单的权威来源。它开宗明义地声明只有本文列出的字段才属于本技能的读写范围HubSpot 中的其他一切字段都保持原样、不予触碰。这一约束同时服务于两个目标可预测性技能写什么、不写什么完全可预期负责人可以放心地把记录这次通话更新 CRM这类操作交给它数据所有权交易阶段dealstage、流水线pipeline、负责人hubspot_owner_id等由负责人亲自管理的字段技能永远不会擅自覆盖。在实际工作流中SKILL.md 明确要求在向 HubSpot 写入任何内容之前必须先阅读本文件确认字段名、活动类型与关联规则见 SKILL.md。也就是说这份参考文档是技能每次执行写操作前的事实依据。二、Contacts联系人写入字段与查找字段写入字段Write联系人写入仅限于四个字段且严格受控字段用途email主标识符用于查找与去重dedupe。创建时必须设置。firstname如果可从邮件签名或日历邀请中获取则填写未知则留空。lastname同上可从邮件签名或日历邀请获取时填写未知则留空。company从邮件签名域名或日历组织信息获取时填写。规则非常明确不得写入任何其他联系人属性。负责人owner、生命周期阶段lifecycle stage、潜在客户来源lead source属于用户管理字段——绝不覆盖。在 examples/log-call-happy-path.md 中可以看到这一规则的实战形态当日历邀请出现了一位不在 HubSpot 中的参会者 Ben Rivera 时技能从邮件域名推断出company: Acme创建联系人时只写了email、firstname、lastname、company四个字段并先向用户宣告创建操作。读取字段Read用于查找字段用途email搜索键。大小写不敏感的精确匹配。firstname·lastname·company在歧义消解ambiguity resolution时展示给用户。hs_object_id用于与交易deals和活动activities建立关联。这里有一个容易踩坑的细节HubSpot 以邮箱的精确匹配做去重Sarah.Linacme.com与sarah.linacme.com会被视为两个不同的联系人。因此 gotchas.md 专门强调查找前必须将邮箱规范化为小写否则会创建出静默的重复联系人直接摧毁负责人对技能的信任。这也是为什么上面读取表中明确写着case-insensitive exact match大小写不敏感的精确匹配。三、Deals交易清理路径下的读写边界交易字段的读写规则是所有对象中最严格的一组——技能对交易的默认姿态是只读写入仅发生在清理路径cleanup path且必须经过用户逐项批准。读取字段所有清理与消解路径通用字段用途dealname展示给用户用于与邮件主题/会议主题做模糊匹配。dealstage清理期间只读——发现不一致只能标记flag绝不更改。amount清理时读取若近期邮件/会议暗示金额变化则标记。closedate清理时读取若已过时则标记。hs_next_step清理时读取并可提议更新。hubspot_owner_id展示给用户绝不更改。hs_lastactivitydate用于识别陈旧交易stale deals。关联的联系人用于判断近期邮件/会议的参与者是否已在交易上。写入字段仅清理路径且需批准字段规则hs_next_step可提议更新仅在用户明确批准后写入。closedate可提议更新仅在用户明确批准后写入。amount可提议更新仅在用户明确批准后写入。联系人关联可提议补充缺失的交易参与者仅在批准后写入。同时有一条绝对红线清理期间绝不写入dealstage、pipeline、hubspot_owner_id或任何自定义属性——这些都属于负责人管理字段。cleanup-checklist.md 是这一读写在清理路径上的完整执行清单逐项检查最后活动日期、hs_next_step、dealstage、closedate、amount、关联联系人、笔记卫生并以当前值 → 建议值并排展示只写用户批准的部分。关于阶段变更清单明确要求仅标记——绝不自动改阶段把证据摆出来让用户决定。四、Activities活动三类活动与各自写入属性技能写入的活动严格使用 HubSpot 的标准活动词汇不得发明自定义活动类型活动类型使用者写入的字段Email engagementEMAIL邮件路径hs_email_subject邮件线程主题、hs_email_text摘要而非完整线程、hs_timestamp最新消息时间、关联的联系人 交易Call engagementCALL通话路径hs_call_title事件标题、hs_call_body摘要、hs_call_duration取自日历、hs_timestamp事件开始时间、关联的联系人 交易NoteNOTE清理路径hs_note_body当需要为未来复核标记某事、而又不适合做字段更新时摘要而非抄录Email 活动的内容原则hs_email_text写入的是摘要而非完整线程。这一约定背后有明确的业务理由见 gotchas.mdHubSpot 活动是供快速扫描的信号面signal surface不是转录归档。一份 12 封邮件的完整线程粘贴进活动正文毫无用处而三句话的达成了什么才是可行动的。好的摘要示例是Sarah confirmed scope for Q2 expansion — 50 seats, $18K ACV, start date June 1. Shell send the signed SOW by Friday. No open questions.即摘要要点名决策、数字和下一步。实战形态两个完整示例邮件路径examples/log-email-happy-path.md线程主题 Acme Q2 pricing follow-up 直接用作hs_email_subject正文摘要 Sarah confirmed 50 seats at $360/seat ($18K). Signed SOW coming Friday. 写入hs_email_texths_timestamp取最新消息时间关联联系人与交易各一。通话路径examples/log-call-happy-path.md事件标题 Acme — technical deep dive 用作hs_call_title无会议描述时写入占位摘要并提示用户补充hs_call_duration为 30 分钟hs_timestamp为事件开始时间 10:00同时关联两个联系人既有 新建与交易。Note 的追加不重写原则在清理路径中当发现问题需要标记但又不适合直接改字段时写入一条NOTE。对应的卫生规则cleanup-checklist.md 第 7 项是追加新 Note 澄清当前状态绝不编辑或删除旧 Note——追加而非重写历史。这与 SKILL.md 中绝不删除记录的硬性审批门一致见 SKILL.md。五、Association rules关联规则活动的关联规则是整个字段体系中最需要严格执行的部分每个活动必须同时关联到交易dealAND 至少一个联系人contact——两者缺一不可如果在记录活动的过程中临时创建了联系人必须在同一次操作中把它关联到交易这样活动才能同时出现在联系人和交易的时间线上不要在记录活动的流程中把联系人关联到交易除非该联系人确实参与了那封邮件线程或那场会议。这条必须是真实参与者的约束在 examples/log-call-happy-path.md 中有直接体现新建的 Ben Rivera 因为实际出席了对 Acme 的技术深挖会议所以被创建并关联到 Acme Q2 Expansion 交易而在 examples/cleanup-deal.md 中Maria Chen 因出席了 Acme — legal review walkthrough 会议而被提议加入交易——这些关联都以实际参与为唯一依据。六、贯穿全部规则的两条底线把字段表、活动表和关联规则放在一起看可以提炼出crm-maintenance对 HubSpot 数据的整体姿态写入最小化联系人只写 4 个字段、交易只写 4 类数据且需逐项批准、活动只用 3 种标准类型。白名单之外一律不动。所有权让渡dealstage、pipeline、hubspot_owner_id、生命周期阶段、来源字段等负责人管理数据技能只能读、只能标记、只能提议写入必须等用户点头。即便是证据很强的阶段变更也遵循标记并搁置flag and defer原则见 SKILL.md 与 gotchas.md 中基于邮件措辞提议阶段变更的反面案例。七、在技能工作流中的引用位置这份字段文档不是孤立存在的它在crm-maintenance的三条执行路径中都被显式引用邮件路径 / 通话路径技能在解析联系人、定位交易、写入活动前需先按本文核对字段与关联规则清理路径技能按 cleanup-checklist.md 逐字段审计本文定义了每个字段的读写边界歧义场景当联系人去重或交易定位出现歧义时gotchas.md 的 Good/Bad 对照提供了最常见的失败模式与正确姿势。结语hubspot-fields.md是一份少即是多的字段契约它用四张表加三条关联规则把技能在 HubSpot 上的全部读写行为限定在一个小而清晰的范围之内。正是这种严格的边界约束让crm-maintenance既能自动完成联系人创建、活动记录与交易清理又不会触碰负责人真正掌控的数据——这份可预期性就是它作为知识工作插件knowledge-work-plugins 仓库见 README.md被信任的基础。延伸阅读SKILL.md完整工作流与审批门、cleanup-checklist.md清理路径的 7 项检查、gotchas.mdGood/Bad 边界案例、examples/cleanup-deal.md一次完整交易的清理演练。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考