opcmenu.com

【何时用】用户用自然语言找**产品/作品**时，比如「有没有给独立开发者用的财务工具」「记笔记的极简 app」「Notion 替代品」。返回按相关度排序的产品卡片，含 slug / tagline / 所属主理人。 【只管产品】找「人」（能提供某种价值的主理人）用 search_people；搜需求用 search_needs。 【机制】关键词 + 向量（阿里云百炼 text-embedding-v3）双路并行召回后 RRF 融合，另有 LLM 查询扩展 / 精排，各步可自动降级。结果里的 mode 一般为 hybrid。 【常见 pitfall】问 "什么是独行录"、"如何注册" 这种 meta 问题不要用本工具，那是站点介绍不在数据里。

【何时用】用户想看「热门」「今日新品」「随机逛逛」「月度榜」时。比 search 更适合无明确意图的浏览。 【type 取值】 - hottest: 已认领主理人优先 + 累计浏览量排序 - today: 今日新发布 - random: 随机抽取（已认领优先，探索用） - leaderboard: 上月榜（上个自然月的预计算快照，与 hottest 的累计热度不是一回事）

按 id 或 slug 获取产品完整详情（owner 主理人 / 描述 / 链接 / 媒体 / 分类 / 标签 / 发布时间）。两个参数二选一，slug 优先。 【何时用】用户点了某个产品想看详情，或 search/list 返回后要展开看某条。 【相关 resource】也可以用 resources/read URI: opcmenu://product/{slug}。

【何时用】用户想看「有哪些做一人公司的人」「最热门的主理人」时。返回主理人卡片：昵称 / 头像 / 简介 / 作品数 / isStub（是否爬虫导入占位号，false=已认领真人）。 【后续 drill-down】可以接 get_creator 看某位主理人的完整作品列表。

按 id 查主理人 profile + 已发布作品列表（按热度+发布时间排序）。 【何时用】用户想了解某位主理人在做什么、关注他/她的全部作品。 【相关 resource】opcmenu://creator/{id}

查活动列表（线上/线下聚会、讲座、demo day、内测招募，以及 COMPETITION 创业大赛/外部机会）。支持按类型、城市过滤，仅看未来场次，游标分页。 【何时用】用户问「最近有什么活动」「下周有没有线下聚会」「上海有什么创业大赛/机会」时。找大赛/机会用 type=COMPETITION + city。upcomingOnly=true 是大部分情况下你想要的。

按 id 或 slug 拿活动详情：标题 / 描述 / 时间地点 / organizer / 报名情况。两个参数二选一，slug 优先。 【怎么报名——判据只看 signup，不看 type】 - **signup 不为空 → 站内能报**：用 get_signup_activity 看要填什么、submit_signup 提交。**站内报名只有这一条链。**（平台自办/承办的赛事也常是 type=COMPETITION，一样在站内报——别拿 type 判。） - **signup 为空且 externalUrl 非空** → 这是导入的外部赛事资讯，站内报不了，如实让用户去 externalUrl 那儿报。 - 两个都空 → 这场就是没开报名，别编一个入口出来。 【相关 resource】opcmenu://activity/{slug}

按 slug 获取某个一人公司主页（公开视角：仅返回已发布 PUBLISHED 的公司；本人 owner 可见自己任意状态的公司）。查不到返回 found=false。 【何时用】用户想看某家一人公司在做什么。 【相关 resource】opcmenu://company/{slug}

列出已发布的一人公司主页（最新优先）。可选 q 关键词命中名称 / 定位。 【何时用】用户想浏览「有哪些一人公司」或按关键词找公司。drill-down 用 get_company。

【何时用】用户说「随便看看」「让我发现些有意思的」「给我推荐点东西」时。随机抽 已发布 的产品（已认领主理人的产品优先出现）。比 search 更适合「我也不知道我想要什么」场景。续拉时把已看过的产品 id 传进 exclude 去重。

返回千人千面的发现 feed：登录且设过兴趣（set_my_preferences）时按兴趣语义排序，否则回落「已认领优先 + 热度」。比 random_feed 更贴合用户口味，是网页登录后的默认发现页。续拉时把 nextCursor 原样回传以延续同一副牌。

按分类系统性地逛已发布产品（已认领主理人优先）。比 list_products 多了分类过滤，比 search_products 更适合「结构化浏览某一类」而非语义搜索。

【何时用】用户想看「大家都在找什么」「有什么我能帮上/接得住的需求」时——这是需求互换的主入口。 【结构】一人一卡按作者聚合：每张卡是一位主理人（主打 author.

按 id 查单条需求的完整卡片：类型 / 标题 / 详情 / 配图 / 状态 / 作者（含 canOffer 与代表产品）。登录时附带 isMine 与 displaying。查不到返回 found=false。 【口径】接洽不限人数（没有名额概念），也没有报酬/感谢费。displaying=false 表示作者手动下架了（status 仍是 OPEN——下架只改展示期不改状态），别再向用户推荐它。 【相关 resource】opcmenu://need/{id} 【后续】想接这条需求 → contact_need（需登录），它返回 conversationId 可以直接接 send_message。

【何时用】用户想找「人」时——「找能提供小程序代开发的主理人」「谁懂跨境电商供应链」「找人合作做 AI 出海产品」。搜的是主理人的供给侧（canOffer 能提供什么 + 昵称/介绍/身份标签），这是 OPC 之间撮合合作的刚需入口。 【机制】关键词 + 向量混合检索（RRF 融合），真人（已认领）梯队前置。结果含 canOffer / similarity / claimed。 【组合链】命中后 get_creator 看作品尽调 → start_conversation 开聊；对方若发过需求也可 contact_need 顺着需求接洽。搜「产品」用 search_products，搜「需求」用 search_needs。 【常见 pitfall】**不支持按手机号搜人**（隐私保护，服务端对手机号查询恒返回空）——用户给的是手机号时直接说明不支持，改问对方的昵称或能提供什么。

【何时用】用户想定向找「有没有人在找 X」时——「有没有人想找设计合作」「谁在找出海经验交流」。比 list_needs_feed（推荐流）更适合带明确关键词的检索。 【机制】标题/详情关键词 + need_embedding 向量混合检索（RRF 融合），只出在架需求（与信息流可见性口径一致）。返回完整需求卡（含作者 canOffer）。 【组合链】命中 → get_need 看详情 → contact_need 接洽拿 conversationId → send_message 开聊。

独行录的**官方内容流**：每日发现选品、创业大赛机会、园区与政策资讯。 【何时用】用户想看「最近站里推了什么」「有哪些新的创业大赛机会」时；也可以传 attachType+attachId 查挂在某产品/活动/园区上的相关内容。 【重要口径——别说成社区】这不是用户社区：站内**没有用户发帖入口**（App 的动态 tab 已换成产业链），流里几乎全是系统生成的官方内容。别向用户描述成「大家在聊什么」，也别建议用户「去发个动态」——没有那个入口。 【feed】recommend（默认）| following（只看我关注的人，需登录；因为几乎没有用户帖，这个流通常是空的）。

按 id 查内容流里的单条（正文 / 图片视频 / 挂卡 attach / 作者）。登录时附带 viewerHasLiked / isMine。 【口径】绝大多数是官方生成的内容（每日选品 / 赛事导入），不是用户动态；评论区全站至今零条，别向用户提「去评论区看看」。

浏览 / 筛选 OPC 园区目录（六城）。 【杀手用法】按补贴类型筛：benefitType=RENT_SUBSIDY 找「有租金补贴的园区」——这是主理人/找资源者最高频的诉求。可叠加 city / track / 状态 / 关键词。 【drill-down】get_park 看补贴明细 + 入驻条件 + 信源。

按 id 查园区完整详情：补贴明细（类型 / 金额 / 条件）+ 运营方 + 地址坐标 + 入驻主理人 + 渠道 + 信源 + 最近新闻。查不到 found=false。 【口径】园区是**运营维护的目录数据**，站内没有用户打卡/点评（那套 UGC 已下线），别编「有 N 人打过卡」「评分 4.

园区新闻 feed（开园 / 招商 / 补贴变化等时效信息）。可按城市或具体园区过滤。

各城市 / 区的创业政策红利（政策大礼包：标题 / 发文单位 / 日期 / 亮点 / 信源）。 【何时用】「深圳 OPC 有什么政策红利」「入驻前看看当地政策」。不传 city 返回全部。

各城市园区总数 + 已运营数（按总数倒序），宏观选址用。传 benefitType 则只统计含该补贴的园区，与列表口径一致。

返回某产品的口碑：星级汇总（平均分 + 1~5 星分布 + 总数）+ 评价列表（文字 + 星级）。登录时附带 myRating。get_product 详情不含评价，要口碑必须调本工具。 【口径】站内口碑刚起步，**绝大多数产品是 0 条评价——空返回是常态，不是查询失败**。别因为查空就换别的工具反复试，更别去站外找评价冒充站内口碑。 【写】rate_product 打分写评。

只取某产品的星级汇总（平均分 + 分布 + 总数），不拉评价列表——省 token 的「评分多少」快查。要看评价文字用 get_product_ratings。

返回某主理人收到的推荐口碑（无星级，只有文字 + 关系 relation）+ 总数。登录时附带 myRating（我给 TA 的口碑）。 【何时用】人物尽调：谁背书过 TA、以什么关系、说了什么。 【口径】全站至今几乎没有人写过主理人口碑，**空返回是常态**。真要判断一个人靠不靠谱，看 get_creator 的作品列表比看这里有用。写口碑用 endorse_creator。

【何时用】用户问「最近有什么能报名的 / 这周截止的有哪些 / 有没有黑客松」时调它。这是站内**唯一能真报名**的机会列表：每一场都挂着可用的报名表单。 【组合链】拿到 slug 后：① get_signup_activity(slug) 一次拿全「详情 + 我的报名状态 + 还缺哪几题」；② 缺项补齐后 submit_signup(slug) 直接报；③ 想一次盘几场就 get_signup_gaps(slugs=[…]) 拿跨场合并的待答清单，问一轮就够。 【口径/坑】① 本工具返回的每一条都**当场能在站内报**（判据是这场挂了报名配置，与 Activity.

【何时用】用户对某一场感兴趣、或准备报名之前调它。**一次调用给全上下文**：公开详情（简介/时间/地点/名额/题目表/答疑群）＋（登录时）我的报名状态、每题的现值、还缺哪几个必填项——App 上这是两个接口两屏，agent 端合成一次。 【组合链】① viewer.

【何时用】用户要**买一类服务**而不是找某个具体产品时：「GPU 租赁」「代理记账」「商标代办」「法务咨询」「找人帮我投流」「大模型 token 哪买便宜」——这是高意图检索的正确入口。按服务域精确取整组，比 search_products 关键词碰运气稳。 【组合链】items[].

【何时用】一个工具两个透镜，用 side 切：side=investor 找**投资人**（个人/产投/机构），side=project 找**在融资的项目**。用户说「帮我找看 AI 应用的天使」走前者，「最近有哪些一人公司在融钱」走后者。 【组合链】items[].

【何时用】用户要的是**某一类人本人**而不是某个产品/服务时用：「帮我找个能写代码的」「有没有做出海的人」「找几个律师/财税顾问聊聊」。和 list_service_products 的区别：那边是「他卖什么」（产品目录），这边是「他本人是干什么的」（人的目录）；和 search_people 的区别：那边是语义搜，这边是结构化职业筛选，适合按类目扫一遍。 【组合链】items[].

【需要登录】上报一个追踪事件（点击 / 浏览 / 分享 / 下载 等）。targetType + targetId 决定目标对象，type 是动作。 【常见用法】当 agent 帮用户完成「分享某产品」「点开某主理人主页」时记一笔，让推荐算法更准。 【type 例】 view | click_link | share | download | follow

【需要登录】返回当前用户的完整资料：昵称 / 简介 / 介绍 / 所在地 / 全部链接（含 friends/private 等所有可见范围）/ 身份 persona。 【何时用】agent 要帮用户「把资料填到别的平台」「检查我留了哪些联系方式」「改我的链接」之前，先用它把现状读出来。比 get_creator 多了私有链接和 persona（get_creator 是公开视角，只吐 public）。

【需要登录】列出当前用户名下的产品（含待认领 / 已发布 / 已下架等全部状态，以及每个产品的全部链接）。 【何时用】agent 要改某个产品的链接/资料前先列出来拿 productId；或盘点「我发布了哪些东西」。

【需要登录】一次调用拿全「我是谁」的结构化全集：基本信息（含 canOffer 我能提供什么）+ 按分组聚合的全部链接（标注每条可见范围）+ 已发布产品 + **多角色画像 roleProfile**（融资/投资人/机构/资源寻找者/在校/阶段）+ 我关注的产品。 【何时用】写开场白、填外部平台的表单、生成 BP 大纲、判断该不该接某条需求——这些事都要先有这一份。**别为了凑齐这些信息去连调四五个工具，这里一次给全。** 【组合链】get_my_card → 拿 canOffer 对照 list_needs_feed 挑能接的 → contact_need → send_message。 【想改】资料本体走 update_my_profile；角色画像走 set_my_role_profile；也可以用 resource opcmenu://me/card 拿同样数据。 【完整度】missing 列出还没填的关键项（照名片完整度口径），是「还差哪几步」的现成代办清单。

【需要登录】更新当前用户资料，立即生效（资料修改不走审核）。所有字段可选，只传想改的；links 传则整组替换（要增删单条用 add_profile_link / remove_profile_link 更方便）。建议先 get_my_profile 读现状再改。 【canOffer 是全站撮合的轴心】search_people 搜的就是它、需求信息流的 matchScore 按它算、get_need_recommendations 拿它给作者推人。留空 = 从撮合池里掉出去，谁也搜不到你。帮用户入驻/整理资料时**一定要顺手把它写上**，而且要写具体（「能给早期项目做 0→1 的小程序开发，两周内出可用版本」远胜「技术合作」）。

【需要登录】给当前用户加一条链接（不动其它字段）。type 见 LINK_TYPES（website/github/wechat/douyin/shipinhao/email/phone…），visibility 缺省 public。 【例】「把我的抖音加上，设为好友可见」→ type=douyin, url=.

【需要登录】按 url（可加 type 进一步限定）删除当前用户的链接。匹配不到则 no-op。

【需要登录】把当前用户某条链接（按 url 匹配，可加 type 限定）的可见范围改成 public/friends/private。 【例】「把我的手机号改成仅自己可见」。

【需要登录】更新当前用户名下某个产品（仅本人可改）。先用 get_my_products 拿 productId。所有字段可选，只传想改的；links 传则整组替换。 【发布】先过后审：立即生效，后台异步做风控审计，不卡审核。**注意：编辑会把已下架（ARCHIVED）产品重新发布上架**——只想改内容不想上架的，改完再用 set_product_status 下架回去。

【需要登录】关注某位主理人（用户 id）。互相关注即成为好友，对方设为「好友可见」的链接会对你可见。幂等：重复关注 no-op。先用 list_creators / get_creator 拿 id。

【需要登录】取消关注某位主理人。幂等：未关注时也返回 ok。

【需要登录】返回当前用户的关注 / 粉丝 / 好友（互相关注）列表与计数。

【需要登录】列出当前用户的所有私信会话（含未读数 unread、最近一条预览、成员信息）。先用它拿 conversationId 再 read_messages / send_message。 【两种会话】type=DM 是一对一私信；type=GROUP 是平台的破冰介绍群（系统把两位可能互相有用的人和官方号拉在一起，带 title 和成员列表）。**群里不做交换联系方式**，要联系方式在 DM 里走 request_contact_exchange。 【未读】每条自带 unread，别再去找什么「未读总数」工具，加起来就是。

【需要登录】与某位用户开启 1-1 私信会话（已存在则返回原会话，幂等）。可选 productId 标记围绕哪个产品咨询。不能和自己开会话。先用 get_creator / search_people 拿对方 userId。 【返回】conversation（含 id）+ created（这次是不是**新建**的）+ openerSent（服务端是否已自动替你递了开场语）+ opener/openerKind（你设过自定义开场语就带原文 kind=custom；没设时服务端按对方的产品现生成一句，kind=product/generic，原文不回传，别编）。**created=true 且 openerSent=true 时对方已经收到你的开场语了，别再重复问一遍好**——接着说正事即可。开场语内容用 get_my_chat_opener 看，改用 set_my_chat_opener。 【每日开场额度】只有**新建**会话才占额度（回复老会话、别人来找你都不占）。撞上限时返回 429 chat_quota_exhausted，且返回体里直接带出口（额度实况 / 引荐短链与话术 / 积分兑换报价）。**那不是临时故障，今天的额度不会自己回来，不要退避重试**——照返回里的 exits 跟用户说清楚。

【需要登录】读取某个会话的消息。默认返回最近若干条（倒序，含 nextBefore 游标向前翻）；传 after=<messageId> 则增量拉取该消息之后的新消息（正序，用于轮询）。只能读自己参与的会话。

【需要登录】在某个会话里以当前用户身份发一条文字消息。先用 list_my_conversations / start_conversation 拿 conversationId。 【注意】这会真的把消息发给对方——发送前请向用户确认收件人和内容。

【需要登录】把某个会话标记为已读（更新我的 lastReadAt）。

【需要登录】在会话里转发一张站内卡片（与 App 聊天里的「名片/需求卡转发」同源）：type=owner 转某位主理人的名片（把「我自己的名片」发给对方 = 用 get_my_profile 拿到自己的 id 再转），type=need 转某条需求卡。标题/头图/链接由服务端从库里重建可信快照，不接受自定义内容。 【注意】这会真的把卡片发给对方——发送前请向用户确认收件人和卡片对象。

【需要登录】查看某个 1-1 会话的「交换联系方式」状态：exchange = 最近一次交换（status=ACCEPTED 时 contacts 里双方联系方式互见），myContacts = 我会被交换出去的联系方式，canRequest = 当前能否发起新请求。 【组合链】canRequest=true → request_contact_exchange 发起；对方发起的 PENDING → 与用户确认后 respond_contact_exchange 响应；myContacts 为空 → 先用 add_profile_link 补 contact 组链接（微信/电话/邮箱）。

【需要登录】在 1-1 会话里发起「交换联系方式」请求：对方同意后，双方的微信/电话/邮箱等联系方式互见（各自快照，之后改资料不回溯）。要求自己至少填了一条联系方式（no_contact_info 时先用 add_profile_link 补 contact 组链接）。已交换过会报 already_exchanged；对方已有待处理请求会报 peer_request_pending（此时应改走 respond_contact_exchange）。自己重复发起幂等回放。 【注意】这会真的向对方发出请求消息——发起前请向用户确认。

【需要登录】同意或婉拒对方发来的「交换联系方式」请求（exchangeId 从 get_contact_exchange_state 的 PENDING exchange 拿）。accept=true 表示同意：把我的联系方式快照交给对方、同时拿到对方的（结果在返回的 contacts 里），此操作不可撤回——**必须先向用户明确确认**；同意方也需至少一条联系方式。accept=false 婉拒，之后对方可再次发起。重复响应幂等回放。

【需要登录】列出我作为主办方/管理员能管的全部活动（含已发布 / 已取消 / 已结束 / 被下架），每场带 **submissionCount 报名总数 + pendingCount 待处置数 + myRole 我的角色 + 报名配置概况**。 【何时用】「我那几场活动各报了多少人 / 还有多少没处置」——一次调用就答完，不用再逐场查。改活动或看名单前先用它拿 slug / activityId。 【组合链】pendingCount>0 的那场 → list_signup_submissions 看是谁 → bulk_review_signup_submissions 一次处置完。

【需要登录】改我办的活动的**本体信息**（先过后审：立即生效；slug/type 不可改）。先用 list_my_activities 拿 activityId。 【分工——别调错】活动本体（标题/介绍/时间/地点/长图/封面）走这里；**报名表单与报名方式**走 update_organizer_signup_config。 【红线：截止时间只能往后不能往前】把 registrationDeadline 改早，会把正在填的人当场挡在门外，且已开始填的草稿全部作废。用户要「提前截止」时先跟他确认清楚这一点。

【需要登录】取消（下线）我发起的某个活动。已取消 / 已结束的活动不能再取消。

【需要登录】新建一个产品 / 作品，先过后审：创建后立即发布对外可见。slug 可选：不填由服务端按名称自动生成；被占用会自动改派生地址。创建后可用 update_my_product 继续补充链接 / 媒体 / 标签。

【需要登录】把我的产品在「已发布 ⇄ 已下架」之间切换（仅这两个状态互切，其余状态由系统管理）。先用 get_my_products 拿 productId 和当前 status。

【需要登录】用认领码把一个（管理员 / 爬虫预录的）产品认领到当前账号名下。先过后审：认领后立即发布。认领码一般由管理员发放。

【需要登录】设置当前用户的身份 / 来意 persona。可选：GENERAL_PUBLIC（随便看看）/ FOUNDER（发布项目）/ INVESTOR（投资）/ MEDIA（观察趋势）/ RECRUITER（招聘）/ SERVICE_BUYER（买服务）/ PARTNER（谈合作）/ OTHER（其它，需填 personaOther）。 【多重身份】可同时是多个身份（如 主理人+投资人）：persona 是主身份，personas 传全部身份。**注意：这是整组替换——不传 personas 会把用户已设的多重身份收缩成单身份**，改之前先用 get_my_profile 看现状。 【创业者分叉】persona=FOUNDER 时可顺带传 creatorType（创造者类型），驱动默认产品分类与后续填写提示；非创业者忽略。

【需要登录】返回当前用户名下的一人公司主页（任意状态，含已归档 ARCHIVED；PENDING_REVIEW 仅历史遗留数据）。没建过则返回 company=null。 【何时用】改公司资料前先用它读现状拿到现有字段 / slug / 状态。每个用户最多一家公司。

【需要登录】为当前用户创建一人公司主页（每个用户最多一家；已存在则等价于更新）。slug 全局唯一（被别人占用会报 slug_taken）。 【发布】先过后审：立即生效，后台异步风控审计。 【提示】description 越详细，主页内容质量越高。建到了就可以在引导里 complete_onboarding。

【需要登录】更新当前用户名下的公司主页（按 ownerId upsert，所有字段可选但仍要满足 schema：传 slug/name 时格式校验）。先用 get_my_company 读现状。slug 被别人占用会报 slug_taken。 【发布】先过后审：立即生效，后台异步风控审计。

【需要登录】返回当前用户的入驻引导状态：completed（是否已完成）/ persona（身份）/ isFounder / creatorType（创造者类型）/ hasProduct（名下是否有产品）/ hasProfile（bio 是否已填；详细介绍 intro 是选填，不算门槛）/ hasCompany（是否建了公司）。 【何时用】帮用户「完成入驻 / 看还差哪步」时第一步先读它，再按缺口补：选身份(set_persona)→发产品(create_product)→完善资料(update_my_profile，**记得写 canOffer**)→可选建公司(create_company)→complete_onboarding。 【prefill——别从零开始问】返回里可能带 prefill：这个人此前在网页上报过名、或被运营在现场当面录过资料，服务端手里就有一份现成的（含 LLM 通读其报名答卷得出的 understanding 要点）。有它就**当上下文用，能少打很多字**。 ⚠ **预填只减打字，不减追问**：每一项都要念给用户确认，必填项一项都不能跳，`complete_onboarding` 的校验一条都不能绕。prefill 为 null 是常态（大多数人没有）。

【需要登录】校验前置条件后把入驻引导标记为完成（给 onboardedAt 盖戳）。 【前置】必须已选身份 persona；若是创业者（FOUNDER），还需名下至少 1 个产品且 bio 已填（intro 选填不卡），否则报 onboarding_incomplete。 【注意】这是真实状态变更——调用前先 get_onboarding_status 确认各项已就绪，并向用户确认「确实要完成入驻」。

【需要登录】把一张公开可访问的图片 URL 镜像进独行录存储，返回稳定的图片地址。 【何时用】要给「我的头像 / 产品 logo / 产品封面 / 产品图集 / 活动封面」设图时：先用本工具把外部图片 URL 转成独行录地址，再把返回的 url 填进 update_my_profile(avatarUrl) / update_my_product(logoUrl·coverUrl·gallery) / create_product / create_organizer_activity(coverUrl·posterUrls)。 【限制】仅支持公网 http(s) 图片，带大小/类型/SSRF 校验。

【需要登录】给某产品打 1–5 星 + 可选文字评价（一人一产品一条，再次调用即编辑）。不能评价自己的产品。先用 get_product / search_products 拿 productId。

【需要登录】给某位主理人写一段推荐口碑（无星级，文字必填 ≥4 字，可选关系 relation）。不能给自己 / 未认领占位号写；互相拉黑时不可写。一人对一人一条，再次调用即编辑。

【需要登录】删除当前用户对某对象（产品/园区/主理人）的评价（幂等：没有则 no-op）。

【需要登录】拉黑某用户：双方互不能私信，并自动解除互相关注。处理骚扰时用。幂等：重复拉黑 no-op。

【需要登录】取消对某用户的拉黑。幂等：未拉黑时也返回 ok。

【需要登录】列出当前用户拉黑的所有用户。

【需要登录】举报违规内容 / 用户。targetType 决定举报对象，reason 是原因。审核后台会处理。

【需要登录】返回当前用户设置的兴趣标签（用于回显，改前先读）。

【需要登录】设置当前用户的兴趣标签（+ 可选自由描述），用于计算兴趣向量、驱动 personalized_feed 的千人千面排序。一句话即可调教推荐，是个性化读写闭环的写入端。整组替换。

【需要登录】返回当前用户的通知开关：follows（新增关注）/ dms（私信）/ activities（活动）/ drops（新品播报）/ matches（新需求与我价值匹配时的撮合推送）/ nudge（未读私信触达提醒）。

【需要登录】更新当前用户的通知开关（只传想改的，其余保持不变）。

【需要登录】列出当前用户的 agent / CLI 接入设备（名称 / 客户端 / token 末 6 位 / 创建·最近使用·过期·吊销时间）。吊销某台用 revoke_my_device。

【需要登录】吊销当前用户的某台接入设备（其 token 立即失效）。先用 list_my_devices 拿 deviceId。返回 revoked 是否实际吊销了一条。

【需要登录】返回当前用户与目标用户的关系：following（我是否关注 TA）/ followedBy（TA 是否关注我）/ isFriend（互相关注）/ isSelf。决定是 follow 还是已是好友（好友可见对方「好友可见」链接）。

【需要登录】返回当前用户参与的某个会话的详情（成员 / 关联产品 / 最近预览 / 我的已读位 / 是否静音）。只能查自己参与的会话。读消息用 read_messages。

【需要登录】检查当前用户是否满足发起活动的前置条件。**两条轨，满足任一即可**：轨 A 主理人 —— 资料完善（bio + intro≥10 字）且至少 1 个已发布产品；轨 B 主办方 —— 入驻已完成 + 主办方资料四项齐全（主办方名称 / 联系人姓名 / 联系电话 / 一句话介绍）。ok=true 时 via 说明走的是哪条（owner=轨 A，organizer=轨 B）。 【ok=false 的 reason】profile_incomplete = 入驻还没走完（入驻本身就会强制填 bio/intro，所以这条等于「先去完成入驻」）；organizer_profile_required = 入驻完了但缺主办方资料四项——这是实际最常见的一条，只差一个已发布产品的轨 A 用户也会落到这里（对正要发活动的人来说，填四项资料比再发布一个产品近）；no_published_product = 老枚举，现口径下基本不会返回。 【怎么补】想走轨 A 就用 create_product 发布产品。缺主办方资料**这里没有对应的写工具**，别拿别的工具去试——那四项要走 POST /v1/me/organizer-profile，联系电话必须过短信验证码，agent 端做不了；请引导用户去 App 或网页版填「主办方资料」（四项一次填完，不拆步、不跳过）。 发起活动（create_organizer_activity）前先用它，免得白填。

【需要登录】用邮件令牌把某个（爬虫预录的）占位创客号名下的全部产品 + 会话一次性转到当前账号。令牌来自冷启动外联邮件里的链接（/u/{creatorId}?

【需要登录】以当前用户身份发布一条需求（需求互换核心 loop 的起点）。先过后审：发布即展示在需求信息流，后台异步风控，不用等审核。发布后系统自动做向量撮合、推送给最匹配的主理人；也可以随后用 get_need_recommendations 主动看谁能满足。 【写好它】title 认真写清楚要什么（3–120 字）；detail 越具体，撮合和搜索越准。示例：「找人合作把我的效率工具做出海版本」「找能提供小程序代开发的主理人」。发布是公开动作：发布前把拟发的 title / detail 给用户过目确认。 【挂载】contextType+contextId 可把需求挂到自己的产品/活动/某人（成对传）。配图先用 upload_image_from_url 拿稳定 URL。

【需要登录】编辑自己发布的需求（仅 OPEN 状态可改）。可改 类型 / 标题 / 详情 / 配图，只传想改的。先用 list_my_needs 拿 needId。 【失败语义】非本人 403 not_your_need；非 OPEN（已取消或历史遗留关单）409 need_closed。被接洽/被承接不改变需求状态，仍是 OPEN、仍可编辑。

【需要登录】把自己的需求移出信息流（状态与接洽不变、不删除）。需求不会因被接洽或时间流逝自动下架，想暂时不展示就用它。之后可用 reopen_need 免费重新展示，两者成对可反复切。 【失败语义】非本人 403 not_your_need；已取消/完成 409 need_closed。

【需要登录】把手动下架过的需求放回信息流（与 unpublish_need 成对，免费、可反复切）。 【失败语义】非本人 403 not_your_need；已取消/完成的不可重开 409 need_closed（那种情况请用 create_need 重新发布）。

【需要登录】发起人取消自己的需求（终态，不可再重开/编辑）。只是暂时不想展示请用 unpublish_need（可逆），不要用本工具。 【失败语义】非本人 403 not_your_need；已完成 409 need_already_completed；已取消 409 need_closed。

【需要登录】硬删除自己的需求（连同全部接洽记录，不可恢复）。日常收尾优先用 cancel_need（保留记录）或 unpublish_need（可逆下架），删除只用于确实要抹掉时——调用前先向用户确认。 【失败语义】非本人 403 not_your_need。

【需要登录】对某条需求「找他聊聊」：与发起人建立 1-1 会话并登记接洽。任何人都能接洽、人数不设上限，需求不会因被接洽而下架。幂等：重复调用只返回已有会话。 【组合链——这是关键】返回 conversationId，直接接 send_message 在该会话继续谈；开聊前可先 get_conversation_needs 一次拿全双方需求上下文。谈妥交付后双方各调一次 complete_need 完成。 【失败语义】不能接洽自己的需求 400 cannot_contact_own_need；404 need_not_found；**429 chat_quota_exhausted = 今天新开会话的额度用完了**（回复老会话不受影响），返回体自带出口，别退避重试。

【需要登录】在某个接洽会话里点「完成需求」。**双方各确认一次**：发起人和承接人都要在同一会话里各调一次本工具，双方都确认后该承接才置 COMPLETED；只有一方调过时处于等待对方确认状态（看返回的 authorDoneAt / claimerDoneAt）。 【前置】conversationId 必须是 contact_need 建立的那个会话。确认是真实状态变更，调用前先向用户确认「事情确实办完了」。 【失败语义】非该需求当事人 403 not_party_to_need；会话没绑这条需求 409 no_claim_for_conversation；已完成 409 need_already_completed；已取消 409 need_closed。

【需要登录】列出当前用户发布的需求（现行状态只有 OPEN / CANCELLED；IN_PROGRESS / COMPLETED / EXPIRED 仅历史遗留数据——完成态记在每条承接（claim）上，需求不因某条承接完成而关单），时间倒序、游标分页。编辑 / 下架 / 取消 / 拉推荐之前先用它拿 needId；查某条承接是否完成用 get_conversation_needs 看 claim 状态，别按 status=COMPLETED 过滤。信息流里不会出现自己的需求，盘点自己的一律走这里。 【下架 ≠ 改状态】手动下架只把需求移出信息流，status 仍是 OPEN——**判据是每条返回里的 displaying 布尔**（服务端按服务器时钟算好的），别拿 status 猜。只想看还在展示的传 displaying=true。

【需要登录】对**自己发布的**某条需求拉个性化推荐：谁最可能满足它（一人一卡，按「对方能提供的 ↔ 我的需求」向量匹配 + 回复率/活跃度加权，含 matchScore / matchReason / authorNeeds）。这是「发完需求主动出击」的工具，不用干等撮合推送。 【组合链】看中某人 → contact_need 对方的需求或 start_conversation 直接开聊。续拉传回 nextCursor，并把已看过的需求 id 放进 seen 软性下沉。 【越权】只能查自己的需求，别人的会被拒（not_your_need）。

【需要登录】聊天前情报一步到位：一次调用同时返回 (1) conversationNeed——该会话绑定的接洽需求（含双方完成握手状态 authorDoneAt / claimerDoneAt，判断能否 / 是否该 complete_need）；(2) peerOpenNeeds——对方最近的 OPEN 需求（最多 10 条，了解对方还在找什么，找合作切入点）。没绑需求时 conversationNeed=null。 【组合链】list_my_conversations 拿 conversationId → 本工具补上下文 → send_message 回复 / complete_need 确认完成。只能查自己参与的会话。

【需要登录】返回某对象的分享卡 manifest：**shareText（现成的分享文案）+ link（落地页链接）**，外加卡片页数/版式元数据。agent 帮用户「把我的主页/需求分享出去」时用它拿文案和链接，可直接转发到任何渠道。 【kind 取值】owner（主理人主页卡，id=用户 id，自己或他人皆可）| need（需求卡，id=需求 id）| card（我的个人名片卡，仅本人，id 固定传 "me"）| position（我的定位卡，仅本人，id 固定传 "me"；定位栏唯一的分享出口）| onboarding（入驻完成卡，id 固定传 "me"）。 【注意】返回里没有图片 URL——卡片图片的渲染接口是登录态 + private 缓存的站内接口，不要自己拼 image URL 当公开资源发给第三方；对外分享一律用 shareText + link。 【失败语义】对象不存在返回 found=false；kind=card / onboarding 而 id 不是 "me" 报 403。

【需要登录】【何时用】用户说「帮我报这场」时调它。只传**这次要新填/要改的答案**即可：handler 自己会先读一遍我在这场活动的全部现值（上一版提交 + 跨表单复用的资料覆盖层 + 主页/公司/产品推导），打上你的补丁后提交**全集**。 【组合链】get_signup_activity(slug) 看 viewer.

【需要登录】【何时用】用户问「我报过哪些 / 那个赛事结果出来没 / 主办方回我了吗」时调它。一次给全：我报过的所有场次（最多 50 条，新的在前）＋ 每一场的投递状态与**主办方处置结果**（reviewStatus：PENDING（待初审） | REVIEWING（初审中） | SHORTLISTED（已入围） | WAITLIST（候补） | REJECTED（未通过） | WITHDRAWN（已撤回））＋ 主办方留言 reviewNote。App 上这是「我的报名」那一屏。 【组合链】看到某场 reviewStatus=SHORTLISTED 或 reviewNote 里要求补材料 → get_signup_activity(slug) 看还缺哪几题 → submit_signup(slug) 补交（重新提交会覆盖上一版）。想一次盘所有在报的场次还缺什么 → get_signup_gaps。 【口径/坑】① 默认**不返回答案全文**（50 条里全是本人的手机号/微信/证件字段，没必要整份灌进上下文），只给答了哪几题的 key 列表；确实要看内容再传 includeAnswers=true。② submission.

【需要登录】【何时用】用户随口给了一条以后每场报名都要用的信息（「我微信是 xxx」「团队 3 个人」「所在城市杭州」），先落进跨表单复用的**报名资料覆盖层**，下次报任何一场都会自动带出来。 【组合链】get_signup_gaps 拿到 missingCombined（跨场去重后的待答清单）→ 问用户 → 本工具一次性写进覆盖层 → 之后每场 submit_signup 都不用再问。key 必须用 get_signup_activity / get_signup_gaps 返回的那个 key（跨活动稳定，别自造）。 【口径/坑】① 这里**只写报名场景的覆盖层**，绝不改主页/公司/产品本体——改那些走 update_my_profile。② 只收文本；文件类答案（BP 等）只能走 App 的上传通道，这里写进去会把已传文件的记录顶成一串文本。③ 敏感题（证件号）刻意不做跨表单记忆，别往这儿写。④ 写入的值不会回显在返回体里（只回 key），这是刻意的隐私收口。

【需要登录】【何时用】用户想一口气报好几场（或问「我现在能报的都缺什么」）时调它。**这是 agent 独有、App 永远不会有的接口**：一次算完多场的缺口，并把同一个题目跨场去重合并——「姓名、微信、一句话项目介绍」问一遍就够，不用一场问一遍。 【组合链】① 不传 slugs 就自动取 list_signup_feed 前 N 场**我还没报的**；② 拿 missingCombined 一轮问完用户；③ 通用项 update_my_signup_profile 一次落库；④ 逐场 submit_signup（这时基本零缺口）。想看某一场的完整题面再 get_signup_activity。 【口径/坑】① missingCombined 里每项带 activities=[这几场都要]，问一次可以覆盖多场——**别自己在上下文里做集合运算**，那既费 token 又容易漏。② fillable=false 的项是附件题，agent 传不了，只能提示用户去报名页/App 传。③ 已报过的场次（submitted=true）默认不进结果，除非显式点名在 slugs 里。④ 一次最多 10 场，服务端分批取，别指望它当全站扫描器用。

【需要登录】【何时用】用户说「帮我发一场分享会 / 建一个报名」时调它。这是站内建活动的**唯一正确入口**：活动本体 + 报名配置一次写入，建完立刻进报名 feed、报名页立刻可用（先过后审，不留灰度闸）。 【组合链】建完拿 slug → signupPageUrl 直接发给用户去转发 → get_organizer_activity(slug) 读现值 → update_organizer_signup_config(slug) 改题目/联系方式 → 报名进来后 list_signup_submissions(slug) 看名单 → bulk_review_signup_submissions 批量处置 → issue_signup_export_link 导出。活动本体（标题/时间/地点/截止/名额）改动走 update_activity。 【口径/坑】① **别逐字段构造几十题的表单**：不传 extraQuestions 就落系统基线四项（姓名/手机号/微信号/一句话项目介绍，全是跨活动复用的稳定 key，报名者一键带出）；额外题只要一行一个中文题面丢进 extraQuestions，key/type 由服务端生成。真要做复杂表单让用户去 opcmenu.

【需要登录】【何时用】改配置前的**读-改-写第一步**，或用户问「这场我是怎么配的 / 报名表都有哪些题」。返回活动本体现值 + 报名配置（题目表 formSchema、外部表单地址、类目、联系方式二维码）+ 我在这场的权限档（myAccess: OWNER / ADMIN / PLATFORM_ADMIN）。 【组合链】本工具读现值 → update_organizer_signup_config(slug) 改报名配置（题目/类目/联系方式）；活动本体（标题/时间/地点/截止/名额）改动走 update_activity。要看报名进来多少人走 list_signup_submissions。 【口径/坑】① activityRef 收 slug 或活动 id 都行。② 只要能读就返回，**活动被下架/取消后照样能读**——报名的人还等着主办方联系。③ 返回里没有任何报名者数据。④ 不返回 learnedPageKeys（客户端学表单的内部账本，对你没用）。

【需要登录】【何时用】用户要改报名表的题目、换报名类目、贴外部表单地址、换答疑群二维码时调它。**立即生效，不留灰度闸**。 【组合链】get_organizer_activity(slug) 读现值 → 本工具传**要改的那几项**（缺省即不动）→ 再读一次确认。改完可以把 signupPageUrl 发给用户去转发。 【口径/坑】① **本工具改不了报名截止时间**——截止在活动本体上，改它走 update_activity。而且：**「截止绝不能提前封口」是这个产品的红线**，把截止改早会把此刻正在填表的人当场挡在外面，任何「提前收口」的请求都必须先跟用户确认清楚后果。② formSchema 是**整表覆盖**，不是打补丁：传了就以你这份为准，漏写的题会被删掉（而且进「不再学习」名单，客户端以后也不会把它学回来）。稳妥做法是先 get_organizer_activity 拿到现有 formSchema，改完整份传回来。③ hostedEnabled=true 而一道题都不给时，服务层会落基线四项（姓名/手机号/微信号/项目介绍），不会留一张空表。④ 投递通道（adapterKey/deliveryMode）是平台侧基建，主办方改不了，也不该改。⑤ 改 signupUrl 会让投递方式跟着重算（有外链→用户设备代填投递；纯托管→站内收）。

【需要登录】【何时用】主办方问「报了多少人 / 今天新增几个 / 有哪些做 AI 的报了」时调它。返回名单页 + 首页概览（总数 / 今日新增 / 待初审 / 渠道分布）。 【组合链·批量处置，这是 agent 对 web /pro 的碾压位】list_signup_submissions(slug, q='Agent') 拿到 items[].

【需要登录】【何时用】用户明确说「我要联系这个人 / 把他的微信给我 / 他报名时写了什么」时才调。**这里才解密联系方式**（微信/邮箱/手机），list_signup_submissions 默认是不给的。 【组合链】list_signup_submissions(slug, q=…) 定位到某一行 → 本工具取该行完整答案与联系方式 → review_signup_submission 单独处置他 → 想直接在站内找他聊就用 start_conversation（仅当他是站内注册用户，见返回的 user.

【需要登录】【何时用】用户对某一个人下结论（入围/候补/未通过）时调它。**处置结果报名者在「我的报名」里看得见**，reviewNote 是直接给他看的一句话。 【组合链】list_signup_submissions 定位 → get_signup_submission 看清这个人 → 本工具处置。一次要处置很多人用 bulk_review_signup_submissions（那边有 preview 可以先过目）。 【口径/坑】① 执行前把「谁 → 改成什么」念给用户确认——报名者那头会看到。② reviewNote 缺省=不动之前写的留言，传空串会**清空**它。③ 只动报名结果，不碰投递状态（那是「有没有投到源表单」，两码事）。④ 取值：PENDING（待初审） | REVIEWING（初审中） | SHORTLISTED（已入围） | WAITLIST（候补） | REJECTED（未通过） | WITHDRAWN（已撤回）。

【需要登录】【何时用】用户说「把做 AI 的都入围、其余候补」这类整批操作时调它。**这是 agent 相对 web /pro 最大的效率差**：那边要勾 200 个复选框。 【组合链】list_signup_submissions(slug, q='Agent') 拿 ids → 本工具 preview=true **不落库**，返回「将被改的 id + 昵称 + 当前状态」念给用户 → 用户确认后 preview=false 真正执行 → 剩下的人换个 reviewStatus 再来一次。 【口径/坑】① **执行前必须把名单念给用户确认**——处置结果报名者在「我的报名」里立刻看得见，改错了收不回来。preview=true 就是为这一步设计的（它是 App 那个确认弹层在 agent 端的形态，不是可以省掉的一步）。② 返回体自带 diff：requested / updated / ignoredIds——不属于这场活动的 id 会被服务层**静默忽略**，传 200 个只改了 197 个时，是哪 3 个掉了这里如实告诉你。③ reviewNote **不接受空串**（zod 直接封死）：批量清空 200 条留言且无处恢复，风险太高；不传就是不动。④ 一次最多 200 个 id。⑤ 只动报名结果，不碰投递状态。

【需要登录】【何时用】用户说「把报名表给我 / 导出名单 / 我要下载 Excel」时调它。返回一条**一次性签名下载链接**，用户自己在浏览器里打开就下载 CSV。 【组合链】list_signup_submissions 先给用户看数量和概览 → 确认要整份表格 → 本工具铸链接 → 把 url 原样发给用户。想按人处置不需要导出，直接 bulk_review_signup_submissions。 【口径/坑】① **绝不返回 CSV 正文**：一次最多两万行、每行带解密后的手机号微信号，那种东西不该进模型上下文。工具只给链接。② 链接**10 分钟有效、且只能成功打开一次**——换过一次即废（它被转进工作群就等于整份手机号裸奔，所以是真一次性）。用户没在 10 分钟内打开就再调一次。③ 提醒用户：这份表里全是报名者的联系方式，别往群里转发。④ 打开链接时会再校验一次权限（票只证明 10 分钟前你有权限，不是授权本身）。⑤ 撞顶两万行时 CSV 末尾会有一行中文说明，让用户看一眼。

【需要登录】【何时用】任何「今天怎么样 / 有什么要处理的 / 日报 / 早上问一句」的场景**都从这里开始**。它把 App 里分散在六屏、且必须由用户自己想起来去点的六件事并成一次返回： ① 未读私信数 ② 最近 7 天谁看过我（计数 + 具名前几位）③ 今日开聊额度 ④ 7 天内截止且我还没报的场次 ⑤ 定位栏「最该做的三件事」⑥ 我办的活动待审报名数。 这是 agent 面独有的形态——App 里没有、也不该有这一屏；一次调用换一段话。 【组合链】 · unread>0 → list_my_conversations 找出是谁 → read_messages 看内容 → send_message 回。 · attention.

【需要登录】【何时用】用户说「帮我拉几个朋友进来」「发个邀请给他」，或者开聊额度不够、需要长期加额度时。返回形状几乎就是为 agent 设计的：5 条短信话术 + 2 条微信话术 + 专属短链 + 三段统计（点开 / 注册 / 已入驻）。 【组合链】拿到 smsTemplates / wechatTemplates → **按收件人挑一条**（label 就是场景：通用 / 发给同行 / 发给老朋友 / 发给还没创业的 / 发给投资人媒体）→ 交给用户本人去发（短信从他手机发出去才有人信）。发完隔天再调本工具看 stats.

【需要登录】【何时用】只在开聊额度用尽、用户**明确要求**今天就多聊一个人时。花 500 积分换今天 +1 次开场，每日限 1 次。这是应急安全阀，不是常规出口。 【必须先征得同意】**agent 不许自动兑换**。先把「这要花 500 积分」原话念给用户，拿到明确同意再调。撞额度墙时 start_conversation / contact_need 的失败返回体里已经带了这个出口和你的余额，照着念即可。 【组合链】兑换成功 → 立刻 start_conversation 把这一次用掉（额度只加今天，过夜作废）。不想花积分 → get_my_invite 走引荐（那是永久加额度，兑换只加一天）。 【口径/坑】 · 两种失败都是**终态，绝不重试**：409 insufficient_points（余额不够）/ 409 chat_quota_redeem_limit（今天已经兑换过了）。返回体里会带上当前额度和余额，直接转述。 · 如果你刚调过一次然后超时了，再调撞到 chat_quota_redeem_limit —— 那说明**上一次其实成功了**（每日上限靠全表唯一键原子兜底）。读返回体里的 quota 确认，不要当失败。 · 额度只拦「新开一个会话」；回复老会话、别人来找你都不受影响。 · 积分体系 2026-07-03 已从用户面下线，这是全站唯一一个还露在 agent 面的积分动作。别去找别的积分工具，没有。

【需要登录】【何时用】用户问「最近有人关注我吗」「谁看了我的产品」，或者你要给他找**主动开聊的由头**时。三路合并：产品被浏览 / 主页被浏览 / 需求作者页被点开。 【组合链】这条链是本工具存在的全部理由，App 里要三次点击两次跳转： named[].

【需要登录】【何时用】用户在对话里透露了角色信息就顺手写进去：在融资（轮次/金额/要求）、我是投资人（类型/关注轮次/单笔规模/赛道）、我代表机构（园区/赛事/企服，能给什么资源）、我是来找人的媒体/HR/采购/合作方、我还在上学、我的创业阶段变了。这些字段决定他出现在首页哪个 tab、被谁搜到。 【组合链】写完 fundraising.

【需要登录】【何时用】用户问「我现在到哪一步了」「接下来该干嘛」「帮我把这周能做的都做了」。返回五级主线的当前等级、六维画像、称号与总分，以及全部任务的完成态与 nextUp（最该做的三件事）。 【组合链·代办】nextUp 里每条任务都带 suggestedTool——**这是 agent 面相对 App 的关键差别：App 的 CTA 只能把人跳到那一屏让他自己动手，你能直接把这件事做完。** 对照表： · 写「我能提供什么」/ 一句话说清项目 → update_my_profile(canOffer)（partner.

【需要登录】【何时用】用户完成了平台观测不到的**线下动作**：注册了公司、拿到商标 / 软著 / ICP 备案、收到第一笔钱、开始盈利……由他自报，平台不审核（可以顺手把备案号/注册号填进 note）。 【组合链】打完勾返回体自带**涨分回执**（打勾前后的总分与段位、本次新完成了哪些任务）——直接念给用户，别再调 get_my_positioning 前后各拉一次自己减。段位变了就顺势给下一步：get_my_positioning 看新一级的任务，或按 nextUp 的 suggestedTool 直接接着做。 【口径/坑】 · **只有 manual 类任务能打勾**，auto 类（发产品、聊过多少人、发过几条需求）是平台记录算出来的，硬打会 400 task_not_manual——那不是 bug，是防止分数变成自助填空。 · 合法 taskKey（从服务层的 manual 任务集合生成）：build.

【需要登录】【何时用】「我在产业链的什么位置」「我的上游下游是谁」「这家公司的上下游有哪些」。返回以某个节点为锚的自我中心视图：上游若干环 + 锚点自己的链位 + 下游若干环，每环带成员。 【组合链·多跳】 · **不传 subjectType/subjectId 就直接落在「我」身上**（我 + 我的已发布产品里的默认锚点），一次调用就位；返回体里带 myAnchors 告诉你我还有哪些锚点可切。 · 拿链上**任意成员的 id 再调本接口**就是下一跳（「上游的上游」）——这就是递归展开产业链的全部方法。 · 先 metadataOnly=true 探方向（只出类别和计数，不判成员，快且省），锁定要看的那一类再用 list_chain_group_members 翻它的成员。 · 成员 members[].

【需要登录】【何时用】get_chain_anchor 某一类只给了一屏预览，用户想再看几个时。按 groupId 单独翻那一组。 【组合链】get_chain_anchor 拿 groupId + direction → 本工具翻页 → items[].

【需要登录】【何时用】**全平台唯一一个「自由文本即写入」的接口，正是 agent 的主场。** 用户在对话里刚说完自己在干什么，你把那段话整理成一句 describe 直接提交，LLM 据此推出链位并把他并进链网。App 里这一步要用户自己打开定位页、切到产业链、想一段话再打字。 【组合链】提交成功 → get_chain_anchor 立刻能看到他新的上下游环 → 从环里挑人 get_creator → start_conversation。不传 subjectType/subjectId 就是给「我」归位；给产品归位就传 subjectType=product + 产品 id（必须是我自己的产品，先 get_my_products 拿 id）。 【怎么写 describe】把用户原话整理成「给谁做什么、用什么做、做完交付什么」，5~500 字。**别替他编**——他没说的上下游不许你加。 【口径/坑】 · 归位记 source='declared'：用户拍板的链位钉死，后续系统自动重推**不会覆盖**它（画像的其它字段照常刷新）。 · 失败分支返回体自带出口，照着念：position_unclear（看不出你在干什么，要补「给谁做什么」，**别重试**）/ position_relations_unclear（看得出做什么、看不出上下游是谁，要追问「活儿从谁手上接、做完交给谁用」，**别重试**）/ chain_source_changed（你刚改过资料或产品，原样重提一次即可）/ llm_unavailable（判链位的模型不在，过几分钟再试，别说成描述有问题）。 · 这是一次完整的 LLM 重推，**慢且花钱**。同一段描述重复提交会被本工具去重（返回 deduped=true），别靠重复调来「催」。 · 归位会改变他在别人产业链视图里的位置——这是对外可见的写操作，不是本地设置。

【需要登录】【何时用】要改开场语之前先读现状；或者用户问「别人点找我聊聊时会收到什么」。 【组合链】读完 → 觉得该改就 set_my_chat_opener 写一句更像人说的。写之前先 get_my_card / get_my_products 读一遍他的「我能提供什么」和产品，写出来的话才有具体内容。 【口径/坑】opener=null 表示他没自定义，实际发出去的是 effective（全站默认那句）。这不是「没设置好」，默认那句本来就够用。

【需要登录】【何时用】这是**纯文案活，正是 agent 最该替用户干的事**：读一遍他的「我能提供什么」和产品，替他写一句像真人说的开场白。 【这句话会自动发出去】别人点「找 TA 聊聊」时，服务端会**替你自动发出这一句**作为第一条消息（只在新建会话时发一次，不会刷屏）。所以它是一条**自动广播通道**，不是一条普通私信。 【怎么写】朴素、具体、不做当场能被戳穿的断言。三条硬规矩：① 不写「我懂你想要什么」这类你按按钮那刻根本不知道的话，对方回一句「那你说说」就穿帮；② 不用对仗押韵金句——顺口正是模板和 AI 文案的指纹；③ 说清「我从哪儿看到你的」，这是真的、可验证的，也天然给了对方话头。**不许出现任何「我是 AI 助手 / 自动发送」之类的标识**（产品口径：这就是他本人说的第一句话）。 【组合链】get_my_card（读 canOffer / 产品）→ 本工具写 → get_my_chat_opener 复核 → 之后 start_conversation 开的每个新会话都会自动带上它。传 null 或空串 = 恢复全站默认。 【口径/坑】 · 上限 120 字，超了报 chat_opener_too_long（400，终态，改短再提）。 · **不许夹联系方式和外链**：手机号 / 微信号 / QQ / 邮箱 / http 链接一律拒（chat_opener_has_contact）。这是自动广播面，放开就成了「加我微信卖课」的免费群发口。要换联系方式走双同意的 request_contact_exchange。 · 过敏感词闸（与私信同一把尺），命中报 content_rejected（400，终态，换写法，别原样重试）。

【需要登录】【何时用】用户说「这个产品我先存着 / 关注一下 / 回头再看」。关注的是**产品**，不是人（关注人用 follow_creator，那个才影响好友关系和「好友可见」链接）。 【组合链】search_products / list_service_products / get_product 拿到 productId → 本工具关注 → 之后用 get_my_card 看我关注了哪些（关注列表并在名片里，没有单独的列表工具）→ 想找主理人聊就 get_creator → start_conversation。 【口径/坑】幂等，重复关注 no-op。只能关注**已发布**的产品，找不到或已下架报 404。关注是单方面的、对方看不到通知，不算打招呼——真想让对方知道就去开聊。

【需要登录】【何时用】用户说「这个不用留着了」。 【组合链】get_my_card 看当前关注了哪些 → 本工具取关。 【口径/坑】幂等，本来就没关注也返回成功（不报错）。对方永远看不见你关注过或取关过。

【需要登录】查看独行录合作目标、待我做/我派出的任务、待回应合作邀请。任务保留目标与指派人，便于持续跟进。目标列表最多返回 limit 条并给总数，goalOffset 按 nextOffset 翻页（只影响目标列表）；任务 reachingLimit=true 时可能还有，按 goalId 调 list_collaboration_tasks 查看。邀请最多 50 条。读任务会幂等补齐周期任务的期次，故不是纯只读。不会读取或标记安排。下一步：get_collaboration_goal 看目标详情；set_collaboration_task_status 回报进展；respond_collaboration_invite 回应邀请；安排另用 get_my_dispatch。

【需要登录】按 assigned_to_me（待我做）或 assigned_by_me（我派给他人）列独行录任务；done=true 查看已了结记录，goalId 缩小到某目标。归档目标不在此列表，归档目标任务用 get_collaboration_goal。任务查询会幂等补周期期次。reachingLimit=true 表示可能截断，不代表总数。

【需要登录】看独行录目标详情、我的权限、合作人、任务。服务校验成员权限；includeClosed=true 包含已了结任务，最多 200 条，reachingLimit 表示可能截断。读任务会幂等补周期期次。创建任务用 create_collaboration_task，发起人改目标用 update_collaboration_goal。

【需要登录】创建一个持久的独行录合作目标；用户成为发起人。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 先 get_my_work 核对已有目标，再创建；返回 id 用于 get_collaboration_goal/create_collaboration_task。

【需要登录】发起人更新目标标题、意图、截止或状态 ACTIVE/COMPLETED/ARCHIVED。归档后目标不再出现在默认待办。省略保留，intent/dueAt=null 清空。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_collaboration_goal 核对。

【需要登录】在独行录目标中创建任务；assigneeId 省略为自己，指定他人必须是目标合作人，会通知对方。用户授权派给该人后才调用。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 创建前后用 get_collaboration_goal 核对。

【需要登录】更新任务标题、描述、截止；换被指派人需要指派权限且可能通知新负责人。权限由服务校验，省略保留，detail/dueAt=null 清空。状态用 set_collaboration_task_status。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_collaboration_goal 核对任务。

【需要登录】被指派人可设 TODO/DOING/DONE/DECLINED；只有指派人可设 CANCELLED。DONE/DECLINED 的 note 会作为完成留言/婉拒理由并通知指派人。不能代替他人宣称工作已完成。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 list_collaboration_tasks(done=true) 或 get_collaboration_goal(includeClosed=true) 核对。

【需要登录】目标发起人向指定站内用户发出合作邀请，会通知对方。必须已有用户对邀请对象和内容的授权。仅支持站内定向邀请；返回不含手机号或可转发邀请令牌。服务会复用尚有效的同人待回应邀请；并发无持久去重保证。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。

【需要登录】回应 get_my_work 返回的本人定向合作邀请。接受会加入目标并向合作人公开参与关系；婉拒后邀请不再待处理。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 接受后用 get_collaboration_goal 核对，待回应列表用 get_my_work。

【需要登录】查看安排路径、建议接洽的人/活动、等待结果反馈的安排和对方来找我的请求。仅服务端灰度已开启的账户可用。此调用会将展示的当前建议标记为已看，影响后台自动换人，故不是纯只读。fillStatus=FILLING 可稍后重查；FAILED 如实报告失败，不自动重新汇报。接受建议用 accept_dispatch_arrangement，反馈用 set_dispatch_outcome。

【需要登录】把用户确认的现状/目标交给独行录排安排：首次建路径，后续追加汇报并重排未接受部分。会调用平台 LLM、写入记录，可能后台排人和发通知，需灰度已开启。按用户限流，提示汇报过于频繁时不要立即重试。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 的 reports 核对是否已收到，FILLING 时等候后查询。

【需要登录】接受 get_my_dispatch 的建议。MEET 会真实建会话并以本人名义发送 opener；省略 opener 会发送平台预写开场白，先展示内容并取得用户授权。ATTEND 会尝试报名，但本工具不证明报名成功，始终返回 signupVerificationRequired=true；按 next 用 get_signup_activity 核对实际报名方式和状态，必要时 list_my_signups 核对投递结果。hasSignupRecordHint 仅表示有记录，可能只是外部留资、投递失败或取消；openSignupSlug 为空也不证明完成。外部表单仍须完成源站提交，缺资料时再用 submit_signup。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 服务只对完成后的重复接受短路，不保证并发去重。

【需要登录】拒绝尚未接受的建议。SWAP 换一个；WRONG_DIRECTION/OTHER 可能重排；HAVE_ALREADY/NOT_NOW 跳过这一步。可能调用平台 LLM、后台排人和通知。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对新安排。

【需要登录】对已接受的安排反馈用户告知的结果：HELPFUL 有帮助、OK 一般、NO_REPLY 没回复、NO_SHOW 没聊上、NOT_FIT 不合适。可能完成步骤、安排下一步或补排人，消耗平台 LLM 并可能通知。不要根据已读或时间猜测用户结果。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对。

【需要登录】用户明确表示这步自行搞定/不再需要时跳过，终结该步骤未接受建议并推进后续步骤，可能触发平台 LLM 排人。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对。

【需要登录】回应 get_my_dispatch.