个人需求登记

personal-requirement-refined 核心定位

只处理“别人提给这个伙伴的需求/事项”的登记与留痕。

目标是：

帮伙伴把收到的需求沉淀到个人需求表 保留原始上下文，方便后续分诊、巡检和蒸馏 不把尚未明确执行的事项误写成团队任务 凭证约定

默认从 {workspace}/.凭证s.yaml 读取统一凭证。

vika_令牌: 维格 API 令牌

若没有 令牌：

可以做抽取、补问、预览 不得假装已经写表成功

环境变量只作为兼容兜底，不作为主路径。

团队目录定位

默认内置团队注册表，用于安装后按伙伴所属团队自动定位目录。详见：

references/team-registry.md references/team-space-map.md references/令牌-bootstrap.md

当前已内置的团队目录映射：

sre1 → fodnKCCP36E8P sre2 → fod43nDVFJSdN dba → fodMuF6A6u095 network → fodLuvh69iR9S 平台 → fodmoWEarqg0G

同时内置成员映射表：

datasheet_id: dst3rQeN6vC9o2Hj4h

成员映射表用于识别伙伴属于哪个团队；团队目录用于建表和复用表，两者不是同一个对象。

首次安装/bootstrap

bootstrap 需要支持安装完成后立即显化初始化提示。

也就是说：

技能 安装完成后：若本地还没有可用的 vika_令牌，安装方或宿主必须立刻向伙伴前台发送初始化引导 后续真实登记需求时：若仍缺 令牌，可继续沿用同一 bootstrap 话术补齐

bootstrap 时需要做到：

能告诉伙伴他应该打开哪个团队维格入口 能告诉伙伴去维格侧获取个人 API 令牌 后再发回 能明确说明：个人需求表会建在其所属团队目录下 能明确说明：若当前季度已有个人表，则直接复用 安装完成后的首次提示应简短直接，不要讲过多实现细节

安装后首条初始化消息模板见 references/安装-init-message.md。 前台显化规则见 references/frontend-messaging-rules.md。

触发条件

出现以下任一意图时触发：

转需求 / 转事项 / 帮我登记 / 刚有人找我 / 帮我记一下 / 记个需求 /register、/record、/需求登记 伙伴在转述别人提给自己的业务诉求、问题、协作请求 语义上明显是在说“这件事先帮我记下来” 不触发条件

以下情况不要走本 技能：

明确是在给别人下发执行任务 明确要求安排负责人、截止时间、验收标准 明确是在反馈任务确认、进度、完成、阻塞 普通闲聊、知识问答、已完成事项汇报

若不确定，只追问一次：

这条你是想让我先登记成个人需求，还是已经要按团队任务派发？

标准流程 Step 1：识别是否为“需求登记”

先判断当前对象是不是“别人提给伙伴的事”，且仍处于收集、澄清、待分诊阶段。

判断标准：

核心问题是“这是什么事、要不要接、归谁看、怎么整理” → 需求 核心问题是“谁来做、何时完成、做到什么算完成” → 任务，不走本 技能 Step 2：抽取字段

至少抽取以下字段：

counterpart_name counterpart_org title description original_message item_type priority_hint found_at

原始消息优先保留，不要过度改写。

Step 3：补问（最多 2 轮）

仅补问真正影响记录质量的缺口，例如：

谁提的 想做什么 紧急程度大概如何 是否有约定时间

避免把聊天变成填表。

Step 4：安装后若未初始化，立即显化 令牌 bootstrap

若当前不存在可用的 vika_令牌：

技能 安装完成后，安装方或宿主必须立刻向伙伴发送一条初始化提示 优先读取成员映射表识别团队 给伙伴返回对应团队的维格入口地址 引导其在维格侧获取个人 API 令牌 拿到 令牌 后自动继续初始化

在后续真实需求登记场景里，若仍缺 令牌，也继续使用同一 bootstrap 流程。

bootstrap 标准话术和入口说明见：

references/令牌-bootstrap.md references/安装-init-message.md Step 5：生成预览并等待真人确认

伙伴明确回复“确认 / 按这个记 / 可以登记 / 就这么写”后才可写表。

Step 6：写入个人需求维格表

确认后，维格相关操作必须优先走包内固定脚本，不要让模型临场拼 API、拼 curl、拼字段。

固定执行入口：

初始化/定位目录/查建表：scripts/设置up-personal-requirement.py 仅建表：scripts/创建-personal-requirement-table.py 写记录：scripts/write-personal-requirement-record.py 配置生成：scripts/生成-personal-config.py

执行原则：

从 {workspace}/.凭证s.yaml 读取 vika_令牌 先读取成员映射表识别伙伴所属团队 再按团队注册表定位目录 在对应团队目录下复用或创建个人需求表 最终通过固定写入脚本落记录

禁止模型自行发挥：

不临时手写维格 API 不临时拼 shell/curl 命令替代固定脚本 不自行猜字段名或表结构

推荐记录内容至少包含：

需求标题 需求描述 对方信息 原始消息 优先级提示 发现时间 当前状态（如：待整理 / 待分诊 / 已登记） Step 7：返回结果

前台只返回对伙伴有价值的稳定结果，不暴露后台执行细节。

成功时：

✅ 已帮你记录到个人需求表，后续可以继续分诊或转团队任务。

失败时：

⚠️ 这次暂时没成功写入，我再试一次，完成后告诉你结果。

输出约束：

不输出脚本命令、API 路径、解析细节、字段映射细节 不输出“我换个方式试试 / 写得有点糙 / 继续查一下接口” 失败时只给摘要，不给内部过程

具体前台话术约束见 references/frontend-messaging-rules.md。

与任务 技能 的边界 本 技能 负责 需求 intake 字段抽取与补问 需求预览与确认 写个人需求表 本 技能 不负责 写团队任务表 派发任务给其他负责人 维护团队任务状态 响应负责人任务回执 需求转任务规则

若伙伴明确表达以下语义：

这个需求现在要安排执行了 把这条需求转成任务 帮我派给某某去做

则不要继续停留在需求登记流程，应改走 task-dis补丁-refined。

转换原则：

个人需求记录保留原样 新建一条团队任务 两边建立关联字段，而不是把需求记录直接改造成任务记录

推荐关联字段：

个人需求表：linked_task_id / linked_task_record_id 团队任务表：source_requirement_id / source_requirement_record_id 强约束 不跳过伙伴真人确认直接写表 没有 令牌 时不得声称已写入 安装完成后若缺 令牌，应主动显化初始化提示，而不是让伙伴自己猜目录和入口 安装完成后初始化提示由安装方或宿主立刻发送，不等待伙伴再次触发 技能 不直接写组级团队任务表 不把模糊需求直接当作任务派发 最多补问 2 轮 先用成员映射表识别 group，再用内置 team registry 定位团队目录，而不是把两者混为一谈 团队目录定位优先走内置 team registry，而不是硬编码空间 前台不得暴露 API/命令/解析/排障细节 前台禁止出现“写得有点糙”“我换个方式查”“我再试试命令”等内部过程表述