linkedin-skills开发者指南如何正确处理LinkedIn的3种URN类型与2级线程扁平化陷阱【免费下载链接】linkedin-skillsClaude skills for LinkedIn. 11 Claude Code and Codex skills that write human-sounding LinkedIn posts, craft comments that get noticed, analyze your feed, and build a publishing cadence, all from your terminal. Content engineering by Creative Content Crafts. MIT.项目地址: https://gitcode.com/gh_mirrors/lin/linkedin-skillslinkedin-skills 是一个面向 LinkedIn 的 Claude Code / Codex 技能集合它让 AI 助手能以你的语气写帖子、发评论、回线程。要让这套技能真正跑通开发者必须理解两件事LinkedIn 的3 种帖子 URN 类型activity、share、ugcPost以及2 级线程扁平化这条隐藏规则。本指南带你从 URL 解析讲到正确发布避开最常见的 400/404 错误。三种URN类型一览activity、share、ugcPostLinkedIn 后台并不用 URL 本身作为帖子的唯一标识而是用 URN统一资源名。同一个帖子在不同入口下URN 前缀可能完全不同URN 类型典型 URL 片段生成的 URNactivity/posts/昵称-activity-7448...-XXurn:li:activity:7448...share/posts/昵称-share-7449...-XXurn:li:share:7449...ugcPost/feed/update/urn:li:ugcPost:7447...urn:li:ugcPost:7447...完整映射表见根目录技能文档 SKILL.md。新手最容易踩的坑是URL 里写的 slug 类型不一定是 LinkedIn 后台认定的规范 URNcanonical URN。这正是后文 404 陷阱的根源。URL 解析怎么做先找评论再按优先级匹配帖子linkedin-skills 把全部解析逻辑收敛在一个纯 Python 模块里lib/url_parser.py。它的匹配顺序非常讲究先匹配 comment URN。正则 COMMENT_URN_RE 会在全局查找urn:li:comment:(activity:帖子ID,评论ID)片段通常在?commentUrn...查询参数里需要 URL 解码。命中则同时返回post_urn、comment_id和comment_urnurl_type标记为comment。再按 ugcPost → share → activity 的顺序匹配帖子 slug。见 parse_linkedin_url。顺序不能随意调换因为 ugcPost 更具体应优先命中。都不匹配则返回url_type: unknown由技能决定是向用户要信息还是放弃。解析结果是一个结构化的 dictpost_activity_id/post_urn/comment_id/comment_urn/url_type下游所有技能都只消费这个结构不再各自写正则。陷阱一评论URN有长短两种写法只有长写法是API认的这是最反直觉的一点linkedin-skills 的测试文档里专门钉死了这个区别见 tests/test_response_shapes.py 的CommentUrnForms测试类来源写法示例LinkedIn 网页永久链接、爬虫数据短形式urn:li:comment:(activity:111,222)发布 API 实际使用的长形式urn:li:comment:(urn:li:activity:111,222)也就是说你从浏览器地址栏复制来的评论链接解码后是短形式但调发布接口时必须发长形式。parse_linkedin_url会自动把粘贴进来的短形式规范化成长形式而构造父评论的辅助函数 build_parent_comment_urn 输出的也是长形式。⚠️ 开发者注意不要把长形式修正回短形式。LinkedIn 的 URL 看起来是短写法只说明网页端用短形式不代表 API 也一样。技能文档 linkedin-reply-handler/SKILL.md 里专门警告了这一点。陷阱二2级线程扁平化parentComment必须指向顶层评论LinkedIn 的评论线程只嵌套两层。无论一场对话逻辑上进行了多少回合第二条及之后的回复在存储层面都挂在顶层评论下帖子 (urn:li:activity:P) ├─ 评论 A (id: 111) ← 顶层 │ ├─ 回复 B (id: 222) ← 第2层 │ └─ 回复 C (id: 333) ← 仍然是第2层挂在 A 下不在 B 下所以当你回复 C 时parentComment必须传A 的 URN而不是 C 或 B 的。传错了会发生三种后果完整说明见 threading-rules.md部分帖子直接返回400 Bad Request评论被静默放错位置用户看到的是错误层级二级 URN 被拒绝时评论变成孤儿。批量扫帖whole-thread 模式时更容易乱队列里每条草稿都要携带top_level_comment_id回复 B 或 C 的草稿统一用 A 的 URN。技能 linkedin-reply-handler 在步骤 6 明确要求逐条核对这个字段。陷阱三404 时activity URN未必是规范URN解析器从 URL slug 推出的post_urn有时是activity而 LinkedIn 后台真正认的是ugcPost——这时直接发评论会得到 404。标准回退方案SKILL.md 已知陷阱用lib.ApifyClient.fetch_post_comments(post_id...)拉取该帖已有评论从任意一条已有评论的post_input/comment_url字段读出规范 URN用规范 URN 重新发起发布。还有一个关联的reshare 陷阱转发帖reshare的评论树挂在原帖上而不是转发自己的 activity id 上。对转发 id 调评论接口会返回空。同理重新分享时要走shareUrnurn:li:share:*或urn:li:ugcPost:*不要手工把 activity id 转成 share id两者的 id 可能不同——lib/publora_client.py 的create_reshare和 linkedin-comment-drafter 的 Reshare 模式都遵循这条规则。标准流程从URL解析到正确发布把以上知识串起来linkedin-skills 的处理管线是四步对应解析 → 起草 → 审批 → 发布的核心模式步骤做什么关键函数/文件1. 解析任意形态的帖子/评论 URL → 结构化 URNparse_linkedin_url2. 读上下文拉帖子正文、评论树Apify确定线程结构lib/apify_client.py3. 构造父评论定位顶层评论 id → 生成长形式 parentComment URNbuild_parent_comment_urn4. 审批后发布反应 回复经 Publora 发出lib/publora_client.py这些行为不是靠文档约束而是被回归测试锁定的tests/test_response_shapes.py 用 tests/fixtures/apify_comments.json 等真实数据夹具断言短形式 URN 能被解析成长形式父评论 URN 总能从顶层评论 id 构造出来两类评论读取器的字段命名差异。改代码前跑一遍测试就能确认没破坏任何规则。开发者自查清单发布评论前对照检查一遍✅ 帖子的post_urn是从 URL 解析出来的还是已验证过的规范 URN404 了就走评论回退✅ 目标评论是回复吗是 →parentComment指向顶层评论的长形式 URN✅ URN 用的是长形式urn:li:comment:(urn:li:activity:X,Y)不是短形式✅ 输入是转发帖吗先解析到原帖再拉评论树✅ 批量发布时逐条核对top_level_comment_id并按顺序逐条发出不并发轰炸掌握这三类 URN 与 2 级扁平化规则你就理解了 linkedin-skills 整个读写管线的地基。更多细节可以通读根 README.md 的开发者章节和 references/voice-rules.md它们分别覆盖了运行时时序与文风规则。【免费下载链接】linkedin-skillsClaude skills for LinkedIn. 11 Claude Code and Codex skills that write human-sounding LinkedIn posts, craft comments that get noticed, analyze your feed, and build a publishing cadence, all from your terminal. Content engineering by Creative Content Crafts. MIT.项目地址: https://gitcode.com/gh_mirrors/lin/linkedin-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 linkedin-skills开发者指南：如何正确处理LinkedIn的3种URN类型与2级线程扁平化陷阱
linkedin-skills开发者指南如何正确处理LinkedIn的3种URN类型与2级线程扁平化陷阱【免费下载链接】linkedin-skillsClaude skills for LinkedIn. 11 Claude Code and Codex skills that write human-sounding LinkedIn posts, craft comments that get noticed, analyze your feed, and build a publishing cadence, all from your terminal. Content engineering by Creative Content Crafts. MIT.项目地址: https://gitcode.com/gh_mirrors/lin/linkedin-skillslinkedin-skills 是一个面向 LinkedIn 的 Claude Code / Codex 技能集合它让 AI 助手能以你的语气写帖子、发评论、回线程。要让这套技能真正跑通开发者必须理解两件事LinkedIn 的3 种帖子 URN 类型activity、share、ugcPost以及2 级线程扁平化这条隐藏规则。本指南带你从 URL 解析讲到正确发布避开最常见的 400/404 错误。三种URN类型一览activity、share、ugcPostLinkedIn 后台并不用 URL 本身作为帖子的唯一标识而是用 URN统一资源名。同一个帖子在不同入口下URN 前缀可能完全不同URN 类型典型 URL 片段生成的 URNactivity/posts/昵称-activity-7448...-XXurn:li:activity:7448...share/posts/昵称-share-7449...-XXurn:li:share:7449...ugcPost/feed/update/urn:li:ugcPost:7447...urn:li:ugcPost:7447...完整映射表见根目录技能文档 SKILL.md。新手最容易踩的坑是URL 里写的 slug 类型不一定是 LinkedIn 后台认定的规范 URNcanonical URN。这正是后文 404 陷阱的根源。URL 解析怎么做先找评论再按优先级匹配帖子linkedin-skills 把全部解析逻辑收敛在一个纯 Python 模块里lib/url_parser.py。它的匹配顺序非常讲究先匹配 comment URN。正则 COMMENT_URN_RE 会在全局查找urn:li:comment:(activity:帖子ID,评论ID)片段通常在?commentUrn...查询参数里需要 URL 解码。命中则同时返回post_urn、comment_id和comment_urnurl_type标记为comment。再按 ugcPost → share → activity 的顺序匹配帖子 slug。见 parse_linkedin_url。顺序不能随意调换因为 ugcPost 更具体应优先命中。都不匹配则返回url_type: unknown由技能决定是向用户要信息还是放弃。解析结果是一个结构化的 dictpost_activity_id/post_urn/comment_id/comment_urn/url_type下游所有技能都只消费这个结构不再各自写正则。陷阱一评论URN有长短两种写法只有长写法是API认的这是最反直觉的一点linkedin-skills 的测试文档里专门钉死了这个区别见 tests/test_response_shapes.py 的CommentUrnForms测试类来源写法示例LinkedIn 网页永久链接、爬虫数据短形式urn:li:comment:(activity:111,222)发布 API 实际使用的长形式urn:li:comment:(urn:li:activity:111,222)也就是说你从浏览器地址栏复制来的评论链接解码后是短形式但调发布接口时必须发长形式。parse_linkedin_url会自动把粘贴进来的短形式规范化成长形式而构造父评论的辅助函数 build_parent_comment_urn 输出的也是长形式。⚠️ 开发者注意不要把长形式修正回短形式。LinkedIn 的 URL 看起来是短写法只说明网页端用短形式不代表 API 也一样。技能文档 linkedin-reply-handler/SKILL.md 里专门警告了这一点。陷阱二2级线程扁平化parentComment必须指向顶层评论LinkedIn 的评论线程只嵌套两层。无论一场对话逻辑上进行了多少回合第二条及之后的回复在存储层面都挂在顶层评论下帖子 (urn:li:activity:P) ├─ 评论 A (id: 111) ← 顶层 │ ├─ 回复 B (id: 222) ← 第2层 │ └─ 回复 C (id: 333) ← 仍然是第2层挂在 A 下不在 B 下所以当你回复 C 时parentComment必须传A 的 URN而不是 C 或 B 的。传错了会发生三种后果完整说明见 threading-rules.md部分帖子直接返回400 Bad Request评论被静默放错位置用户看到的是错误层级二级 URN 被拒绝时评论变成孤儿。批量扫帖whole-thread 模式时更容易乱队列里每条草稿都要携带top_level_comment_id回复 B 或 C 的草稿统一用 A 的 URN。技能 linkedin-reply-handler 在步骤 6 明确要求逐条核对这个字段。陷阱三404 时activity URN未必是规范URN解析器从 URL slug 推出的post_urn有时是activity而 LinkedIn 后台真正认的是ugcPost——这时直接发评论会得到 404。标准回退方案SKILL.md 已知陷阱用lib.ApifyClient.fetch_post_comments(post_id...)拉取该帖已有评论从任意一条已有评论的post_input/comment_url字段读出规范 URN用规范 URN 重新发起发布。还有一个关联的reshare 陷阱转发帖reshare的评论树挂在原帖上而不是转发自己的 activity id 上。对转发 id 调评论接口会返回空。同理重新分享时要走shareUrnurn:li:share:*或urn:li:ugcPost:*不要手工把 activity id 转成 share id两者的 id 可能不同——lib/publora_client.py 的create_reshare和 linkedin-comment-drafter 的 Reshare 模式都遵循这条规则。标准流程从URL解析到正确发布把以上知识串起来linkedin-skills 的处理管线是四步对应解析 → 起草 → 审批 → 发布的核心模式步骤做什么关键函数/文件1. 解析任意形态的帖子/评论 URL → 结构化 URNparse_linkedin_url2. 读上下文拉帖子正文、评论树Apify确定线程结构lib/apify_client.py3. 构造父评论定位顶层评论 id → 生成长形式 parentComment URNbuild_parent_comment_urn4. 审批后发布反应 回复经 Publora 发出lib/publora_client.py这些行为不是靠文档约束而是被回归测试锁定的tests/test_response_shapes.py 用 tests/fixtures/apify_comments.json 等真实数据夹具断言短形式 URN 能被解析成长形式父评论 URN 总能从顶层评论 id 构造出来两类评论读取器的字段命名差异。改代码前跑一遍测试就能确认没破坏任何规则。开发者自查清单发布评论前对照检查一遍✅ 帖子的post_urn是从 URL 解析出来的还是已验证过的规范 URN404 了就走评论回退✅ 目标评论是回复吗是 →parentComment指向顶层评论的长形式 URN✅ URN 用的是长形式urn:li:comment:(urn:li:activity:X,Y)不是短形式✅ 输入是转发帖吗先解析到原帖再拉评论树✅ 批量发布时逐条核对top_level_comment_id并按顺序逐条发出不并发轰炸掌握这三类 URN 与 2 级扁平化规则你就理解了 linkedin-skills 整个读写管线的地基。更多细节可以通读根 README.md 的开发者章节和 references/voice-rules.md它们分别覆盖了运行时时序与文风规则。【免费下载链接】linkedin-skillsClaude skills for LinkedIn. 11 Claude Code and Codex skills that write human-sounding LinkedIn posts, craft comments that get noticed, analyze your feed, and build a publishing cadence, all from your terminal. Content engineering by Creative Content Crafts. MIT.项目地址: https://gitcode.com/gh_mirrors/lin/linkedin-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考