get-shit-done 用户画像引擎gsd-user-profiler Agent 的 8 维行为评分与结构化分析规范【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-doneget-shit-doneGSD是一套面向 Claude Code 的轻量级元提示meta-prompting、上下文工程与规格驱动开发spec-driven development系统。为了让 Claude 在每段对话开始时不再是千篇一律的通用助手GSD 引入了开发者画像User Profiling能力通过分析真实会话中开发者的语言模式产出可被 Claude 直接执行的指令化画像。本文以 gsd-user-profiler Agent 定义 为主体结合其评分规则源 user-profiling.md、编排流程 profile-user.md 与 SDK 查询实现完整讲解这个画像 Agent 如何读取输入、按 8 个行为维度逐项打分、如何处理证据与敏感内容、以及最终以何种 JSON 契约产出结果。读完后你将掌握 GSD 画像分析从会话到可执行指令的完整机制也能理解其置信度阈值、引文规则、隐私过滤与薄数据处理策略的设计动机。一、gsd-user-profiler 是什么gsd-user-profiler 是 GSD 系统中的一个专用分析 Agent位于 agents/gsd-user-profiler.md其 frontmatter 声明如下--- name: gsd-user-profiler description: Analyzes extracted session messages across 8 behavioral dimensions to produce a scored developer profile with confidence levels and evidence. Spawned by profile orchestration workflows. tools: Read color: magenta ---三处声明对应三层含义定位它不做任何写入操作仅具备Read工具它的全部工作是读消息 → 评分 → 输出 JSON产出交给编排者orchestrator落盘。触发方式两种 —— 由 profile 编排工作流Phase 3生成或由 standalone profiling 中的write-profile步骤触发。角色契约它的评分依据不是自身经验而是严格应用 user-profiling.md 参考文档中定义的启发式。Agent 定义中反复强调一句CRITICAL必须应用参考文档定义的 rubric不得发明参考文档之外的维度、评分规则或模式参考文档是看什么、怎么打分的唯一事实来源single source of truth。这意味着画像系统的可解释性、一致性与可审计性被刻意设计为规则外置启发式细则集中在参考文档里Agent 只负责忠实执行任何维度漂移rating 超出谱系、证据凭空捏造都被视为违规。二、输入契约被提取的会话消息 JSONLgsd-user-profiler 接收的不是原始会话转储而是已经过流水线加工的结构化消息样本。每条消息结构如下源自 gsd-user-profiler.md 的input段{ sessionId: string, projectPath: encoded-path-string, projectName: human-readable-project-name, timestamp: ISO-8601, content: message text (max 500 chars for profiling) }输入数据有 5 个关键特性直接决定后续评分逻辑纯用户消息系统消息、工具结果、Claude 回复已被剔除仅保留真实的用户消息genuine user messages。统一截断每条消息截断到 500 字符用于画像message_char_limit。按项目比例采样多个项目间按比例抽取样本避免单一项目主导结论。近因加权采样采样阶段已让近期会话过度代表体现最近行为更贴近当前工作风格的假设。典型规模全部项目合计 100–150 条代表性消息。该采样逻辑在 SDK 中有对应实现profile-sample.ts 是gsd-tools profile-sample的 SDK 移植版。源码中limit options.limit || 150、maxChars options.maxChars || 500正是上文中150 条上限、500 字符截断两个默认值的落地实现依赖profile-scan-sessions.ts的会话扫描、profile-extract-messages.ts的isGenuineUserMessage用户消息判别与truncateContent截断等模块。查询处理器的完整注册关系记录在 QUERY-HANDLERS.md其中profile-sample、write-profile等均以 kebab-case 名称注册为 SDK query 子命令。三、评分参考必须全文阅读的 Heuristics RubricAgent 的reference段指向~/.claude/get-shit-done/references/user-profiling.md仓库内对应 get-shit-done/references/user-profiling.md并要求在分析任何消息之前全文读入。该文档定义四类要素8 个维度的定义与评分谱系rating spectrum每个维度在消息中应寻找的信号模式signal patterns判定评级的检测启发式detection heuristics置信度打分阈值、证据整理规则、敏感内容排除、近因加权指引与输出 schema。在讲解 8 个维度之前先建立全系统通用的置信度分级除特别注明外每个维度一致适用置信度触发条件HIGH10 条加权后一致信号且同模式在 2 项目中出现MEDIUM5–9 条信号或仅在 1 个项目内一致LOW相关信号 5 条或信号自相矛盾UNSCORED0 条相关信号不存在数据不足默认猜一个的选项注意frustration_triggers 维度对 LOW 有专门说明 —— 低沮丧事件数属于正向结论开发者总体满意不代表数据不足UNSCORED未检测到沮丧同样是有价值的发现而不是失败。四、8 个行为维度逐项详解4.1 Communication Style沟通风格衡量开发者如何组织请求、指令与反馈的结构性模式。Rating描述terse-direct简短祈使句、极少上下文直奔主题conversational中等长度消息指令与提问、自言自语混排语气自然随意detailed-structured长消息且带显式结构——标题、编号列表、问题陈述、预分析mixed无主导模式风格随任务类型或项目上下文切换信号模式包括消息长度分布均值 50 词为 terse50–200 词为 conversational200 词为 detailed祈使句与疑问句之比Markdown 标题/编号列表/代码块等结构化排版频率请求前是否提供上下文前言句子完整性跨消息补充上下文的后续跟进模式。检测启发式要点均值 50 词 祈使语气主导 极少排版 →terse-direct50–200 词 祈使/疑问混合 偶尔排版 →conversational200 词 频繁结构化排版 有上下文前言 →detailed-structured长度方差高标准差 均值的 60%且无单一风格达到 60% 以上 →mixed若风格随项目类型系统性变化也应判mixed并加 context-dependent 注释。4.2 Decision Speed决策速度衡量当 Claude 提供选项、方案或权衡取舍时开发者做出选择的快慢方式。Rating描述fast-intuitive凭经验或直觉立即决定极少斟酌deliberate-informed决策前要求对比或总结想先理解权衡research-first延迟决策、自行调研可能离开后带回结论delegator把决策交给 Claude信任其建议信号模式选项呈现到决策之间的消息间隔即时选择倾向 fast-intuitive对比请求compare these、pros and cons?外部调研痕迹I looked into X and…、according to the docs…授权语言just pick one、your call决策反复频率。检测启发式要点呈现后 1–2 条消息内用决定性语言use X、go with A选定且极少要求对比 →fast-intuitive要求权衡分析/对比表、收到对比后再定 →deliberate-informed用let me look into this推迟并带回文档/资料引用 →research-first授权语言出现 3 次以上且极少推翻 Claude 选择 →delegator。参考文档特别指出决策速度常随决策风险变化如样式选型 fast-intuitive、数据库/鉴权选型 research-first应如实报告这种 split。4.3 Explanation Depth解释深度衡量开发者希望代码旁边附带多少解释——理解与速度的偏好权衡。Rating描述code-only只要可运行代码最少或零解释能直接读懂代码concise要简短方法说明 代码记录关键决策但不过度详尽detailed要透彻讲解方法、推理与代码欣赏结构化展开educational要深层概念解释把交互当学习机会信号模式显式深度请求just show me the code、explain why、teach me about X对解释的反应跳过追问嫌多追问的深度表层能跑吗 vs 概念性为什么用此模式而非 X);代码理解信号在消息中直接引用实现细节我已熟悉 X类信号skip the basics、I know how hooks work。检测启发式要点要求只给代码/跳过解释且很少追问概念、直接引用代码细节 →code-only接受简短解释并针对具体决策做聚焦追问 →concise常问why、要求 walkthrough、欣赏结构化解释 →detailed提出超出当前任务的概念性问题、使用学习型语言I want to understand、teach me→educational。参考文档提醒解释深度常与领域熟悉度相关熟知的 React/TS 要 code-only新的数据库优化要 detailed应报告 split。4.4 Debugging Approach调试方式衡量开发者与 Claude 协作时如何处理问题、报错与意外行为。Rating描述fix-first粘贴报错就要修复对诊断兴趣极低结果导向diagnostic提供报错与上下文想在修复前先理解根因hypothesis-driven先独立排查带着具体理论找 Claude 验证collaborative把 Claude 当伙伴逐步共同排查信号模式报错呈现方式裸报错 vs I think it might be… vs Can you help me understand why…预排查痕迹说明已试过什么、是否读过日志/查过状态/隔离过问题修复后是否追问为什么会这样分步语言Lets check X first、walk me through the debugging修复接受方式立即应用还是先质疑。检测启发式要点无上下文粘贴报错、无根因追问、立即前进 →fix-first带上下文并提供原因请求 →diagnostic分享自有分析并提出理论、请 Claude 证实/证伪 →hypothesis-driven使用协作语lets且偏好增量诊断 →collaborative。4.5 UX PhilosophyUX 理念衡量开发者相对功能实现而言如何权衡用户体验、设计与视觉质量。Rating描述function-first先让功能跑起来美化延后实现期几乎不考虑 UXpragmatic一开始就保证基本可用性不丑不坏但不过度追求设计design-conscious设计与 UX 与功能同等重要注重视觉细节backend-focused主要做后端/CLI前端接触与兴趣极少信号模式设计相关请求样式、布局、响应式、动画、配色、间距美化时机实现期还是延后UI 反馈具体度make it look better vs padding 提到 16px、字重 600前后端请求占比无障碍提及a11y、屏幕阅读器、键盘导航、ARIA。检测启发式要点几乎不提 UI/UX、聚焦逻辑/API/数据、延后样式 →function-first带基本 UX 要求、提及可用性但不追求像素级 →pragmatic给出具体设计要求、把 UI bug 与逻辑 bug 同等对待 →design-conscious消息聚焦数据/性能/基础设施且几乎不碰前端 →backend-focused。参考文档强调 UX 理念天然依赖项目类型——若开发者只有后端项目需注明该评级反映可得数据未必代表其前端偏好。4.6 Vendor Philosophy选型理念衡量开发者如何选择与评估库、框架和外部服务。Rating描述pragmatic-fast什么能用用什么接受 Claude 建议或最快方案几乎不评估conservative偏好知名、久经考验、广泛采用的选项风险厌恶thorough-evaluator提交前调研备选、读文档、对比特性与权衡opinionated对特定工具有强烈先验偏好明确知道自己喜欢什么信号模式选库语言just use whatever、is X the standard?、I want to compare A vs B、were using X, period评估深度接受首个建议还是索要备选明确偏好陈述拒绝模式及其依据流行度/个人经验/文档质量依赖态度minimize dependencies、no external deps。检测启发式要点不反驳地接受建议、说sounds good、很少问备选 →pragmatic-fast询问流行度/维护度/社区并偏好industry standard/battle-tested、回避新实验品 →conservative要求对比、决策前读文档、关注边界情况/许可证/bundle 体积 →thorough-evaluator主动点名具体库、推翻 Claude 建议、表达强偏好 →opinionated。4.7 Frustration Triggers挫败触发点衡量开发者的消息中哪些因素引发可见的挫败、纠正或负面情绪信号。Rating描述scope-creep因 Claude 做了未被要求的事而恼火要受约束的执行边界instruction-adherence因 Claude 未精确遵循指令而恼火看重精确性verbosity因 Claude 过度解释/冗长而恼火要简洁regression因 Claude 修 A 弄坏已有正常代码而恼火看重稳定性信号模式纠正语言I didnt ask for that、dont do X、I said Y not Z重复指令并加重语气提示指令遵循挫败情绪语调转变转为短促、大写、感叹号、明确挫败词dont陈述——禁止内容即挫败线索挫败后的恢复速度。检测启发式要点纠正未请求的工作I only asked for X、stop adding things→scope-creep重复指令、纠正对既定要求的偏离并强调精确性I specifically said…→instruction-adherence要求变短、跳过解释、对篇幅表露厌烦 →verbosity对功能被破坏表达挫败、检查回归、说you broke X while fixing Y →regression。参考文档指出挫败触发点倾向于跨项目一致性格驱动而非项目驱动但强度会随项目重要度变化多触发点并存时报告主触发点并注明次要。4.8 Learning Style学习风格衡量开发者偏好如何理解新概念、新工具、新模式。Rating描述self-directed直接读代码、独立搞清楚向 Claude 问具体问题guided请 Claude 讲解相关部分偏好引导式理解documentation-first动手前先读官方文档与教程频繁引用文档example-driven要可直接改的可运行示例模式匹配式学习信号模式学习启动方式读代码 / 求讲解 / 求文档 / 求示例外部来源引用文档、教程、Stack Overflow、博客示例请求show me an example代码阅读指示I looked at the implementation、from reading the code…explain X与show me X消息之比。检测启发式要点引用直接读代码、提出精准问题、展现独立调查 →self-directed请 Claude 讲解概念、要 walkthrough、偏好经 Claude 中介的理解 →guided引用文档、索要文档链接 →documentation-first请求示例并修改示例、靠模式匹配学习 →example-driven。学习风格常随领域熟练度变化熟悉的 TypeScript/Node 用 self-directed新的 Rust 用 example-driven需报告 split。五、逐维度的评分执行流程Agent 在process段定义了七步执行规程其中analyze_dimensions是核心对每个维度依次执行扫描信号 → 计数证据 → 选引文 → 评估跨项目一致性 → 应用置信度 → 写 summary → 写 claude_instruction。5.1 近因加权Recency Weighting计数信号时执行近因加权最近 30 天内的信号按约 3 倍计权如 4 条近期信号 12 条加权信号。这是开发者风格会演化这一假设的体现——6 个月前简洁的开发者现在可能给出结构化长上下文。执行规则统计信号时近期信号 ×3选引文时同等表现的两条引文优先选新的近期与远期信号冲突时评级以近期为准但要在 summary 注明演化如recently shifted from terse-direct to conversational30 天窗口相对分析日期计算非固定日期。边界情况若全部会话都早于 30 天或全部都在 30 天内则不加权它们一样旧或一样新3 倍权重是指导值而非硬乘数当加权数跨越置信度阈值时应人工判断。5.2 跨项目一致性Cross-Project Consistency每个维度都要回答这个模式是否跨项目成立同一评级在 2 项目均适用 →cross_project_consistent: true模式随项目变化 →cross_project_consistent: false且 summary 必须描述分裂情况rating 字段取证据最多的主导模式由 summary 承载细节。context-dependent split 的最终裁决发生在 Phase 3 编排期编排器把分裂情况呈现给开发者如CLI/后端项目 → terse-direct前端/UI 项目 → detailed-structured询问哪一个是其一般性偏好在开发者裁决之前Claude 使用主导模式并留意上下文变化。5.3 证据引文整理Evidence Curation每个维度保留最多 3 条代表性引文8 维合计 24 条采用组合格式**Signal:** [对该引文所证明模式的解释] / **Example:** [约 100 字符的截断引文] -- project: [项目名]引文选择有四条约束偏好跨项目引文以证明模式的一致性偏好近期引文同等表现时偏好自然语言消息优先于日志粘贴、会话上下文转储和大段代码块截断到行为信号本身目标约 100 字符保留有意义片段而非整条消息——信号在中段时用 ... 表示省略绝不用 50 字符能表达信号时就贴整条 500 字符消息。引文必须携带项目名-- project: [name]这是可验证性与跨项目模式的证明基础。5.4 claude_instruction画像落地的关键字段参考文档用一整个 Schema Notes 小节强调claude_instruction是让画像从分析结论变成可执行行为的唯一通道必须用祈使句、面向 Claude、可直接照做好Provide structured responses with headers and numbered lists to match this developers communication style.坏You tend to like structured responses.好Ask before making changes beyond the stated request -- this developer values bounded execution.坏The developer gets frustrated when you do extra work.三类特殊场景的兜底写法LOW 置信度维度的指令要带试探性Try X -- ask if this matches their preferenceUNSCORED 维度使用中性兜底No strong preference detected. Ask the developer when this dimension is relevant.summary 则需 1–2 句话描述观察到的模式并附上下文相关注记。六、敏感内容排除与两层防御选定全部引文后Agent 必须做最后一轮敏感内容过滤Layer 1逐条检查以下模式模式含义sk-API key 前缀Bearer认证 token 头password凭据引用secret机密值token当作为凭据值而非概念讨论时api_key/API_KEYAPI key 引用含用户名的完整绝对路径如/Users/john/...、/home/john/...命中后的处理顺序① 用下一条不含敏感内容的最佳引文替换② 无干净替换则减少该维度证据数③ 将排除记录写入sensitive_excluded元数据数组格式如{ sensitive_excluded: [ { type: api_key_pattern, count: 2 }, { type: file_path_with_username, count: 1 } ] }这套元数据支撑纵深防御审计defense-in-depth auditingAgent 侧的 Layer 1 过滤之后还有write-profile步骤中的 Layer 2 正则过滤做第二道防线但参考文档明确要求 profiler 仍应主动回避敏感引文。纪律性约束同时规定绝不捏造证据或编造引文——每条引文必须来自真实会话消息。七、稀疏数据策略full / hybrid / insufficient 三档模式画像引擎并不假设数据永远充足。Agent 读取消息时先统计真实用户消息总数决定阈值模式真实消息总数模式行为 50full8 个维度全量分析问卷可选用户自愿补充20–50hybrid分析现有消息并为各维打分LOW/UNSCORED 维度用问卷补充 20insufficient所有维度判 LOW 或 UNSCORED建议以问卷为主画像来源并注明insufficient session data for behavioral analysis单维度数据不足的标准化处理即便消息总数超过阈值置信度置UNSCORED、summary 置 Insufficient data -- no clear signals detected for this dimension.、claude_instruction 用中性兜底、evidence_quotes 置空数组[]、evidence_count 置0。问卷补充规则hybrid 模式填补会话分析的空白维度问卷得出的评级默认 MEDIUM 置信度强烈明确选择或 LOWit varies或模糊选择若会话分析与问卷在某维度一致可上调置信度如 session LOW questionnaire MEDIUM 一致 → MEDIUM。八、输出契约analysis包裹的结构化 JSONAgent 的最终产出是包裹在analysis标签内、严格符合参考文档 schema 的完整 JSON供编排者程序化解析——Agent 定义明确禁止在标签外返回 Markdown 评论、解释或注意事项。顶层字段字段含义profile_version恒为1.0analyzed_atISO-8601 时间戳data_sourcesession_analysis/questionnaire/hybridprojects_analyzed贡献消息的项目名列表messages_analyzed处理过的真实用户消息总数message_threshold触发档位full/hybrid/insufficientsensitive_excluded被排除的敏感内容类型与计数无则为空数组dimensions8 维对象键为维度 id每个维度对象都需具备 7 个必填字段rating、confidence、evidence_count、cross_project_consistent、evidence_quotes内含 signal/quote/project 三字段的引文数组、summary、claude_instruction。8 个维度的rating枚举值如下评阅时必须逐项核对不允许发明谱系外评级communication_style: terse-direct|conversational|detailed-structured|mixed, decision_speed: fast-intuitive|deliberate-informed|research-first|delegator, explanation_depth: code-only|concise|detailed|educational, debugging_approach: fix-first|diagnostic|hypothesis-driven|collaborative, ux_philosophy: function-first|pragmatic|design-conscious|backend-focused, vendor_philosophy: pragmatic-fast|conservative|thorough-evaluator|opinionated, frustration_triggers: scope-creep|instruction-adherence|verbosity|regression, learning_style: self-directed|guided|documentation-first|example-driven返回前 Agent 须自查8 个维度齐全、每维字段完整、rating 在谱系内、confidence 为四值之一、claude_instruction 为祈使指令而非描述、sensitive_excluded已填充无排除则为空数组、message_threshold与实际消息数一致。九、从分析 JSON 到画像产物该 JSON 并非终点。编排流程 profile-user.md 将分析结果加工为三类产物报告卡Report Card以表格向用户呈现 8 维的 Rating 与 Confidence再抽取 3–4 个置信度最高、证据最多的维度组成高亮区Highlights附带最有说服力的证据引文。USER-PROFILE.md经gsd-sdk query write-profile --input $ANALYSIS_PATH --json写入$HOME/.claude/get-shit-done/USER-PROFILE.md。其落盘模板为 templates/user-profile.md以{{dimension.rating}} | {{dimension.confidence}}呈现每维评级、把claude_instruction作为Directive字段突出、按维度附 Evidence并汇总 Profile Metadata 表版本、来源、项目数、消息数、评分维度数、高/中/低置信度计数、排除的敏感内容。模板头部写明使用语义本画像由会话分析生成包含 Claude 与该开发者协作时应遵循的行为指令。HIGH 置信度维度应直接执行LOW 置信度维度应带试探语气处理。可发现工件Artifacts可选的/gsd-dev-preferencesskill、项目级CLAUDE.md画像段或全局$HOME/.claude/CLAUDE.md画像段——分别经generate-dev-preferences与generate-claude-profile--global变体生成使画像能在任意会话被 Claude 自动加载。整个流程由/gsd:profile-user命令commands/gsd/profile-user.md支持--questionnaire跳过会话分析直用问卷、--refresh在已有画像时重建并备份路由至 profile-user 编排工作流。该工作流负责把 **Phase 1会话流水线**与 **Phase 2画像引擎**串成用户体验闭环既有会话分析路径scan-sessions→profile-sample→ 孵化 gsd-user-profiler → 提取analysis也有问卷兜底路径profile-questionnaire取 8 问 → 答案 JSON → 转换分析 JSON随后进行分裂裁决Step 5、写盘Step 6、展示与工件生成Step 7–9--refresh时还对比新旧画像输出维度变更 diff。十、为什么参考文档即唯一真相值得借鉴从源码结构看画像系统的质量保障依赖三个刻意设计规则与执行分离启发式 rubric 独立成文user-profiling.mdAgent 只做忠实应用。这使得评分标准可版本化参考文档尾部标注 version 1.0、Dimensions: 8且任何新维度/新信号都必须先改参考文档而非临时改 Agent 提示。结构化可解析输出analysis标签 严格 JSON schema 让编排器能够程序化抽取避免 LLM 自由文本带来的解析脆弱性。保守拒绝而非瞎猜证据不足时输出 UNSCORED 中性兜底指令 问卷补充路径宁可降低置信度也不臆造评级敏感内容过滤采用 Layer 1/Layer 2 双层设计并保留审计元数据。这套从真实会话证据出发、分维度打分、按置信度分级、最终转化为 Claude 可执行指令的画像管线正是 get-shit-done 上下文工程理念的缩影Claude 每次对话从通用开场到逐步学会这位开发者想要多长的解释、多久拍板、什么会激怒他、他如何学习而这一切的可信度最终都建立在参考文档说了什么、真实消息里有什么这两个事实锚点之上。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考